Guide
Installing a Web Application Firewall on
Ubuntu Server 22.04
- Nuno Romão
Objective:
In this lab you’ll will be able to follow the step-by-step guide to install a Web Application
Firewall to protect your web Apps, as well as set your Ubuntu Server as a reverse proxy in case
your website is hosted in another server.
1
[© Nuno Filipe Romão Pereira]
In this exercise we’ll be using the following network design.
Figure 1 - Network typology
We’ll be focusing mostly on the demilitarized zone.
Our Web Application Firewall is an Ubuntu Server 22.04 and our Web Server is a Windows Server
2022 with Internet Information Services installed.
The WebServer will be hosted behind the WAF server in it’s own dedicated network, and our WAF
will work in a reverse proxy manner.
Here are the IP addresses used in the exercise:
Firewall (pfsense) – DMZ interface: 172.16.0.254
WAF DMZ network: 172.16.0.10
WAF DMZ dedicated network: 172.16.1.10
Web Server (Windows): 172.16.1.1
2
[© Nuno Filipe Romão Pereira]
Figure 2 - WAF server network configuration
Temporarily we’ll open up communications in our Firewall to install software and update our
systems.
Figure 3 - Apache2 installation
Install apache2 as the WAF we’ll be using is ModSecurity and it works with Apache.
Then install ModSecurity module.
Figure 4 - ModSecurity2 installation command
After installing ModSecurity, we need to make sure “modsecurity.conf” file exists and it is
recommended to change the way ModSecurity is working, as by default it will work in
“DetectionOnly” and we need to change it to “On” in order to block malicious requests.
NOTE: After installation modsecurity.conf doesn’t exists, the file has the name
modsecurity.conf-recommended and it needs to be changed.
3
[© Nuno Filipe Romão Pereira]
To perform this change go to /etc/modsecurity.
Figure 5 - modsecurity.conf creation
Edit modsecurity.conf and change the default value for SecRuleEngine.
Figure 6 - Change SecRuleEngine to "On" to block any malicious requests
Once this is done, we can use the OWASP project Core Rule Set rules in our ModSecurity.
Before we begin, please create a backup of modsecurity-crs folder in /usr/share.
Figure 7 - Create a backup of the original modsecurity core rule set folder
4
[© Nuno Filipe Romão Pereira]
Go to OWASP core rule site GitHub.
Figure 8 - Search for owasp core rule set
Figure 9 - Go to Github page for this project
5
[© Nuno Filipe Romão Pereira]
Copy the git link.
Figure 10 - Github project cloning
Paste the link and give modsecurity-crs as the name of the folder where all git content should be
cloned to.
Figure 11 - Clone github repository to modsecurity-crs folder
Now create a crs-setup.conf file from the crs-setup.conf.example document.
Figure 12 - Creation of crs-setup.conf
6
[© Nuno Filipe Romão Pereira]
Once that is done, it is time to include all the rules present in /usr/share/modsecurity-crs/rules on
our apache module.
Edit the security2.conf file at /etc/apache2/mods-enabled/security2.conf.
Figure 13 - ModSecurity2 mod configuration file
Add the following lines.
Figure 14 - Identify files to be loaded with ModSecurity2
You may restart your Apache2, and be aware it may throw an error.
Don’t worry, we’ll see what the problem is with the rules and since it is a rule that is compatible
with modsecurity version 3, we’ll need to remove this file for the time being as at the time of
writing, modsecurity3 is still not available from the repositories and it would be necessary to
compile it from source. We’ll not be focusing on that process in this guide, so we are just going to
move our rule to another folder.
7
[© Nuno Filipe Romão Pereira]
Figure 15 - Apache2 error when restarting the service
Use journalctl -xe to view which rule is giving us problems.
Figure 16 - journalctl -xe output
Figure 17 - journalctl -xe output
Let us move the rule to the home folder of our user.
8
[© Nuno Filipe Romão Pereira]
Figure 18 – Moving the rule that is giving an error to another folder
Let us restart apache again.
Figure 19 - Apache2 restarted successfully
If you want to know which version of modsecurity you are using, you can use the following
command:
apt-cache show libapache2-mod-security2 | grep -E '(Version|Package)'
Figure 20 - View which version of apache2 you are currently using
Now we need to make sure that ModSecurity is working.
To test if the system is working, we’ll be using a Kali Linux machine on the “INTERNET netwok (NAT
Network)” showed previously in our network typology.
Keep in mind that our Firewall already has packet forwarding setup on it’s NAT configuration.
Figure 21 - Port forwarding configuration in our PfSense
9
[© Nuno Filipe Romão Pereira]
Figure 22 - Firewall networks
From what we can see in our firewall, the 67.83.0.7 is our public interface, and Kali will try to
connect to our WAF through that IP address.
NOTE: This “public” IP address is set in a controlled environment and is not in any way connected
or related to the real 67.83.0.7 IP address in the real world.
In Kali we can confirm that we can connect (“ciseg.pt” is defined in our hosts for this lab)
Figure 23 - Web page access from Kali Linux
10
[© Nuno Filipe Romão Pereira]
Figure 24 - hosts configuration on Kali Linux
Let us do a scan with Nikto and see if our ModSecurity is stopping malicious requests.
On kali run the scan.
Figure 25 - Nikto attempting to scan the ciseg.pt website
We can see the logs generated by modsecurity in the following error.log file.
Figure 26 - See apache2 error logs
11
[© Nuno Filipe Romão Pereira]
Figure 27 - Sample of messages being generated in error.log
When we run the tail command the output will run very fast in your screen, while nikto is still
running.
Since it is working, we should configure our reverse proxy and send allowed communications to
the IIS server.
Figure 28 - Creation of ciseg.pt.conf configuration file
Figure 29 - Reverse proxy configuration for HTTP connections
12
[© Nuno Filipe Romão Pereira]
Make sure your WAF has hosts file configured.
Figure 30 - WAF server hosts file configuration
Let us enable proxy module and our website, with
a2ensite ciseg.pt
a2enmod proxy
a2enmod proxy_http
Figure 31 - Enabling website and proxy module
Figure 32 - enabling proxy_http module
13
[© Nuno Filipe Romão Pereira]
Figure 33 - Accessing website from Kali Linux machine
Even with a proxy enabled you’ll be able to connect to your website and ModSecurity will still be
able to block malicious connections to our website.
This is just a small feature to improve your security posture, but take into consideration that we
should activate Transport Layer Security.
14
[© Nuno Filipe Romão Pereira]
