Re: [dns-operations] DNS RRL light?
On Sat, Sep 15, 2012 at 6:52 PM, Mohamed Lrhazi ml...@georgetown.edu wrote: https://gist.github.com/3729931 I updated the script to hash, and hence count and rate limit, the errors and responses, instead of the qname+qtype. The way am doing it is : - If response rcode is not NOERROR, hash and count the rcode itself. - else, concat all response RRs, and hash and count that instead. Is that good enough? also, with BIND RRL slip functionality aside, how close is this script to the real deal? Also, one could say that by enabling RRL, we are adding a weaknesses to the system: - Attack using large number of unique queries and unique source IPs, aiming at exhausting our RAM... Is that a valid criticism? Does BIND RRL mitigate that? Should one add logic to disable the whole RRL after reaching some QPS threshold? Thanks a lot, Mohamed. ___ 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] DNS RRL light?
Hello, For various reasons, I cannot immediately implement RRL on my DNS servers... but would like to implement something, in the meanwhile! Would these two rules be a good start? - Rate limit clients to 100 qps. Drop for 5 mins if exceeded. - Rate limit client to 5 identical queries per second. Drop for 5 mins if exceeded. I implemented these rules already, logging drops instead of performing them, and it does not seem to be dropping any legit clients, and does seem to catch the obvious ANY flood I have been watching... but am sure there is more to it than meets the eye. Any logical errors, or other errors, you see there? Also, any, simple to implement, enhancements you could add? Thank you so much. Mohamed. ___ 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 RRL light?
- Rate limit clients to 100 qps. Drop for 5 mins if exceeded. - Rate limit client to 5 identical queries per second. Drop for 5 mins if exceeded. Any logical errors, or other errors, you see there? Also, any, simple to implement, enhancements you could add? The first rule is to do whatever works in your situation no matter what outsiders say. Are you counting identical queries including qtype as well as qname? Are you dropping identical queries or all queries? Counting all queries might not work on a server for a popular domain, because there can be a lot of legitimte queries from a single carrier grade NAT IP address. Even counting 5 identical queries or responses might cause problems for a sufficiently popular web site. Counting identical queries instead identical responses might let a bad guy reflect a stream of 1500+ Byte NXDOMAIN responses using a stream of queries for unique bogus domains. Blocking at 5 identical queries per second sounds reasonable to me, but blocking for 5 minutes sounds far too long, because it might unnessarily drop legitimate queries. A 5 minute window means that on average it will be closed 2.5 minutes after the attack stops. If your scheme can react to the first 5 identical queries in a second, why not block for only 10 or 15 seconds? Vernon Schryverv...@rhyolite.com ___ 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 RRL light?
From: Mohamed Lrhazi ml...@georgetown.edu I am counting query_type+query_name, implemented as: set qhash [b64encode [md5 $q_type:$q_name]] I guess that's my state blob. Is that good? If possible, I'd use a bit hash function with lower CPU costs, although speed might matter. However, it sounds as this is all done as in shell scripts, and so it's not expected to handle many queries per second. Any good 128-bit hash will have no more collisions than a 128-bit cryptographic hash function and might have fewer. Contrary to ancient superstition, cryptographic hashes have no fewer or better distributed collisions than any other good hash function. Cryptographic hashes are only supposed to be hard to reverse and their collisions are supposed to be hard to predict. Those characteristics and their mundane collision characteristics are based only hope and a trivial number (compared to 2**128)of tests instead of mathematics like that behind other hash functions such as cyclic redundancy checks. If the IP address is handled elsewhere, any reasonable (not necessarily 'good') 32-bit hash such as `sum` or `cksum` should also have no collisions that matter, be a lot faster, and need fewer bits. The size of the state blob matters if you want to handle lots of queries/second and so need to store window size blobs; (10 seconds)*(100K blobs/second)=1M blobs. The key for each BIND9 RRL state blob consists of - 129 bits of IP address. Perhaps embedded IPv4 addresses would work, but this time I chose a separate IPv4/IPv6 bit. - qtype - simplistic 32-bit hash of qname to avoid a fixed size 256 byte buffer or worse, malloc - DNS class compressed to one bit for now - whether the response is an error, NXDOMAIN, or normal - whether TCP was used. Most of the BIND9 RRL blob consists of other stuff including links, counters, and timers. I am also dropping everything, during the drop window, as I did not want to keep the query info for too long, but since I will lower the window, it might be feasible. Dropping everything increases the likelihood of dropping legitimate requests, and so is another reason to make your window as short as possible. Vernon Schryverv...@rhyolite.com ___ 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
