Header
Home | Set as homepage | Add to favorites
Sections
Syndication


Blogroll:

||||| ALL Cisco-Network ARTICLES |||||  
CCIE Journey,
The CCIE Journey, 



Host- and Network-Based IDSs

image


 

IDS systems can be installed on a host, on the network, or on a combination of both. Each monitoring location has its own benefits and drawbacks. Network monitoring requires the installation of probes on the network that’s to be monitored, while host-based monitoring requires that software be installed on all host systems to be monitored. Both types of IDS are configured to send alarms and events to a central location.

Host-based and network-based IDSs send alerts and alarms to a centralized location where security administrators can view them. CIDS sensors can be managed using Cisco Secure Policy Manager (CSPM). Additionally, sensors can be configured using the built in Device Manager application included with the sensor software. Alarms and events can be collected and viewed using Cisco’s Event Viewer. These applications are discussed in more detail in Chapter 25.

Host-Based Detection

By installing a software agent on all hosts, host-based IDSs monitor all system activities, log files, and network traffic received. Host-based systems might also monitor the OS, system calls, audit logs, and error messages on the host system. While network probes can detect an attack, only host-based systems can determine whether the attack was successful. Additionally, host-based systems can record what the attacker performed on the compromised host.

Not all attacks are performed over the network. By gaining physical access to a computer system, an intruder can attack a system or data without generating any network traffic. Host-based systems can detect attacks that are out-of-band or performed from the console, but a savvy intruder with knowledge of the IDSs can quickly disable any detection software once physical access is accomplished. Neither host nor network-based IDS is a replacement for proper physical security.


Note 

Out-of-band is a term used to describe any traffic or access that doesn’t traverse the public or monitored network. Common out-of-band access methods are a private network, a console connection, or an RS232 serial connection between two or more hosts.

Another advantage for host-based monitoring is its capability to detect stealth attacks. Some network-based IDS systems can be fooled by playing with the fragmentation or TTL of the packets. For a host to process traffic, it must be received and reassembled, and, therefore, it’s subject to monitoring by the host-based IDS. Packet fragmentation and Time to Live (TTL) manipulation are discussed in the section “Network-Based IDS.”

Host-Based Drawbacks

Host-based IDSs have four key disadvantages or weaknesses:

  • Manageability

  • Micro view of network attacks

  • Compromised hosts

  • Operating systems limitations

Depending on host-based IDSs requires the IDS software be installed on all hosts. This can become an administrative nightmare as version control, software maintenance, and software configuration become a time-consuming and complicated task.

Because host-based systems only analyze traffic received by the host, they can’t detect common reconnaissance attacks performed against the host or a range of hosts. Host- based IDSs won’t detect ping sweeps or port scans performed across a range of hosts.

When a host-based IDS detects an attack, it sends a notification to the management station or the sensor responsible for collecting and recording alarms. If the host is compromised, it might be possible for the intruder to disable the IDS software or that host’s network connection. If the IDS software or the network connection are disabled, the host won’t generate an alert.

IDS software must be installed on each system on the network to provide complete coverage of the network. In heterogeneous environments, this can become a problem because the IDS software must support so many different OSs. Before deciding on an IDS system, you should ensure the IDS software will run on each OS present on the network.

Network-Based IDSs

Network-based IDSs uses probes or sensors installed throughout the network. These probes sniff the network looking for traffic that matches a defined profile or signature. Sensors receive and analyze traffic in real time. Once a traffic pattern or signature is recognized, the probe sends an alert to the management platform and can be configured to take action to prevent any additional access.


Note 

Sniffing the network is a term used to describe a network interface that receives all network traffic. Typically, a network interface only processes packets that are specifically addressed to the host or the broadcast address. By placing the interface in Promiscuous mode, the interface can receive, process, and analyze all traffic traversing the network, regardless of the Layer 2 or 3 address. Legitimate tools used by network engineers to view all network traffic are commonly called network sniffers.

Network-based detection has the advantage of seeing intrusions from a network perspective. While host-based detection can’t detect a ping sweep or a port scan across multiple hosts, network-based IDSs can easily detect such reconnaissance attacks. Network-based sensors generate an alert when these reconnaissance attacks are discovered.

Network-based IDSs don’t depend on the resources of a host machine and, therefore, won’t use valuable network and CPU cycles on mission-critical servers. Additionally, because there’s no software to install, there are no issues with OS compatibility. With network-based IDSs, the IDS software runs only on the director and the sensors.

Sensors have an interface used for monitoring the network (monitoring interface) and a second interface used for command and control (command and control interface). Sensors can’t send network traffic on the monitoring interface (MI) and are, thereby, invisible to anyone unfamiliar with the security features of the network. The command and control interface (CCI) can send and receive management traffic, and this is the interface used to communicate with the management or director computer(s).

To ensure proper security, the network-based IDS should have a separate and highly secure management network. The director platforms and sensors will communicate with one another via this secured management network. Each probe will use this network to send alarms to the director platform, and the director platform will use this management network to configure and update each network sensor.

Network-Based Drawbacks

Network-based intrusion detection has four basic weaknesses:

  • Bandwidth

  • Packet fragmentation and reassembly

  • TTL manipulation

  • Encryption

One of the more difficult weaknesses to compensate for is the bandwidth limitation of network-based intrusion detection. Network probes must receive all network traffic, reassemble that traffic, and analyze the traffic. As network speeds increase, so must the capabilities of the intrusion detection probes. The solution is to ensure the network is designed properly to allow the strategic placement of multiple probes. As the network grows, more probes can be added to ensure proper coverage and security.

One way hackers attempt to conceal their activity from network-based IDS is to fragment their packets. Each protocol has a maximum packet size. If data to be sent across the network is larger than the maximum packet size, the packet must be fragmented. Fragmentation is simply the process of breaking up data into smaller pieces. These pieces must be put back together in the correct order for proper analyzing. Some OSs reassemble packets first to last, while others reassemble packets last to first. The order of reassembly isn’t an issue as long as no overlap occurs. If a fragmentation overlap occurs, the sensor must know the correct reassembly process. Many hackers attempt to prevent detection by sending overlapping fragmented packets. A sensor won’t detect intrusion activity if the sensor is unable to reassemble the packets correctly.


Note 

Maximum packet size, also known as maximum transmission unit (MTU), is dependant on the type of network used. Ethernet typically has a MTU of 1,500 bytes, while token ring, for example, can have an MTU of 8,000 bytes or more.

Manipulating the TTL field on multiple packets is another technique used to fool network-based sensors. All TCP/IP packets have a TTL field, which specifies how long a packet should be considered valid on the network. The initial value of the TTL field can range from 1 to 255. Each time a packet passes through a router, the TTL is decremented by 1. When the TTL value reaches zero, the packet is discarded and is no longer forwarded. Figure 23-2 shows how an attacker might use a TTL attack to try and fool a network-based IDS. As you can see in Figure 23-2, the attacker can send packets with a lowered TTL that will reach the sensor, but not the host. Additional packets are sent that reach both the sensor and the host. TTL manipulation is ineffective if the probe and the host are located on the same local area network (LAN).

Click To expand
Figure 23-2: Manipulating network-based sensors using TTL

Using a TTL attack, an intruder can send hundreds of packets to the target network with a lowered TTL. Packets with the lowered TTL reach the sensor, but won’t be forwarded to the host. When the packets reach the router, the TTL is decremented and the packet is discarded. At the same time, the intruder could then send actual attack traffic with a normal TTL that will reach both the sensor and the host. In essence, the attacker is attempting to confuse the sensor by hiding malicious traffic within a stream of valid or nonsuspicious traffic. Because an attacker must have a detailed view of the network beforehand, this isn’t a simple attack to use successfully. This type of attack can only be used against network-based IDSs.

The third weakness of network-based IDSs is created through the use of encryption. To work properly, an IDS must read the contents of packets that cross the network. If the data held within the packet is encrypted, the sensor has no way of viewing the contents. If your network uses VPNs, IPSec, or any other form of encryption, then it’s important to place sensors outside the encrypted tunnels. Outside the encrypted tunnel, packets are no longer encrypted and, therefore, can be read by the sensor.

280 times read

Related news

» Intrusion Detection System Overview Summary
by alperen posted on Feb 24,2010
» Intrusion Detection Systems Overview
by alperen posted on Feb 24,2010
» Intrusion Detection System Overview Questions and answers
by alperen posted on Feb 24,2010
» Configuring Signatures and Alarms
by admin posted on Nov 26,2008
» Cisco Intrusion Detection
by admin posted on Nov 24,2008
Did you enjoy this article?
(total 0 votes)

comment Comments (0 posted) 

More Top News
CCSP-Cisco Certified Security Professional
Most Popular
Most Commented
Featured Author