MPRM Group Limited - Network Security

<body topmargin="0" leftmargin="0"> <p align="center"><font face="MS Sans Serif" size="2"><a target="_top" href="http://www.mobrien.com/advice1.html">Contact us</a> | <a href="http://www.mobrien.com/firewall_r.html">Firewalls</a> | <a href="http://www.mobrien.com/windows_nt_wardoc.htm">NT Penetration</a> | <a href="http://www.mobrien.com/web.html">Web Services</a> | <a href="http://www.mobrien.com/computer_crime.shtml">Computer Crime</a> | <a href="http://www.mobrien.com/terminology.shtml">Terminology</a> | <b><a target="_top" href="http://www.mobrien.com/ui.html">Index</a></b></font> <p align="center"><b><font face="MS Sans Serif" size="3"><img src="mprm_white.gif" border="0" width="300" height="75"></font></b> <p><font face="Verdana" color="#000080" size="4" t ,><i>Investigation Tool: Knowledge</i></font> <p><b><font face="MS Sans Serif" size="3"><u>Detecting intruders who attack systems through your network.</u></font></b> <p align="left"><font face="Verdana" size="2"><b>Welcome:</b></font> <blockquote> <ul> <li> <p align="left"><font face="Verdana" size="2">A small collection of  <a href="http://library.mobrien.com">free hacker (not cracker) tools</a> is available at our <a href="http://library.mobrien.com">Collingwood server</a> to help you watch your favourite box for intruders. </font></p> <li> <p align="left"><font face="Verdana" size="2">An extensive array of <a href="http://www.mobrien.com/traceroute.html">traceroute facilities</a> is available at out <a href="http://www.mobrien.com/traceroute.html">Mississauga Server</a></font></p> <li> <p align="left"><font face="Verdana" size="2">A comprehensive set of <a href="http://www.mobrien.com/net.shtml">network tools</a> is available at this site including: Subnet Mask Calculator; Network/Node Calculator; IP address Calculator (hex / decimal / binary TCPIP Address); NSLookup; and Traceroute.</font></p> </li> </ul> </blockquote> <p align="left"><font face="Verdana" size="2">We also suggest you check out the latest security releases from  the folllowing:</font> <ul> <li><font face="Verdana" size="2"><a target="_blank" href="http://bach.cis.temple.edu/linux/linux-security/Linux-Alerts/">Linux Security Alert</a> from Linux Emergency Response Team.</font> <li><a target="_blank" href="http://www.microsoft.com/security/"><font face="Verdana" size="2">Microsoft Security Advisor</font></a> <li><a target="_blank" href="http://www.openbsd.org/security.html"><font face="Verdana" size="2">OpenBSD Security Views</font></a> <li><a target="_blank" href="http://www.sgi.com/Support/security/advisories.html"><font face="Verdana" size="2">Silicon Graphics Security Advisories</font></a> <li><a target="_blank" href="http://sunsolve.sun.com/sunsolve/securitypub.html"><font face="Verdana" size="2">Sun: Security and Other Public Information</font></a> <li><font face="Verdana" size="2"><a href="http://www.mobrien.com/intruders.shtml">Detecting Intruders</a></font></li> </ul> <p><b><font face="MS Sans Serif" size="3">PAGE MENU</font></b><font face="MS Sans Serif" size="3"><br> </font><font face="MS Sans Serif" size="2"><a target="_top" href="http://www.mobrien.com/advice1.html">Contact us</a> | <a href="http://www.mobrien.com/firewall_r.html">Firewalls</a> | <a href="http://www.mobrien.com/windows_nt_wardoc.htm">NT Penetration</a> | <a href="http://www.mobrien.com/web.html">Web Services</a> | <a href="http://www.mobrien.com/computer_crime.shtml">Computer Crime</a> | <a href="http://www.mobrien.com/terminology.shtml">Terminology</a> | <b><a target="_top" href="http://www.mobrien.com/ui.html">Index</a></b></font> <table cellSpacing="0" cellPadding="0" border="0"> <tbody> <tr> <td vAlign="top"><font face="MS Sans Serif" size="2">1. <b>Introduction</b><br> - <a href="#1.1">What is a "network intrusion detection system (NIDS)"?</a><br> - <a href="#1.2">Who is misusing the system?</a><br> - <a href="#1.3">How do intruders get into systems?</a><br> - <a href="#1.4">Why can intruders get into systems?</a><br> - <a href="#1.5">How do intruders get passwords?</a><br> - <a href="#1.6">What is a typical intrusion scenario?</a><br> - <a href="#1.7">What are some common "intrusion signatures"?</a><br> - <a href="#1.8">What are some common exploits?</a><br> - <a href="#1.9">What are some common reconnaisance scans?</a><br> - <a href="#1.10">What are some common DoS (Denial of Service) attacks?</a><br> - <a href="#1.11">How much danger from intrusions is there?</a><br> - <a href="#1.12">Where can I find current statistics about intrusions?</a><br> 2. <a href="#2."><b>Architecture</b></a><br> - <a href="#2.1">How are intrusions detected?</a><br> - <a href="#2.2">How does a NIDS match signatures with incoming traffic?</a><br> - <a href="#2.4">What happens after a NIDS detects an attack?</a><br> - <a href="#2.5">What other countermeasures besides IDS are there?</a><br> - <a href="#2.6">Where do I put IDS systems on my network?</a><br> - <a href="#2.7">How does IDS fit with the rest of my security framework?</a><br> 3. <a href="#3."><b>Policy</b></a><br> - <a href="#3.1">How do I increase intrusion detection/prevention under WinNT?</a><br> - <a href="#3.2">How do I increase intrusion detection/prevention under Win95/Win98?</a><br> - <a href="#3.3">How do I increase intrusion detection/prevention under UNIX?</a><br> - <a href="#3.4">How do I increase intrusion detection/prevention under Macintosh?</a><br> - <a href="#3.5">How do I increase intrusion detection/prevention for the enterprise?</a><br> - <a href="#3.6">How should I implement intrusion detection my enterprise?</a><br> - <a href="#3.7">What should I do when I've been hacked?</a><br> - <a href="#3.8">How should I respond when somebody tells me they've been hacked from my site?</a><br> - <a href="#3.9">How do I collect enough evidence about the hacker?</a></font> <p><font face="MS Sans Serif" size="2">4. <a href="#4."><b>Products</b></a><br> - <a href="#4.1">What freeware/shareware intrusion detection systems are available?</a><br> - <a href="#4.2">What commercial intrusion detection systems are available?</a><br> - <a href="#4.3">What is a "network grep" system?</a><br> - <a href="#4.4">What tools do intruders use to break into my systems?</a><br> - <a href="#4.5">What other free/shareware intrusion detection products should I be aware of?</a><br> 6. <a href="#6."><b>Resources</b></a><br> - <a href="#6.1">Where can I find updates about new security holes?</a><br> - <a href="#6.2">What are some other security and intrusion detection resources?</a><br> - <a href="#6.3">What are some sites that are interesting?</a><br> 7. <a href="#7."><b>IDS and Firewalls</b></a><br> - <a href="#7.2">Why do I need IDS if I already have a firewall?</a><br> - <a href="#7.3">If I have a intrusion detection, do I need firewall?</a><br> - <a href="#7.4">Where does the intrusion detection system gets its information? The firewall?</a><br> 8. <a href="#8."><b>Implementation Guide</b></a><br> - <a href="#8.1">What questions should I ask my IDS vendor?</a><br> - <a href="#8.2">How do I maintain the system on an on-going basis?</a><br> - <a href="#8.4">How do I stop innapropriate web surfing?</a><br> - <a href="#8.5">How can I build my own IDS (writing code)?</a><br> - <a href="#8.7">What is the legality of NIDS (since it is a form of wiretap)?</a><br> - <a href="#8.8">How do I save logfiles in a tamper-proof way?</a><br> 9. <a href="#9"><b>What are the limitations of NIDS?</b></a><br> -<a href="#9.1">Switched network (inherent limitation)</a><br> -<a href="#9.2">Resource limitations</a><br> -<a href="#9.3">Attacks against the NIDS</a><br> -<a href="#9.4">Simple evasion</a><br> -<a href="#9.5">Complex evasion</a><br> -<a href="#9.9">Tools</a><br> 10. <a href="#10."><b>Misc.</b></a><br> - <a href="#10.1">What are some standardization/interoperability efforts?</a><br> 11. <a href="#11."><b>Honeypots and Deception Systems</b></a><br> - <a href="#11.1">What is a honeypot?</a><br> - <a href="#11.2">What are the advantages of a honeypot?</a><br> - <a href="#11.3">What are the disadvantages of a honeypot?</a><br> - <a href="#11.4">How can I setup my own honepot?</a><br> - <a href="#11.5">What are the types of honeypots?</a><br> - <a href="#11.6">What are the pros/cons of setting up a system that can be hacked?</a><br> - <a href="#11.7">Are there examples of people using honeypots?</a><br> - <a href="#11.8">What honeypot products are available?</a><br> - <a href="#11.9">What are deception countermeasures?</a><br> <br> </font></p> </td> </tr> </tbody> </table> <dl compact> <dt>  <dt>  <h1><a name="1."><font face="MS Sans Serif" size="3">1. Introduction</font></a></h1> <dd>  <dt>  <h2><a name="1.1"><font face="MS Sans Serif" size="3">1.1 What is a "network intrusion detection system (NIDS)"?</font></a></h2> <dd> <p><font face="MS Sans Serif" size="3">An <b>intrusion</b> is somebody (A.K.A. "hacker" or "cracker") attempting to break into or misuse your system. The word "misuse" is broad, and can reflect something severe as stealing confidential data to something minor such as misusing your email system for spam (though for many of us, that is a major issue!).</font> <p><font face="MS Sans Serif" size="3">An "Intrusion Detection System (IDS)" is a system for detecting such intrusions. For the purposes of this FAQ, IDS can be broken down into the following categories:</font> <p><font face="MS Sans Serif" size="3"><b>network intrusion detection systems (NIDS)</b> monitors packets on the network wire and attempts to discover if a hacker/cracker is attempting to break into a system (or cause a denial of service attack). A typical example is a system that watches for large number of TCP connection requests (SYN) to many different ports on a target machine, thus discovering if someone is attempting a TCP port scan. A NIDS may run either on the target machine who watches its own traffic (usually integrated with the stack and services themselves), or on an independent machine promiscuously watching all network traffic (hub, router, probe). Note that a "network" IDS monitors many machines, whereas the others monitor only a single machine (the one they are installed on).</font> <p><font face="MS Sans Serif" size="3"><b>system integrity verifiers (SIV)</b> monitors system files to find when a intruder changes them (thereby leaving behind a backdoor). The most famous of such systems is "Tripwire". A SIV may watch other components as well, such as the Windows registry and chron configuration, in order to find well known signatures. It may also detect when a normal user somehow acquires root/administrator level privleges. Many existing products in this area should be considered more "tools" than complete "systems": i.e. something like "Tripwire" detects changes in critical system components, but doesn't generate real-time alerts upon an intrusion.</font> <p><font face="MS Sans Serif" size="3"><b>log file monitors (LFM)</b> monitor log files generated by network services. In a similar manner to NIDS, these systems look for patterns in the log files that suggest an intruder is attacking. A typical example would be a parser for HTTP server log files that looking for intruders who try well-known security holes, such as the "phf" attack. Example: swatch</font> <p><font face="MS Sans Serif" size="3"><b>deception systems</b> (A.K.A. decoys, lures, fly-traps, honeypots) which contain pseudo-services whose goal is to emulate well-known holes in order to trap hackers. See <i>The Deception ToolKit <a href="http://www.all.net/dtk/">http://www.all.net/dtk/</a></i> for an example. Also, simple tricks by renaming "administrator" account on NT, then setting up a dummy account with no rights by extensive auditing can be used. There is more on "deception" later in this document. Also see <a href="http://www.enteract.com/~lspitz/honeypot.html">http://www.enteract.com/~lspitz/honeypot.html</a></font> <p><b><font face="MS Sans Serif" size="3">other</font></b> <p><font face="MS Sans Serif" size="3">For more info, see <a href="http://www.icsa.net/idswhite/">http://www.icsa.net/idswhite/</a>.</font></p> <dt>  <h2><a name="1.2"><font face="MS Sans Serif" size="3">1.2 Who is misusing the system?</font></a></h2> <dd><font face="MS Sans Serif" size="3">There are two words to describe the intruder: <b>hacker</b> and <b>cracker</b>. A hacker is a generic term for a person who likes getting into things. The benign hacker is the person who likes to get into his/her own computer and understand how it works. The malicious hacker is the person who likes getting into other people's systems. The benign hackers wish that the media would stop bad-mouthing all hackers and use the term 'cracker' instead. Unfortunately, this is not likely to happen. In any event, the word used in this FAQ is 'intruder', to generically denote anybody trying to get into your systems.</font> <p><font face="MS Sans Serif" size="3">Intruders can be classified into two categories.</font> <dl> <dt><b><font face="MS Sans Serif" size="3">Outsiders</font></b> <dd><font face="MS Sans Serif" size="3">Intruders from outside your network, and who may attack you external presence (deface web servers, forward spam through email servers, etc.). They may also attempt to go around the firewall to attack machines on the internal network. Outside intruders may come from the <b>Internet</b>, <b>dial-up</b> lines, <b>physical break-ins</b>, or from <b>partner</b> (vendor, customer, reseller, etc.) network that is linked to your corporate network.</font> <dt><b><font face="MS Sans Serif" size="3">Insiders</font></b> <dd><font face="MS Sans Serif" size="3">Intruders that legitimately use your internal network. These include users who <b>misuse priviledges</b> (such as the Social Security employee who marked someone as being dead because they didn't like that person) or who <b>impersonate</b> higher privileged users (such as using someone else's terminal). A frequently quoted statistic is that 80% of security breaches are committed by insiders.</font></dd> </dl> <p><font face="MS Sans Serif" size="3">There are several types of intruders <b>Joy riders</b> hack because they can. <b>Vandals</b> are intent on causing destruction or marking up your web-pages. <b>Profiteers</b> are intent on profiting from their enterprise, such as rigging the system to give them money or by stealing corporate data and selling it.</font></p> <dt>  <h2><a name="1.3"><font face="MS Sans Serif" size="3">1.3 How do intruders get into systems?</font></a></h2> <dd><font face="MS Sans Serif" size="3">The primary ways a intruder can get into a system:</font> <p><font face="MS Sans Serif" size="3"><b>Physical Intrusion</b> If a intruders have physical access to a machine (i.e. they can use the keyboard or take apart the system), they will be able to get in. Techniques range from special privileges the console has, to the ability to physically take apart the system and remove the disk drive (and read/write it on another machine). Even BIOS protection is easy to bypass: virtually all BIOSes have backdoor passwords.</font> <p><font face="MS Sans Serif" size="3"><b>System Intrusion</b> This type of hacking assumes the intruder already has a low-privilege user account on the system. If the system doesn't have the latest security patches, there is a good chance the intruder will be able to use a known exploit in order to gain additional administrative privileges.</font> <p><font face="MS Sans Serif" size="3"><b>Remote Intrusion</b> This type of hacking involves a intruder who attempts to penetrate a system remotely across the network. The intruder begins with no special privileges. There are several forms of this hacking. For example, a intruder has a much more difficult time if there exists a firewall on between him/her and the victim machine.</font> <p><font face="MS Sans Serif" size="3">Note that Network Intrusion Detection Systems are primarily concerned with Remote Intrusion.</font></p> <dt>  <h2><a name="1.4"><font face="MS Sans Serif" size="3">1.4 Why can intruders get into systems?</font></a></h2> <dd><font face="MS Sans Serif" size="3">Software always has bugs. System Administrators and Programmers can never track down and eliminate all possible holes. Intruders have only to find one hole to break in.</font> <dl> <dt>  <h3><a name="1.4.1"><font face="MS Sans Serif" size="3">1.4.1 Software bugs</font></a></h3> <dd><font face="MS Sans Serif" size="3">Software bugs are exploited in the server daemons, the client applications, the operating system, and the network stack. Software bugs can be classified in the following manner:</font> <p><font face="MS Sans Serif" size="3"><b>Buffer overflows:</b> Almost all the security holes you read about in the press are due to this problem. A typical example is a programmer who sets aside 256 characters to hold a login username. Surely, the programmer thinks, nobody will ever have a name longer than that. But a hacker thinks, what happens if I enter in a false username longer than that? Where do the additional characters go? If they hackers do the job just right, they can send 300 characters, including code that will be executed by the server, and voila, they've broken in. Hackers find these bugs in several ways. First of all, the source code for a lot of services is available on the net. Hackers routinely look through this code searching for programs that have buffer overflow problems. Secondly, hackers may look at the programs themselves to see if such a problem exists, though reading assembly output is really difficult. Thirdly, hackers will examine every place the program has input and try to overflow it with random data. If the program crashes, there is a good chance that carefully constructed input will allow the hacker to break in. Note that this problem is common in programs written in C/C++, but rare in programs written in Java.</font> <p><font face="MS Sans Serif" size="3"><b>Unexpected combinations:</b> Programs are usually constructed using many layers of code, including the underlying operating system as the bottom most layer. Intruders can often send input that is meaningless to one layer, but meaningful to another layer. The most common language for processing user input on the web is PERL. Programs written in PERL will usually send this input to other programs for further evaluation. A common hacking technique would be to enter something like "<code>| mail < /etc/passwd</code>". This gets executed because PERL asks the operating system to launch an additional programme with that input. However, the operating system intercepts the pipe '|' character and launches the 'mail' programme as well, which causes the password file to be emailed to the intruder.</font> <p><font face="MS Sans Serif" size="3"><b>Unhandled input:</b> Most programs are written to handle valid input. Most programmers do not consider what happens when somebody enters input that doesn't match the specification.</font> <p><font face="MS Sans Serif" size="3"><b>Race conditions:</b> Most systems today are "multitasking/multithreaded". This means that they can execute more than one programme at a time. There is a danger if two programs need to access the same data at the same time. Imagine two programs, A and B, who need to modify the same file. In order to modify a file, each programme must first read the file into memory, change the contents in memory, then copy the memory back out into the file. The race condition occurs when programme A reads the file into memory, then makes the change. However, before A gets to write the file, programme B steps in and does the full read/modify/write on the file. Now programme A writes its copy back out to the file. Since programme A started with a copy before B made its changes, all of B's changes will be lost. Since you need to get the sequence of events in just the right order, race conditions are very rare. Intruders usually have to tries thousands of time before they get it right, and hack into the system.</font></p> <dt>  <h3><a name="1.4.2"><font face="MS Sans Serif" size="3">1.4.2 System configuration</font></a></h3> <dd><font face="MS Sans Serif" size="3">System configuration bugs can be classified in the following manner:</font> <p><font face="MS Sans Serif" size="3"><b>Default configurations:</b> Most systems are shipped to customers with default, easy-to-use configurations. Unfortunately, "easy-to-use" means "easy-to-break-in". Almost any UNIX or WinNT machine shipped to you can be hacked in easily.</font> <p><font face="MS Sans Serif" size="3"><b>Lazy administrators:</b> A surprising number of machines are configured with an empty root/administrator password. This is because the administrator is too lazy to configure one right now and wants to get the machine up and running quickly with minimal fuss. Unfortunately, they never get around to fixing the password later, allowing intruders easy access. One of the first things a intruder will do on a network is to scan all machines for empty passwords.</font> <p><font face="MS Sans Serif" size="3"><b>Hole creation:</b> Virtually all programs can be configured to run in a non-secure mode. Sometimes administrators will inadvertently open a hole on a machine. Most administration guides will suggest that administrators turn off everything that doesn't absolutely positively need to run on a machine in order to avoid accidental holes. Note that security auditing packages can usually find these holes and notify the administrator.</font> <p><font face="MS Sans Serif" size="3"><b>Trust relationships:</b> Intruders often "island hop" through the network exploiting trust relationships. A network of machines trusting each other is only as secure as its weakest link.</font></p> <dt>  <h3><a name="1.4.3"><font face="MS Sans Serif" size="3">1.4.3 Password cracking</font></a></h3> <dd><font face="MS Sans Serif" size="3">This is a special category all to itself.</font> <p><font face="MS Sans Serif" size="3"><b>Really weak passwords:</b> Most people use the names of themselves, their children, spouse/SO, pet, or car model as their password. Then there are the users who choose "password" or simply nothing. This gives a list of less than 30 possibilities that a intruder can type in for themselves.</font> <p><font face="MS Sans Serif" size="3"><b>Dictionary attacks:</b> Failing the above attack, the intruder can next try a "dictionary attack". In this attack, the intruder will use a programme that will try every possible word in the dictionary. Dictionary attacks can be done either by repeatedly logging into systems, or by collecting encrypted passwords and attempting to find a match by similarly encrypting all the passwords in the dictionary. Intruders usually have a copy of the English dictionary as well as foreign language dictionaries for this purpose. They all use additional dictionary-like databases, such as names (see above) and lists of common passwords.</font> <p><font face="MS Sans Serif" size="3"><b>Brute force attacks:</b> Similar to a Dictionary attack, a intruder may try all possible combinations of characters. A short 4-letter password consisting of lower-case letters can be cracked in just a few minutes (roughly, half a million possible combinations). A long 7-character password consisting of upper and lower case, as well as numbers and punctuation (10 trillion combinations) can take months to crack assuming you can try a million combinations a second (in practice, a thousand combinations per second is more likely for a single machine).</font></p> <dt>  <h3><a name="1.4.4"><font face="MS Sans Serif" size="3">1.4.4 Sniffing unsecured traffic</font></a></h3> <dd> <p><font face="MS Sans Serif" size="3"><b>Shared medium:</b> On traditional Ethernet, all you have to do is put a Sniffer on the wire to see all the traffic on a segment. This is getting more difficult now that most corporations are transitioning to switched Ethernet.</font> <p><font face="MS Sans Serif" size="3"><b>Server sniffing:</b> However, on switched networks, if you can install a sniffing programme on a server (especially one acting as a router), you can probably use that information to break into client machines and trusted machines as well. For example, you might not know a user's password, but sniffing a Telnet session when they log in will give you that password.</font> <p><font face="MS Sans Serif" size="3"><b>Remote sniffing:</b> A large number of boxes come with RMON enabled and public community strings. While the bandwidth is really low (you can't sniff all the traffic), it presents interesting possibilities.</font></p> <dt>  <h3><a name="1.4.5"><font face="MS Sans Serif" size="3">1.4.5 Design flaws</font></a></h3> <dd><font face="MS Sans Serif" size="3">Even if a software implementation is completely correct according to the design, there still may be bugs in the design itself that leads to intrusions.</font> <p><font face="MS Sans Serif" size="3"><b>TCP/IP protocol flaws:</b> The TCP/IP protocool was designed before we had much experience with the wide-scale hacking we see today. As a result, there are a number of design flaws that lead to possible security problems. Some examples include smurf attacks, ICMP Unreachable disconnects, IP spoofing, and SYN floods. The biggest problem is that the IP protocol itself is very "trusting": hackers are free to forge and change IP data with impunity. IPsec (IP security) has been designed to overcome many of these flaws, but it is not yet widely used.</font> <p><font face="MS Sans Serif" size="3"><b>UNIX design flaws:</b> There are number of inherent flaws in the UNIX operating system that frequently lead to intrusions. The chief problem is the access control system, where only 'root' is granted administrative rights. As a result,</font></p> </dd> </dl> <dt>  <h2><a name="1.5"><font face="MS Sans Serif" size="3">1.5 How do intruders get passwords?</font></a></h2> <dd><font face="MS Sans Serif" size="3">Intruders get passwords in the following ways:</font> <p><font face="MS Sans Serif" size="3"><b>Clear-text sniffing:</b> A number of protocols (Telnet, FTP, HTTP Basic) use clear-text passwords, meaning that they are not encrypted as the go over the wire between the client and the server. A intruder with a protocol analyzer can watch the wire looking for such passwords. No further effort is needed; the intruder can start immediately using those passwords to log in.</font> <p><font face="MS Sans Serif" size="3"><b>Encrypted sniffing:</b> Most protocols, however, use some sort of encryption on the passwords. In these cases, the intruder will need to carry out a Dictionary or Brute Force attack on the password in order to attempt decryption. Note that you still don't know about the intruder's presence, as he/she has been completely passive and has not transmitted anything on the wire. Password cracking does not require anything to be sent on the wire as intruder's own machine is being used to authenticate your password.</font> <p><font face="MS Sans Serif" size="3"><b>Replay attack:</b> In some cases, intruders do not need to decrypt the password. They can use the encrypted form instead in order to login to systems. This usually requires reprogramming their client software in order to make use of the encrypted password.</font> <p><font face="MS Sans Serif" size="3"><b>Password file stealing:</b> The entire user database is usually stored in a single file on the disk. In UNIX, this file is <code>/etc/passwd</code> (or some mirror of that file), and under WinNT, this is the SAM file. Either way, once a intruder gets hold of this file, he/she can run cracking programs (described above) in order to find some weak passwords within the file.</font> <p><font face="MS Sans Serif" size="3"><b>Observation:</b> One of the traditional problems in password security is that passwords must be long and difficult to guess (in order to make Dictionary and Brute Force cracks unreasonably difficult). However, such passwords are often difficult to remember, so users write them down somewhere. Intruders can often search a persons work site in order to find passwords written on little pieces of paper (usually under the keyboard). Intruders can also train themselves to watch typed in passwords behind a user's back.</font> <p><font face="MS Sans Serif" size="3"><b>Social Engineering:</b> A common (successful) technique is to simply call the user and say "Hi, this is Bob from MIS. We're trying to track down some problems on the network and they appear to be coming from your machine. What password are you using?" Many users will give up their password in this situation. (Most corporations have a policy where they tell users to never give out their password, even to their own MIS departments, but this technique is still successful. One easy way around this is for MIS to call the new employee 6-months have being hired and ask for their password, then criticize them for giving it to them in a manner they will not forget :-)</font></p> <dt>  <h2><a name="1.6"><font face="MS Sans Serif" size="3">1.6 What is a typical intrusion scenario?</font></a></h2> <dd> <p><font face="MS Sans Serif" size="3">A typical scenario might be:</font> <p><font face="MS Sans Serif" size="3">Step 1: <b>outside reconnaissance</b> The intruder will find out as much as possible without actually giving themselves away. They will do this by finding public information or appearing as a normal user. In this stage, you really can't detect them. The intruder will do a 'whois' lookup to find as much information as possible about your network as registered along with your Domain Name (such as <code>foobar.com</code>. The intruder might walk through your DNS tables (using 'nslookup', 'dig', or other utilities to do domain transfers) to find the names of your machines. The intruder will browse other public information, such as your public web sites and anonymous FTP sites. The intruder might search news articles and press releases about your company.</font> <p><font face="MS Sans Serif" size="3">Step 2: <b>inside reconnaisance</b> The intruder uses more invasive techniques to scan for information, but still doesn't do anything harmful. They might walk through all your web pages and look for CGI scripts (CGI scripts are often easily hacked). They might do a 'ping' sweep in order to see which machines are alive. They might do a UDP/TCP scan/strobe on target machines in order to see what services are available. They'll run utilities like 'rcpinfo', 'showmount', 'snmpwalk', etc. in order to see what's available. At this point, the intruder has done 'normal' activity on the network and has not done anything that can be classified as an intrusion. At this point, a NIDS will be able to tell you that "somebody is checking door handles", but nobody has actually tried to open a door yet.</font> <p><font face="MS Sans Serif" size="3">Step 3: <b>exploit</b> The intruder crosses the line and starts exploiting possible holes in the target machines. The intruder may attempt to compromise a CGI script by sending shell commands in input fields. The intruder might attempt to exploit well-known buffer-overrun holes by sending large amounts of data. The intruder may start checking for login accounts with easily guessable (or empty) passwords. The hacker may go through several stages of exploits. For example, if the hacker was able to access a user account, they will now attempt further exploits in order to get root/admin access.</font> <p><font face="MS Sans Serif" size="3">Step 4: <b>foot hold</b> At this stage, the hacker has successfully gained a foot hold in your network by hacking into a machine. The intruder's main goal is to hide evidence of the attacks (doctoring the audit trail and log files) and make sure they can get back in again. They may install 'toolkits' that give them access, replace existing services with their own Trojan horses that have backdoor passwords, or create their own user accounts. System Integrity Verifiers (SIVs) can often detect an intruder at this point by noting the changed system files. The hacker will then use the system as a stepping stone to other systems, since most networks have fewer defences from inside attacks.</font> <p><font face="MS Sans Serif" size="3">Step 5: <b>profit</b> The intruder takes advantage of their status to steal confidential data, misuse system resources (i.e. stage attacks at other sites from your site), or deface web pages.</font> <p><font face="MS Sans Serif" size="3">Another scenario starts differently. Rather than attack a specific site, and intruder might simply scan random internet addresses looking for a specific hole. For example, an intruder may attempt to scan the entire Internet for machines that have the SendMail DEBUG hole. They simply exploit such machines that they find. They don't target you directly, and they really won't even know who you are. (This is known as a 'birthday attack'; given a list of well-known security holes and a list of IP addresses, there is a good chance that there exists some machine somewhere that has one of those holes).</font></p> <dt>  <h2><a name="1.7"><font face="MS Sans Serif" size="3">1.7 What are some common "intrusion signatures"?</font></a></h2> <dd><font face="MS Sans Serif" size="3">There are three types of attacks:</font> <p><font face="MS Sans Serif" size="3"><b>reconnaisance</b> These include ping sweeps, DNS zone transfers, email recons, TCP or UDP port scans, and possibly indexing of public web servers to find cgi holes.</font> <p><font face="MS Sans Serif" size="3"><b>exploits</b> Intruders will take advantage of hidden features or bugs to gain access to the system.</font> <p><font face="MS Sans Serif" size="3"><b>denial-of-service (DoS) attacks</b> Where the intruder attempts to crash a service (or the machine), overload network links, overloaded the CPU, or fill up the disk. The intruder is not trying to gain information, but to simply act as a vandal to prevent you from making use of your machine.</font></p> <dt>  <h2><a name="1.8"><font face="MS Sans Serif" size="3">1.8 What are some common exploits?</font></a></h2> <dd> <dl> <dt>  <h3><a name="1.8.1"><font face="MS Sans Serif" size="3">1.8.1 CGI scripts</font></a></h3> <dd><font face="MS Sans Serif" size="3">CGI programs are notoriously insecure. Typical security holes include passing tainted input directly to the command shell via the use of shell metacharacters, using hidden variables specifying any filename on the system, and otherwise revealing more about the system than is good. The most well-known CGI bug is the 'phf' library shipped with NCSA httpd. The 'phf' library is supposed to allow server-parsed HTML, but can be exploited to give back any file. Other well-known CGI scripts that an intruder might attempt to exploit are: TextCounter, GuestBook, EWS, info2www, Count.cgi, handler, webdist.cgi, php.cgi, files.pl, nph-test-cgi, nph-publish, AnyForm, FormMail. If you see somebody trying to access one or all of these CGI scripts (and you don't use them), then it is clear indication of an intrusion attempt (assuming you don't have a version installed that you actually want to use).</font> <dt>  <h3><a name="1.8.2"><font face="MS Sans Serif" size="3">1.8.2 Web server attacks</font></a></h3> <dd><font face="MS Sans Serif" size="3">Beyond the execution of CGI programs, web servers have other possible holes. A large number of self-written web servers (include IIS 1.0 and NetWare 2.x) have hole whereby a file name can include a series of "../" in the path name to move elsewhere in the file system, getting any file. Another common bug is buffer overflow in the request field or in one of the other HTTP fields.</font> <p><font face="MS Sans Serif" size="3">Web server often have bugs related to their interaction with the underlying <b>operating system</b>. An old hole in Microsoft IIS have been dealing with the fact that files have two names, a long filename and a short 8.3 hashed equivalent that could sometimes be accessed bypassing permissions. NTFS (the new file system) has a feature called "alternate data streams" that is similar to the Macintosh data and resource forks. You could access the file through its stream name by appending "::$DATA" in order to see a script rather than run it.</font> <p><font face="MS Sans Serif" size="3">Servers have long had problems with <b>URLs</b>. For example, the "death by a thousand slashes" problem in older Apache would cause huge CPU loads as it tried to process each directory in a thousand slash URL.</font></p> <dt>  <h3><a name="1.8.3"><font face="MS Sans Serif" size="3">1.8.3 Web browser attacks</font></a></h3> <dd><font face="MS Sans Serif" size="3">It seems that all of Microsoft's and Netscape's web browsers have security holes (though, of course, the latest ones never have any that we know about -- yet). This includes both URL, HTTP, HTML, JavaScript, Frames, Java, and ActiveX attacks.</font> <p><font face="MS Sans Serif" size="3"><b>URL</b> fields can cause a buffer overflow condition, either as it is parsed in the HTTP header, as it is displayed on the screen, or processed in some form (such as saved in the cache history). Also, an old bug with Internet Explorer allowed interaction with a bug whereby the browser would execute .LNK or .URL commands.</font> <p><font face="MS Sans Serif" size="3"><b>HTTP</b> headers can be used to exploit bugs because some fields are passed to functions that expect only certain information.</font> <p><font face="MS Sans Serif" size="3"><b>HTML</b> can be often exploited, such as the MIME-type overflow in Netscape Communicator's <EMBED> command.</font> <p><font face="MS Sans Serif" size="3"><b>JavaScript</b> is a perennial favorite, and usually tries to exploit the "file upload" function by generating a filename and automatically hidden the "SUBMIT" button. There have been many variations of this bug fixed, then new ways found to circumvent the fixes.</font> <p><font face="MS Sans Serif" size="3"><b>Frames</b> are often used as part of a JavaScript or Java hack (for example, hiding web-pages in 1px by 1px sized screens), but they present special problems. For example, I can include a link to a trustworthy site that uses frames, then replace some of those frames with web pages from my own site, and they will appear to you to be part of that remote site.</font> <p><font face="MS Sans Serif" size="3"><b>Java</b> has a robust security model, but that model has proven to have the occasional bug (though compared to everything else, it has proven to be one of the most secure elements of the whole system). Moreover, its robust security may be its undoing: Normal Java applets have no access to the local system, but sometimes they would be more useful if they did have local access. Thus, the implementation of "trust" models that can more easily be hacked.</font> <p><font face="MS Sans Serif" size="3"><b>ActiveX</b> is even more dangerous than Java as it works purely from a trust model and runs native code. You can even inadvertently catch a virus that was accidentally imbedded in some vendor's code.</font></p> <dt>  <h3><a name="1.8.4"><font face="MS Sans Serif" size="3">1.8.4 SMTP (SendMail) attacks</font></a></h3> <dd><font face="MS Sans Serif" size="3">SendMail is an extremely complicated and widely used program, and as a consequence, has been the frequent source of security holes. In the old days (of the '88 Morris Worm), hackers would take advantage of a hole in the DEBUG command or the hidden WIZ feature to break into SMTP. These days, they often try buffer overruns. SMTP also can be exploited in reconnaissance attacks, such as using the VRFY command to find user names.</font> <dt>  <h3><a name="1.8.5"><font face="MS Sans Serif" size="3">1.8.5 Access</font></a></h3> <dd><font face="MS Sans Serif" size="3">Failed login attempts, failed file access attempts, password cracking, administrative powers abuse</font> <dt>  <h3><a name="1.8.6"><font face="MS Sans Serif" size="3">1.8.6 IMAP</font></a></h3> <dd><font face="MS Sans Serif" size="3">Users retrieve email from servers via the IMAP protocol (in contrast, SMTP transfers email between servers). Hackers have found a number of bugs in several popular IMAP servers.</font> <dt>  <h3><a name="1.8.7"><font face="MS Sans Serif" size="3">1.8.7 IP spoofing</font></a></h3> <dd><font face="MS Sans Serif" size="3">There is a range of attacks that take advantage of the ability to forge (or 'spoof') your IP address. While a source address is sent along with every IP packet, it isn't actually used for routing. This means an intruder can pretend to be you when talking to a server. The intruder never sees the response packets (although your machine does, but throws them away because they don't match any requests you've sent). The intruder won't get data back this way, but can still send commands to the server pretending to be you.</font> <p><font face="MS Sans Serif" size="3">IP spoofing is frequently used as part of other attacks:</font> <dl> <dt><b><font face="MS Sans Serif" size="3">SMURF</font></b> <dd><font face="MS Sans Serif" size="3">Where the source address of a broadcast ping is forged so that a huge number of machines respond back to victim indicated by the address, overloading it (or its link).</font> <dt><b><font face="MS Sans Serif" size="3">TCP sequence number prediction</font></b> <dd><font face="MS Sans Serif" size="3">In the startup of a TCP connection, you must choose a sequence number for your end, and the server must choose a sequence number for its end. Older TCP stacks choose predictable sequence numbers, allowing intruders to create TCP connections from a forged IP address (for which they will never see the response packets) that presumably will bypass security.</font> <dt><b><a name="DNSsequencespoof"><font face="MS Sans Serif" size="3">DNS poisoning through sequence prediction</font></a></b> <dd><font face="MS Sans Serif" size="3">DNS servers will "recursively" resolve DNS names. Thus, the DNS server that satisfies a client request will become itself a client to the next server in the recursive chain. The sequence numbers it uses are predictable. Thus, an intruder can send a request to the DNS server and a response to the server forged to be from the next server in the chain. It will then believe the forged response, and use that to satisfy other clients.</font></dd> </dl> <dt>  <h3><a name="1.8.8"><font face="MS Sans Serif" size="3">1.8.8 Buffer Overflows</font></a></h3> <dd><font face="MS Sans Serif" size="3">Some other buffer overflow attacks are:</font> <dl> <dt><b><a name="DNSoverflow"><font face="MS Sans Serif" size="3">DNS overflow</font></a></b> <dd><font face="MS Sans Serif" size="3">Where an overly long DNS name is sent to a server. DNS names are limited to 64-bytes per subcomponent and 256-bytes overall.</font> <dt><b><font face="MS Sans Serif" size="3">statd overflow</font></b> <dd><font face="MS Sans Serif" size="3">where an overly long filename is provided</font></dd> </dl> <dt>  <h3><a name="1.8.9"><font face="MS Sans Serif" size="3">1.8.9 DNS attacks</font></a></h3> <dd><font face="MS Sans Serif" size="3">DNS is a prime target because if you can corrupt the DNS server, you can take advantage of trust relationships.</font> <dl> <dt><b><font face="MS Sans Serif" size="3">DNS cache poisoning</font></b> <dd><font face="MS Sans Serif" size="3">Every DNS packet contains a "Question" section and "Answer" section. Vulnerable servers will believe (and cache) Answers that you send along with Questions. Most, but not all, DNS servers have been patched as of November, 1998.</font> <dt><b><font face="MS Sans Serif" size="3">DNS poisoning through sequence prediction</font></b> <dd><font face="MS Sans Serif" size="3">See <a href="#DNSsequencespoof">above</a></font> <dt><b><font face="MS Sans Serif" size="3">DNS overflow</font></b> <dd><font face="MS Sans Serif" size="3">See <a href="#DNSoverflow">above</a></font></dd> </dl> </dd> </dl> <dt>  <h2><a name="1.9"><font face="MS Sans Serif" size="3">1.9 What are some common reconnaisance scans?</font></a></h2> <dd> <dl> <dt>  <h3><a name="1.9.1"><font face="MS Sans Serif" size="3">1.9.1 Ping sweeps</font></a></h3> <dd><font face="MS Sans Serif" size="3">This simple scan simply pings a range of IP addresses to find which machines are alive. Note that more sophisticated scanners will use other protocols (such as an SNMP sweep) to do the same thing.</font> <dt>  <h3><a name="1.9.2"><font face="MS Sans Serif" size="3">1.9.2 TCP scans</font></a></h3> <dd><font face="MS Sans Serif" size="3">Probes for open (listening) TCP ports looking for services the intruder can exploit. Scans can use normal TCP connections or stealth scans that use half-open connections (to prevent them from being logged) or FIN scans (never opens a port, but tests if someone's listening). Scans can be either sequential, randomized, or configured lists of ports.</font> <dt>  <h3><a name="1.9.3"><font face="MS Sans Serif" size="3">1.9.3 UDP scans</font></a></h3> <dd><font face="MS Sans Serif" size="3">These scans are a little bit more difficult because UDP is a connectionless protocol. The technique is to send a garbage UDP packet to the desired port. Most machines will respond with an ICMP "destination port unreachable" message, indicating that no service is listening at that port. However, many machines throttle ICMP messages, so you can't do this very fast.</font> <dt>  <h3><a name="1.9.4"><font face="MS Sans Serif" size="3">1.9.4 OS identification</font></a></h3> <dd><font face="MS Sans Serif" size="3">By sending illegal (or strange) ICMP or TCP packets, an intruder can identify the operating system. Standards usually state how machines should respond to legal packets, so machines tend to be uniform in their response to valid input. However, standards omit (usually intentionally) the response to invalid input. Thus, each operating system's unique responses to invalid inputs forms a signature that hackers can use to figure out what the target machine is. This type of activity occurs at a low level (like stealth TCP scans) that systems do not log.</font> <dt>  <h3><a name="1.9.5"><font face="MS Sans Serif" size="3">1.9.5 Account scans</font></a></h3> <dd><font face="MS Sans Serif" size="3">Tries to log on with accounts</font> <ul> <li><font face="MS Sans Serif" size="3">Accounts with no passwords</font> <li><font face="MS Sans Serif" size="3">Accounts with password same as username, or "password".</font> <li><font face="MS Sans Serif" size="3">Default accounts that were shipped with the product (a common problem on SGI, done to make setup easier)</font> <li><font face="MS Sans Serif" size="3">Accounts installed with software products (common on Microsoft as well as Unix, caused by products that run under their own special user account).</font> <li><font face="MS Sans Serif" size="3">Anonymous FTP problems (CWD ~root)</font> <li><font face="MS Sans Serif" size="3">Scan for rlogin/rsh/rexec ports, that may supported trusted logins.</font></li> </ul> </dd> </dl> <dt>  <h2><a name="1.10"><font face="MS Sans Serif" size="3">1.10 What are some common DoS (Denial of Service) attacks?</font></a></h2> <dd> <dl> <dt>  <h3><a name="1.10.1"><font face="MS Sans Serif" size="3">1.10.1 Ping-of-Death</font></a></h3> <dd><font face="MS Sans Serif" size="3">Sends an invalid fragment, which starts before the end of packet, but extends past the end of the packet.</font> <dt>  <h3><a name="1.10.2"><font face="MS Sans Serif" size="3">1.10.2 SYN Flood</font></a></h3> <dd><font face="MS Sans Serif" size="3">Sends TCP SYN packet (which start connections) very fast, leaving the victim waiting to complete a huge number of connections, causing it to run out of resources and dropping legitimate connections. A new defence against this are "SYN cookies". Each side of a connection has its own sequence-number. In response to a SYN, the attacked machine creates a special sequence number that is a "cookie" of the connection then forgets everything it knows about the connection. It can then recreate the forgotten information about the connection when the next packets come in from a legitimate connection.</font> <dt>  <h3><a name="1.10.3"><font face="MS Sans Serif" size="3">1.10.3 Land/Latierra</font></a></h3> <dd><font face="MS Sans Serif" size="3">Sends forged SYN packet with identical source/destination address/port so that system goes into infinite loop trying to complete the TCP connection.</font> <dt>  <h3><a name="1.10.4"><font face="MS Sans Serif" size="3">1.10.4 WinNuke</font></a></h3> <dd><font face="MS Sans Serif" size="3">Sends OOB/URG data on a TCP connection to port 139 (NetBIOS Session/SMB), which cause the Windows system to hang.</font></dd> </dl> <dt>  <h2><a name="1.11"><font face="MS Sans Serif" size="3">1.11 How much danger from intrusions is there?</font></a></h2> <dd><font face="MS Sans Serif" size="3">I frequently hear from people the statement "There's nothing on the system that anybody would want anyway". I walk them through various scenarios, such as simple ones if they've ever paid for anything on-line with a credit card or if they have any financial records or social security number on their personal machine.</font> <p><font face="MS Sans Serif" size="3">More importantly, there is the issue of legal liability. You are potentially liable for damages caused by a hacker using your machine. You must be able to prove to a court that you took "reasonable" measures to defend yourself from hackers. For example, consider if you put a machine on a fast link (cable modem or DSL) and left administrator/root accounts open with no password. Then if a hacker breaks into that machine, then uses that machine to break into a bank, you may be held liable because you did not take the most obvious measures in securing the machine.</font> <p><font face="MS Sans Serif" size="3">There is a good paper <i><a target="_blank" href="http://www.cert.org/research/JHThesis/Start.html">http://www.cert.org/research/JHThesis/Start.html</a></i> by John D. Howard that discusses how much hacking goes on over the Internet, and how much danger you are in.</font></p> <dt>  <h2><a name="1.12"><font face="MS Sans Serif" size="3">1.12 Where can I find current statistics about intrusions?</font></a></h2> <dd> <dl> <dt><font face="MS Sans Serif" size="3">CyberNotes by NIPC (<a href="http://www.fbi.gov/nipc/welcom.htm">http://www.fbi.gov/nipc/welcome.htm</a>)</font> <dd><font face="MS Sans Serif" size="3">CyberNotes is published every two weeks by the National Infrastructure Protection Center (NIPC). Its mission is to support security and information system professionals with timely information on cyber vulnerabilities, hacker exploit scripts, hacker trends, virus information, and other critical infrastructure-related best practices.</font> <p><font face="MS Sans Serif" size="3">The NIPC was set up by the FBI in mid 1998, and its first major activity was to help track down the source of the Melissa virus (W97M.Melissa). The CyberNotes archive goes back to January 1999.</font></p> <dt><font face="MS Sans Serif" size="3">AusCERT Consolidated Statistics Project (<a href="http://www.auscert.org.au/Information/acsp/index.html">http://www.auscert.org.au/Information/acsp/index.html</a>)</font> <dd><font face="MS Sans Serif" size="3">A project to collect intrusion statistics from around the web and consolidate them. They want people to join and send them info.</font> <dt><font face="MS Sans Serif" size="3">An Analysis Of Security Incidents On The Internet 1989 - 1995 (<a href="http://www.cert.org/research/JHThesis/Start.html">http://www.cert.org/research/JHThesis/Start.html</a>)</font> <dd><font face="MS Sans Serif" size="3">A dissertation by John D. Howard, Carnegie Mellon University</font> <dt><font face="MS Sans Serif" size="3">CERT Reports, Articles, and Presentations (<a href="http://www.cert.org/nav/reports.html">http://www.cert.org/nav/reports.html</a>)</font> <dd><font face="MS Sans Serif" size="3">CERT has a number of historical statistics on intrusions, but they aren't nearly as up-to-date as the NIPC.</font> <dt><font face="MS Sans Serif" size="3">1999 CSI-DBI Survey (<a href="http://www.gocsi.com/summary.htm">http://www.gocsi.com/summary.htm</a>) or (<a href="http://www.gocsi.com/prelea990301.htm">http://www.gocsi.com/prelea990301.htm</a></font> <dd><font face="MS Sans Serif" size="3">CSI (Computer Security Institute) does a number of surveys about intrusions and security</font></dd> </dl> <dt>  <h1><a name="2."><font face="MS Sans Serif" size="3">2. Architecture</font></a></h1> <dd>  <dt>  <h2><a name="2.1"><font face="MS Sans Serif" size="3">2.1 How are intrusions detected?</font></a></h2> <dd> <dl> <dt><b><font face="MS Sans Serif" size="3">2.1.1 Anomaly detection</font></b> <dd><font face="MS Sans Serif" size="3">The most common way people approach network intrusion detection is to detect statistical anomalies. The idea behind this approach is to measure a "baseline" of such stats as CPU utilization, disk activity, user logins, file activity, and so forth. Then, the system can trigger when there is a deviation from this baseline.</font> <p><font face="MS Sans Serif" size="3">The benefit of this approach is that it can detect the anomalies without having to understand the underlying cause behind the anomalies.</font> <p><font face="MS Sans Serif" size="3">For example, let's say that you monitor the traffic from individual workstations. Then, the system notes that at 2am, a lot of these workstations start logging into the servers and carrying out tasks. This is something interesting to note and possibly take action on.</font></p> <dt><b><font face="MS Sans Serif" size="3">2.1.2 Signature recognition</font></b> <dd><font face="MS Sans Serif" size="3">The majority of commercial products are based upon examining the traffic looking for well-known patterns of attack. This means that for every hacker technique, the engineers code something into the system for that technique.</font> <p><font face="MS Sans Serif" size="3">This can be as simple as a pattern match. The classic example is to example every packet on the wire for the pattern "/cgi-bin/phf?", which might indicate somebody attempting to access this vulnerable CGI script on a web-server. Some IDS systems are built from large databases that contain hundreds (or thousands) of such strings. They just plug into the wire and trigger on every packet they see that contains one of these strings.</font></p> </dd> </dl> <dt>  <h2><a name="2.2"><font face="MS Sans Serif" size="3">2.2 How does a NIDS match signatures with incoming traffic?</font></a></h2> <dd> <p><font face="MS Sans Serif" size="3">Traffic consists of IP datagrams flowing across a network. A NIDS is able to capture those packets as they flow by on the wire. A NIDS consists of a special TCP/IP stack that reassembles IP datagrams and TCP streams. It then applies some of the following techniques:</font> <p><font face="MS Sans Serif" size="3"><b>Protocol stack verification</b> A number of intrusions, such as "Ping-O-Death" and "TCP Stealth Scanning" use violations of the underlying IP, TCP, UDP, and ICMP protocols in order to attack the machine. A simple verification system can flag invalid packets. This can include valid, by suspicious, behavior such as severally fragmented IP packets.</font> <p><font face="MS Sans Serif" size="3"><b>Application protocol verification</b> A number of intrusions use invalid protocol behavior, such as "WinNuke", which uses invalid NetBIOS protocol (adding OOB data) or DNS cache poisoning, which has a valid, but unusually signature. In order to effectively detect these intrusions, a NIDS must re-implement a wide variety of application-layer protocols in order to detect suspicious or invalid behavior.</font> <p><font face="MS Sans Serif" size="3"><b>Creating new loggable events</b> A NIDS can be used to extend the auditing capabilities of your network management software. For example, a NIDS can simply log all the application layer protocols used on a machine. Downstream event log systems (WinNT Event, UNIX syslog, SNMP TRAPS, etc.) can then correlate these extended events with other events on the network.</font></p> <dt>  <h2><a name="2.4"><font face="MS Sans Serif" size="3">2.4 What happens after a NIDS detects an attack?</font></a></h2> <dd> <dl> <dt><b><font face="MS Sans Serif" size="3">Reconfigure firewall</font></b> <dd><font face="MS Sans Serif" size="3">Configure the firewall to filter out the IP address of the intruder. However, this still allows the intruder to attack from other addresses. Checkpoint firewall's support a "Suspicious Activity Monitoring Protocol (SAMP)" for configuring firewalls. Checkpoint has their "OPSEC" standard for re-configuring firewalls to block the offending IP address.</font> <dt><b><font face="MS Sans Serif" size="3">chime</font></b> <dd><font face="MS Sans Serif" size="3">Beep or play a .WAV file. For example, you might hear a recording "You are under attack".</font> <dt><b><font face="MS Sans Serif" size="3">SNMP Trap</font></b> <dd><font face="MS Sans Serif" size="3">Send an SNMP Trap datagram to a management console like HP OpenView, Tivoli, Cabletron Spectrum, etc.</font> <dt><b><font face="MS Sans Serif" size="3">NT Event</font></b> <dd><font face="MS Sans Serif" size="3">Send an event to the WinNT event log.</font> <dt><b><font face="MS Sans Serif" size="3">syslog</font></b> <dd><font face="MS Sans Serif" size="3">Send an event to the UNIX syslog event system.</font> <dt><b><font face="MS Sans Serif" size="3">send email</font></b> <dd><font face="MS Sans Serif" size="3">Send email to an administrator to notify of the attack.</font> <dt><b><font face="MS Sans Serif" size="3">page</font></b> <dd><font face="MS Sans Serif" size="3">Page (using normal pagers) the system administrator.</font> <dt><b><font face="MS Sans Serif" size="3">Log the attack</font></b> <dd><font face="MS Sans Serif" size="3">Save the attack information (timestamp, intruder IP address, victim IP address/port, protocol information).</font> <dt><b><font face="MS Sans Serif" size="3">Save evidence</font></b> <dd><font face="MS Sans Serif" size="3">Save a tracefile of the raw packets for later analysis.</font> <dt><b><font face="MS Sans Serif" size="3">Launch program</font></b> <dd><font face="MS Sans Serif" size="3">Launch a separate programme to handle the event.</font> <dt><b><font face="MS Sans Serif" size="3">Terminate the TCP session</font></b> <dd><font face="MS Sans Serif" size="3">Forge a TCP FIN packet to force a connection to terminate.</font></dd> </dl> <dt>  <h2><a name="2.5"><font face="MS Sans Serif" size="3">2.5 What other countermeasures besides IDS are there?</font></a></h2> <dd> <dl> <dt><b><font face="MS Sans Serif" size="3">Firewalls</font></b> <dd><font face="MS Sans Serif" size="3">Most people think of the firewall as their first line of defence. This means if intruders figure out how to bypass it (easy, especially since most intrusions are committed by employees inside the firewall), they will have free run of the network. A better approach is to think of it as the <i>last</i> line of defence: you should be pretty sure machines are configured right and intrusion detection is operating, and then place the firewall up just to avoid the wannabe script-kiddies. Note that almost any router these days can be configured with some firewall filtering. While firewalls protect external access, they leave the network unprotected from internal intrusions. It has been estimated that 80% of losses due to "hackers" have been internal attacks.</font> <dt><b><font face="MS Sans Serif" size="3">authentication</font></b> <dd><font face="MS Sans Serif" size="3">You should run scanners that automated the finding of open accounts. You should enforce automatically strict policies for passwords (7 character minimum, including numbers, dual-case, and punctuation) using crack or built in policy checkers (WinNT native, add-on for UNIX). You can also consider single-sign on products and integrating as many password systems as you can, such as RADIUS/TACACS integration with UNIX or NT (for dial-up style login), integrating UNIX <i>and</i> WinNT authentication (with existing tools are the new Kerberos in Windows 2000). These authentication systems will help you also remove "clear-text" passwords from protocols such as Telnet, FTP, IMAP, POP, etc.</font> <dt><b><font face="MS Sans Serif" size="3">VPNs (Virtual Private Networks)</font></b> <dd><font face="MS Sans Serif" size="3">VPNs create a secure connection over the Internet for remote access (e.g. for telecomuters). Example #1: Microsoft includes a a technology called PPTP (PPP over TCP) built into Windows. This gives a machine two IP addresses, one on the Internet, and a virtual one on the corporate network. Example #2: IPsec enhances the traditional IP protocol with security. While VPN vendors claim their product "enhance security", the reality is that they decrease corporate security. While the pipe itself is secure (authenticated, encrypted), either ends of the pipe are wide open. A home machine compromised with a backdoor rootkit allows a hacker to subvert the VPN connection, allow full, undetectable access to the other side of the firewall.</font> <dt><b><font face="MS Sans Serif" size="3">encryption</font></b> <dd><font face="MS Sans Serif" size="3">Encryption is becoming increasingly popular. You have your choice of email encryption (PGP, SMIME), file encryption (PGP again), or file system encryption (BestCrypt, PGP again).</font> <dt><b><font face="MS Sans Serif" size="3">lures/honeypots</font></b> <dd><font face="MS Sans Serif" size="3">Programs that pretend to be a service, but which do not advertise themselves. It can be something as simple as one of the many BackOrifice emulators (such as NFR's Back Officer Friendly), or as complex as an entire subnet of bogus systems installed for that purpose.</font></dd> </dl> <dt>  <h2><a name="2.6"><font face="MS Sans Serif" size="3">2.6 Where do I put IDS systems on my network?</font></a></h2> <dd> <dl> <dt><b><font face="MS Sans Serif" size="3">network hosts</font></b> <dd><font face="MS Sans Serif" size="3">Even though network intrusion detection systems have traditionally been used as probes, they can also be placed on hosts (in non-promiscuous mode). Take for example a switched network where an employee is on the same switch as the CEO, who runs Win98. The windows machine is completely defenceless, and has no logging capabilities that could be fed to a traditional host-based intrusion detection system. The employee could run a network-based password cracker for months without fear of being caught. A NIDS installed like virus scanning software is the most effective way to detect such intrusions.</font> <dt><b><font face="MS Sans Serif" size="3">network perimeter</font></b> <dd><font face="MS Sans Serif" size="3">IDS is most effective on the network perimeter, such as on both sides of the <b>firewall</b>, near the <b>dial-up</b> server, and on links to <b>partner</b> networks. These links tend to be low-bandwidth (T1 speeds) such that an IDS can keep up with the traffic.</font> <dt><b><font face="MS Sans Serif" size="3">WAN backbone</font></b> <dd><font face="MS Sans Serif" size="3">Another high-value point is the corporate WAN backbone. A frequent problem is hacking from "outlying" areas to the main corporate network. Since WAN links tend to be low bandwidth, IDS systems can keep up.</font> <dt><b><font face="MS Sans Serif" size="3">server farms</font></b> <dd><font face="MS Sans Serif" size="3">Serves are often placed on their own network, connected to switches. The problem these servers have, though, is that IDS systems cannot keep up with high-volume traffic. For extremely important servers, you may be able to install dedicate IDS systems that monitor just the individual server's link. Also, application servers tend to have lower traffic than file servers, so they are better targets for IDS systems.</font> <dt><b><font face="MS Sans Serif" size="3">LAN backbones</font></b> <dd><font face="MS Sans Serif" size="3">IDS systems are impractical for LAN backbones, because of their high traffic requirements. Some vendors are incorporating IDS detection into switches. A full IDS system that must reassemble packets is unlikely to keep up. A scaled-down system that detects simpler attacks but can keep up is likely to be a better choice.</font></dd> </dl> <dt>  <h2><a name="2.7"><font face="MS Sans Serif" size="3">2.7 How does IDS fit with the rest of my security framework?</font></a></h2> <dd> <ol> <li><font face="MS Sans Serif" size="3">Put firewalls between areas of the network with different security requirements (i.e. between internet-localnet, between users-servers, between company-parterns, etc).</font> <li><font face="MS Sans Serif" size="3">Use network vulnerability scanners to double check firewalls and to find holes that intruders can exploit.</font> <li><font face="MS Sans Serif" size="3">Use host policy scanners to make sure they conform to accepted practices (i.e. latest patches).</font> <li><font face="MS Sans Serif" size="3">Use <b>Network intrusion detection systems</b> and other packet sniffing utilities to see what is actually going on.</font> <li><font face="MS Sans Serif" size="3">Use <b>host-based intrusion detection systems</b> and virus scanners to flag successful intrusions.</font> <li><font face="MS Sans Serif" size="3">Create an easy to follow policy that clearly states the response to intrusions.</font></li> </ol> <dt>  <h2><a name="2.8"><font face="MS Sans Serif" size="3">2.8 How can I detect if someone is running a NIDS?</font></a></h2> <dd><font face="MS Sans Serif" size="3">A NIDS is essentially a sniffer, so therefore standard sniffer detection techniques can be used. Such techniques are explained in <a href="http://www.robertgraham.com/pubs/sniffing-faq.html#detect">http://www.robertgraham.com/pubs/sniffing-faq.html#detect</a>.</font> <p><font face="MS Sans Serif" size="3">An example would be to do a traceroute against the victim. This will often generate a low-level event in the IDS. Traceroutes are harmless and frequent on the net, so they don't indicate an attack. However, since many attacks are preceded by traceroutes, IDSs will log them anyway. As part of the logging system, it will usually do a reverse-DNS lookup. Therefore, if you run your own DNS server, then you can detect when somebody is doing a reverse-DNS lookup on your IP address in response to your traceroute.</font></p> <dt>  <h1><a name="3."><font face="MS Sans Serif" size="3">3. Policy</font></a></h1> <dd>  <dt>  <h2><a name="3.1"><font face="MS Sans Serif" size="3">3.1 How do I increase intrusion detection/prevention under WinNT?</font></a></h2> <dd><font face="MS Sans Serif" size="3">The following lists items that make WinNT more secure, including detection as well as prevention. These are roughly listed in order of importance.</font> <ol> <li><font face="MS Sans Serif" size="3">Install the latest service packs and "hot fixes". These are listed at <a href="http://www.microsoft.com/security/">http://www.microsoft.com/security/</a>. If you are using WinNT 4.0 and you don't have Service Pack #3 (SP3) installed, an intruder can break into your system.</font> <li><font face="MS Sans Serif" size="3">INSTALLATION: Use NTFS instead of FAT. NTFS allows permissions to be set on a per-file/per-directory basis. NTFS also allows auditing on a per-file/per-directory basis. Note that many people recommend using FAT as the boot drive and NTFS for all other drives (due to the ease-of-use in using DOS to fix things on a FAT drive). However, using NTFS for all drives is definitely more secure.</font> <li><font face="MS Sans Serif" size="3">USRMGR: Rename the "administrator" account. A common attack is to use a Dictionary or brute force attack on the "administrator" account. Normal accounts can be configured to automatically (and temporarily) "lock out" after a few failed password attempts. However, this feature isn't possible for the administrator account because this allows a denial of service attack (i.e. prevent administration of the machine by locking out the administrator account).</font> <li><font face="MS Sans Serif" size="3">USRMGR: Create a new account named "administrator" for detecting intrusion attempts.</font> <li><font face="MS Sans Serif" size="3">USRMGR: Disable the "guest" account. You may also want to rename this account as (much like "administrator"). Once you've renamed the "guest" account, you may want to create a new account named "guest" for detecting hacking attempts.</font> <li><font face="MS Sans Serif" size="3">NTFS: Disable "write" access for "Everyone" on the <code>%systemroot%/system32</code> directory.</font> <li><font face="MS Sans Serif" size="3">REGEDT32: Turn on auditing for "HKEY_LOCAL_MACHINE\Security" in order to detect remote registry browsing.</font> <li><font face="MS Sans Serif" size="3">INSTALLATION: Do not install in "C:\WINNT" directory. Sometimes intruders will be able to access files if they know the filename; installing in some other directory prevents a priori knowledge. Better yet, install in C:\WINNT, then reinstall in some other directory, then turn auditing on within that directory to alert you to people accessing those older files.</font> <li><font face="MS Sans Serif" size="3">INSTALLATION: Use the boot partition only for booting and for system files. Put data and applications on a separate partition. It is also a good idea to separate applications from data.</font> <li><font face="MS Sans Serif" size="3">CONTROLPANEL: Enable "Password Protected" on the screensaver. The best screensaver is "Blank Screen". You would think that screensavers run at idle priority, but this isn't always the case, so you can increase the performance of your server by using "Blank Screen". Also, this will reduce power consumption in monitors, especially those that can detect a blank screen and turn themselves off. Finally, some screensavers (i.e. PointCast) are probably hackable.</font> <li><font face="MS Sans Serif" size="3">REGEDT32: Turn off automatic sharing of ADMIN$, C$, D$, etc. via the "AutoShare" parameter in the registry. This parameter is under "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters", and is "AutoShareServer" for WinNT Server or "AutoShareWks" for WinNT Workstation. This is a DWORD, with a value of '1' for enabled (default), or a value of '0' for disabled. You will have to add the value yourself because it doesn't already exist in the registry.</font> <li><font face="MS Sans Serif" size="3">REGEDT32: Turn of account/share information via anonymous access. Add "RestrictAnonymous" DWORD with a value of "1" to the registry key "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA" Note that if you see an error "Could not find domain controller for this domain." while setting domain trust relationships, you may have to change it back.</font> <li><font face="MS Sans Serif" size="3">USRMGR: If you are using Domains (rather than Workgroups), change the user right "Access this computer from the network" to "Authenticated Users" rather than "Everyone". This disables remote access via local accounts on your machine, and allows only access through domain accounts.</font> <li><font face="MS Sans Serif" size="3">PASSPROP: Enable lockout of the "administrator" account for remote access. This enables the situation where the remote intruder fails to guess the correct password after three tries. After lock-out, the administrator can only log in locally at the system console. You can also disable remote administrator access completely in USRMGR by removing the right "Access this computer from the network" from "Administrators", but this disables all remote administration, which make administration too difficult in a large WinNT environment.</font></li> </ol> <p><font face="MS Sans Serif" size="3">Also consider physical intrusion prevention network wide. John Kozubik suggests using login scripts to force the built-in password protected screen-saver. In the login script, include the line like:</font> <pre><font face="MS Sans Serif" size="3"> regedit /s \\MY_PDC\netlogon\scrn.reg </font></pre> <font face="MS Sans Serif" size="3">And in the file "scrn.reg", put the text:</font> <pre><font face="MS Sans Serif" size="3"> REGEDIT4 [HKEY_CURRENT_USER\Control Panel\Desktop] "ScreenSaveTimeOut"="1800" "ScreenSaveActive"="1" "SCRNSAVE.EXE"="c:\winnt\system32\logon.scr" "ScreenSaverIsSecure"="1" </font></pre> <font face="MS Sans Serif" size="3">This will trigger the password prompt to appear 30-minutes after a user is away from the desktop (it doesn't log them out; just forces them to re-enter the password before they have access again).</font> <dt>  <h2><a name="3.2"><font face="MS Sans Serif" size="3">3.2 How do I increase intrusion detection/prevention under Win95/Win98?</font></a></h2> <dd><font face="MS Sans Serif" size="3">This section assumes you are a home user using Win95/Win98 to access the Internet. Win95/Win98 has no auditing or logging capabilities; you really should upgrade to WinNT if you are using the system for any serious purpose.</font> <p><font face="MS Sans Serif" size="3">The following are techniques for the typical user:</font> <ol> <li><font face="MS Sans Serif" size="3">Install the latest patches (of course).</font> <li><font face="MS Sans Serif" size="3">Turn off print sharing. When print sharing is turned on, the system creates a PRINTER$ share that allows remote systems to access printer drivers from the local system32 directory. Unfortunately, this allows remote systems to access non-driver files, such as the Win95 password file (combined with other Win95 bugs).</font> <li><font face="MS Sans Serif" size="3">Turn off file sharing. As a home user, you probably don't need it. If you must share files, make sure that you choose a strong password, and only turn it on for brief moments while you need to share the files, then turn it off again.</font> <li><font face="MS Sans Serif" size="3">(more forthcoming)</font></li> </ol> <p><font face="MS Sans Serif" size="3">John Kozubik suggests the following techniques for corporate users (who presumably run login scripts from the servers). Since Win95/Win98 is so vulnerable, they provide easy penetration to the rest of the corporate environment. Win95 caches passwords in easy-to-read formats, so you want to remove them.</font> <dl> <dt><code><font face="MS Sans Serif" size="3">del c:\windows\*.pwl</font></code> <dd><font face="MS Sans Serif" size="3">The password cache file will be the first one intruders look for. It has the same name as the user name, and poorly encrypts the cached passwords. Beware that this deletes dial-up passwords as well, so users that bring their notebooks into work and connect to the network will find their home dial-up passwords deleted.</font> <dt><font face="MS Sans Serif" size="3">Disable internal caching of passwords</font> <dd><font face="MS Sans Serif" size="3">Run:</font> <pre><font face="MS Sans Serif" size="3">REGEDIT /s \\MY_PDC\netlogon\nocache.reg</font></pre> <font face="MS Sans Serif" size="3">where "nocache.reg" consists of:</font> <pre><font face="MS Sans Serif" size="3"> REGEDIT4 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Network] "DisablePwdCaching"=dword:00000001 </font></pre> </dd> </dl> <dt>  <h2><a name="3.3"><font face="MS Sans Serif" size="3">3.3 How do I increase intrusion detection/prevention under UNIX?</font></a></h2> <dd> <ol> <li><font face="MS Sans Serif" size="3">Do not install more services than you need. I installed everything on my RedHat Linux distribution and the machine lights up like a Xmas tree when port scanned. I already know of a few holes on that (test) machine that I can use to break in.</font> <li><font face="MS Sans Serif" size="3">Use 'netstat' or a TCP/UDP scanner and '<tt>rpcinfo</tt>' to list all services on your machine. Again, make sure that everything you don't explicitly understand is turned off.</font> <li><font face="MS Sans Serif" size="3">(more forthcoming; frankly, I've been more of an WinNT admin lately so my skills are getting rusty)</font> <li><font face="MS Sans Serif" size="3">Read <a href="ftp://ftp.auscert.org.au/pub/auscert/papers/unix_security_checklist">ftp://ftp.auscert.org.au/pub/auscert/papers/unix_security_checklist</a>.</font></li> </ol> <font face="MS Sans Serif" size="3">Of course, you might want to consider upgrading the system. There are a large number of SunOS 4.x systems out there, for example, even though Sun stopped "officially" supporting it many years ago.</font> <dt>  <h2><a name="3.4"><font face="MS Sans Serif" size="3">3.4 How do I increase intrusion detection/prevention under Macintosh?</font></a></h2> <dd><font face="MS Sans Serif" size="3">Macintoshes are 'end-user' systems, and support few services that can be hacked. In comparison, Windows machines are more numerous, and UNIX machines have a lot more interesting (hackable) services running on them. Thus, Macintoshes are frequently not the target of intruders.</font> <p><font face="MS Sans Serif" size="3">Beyond that, I know of nothing in particular.</font></p> <dt>  <h2><a name="3.5"><font face="MS Sans Serif" size="3">3.5 How do I increase intrusion detection/prevention for the enterprise?</font></a></h2> <dd> <p><font face="MS Sans Serif" size="3">First and foremost, create a security policy. Let's say that you are watching the network late in the evening and you see an intrusion in-progress. What do you do? Do you let the intrusion progress and collect evidence? Do you pull the plug? If so, do you pull the plug on the firewall between the intra- and extra- net? Or do you take down the entire Internet connection (preventing users from getting to you web site)? Who has the authority to pull the plug?</font> <p><font face="MS Sans Serif" size="3">The priorities need to be set in place by the CEO of the corporation. Let's consider the scenario where you think you are being attacked, so you pull the plug. The users get up in arms, and complain. And, as it turns out, you were wrong, so your but gets fried. Even when blatant attacks are going on, few people pull the plug for fear of just such repercussions. Data theft is theoretical; ticked-off users are very real. Therefore, you need a policy from the very top that clearly states the importance of things and clearly lays out a procedure for what happens when an intrusion is suspected. [Author: does anybody have sample policies they can send me?]</font> <p><font face="MS Sans Serif" size="3">Once you have the priorities straight, you need to figure out the technology. That's described in the next section.</font></p> <dt>  <h2><a name="3.6"><font face="MS Sans Serif" size="3">3.6 How should I implement intrusion detection my enterprise?</font></a></h2> <dd><font face="MS Sans Serif" size="3">Think about how you can configure the following systems in order to detect intruders:</font> <ol> <li><font face="MS Sans Serif" size="3"><b>Operating Systems</b> such as WinNT and UNIX come with integrated logging/auditing features that can be used to monitor security critical resources. A section below discusses how to configure Windows and UNIX in order to enable intrusion detection.</font> <li><font face="MS Sans Serif" size="3"><b>Services</b>, such as web servers, email servers, and databases, include logging/auditing features as well. In addition, there are many tools that can be used to parse these files in order to discover intrusion signatures.</font> <li><font face="MS Sans Serif" size="3"><b>Network Intrusion Detection Systems</b> that watch network traffic in an attempt to discover intrusion attempts. A section below lists a number of these products.</font> <li><font face="MS Sans Serif" size="3"><b>Firewalls</b> usually have some network intrusion detection capabilities. After all, blocking intrusions is their primary purpose; it would be foolish not to detect intrusions as well.</font> <li><font face="MS Sans Serif" size="3"><b>Network management platforms</b> (such as OpenView) have tools to help network managers set alerts on suspicious activity. At minimum, all SNMP devices should send "Authentication Failure" traps and management consoles should alert administrators when these go off.</font></li> </ol> <dt>  <h2><a name="3.7"><font face="MS Sans Serif" size="3">3.7 What should I do when I've been hacked?</font></a></h2> <dd><font face="MS Sans Serif" size="3">Read CERT's intruder detection checklist at <a target="_blank" href="ftp://ftp.cert.org/pub/tech_tips/intruder_detection_checklist">ftp://ftp.cert.org/pub/tech_tips/intruder_detection_checklist</a>.</font> <p><font face="MS Sans Serif" size="3">For the most part, a good response requires that you've set up good defensive measures in the first place. These include:</font> <dl> <dt><font face="MS Sans Serif" size="3">incident response team</font> <dd><font face="MS Sans Serif" size="3">Set up an "incident response team". Identify those people who should be called whenever people suspect an intrusion in progress. The response team needs to be "inter-departmental", and include such people as:</font> <dl> <dt><font face="MS Sans Serif" size="3">upper management</font> <dd><font face="MS Sans Serif" size="3">Need to identify somebody with the authority to handle escalated issues. For example, if the company has an online trading service, you need to identify somebody with enough power to "pull the plug". Going off-line on such a service will have a major impact -- but would still be better than hackers trading away people's stocks.</font> <dt><font face="MS Sans Serif" size="3">HR (Human Resources)</font> <dd><font face="MS Sans Serif" size="3">Many attacks come from internal employees. This consists of both serious attacks (cracking into machines) as well as nuisance attacks, such as browsing inappropriate servers looking for files like customer lists that might be left open.</font> <dt><font face="MS Sans Serif" size="3">technical staff</font> <dd><font face="MS Sans Serif" size="3">Security is often separate from normal MIS activity. If security personel detects a compromised system, they need to know who in MIS they need to call.</font> <dt><font face="MS Sans Serif" size="3">outside members</font> <dd><font face="MS Sans Serif" size="3">Identify people outside the company that may be contacted. This might be a local ISP person (for example, helping against smurf attacks), the local police, or the FBI. These aren't necessarily "formal" team members. They might not know anything about this, or they might simply be a "role" (like support@localisp.net). But put their names on the list so that everyone knows who to call.</font> <dt><font face="MS Sans Serif" size="3">security team</font> <dd><font face="MS Sans Serif" size="3">Of course, the most important team members will be the security people themselves.</font></dd> </dl> <font face="MS Sans Serif" size="3">Note that not all "team members" need to be involved with every incident. For example, you only need to ping upper management on serious attacks. They may never be called upon, but they do need to be identified, and they do need to be prepared as to the types of decisions they will have to make.</font> <dt><font face="MS Sans Serif" size="3">response procedure</font> <dd><font face="MS Sans Serif" size="3">Figure out guidelines now for the response action. For example, you need to decide now what your priorities are between network uptime and intrusion: can you pull the network plug whenever you strongly suspect intrusion? Do you want to allow continued intrusion in order to gather evidence against the intruder? Decide now, and get the CEO's approval now, because you won't have time during the attack.</font> <dt><font face="MS Sans Serif" size="3">lines of communication</font> <dd><font face="MS Sans Serif" size="3">Figure out guidelines for communication. Do you propagate the information up the corporate food chain from your boss up to the CEO, or horizontally to other business units? Do you take part in incident reporting organizations such as FIRST (Forum of Incident Response and Security Teams) at <a target="_blank" href="http://www.first.org">http://www.first.org</a>? Do you inform the FBI or police? Do you notify partners (vendors/customers) that have a connection to your network (and who may be compromised, or from whom the attack originated)? Do you hide the intrusion from the press? Note that the FBI has a webpage for reporting crime at: <a href="http://www.usdoj.gov/criminal/cybercrime/reporting.htm">http://www.usdoj.gov/criminal/cybercrime/reporting.htm</a></font> <dt><font face="MS Sans Serif" size="3">logging procedures</font> <dd><font face="MS Sans Serif" size="3">Set up your logging/auditing/monitoring procedures now; one of the most common thoughts after an attack is how much they wished they had adequate logging in the first place in order to figure out what happened.</font> <dt><font face="MS Sans Serif" size="3">training/rehearsal</font> <dd><font face="MS Sans Serif" size="3">Get training on all these issues. Each person involved needs to understand the scope of what they need to do. Also carry out dry runs. Assume a massive hacker penetration into your network, and drill what happens. Most hacker penetrations succeed because companies practice at being unprepared for their attack.</font></dd> </dl> <font face="MS Sans Serif" size="3">Since computer networks are growing so fast, there are not enough trained people to handle intrusions. Likewise, networks grow in an ad hoc fashion, so logging/auditing is haphazard. These conditions lead to the state that people don't know what to do when they've been attacked, and their networks aren't robust enough to recover well from the attack.</font> <dt>  <h2><a name="3.8"><font face="MS Sans Serif" size="3">3.8 How should I respond when somebody tells me they've been hacked from my site?</font></a></h2> <dd><font face="MS Sans Serif" size="3">On the IDS mailing list, someone asked how they should respond to the following email:</font> <pre><font face="MS Sans Serif" size="3"> Below is a log showing a telnet connection from a machine within your domain. The machine it connected to does not offer this service publicly so this can only be assumed to be an IP space probe for vulnerable machines. We take this matter seriously, and hope that you will as well. Please take action on this issue as is appropriate and respond to this address with your actions. Nov 6 07:13:13 pbreton in.telnetd[31565]: refused connect from xx.xx.xx.xx </font></pre> <font face="MS Sans Serif" size="3">This log entry was likely generated by tcpwrappers, a facility that enhances logging and access control to services on UNIX. It shows an unauthorized attempt from your site to the specified machine. As claimed in the email message, it may be an automated sweep of some sort. The most popular protocols people sweep with are ICMP, FTP, SMTP, NNTP, and Telnet.</font> <p><font face="MS Sans Serif" size="3">In any case, this is evidence of a probe, not an attack. Furthermore, there is no other corroborating evidence. As pointed out by Greg Drew <gdrew at computer dot org> there could be a number of benign reasons:</font> <ul> <li><font face="MS Sans Serif" size="3">Somebody typed "telnet xx.xx.xx.xx" and mistyped the IP address.</font> <li><font face="MS Sans Serif" size="3">Somebody meant to type "telnet xx.xx.xx.xx 25" to connect to the STMP service in response to receiving spam from the site. The person might have forgotten the "25" or mistyped "23".</font> <li><font face="MS Sans Serif" size="3">Somebody might have actually done a more extensive scan on the target machines in response to spam. I've personally done light scans before (finger, rusers, etc.) to track down the source of spam.</font> <li><font face="MS Sans Serif" size="3">May have been an honest mistake (i.e. somebody used to have an account on that machine, but no longer does).</font></li> </ul> <font face="MS Sans Serif" size="3">But there are also some nefarious possibilities:</font> <ul> <li><font face="MS Sans Serif" size="3">Your site may have already been hacked, and the hacker is running scans from the compromised machine.</font> <li><font face="MS Sans Serif" size="3">One of your employees is using the machine to hack (I've worked at a company where this happened -- though since the company made protocol analyzers, it was kinda stupid and they were quickly detected).</font></li> </ul> <font face="MS Sans Serif" size="3"><vick at macdoon dot lerc dot nasa dot gov> pointed out another possibility: this might be a social engineering attack. The message asks (commands) you to contact them to describe what actions you have taken. If you do so, it will tell a lot about your network:</font> <ul> <li><font face="MS Sans Serif" size="3">The target is a legal IP address (though not so interesting).</font> <li><font face="MS Sans Serif" size="3">Your IP address (the above message was likely sent to "postmaster" or some such well-known address, but you will likely respond using your own address.</font> <li><font face="MS Sans Serif" size="3">Your readiness level: if you come back with a lame response (such as "we can't take action because we have no log files") then they know that your network is prime hacking territory.</font> <li><font face="MS Sans Serif" size="3">This may be "social engineering spam". The sender of the message may be a company looking to resell intrusion detection products.</font></li> </ul> <font face="MS Sans Serif" size="3">Like responding to spam, there is probably little good that can come about responding to this email message (unless you find evidence that some hacker has been using your network as a stepping stone). It probably would be a good idea to check you system logs for the data/time in question, and if you don't have logs, now might be a good time to turn logging on.</font> <p><font face="MS Sans Serif" size="3"><b>As it turns out, the incident was benign.</b> The target network had reconfigured itself, and the "unauthorized" user didn't know about it yet, and wasn't logging in correctly.</font></p> <dt>  <h2><a name="3.9"><font face="MS Sans Serif" size="3">3.9 How do I collect enough evidence about the hacker?</font></a></h2> <dd><font face="MS Sans Serif" size="3">An interesting field of IDS is collecting enough information about the incident to identify the hacker. This can be very hard because truely elite hackers will be bouncing their attacks from another compromised system. Hackers will also often employ IP address spoofing, which may appear as if attacks are coming from machines that aren't even turned on.</font> <p><font face="MS Sans Serif" size="3">As far as I can tell, the best technique is to collect as much information as you can. For example, I've put a packet sniffer capturing to tracefiles on our T-1 line saving to files on a 16-gigabyte disk (most any sniffing programme on most platforms can do this). You may not think it fun, but I enjoy perusing these files. It's amazing how many TCP/UDP scans and other probes I see on a regular basis.</font> <p><font face="MS Sans Serif" size="3">Likewise, you should make sure you have full auditing and logging enabled on any/all systems exposed to the Internet. These will help you figure out what happened when you were hacked.</font> <p> </p> <dt>  <h1><a name="4."><font face="MS Sans Serif" size="3">4. Products</font></a></h1> <dd><font face="MS Sans Serif" size="3">This section discusses the major network IDS products.</font> <dt>  <h2><a name="4.1"><font face="MS Sans Serif" size="3">4.1 What freeware/shareware intrusion detection systems are available?</font></a></h2> <dd><font face="MS Sans Serif" size="3">The most complete list on the net seams to be the <i>COAST Intrusion Detection System Resources page</i> at <a href="http://www.cs.purdue.edu/coast/ids">http://www.cs.purdue.edu/coast/ids</a>.</font> <p><font face="MS Sans Serif" size="3">See sections 4.4 and 4.5 below for a discussion of some freeware technologies.</font></p> <dt>  <h2><a name="4.2"><font face="MS Sans Serif" size="3">4.2 What commercial intrusion detection systems are available?</font></a></h2> <dd><font face="MS Sans Serif" size="3">Note: I've removed the table of info because it has gotten dangerously out-of-date</font> <p><font face="MS Sans Serif" size="3">Reviews can be found at:</font> <ul> <li><a href="http://www.nwc.com/1023/1023f19.html"><font face="MS Sans Serif" size="3">http://www.nwc.com/1023/1023f19.html</font></a></li> </ul> <p><font face="MS Sans Serif" size="3">Several of these have comments from the vendors themselves that they emailed me. Also note that this information can quickly become out of date. The industry has gone through several major changes since I started this document.</font> <p><font face="MS Sans Serif" size="3">The site <a href="http://www.internations.net/uk/talisker/">http://www.internations.net/uk/talisker/</a> has done a good job of wading through the marketing hype and pulling out the salient points about each of the commercial products.</font> <dl> <dt>  <h3><a name="4.2.0"><font face="MS Sans Serif" size="3">4.2.0 BlackICE by Network ICE</font></a></h3> <dd><font face="MS Sans Serif" size="3">Vendor comments:</font> <blockquote> <font face="MS Sans Serif" size="3">BlackICE has multiple versions. The core is built around "BlackICE Sentry", a full network-based intrusion detection system. There are also host/hybrid versions that run on Windows desktops with a built-in personal firewall.</font> <p><font face="MS Sans Serif" size="3">The list of intrusions it detects is at: <a href="http://www.networkice.com/advICE/Intrusions">http://www.networkice.com/advICE/Intrusions</a></font> <p><font face="MS Sans Serif" size="3">Distinguishing features of BlackICE Sentry are:</font> <ul> <li><font face="MS Sans Serif" size="3">Full 7-layer, stateful, protocol analysis</font> <li><font face="MS Sans Serif" size="3">Anti-evasion techniques (handles fragmentation, whisker scans, a whole suite of signature changing attacks)</font> <li><font face="MS Sans Serif" size="3">Extremely fast, easily handles full 100-mbps bandwidth.</font></li> </ul> <p><font face="MS Sans Serif" size="3">Goto <a href="http://www.networkice.com">http://www.networkice.com</a> for more information.</font></p> </blockquote> <dt>  <h3><a name="4.2.1"><font face="MS Sans Serif" size="3">4.2.1 CyberCop Monitor by Network Associates, Inc.</font></a></h3> <dd><font face="MS Sans Serif" size="3">Vendor comments:</font> <blockquote> <font face="MS Sans Serif" size="3">CyberCop Monitor is a hybrid host/network based IDS that analyzes network traffic to and from the host as well as Windows NT EventLog audit trails and Windows NT authentication activity.</font> <p>  <ul> <li><font face="MS Sans Serif" size="3">Developed under the Microsoft Management Console user interface, both CyberCop Monitor and the SMI Console integrate to provide an easy to use graphical interface for local / remote reporting, and remote installation.</font> <li><font face="MS Sans Serif" size="3">Configuration editor allows for custom settings and thresholds to suit every environment, including security profiles, account groups, time and subnets.</font> <li><font face="MS Sans Serif" size="3">Extensive filtering using ordered filter rules for each signature.</font> <li><font face="MS Sans Serif" size="3">Report coalescing feature suppresses denial of service on the IDS itself.</font> <li><font face="MS Sans Serif" size="3">Report collating of monitoring and scanning information per system with trend analysis options, including 3D charting and graphing from an SQL database.</font></li> </ul> <p><font face="MS Sans Serif" size="3">Goto <<a href="http://www.nai.com">http://www.nai.com</a>> for more information.</font> <p><font face="MS Sans Serif" size="3">CyberCop Monitor was written from the ground up by NAI. There is NO connection with the CyberCop Network v.1.0 product developed by Network General/WheelGroup or the Haystack product from TIS - This was aging technology and shelved some months after each subsequent acquisition.</font></p> </blockquote> <dt>  <h3><a name="4.2.2"><font face="MS Sans Serif" size="3">4.2.2 RealSecure by Internet Security Systems (ISS), Inc.</font></a></h3> <dd><font face="MS Sans Serif" size="3">Vendor comments:</font> <blockquote> <font face="MS Sans Serif" size="3">Internet Security Systems is the first and only company that has tied both intrusion detection (ISS RealSecure) and vulnerability detection (ISS Internet Scanner) into an integrated security platform for organization to help plan, analyze, and manage their security on a continuous basis. ISS RealSecure is a component of ISS SAFEsuite family of products that cover managing security risk across the enterprise. ISS RealSecure is the market-leader in Intrusion Detection with an integrated host and network based solution. ISS RealSecure comes with over 400 attack signatures with the ability for customers in both the network and host based solution to add or modify their own signatures.</font> </blockquote> <dt>  <h3><a name="4.2.3"><font face="MS Sans Serif" size="3">4.2.3 NetRanger by WheelGroup/Cisco</font></a></h3> <dd><font face="MS Sans Serif" size="3">Originally by Wheelgroup, bought by Cisco. It has been recently renamed, though I'm not sure to what. Goto <a href="http://www.wheelgroup.com">http://www.wheelgroup.com</a>.</font> <dt>  <h3><font face="MS Sans Serif" size="3"><a name="4.2.4">4.2.4</a> eTrust Intrusion Detection by Computer Associates</font></h3> <dd><font face="MS Sans Serif" size="3">Formerly Memco/Abirnet/PLATINUM SessionWall, this is now owned by Computer Associates and marketed as <i>eTrust Intrusion Detection</i>.</font> <p><font face="MS Sans Serif" size="3">Goto <a href="http://www.cai.com/solutions/enterprise/etrust/intrusion_detection">http://www.cai.com/solutions/enterprise/etrust/intrusion_detection</a>.</font> <p><font face="MS Sans Serif" size="3">Originally, SessionWall started out as more of a firewall/content-inspection platform that interposed itself in the stream of traffic. I'm not sure where it is now.</font></p> <dt>  <h3><a name="4.2.6"><font face="MS Sans Serif" size="3">4.2.6 NetProwler by Axent</font></a></h3> <dd><font face="MS Sans Serif" size="3">Goto <a href="http://www.axent.com">http://www.axent.com</a>.</font> <dt>  <h3><a name="4.2.7"><font face="MS Sans Serif" size="3">4.2.7 Centrax by Cybersafe</font></a></h3> <dd><font face="MS Sans Serif" size="3">Goto <a href="http://www.cybersafe.com/solutions/centrax.html">http://www.cybersafe.com/solutions/centrax.html</a>.</font> <dt>  <h3><a name="4.2.9"><font face="MS Sans Serif" size="3">4.2.9 NFR by Network Flight Recorder</font></a></h3> <dd><font face="MS Sans Serif" size="3">Vendor comments:</font> <blockquote> <font face="MS Sans Serif" size="3">NFR is available in multiple forms: a freeware/research version (see below), the "NFR Intrusion Detection Appliance" which comes as bootable CD-ROM, and bundles from 3rd party resellers that add their own features on top of it (like Anzen).</font> <p><font face="MS Sans Serif" size="3">One of the popular features of NFR is "N-code", a fully featured programming language optimized for intrusion detection style capabilities. They have a fulll SMTP parser written in the N-code. Most other systems have either simply add signatures or force you to use raw C programming. Numerous N-code scripts are downloadable from the Internet from sources such as L0pht.</font> <p><font face="MS Sans Serif" size="3">NFR does more statistical analysis than other systems. The N-code system allows easy additions into this generic statistical machine.</font> <p><font face="MS Sans Serif" size="3">A general description can be found at <a href="http://www.nfr.net/forum/publications/LISA-97.htm">http://www.nfr.net/forum/publications/LISA-97.htm</a></font></p> </blockquote> <dt>  <h3><a name="4.2.10"><font face="MS Sans Serif" size="3">4.2.10 Dragon by Security Wizards</font></a></h3> <dd><font face="MS Sans Serif" size="3">Goto <a href="http://www.network-defence.com">http://www.network-defense.com</a></font></dd> </dl> <dt>  <h2><a name="4.3"><font face="MS Sans Serif" size="3">4.3 What is a "network grep" system?</font></a></h2> <dd><font face="MS Sans Serif" size="3">A "network grep" system is based around <a href="http://www.robertgraham.com/pubs/sniffing-faq.html">raw packet capture</a> pumped through a "regular expression" parser that finds patterns in the network traffic. An example pattern would be: "<tt>/cgi-bin/phf</tt>", which would indicate an attempt to exploit the vulnerable CGI script called "phf". Once building such a system, you would then analyze well-known attacks, extract strings specific to those attacks, and add them to your databse of patterns. See <a href="http://www.packetfactory.net/ngrep/">http://www.packetfactory.net/ngrep/</a> for an example.</font> <p><font face="MS Sans Serif" size="3">"Regexp" (regular expression) is a common pattern-matching language in the UNIX environment. While it has traditionally been used for searching text files, it can also be used for arbitrary binary data. In truth, such systems have more flexible matching criteria, such as finding ports or matching TCP flags.</font> <p><font face="MS Sans Serif" size="3">"libpcap" (library for packet capture) is a common library available for UNIX systems that "sniffs" packets off a wire. Most UNIX-based intrusion detection systems (of any kind) use libpcap, though many also have optimized drivers for a small subset of platforms.</font> <p><font face="MS Sans Serif" size="3">The source code for both modules is freely available. A large number of intrusion detection systems simply feed the output of libpcap (or tcpdump) into the regular expression parse, where the expressions come from a file on the disk. Some even simpler systems don't even use regular expressions and simply compare packets with well-known byte patterns. If you want to build a system like this yourself, read up on 'tcpdump' and regular expressions. To understand libpcap/tcpdump, the following document will be helpful: <a href="http://www.robertgraham.com/pubs/sniffing-faq.html">http://www.robertgraham.com/pubs/sniffing-faq.html</a>.</font> <p><font face="MS Sans Serif" size="3">This class of intrusion detection system has one advantage: it is the easiest to update. Products of this class will consistently have the largest number of "signatures" and be the fastest time-to-market for detecting new popular attack "scripts".</font> <p><font face="MS Sans Serif" size="3">However, while such systems may bost the largest number of "signatures", they detect the fewest number of "serious" intrusions. For example, the 8 bytes "CE63D1D2 16E713CF" when seen at the start of UDP data indicates Back Orifice traffic with the default password. Even though 80% of Back Orifice attacks use the default password, the other 20% use different passwords and would not be detected by the system. For example, changing the Back Orifice password to "evade" would change the pattern to "8E42A52C 0666BC4A", and would go undetected by "network grep" systems.</font> <p><font face="MS Sans Serif" size="3">Some of these systems do not reassemble IP datagrams or TCP streams. Again, a hacker could simply reconfigure the MTU size on the machine in order to evade regexp-pcap systems.</font> <p><font face="MS Sans Serif" size="3">Such systems result in larger numbers of false positives. In the BackOrifice example above, the 64-bit pattern is not so uncommon that it won't be seen in other traffic. This will cause alarms to go off even when no Back Orifice is present.</font> <p><font face="MS Sans Serif" size="3">Systems based upon protocol analysis do not have these problems. They catch all instances of the attack, not just the common varieties; they result in fewer false positives; and they often are able to run faster because a protocol decode doesn't have to "search" a frame. They are also able to more fully diagnose the problem; for example distinguish between a "Back Orifice PING" (which is harmless) and a "Back Orifice compromise" (which is an extreme condition). On the other hand, it can often take a week to add a new protocol analysis signature (rather than hours) due to the design and testing involved. Also, overly-agressive attempts to reduce false positives also leads to missing real attacks in some cases.</font> <p><font face="MS Sans Serif" size="3">However, such systems have an advantage over protocol analysis systems. Because they do not have pre-conceived notion about what network traffic is supposed to look like, they can often detect attacks that other systems might miss. For example, if a company is running a POP3 server on a different port, it is likely that protocol analysis systems will not recognize the traffic as POP3. Therefore, any attacks against the port will go undetected. On the other hand, a network-grep style system doesn't necessarily care about port numbers and will check for the same signatures regardless of ports.</font> <p>  <dl> <dt>  <h3><a name="4.3.1"><font face="MS Sans Serif" size="3">4.3.1 Dragon</font></a></h3> <dd><font face="MS Sans Serif" size="3">See above.</font> <dt>  <h3><a name="4.3.2"><font face="MS Sans Serif" size="3">4.3.2 Bro</font></a></h3> <dd><font face="MS Sans Serif" size="3">Vern Paxson's Bro intrusion detection system. Vern Paxson wrote large portions of libpcap that many other intrusion detection systems are based on (like NFR and Dragon). I haven't heard of anyone actually using Bro itself. Read the paper <a href="http://ftp.ee.lbl.gov/papers/bro-usenix98-revised.ps.Z">http://ftp.ee.lbl.gov/papers/bro-usenix98-revised.ps.Z</a> for more information.</font> <dt>  <h3><font face="MS Sans Serif" size="3"><a name="4.3.3">4.3.3</a> <a name="snort">Snort</a></font></h3> <dd><a href="http://www.clark.net/~roesch/security.html"><font face="MS Sans Serif" size="3">http://www.clark.net/~roesch/security.html</font></a> <p><font face="MS Sans Serif" size="3">Snort has recently become very popular, and is considered really cool by a lot of people. It contains over 100 of its own signatures, and others can be found on the Internet.</font> <p><font face="MS Sans Serif" size="3">Following is an example rule:</font> <pre><font face="MS Sans Serif" size="3"> # here's an example of PHF attack detection where just a straight text string # is searched for in the app layer alert tcp any any -> 192.168.1.0/24 80 (msg:"PHF attempt"; content:"/cgi-bin/phf";) </font></pre> <font face="MS Sans Serif" size="3">It says to alert an a TCP connection from any IP address and any port to the 192.168.1.x subnet to port 80. It searches for the content "/cgi-bin/phf" anywhere in the content. If it find such content, it will alert the console with a message "PHF attempt".</font> <p><font face="MS Sans Serif" size="3">Usage of snort is usually done in the following manner:</font> <ul> <li><font face="MS Sans Serif" size="3">BPF filters (part of libpcap) are configured to narrow down the focus to cetain types of traffic.</font> <li><font face="MS Sans Serif" size="3">A decision is made about which IP addresses are internal and which are external to further narrow down the focus.</font> <li><font face="MS Sans Serif" size="3">Rules are edited to fit the local environment.</font> <li><font face="MS Sans Serif" size="3">System runs</font> <li><font face="MS Sans Serif" size="3">Rules are further edited to remove false positives.</font></li> </ul> <p><font face="MS Sans Serif" size="3">Also, snort has a number of options to be used just to sniff network traffic.</font> <p><font face="MS Sans Serif" size="3">Rules:</font> <ul> <li><a href="http://snort.rapidnet.com/"><font face="MS Sans Serif" size="3">http://snort.rapidnet.com/</font></a> <li><a href="http://www.whitehats.com"><font face="MS Sans Serif" size="3">http://www.whitehats.com</font></a></li> </ul> <dt>  <h3><a name="4.3.4"><font face="MS Sans Serif" size="3">4.3.4 Argus</font></a></h3> <dd><font face="MS Sans Serif" size="3">Argus isn't an intrusion detection system itself. However, it monitors packets off the wire and generates logfile events. You can then process those log entries (or peruse them yourself) to find intrusions.</font> <p><font face="MS Sans Serif" size="3">See <a href="ftp://coast.cs.purdue.edu/pub/tools/unix/argus">ftp://coast.cs.purdue.edu/pub/tools/unix/argus</a> for more info. Also see <a href="ftp://ftp.sei.cmu.edu/pub/argus-1.5">ftp://ftp.sei.cmu.edu/pub/argus-1.5</a></font></p> </dd> </dl> <dt>  <h2><a name="4.4"><font face="MS Sans Serif" size="3">4.4 What tools do intruders use to break into my systems?</font></a></h2> <dd> <dl> <dt>  <h3><a name="4.4.1"><font face="MS Sans Serif" size="3">4.4.1 UNIX utilities</font></a></h3> <dd><font face="MS Sans Serif" size="3">These utilities either come with your favorite UNIX platform or you can download them for free.</font> <dl> <dt><font face="MS Sans Serif" size="3">ping</font> <dd><font face="MS Sans Serif" size="3">to see if a host is alive.</font> <dt><font face="MS Sans Serif" size="3">traceroute</font> <dd><font face="MS Sans Serif" size="3">to find the route to the host</font> <dt><font face="MS Sans Serif" size="3">nslookup/dig</font> <dd><font face="MS Sans Serif" size="3">to discover all your DNS information</font> <dt><font face="MS Sans Serif" size="3">whois</font> <dd><font face="MS Sans Serif" size="3">finds out Internic registration information</font> <dt><font face="MS Sans Serif" size="3">finger</font> <dd><font face="MS Sans Serif" size="3">finds out who is logged in and info about users</font> <dt><font face="MS Sans Serif" size="3">rpcinfo</font> <dd><font face="MS Sans Serif" size="3">finds out what RPC services are running</font> <dt><font face="MS Sans Serif" size="3">showmount</font> <dd><font face="MS Sans Serif" size="3">display shares on a machine</font> <dt><font face="MS Sans Serif" size="3">SAMBA</font> <dd><font face="MS Sans Serif" size="3">displays info about WinNT SMB shares</font> <dt><font face="MS Sans Serif" size="3">telnet</font> <dd><font face="MS Sans Serif" size="3">the granddaddy of them all -- allows you to connect and play with any text-based protocol (HTTP, FTP, SMTP, etc.)</font></dd> </dl> <dt>  <h3><a name="4.4.2"><font face="MS Sans Serif" size="3">4.4.2 WinNT utilities</font></a></h3> <dd><font face="MS Sans Serif" size="3">All of the UNIX utilities mentioned above can be used with WinNT. There are also some WinNT specific ones.</font> <dl> <dt><font face="MS Sans Serif" size="3">nbtstat</font> <dd><font face="MS Sans Serif" size="3">discovers NetBIOS information on remote machine</font> <dt><font face="MS Sans Serif" size="3">net view</font> <dd><font face="MS Sans Serif" size="3">is the LANMAN programme that allows you to remotely view WinNT shares</font></dd> </dl> <dt>  <h3><a name="4.4.3"><font face="MS Sans Serif" size="3">4.4.3 Hacking-specific utilities</font></a></h3> <dd><font face="MS Sans Serif" size="3">The standard toolkit for a intruder.</font> <dl> <dt><font face="MS Sans Serif" size="3">netcat</font> <dd><font face="MS Sans Serif" size="3">is characterized as a "TCP/IP" Swiss Army Knife, allows intruders to script protocol interactions, especially text-based protocols.</font> <dt><font face="MS Sans Serif" size="3">crack / NTcrack / L0phtCrack / etc.</font> <dd><font face="MS Sans Serif" size="3">that crack network passwords (Dictionary or Brute Force). These packages also contain utilities for dumping passwords out of databases and sniffing them off the wire.</font> <dt><font face="MS Sans Serif" size="3">Sniffing utilities</font> <dd><font face="MS Sans Serif" size="3">for watching raw network traffic, such as <b>Gobbler</b>, <b>tcpdump</b>, or even an honest-to-god Network Associates <b>Sniffer© Network Analyzer</b></font> <dt><font face="MS Sans Serif" size="3">TCP and UDP port scanners</font> <dd><font face="MS Sans Serif" size="3">for scanning/strobing/probing which TCP ports are available. TCP port-scanners can also run in a number of stealth modes to evade/elude loggers.</font> <dt><font face="MS Sans Serif" size="3">Ping sweepers</font> <dd><font face="MS Sans Serif" size="3">for pinging large numbers of machines to see which ones are active.</font> <dt><font face="MS Sans Serif" size="3">Exploit packs</font> <dd><font face="MS Sans Serif" size="3">which are a set of one or more programs that know how to exploit holes on systems (usually, once the user is logged in).</font> <dt><font face="MS Sans Serif" size="3">Remote security auditors</font> <dd><font face="MS Sans Serif" size="3">such as SATAN that look for a number of well known holes in machines all across the network.</font> <dt><font face="MS Sans Serif" size="3">War dialers</font> <dd><font face="MS Sans Serif" size="3">that dial lots of phone numbers looking for dial-in ports.</font> <dt><font face="MS Sans Serif" size="3">NAT</font> <dd><font face="MS Sans Serif" size="3">is based upon the SAMBA code, and is useful for discovering NetBIOS/SMB info from Windows and SAMBA servers.</font> <dt><font face="MS Sans Serif" size="3">Scanners</font> <dd><font face="MS Sans Serif" size="3">are programs (like <a href="http://www.fish.com/satan/">SATAN</a>, <a href="http://www.issx.com">ISS</a>, <a href="http://www.nai.com">CyberCop</a> Scanner) that probe the system for vulnerabilities. That have a huge number of vulnerabilities they check for and are generally automated, giving the hacker that highest return for the minimal effort.</font></dd> </dl> </dd> </dl> <dt>  <h2><a name="4.5"><font face="MS Sans Serif" size="3">4.5 What other free/shareware intrusion detection products should I be aware of?</font></a></h2> <dd> <dl> <dt>  <h3><a name="4.5.0"><font face="MS Sans Serif" size="3">4.5.0 NFR, Research Version</font></a></h3> <dd><font face="MS Sans Serif" size="3">The "NFR Research Version" is a configurable toolkit, available from the Internet for research and noncommercial use. It is "as is" software that requires expertise from the end user to install and configure. It is not a "plug and play" intrusion detection system. (quote from NFR)</font> <p><font face="MS Sans Serif" size="3">See above for info on the commercial version.</font></p> <dt>  <h3><a name="4.5.1"><font face="MS Sans Serif" size="3">4.5.1 tcpwrappers</font></a></h3> <dd><font face="MS Sans Serif" size="3">Tcpwrappers are an add-in for UNIX, and sit between <code>inetd</code> and services (like ftp, telnet, etc.). The <code>inetd</code> will first call tcpwrappers, which will do some authentication (by IP address) and logging. Then, tcpwrappers will call the actual service, if need be.</font> <dt>  <h3><a name="4.5.2"><font face="MS Sans Serif" size="3">4.5.2 IDS for Checkpoint Firewalls</font></a></h3> <dd><font face="MS Sans Serif" size="3">Log file analysis of firewalls is very similar to network analysis. See <a href="http://www.enteract.com/~lspitz/intrusion.html">http://www.enteract.com/~lspitz/intrusion.html</a> for an example.</font> <dt>  <h3><a name="4.5.3"><font face="MS Sans Serif" size="3">4.5.3 Shadow</font></a></h3> <dd><font face="MS Sans Serif" size="3">I think it is a project used in the Navy to track intrusions, and generate reports on them. They have an interesting report at <a href="http://www.nswc.navy.mil/ISSEC/CID/co-ordinated_analysis.txt">http://www.nswc.navy.mil/ISSEC/CID/co-ordinated_analysis.txt</a> where they describe coordinated, slow attacks they have detected using this system.</font> <dt>  <h3><a name="4.5.4"><font face="MS Sans Serif" size="3">4.5.4 AAFID</font></a></h3> <dd><font face="MS Sans Serif" size="3">Purdue's <a href="http://www.cs.purdue.edu/coast">COAST</a> distributed agent idea. I'm not sure how much of this is proposals, and how much is real.</font></dd> </dl> <dt>  <h2><a name="4.6"><font face="MS Sans Serif" size="3">4.6 Are there NIDS available for my host?</font></a></h2> <dd><font face="MS Sans Serif" size="3">A new class of NIDS runs on hosts in non-promiscuous mode.</font> <dl> <dt>  <h3><a name="4.6.1"><font face="MS Sans Serif" size="3">4.6.1 Network ICE / BlackICE Defender</font></a></h3> <dd><font face="MS Sans Serif" size="3">The first such system was BlackICE Defender from Network ICE released in mid-1999. The system also contains a personal firewall. It runs on Win95, Win98, WinNT, and Win2k. It is targetted at both end-nodes and servers.</font> <dt>  <h3><a name="4.6.2"><font face="MS Sans Serif" size="3">4.6.2 Network Associates / CyberCop Monitor v2.0</font></a></h3> <dd><font face="MS Sans Serif" size="3">The second system is CCM from Network Associates, released in late 1999. While billed primarily as a "host-based IDS", the majority of the intrusions it detects are network-based. It currently supports WinNT (and presumably Win2k) and they have announced support for Solaris.</font> <dt>  <h3><a name="4.6.3"><font face="MS Sans Serif" size="3">4.6.3 CyberSafe / Centrax NNID</font></a></h3> <dd><font face="MS Sans Serif" size="3">In February of 2000, CyberSafe announced their "network node intrusion detection (NNID)". Apparently, versions of their Centrax NIDS come in both promiscuous and non-promiscuous licenses starting with version 2.3.</font> <dt>  <h3><a name="4.6.4"><font face="MS Sans Serif" size="3">4.6.4 ISS / RealSecure Micro-Agent</font></a></h3> <dd><font face="MS Sans Serif" size="3">ISS has pre-announced a "Micro-Agent" version of the RealSecure NIDS. The announcement indicates that it will also contain "blocking" features, which presumably will consist of some sort of personal firewall. They have announced that this will be available for both WinNT (and presumably Win2k) as well as Solaris.</font></dd> </dl> <dt>  <h1><a name="6."><font face="MS Sans Serif" size="3">6. Resources</font></a></h1> <dd>  <dt>  <h2><a name="6.1"><font face="MS Sans Serif" size="3">6.1 Where can I find updates about new security holes?</font></a></h2> <dd> <dl> <dt>  <h3><a name="6.1.1"><font face="MS Sans Serif" size="3">6.1.1 CERT (Computer Emergency Response Team)</font></a></h3> <dd><font face="MS Sans Serif" size="3">If it is a security problem, you will eventually see it appear in a CERT advisory. CERT (Computer Emergency Response Team) was set up by a number of universities and DARPA in response to the Morris Worm of 1988. Goto <a href="http://www.cert.org">http://www.cert.org</a>.</font> <dt>  <h3><a name="6.1.2"><font face="MS Sans Serif" size="3">6.1.2 AUSCERT (AUStralian Computer Emergency Response Team)</font></a></h3> <dd><font face="MS Sans Serif" size="3">AUSCERT is the AUStralian Computer Emergency Response Team. For registration information, see their web site on:</font> <p><a href="http://www.auscert.org.au/"><font face="MS Sans Serif" size="3">http://www.auscert.org.au/</font></a> <p><font face="MS Sans Serif" size="3">For more details, contact AUSCERT directly on <a href="mailto:auscert@auscert.org.au">auscert@auscert.org.au</a>.</font></p> <dt>  <h3><a name="6.1.3"><font face="MS Sans Serif" size="3">6.1.3 CIAC (Computer Incident Advisory Capability) by US Department of Energy</font></a></h3> <dd><font face="MS Sans Serif" size="3">Has a number of useful advisories. Goto <a href="http://www.ciac.org/">http://www.ciac.org/</a>.</font></dd> </dl> <dt>  <h2><a name="6.2"><font face="MS Sans Serif" size="3">6.2 What are some other security and intrusion detection resources?</font></a></h2> <dd> <dl> <dt>  <h3><a name="6.2.1"><font face="MS Sans Serif" size="3">6.2.1 Purdue's COAST archive</font></a></h3> <dd><font face="MS Sans Serif" size="3">This is the best site on the net for learning about IDS and security in general. See <a href="http://www.cs.purdue.edu/coast">http://www.cs.purdue.edu/coast</a>, <a href="http://www.cs.purdue.edu/coast/intrusion-detection">http://www.cs.purdue.edu/coast/intrusion-detection</a><a>, and </a><a href="http://www.cs.purdue.edu/coast/ids">http://www.cs.purdue.edu/coast/ids</a>.</font> <dt>  <h3><a name="6.2.2"><font face="MS Sans Serif" size="3">6.2.2 SANS Institute</font></a></h3> <dd><font face="MS Sans Serif" size="3">I think this may be the best site for security information for people who are not themselves hackers. Their target audience is MIS professionals who have to defend their networks. Goto <a href="http://www.sans.org/">http://www.sans.org/</a></font> <dt>  <h3><a name="6.2.3"><font face="MS Sans Serif" size="3">6.2.3 L0pht Heavy Industries</font></a></h3> <dd><font face="MS Sans Serif" size="3">These are some hackers with some pretty good tools and useful alerts, targeted at Windows. Goto <a href="http://www.l0pht.com">http://www.l0pht.com</a></font> <dt>  <h3><a name="6.2.4"><font face="MS Sans Serif" size="3">6.2.4 Technical Incursion Countermeasures</font></a></h3> <dd><font face="MS Sans Serif" size="3">I like this site; it has a bunch of well organized info on intrusion (A.K.A. incursion). Goto <a href="http://www.ticm.com">http://www.ticm.com</a></font> <dt>  <h3><a name="6.2.5"><font face="MS Sans Serif" size="3">6.2.5 IDS mailing list</font></a></h3> <dd><font face="MS Sans Serif" size="3">Email "subscribe ids" to majordomo@uow.edu.au<br> Email questions to ids-owner@uow.edu.au<br> This is a nice, low-volume list with interesting discussions from time-to-time.</font> <dt>  <h3><a name="6.2.6"><font face="MS Sans Serif" size="3">6.2.6 Michael Sobirey's Intrusion Detection Systems page</font></a></h3> <dd><a href="http://www-rnks.informatik.tu-cottbus.de/~sobirey/ids.html"><font face="MS Sans Serif" size="3">http://www-rnks.informatik.tu-cottbus.de/~sobirey/ids.html</font></a> <dt>  <h3><a name="6.2.7"><font face="MS Sans Serif" size="3">6.2.7 advICE database</font></a></h3> <dd><a href="http://www.networkice.com/advice/Countermeasures/Intrusion_Detection/default.htm"><font face="MS Sans Serif" size="3">http://www.networkice.com/advice/Countermeasures/Intrusion%20Detection/default.htm</font></a></dd> </dl> <dt>  <h2><a name="6.3"><font face="MS Sans Serif" size="3">6.3 What are some sites that are interesting?</font></a></h2> <dd><font face="MS Sans Serif" size="3">Here are some sites that aggregate info from other sites. Could be worth a look.</font> <dl> <dt>  <h3><a name="6.3.1"><font face="MS Sans Serif" size="3">6.3.1 NIH security site</font></a></h3> <dd><font face="MS Sans Serif" size="3">Goto <a href="http://www.alw.nih.gov/Security/">http://www.alw.nih.gov/Security/</a></font> <dt>  <h3><a name="6.3.2"><font face="MS Sans Serif" size="3">6.3.2 NTSecurity.net</font></a></h3> <dd><font face="MS Sans Serif" size="3">Goto <a href="http://www.ntsecurity.net/">http://www.ntsecurity.net/</a>.</font></dd> </dl> <dt>  <h1><a name="7."><font face="MS Sans Serif" size="3">7. IDS and Firewalls</font></a></h1> <dd>  <dt>  <h2><a name="7.2"><font face="MS Sans Serif" size="3">7.2 Why do I need IDS if I already have a firewall?</font></a></h2> <dd><font face="MS Sans Serif" size="3">A common misunderstanding is that firewalls recognize attacks and block them. This is not true.</font> <p><font face="MS Sans Serif" size="3">Firewalls are simply a device that shuts off everything, then turns back on only a few well-chosen items. In a perfect world, systems would already be "locked down" and secure, and firewalls would be unneeded. The reason we have firewalls is precisely because security holes are left open accidentally.</font> <p><font face="MS Sans Serif" size="3">Thus, when installing a firewall, the first thing it does is stops ALL communication. The firewall administrator then carefully adds "rules" that allow specific types of traffic to go through the firewall. For example, a typical corporate firewall allowing access to the Internet would stop all UDP and ICMP datagram traffic, stops incoming TCP connections, but <i>allows</i> outgoing TCP connections. This stops all incoming connections from Internet hackers, but still allows internal users to connect in the outgoing direction.</font> <p><font face="MS Sans Serif" size="3">A firewall is simply a fence around you network, with a couple of well chosen gates. A fence has no capability of detecting somebody trying to break in (such as digging a hole underneath it), nor does a fence know if somebody coming through the gate is allowed in. It simply restricts access to the designated points.</font> <p><font face="MS Sans Serif" size="3">In summary, a firewall is not the dynamic defensive system that users imagine it to be. In contrast, an IDS <i>is</i> much more of that dynamic system. An IDS <i>does</i> recognize attacks against the network that firewalls are unable to see.</font> <p><font face="MS Sans Serif" size="3">For example, in April of 1999, many sites were hacked via a bug in ColdFusion. These sites all had firewalls that restricted access only to the web server at port 80. However, it was the web server that was hacked. Thus, the firewall provided no defence. On the other hand, an intrusion detection system would have discovered the attack, because it matched the signature configured in the system.</font> <p><font face="MS Sans Serif" size="3">Another problem with firewalls is that they are only at the boundary to your network. Roughly 80% of all financial losses due to hacking come from inside the network. A firewall a the perimeter of the network sees nothing going on inside; it only sees that traffic which passes between the internal network and the Internet.</font> <p><font face="MS Sans Serif" size="3">Some reasons for adding IDS to you firewall are:</font> <ul> <li><font face="MS Sans Serif" size="3">Double-checks misconfigured firewalls.</font> <li><font face="MS Sans Serif" size="3">Catches attacks that firewalls legitimate allow through (such as attacks against web servers).</font> <li><font face="MS Sans Serif" size="3">Catches attempts that fail.</font> <li><font face="MS Sans Serif" size="3">Catches insider hacking.</font></li> </ul> <p><font face="MS Sans Serif" size="3">"defence in depth, and overkill paranoia, are your friends." (quote by Bennett Todd <bet at mordor dot net>). Hackers are much more capable than you think; the more defences you have, the better. And they still won't protect you from the determined hacker. They will, however, raise the bar on determination needed by the hackers.</font></p> <dt>  <h2><a name="7.2.1"><font face="MS Sans Serif" size="3">7.2.1 How is it that hackers can get through firewalls?</font></a></h2> <dd><i><font face="MS Sans Serif" size="3">Editors Note: This just clarifies the point above.</font></i> <p><font face="MS Sans Serif" size="3">Consider bridge building throughout history. As time goes on, technology improves, and bridges are able to span ever larger distances (such as the Golden Gate bridge in SF, whose span is measured in kilometers). Bridge builders are very conservative due to the immense embarassment (not to mention loss of life) should the bridges fail. Therefore, they use much more material (wood, stone, steel) than they need, and they don't create spans nearly as long as they think they can. However, as time goes on, as bridges prove themselves, engineers take more and more risks, until a bridge fails. Then all the engineers become much more conservative again. As has been quoted "It's easy to build a bridge that doesn't fall down; what takes skill is building a bridge that just <i>barely</i> doesn't fall down."</font> <p><font face="MS Sans Serif" size="3">In much the same way, most firewall administrators take the conservative approach. It is easy to build a firewall that can't be hacked by being overly conservative and paranoid, and simply turn off all but the absolutely necessary services.</font> <p><font face="MS Sans Serif" size="3">However, in the real world, engineers are not allowed to be sufficiently paranoid. Just like bridge builders want to span ever wider rivers and gorges, corporations want to ever expand the services of the Internet. This puts immense pressure on firewall admins to relax the barriers. This process will continue up to the point where there system is hacked, at which point the corporation will become much more conservative. From this perspective, one could say that corporate dynamics are such that they will generally force the system to the point where it gets hacked.</font> <p><font face="MS Sans Serif" size="3">As every firewall admin knows, the system is under constant attack from the Internet. Hackers from all over the world are constantly probing the system for weaknesses. Moreover, every few months a new security vulnerability is found in popular products, at which point the hackers simply scan the entire Internet looking for people with that hole, causing thousands of websites to be hacked. Such recent holes have been the ColdFusion cfmdocs bug and the Microsoft .htr buffer overflow.</font></p> <dt>  <h2><a name="7.3"><font face="MS Sans Serif" size="3">7.3 If I have a intrusion detection, do I need firewall?</font></a></h2> <dd><font face="MS Sans Serif" size="3">Of course. Every corporation needs a well managed, single point of entry.</font> <p><font face="MS Sans Serif" size="3">There are a huge number of "script-kiddies" that are always running automated programs (like SATAN) on the Internet looking for holes. Without a firewall, these automated programs can detect and exploit holes literally in the blink of an eye. Even dial-up users who use the Internet only a few hours a week are getting scanned on a regular basis; high-profile corporate sites will be scanned by script-kiddies much more often.</font></p> <dt>  <h2><a name="7.4"><font face="MS Sans Serif" size="3">7.4 Where does the intrusion detection system gets its information? The firewall?</font></a></h2> <dd><font face="MS Sans Serif" size="3">No. While some log file analysis programme do scan firewall logs for signs of intrusions, most intrusion detection systems get their information elsewhere.</font> <p><font face="MS Sans Serif" size="3">Remember that firewalls are simple rule-based systems that allow/deny traffic going through them. Even "content inspection" style firewalls do not have the capability to clearly say whether the traffic constitues an attack; they only determine whether it matches their rules or not.</font> <p><font face="MS Sans Serif" size="3">For example, a firewall in front of a web server might block all traffic except for TCP connections to port 80. As far as the firewall is concerned, any port-80 traffic is legitimate. An IDS, on the other hand, examines that same traffic and looks for pattern of attack. An IDS system doesn't really care if the manager decided to allow port 80 and deny the rest: as far as the IDS is concerned, all traffic is suspicious.</font> <p><font face="MS Sans Serif" size="3">This means that an IDS must look at the same source of data as the firewall: namely, the raw network traffic on the wire. If an IDS sat "downstream" from the firewall isntead of side-by-side, it would be limitted to only those things the firewall considered attacks. In the above example, the firewall would never pass port 80 traffic to the IDS.</font> <p>  <pre><font face="MS Sans Serif" size="3"> +-+ . |F| +-----+ . |I+--+IDS#1| . /============\ |R| +-----+ /============\ . H H |E| H corporate H . H internet H--------+--------+ +------+------H network H . H H | |W| | H +-----+ \============/ +--v--+ |A| +--v--+ \=========+IDS#4| |IDS#3| |L| |IDS#2| +-----+ +-----+ |L| +-----+ . +-+ . </font></pre> <dl> <dt><font face="MS Sans Serif" size="3">IDS #1</font> <dd><font face="MS Sans Serif" size="3">Few IDSs work this way. Firewalls don't produce enough information in order to effectively detect intrusions.</font> <dt><font face="MS Sans Serif" size="3">IDS #2</font> <dd><font face="MS Sans Serif" size="3">This popular placement of an IDS detects attacks that successfully penetrate the firewall.</font> <dt><font face="MS Sans Serif" size="3">IDS #3</font> <dd><font face="MS Sans Serif" size="3">This placement detects attacks that are attempted against the firewall.</font> <dt><font face="MS Sans Serif" size="3">IDS #4</font> <dd><font face="MS Sans Serif" size="3">By placing intrusion detection systems throughout a corporate network, attacks by insiders will be detected.</font></dd> </dl> <dt>  <h1><a name="8."><font face="MS Sans Serif" size="3">8. Implementation Guide</font></a></h1> <dd>  <dt>  <h2><a name="8.1"><font face="MS Sans Serif" size="3">8.1 What questions should I ask my IDS vendor?</font></a></h2> <dd><font face="MS Sans Serif" size="3">CSI (Computer Security Institute) has a good page on this, where they posed questions to IDS vendors, as well as asked them what the difficult questions are. This site is at <a href="http://www.gocsi.com/intrusion.htm">http://www.gocsi.com/intrusion.htm</a>.</font> <p><font face="MS Sans Serif" size="3">Some common questions are:</font> <dl> <dt><font face="MS Sans Serif" size="3">What does it cost?</font> <dd><font face="MS Sans Serif" size="3">Of course.</font> <dt><font face="MS Sans Serif" size="3">What do signature updates and maintanance cost?</font> <dd><font face="MS Sans Serif" size="3">Intrusion detection is much like virus protection, a system that hasn't been updated for a year will miss common new attacks.</font> <dt><font face="MS Sans Serif" size="3">At what real-world traffic levels does the product become <a href="#9.3.1">blind</a>, in packets/second?</font> <dd><font face="MS Sans Serif" size="3">First, what segments do you plan on putting the IDS onto? If you have only a 1.5-mbps connection to the Internet that you want to monitor, you don't need the fastest performing system. On the other hand, if you are trying to monitor a server farm in your corporation in order to detect internal attacks, a hacker could easily <a class="dict" href="http://www.robertgraham.com/pubs/hacking-dict.html#smurf">smurf</a> the segment in order to <a href="#9.3.1">blind</a> the sensor.</font> <p><font face="MS Sans Serif" size="3">The most important metric is <b>packets/second</b>. Marketing people use weasle words to say that their products can keep up with a full 100-mbps networks, but that is only under ideal conditions. A Network World did a review in August of 1998 where products failed at roughly 30% network load (50,000 pacets/second). Likewise, Network Computing did a <a href="http://www.nwc.com/1023/1023f19.html">review</a> in September of 1999 with real-world traffic where several products that claimed 100-mbps could still not keep up.</font></p> <dt><font face="MS Sans Serif" size="3">How easy is the product to evade?</font> <dd><font face="MS Sans Serif" size="3">Go down the list in section <a href="#9.4">9.4</a> and ask the vendor if such activities will evade the IDS. If you want to give the vendor heartburn, ask them about section <a href="#9.5">9.5</a> .</font> <dt><font face="MS Sans Serif" size="3">How scalable is the IDS system as a whole?</font> <dd><font face="MS Sans Serif" size="3">How many sensors does the system support? How big can the database be? What are the traffic levels when forwarding information to the management console? What happens when the management console is overloaded? These are tough questions.</font> <dt><font face="MS Sans Serif" size="3">How much will it cost to run and maintain the product?</font> <dd><font face="MS Sans Serif" size="3">How good is the reporting architecture? How easy is it to manage false positives? How long does it take to track down alerts and identify the situation? How many people do I need to use this product?</font></dd> </dl> <p><font face="MS Sans Serif" size="3">The following questions are commonly asked, but are less likely to produce meaningful answers:</font></p> <dt><font face="MS Sans Serif" size="3">How many signatures does the system support?</font> <dd><font face="MS Sans Serif" size="3">Unfortunately, vendors dramatically inflate their signature count. This is the game that all vendors must play, even though it is becoming less and less important.</font> <dt><font face="MS Sans Serif" size="3">What intrusion <a href="#2.4">response</a> features does the product have?</font> <dd><font face="MS Sans Serif" size="3">A feature like automatically reconfiguring a firewall sounds really cool, but in real life, few security managers implement it. Reconfiguring a corporate firewall is extremely dangerous.</font></dd> </dl> <dl> <dt>  <h2><a name="8.2"><font face="MS Sans Serif" size="3">8.2 How do I maintain the system on an on-going basis?</font></a></h2> <dd><font face="MS Sans Serif" size="3">I put this question in here hoping for feedback; I really don't have an answer.</font> <p><font face="MS Sans Serif" size="3">If you install an intrusion detection system, you WILL see intrusions on an on-going basis. In a SOHO environment, you will likely get scanned by a hacker once a week. On a well-known web-site, hackers will probe your site for vulnerabilies many times per day. On a large internal corporate network, you will find constant suspicious activities by internal employees.</font> <p><font face="MS Sans Serif" size="3">The first problem that you are likely to be confronted with is employees surfing p-orn sites on the web. Just about every long-term administrator I know has interesting stories about this. Most don't care about p-orn, it just embarrassing knowing what people are up to.</font> <p><font face="MS Sans Serif" size="3">It is interesting that many otherwise conservative corporations do not outright restrict such surfing -- because it is often the executives themselves that do it. Lower-level engineers detecting such activities usually fear to bring the subject up.</font> <p><font face="MS Sans Serif" size="3">The next problem that engineers face is a Human Resource (HR) issue. You will find users doing things they shouldn't, so a lot of time is spent interfacing with HR working with the offending employee.</font> <p><font face="MS Sans Serif" size="3">The last problem is what to do about Internet script-kiddies and hackers probing your system. Usually, a call to ISP in question or email to their "abuse@" mail box suffices. Sometimes the ISP will be grateful -- because their own systems have been compromised.</font> <p><font face="MS Sans Serif" size="3">Remember that even what appears to be the most egregious hack may, in fact, be innocuous, so aproach other people with dignity and respect.</font></p> <dt>  <h2><a name="8.4"><font face="MS Sans Serif" size="3">8.4 How do I stop innapropriate web surfing?</font></a></h2> <dd><font face="MS Sans Serif" size="3">One of the biggest concerns for corporations today is employees surfing "innapropriate" web sites. To some extent, companies are worried about employees wasting company time on the Internet, and to another extent, companies are worried about legal liability, such as when an employee surfs p-orn sites that causes a sexual harassment lawsuit.</font> <p><font face="MS Sans Serif" size="3">However, companies do not like being in the position of being "big brother". Rules against inappropriate surfing inevitably lead to grey areas (for example: Playboy.com recently had an article on computer security, which an employee could easily have stumbled across while doing a legitimate search on the web).</font> <p><font face="MS Sans Serif" size="3">Intrusion detection systems, firewalls, proxy servers, and sniffing programs can be configured to log all web surfing traffic to log files, including <i>who</i> accessed <i>which</i> websites. Most companies already have these logs, but few make use of this information. Network technicians do not want to take on the role of HR and prosecute people. (In many cases, the culprits are executives and going after them can be a career limiting move (CLM)).</font> <p><font face="MS Sans Serif" size="3">One elegant solution is posting such information to a public internal website. This has been known to dramatically affect inappropriate surfing. Rather than having a central authority judging appropriateness, it leaves it up to the individual to make that judgement.</font></p> <dt>  <h2><a name="8.5"><font face="MS Sans Serif" size="3">8.5 How can I build my own IDS (writing code)?</font></a></h2> <dd><font face="MS Sans Serif" size="3">Simple intrusion detection systems are easy to build. Simply grab an input source (log files, network traffic) and pass it through a pattern match (regexp). Along with it, through the same data through some statistical analysis, much like how SETI@Home sends radio noise through some Fourier analysis looking for repeated patterns.</font> <p><font face="MS Sans Serif" size="3">For example, section <a href="#4.3">4.3</a> above discusses a "network grep" system that passes network traffic through a pattern match system. Such a system could be built with some knowledge of C and a UNIX system.</font> <p><font face="MS Sans Serif" size="3">Similarly, section <a href="#4.5.2">4.5.2</a> describes a PERL based system that parses log files from a firewall.</font></p> <dt>  <h2><a name="8.7"><font face="MS Sans Serif" size="3">8.7 What is the legality of NIDS (since it is a form of wiretap)?</font></a></h2> <dd> <p><font face="MS Sans Serif" size="3">Different countries and states have different laws, but it is generally legal to monitor your OWN traffic for intrusions.</font> <p><font face="MS Sans Serif" size="3">One concern that people have is that running a NIDS on a corporate network results in network managers viewing employee Internet surfing activity (sometimes network managers find top executives surfing porn sites). As the network equipement and the user's workstation belong to the company, the legal precident is that use of the corporate equipment implies consent to monitoring. However, it is recommended that companies explicitly state in employee handbooks that their network activity <i>will</i> be monitored. At minimum, it avoid embarrasing situations.</font></p> <dt>  <h2><a name="8.8"><font face="MS Sans Serif" size="3">8.8 How do I save logfiles in a tamper-proof way?</font></a></h2> <dd><font face="MS Sans Serif" size="3">The first thing a hacker does is delete/change the logfiles in order to hide evidence of the break in. Therefore, a common need is to have a "write-once" storage system whereby once data is written, it can never be altered.</font> <p><font face="MS Sans Serif" size="3">WORM (Write-Once-Read-Many) drives have historically been used for this purpose, but they are expensive and finnicky. They probably don't have drivers for your system, and you software is likely incompatible with them in other ways (i.e. some systems do alter the files a little bit as they create them, which doesn't work on a worm).</font> <p><font face="MS Sans Serif" size="3">One problem with any system is that entropy sets in. It may be provable secure today, but it is unlikely to stay that way. For example, one technique for logging would be to employ syslog where the receiver doesn't have a TCP/IP stack but instead uses TCPDUMP to save the raw packets to a file (presumably, a utility would be run a later date to reconstruct the syslog entries). From the entropy perspective, there is no guarantee that a TCP/IP stack won't be installed during an update, or when a new person joins the team, or when machines get shuffled around.</font> <p><font face="MS Sans Serif" size="3">To combat such entropy, the model system uses the "snipped-wire" approach. In this model, an extra Ethernet adapter is installed in the machine who is generating the data, and the <b>receive</b> wire is cut. If an accident later happens such that the extra adapter is connected to an unsecured network, then few problems are likely to result.</font> <p><font face="MS Sans Serif" size="3">In much the same way, the receiving system should have only a single Ethernet adapter, and its <b>transmit</b> wire should be cut. It would be best to also disable the TCP/IP stack and instead force the data through packet sniffing utilities. (Yes, there are attacks that can compromise the system even when no responses are ever received).</font> <p><font face="MS Sans Serif" size="3">Normal TCP/IP won't work in this scenario. You will need to hard-code the route and ARP tables on the generating machine in order to force the traffic out the one-way wire. Similarly, you will need to use special utilities on the receiving machine in order to parse incoming packets back into useful data.</font> <p><font face="MS Sans Serif" size="3">UDP-based transports like 'syslog' and SNMP Traps are the most useful transports in this situation. They are easy to generate on the outgoing machine as they are built into most systems. Since responses aren't generated anyway, it doesn't hamper the normal flow of applications. Likewise, they are easy to parse back into SNMP messages or syslog files on the receiving end, or at least, it is easy to harden a TCP/IP stack to receive only those ports. At very least, TFTP or NFS can be configured to transport files to a TCP/IP stack on the other side.</font> <p><font face="MS Sans Serif" size="3">One problem that goes along with this is data management. You cannot connect the data repository to a network, so anything you use to backup the system must be installed on the system itself.</font> <p><font face="MS Sans Serif" size="3">Personally, the system I use is an old Pentium-90 computer with a 6-gig drive, CD-ROM writer, and a sniffing utility that dumps all the network traffic (a 416-kbps DSL connection) to packet capture files on the disk. A couple simple filters remove a lot of the bulk so downloading the latest RedHat distribution doesn't fill up the disk. I prefer this solution over actual log files because it captures absolutely everything that happens on the wire, even all numerous so-called stealth attempts.</font></p> <dt>  <h1><a name="9"><font face="MS Sans Serif" size="3">9 What are the limitations of NIDS?</font></a></h1> <dd><font face="MS Sans Serif" size="3">Network intrusion detection systems are unreliable enough that they should be considered only as secondary systems designed to backup the primary security systems.</font> <p><font face="MS Sans Serif" size="3">Primary systems such as firewalls, encryption, and authentication are rock solid. Bugs or misconfiguration often lead to problems in these systems, but the underlying concepts are "provably" accurate.</font> <p><font face="MS Sans Serif" size="3">The underlying concepts bhind NIDS are not absolutely accurate. Intrusion detection systems suffer from the two problems whereby normal traffic causes many false positives (cry wolf), and careful hackers can evade or disable the intrusion detection systems. Indeed, there are many proofs that show how network intrusion detection systems will never be accurate.</font> <p><font face="MS Sans Serif" size="3">This doesn't mean intrusion detection systems are invalid. Hacking is so pervasive on today's networks that people are regularly astounded when they first install such systems (both inside and outside the firewall). Good intrusion detection systems can dramatically improve the security of a site. It just needs to be remembered that intrusion detection systems are backup. The "proveably accurate" systems regularly fail (due to human error), and the "proveably incorrect" systems regularly work.</font> <p> </p> <dt>  <h2><a name="9.1"><font face="MS Sans Serif" size="3">9.1 Switched network (inherent limitation)</font></a></h2> <dd> <p><font face="MS Sans Serif" size="3">Switched networks (such as 100-mbps and gigabit Ethernet switches) poses dramatic problems to network intrusion detection systems. There is no easy place to "plug in" a sensor in order to see all the traffic.</font> <p><font face="MS Sans Serif" size="3">For example, somebody on the same switched fabric as the CEO has free reign to attack the CEO's machine all day long, such as with a password grinder targetting the File and Print sharing.</font> <p><font face="MS Sans Serif" size="3">There are some solutions to this problem, but not all of them are satisfactory.</font> <p>  <dl> <dt>  <h3><font face="MS Sans Serif" size="3">Embed IDS within the switch</font></h3> <dd><font face="MS Sans Serif" size="3">Some vendors (Cisco, ODS) are imbedding intrusion detection directly into switches. As far as I can tell, however, these IDS systems do not have the broad range of detection as traditional NIDS.</font> <dt>  <h3><font face="MS Sans Serif" size="3">Monitor/span port</font></h3> <dd><font face="MS Sans Serif" size="3">Many switches have a "monitor port" for attaching network analyzers. A NIDS can easily be added to this port as well. An obvious problem is that the port runs at a much lower speed than the switch backplane, so the NIDS will not be able to see all the traffic on a heavily loaded switch. Moreover, such ports are often used by sniffers for network management purposes, and must often be swapped out occasionally.</font> <dt>  <h3><font face="MS Sans Serif" size="3"><a name="#cable-taps">Tap into the cable</a> (for inter-switch or switch-to-node)</font></h3> <dd><font face="MS Sans Serif" size="3">A monitor can be connected directly to the cable in order to monitor the traffic. These may be cables between switches or cables from the switch to a host. Different techniques would be:</font> <p>  <dl> <dt><i><font face="MS Sans Serif" size="3">inline taps</font></i> <dd><font face="MS Sans Serif" size="3">Inline taps are devices that insert themselves directly into the stream of communication and make a copy of it. A typical example would be the Shomiti Century Tap (<a href="http://www.shomiti.com/productsf/tapfamilyf.html">http://www.shomiti.com/productsf/tapfamilyf.html</a>) which plugs into a 100-mbps full duplex line, and allows a computer equipped with 2 adapters to read both channels.</font> <dt><i><font face="MS Sans Serif" size="3">vampire taps</font></i> <dd><font face="MS Sans Serif" size="3">In the olden days, vampire taps were a mainstay of thick coax Ethernet, and were the preferred way of connecting end-nodes to the network.</font> <dt><i><font face="MS Sans Serif" size="3">inductance taps</font></i> <dd><font face="MS Sans Serif" size="3">Most taps can be detected with TDR (Time Domain Reflectometer) equipement. Inductance taps do change the cable in any way, but instead site on the outside and monitor the electromagnetic noise emitted by the cables. Only used by spies.</font></dd> </dl> <p><font face="MS Sans Serif" size="3">The problem with tapping into the cable, especially those between switches, is that they generate huge amounts of traffic. Most NIDS cannot handle very high loads before going "blind".</font> <p><font face="MS Sans Serif" size="3">Thanks to Christopher Zarcone < czarcone at acm dot org > for this info.</font></p> <dt>  <h3><font face="MS Sans Serif" size="3">Host-based sensors</font></h3> <dd><font face="MS Sans Serif" size="3">From a conceptual point of view, the only way to defeat the resource limitations of switched networks is to distribute host-based intrusion detection. Several host-based agents, such as BlackICE and CyberCop Monitor, contain a network-based component that monitors only that host's traffic. Others do the traditional logfile and audit analysis.</font></dd> </dl> <dt>  <h2><a name="9.2"><font face="MS Sans Serif" size="3">9.2 Resource limitations</font></a></h2> <dd> <p><font face="MS Sans Serif" size="3">Network intrusion detection systems sit at centralized locations on the network. They must be able to keep up with, analyze, and store information generated by potentially thousands of machines. It must emulate the combined entity of all the machines sending traffic through its segment. Obviously, it cannot do this fully, and must take short cuts.</font> <p><font face="MS Sans Serif" size="3">This section lists some typical resource issues.</font> <p>  <dl> <dt>  <h3><a name="9.2.1"><font face="MS Sans Serif" size="3">9.2.1 Network traffic loads</font></a></h3> <dd><font face="MS Sans Serif" size="3">Current NIDS have trouble keeping up with fully loaded segments. The average website has a frame size of around 180-bytes, which translates to about 50,000 packets/second on a 100-mbps Ethernet. Most IDS units cannot keep up with this speed. Most customers have less than this, but it can still occasionally be a concern.</font> <p><font face="MS Sans Serif" size="3">When buying an IDS, ask the vendor how many packets/second the system can handle. Many vendors will try to tell you how many bits/second, but per-packet is the real performance bottleneck. Virtually all vendors can handle 100-mbps traffic using 1500-byte packets, few can handle 100-mbps traffic using 60-byte packets.</font></p> <dt>  <h3><a name="9.2.2"><font face="MS Sans Serif" size="3">9.2.2 TCP connections</font></a></h3> <dd><font face="MS Sans Serif" size="3">IDS must maintain connection state for a large number of TCP connections. This requires extensive amount of memory. The problem is exacerbated by evasion techniques, often requiring the IDS to maintain connection information even after the client/server have closed it.</font> <p><font face="MS Sans Serif" size="3">When buying an IDS, ask the vendor how many simultaneous TCP connections it can handle.</font></p> <dt>  <h3><a name="9.2.3"><font face="MS Sans Serif" size="3">9.2.3 Other state information</font></a></h3> <dd><font face="MS Sans Serif" size="3">TCP is the simplest example of state information that must be kept by the IDS in memory, but other examples include IP fragments, TCP scan information, and ARP tables.</font> <dt>  <h3><a name="9.2.4"><font face="MS Sans Serif" size="3">9.2.4 Long term state</font></a></h3> <dd><font face="MS Sans Serif" size="3">A classic problem is "slow scans", where the attacker scans the system very slowly. The IDS is unable to store that much information over that long a time, so is unable to match the data together.</font></dd> </dl> <dt>  <h2><a name="9.3"><font face="MS Sans Serif" size="3">9.3 Attacks against the NIDS</font></a></h2> <dd> <p><font face="MS Sans Serif" size="3">The intrusion detection system itself can be attacked in the following ways.</font> <dl> <dt>  <h3><a name="9.3.1"><font face="MS Sans Serif" size="3">9.3.1 Blind the sensor</font></a></h3> <dd> <p><font face="MS Sans Serif" size="3">Network intrusion detection systems are generally built as "passive monitors" from COTS (commercial-off-the-shelf) computers. The monitors are placed alongside the networking stream, not in the middle. This means that if they cannot keep up with the high rates of traffic, they have no way to throttle it back. They must start dropping packets. This is known as trying to drink from a firehose. Few NIDS today can keep up with a fully saturated 100-mbps link (where "saturated" means average sized packets of 180 bytes, which is roughly 50,000 packets/second).</font> <p><font face="MS Sans Serif" size="3">Not only will the sensor start dropping packets is cannot process, high traffic rates can completely shut down the sensor. For example, consider a sensor that can process a maximum of 20,000 frames/second. When the proferred load is 40,000 frames/second, it usually drops actual processing down to 10,000 frames/second or 5,000 frames/second, or maybe even zero. This is because frame reception and frame analysis are two different acitivities. Most architectures require the system to capture the packet even when it is too busy to analyze it, which takes even more time away from analysis.</font> <p><font face="MS Sans Serif" size="3">Therefore, an intruder can attack the sensor by saturating the link. If the intruder is local, he/she can simply use a transmit program. A 400-Mhz box can fully saturate a link with 60-byte packets, breaking most IDS systems that might be attached to the system.</font> <p><font face="MS Sans Serif" size="3">A remote attacker can execute smurf or fraggle attacks, likewise saturating links. It is unlikely an attacker will have a fast enough link themselves (100-mbps is quite rare) in order to be able to attack head-on in this manner.</font></p> <dt>  <h3><a name="9.3.2"><font face="MS Sans Serif" size="3">9.3.2 Blind the event storage (snow blind)</font></a></h3> <dd> <p><font face="MS Sans Serif" size="3">The 'nmap' port scanning tool contains a feature known as "decoy" scans. It scans using hundreds of spoofed source addresses as well as the real IP address of the attacker. It therefore becomes an improbable task for the administrator to find discover which of the IP addresses was real, and which was one of the decoy addresses.</font> <p><font face="MS Sans Serif" size="3">Any attack can be built from the same components. A massive attack with spoofed addresses can always hide a real attack inserted somewhere inside. Administrators would be hard pressed to discover the real attack inside of all that noise.</font> <p><font face="MS Sans Serif" size="3">These two scenarios still retain forensics data, though. If the attacker is suspected, the data is still there to find. Another attack is to fill up event storage. When the database fills up, no more attacks will be discovered, or older attacks will be deleted. Either way, no evidence exists anywhere that will point to the intruder.</font></p> <dt>  <h3><a name="9.3.3"><font face="MS Sans Serif" size="3">9.3.3 DoS (Denial of Service)</font></a></h3> <dd> <p><font face="MS Sans Serif" size="3">A NIDS is an extremely complex system, equivelent in complexity to an entire TCP/IP stack running numerous services. This means the NIDS is susceptible to such attacks as SYN floods and smurf attacks.</font> <p><font face="MS Sans Serif" size="3">Moreover, the numerous protocols NIDS analyze leave them open to outright crashes when unexpected traffic is seen. Attackers can often buy the same intrusion detection systems used by their victim, then experiment in many ways in order to find packets that will kill the IDS. Then during the attack, the intruder kills the IDS, then continues undetected.</font></p> </dd> </dl> <dt>  <h2><a name="9.4"><font face="MS Sans Serif" size="3">9.4 Simple evasion</font></a></h2> <dd> <p><font face="MS Sans Serif" size="3">This section describes simple evasion tactics that fool basic intrusion detection systems. The next section will describe advanced measures.</font> <dl> <dt>  <h3><a name="9.4.1"><font face="MS Sans Serif" size="3">9.4.1 Fragmentation</font></a></h3> <dd><font face="MS Sans Serif" size="3"><a class="dict" href="http://www.robertgraham.com/pubs/hacking-dict.html#fragment">Fragmentation</a> is the ability to break up a single IP packet into multiple smaller packets. The receiving TCP/IP stack then reassembles the data back again before forwarding the data back up to the application. Most intrusion detection systems do not have the ability to reassemble IP packets. Therefore, there exist simple tools (like <a href="#fragrouter">fragrouter</a>) that can auto-fragment attacks in order to evade IDS.</font> <p><font face="MS Sans Serif" size="3">Note that fragmenting the IP packets in the middle of the TCP header has long been used to evade firewall port filtering.</font> <p><font face="MS Sans Serif" size="3">Some industrial grade NIDS can reassemble traffic. Also, some firewalls can "normalize" traffic by forcing reassembly before passing the traffic through to the other end.</font></p> <dt>  <h3><a name="9.4.2"><font face="MS Sans Serif" size="3">9.4.2 Avoiding defaults</font></a></h3> <dd><font face="MS Sans Serif" size="3">People often use firewalls as easy NIDS, where they make assumptions that the destination port uniquely identifies the protocol. A hacker who successfully installs a backdoor can run standard protocols on non-default ports. For example, a hacker may send a user a Back Orifice infected program, but change the port from the default of 31337. Most intrusion detection systems will no longer identify the traffic correctly (though a few do).</font> <dt>  <h3><a name="9.4.3"><font face="MS Sans Serif" size="3">9.4.3 Slow scans</font></a></h3> <dd><font face="MS Sans Serif" size="3">Because of the volume of traffic on the wire, NIDS have difficulty maintaining long-term traffic logs. It is therefore difficult to detect "slow scans" (ping sweeps or port-scans) where intruders scan one port/address every hour.</font> <dt>  <h3><a name="9.4.4"><font face="MS Sans Serif" size="3">9.4.4 Coordinated, low-bandwidth attacks</font></a></h3> <dd><font face="MS Sans Serif" size="3">Sometimes hackers get together and run a slow scan from multiple IP addresses. This make it difficult for an intrusion detection system to correlate the information.</font> <dt>  <h3><a name="9.4.5"><font face="MS Sans Serif" size="3">9.4.5 Address spoofing/proxying</font></a></h3> <dd><font face="MS Sans Serif" size="3">One goal of intrusion detection is to point fingers at who is attacking you. This can be difficult for a number of reasons. In 'Smurf' attack, for example, you receive thousands of replies from a packet that you never sent. The NIDS and detect those replies, but cannot discover who sent the forged packet. In TCP Sequence Number Prediction, forged IP addresses are used so that the NIDS does not know precisely where the intruder is coming from. Finally, most intruders will 'bounce' their attacks via FTP or Web proxies, or stage their attacks from other sites they have broken into. Thus, it will be very difficult to find out who is attacking your site, and configuring IP address filters in your firewall won't help.</font> <dt>  <h3><a name="9.4.6"><font face="MS Sans Serif" size="3">9.4.6 Pattern change evasion</font></a></h3> <dd><font face="MS Sans Serif" size="3">Many simple network intrusion detection systems rely upon "pattern matching". Attack scripts have well know patterns, so simply compiling a database of the output of known attack scripts provides pretty good detection, but can easily be evaded by simply changing the script.</font> <p><font face="MS Sans Serif" size="3">For example, some POP3 servers are vulnerable to a buffer overflow when a long password is entered. There exist several popular attack scripts for this vulnerability. One intrusion detection system might contain 10 patterns to match match the 10 most common scripts, while another intrusion detection system looks at the password field and alarms when more than 100 bytes have been entered. The first system is easy to evade simply by changing the attack script, while the second system catches any attack on this point.</font> <p><font face="MS Sans Serif" size="3">The typical example is simple changes to the URL. For example, this document can be retrieved through the URL: <a href="http://www.robertgraham.com/pubs/./network-intrusion-detection.html">http://www.robertgraham.com/pubs/./network-intrusion-detection%2Ehtml</a>. Even though the exact pattern has changed, the <i>meaning</i> hasn't been altered. A NIDS looking for the original URL on the wire won't detect this alered one unless it has anti-evasion countermeasures.</font></p> </dd> </dl> <dt>  <h2><a name="9.5"><font face="MS Sans Serif" size="3">9.5 Complex evasion</font></a></h2> <dd><font face="MS Sans Serif" size="3">Talented hackers can direct their attacks at their victims in ways to bypass intrusion detection systems. An early paper by Vern Paxson on his NIDS called "Bro" describes some of these problems. The original PostScript version is at <a href="ftp://ftp.ee.lbl.gov/papers/bro-usenix98-revised.ps.Z">ftp://ftp.ee.lbl.gov/papers/bro-usenix98-revised.ps.Z</a>.</font> <p><font face="MS Sans Serif" size="3">The seminal paper on network intrusion detection "evasion" was written by <a href="http://www.enteract.com/~tqbf/">Thomas H. Ptacek</a> and Timothy N. Newsham. The original PostScript version is available at <a href="http://www.aciri.org/vern/Ptacek-Newsham-Evasion-98.ps">http://www.aciri.org/vern/Ptacek-Newsham-Evasion-98.ps</a>, while an HTML mirror is available at <a href="http://www.robertgraham.com/mirror/Ptacek-Newsham-Evasion-98.html">http://www.robertgraham.com/mirror/Ptacek-Newsham-Evasion-98.html</a>. Thomas H. Ptacek claims that many/most of the commercial products still (October 1999) have serious problems in this regard. Much this this section summarizes these two papers.</font> <p><font face="MS Sans Serif" size="3">These papers describe the abstract concept that the network model used by the network intrusion detection system is different than the real world.</font> <p><font face="MS Sans Serif" size="3">For example, an intruder might send a TCP FYN packet that the NIDS sees, but which the victim host never sees. This causes the NIDS to believe the connection is closed, but when in fact it isn't. Since TCP connections do not send "keep-alives", the intruder could wait hours or days after this "close" before continuing the attack. In practice, most interesting services do kill the connection after a certain time with no activity, but the inruder still can cause a wait of several minutes before continuing.</font> <p><font face="MS Sans Serif" size="3">The first such attack is to find a way to pass packets as far as the NIDS, but cause a later router to drop packets. This depends upon the router configuration, but typical examples include low TTL fields, fragmentation, source routing, and other IP options. If there is a slow link past the NIDS, then the hacker can flood the link with high priority IP packets, and send the TCP FIN as a low priority packet -- the router's queuing mechanism will likely drop the packet.</font> <p><font face="MS Sans Serif" size="3">Another approach is to consider what the host will or will not accept. For example, different TCP stacks behave differently to slightly invalid input (which programs like 'nmap' and 'queso' use to fingerprint operating systems). Typical ways of causing different traffic to be accepted/rejected is to send TCP options, cause timeouts to occur for IP fragments or TCP segments, overlap fragments/segments, send slight wrong values in TCP flags or sequence numbers.</font> <p><font face="MS Sans Serif" size="3">The Ptacek/Newsham paper concentrated on IP fragmentation and TCP segmentation problems in order to highlight bugs in IDSs. For example, they noted that if overlapping fragments are sent with different data, some systems prefer the data from the first fragment(WinNT, Solaris), whereas others keep the data from the last fragment (Linux, BSD). The NIDS has no way of knowing which the end-node will accept, and may guess wrong.</font> <p><font face="MS Sans Serif" size="3">Their TCP connection analysis was even more in depth, discussing ways of "de-synchronizing" TCP connections, which are much more fragile than one would think. Again, the IDS cannot correctly model all possible TCP/IP stack behavior and figure out what the end-node will accept as data. TCP also has the overlap problems that IP fragmentation has. For example, intrusion detection systems might accept the first segment and ignore later segments, but most hosts accept the later segmetns.</font> <p><font face="MS Sans Serif" size="3">They ran tests against various intrusion detection systems in order to figure out if they could evade intrusion detection systems. Their results were dismal -- one major intrusion detection system could be completely evaded simply by fragmenting packets, others could be thrown off by "desynchronizing" from the data the end-node would accept.</font> <p><font face="MS Sans Serif" size="3"> </font></p> <dt>  <h2><a name="9.9"><font face="MS Sans Serif" size="3">9.9 Tools</font></a></h2> <dd><font face="MS Sans Serif" size="3">The following tools may help in evaluating IDS systems for these problems.</font> <dl> <dt><font face="MS Sans Serif" size="3">Anzen <a name="nidsbench">NIDSbench</a></font> <dd><font face="MS Sans Serif" size="3"><a href="http://www.anzen.com/research/nidsbench/">http://www.anzen.com/research/nidsbench/</a>.</font> <p><font face="MS Sans Serif" size="3">Contains the "<a name="fragrouter">fragrouter</a>" that forces all traffic to fragment, which demonstrates how easy it is for hackers/crackers to do the same in order to evade intrusion detection. This accepts incoming traffic then fragments it according to various rules (IP fragmentation with various sizes and overlap, TCP segmentation again with various sizes and overlaps, TCP insertion in order to de-synchronize the connection, etc.).</font> <p><font face="MS Sans Serif" size="3">Also contains the "<a href="http://secinf.net/info/misc/tcpreplay">tcpreplay</a>" program, which dumps high loads onto an Ethernet segment in order to veriy a NIDS can keep up.</font></p> <dt><font face="MS Sans Serif" size="3">CASL</font> <dd><font face="MS Sans Serif" size="3">NAI's CyberCop Scanner comes with CASL built in. This was used in the Insertion/Evasion paper above to carry out validation tests. It allows scripting of low-level TCP/IP packets.</font> <p><font face="MS Sans Serif" size="3">Some scripts for CASL are at: <a href="http://www.roses-labs.com/labs/labs.htm">http://www.roses-labs.com/labs/labs.htm</a></font></p> </dd> </dl> <dt>  <h1><a name="10."><font face="MS Sans Serif" size="3">10. Misc.</font></a></h1> <dd>  <dt>  <h2><a name="10.1"><font face="MS Sans Serif" size="3">10.1 What are some standardization/interoperability efforts?</font></a></h2> <dd> <dl> <dt>  <h3><a name="10.1.1"><font face="MS Sans Serif" size="3">10.1.1 COAST audit trails format</font></a></h3> <dd><font face="MS Sans Serif" size="3">A much more narrowly defined effort that solves a specific problem. Hasn't produce proposals yet. See <a href="http://www.cs.purdue.edu/coast/projects/audit-trails-format.html">http://www.cs.purdue.edu/coast/projects/audit-trails-format.html</a></font> <dt>  <h3><a name="10.1.2"><font face="MS Sans Serif" size="3">10.1.2 Universal Format for Logger Messages</font></a></h3> <dd><font face="MS Sans Serif" size="3">See <a href="http://www.ietf.org/internet-drafts/draft-abela-ulm-04.txt">http://www.ietf.org/internet-drafts/draft-abela-ulm-04.txt</a></font> <dt>  <h3><a name="10.1.3"><font face="MS Sans Serif" size="3">10.1.3 IETF Intrusion Detection Working Group</font></a></h3> <dd><font face="MS Sans Serif" size="3">Charter: <a href="http://www.ietf.org/html.charters/idwg-charter.html">http://www.ietf.org/html.charters/idwg-charter.html</a><br> Archive: <a href="http://www.semper.org/idwg-public/">http://www.semper.org/idwg-public/</a><br> Subscribe: <a href="http://secinf.net/info/misc/idwg-public-request@zurich.ibm.com">idwg-public-request@zurich.ibm.com</a></font> <dt>  <h3><a name="10.1.4"><font face="MS Sans Serif" size="3">10.1.4 CIDF (Common Intrusion Detection Framework)</font></a></h3> <dd><font face="MS Sans Serif" size="3">Has specified a lisp-like format for messages between "Event Generators", "Event Analyzers", "Event Databases", and "Response Units". Currently very theoretical with little industry input.</font> <dt>  <h3><a name="10.1.5"><font face="MS Sans Serif" size="3">10.1.5 SAF (Security Advisory Format)</font></a></h3> <dd><font face="MS Sans Serif" size="3">An attempt to standardize security advisories, such as those that come from CERT, the FBI, etc. <a href="http://www.ietf.org/internet-drafts/draft-debeaupuis-saf-00.txt">http://www.ietf.org/internet-drafts/draft-debeaupuis-saf-00.txt</a></font> <dt>  <h3><font face="MS Sans Serif" size="3"><a name="10.1.6">10.1.6</a> Mitre's <a name="cve">CVE effort</a></font></h3> <dd><font face="MS Sans Serif" size="3">"Common Vulnerabilities and Exposures (CVE)" - aims to standardize the names for all publicly known vulnerabilities and security exposures. While this is primarily an academic effort, it does have some vendor input from the major vulnerability assessment and IDS vendors.</font> <p><font face="MS Sans Serif" size="3">The CVE effort is best thought of as a "concordance": it allows people to sync up between the various advisories and IDS/scanner checks. It solves the problem that different products detect such things differently. For example, one intrusion detection system might detect a buffer overflow by examining the length of a field, and therefore map to multiple CVE entries and advisories for different products that have buffer overflows in the same field. Likewise, another IDS system might match the signatures of specific exploits (from published scripts) of a single vulnerability.</font> <p><font face="MS Sans Serif" size="3">Therefore, there might be one-to-many, many-to-one, or many-to-many mappings between any product or set of advisories. The CVE provides a concordance between various systems.</font> <p><a href="http://www.cve.mitre.org/"><font face="MS Sans Serif" size="3">http://www.cve.mitre.org/</font></a></p> </dd> </dl> <dt>  <h1><a name="11."><font face="MS Sans Serif" size="3">11. Honeypots and Deception Systems</font></a></h1> <dd><font face="MS Sans Serif" size="3">While not strictly sniffer-based intrusion detection systems, honeypots still process network protocols in much the same ways. Therefore, I've decided to add this section to my FAQ.</font> <dt>  <h2><a name="11.1"><font face="MS Sans Serif" size="3">11.1 What is a honeypot?</font></a></h2> <dd><font face="MS Sans Serif" size="3">A <i>honeypot</i> is a system designed to look like something that an intruder can hack. Examples can be:</font> <ul> <li><font face="MS Sans Serif" size="3">Installing a machine on the network with no particular purpose other than to log all attempted access.</font> <li><font face="MS Sans Serif" size="3">Installing an older unpatched operating system on a machine. For example, the default installation of WinNT 4 with IIS 4 can be hacked using several different techniques. A standard intrusion detection system can then be used to log hacks directed against the machine, and further track what the intruder attempts to do with the system once it is compromised.</font> <li><font face="MS Sans Serif" size="3">Install special software designed for this purpose. It has the advantage of making it look like the intruder is successful without really allowing them access.</font> <li><font face="MS Sans Serif" size="3">Any existing system can be "honeypot-ized". For example, on WinNT, it is possible to rename the default "administrator" account, then create a dummy account called "administrator" with no password. WinNT allows extensive logging of a person's activities, so this honeypot will track users attempting to gain adminstrator access and exploit that access.</font></li> </ul> <dt>  <h2><a name="11.2"><font face="MS Sans Serif" size="3">11.2 What are the advantages of a honeypot?</font></a></h2> <dd> <ul> <li><font face="MS Sans Serif" size="3">An early-alarm that will trip only upon hostile activity. Network intrusion detection systems have a problem distinguishing hostile traffic from benign traffic. Isolated honeypots have a much easier time because they are systems that should not normally be accessed. This means that <i>all</i> traffic to a honeypot system is already suspect. Network management discovery tools and vulnerability assessment tools still cause false positives, but they otherwise give a better detection rate.</font> <li><font face="MS Sans Serif" size="3">A hostile-intent assessment system. Honeypots often present themselves as easily hacked systems. One of the most common things hackers do is scan the Internet doing "<a href="http://www.robertgraham.com/pubs/hacking-dict.html#banner">banner checks</a>". The honeypot can be setup to provide a banner that looks like a system that can easily be hacked, then to trigger is somebody actually does the hack. For example, the POP3 service reports the version of the software. Several versions of well-known packages have buffer-overflow holes. A hacker connections to <a href="http://www.robertgraham.com/pubs/firewall-seen.html#port110">port 110</a>, grabs the version info from the banner, then looks up the version in a table that points to which exploit script can be used to break into the system.</font></li> </ul> <dt>  <h2><a name="11.3"><font face="MS Sans Serif" size="3">11.3 What are the disadvantages of a honeypot?</font></a></h2> <dd> <ul> <li><font face="MS Sans Serif" size="3">If the system does indeed get hacked, it can be used as a stepping stone to further compromise the network.</font> <li><font face="MS Sans Serif" size="3">Some people believe that since honeypots lure hackers in, that legal rights to prosecute hackers are reduced. This is a misconception, because honeypots are not active lures -- they do not advertise themselves. A hacker can only find a honeypot in the first place by running search programs on a network.</font> <li><font face="MS Sans Serif" size="3">Honeypots add complexity. In security, complexity is bad: it leads to increased exposure to exploits.</font> <li><font face="MS Sans Serif" size="3">Honepots must be maintained just like any other networking equipment/services. This leads many people to turn them off after a while. You think that a 468 running RedHat Linux 4.2 that you setup 2 years ago doesn't require maintainance, but in reality it does. How do you know the logging is working right? What do you do when a new network management platform or vulnerability assessment system starts being used and alarmas start going off? What do you do when alarms stop coming in because a hacker has compromised the system and is using it launch other attacks against you (or worse, back out to the Internet)?</font></li> </ul> <dt>  <h2><a name="11.4"><font face="MS Sans Serif" size="3">11.4 How can I setup my own honepot?</font></a></h2> <dd><font face="MS Sans Serif" size="3">The thing to remember is that setting up honepots is really easy. While honeypot products are cool, virtually any existing hardware/software can be setup to be your honeypot.</font> <p><font face="MS Sans Serif" size="3">Your gameplan should consist of the following steps:</font> <dl> <dt><font face="MS Sans Serif" size="3">documentation, documentation, documentation</font> <dd><font face="MS Sans Serif" size="3">The first step in any network management endeavor (actually, the last step when people discover the pain of not having done it in the first place).</font> <dt><font face="MS Sans Serif" size="3">maintainance plan</font> <dd><font face="MS Sans Serif" size="3">How do you plan on maintaining it?</font> <dt><font face="MS Sans Serif" size="3">alarm reporting</font> <dd><font face="MS Sans Serif" size="3">How do you plan on receiving alarms from the system?</font> <dt><font face="MS Sans Serif" size="3">reaction plan</font> <dd><font face="MS Sans Serif" size="3">What do you plan on doing when an alarm goes off?</font></dd> </dl> <dt>  <h2><a name="11.5"><font face="MS Sans Serif" size="3">11.5 What are the types of honeypots?</font></a></h2> <dd> <dl> <dt><font face="MS Sans Serif" size="3">Port monitors</font> <dd><font face="MS Sans Serif" size="3">The simplest honeypot is simply a <a href="http://www.robertgraham.com/pubs/hacking-dict.html#sockets">sockets</a>-based programme that opens up a listening port. A typical example of this is the programme <i>NukeNabber</i> (for Windows) that listens on ports typically scanned for by hackers. This alerts the user that they are being scanned. The disadvantage of these programs are:</font> <ul> <li><font face="MS Sans Serif" size="3">In most cases where they are used, it is actually better to setup a personal firewall to block access from the attacker. Port monitors don't log any better than firewall would.</font> <li><font face="MS Sans Serif" size="3">They alert the hacker that such a system is running because they first accept, then drop, the connection.</font></li> </ul> <dt><font face="MS Sans Serif" size="3">Deception systems</font> <dd><font face="MS Sans Serif" size="3">The next logical step beyond the port monitor is a system that actually interacts with the hacker. For example, rather than simply accepting <a href="http://www.robertgraham.com/pubs/firewall-seen.html#port110">port 110</a> for POP3, then dropping it, a deception system will actually respond as if it were a POP3 server. It may give a generic banner, or it may generate a banner with a version number that hackers know they can hack. Since 99% of attacks against POP3 are buffer-overruns in the username or passwords, most deception systems only implement that portion of the protocol. Likewise, most deception systems implement only as much of the protocol machine as necessary to trap 90% of the attacks against the protocol.</font> <dt><font face="MS Sans Serif" size="3">Multi-protocol deception systems</font> <dd><font face="MS Sans Serif" size="3">Packages like Specter or Fred Cohen's Deception Toolkit offer most of the commonly hacked protocols in a single toolkit. Likewise, these systems come with multiple banners in order to emulate packages for different operating systems.</font> <dt><font face="MS Sans Serif" size="3">Full systems</font> <dd><font face="MS Sans Serif" size="3">Beyond products targetted directly at deception, you can also implement full systems. Most systems have the ability to alert on exception conditions. By using the native logging/auditing built into such</font> <dt><font face="MS Sans Serif" size="3">Full systems plus NIDS</font> <dd><font face="MS Sans Serif" size="3">Along with the full system mentioned above, you might want to include a full intrusion detection system to supplement the internal logging.</font></dd> </dl> <dt>  <h2><a name="11.6"><font face="MS Sans Serif" size="3">11.6 What are the pros/cons of setting up a system that can be hacked?</font></a></h2> <dd><font face="MS Sans Serif" size="3">The three most commonly hacked servers on the net are unpatched systems running older Linux (like RedHat 5.0), Solaris 2.6, and Microsoft IIS 4.0. Therefore, as part of your honeypot plan, you might want to setup one or all three of these systems.</font> <p><font face="MS Sans Serif" size="3">Remember: if you put one of these systems on the Internet, within a month it will be discovered and hacked.</font> <p>  <dl> <dt>  <h3><font face="MS Sans Serif" size="3">Pros:</font></h3> <dd> <p> </p> <dt><font face="MS Sans Serif" size="3">Learn about incidence response</font> <dd><font face="MS Sans Serif" size="3">Most people believe "it can't happen to them", and are unprepared when it does. Setting up systems that hackers break into will teach you about how to detect hacker breakins and how to clean up after them.</font> <dt><font face="MS Sans Serif" size="3">Learn about hacking techniques</font> <dd><font face="MS Sans Serif" size="3">Watching hackers break into your system teaches you a lot about hacking.</font> <p><font face="MS Sans Serif" size="3">If you need a secure system inside your company (for example, one that holds financial information), setup a similar system outside your company with bogus data. If a hacker compromises that system, you'll learn how to protect the one inside your company from similar exploits.</font></p> <dt><font face="MS Sans Serif" size="3">Early warning systems</font> <dd><font face="MS Sans Serif" size="3">Setting up servers inside your company that can easily be hacked will alert you to hostile activity long before real systems get compromised. Hackers try the simpler techniques first before moving on to harder ways of breaking into system. Therefore, setting up an easily hacked system will clearly indicate the hostile intent of somebody.</font> <dt>  <h3><font face="MS Sans Serif" size="3">Cons:</font></h3> <dd>  <dt><font face="MS Sans Serif" size="3">Launching Point</font> <dd><font face="MS Sans Serif" size="3">The biggest danger is that somebody could use that system to launch further attacks against either you or other people. In particular, there might be legal considerations when a system you control attacks a third party.</font></dd> </dl> <dt>  <h2><a name="11.7"><font face="MS Sans Serif" size="3">11.7 Are there examples of people using honeypots?</font></a></h2> <dd><font face="MS Sans Serif" size="3">The book <a href="http://www.amazon.com/exec/obidos/ASIN/0671726889/robertgrahamcom">The Cuckoo's Egg</a> by <i>Clifford Stoll</i> is an engaging story about a researcher who bumbles his way into tracking down a hacker who was abusing the university's computer systems. The researcher basically left the system open and vulnerable for about a year in order to track the hacker's activities.</font> <p><font face="MS Sans Serif" size="3">The San Diego Supercomputer Center has left machines up that can be hacked. <a href="http://security.sdsc.edu/incidents/worm.2000.01.18.shtml">http://security.sdsc.edu/incidents/worm.2000.01.18.shtml</a></font></p> <dt>  <h2><a name="11.8"><font face="MS Sans Serif" size="3">11.8 What honeypot products are available?</font></a></h2> <dd><font face="MS Sans Serif" size="3">The following are products that I know of.</font> <dl> <dt><font face="MS Sans Serif" size="3">Fred Cohen's Deception Toolkit</font> <dd><a href="http://www.all.net/dtk/"><font face="MS Sans Serif" size="3">http://www.all.net/dtk/</font></a> <dt><font face="MS Sans Serif" size="3">Specter</font> <dd><a href="http://www.specter.ch/"><font face="MS Sans Serif" size="3">http://www.specter.ch/</font></a> <dt><font face="MS Sans Serif" size="3">NAI CyberCop Sting</font> <dd><a href="http://www.nai.com/"><font face="MS Sans Serif" size="3">http://www.nai.com/</font></a> <dt><font face="MS Sans Serif" size="3">netcat</font> <dd><font face="MS Sans Serif" size="3">The netcat tool can be used to respond with deceptive banners.</font></dd> </dl> <dt>  <h2><a name="11.9"><font face="MS Sans Serif" size="3">11.9 What are deception countermeasures?</font></a></h2> <dd><font face="MS Sans Serif" size="3">Beyond honeypots in particular, you can setup "deception countermeasures". Your network "leaks" lots of information about itself, which hackers in turn use to break into your network. Therefore, if you leaks deceptive information about you network, then you'll at minimum misdirect your attackers, but hopefully trigger alerts.</font> <p><font face="MS Sans Serif" size="3">I personally have done the following sorts of things:</font> <dl> <dt><font face="MS Sans Serif" size="3">Email headers</font> <dd><font face="MS Sans Serif" size="3">A classic problem on the web is that email systems insert the IP address of the system sending the message to it. If you are inside a corporation and send email out, you reveal internal email servers. If you are using a free email system like Yahoo mail or Hotmail, the IP address of the machine you used to send the mail is included in the header. This process can go several level deep as email inside companies often travel several hops through gateway, firewalls, and anti-virus content scanners. It's difficult, but you can reprogram things in order to insert bogus IP addresses in to the headers.</font> <dt><font face="MS Sans Serif" size="3">DNS info</font> <dd><font face="MS Sans Serif" size="3">One of the first things a hacker will do against you is a DNS Zone Transfer. Many admins blocks access to TCP port 53 to stop this (though that breaks other DNS services). By inserting bogus machines or even entire bogus subdomains you misdirect the hacker. For example, I could setup a machine called "bogus.robertgraham.com" with an IP address of 192.0.2.132, then tell my IDS to trigger whenever it sees traffic to that address. Since my IDS already triggers on Zone Transfers, this'll catch somebody who is seriously trying to scope out my network.</font> <dt><font face="MS Sans Serif" size="3">anti-sniffers</font> <dd><font face="MS Sans Serif" size="3">Are you certain that your ISP isn't sniffing you? Well, in order to find out, setup machines elsewhere on the Internet to connect to some of your boxes using clear-text passwords. Then setup your IDS to trigger when anybody else uses those passwords. This is best used with a honeypot that doesn't have real services. For example, I've setup a virtual Telnet daemon on that another machines logs into every once-and-a-while. I've setup the IDS to trigger if anybody but that machine logs in using that account name. When they log in, they will soon find out it isn't real account.</font> <dt><font face="MS Sans Serif" size="3">anti-sniffers, part deux</font> <dd><font face="MS Sans Serif" size="3">Similar to above, you can transfer password files across the network that contain easily crackable passwords, then have the IDS trigger whenever anybody attempts to login. For example, setup a batch file that regularly transfers files via FTP, one of which is <a href="http://www.robertgraham.com/pubs/hacking-dict.html#etc-passwd">/etc/passwd</a>. This will tell you if anybody has sniffed that file.</font></dd> </dl> <dt>  <h2><font face="MS Sans Serif" size="3"><a name="11.10">11.10</a> What are the legal implication of honeypots?</font></h2> <dd> <dl> <dt>  <h3><font face="MS Sans Serif" size="3"><a name="11.10.1">11.10.1</a> Do honeypots constitute entrapment?</font></h3> <dd><font face="MS Sans Serif" size="3">No. This is the most commonly asked question about honeypots, and the answer is a clear no. Entrapment has a clear legal definition whereby law enforcement officers encourage somebody to a commit a crime that they were not otherwise disposed to do. This means:</font> <ul> <li><font face="MS Sans Serif" size="3">If you are not a law enforcement officer, you cannot entrap.</font> <li><font face="MS Sans Serif" size="3">Affording the means for somebody to commit a crime is not the same as encouraging the crime. The FBI can setup a honeypot without risk of entrapment.</font> <li><font face="MS Sans Serif" size="3">If the FBI contacts somebody in <a href="news://alt.2600">alt.2600</a> and posts a bounty for cracking into a system, then it <i>would</i> be entrapment.</font> <li> </li> </ul> </dd> </dl> </dd> </dl> <p>  <p align="left"><font face="Verdana" size="2"><br> </font><a href="http://www.mobrien.com/enter.html"><font face="Arial" size="2">Site Map</font></a><font face="Arial" size="2"> ~ <a href="http://www.mobrien.com/index.html">Home</a> ~ <a href="http://www.mobrien.com/advice1.html">Tell Us Yor Problem</a> ~ <a href="http://www.mobrien.com/legal.html">Site Legal Notice</a> ~ <a href="http://www.mobrien.com/services.html">What Can We Do</a> ~ <a href="http://www.mobrien.com/network.html">Network Security</a> ~ <a href="http://www.mobrien.com/angelfire.html">Tools</a> ~ <a href="http://www.mobrien.com/firewall.html">Understanding Firewalls</a> ~ <a href="http://www.mobrien.com/index.htm">VIP Protection</a> ~ <a href="http://www.mobrien.com/Kretz-TorSun.html">Case Files</a> ~ <a href="http://www.mobrien.com/backgrnd.html">Background Checks</a> ~ <a href="http://www.mobrien.com/helos.htm">Air Services</a> ~ <a href="http://www.mobrien.com/helos_1.htm">Helo Types</a> ~ <a href="http://www.mobrien.com/diy.html">Catching Cheaters</a> ~ <a href="http://www.mobrien.com/pdo.html">Personality Disorders</a> ~ <a href="http://www.mobrien.com/commentary.htm">Child Murderers</a> ~ <a href="http://www.mobrien.com/index-2.htm">About: Investigators</a> ~ <a href="http://www.mobrien.com/help.html">Email Help</a> ~ <a href="http://www.mobrien.com/search.html">Site Search</a> ~ <a href="http://www.mobrien.com/twr.htm">Global Security Publication</a> ~ <a href="http://www.mobrien.com/home.html">Security Links</a> ~ <a href="http://www.mobrien.com/links.html">More Links</a> ~ <a href="http://www.mobrien.com/comments.html">Your Comments</a></font> <font face="Arial" size="2">~ <a href="http://www.mobrien.com/index.html">Home</a> ~ <a href="http://www.mobrien.com/advice1.html">Tell Us Yor Problem</a> ~ <a href="http://www.mobrien.com/legal.html">Site Legal Notice</a> ~ <a href="http://www.mobrien.com/services.html">What Can We Do</a> ~ <a href="http://www.mobrien.com/network.html">Network Security</a> ~ <a href="http://www.mobrien.com/angelfire.html">Tools</a> ~ <a href="http://www.mobrien.com/firewall.html">Understanding Firewalls</a> ~ <a href="http://www.mobrien.com/index.htm">VIP Protection</a> ~ <a href="http://www.mobrien.com/Kretz-TorSun.html">Case Files</a> ~ <a href="http://www.mobrien.com/backgrnd.html">Background Checks</a> ~ <a href="http://www.mobrien.com/helos.htm">Air Services</a> ~ <a href="http://www.mobrien.com/helos_1.htm">Helo Types</a> ~ <a href="http://www.mobrien.com/diy.html">Catching Cheaters</a> ~ <a href="http://www.mobrien.com/pdo.html">Personality Disorders</a> ~ <a href="http://www.mobrien.com/commentary.htm">Child Murderers</a> ~ <a href="http://www.mobrien.com/index-2.htm">About: Investigators</a> ~ <a href="http://www.mobrien.com/help.html">Email Help</a> ~ <a href="http://www.mobrien.com/search.html">Site Search</a> ~ <a href="http://www.mobrien.com/twr.htm">Global Security Publication</a> ~ <a href="http://www.mobrien.com/home.html">Security Links</a> ~ <a href="http://www.mobrien.com/links.html">More Links</a> ~ <a href="http://www.mobrien.com/comments.html">Your Comments</a></font><font face="Verdana" size="2"><br> </font> <p align="center"><font face="MS Sans Serif" size="2"> <a href="advice1.html" target="_top">Contact us</a> | <a href="firewall_r.html">Firewalls</a> | <a href="windows_nt_wardoc.htm">NT Penetration</a> | <a href="web.html">Web Services</a> | <a href="computer_crime.shtml">Computer Crime</a> | <a href="terminology.shtml">Terminology</a> | <b> <a href="ui.html" target="_top">Index</a></b> </font></p> </body>