DNS Attacks

Wed Jan 18 17:15:22 UTC 2012

On Jan 18, 2012 8:43 AM, "Christopher Morrow" <morrowc.lists at gmail.com>
wrote:
>
> On Wed, Jan 18, 2012 at 11:34 AM, Steven Bellovin <smb at cs.columbia.edu>
wrote:
> >
> > On Jan 18, 2012, at 10:41 30AM, Christopher Morrow wrote:
> >
> >> On Wed, Jan 18, 2012 at 10:05 AM, Nick Hilliard <nick at foobar.org>
wrote:
> >>> On 18/01/2012 14:18, Leigh Porter wrote:
> >>>> Yeah like I say, it wasn't my idea to put DNS behind firewalls. As
long
> >>>> as it is not *my* firewalls I really don't care what they do ;-)
> >>>
> >>> As you're posting here, it looks like it's become your problem. :-D
> >>>
> >>> Seriously, though, there is no value to maintaining state for DNS
queries.
> >>>  You would be much better off to put your firewall production
interfaces on
> >>> a routed port on a hardware router so that you can implement ASIC
packet
> >>> filtering.  This will operate at wire speed without dumping you into
the
> >>> colloquial poo every time someone decides to take out your critical
> >>> infrastructure.
> >>
> >> I get the feeling that leigh had implemented this against his own
> >> advice for a client... that he's onboard with 'putting a firewall in
> >> front of a dns server is dumb' meme...
> >
> > In principle, this is certainly correct (and I've often said the same
thing
> > about web servers); in practice, though, a lot depends on the specs.
 For
> > example: can the firewall discard useless requests more quickly?  Does
it do
> > a better job of discarding malformed packets?  Is the vendor better
about
> > supplying patches to new vulnerabilities?  Can it do a better job
filtering
> > on source IP address?  Does it do load-balancing?  Are there other
services
> > on the same server IP address that do require stateful filtering?
>
>
> yup... I think roland and nick (he can correct me, roland I KNOW is
> saying this) are basically saying:
>
> permit tcp any any eq 80
> permit tcp any any eq 443
> deny ip any any
>
> is far, far better than state management in a firewall. Anything more
> complex and your firewall fails long before the 7206's
> interface/filter will :( Some folks would say you'd be better off
> doing some LB/filtering-in-software behind said router interface
> filter, I can't argue with that.
>
> > As I said, most of the time a dedicated DNS appliance doesn't benefit
from
> > firewall protection.  Occasionally, though, it might.
>
> I suspect the cases where it MAY benefit are the 'lower packet rate,
> ping-o-death-type' attacks only though. Essentially 'use a proxy to
> remove unknown cruft' as a frontend to your more complex dns/web
> answering system, eh?
>
> under load though, high pps rate attacks/instances (victoria secret
> fashion-show sorts of things) your firewall/proxy is likely to die
> before the backend does ;(
>

Very refreshing tone of conversation. Normally I hear a chorus of "defense
in depth" blah when we should be talking about fundamental host / protocol
based robustness.... and matching risks with controls ...not boxes with
places on a network map.

It leads to:  security is like an onion, it makes you cry

The ng stateful firewall is no firewall (tm)

I like https://www.opengroup.org/jericho/index.htm

Cb
> -chris
>
> >
> >                --Steve Bellovin, https://www.cs.columbia.edu/~smb
> >
> >
> >
> >
> >
>