cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
8709
Views
6
Helpful
5
Replies

Flooded with %ASA-2-106006:

wsanders1
Level 1
Level 1

Hello all! We have a fairly typical ASA 5550 setup, with all but one subnet of our 149.147.0.0 address space "inside" and one subnet 147.137.158.0 "dmz" (outside):

interface GigabitEthernet1/1

nameif inside

security-level 50

ip address 149.137.1.5 255.255.255.0

!

interface GigabitEthernet0/0

description outside

nameif dmz

security-level 10

ip address 149.137.158.248 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 149.137.1.141/1030 to 149.137.187.231/38293 on interface inside

The message isn't really 100% clear to me, but it seems to imply there are packets from 149.137.1.141 arriving on the "dmz" interface, trying to be routed to 149.137.187.231 "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 149.137.1.0 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 149.147.1.141 on "inside" in the arp table:

# sh route

S 0.0.0.0 0.0.0.0 [1/0] via 149.137.158.252, dmz

S 10.0.0.0 255.0.0.0 [1/0] via 149.137.1.254, inside

S 149.137.0.0 255.255.0.0 [1/0] via 149.137.1.254, inside

C 149.137.1.0 255.255.255.0 is directly connected, inside

C 149.137.158.0 255.255.255.0 is directly connected, dmz

# show arp | include 141

inside 149.137.1.141 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.

5 Replies 5

Joshua Walton
Level 1
Level 1

Hello Sanders,

The firewall implicitly denies all packets, we therefore have to explicitly permit what is to be allowed. You are seeing this error message because you have no access control entry permitting such.

You can turn off logging for this error by issuing:

no logging message 106006

I would suggest investigating both hosts in question as to why and what is sending UDP packets as frequently. One way is to sniff the network on either side.

Check your switch as well.

HTH

Also,

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 149.137.1.141 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.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: