nanog mailing list archives

RE: Thank you, Comcast.


From: "Keith Medcalf" <kmedcalf () dessus com>
Date: Fri, 26 Feb 2016 18:43:17 -0700

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.


-----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



















Current thread: