WASC Distributed Web Honeypots Project Update
As the WASC Distributed Web Honeypots Project Sponsor, we are excited to announce that we have officially launched the next phase of the project! If you would like to participate, please read below.
Project Overview
The goal of the Distributed Web Honeypot (DWH) Project is to identify emerging attacks against web applications and report them to the community. This may include automated scanning activity, probes, as well as, targeted attacks against specific web sites or applications. The scope of this project has recently been expanded to include deployment of both standard web application honeypots and/or open proxy honeypots. Project participants may choose whether they want to run their honeypot as an open proxy or a stand-alone sensor.
Project Leader
If you would like to be involved with the project, please contact the project leader - Ryan Barnett (rbarnett
trustwave.com).
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 provide technical details about web-based 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?
How did you configure this web honeypot?
The new WASC web honeypot architecture 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. You shoud, however, consult your ISP's AUP info before deploying any web servers. 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:
How to Participate
There are two ways to participate:
- Deploy a honeypot sensor
You can participate by deploying the WASC Web Honyepot sensor on your own network. WASC has created a VMware image of the standard sensor. This image includes all of the software to quickly get your sensor up and running with little configuration on the end user's part. You must contact the project leader via email in order to participate. You will then recieve the link location to download the VMware image. You will need to have the free version of VMware player or Server. If you would like to deploy a honeypot sensor, include the following details in your email to the project leader:
- Sensor Point of Contact (POC) name
- Source IP address that the logs will be coming from
- Geographic location (Country, State, Locality)
- Network Block Owner
The Project Leader will send back an email with instructions for downloading the VMware honeypot image data and the OS root credentials. The VMware host is configured with dhcp, so after you login, verify that the host has successfully obtained an IP address. The Project Leader will also provide you with the ModSecurity log agent credentials you will need to authenticate when sending your log data. ModSecurity uses a C program called mlogc located in the /usr/local/apache/conf/ directory. This program will take the data generated by the ModSecurity concurrent audit log and uses HTTP PUT requests to upload the individual audit_log files to the central console host. Each WASC honeypot sensor will have a unique username/password combination. The file that you will need to update is /opt/wasc-honeypot/etc/mlogc.conf. The final step is to start up the apache web server - /etc/init.d/wasc-honeypot-ctl.sh start. You should then review the log files to ensure that they everything is working properly.
- Data analysis
Even if you do not deploy a honeypot sensor, we need help with data analysis for the capture traffic. We will provide access to the ModSecurity AuditConsole web interface to all project participants. The AuditConsole has built in searching and reporting functions that may be used for batch analysis. We will provide all project participants with a reporting procedure so that we have a consistent process for vetting data prior to releasing to the public.