From: Subject: Intrusion Detection Date: Sun, 17 Jun 2001 11:51:17 +0900 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Location: http://www.enteract.com/~lspitz/ids.html X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Intrusion Detection Intrusion=20 Detection
Knowing when someone is knocking on your = door.=20

Lance E. = Spitzner=20

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

Setting up = Intrusion=20 Detection=20

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Reacting to = an=20 Intrusion=20

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

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

  1. Your systems may have indeed = been=20 scanned, but by accident. Many times large organizations scan their = internal=20 networks and remote offices. Someone may have scanned the wrong = network (I=20 personally know of this happening at one organization).=20
  2. Often the people responsible = for the=20 systems that scanned you have no idea of what happened. Large systems = with=20 hundreds of users may have a malicious user who is illegally using his = or her=20 account to probe other networks. Or, the system may have been hacked = and is=20 beings used as a launching point. Either way, the admin of the system = will=20 want to know so they can fix the problem.=20
  3. The source IP address showing = in your=20 logs may not be valid system, rather they may be a "decoy" source. = Many=20 scanning tools allow the user to change the source IP address to = whatever the=20 user wants. Your logs may show your systems scanned from five = different=20 sources, however you were actually scanned be the same machine. The = user is=20 attempting to deceive the true source of the probe by using fake = source IPs.=20 It is now extremely difficult to determine which one of scans was the = actual=20 probe. Also, the user could have faked his source IP address to lay = blame on=20 someone else.
Even with the=20 best of intentions, you can do more harm then good. For example, lets = say you=20 discover that the system that scanned you has been hacked and is being = used as a=20 launching point. You identify a backdoor the hacker left, gain access, = grab all=20 of his tools and logs, and then proceed to notify the system owner and = various=20 emergency response organizations. Even though you think you have done = the right=20 thing, you have caused more harm then good.=20
  1. Most likely the hacker = replaced various=20 monitoring tools and logs on the compromised system. He may discover = you were=20 there, then wipe the system clean to cover his tracks (thus destroying = the=20 machine).=20
  2. The system admin may have = known about=20 the hacker and was working with law enforcement. You have just messed = up their=20 investigation.=20
  3. You can be held liable for = the hacking=20 incident. The system owners do not know you and may accuse you of = being the=20 original hacker, attempting to protect yourself by blaming someone=20 else.
Basically, = there is a=20 lot that can wrong and not much that can go right when you act on your = own. The=20 best thing you can do is first get as much information as you can. = Identify any=20 logs that show probes from the source address. Then identify the = individuals=20 and/or organization responsible for the incident. The whois database, = dig, and=20 nslookup are excellent methods to discover who is responsible for the = system.=20 Email them with details of what happened when, including log entries for = verification. You may also want to courtesy copy the = organization’s upstream=20 provider to keep them informed. If the intrusions are serious enough, = contact=20 professional response organizations, such as CERT http://www.cert.org/ or CIAC at http://www.ciac.org/. If the intrusion = attempts=20 continue with no response from the system owners, call the organization. = The=20 phone can be a very powerful tool.=20

Conclusion=20

Sooner or later, you systems and = networks=20 may be probed for various vulnerabilities. By taking some of the basic = measures=20 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=20 understanding of the threats to your network and react to these threats. = When=20 identified, it is best to gain as much information as possible, then = notify the=20 individuals and organization responsible for the system. Taking action = on your=20 own will often become messy, causing more harm then good. By working = with=20 others, you will come to a better a solution.=20

Figure = 1=20

Subject: ### = Intrusion=20 Detection Alert ###=20

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

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

--- Finger Results = ---=20

[ICARUS.CC.UIC.EDU]=20

Login Name TTY = Idle When=20 Where=20

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

Figure 2 =

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

USER=3Dlance@honeynet.org
SRV=3D`echo $1 | cut -f1=20 -d.`
DATE=3D`date=20 "+%a %b %e"`
TIME=3D`date "+%T"`
FINGER=3D`/usr/local/bin/safe_finger=20 @$2`=20

MAIL=3D/usr/bin/mail=20

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

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

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

--- Finger Results = ---=20

$FINGER=20

EOF=20

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

if [ $SRV=3Dimap = ];=20 then=20

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

fi =
 =20

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

Whitepapers /=20 = Publications