On Fri, 7 Jan 2000, Jimi Aleshin wrote:
> I though it was more insecure allowing TCP transers through port 53. That's what
> I've always heard.
If you mean "zone transfers" when you say "TCP transfers" then yes, it's a
bad thing (assuming the resolver is serving names and not just answering
queries), however if you really mean blocking all TCP to port 53, then
breaking DNS may indeed be less insecure, but the entire point of having the
resolver is to be able to resolve names.
Allowing zone transfers to unauthorized hosts is normally considered a
security issue. That's easily solvable in modern resolvers with a
configuration option. Non-modern resolvers have enough security issues
that it's not worth worrying about zone xfers.
TCP requires a three-way handshake before the application layer call even
sees *any* data. UDP simply requires that a datagram arrive on the
correct port. Therefore, there is more application exposure with UDP
than with TCP (especially if your IP stack has good pseudo-random TCP
sequence numbers), since only application-layer protection is available,
not stack-layer for spoofed packets. For DNS, that protection is the
query-ID. Query-IDs only protect responses for your queries though, they
won't protect you from external queries to your nameserver (dictionary
queries of a nameserver would be less efficient than a zone transfer, but
as effective if they weren't noticed.)
Now, if the nameserver in question isn't authoritative for any external
domains, *some* TCP can be filtered at the outside screening router to
ensure that only packets with the ACK bit on come back in to TCP/53. That
means that for TCP, we can ensure (barring a trojaned IP stack) that
the only traffic we get for our DNS is a response to a query we sent
out. With UDP, the only way to get the same kind of protection is to
place a stateful packet filter (such as Darren Reed's
*excellent* Open Sourced IPFilter) in between the DNS and the Internet.
Correct resolver behaviour *requires* TCP access for long query answers.
Blocking that will hose something at some point, so while it's a way to block
zone transfers, that's not the only effect and the other effect normally isn't
desired.
> Anyways, look at this
> http://advice.networkice.com/Advice/Intrusions/2000401/default.htm
Disallowing zone transfers is generally a good thing, breaking resolver
functionality in regard to long answers is generally a bad thing, they're
fortunately not mutually tied in BIND8, they *are* mutually tied in a
packet filter (especially if you're authoritative for a zone and don't
realize the consequences of blocking TCP/53 and add a significant
number of Resource Records to a query answer down the road.)
If the zone in question has slave servers somewhere, they'll need to do zone
transfers, in which case you're going to have to allow the traffic from at
least the slaves. Once again, that's a resolver configuration issue, though
it's solvable with TCP filtering so that non-ACKed packets can't come from
anyone who's not allowed to do a zone transfer.
If you need to do zone transfers, the same inbound ACK filtering will
work as well as for large query answers.
I'll reitterate and expand on it here:
The best answer IMO is to have external *hardened* nameservers which are
used to formulate queries to the root servers and through them any
authoritative nameservers. The only thing you should be passing through
the firewall in such an architecture is queries from the internal
nameservers if you're not using a proxy-based firewall, and if you are,
just queries from the proxies themselves (which is again preferred.) to
the external servers. The external servers should only resolve queries
for the authorized hosts.
If you're using application layer proxies under such a scenerio, you have
completely negated DNS-based tunneling, telnet over UDP/53 programs, etc.
For the price of one or two PCs, you get all that protection (assuming
you can configure them securely.)
Now, I'm ravingly paranoid, so I don't like external hosts like that to
share the same layer 2 infrastructure as my external firewall interfaces,
so I add more stuff to that mix, but that's because I don't fully trust
my Ethernet drivers, switch vendors, etc. That means adding a layer 3
device that I have some trust in to route in there, call that the cost of
another PC or small router.
Just like blocking all ICMP without understanding TCP Path MTU discovery
is ill-advised, blocking TCP for DNS boxes without understanding the DNS
protocol is also ill-advised. "I've heard..." is good to use as a prompt
to do in-depth investigation, it's often poor to use it as method of
defining access lists.
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
[EMAIL PROTECTED] which may have no basis whatsoever in fact."
PSB#9280
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
