[Owasp_wasc_distributed_web_honeypots_project] Deploying a Sensor - Quick Steps

Ryan Barnett ryan.barnett at owasp.org
Wed Apr 1 13:30:46 UTC 2015

Hello everyone,
I received a number of requests to deploy Sensors which is GREAT!  Here is
some quick reference information to get you started -

Download the Sensor VM ZIP -
Download the VMware Sensor ZIP (~441 MB) from here -

Logging In -
Once you start it up, you can login with these credentials -
Username ­ hpadmin
Password ­ hpadmin
You can use ³sudo² to execute root-level activities.

Networking -
The honeypot is configured to use DHCP in ³bridged mode² networking.  If you
have issues with the NIC coming up, you should be able to use ifconfig to
see which ³eth#² interface came up and then add an entry for it in
/etc/network/interfaces file.

Honeypot Configs -
The majority of config files are under this directory -
/opt/wasc-honeypot/etc/.  The Apache configs are setup so the honeypot works
as an ³open proxy².  If you do not want to run the Sensor in this way (due
to legal concerns), you can simply set ³ProxyRequests Off² in the
/opt/wasc-honeypot/etc/honeypot_begin.conf file.  In this config, the
honeypot Sensor will simply be a web server listening on the defined ports
and not an open proxy.  The honeypots are configured to sync/pull rules from
our OWASP CRS repository on GitHub
each day and reload configs.  This allows us to be able to update honeypot
rules going forward to address false positives/false negatives.
Additionally ­ with ModSecurity v2.9 installed, we are also using the
SecRemoteRules directive
les).  This also allows us to quickly deploy new rules for emerging
vulns/attacks such as ENV BASH Bug or ShellShock vs. solely using ³generic
attack detection² from the OWASP CRS.

New Capabilities -
Additional cool updates we have are some advanced functionality to be able
to capture more attack/threat data from these attacks.  One method is that
we can capture file upload attempts under /data/httpd/upload/ directory.  If
we see Remote File Inclusion attacks, we will actually fire off a cURL
script to try and go out and retrieve the file and save it locally under
/data/httpd/rfi/ directory.  We also have some new ³attack response
spoofing² capabilities.  This includes proxying to RFI files to spoof a
successful download, also if we see any SQLi attacks, we proxy/spoof a
Microsoft SQL error page and if we see ³phpinfo()² we will spoof a response
page as well.  The goals here are to try and get the attackers to move from
the initial Level 1 probes to Level 2 exploit attempts.

Log Files -
The Apache access/error log files are held under - /data/httpd/.

Centralized Logging -
The honeypot is pre-configured to use the ModSecurity mlogc program to
forward events off to our central logging host that is running the
AuditConsole app - https://console.modsecurity.org/Dashboard.  Let me know
if you would like to have Console access and I will create an account for
you and send you credentials.  Mlogc configs are under
/opt/wasc-honeypot/etc/mlogc.conf file and the logs are under /data/mlogc/.

Send a note out to the mail-list if you have any issues.


Ryan Barnett
OWASP/WASC Distributed Web Honeypots Project Lead

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp_wasc_distributed_web_honeypots_project/attachments/20150401/fc29a6ba/attachment.html>

More information about the Owasp_wasc_distributed_web_honeypots_project mailing list