Network Sniffers Do Not See All Packets

A network IDS works by running a network adapter in promiscuous mode to capture all of the packets coming into and going out of a particular subnet. Notice that this is not the same as watching all of the network traffic that appears on a subnet. Look at Figure 9.2. Here, the physical arrangement of the nodes is in a ring with node B sitting between node A and the node running the IDS. The packet “Hello B” is sent from node A to node B. However, because A and B are directly adjacent, B grabs and processes the packet sent by A. The node running the IDS never has a chance of seeing the packet.

Figure 9.2  An IDS does not see all packets on a subnet.

This means that a network IDS is not designed to track all the network activities on a subnet. Instead, the IDS is positioned to look for inbound and outbound packets at the entry/exit of the subnet. Following terminology introduced earlier in the book, the network IDS catches intruders, but it does not always catch internal misuse. If the packet from A to B had been a misuse or internal hack, the IDS node would miss it. To catch attacks between nodes, an intelligent IDS sniffer would need to be run on each node.

Network Sniffers Are Blinded by Encryption

Many sites rely on encryption for privacy of network traffic. In some cases, two corporate sites are connected by an IP tunnel. A firewall at each site implements the IP tunnel so that all traffic is encrypted as it passes across the unsecure Internet. After a firewall receives an encrypted packet from another site, the packet is decrypted and sent on to the target node in the secure network. A configuration like this does not hinder network intrusion detection. The packet appears in the clear as it leaves the firewall. Because the network IDS is the first node after the firewall (see Figure 9.1), the encryption does not impact the solution.

In some cases, though, an IP tunnel is established between two arbitrary nodes in a network. The nodes could be in the same subnet, or they could be communicating across the Internet. The IP traffic is not decrypted until the receiving node reads the packet from its network adapter. The network IDS has no way of seeing the cleartext version of the packets. Any attack signatures that require cleartext packets will not work when two nodes use an IP tunnel. Again, one possible solution to this problem is to run a sniffer on each node. Note that the sniffer must be in the OS network stack after the packets are decrypted.

When you connect from a browser to a Web server using secure sockets (SSL), the packets from your computer are not decrypted until they reach the Web server application itself. SSL packets flow through the firewall and remain encrypted. The packet arrives at the Web server node, moves up through the kernel stack, and is read by the Web server program from a socket. It is not until this last step, which only the Web server program itself controls, that the packet is decrypted. This type of application-level encryption also blinds network sniffers to many attacks such as the “phf” hack.

Missed System-Level Attacks

As mentioned in Chapter 6, “Detecting Intruders on Your System Is Fun and Easy,” system-level monitoring has access to important events such as privilege transition. A new attack that causes a buffer overflow and gives root privileges to a remote user will not be seen by a network IDS. If the attack signature is written properly, the system-level IDS will detect and respond to this type of situation.

Two general classes of attacks exist that a network IDS cannot detect, but a system-level IDS can. You can think of the first class as unknown side effects. When an activity on the system happens as the result of receiving a network packet, it’s possible that a side effect will occur that violates your security policy. Examples include the following:

•  Creation of a world-writable file by a privileged program as a result of processing a network packet

•  Downgrading the security of an existing resource, such as making /etc/passwd world writable

•  Upgrading the privilege of a user, such as changing the UID of a normal user to zero in /etc/passwd

•  Creation of a back door, such as any program that can lead the user to a root shell

Unless the hacks that led to these breaches already are known in the security community, the network IDS will not see these events, but the system-level IDS will. If you have a scanner, some of these problems will be caught the next time it runs. In some sense this argument seems unfair because it merely states that if the attack is not known in the community, the network IDS vendor cannot build a signature to catch the attack. However, even if the initiation sequence for the attack is unknown, a system-level IDS can detect that a SUID root program was created. What this says to you is that you need both types of IDSs—system and network—to catch all of the attacks you face.

The other class of system-level problems that a network IDS misses are attacks that are not based on sending or receiving network packets. Examples include any hacks launched by directly attached terminals or TTYs. If you are connected to the computer system with a terminal, you can start a nasty brute force password guessing program, and no network sniffer will be able to detect it. Most midrange hardware vendors still sell a significant number of dumb terminals to customers. Naturally, these threats are posed mostly by insiders rather than intruders.