Lance E. Spitzner

Your network is being scanned for vulnerabilities. This may happen only once a month or twice a day, regardless, there are people out there probing your network and systems for weaknesses. I can say this with confidence because I have yet to work on a network that has not been probed. My personal network of six systems at home is on a dedicated ISDN line. This network has no valuable data, nor represents any organization, yet I get probed two to four times a week. If you have a system or network connected to the Internet, you become a target. This article will discuss how you can protect yourself by detecting these intrusion attempts. I will then cover what you can do when you discover these attempts.

Setting up Intrusion Detection

The methods we will be discussing are simple in use and implementation. For larger or more security conscientious organizations, you may want to consider third party Intrusion Detection Systems, such as Network Flight Recorder (http://www.nfr.net/nfr). These more advanced IDS systems use traffic analysis and advance algorithms to determine if a probe has been conducted. Our approach will be somewhat simpler.

There are a variety of different probes hackers will attempt. The first type we will prepare for is one of the most common, port scans. Port scans are where an inidvidual attempts to connect to a variety of different ports. The scans can be used on a specific target, or used to scan entire IP ranges, often chosen at random This is one of the most popular information gathering methods used by hackers today as it identifies what ports and services are open.

To detect these scans, we will build a system that emails us alerts whenever someone connects to a predetermined port. First, we identify three to five of the most commonly scanned ports. Then we select two to three systems to listen on these ports. When an intruder scans our network, he will most likely hit our systems listening on these ports. When these ports are scanned, the systems log the attempt, execute various predetermined actions, then email an alert to a point of contact.

The end result is you receive an email for each port scanned. If you have 3 systems, each listening on 4 ports, then you may get up to 12 emails from a single network port scan. However, this is normally not the case. If hackers are scanning an entire network, they are normally looking for a single vulnerability, such as imap (port 143). In this case, we would have received only three emails, one from each system. When they scan a single target, often they scan a range of ports, such as 1-1024. In that case, we would have received only 4 emails, one for each port on the system. Based on what emails you get, you can quickly determine what the intruder is interested in. See Figure 1.

To implement this methodology, we first identify two to three systems to use for monitoring. I often select DNS servers as these are primary targets, many scanning tools start by scanning Name Servers to build databases of IP addresses. Then select three to five of the most commonly scanned ports. Ensure that you are not using these ports, or every time someone connects to it, you will be alerted. To identify commonly scanned ports, CERT alerts are a great place to start, you can find these alerts at http://www.cert.org. The ports we will be using are.

imap (port 143)
SMB (port 139)
login (port 513)
http (port 80)

I like these ports since hackers commonly look for them, but most of your systems will not be using them. Make sure these ports are not already blocked by a screening router or a firewall. We will then set several system to listen on these ports, alerting us when there is a connection.

Our implementation uses TCP Wrappers. Created by Wietse Venema, TCP Wrappers allows us to control, log, and most importantly, react to any wrapped service. When someone connects to one of the services we defined above, TCP Wrappers will log the connection (via syslog) and then spawn our alerting mechanism.

For those of you who do not already have TCP Wrappers installed , I highly recommend it. It is extremely easy to compile, configure, and implement. You can find it at many tool repositories, such as ftp://coast.cs/purdue.edu/pub/tools/unix. Before you compile it, enable language extensions in the Makefile (this greatly enhances it configurability). We will be using this capability for intrusion detection purposes. For more information on installing TCP Wrappers, I recommend you review my article on "Armoring Solaris".

Once we have compiled and installed TCP Wrappers, we will want to wrap the four ports we defined above. The ports are first defined in /etc/services and then added to the /etc/inetd.conf file. Here is an example of "wrapping" imap in the file /etc/inetd.conf.

imap stream tcp nowait root /usr/local/bin/tcpd imap.trap

When someone connects to port 143, tcpd accepts the connection from inetd. It then looks at the /etc/hosts.allow file for access control. This is where we define what connections are allowed to launch the alert. Finally, it will finish by launching imap.trap. You will need to rename imap.trap for each respective service, such as http.trap for http or smb.trap for smb. Below is an example of the entry in /etc/hosts.allow, this is the entry that alerts us of a possible probe.

imap.trap: ALL: spawn (/var/adm/ids.sh %d %h %H)

This tells tcpd to accept all connections to port 143 regardless of IP, then spawn our intrusion detection script, the script that alerts us. We want spawn instead of twist, because twist uses the remote client for all stdout and stderr. The three expansions following the ids.sh file (defined by TCP Wrappers) become in line variables.

The script /var/adm/ids.sh is where all the action happens. You can modify for your own personal taste. I have included an example that parses the data, does a safe_finger on the client, emails an alert to a point of contact, and optionally launches snoop to track any additional action see Figure 2.

Now, whenever someone connects to one of our predetermined ports, we receive a formatted email with all the critical data. For example, a user scans our network for port 143 looking for imap vulnerabilities. Three of our systems are listening on that port. The connection is made, and tcpd is launched. It looks at /etc/hosts.allow, and finds an entry for imap.trap. It spawns our intrusion detection script /var/adm/ids.sh, which parses the data, fingers the client, then emails an alert. We also have the option of launching tools, in this example snoop. The last thing that happens is that tcpd attempts to launch /usr/sbin/imap.trap, which it does not find. Tcpd then exits, logging an error to syslog. To avoid this, you may want to create a shell script /usr/sbin/imap.trap, which does nothing but exit out.

One thing to keep in mind is Denial of Service attacks. The more you have your script do, the more system overhead you incur. An attacker could disable your system by making multiple connections to the predetermined ports, creating multiple processes of your scripts. I recommend that if you implement a variety of actions in your scripts, that you limit the number of process per source IP address.  A simple way to do this is grep for the source in your tcpdlog.  If you do not find the source, this is the first time the system has probed you, so launch your profiling script.  Otherwise, the source has scanned you before, so just log the entry.

An alternative to using TCP Wrappers is router logs. Many of us do not have the luxury of using three systems for intrusion detection. However, you can use the methodology described above using your internet router. One again, you select two or three systems and three to five ports to be monitored. Build an ACL (Access Control List) on your router that denies the specified ports and systems. Have this ACL log all connection attempts to a syslog server. Now you can monitor any denied traffic and quickly determine if your network has been probed. I have had great success implementing this with Swatch which automates both the filtering and alerting process.

These solutions are not foolproof. Many of today’s port scanners do not complete the TCP SYN/ACK sequence during a connection. In fact, many scans use invalid packets (such as FIN or Xmas scans). The methods I have discussed will NOT detect some of these scans. For more robust intrusion detection you will need more advance tools, such as tcplogd, which will detect these "stealth" scans.

There are other ways you can implement intrusion detection on your system. Once again, you have to first identify the intrusion methodology, then implement a tracking and alerting procedure. An example would be brute force attempts to login. Five consecutive failed attempts to login are logged in the file /var/adm/loginlog. This would happen when a hacker is probing your system for weak login and password combinations. I set all my systems to run a daily cronjob and see if there are any entries in the file. If there are, someone has either forgotten their password and is guessing what it is, or a potential hacker is attempting a brute force entry. The cronjob emails me the entries, make a copy to an archive, then clears the log. Another example is the common /cgi-bin/test-cgi attack used on web servers. Instead of disabling this cgi script, I alter it to log and email me whenever someone attempts this exploit. This usually involves nothing more the modifying the shell script test-cgi (be sure to test this before you implement it on your system).

As we have covered, there are a variety of simple ways to implement some basic intrusion detection. Though not foolproof, these methodologies will help you identify potential probes and protect your network. Now, once you have implemented intrusion detection, what do you do when you discover your systems are being probed?

Reacting to an Intrusion

The firs step is confirming that your systems are truly being probed. Just because you receive one email alert from our TCP Wrapper setup does NOT mean you are being scanned. A confused user may be connecting to the wrong system, or someone is simply mistyping a key. Nothing is more embarrassing then accusing someone of something they did not do.However, if you have three consecutive systems scanned on the same port at the same time, this indicates that you may have been probed. Now what?

The last thing you want to do is send out a counter attack on the system and take them off the air. When your network gets scanned, you may feel frustrated and want to take that frustration on the system that probed you.. Since someone is preparing to hack you, shouldn’t you act? However, you want to be very careful how you react.

1. Your systems may have indeed been scanned, but by accident. Many times large organizations scan their internal networks and remote offices. Someone may have scanned the wrong network (I personally know of this happening at one organization).
2. Often the people responsible for the systems that scanned you have no idea of what happened. Large systems with hundreds of users may have a malicious user who is illegally using his or her account to probe other networks. Or, the system may have been hacked and is beings used as a launching point. Either way, the admin of the system will want to know so they can fix the problem.
3. The source IP address showing in your logs may not be valid system, rather they may be a "decoy" source. Many scanning tools allow the user to change the source IP address to whatever the user wants. Your logs may show your systems scanned from five different sources, however you were actually scanned be the same machine. The user is attempting to deceive the true source of the probe by using fake source IPs. It is now extremely difficult to determine which one of scans was the actual probe. Also, the user could have faked his source IP address to lay blame on someone else.

1. Most likely the hacker replaced various monitoring tools and logs on the compromised system. He may discover you were there, then wipe the system clean to cover his tracks (thus destroying the machine).
2. The system admin may have known about the hacker and was working with law enforcement. You have just messed up their investigation.
3. You can be held liable for the hacking incident. The system owners do not know you and may accuse you of being the original hacker, attempting to protect yourself by blaming someone else.

Conclusion

Sooner or later, you systems and networks may be probed for various vulnerabilities. By taking some of the basic measures we have discussed, you will be better prepared to log and identify these attempts. Once identified, you can track these probes and gain a better understanding of the threats to your network and react to these threats. When identified, it is best to gain as much information as possible, then notify the individuals and organization responsible for the system. Taking action on your own will often become messy, causing more harm then good. By working with others, you will come to a better a solution.

Figure 1

Subject: ### Intrusion Detection Alert ###

You have received this alert because the network
is potentially being scanned. The information below
is the packet that was logged and dropped.

Date: Sat Jan 24
Time: 18:47:46
Source: ICARUS.CC.UIC.EDU
Destination: lisa
Service: imap

--- Finger Results ---

[ICARUS.CC.UIC.EDU]

Login Name TTY Idle When Where

Spitzner Lance Everett Spitzn pts/72 Sun 18:42 lspitz-4.soho.entera
 

Figure 2

#!/bin/ksh
#
# Script launched by tcpd for intrusion detection purposes
#

USER=lance@spitzner.net
SRV=`echo $1 | cut -f1 -d.`
DATE=`date "+%a %b %e"`
TIME=`date "+%T"`
FINGER=`/usr/local/bin/safe_finger @$2`

MAIL=/usr/bin/mail

$MAIL $USER <<EOF
Subject: ### Intrusion Detection Alert ###

You have received this alert because the network
is potentially being scanned. The information below
is the packet that was logged and dropped.

Date: $DATE
Time: $TIME
Source: $2
Destination: $3
Service: $SRV

--- Finger Results ---

$FINGER

EOF

##### If the service is imap, lets go ahead and snoop the session.

if [ $SRV=imap ]; then

snoop -v -c 5000 -o /var/adm/$2_snoop.$$ $2 &

fi
 

Author’s bio
Lance Spitzner enjoys learning by blowing up his Unix systems at home. Before this, he was an Officer in the Rapid Deployment Force, where he blew up things of a different nature. You can reach him at lance@spitzner.net .