Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 10184
  • Last Modified:

Deny inbound UDP due to DNS Response

Does anyone have an idea as to what the following message is:-
It appears in my CISCO fireall log several times a day!
2006-06-15 12:37:35      Local4.Critical      220.0.0.100      Jun 15 2006 11:37:35: %PIX-2-106007: Deny inbound UDP from 81.22.32.15/53 to 192.168.1.2/49127 due to DNS Response
where 192.168.1.2 is my modem connected to the internet!
I know the /53 is DNS - I have a Win 2003k set up for my network DNS
0
Mawallace
Asked:
Mawallace
  • 2
  • 2
  • 2
  • +1
1 Solution
 
renillCommented:
Explanation:   This is a connection-related message. This message is logged if
a UDP packet containing a DNS query or response is denied. The flag variable
is either Response or Query.

Action: If the inside port number is 53, it is likely that the inside host is
set up as a caching nameserver. Add an access-list command statement to
permit traffic on UDP port 53. If the outside port number is 53, the most
likely cause is that a DNS server was too slow to respond, and the query was
answered by another server.

If your internal DNS server is supposed to answer to public requests, add the
access-list. I would strongly advise removing the conduits and only using
access-lists. As I understand, that is the only way to provide outbound
packet filtering.

access-list udp_bound deny protocol source mask dest mask eq port
access-group udp_bound in interface inside

renill

0
 
MawallaceAuthor Commented:
The /53 is  outside.
Does this mean I need to open up the network so that all /53 requests are passed inbound? Seems a bit dangerous to let anyone connect to the network via port 53?
0
 
Keith AlabasterCommented:
First, Are you hosting internally a dns service that needs to be referenced by the Internet population? If no, then no you don't.

As a caveat to Renill's suggestions, if you do not already have an ACL associated with outbound traffic, be aware that once you apply an outbound acl you will need to specifically allow all of the outbound traffic you wish to permit.  ie no outbound acl means all outgoing is allowed (subject to there being a suitable nat/global configuration statement in place).  Apply an outbound acl then you need to tell it all of the allowed traffic, not just DNS  ie web, mail, ftp icmp etc.

I agree that the source port being from /53 sounds like it is a response that may well have timed out. If the original request had come from your internal network then the PIX (I assume its PIX) would still have an entry in its tables for that request going out so the response would be 'expected'.

You could temporarily raise the reporting level on your syslog to see if you get more detailed information but be aware that this will also put more load on your firewall.
0
Put Machine Learning to Work--Protect Your Clients

Machine learning means Smarter Cybersecurity™ Solutions.
As technology continues to advance, managing and analyzing massive data sets just can’t be accomplished by humans alone. It requires huge amounts of memory and storage, as well as high-speed processing of the cloud.

 
lrmooreCommented:
Renill posted directly from Cisco's Error Message Decoder. I think the important part is this:
" If the outside port number is 53, the most likely cause is that a DNS server was too slow to respond, and the query was answered by another server."

>%PIX-2-106007: Deny inbound UDP from 81.22.32.15/53 to 192.168.1.2/49127
In your log entry, it is clearly the outside host with port# 53 and is most likely that this is a delayed response that has already been answered and the client no longer needs it. The PIX is smart enough to deny this packet because the client already has the answer. It is part of normal operation. You can disable this particular error message # in the syslog setup.

Q: Does your internal DNS server use specified forwarders, or root hints only for unknown zones?

0
 
MawallaceAuthor Commented:
My DNS server uses root hints, not a specified forwarder
0
 
lrmooreCommented:
I suggest just supressing this particular message and getting on with life.
0
 
Keith AlabasterCommented:
lol @ LR
0

Featured Post

2017 Webroot Threat Report

MSPs: Get the facts you need to protect your clients.
The 2017 Webroot Threat Report provides a uniquely insightful global view into the analysis and discoveries made by the Webroot® Threat Intelligence Platform to provide insights on key trends and risks as seen by our users.

  • 2
  • 2
  • 2
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now