Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
On Oct 29, 2012, at 4:28 PM, Klaus Darilion wrote: We apply iptables based rate-limiting on ANY queries with RD bit set. The problem with fronting your DNS servers with a stateful firewall is that it makes it susceptible to trivial state-exhaustion attacks. This is not a good idea. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton ___ 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
On Mon, Oct 29, 2012 at 10:13:55AM +, Dobbins, Roland rdobb...@arbor.net wrote a message of 20 lines which said: We apply iptables based rate-limiting on ANY queries with RD bit set. The problem with fronting your DNS servers with a stateful firewall ? iptables != stateful firewalling. Some people are careless enough to use iptables modules with connection tracking (very bad idea for the DNS, for the reasons you explain) but others are more careful (rate-limiting requires only a small amount of state). ___ 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
On Oct 29, 2012, at 5:16 PM, Stephane Bortzmeyer wrote: ? iptables != stateful firewalling. I've only ever seen it deployed with connection tracking - i.e., statefully. You're right, though, that isn't a requirement. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton ___ 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
On Mon, Oct 29, 2012 at 10:21:46AM +,
Dobbins, Roland rdobb...@arbor.net wrote
a message of 20 lines which said:
I've only ever seen it deployed with connection tracking - i.e.,
statefully.
Several TLD use iptables for rate-limiting ANY amplification
attacks. They typically use the hashlimit module, which does not
activate connection tracking (which is mostly useless for DNS, anyway).
iptables -A INPUT -p udp --dport 53 -m hashlimit \
--hashlimit-name DNS --hashlimit-above 20/second --hashlimit-mode srcip \
--hashlimit-burst 100 --hashlimit-srcmask 28 -j DROP
Or, if you want to rate-limit only some patterns (ANY ripe.net...):
wget http://www.bortzmeyer.org/files/generate-netfilter-u32-dns-rule.py
then:
domain=ripe.net
action=RATELIMITER
action=LOG --log-prefix DNS-ANY-query-$domain
rule=$(python generate-netfilter-u32-dns-rule.py --qname $domain --qtype ANY)
iptables --append INPUT --destination ${MYSERVICEIPADDRESS} --protocol udp
--destination-port 53 \
--match u32 --u32 $rule \
--jump ${action}
iptables -A ${action} -p udp --dport 53 -m hashlimit \
--hashlimit-name DNS --hashlimit-above 20/second --hashlimit-mode srcip \
--hashlimit-burst 100 --hashlimit-srcmask 28 -j DROP
___
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] ATT DNS Cache Poisoning?
Thank you for your answer, Roy. Here follows my comments. On 29/10/2012 12:54, Roy Arends wrote: I did not say that. I asked DNSSEC does not defend against the Kaminsky hack?. I thought it was some sort of rhetoric question. My apologies. AFAIK, DNSSEC does not possess any revocation mechanism (an expiration mechanism does exist but I am really talking about _revocation_). Sure, CRL's are mostly only valid for 24 hours. So the revocation granularity for certificates is not real time and might have at least a 86399 second delay. If you'd want to beat that with DNSSEC, re-sign at least twice a day :-). I'm trying to argue that times can be 'gamed' to match CRL requirements. OCSP is a real time certificate checking method. Only realtime signing (Phreebird, etc) of TLSA records can match that, I think. Some say what's the matter anyway? Neither CRLs nor OCSP are checked in the real world.. I often answer that X509 have the merit to possess an already-designed revocation mechanism, which DANE cannot claim to have yet. But maybe this should be discussed off-list or on DANE WG mailing-list. Sorry. I have to admit this attack scenario is far-reached, as most DNSSEC-validatating servers do implement SPR and some even implement 0x20, but there is still the problem of middle boxes un-randomizing source ports. To me, DNSSEC protects the dns cache against Kaminsky's hack. It is not cache poisoning if you inject a cache with valid data. Naming convention problem then. My bad. Can you tell me how do you name a record no longer served by authoritative servers (removal is assumed to be a deliberate move) but whose signature are still valid? These pseudo-valid records can still be injected via a Kaminsky hack or MITM attack, which can be occasionally of concern. Best regards, Florian Maury ___ 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
On 29.10.2012 11:13, Dobbins, Roland wrote: On Oct 29, 2012, at 4:28 PM, Klaus Darilion wrote: We apply iptables based rate-limiting on ANY queries with RD bit set. The problem with fronting your DNS servers with a stateful firewall is that it makes it susceptible to trivial state-exhaustion attacks. This is not a good idea. It depends on the implementation of the firewall. For example most iptables modules which saves states have a limited number of resources to keep state. If the max. number of entries is reached, it usually deletes an old one. So, the result may not be perfect, but it is better then no rules at all. And as I said, it is not a general solution but works fine for us. Sometimes it is simpler to wait and watch what the attackers do, and if the attacks are getting to noisy, do something effective against it. Thinking of all possible scenarios that an attacker could do and then finding an solution which handles all of these scenarios is sometimes not worth the effort, especially as we see amplification attacks not as a real serious problem for our name servers, but just annoying. regards Klaus ___ 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] ATT DNS Cache Poisoning?
On 29/10/2012 13:33, Paul Wouters wrote: The kaminsky attack has nothing to do with revocation. DNSSEC solves the kaminsky attack which relies on unsigned spoofable data. I may be the only one worried about replayed signed data, after it is removed from authoritative servers. Let's take an extreme example to illustrate: Alice rents Bob a server called AMX and uses this server as a MX for her domain. The MX record is configured with a TTL of 1 day and the record set is signed for 3 months. A month later, Alice's activity has grown exponentially, and the server has become undersized for her mailing activity, so she rents Bob a larger server, BMX. She configures BMX to be her new MX and give back to Bob the AMX server. The new MX record set no longer contains the AMX server. Mallory wants to read Alice's emails. He manages to rent Bob AMX. He, then, replays the old MX record set whose signature are not expired (the signature is still valid for 2 months) to Charlie, whose resolver is vulnerable to the Kaminsky hack. When Charlie will want to send an email to Alice, he will find in its cache the replayed record set (because the signature is valid, the DNSSEC-validator has no reason to reject it) and will send his email to Mallory. If Alice could have revoked her signature on the previous MX RRSet, her emails sent by Charlie would not have been redirected to Mallory's server. One can tell She should not have signed for a period that long. It's the eternal problem of zone survivability: the shorter the signature, the shorter the interval a slave server can serve data before it expires without signing the zone himself (which can be a problem if the slave server is administrated by a third party). This lack of revocation mechanism can be a problem for some usage of DNSSEC, as in DANE where usage type 2 or 3 induce a new risk: a cache could be poisoned via a Kaminsky attack with a TLSA record whose *BUZZER* TLSA records that are not protected with DNSSEC, MUST NOT be used. If implementations do this anyway, they are broken. Absolutely. I was talking about valid DNSSEC-signed TLSA record sets replayed after their removal from the zone but before their signature expires. I would be happy to be proven wrong. I'm only a not-so-young padawan, after all ;) Patience, my grass hopper. Thank you, Florian Maury ___ 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] ATT DNS Cache Poisoning?
Florian Maury (pub-dnsop) writes: Let's take an extreme example to illustrate: [...] Mallory wants to read Alice's emails. He manages to rent Bob AMX. He, then, replays the old MX record set whose signature are not expired (the signature is still valid for 2 months) to Charlie, whose resolver is vulnerable to the Kaminsky hack. I use precisely this example in our workshops to illustrate why TTLs are included in the signatures, and why these are limited in duration. (Slight variation: old IP is rented by attacker to host a website that then does an SSL stripping attack, and Bob's your uncle[*]) You still control the validity of the data in the cache, though you don't control the cache behaviour. If Alice could have revoked her signature on the previous MX RRSet, her emails sent by Charlie would not have been redirected to Mallory's server. Revoking = have short signature lifetime, publish new ones regularly that will be preferred by validators. One can tell She should not have signed for a period that long. It's the eternal problem of zone survivability: the shorter the signature, the shorter the interval a slave server can serve data before it expires without signing the zone himself (which can be a problem if the slave server is administrated by a third party). It's an operational challenge, not a design one, and it remains: polluting caches with still-valid data is not cache poisoning (that data could have ended up in the cache in any number of ways; ceasing to publish signed data does not preclude it still being available somewhere). [*] No relation to to Alice's Bob. Cheers, Phil ___ 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
On 2012-10-29, at 06:16, Stephane Bortzmeyer bortzme...@nic.fr wrote: On Mon, Oct 29, 2012 at 10:13:55AM +, Dobbins, Roland rdobb...@arbor.net wrote a message of 20 lines which said: We apply iptables based rate-limiting on ANY queries with RD bit set. The problem with fronting your DNS servers with a stateful firewall ? iptables != stateful firewalling. no, rate-limiting == stateful firewalling. (I appreciate that there are techniques available to keep the state manageable, but state is required to rate-limit and retaining state in front of DNS servers in general ought indeed to prompt some careful thinking before implementation.) Joe ___ 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
On Oct 30, 2012, at 12:54 AM, Joe Abley wrote: (I appreciate that there are techniques available to keep the state manageable, but state is required to rate-limit and retaining state in front of DNS servers in general ought indeed to prompt some careful thinking before implementation.) Concur. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton ___ 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
