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. Without knowing how the attackers were able to compromise the web site, we do not know how to protect against these attacks.
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. 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? This project aims to answer these types of questions.
Are there any legal issues I should be concerned with?
The short answer is yes. There are some legal issues to be aware of in this type of honeypot setup where we will be capturing third party user information. In order to avoid many of the legal issues surrounding monitoring this traffic (such as violating US Wiretapping Statues, etc…) we must banner our honeypot web servers. These banners announce to the user that their traffic will be monitored. We implement banners both on the main index webpage and also in an HTTP response header that specify this monitoring. This technique constitutes an exemption to the wire tapping statue and allows the monitoring since use of our proxy constitutes consent to monitoring.
The second area of concern deals with the concept of Data Control, which is our ability to identify and block malicious web requests and not forward them onto the target web site. In order to facilitate this functionality, we have implemented various security modules into our Apache build such as ModSecurity, Mod_Evasive, etc… If you are not familiar with these modules, you should read the appropriate documentation from their web sites to fully understand their functionality.
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.
How did you configure this open proxy honeypot?
There are many unique configurations that are required for this deployment as our goal is to function as a legitimate proxy server while still identifying and blocking malicious requests. For background information on the general configurations of the open proxy honeypot, please review this document - http://honeypots.sourceforge.net/open_proxy_honeypots.pdf. The document outlines the settings and configurations that went into the Gen I setup. You can also review the Honeypot Project’s Scan of the Month Challenge #31 for data on the previous deployment - http://www.honeynet.org/scans/scan31/.
This new WASC open proxy honeypot is setup basically in the same manner with a few advancements –
1. Centralized logging of the ModSecurity audit_log data with the logc program.
2. Use of the Apache 2.2 Mod_Rewrite HANDLER function to identify OS command injections and to spoof responses.
3. Implementation of the PHP Honeypot application to identify and log PHP-based attacks.
4. Inclusion of the Gotroot ModSecurity signatures to identify a larger number of attacks.
How do I get the WASC VMware host image up and running and configured correctly?
The first step that you must take is to contact the Project Leader to let him know that you would like to participate. In your email, please specify the following –
1. Sensor POC name
2. Source IP address that the logs will be coming from
3. Geographic location (Country, State, Locality)
4. Network Block Owner
The Project Leader will send back an email with the VMware 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 “logc” 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 /usr/local/apache/conf/logc.conf. Here are the contents –
LogStorageDir /usr/local/apache/logs/audit_log/data/
ConsoleURI http://209.209.13.209:8886/rpc/auditLogReceiver
SensorUsername
SensorPassword
MaxConnections 10
KeepAlive 150
KeepAliveTimeout 300
ErrorLog /tmp/logc.err
The final step is to start up the apache web server - /usr/local/apache/bin/apachectl start. You should then review the log files to ensure that they everything is working properly.
If you would like to be involved with the project, please contact
Ryan Barnett
