DNS Amplification Attacks... and a trivial proposal

[Mark Andrews]

In message <18216.1371209330 at server1.tristatelogic.com>, "Ronald F. Guilmette" writes:
> 
> In message <20130614050625.850CF35E5911 at drugs.dv.isc.org>, 
> Mark Andrews <marka at isc.org> wrote:
> 
> >In message <15120.1371179125 at server1.tristatelogic.com>, "Ronald F. Guilmette"
> > writes:
> >> >* Large numbers of ISPs claim they implement BCP 38.
> >> 
> >> I claimed that I was Charlie Chaplin once.  Unfortunately, Robert Downey Jr.
> >> beat me to it.
> >> 
> >> (My claim also did not help any of the organizations who were DDoS'd last
> >> week in any material way.)
> >
> >But it does {help} if the claims are valid {and} reduce the number of machines that
> >can be used to launch attacks from
> 
> Yes.
> 
> >... and it also applies peer presure on other ISPs.
> 
> Oh!... Yea!...  THAT will certainly work and have a big impact.   (Please
> just ignore that suppressed snickering coming from the back of the room.
> Those people are from Missouri.)
> 
> >It also invalidates claims from ISP's that say they can't
> >implement BCP 38 when push comes to shove.
> 
> Could you help me out a little here?  I just want to mark it on my
> calendar... When exactly is push currently anticipated to intersect
> with shove?  (I personally have been waiting for this cosmological
> once-in-a-lifetime event for the past 10+ years already.  I don't
> mean to seem impatient, but this is starting to border on ridiculous
> now.  Where is that much-rumored packet-based Pearl Harbor when we
> need it?    How many more legitimate packets have to die before
> _everyone_ summons up the courage to end this mess once and for all?
> What are the recalcitrant hold-outs waiting for?  The second coming??)
> 
> >> At the risk of stating the obvious, putting a bunch of machines behind
> >> a NAT box does not make the routed IPv4 addresses that those boxes were
> >> formerly connected to disappear.
> >
> >But it does stop machines behind the NAT boxes from being able
> >reflect packets off machines elsewhere on the net.  Everything
> >coming from the NAT has the NAT's address as its source.
> 
> That would be nice.  I personally don't know if it is always and
> everywhere true or not.  It would indeed be some comfort if it
> were indeed everywhere and always true, but even my trusty old WRT54G
> has some some rather interesting "tunneling" options that I vaguely
> suspect might allow for some rather questionable stuff to occur.

> (I know for a fact that one hijacked machine that was most certainly
> behind a NAT box was nontheless serving up helpful DNS responses for
> some rather unsavory East Block phake pharmacy spammers... at least
> once upon a time.

I know a red herring when I see one.

> I worry what other NAT box funny business may make
> it possible to dole out, to the net at large, odd packets, including
> perhaps even spoofed ones under certain conditions.  And yes, in such
> a case the box can no longer be called a purely "NAT" box in the strictest
> sense of the word.  Let's not waste time quibbling about that.  The issue
> isn't the terminology.  The issue is "What are the capabilities?")

And a argument from someone who doesn't understand how NATs are
designed to work.  They are not firewalls.  They are supposed to
let traffic through and opening up forwarding ports is perfectly
normal behaviour.

> >This turns
> >the attack from a amplified, reflected, DDoS attack into a staight
> >out DDoS attack (no amplification, no reflection).  Attempts to
> >lauch attacks from behind the NAT impact the user of the NAT and
> >the would be reflector not third parties.
> 
> One hopes anyway.  But none of this negates the more important and
> overriding point I made, to wit:

And the only way to get rid of reflectors is to turn the net off.
 
> >>  Do you believe that everybody who
> >> puts a box behind a NAT then immediately takes pains to insure that
> >> _nothing_ will ever represent itself to the public Internet as occupying
> >> that box's previous routed address ever again?  Or is it just as likely,
> >> if not moreso, that some new box will be put in the old box's place...
> >> a new box which is even less likely than the old one to be a mere end-
> >> luser client machine, incapable of reflecting anything, and vastly more
> >> likly to be a brand new *server* of some sort... probably of a kind that
> >> will suddenly make that IP address useful as a packet reflector, where
> >> the prior box would not have been useful at all in that respect?
> >
> >I'd rather have another reflector than a spoofed traffic source.
> 
> Well, that makes one of us.

So you don't believe anyone should ever put up a server.  Personally
I like there to be servers out there.  The net would be a very boring
place without them.

Or perhaps you have bought into the illogical argument that servers
shouldn't be run from homes.  That it is some how "wrong".  That
one should have to pay extortion money to run a "server".

> >There will always be reflectors.  There doesn't have to be any
> >sources of spoofed traffic.
> 
> There doesn't have to be, but there always will be, nontheless.  It's
> like trying to close the last open SMTP relay... which actually might
> be possible someday... like eradicating smallpox... versus locking down
> every single last bloody IPv4 address on every single bloody last
> machine in every single bloody last Kinko's or Internet cafe in the
> entire Universe and making sure that each and every one of them cannot
> make an unfettered outbound port 25 (smtp client) TCP connect to any
> bloody address they want.  THAT will just never happen.

SMTP relays are basically gone.  They haven't been a issue for years.

Droping spoofed traffic is significantly different to dropping SMTP
traffic.  They really are totally different problems.

> Amplification is like leverage.
> 
> The Greek mathematician and inventor, Archimedes, upon realizing the
> limitless implications of his new invention, the lever, is believed
> to have said "Give me a place to stand and I can move the world!"

But we don't have limitless amplification.

> As regards to amplification attack origination points, there will
> _always_ be a place to stand (to originate the attack from).

Which assumes you can find a compromised machine at a ISP which
doesn't filter that isn't behind a NAT or a CPE that has built in
anti spoofing rules.   While the compromised machines may not be
dropping the rest are getting harder to meet and will continue to
do so.

>  We need
> to take away the lever.  The lever is the amplifying reflectors.  Right
> now they are all "dumb".  I merely suggested making them just intelligent
> enough so that they can comprehend the command "Stop hurting me!"

Which won't work against any determined attack.  Think 400 million
reflectors.
 
> But I guess that is a radical notion.
> 
> >CPE vendors have been informed of the broken defaults in their boxes
> >and new equipment will ship which is not broken.
> 
> Great!  That certainly won't hurt.
> 
> I am compelled to wonder aloud however how it can possibly be the case
> that anybody would ever hold the position that we are likely to see a
> solution to this problem sooner, more conveniently, and at lower cost
> by pushing out updated _hardware_ to millions of sites worldwide, you
> know, as opposed to pushing out updated _software_ to millions of sites
> worldwide.
> 
> Call me old fashioned, but I cling to the antiquated belief that it
> might actually easier, faster, and less expensive to change out soft-
> ware than it is to change out hardware.
> 
> I guess that somebody needs to call out the men with the white coats
> that strap up in the back and tell them to come and get me.

You keep thinking that this is a new problem.  It isn't.  You don't
just have to upgrade every server in the world.  You also have to
upgrade every client in the world.  You need to make sure the
"solution" isn't worse than the status quo.  You also need to believe
that the solution will work once the attacker adapts.

rrl will fail once the attacker adapts.
your idea will fail once the attacker adapts.
dns cookies or a varient of it will work but will take years to
get there.
bcp 38 will work but will take years to get there without a push
by governments.

> Regards,
> rfg
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org