Skip to content

The Audit Experiment

doksu edited this page Mar 3, 2016 · 17 revisions

#The Audit Experiment is currently offline until further notice

#About The Audit Experiment is a honeypot designed to produce interesting audit events for the development of the Linux Auditd app for Splunk (https://splunkbase.splunk.com/app/2642/). The data is ingested into Splunk, accessible to the world and has a guest account (username: 'guest' password: 'auditd') you can use to login and try the Linux Auditd app: https://auditd.mooo.com:8000

#Why? By their very nature, audit logs generally can't be shared or used for development activities. Without a project such as this we wouldn't have sufficient and varied enough data to develop this app to its full potential. We are simply collecting the noise of bad actor activity on the Internet.

#I'm doing academic research, can I use the data? Be my guest. You can download the logs wholesale by exporting them via the Splunk web interface. I'm also happy to provide details of the configuration, such that you can replicate it for more rigorously controlled experiments.

#How is the honeypot configured? It's an Amazon EC2 Micro Instance running RHEL 7. SELinux TE, RBACs and MCS have been used to harden the machine and provide interesting audit events. Most of the filesystem is audited for reads/writes/attribute changes using auditctl - this too provides a wealth of interesting events. Splunk and the Linux auditd app have been installed, then confined with SELinux (https://github.com/doksu/selinux_policy_for_splunk). SSH is open to the world. Root login via SSH has been disabled and the login banner provides guest credentials to give anyone the ability to login and have a poke around without the need to brute-force their way in. For the benefit of the community, Splunk is also accessible to the world and has a guest account (username: 'guest' password: 'auditd') you can use to login and try the Linux Auditd app: https://auditd.mooo.com:8000

#What happens if the honeypot is compromised? Great, so long as we can collect the audit logs (they're the only thing of value on the machine), the experiment can be considered a success; we will learn from the breach, then rebuild the machine with the lessons learnt. However, the likelihood of complete compromise is very low given the mitigations in place. Even on its own, confining users with SELinux RBACs (the means by which Domain/Type Enforcement is applied to users) significantly mitigates the damage that can be caused.

Clone this wiki locally