| | 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=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 <
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
|
