Re: Does blocking TCP DNS packets keep your Bind safe?

["Crist Clark" <crist.clark () globalstar com>]

Don Kendrick wrote:
> ******* Repost, sorry wrong email address used **********
>
> OK, here I go again breaking things :)
>
> Over the years I've argued about blocking icmp at the border routers. Steve
> Bellovin et al would usually argue that it breaks path MTU, etc. I'd
> usually argue that we can rely on path MTU being negotiated elsewhere in
> the path (LAN vs. WAN bandwidth)...but I digress
>
> Here's what I am suggesting:
>
> 1. We should all only do zone transfers (TCP) with known secondaries.
>
> 2. Most if not all "normal" queries needed by legit Internet traffic are UDP.

False. Blocking TCP breaks normal queries. If the response to a query
is greater than 1024 bytes, the server sends a partial response, and
client and server will try to redo the transaction with TCP.

Responses that big do not happen often, but they happen. And people
do quite often block 53/tcp without their world coming to an end.
But this is where one usually inserts the story about the Great DNS 
Meltdown when more root servers were added. This made queries for
the root list greater than 1024 and the whole DNS system started
to break down from people violation the DNS spec (RFC1035) and 
blocking TCP. But I'm not up for a long rant on that now.

> Why not just block port 53 TCP connections at the border routers except for
> our secondaries. Is it possible to do a buffer overflow or other DNS/Bind
> exploit via UDP? I don't know the answer, I'm asking.

It is possible. I am personally not aware of any kiddie tools that actually
use UDP attacks access, only for recon. But it is theoretically possible
to do it with known bugs.
-- 
Crist J. Clark                                Network Security Engineer
crist.clark () globalstar com                    Globalstar, L.P.
(408) 933-4387                                FAX: (408) 933-4926

The information contained in this e-mail message is confidential,
intended only for the use of the individual or entity named above.  If
the reader of this e-mail is not the intended recipient, or the employee
or agent responsible to deliver it to the intended recipient, you are
hereby notified that any review, dissemination, distribution or copying
of this communication is strictly prohibited.  If you have received this
e-mail in error, please contact postmaster () globalstar com
_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://www.nfr.com/mailman/listinfo/firewall-wizards