Time is an important aspect of Network Security Monitoring. If you don't pay close attention to the time shown in your evidence, and recognize what it means, it's possible you could misinterpret the values you see.
My students and I encountered this issue in TCP/IP Weapons School at Black Hat this week. Let's look at the first ICMP packet in one of our labs.
I'm going to show the output using the Hd tool and then identify and decode the field that depicts time.
In the following output, 2d 0c 65 49 occupies the part of the packet where Libpcap has added a timestamp.
Hd output:
$ hd icmp.sample.pcap
00000000 d4 c3 b2 a1 02 00 04 00 00 00 00 00 00 00 00 00 |................|
00000010 ea 05 00 00 01 00 00 00 2d 0c 65 49 5f bf 0c 00 |........-.eI_...|
00000020 4a 00 00 00 4a 00 00 00 00 0c 29 82 11 33 00 50 |J...J.....)..3.P|
00000030 56 c0 00 01 08 00 45 00 00 3c 02 77 00 00 80 01 |V.....E..<.w....|
00000040 ea f1 c0 a8 e6 01 c0 a8 e6 05 08 00 43 5c 07 00 |............C\..|
00000050 03 00 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e |..abcdefghijklmn|
00000060 6f 70 71 72 73 74 75 76 77 61 62 63 64 65 66 67 |opqrstuvwabcdefg|
00000070 68 69 |hi|
00000072
Tpo convert 2d 0c 65 49 to a time, we have to swap the bytes, so becomes 0x49650c2d, or 1231359021 in decimal. 1231359021 is a Unix timestamp that we can convert with the -r option found in the FreeBSD version of the date command.
First let me show the date on this system so you can see the timezone of the FreeBSD system, and then I'll convert the seconds into a human readable time.
$ date
Wed Jul 28 00:11:23 EDT 2010
$ date -r 1231359021
Wed Jan 7 15:10:21 EST 2009
So, this ICMP packet has a timestamp of Wed Jan 7 15:10:21 EST 2009. Note that the date command produces a time in EST and not EDT. 15:10:21 EST becomes 16:10:21 EDT. I would have preferred seeing the date output show EDT since that is the time zone on the system in question, but I can understand the output. That seems simple enough, right?
Let's see what Tcpdump says about this packet. First I run the date command to remind us where we are running Tcpdump.
FreeBSD Tcpdump:
$ date
Wed Jul 28 00:11:23 EDT 2010
$ tcpdump -h
tcpdump version 3.9.8
libpcap version 0.9.8
$ tcpdump -n -tttt -r icmp.sample.pcap
2009-01-07 16:10:21.835423 IP 192.168.230.1 > 192.168.230.5:
ICMP echo request, id 1792, seq 768, length 40
As we expected, this packet has a timestamp of 16:10:21 (ignore the fractions of a second), and since the time zone is EDT it matches what we expect.
Let's see what a tool like Tshark says.
FreeBSD Tshark:
$ tshark -v
TShark 1.0.7
...edited...
Compiled with GLib 1.2.10, with libpcap 0.9.8, with libz 1.2.3, without POSIX
capabilities, without libpcre, without SMI, without ADNS, without Lua, without
GnuTLS, without Gcrypt, with Heimdal Kerberos.
NOTE: this build doesn't support the "matches" operator for Wireshark filter
syntax.
Running on FreeBSD 7.2-RELEASE-p7, with libpcap version 0.9.8.
Built using gcc 4.2.1 20070719 [FreeBSD].
$ tshark -n -t ad -r icmp.sample.pcap
1 2009-01-07 15:10:21.835423 192.168.230.1 -> 192.168.230.5
ICMP Echo (ping) request
What? Why does it show 15:10:21? That's the result for EST, not EDT, which is the time zone of the FreeBSD system.
Let's see if a Linux system in EDT behaves the same way.
$ date
Wed Jul 28 00:44:54 EDT 2010
$ tcpdump -V
tcpdump version 4.0.0
libpcap version 1.0.0
$ tcpdump -n -tttt -r icmp.sample.pcap
2009-01-07 16:10:21.835423 IP 192.168.230.1 > 192.168.230.5:
ICMP echo request, id 1792, seq 768, length 40
$ tshark -v
TShark 1.2.7
...edited...
Compiled with GLib 2.24.0, with libpcap 1.0.0, with libz 1.2.3.3, with POSIX
capabilities (Linux), with libpcre 7.8, with SMI 0.4.8, with c-ares 1.7.0, with
Lua 5.1, with GnuTLS 2.8.5, with Gcrypt 1.4.4, with MIT Kerberos, with GeoIP.
Running on Linux 2.6.32-23-generic, with libpcap version 1.0.0, GnuTLS 2.8.5,
Gcrypt 1.4.4.
Built using gcc 4.4.3.
$ tshark -n -t ad -r icmp.sample.pcap
1 2009-01-07 15:10:21.835423 192.168.230.1 192.168.230.5
ICMP Echo (ping) request
Again, we see Tcpdump correctly honor the local time zone (EDT) and display the timestamp as 16:10:21, whereas Tshark shows the timestamp as EST or 15:10:21.
I am really disappointed by this Tshark behavior. Incidentally, you get the same results from any tool in the Wireshark suite, such as Wireshark itself, capinfos, etc.
Does anyone know why Tshark and the like don't really honor the local time zone, and instead use Standard Time instead of recognizing Daylight Savings Time?
0 komentar:
Posting Komentar