Sniffing The Wire

From Free Knowledge Base- The DUCK Project: information for everyone
Revision as of 21:50, 11 January 2024 by Littleguy (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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.