Part II: Traffic Analysis
7 Packet Dissection Using TCPdump
8 Examining IP Header Fields
9 Examining Embedded Protocol Header Fields
10 Real-World Analysis
11 Mystery Traffic
Chapter 7. Packet Dissection Using TCPdump
The next four chapters explore using TCPdump to analyze network traffic. TCPdump provides some wonderful benefits when used with a signature-based NIDS in a network. Most often, when signature-based NIDS detect some kind of anomalous activity, it is due to a pre-defined signature discovering a malicious packet. Typically, the NIDS will alert on the activity and perhaps capture the single packet that it perceives to contain an event of interest.
There are several problems with this method. First, as anyone who has ever used a NIDS knows, these systems are prone to generating alerts when there really is no problem. This is known as a false positive. The reason that many NIDS generate false positives is because signatures are not specific enough and the packet is not examined in context with those that precede it or those that follow.
It really is helpful to have a tool such as TCPdump running in the background capturing traffic into and out of the network—kind of like a traffic audit trail. Although TCPdump, by default, doesn't capture the entire packet, you still have much of the pertinent information captured in the headers— where the traffic came from, where it is going, and what the purpose of the packet is. The signature-based NIDS can inspect the packet on its own for payload anomalies. The captured TCPdump traffic can be used to distinguish real alerts from false positives. Assuming that your NIDS affords you access to the signature and access to the packet that caused the alert to fire, you can examine the given packet for problems. Additionally, you can use the TCPdump traffic collected before and after the alert to assist in the assessment. There have been many times when examining collected TCPdump records has provided the extra detail to allow more accurate assessments of alerts generated by a NIDS.
The quest is to become proficient at doing analysis of traffic apart from a NIDS, which is what the next four chapters will teach you.
We start off with the most basic analysis possible—looking at the packet at the bit level. Chapter 8, "Examining IP Header Fields," will show you how to dissect a packet for the rare occasion when a packet-sniffing tool is not adequate for packet interpretation. Next, Chapters 9, "Examining Embedded Protocol Header Fields," and 10, "Real-World Analysis," discuss another level of interpretation—examining fields in the packet. As we discovered when looking at TCP/IP, it is impossible to tell what is abnormal unless we are familiar with what is normal. The same goes for understanding the fields in a packet. Next, in Chapter 11, "Mystery Traffic," we will move one layer higher in the analysis process by looking at the packet as a whole. In other words, discovering the intent of the packet. After we have completed this topic, we will look at some real-world events from monitored traffic using TCPdump. Here, we will study a synthesis of packets to understand some incidents. Finally, Chapter 12, " Writing TCPdump Filters," looks at
beginning forensics in an attempt to further explain a specific real-world event. We will delve into passive fingerprinting and try to determine if activity has been spoofed or is from many different real sources.
Background Activity Isn't Always Noise
As mentioned many times in the book, a NIDS is required for detecting pre-defined anomalous behavior, whether it is some suspicious payload in a packet or some violation of protocol. Although there are NIDS that can be configured to dynamically capture packets after the suspicious one, NIDS do not save packets that are of no current interest. That is why the use of TCPdump or any other tool that can capture background traffic is advocated. There will be events of interest that might not have pre-defined signatures.
Years ago, I was a member of a military CERT team when we received an email from an administrator of another site who informed us that he believed that a computer from our network had been used to break into a computer on his network. He supplied us with the alleged date, time, source, and destination IPs. He gave us one other valuable piece of information: he believed a user account with the name of Darren had been added to the password file. Immediately, we researched the complaint and discovered that the source IP from our network alleged to be involved was a static IP associated with our dial-in pool of addresses. This was many years ago, before DHCP was in vogue. The owner of the IP address was a well-respected manager who seemed the antithesis of the stereotypical hacker. We asked around and discovered the man had a teenage son named Darren. With no sense of culpability or shame, the employee readily admitted to the security officer that he'd given his military dial-in account number, username, and password to his son. Yet, he vehemently denied that his son would be involved in hacking.
At that point, it was up to the security team to prove any guilt. We began our efforts by searching the TCPdump records from the day and time of the incident, and several days before and after to amass a profile of the use of the IP. We discovered that the source IP had connected to the destination IP reported by the system administrator and that the user of the source IP had visited literally hundreds of pornography sites as well. But the activity of the user of the IP had set off no alerts on the NIDS. Only the audit trail of TCPdump records allowed us to resolve the complaint.
Think about the use of alarms in department stores. Most are equipped with some kind of burglar alarm to sound if there is a break-in or intrusion after hours. And, most have a device that alarms on your way out of the store if you haven't deactivated some kind of indicator by paying for a piece of merchandise. So, the department store alarms are equipped to alert on some pre-defined conditions. Yet, department stores also have video cameras at doors or other locations in the
store. These cameras record an audit trail of activity that might be entirely unrelated to break-ins and thefts. I remember a news report about a sought-after kidnapper who had used his credit card number at a Wal-Mart. This same Wal-Mart had cameras that captured his and the kidnapped child's images on video. His activity didn't set off any alarms, yet having the background tape of store activity assisted law enforcement in identifying and capturing the kidnapper.
Why Learn to Do Packet Dissection?
With all the tools, both free and commercial, available to do packet interpretation for you, why
is it necessary to re-invent the wheel by performing your own packet dissection? If programs such as Ethereal can perform every layer of interpretation from the frame header to protocol decodes appropriate for the packet's particular payload, why would you even need to know how to interpret hex or bit output of the packet? Well, these are excellent and accurate dissection tools when you have a packet with expected values and predictable pedestrian behavior. When someone crafts a packet with unusual or unexpected values, these tools might fall far short of being accurate.
As an example, early in 2001, a program known as sidestep was released by Robert Graham, a Chief Technical Officer (CTO) of an NIDS company. The assertion of the author that was demonstrated by sidestep was that NIDS must be protocol-aware so that they will not be susceptible to techniques used to elude detection. There is a derogatory term network grep, or packet grep, that is used to describe a NIDS that simply looks for a string of characters in a packet as a signature for discovering malicious activity. The UNIX grep command searches for a string of characters in text or files, hence the term network grep. If a NIDS is not protocolaware, it might be duped by simple manipulations of payload.
Sidestep can be run in evasive mode for different protocols such as DNS, RPC, and several others to prove the author's point. In the DNS evasive mode, sidestep queries a DNS server for the version of BIND it is running. A DNS server readily responds to this if it has not been silenced from giving out this potentially valuable information. If a normally formatted version of BIND query is issued, most NIDS detect this by looking for the string "07version04bind". The numeric prefixes, also known as labels, seen before "version" and "bind" simply tell how many characters are found in the following node.
RFC 1035 explains the use of pointers in DNS payloads. The legitimate use of pointers is found in a DNS response when there are multiple records returned with repeated information. For instance, what if you issued a query that returned several hosts with a node of veryveryverylongname? If you have host1.veryveryverylongname.com returned as a first response, a second response that needs to reference host2.veryveryverylongname.com can include the node host2 and point to the position of the occurrence of veryveryverylongname.com in the first response. This obviously shortens the response quite a bit, especially if you have several responses with veryveryverylongname.com in them. If you want more details on the concept of using pointers in a DNS query, look at the section, "Sidestep
DNS Queries."
Pointers can be used in queries as well for evasion purposes, as demonstrated by running sidestep. It is no longer necessary to have the node "version" precede the node "bind" in the string of characters in the DNS query. Pointers can direct the decoding of the query so that the node "bind" could precede the node "version" in order, but not in the order in which they are decoded by the DNS server. The DNS server happily responds to a query with pointers, yet a NIDS that does a network grep for "07version04bind" is blind to the query.
Before all of this was discovered, I tried to understand the evasive machinations employed by sidestep. I ran the code in evasive mode and used Ethereal. Ethereal was great at doing packet capture and decoding all the normal behaviors and values, but it was as clueless as I was when it came to discovering the evasive techniques used. At that point, I was decoding bits and reading RFCs. Indeed, most times, you will not be involved in this type of sleuth work, and your packet sniffers/decoders will be excellent and reliable tools.Yet, for the rare times when they fail, you will be left to your own wiles to understand the packets, which is why we are about to discuss packet dissection. And, if you aren't convinced that learning packet dissection is worthwhile, another benefit is that it helps you become infinitely more familiar with the protocol that you are analyzing.