Thug is a low-interaction client honeypot used for analyzing web-based, client-side attacks. As client-side attacks become more obfuscated and difficult to analyze, Thug can be used to emulate the behavior of a web browser (16 different User-Agents at time of writing) to detect malicious web pages while creating detailed logs and saving payloads.
While looking into Thug I found that there wasn't an existing guide for installing it on FreeBSD. The Thug build documentation is good, but I found it makes a number of assumptions on prerequisites already being installed. After some trial and error I've documented the entire process I used to get Thug running on a fresh FreeBSD 9.1 image.
I'm using a custom NanoBSD image with PacketFilter (PF) as my home firewall/gateway and indexing the PF activity into Splunk. Being able to report on and graph the firewall data is valuable Intelligence when planning your next HoneyPot project; among other things.
The write-up that follows isn't specific to NanoBSD and should work with any PF installation (FreeBSD, OpenBSD, pfSense, etc). I should also mention that I originally implemented this with real-time logging by running
tcpdumpon pflog0 and piping the output to
logger. For the most part it worked, but Splunk would have random events that were missing the first line of the tcpdump output. Instead of burning cycles trying to determine where the random data was being dropped, I settled on a 5-minute "push" interval of the /var/pflog file to Splunk. I haven't encountered the issue since.
The PF-to-Syslog portion of my implementation is based on the OpenBSD documentation for PF with a couple minor tweaks. Whereas the Splunk portion is completely custom and involved many nights of RegExp wrestling and LOTS of test packets with Nping. As a quick side-note: if you're looking for a utility for writing and testing RegExps on OS X check out RegExRX. Well worth the $4.99.
I ran into an issue while customizing my new MacBook Pro where after installing the first Perl module the CPAN executable simply vanished (or at least appeared to!).
After some digging I discovered that the file permissions for a number of CPAN/Perl scripts had been modified at some point during the module installation and the 'execute' flag removed.
Below are a few of the affected executables in the
/usr/bin directory, notice how the 'execute' bit isn't set:
-rw-rw-rw- 35 root wheel 807 Jul 4 11:52 cpan -rw-rw-rw- 35 root wheel 807 Jul 4 11:52 cpan2dist -rw-rw-rw- 35 root wheel 807 Jul 4 11:52 cpanp -rw-rw-rw- 35 root wheel 807 Jul 4 11:52 cpanp-run-perl
I run a number of Sguil deployments, of which some are on hardware that is extremely under-utilized, so I set out to determine what it would take to run multiple Sguil deployments on the same server.
The required configuration changes were relatively simple for most of the processes (Sguil agents, Snort, DaemonLogger, PADS, Barnyard) until I got to SANCP. The FreeBSD package at the time of this writing (v1.6.1_4) doesn't utilize a PID file, nor does it have a configuration option for defining one. This makes it very difficult to run multiple instances since without a PID file the rc.subsystem defaults to checking for the process name in the process table; thus leading to
sancp already running? errors.
On a recently built FreeBSD 8.1 amd64 server I'm experiencing segmentation faults when I ctrl-c out of
tcpdump on a busy network interface.