Hello all! We have a fairly typical ASA 5550 setup, with all but one subnet of our 18.104.22.168 address space "inside" and one subnet 22.214.171.124 "dmz" (outside):
ip address 126.96.36.199 255.255.255.0
ip address 188.8.131.52 255.255.255.0
We are getting flooded with these, hundreds per second:
Aug 23 2009 15:36:11: %ASA-2-106006: Deny inbound UDP from 184.108.40.206/1030 to 220.127.116.11/38293 on interface inside
The message isn't really 100% clear to me, but it seems to imply there are packets from 18.104.22.168 arriving on the "dmz" interface, trying to be routed to 22.214.171.124 "inside", because the word "inbound" implies a packet coming from a lower to higher security-level.
Is this correct? If so, a logical explanation is that someone has plugged the 126.96.36.199 net, which is supposed to be inside, into a dumb hub on the DMZ somewhere.
Otherwise, if the packet is arriving on the inside interface, it could be a symptom of a severe unicast flooding problem. Even so, I don't see why the ASA ought to care, since my routes point all the inside nets except my DMZ to inside, and the ASA sees 188.8.131.52 on "inside" in the arp table:
# sh route
S 0.0.0.0 0.0.0.0 [1/0] via 184.108.40.206, dmz
S 10.0.0.0 255.0.0.0 [1/0] via 220.127.116.11, inside
S 18.104.22.168 255.255.0.0 [1/0] via 22.214.171.124, inside
C 126.96.36.199 255.255.255.0 is directly connected, inside
C 188.8.131.52 255.255.255.0 is directly connected, dmz
# show arp | include 141
inside 184.108.40.206 0011.43e4.cb0d
I need to fix this, it makes syslog rather useless, eh?
BTW this also caused "fixup dns" to blow up DNS connectivity later in the day, about 6 hr after putting the firewall inline; I had to "no fixup dns" to get it working again.
A misconfigured Discovery scan on the Symantec System Center can cause a tremendous amount of traffic on this port.
A high amount of traffic may indicate that the Symantec System Center Discovery service is configured to run frequent intense discoveries. Attackers will use this port to inject malware onto hosts within the network. I would run a rootkit revealer.
Skype also uses this port. When a client acts as a 'supernode' you will see a lot of traffic from all over the world on this port.
I'm still not sure which interface the packet is arriving on. The only documentation on this message is: "%PIX|ASA-2-106006: Deny inbound UDP from outside_address/outside_port to inside_address/inside_port on interface interface_name. This is a connection-related message. This message is displayed if an inbound UDP packet is denied by your security policy."
Which implies that the 220.127.116.11 packet is arriving on our outside interface "dmz" where is has no business popping up in the first place, unicast flooding or not.
In that case ASA is justified in calling this Sev 2 - it's not just a deny based on an ACE, it's an IP that shouldn't show up there at all, and could be spoofed, even.
Actually most of this traffic is from a host running Novell Patch Manager, which is a similar service to the Symantec junk and likewise seems to be port-scanning everything at a furious rate. (Now that I've suppressed 106006's I'm seeing a few 106001's (SYN's from the same host).
Thanks for the tip about "no logging message" - I was going to get around to that eventually but I figured if ASA thought this was a Sev 2 message I'd try to track it down first.
Confirmed with wireshark that the UDP packets are flooding the inside interface. So, regarding 106006 (and 106001), I would hardly call this "critical" but thanks ASA for caring so much about my unicast flooding problem.
The 106006 description is misleading. It might be better characterised as "violation of routing policy on packet seen on interface ".
Correction: I'm NOT being flooded. What is happening is that various devices are probing nonexistent subnets in our inside address space, and the subnets that are not configured are being default-routed to the ASA.
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...