0

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 208.69.57.21, (it was 208.69.57.101) 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.

bobobobo
  • 789
  • 6
  • 14
  • 26
  • last time i checked - ages ago - tcpdump did not care about your ip address but cared about your interface ;) – TomTom Nov 09 '11 at 18:33

4 Answers4

3

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.

JakePaulus
  • 2,347
  • 16
  • 17
  • +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 09 '11 at 18:30
2

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 208.69.57.21 is vulnerable to MS11-083/CVE-2011-2013.

Gerald Combs
  • 6,441
  • 25
  • 35
  • 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 09 '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 09 '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 09 '11 at 23:54
1

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.

David Schwartz
  • 31,449
  • 2
  • 55
  • 84
0

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.

dkaragasidis
  • 745
  • 4
  • 11