[170517] in North American Network Operators' Group
Re: Access Lists for Subscriber facing ports?
daemon@ATHENA.MIT.EDU (Blake Hudson)
Fri Mar 28 14:49:22 2014
Date: Fri, 28 Mar 2014 13:48:43 -0500
From: Blake Hudson <blake@ispn.net>
To: nanog@nanog.org
In-Reply-To: <CACTmXQWiJEamp5h_UCfi=yd8ZW1-VsNCc=n-E+59wWMrEAm=Wg@mail.gmail.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Shawn L wrote the following on 3/27/2014 7:44 AM:
> With all of the new worms / denial of service / exploits, etc. that are
> coming out, I'm wondering what others are using for access-lists on
> residential subscriber-facing ports.
>
> We've always taken the stance of 'allow unless there is a compelling reason
> not to', but with everything that is coming out lately, I'm not sure that's
> the correct position any more.
>
> thanks
By default on all devices and customers we enforce BCP 38 as close to
the subscriber as possible (as well as any other L2/L3 abuse mitigation
techniques that the equipment supports well), and possibly again at the
network border.
On residential accounts we only consider blocking TCP/UDP ports < 1024
and even then that typically means blocking just SMB (135-139, 445).
With SMB blocking becoming a largely irrelevent need given the move to
more secure Windows versions, OS firewalls, and firewall enabled CPEs.
In the context of an ISP, I very strongly believe in a policy of
non-blocking and neutrality. If there's an issue with telco provided CPE
that is running services accessible via the WAN (DNS, Telnet, etc),
that's an issue best addressed at the CPE level, although temproary ACLs
could be applied upstream. If a customer is running their own vulnerable
equipment, we may try to notify him or her, but if it does not impact
service to other subscribers then we won't go through too many hoops to
educate them.
--Blake
