|Join hundreds of other Developers and InfoSec professionals for Training, Sessions and Community at our first conference of 2019|
[AppSec Tel Aviv, May 26-30th]
OWASP WASC Distributed Web Honeypots Project
OWASP WASC Distributed Web Honeypots Project
The goal of the OWASP WASC Distributed Web Honeypots Project is to identify emerging attacks against web applications and report them to the community including automated scanning activity, probes, as well as, targeted attacks against specific web apps.
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.
This project fills a need in the web application Defender's community to have detailed data about mass web application scanning attacks such as those being operated by Botnets. This project will provide detailed data about attacks and their origins.
The OWASP WASC Distributed Web Honeypots Project is free to use. It is licensed under the Apache 2.0 License.
What is the OWASP WASC Distributed Web Honeypots Project?
The OWASP WASC Distributed Web Honeypots Project provides:
News and Events
This project can be purchased as a print on demand book from Lulu.com
There are two ways to participate:
Deploy a honeypot sensor
You can participate by deploying the Web Honyepot sensor on your own network. We 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 receive 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 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.
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.
- 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:
The OWASP WASC Distributed Web Honeypots Project is developed by a worldwide team of volunteers. The primary contributors to date have been:
- Felipe Costa
- Chaim Sanders
As of April 2015, the priorities are:
The main roadmap item is to solicit participants to deploy Sensors to collect data. The main deliverables for this project are: 1) Real-world web attack data, 2) Real-time web attack data and 3) Technical details that can be leveraged by the OWASP Defenders community to help protect their websites. Think of this project as somewhat similar to the SANS Dshield project where the community correlates data and can also obtain reputation services for blocking IP addresses, etc...
| PROJECT INFO
What does this OWASP project offer you?
| RELEASE(S) INFO|
What releases are available for this project?