Could defending the Domain Name System (DNS) infrastructure against amplification attacks be as simple as switching protocols in resolvers? Probably not – but an experiment conducted at APNIC has far-reaching implications. As Geoff Huston, chief scientist at APNIC, writes, DNS amplification attacks are easy to launch and can be …
how to test my home kit to see if it's up to snuff on this.
RPF. If a packet arrives on an an interface that it can't possibly logically arrive through, you JUST DROP IT; bill the customer for the traffic if you so desire, but JUST DROP IT...
How hard is this?
The ignorance of network operators just knows no bounds.
Or implement BCP38 but that's only been around for 13 years without people bothering with it!
So half assed end point implementations of the standard? That includes Applye's
The other issue is throughput
Presumably most DNS servers handle a huge number of requests and multiplying the size and number of standard requests is going to have a substantial impact on that.
But maybe that's the price you have to pay for a more robust internet that cannot be partly broken by some skiddie with a grievance against their boss/bank/mommy/The Trilateral Commission etc.
[Client]: Give me an A-record for theregister.co.uk
Time taken: 1x RT
[Client] Give me an A-record for theregister.co.uk
[Server] No can do. TCP only.
[client] SYN! Request conversation!
[server] Acknowledge. Fire away!
[Client]: Conversation ok. Give me an A-record for theregister.co.uk
[server]: 18.104.22.168. I'm done talking.
[Client] Me too. Over and out.
Time taken: 3x RT (not including final packet).
At an RT of 300ms (Hardly unusual), that's more than half a second extra delay. Now multiply that by all the domains holding different scripts, static image servers, ads and such on a typical webpage...
At an RT of 300ms (Hardly unusual), that's more than half a second extra delay. Now multiply that by all the domains holding different scripts, static image servers, ads and such on a typical webpage..."
That's what I was afraid of.
Too bad, it seemed like a plausible quick fix.
Nope, this won't work
Won't work - as TCP is stateful it requires storage on the host. It now becomes vulnerable to a syn flood DDOS clogging it up.
This is a no-go dead-end.
Re: Nope, this won't work
Mmm. I fear you may well be right.
Perhaps the answer to asymmetric attacks, is to require all UDP packets to be at least 512 bytes, or get dropped.
thus removing the asymmetry.
Re: Nope, this won't work
Are you ignoring the eight countermeasures listed in the Wikipedia reference you gave?
Re: Nope, this won't work
The post was about using TCP - I was pointing out that it won't work. A one liner of 'you can do this' means nothing. With regards to the 'fixes' in RFC4987, no, they're not being ignored:
Filtering - if you can filter, you can filter UDP
Increasing Backlog - RFC 4987 states this 'has serious negative aspects' and no-one's got it to work.
Reducing SYN-RECEIVED Timer - best you look up how long this timer stays open and how much would you cut it down to - then consider how much memory you have and how much a TCB costs.
Recycling the Oldest Half-Open TCB - this doesnt stop being swamped, it stops running out of memory - you can still be flooded with TCB from a DDOS and stop it working. Also a DDOS attack will knock out a valid connection if its half-open mode so its still broken.
SYN Cache - a decent DDOS will break this.
SYN cookies - this will increase the time before you're flooded - you still store a TCB, just smaller. And its complicated.
Hybrid Approaches - this isnt an approach - its a mixture of others.
Firewalls and Proxies - use these to filter UDP and its fixed as well.
See the above? That's called research.
So no, it won't work. You have a separate set of just-as-complex problems.
Use UDP normally, but switch to TCP only if a DNS server is under attack. Might even deter attacks, if attackers know the results will be limited.
And yet in order for attackers to be deterred, they would probably have to be aware why their attack would not work, allowing them to come up with a workaround. Perhaps they might start a reflection attack and then move on to a DDoS once the switch had been made to TCP., or run both simultaneously.
Who the hell made those slides?
This was a problem 15 years ago along with ICMP amplification
And mostly solved by rate limiting queries coming from any given IP address (claimed or real).
The REAL problem (as with open mail relays) is that there are a LOT of systems running very old code or with no administrators (or both) and unless someone goes around doing the elctronic equivalent of knocking a few hats off on the street, they won't get fixed.
Moving to TCP would help a little but isn't much use against DDoS attacks.
We'll just come full circle again, once we find another exploit, and some hacktivist programers turn it into a simple method for attack.
- The land of Milk and Sammy: Free music app touted by Samsung
- The long war on 'DRAM price fixing' is over: Claim YOUR spoils now (It's worth a few beers)
- Privacy warriors lob sueball at Facebook buyout of WhatsApp
- Dell thuds down low-cost lap workstation for
cheapfrugal creatives or engineers
- 20 Freescale staff on vanished Malaysia Airlines flight MH370