| Previous | Table of Contents | Next |
Like any other application that you run in a distributed environment, a network IDS needs to provide useful systems management capabilities. Features needed include the following:
Depending on your level of sophistication, you might also be interested in designing your own attack signatures. Not all network IDSs provide a simple way for you to create signatures.
What can a network IDS detect? First, because the source of information is network packets, network IDSs look for attacks that are targeted at network protocols. Examples include Ping of Death and SYN Flood because both of these are attacks against weaknesses in TCP/IP itself. Problems in other protocols, such as Novell IPX and Microsoft SMB, also are found.
Protocol problems result in other attacks such as the following:
Next, by analyzing packet data content (as opposed to header fields) a network IDS can look for attacks such as the AIX “rlogin -froot” bug. Other example application attacks and vulnerabilities detected by network IDSs are as follow:
Unlike scanners that occasionally probe your systems for these weaknesses, network IDSs look for evidence of someone mounting one of these attacks against your systems in real time. The evidence is found by inspecting the contents of packets.
Finally, scanning packet data for unauthorized strings such as “confidential”, “proprietary”, “secret”, and other potential leakages is another feature found in some network IDSs. A list of keywords can be configured into the IDS. Naturally, performance concerns arise if the list is too long.
Chapter 7, “Vulnerability Scanners,” described useful scanner tools that can be used to probe your systems for weaknesses. If a hacker is scanning your system with ISS or SATAN, a network IDS should be able to detect the activity. Of course, looking for patterns such as port scanning of TCP/IP ports is a process that also is affected by time. What if an attacker scans one port per day? Is this something that a network IDS can detect? Most network IDSs have a time-out setting that you can configure to determine the interval, which constitutes a group of related events such as sequential port scans. If you set this value too small, you could miss sequential port scans across days, for example.
Breaking down packets into smaller chunks and reassembling them into the proper format is something that happens often in network communications. You saw how this happens between network layers on the same system, and between peer layers on different systems when you read Chapter 4, “Traditional Network Security Approaches.”
A well-known attack called IP Fragmentation tries to inject or form bogus IP packets so that when they are reassembled at the target node, there is a chance for a successful hack. Various operating systems handle reassembly of fragmented packets differently. So, the attack will not always succeed.
Recall that sequence numbers are included in TCP/IP packets so that the receiving node can reassemble packets received out of order into the proper format. By messing around with sequence numbers in injected or forged packets, an attacker can trick the receiving system into overlaying already received data with something else. For example, if the target node received a packet with the sequence number for bytes 1–5 and data “smith.” The hacker could send another packet with the same sequence number but data “root.” Depending on how the receiving OS handles this condition, it will either overlay the first packet or discard the new (hacked) packet. The behavior of the OS determines whether the hack succeeds or not.
| Previous | Table of Contents | Next |