UDP flooding / Ethernet issues? WAS Re: named "error sending response: not enough free resources"

[Chuck Swiger]

Hi--

On Jan 29, 2010, at 8:51 AM, James Smallacombe wrote:
>> On Thu, Jan 28, 2010 at 12:59 PM, James Smallacombe <up at 3.am> wrote:
>>> To follow up on this: Noticed the issue again this morning, which also was
>>> accompanied by latency so high that I could not connect (some pings got
>>> through at very high latency).  I emailed the provider and they told me that
>>> they had my port on their Ether switch set to 10Mbs.  They switched it to
>>> 100Mbs and only time will tell if that fixes it.
[ ... ]
> Today's security run output showed this:
> 
> +(RULE NUMBER) 16054161 131965203420 deny ip from any to (blocked IP)
> 
> and more alarmingly, this:
> 
> kernel log messages:
> +++ /tmp/security.BErFHSS3      2010-01-29 03:09:32.000000000 -0500
> +re0: link state changed to DOWN
> +re0: link state changed to UP

These are probably from your ISP changing the link speed from 10 to 100Mbs.

> +re0: promiscuous mode enabled
> +re0: promiscuous mode disabled
> +re0: promiscuous mode enabled
> +re0: promiscuous mode disabled
> +re0: promiscuous mode enabled
> +re0: promiscuous mode disabled

These are from running tcpdump.

> re0 obviously being the Realtek Ethernet driver.  The server itself never went down during this time, but the Ethernet did.  Is there any DOS type of event that could cause this, or could the root of the problem be an Ethernet hardware or driver issue?  Again, it is not clear to me which is the cause and which is the effect.
> 
> Last bit of info:  I just did a: 'tcpdump -n | grep -i udp' and saw a bunch of these, coming up a couple of times per second:
> 
> 11:31:59.387561 IP (IP REMOVED) > (IP REMOVED): NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
> 
> Where the source and destination IPs vary, but are NOT one of mine, but DO appear to belong to my colo/dedicated server provider and their customers. Is my server being used to DDOS others?  If so, how?

That is standard Windows NetBIOS over IP traffic.  It shouldn't be coming over your link unless your machines are sharing a subnet with someone else's Windows (or Samba) domain.  You might discuss this with your ISP and ask them what's up, but failing that, using IPFW rules like this would be prudent:

  add deny tcp from any 135-139 to any
  add deny tcp from any to any 135-139
  add deny udp from any 135-139 to any
  add deny udp from any to any 135-139

Regards,
-- 
-Chuck