I was recently contracted to help another consultant sniff a customer's network for suspicious activity. The situation was that the customer had been put on blacklists because some internal machine had apparently been compromised and was sending out spam.
Obviously the first task was to find and clean up any infected machines. The consultant contracted that out to someone else who updated virus software and ran scans. Unfortunately, that person didn't provide details of his work - he just reported that he had found and fixed "some problems". This didn't leave anyone feeling confident that the problem had actually been dealt with.
I pointed out that, if possible, all machines other than the internal mailserver should be blocked from sending email (other than to the internal mailserver, of course). Ideally, they should be locked down to only whatever outgoing ports are absolutely necessary, but blocking 25 and 465 is a good start. That was done, but my contact still wanted to know how to sniff what is actually happening on the network.
I had him buy a DualComm port mirroring switch and arranged to meet him at the customer site. The DualComm is an inexpensive 5 port, USB powered switch that, by default, mirrors port 1 to port 5. It's small enough to keep in your laptop bag, cheap enough that you can leave it at a customer site and the USB power means one less outlet to hunt for. The default port mirroring makes this ideal for lan sniffing.
Because the consultant wanted to use Windows, I brought a Windows laptop with Windump installed. Windump is just tcpdump so that makes it easy for me and it also means that he can search for tcpdump tutorials and learn more about its usage.
Both Linux and MacOSX users have tcpdump installed by default. Personally, I'd much rather carry a Mac or Linux laptop for this kind of work as there are many other tools that Windows doesn't bother to include. But this consultant was more comfortable with Windows, so that's what we did.
On site, I connected my laptop to port 5 of his DualComm, took the patch cord that went to the ISP's router and put it in port 2, and then ran port 1 back to the customer's switch where I had unplugged the router cable. I started up a CMD window and showed him that we could do things like
windump "tcp port 25 or tcp port 465"
That showed traffic to and from the internal Kerio mailserver as we'd expect. I then stopped the mailserver and all Windump output ceased. We watched for a few minutes, saw nothing, and turned the mailserver back on. I showed him that the Kerio admin "Active Connections" under Status should match the IP's we were seeing in Windump. This made him feel more confident that the problem was indeed resolved. I did suggest that he might want to log some longer runs just to be certain, but as I confirmed that client machines were blocked, I don't expect to see this problem again. The sloppiness of the contractor who did the virus cleanup bothers me a bit, but otherwise this is under control.
Got something to add? Send me email.
More Articles by Anthony Lawrence © 2012-07-13 Anthony Lawrence
Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do. (Donald Knuth)