In the olden days, the Internet was without a doubt a nicer place. Akin to leaving your front door unlocked when you went shopping, you could leave your email accessible with password and no-one would even bat an eyelid. And although you might have only received 20 email messages a week, the bonus was that they’d all be for you and from people you knew.

Sadly, the Internet is no longer like that. The days of the alleged unpatched Windows Server being infected with malware within 10 seconds of being plugged into the Internet paints a picture of where we are today with our precious but flawed Internet.

Neighborhood Watch

In these darker times, when you set a freshly baked server live on the Internet, it’s critical to know how it’s fairing. Knowing how much bandwidth your server is using and how much email it sends in a day is all well and good, but are you aware of how many times someone scanned which TCP or UDP ports you left open? Can you really make sure that all 65,535 UDP and 65,535 TCP ports are safe – every day and night, 365 days a year?

Thankfully straight out of the box, or with a little customization, can manage all that easily with the long-standing security stalwart PortSentry  . In this article, I’ll help you monitor all your ports and help you avoid banning your own user and admin IPs in the process.

Incidentally, PortSentry heralds from those innocent and forgotten times and is well over a decade old; amazingly, it still does its job very well. When it comes to PortSentry, simplicity is the key to its efficacy.

Not All Implementations Are the Same

PortSentry reacts a little differently on various operating systems, I’ve used it on Solaris and Debian, Ubuntu, and Gentoo, but just to be clear from the outset, I’ll focus on the Debian/Ubuntu flavors.

One of the main operating systems differences is how it “opened” ports. By design, PortSentry listens on any unused ports that aren’t in use by your legitimate daemons at boot/execution time. On some Unix-like systems, rather than just responding to probes on those open ports, PortSentry actually opens those unused ports and almost becomes a Honeypot – which has its pros and cons.

PortSentry has a handful of config files, most of which live inside /etc/portsentry on Debian-based distributions. One, however, resides in /etc/default/portsentry , which contains the settings in which mode PortSentry should run. Here, I’m using the advanced modes for both TCP and UDP:

TCP_MODE="atcp"
UDP_MODE="audp"

Figure 1 sheds a little more light on the available modes that PortSentry can offer.

Figure 1: The various modes of PortSentry.

In standard, basic port-bound modes, it runs in the background and reports any violations, whereas in Stealth modes, PortSentry will use a raw socket to monitor all incoming packets, and if a monitored port is probed, it will block the host. Apparently this method will detect connect() scans, SYN/half-open scans, and FIN scans.

The most sensitive modes are those used by Advanced Stealth scan detection. You can explicitly ask PortSentry to ignore certain ports (which can be key when running a particularly reactionary configuration) to protect legitimate traffic. By default, PortSentry pays most attention to the first 1024 ports (otherwise known as privileged ports) because that’s where non-ephemeral connections usually originate from daemons.

As part of the advanced modes for both TCP and UDP, PortSentry employs what’s referred to as Advanced Logic mode, wherein it can follow traffic from already established connections and ignore the re-connect back to a separate port, avoiding a false positive being triggered. An example might be an FTP client that opens up ports outside of the privileged port range (anything from port 1024 to 65535), which requires the FTP server to connect back to you, opening another port. PortSentry is clever enough to consider this safe traffic, and this mechanism could even be referred to as using a rudimentary stateful inspection engine, which for software of its age is a little surprising.