Subject: Intrusion Detection
From: <Microsoft Internet Explorer 5¡Æ¢® AuAa>
Date: Sun, 17 Jun 2001 11:51:17 +0900

Intrusion
Detection
Knowing when someone is knocking on your door.

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://ftp.cerias/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.

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).

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.

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.

Even with the
best of intentions, you can do more harm then good. For example, lets say you
discover that the system that scanned you has been hacked and is being used as a
launching point. You identify a backdoor the hacker left, gain access, grab all
of his tools and logs, and then proceed to notify the system owner and various
emergency response organizations. Even though you think you have done the right
thing, you have caused more harm then good.

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).

The system admin may have known about
the hacker and was working with law enforcement. You have just messed up their
investigation.

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.

Basically, there is a
lot that can wrong and not much that can go right when you act on your own. The
best thing you can do is first get as much information as you can. Identify any
logs that show probes from the source address. Then identify the individuals
and/or organization responsible for the incident. The whois database, dig, and
nslookup are excellent methods to discover who is responsible for the system.
Email them with details of what happened when, including log entries for
verification. You may also want to courtesy copy the organization’s upstream
provider to keep them informed. If the intrusions are serious enough, contact
professional response organizations, such as CERT http://www.cert.org/ or CIAC at http://www.ciac.org/. If the intrusion attempts
continue with no response from the system owners, call the organization. The
phone can be a very powerful tool.

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=[email-masked]
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 [email-masked] .

Whitepapers /
Publications