Ingress filtering on transits, peers, and IX ports

Wed Oct 14 23:39:55 UTC 2020

> On 15 Oct 2020, at 04:09, Casey Deccio <casey at deccio.net> wrote:
> 
> 
>> On Oct 13, 2020, at 8:49 PM, Chris Adams <cma at cmadams.net> wrote:
>> 
>> Once upon a time, Eric Kuhnke <eric.kuhnke at gmail.com> said:
>>> Considering that one can run an instance of an anycasted recursive
>>> nameserver, under heavy load for a very large number of clients, on a $600
>>> 1U server these days... I wonder what exactly the threat model is.
>> 
>> A customer forwarded one of these notices to us - looked like it's about
>> recursive DNS cache poisoning.
> 
> In part, yes.  More generally, it's about allowing spoofed-source packets in your front door, appearing to be from your own network, and what a bad actor could do with them.  The probes from the experiment were harmless.  But if there were malicious intent, this access could facilitate cache poisoning, depending on your DNS server configuration.
> 
>> It's been a while since I looked
>> closely, but I thought modern recursive DNS software was pretty
>> resistant to that, and anyway, the real answer to that is DNSSEC.
> 
> It is.  But DNSSEC requires support both on the side of the resolver (validation enabled) and the authoritative server (zone signed).  Adoption is still far from universal.  There are efforts to improve that, but it can't be your only hope, in its current state.
> 
> But, perhaps more importantly, cache poisoning is not the only concern.  Other vulnerable DNS (for example) configurations might be exploited by a single packet being received and acted on as "trusted”.

I know Casey knows this, but to the rest of you, this is why TSIG, SIG(0) and DNS COOKIE where invented.  IP addresses, especially IP addresses on UDP packets, are not trustworthy.  If you are not using one or more of these when sending a query you should be updating your DNS software.  If you are a ISP that is purchasing CPEs you should be requiring that the CPE uses these by default.

If you are purchasing other equipment it also should be using it by default.  Fixing security issues requires everyone to play their part.  +10% (and growing) of the worlds authoritative DNS servers support DNS COOKIE.  I don’t have measurements for recursive servers.  For it to be of benefit the clients also need to be sending requests with an DNS COOKIE option present.  Many recursive servers send this option by default as well.  The option was design to allow independent upgrade of servers and clients to occur.  The only coordination required is within a anycast server cluster where all the servers need to support the option and use a common shared secret and algorithm.  Clients will workaround shared secret / algorithm misconfigurations.

Mark

>> I could be wrong, but getting a scary-sounding OMG SECURITY ALERT email
> 
> Crafting wording in an alert email such that it should both be taken seriously and it doesn't sound too dramatic is hard.  We have gotten many positive responses.  But we've also gotten some *meh*.  In the end we made a choice about whether individual reach-out was important and worth the effort, ahead of future publication and presentation.  We decided that it was.  Many operators have agreed with us.  But I get that not everyone will feel the same about it.
> 
>> from some group I've never heard of (and haven't AFAIK engaged the
>> community about their "new" attack, scans, or notices)
> 
> I suppose it depends on your definition of "engage the community".  I think that's what we're doing right now.  We're also no stranger to NANOG (though perhaps more of a lurker on the mailing list).  But community is a much broader term.  And anyway, there is some order to this whole thing, and broader announcements will come later.
> 
> Cheers,
> Casey

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org