|
On 12/08/2014 09:40 AM, der.hans wrote:
Am 08. Dez, 2014 schwätzte Michael Butash so: I just bring it up as I've had "security experts" say to block things like that and icmp in more of a service-provider or servicing capacity, and experience has just told me best to leave it be as a natural thing for dns and networking in general. Often makes for more complication and problem than you're fixing ultimately if ramifications are not understood. It's not a large payload issue, it's a method of them validating who is a script opening a raw udp socket to spew junk, etc vs. a "real" RFC-compliant client by sending that truncate bit back to the client, making them request via tcp, and thus doing something more than legit aiming a cannon.anomaly mitigation gear (the things that keep 400gb DDoS at bay) use that to So if I remember the rfc process right, client requests record, that ends up being like a domain key over 512 bytes, server sends back a truncate message, basically "too large a reply, resend via tcp pls so I can fragment it". Client then does, and normally gets their big dns record in a few chunks. Better yet, cut and paste from rfc: In the absence of EDNS0 (Extension Mechanisms for DNS 0) (see below), the normal behaviour of any DNS server needing to send a UDP response that would exceed the 512-byte limit is for the server to truncate the response so that it fits within that limit and then set the TC flag in the response header. When the client receives such a response, it takes the TC flag as an indication that it should retry over TCP instead.Old Cisco anomaly mitigation appliances did that, and later Arbor tms and most other software that auto-mitigate dns attacks, as it's one of the few ways you can "challenge" a client to interact back in such a way you can identify whether it's a real client request or a raw socket bit-blast at udp/53 pr other. They have interesting ways of challenging other protocol behavior as well to verify who's real or not.
Well, I remember one instance we had to reach out to road runner cable engineers because they were blocking tcp/53 requests for their customer dns resolvers, and suddenly a large swatch of their customer base couldn't resolve anything hosted by us when our ddos appliances blacklisted them as an attacker (2 addresses doing a _lot_ of requests interpreted as bad, which at the time we had some 50mil domains under us, so it was felt). They opened it, but we had to whitelist them specially until then. Pedantic things you learn over the years that stick with you. ciao, |
--------------------------------------------------- PLUG-discuss mailing list - [email protected] To subscribe, unsubscribe, or to change your mail settings: http://lists.phxlinux.org/mailman/listinfo/plug-discuss
