Difference between revisions of "Sniffing The Wire"
(New page: Tracking down connections with tcpdump. (1). Case I: A firewalled windows machine connects to an unidentified remote server when first booted. The connection quickly disappears. Doing ...) |
m |
||
Line 56: | Line 56: | ||
[[Category:Computer_Technology]] | [[Category:Computer_Technology]] | ||
[[Category:Linux]] | [[Category:Linux]] | ||
+ | [[Category:Security]] |
Latest revision as of 21:50, 11 January 2024
Tracking down connections with tcpdump.
(1). Case I: A firewalled windows machine connects to an unidentified remote server when first booted. The connection quickly disappears.
Doing a cat /proc/net/ip_conntrack on the firewall shows destination ports 53 and 80 on a remote machine, IP netblock registered to Savvis (a large provider.)
cat /proc/net/ip_conntrack
To "sniff the wire" and see what is being sent to the remote address the tcpdump tool is used. First, start tcpdump writing to a binary file 'tcpdump -w /tmp/everything'. This will log all traffic into a file later readable using 'tcpdump -r /tmp/everything'. The windows client is loaded again. Connection identified. Control-C issued to tcpdump to halt logging.
tcpdump -w /tmp/everything
Now we can analyze the file. Here's one of our suspect entries:
20:14:05.559578 ourhost.dsl.gw202.ourisp.net.1203 > 64.240.90.167.domain: 59643 [1au] A? update.microsoft.com.nsatc.net. (59) (DF) 20:14:05.604089 64.240.90.167.domain > ourhost.dsl.gw202.ourisp.net.1203: 59643*- 3/5/5[|domain]
tcpdump -r /tmp/everything|less
At first glance looks like windows update, but wait, the host is not Microsoft. The host is nsatc.net which whois says is also owned by Savvis. Could this be spyware? Lets do a hex dump and see what our windows client is saying to the remote host.
tcpdump -r everything.txt -X -s 1500 'host 64.240.90.167'
Produces the following dump:
20:14:05.559578 ourhost.dsl.gw202.ourisp.net.1203 > 64.240.90.167.domain: 59643 [1au] A? update.microsoft.com.nsatc.net. (59) (DF) 0x0000 4500 0057 0000 4000 4011 91ef 4015 ccfa E..W..@.@...@... 0x0010 40f0 5aa7 04b3 0035 0043 f86a e8fb 0010 @.Z....5.C.j.... 0x0020 0001 0000 0000 0001 0675 7064 6174 6509 .........update. 0x0030 6d69 6372 6f73 6f66 7403 636f 6d05 6e73 microsoft.com.ns 0x0040 6174 6303 6e65 7400 0001 0001 0000 2908 atc.net.......). 0x0050 0000 .. 20:14:05.604089 64.240.90.167.domain > ourhost.dsl.gw202.ourisp.net.1203: 59643*- 3/5/5[|domain] 0x0000 4500 012b 76cb 0000 f311 a74f 40f0 5aa7 E..+v......O@.Z. 0x0010 4015 ccfa 0035 04b3 0117 2107 e8fb 8400 @....5....!..... 0x0020 0001 0003 0005 0005 0675 7064 6174 6509 .........update. 0x0030 6d69 6372 6f73 6f66 7403 636f 6d05 6e73 microsoft.com.ns 0x0040 6174 6303 6e65 7400 0001 0001 c00c 0001 atc.net......... 0x0050 0001 ..
The address update.microsoft.com.nsatc.net is visible.
After a bit of googling it is learned that Microsoft seems to load balance the windows update service with contracted third parties. There was cause to be alarmed but though some digging it is revealed the traffic is legitimate.