2004-07-19
IntroductionThis is the second of a two-part article series that discusses various methods of testing the integrity of your firewall and IDS, using low-level TCP/IP packet crafting tools and techniques. Part one showed several examples that tested a firewall (port 80 TCP, and port 53, UDP) using tools like hping and tcpdump.We will now continue the discussion with a third test of the firewall, using the same tools as noted above, and then move on to test your IDS signatures and detection ability. Note that the focus here is on a Linux environment, but the process is similar with other Unix-like firewall/IDS environments as well. Please familiarize yourself with part one of this article before continuing on with this paper. Testing your firewall - third example, ICMP echo requestsThe example shown below is a simple ICMP echo request to see if a machine is alive, in this case our test machine.As was used extensively in part one of this article, we'll be using hping and tcpdump to perform the tests. The syntax and output of hping for a simple ICMP echo request is shown below:
This time there is one packet received as was noted above, and the round trip time is shown. By going with this it looks like our ICMP echo request was indeed allowed through the firewall. Below you will note the packet as it was sent on our hping machine. The output shows the packet was received on our hping test machine from the machine we just pinged from. The tcpdump syntax is shown below once again.
We can deduce from the above two packets that the destination computer's firewall did allow the ICMP packet through, as we received an answer packet back from it. I did not show the destination computer receiving the packet as we have successfully proven that the firewall is accepting our test criteria. Nor is there any firewall output to show as it did not cause any firewall rulesets to trigger. IDS signature test - reserved flag testWe will now begin to do some testing of our IDS, which in this case is Snort. This test was done with Snort's default ruleset.The first test that we will do is to see if our IDS triggers as it is supposed to when it receives packets with the ECN and CWR flags active in the 13th byte offset of the TCP header. Hping syntax is as noted below:
Noted below is the packet as seen when it was sent by the machine which had crafted it:
Note the flags WE in the above packet. These signify that the ECN and CWR flags are set in this packet. Now, note the packet below comes from the IDS test machine.
The packet is as it should be: a mirror image of the packet sent by the machine on which it was crafted. Now let's take a look at the Snort output. Below you will note the Snort output shown as it received the packet. You will see that there is a number 1 and 2 that are set in the output. This signifies that the proper bits for this byte are set. In this case it is bit 128 and 64 in the 13th byte offset in the TCP header. This is where all the flags are contained, in other words, flags such as SYN, FYN, PSH and such. There is a great deal of information logged in the Snort output. Starting on the first line and going from left to right I will explain the fields themselves. We start off with the date and time field, down to the microsecond (just like tcpdump). This is followed by the MAC addresses of the sending and receiving computers. Next is the type field which stands for DoD ethernet, and then the length of the packet itself. Now the source IP address and port is followed by the destination IP address and port. After that, you see TCP which is for the TCP packet and a time to live of 64. The type of service is shown to be zero. Then the IP id number is shown as 29729, and after it is the IP header length of 20 bytes. DgmLen stands for the datagram length. As mentioned above, the 1 and 2 mean that the bit positions 128 and 64 are set in this packet. Then we have the sequence number, as well as the acknowledgement number. Closing out this info is the window size and TCP length. Here is the Snort output from our first example:
In the
Our example was used to see if the Snort IDS would indeed trigger and log this as an alert, on receipt of a packet with the ECN and CWR flags set. As noted, it did indeed perform as it should have. Second IDS signature test - LSRR packetsWe will now test a different IDS signature. To be specific, we will see if Snort will indeed detect LSRR (Loose Source Record Route, commonly known as loose source routed) packets as it is supposed to.Hping syntax as noted is below:
The packets as they looked like when leaving the hping machine
The Snort output below is shown as Snort saw the packet:
Taken from the alert file in
And here is what was received on the test machine:
So as we can see, the Snort IDS definitely picked up the receipt of our LSRR packets. Now we can be confident that even Snort's default ruleset is working as advertised. Dispelling some mythsFinally, I would like to take the time to dispel some myths here about packet crafting. The first myth is about buffer overflows. You cannot send buffer overflows using a packet crafting tool because the three-way TCP/IP handshake needs to be completed for an exploit to work. This is why the code needs to be compiled, for within the code itself are the systems calls to handle the 3 way TCP/IP handshake.On most stacks today the sequence numbers are pseudo-random and therefore difficult to predict, making the ISN prediction attack impractical, though not impossible. So in light of this any data you inject into a packet will be ignored by the destination machine unless you have successfully completed the TCP/IP handshake. ConclusionHopefully you can now see the clear benefits of crafting packets, and what it will bring to you and your security posture. Not only that, but along the way you will also learn about the all-important subject of low level TCP/IP. The examples that were shown in this, and the first part of this article, are just a starting point -- each person's network or setup can be unique, and the firewall rulesets or IDS signatures will be different. It will be up to you to use the knowledge gained to actively probe your own defenses.
I sincerely hope you found this article series of use to you. Feel free to contact me, if you like, with regards to it.
|
||||||||||||
About the author
Don Parker is an Intrusion Detection Specialist who holds the GCIA certification. He works for Rigel Kent Security and Advisory Services as an instructor and also provides other computer security services of a highly specialized nature.
View more articles by Don Parker on SecurityFocus.
|
||||||||||||
|
Comments or reprint requests can be sent to the editor. |
