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. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com
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. On Thu, Feb 25, 2016 at 10:46 PM, Mike Hammett <nanog@ics-il.net> wrote:
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.
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
On 26 Feb 2016, at 10:52, Paras Jha wrote:
You don't typically see DNS amplified floods coming from home ISPs.
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. ----------------------------------- Roland Dobbins <rdobbins@arbor.net>
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
On Feb 25, 2016, at 10:52 PM, Paras Jha <paras@protrafsolutions.com> wrote:
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.
On Thu, Feb 25, 2016 at 10:46 PM, Mike Hammett <nanog@ics-il.net> wrote:
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.
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
On Thu, 25 Feb 2016, Jared Mauch wrote:
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. -- Mikael Abrahamsson email: swmike@swm.pp.se
In message <alpine.DEB.2.02.1602260718460.11524@uplift.swm.pp.se>, Mikael Abrah amsson writes:
On Thu, 25 Feb 2016, Jared Mauch wrote:
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.
-- Mikael Abrahamsson email: swmike@swm.pp.se -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
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. On Fri, Feb 26, 2016 at 12:27 AM, Mark Andrews <marka@isc.org> wrote:
In message <alpine.DEB.2.02.1602260718460.11524@uplift.swm.pp.se>, Mikael Abrah amsson writes:
On Thu, 25 Feb 2016, Jared Mauch wrote:
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.
-- Mikael Abrahamsson email: swmike@swm.pp.se -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
I do on my network (well, the ISP, not the IX). It makes complete sense. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mikael Abrahamsson" <swmike@swm.pp.se> To: "Jared Mauch" <jared@puck.nether.net> Cc: "NANOG list" <nanog@nanog.org> Sent: Friday, February 26, 2016 12:20:28 AM Subject: Re: Thank you, Comcast. On Thu, 25 Feb 2016, Jared Mauch wrote:
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. -- Mikael Abrahamsson email: swmike@swm.pp.se
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. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Nick Hilliard" <nick@foobar.org> To: "Mikael Abrahamsson" <swmike@swm.pp.se> Cc: "NANOG list" <nanog@nanog.org> Sent: Friday, February 26, 2016 7:17:30 AM Subject: Re: Thank you, Comcast. 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
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 -----Original Message----- From: Mike Hammett <nanog@ics-il.net> Sender: "NANOG" <nanog-bounces@nanog.org>Date: Fri, 26 Feb 2016 07:27:50 Cc: NANOG list<nanog@nanog.org> Subject: Re: Thank you, Comcast. "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. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Nick Hilliard" <nick@foobar.org> To: "Mikael Abrahamsson" <swmike@swm.pp.se> Cc: "NANOG list" <nanog@nanog.org> Sent: Friday, February 26, 2016 7:17:30 AM Subject: Re: Thank you, Comcast. 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
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. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Dovid Bender" <dovid@telecurve.com> To: "Mike Hammett" <nanog@ics-il.net>, "NANOG" <nanog-bounces@nanog.org> Cc: "NANOG list" <nanog@nanog.org> Sent: Friday, February 26, 2016 7:32:09 AM Subject: Re: Thank you, Comcast. 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 -----Original Message----- From: Mike Hammett <nanog@ics-il.net> Sender: "NANOG" <nanog-bounces@nanog.org>Date: Fri, 26 Feb 2016 07:27:50 Cc: NANOG list<nanog@nanog.org> Subject: Re: Thank you, Comcast. "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. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Nick Hilliard" <nick@foobar.org> To: "Mikael Abrahamsson" <swmike@swm.pp.se> Cc: "NANOG list" <nanog@nanog.org> Sent: Friday, February 26, 2016 7:17:30 AM Subject: Re: Thank you, Comcast. 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
On 2/26/16, 8:27 AM, "NANOG on behalf of Mike Hammett" <nanog-bounces@nanog.org on behalf of nanog@ics-il.net> wrote:
"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.
There¹s some question about whether the FCC or 3rd party DNS providers would be though. Especially under the Title-II rules around non-blocking of legitimate traffic. - Jason
On 2/26/16 6:27 AM, Mike Hammett wrote:
"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.
Except that half the time people run their own DNS resolvers because their provider's resolvers are 1) Absolute garbage and either fail queries for no reason, don't respond at times, respond super slow, etc. 2) Hijack NXDOMAIN for advertising / money generation 3) Hijack responses to inject their own ads, popups, etc. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org
I think you'd be hard pressed to find more than a tenth of a percent of people attempt to run their own DNS server. Some do because they think it'll be better in some way. Rare is the occasion where anything user configured would outperform a local DNS server managed by the ISP that does no form of trickery. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Brielle Bruns" <bruns@2mbit.com> To: nanog@nanog.org Sent: Friday, February 26, 2016 9:56:40 AM Subject: Re: Thank you, Comcast. On 2/26/16 6:27 AM, Mike Hammett wrote:
"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.
Except that half the time people run their own DNS resolvers because their provider's resolvers are 1) Absolute garbage and either fail queries for no reason, don't respond at times, respond super slow, etc. 2) Hijack NXDOMAIN for advertising / money generation 3) Hijack responses to inject their own ads, popups, etc. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org
On 26 Feb 2016, at 23:15, Mike Hammett wrote:
I think you'd be hard pressed to find more than a tenth of a percent of people attempt to run their own DNS server.
You'll find a heck of a lot more of them doing so unknowingly, because they're running misconfigured, abusable CPE devices which can be leveraged by attackers to launch DNS reflection/amplification attacks. Note that outbound/crossbound DDoS attacks can have just as much of a negative impact on availability as inbound DDoS attacks; even more, when multiple attackers are abusing the same reflectors/amplifiers (which is often the case). And even that small tenth of a percent who're deliberately running their own DNS servers can end up inadvertently causing disruption if they're running those DNS servers as open recursors. ----------------------------------- Roland Dobbins <rdobbins@arbor.net>
On 2/26/16 9:15 AM, Mike Hammett wrote:
I think you'd be hard pressed to find more than a tenth of a percent of people attempt to run their own DNS server. Some do because they think it'll be better in some way. Rare is the occasion where anything user configured would outperform a local DNS server managed by the ISP that does no form of trickery.
"does no form of trickery" Therein lies the problem. Can we trust ISPs to be honest about not messing with our traffic? Kudos to you if you can say that with a straight face :-) Doesn't matter how many people actually have what we think is a 'valid' reason to do it. People have their reasons, may it be because of performance, or what they perceive as CDN issues, or just not trusting their provider. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org
They have to be honest or face litigation. Transparency is the biggest (if not the only) useful thing out of the Open Internet Order. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Brielle Bruns" <bruns@2mbit.com> To: "Mike Hammett" <nanog@ics-il.net> Cc: nanog@nanog.org Sent: Friday, February 26, 2016 10:46:27 AM Subject: Re: Thank you, Comcast. On 2/26/16 9:15 AM, Mike Hammett wrote:
I think you'd be hard pressed to find more than a tenth of a percent of people attempt to run their own DNS server. Some do because they think it'll be better in some way. Rare is the occasion where anything user configured would outperform a local DNS server managed by the ISP that does no form of trickery.
"does no form of trickery" Therein lies the problem. Can we trust ISPs to be honest about not messing with our traffic? Kudos to you if you can say that with a straight face :-) Doesn't matter how many people actually have what we think is a 'valid' reason to do it. People have their reasons, may it be because of performance, or what they perceive as CDN issues, or just not trusting their provider. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org
On 2/26/16 10:01 AM, Mike Hammett wrote:
They have to be honest or face litigation. Transparency is the biggest (if not the only) useful thing out of the Open Internet Order.
As long as the profit from doing shady things and lying is greater then the cost of settling a lawsuit, companies will be dishonest and do shady things. So, no, I don't believe threat of litigation is any barrier to how ISPs conduct their business. In fact, with how pro-business and fuck-consumer the current climate is from the govt, its just going to get worse. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org
Said in a forum comprised largely of ISPs? Bold move. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Brielle Bruns" <bruns@2mbit.com> To: nanog@nanog.org Sent: Friday, February 26, 2016 11:09:03 AM Subject: Re: Thank you, Comcast. On 2/26/16 10:01 AM, Mike Hammett wrote:
They have to be honest or face litigation. Transparency is the biggest (if not the only) useful thing out of the Open Internet Order.
As long as the profit from doing shady things and lying is greater then the cost of settling a lawsuit, companies will be dishonest and do shady things. So, no, I don't believe threat of litigation is any barrier to how ISPs conduct their business. In fact, with how pro-business and fuck-consumer the current climate is from the govt, its just going to get worse. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org
On 2/26/16 10:22 AM, Mike Hammett wrote:
Said in a forum comprised largely of ISPs? Bold move.
I appreciate the work the technical people here do, but doesn't change the fact that the people who call the shots aren't always on the same page or have the same goals as do the technical people. I don't work for ISPs anymore like I did in my early career, but my experiences from back then burned quite a bit into my brain. So, sorry if anyone feels slighted by what I said, but honesty hurts. Dancing around the truth does no one any good. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org
I disagree...the point of what I sent (missed by some) is that in just this small audience there are many that do/have/know about customers that run their own stuff. Trying to blow it off, or minimize those customers just makes you seem a little arrogant. Nothing worse than an arrogant business...
On Feb 26, 2016, at 11:15 AM, Mike Hammett <nanog@ics-il.net> wrote:
I think you'd be hard pressed to find more than a tenth of a percent of people attempt to run their own DNS server. Some do because they think it'll be better in some way. Rare is the occasion where anything user configured would outperform a local DNS server managed by the ISP that does no form of trickery.
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
----- Original Message -----
From: "Brielle Bruns" <bruns@2mbit.com> To: nanog@nanog.org Sent: Friday, February 26, 2016 9:56:40 AM Subject: Re: Thank you, Comcast.
On 2/26/16 6:27 AM, Mike Hammett wrote: "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.
Except that half the time people run their own DNS resolvers because their provider's resolvers are
1) Absolute garbage and either fail queries for no reason, don't respond at times, respond super slow, etc.
2) Hijack NXDOMAIN for advertising / money generation
3) Hijack responses to inject their own ads, popups, etc.
-- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org
This small audience also consists of predominately people that administer networks and would be doing such things. I'll be you'll find a vastly different percentage of the Cross Stitch Operators Group even know what DNS is, much less have any desire to change it. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "David Bass" <davidbass570@gmail.com> To: "Mike Hammett" <nanog@ics-il.net> Cc: "Brielle Bruns" <bruns@2mbit.com>, nanog@nanog.org Sent: Friday, February 26, 2016 10:47:55 AM Subject: Re: Thank you, Comcast. I disagree...the point of what I sent (missed by some) is that in just this small audience there are many that do/have/know about customers that run their own stuff. Trying to blow it off, or minimize those customers just makes you seem a little arrogant. Nothing worse than an arrogant business...
On Feb 26, 2016, at 11:15 AM, Mike Hammett <nanog@ics-il.net> wrote:
I think you'd be hard pressed to find more than a tenth of a percent of people attempt to run their own DNS server. Some do because they think it'll be better in some way. Rare is the occasion where anything user configured would outperform a local DNS server managed by the ISP that does no form of trickery.
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
----- Original Message -----
From: "Brielle Bruns" <bruns@2mbit.com> To: nanog@nanog.org Sent: Friday, February 26, 2016 9:56:40 AM Subject: Re: Thank you, Comcast.
On 2/26/16 6:27 AM, Mike Hammett wrote: "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.
Except that half the time people run their own DNS resolvers because their provider's resolvers are
1) Absolute garbage and either fail queries for no reason, don't respond at times, respond super slow, etc.
2) Hijack NXDOMAIN for advertising / money generation
3) Hijack responses to inject their own ads, popups, etc.
-- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org
In article <848464982.14027.1456503347620.JavaMail.mhammett@ThunderFuck> you write:
I think you'd be hard pressed to find more than a tenth of a percent of people attempt to run their own DNS server. Some do because they think it'll be better in some way. Rare is the occasion where anything user configured would outperform a local DNS server managed by the ISP that does no form of trickery.
I run my own DNS cache behind my home NAT router. It knows about some locally served names so I can refer to the computers on my LAN by name, and it does DNSSEC which my ISP's (T-W) DNS caches don't. Since it's not visible from outside, it's hard to see how anyone could abuse it, and it really does stuff that other caches don't. I wouldn't have any problem if my ISP filtered outgoing port 53 traffic with the QR bit set, of which I should be sending none, but I'd be annoyed if they filtered outgoing queries. R's, John
----- Original Message -----
From: "Mike Hammett" <nanog@ics-il.net>
I think you'd be hard pressed to find more than a tenth of a percent of people attempt to run their own DNS server. Some do because they think it'll be better in some way. Rare is the occasion where anything user configured would outperform a local DNS server managed by the ISP that does no form of trickery.
I suspect it's higher than that, because of the fraction of edge routers which do DNS masquerading. Since that caches, I'm assuming it's a recursor, rather than merely a pass-through, though I suppose it might be implementation dependent. And *most* eyeball customer resolver servers engage in search stupidity now, don't they? :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
Once upon a time, Brielle Bruns <bruns@2mbit.com> said:
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.
Except that half the time people run their own DNS resolvers because their provider's resolvers are
Resolver != authoritative server. Your local DNS resolver doesn't need to be (and should not be) listening to port 53 on the Internet. Only DNS authoritative servers need to accept Internet traffic on port 53, and almost nobody needs to be running one on a typical residential connection (especially since residential IPs do change from time to time). -- Chris Adams <cma@cmadams.net>
On 2/26/16 10:02 AM, Chris Adams wrote:
Except that half the time people run their own DNS resolvers because their provider's resolvers are
Resolver != authoritative server. Your local DNS resolver doesn't need to be (and should not be) listening to port 53 on the Internet. Only DNS authoritative servers need to accept Internet traffic on port 53, and almost nobody needs to be running one on a typical residential connection (especially since residential IPs do change from time to time).
UDP is a fun protocol - stateless, so blocking a DST of 53/UDP to the customer also will block responses to recursive queries that originate from SRC 53/UDP. Connection tracking sorta makes it stateful to a point, but it can get ugly with enough traffic. Place the blame for local resolvers listening on WAN squarely where it belongs - the router vendors who make these devices. You can't do anything about idiots buying a pro-sumer/professional device like an EdgeRouter and misconfiguring it, but Linksys/Cisco, D-Link, Netgear, etc that are targeted towards home users should be held to the fire for that kind of screw up. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org
On 27 Feb 2016, at 0:16, Brielle Bruns wrote:
UDP is a fun protocol - stateless, so blocking a DST of 53/UDP to the customer also will block responses to recursive queries that originate from SRC 53/UDP.
Which are relatively rare, these days. Any device doing this by default is likely running out-of-date software that is abusable in multiple ways. ----------------------------------- Roland Dobbins <rdobbins@arbor.net>
On 27 Feb 2016, at 0:16, Brielle Bruns wrote:
You can't do anything about idiots buying a pro-sumer/professional device like an EdgeRouter and misconfiguring it, but Linksys/Cisco, D-Link, Netgear, etc that are targeted towards home users should be held to the fire for that kind of screw up.
Also, see this article: <http://arstechnica.com/security/2016/02/asus-lawsuit-puts-entire-industry-on-notice-over-shoddy-router-security/> and this .pdf preso: <https://app.box.com/s/rblnddlhda44giwfa8hy> ----------------------------------- Roland Dobbins <rdobbins@arbor.net>
On 26/02/16 09:16, Brielle Bruns wrote:
Place the blame for local resolvers listening on WAN squarely where it belongs - the router vendors who make these devices.
As long as ISPs massively buy crappy hardware pieces, vendors will make them and sell them. That's how it works. Best regards.
On 2/26/16, 12:33 PM, "NANOG on behalf of Octavio Alvarez" <nanog-bounces@nanog.org on behalf of octalnanog@alvarezp.org> wrote:
On 26/02/16 09:16, Brielle Bruns wrote:
Place the blame for local resolvers listening on WAN squarely where it belongs - the router vendors who make these devices.
As long as ISPs massively buy crappy hardware pieces, vendors will make them and sell them. That's how it works.
I think the bigger culprit is not the stuff ISPs buy but what consumers buy (aka COAM). Jason
On Feb 26, 2016, at 2:28 PM, Livingood, Jason <Jason_Livingood@comcast.com> wrote:
I think the bigger culprit is not the stuff ISPs buy but what consumers buy (aka COAM).
I’m certainly not a comcast apologist, (I do wish they would service the communities where they had their call centers, like here in the unserved parts of their Scio Township call center). But Jason is spot-on here. There are clear scale problems when dealing with large numbers of customers, and no matter what some of them will use crap equipment. We as an the techies in industry often “just fix it” for our friends/parents/colleagues. I am an enabler of CGN as I often help a local WISP with their environment when they should be doing IPv6 or something else. Often people are willing to leave as a customer because their device which gets no firmware updates blocks valid DNS requests or has some other problem. These items are shipped freight 6 months in advance from someplace like Shenzhen and never updated, then when they don’t work, customers who don’t understand RF propagation issues, why running a cable through the wall is better, etc.. end up ditching because of the $200 gift card offered for 8 hours of time waiting for an installation appointment in 2 years. These incentives are all wrong in the marketplace, we need better equipment, better people and better responses to the issues. We all have committed various technical sins, I’m not immune, nor is Comcast or likely most people on the list. This thread was started because Comcast and the teams led by Michael actually worked to remediate abusive customer equipment that wasn’t their fault. As we continue to connect devices to the network, the ability to do this type of remediation is essential. If you don’t believe me, look at the recent settlement with ASUS (http://arstechnica.com/security/2016/02/asus-lawsuit-puts-entire-industry-on...) or this twitter account - http://tinyurl.com/p6tfh8d where things are comically documented. (Short URL as it uses a profane term that some systems may filter). - Jared
Once upon a time, Brielle Bruns <bruns@2mbit.com> said:
UDP is a fun protocol - stateless, so blocking a DST of 53/UDP to the customer also will block responses to recursive queries that originate from SRC 53/UDP. Connection tracking sorta makes it stateful to a point, but it can get ugly with enough traffic.
Sending queries from port 53 has been considered bad behavior and deprecated for what, 15 years now? -- Chris Adams <cma@cmadams.net>
This is one of my pet peeves. Another is default passwords for devices. Kudo to TP-Link for not shipping devices with default passwords. Regards, Dovid -----Original Message----- From: Brielle Bruns <bruns@2mbit.com> Sender: "NANOG" <nanog-bounces@nanog.org>Date: Fri, 26 Feb 2016 10:16:33 To: <nanog@nanog.org> Subject: Re: Thank you, Comcast. On 2/26/16 10:02 AM, Chris Adams wrote:
Except that half the time people run their own DNS resolvers because their provider's resolvers are
Resolver != authoritative server. Your local DNS resolver doesn't need to be (and should not be) listening to port 53 on the Internet. Only DNS authoritative servers need to accept Internet traffic on port 53, and almost nobody needs to be running one on a typical residential connection (especially since residential IPs do change from time to time).
UDP is a fun protocol - stateless, so blocking a DST of 53/UDP to the customer also will block responses to recursive queries that originate from SRC 53/UDP. Connection tracking sorta makes it stateful to a point, but it can get ugly with enough traffic. Place the blame for local resolvers listening on WAN squarely where it belongs - the router vendors who make these devices. You can't do anything about idiots buying a pro-sumer/professional device like an EdgeRouter and misconfiguring it, but Linksys/Cisco, D-Link, Netgear, etc that are targeted towards home users should be held to the fire for that kind of screw up. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org
On Fri, Feb 26, 2016 at 10:16:33AM -0700, Brielle Bruns wrote:
You can't do anything about idiots buying a pro-sumer/professional device like an EdgeRouter and misconfiguring it, but Linksys/Cisco, D-Link, Netgear, etc that are targeted towards home users should be held to the fire for that kind of screw up.
That is starting to happen: FTC Dings ASUS For Selling 'Secure' Routers That Shipped With Default Admin/Admin Login (And Other Flaws) https://www.techdirt.com/articles/20160223/11103133687/ftc-dings-asus-sellin... ---rsk
On 2/26/16 1:08 PM, Rich Kulawiec wrote:
On Fri, Feb 26, 2016 at 10:16:33AM -0700, Brielle Bruns wrote:
You can't do anything about idiots buying a pro-sumer/professional device like an EdgeRouter and misconfiguring it, but Linksys/Cisco, D-Link, Netgear, etc that are targeted towards home users should be held to the fire for that kind of screw up.
That is starting to happen:
FTC Dings ASUS For Selling 'Secure' Routers That Shipped With Default Admin/Admin Login (And Other Flaws) https://www.techdirt.com/articles/20160223/11103133687/ftc-dings-asus-sellin...
---rsk
It looks like they nailed ASUS due to it claiming to be 'secure'. I don't have a problem per-se with default passwords being used on a new device that requires configuration before it actually works and isn't marketed to the ignorant end user. IE: (again my experience with Ubiquiti stuff being a baseline) The EdgeRouter series is power user/professional targeted, default passwords, however it does not come 'pre-configured', can't route, can't NAT, etc without some initial setup. Cisco's non-consumer stuff like the Cat6500, etc having no password by default doesn't bug me because the thing is useless until you actually configure it. Its all about the market you are targeting IMHO. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org
There is so much arrogance in these posts saying that these things should be blocked because it's best or because it's negligible. The point of having an open internet is that people are going to have use cases that you haven't even thought of and should not be hindered. Even the reasons you have identified--who are you to say that I can't run services for my own use to my home? Why should I have to pay for two separate connections so that I can have tv and internet because I require ports not being blocked for it to function? I maintain a lab out of my home and it's on my dime to maintain and for my personal use. Please tell me again about my need for a business connection. Sincerely, Anthony R Junk Network and Security Engineer (410) 929-1838 anthonyrjunk@gmail.com On Fri, Feb 26, 2016 at 12:02 PM, Chris Adams <cma@cmadams.net> wrote:
Once upon a time, Brielle Bruns <bruns@2mbit.com> said:
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.
Except that half the time people run their own DNS resolvers because their provider's resolvers are
Resolver != authoritative server. Your local DNS resolver doesn't need to be (and should not be) listening to port 53 on the Internet. Only DNS authoritative servers need to accept Internet traffic on port 53, and almost nobody needs to be running one on a typical residential connection (especially since residential IPs do change from time to time).
-- Chris Adams <cma@cmadams.net>
On 27 Feb 2016, at 0:25, Anthony Junk wrote:
There is so much arrogance in these posts saying that these things should be blocked because it's best or because it's negligible.
I think there's a lack of comprehension on the part of those who don't run large networks and/or who aren't responsible for maintaing network availability for their customer base. Blocking or QoSing down port-pairs at the peering/transit edge is all too often the least worst option these operators have
Please tell me again about my need for a business connection.
Caveat emptor. ----------------------------------- Roland Dobbins <rdobbins@arbor.net>
On 26 Feb 2016, at 20:17, Nick Hilliard wrote:
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.
Actually, what they're talking about is blocking packets *destined* for UDP/53 on broadband access networks, not *sourced from*. ----------------------------------- Roland Dobbins <rdobbins@arbor.net>
On Fri, 26 Feb 2016, Nick Hilliard wrote:
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.
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. -- Mikael Abrahamsson email: swmike@swm.pp.se
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
On Feb 26, 2016, at 8:55 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
On Fri, 26 Feb 2016, Nick Hilliard wrote:
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.
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.
-- Mikael Abrahamsson email: swmike@swm.pp.se
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
On Feb 26, 2016, at 9:18 AM, Maxwell Cole <mcole.mailinglists@gmail.com> wrote:
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
On Feb 26, 2016, at 8:55 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
On Fri, 26 Feb 2016, Nick Hilliard wrote:
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.
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.
-- Mikael Abrahamsson email: swmike@swm.pp.se
On Fri, Feb 26, 2016 at 6:28 AM, Jared Mauch <jared@puck.nether.net> wrote:
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
I don't agree with the approach of going after individual reflectors (open*project) or blocking specific ports (Comcast's action here) as both are reactive, unlikely to be particularly effective (there are still millions of reflectors and plenty of open ports available), and don't solve the root problem (spoofed packets making it onto the public internet). What I'd much rather see Comcast do is use their netflow to trace the source of the spoofed packets (one of their peers or transit providers, no doubt) and strongly encourage (using their legal or PR team as needed) them to trace back and stop the spoofing. This benefits everyone in a much more direct and scalable way. Until some of the larger providers start doing that, amplification attacks and other spoofed-source attacks (DNS and synfloods) will continue to thrive. (I've contacted several ISPs about the spoofed traffic they send to us. The next major hurdle is that so many don't have netflow or other useful monitoring of their networks....) Damian
On 26 Feb 2016, at 23:02, Damian Menscher via NANOG wrote:
What I'd much rather see Comcast do is use their netflow to trace the source of the spoofed packets (one of their peers or transit providers, no doubt) and strongly encourage (using their legal or PR team as needed) them to trace back and stop the spoofing.
These approaches aren't necessarily mutually exclusive, as most flow telemetry implementations still report on blocked traffic from exporting devices. Keeping the network up and available for the vast majority of the customer base trumps all other considerations. DNS queries should not typically be directed towards consumer broadband access netblocks, period; and when they cause operational problems due to abusable CPE being, well, abused, immediate remediation action(s) must be taken. To do otherwise would be irresponsible. ----------------------------------- Roland Dobbins <rdobbins@arbor.net>
We all know what countries this traffic is coming from. While you can threaten the local ISP's the ones over seas where the traffic is coming from won't care. Regards, Dovid -----Original Message----- From: Damian Menscher via NANOG <nanog@nanog.org> Sender: "NANOG" <nanog-bounces@nanog.org>Date: Fri, 26 Feb 2016 08:02:52 To: Jared Mauch<jared@puck.nether.net>; Jason Livingood<Jason_Livingood@cable.comcast.com>; Mody, Nirmal<Nirmal_Mody@cable.comcast.com> Reply-To: Damian Menscher <damian@google.com> Cc: NANOG list<nanog@nanog.org> Subject: Re: Thank you, Comcast. On Fri, Feb 26, 2016 at 6:28 AM, Jared Mauch <jared@puck.nether.net> wrote:
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
I don't agree with the approach of going after individual reflectors (open*project) or blocking specific ports (Comcast's action here) as both are reactive, unlikely to be particularly effective (there are still millions of reflectors and plenty of open ports available), and don't solve the root problem (spoofed packets making it onto the public internet). What I'd much rather see Comcast do is use their netflow to trace the source of the spoofed packets (one of their peers or transit providers, no doubt) and strongly encourage (using their legal or PR team as needed) them to trace back and stop the spoofing. This benefits everyone in a much more direct and scalable way. Until some of the larger providers start doing that, amplification attacks and other spoofed-source attacks (DNS and synfloods) will continue to thrive. (I've contacted several ISPs about the spoofed traffic they send to us. The next major hurdle is that so many don't have netflow or other useful monitoring of their networks....) Damian
"We all know..." followed by a false statement is amusing. A significant portion of spoofing originates from North America. In a recent attack I'm reviewing, the top sources of spoofing were the southwestern US, the northwestern US, and east Asia (and almost none from Europe). If ISPs understood how to collect and review netflow we might get somewhere... why is this so hard, and how do we fix it? Damian On Fri, Feb 26, 2016 at 10:48 AM, Dovid Bender <dovid@telecurve.com> wrote:
We all know what countries this traffic is coming from. While you can threaten the local ISP's the ones over seas where the traffic is coming from won't care.
Regards,
Dovid
-----Original Message----- From: Damian Menscher via NANOG <nanog@nanog.org> Sender: "NANOG" <nanog-bounces@nanog.org>Date: Fri, 26 Feb 2016 08:02:52 To: Jared Mauch<jared@puck.nether.net>; Jason Livingood< Jason_Livingood@cable.comcast.com>; Mody, Nirmal< Nirmal_Mody@cable.comcast.com> Reply-To: Damian Menscher <damian@google.com> Cc: NANOG list<nanog@nanog.org> Subject: Re: Thank you, Comcast.
On Fri, Feb 26, 2016 at 6:28 AM, Jared Mauch <jared@puck.nether.net> wrote:
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
I don't agree with the approach of going after individual reflectors (open*project) or blocking specific ports (Comcast's action here) as both are reactive, unlikely to be particularly effective (there are still millions of reflectors and plenty of open ports available), and don't solve the root problem (spoofed packets making it onto the public internet). What I'd much rather see Comcast do is use their netflow to trace the source of the spoofed packets (one of their peers or transit providers, no doubt) and strongly encourage (using their legal or PR team as needed) them to trace back and stop the spoofing. This benefits everyone in a much more direct and scalable way. Until some of the larger providers start doing that, amplification attacks and other spoofed-source attacks (DNS and synfloods) will continue to thrive.
(I've contacted several ISPs about the spoofed traffic they send to us. The next major hurdle is that so many don't have netflow or other useful monitoring of their networks....)
Damian
Lawsuits? There is no reason the dedicated server I have with a 100meg pipe for $65.00 per month is able to spoof IP's. The colo's should be doing a better job to lock this down. Regards, Dovid -----Original Message----- From: Damian Menscher <damian@google.com> Date: Fri, 26 Feb 2016 11:47:43 To: Dovid B<dovid@telecurve.com> Cc: Jared Mauch<jared@puck.nether.net>; Jason Livingood<Jason_Livingood@cable.comcast.com>; Mody, Nirmal<Nirmal_Mody@cable.comcast.com>; NANOG list<nanog@nanog.org> Subject: Re: Thank you, Comcast. "We all know..." followed by a false statement is amusing. A significant portion of spoofing originates from North America. In a recent attack I'm reviewing, the top sources of spoofing were the southwestern US, the northwestern US, and east Asia (and almost none from Europe). If ISPs understood how to collect and review netflow we might get somewhere... why is this so hard, and how do we fix it? Damian On Fri, Feb 26, 2016 at 10:48 AM, Dovid Bender <dovid@telecurve.com> wrote:
We all know what countries this traffic is coming from. While you can threaten the local ISP's the ones over seas where the traffic is coming from won't care.
Regards,
Dovid
-----Original Message----- From: Damian Menscher via NANOG <nanog@nanog.org> Sender: "NANOG" <nanog-bounces@nanog.org>Date: Fri, 26 Feb 2016 08:02:52 To: Jared Mauch<jared@puck.nether.net>; Jason Livingood< Jason_Livingood@cable.comcast.com>; Mody, Nirmal< Nirmal_Mody@cable.comcast.com> Reply-To: Damian Menscher <damian@google.com> Cc: NANOG list<nanog@nanog.org> Subject: Re: Thank you, Comcast.
On Fri, Feb 26, 2016 at 6:28 AM, Jared Mauch <jared@puck.nether.net> wrote:
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
I don't agree with the approach of going after individual reflectors (open*project) or blocking specific ports (Comcast's action here) as both are reactive, unlikely to be particularly effective (there are still millions of reflectors and plenty of open ports available), and don't solve the root problem (spoofed packets making it onto the public internet). What I'd much rather see Comcast do is use their netflow to trace the source of the spoofed packets (one of their peers or transit providers, no doubt) and strongly encourage (using their legal or PR team as needed) them to trace back and stop the spoofing. This benefits everyone in a much more direct and scalable way. Until some of the larger providers start doing that, amplification attacks and other spoofed-source attacks (DNS and synfloods) will continue to thrive.
(I've contacted several ISPs about the spoofed traffic they send to us. The next major hurdle is that so many don't have netflow or other useful monitoring of their networks....)
Damian
I'd expect the Colo's to start "locking this down" about the same time I'd expect ISP's to start implementing BCP38 in earnest. Adam ------ Original Message ------ From: "Dovid Bender" <dovid@telecurve.com> To: "Damian Menscher" <damian@google.com> Cc: "Mody, Nirmal" <Nirmal_Mody@cable.comcast.com>; "NANOG list" <nanog@nanog.org> Sent: 2/26/2016 3:43:34 PM Subject: Re: Thank you, Comcast.
Lawsuits? There is no reason the dedicated server I have with a 100meg pipe for $65.00 per month is able to spoof IP's. The colo's should be doing a better job to lock this down.
Regards,
Dovid
-----Original Message----- From: Damian Menscher <damian@google.com> Date: Fri, 26 Feb 2016 11:47:43 To: Dovid B<dovid@telecurve.com> Cc: Jared Mauch<jared@puck.nether.net>; Jason Livingood<Jason_Livingood@cable.comcast.com>; Mody, Nirmal<Nirmal_Mody@cable.comcast.com>; NANOG list<nanog@nanog.org> Subject: Re: Thank you, Comcast.
"We all know..." followed by a false statement is amusing.
A significant portion of spoofing originates from North America. In a recent attack I'm reviewing, the top sources of spoofing were the southwestern US, the northwestern US, and east Asia (and almost none from Europe).
If ISPs understood how to collect and review netflow we might get somewhere... why is this so hard, and how do we fix it?
Damian
On Fri, Feb 26, 2016 at 10:48 AM, Dovid Bender <dovid@telecurve.com> wrote:
We all know what countries this traffic is coming from. While you can threaten the local ISP's the ones over seas where the traffic is coming from won't care.
Regards,
Dovid
-----Original Message----- From: Damian Menscher via NANOG <nanog@nanog.org> Sender: "NANOG" <nanog-bounces@nanog.org>Date: Fri, 26 Feb 2016 08:02:52 To: Jared Mauch<jared@puck.nether.net>; Jason Livingood< Jason_Livingood@cable.comcast.com>; Mody, Nirmal< Nirmal_Mody@cable.comcast.com> Reply-To: Damian Menscher <damian@google.com> Cc: NANOG list<nanog@nanog.org> Subject: Re: Thank you, Comcast.
On Fri, Feb 26, 2016 at 6:28 AM, Jared Mauch <jared@puck.nether.net> wrote:
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
I don't agree with the approach of going after individual reflectors (open*project) or blocking specific ports (Comcast's action here) as both are reactive, unlikely to be particularly effective (there are still millions of reflectors and plenty of open ports available), and don't solve the root problem (spoofed packets making it onto the public internet). What I'd much rather see Comcast do is use their netflow to trace the source of the spoofed packets (one of their peers or transit providers, no doubt) and strongly encourage (using their legal or PR team as needed) them to trace back and stop the spoofing. This benefits everyone in a much more direct and scalable way. Until some of the larger providers start doing that, amplification attacks and other spoofed-source attacks (DNS and synfloods) will continue to thrive.
(I've contacted several ISPs about the spoofed traffic they send to us. The next major hurdle is that so many don't have netflow or other useful monitoring of their networks....)
Damian
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.
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Maxwell Cole Sent: Friday, 26 February, 2016 07:19 To: Mikael Abrahamsson Cc: NANOG list Subject: Re: Thank you, Comcast.
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
On Feb 26, 2016, at 8:55 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
On Fri, 26 Feb 2016, Nick Hilliard wrote:
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.
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.
-- Mikael Abrahamsson email: swmike@swm.pp.se
On Feb 26, 2016, at 8:55 AM, Mikael Abrahamsson <swmike@swm.pp.se<mailto:swmike@swm.pp.se>> wrote:
On Fri, 26 Feb 2016, Nick Hilliard wrote:
Traffic from dns-spoofing attacks generally has src port = 53 and dst
FWIW, Comcast's list of blocked ports is at http://customer.xfinity.com/help-and-support/internet/list-of-blocked-ports/. The suspensions this week are in direct response to reported abuse from amplification attacks, which we obviously take very seriously. We are in the process of considering adding some new ports to this block list right now, and one big suggestion is SSDP. If you have any others you wish to suggest please send them to me and the guy on the cc line (Nirmal Mody). Thanks! Jason On 2/26/16, 9:31 AM, "NANOG on behalf of Keith Medcalf" <nanog-bounces@nanog.org<mailto:nanog-bounces@nanog.org> on behalf of kmedcalf@dessus.com<mailto:kmedcalf@dessus.com>> wrote: 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. -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Maxwell Cole Sent: Friday, 26 February, 2016 07:19 To: Mikael Abrahamsson Cc: NANOG list Subject: Re: Thank you, Comcast. 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 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.
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.
-- Mikael Abrahamsson email: swmike@swm.pp.se<mailto:swmike@swm.pp.se>
On Friday, 26 February, 2016 08:13, Jason_Livingood@comcast.com said:
FWIW, Comcast's list of blocked ports is at http://customer.xfinity.com/help-and-support/internet/list-of-blocked- ports/. The suspensions this week are in direct response to reported abuse from amplification attacks, which we obviously take very seriously.
God is that a horrid web page. I cannot view it. The wheels on the bus go round and round non-stop. It has so much intertwined malicious javascript, cross-site scripting, and malicious trackers that the alarm klaxons go off when I attempt to access it. I spent a couple of minutes attempting to access the page but still maintaining blocks to the malicious links. Apparently, viewing the page requires that all security be turned off and that the viewer allows completely untrusted code from completely untrustworty sources to run unabated on the viewers computer. I do not permit this. For anyone. Ever. This pretty much ensures that I would never be one of your customers. If you cannot operate a server which serves renderable non-malicious web pages properly, what hope is there that you can do anything else right?
We are in the process of considering adding some new ports to this block list right now, and one big suggestion is SSDP. If you have any others you wish to suggest please send them to me and the guy on the cc line (Nirmal Mody).
On 2/26/16, 9:31 AM, "NANOG on behalf of Keith Medcalf" <nanog- bounces@nanog.org on behalf of kmedcalf@dessus.com> wrote:
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.
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Maxwell Cole Sent: Friday, 26 February, 2016 07:19 To: Mikael Abrahamsson Cc: NANOG list Subject: Re: Thank you, Comcast. 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 > On Feb 26, 2016, at 8:55 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote: > > On Fri, 26 Feb 2016, Nick Hilliard wrote: > >> 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. > > 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. > > -- > Mikael Abrahamsson email: swmike@swm.pp.se
Works fine on a default Chrome installation. *shrugs* ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Keith Medcalf" <kmedcalf@dessus.com> To: "NANOG list" <nanog@nanog.org> Cc: "Nirmal Mody" <Nirmal_Mody@cable.comcast.com> Sent: Friday, February 26, 2016 9:55:20 AM Subject: RE: Thank you, Comcast. On Friday, 26 February, 2016 08:13, Jason_Livingood@comcast.com said:
FWIW, Comcast's list of blocked ports is at http://customer.xfinity.com/help-and-support/internet/list-of-blocked- ports/. The suspensions this week are in direct response to reported abuse from amplification attacks, which we obviously take very seriously.
God is that a horrid web page. I cannot view it. The wheels on the bus go round and round non-stop. It has so much intertwined malicious javascript, cross-site scripting, and malicious trackers that the alarm klaxons go off when I attempt to access it. I spent a couple of minutes attempting to access the page but still maintaining blocks to the malicious links. Apparently, viewing the page requires that all security be turned off and that the viewer allows completely untrusted code from completely untrustworty sources to run unabated on the viewers computer. I do not permit this. For anyone. Ever. This pretty much ensures that I would never be one of your customers. If you cannot operate a server which serves renderable non-malicious web pages properly, what hope is there that you can do anything else right?
We are in the process of considering adding some new ports to this block list right now, and one big suggestion is SSDP. If you have any others you wish to suggest please send them to me and the guy on the cc line (Nirmal Mody).
On 2/26/16, 9:31 AM, "NANOG on behalf of Keith Medcalf" <nanog- bounces@nanog.org on behalf of kmedcalf@dessus.com> wrote:
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.
On Feb 26, 2016, at 8:55 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
On Fri, 26 Feb 2016, Nick Hilliard wrote:
Traffic from dns-spoofing attacks generally has src port = 53 and dst
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Maxwell Cole Sent: Friday, 26 February, 2016 07:19 To: Mikael Abrahamsson Cc: NANOG list Subject: Re: Thank you, Comcast. 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 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.
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.
-- Mikael Abrahamsson email: swmike@swm.pp.se
Also worked fine in IE 11 and Firefox. I didn't change any particular security settings either. Might want to check your stuff before you rant on someone's web site. Steven Naslund Chicago IL -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Mike Hammett Sent: Friday, February 26, 2016 10:01 AM To: NANOG list Subject: Re: Thank you, Comcast. Works fine on a default Chrome installation. *shrugs* ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Keith Medcalf" <kmedcalf@dessus.com> To: "NANOG list" <nanog@nanog.org> Cc: "Nirmal Mody" <Nirmal_Mody@cable.comcast.com> Sent: Friday, February 26, 2016 9:55:20 AM Subject: RE: Thank you, Comcast. On Friday, 26 February, 2016 08:13, Jason_Livingood@comcast.com said:
FWIW, Comcast's list of blocked ports is at http://customer.xfinity.com/help-and-support/internet/list-of-blocked- ports/. The suspensions this week are in direct response to reported abuse from amplification attacks, which we obviously take very seriously.
God is that a horrid web page. I cannot view it. The wheels on the bus go round and round non-stop. It has so much intertwined malicious javascript, cross-site scripting, and malicious trackers that the alarm klaxons go off when I attempt to access it. I spent a couple of minutes attempting to access the page but still maintaining blocks to the malicious links. Apparently, viewing the page requires that all security be turned off and that the viewer allows completely untrusted code from completely untrustworty sources to run unabated on the viewers computer. I do not permit this. For anyone. Ever. This pretty much ensures that I would never be one of your customers. If you cannot operate a server which serves renderable non-malicious web pages properly, what hope is there that you can do anything else right?
We are in the process of considering adding some new ports to this block list right now, and one big suggestion is SSDP. If you have any others you wish to suggest please send them to me and the guy on the cc line (Nirmal Mody).
On 2/26/16, 9:31 AM, "NANOG on behalf of Keith Medcalf" <nanog- bounces@nanog.org on behalf of kmedcalf@dessus.com> wrote:
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.
On Feb 26, 2016, at 8:55 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
On Fri, 26 Feb 2016, Nick Hilliard wrote:
Traffic from dns-spoofing attacks generally has src port = 53 and dst
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Maxwell Cole Sent: Friday, 26 February, 2016 07:19 To: Mikael Abrahamsson Cc: NANOG list Subject: Re: Thank you, Comcast. 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 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.
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.
-- Mikael Abrahamsson email: swmike@swm.pp.se
The default configuration of IE (all versions), Firefox (all versions), Edge (all versions) and Chrome (all versions) is a zero-security configuration. Of course it works fine in a zero-security configuration -- I said that from the get go. It does not work if you do not permit javascript to run unless approved, and do not permit unapproved (and unapprovable scripts from third-party sites of unknown provenance) to run. It does not work if you block cross-site access to widgets and crap coming from third-parties of equally unknown provenance. I do not know what it is looking for, but it cannot do that, so therefore it does not work. You may not care about how insecure your browser is -- I do.
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Naslund, Steve Sent: Friday, 26 February, 2016 10:11 To: NANOG list Subject: RE: Thank you, Comcast.
Also worked fine in IE 11 and Firefox. I didn't change any particular security settings either. Might want to check your stuff before you rant on someone's web site.
Steven Naslund Chicago IL
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Mike Hammett Sent: Friday, February 26, 2016 10:01 AM To: NANOG list Subject: Re: Thank you, Comcast.
Works fine on a default Chrome installation. *shrugs*
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
----- Original Message -----
From: "Keith Medcalf" <kmedcalf@dessus.com> To: "NANOG list" <nanog@nanog.org> Cc: "Nirmal Mody" <Nirmal_Mody@cable.comcast.com> Sent: Friday, February 26, 2016 9:55:20 AM Subject: RE: Thank you, Comcast.
On Friday, 26 February, 2016 08:13, Jason_Livingood@comcast.com said:
FWIW, Comcast's list of blocked ports is at http://customer.xfinity.com/help-and-support/internet/list-of-blocked- ports/. The suspensions this week are in direct response to reported abuse from amplification attacks, which we obviously take very seriously.
God is that a horrid web page. I cannot view it. The wheels on the bus go round and round non-stop.
It has so much intertwined malicious javascript, cross-site scripting, and malicious trackers that the alarm klaxons go off when I attempt to access it. I spent a couple of minutes attempting to access the page but still maintaining blocks to the malicious links. Apparently, viewing the page requires that all security be turned off and that the viewer allows completely untrusted code from completely untrustworty sources to run unabated on the viewers computer.
I do not permit this. For anyone. Ever.
This pretty much ensures that I would never be one of your customers. If you cannot operate a server which serves renderable non-malicious web pages properly, what hope is there that you can do anything else right?
We are in the process of considering adding some new ports to this block list right now, and one big suggestion is SSDP. If you have any others you wish to suggest please send them to me and the guy on the cc line (Nirmal Mody).
On 2/26/16, 9:31 AM, "NANOG on behalf of Keith Medcalf" <nanog- bounces@nanog.org on behalf of kmedcalf@dessus.com> wrote:
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.
On Feb 26, 2016, at 8:55 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
On Fri, 26 Feb 2016, Nick Hilliard wrote:
Traffic from dns-spoofing attacks generally has src port = 53 and dst
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Maxwell Cole Sent: Friday, 26 February, 2016 07:19 To: Mikael Abrahamsson Cc: NANOG list Subject: Re: Thank you, Comcast. 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 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.
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.
-- Mikael Abrahamsson email: swmike@swm.pp.se
So we have people saying that blocking residential users from hosting DNS servers is not really providing Internet service. Now we have people saying it isn't service if it doesn't (more or less) completely work in lynx. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Keith Medcalf" <kmedcalf@dessus.com> To: "NANOG list" <nanog@nanog.org> Sent: Friday, February 26, 2016 6:59:28 PM Subject: RE: Thank you, Comcast. The default configuration of IE (all versions), Firefox (all versions), Edge (all versions) and Chrome (all versions) is a zero-security configuration. Of course it works fine in a zero-security configuration -- I said that from the get go. It does not work if you do not permit javascript to run unless approved, and do not permit unapproved (and unapprovable scripts from third-party sites of unknown provenance) to run. It does not work if you block cross-site access to widgets and crap coming from third-parties of equally unknown provenance. I do not know what it is looking for, but it cannot do that, so therefore it does not work. You may not care about how insecure your browser is -- I do.
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Naslund, Steve Sent: Friday, 26 February, 2016 10:11 To: NANOG list Subject: RE: Thank you, Comcast.
Also worked fine in IE 11 and Firefox. I didn't change any particular security settings either. Might want to check your stuff before you rant on someone's web site.
Steven Naslund Chicago IL
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Mike Hammett Sent: Friday, February 26, 2016 10:01 AM To: NANOG list Subject: Re: Thank you, Comcast.
Works fine on a default Chrome installation. *shrugs*
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
----- Original Message -----
From: "Keith Medcalf" <kmedcalf@dessus.com> To: "NANOG list" <nanog@nanog.org> Cc: "Nirmal Mody" <Nirmal_Mody@cable.comcast.com> Sent: Friday, February 26, 2016 9:55:20 AM Subject: RE: Thank you, Comcast.
On Friday, 26 February, 2016 08:13, Jason_Livingood@comcast.com said:
FWIW, Comcast's list of blocked ports is at http://customer.xfinity.com/help-and-support/internet/list-of-blocked- ports/. The suspensions this week are in direct response to reported abuse from amplification attacks, which we obviously take very seriously.
God is that a horrid web page. I cannot view it. The wheels on the bus go round and round non-stop.
It has so much intertwined malicious javascript, cross-site scripting, and malicious trackers that the alarm klaxons go off when I attempt to access it. I spent a couple of minutes attempting to access the page but still maintaining blocks to the malicious links. Apparently, viewing the page requires that all security be turned off and that the viewer allows completely untrusted code from completely untrustworty sources to run unabated on the viewers computer.
I do not permit this. For anyone. Ever.
This pretty much ensures that I would never be one of your customers. If you cannot operate a server which serves renderable non-malicious web pages properly, what hope is there that you can do anything else right?
We are in the process of considering adding some new ports to this block list right now, and one big suggestion is SSDP. If you have any others you wish to suggest please send them to me and the guy on the cc line (Nirmal Mody).
On 2/26/16, 9:31 AM, "NANOG on behalf of Keith Medcalf" <nanog- bounces@nanog.org on behalf of kmedcalf@dessus.com> wrote:
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.
On Feb 26, 2016, at 8:55 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
On Fri, 26 Feb 2016, Nick Hilliard wrote:
Traffic from dns-spoofing attacks generally has src port = 53 and dst
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Maxwell Cole Sent: Friday, 26 February, 2016 07:19 To: Mikael Abrahamsson Cc: NANOG list Subject: Re: Thank you, Comcast. 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 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.
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.
-- Mikael Abrahamsson email: swmike@swm.pp.se
Who said that? Of course, it is almost impossible to do anything malicious with lynx as the browser. Why you need to run scripts from google, adobe, and a myriad of other sources (including not less than 3 third party malvertizing sites, 6 tracking sites, and 2 miscellaneous known-malicious content sites is beyond me. It is downright disgusting that your page requires that such malicious sh*t be allowed free reign in order to view your web pages (which would be more properly known as infection pages). Of course, you might also be requiring Flash or some other dildo-ass plugin as well, all of which will not run because I do not permit them to run without permission (in fact, the blocking is so damn good that you will be unable to detect whether those facilities exist or not).
Now we have people saying it isn't service if it doesn't (more or less) completely work in lynx.
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
----- Original Message -----
From: "Keith Medcalf" <kmedcalf@dessus.com> To: "NANOG list" <nanog@nanog.org> Sent: Friday, February 26, 2016 6:59:28 PM Subject: RE: Thank you, Comcast.
The default configuration of IE (all versions), Firefox (all versions), Edge (all versions) and Chrome (all versions) is a zero-security configuration. Of course it works fine in a zero-security configuration -- I said that from the get go.
It does not work if you do not permit javascript to run unless approved, and do not permit unapproved (and unapprovable scripts from third-party sites of unknown provenance) to run. It does not work if you block cross- site access to widgets and crap coming from third-parties of equally unknown provenance.
I do not know what it is looking for, but it cannot do that, so therefore it does not work.
You may not care about how insecure your browser is -- I do.
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Naslund, Steve Sent: Friday, 26 February, 2016 10:11 To: NANOG list Subject: RE: Thank you, Comcast.
Also worked fine in IE 11 and Firefox. I didn't change any particular security settings either. Might want to check your stuff before you rant on someone's web site.
Steven Naslund Chicago IL
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Mike Hammett Sent: Friday, February 26, 2016 10:01 AM To: NANOG list Subject: Re: Thank you, Comcast.
Works fine on a default Chrome installation. *shrugs*
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
----- Original Message -----
From: "Keith Medcalf" <kmedcalf@dessus.com> To: "NANOG list" <nanog@nanog.org> Cc: "Nirmal Mody" <Nirmal_Mody@cable.comcast.com> Sent: Friday, February 26, 2016 9:55:20 AM Subject: RE: Thank you, Comcast.
On Friday, 26 February, 2016 08:13, Jason_Livingood@comcast.com said:
FWIW, Comcast's list of blocked ports is at http://customer.xfinity.com/help-and-support/internet/list-of-blocked- ports/. The suspensions this week are in direct response to reported abuse from amplification attacks, which we obviously take very seriously.
God is that a horrid web page. I cannot view it. The wheels on the bus go round and round non-stop.
It has so much intertwined malicious javascript, cross-site scripting, and malicious trackers that the alarm klaxons go off when I attempt to access it. I spent a couple of minutes attempting to access the page but still maintaining blocks to the malicious links. Apparently, viewing the page requires that all security be turned off and that the viewer allows completely untrusted code from completely untrustworty sources to run unabated on the viewers computer.
I do not permit this. For anyone. Ever.
This pretty much ensures that I would never be one of your customers. If you cannot operate a server which serves renderable non-malicious web pages properly, what hope is there that you can do anything else right?
We are in the process of considering adding some new ports to this block list right now, and one big suggestion is SSDP. If you have any others you wish to suggest please send them to me and the guy on the cc line (Nirmal Mody).
On 2/26/16, 9:31 AM, "NANOG on behalf of Keith Medcalf" <nanog- bounces@nanog.org on behalf of kmedcalf@dessus.com> wrote:
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.
On Feb 26, 2016, at 8:55 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
On Fri, 26 Feb 2016, Nick Hilliard wrote:
Traffic from dns-spoofing attacks generally has src port = 53 and dst
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Maxwell Cole Sent: Friday, 26 February, 2016 07:19 To: Mikael Abrahamsson Cc: NANOG list Subject: Re: Thank you, Comcast. 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 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.
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.
-- Mikael Abrahamsson email: swmike@swm.pp.se
On Fri, Feb 26, 2016 at 07:21:04PM -0600, Mike Hammett wrote:
So we have people saying that blocking residential users from hosting DNS servers is not really providing Internet service. Now we have people saying it isn't service if it doesn't (more or less) completely work in lynx.
Actually, nobody is saying that, but: there is zero reason why that page shouldn't work in a text-only browser like lynx or w3m. It conveys technical information of importance to current and prospective users of the service. It *should* comply with the ADA and other accessability standards, and one well-known baseline way to (at minimum) take a vague step in that direction is to ensure that it's reasable (and navigable) in a text-only browser. There's also zero reason why that page should require Javascript, plugins (especially obsolete and dangerous plugins like Flash), or why it should utilize advertising, trackers, and malicious third-party sites, or why it should be horribly bloated with useless junk. The problem here is not the people who choose to use browsers and browser configurations set for security and privacy. The problem is the jerks who published important information in a cesspool. ---rsk
I'm fairly certainly we'll never agree., so might as well end it now. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Rich Kulawiec" <rsk@gsp.org> To: nanog@nanog.org Sent: Saturday, February 27, 2016 7:07:04 AM Subject: Re: Thank you, Comcast. On Fri, Feb 26, 2016 at 07:21:04PM -0600, Mike Hammett wrote:
So we have people saying that blocking residential users from hosting DNS servers is not really providing Internet service. Now we have people saying it isn't service if it doesn't (more or less) completely work in lynx.
Actually, nobody is saying that, but: there is zero reason why that page shouldn't work in a text-only browser like lynx or w3m. It conveys technical information of importance to current and prospective users of the service. It *should* comply with the ADA and other accessability standards, and one well-known baseline way to (at minimum) take a vague step in that direction is to ensure that it's reasable (and navigable) in a text-only browser. There's also zero reason why that page should require Javascript, plugins (especially obsolete and dangerous plugins like Flash), or why it should utilize advertising, trackers, and malicious third-party sites, or why it should be horribly bloated with useless junk. The problem here is not the people who choose to use browsers and browser configurations set for security and privacy. The problem is the jerks who published important information in a cesspool. ---rsk
On Fri, Feb 26, 2016 at 08:55:20AM -0700, Keith Medcalf wrote:
On Friday, 26 February, 2016 08:13, Jason_Livingood@comcast.com said:
FWIW, Comcast's list of blocked ports is at http://customer.xfinity.com/help-and-support/internet/list-of-blocked- ports/. The suspensions this week are in direct response to reported abuse from amplification attacks, which we obviously take very seriously.
God is that a horrid web page. I cannot view it. The wheels on the bus go round and round non-stop.
Agreed -- it's completely dysfunctional worthless crap. I wonder if it occurred to anybody that a list of blocked ports could be published as a single static web page with no scripting, or better yet, as a text file so that it could be acquired with and used by scripts. ---rsk
On Fri, Feb 26, 2016 at 12:17:32PM -0500, Rich Kulawiec wrote:
On Fri, Feb 26, 2016 at 08:55:20AM -0700, Keith Medcalf wrote:
On Friday, 26 February, 2016 08:13, Jason_Livingood@comcast.com said:
http://customer.xfinity.com/help-and-support/internet/list-of-blocked- ports/
... I cannot view it. ...
Agreed -- it's completely dysfunctional worthless crap. I wonder if it occurred to anybody that a list of blocked ports could be published as a single static web page with no scripting, or better yet, as a text file so that it could be acquired with and used by scripts.
And also be made usable by the visually-impaired (section 508, e.g. http://webaim.org/standards/508/checklist). -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York
Livingood, Jason wrote on 2/26/2016 9:12 AM:
FWIW, Comcast's list of blocked ports is at http://customer.xfinity.com/help-and-support/internet/list-of-blocked-ports/. The suspensions this week are in direct response to reported abuse from amplification attacks, which we obviously take very seriously.
We are in the process of considering adding some new ports to this block list right now, and one big suggestion is SSDP. If you have any others you wish to suggest please send them to me and the guy on the cc line (Nirmal Mody).
Thanks! Jason
Jason, how do you propose to block SSDP without also blocking legitimate traffic as well (since SSDP uses a port > 1024 and is used as part of the ephemeral port range on some devices) ? Is the downside of blocking (admittedly a small amount of) legitimate user traffic worth the upside? And is this practice /Open Internet/ friendly? --Blake
On 26 Feb 2016, at 23:44, Blake Hudson wrote:
Jason, how do you propose to block SSDP without also blocking legitimate traffic as well (since SSDP uses a port > 1024 and is used as part of the ephemeral port range on some devices) ?
I'm not Jason, but blocking specific port-pairs such as UDP/80 ---> UDP/1900 and UDP/443 ---> UDP/1900 solves close to 90% of the problem, as UDP/80 and UDP/443 are the most common destination ports leveraged in this type of attack. For an explanation of how UDP reflection/amplification attacks work, see this .pdf preso: <https://app.box.com/s/r7an1moswtc7ce58f8gg> ----------------------------------- Roland Dobbins <rdobbins@arbor.net>
On 2/26/16, 11:44 AM, "Blake Hudson" <blake@ispn.net<mailto:blake@ispn.net>> wrote: Jason, how do you propose to block SSDP without also blocking legitimate traffic as well (since SSDP uses a port > 1024 and is used as part of the ephemeral port range on some devices) ? As Roland suggested, very likely via UDP/1900. This will obviously be disclosed in advance to customers and tested thoroughly. I believe a few other ISPs have already taken this step. And is this practice Open Internet friendly? Port blocking is considered a form of reasonable network management provided it can be justified by security or operational stability reasons. Of course it must also be transparently disclosed and so on. Jason
On 2/26/16, 11:44 AM, "Blake Hudson" <blake@ispn.net <mailto:blake@ispn.net>> wrote:
Jason, how do you propose to block SSDP without also blocking legitimate traffic as well (since SSDP uses a port > 1024 and is used as part of the ephemeral port range on some devices) ?
As Roland suggested, very likely via UDP/1900. This will obviously be disclosed in advance to customers and tested thoroughly. I believe a few other ISPs have already taken this step.
And is this practice /Open Internet/ friendly?
Port blocking is considered a form of reasonable network management provided it can be justified by security or operational stability reasons. Of course it must also be transparently disclosed and so on.
Jason The difference in blocking any of the existing ports on your list and blocking UDP/1900 is that the ports on your list are all registered
Livingood, Jason wrote on 2/26/2016 1:32 PM: ports. Port 1900 is not registered - a host may use port 1900 when making an outbound connection to another host (lookup ephemeral port range for more info) regardless of whether either host is using or running an SSDP server. A block on port 1900 will result in blocking legitimate customer traffic if the customer's device happened to select port 1900 as parts of its ephemeral port range. To my knowledge, a current Windows, Linux, Apple device will not use port 1900 as part of its ephemeral port range, but Wikipedia suggests XP and older Windows operating systems will and I know that many NAT routers will (which affects all clients behind that NAT router, regardless of their OS). I have no idea what popular mobile clients use for their ephemeral port ranges. I imagine the NAT routers will be most common actors using ports outside of the IANA suggested ephemeral port range. Do you suggest that it is "reasonable network management" that users behind a NAT router have their 876th (1900 - 1024) UDP connection attempt blocked? --Blake
Blake Hudson wrote on 2/26/2016 2:01 PM:
On 2/26/16, 11:44 AM, "Blake Hudson" <blake@ispn.net <mailto:blake@ispn.net>> wrote:
Jason, how do you propose to block SSDP without also blocking legitimate traffic as well (since SSDP uses a port > 1024 and is used as part of the ephemeral port range on some devices) ?
As Roland suggested, very likely via UDP/1900. This will obviously be disclosed in advance to customers and tested thoroughly. I believe a few other ISPs have already taken this step.
And is this practice /Open Internet/ friendly?
Port blocking is considered a form of reasonable network management provided it can be justified by security or operational stability reasons. Of course it must also be transparently disclosed and so on.
Jason The difference in blocking any of the existing ports on your list and blocking UDP/1900 is that the ports on your list are all registered
Livingood, Jason wrote on 2/26/2016 1:32 PM: ports. Port 1900 is not registered - a host may use port 1900 when making an outbound connection to another host (lookup ephemeral port range for more info) regardless of whether either host is using or running an SSDP server. A block on port 1900 will result in blocking legitimate customer traffic if the customer's device happened to select port 1900 as parts of its ephemeral port range.
To my knowledge, a current Windows, Linux, Apple device will not use port 1900 as part of its ephemeral port range, but Wikipedia suggests XP and older Windows operating systems will and I know that many NAT routers will (which affects all clients behind that NAT router, regardless of their OS). I have no idea what popular mobile clients use for their ephemeral port ranges. I imagine the NAT routers will be most common actors using ports outside of the IANA suggested ephemeral port range. Do you suggest that it is "reasonable network management" that users behind a NAT router have their 876th (1900 - 1024) UDP connection attempt blocked?
--Blake
Correction, I should have stated that the ports < 1024 were well-known. 1900 is not a well-known port
The difference in blocking any of the existing ports on your list and blocking UDP/1900 is that the ports on your list are all registered ports. Port 1900 is not registered -
IANA is under the impression it's registered for SSDP. Do you have some reason to believe they're mistaken? http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?&page=34
*yawn* I expected this from the news sites selling page views, not NANOG where people are supposed to actually know how things work. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Keith Medcalf" <kmedcalf@dessus.com> To: "NANOG list" <nanog@nanog.org> Sent: Friday, February 26, 2016 8:31:47 AM Subject: RE: Thank you, Comcast. 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.
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Maxwell Cole Sent: Friday, 26 February, 2016 07:19 To: Mikael Abrahamsson Cc: NANOG list Subject: Re: Thank you, Comcast.
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
On Feb 26, 2016, at 8:55 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
On Fri, 26 Feb 2016, Nick Hilliard wrote:
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.
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.
-- Mikael Abrahamsson email: swmike@swm.pp.se
On Feb 26, 2016, at 06:31, Keith Medcalf <kmedcalf@dessus.com> wrote:
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.
Absolutely. It’s funny that a group that worries about about net neutrality and whinges about T-Mobile’s zero-rating certain video sources is perfectly fine with blindly blocking *ports*, without even understanding if it’s legitimate traffic.
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)
This would be a big reason to point to a different DNS...
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.
Thats not really a fair comparison, I think a lot of people have issues with people censoring/controlling/prioritizing internet access to make money. Its a somewhat more nuanced conversation when you are talking about doing the same thing to prevent abuse. Cheers, Max
On Feb 26, 2016, at 10:32 AM, James Downs <egon@egon.cc> wrote:
On Feb 26, 2016, at 06:31, Keith Medcalf <kmedcalf@dessus.com> wrote:
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.
Absolutely. It’s funny that a group that worries about about net neutrality and whinges about T-Mobile’s zero-rating certain video sources is perfectly fine with blindly blocking *ports*, without even understanding if it’s legitimate traffic.
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)
This would be a big reason to point to a different DNS...
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.
Greetings, On Fri, 26 Feb 2016, Keith Medcalf wrote:
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.
I wholeheartedly agree! When purchasing an "Internet connection", we expect that to be full access to the Internet. Granted, *some* parts of the Internet are up/down or never available, but the *protocols* should *ALL* be available. Customers regularly use various VPN protocols from GRE, SIT, and IPIP, monitoring protocols such as SNMP, as well as RTP and SIP (where we spend the bulk of our time troubleshooting). Customers EXPECT their packets to be passed unhampered. Otherwise, all the provider is giving them is acces to email and to surf for porn. That provider would simply be offering an "entertainment" connection to the public Internet, not full Internet access. However, if a 'provider' wishes to block ANYTHING, then they need to inform the customer IN WRITING exactly what will be blocked so that customer doesn't waste their time and money with said (limited) service and vote with their wallet by buying *real* Internet service, elsewhere. --- Jay Nugent Nugent Telecommunications consulting Ypsilanti, Michigan
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Maxwell Cole Sent: Friday, 26 February, 2016 07:19 To: Mikael Abrahamsson Cc: NANOG list Subject: Re: Thank you, Comcast.
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
On Feb 26, 2016, at 8:55 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
On Fri, 26 Feb 2016, Nick Hilliard wrote:
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.
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.
-- Mikael Abrahamsson email: swmike@swm.pp.se
-- () ascii ribbon campaign in /\ support of plain text e-mail o Averaging at least 3 days of MTBWTF!?!?!? o The solution for long term Internet growth is IPv6. +------------------------------------------------------------------------+ | Jay Nugent jjn@nuge.com (734)484-5105 (734)649-0850/Cell | | Nugent Telecommunications [www.nuge.com] | | Internet Consulting/Linux SysAdmin/Engineering & Design | | ISP Monitoring [www.ispmonitor.org] ISP Performance Monitoring | +------------------------------------------------------------------------+ 10:01:01 up 6 days, 20:04, 2 users, load average: 0.40, 0.54, 0.43
On 26 Feb 2016, at 22:52, Jay Nugent wrote:
Customers regularly use various VPN protocols from GRE, SIT, and IPIP, monitoring protocols such as SNMP, as well as RTP and SIP (where we spend the bulk of our time troubleshooting).
Not so on consumer broadband access networks, which are what's being discussed in this thread. It's a different story for transit operators. ----------------------------------- Roland Dobbins <rdobbins@arbor.net>
Customers regularly use various VPN protocols from GRE, SIT, and IPIP, monitoring protocols such as SNMP, as well as RTP and SIP (where we spend the bulk of our time troubleshooting).
Not so on consumer broadband access networks, which are what's being discussed in this thread.
A certain number of us work from home and connect to headquarters with a VPN. and have SIP phones, you know. Not just meganerds. R's, John
On 27 Feb 2016, at 4:03, John Levine wrote:
A certain number of us work from home and connect to headquarters with a VPN. and have SIP phones, you know.
Not typically via/requiring the protocols you mentioned. ----------------------------------- Roland Dobbins <rdobbins@arbor.net>
Really? Consumer Narrowband Access Networks use these protocols all the time. (I call them narrowband since that is what they are -- even though the common euphamism is broadband, "broad" it certainly is not).
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Roland Dobbins Sent: Friday, 26 February, 2016 10:55 To: NANOG list Subject: Re: Thank you, Comcast.
On 26 Feb 2016, at 22:52, Jay Nugent wrote:
Customers regularly use various VPN protocols from GRE, SIT, and IPIP, monitoring protocols such as SNMP, as well as RTP and SIP (where we spend the bulk of our time troubleshooting).
Not so on consumer broadband access networks, which are what's being discussed in this thread.
It's a different story for transit operators.
----------------------------------- Roland Dobbins <rdobbins@arbor.net>
On 27 Feb 2016, at 8:06, Keith Medcalf wrote:
Consumer Narrowband Access Networks use these protocols all the time.
Most broadband access customers do not actively use these protocols, themselves, with the partial exception of SIP. ----------------------------------- Roland Dobbins <rdobbins@arbor.net>
On Fri, 26 Feb 2016 10:52:55 -0500, Jay Nugent said:
However, if a 'provider' wishes to block ANYTHING, then they need to inform the customer IN WRITING exactly what will be blocked so that customer doesn't waste their time and money with said (limited) service and vote with their wallet by buying *real* Internet service, elsewhere.
Which is only an option in those rare places where there's actual real competition. In most places, it's a monopoly, or a non-functional duopoly (Let's face it - how many users will protest a 10M cable connection with 4 ports punched out by moving to 768K DSL?)
I agree with this...from a customer perspective. I've seen ISPs block other traffic as well...even on "business" accounts, and break their customers networks. It's the Internet not a private network... I've never been a typical user though...maybe one of the "dozen" Mike refers to that runs a email server, web server, dns server, etc, etc, etc out of their house.
On Feb 26, 2016, at 9:31 AM, Keith Medcalf <kmedcalf@dessus.com> wrote:
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.
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Maxwell Cole Sent: Friday, 26 February, 2016 07:19 To: Mikael Abrahamsson Cc: NANOG list Subject: Re: Thank you, Comcast.
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
On Feb 26, 2016, at 8:55 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
On Fri, 26 Feb 2016, Nick Hilliard wrote:
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.
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.
-- Mikael Abrahamsson email: swmike@swm.pp.se
I don't have a problem with an ISP blocking certain things by default as long as they identify them like Comcast has done especially for consumer service. It would be nice if there was a way to opt out of the protection for the few people that need those services either through a web interface or a phone call. They might make the case though that certain services require a business class of service. Back in the 90s we used to block port 25 traffic for all customers unless they needed it opened because there were so many insecure mail systems out there. Sometimes you have to protect the clueless majority at the expense of a slight inconvenience for the geeks. So if you were smart enough to know that you need port 25 opened, we would do it. Most people did not know that it should be blocked most of the time so we protected them. Steven Naslund Chicago IL
I agree with this...from a customer perspective. I've seen ISPs block other traffic as well...even on "business" accounts, and break their customers networks.
It's the Internet not a private network...
I've never been a typical user though...maybe one of the "dozen" Mike refers to that runs a email server, web server, dns server, etc, etc, etc out of their house.
On Feb 26, 2016, at 9:31 AM, Keith Medcalf <kmedcalf@dessus.com> wrote:
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.
On 2/26/16 7:31 AM, Keith Medcalf wrote:
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.
Thumbs up to this one. I like how CenturyLink gives me the option of turning off port 25 blocking quickly if you know where to go, but it is on by default. I can live with blocks on by default, but easily be able to be turned off (if you are smart enough to know where to look to disable the options). Only thing I dislike is that they don't seem to remember it between service upgrades, and every time I bump my customer speeds I have to remember to go reset it or they can't send e-mail. :-) -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org
On Feb 26, 2016 8:34 AM, "Keith Medcalf" <kmedcalf@dessus.com> wrote:
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,
Traffic Shaping/Policing/Congestion policies, inbound and outbound
Some ISPs are good at this and provide opt-in/out methods for at least
etc) the first three on the list. Others not so much.
Every ISP I have felt with that messes with the DNS, has no valid opt-out other than using different DNS. The opt-out they use is a HTTP cookie, which only works for web browsers. It doesn't work for any other program.
Every ISP I have felt with that messes with the DNS, has no valid opt-out other than using different DNS. The opt-out they use is a HTTP cookie, which only works for web browsers. It doesn't work for any other program.
T-W and I am fairly sure Comcast have per-customer opt-out from DNS "enhancement". T-W's is at http://dnssearch.rr.com/prefs.php I still don't use their DNS caches, but that's not the reason. R's, John
On 2/26/16, 1:03 PM, "NANOG on behalf of John Levine" <nanog-bounces@nanog.org<mailto:nanog-bounces@nanog.org> on behalf of johnl@iecc.com<mailto:johnl@iecc.com>> wrote: T-W and I am fairly sure Comcast have per-customer opt-out from DNS "enhancement". T-W's is at http://dnssearch.rr.com/prefs.php I still don't use their DNS caches, but that's not the reason. Comcast stopped doing NXDOMAIN redirection on January 10, 2012, a little more than 4 years ago. We did so when we completed our DNSSEC deployment. The relevant announcements can be found at: http://corporate.comcast.com/comcast-voices/comcast-completes-dnssec-deploym... and http://corporate.comcast.com/comcast-voices/comcast-domain-helper-shuts-down Regards Jason / Comcast
In article <df93d62ef8e6cb4db2e0fd81f856cac1@mail.dessus.com> you write:
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.
Huh. Is it 1998 again? R's, John
I run my own resolver from behind my firewall at my home. I don't allow incoming port 53 traffic. I realize there's not a lot of privacy on the net, but I don't like having my dns queries tracked in order to target advertising at me and for annoying failed queries to end up at some annoying search page. On 2/26/2016 9:18 AM, Maxwell Cole wrote:
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
On Feb 26, 2016, at 8:55 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
On Fri, 26 Feb 2016, Nick Hilliard wrote:
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. 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.
-- Mikael Abrahamsson email: swmike@swm.pp.se
-- Best Regards Curtis Maurand Principal Xyonet Web Hosting mailto:cmaurand@xyonet.com http://www.xyonet.com
On Fri, Feb 26, 2016 at 11:04:49AM -0500, Curtis Maurand wrote:
I run my own resolver from behind my firewall at my home. I don't allow incoming port 53 traffic. I realize there's not a lot of privacy on the net, but I don't like having my dns queries tracked in order to target advertising at me and for annoying failed queries to end up at some annoying search page.
Likewise, and I don't like getting back forged DNS responses because some already-bloated ISP needs to tuck a few more dollars into their executives' paychecks. I've tested it fairly thoroughly in order to ensure that it can't be conscripted into an attack and do so again every time I make a firewall configuration change or a software upgrade. I've also started running local resolvers on portable systems in order to avoid the same set of problems when connecting to random networks. It often occurs to me that if the engineers of those networks invested the time that they spend corrupting DNS into preventing DNS-borne attacks that the entire Internet would be better off. ---rsk
On Fri, 26 Feb 2016 07:20:28 +0100 (CET) Mikael Abrahamsson <swmike@swm.pp.se> wrote:
I know historically there were resolvers that used UDP/53 as source port for queries, but is this the case nowadays?
Empirically from what I've observed, much less than there once was. Looking at a sample of a few thousand queries on a server set I can see, I don't need much more than what two hands can count. I still see the occasional ISP name server, probably having been around forever and perhaps locked in with the query-source option in BIND. You also see what is probably as a result of some local oddball policy, making something easier, such as the queries *.labs.rapid7.com (hi guys) like to issue for things like VERSION.BIND CH TXT. John
And you¹d be correct (about SSDP). ;-) - Jason (Comcast) On 2/25/16, 10:52 PM, "NANOG on behalf of Paras Jha" <nanog-bounces@nanog.org on behalf of paras@protrafsolutions.com> wrote:
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.
On Thu, Feb 25, 2016 at 10:46 PM, Mike Hammett <nanog@ics-il.net> wrote:
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.
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
On Thursday, February 25, 2016, Mike Hammett <nanog@ics-il.net> wrote:
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
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
participants (32)
-
Adam -
Anthony Junk -
Blake Hudson -
Brielle Bruns -
Ca By -
Chris Adams -
Curtis Maurand -
Damian Menscher -
David Bass -
Dovid Bender -
Henry Yen -
James Downs -
Jared Mauch -
Jay Nugent -
Jay R. Ashworth -
John Kristoff -
John Levine -
Keith Medcalf -
Livingood, Jason -
Mark Andrews -
Maxwell Cole -
Mikael Abrahamsson -
Mike Hammett -
Mikeal Clark -
Naslund, Steve -
Nick Hilliard -
Octavio Alvarez -
Paras Jha -
Philip Dorr -
Rich Kulawiec -
Roland Dobbins -
Valdis.Kletnieks＠vt.edu