Re: [dns-operations] Mozilla Firefox and ANY queries
* KLaM Postmaster wrote: But nobody is asking the fundamental question, why do they need this info in the first place? Because they added their own caching code for DNS responses. The getaddrinfo/getaddrbyname API is designed to be called on every new socket. But they hacked around this design and now trying to fix it. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Google DNS used as amplification - aren't they caching?
* Paul Wouters wrote: It seems that the nsd ratelimits to send TC=1 isn't working well either to reduce the incoming amount of UDP queries. Why does google dns seems so inefficient at caching? I can second this. With rate limiting and dampening (at my side) I get customer complains, that the Google webmaster tools report an unreachability of the DNS servers (about 5%). OTOH there are customers which use Google public DNS and do have sporadic resolving problems Internet is not working! We can't even access our own home page! And this is true: Google IP ranges hit the dampening limits several times the day. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] DNS Issue
* John Kristoff wrote: And why auditors do not like tcp53 open to public? They may have an outdated, naive view of what should be open and what shouldn't be? Show them the above and ask them why. I'd be curious what the response is. We have never seen TCP/53 in public beside strange examples or attack. TCP/53 ise superseded by EDNS0 TCP/53 is only needed for AXFR, allow TCP/53 only to(!) your primary NS DNS works over UDP There are more such answers. But the most prominent answer is: We marked it red, because it's a security risk. Close it! ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] N-Root
* Stephane Bortzmeyer wrote: Congratulations: you've solved the easy problem, the technical one, and left open the really hard one, finding who has the legitimacy to hire/fire root name server operators :-) Oh, this problem was solved years ago. ICANN was founded to bind all efforts of gouvernments, private people, and orgranisations in a burocracy impossible to understand nor to survice, with the simple goal to keep all those from affecting the real work of the real root server operators. The funny part is, that the root server operators (which does not exist as an organization) appears to be an organisation within ICANN. But this is only just another level of indirection and confusion. ICANN is very successful in doing their (hidden) primary goal: Let the operators work. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Force TCP for external quereis to Open Resolvers?
* Jim Reid wrote: In this case, DDoS attackers would get those truncated responses sent to their victims. OK, they lose the amplification factor but they still get to flood the victim(s) with unsolicited traffic. That does already happen in the wild. I was part of such an TC=1 attack and got sued over the remaining(!) 2Mbps. That's why I went further and stop query processing at all for this victim: DNS Dampening. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Recently closed open resolver and reflection attacks
* wbr...@e1b.org wrote: Any idea how long it takes before the formerly abusable server gets taken off the lists of open recursive servers? About a week. Then the attacks calm down. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Another whitepaper on DDOS
* Tony Finch wrote: DigiNotar's bogus Google certificate would not have worked with DANE. But the errornous transfer of ebay.de would create a deasaster with DANE. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Defending against DNS reflection amplification attacks
* Jan-Piet Mens wrote: FYI, a paper (Feb 2013) titled Defending against DNS reflection amplification attacks at [1]. Despite they are using the wrong patch for DNS Dampening, the results are impressing. Works as designed. Of course, they require a SLIP parameter. I heard this. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] DNS ANY requests / UltraDNS
* Colm MacCárthaigh wrote: On Wed, Jan 9, 2013 at 4:24 PM, Scott Brynen scott.bry...@visioncritical.com wrote: In an interesting development to this, UltraDNS are starting to REFUSE a UDP/ANY request on some of their name servers. Considering that a status=REFUSED response is exactly as large as a TC=1 response with no answer section, is there a technical benefit to responding with REFUSED? Both approches does not help. The traffic generated by such small answers to spoofed queries is still sufficient to bring the target down. Be there, done that, got sued. That's why I switched to a much more aggressive DNS dampening. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] DNS ANY requests from Amazon?
* Stephane Bortzmeyer wrote: No one in his right mind limits simply by the client's IP address. Interesting point. Nice to read. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
* Klaus Darilion wrote: Agreed. That's why I mentioned that our iptables based rate limiting only mitigates the current ANY amplification attacks, not all kind of attacks. I did see some attacks with repeated DNSKEY queries. Dampening catched them. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
* Lutz Donnerhacke wrote: If they are optimal or not is still an open question. But the patch is useable now. Far from perfect or finished, but used in practice. I was able to collect some statistics and keep an eye on the attacks itself. Interestingly the attackers seem to honor the RRL defaults and apply their attacks in a way to render this patch useless. http://lutz.donnerhacke.de/eng/Blog/DNS-Dampening-under-the-microscope ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
* Lutz Donnerhacke wrote:
The defaults are not optimal yet.
If they are optimal or not is still an open question. But the patch is
useable now. Far from perfect or finished, but used in practice.
http://altlasten.lutz.donnerhacke.de/mitarb/lutz/bind-9.9.2-dampening.patch
Unfortunly I do have a serious problem: The attack volume decreased that
drastically on my servers, that I can't test the patch in real
environments anymore. I do have one or two amplification attackes per hour
left ... #firstworldproblems
So if anybody is willing to try it out: Please do. Please report to me.
Minimal configuration is dampening {}; in options or view. I do
recommend at least dampening { exempt-clients { local_AS; resolvers; };};.
If you want to help, please add report-interval secs;. The number of
seconds should be less than the overrun of a 32bit counter under your query
rate. Reports can be found in the dampening category.
There are two implemtations activated in the patch: The (old) heap and a
(new) hash/queue. I do not know which of them performs better so I run both
in parallel to gather information. If you do not like such a play, please
remove the approbiate init function from implementations in dampening.c.
Personally I do think, the heap implementation is more stable to variable
load, but I do not have hard evidence for it yet.
Please let me thank the developers of the RRL patch, which point me to the
right files. I'm still unsure, if the RRL patch and my idea came to the same
results at the current type of attacks. I'm still wonder, if the patch
really survives a higher query rate than those I have access to.
Cut from the changed ARM
Dampening
Spoofed UDP queries are a major security threat especially when
reflected and possibly amplified by DNS servers. Dampening is a
dynamically adapting method for dealing with such kinds of misuse.
So dampening a about spoofing, hence TCP connections are not
affected at all.
Every piece of a query and its response is associated with
specific penalty points. Those points aggregate over all queries
from netblocks defined by |IPv6-prefix-length| and
|IPv4-prefix-length|. Over the time, the penalty
decreases exponentially (determined by |halflife|).
So each netblock gains a penalty over time characteristics.
In order to allow local clients, which should be protected by
anti-spoof techniques at the edge of the operated network, to
send any amount of queries without fear the risks of being blocked,
push them into a seperate view with other or no dampening rules or
add them to |exempt-clients|.
If the penalty exeeds |limit-enable-dampening|, the netblock gets
dampened. No further query processing will occur.
Every further query is dropped silently before inspecting the
content of the query itself. So the penalty value can decrease
slowly, if the sender collect not quickly enough further
|score-per-query| points. Please note, that
penalty values can't exceed |limit-maximum|.
If the penalty drops below |limit-disable-dampening|,
query processing for the netblock switchs back to normal. If
the penalty drops as low as |limit-irrelevant|,
the netblock is removed ..from the statistics. The next query
gains |score-first-query| for this netblock
and reenteres the collection.
Comment current attacks gain a huge amplification from ANY query
to DNSSEC signed zones. So each ANY query is charged with
additional |score-qtype-any| points. Furthermore
current attackers repeat the same packet over and over again, so
keeping the same id in each query. Such repetitions are recognised
and give |score-duplicates| points times the
repetition of this id.
Amplification attacks aims to huge answers, so the next penalty
comes from the response size. The penalty increased lineary from
zero for responses up to |minimum-score-size|
bytes. The maximum penalty of |score-size| is
reached when the response reaches or exceeds
|maximum-score-size| bytes.
In order to minimize expensive calulations for each query, the
penalty decay is delayed by at least
|update-delay| seconds. The statistics table
has space for |min-table-size| elements but
might increase to |max-table-size| elements if
necessary.
In order to compare various storage models, which are activated
at compile time, regular statistics can by extracted by setting
|report-interval| to the seconds between reports.
Those statistic lines contain the numerical index of the
implementation |Stats for #...|, the number of
queries processed, dampened, and exempted |queries ././.|,
and aggregated time spend in the various functions.
End of Cut
___
dns-operations mailing list
dns-operations
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
* Lutz Donnerhacke wrote: Exactly that's the result, I do observe. Details: http://lutz.donnerhacke.de/eng/Blog/Two-weeks-of-DNS-Dampening ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] How many kinds of DNS DoS attacks are we trying to stop ?
* Stephane Bortzmeyer wrote: For instance, I'm a big fan of rate-limiting ANY requests because it works fine *today* in *some* attacks but I would never say it is *the* solution to DNS-based DoS attacks. It is just a tool among others. I collected a few statistics. It's far from complete nor perfectly designed, but it covered my ass. Right now. This week. http://lutz.donnerhacke.de/eng/Blog/First-results-from-DNS-Dampening One observation I'm not sure about is: Attacker query rate seems to drop by half about two to tree weeks after rate limiting or three days after dampening. To verify the alternatives, I had to relist my server on the scriptkiddies pastbin. But I does not know the URL nor I'm willing to do so. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
[dns-operations] First experiments with DNS dampening to fight amplification attacks
Hi everybody, after serveral heavy misuse of my authoritive servers, I was urged to *solve* the problem. This is obviously not possible, but I'd like to share my results with you. I managed to drop the outgoing bandwith from a saturated 100Mbps to 80% of the incoming attack data rate in a first step. Now I so stop each attack within 40 packets. I do only respond to 30 out of 1 queries. Most production traffic is untouched. There are some collateral damage, which needs to be investigated, i.e. recursive resolvers of IPv6 tunnel providers with qmail customers are overblocked from time to time: The defaults are not optimal yet. Please have a look at http://lutz.donnerhacke.de/eng/Blog/DNS-Dampening ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
* Miek Gieben wrote: 1. Why didn't you use: http://www.redbarn.org/dns/ratelimits ? Because the remaining rate of attack is still high enough to cause problems. We had a serious query from a lawyer of an small company which can't work anymore because their 2Mbps line is saturated. 2. Will this scale to TLD sized DNS servers? It's in a very early state of development. Currently I'm trying to collect real world data to find a reasonable set of defaults. With much conservative values, it might work for a TLD. But I do not understand the problem space to claim anything. Please feel free to try it out at you site and tell me about the results. Paul, yes it drops all the responses in dampening state. It does it for a very good reason: Even REFUSED messages are enough to run the attack. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
