In a previous article, we went through the steps required to set up a security dojo that is accessible for external testing. In this article, I will go through the required setups for testing Sophos XG Web Application Firewall (aka WAF or Web Server Protection).
This will be a very basic configuration designed to show you how to test and learn more about your application and WAF protection options. Picking up from the Web Security Dojo deployment guide we need to configure the WAF, firewall and the external Kali Linux testing machine. Once configured we can run a couple of tests and then 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 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 Web Server 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 firewall rule is where all of the components come together. Only once the rule is turned on is the web application available.
Is your firewall telling simply telling you the URL a threat came from but not what web page someone was one when they URL was loaded? Fastvue Reporter intelligently stitches Internet access logs together to give you a more accurate view of what sites people are accessing when 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 what the IP address is the one on which you have published the DVWA on the Sophos XG 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:
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 None. Repeat the SQL injection test, and you should see that the injection is allowed.
In the Sophos XG management console click Log Viewer in the top right. Select Web server protection on the right-hand drop down box and you should see an entries similar to the image below
We can see an error entry for WAF anomily when the Protection Policy is enabled. We can see a normal log entry for when the Protection Policy is set to none. This provides some information but not very much. Even highlighting the filter icon and getting more information only shows a subset of what is really going on.
To really see what is happening and what is being logged, we need to connect to the Sophos XG console. SSH to the device, enter the advanced shell and read the logs directly from /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 loads of 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.
\[Mon May 21 16:08:24.991640 2018\] **\[security2:error**\] \[pid 13369:tid 4074740544\]- - 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 "/content/waf/2.7.3/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 "WwLS2H8AAAEAADQ5PcQAAAAG"\], referer: http://dvwa.local/dvwa/vulnerabilities/sqli/
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.
[Mon May 21 16:08:24.992801 2018] [security2:error] [pid 13369:tid 4074740544]-
ModSecurity: Access denied with code 403 (phase 2). Pattern match "(.*)" at TX:950901-OWASP_CRS/WEB_ATTACK/SQL_INJECTION-ARGS:id. [file "/content/waf/2.7.3/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 "WwLS2H8AAAEAADQ5PcQAAAAG"], referer: http://dvwa.local/dvwa/vulnerabilities/sqli/
Following the detection, a log entry is also added for serving the 403 Permission denied page.
[Mon May 21 16:08:24.989342 2018] timestamp="1526911704" srcip="192.168.0.108" localip="192.168.0.150" user="-" host="192.168.0.108" method="GET" statuscode="403" reason="WAF Anomaly" extra="Inbound Anomaly Score Exceeded (Total Score: 28, SQLi=14, XSS=): Last Matched Message: 981243-Detects classic SQL injection probings 2/2" exceptions="-" duration="3846" url="/dvwa/vulnerabilities/sqli/" server="dvwa.local" referer="http://dvwa.local/dvwa/vulnerabilities/sqli/" cookie="security=low; security=low; PHPSESSID=oa4ve58sarjni1io1iig1c9bi1" set-cookie="-" recvbytes="507" sentbytes="437" protocol="HTTP/1.1" ctype="text/html" uagent="Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0" querystring="?id=%25%27+or+%270%27%3D%270&Submit=Submit" websocket_scheme="-" websocket_protocol="-" websocket_key="-" websocket_version="-" ruleid="7"
Compare that to the same request when no inspection is being performed
[Mon May 21 15:57:48.758134 2018] timestamp="1526911068" srcip="192.168.0.108" localip="192.168.0.150" user="-" host="192.168.0.108" method="GET" statuscode="200" reason="-" extra="-" exceptions="-" duration="9654" url="/dvwa/vulnerabilities/sqli/" server="dvwa.local" referer="http://dvwa.local/dvwa/vulnerabilities/sqli/?id=%25%27+or+%270%27%3D%270&Submit=Submit" cookie="security=low; security=low; PHPSESSID=oa4ve58sarjni1io1iig1c9bi1" set-cookie="-" recvbytes="508" sentbytes="1865" protocol="HTTP/1.1" ctype="text/html" uagent="Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0" querystring="" websocket_scheme="-" websocket_protocol="-" websocket_key="-" websocket_version="-" ruleid="7"
You can see how the UI logs provide you with some basic information that would indicate an issue but not really enough information to be able to tune your WAF to eliminate false positive or negatives.
You now have a basic setup on which you can test various vulnerabilities. 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.
Attacking and Testing Sophos SG Web Application Firewall
Testing Web Application Firewalls with Web Security Dojo