Now that we have looked at some of the capabilities of an IDS as far as alerting
on malicious traffic, it’s time to take a closer look at what exactly IDSs can keep
an eye on, what data sources they use to do this monitoring, how they separate
attack traffic from normal traffic, and some possible responses to seeing malicious
traffic.
What the IDS Is Watching ??
Let’s start by looking at what your IDS is able to see.This is going to depend
greatly on what type of IDS it is, and where it’s placed in your network. IDSs are
classified by their functionality, loosely grouped into the following three categories:
■ Network-Based Intrusion Detection System (NIDS)
■ Host-Based Intrusion Detection System (HIDS)
■ Distributed Intrusion Detection System (DIDS)
Network IDS
The NIDS derives its name from the fact that it monitors an entire network seg
ment, or subnet.This is done by changing the mode on the NIDS’ network
interface card (NIC). Normally, a NIC operates in nonpromiscuous mode, lis
tening only for packets destined for its own media access control (MAC) address.
Other packets are not forwarded up the stack for analysis; they are ignored.To
monitor all traffic on the subnet, not just those packets addressed to the NIDS
machine itself, the NIDS must accept all packets and forward them up the stack.
This is known as promiscuous mode.
In promiscuous mode, the NIDS can eavesdrop on all communications
on the network segment. However, that’s not all that is necessary to ensure that
your NIDS is capable of listening to all traffic on the subnet.The network device
immediately upstream of your NIDS must also be configured to send all packets
on the subnet to your NIDS. If that device is a hub, all packets are automatically
sent since all ports on a hub receive all traffic flowing through the hub. However,
if that device is a switch, you may have to put the port on the switch into a
monitoring mode, turning it into a span port. After setting up your NIDS, it is
advisable to run a sniffing tool on the interface, to ensure that you can see all
traffic on the subnet.
The advantage of a NIDS is that it has no impact on the systems or networks
it is monitoring. It doesn’t add any load to the hosts, and an attacker who com
promises one of the systems being watched can’t touch the NIDS and may not
even know it is there. One downside of the monitoring is maxing out your span
ports that you are allotted on a given network, and maxing out the bandwidth
on the span itself. If you have 20 100MB ports spanning to one port, you begin
filling up backplane… once that 5GB or 11GB backplane is saturated, you are in
a world of hurt.
In view of emerging privacy regulations, monitoring network communications is a responsibility that must be considered carefully. Make sure that you are familiar with your local legal requirements for such activity.
In Figure 1.1, we see a network using three NIDS.The units have been placed on strategic network segments and can monitor network traffic for all devices on the segment.This configuration represents a standard perimeter security network topology where the screened subnets housing the public servers are protected by NIDSs. When a public server is compromised on a screened subnet, the server can become a launching platform for additional exploits. Careful monitoring is necessary to prevent further damage.
on malicious traffic, it’s time to take a closer look at what exactly IDSs can keep
an eye on, what data sources they use to do this monitoring, how they separate
attack traffic from normal traffic, and some possible responses to seeing malicious
traffic.
What the IDS Is Watching ??
Let’s start by looking at what your IDS is able to see.This is going to depend
greatly on what type of IDS it is, and where it’s placed in your network. IDSs are
classified by their functionality, loosely grouped into the following three categories:
■ Network-Based Intrusion Detection System (NIDS)
■ Host-Based Intrusion Detection System (HIDS)
■ Distributed Intrusion Detection System (DIDS)
Network IDS
The NIDS derives its name from the fact that it monitors an entire network seg
ment, or subnet.This is done by changing the mode on the NIDS’ network
interface card (NIC). Normally, a NIC operates in nonpromiscuous mode, lis
tening only for packets destined for its own media access control (MAC) address.
Other packets are not forwarded up the stack for analysis; they are ignored.To
monitor all traffic on the subnet, not just those packets addressed to the NIDS
machine itself, the NIDS must accept all packets and forward them up the stack.
This is known as promiscuous mode.
In promiscuous mode, the NIDS can eavesdrop on all communications
on the network segment. However, that’s not all that is necessary to ensure that
your NIDS is capable of listening to all traffic on the subnet.The network device
immediately upstream of your NIDS must also be configured to send all packets
on the subnet to your NIDS. If that device is a hub, all packets are automatically
sent since all ports on a hub receive all traffic flowing through the hub. However,
if that device is a switch, you may have to put the port on the switch into a
monitoring mode, turning it into a span port. After setting up your NIDS, it is
advisable to run a sniffing tool on the interface, to ensure that you can see all
traffic on the subnet.
The advantage of a NIDS is that it has no impact on the systems or networks
it is monitoring. It doesn’t add any load to the hosts, and an attacker who com
promises one of the systems being watched can’t touch the NIDS and may not
even know it is there. One downside of the monitoring is maxing out your span
ports that you are allotted on a given network, and maxing out the bandwidth
on the span itself. If you have 20 100MB ports spanning to one port, you begin
filling up backplane… once that 5GB or 11GB backplane is saturated, you are in
a world of hurt.
In view of emerging privacy regulations, monitoring network communications is a responsibility that must be considered carefully. Make sure that you are familiar with your local legal requirements for such activity.
In Figure 1.1, we see a network using three NIDS.The units have been placed on strategic network segments and can monitor network traffic for all devices on the segment.This configuration represents a standard perimeter security network topology where the screened subnets housing the public servers are protected by NIDSs. When a public server is compromised on a screened subnet, the server can become a launching platform for additional exploits. Careful monitoring is necessary to prevent further damage.
The internal host systems are protected by an additional NIDS to mitigate
exposure to internal compromise.The use of multiple NIDS within a network is an example of a defense-in-depth security architecture.
exposure to internal compromise.The use of multiple NIDS within a network is an example of a defense-in-depth security architecture.
Host-Based IDS
Host-based IDSs, or HIDSs, differ from NIDSs in two ways. First, an installed
HIDS protects only the system on which it resides, not the entire subnet, and
second, the network card of a system with a HIDS installed normally operates in
nonpromiscuous mode.This can be an advantage in some cases—not all NICs
are capable of promiscuous mode, although most modern NICs are. In addition,
promiscuous mode can be CPU intensive for a slow host machine.
Another advantage of HIDS is the ability to tailor the ruleset to be very spe
cific to the particular host system. For example, there is no need to configure mul
tiple rules designed to detect Network File System (NFS) exploits on a host that is
not using the NFS. Being able to fine-tune your ruleset will enhance performance
and decrease false positives (or true positives that you simply don’t care about).The
major advantage of a HIDS, however, lies in its capability to detect specific changes
to the files and operating system of its host. It can monitor file sizes and checksums
to ensure that crucial system files are not maliciously modified without someone
noticing. It can intercept rogue system calls that may be an attempt at exploiting a
local vulnerability. Moreover, it can watch traffic within a system that never crosses
the network, and therefore would never be seen by the NIDS.
There are a few downsides to electing to use a HIDS.You’ll have to choose
one that is tailored to your operating system. If you have many different oper
ating systems on your network and want to use the same vendor for all your
HIDSs, you may have to do a little shopping to find the right vendor that sup
ports all of your operating systems. A HIDS will add load to the host on which it
is configured, as the HIDS process(es) will consume resources.This is usually not
a problem on an individual’s desktop, but can become one on a busy network
server. Make sure you are familiar with the details of any HIDS that you choose
and how it operates—some HIDSs will watch file accesses, usage times, process
loads, and/or system calls, while others may also watch network activity from the
point of view of that host. Know what features you want in your HIDS, and
make sure that the HIDS you select will support those features on all the plat
forms you need.
Host-based IDSs, or HIDSs, differ from NIDSs in two ways. First, an installed
HIDS protects only the system on which it resides, not the entire subnet, and
second, the network card of a system with a HIDS installed normally operates in
nonpromiscuous mode.This can be an advantage in some cases—not all NICs
are capable of promiscuous mode, although most modern NICs are. In addition,
promiscuous mode can be CPU intensive for a slow host machine.
Another advantage of HIDS is the ability to tailor the ruleset to be very spe
cific to the particular host system. For example, there is no need to configure mul
tiple rules designed to detect Network File System (NFS) exploits on a host that is
not using the NFS. Being able to fine-tune your ruleset will enhance performance
and decrease false positives (or true positives that you simply don’t care about).The
major advantage of a HIDS, however, lies in its capability to detect specific changes
to the files and operating system of its host. It can monitor file sizes and checksums
to ensure that crucial system files are not maliciously modified without someone
noticing. It can intercept rogue system calls that may be an attempt at exploiting a
local vulnerability. Moreover, it can watch traffic within a system that never crosses
the network, and therefore would never be seen by the NIDS.
There are a few downsides to electing to use a HIDS.You’ll have to choose
one that is tailored to your operating system. If you have many different oper
ating systems on your network and want to use the same vendor for all your
HIDSs, you may have to do a little shopping to find the right vendor that sup
ports all of your operating systems. A HIDS will add load to the host on which it
is configured, as the HIDS process(es) will consume resources.This is usually not
a problem on an individual’s desktop, but can become one on a busy network
server. Make sure you are familiar with the details of any HIDS that you choose
and how it operates—some HIDSs will watch file accesses, usage times, process
loads, and/or system calls, while others may also watch network activity from the
point of view of that host. Know what features you want in your HIDS, and
make sure that the HIDS you select will support those features on all the plat
forms you need.
In addition, maintaining a large network of systems with many HIDS
deployed can be very challenging.The HIDS solution alone does not always scale
well, and without centralized management, you may be a very busy system
administrator indeed trying to keep up with all those alerts.
Figure 1.2 depicts a network using a HIDS on specific servers and host com
puters. As previously mentioned, the ruleset for the HIDS on the mail server is
customized to protect it from mail server exploits, while the Web server rules are
tailored for Web exploits. During installation, individual host machines can be
configured with a common set of rules. New rules can be loaded periodically to
account for new vulnerabilities.
deployed can be very challenging.The HIDS solution alone does not always scale
well, and without centralized management, you may be a very busy system
administrator indeed trying to keep up with all those alerts.
Figure 1.2 depicts a network using a HIDS on specific servers and host com
puters. As previously mentioned, the ruleset for the HIDS on the mail server is
customized to protect it from mail server exploits, while the Web server rules are
tailored for Web exploits. During installation, individual host machines can be
configured with a common set of rules. New rules can be loaded periodically to
account for new vulnerabilities.
Distributed IDS :
A Distributed Intrusion Detection System, or DIDS, is a combination of NIDS
sensors, HIDS sensors, or both, distributed across your enterprise, and all
reporting to a central correlation system. Attack logs are generated on the sensors
and uploaded (either periodically or continuously) to the central server station
where they can be stored in a central database. New attack signatures are created or downloaded to the management station as they become available, and can
then be downloaded to the sensors on an as-needed basis.The different kinds of
sensors may or may not be managed by the same server, and the management
servers are frequently separate from the servers that collect the logs.The rules for
each sensor can be tailored to meet its individual needs, suiting the network or
the host that each sensor monitors. Alerts can be forwarded to a messaging
system located on the correlation system station and used to notify the IDS
administrator.
A Distributed Intrusion Detection System, or DIDS, is a combination of NIDS
sensors, HIDS sensors, or both, distributed across your enterprise, and all
reporting to a central correlation system. Attack logs are generated on the sensors
and uploaded (either periodically or continuously) to the central server station
where they can be stored in a central database. New attack signatures are created or downloaded to the management station as they become available, and can
then be downloaded to the sensors on an as-needed basis.The different kinds of
sensors may or may not be managed by the same server, and the management
servers are frequently separate from the servers that collect the logs.The rules for
each sensor can be tailored to meet its individual needs, suiting the network or
the host that each sensor monitors. Alerts can be forwarded to a messaging
system located on the correlation system station and used to notify the IDS
administrator.
