Virtual Burglar Alarm - Intrusion Detection Systems (Part 2)
Thomas Biege
Table of Contents
- Architectures
- Requirements
- Location-specific Questions
- What Does The Future Hold?
4. Architectures
In addition to numerous analysis procedures there are also various
architectures for ID systems. The sections below address only the most
commonly used architectures. First, we must clarify some misconceptions
about the terms host-based IDS and networked-based IDS. The term host-based
IDS may suggest that an IDS is being used to monitor computer system
security. This assumption, however, is incorrect. Host-based ID systems are
products that receive their audit data from a host, that is to say, the
host's log files or executed system calls (syscalls). Host-based ID systems
are capable of monitoring 1-n computers, so they are not limited to one
computer. Network-based ID systems analyze network data, no matter how they
receive the data or where they collect it. In the process, network-based ID
systems monitor the security of computer systems in a network. A common
mistake is to designate as network-based only those ID systems that receive
their data from a network interface operating in promiscuous mode in order
to read all network packet traffic that is passing through. Such systems
are classic sensor-based ID systems. More recent approaches use agents
installed on the computer system to be monitored so that the agents can
intercept network packets from the TCP/IP stack's different levels and send
them to a centralized analysis unit.
4.1 Host-based IDS (H-IDS)
Host-based ID systems are the oldest systems. The United States military
used host-based ID systems to monitor database hosts and others. In a
typical case, user-level log data (syslog for Unix systems) and/or
kernel-level log data (e.g., BSM Auditing Subsystem from Solaris, AIX Audit
Subsystem, NT Event Log and others) is examined for intrusion patterns.
Other H-ID systems such as PortSentry [8.3.4] also eavesdrop at TCP/UDP
ports and notify the SO when a connection to the corresponding ports is
being established. The advantage of H-ID systems is the fact that they
cause fewer false positives than network-based ID systems, since they know
exactly how the computer system reacts. In addition, H-ID systems can
recognize attacks that N-IDS systems are unable to spot, such as, for
example, attacks from the console, modems, encrypted connections and
malicious programs (e.g., Trojan horses and similar viruses). On the
downside, it should be noted that an H-IDS must be installed and maintained
on every computer that is to be monitored. H-ID systems cannot adequately -
if at all - recognize denial-of-service attacks that exploit a system's
TCP/IP stack errors, because the system crashes first and a host-based ID
system generally operates at a higher level than, for example, a
network-based IDS.
4.2 Network-based IDS (N-IDS)
In recent years, sensor-based N-ID systems have gained much popularity due
to the accelerating proliferation of network connections and the resulting
need for security policies. At the same time, technological advances
provided sufficient performance capacity to analyze large amounts of data
in real-time - regardless of one's definition of real-time. Sensor-based
N-ID systems are quite amenable to central use and administration. Thus, an
IDS can monitor entire computer networks by using just one computer and one
doesn't have to deal with every individual host. This is a very attractive
feature of sensor-based N-ID systems, since they require fewer
administrative and financial resources. A sensor-based N-ID system's event
box reads all data transmitted through a network segment and then sends the
data to the analysis box. The system can use the header information (flags,
attributes, etc.) to identify denial-of-service attacks or scans (checking
a network for computers or checking computers for services offered). The
payload contains the data the TCP/IP stack sends to the application level.
The A-box checks this data for attack patterns. There are some huge
problems that occur with the use of N-ID systems. Some of these problems
may have more profound consequences in the future.
The most obvious problem facing sensor-based N-ID systems is data
encryption. A classic N-IDS is rendered useless not only by VPN solutions
such as IPsec and others, but also by encrypted login connections such as
SSH. It is impossible to decrypt the data for analysis. In such cases, a
host-based system is clearly superior. It doesn't make sense to solve this
problem with a public key infrastructure or similar key management
procedures, since this drastically increases the ID system's complexity,
which, in turn, decreases the system's power. Analyses would also take much
longer, since cryptographic algorithms are very compute-intensive. Growing
network bandwidth makes it difficult for a sensor-based N-IDS to seamlessly
read all data without exceeding the capacity of the internal (ring) buffer
and losing data in the process. The Network Flight Recorder is able to
monitor a saturated 100 MBit network. The switched network infrastructure
constitutes another hurdle that must be overcome. With a regular Ethernet,
all computers in a logical segment share the transmission medium (physical
segment). This means that if two computers want to send packets
simultaneously, the packets may collide and must be resent. In other words,
the computers are located in a shared collision domain. A switch avoids
collisions because this process uses ports at the switch to assign every
computer its own physical network trunk and sends the packets to exactly
the computer they were addressed to. Thus, a switch creates smaller
physical segments that contain only one computer each. If the network
packets arrive only at the computer for which they were intended, then the
N-IDS E-box can no longer read the packets as well and the IDS is once
again rendered blind. Some switches have a so-called spy or monitoring port
that lets the N-IDS read the packets. For a 100 MBit network, every port of
the switch, including the spy port, has a bandwidth of 100 MBit. If the
switch has 10 ports, not including the spy port, then the spy port would
require a bandwidth of 10 x 100 MBit to transmit all the data from all
ports. The spy port only has 1/10 of the required bandwidth and thus cannot
even read all the data in a network operating at full capacity.
Consequently, the spy port is primarily a stopgap solution in the intrusion
detection field. To be able to analyze the data, the N-IDS must understand
all commonly used network proheadlineols, such as TCP/IP, IPX, Appletalk, etc.
The IDS is useless when it comes to protecting a network that uses a highly
exotic proheadlineol the IDS vendor did not implement. While the specifications
for the TCP/IP stack are defined in the RFC documents, every operating
system vendor implements them differently. As a result, the sensor-based
N-IDS is never quite sure of the state of a host's TCP/IP stack. An
attacker can exploit these discrepancies across different stack
implementations by "hiding" his packages from the IDS or by inserting
packets in the IDS data stream that does not recognize and ignores the
target system. [8.2.6] Here is a simple example to illustrate this
situation: An attacker sends a TCP packet containing the attack data to an
unsecured network service in the target system. The TCP header's checksum
was deliberately miscalculated. The IDS spots the package, yet ignores it
due to the incorrect checksum. The target system receives the package, but
doesn't investigate the checksum, because it has not been implemented, and
then forwards the usage data to the server. Result: The IDS dismissed the
packet, but the target system accepted it and the attacker succeeded at
exploiting the security flaw unnoticed.
These are grave problems that make the future use of purely sensor-based
N-IDS quite unlikely.
Node-based N-ID systems avoid many of the classic N-ID system problems.
However, their decentralized structure makes them somewhat more difficult
to use than their older counterparts. With node-based N-ID systems,
individual computer systems use small monitors integrated in the TCP/IP
stack to read the network packets at a higher level and then analyze them
centrally (or in a de-centralized fashion). Consequently, inconsistencies
during the interpretation of network connections, buffer overflows and
low-level encryption (IPsec, etc.) no longer pose any problems. Still,
unless complicated key management procedures are being used, data encrypted
at higher levels (e.g., via Secure Shell, PGP, SSL, etc.) can still not be
viewed in clear text.
4.3 Alternatives
In addition to host-based and net-based approaches, there were other
developments in intrusion detection system architectures, most of which
have not been used in practice (e.g., mobile autonomous agents). The most
widely known alternatives are probably the agent-based IDS, which spurns
the monolithic architecture of classic ID systems, and Honeypot, a system
that creates the illusion of a vulnerable system for the attacker.
4.3.1 Honeypot Systems
Honeypots are systems that pretend to have security flaws. Once an intruder
discovers the system, he will attack it and encounter no problems with
compromising the security mechanisms. The attacker believes he has entered
a regular computer system, when he was actually routed to a sealed-off
environment. The system notifies the SO about the intrusion, who is now
able to observe and analyze the opponent's behavior. This method makes it
possible to discern the opponent's intent or even to discover new types of
attacks.
Deception Toolkit (DTK) and ManTrap are good examples of host-based
Honeypot systems. Theoretically, it is also possible to create
network-based Honeypot systems that provide the attacker with an entire
illusionary network by using one computer to implement multiple virtual
machines (VM) with virtual network connections. Secure Networks, Inc. (SNI)
once announced the creation of a Honeynet, but apparently the project never
made it to the marketing stage.
While honeypots can reliably recognize attacks, they can also keep security
officers unnecessarily busy, since even the most untalented attackers can
break into the honeypot system. Oftentimes, such attackers have no
intention of stealing specific information, and they are merely attacking
the system out of boredom or to place IRC bots. Such attacks waste time and
yield no new insights for the SO. Since a honeypot is essentially a trap,
it is, of course, possible for an attacker to avoid it and thus remain
undiscovered. Honeypots are particularly useful in a DMZ or in front of
firewalls, since they do not provide very many angles for attack. This, in
turn, increases the likelihood that an attacker will target the honeypot
system.
4.3.2 Agent-based Intrusion Detetcion Systems (AA-IDS)
AA-ID systems are good examples of distributed computing. Small, autonomous
software programs (agents) run on the system that is being observed. These
agents simply monitor commands or even watch for attacks. The information
collected by the agents is sent to other units of the ID system, where it
is further processed. Autonomous Agents for Intrusion Detection (AAFID)
and EMERALD are two well-known examples of AA ID systems. Let's use
AAFID as an example to illustrate this type of IDS.
AAFID has a hierarchical structure. The agents are located at the bottom of
the hierarchy. Multiple agents performing different tasks can be used on
any one host. All agents send their information to a transceiver located on
the same host. The transceiver monitors and controls the agents and can
start, stop and reconfigure them. The transceiver is also responsible for
data reduction and sends its results to one or more monitors, which make up
the next highest level in the hierarchy. The monitors themselves can also
be arranged hierarchically. They check and collate the data from the
transceivers. The monitors' ability to collate data from different hosts
enables the system to recognize attacks that originate from multiple hosts.
AAFID's structure makes it easily scalable. When a new server is added to
the network, simply install the AAFID components on the server. The
components will then send their reports to a superordinate monitor.
5. Requirements
An intrusion detection system vendor should keep the following requirements
in mind.
- The system must be easy to install.
- IDS maintenance must be simple and inexpensive.
- The ID system's administration should be facilitated with a GUI.
- The IDS should come with comprehensive online help functions.
- The IDS must be able to provide data for users with different levels of
experience. This means that the system must be able to display a very
abstract description of an attack for inexperienced users. Upon request,
the IDS should be able to provide more detailed displays for
technologically well-versed users.
- The IDS must be able to display the reason for an alarm.
- Large volumes of data must be displayed in a way that makes manual
processing possible.
- The vendor should provide technical support.
- The vendor should make attack signatures easily available.
- The user must manually enter his own attack patterns.
- The vendor should offer training courses for the customer's employees.
- The system running the IDS software should be well secured.
- The IDS itself has to be resistant to attacks.
- The product must be easily scalable.
- To improve efficiency, the IDS should be able to accommodate external,
security-related information, such as, for example, vacation days, holidays
and sick days.
- The ID system should be a hybrid, which means that it should support
both misuse and anomaly detection.
- The data should be analyzed in "real time".
- The system should be able to process data from multiple sources
(network, log files, etc.).
- The system must guarantee the authenticity of the collected audit data
with, for example, cryptographic signatures. Otherwise, the data is legally
inadmissible.
- For legal reasons, user data must be pseudonym-coded. With pseudonym
coding it is not possible, for example, to monitor employee performance.
This is often a requirement for the commercial use of ID systems. Caution:
Pseudonym-coding can significantly slow down the audit data analysis
process, since this requires complicated crypto-algorithms.
- The data exchanged among the individual IDS components must be
encrypted. This prevents an attacker from gleaning any useful information
and makes it impossible for an attacker to manipulate the data.
- The ID system components should be able to transmit data through
multiple channels so that no data is lost in case one channel fails.
Examples of transmission media are computer networks, telephone systems,
serial cables, radio channels, etc.
- The collected audit data must retain its integrity. Data integrity can
be ensured with encryption or by storing the data on write-once media.
- It must be possible to change the audit data's granularity, so that,
for example, granularity can be increased during an attack.
- The IDS must be able to recognize and prioritize multiple attacks.
- In case of component failure, the ID system must sound an alarm
immediately.
- et cetera
6. Location-specific Questions
In order to use an IDS sensibly, you first must ask yourself and answer a
few questions, instead of falling for the marketing hype. An IDS is an
efficient addition to your IT security infrastructure only if you use an
IDS that is right for your requirements, as well as one whose strengths and
weaknesses you understand.
- Can the IDS implement my security policy?
The IDS and its configuration must be sufficiently flexible to be adaptable
to your security policy. Naturally, an N-IDS cannot perform all of the same
tasks as an H-IDS (and vice versa), such as, for example console logins
after hours.
- What do I want to protect?
If you want to protect your network infrastructure against failures, such
as, for example, failures caused by DoS attacks on routers, you must use an
N-IDS, since an H-IDS works at a higher level and does not recognize such
attacks sufficiently, if it recognizes them at all. In addition, it is
unlikely that there are host-based ID systems for the different router,
server and workstation operating systems. It is easy and inexpensive to
monitor workstations and servers with an N-IDS. This requires that the
systems are located in a separate network. In general, servers,
workstations, Ethernet printers / printer servers, as well as modem and fax
servers should always be located in separate rooms and separate network
segments, since they have their own administration and security domains. In
order to help discover attacks from your own network, you should always
monitor attacks on as well as those originating from your system.
- Where do you want the protection?
Do you want to monitor a server in a DMZ with a 3 GBit Internet connection?
Or the research department's subnetwork? Or perhaps you want to monitor the
NIS server in a slow 10 MBit network that is used only by visitors, interns
and students? The answer to this question significantly affects your choice
of ID system and its features.
- How many systems do I have to protect?
Do you have only one server or three dozen? Are the systems you want to
protect located in a single network or are they distributed? Are the
systems possibly situated far apart in different geographic regions where
your company's branches/networks are located?
- What does my network look like?
You should use network management consoles to obtain an overview of your
network. The administrators can answer questions about network speed, the
use of switches, virtual private networks (VPN), etc. These factors affect
your choice of IDS type and what kind of hardware to use.
- Does the IDS work together with my network's other components?
For example, can the IDS send SNMP messages to network management stations
such as OpenView or TIVOLI? This procedure can easily and effectively
reveal security violations (e.g., an attacked host could flash red in the
network management station's graphic display of the network). The
countermeasure box should be able to customize firewall configurations or
to communicate with other ID systems and vendors. Open proheadlineols that
protect the components' ability to inter-operate are required to achieve
this goal. The following standards are currently in widespread use:
- Common Intrusion Detection Framework (CIDF)
- Open Plattform for Security (OPENSEC )
- Adaptive Network Security Alliance (ANSA)
- Intrusion Detection Message Exchange Format (IDMEF)
7. What Does the Future Hold?
Wanting to answer such a question is basically futile, since the effort is
purely speculative. Nonetheless, I will attempt to take a cautious look at
what the future might hold.
More and more computers and intelligent electronic devices are becoming
part of everyday life. They will communicate with each other through
increasingly wider bandwidths and exotic proheadlineols (see Bluetooth, UMTS,
etc.). The demand to connect these systems to public networks is also
growing steadily, along with the volume of sensitive data stored in digital
format, such as, for example, results of medical exams, credit card
numbers, liquidity, shopping behavior, etc. An IDS product must be able to
cope with these developments. An increasing number of connections are also
being encrypted, which renders sensor-based N-ID systems just about
useless. Next to increasing performance, the capacity of the individual
security and management products to inter-operate is a challenge for IDS
developers. Until now, the vendors of various network management software,
firewalls, intrusion detection systems, I&A products, etc. have been
developing their own limited insular solutions. Open interfaces that permit
the exchange of data for the purpose of cooperation can significantly boost
the administration and security for networks.
The observations made by today's ID systems are still overly limited to the
digital domain. Future ID systems should also take into account information
provided by alarm systems, physical access control mechanisms (magnetic
card locks, etc.) and telephone systems/modems. That is how an ID system
will be able to recognize attacks at the virtual level as well, or to refer
to the acquired knowledge during the analysis of virtual attacks. For
example, an IDS could sound an alarm when user A logs into a server's
console, even though the magnetic card locks indicate that only user E is
inside the server room. As is the case for firewalls, there will be an increase in the development of independent, powerful ID systems Snort and PakeMon are good examples of such systems.
References
- Books
- Bace, Rebecca Gurley (2000): Intrusion Detection. - MTP, Indianapolis.
- Proctor, Paul E. (2001): The Practical Intrusion Detection Handbook. - Prentice Hall, New Jersey.
- Papers
- Sundaram, Aurobindo: An Introduction to Intrusion Detection.
- von Helden, Josef: Grundlagen,
Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS)
und Intrusion Response Systeme (IRS.
- Kumar, Sandeep & Eugene H. Spafford (1994): An
Application of Pattern Matching in Intrusion Detection. - Technical Report CSD-TR-94-013.
- Anderson, J. P.: Computer Security Threat
Monitoring and Surveillance.
- Crosbie, Mark & Gene Spafford: Active
Defense of a Computer System using Autonomous Agents.
- Ptacek, Thomas H. & Timothy N. Newsham (1998):
Evasion and Denial of Service: Eluding Network
Intrusion Detection. - Secure Network, Inc.
- Curry, David A., Herve Debar & Ming-Yuh Huang:
Intrusion Detection Message Exchange Format; http://www.silicondefense.com/idwg/draft-ietf-idwg-idmef-xml-02.txt
- Bishop, Matt (1995): Standrad Audit Trail Format. - National Information Systems Security Conference: 136-145
- Common Intrusion Specification Language
(CISL); http://www.gidos.org/drafts/language.txt
- Vern Paxons; Bro: A System for Detecting Network Intruders in RealTime
Thomas Biege has been working in the SUSE security team for the past two years. He studies general computer sciences at the technical college Dortmund. Presently he is busy with the development of a host-based intrusion detection system, which he will present in his diploma thesis.
|
|
|
Contact 
