INLS 183 Project 4: Portsentry-1.0 and Logcheck-1.1.1

Introduction

Having concentrated so far on packages that would add functionality to the system and prevent data loss, I felt that security was the next area I should explore. This is probably one topic that is most unfamiliar to new users of Linux, unaware of the extent to which a system can be compromised. Vulnerabilities tend to be found in the various programs or daemons running on any typical Linux system, such at wu-ftpd or sendmail--especially those that interact with or listen to the network. However, in order for a foreign host to take advantage of such a hole, he must discover if it exists. One way of doing so is called a portscan, which is an automated test of a range of ports on a system. A port is like a standard flag in the TCP header on a packet that instructs the receiving system to give the data a daemon listening on that port. For instance web traffic uses port 80, ssh uses 23, etc. It’s not unusual for a single host to try and connect to a single port, but it is strange to see a host attempt connections to a range of ports (especially unbound ports) in quick succession. In most cases this is the result of a port scanner, automatically probing a system for ports that might be bound to vulnerable daemons.

Portsentry, by Psionic can combat this by binding to a range of ports (not already bound to by legitimate programs) and by then detecting hosts that try to make connections. As soon as a host is detected attempting such a connection, Portsentry immediately takes action to filter the packets from that host and deny any future connections via tcp_wrapper’s /etc/hosts.deny file. Portsentry’s actions are recorded by the syslog daemon and stored in /var/log/messages (according to /etc/syslog.conf). Therefore it is equally important to install a package like Logcheck to automatically cull new noteworthy log entries and send them via email to root.

I decided to install Logcheck after realizing that Portsentry simply added more entries to an already bloated /var/log/messages file. In retrospect I’m not exactly sure Portsentry is running as it was advertised. It appears to react when a host tries to connect to a single port once or twice, not a range of ports as I expected. Then because the system that’s trying to make a connection is probably misconfigured, it continues to send packets to that port once it’s blocked, and I get a message, via Logcheck every time a blocked host tries to make a connection—sometimes that mean four or five message every hour. Once Portsentry had blocked 74 hosts in a day, I was receiving emails approaching half a megabyte. Though I would like to investigate other options has far as preventive security is concerned, I will probably try something more like Tripwire next.

Portsentry Installation

I started by printing out the extensive install and configuration files (README.install and portsentry.conf) to read while I was configuring and installing. In order to make changes to the portsentry.conf file, one has to be familiar with the various modes in which Portsentry can operate. As I understand it, mode 1 involves binding to a predefined set of unbound ports and listening for connections. The two other modes, “Stealth Scan and Advanced Stealth Scan” involve using a “socket to monitor all incoming traffic” and monitoring all ports under a top limit, such 1023, for special types of stealth port scans. For simplicity, I chose the first mode, the configuration for which really only involves choosing that set of ports which Portsentry should listen to. The portsentry.conf file came with three predefined lists of ports, I choose the middle ground:

TCP_PORTS="1,11,15,79,111,119,143,540,635,1080,1524,2000,5742,6667,12345,12346,20034,31337,32771,32772,32773,32774,4042
1,49724,54320"
UDP_PORTS="1,7,9,69,161,162,513,635,640,641,700,32770,32771,32772,32773,32774,31337,54321"

I also had to choose a “KILL_ROUTE” which essentially tells the program what to do with packets received by a suspected portscanner. In all of the various options, the KILL_ROUTE is intended to filter packets from being received, while making it appear to the sender to him as if the system doesn’t exist--in other words it sends no reply. I choose the option that seemed most appropriate for my system:

# New ipchain support for Linux kernel version 2.102+
KILL_ROUTE="/sbin/ipchains -I input -s $TARGET$ -j DENY -l"

This utilizes ipchains, which provides packet filtering and IP firewalling to the Linux kernel, in this case version 2.102 and up. I took a peak in /boot and intuited that I had kernel 2.2.14-5.0, judging by the suffix being used on most of the files in that directory. That was it for configuration.

The next step in the README.install file suggested that I make some changes to the portsentry.ignore file, which lists hosts that Portsentry will ignore. Important hosts to include here are 127.0.0.1 (the localhost), and the IP of the local interface, in my case 152.2.38.210. Otherwise the instructions advised keeping this list short, to prevent missing important information even from hosts assumed to be ‘friendly.’

Last step, I typed:

make linux
make install (as root)

That completed the installation, placing the files in /usr/local/psionic/portsentry/. Like any other daemon, Portsentry needs to be started, so I issued the following commands:

/usr/local/psionic/portsentry/portsentry –tcp
/usr/local/psionic/portsentry/portsentry –udp

This starts Portsentry binding to and listening on all of the port specified in the conf file above (mode1). I almost immediately issued the command tail /var/log/messages to confirm that portsentry had indeed installed correctly. This is what I saw:

...
Oct 14 19:23:10 nchcap portsentry[25360]: adminalert: Going into listen mode on UDP port: 31337
Oct 14 19:23:10 nchcap portsentry[25360]: adminalert: Going into listen mode on UDP port: 54321
Oct 14 19:23:10 nchcap portsentry[25360]: adminalert: PortSentry is now active and listening.
Oct 14 19:24:32 nchcap portsentry[25360]: attackalert: Connect from host: squash.ils.unc.edu/152.2.81.51 to UDP port: 513
Oct 14 19:24:32 nchcap portsentry[25360]: attackalert: Host 152.2.81.51 has been blocked via wrappers with string: "ALL: 152.2.81.51"

The line with “PortSentry is now active and listening” was the key to me that everything was going off with out a hitch. What surprised me, was that only a minute after I turned Portsentry on, I had received my first attackalert from 152.2.81.51.

In fact that was only the beginning. In the course of a day I received multiple attack alerts from 74 IP address all over campus. Only one came from outside the 152.2 domain. Either handfuls of people were scanning my ports, or there is a lot of miscellaneous traffic out there. I presume it was the latter as I discovered that the majority were tripping 1 of 5 specific ports over and over again: UDP 513, UDP 161, UDP 162, UDP 69, and UDP 9. Rather than trying to keep track of the new entries in my /var/log/messages file, I decided to install another piece of software from www.psionic.com called Logcheck.

Logcheck Installation

After reading the documentation (README.logcheck and INSTALL.logcheck), I realized Logcheck is a very simple program, not unlike my homegrown backup utility. Log check basically consists of two pieces: logcheck.sh, the main program script that checks the logs and is run every hour or so via cron, and logtail, an executable program that creates a small file for each log that logcheck is checking, to keep track of the last line in the log that it read. In addition, there are a number of text files that contain the system-specific keywords that logcheck scans for (or ignores) in the log files. These lists have been designed for specific systems based the type of information that a sysadmin needs to know about. The README.install file outlines the process as follows:

The whole process follows the following structure:

logcheck.sh executes hourly ---->
logcheck.sh executes logtail on log files ---->
logtail parses off any text from the last time it was run --->
logcheck greps text for system attack messages --->
logcheck greps text for security violations --->
logcheck greps text for security violations to ignore --->
logcheck greps text for all messages to ignore. --->
any messages found are mailed to system admin.

Installation of Logcheck was also a breeze. First I checked my /etc/syslog.conf and made sure it was inline with the INSTALL document; it was. Next I made sure the configuration details in logcheck.sh agreed with my syslog.conf file; they did. Then to install, I typed:

make linux

At this point, logtail was copied to /usr/local/bin/logtail, and all the config files, as well as logcheck.sh were put in /usr/local/etc/. The last issue then was for me to put an entry in root’s crontab file that runs logcheck.sh every hour:

# Runs Psionic Software's logcheck
00 * * * * /bin/sh /usr/local/etc/logcheck.sh

With this done, I went to do other things to wait for my first email.

Portsentry and Logcheck in Action

It was massive when it came, particularly because I had installed Portsentry the day before and it had accumulated a lot of messages in my messages file, 174K worth! Subsequent hourly emails were in the 30-50K range, but much of the details were log entries telling me that a blocked IP was trying to connect again, to the same port. So I didn’t really get the idea that my system was any more secure. In fact the only connection that may have been genuine was the one from outside the UNC domain (152.2):

Oct 15 06:02:49 nchcap portsentry[25358]: attackalert: Connect from host: nas-110-15.la.navipath.net/216.67.110.15 to TCP port: 12345
Oct 15 06:02:49 nchcap portsentry[25358]: attackalert: Host 216.67.110.15 has been blocked via wrappers with string: "ALL: 216.67.110.15"
Oct 15 06:02:49 nchcap portsentry[25358]: attackalert: Host 216.67.110.15 has been blocked via dropped route using command: "/sbin/route add -host 216.67.110.15 reject"

This was the only host that tried to connect to a TCP port, and it tried a random port that no one else was using. The other messages only seemed to prove that there’s a lot of garbage traffic sent out on the UNC network. After I started to receive emails in the 300-500K range, I decided to eliminate the few ports from portsentry.conf that were triggering most of the alerts, and I flushed the ipchains table that was refusing the packets from all of these campus machines. Since then, the emails have been much more manageable, consisting only of important system messages. With a bit of tweaking, I should be able to limit the logging and the logchecking to the bare minimum. I will probably feel more secure when I have Tripwire installed---in the event that someone does break in.

INLS 183 Project 4: Portsentry-1.0 and Logcheck-1.1.1 script file