View and vote on the article here: Intrusion Detection
Intrusion Detection| Category | | | Summary | | | Body |
Intrusion Detection
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 <<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 . |
|
This article was imported from the CyberArmy University site. (original author: )
There are no replies to this post yet.
|