Quick Links
Homepage
Why are you doing this?
Web attacks are increasing at an alarming rate. There are constant news stories of web application breaches; however there is normally not much technical information as to what vulnerabilities were exploited. See the WASC Web Hacking Incident Database (WHID) for data. Without knowing how the attackers were able to compromise the web site, we do not know how to protect our web applications. This is one of the main goals of this project - to shed light onto these web-based attacks in order to provide technical details about the attack vectors. This project aims to answer the following types of questions:
- What web applications are the bad guys targeting?
- Are they using new tools or techniques?
- Is there a new worm out on the web that is mass rooting websites?
Isn't ISC/Dshield already doing this?
The Web Honeypot is a component of the DShield project and their goal is to build something like DShield (which collects firewall logs) for webapps. The goal of their project is to collect quantitative data measuring the activity of automated or semi-automated probes against web applications. They look for "probes" rather than actual "attack" payloads. They are after more of the http "background noise".
How did you configure this web honeypot?
This new WASC web honeypot is setup with the following:
- ModSecurity web application firewall engine.
- OWASP ModSecurity Core Rule Set (CRS).
- Centralized logging of the ModSecurity audit_log data with the mlogc program along with the Trustwave SIEM and the ModSecurity Audit Console.
Are there any legal issues I should be concerned with?
The short answer is yes - if you choose to run your honeypot as an open proxy server. There are some legal issues to be aware of in this type of honeypot setup where we will be capturing third party user information. The Honeynet Project has excellent information on the challenges and issues surrounding due diligence in deploying honeypots/honeynets. Refer to this paper on Honeynets. In their book Know Your Enemy they have an entire chapter dedicated to Legal Issues. It is this concern over increased risk why we expanded the project scope to allow for deployment of stand alone web sites instead of running it as an open proxy.
Should I run this on my production environment?
That depends on your risk tolerance and whether or not you want to run the honeypot as an open proxy. If your organization is willing to approve it, then the program itself is a virtual host and will run under any host that runs VMware. We have many varied organizations participating ranging from universities, ISPs and government networks.
Can I run the sensor at home?
Sure, many participants are running the sensors from their home network. There may be conflicts with your ISP allowing inbound HTTP traffic however the honeypots are pre-configured to listen on common proxy ports including 8000, 8080 and 3128.
Should I announce the honeypot IP address on public lists?
That is up to you however be aware that if the sensor IP address becomes posted to pubic open proxy lists that more than likely your sensor will become flooded with SPAMMER traffic.
What prerequisites do I need to participate?
An understanding of ModSecurity functionality will help to understand the rules and logs being generated. Review the following:
Comments (0)
You don't have permission to comment on this page.