“No Hard Drive? No Problem!” SANS Network Forensics (Sec558)

A lot has been written about methods for “fingerprinting” systems with active scanning methods (eg. nmap). These of course require that the system be actively reachable, and that you don’t mind totally giving away your position with a very noisy scan (sort of like shooting a shotgun directly at a suspect to see if you can get him to look at you, in hopes that you’ll catch a glimpse of his face).

A lot has also been written about more covert ways of achieving the same goal, based on packets surreptitiously captured from the host of interest (a la p0f). This is certainly very cool, and can be inordinately useful…if you happen to have packet captures from the host of interest, or can begin to get them. (Either you were capturing its packets to begin with, or it’s still around to get packets from.)

But what if the system is long gone, never to return? Or what if you’re lucky enough to see it again, but for technological/logistical/legal reasons you can’t grab its packets? As we see in Sec558, all hope is not lost…

While most firewalls report only sparse information about the packets that they see (and perhaps reject), many of them at least include such information as the Time To Live (TTL) field. What a lot of forensic analysts don’t realize is that different operating systems choose different initial values for the TTL field. For example, current versions of Linux start with 64, and Windows with 128. So if you see a packet logged by a firewall with a TTL of 61, it’s a pretty good guess that it came from a Linux system 3 hops from the firewall. Of course it could be a Windows system 67 hops away, but which is more likely?

TTLs can be, and sometimes are, crafted. But when dealing with the 99% of packets whose headers aren’t crafted, this works like a charm. You can also correlate TTLs with other aspects of the network traffic logged by a firewall, such as source and destination port numbers, IP ID sequences, and such.

Here are three lines from an iptables firewall log. Can you guess what OS the client is running? How about the manufacturer?

Mar 24 12:13:13 192.168.1.10 kernel: [ 915.256256] FIREWALL:BLOCKEDIN=eth3 OUT= MAC=ff:ff:ff:ff:ff:ff:00:21:70:4d:4f:ae:08:00 SRC=192.168.1.170 DST=192.168.1.255 LEN=96 TOS=0×00 PREC=0×00 TTL=128 ID=61495 PROTO=UDP SPT=137 DPT=137 LEN=76 Mar 24 12:13:14 192.168.1.10 kernel: [ 916.006952] FIREWALL:BLOCKEDIN=eth3 OUT= MAC=ff:ff:ff:ff:ff:ff:00:21:70:4d:4f:ae:08:00 SRC=192.168.1.170 DST=192.168.1.255 LEN=96 TOS=0×00 PREC=0×00 TTL=128 ID=61496 PROTO=UDP SPT=137 DPT=137 LEN=76 Mar 24 12:13:14 192.168.1.10 kernel: [ 916.764653] FIREWALL:BLOCKEDIN=eth3 OUT= MAC=ff:ff:ff:ff:ff:ff:00:21:70:4d:4f:ae:08:00 SRC=192.168.1.170 DST=192.168.1.255 LEN=96 TOS=0×00 PREC=0×00 TTL=128 ID=61497 PROTO=UDP SPT=137 DPT=137 LEN=76

With a TTL of 128, this is probably a Windows system 0 hops away (meaning it has not traversed a router, so it is on the local segment). This is further supported by the UDP port 137 (NETBIOS) traffic, which is very common for Windows systems. The sequential IP IDs tend to corroborate this as well.

Based on the first three bytes of the MAC address (“00:21:70″), it’s probably a Dell.

Jonathan Ham is an independent security consultant and a SANS Certified Instructor, who teaches forensics and other tracks. When he goes to sleep at night, he counts packets as they leap through firewalls.