I know. It seems odd, doesn't it?
They're actually suspending people's accounts for DNS amplification. My aunt got a call about it tonight. I had already firewalled that off on her router before they called, but they're doing it. There's more that they could do I'm sure, but they're doing it. Maybe it's flooding their upstream causing other service issues.... but they're doing it.
So many others aren't doing much at all.
It's interesting that they'd call about DNS amplification... You don't
typically see DNS amplified floods coming from home ISPs. I would imagine
SSDP amplification is a far greater issue for any home ISP.
Actually, it's quite common, as a lot of CPE have abusable DNS forwarders running on their public interfaces.
DNS, SSDP, and SNMP reflection/amplification quite commonly emanate from broadband access networks due to abusable CPE. Others, as well, of course, but those are generally the most prevalent.
SSDP, DNS and other amplification is a big issue for large consumer networks like Comcast.
This is something I’m hoping other vendors take seriously (eg: Netgear) when it comes to their usage of DNSMASQ and other tools on-box and iptables configs that promote spoofing by using IP ranges vs constraining rules with the ingress/egress interface.
It’s these simple amateur errors that can turn a port 53 redirect into a spoofing instance when it only passes the INPUT rule vs -t NAT rule.
Please block SSDP and Chargen on your networks. Consider rate-limiting DNS & SNMP to 1% or something appropriate to avoid issues.
Make sure you permit TCP/53 for DNS queries so if TC=1 lookups work.
- Jared
Speaking of which, historically ISPs have been blocking TCP/135, TCP/445 and a few others towards customers (at least that's what I know). TCP/25 seems to be blocked as well.
Why isn't UDP/53 blocked towards customers? I know historically there were resolvers that used UDP/53 as source port for queries, but is this the case nowadays?
I know providers that have blocked UDP/53 towards customers as a countermeasure to the amplification attacks. As far as I heard, there were no customer complaints.
> Make sure you permit TCP/53 for DNS queries so if TC=1 lookups work.
Speaking of which, historically ISPs have been blocking TCP/135, TCP/445
and a few others towards customers (at least that's what I know). TCP/25
seems to be blocked as well.Why isn't UDP/53 blocked towards customers? I know historically there were
resolvers that used UDP/53 as source port for queries, but is this the
case nowadays?I know providers that have blocked UDP/53 towards customers as a
countermeasure to the amplification attacks. As far as I heard, there were
no customer complaints.
Because complaining is like talking to a brick wall most of the
time. People work around the ISP idiocy by shifting ports, its
easier than trying to get through help desk hell.
Totally agree. It's silly that my home lab has to cost me 5x the
normal rate if I want to use some of the standard ports but that is
normal now.
I do on my network (well, the ISP, not the IX). It makes complete sense.
Mikael Abrahamsson wrote:
Why isn't UDP/53 blocked towards customers? I know historically there
were resolvers that used UDP/53 as source port for queries, but is this
the case nowadays?I know providers that have blocked UDP/53 towards customers as a
countermeasure to the amplification attacks. As far as I heard, there
were no customer complaints.
Traffic from dns-spoofing attacks generally has src port = 53 and dst
port = random. If you block packets with udp src port=53 towards
customers, you will also block legitimate return traffic if the
customers run their own DNS servers or use opendns / google dns / etc.
Nick
"you will also block legitimate return traffic if the
customers run their own DNS servers or use opendns / google dns / etc."
I'm fine with that. Residential customers shouldn't be running DNS servers anyway and as far as the outside resolvers to go, ehhhh... I see the case for OpenDNS given that you can use it to filter (though that's easily bypassed), but not really for any others.
I had a client with a few boxes that had dns wide open. Couldn't you use snort to match against those specific requests and just drop those packets?
Regards,
Dovid
I know. It seems odd, doesn't it?
They're actually suspending people's accounts for DNS amplification. My
aunt got a call about it tonight. I had already firewalled that off on her
router before they called, but they're doing it. There's more that they
could do I'm sure, but they're doing it. Maybe it's flooding their upstream
causing other service issues.... but they're doing it.So many others aren't doing much at all.
+1 for thank you Comcast and all the folks that file and respond to network
abuse reports.
Comcast is one of the good ones helping the internet thrive (IPv6,
dnsssec, responding to and shutting down abuse)
CB
Actually, what they're talking about is blocking packets *destined* for UDP/53 on broadband access networks, not *sourced from*.
Sure, it's a very interesting discussion what ports should be blocked or not.
http://www.bitag.org/documents/Port-Blocking.pdf
This mentions on page 3.1, TCP(UDP)/25,135,139 and 445. They've been blocked for a very long time to fix some issues, even though there is legitimate use for these ports.
So if you're blocking these ports, it seems like a small step to block UDP/TCP/53 towards customers as well. I can't come up with an argument that makes sense to block TCP/25 and then not block port UDP/TCP/53 as well. If you're protecting the Internet from your customers misconfiguraiton by blocking port 25 and the MS ports, why not 53 as well?
This is a slippery slope of course, and judgement calls are not easy to make.
I'm sure someone smarter than I will chime in here, but I'd say far too much effort\resources for too little tangible results.
I agree,
At the very least things like SNMP/NTP should be blocked. I mean how many people actually run a legit NTP server out of their home? Dozens? And the people who run SNMP devices with the default/common communities aren’t the ones using it.
If the argument is that you need a Business class account to run a mail server then I have no problem extending that to DNS servers also.
Cheers,
Max
Most of the NTP hosts have been remediated or blocked.
Using QoS to set a cap of the amount of SNMP and DNS traffic is a fair response IMHO.
Some carriers eg: 7018 block chargen wholesale across their network. We haven't taken that step but it's also something I'm not opposed to.
As a community we need to determine if this background radiation and these responses are proper. I think it's a good response since vendors can't do uRPF at line rate and the major purchasers of BCM switches don't ask for it and aren't doing it, so it's not optimized or does not exist. /sigh
Jared Mauch
ISP's should block nothing, to or from the customer, unless they make it clear *before* selling the service (and include it in the Terms and Conditions of Service Contract), that they are not selling an Internet connection but are selling a partially functional Internet connection (or a limited Internet Service), and specifying exactly what the built-in deficiencies are.
Deficiencies may include:
port/protocol blockage toward the customer (destination blocks)
port/protocol blockage toward the internet (source blocks)
DNS diddling (filtering of responses, NXDOMAIN redirection/wildcards, etc)
Traffic Shaping/Policing/Congestion policies, inbound and outbound
Some ISPs are good at this and provide opt-in/out methods for at least the first three on the list. Others not so much.
And you¹d be correct (about SSDP). 
- Jason (Comcast)
On 2/25/16, 10:52 PM, "NANOG on behalf of Paras Jha"
On 2/26/16, 8:27 AM, "NANOG on behalf of Mike Hammett"