Network Intrusion Detection: detecting and dealing with portscanners

Copyright © 1999 Jeremy McMillan

The subject of security and intrusion detection is usually tied to the concept of a wily cracker coming in over the Internet to subvert a helplessly connected host computer and do unimaginable damage. My personal and professional opinion, as a network technician, is that your time is better spent defending against people who legitimately have some access to the concerned systems. That practice is really more of an art, and it is way beyond the scope of any one article. It is wise nevertheless to take a defensive posture against the "script-kiddiez" downloading and running poorly understood "sploits" from rootshell.com and elsewhere.

The wannabe-hacker/crackers read postings from someone who is actually smart enough to debug a problem with a service. Maybe the debugger wrote a script or program to demonstrate or "sploit" (exploit) the bug in question. This is not bad in itself, since it is easier for the original author of a program to correct a bug than a mere user. User debugging is a long-standing part of the free software culture. The people we're worried about are the ones who get kicks by subverting other people's computers in the time it takes the sysadmin to disable/patch/upgrade the buggy service.

First, they have to find victims. Also, they are looking for network services which are known on hosts that are unknown. The method they use is called portscanning. Portscanning simply is multiple attempts to connect to several IP addresses. If your server responds, the nasty cracker logs the successful attempt to contact someone who is suspected to be vulnerable and nasty things *may* follow.

I use ipfw, the FreeBSD kernel based firewall and natd with a discard pseudo-interface. For my last (default) firewall rule, rather than dropping the packets silently, I can forward them with natd to my discard interface. Packet captures can be monitored or dumped from there. In addition to that rule, I like to add another preceding rule.

This rule is the trick that catches most portscanners. I have one address on my subnet which will never have a legitimate host on it. You should preferably use an address which has a very low port number on common sized subnets. Only "ignorant" peers will send packets directly to it. I set my discard interface to this address and log any packet destined directly to it. If I want to, I can set the log limit to 1 and configure syslog to pipe the log entry to an escalator program: email, pager, fax, printer, or a PERL script to issue a new ipfw rule that blocks the offending source address. I like to save the results of a traceroute to the offending source address.

This works specifically because the attacker does not know your IP address distribution. It has very limited usefulness, but it can provide early warning that your system has become "interesting" to malicious or negligent outsiders as well as identify where they are coming from. Rather than sounding the alarm at the moment your system has been breached, this will also hopefully provide you with a place to start looking once you discover a problem. This is a good idea since problems resulting from an intrusion are not always obvious. A rash of portscans followed by a daemon mysteriously crashing is *certainly* worth investigation. As always, YMMV.

Jeremy McMillan, aphor@ripco.com