Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a bunch of UDP datagrams reaching my server that look like so:

Some UDP datagrams not for my server

The question is, my IP is not, (it was so how are those datagrams even being received/logged by my tcpdump?

Also, what kind of attack is this formally called? I don't think it is DOS.

share|improve this question
last time i checked - ages ago - tcpdump did not care about your ip address but cared about your interface ;) – TomTom Nov 9 '11 at 18:33

I could be wrong, but the only way I can think of for a datagram to reach your computer when the layer 3 address doesn't match is if the layer 2 address is manually resolved on the sender and the sender is on the same layer 2 segment. If this is true, you should be able to identify the sender by the layer 2 source address in that packet capture. I suppose it's also possible that the layer 3 device (router or firewall) that does sit on your layer 2 segment could be compromised or misconfigured to result in the improper resolution of that layer 3 address to your layer 2 address.

In either case, go after the sender as identified by their MAC address.

share|improve this answer
+1 for the idea that you should check the Ethernet hardware source address to at least know how they're getting on your network. – David Schwartz Nov 9 '11 at 18:30

What netmask is your network using? If it's /24, you're likely seeing someone else's traffic because their destination address isn't in the switch's CAM table. If a switch doesn't know which port a device is on it will send traffic destined to that device out every port.

Is this an attack? Not sure. The fact that the source and destination port numbers are 0 along with the UDP length error looks odd. Maybe someone is trying to see if is vulnerable to MS11-083/CVE-2011-2013.

share|improve this answer
All hosts that are not the intended destination of the traffic should drop the traffic then and shouldn't show up in the capture, correct? (BTW, thanks for Wireshark!). – joeqwerty Nov 9 '11 at 23:07
tcpdump puts the interface in promiscuous mode by default. You have to explicitly tell it not to with -p. The same is true for Wireshark, TShark, and dumpcap (including -p). – Gerald Combs Nov 9 '11 at 23:51
Thanks, I didn't know that. Still I've never seen packets in a Wireshark capture where the capturing machine wasn't the intended destination or where the traffic wasn't some type of broadcast, multicast, or flooding of some sort, which probably means that the NIC's didn't support promiscuous mode. – joeqwerty Nov 9 '11 at 23:54

Unless you have an atypical network, there are no rules to prevent a packet from getting switched to machines other than its destination. The Ethernet layer has no idea what IP address the packets are bound for, so it cannot reliably filter them by IP. It filters by Ethernet hardware address, but it doesn't always know for sure which port is associated with an Ethernet hardware address. So some packets do get flooded to all switched ports.

These do appear to be corrupt though.

share|improve this answer

Any chance that your host is a virtual private server? Maybe these datagrams are destined for another container that shares the same NIC with your node. (...and for some reason your NIC is in promiscuous mode)

This would be a UDP Flood attack, if the datagrams weren't corrupted and were destined for random ports.

share|improve this answer

Your Answer


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.