IPS Signature 4003/0 - NMAP UDP originating from W2K3 Outside DNS server

[Christopher Bell]

I've been reading around a bit, and everything I can find on this signature points to Linux hosts. In my case, this sig is firing as Atacker=W2K3 DNS server in my DMZ. It's our outside DNS server (SOA). So far - I can't find any reason NOT to be concerned - are there any false positives that could be causing this?

[Christopher Bell]

I just read my post - let me clarify. My outside DNS server is the attacker on this sig. The DNS server runs W2K3. Port 53 TCP and UDP are open to the world in the Firewall (ASA5520). My DNS server is SOA.

Sorry for any confusion in my original post.

[andrgrif · Accepted solution]

Hello,

As per the benign trigger details for 4003-0:

"Many network management tools, such as HPs Open View, provide network mapping capabilities. This may include a mapping of available network services, so UDP port sweeps may be expected from these systems.

DNS (Port 53), LDAP (Port 389), and Active Direcory (Port 88) servers have been shown to cause false positive alarms when responding to numerous queries from the same host.

Due to the stateless nature of UDP traffic, this signature may fire on any application that makes multiple queries to the same UDP service on another system. Because the application often uses a different source port for each request, the responses from the service may be mistaken for a port scan by the sensor. If when examining the alarms for this signature it is determined that a known network service is the source port for this alarm, a filter can be used to eliminate the false postive alarms."

Additionally, from the Suggested Filters section:

"Exclude network management stations as sources and destinations. Exclude DNS / LDAP / Active Directory servers as sources."

If the signature has only recently started firing for that DNS server, then you might want to read http://isc.sans.org/diary.html?storyid=5713 which may be applicable.

[Christopher Bell]

Thanks for the link to the article! I had actually read the trigger details before posting and was relatively sure they did not apply. The IP addresses that are being used in the DDoS mentioned in the SAN's article are the same one's we are seeing.

[Christopher Bell]

Just as one final follow up to this in case others see the same thing. Here are some of the details things I've observed:

- If you are not forwarding, the sig that fires is 4003/0 (not sure why this sig fires)

- The query against the name server is for the root name servers.

- If you are not forwarding, and have recursive turned off, then the response to the queries is a Standard query response, Server Failure. The intended response is not what the attack is crafted to produce (in our case), but there is still a response.

- In our case we are SOA - but when the query is sourced from one of the spoofed IP's, we respond with "Server is not an authority for domain". If you do a packet capture you can see this in the DNS portion of the frame.

I'm not a DNS expert - but I thought I would share in case others see similar situations.

Currently, I simply block all incoming traffic from the spoofed IP address until the attack subsides. There is probably a better way of doing this, but I haven't yet taken the time to figure out how.