We help IT Professionals succeed at work.

Cisco config question--DNS not working from inside

tgoetze
tgoetze asked
on
We've got a problem that we think is due to the access list.

On the (in) interface we have an access-list like:

permit tcp any x.x.x.0 0.0.0.255 established
permit icmp any any
permit tcp any any eq domain
permit udp any any eq domain
deny ip any any

And no access list on the (out) interface.
Both sides were originally more stringent, but we've
loosed up to try and see if we can get things to work.

Problem is that when we enable the (in) list, we
are not able obtain web pages using host names
from inside the network going out
(e.g. http://www.yahoo.com doesn't work but
http://216.115.102.81 does work).

When the (in) list is disabled we don't have any problems,
but neither do those people with too much time on their
hands.

Any ideas?
Comment
Watch Question

Commented:
you should change the lines to:
permit tcp any eq domain any gt 1023
permit udp any eq domain any gt 1023

The reply comes back with the src port = domain and dst port greater than 1023.

You should consider limiting the dns servers you can use, as:
permit tcp host 1.2.3.4 eq domain any gt 1023
permit udp host 1.2.3.4 eq domain any gt 1023

Even with access list I have provided a hacker can set his source address to 53 and then be able to access ALL ports greater than 1023.

Commented:
I believe Svindler is assuming where the DNS server is in relationship to the interface in question.  I would disagree with him in that opening up everything above 1023 is a bad idea all around.  Instead of trying to open source ports, than you should either move the access list to another interface or change the direction of the existing access list.  Outbound lists are typically desired anyway as they are much more efficient.

Where is the DNS server in relationship to this interface?  Is it off this interface as I believe Svindler may be suggesting or are the clients off this interface and the DNS server is off of another interface?

Commented:
My assumptions are that the access list has been applied as incoming on the interface closest to the internet. This is the corect place to put it, if security is first priority. If the access list is applied as outgoing on the internal interface, as suggested by scraig because of performance, the router itself is not protected.

If the router only has two active interfaces then the performance hit is not an issue, as the packets will have to go through the access list anyway. (Except of course if you would want to have unrestricted access to the router from the internet).

I was also assuming that the internal users were using dns servers on the outside. A caching dns on the inside would improve performance and allow an even tighter filter on the router.

I certainly did NOT suggest opening up for everything above 1023! As you can see from the access list I was only tightening the filter even further so return packets from domain/53 source ports is only allowed to destination ports greater than 1023, ie unpriviledged ports.

Commented:
My apologies - I didn't read your acl close enough - I saw the gt 1023 and thought you were opening up the world so to speak.  

As to what I recommended - I did not recommend putting the list anywhere - instead I said if you are going to open everything up to get something working, then you should look at placing the list in another fashion.  As to where this list is currently and whether or not it should be inbound or outbound, I agree with your assessment of where it should be (inbound on an Internet interface).  However, since I didn't make that assumption (although it is a fair one to make) I didn't make recommendations accordingly.  My only point was to look at other ways of getting things working and that outbound lists are typically more desirable.  I then asked for more info as I did not want to assume anything.

Author

Commented:
svindler,

Your suggestion for getting things to work does indeed
work. I learned (and am embarassed I didn't realize it
earlier) that both addresses can have ports specified
in the this (that's what happens when you learn only
from reading examples found on the internet).

You've obviously earned the points for answer the question.
But if you don't mind I'd like to find out some more from
one thing that you said:
  "I was also assuming that the internal users were using dns servers on the outside. A caching dns on
the inside would improve performance and allow an even tighter filter on the router."

Actually, we have two internal DNS servers which (I think)
do cacheing.

I'm guessing your tighter filter would be something like:

suppose internal DNS servers are A1 and A2, and the
DNS servers they use for extneral (from our service
provider) are B1 and B2

then we should do:

permit tcp host B1 eq domain host A1 gt 1023
permit tcp host B1 eq domain host A2 gt 1023
permit tcp host B2 eq domain host A1 gt 1023
permit tcp host B2 eq domain host A2 gt 1023
permit udp host B1 eq domain host A1 gt 1023
permit udp host B1 eq domain host A2 gt 1023
permit udp host B2 eq domain host A1 gt 1023
permit udp host B2 eq domain host A2 gt 1023

Is this what you were thinking?

And finally, we do have two service providers, and we have
just been putting the same access list on both (in) interfaces. I think this is the right thing to do, but
curious if there are efficiency issues with it.

Thank you very much!

Tom

Commented:
You are right about the format of the access lists. You can turn up security just a little bit more by adding "established" to the "permit tcp" statements like:
permit tcp host B1 eq domain host A1 gt 1023 established
This makes it even harder for a hacker that has compromised B1 to compromise your dns A1, but now we are really going for the small details. There is no reason not to add the "established" though.

You can apply the same list to both interfaces. If you are looking into getting every inch of performance from the router, you could make two different access list, that are shorter, so that packets for isp B1's dns server only can come in through the interface to B1 and the same for B2. Now I am assuming that the dns server B1 belongs to isp B1 and dns server B2 belongs to isp B2.
This does however require that packets from the B1 dns server only returns through the B1 interface and the same for B2. That depends on your peering agreement with the two isps.

Your last comment has taught me that scraig was wise in not assuming too much about the network in question. I will try to keep that in mind when answering questions in the future.

Author

Commented:
Much appreciated.

Author

Commented:
svindler,

I was thinking about something in your last response, and I'm not sure I believe it. My first line already allows all incoming traffic if it is established, so if I were to add "established" to all the
  permit tcp host B1 eq domain host A1 gt 1023 established

then I don't think it would work (since it should be matched in the first line anyway).

Do you agree, I hope I don't have to try it to see if I'm correct.

Let me know.

Commented:
Good point. Actually you don't need the "permit tcp" lines for dns, as they are already matched by the first line.

If you decide to keep the lines for some reason, you should add "established". Otherwise a hacker can use port 53 as a source point and connect to any port above 1023.
One reason to keep the lines could be if you decide to limit the internet services available to your users, such as replacing the first line with (just an example for http and https):
permit tcp any eq http x.x.x.0 0.0.0.255 established
permit tcp any eq 443 x.x.x.0 0.0.0.255 established

Explore More ContentExplore courses, solutions, and other research materials related to this topic.