planetILUG

Join the
ILUG
on FaceBook

Join the
ILUG
on LinkedIn

Join the
ILUG SETI
Group

By Ka Chun Leung

Port Sentry

Linux Only features:

Pros:

Cons:

On a non-linux machine Port Sentry will not see port scans directed at ports with already running services (the reason being that when a service is already bound to that port, Port Sentry can't also bind to it). This means that if an attacker scans for a specific exploit instead of a spectrum wide scan Port Sentry will know nothing about it. This kind of scanning is very common and usually more dangerous. An attacker might have the Bind and Wu-ftpd root exploits, and have a script connecting only to these 2 ports across a subnet and try to exploit them. On any machine that runs vulnerable versions of one or both of these services you will be hacked, and Port Sentry will continue to tell you that everything is fine.

Port Sentry needs to be run on every host that you wish to check for port scans, this adds quite a bit of system administration overhead on a large network.

It is stupid to use such counter measures as to dynamically block a host that appears to be port scanning. The source IP of a scan can be faked to fool Port Sentry into blocking an arbitrary host (for example localhost or the routing machine for the Port Sentry machine, effectively DOSsing your machine), a large number of faked source IPs can destroy your machines static routing table or fill your firewall rule table to the point that it can bearly run (There is a similar note in the nmap man page under the -D decoy section, I can't help but think that fyodor is sneering at Port Sentry in particular).

Even if nobody was intentionally DOSsing your machine, dynamically blocking IPs isn't as some might think. If a server is up for any length of time, the amount of port scans it receives will be pretty high and eventually somebody will have to go in and clear the blackhole routes and firewall rules. If you are an ISP you will also get a lot of apparent port scans from your users, they may not be using a port scanner, just merely connecting to an arbitrary port to see if you provide a certain service. Port Sentry will cut your user off, thankfully said user can dialup and get allocated another IP, but the blocked IP will remain blocked for the next user to get that allocation.

Port Sentry uses Linux's AF_SOCKET interface for packet capturing. This means that on a Linux box port sentry can detect port scans without necessarily binding to ports, and also detect certain kinds of stealth scans. I know I'm talking to Linux users, but portability is important, and every major packet capturing program is portable across different unixes, usually through using libpcap. But Linux users don't rejoice yet, AF_SOCKET was the standard interface for 2.2 and was much ballyhooed for its extreme inefficiency. Linux 2.4 supports an efficient BPF style packet capture, this is a different API and unless Port Sentry explicitly supports it (I doubt it, but I don't know for sure) you will still be using the old interface and see no performance improvement. Running Port Sentry with packet capturing on a high load network will result in dropped packets.

I've tested Port Sentry with packet capturing enabled and it seems that nmap with certain stealth scan options still easily elude it.

Conclusion:

Snort
Snort falls into the category of Network Intrusion Detection Systems (NIDS). It is the best open source program of this type that I am aware of. Port scan detection is a subset of NIDS so one can rightfully assume that snort handles this as well.

Pros:

Because it is entirely a packet capture NIDS, it doesn't suffer from Port Sentry's port binding and is able to see a lot more of what's going on underneath.

Snort can act as a tcpdump like packet analyser, a packet logger (for gathering statistical data around your network, or as an NIDS).

Snort can output in tcpdump format letting you analyse snort logs with many of the already existing programs that interpret tcpdumps.

Snort can be configured to detect specific exploits going through your network which a program like Port Sentry can not. It is legal to port scan a machine in most countries, all a port scan detector is good for is to act as an early warning system (because port scans often precede exploit attempts). Software like snort can also analyse packets looking for specific exploits, and logging the session. This is good from an evidence point of view, or simply detecting what specific exploits are being launched against you.

The exploits that snort looks out for are configurable using rules, the default rules detect hundreds of exploits from aforementioned Bind/Wu-FTPD (right down to the specific exploit type by analysing the packet) to DOS attacks to a variety of well known web exploits to pings of death to netbios exploits. Basically if there is a network based exploit with a discernable pattern it should be trivial to to create a rule to detect it. www.snort.org and www.whitehats.com carry up to date rules (and user submitted rules).

Snort is also extensible using plugins, the base package already contains a number of useful plugins.

Snort does passive port scan detection, it won't advertise services that do not exist or in any capacity give away the fact that you are running an IDS. Snort's port scanner plugin is also much more adept than Port Sentry at detecting various Stealth scans. You can also configure the plugin to report scans only if they scan multiple ports at a particular rate, compared to the classic Port Sentry way of getting triggered when somebody connects to a bound port.

There is an experimental plugin for snort (called spade) which detects anomalous network traffic. It's quite configurable and basically lets you take a more statistical approach to NIDS, rating unusual traffic by the frequency with which they occur. Another plugin is being developed that will use spade to pinpoint the most likely attacker in an nmap decoy scan

Snort can be used to detect attacks across an entire network, not just on a single machine.

Conclusion:

Summary

Although I wouldn't consider it worthwhile, you can also use the NIDS to detect port scans outside the firewall, either by having the NIDS machine outside the firewall (the extra traffic will add a burden on the NIDS machine) or on the firewall machine itself, by setting the firewall to filter on traffic going out it's internal interface instead of coming in its external interface (in the latter case, a packet capture on the same machine still won't see the packet, again this is a bad idea from a performance point of view). Of course you can always use the firewall itself to detect port scans by logging connections to blocked ports, it'll do it better than Port Sentry, more efficiently than Port Sentry or Snort, but not as cleverly as Snort.

USERS COMMENTS

Posted By Gooboo Gobbins 21:39, 27 May 2005

Most of us aren't interested in using Linux in a large network setting, so I believe that you've made an erroneous assumption. A lot of us use Linux (and other free OSes) at home simply for the cost savings. Many people might want to relegate that application to "hobbyist", but what is "hobbyist" about it if the systems are performing exactly the same functions they would in the working environment? Regarding PortSentry, I think the biggest selling point is something that Snort currently lacks; easy implementation. I started working with Snort a few months back at work in order to track down a worm. Snort was cumbersome, confusing and downright unfriendly. It also doesn't easily do anything other than warn you of a problem. It can be configured to run other applications, but that's a little overkill since most of us just want to block the traffic and forget about it. PortSentry excels in this way. I am using it at home to protect my machines, and it's done a wonderful job. It didn't take long to configure and it only runs on the Linux based firewall that my actual servers sit behind. It's been running this way since 2001 and the only thing I've had to do is occasionally recompile some components of my firewall. Would I use it at work? It depends on the application. I think I would stick with a Cisco PIX for firewall services, but between the multiple sites that are linked via point-to-point T1s, I would certainly consider it so that if a site does get infected, it gets blocked. Damn the users as network security is more important. I don't care if they have to undergo a little inconvenience if I know that I have some breathing room to resolve the problem. I don't want simple warning that mostly turn out to be false positives. I want something that looks for known suspect traffic and DOES SOMETHING. Again, this is where PortSentry excels. Regarding portability, that's simply a judgement call. It's not important overall if you are a Linux user where PortSentry is concerned. But I'd say that it's best to leave that decision up to the individual. Sometimes it matters and sometimes it doesn't.