Contact:[email protected]
Viewpoint
Is Network Intrusion Detection Software Being Used Correctly?
By Marcus J. Ranum
------------------------------------------------------------------------
--------
It's early Sunday morning and the network manager is sleeping at home. A
stealth hacker program is unfolding itself behind the company's
firewall, preparing to open a path into the network. Immediately, the
network manager's pager is activated: "Attack in progress!"
Within minutes, the network manager has logged in over a secure link,
accessed the company's intrusion detection system, and obtained complete
details of the origin and nature of the attack. After a few quick phone
calls, the penetration is blocked, and law enforcement agents will soon
be knocking on the hacker's front door.
Sounds great, doesn't it? Unfortunately, the reality of network
intrusion detection and response doesn't even come close to this
hypothetical scenario. For one thing, most intrusion detection
systems--software and hardware components that detect incursions into a
network--cannot trace an attacker back to his or her point of origin.
Yet many network managers are purchasing intrusion detection systems
anyway. Are they getting their money's worth? Are their networks any
safer? The evidence suggests that the answer is no to both questions,
but that need not be the case.
IDS type.
Researchers have been working on intrusion detection systems for a long
time without achieving what could be called a major breakthrough.
Currently, users have two choices: anomaly detection and misuse
detection. But each has serious limitations.
Anomaly detection. The usual line of research focuses on what is called
the anomaly detection intrusion detection system (AD-IDS). An AD-IDS
"learns" what constitutes normal network traffic, developing sets of
models that are updated over time. These models are applied against new
traffic. Traffic that doesn't match the normal model is flagged as
suspicious.
These systems are attractive conceptually, but it is hard to create a
reliable model for normal traffic. As networks grow, the mix of
applications becomes so complex that traffic looks random. A patient
hacker may even generate his or her own traffic to generate a distorted
model of normal so that, sooner or later, an attack may look normal and
get past the IDS. On the other hand, if the IDS is set up with a narrow
definition of normal, the system will generate large numbers of false
positives, and the IDS will be ignored.
Much research is still being done on AD-IDS, but for now these systems
are not the answer.
Misuse detection. Many companies offer an easier to operate form of IDS
called misuse detection intrusion detection systems (MD-IDS). The MD-IDS
resembles a virus scanner attached to a network. It is usually
programmed with signature sets representing the types of connections and
traffic that indicate a particular attack. Other forms of these systems
rely on host platform information, such as C2 audit logs (which record
information such as file accesses), to detect patterns of suspicious
activity.
These systems are fast and don't generate false positives because they
"understand" what attacks look like. But, like virus scanners, MD-IDSs
cannot detect something that the network manager doesn't know about--the
type of attack the network manager most wants to detect. For an MD-IDS
to be useful, its signature sets must be constantly updated. Even so,
the network will still be vulnerable to new attacks.
It is also distressingly easy for an attacker to hide traces of the
attack. For example, if an MD-IDS on a UNIX system is configured to look
for the attack string "rootkit," a hacker might disguise an attack by
inserting an "X" and an "F" into the attack stream ("rooXFtkit"). With a
few keystrokes, the hacker can assign the "F" key the function of the
"delete" or "erase" key. In the string "rooXFtkit," then, the "F" will
erase the "X" with the result that "rootkit" will have eluded the
MD-IDS. (For an excellent discussion of these types of problems, see
Secure Networks Inc.'s paper "Problems with Intrusion Detection
Systems," available through Security Management Online.)
IDS placement.
Regardless of the type of IDS software selected, the user must also
decide where to place it: inside the firewall or outside. Most IDSs
these days are deployed outside the network firewall, where they detect
any attack and send an alarm. By contrast, if an IDS were placed within
the firewall, it would detect only attacks that penetrate that security
shield.
The latter approach, though less used, is the better one. It saves the
system administrator from wasting time on failed attempts to enter the
system. (Remember, a firewall is actually preventing the attacks on the
system, and it will do so regardless of whether an IDS is in place to
monitor real-time attacks.)
When I built my first security and mission critical Internet system in
1991 as a part of a major corporation's Internet gateway, I set up an
IDS to look for common system commands that hackers often try (but that
the corporation didn't use), and attackers were detected about twice a
week. I used to backtrack the attacks, and often caught the hackers. But
while the attacks were frequent, the hackers were usually just "rattling
the doorknobs," and it would have been prohibitively expensive to try to
prosecute.
The process of running down an attack and documenting the incident took
about four hours per attack. The effort had no impact--as the arrival
rate of new Internet users increased, so did the attack rate--but it was
costing me sixteen hours a week. Since I had built the system, I knew it
could resist the attacks it was detecting. My effort at backtracking was
a waste of time, especially since I wasn't authorized by the company to
do follow-up that might lead to a prosecution.
Today, it is even harder to track hackers. Even companies with the time
and resources to pursue attackers may find themselves following dead-end
trails. The address from which the attack appears to originate could
just be spoofed, for example. Even if the administrator knows where the
attack is coming from, it is almost always from a stolen or fraudulently
acquired account. It is more cost effective to simply chase hackers away
and get back to work.
Intrusion detection systems can be effectively employed, however. Using
a technique I call "burglar alarms," an IDS can provide a useful and
reliable notification of certain classes of security incidents.
A computer network burglar alarm is an IDS that relies on an
understanding of the network and what activity should not happen within
it. To understand network burglar alarms, consider a home alarm system
in a house that enforces a simple security policy: when I am not home,
nobody should be operating doors or windows, breaking glass objects, or
operating the door to the safe. Based on that descriptive policy, I can
design a burglar alarm system using switches at doors/windows, glass
break detectors, and some tamper switches.
One of the best tools for building a burglar alarm intrusion detection
system is an MD-IDS because it has a rules base that is configurable for
where to look for intrusions and what exactly to look for. (An AD-IDS
doesn't work well for this purpose because it is not easy enough to set
up and operate.)
The MD-IDS should be set up to detect any anomaly and register an alert.
Suppose, for example, a network is behind a firewall that blocks
Internet Protocol (IP) traffic: the firewall is configured to look for
certain IP address ranges and trip an alert if any are found inside the
firewall. If the firewall does not allow any incoming traffic except for
e-mail, Usenet, and domain name service to a central mail hub, the
MD-IDS should be set up to send an alert if the firewall permits
connections to internal systems for other than those services, to other
than those specific servers.
If a network manager is concerned that an insider might try to hack
outside sites, the MD-IDS can be configured to send an alert if certain
types of traffic go out through the firewall.
Perhaps the most powerful capability of burglar alarm IDSs is that they
challenge the attacker with the unexpected. If someone breaks in, that
person needs to familiarize him or herself with the network. Just as a
burglar may rummage through jewelry boxes or drawers once past the
perimeter alarm, a hacker will scan a network for systems that look
attack-worthy.
Detecting internal scans is as effective a way of catching a hacker as a
magnetic tamper switch under a money clip on the dresser is for catching
a burglar. Most hackers, like burglars, are not expecting creative
defenses--once they get through the firewall, they assume that nobody is
watching.
To get the best mileage out of an IDS, the network manager should draw
up a list of the kinds of incursions that could cause a serious problem
and set the system up to watch for them. The IDS should be placed inside
the firewall, where it can detect all activity that puts information and
systems at serious risk. The number of typical attacks seen on the
internal network should be very low, and will either represent auditors
or hackers that have somehow gotten through the perimeter. In the worst
possible case, it may detect employees launching hacks against sites out
on the Internet or against internal locations of which they are not
authorized users.
As with all Internet software, security software is improving at a rapid
rate. The near future promises IDSs that combine anomaly detection with
misuse detection, and hopefully they will integrate smoothly with
firewalls and other security systems. Until then, the technology should
only be used as part of an overall defense strategy--and where it will
be the most effective, not where it will generate the most hits.
------------------------------------------------------------------------
--------
Marcus Ranum is the CEO of Network Flight Recorder, Inc., a firm
specializing in network traffic analysis software. He built the first
commercial Internet firewall product in 1991 and subsequently designed
and implemented several other significant security systems. He is a
coauthor of the recently published Web Site Security Handbook.
Security Management OnLine
Back to the Index