| Setup Throughout the months my honeypot setup changed a little. The current hardware configuration consists of:
At first the system ran RedHat 6.2. Later on I went on using RedHat 7.1, which is a bit newer, but not too new. To be able to see what crackers do with my system I hacked some programs up a bit:
I combined 'script' and 'bash' to a logging version of bash. Every invocation of '/bin/bash' (and since 'sh' is symbolically linked to 'bash', '/bin/sh' too) is actually an invocation of 'script'. The screen-output is logged to a file hidden somewhere on the local machine, every time bash is run to a different file. The first version then started a real bash from '/sbin/bash', but that might arouse suspicion, so I changed it to work transparantly, without extra binaries. One problem with my logging bash though: there are now three processes for every invocation of bash. This would -really- be suspicious, since it would show immediately with 'ps' or alike. To get around this problem I implemented a simple filter which would filter away the two other bash-processes. This could be used to filter other things as well, for instance my connections with the system to retrieve logs.
I configured Apache so that I can connect from a certain remote machine to it to retrieve any file on the system readable by the user httpd runs under. This allows me to easily fetch the logfiles my logging bash creates. My logging bash filters away the IP-address of that system in it's output, so that the cracker wouldn't notice even if he looked at netstat output. The virtual host I configured in Apache logs to /dev/null, so there's no accesslog where my log-retrievals show up.
I once hacked up libprocfs to return a arbitrary uptime, for instance 235 days more than the system actually was up. This would perhaps get a cracker to see my system as very stable and therefor suitable for an IRC-bot, or whatever he wanted to run on a stable box. However, there are a few implications of this hack. First, the filedates and system logs should reflect this high uptime. Secondly, a system with such a high uptime yet running a highly vulnerable version of wu-ftpd seems unlikely. Ofcourse, the admin could've activated the ftpd a 230 days after boot, but then the logs should also show that. I've never used this hacked up libprocfs while actively running a honeypot for these reasons.
I hacked the OpenSSH ssh-client to log passwords to a file. This allows me to track crackers logging in to other systems. It gives insight in how crackers go about with their backdoor passwords as well as give me some very clear evidence I could present to system administrators who's systems are cracked.
The network setup is a bit evil and insecure, but due to my lack of switches and systems I can't do much better than this. Anyway, this is how I've configured things. My ISP assigned me three IP-addresses. One of them I used for myself, one of the two others I used for the honeypot. Sadly my ISP decided or was forced to withdraw the second and third IP-addresses they assigned to their customers a few months ago, although I can still use them.. Anyway, I configured the honeypot's IP-address to my router/gateway machine (running FreeBSD). Since the honeypot was connected to the switch on my LAN (dangerous, I know) my FreeBSD machine should forward the packets it received on it's external interface to it's internal interface. With some ifconfig and ipfw voodoo this is doable:
First I configure the honeypot's IP-address to my external interface and the honeypot's gateway on the internal interface. This allows my ISP to send my FreeBSD system the packets destined for my honeypot and allows the honeypot to set it's default route to my FreeBSD system. To get the traffic from my honeypot to my ISP the 'fwd'-rule is needed in ipfw. To get the traffic destined for my honeypot from the FreeBSD machine over to the LAN, the static arp and 'fwd'-rule in ipfw are needed. Routing the traffic through my FreeBSD machine has some advantages too. Because of this I can run snort to get warnings when a cracker is at work. I can also shape the honeypot's traffic to avoid participation in DDoS-attacks and to mitigate scans started from the honeypot.
|