1

For my final year project, I wanted to do a comparative analysis of 2 WAF's ModSec/Shadow Daemon and web-based honeypot SNARE/TANNER.

I wanted to find out if there are any benefits of placing WAF inline of a web-based honeypot. Does it defeat the purpose of a honeypot by placing WAF inline? Can WAF add value in terms of deception capabilities or aid in the development of future mitigation techniques? For instance, determine what attacks bypass WAF, if so what attacks be caught by the honeypot? I know this boils down to the honeypots limitations as it's low-interaction and applies vulnerability type emulation rather than actual vulnerabilites.

  1. Would an inline WAF make the honeypot appear more attractive by making it more difficult to attack?

  2. Can consolidating WAF and honeypot attack vector logs though SIEM aid in adding context to the data generated?

The first approach requires a live deployment which I currently don't have time for to test this. The second approach would be ideal because I could use WAF testing frameworks such as WA3F, Web Goat, Imperva ect which would can be tested in a virtual environment.

This research topic has not been done before, I don't know why. I just want to confirm whether it's a waste of time or I’m going about it the wrong way.

  • 1
    It looks like you have an X/Y problem. First, why do you want to test the combination without knowing the answers to all these questions first? Second, everything you state that you want a WAF to do can be done on the honeypot. Third, what outcomes are you looking for? You don't start an experiment and then figure out what you are trying to study along the way. Do you want to study WAF evasion techniques? What is it exactly that you want to study here? Fourth, being a "challenge" does not make a target attractive to hackers: they are looking for the value in the hack. – schroeder Apr 2 at 6:36
  • Thanks for your valueable insight. I think this is the issue what I'm trying to wrap my head around. Intially I wanted to do a comparative analysis of web-based honeypots but because SNARE/TANNER is the only one out there along with Glastopf (it's predesessor/no longer supported) through that out of the window. Yes I want examine current WAF evasion techniques against default WAF deployment settings. Can a honeypot be a useful mechinisim in adding value to WAF bypassing techniques attack data? If the honeypot captures bypassing techniques exploits, can't this be used to generate new rules? – DanKi Apr 2 at 8:11
  • 1
    This approach is much clearer. Using a web honeypot as a basis to analyse what escapes a WAF is useful. Just remember that a WAF is not a drop-in, fire-and-forget tool. WAF needs to be configured to counter specific threats. A useful research vector is watching what gets through the WAF even when it is configured to block specific things. this approach allows you to be free with the "honeypot" you use and even allows you to craft your own web target that's not a honeypot but just something with a lof ot logging. – schroeder Apr 2 at 8:58
  • Thanks for the clarification, I greatly appreciate it. As this has not been done before, this has definitely helped in being more specific. WAF and Honeypot research in general seems to be lacking, very little output in recent years, which made it difficult to identify a topic. Although I knew what I wanted to do, it was just a case of narrowing it down. Once again, thanks for your guidance. – DanKi Apr 2 at 9:37
0

Would an inline WAF make the honeypot appear more attractive by making it more difficult to attack?

Many websites are built out having load balancers/WAF in front of the actual web servers. It’s quite common. They’re also used for SSL/TLS termination to boost performance. That said, it does add complexity in that a vulnerability in your WAF implementation could result in the attacker having an alarming level of access. A great example of this is HeartBleed.

Can consolidating WAF and honeypot attack vector logs though SIEM aid in adding context to the data generated?

Sure, however rules need to be created for the SIEM to digest/correlate the two additional data points.

WAF Benefits

There are two major advantages with placing a WAF in front of your web application honey pot.

  1. SSL/TLS termination. This is pretty much required so the request/response can be inspected.
  2. Prevent the hacking others. The honeypot deployment shouldn’t send malevolent traffic out to the Internet. Nor should it be a place for an attacker to send unsuspecting users. An example being a persistent XSS. Both of these should be prevented so you're not aiding the attacker.

Legal

I'm not a lawyer nor is this the place to seek legal advice.

With that out of the way, there are legal concerns with running a honeypot as brought up in a prior post:

What is the current U.S. law regarding the building of and deployment of honeypots?

  • Thanks for your response, I shall look into these further as a part of my research. – DanKi Apr 7 at 2:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.