[ILUG] Port Sentry vs Snort

[Smelly Pooh]

I apologise for the grammatical ineptitude of my previous postings to the port
scanning thread, I was in a rush.  I'll summarise my opinion in this post

== Port Sentry ==
A port scan detector that can be configured to bind to ports you want
monitored, reporting scans made to these ports and optionally running a command
to deal with the scanning host (usually in the form of routing that host to a
blackhole or adding a firewall rule dealing with said host)

Linux Only features:
Port Sentry can capture packets on Linux making it capable of detecting
"stealth" scans that the default port binding method will never see.  It also
makes it unnecessary to bind to the ports you wish to monitor

Pros:
Stealth scan detection on Linux

Cons:
A port scan detector that binds to ports is a terrible idea.  It advertises
services (usually those that are known to be hackable, which is why Port
Sentry binds them in the first place) that aren't there, making your server
seem like a hackers goldmine.  This forces you to use Port Sentry's counter
measures (routing the port scanner to a blackhole or bringing up a firewall
rule to blck the attacker)

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:
Port Sentry strikes me as a piece of software written by people who have very
little low level network programming experience (packet capturing using an
unportable and inefficient interface) and even less network security
experience (advertising commonly exploited ports that aren't there thus
enticing hackers to try to hack you, dynamically blocking IPs, unimpressive
performance against stealth scans).  This is a poor piece of software and I
can't help but think that its only reasons for success are because of the
placebo that it proactively responds to scans and the fact that it was written
by a security company.  It may be passable for the home user but you'd be a
fool to run it on any large commercial network

== 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 aswell.

Pros:
Snort is portable across multiple platforms using the libpcap library

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:
Snort is a fine piece of software, there is certainly no comparison with Port
Sentry, it does so much more, and where they do the same thing, Snort does it
much better.  Without a bit of configuring (especially WRT ignoring DNS server
traffic) you might get more information than you want, but the configuration
files are organised in such a way that you can comment out an include line to
ignore a certain class of exploits



Port scanning is way too common on the internet these days to get your nickers
in a rut over.  People might be interested to see this kind of thing on a home
machine, but if you run a popular server on the internet and you checked back
against every port scan launched against you, you will not get anything done,
and for no good reason considering most port scans are harmless.  Also note
that port scan detection and NIDS in general are no replacement for
firewalling, they are complementary.  A firewall should by default deny all
traffic except those that are allowed explicitly (sometimes that might include
allowing all outgoing connections).  An NIDS should be run on a machine that
can see all the traffic that gets past the firewall, preferably not on the
firewall machine itself because NIDS can be quite performance intensive.  This
way your NIDS will only report traffic that might possibly be a threat because
it made it past your firewall.

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