Posts Tagged ‘arp’

Network forensics afternoon

December 1, 2010 11 comments

Well, strange things happened today . While working on a project , I noticed a strange high incoming network traffic on the system monitor of my ubuntu machine. High, as in ~8MBps with small bursts that lasted some minutes and produced ( according to system monitor again ) a total download traffic of 1.9 GB .
As you can imagine I was pretty surprised , I was sure I was not running anything that could cause such amounts of traffic . The applications running at that time were skype,  firefox , thunderbird and Aptana studio none of which could result to that kind of traffic (I had only one tab open in ff at the time , pointing to KTH website , and Aptana’s automatic update process needs user confirmation in order to download updates) . My first reaction was to run netstat , which produced uninteresting results , typical ESTABLISHED connections by thunderbird to the imap servers it was supposed to, a connection to ip initiated by an application recognised as “python” ( which was actually the ubuntu one client ) , one regarding skype and one regarding ff as expected more or less. I didn’t keep the output somewhere but I’m pretty sure I didn’t miss anything there. As I was gradually getting from surprised to worried since the traffic seemed to continue at approx the same rate, I fired up wireshark and started capturing my wired interface. Couple of minutes after that the traffic stopped and I haven’t noticed anything peculiar since.

So I started to check the capture , trying to find the stream that produced the traffic I observed. From a first look there seemed to be many long UDP flows from different IP addresses (various high ports) to a specific IP address (not my interface’s though) on port 51508 . The destination address is in the same subnet as mine and I have  confirmed that is up and port 51508 (among other high ports is open). This smelled like bittorrent traffic from distance . To confirm , here is what a random packet of that stream looked like :

0000  0c 60 76 61 69 98 00 12  bf d9 bf 65 08 00 45 00   .`vai... ...e..E.
0010  00 83 5f cc 00 00 0e 11  8f 96 18 71 f4 7d d5 67   .._..... ...q.}.g
0020  da b1 fb 21 c9 34 00 6f  fd 34 64 31 3a 61 64 32   ...!.4.o .4d1:ad2
0030  3a 69 64 32 30 3a 49 b8  74 ec 25 bf d6 64 bc 10   :id20:I. t.%..d..
0040  b8 94 e1 60 fd 59 b8 b0  45 15 36 3a 74 61 72 67   ...`.Y.. E.6:targ
0050  65 74 32 30 3a 49 b9 33  f4 ee 98 e2 29 bd 70 f2   et20:I.3 ....).p.
0060  a3 95 7b de d5 05 8d 38  01 65 31 3a 71 39 3a 66   ..{....8 .e1:q9:f
0070  69 6e 64 5f 6e 6f 64 65  31 3a 74 34 3a 84 8c 00   ind_node 1:t4:...
0080  00 31 3a 76 34 3a 55 54  57 b2 31 3a 79 31 3a 71   .1:v4:UT W.1:y1:q
0090  65                                                 e

which is actually a find_node DHT QUERY as described here . While this sort of explains the nature of the traffic , it doesn’t explain

a) Why was I apparently receiving this traffic when I was not supposed to in the first place .

b) If I was receiving the traffic, what was it and where was it stored in my machine.( remember we are talking about ~2GB of data.)

To start with b) I didn’t remember the last time I checked how much space i was using on my disk, but the current usage percentage didn’t seem alerting by itself. So , this is where find(1) came in handy

~$ find . -type f -mmin -120 -printf '%p %s \n'

didn’t reveal anything interesting although. There were a bunch of files modified in the past 2 hours , but none of them seemed suspicious or modified with no reason.

as to a)  I can only make wild guesses. One detail that might be interesting is that yesterday all the switches in the building were replaced so to support the 100/1o we are ow offered (hence the 8,4 MBps in the beginning) .It doesn’t look like an ARP attack , according to the capture. But what kind of misconfiguration would have these kind of results ? I can see a lot of packets addressed to other hosts. CAM table overflow at the switch ?But why I was seeing the traffic in the system monitor ? Shouldn’t those packets be dropped by my NIC ? It wasn’t in promiscuous mode before I ran wireshark .

So ? Comments, suggestions , answers to the questions ?