Packet Crafting for Firewall & IDS Audits (Part 1 of 2)
by Don Parker
With the current threat environment that home and corporate users face today, having a firewall and IDS is no longer a luxury, but rather a necessity. Yet many people do not really take the time to make sure though that these lines of defense are indeed working properly. After all, it is very easy to invalidate your router's entire ACL list by making a single misconfigured entry. The same can be said for your firewall, whereby one poor entry into your iptables script, for example, could leave you vulnerable. Have you properly configured certain options which may be available with your firewall? All of these questions can be answered, and more importantly verified through the use of packet crafting. What this will allow you to do is manually verify that all is working well with your firewall and IDS, and that each is properly configured.
It is best to not blindly rely on the output of certain automated tools when auditing devices that safeguard your valuable computing assets. I would compare this to an analogy where one manually checks his door locks and the burners on the stove before going to bed, instead of waiting for a burglar or a fire alarm to be woken up. You know you've done everything required to safeguard your environment, but at the end of the day you still want to make sure. Packet crafting, when used to audit your network, cannot verify all conditions affecting your firewall and IDS, but the process can do so a fair number of them.
This article is the first of a two-part series that will discuss various methods to test the integrity of your firewall and IDS using low-level TCP/IP packet crafting tools and techniques. The focus is on a Linux environment but the process will work similarly well with other Unix-like environment too.
Benefits of packet crafting
There are some side benefits to learning how to audit your firewall and IDS though the use of packet crafting. To learn how to effectively use tools such as hping, and reliably interpret their data, you force yourself to learn more about TCP/IP. Learning more about the base unit for computer communications, the packet, is a laudable goal for anyone wishing to further his knowledge of computers. That being said, I will not assume that all of the readers of this magazine have a good grasp of TCP/IP. Over the course of this article there will be detailed explanations of the output which will be shown. All of the fields shown in the Snort and tcpdump output will be explained clearly and concisely. You might say this will be as much about understanding TCP/IP as it is about learning how to test your firewall and IDS ruleset.
Several examples will be shown for both a firewall and IDS. Some very generic ones are used, as this document is meant to show you how to use hping, Snort, and tcpdump. Therefore, the examples listed below are a good starting point. After having played with the below noted examples you should feel comfortable enough to actively test your own firewall and IDS. Note that there are also automated tools out there which can do this for you. It is important, though, that you know how to do it yourself and are able to monitor and analyze the output. This will give you a feeling of confidence knowing that your perimeter defenses are indeed working as advertised.
Testing your firewall - first example
We will now start off by showing several examples of how to test your firewall for various conditions. The first one will be to see if you have port 80 open through your firewall. The second example will check to see if your firewall has port 53 open as well, and then we'll conclude part one of this article.
Please note that these tests were performed on Linux using SuSE Professional 9.0 with the standard Iptables firewall ruleset in place. I am not including a sample IPTables syntax here as you may be using IPChains on Linux instead, or perhaps a firewall appliance, a commercial firewall or some other type of solution. It would also be difficult to put down a rule that takes into account all of the other rules as well, which is the primary reason for not having provided a sample rule syntax here. To that end, each condition being tested will be explained so as to give you the context in which it was tested. In part two we'll look at Snort; the Snort build used was Snort 2.1.0 with a standard default ruleset in place.
The below noted example shows a packet sent to port 80. The packet is silently dropped as it should be, due to the configuration of our SuSE firewall. Normal behavior for a TCP packet sent to a port with no listening service would be a reset packet being sent back to the originating machine.
Shown below is a cut and paste of my term window and the syntax used to invoke hping. I will explain the hping switches used below for this example, however unless there is a major difference in syntax I will not elaborate again on hping syntax.
Note as well the output of the hping below the command line syntax. This just shows the address that the packet is going to, that S is set (SYN packet), that there are 40 bytes in the packet (normal TCP/IP header size) and that there are 0 data bytes in the packet.
The last remaining bit of our hping output, as seen below, are the statistics for the packet crafting you just did using hping. It tells you 1 packet was transmitted, 0 packets were received back, and that it was %100 packet loss. It also gives you the round trip time if any packets were sent back.
Having used the above noted command syntax, seen below is what the packet looks like as it is sent from the machine that it was crafted on using hping. The tcpdump syntax noted below to invoke tcpdump will now be explained.
Using the above two IP addresses with the noted syntax stipulates to tcpdump that you want to collect packets that go between 192.168.1.100 and 192.168.1.108 only. This cuts down on chatter that you may pick up on from, say, your ISP's DNS server or your switch's ARP packets.
To help you in reading tcpdump data I will fully explain all the fields in the packet below, just as I have explained the tcpdump syntax used. Starting with the time field we will now see what every field means.
The below noted screenshot is from the destination computer that we are testing, showing what happened when this packet was received. It was dropped by default as there is no service presently there, and that is how IPTables is configured to deal with packets sent to ports offering no services by default on SuSE.
This is the packet as it arrived at the test machine. All is normal, as can be seen:
So as we can see when the packet was sent, it was indeed received by the destination machine, however it was silently discarded.
Testing your firewall - second example, probing port 53 UDP
Now we'll try a second example and probe port 53 UDP. Note below the hping syntax that was used, and its ensuing output as well:
We have now sent a UDP packet to port 53 to see if it will also silently drop the packet. As we can see from the hping output and the firewall information below, it was indeed discarded as port 53 UDP is closed off.
This is the packet as it was received on the machine we are testing:
This is the packet as it was sent out from the machine we are using to test the security of the firewall:
Normal behaviour when a UDP packet is sent to a port that is not listening is that an ICMP port unreachable message is sent. In our case however this does not happen as the test machine has its IPTables script set to silently discard these types of packets.
As you are beginning to see, packet crafting is a rather excellent tool to use in verifying your firewall ruleset. Especially one which can get rather complex and granular as an IPTables script can become.
Concluding part one
We have looked at two examples of testing your firewall using hping and tcpdump. Next time, in part two of this article, we'll look at another firewall example and then move on to test the Snort IDS using similar methods as were outlined here. Stay tuned.
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.|
This article originally appeared on SecurityFocus.com -- reproduction in whole or in part is not allowed without expressed written consent.