Go to next/previous page

WOF(Walk on the Fire)

In today's age, hundreds of vendors have come up with Web Application Firewalls(WAFs) with false promises and defacing mechanism. But at the end of the day, the biggest concern of the End user(Website owner or WAF Buyer) is WAF behaviour and number of false positives(or legitimate traffic blocking) encountered. There are so many Commercial Firewalls like F5, Barracuda, Imperva, etc. and Open Source Firewalls like ModSecurity, Naxsi, etc. But not all of the WAF vendor came up with the idea of passive mode(or listening mode, a mode in which attacks are only detected but not blocked by the firewalls).

Generally banking and critical infrastructure sites does not prefer to put any WAF in Inline Mode as it might block the legitimate data. Instead they want it in Learning/Passive Mode which detects attacks. But what if the existing WAF vendors doesn't provide passive or learning mode? (e.g ModSecurity or Naxsi, or some other commercial or open source WAFs). So here is the solution:

Any Web Application Firewall works independent of the Back End Website technologies on which it is planted(whether Back End Website is hosted over Apache,IIS etc. or whether Back End technology is html, php, asp, etc.). For example, assume there is one website named which is behind a Web Application Firewall, and assume this website has one input parameter .var. which, at the time of request looks something like :

In this scenario, WAF, which is planted in front of doesn't care whether the parameter name is .var. or something else. In other words, Web Application Firewalls doesn't have Blueprint(map) of the Back End Website. We can use this bug of Web Application Firewalls to make a Passive/Listening Mode for any Web Application Firewall, no matter whether vendor is supporting Passive Mode or not.We can cheat WAFs by using concepts of HTTP protocol, a stateless protocol (it's tag is showing it's advantage). Assume the same example of in which user passes argument .var. equals to .123. which will look like,

But let's assume you have one sniffer running on the reverse proxy or on local server on which site is hosted, Now this sniffer (I tested with several WAFs like mod security , naxsi and some other commercial WAFs)will forwards traffic to the WAF which is :

1) Installed on the same machine but listening on different NIC

2) Installed on some public IP with DNS name like (On which WAF is in Inline-mode) So this HTTP Stack decoding and mirroring new HTTP Stack with different hostname on which WAF is installed in inline mode. So there is no impact of WAF over the end-website.

I.e. will be translated like by Sniffer listening on Reverse proxy (or on the different NIC of webserver). Now on, there are no files like .in.php. or no variable named .var. but WAF doesn?t care about this. In another words we are fooling WAF , How ?

I.e. (by normal user ) which will be dropped by coz there is no file called .in.php. exist over the server and also value of .var. is not making any attack (you can say it is legitimate and acceptable).But imagine the same request but like this :< script>alert("xss attack vector")< /script> which will try to exploit website variable .var. with XSS attack vector. So the above request will be blocked(though there is no file exist named .in.php. file or there is no parameter exist .var. exist over the WAF box, and due to the reason that WAF doesn't know the blueprint of back-end website, We are fooling WAF).

So there will be two possibilities at WAF End:

1)If traffic is legitimate and not hitting any rule described in WAF, it will be dropped by WAF Box. (Reason: there is a dumb hello page installed on this box with all WAF rules, so no real pages exist) 2)If traffic is hitting some rules of WAF (or traffic issome attack vector, harmful to the website), it will be Forbidden (403) or blocked which is captured by our sniffer. (Reason: It hits a attack signature which is described as a rule in WAF)

So the for understanding, see below setup:

Website Visitors <--> (Reverse_proxy+our sniffer) <--> Actual website behind reverse proxy

(Assume that WAF Box is over some public IP out of the above setup and our sniffer sends mirrored traffic to WAF box in order to execute all the WAF Rules against the mirrored HTTP request from the real source, in another word we are .Simulating Web Application Firewall. with HTTP traffic Mirroring).

So .our sniffer. will decode visitors request (including cookies, referer and all HTTP stack parameters) and it will create and throw one new HTTP request which is mirrored from the original traffic to the WAF box (which is defined by us in sniffer code).Sniffer also logs HTTP RESPOSNSE codes(like 403,406,404 etc) So there will be two possible

response codes:

1) 404 (Not found , for all legitimate traffic which is not hitting any rule of WAF)

Why 404?

Coz if traffic is not hitting any WAF rules then it will be thrown to the apache dumb page (i.e. apache's common .its works. message page)which doesn?t contain any parameters or cookies)

2) 403,406 etc (Forbidden or blocked , for traffic which has attack vector and which hits any of WAF rules)

Why 403 or 406?

Coz Web Application Firewalls rule was hit by the request which is sent by our sniffer. No matter whether in backend apache hello page, the requested variable exists or not.

Final Picture:

1) Request is sent by the end-user of the website

2) Request arrives at reverse proxy box on which sniffer is also installed

3) Request is received by reverse proxy and reverse proxy will forward this to the actual website, At the same time, Sniffer also mirrors all HTTP fields (including cookies,referrer etc) and re-builes and throws the request to the WAF Box (WAF Simulation).

4) Actual Client request is served by respective response by Original webserver , at the same time, Sniffer also gets HTTP_RESPONSE (like 404 or 403,406) code for mirrored request which is sent to the WAF Box(which is in .inline-mode. at some remote box).

5) User can collect the blocking logs from WAF box which is the simulation of the real traffic. Without touching the actual requests.


  • No CPU and memory utilization required on the reverse proxy box.
  • No interference in the actual HTTP_REQUEST and HTTP_RESPONSE.
  • No need to put any WAF from any vendor in inline-mode.
  • No tension of false positive while there is a detection of attacks is going on by WAF.
  • Overall CPU and Memory usage is pretty lower because WAF rule processing is done over some third party system.
  • Similar to Gartner's RASP concept


  • Sniffer should be capable of handling Gbps traffic otherwise it will drop certain HTTP_REQUESTs and HTTP_RESPONSESs (Sniffer should be implemented in PF_RING instead of libpcap or some other TCP wrappers)
  • Problem in finding some of the Business Logic Vulnerabilities by using above mechanism.


  • By mirroring the traffic, we are sending two requests, one by reverse proxy and other by sniffer (which is also installed over the reverse proxy machine) to actual website and to WAF box respectively.

  • WAF Box over some public IP can be in any mode (either .inline mode. or .learning mode.), no matter.

  • This whole procedure is not even touching the single bit of HTTP_REQUEST or HTTP_RESPONSE due to the reason that HTTP REQUEST and HTTP RESPONSE decoding and encoding is done by Sniffer which is installed on reverse proxy box.

  • In case of SSL, we can use the same phenomenon by using technique of .SSL-Offloading. in order to get dencrypted traffic or you can install this on the same web-server but on different NIC.

Leave a comment