Guarding Your Computer with PortSentry | Red Hat Fedora Linux 3 Bible

While LogSentry gathers and sorts log messages that may represent attempts to break into your computer system, the PortSentry takes a more active approach to protecting your system from network intrusions. PortSentry can be installed and configured on a Fedora system to monitor selected TCP and UDP ports, and can then react to attempts to access these ports (presumably by people trying to break in) in ways that you choose.

PortSentry acts as a nice complement to LogSentry by actively looking for intrusion behavior on network ports. When PortSentry perceives an attack, it reacts to the attack (in ways that you choose) and produces log messages about the activity that can be forwarded to the system administrator by LogSentry.

PortSentry operates in several different modes. Each of these modes can be applied to monitoring of TCP and UDP ports. The PortSentry modes include:

Basic — This is the mode PortSentry uses by default. Selected UDP and TCP ports in this mode are bound by PortSentry, giving the monitored ports the appearance of offering a service to the network.
Stealth — In this mode, PortSentry listens to the ports at the socket level instead of binding the ports. This mode can detect a variety of scan techniques (strobe-style, SYN, FIN, NULL, XMAS and UDP scans), but because it is more sensitive than basic mode, it is likely to produce more false alarms.

Advanced Stealth — This mode offers the same detection method as the regular stealth mode, but instead of monitoring only the selected ports, it monitors all ports below a selected number (port number 1023, by default). You can then exclude monitoring of particular ports. This mode is even more sensitive than Stealth mode and is, therefore, more likely to cause false alarms than regular stealth mode.

Note

When a port is "bound" by PortSentry or any other network service daemon process, all requests that come to that port from the network are handled by the binding process. For example, when the httpd daemon binds to port 80, requests for Web services from the network are processed by httpd.

Besides selecting the PortSentry mode and the ports that are monitored, you can also choose the response to your computer being scanned. By default, PortSentry can log intrusion attempts and block access to the intruder. PortSentry also offers ways of using other tools to respond to intrusions, including firewall rules, route changes, and host denial configuration.

Downloading and installing PortSentry

The portsentry package is not included in any Fedora or Red Hat Linux distribution. You can download the package from any Red Hat Linux FTP mirror site or from the rpmfind.net site. The portsentry package used in this chapter is portsentry-1.0-11.i386.rpm (the last version published by Red Hat as part of the 7.1 PowerTools). After downloading PortSentry, run the following command from the directory you downloaded it to:

 # rpm -Uhv portsentry*

The installed portsentry package consists of several configuration files (in the /etc/portsentry directory), the portsentry start-up script (/etc/init.d/portsentry), and the portsentry command (in /usr/sbin). There are also README files of interest in the /usr/share/doc/portsentry* directory.

Using PortSentry as is

As with LogSentry, you don’t need to do anything to get PortSentry to work after it is installed. By default, here is what PortSentry does when you install the portsentry package:

The /etc/init.d/portsentry start-up script runs automatically when you boot to run levels 3, 4, or 5 (levels 3 and 5 are most commonly used).
The following port numbers are configured to be monitored by PortSentry in basic mode:

TCP: 1, 11, 15, 143, 540, 635, 1080, 1524, 2000, 5742, 6667, 12345, 12346, 20034, 31337, 32771, 32772, 32773, 32774, 40421, 49724, 54320

UDP: 1, 513, 635, 640, 641, 700, 32770, 32771, 32772, 32773, 32774, 31337, 54321
In response to attacks (represented by scans of the ports being monitored), all further attempts to connect to any services for the protocol (TCP or UDP) will be blocked.

The computers that are blocked from accessing your system are listed in either the portsentry.blocked.tcp or portsentry.blocked.udp files (in the /var/portsentry directory), depending on which protocol was scanned (TCP or UPD). Remove entries from these files to restore access to blocked computers.

Configuring PortSentry

Chances are that you will want to make some changes to the way that PortSentry runs. To change how PortSentry behaves, modify the /etc/portsentry/portsentry.conf file. In that file, you can choose which ports to monitor, the mode in which to monitor, and the responses to take when a scan is detected. The responses can include:

Blocking access by the remote computer
Rerouting messages from the remote computer to a dead host
Adding a firewall rule to drop packets from the remote computer

The other file you may want to change is /etc/portsentry/portsentry.modes. The portsentry.modes file simply contains the modes that PortSentry can be run in.

Changing the portsentry.conf file

To edit the portsentry.conf file, as root user, open the /etc/portsentry/portsentry.conf file using any text editor. The following sections describe the information that can be changed in that file.

Selecting ports

The portsentry.conf file defines which ports are monitored in basic and stealth modes. By default, only basic TCP and UDP modes are active, so only those ports are monitored (unless you change to one of the stealth modes). The TCP_PORTS and UDP_PORTS options define which ports are monitored. Here is how they appear in the portsentry.conf file:

TCP_PORTS="1,11,15,143,540,635,1080,1524,2000,5742,6667,12345,12346,200     34,31337,32771,32772,32773,32774,40421,49724,54320"  UDP_PORTS="1,513,635,640,641,700,32770,32771,32772,32773,32774,31337,     54321"

Unless you are a TCP/IP expert, you’re probably wondering what services these ports represent. The Internet Assigned Numbers Authority (IANA) assigns services to UDP and TCP ports. You can see these assignments at the following Web address:

www.iana.org/assignments/port-numbers

Network services in Fedora (as well as other Linux/UNIX systems) obtain port number assignments from the /etc/services file. So, in general, you can simply check the /etc/services file to find out most of the services that are assigned to ports being scanned.

Ports assigned for monitoring are chosen based on a couple of different criteria. Lower port numbers (1, 11, 15, and so on) are chosen to catch port scanners that begin at port 1 and scan through a few hundred ports. If the scanner is blocked after accessing port 1, it won’t be able to get information about any other ports that might be open on your computer. Another criterion is to include ports that are checked specifically by intruders because those services might be vulnerable to attack. They include the systat (port 11) and netstat (port 15) services.

You will want to remove ports from the list in the portsentry.conf file if you are actually running the service assigned to that port. On the other hand, you might want to add ports to the list if you are paranoid about attacks and you want a bit more coverage. The portsentry.conf file contains some examples that you can uncomment (remove the # sign) so that more ports are monitored.

If you change from basic to stealth scans (as described in the “Changing the portsentry.modes file” section later in this chapter), the ports that are monitored are those defined by the ADVANCED_PORTS_TCP and ADVANCED_PORTS_UDP options. Here is how those two options are set by default:

ADVANCED_PORTS_TCP="1023"  ADVANCED_PORTS_UDP="1023"

These entries indicate that all ports from 1 to 1023 are monitored. Monitoring higher port numbers can result in many more false alarms, so this practice is not recommended. If you find that PortSentry is being tripped accidentally, you might want to exclude the ports being tripped by using the ADVANCED_EXCLUDE_TCP and ADVANCED_EXCLUDE_UDP options. The following example shows how these two values are set by default:

ADVANCED_EXCLUDE_TCP="111,113,139"  ADVANCED_EXCLUDE_UDP="520,138,137,67"

By default, ident and NetBIOS services for TCP (ports 111, 113, and 139) and route, NetBIOS, and Bootp broadcasts for UDP (ports 520, 138, 127, and 67) are excluded from the advanced scan. (The exclusion is because a remote computer might hit these ports without representing any misuse.) If you are running in stealth mode, you should likewise exclude any services that you are running on your system by adding their port numbers to this list.

Identifying configuration files

Besides the portsentry.conf file, there are several other configuration files used by PortSentry. You can identify the locations of these other files within the portsentry.conf file. The following lines show how those files are defined:

# Hosts to ignore  IGNORE_FILE="/etc/portsentry/portsentry.ignore"  # Hosts that have been denied (running history)  HISTORY_FILE="/var/portsentry/portsentry.history"  # Hosts denied this session only (temporary until next restart)  BLOCKED_FILE="/var/portsentry/portsentry.blocked"

Chances are that you will not want to move the location of these configuration files. Here are some descriptions of what these files are used for:

The portsentry.ignore file contains a list of all IP addresses that you do not want blocked (even if they improperly try to access ports on your computer). By default, all IP addresses assigned to the local computer are added to this file. You can add IP addresses of trusted computers, if you like.
The portsentry.history file contains a list of IP addresses for computers that have been blocked from accessing your computer.
The portsentry.blocked.* files contain a list of computers that have been blocked from accessing your computer during the current session. The portsentry.blocked.tcp file contains IP addresses of computers that have improperly scanned TCP ports on your computer. Addresses of computers that have been blocked after scanning UDP ports are contained in the portsentry.blocked.udp file.

Access to ports on your computer is only blocked during the current session (that is, until the next reboot or restart of PortSentry). So, to more permanently exclude remote computers, you should impose other restrictions (such as by using the /etc/hosts.deny file, a firewall command, or a reroute to a dead host). These methods are described later in this chapter.

Choosing responses

Someone scanning a port can be compared to someone checking a door in your house to see if it is locked. In most cases, it indicates that someone is checking your system for weaknesses. That is why, when another computer scans your ports, the default response from PortSentry is to block further access from the other computer to your computer for the duration of the current session. No action is taken to permanently block access from that computer. The BLOCK_UDP and BLOCK_TCP options in the portsentry.conf file set which type of automatic response is taken when ports are scanned. Here is how these options are set by default:

BLOCK_UDP="2"  BLOCK_TCP="2"

The value in quotation marks determines how PortSentry reacts to a scan of your ports by another computer. The following list describes each of these values.

A value of "2" (the default value) causes access to be temporarily blocked to services for the scanned protocol (TCP or UDP) and for the action to be logged. Also, if any commands were defined to be run by a KILL_RUN_CMD option, that command is then run. (This option is not configured by default.)
A value of "0" causes port scans to be logged, but not blocked.
A value of "1" causes the KILL_ROUTE and KILL_HOSTS_DENY options to be run. (See the following list for descriptions of these options.) By default, further requests from the remote computer will be rerouted to a dead host, and the remote host’s IP address will be added to the /etc/hosts.deny file, thereby denying access to network services.

Following are some suggestions on options you can use to change the responses to your ports being scanned:

KILL_ROUTE — This option runs the /sbin/route command to reroute requests from the remote computer to a dead host. By default, this option is set to the following value, which effectively drops the request from the remote computer:

KILL_ROUTE="/sbin/route add -host $TARGET$ gw 127.0.0.1"

Note

Instead of rerouting IP packets from the remote host, you can use firewall rules to deny access. If you use ipchains firewalls, uncomment the following line to deny access from the remote host. If you are using iptables, change ipchains to iptables and create an appropriate iptables response.

KILL_ROUTE="/sbin/ipchains -I input -s $TARGET$ -j DENY -l"

This ipchains rule would deny (in other words, drop) all packets from the remote computer. To make this action permanent, you could add the ipchains options (from the -I to the end of the line) to the /etc/sysconfig/ipchains file, replacing the $TARGET$ with the actual IP address of the computer you want to deny access to.

KILL_HOSTS_DENY — This option is used to deny requests for any network services that are protected by TCP wrappers. This option is set by default as follows:
```
KILL_HOSTS_DENY="ALL: $TARGET$" 
```
With the preceding option set, $TARGET$ is replaced by the IP address of the intruding remote computer and the line in quotes is added to the /etc/hosts.deny file. For example, if the remote computer’s IP address were 10.0.0.59, the line that appears in /etc/hosts.deny would be:
```
ALL: 10.0.0.59 
```

KILL_RUN_CMD — Instead of using firewalls, rerouting, or TCP wrappers to deny an intruding computer from accessing your computer, you can choose any command you like in response. With the BLOCK_TCP and BLOCK_UDP options set to "2", the value of KILL_RUN_CMD is run in response to a scan of your monitored ports.

The value of KILL_RUN_CMD should be the full path to the script you want to run, plus any options. To include the IP address of the remote computer or the port number that was scanned, you could include the $TARGET$ or $PORT$ variables, respectively. Here is how the example appears that you would want to modify:

KILL_RUN_CMD="/some/path/here/script $TARGET$ $PORT$"

Caution

Do not use any KILL_RUN_CMD to retaliate against the intruding remote host. Firstly, it is quite possible that the computer that is scanning your ports has itself been cracked and is thus not a valid target for retaliations, and secondly, retaliation may simply incite the cracker into further attacks on you.

PORT_BANNER — You can send a message to the person who sets off the PortSentry monitor by setting the PORT_BANNER option. By default, no message is defined. However, you can uncomment the following line to use that message. (An abusive message is not recommended.)
```
PORT_BANNER="** UNAUTHORIZED ACCESS PROHIBITED ***     YOUR CONNECTION ATTEMPT HAS BEEN LOGGED. GO AWAY."  
```

The number of scans from an intruding computer that PortSentry will accept before setting off the responses described above can be set by using the SCAN_TRIGGER option. By default, that option is set as follows:

SCAN_TRIGGER="0"

The "0" value means that you won’t accept any scans from an intruding system. In other words, the first scan will trip the PortSentry monitor. You can increase this value to be tolerant of one or more errant scans (though you probably won't want to).

Changing the portsentry.modes file

The /etc/portsentry/portsentry.modes file defines the modes in which the PortSentry command is run at boot time. Here is how that file appears by default:

tcp  udp  #stcp  #sudp  #atcp  #audp

The tcp and udp options are the basic PortSentry modes for the TCP and UDP services, respectively. Your other choices of options include stealth TCP (stcp) and advanced stealth TCP (atcp) and stealth UDP (sudp) and advanced stealth UDP (audp). Only run one TCP service and one UDP service. So, if you uncomment a stealth or advanced stealth service, be sure to add a comment in front of the appropriate basic service.

To activate the new services, you would then execute the following command:

 # /etc/init.d/portsentry restart

The new PortSentry modes will take effect immediately. Those new modes will also be in effect when your computer reboots.

Testing PortSentry

You can test that your ports are properly protected in different ways. What you want to do is run a program that a potential intruder would run and see if it trips the appropriate response from PortSentry. For example, you could use a port scanner to see how your ports appear to the outside world. You could also use a command, such as telnet, to try and set off a particular port to see if PortSentry catches it.

nmap is a popular tool for scanning TCP and UDP ports. You can give the nmap command a host name or IP address, and it will scan about 1500 ports on computer to see which ports are open (and presumably offering services that could potentially be cracked).

An RPM of nmap is also available. You can download the nmap-frontend package, which contains a simple graphical interface to nmap called xnmap. I suggest that you install the packages on the system running PortSentry as well as on another system on your LAN (if one is available). Then run the following procedure on the PortSentry system to test it:

If PortSentry is running, shut it down by typing the following:
```
 # /etc/init.d/portsentry stop 
```
Type the following nmap commands to see which ports are open on the local system:
```
 # nmap -sS -O 127.0.0.1 # nmap -sU -O 127.0.0.1  
```
The output shows you which ports are currently offering services on your computer for TCP and UDP protocols, respectively.
If there are any services that you don’t want open, you should turn off those services by using chkconfig service off (replacing service with the service name), by editing the configuration file in the /etc/xinetd.d directory that represents the service and changing disable = no to disable = yes, or by changing your firewall setup.
If there are services that you want to be available from your computer, make sure that the port numbers representing those services are not being monitored by PortSentry. Remove the port number from the TCP_PORTS and/or UDP_PORTS options in the /etc/portsentry/portsentry.conf file, or PortSentry will report that there is a possible stealth scan on the port.
Restart PortSentry as follows:
```
# /etc/init.d/portsentry start
```
Run nmap again, as described previously. The ports offering legitimate services, as well as the ports being monitored by PortSentry, should all appear to be open.
Check the /var/log/messages file to make sure that PortSentry is not trying to monitor any ports on which you are offering services.

When you have determined that PortSentry is set up the way you would like it to be, run the nmap command from another computer on your network. This time, replace 127.0.0.1 with the name or IP address of the PortSentry computer. If everything is working, the first port that the remote computer scans on your PortSentry computer should block all subsequent scans.

Tracking PortSentry intrusions

Besides taking action against intruders, PortSentry logs its activities using the syslog utility. PortSentry’s start-up, shutdown, and scan-detection activities are logged to your /var/log/messages file. The following are examples of PortSentry output in that file.

portsentry[13259]: adminalert: Psionic PortSentry 1.0 is starting.  portsentry[13260]: adminalert: Going into listen mode on TCP port: 1  portsentry[13260]: adminalert: Going into listen mode on TCP port: 11        .        .        .  portsentry[13260]: adminalert: PortSentry is active and listening.  portsentry[]: attackalert:Connect from host:10.0.0.4 to TCP port: 31337  portsentry[]: attackalert: Connect from host: 10.0.0.4 to TCP port: 11  portsentry[]: attackalert: Host: 10.0.0.4 is already blocked. Ignoring        .        .        .  portsentry[13371]: securityalert: Psionic PortSentry is shutting down  portsentry[13371]: adminalert: Psionic PortSentry is shutting down

The first part of the output shows PortSentry starting up. As PortSentry begins listening to each port, that port is noted in a separate log message. The next messages show the computer being scanned. Someone from host 10.0.0.4 ran nmap to scan the ports on the computer. PortSentry caught the scan of port 31337 and blocked attempts to scan other ports.

Finally, the last set of messages shows PortSentry being shut down. This is a security alert because someone besides you could shut down PortSentry to hide the fact that they had broken in.

Note

If you have been running the LogSentry package (described earlier), these messages show up in the e-mail messages you receive each hour from Logcheck.

Restoring access

If access was cut off to a computer that you wanted to have access, there are several things you can check to correct that problem:

/etc/hosts.deny — See if the computer’s IP address was mistakenly added to this file. This would cause network services to be denied to the host at that IP address.
/var/portsentry/portsentry.blocked — Check that an entry for the computer’s IP address wasn’t added to the portsentry.blocked.udp or portsentry.blocked.tcp files.
route — Run the /sbin/route command to see if messages from the computer are being rerouted to a dead host (probably the localhost).

iptables — Run the iptables -L command to see if a new firewall rule was created to block access from the computer.

Tip

To make sure that access isn’t cut off again, you can add the IP address of the remote computer to the /etc/portsentry/portsentry.ignore file. Future improper scans or requests for services won’t cause the remote computer to be blocked.