[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 -
http://projects.webappsec.org/w/file/fetch/94619066/Owasp-honeypot-v1.zip?fo
rce_download=1

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
(https://github.com/SpiderLabs/owasp-modsecurity-crs/tree/owasp-honeypots)
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
(https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#SecRemoteRu
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.

Thanks.

--
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