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