Infosanity's Blog

When I first started running Kippo almost a year ago I had no difficulty getting motivated to log into the honeypot, check for new connections and generally get a feel for what my victims visitors have been up to. As time went by, sessions started to follow familiar patterns and some days would get no hits. Slowly I’d check the logs less frequently, and when I did I’d get an ever increasing backlog to review, decreasing my motivation further.

Recently I got annoyed with myself, my system was ticking along in the background but I was gaining no benefit from it. So in a moment of madness I dusted off my bash and built a quick script to provide a daily review of activity on my system. Essentially this does two things, lists session interaction and files downloaded within the last 24hours.

I’ve had the routine running daily for around a week; for days there was minmal activity on my system, either no logins at all, or logins with immediate disconnects. Today was different, and marked the first success of the script. Delivered to my morning inbox, along with the rest of my regular quick tasks and RSS feed as an interesting session. Malicious user connects, downloads a scanner (archive contents looks like gosh), an irc bot (looks like EnergyMech derivative); and when attempts to run toolkit fail, downloads and runs three (yes, three, paranoia is strong with this one) log cleaners.

Example (snipped) output:

:~$ /opt/kippo-svn/kippo-sessions.sh
***Sessions***
---START:/opt/kippo-svn/log/tty/20110519-220029-5503.log---
www-dev:~# w
 22:00:38 up 14 days,  3:53,  1 user,  load average: 0.08, 0.02, 0.01
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
root     pts/0    77.210.18.212     22:00    0.00s  0.00s  0.00s w
<SNIP>
***DOWNLOADS***
/opt/kippo-svn/dl/20110519220445_http___eduteam_home_ro_mech_gz: gzip compressed data, from Unix, last modified: Sun Oct  4 17:46:52 2009
<SNIP>

The script can be downloaded here, as usual it’s released under the Beerware License

–Andrew Waite

VMWare ESXi is perfect for a self contained lab, but as I’m used to having full access to a ‘real’ network there are a few things I miss not having control over for testing and other things. The biggest of these is a spanf port (or mirror port depending on your hardware). If you’re not familiar, the basic premise is to configure one (or more ports) to reproduce any traffic flowing through any port(s). This provides packet level access for debugging network problems, passing to an I[D/P]S, etc.

ESXi doesn’t provide this functionality, but does allow you to set a vSwitch to be ‘promiscuous’. Unfortunately this isn’t as controllable as a span/mirror port as (from the quick tests I’ve run) essentially turns the vSwitch into a vHub. Not a problem in my lab environment but you probably want to give it some serious thought before enabling in a production environment; do you really want every server on the network to be able to see all traffic on the (virtual) wire?

To make the change in ESXi you need host -> Configuration -> Networking and set the properties as shown below:

vSwitch properties

Once this change is made, any guests connected to the vSwitch can all see any of the network traffic on that switch.

For testing you can build a quick lab scenario with 3 live boot BackTrack systems. Each machine has a different role; server, client and ‘sniffer’. The sniffing machine is now able to view direct communication between the other two systems. Using wireshark’s Follow TCP stream functionality shows the conversation:

sniffed TCP stream

–Andrew Waite

Towards the end of last year I spent a few hours trialling SSH tunnels, I knew how the process worked but hadn’t had much cause to use it in anger; so my lab got some use instead, and a post was written covering the basics; SSH port forwarding 101.

Since I now know how to quickly and successfully implement a tunnel, it turns out that I previously had plenty of cause to use tunnels in the past, I just didn’t know SSH tunnels were the right tool for the job. A couple of recent conversations has made me realise others don’t always know the flexibility of tunnels either so I wanted to try and describe a common scenario to highlight the usefulness of tunnels.

Scenario:

Above is a fairly common setup. You’ve got an internal resource (for example an intranet wiki for documentation), this is in turn protected by a firewall that only allows access from trusted location. Under normal circumstances all staff can access the resource without problems, and any malicious sources (human or automated) can’t access the service.

This works well, until someone needs access and they aren’t at one of the trusted locations (we’re assuming this is an unusual problem and remote access solutions aren’t in place). In a lot of environments SSH is a ‘trusted’ system management solution and is world accessible (and hopefully secured well enough to keep the barbarians from the door, but that’s for different posts).

Solution?:

SSH tunnels (but you guessed that). Tunnel the server’s HTTP (or whatever) service back to your local system, and then connect locally. Using the syntax I discussed previously, from a ‘nix shell you can use this command:

ssh -L 8000:127.0.0.1:80 ssh-server.domain.com

This makes an SSH connection to the server (ssh-server.domain.com), tunnelling the local HTTP service running on port 80 (127.0.0.1:80) and binds it to your machines TCP 8000 port. Now you can connect to the service by typing 127.0.0.1:8000 into a browser, thus traversing the firewall source IP restrictions.

If you’re living in a Windows world, then the PuTTY equivalent configuration will be:

Next time you’re sat in the coffee shop on a Sunday morning, and the boss rings with an ‘emergency’; are you sure that you can’t access the resources you need from where you are? If you can, that coffee (and extra slice of cake) just became expense-able

–Andrew Waite