To test your intrusion detection system (IDS) software usage, from the main screen click the IDS Testing tab, shown in Figure 6.22. Next, enter the source host IP address (this can be an address from a system on the network) in the Source IP Address box.
Then enter the IP address of the destination host in the Destination IP Address box. Be sure to enter the TCP port to where you’ll send the IDS script (the default is TCP/80).
Finally, select the IDS script in the listbox on the left. You can run only one script at a time. The following list explains the various IDS scripts:
Figure 6.22 IDS Testing module.
Single Out-of-Order TCP Segment Test. This script determines whether your IDS is capable of reconstructing data from network transactions when the pack- ets compromising those transactions are sent out of order.
Baseline (Single-Segment). This script determines whether your IDS is appro- priately configured to detect attacks in TCP network traffic. A variation is the Baseline (Multiple-Segments)test.
Desynchronization Test. This script attempts to “desynchronize” your IDS from a TCP connection used for carrying out an attack. By creating a false TCP connec- tion prior to carrying out a real attack, this test attempts to convince your IDS that the attack-bearing connection is entirely invalid, thus preventing it from monitoring the data exchanged in the connection. This specific test functions by opening a connection, immediately resetting it, and opening a new connection in its place.
All Out-of-Order TCP Segment Test. This script determines whether your IDS is capable of reconstructing data from network transactions when the packets compromising those transactions are sent out of order. Real TCP/IP network software is capable of handling arbitrarily ordered packets; IDS is frequently unable to do so.
TCP Sequence Number Verification Test (Jump-Up). This script attempts to determine whether your IDS adequately verifies the sequence numbers on TCP segments. Real TCP/IP network software discards TCP segments that do not bear appropriate sequence numbers. IDS frequently does not and can be forced
to accept bad network packets that confuse TCP analysis and allow attacks to slip past the system. This specific test functions by artificially increasing the sequence numbers in midconnection. A real TCP/IP stack will discard the con- nection at this point; a poorly functioning IDS will not.
TCP Sequence Number Verification Test (Interleave). This script, another varia- tion of the preceding sequence number verification testing, functions by artifi- cially inserting a badly sequenced duplicate TCP segment after each legitimate segment. Real TCP/IP stacks will discard the bad segments and reassemble the attack that the connection contains; poorly functioning IDS software will not.
IP Checksum Verification. This script attempts to determine whether an IDS correctly verifies the IP checksum carried on IP packets. Real TCP/IP software ensures that the checksum on each packet is valid before processing it. Some IDSs do not verify the checksum and can thus be fooled into accepting bad packets, which confuses network traffic analysis and allows attacks to slip past the system.
TCP Checksum Verification. This script attempts to determine whether an IDS correctly verifies the TCP checksum carried on TCP packets.
TCP Data-in-SYN Test. This script attempts to determine whether your IDS correctly deals with data contained in TCP handshake packets. Real TCP/IP software, in accordance with the RFC 793 standard for the TCP protocol, accepts data contained in SYN handshake packets. Some IDSs do not, and data contained in SYN packets is thus invisible to these systems.
IP Fragment Tests Replay. These scripts attempt to verify that your IDS correctly reassembles complete IP packets out of IP fragment streams. They include the following:
■■ IP Fragment Replay
■■ IP Fragmentation Test (8-Byte Tiny Frags)
■■ IP Fragmentation Test (24-Byte Packets)
■■ IP Fragment Out-of-Order Test
■■ IP Fragmentation Overlap test
■■ IP Fragmentation Test (Out-of-Order Fragments)
TCP Three-Way-Handshake Test. This test attempts to verify whether your IDS actually waits for a handshake before recording data from a connection.
TCP ACK Flag Verification. Data exchanged in a TCP connection is sent in a TCP packet with the ACK (acknowledge) flag set. Many TCP/IP stacks will refuse to accept data in a packet that does not bear an ACK flag. IDSs frequently do not verify the presence of the ACK flag and can thus be confused into accept- ing data that is not actually being exchanged in an actual connection.
TCP Segment Retransmission (Inconsistent). This test attempts to confuse your IDS by replaying a segment with inconsistent data. A real TCP/IP stack will dis- card the retransmitted packet; broken IDS software will accept the packet and become desynchronized.
TCP Second-SYN Test. TCP connections are initiated by a handshake protocol involving TCP packets with the SYN flag set. A TCP SYN packet requests a new connection to be created and specifies the sequence numbers for the new con- nection. Real TCP/IP software rejects SYN packets received after a connection has started. This test sends spurious SYN packets that may confuse broken IDS software.
TCP Reset Test. TCP connections are terminated by messages that request con- nection teardown. Real TCP/IP software closes open TCP connections when a correctly sequenced teardown message is received; once a connection is closed, a new connection can be created by using the same ports. Some broken IDSs fail to tear down connections when a teardown message is received. These systems are incapable of tracking new connections that reuse the port numbers from pre- viously closed connections.
TCP Sequence Number Wrapping. TCP sequence numbers are 32-bit integers.
The sequence numbers of a given connection start at an effectively random number. TCP/IP network stacks are required to handle sequence number wrap- around, which occurs when the TCP sequence number exceeds the maximum number that can be expressed in 32 bits and thus wraps back to zero. Broken IDSs fail to handle this case, and packets received after the sequence numbers wrap are discarded.
TCP Overlap Test. TCP packets contain a variable amount of data. The sequence numbers on a TCP segment specify at what point in the stream the data in that segment should appear. Two TCP segments can contain conflicting data if the sequence space used by the two segments overlap. Each type of TCP/IP stack handles this rare case differently. An IDS that cannot duplicate exactly the behavior of the systems it watches can be confused and forced to see different data on the network than what is actually being exchanged.
When you’re ready to begin testing, click the Send Script button; then monitor the results of the test with your IDS software.