by
Etienne Liebetrau
In a previous article, we set up a security dojo that is accessible for external testing and configured Sophos XG's Web Application Firewall to protect a vulnerable web server.
In this article, I will go through the same steps, but this time using Sophos UTM SG's Web Application Firewall. This will be a very basic configuration designed to show you how to test and learn more about your application and WAF protection options in Sophos UTM (SG).
Picking up from the dojo deployment guide, we need to configure the Sophos SG Web Application Firewall and the external Kali Linux testing machine. Once configured we can run a some tests and inspect the behavior and logging.
The Damn Vulnerable Web Application (DVWA) is a great place to start since it allows for multiple exploits with differing levels or native protection. It also runs on HTTP port 80 which makes things just a little easier initially. Before we start configuring additional devices, confirm that you are able to connect to the Dojo and that the DVWA site is accessible from another machine on the LAN. Make a note of the IP address.
There are four components on the Sophos UTM that need to be configured to publish the web application.
The host object is the device or IP address that may contain the various services (or sites) you want to test.
Defining a Real Webserver allows you to specify a particular service on a host object.
This policy is essentially the WAF profile or settings that will be applied. It is specific to web application traffic.
The Virtual Webserver rule is where all of the componenets come together. Once the rule is turned on, the web application is available. There is no explicit firewall rule required.
Most firewalls tell you the URL a threat came from but not the web page someone was one when the URL was loaded. Fastvue Sophos Reporter intelligently stitches Internet access logs together to give you a more accurate view of what sites people are accessing where undesirable files are downloaded from. Try the free 30 day trial.
The attacking machine needs to be configured with the hosts file to enable name lookup and correct header formation. Confirm the IP address on which you have published the DVWA on the Sophos UTM SG appliance.
Edit the hosts file on the attacking machine to at least include DVWA. The file is located at /etc/host
for Linux or c:\Windows\System32\Drivers\etc\hosts
for Windows. Your entry should be similar to this:
192.168.3.150 dvwa.local
You should now be able to connect to the DVWA with the following link
The following procedure allows you to execute the basic SQL injection test. Open a browser on the attacking machine and follow the steps:
You should now be presented with a 403 Forbidden Screen.
To confirm that the WAF is the cause for the protection you need to change the firewall rule, by setting the the Protection Policy to ::No Profile::. Repeat the SQL injection test, and you should see that the injection is allowed.
In the Sophos SG management console, mouse over the logviewer (clipboard icon) and select Web Application Firewall. The log viewer will show you WAF events such as profile changes being applied, and security warnings for when suspect traffic is detected and served content.
The live log viewer is okay to get a general overview of what is happening but to really work with the log you will need to SSH to the device, and read the logs directly from var/log/reverseproxy.log
Below is one of several entries that are generated when an attack is identified. In this case, since it is such a generic attempt, there are 6 matches of a potential exploit. These are detection entries and contain great information.
The id field shows the specific rule that was triggered. This is important should you need to exclude the rule for being a false positive. You can also see the actual arguments that triggered the detection being shown in the Matched Data section.
2018:05:24-14:59:55 et-hom-lab-utm httpd\[11554\]: \[security2:error\] \[pid 11554:tid 4113574768\] \[client 192.168.0.108\] ModSecurity: Warning. Pattern match "(?i:(\[\\\\\\\\s'\\\\"\`\\\\xc2\\\\xb4\\\\xe2\\\\x80\\\\x99\\\\xe2\\\\x80\\\\x98\\\\\\\\(\\\\\\\\)\]\*?)(\[\\\\\\\\d\\\\\\\\w\]++)(\[\\\\\\\\s'\\\\"\`\\\\xc2\\\\xb4\\\\xe2\\\\x80\\\\x99\\\\xe2\\\\x80\\\\x98\\\\\\\\(\\\\\\\\)\]\*?)(?:(?:=|<=>|r?like|sounds\\\\\\\\s+like|regexp)(\[\\\\\\\\s'\\\\"\`\\\\xc2\\\\xb4\\\\xe2\\\\x80\\\\x99\\\\xe2\\\\x80\\\\x98\\\\\\\\(\\\\\\\\)\]\*?)\\\\\\\\2|(?:!=|<=|>=|<>|<|>|\\\\\\\\^|is\\\\\\\\s+not|not\\\\\\\\ ..." at ARGS:id. \[file "/usr/apache/conf/waf/modsecurity\_crs\_sql\_injection\_attacks.conf"\] \[line "77"\] \[id "950901"\] \[rev "2"\] \[msg "SQL Injection Attack: SQL Tautology Detected."\] \[data "Matched Data: '0'='0 found within ARGS:id: %' or '0'='0"\] \[severity "CRITICAL"\] \[ver "OWASP\_CRS/2.2.7"\] \[maturity "9"\] \[accuracy "8"\] \[tag "OWASP\_CRS/WEB\_ATTACK/SQL\_INJECTION"\] \[tag "WASCTC/WASC-19"\] \[tag "OWASP\_TOP\_10/A1"\] \[tag "OWASP\_AppSensor/CIE1"\] \[tag "PCI/6.5.2"\] \[hostname "dvwa.local"\] \[uri "/dvwa/vulnerabilities/sqli/"\] \[unique\_id "Wwa3S8CoAKAAAC0ioVoAAAAC"\]
The detection entries are followed by a conviction entry indicating that enough detection has been done to satisfy a conviction and that this request will be blocked. The WAF security module generates these detection and conviction entries even though it does not relate to any page or response being served.
2018:05:24-14:58:43 et-hom-lab-utm httpd\[11280\]: \[security2:error\] \[pid 11280:tid 4130360176\] \[client 192.168.0.108\] ModSecurity: Access denied with code 403 (phase 2). Pattern match "(.\*)" at TX:950901-OWASP\_CRS/WEB\_ATTACK/SQL\_INJECTION-ARGS:id. \[file "/usr/apache/conf/waf/modsecurity\_crs\_inbound\_blocking.conf"\] \[line "26"\] \[id "981176"\] \[msg "Inbound Anomaly Score Exceeded (Total Score: 28, SQLi=14, XSS=): Last Matched Message: 981243-Detects classic SQL injection probings 2/2"\] \[data "Last Matched Data: '0'='0"\] \[hostname "dvwa.local"\] \[uri "/dvwa/vulnerabilities/sqli/"\] \[unique\_id "Wwa3A8CoAKAAACwQ7hEAAAAA"\]
Following the detection, a log entry is also added for serving the 403 Permission denied page.
2018:05:24-14:58:43 et-hom-lab-utm httpd: id="0299" srcip="192.168.0.108" localip="192.168.0.160" size="235" user="-" host="192.168.0.108" method="GET" statuscode="403" reason="waf" extra="Inbound Anomaly Score Exceeded (Total Score: 28, SQLi=14, XSS=): Last Matched Message: 981243-Detects classic SQL injection probings 2/2" exceptions="-" time="4506" url="/dvwa/vulnerabilities/sqli/" server="dvwa.local" port="80" query="?id=%25%27+or+%270%27%3D%270&Submit=Submit" referer="http://dvwa.local/dvwa/vulnerabilities/sqli/" cookie="security=low; PHPSESSID=pdeqonqmr58lvohadklsm4a7u0" set-cookie="-" uid="Wwa3A8CoAKAAACwQ7hEAAAAA"
Compare that to the same request when no inspection is being performed
2018:05:24-14:53:50 et-hom-lab-utm httpd: id="0299" srcip="192.168.0.108" localip="192.168.0.160" size="1610" user="-" host="192.168.0.108" method="GET" statuscode="200" reason="-" extra="-" exceptions="-" time="6171" url="/dvwa/vulnerabilities/sqli/" server="dvwa.local" port="80" query="?id=%25%27+or+%270%27%3D%270&Submit=Submit" referer="http://dvwa.local/dvwa/vulnerabilities/sqli/" cookie="security=low; PHPSESSID=pdeqonqmr58lvohadklsm4a7u0" set-cookie="-" uid="Wwa13sCoAKAAACXl6TwAAAAF"
Lastly, you can enable Permit mode on the firewall profile. This will detect attacks and log them as such but will still allow the attack to go through.
**2018:05:24-14:59:55** et-hom-lab-utm httpd\[11554\]: \[**security2:error**\] \[pid 11554:tid 4113574768\] \[client 192.168.0.108\] ModSecurity: Warning. Operator GE matched 5 at TX:inbound\_anomaly\_score. \[file "/usr/apache/conf/waf/modsecurity\_crs\_correlation.conf"\] \[line "37"\] \[id "981204"\] \[msg "Inbound Anomaly Score Exceeded (Total Inbound Score: 28, SQLi=14, XSS=): 981243-Detects classic SQL injection probings 2/2"\] \[hostname "dvwa.local"\] \[uri "/dvwa/vulnerabilities/sqli/"\] \[unique\_id "Wwa3S8CoAKAAAC0ioVoAAAAC"\]
**2018:05:24-14:59:55** et-hom-lab-utm httpd: id="0299" srcip="192.168.0.108" localip="192.168.0.160" size="1610" user="-" host="192.168.0.108" method="**GET" statuscode="200"** reason="-" extra="-" exceptions="-" time="13944" url="/dvwa/vulnerabilities/sqli/" server="dvwa.local" port="80" query="?id=%25%27+or+%270%27%3D%270&Submit=Submit" referer="http://dvwa.local/dvwa/vulnerabilities/sqli/" cookie="security=low; PHPSESSID=pdeqonqmr58lvohadklsm4a7u0" set-cookie="-" uid="Wwa3S8CoAKAAAC0ioVoAAAAC"
You now have a basic setup on which you can test various vulnerabilities using Sophos SG's Web Application Firewall features. I encourage you to play around with adding additional targets and attempting to find the exploits that exist in the vulnerable sites. Then attempt to use the WAF functionality to mitigate the issue. Looking at the raw log is, unfortunately, the only way to get actual visibility into what is happening from the WAF perspective.
Fastvue Reporter produces clean, simple, web usage reports using data from your firewall that you can confidently send to department managers and HR team. Automate reports and get the job of reporting on web usage off your desk and into the hands of people that need it. Download the 30-day free trial today!
Download our FREE 30-day trial, or schedule a demo and we'll show you how it works.
Active Directory SSO Authentication in Transparent Proxy Mode
Attacking and Testing Sophos XG Web Application Firewall