An intrusion 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
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:
network intrusion detection
systems (NIDS) 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).
system integrity verifiers (SIV)
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.
log file monitors (LFM)
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
deception systems (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 The
Deception ToolKit http://www.all.net/dtk/
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 http://www.enteract.com/~lspitz/honeypot.html
For more info, see http://www.icsa.net/idswhite/.
- There are two words to describe the
intruder: hacker and cracker. 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.
Intruders can be classified into two
- 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 Internet, dial-up lines, physical
break-ins, or from partner (vendor, customer, reseller, etc.)
network that is linked to your corporate network.
- Intruders that legitimately use
your internal network. These include users who misuse priviledges
(such as the Social Security employee who marked someone as being dead
because they didn't like that person) or who impersonate higher
privileged users (such as using someone else's terminal). A frequently
quoted statistic is that 80% of security breaches are committed by
There are several types of intruders Joy
riders hack because they can. Vandals are intent on causing
destruction or marking up your web-pages. Profiteers are intent on
profiting from their enterprise, such as rigging the system to give them
money or by stealing corporate data and selling it.
- The primary ways a intruder can get
into a system:
Physical Intrusion 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
System Intrusion 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.
Remote Intrusion 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
Note that Network Intrusion Detection
Systems are primarily concerned with Remote Intrusion.
- 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.
- 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:
Buffer overflows: 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
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 "
| mail < /etc/passwd".
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.
Unhandled input: Most
programs are written to handle valid input. Most programmers do not
consider what happens when somebody enters input that doesn't match the
Race conditions: 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
- System configuration bugs can be
classified in the following manner:
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.
Lazy administrators: 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
Hole creation: 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.
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.
- This is a special category all to
Really weak passwords:
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.
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.
Brute force attacks:
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).
Shared medium: 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.
Server sniffing: 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.
Remote sniffing: 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.
- 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.
TCP/IP protocol flaws: 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.
UNIX design flaws: 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,
- Intruders get passwords in the
Clear-text sniffing: 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.
Encrypted sniffing: 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.
Replay attack: 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 file stealing: The
entire user database is usually stored in a single file on the disk. In
UNIX, this file is
/etc/passwd (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.
Observation: 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.
Social Engineering: 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 :-)
A typical scenario might be:
Step 1: outside reconnaissance
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
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.
Step 2: inside reconnaisance
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.
Step 3: exploit 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.
Step 4: foot hold 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.
Step 5: profit 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
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).
- There are three types of attacks:
reconnaisance 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.
exploits Intruders will take
advantage of hidden features or bugs to gain access to the system.
denial-of-service (DoS) attacks
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.
- 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).
- 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.
Web server often have bugs
related to their interaction with the underlying operating system.
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.
Servers have long had problems
with URLs. 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.
- 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
URL 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
HTTP headers can be used
to exploit bugs because some fields are passed to functions that expect
only certain information.
HTML can be often
exploited, such as the MIME-type overflow in Netscape Communicator's
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.
Frames are often used as
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.
Java 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
ActiveX 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.
- 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.
- Failed login attempts, failed file
access attempts, password cracking, administrative powers abuse
- 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
- 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.
IP spoofing is frequently used as
part of other attacks:
- 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
- TCP sequence number
- 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.
poisoning through sequence prediction
- 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.
- Some other buffer overflow attacks
- Where an overly long DNS name
is sent to a server. DNS names are limited to 64-bytes per
subcomponent and 256-bytes overall.
- statd overflow
- where an overly long filename
- DNS is a prime target because if
you can corrupt the DNS server, you can take advantage of trust
- DNS cache poisoning
- 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.
- DNS poisoning through
- See above
- DNS overflow
- See above
- 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.
- 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.
- 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.
- 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.
- Tries to log on with accounts
- Accounts with no passwords
- Accounts with password same as
username, or "password".
- Default accounts that were
shipped with the product (a common problem on SGI, done to make
- Accounts installed with
software products (common on Microsoft as well as Unix, caused by
products that run under their own special user account).
- Anonymous FTP problems (CWD
- Scan for rlogin/rsh/rexec
ports, that may supported trusted logins.
- Sends an invalid fragment, which
starts before the end of packet, but extends past the end of the packet.
- 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.
- Sends forged SYN packet with
identical source/destination address/port so that system goes into
infinite loop trying to complete the TCP connection.
- Sends OOB/URG data on a TCP
connection to port 139 (NetBIOS Session/SMB), which cause the Windows
system to hang.
- 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.
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.
There is a good paper http://www.cert.org/research/JHThesis/Start.html
by John D. Howard that discusses how much hacking goes on over the Internet,
and how much danger you are in.
- CyberNotes by NIPC (http://www.fbi.gov/nipc/welcome.htm)
- 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.
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
- AusCERT Consolidated Statistics
- A project to collect intrusion
statistics from around the web and consolidate them. They want people to
join and send them info.
- An Analysis Of Security Incidents
On The Internet 1989 - 1995 (http://www.cert.org/research/JHThesis/Start.html)
- A dissertation by John D. Howard,
Carnegie Mellon University
- CERT Reports, Articles, and
- CERT has a number of historical
statistics on intrusions, but they aren't nearly as up-to-date as the
- 1999 CSI-DBI Survey (http://www.gocsi.com/summary.htm)
- CSI (Computer Security Institute)
does a number of surveys about intrusions and security
- 2.1.1 Anomaly detection
- 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.
The benefit of this approach is
that it can detect the anomalies without having to understand the
underlying cause behind the anomalies.
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.
- 2.1.2 Signature recognition
- 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.
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.
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
Protocol stack verification 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.
Application protocol verification
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
Creating new loggable events 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.
- Reconfigure firewall
- 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.
- Beep or play a .WAV file. For
example, you might hear a recording "You are under attack".
- SNMP Trap
- Send an SNMP Trap datagram to a
management console like HP OpenView, Tivoli, Cabletron Spectrum, etc.
- NT Event
- Send an event to the WinNT event
- Send an event to the UNIX syslog
- send email
- Send email to an administrator to
notify of the attack.
- Page (using normal pagers) the
- Log the attack
- Save the attack information
(timestamp, intruder IP address, victim IP address/port, protocol
- Save evidence
- Save a tracefile of the raw
packets for later analysis.
- Launch program
- Launch a separate programme to
handle the event.
- Terminate the TCP session
- Forge a TCP FIN packet to force a
connection to terminate.
- 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 last 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.
- 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 and 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.
- VPNs (Virtual Private Networks)
- 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
- 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).
- 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.
- network hosts
- 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.
- network perimeter
- IDS is most effective on the
network perimeter, such as on both sides of the firewall, near
the dial-up server, and on links to partner networks.
These links tend to be low-bandwidth (T1 speeds) such that an IDS can
keep up with the traffic.
- WAN backbone
- 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.
- server farms
- 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.
- LAN backbones
- 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
- Put firewalls between areas of the
network with different security requirements (i.e. between
internet-localnet, between users-servers, between company-parterns,
- Use network vulnerability scanners
to double check firewalls and to find holes that intruders can exploit.
- Use host policy scanners to make
sure they conform to accepted practices (i.e. latest patches).
- Use Network intrusion detection
systems and other packet sniffing utilities to see what is actually
- Use host-based intrusion
detection systems and virus scanners to flag successful intrusions.
- Create an easy to follow policy
that clearly states the response to intrusions.
- A NIDS is essentially a sniffer, so
therefore standard sniffer detection techniques can be used. Such techniques
are explained in http://www.robertgraham.com/pubs/sniffing-faq.html#detect.
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.
- The following lists items that make
WinNT more secure, including detection as well as prevention. These are
roughly listed in order of importance.
- Install the latest service packs
and "hot fixes". These are listed at http://www.microsoft.com/security/.
If you are using WinNT 4.0 and you don't have Service Pack #3 (SP3)
installed, an intruder can break into your system.
- 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.
- 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).
- USRMGR: Create a new account named
"administrator" for detecting intrusion attempts.
- 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.
- NTFS: Disable "write"
access for "Everyone" on the
- REGEDT32: Turn on auditing for
"HKEY_LOCAL_MACHINE\Security" in order to detect remote
- 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.
- 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.
- 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.
- REGEDT32: Turn off automatic
sharing of ADMIN$, C$, D$, etc. via the "AutoShare" parameter
in the registry. This parameter is under
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
- REGEDT32: Turn of account/share
information via anonymous access. Add "RestrictAnonymous"
DWORD with a value of "1" to the registry key
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.
- 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
- 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.
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:
regedit /s \\MY_PDC\netlogon\scrn.reg
And in the file "scrn.reg",
put the text:
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
- 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.
The following are techniques for the
- Install the latest patches (of
- 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
- 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.
- (more forthcoming)
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.
- 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
- Disable internal caching of
REGEDIT /s \\MY_PDC\netlogon\nocache.reg
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.
- 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.
- Use 'netstat' or a TCP/UDP scanner
and 'rpcinfo' to list all services on your machine. Again, make
sure that everything you don't explicitly understand is turned off.
- (more forthcoming; frankly, I've
been more of an WinNT admin lately so my skills are getting rusty)
- Read ftp://ftp.auscert.org.au/pub/auscert/papers/unix_security_checklist.
- 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
Beyond that, I know of nothing in
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?
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?]
Once you have the priorities
straight, you need to figure out the technology. That's described in the
- Think about how you can configure the
following systems in order to detect intruders:
- Operating Systems 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
- Services, 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.
- Network Intrusion Detection
Systems that watch network traffic in an attempt to discover
intrusion attempts. A section below lists a number of these products.
- Firewalls usually have some
network intrusion detection capabilities. After all, blocking intrusions
is their primary purpose; it would be foolish not to detect intrusions
- Network management platforms
(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.
- Read CERT's intruder detection
checklist at ftp://ftp.cert.org/pub/tech_tips/intruder_detection_checklist.
For the most part, a good response
requires that you've set up good defensive measures in the first place.
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
- incident response team
- 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:
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.
- upper management
- 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.
- HR (Human Resources)
- 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.
- technical staff
- 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.
- outside members
- 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 firstname.lastname@example.org). But put their names on
the list so that everyone knows who to call.
- security team
- Of course, the most important
team members will be the security people themselves.
- response procedure
- 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.
- lines of communication
- 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 http://www.first.org?
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: http://www.usdoj.gov/criminal/cybercrime/reporting.htm
- logging procedures
- 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.
- 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.
- On the IDS mailing list, someone asked
how they should respond to the following email:
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
Nov 6 07:13:13 pbreton in.telnetd: refused connect from xx.xx.xx.xx
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.
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:
But there are also some nefarious
- Somebody typed "telnet
xx.xx.xx.xx" and mistyped the IP address.
- 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".
- 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.
- May have been an honest mistake
(i.e. somebody used to have an account on that machine, but no longer
<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 site may have already been
hacked, and the hacker is running scans from the compromised machine.
- 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).
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.
- The target is a legal IP address
(though not so interesting).
- 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.
- 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
- This may be "social
engineering spam". The sender of the message may be a company
looking to resell intrusion detection products.
As it turns out, the incident was
benign. The target network had reconfigured itself, and the
"unauthorized" user didn't know about it yet, and wasn't logging
- 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.
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.
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.
- This section discusses the major
network IDS products.
- The most complete list on the net
seams to be the COAST Intrusion Detection System Resources page at http://www.cs.purdue.edu/coast/ids.
See sections 4.4 and 4.5 below for a
discussion of some freeware technologies.
- Note: I've removed the table of info
because it has gotten dangerously out-of-date
Reviews can be found at:
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.
The site http://www.internations.net/uk/talisker/
has done a good job of wading through the marketing hype and pulling out the
salient points about each of the commercial products.
- Vendor comments:
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
The list of intrusions it
detects is at: http://www.networkice.com/advICE/Intrusions
Distinguishing features of
BlackICE Sentry are:
- Full 7-layer, stateful,
- Anti-evasion techniques
(handles fragmentation, whisker scans, a whole suite of signature
- Extremely fast, easily
handles full 100-mbps bandwidth.
for more information.
- Vendor comments:
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
- 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.
- Configuration editor allows
for custom settings and thresholds to suit every environment,
including security profiles, account groups, time and subnets.
- Extensive filtering using
ordered filter rules for each signature.
- Report coalescing feature
suppresses denial of service on the IDS itself.
- Report collating of
monitoring and scanning information per system with trend analysis
options, including 3D charting and graphing from an SQL database.
for more information.
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.
- Vendor comments:
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.
- Originally by Wheelgroup, bought
by Cisco. It has been recently renamed, though I'm not sure to what.
Intrusion Detection by Computer Associates
- Formerly Memco/Abirnet/PLATINUM
SessionWall, this is now owned by Computer Associates and marketed as eTrust
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.
- Goto http://www.axent.com.
- Goto http://www.cybersafe.com/solutions/centrax.html.
- Vendor comments:
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).
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.
NFR does more statistical
analysis than other systems. The N-code system allows easy additions
into this generic statistical machine.
A general description can be
found at http://www.nfr.net/forum/publications/LISA-97.htm
- Goto http://www.network-defense.com
- A "network grep" system is
based around raw
packet capture pumped through a "regular expression" parser
that finds patterns in the network traffic. An example pattern would be:
"/cgi-bin/phf", 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 http://www.packetfactory.net/ngrep/
for an example.
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.
"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.
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: http://www.robertgraham.com/pubs/sniffing-faq.html.
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
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.
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
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.
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.
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.
- See above.
- 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 http://ftp.ee.lbl.gov/papers/bro-usenix98-revised.ps.Z
for more information.
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.
Following is an example rule:
# 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";)
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".
Usage of snort is usually done in
the following manner:
- BPF filters (part of libpcap)
are configured to narrow down the focus to cetain types of traffic.
- A decision is made about which
IP addresses are internal and which are external to further narrow
down the focus.
- Rules are edited to fit the
- System runs
- Rules are further edited to
remove false positives.
Also, snort has a number of
options to be used just to sniff network traffic.
- 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.
for more info. Also see ftp://ftp.sei.cmu.edu/pub/argus-1.5
- These utilities either come with
your favorite UNIX platform or you can download them for free.
- to see if a host is alive.
- to find the route to the host
- to discover all your DNS
- finds out Internic
- finds out who is logged in and
info about users
- finds out what RPC services
- display shares on a machine
- displays info about WinNT SMB
- the granddaddy of them all --
allows you to connect and play with any text-based protocol (HTTP,
FTP, SMTP, etc.)
- All of the UNIX utilities
mentioned above can be used with WinNT. There are also some WinNT
- discovers NetBIOS information
on remote machine
- net view
- is the LANMAN programme that
allows you to remotely view WinNT shares
- The standard toolkit for a
- is characterized as a
"TCP/IP" Swiss Army Knife, allows intruders to script
protocol interactions, especially text-based protocols.
- crack / NTcrack / L0phtCrack /
- that crack network passwords
(Dictionary or Brute Force). These packages also contain utilities
for dumping passwords out of databases and sniffing them off the
- Sniffing utilities
- for watching raw network
traffic, such as Gobbler, tcpdump, or even an
honest-to-god Network Associates SnifferŠ Network Analyzer
- TCP and UDP port scanners
- 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.
- Ping sweepers
- for pinging large numbers of
machines to see which ones are active.
- Exploit packs
- which are a set of one or more
programs that know how to exploit holes on systems (usually, once
the user is logged in).
- Remote security auditors
- such as SATAN that look for a
number of well known holes in machines all across the network.
- War dialers
- that dial lots of phone
numbers looking for dial-in ports.
- is based upon the SAMBA code,
and is useful for discovering NetBIOS/SMB info from Windows and
- are programs (like SATAN,
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
- 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)
See above for info on the
- Tcpwrappers are an add-in for
UNIX, and sit between
inetd and services (like ftp, telnet,
inetd will first call tcpwrappers, which will do
some authentication (by IP address) and logging. Then, tcpwrappers will
call the actual service, if need be.
- Log file analysis of firewalls is
very similar to network analysis. See http://www.enteract.com/~lspitz/intrusion.html
for an example.
- I think it is a project used in
the Navy to track intrusions, and generate reports on them. They have an
interesting report at http://www.nswc.navy.mil/ISSEC/CID/co-ordinated_analysis.txt
where they describe coordinated, slow attacks they have detected using
- Purdue's COAST
distributed agent idea. I'm not sure how much of this is proposals, and
how much is real.
- A new class of NIDS runs on hosts in
- 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.
- 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.
- 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.
- 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.
- 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 http://www.cert.org.
- AUSCERT is the AUStralian Computer
Emergency Response Team. For registration information, see their web
For more details, contact AUSCERT
directly on email@example.com.
- Has a number of useful advisories.
- This is the best site on the net
for learning about IDS and security in general. See http://www.cs.purdue.edu/coast,
- 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 http://www.sans.org/
- These are some hackers with some
pretty good tools and useful alerts, targeted at Windows. Goto http://www.l0pht.com
- I like this site; it has a bunch
of well organized info on intrusion (A.K.A. incursion). Goto http://www.ticm.com
- Email "subscribe ids" to
Email questions to firstname.lastname@example.org
This is a nice, low-volume list with interesting discussions from
- Here are some sites that aggregate
info from other sites. Could be worth a look.
- Goto http://www.alw.nih.gov/Security/
- Goto http://www.ntsecurity.net/.
- A common misunderstanding is that
firewalls recognize attacks and block them. This is not true.
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.
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 allows outgoing TCP
connections. This stops all incoming connections from Internet hackers, but
still allows internal users to connect in the outgoing direction.
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.
In summary, a firewall is not the
dynamic defensive system that users imagine it to be. In contrast, an IDS is
much more of that dynamic system. An IDS does recognize attacks
against the network that firewalls are unable to see.
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.
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.
Some reasons for adding IDS to you
- Double-checks misconfigured
- Catches attacks that firewalls
legitimate allow through (such as attacks against web servers).
- Catches attempts that fail.
- Catches insider hacking.
"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.
- Editors Note: This just clarifies
the point above.
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 barely
doesn't fall down."
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.
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
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.
- Of course. Every corporation needs a
well managed, single point of entry.
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.
- No. While some log file analysis
programme do scan firewall logs for signs of intrusions, most intrusion
detection systems get their information elsewhere.
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.
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
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.
|F| +-----+ .
/============\ |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| +-----+ .
- IDS #1
- Few IDSs work this way. Firewalls
don't produce enough information in order to effectively detect
- IDS #2
- This popular placement of an IDS
detects attacks that successfully penetrate the firewall.
- IDS #3
- This placement detects attacks
that are attempted against the firewall.
- IDS #4
- By placing intrusion detection
systems throughout a corporate network, attacks by insiders will be
- 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 http://www.gocsi.com/intrusion.htm.
Some common questions are:
- What does it cost?
- Of course.
- What do signature updates and
- Intrusion detection is much like
virus protection, a system that hasn't been updated for a year will miss
common new attacks.
- At what real-world traffic levels
does the product become blind, in packets/second?
- 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
the segment in order to blind the sensor.
The most important metric is packets/second.
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 review
in September of 1999 with real-world traffic where several products that
claimed 100-mbps could still not keep up.
- How easy is the product to evade?
- Go down the list in section 9.4
and ask the vendor if such activities will evade the IDS. If you want to
give the vendor heartburn, ask them about section 9.5
- How scalable is the IDS system as
- 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.
- How much will it cost to run and
maintain the product?
- 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?
The following questions are commonly
asked, but are less likely to produce meaningful answers:
- How many signatures does the system
- 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.
- What intrusion response
features does the product have?
- 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
- I put this question in here hoping for
feedback; I really don't have an answer.
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.
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.
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.
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
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
Remember that even what appears to be
the most egregious hack may, in fact, be innocuous, so aproach other people
with dignity and respect.
- 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
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
Intrusion detection systems,
firewalls, proxy servers, and sniffing programs can be configured to log all
web surfing traffic to log files, including who accessed which
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)).
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
- 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.
For example, section 4.3
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.
Similarly, section 4.5.2
describes a PERL based system that parses log files from a firewall.
Different countries and states have
different laws, but it is generally legal to monitor your OWN traffic for
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 will be monitored. At minimum, it avoid embarrasing
- 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.
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).
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.
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 receive 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.
In much the same way, the receiving
system should have only a single Ethernet adapter, and its transmit
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
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.
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
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
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
- Network intrusion detection systems
are unreliable enough that they should be considered only as secondary
systems designed to backup the primary security systems.
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
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.
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.
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.
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
There are some solutions to this
problem, but not all of them are satisfactory.
Embed IDS within the switch
- 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.
- 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.
Tap into the
cable (for inter-switch or switch-to-node)
- 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:
- inline taps
- 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 (http://www.shomiti.com/productsf/tapfamilyf.html)
which plugs into a 100-mbps full duplex line, and allows a computer
equipped with 2 adapters to read both channels.
- vampire taps
- 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.
- inductance taps
- 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
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
Thanks to Christopher Zarcone
< czarcone at acm dot org > for this info.
- 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.
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.
This section lists some typical
- 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
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
- 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.
When buying an IDS, ask the
vendor how many simultaneous TCP connections it can handle.
- 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.
- 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.
The intrusion detection system itself
can be attacked in the following ways.
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).
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
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.
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.
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.
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.
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.
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.
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.
This section describes simple evasion
tactics that fool basic intrusion detection systems. The next section will
describe advanced measures.
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 fragrouter)
that can auto-fragment attacks in order to evade IDS.
Note that fragmenting the IP
packets in the middle of the TCP header has long been used to evade
firewall port filtering.
Some industrial grade NIDS can
reassemble traffic. Also, some firewalls can "normalize"
traffic by forcing reassembly before passing the traffic through to the
- 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).
- 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.
- 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.
- 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.
- 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.
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.
The typical example is simple
changes to the URL. For example, this document can be retrieved through
the URL: http://www.robertgraham.com/pubs/./network-intrusion-detection%2Ehtml.
Even though the exact pattern has changed, the meaning 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.
- 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 ftp://ftp.ee.lbl.gov/papers/bro-usenix98-revised.ps.Z.
The seminal paper on network
intrusion detection "evasion" was written by Thomas
H. Ptacek and Timothy N. Newsham. The original PostScript version is
available at http://www.aciri.org/vern/Ptacek-Newsham-Evasion-98.ps,
while an HTML mirror is available at http://www.robertgraham.com/mirror/Ptacek-Newsham-Evasion-98.html.
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.
These papers describe the abstract
concept that the network model used by the network intrusion detection
system is different than the real world.
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.
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.
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
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
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.
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.
- The following tools may help in
evaluating IDS systems for these problems.
- Anzen NIDSbench
Contains the "fragrouter"
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.).
Also contains the "tcpreplay"
program, which dumps high loads onto an Ethernet segment in order to
veriy a NIDS can keep up.
- 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
Some scripts for CASL are at: http://www.roses-labs.com/labs/labs.htm
- A much more narrowly defined
effort that solves a specific problem. Hasn't produce proposals yet. See
- See http://www.ietf.org/internet-drafts/draft-abela-ulm-04.txt
- Charter: http://www.ietf.org/html.charters/idwg-charter.html
- 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.
- An attempt to standardize security
advisories, such as those that come from CERT, the FBI, etc. http://www.ietf.org/internet-drafts/draft-debeaupuis-saf-00.txt
- "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.
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.
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
- 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.
- A honeypot is a system designed
to look like something that an intruder can hack. Examples can be:
- Installing a machine on the
network with no particular purpose other than to log all attempted
- 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.
- 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.
- 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
- 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 all 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.
- 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 "banner
checks". 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 port
110, 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.
- If the system does indeed get
hacked, it can be used as a stepping stone to further compromise the
- 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.
- Honeypots add complexity. In
security, complexity is bad: it leads to increased exposure to exploits.
- 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)?
- 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.
Your gameplan should consist of the
- documentation, documentation,
- 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).
- maintainance plan
- How do you plan on maintaining it?
- alarm reporting
- How do you plan on receiving
alarms from the system?
- reaction plan
- What do you plan on doing when an
alarm goes off?
- Port monitors
- The simplest honeypot is simply a sockets-based
programme that opens up a listening port. A typical example of this is
the programme NukeNabber (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:
- 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
- They alert the hacker that
such a system is running because they first accept, then drop, the
- Deception systems
- The next logical step beyond the
port monitor is a system that actually interacts with the hacker. For
example, rather than simply accepting port
110 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.
- Multi-protocol deception systems
- 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.
- Full systems
- 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
- Full systems plus NIDS
- Along with the full system
mentioned above, you might want to include a full intrusion detection
system to supplement the internal logging.
- 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.
Remember: if you put one of these
systems on the Internet, within a month it will be discovered and hacked.
- Learn about incidence response
- 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.
- Learn about hacking techniques
- Watching hackers break into your
system teaches you a lot about hacking.
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.
- Early warning systems
- 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.
- Launching Point
- 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.
- The book The
Cuckoo's Egg by Clifford Stoll 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
The San Diego Supercomputer Center
has left machines up that can be hacked. http://security.sdsc.edu/incidents/worm.2000.01.18.shtml
- The following are products that I know
- Fred Cohen's Deception Toolkit
- NAI CyberCop Sting
- The netcat tool can be used to
respond with deceptive banners.
- 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.
I personally have done the following
sorts of things:
- Email headers
- 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
- DNS info
- 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.
- 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.
- anti-sniffers, part deux
- 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 /etc/passwd.
This will tell you if anybody has sniffed that file.
11.10 What are the
legal implication of honeypots?
honeypots constitute entrapment?
- 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:
- If you are not a law
enforcement officer, you cannot entrap.
- 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.
- If the FBI contacts somebody
in alt.2600 and posts a bounty for
cracking into a system, then it would be entrapment.