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
As a residential ISP, we have seen quite a lot of this in terms of both compromised customer computers spewing spam and ddos, as well as compromised customer routers participating in ddos attacks as well as dns redirection exploits for phishing and other purposes. I too am an advocate of staying out of the way as much as possible, but I've come around to realize that the average customer NEEDS to be protected against the consequences of their ignorance, MORE than they need the freedom to run a publicly accessible dns or ntp server. We now have a default access list in place which locks down subscriber ports and prevents them from being a server on commonly exploited services like dns,ntp,smtp and so forth. The average customer neither knows nor cares, and suffers absolutely nothing because of it. What tipped it over for me was a rash of dns changers that exploited unknown to us default credentials in a number of subscriber modems, causing no end of customers who secretly depended on a set of DNS resolvers controlled by attackers that were performing poorly and resulting in 'why is it slow?' calls to my support staff. These devices should never have internet facing management, but they do and they did. I should also say that the acl's are also easily removable for any customer who asks. We don't make a big production out of it or anything, we just put the flag on their account and thats that.
Mike-
two think that are simple, enforce bcp38 and ntp packet sizes
rndy
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