[187793] in North American Network Operators' Group
RE: Thank you, Comcast.
daemon@ATHENA.MIT.EDU (Keith Medcalf)
Fri Feb 26 10:57:42 2016
X-Original-To: nanog@nanog.org
Date: Fri, 26 Feb 2016 08:55:20 -0700
In-Reply-To: <D2F5D3C1.129888%jason_livingood@cable.comcast.com>
From: "Keith Medcalf" <kmedcalf@dessus.com>
To: "NANOG list" <nanog@nanog.org>
Cc: "Mody, Nirmal" <Nirmal_Mody@cable.comcast.com>
Errors-To: nanog-bounces@nanog.org
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 abus=
e
> 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 i=
t. I spent a couple of minutes attempting to access the page but still mai=
ntaining blocks to the malicious links. Apparently, viewing the page requi=
res that all security be turned off and that the viewer allows completely u=
ntrusted code from completely untrustworty sources to run unabated on the v=
iewers computer.
I do not permit this. For anyone. Ever.
This pretty much ensures that I would never be one of your customers. If y=
ou 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 yo=
u
> 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 Interne=
t
> 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 =3D
> 53 and dst
> port =3D random. If you block packets with udp src port=3D53
> 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
>
>
>
>
>
>
