Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Looking at a wireshark capture, I'm seeing something really strange. Ethernet II packets with random data are being sent on the network. The larger packets in the capture seem to contain bits and pieces of http, but the src/dst don't make any sense at all.

Both src and dst mac addresses are random.... neither exist on my network. The funny thing is, the src/dst randomly change with each packet.

About 1-3 packets/sec. Unable to find either src or dst mac in the switch tables.

Any ideas as to what this traffic is?

See .pcap file from cloudshark below.

http://cloudshark.org/captures/eca6e20e1835

Any help would be appreciated. My mind is boggled. I would love to know how to track down the culprit of these packets!

A

share|improve this question
    
Which packets are you concerned about? Also this may help with finding the source/destination. It's a list of MAC addresses licensed to different manufacturers. –  Mike Naylor Feb 3 at 16:33
    
All of these packets are randomly generated. None of these packets originate from legitimate MAC addresses on my network. –  eaglefly21 Feb 3 at 16:37
    
It looks like a lot of the MAC addresses are licensed to Samsung. Do you have a wireless network? –  Mike Naylor Feb 3 at 16:37
    
I have already filtered everything else that doesn't relate out. These packets continue to stream in at about 2-3 packets/ sec. If you want a longer capture, I can run one for a while. –  eaglefly21 Feb 3 at 16:37
    
Try turning off your wireless access points to see if the traffic stops. –  Mike Naylor Feb 3 at 16:38

1 Answer 1

up vote 1 down vote accepted

Packet 5 has, starting at an offset of hex 0036:

b4 99 ba 3d 49 00 00 17 54 01 63 b2 08 00 45

which looks like the beginning of an Ethernet packet to b4:99:ba:3d:49:00 from 00:17:54:01:63:b2, with a type field of 0x0800 meaning IPv4, and then the first byte of an IPv4 packet with no options.

If we treat that as an IPv4 header:

45 00 01 52 d7 d7 40 00 40 06 13 2f c0 a8 00 09 45 1f 48 cf

that's:

  • 45 - IPv4, 20-byte header
  • 00 - type of service (00 probably means "ordinary boring packet")
  • 01 52 - total length (338 bytes)
  • d7 d7 - identification
  • 40 00 - flags+fragment offset; flags = Don't Fragment, fragment offset = 0
  • 40 - Time To Live
  • 06 - protocol (TCP)
  • 13 2f - checksum
  • c0 a8 00 09 - source address (192.168.0.9)
  • 45 1f 48 cf - destination address (69.31.72.207)

I don't know whether that indicates where the packet came from or not, and I don't know what encapsulation is being used here (i.e., what all the stuff before the IPv4 header is). There might be a header that's not an Ethernet header but does have an Ethernet type field at the end.

share|improve this answer
    
Thanks for the analysis. The 192.168.0.9 is my Barracuda web filter, which has been featured in several of these packets. Most of the world-readable data in the larger packets in this trace seems to be pieces of URL headers relating to keepalives. Not sure why the src/dst mac addresses are so screwy though. Its almost as though there is something either on the Barracuda filter or elsewhere on the network that is sending barracuda web traffic info to random dst addresses. I'll have to dig into my Barracuda a little bit more and see if it might be causing this. Thanks for the lesson! –  eaglefly21 Feb 3 at 21:20
    
One question.... What is creating the packet? Its probably not either of the two machines listed in the info above. Still, VERY weird! –  eaglefly21 Feb 4 at 19:18
    
Closest thing I have to an actual answer. Thanks for helping with the offset. –  eaglefly21 Feb 5 at 13:13

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.