nanog mailing list archives
Re: Thank you, Comcast.
From: Mike Hammett <nanog () ics-il net>
Date: Fri, 26 Feb 2016 10:00:43 -0600 (CST)
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. -----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, MaxOn 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 shouldbe 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 smallstep 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 arenot easy to make.-- Mikael Abrahamsson email: swmike () swm pp se
Current thread:
- Re: Thank you, Comcast., (continued)
- Re: Thank you, Comcast. Damian Menscher via NANOG (Feb 26)
- Re: Thank you, Comcast. Roland Dobbins (Feb 26)
- Re: Thank you, Comcast. Dovid Bender (Feb 26)
- Re: Thank you, Comcast. Jared Mauch (Feb 26)
- Re: Thank you, Comcast. Damian Menscher via NANOG (Feb 26)
- Re: Thank you, Comcast. Dovid Bender (Feb 26)
- Re[2]: Thank you, Comcast. Adam (Feb 26)
- RE: Thank you, Comcast. Keith Medcalf (Feb 26)
- Re: Thank you, Comcast. Livingood, Jason (Feb 26)
- RE: Thank you, Comcast. Keith Medcalf (Feb 26)
- Re: Thank you, Comcast. Mike Hammett (Feb 26)
- RE: Thank you, Comcast. Naslund, Steve (Feb 26)
- RE: Thank you, Comcast. Keith Medcalf (Feb 26)
- Re: Thank you, Comcast. Mike Hammett (Feb 26)
- RE: Thank you, Comcast. Keith Medcalf (Feb 26)
- Re: Thank you, Comcast. Rich Kulawiec (Feb 27)
- Re: Thank you, Comcast. Mike Hammett (Feb 27)
- Re: Thank you, Comcast. Rich Kulawiec (Feb 26)
- Re: Thank you, Comcast. Henry Yen (Feb 26)
- Re: Thank you, Comcast. Blake Hudson (Feb 26)
- Re: Thank you, Comcast. Roland Dobbins (Feb 26)