BCP for ISP to block worms at PEs and NAS
Hello, Can someone confirm if my approach explained below is sufficient and if there is other/better ways to do this ? something i am missing. On my Cisco-based SP network with RPMs in MGX chassis acting as PEs: I have the ACL below applied on many network devices to block the common worms ports, On the NAS, i have placed the worm on the Group-Async interfaces so the worms will not propagate between user who dial up on the same NAS, and on the uplink ethernet interface.(in and out) On the PEs, i have placed it on the interface switches for the customers and on the uplink too, and then on the aggregating routers and on the gateway for all these. ip access-list extended worms deny tcp any any eq 5554 deny tcp any any range 135 139 deny udp any any range 135 netbios-ss deny tcp any any eq 445 deny udp any any eq 1026 permit ip any any Regards
On 4/17/05, Kim Onnel <karim.adel@gmail.com> wrote:
Can someone confirm if my approach explained below is sufficient and if there is other/better ways to do this ? something i am missing.
blocking netbios and 2..3 other ports is one way to go. however, what you need is fast detection and nullrouting / walled garden setup for infected machines on your LAN Joe St.Sauver's presentation at http://darkwing.uoregon.edu/~joe/zombies.pdf should help -- Suresh Ramasubramanian (ops.lists@gmail.com)
On my Cisco-based SP network with RPMs in MGX chassis acting as PEs: I have the ACL below applied on many network devices to block the common worms ports,
if you are a service provider, perhaps filtering in the core will not be appreciated by some customers. of course, as a provider, you can choose what 'service' you are providing. but, if you filter ports, it is not clear you are providing internet service. randy
On Sun, 17 Apr 2005, Randy Bush wrote:
On my Cisco-based SP network with RPMs in MGX chassis acting as PEs: I have the ACL below applied on many network devices to block the common worms ports,
if you are a service provider, perhaps filtering in the core will not be appreciated by some customers. of course, as a provider, you can choose what 'service' you are providing. but, if you filter ports, it is not clear you are providing internet service.
one approach might be radius installed filters? some contract language to allow 'customers' to request standard templated filters at little/no-extra cost to them. Allow them to make the decision to filter themselves (where 'themselves' may be a dial reseller, of course). Making them responsible means when odd-application-12 comes along to utilize tcp/135 you won't have to poke spot holes through your filters to permit this access.
On my Cisco-based SP network with RPMs in MGX chassis acting as PEs: I have the ACL below applied on many network devices to block the common worms ports, if you are a service provider, perhaps filtering in the core will not be appreciated by some customers. of course, as a provider, you can choose what 'service' you are providing. but, if you filter ports, it is not clear you are providing internet service. one approach might be radius installed filters? some contract language to allow 'customers' to request standard templated filters at little/no-extra cost to them. Allow them to make the decision to filter themselves (where 'themselves' may be a dial reseller, of course). Making them responsible means when odd-application-12 comes along to utilize tcp/135 you won't have to poke spot holes through your filters to permit this access.
yep. but note that kim says "ACL below applied on many network devices," and went on to mention ras, which i, possibly mistakenly, took to mean not just the radius-able edge. randy
On Sun, 17 Apr 2005, Randy Bush wrote:
On my Cisco-based SP network with RPMs in MGX chassis acting as PEs: I have the ACL below applied on many network devices to block the common worms ports, if you are a service provider, perhaps filtering in the core will not be appreciated by some customers. of course, as a provider, you can choose what 'service' you are providing. but, if you filter ports, it is not clear you are providing internet service. one approach might be radius installed filters? some contract language to allow 'customers' to request standard templated filters at little/no-extra cost to them. Allow them to make the decision to filter themselves (where 'themselves' may be a dial reseller, of course). Making them responsible means when odd-application-12 comes along to utilize tcp/135 you won't have to poke spot holes through your filters to permit this access.
yep. but note that kim says "ACL below applied on many network devices," and went on to mention ras, which i, possibly mistakenly, took to mean not just the radius-able edge.
whoops, I read his original note as: "i have a large dial/dsl plant for a network and I want to offer filtered Internet" So I lept to: "wow, use radius applied acls for your users, let them choose to have it or not, make standard templates available." If there is no need to filter 'all links' just 'customer links' (and 'customer links' == dial/dsl/radius-authed-connection-types) then the radius filters thing might be a boone to Kim's productivity.
On Sun, 17 Apr 2005, Christopher L. Morrow wrote:
one approach might be radius installed filters? some contract language to allow 'customers' to request standard templated filters at little/no-extra cost to them. Allow them to make the decision to filter themselves (where 'themselves' may be a dial reseller, of course). Making them responsible means when odd-application-12 comes along to utilize tcp/135 you won't have to poke spot holes through your filters to permit this access.
Microsoft (the company that cares about security) has already done that for you by implementing RPC-over-HTTP complete with the same vulnerabilities as RPC-over-135. The sad thing is the number of computers using RPC/Netbios outnumbers the number of computers using SSH. Most former @Home cable providers have blocked various rpc/netbios (network neighborhood) ports for years because people used to be able to see their neighbor's computers in the Windows rpc/netbios browser. You probably want to be a bit careful, because some people use remote Exchange/Outlook which uses RPC. Ephemeral ports can be used by anything, although in practice they are not randomly distributed. Programmers are humans, and they tend to have favorites and those favorites are exploited by attackers. If we lived in a perfect world, everything would be perfect. But we live in a world were 300 million computers do stupid things and Microsoft sells over 10 million new Windows licenses a month. On the other hand, the number of people who actually want to use RPC over the Internet is a very small number. Is it more practical for the few people who want to use RPC over the Internet to make special arrangements; or to keep millions of computers at risk? A few other comments. Port 136 is not used by Microsoft. Port 5554 is probably too specific to a single worm, which is on the decline.
On 04/17/05, Randy Bush <randy@psg.com> wrote:
On my Cisco-based SP network with RPMs in MGX chassis acting as PEs: I have the ACL below applied on many network devices to block the common worms ports,
if you are a service provider, perhaps filtering in the core will not be appreciated by some customers. of course, as a provider, you can choose what 'service' you are providing. but, if you filter ports, it is not clear you are providing internet service.
In practice, it is nearly certain that your users won't care (or even notice) -- but grumpygeeks will argue about it anyway. -- J.D. Falk As a carpenter bends the seat of a chariot <jdfalk@cybernothing.org> I bend this frenzy round my heart.
Even if they care, its consuming alot of CPU resources and bandwidth, i had a long quarrel with my teams members on should we do it or not, i understand that if we only provide best effort traffic without any filtering contracted its wrong to do it, but the ACL matches are so big, doing it on the Radius however is one nice other way to do it IMHO, there was once a worm using port 5000 which broke IPSec, and i had to modify it all over the place, same with MSSQL ports, a Centralised configuration is much better, i would like to see these methods documented anywhere (Practices for ISPs to block worms) On 4/17/05, J.D. Falk <jdfalk@cybernothing.org> wrote:
On 04/17/05, Randy Bush <randy@psg.com> wrote:
On my Cisco-based SP network with RPMs in MGX chassis acting as PEs: I have the ACL below applied on many network devices to block the common worms ports,
if you are a service provider, perhaps filtering in the core will not be appreciated by some customers. of course, as a provider, you can choose what 'service' you are providing. but, if you filter ports, it is not clear you are providing internet service.
In practice, it is nearly certain that your users won't care (or even notice) -- but grumpygeeks will argue about it anyway.
-- J.D. Falk As a carpenter bends the seat of a chariot <jdfalk@cybernothing.org> I bend this frenzy round my heart.
On Sun, 17 Apr 2005, J.D. Falk wrote:
On 04/17/05, Randy Bush <randy@psg.com> wrote:
On my Cisco-based SP network with RPMs in MGX chassis acting as PEs: I have the ACL below applied on many network devices to block the common worms ports,
if you are a service provider, perhaps filtering in the core will not be appreciated by some customers. of course, as a provider, you can choose what 'service' you are providing. but, if you filter ports, it is not clear you are providing internet service.
In practice, it is nearly certain that your users won't care (or even notice) -- but grumpygeeks will argue about it anyway.
interesting... everytime we have filtered in the core we've gotten complaints, I believe many folks filtered/rate-limited in their cores for welchia/nachia and got bunches of complaints about it as well... Hrm, maybe all of these folks are just grumpy-geeks?
interesting... everytime we have filtered in the core we've gotten complaints, I believe many folks filtered/rate-limited in their cores for welchia/nachia and got bunches of complaints about it as well... Hrm, maybe all of these folks are just grumpy-geeks?
i suspect that the remaining small dial-up and other local consumer providers have customer bases who just want their mtv. larger isps and big backbone isps have customer bases with wider usage patterns, and hence become quite unhappy when all they can get is mtv and 500 channels of home shopping. and the customers of the former who don't like partial service, have enough clue to quickly migrate to the latter. celebrate diversity (aka i wish all my competitors did that:-) randy
On Sun, 17 Apr 2005, Randy Bush wrote:
celebrate diversity (aka i wish all my competitors did that:-)
What did people think would happen if they try to hold third-parties liable for the actions of others? Third-parties have very little interest in defending your diversity. And if the FCC starts extending multi-million dollar fines from television to cable and Internet, you'll find very few providers you can migrate quickly, or otherwise, too. Look at the US Federal EnergyStar program. It is nearly impossible to buy a PC which doesn't comply with EnergyStar requirements, and even Microsoft was forced to change Windows default settings to comply. If there was a SecurityStar logo, would PC makers and providers have to comply with it?
On Sun, 17 Apr 2005 13:28:21 +0200 Kim Onnel <karim.adel@gmail.com> wrote:
I have the ACL below applied on many network devices to block the common worms ports,
Beware, you are guaranteed to be blocking other, legitimate things too with some of these rules. More below.
ip access-list extended worms deny tcp any any eq 5554
Whatever worm you're trying to mitigate above (sasser?), you will also be occasionally be taking out TCP sessions that happen to be using that port. Most commonly where one side uses 5554 as it's ephemeral port.
deny tcp any any range 135 139 deny udp any any range 135 netbios-ss deny tcp any any eq 445 deny udp any any eq 1026
Similar as before, you are going to be removing some legitimate traffic. With UDP ephemeral ports this may most likely be DNS and NTP traffic. Note, many people do what you do all the time to the detriment of both real security and robustness in my opinion, but it's your net and you can throw away random packets if you want to. Perhaps set the rules to permit and log first, let it run for awhile and then see what you'll be missing. John
On 04/17/05, John Kristoff <jtk@northwestern.edu> wrote:
deny tcp any any range 135 139 deny udp any any range 135 netbios-ss deny tcp any any eq 445 deny udp any any eq 1026
Similar as before, you are going to be removing some legitimate traffic.
Is this really true? All of the ports listed above are used by LAN protocols that were never intended to communicate directly across backbone networks -- that's why VPNs were invented. Or, is your argument that some system somewhere MIGHT ignore the offical port numbers allocated by IANA and try to pass some other kind of traffic there instead?
Perhaps set the rules to permit and log first, let it run for awhile and then see what you'll be missing.
Yep, this is always good advice. But don't give up just because of some naysayers rolling out the usual FUD. In the real world, security for the many outweighs the extremely unlikely edge cases of the few. -- J.D. Falk As a carpenter bends the seat of a chariot <jdfalk@cybernothing.org> I bend this frenzy round my heart.
In message <20050417200030.GG1174@arctic.org>, "J.D. Falk" writes:
On 04/17/05, John Kristoff <jtk@northwestern.edu> wrote:
deny tcp any any range 135 139 deny udp any any range 135 netbios-ss deny tcp any any eq 445 deny udp any any eq 1026
Similar as before, you are going to be removing some legitimate traffic.
Is this really true? All of the ports listed above are used by LAN protocols that were never intended to communicate directly across backbone networks -- that's why VPNs were invented.
Or, is your argument that some system somewhere MIGHT ignore the offical port numbers allocated by IANA and try to pass some other kind of traffic there instead?
The issue is client-side port numbers -- those aren't rules that block only inbound SYNs. That was clear from another paragraph of Kristoff's post: Whatever worm you're trying to mitigate above (sasser?), you will also be occasionally be taking out TCP sessions that happen to be using that port. Most commonly where one side uses 5554 as it's ephemeral port. The result will be intermittent, undiagnosed failures. "Why isn't that Internet reliable? I do the same thing twice in a row and the second time it fails." --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb
On Sun, 17 Apr 2005 13:00:30 -0700 "J.D. Falk" <jdfalk@cybernothing.org> wrote:
deny udp any any eq 1026
Similar as before, you are going to be removing some legitimate traffic.
Is this really true? All of the ports listed above are used by LAN protocols that were never intended to communicate directly across backbone networks -- that's why VPNs were invented.
I was speaking to the last UDP rule as shown above, but a port number is becoming increasingly more ambiguous as applications adapt when specific ports are filtered. There is also the idea of a 'port switching' process. Find an archived copy of draft-shepard-tcp-reassign-port-number for an example. Or even consider how TFTP works (port 69 is only in use for the initial packet to the TFTP server). Such a process actually has two 'good' properties, that are often add odds in many deployments. One is to foster transparency back into the network and the other is to improve resiliency from attackers attempting to insert spoofed packets into the communications. John
On Sun, 17 Apr 2005, J.D. Falk wrote:
On 04/17/05, John Kristoff <jtk@northwestern.edu> wrote:
deny tcp any any range 135 139 deny udp any any range 135 netbios-ss deny tcp any any eq 445 deny udp any any eq 1026
Similar as before, you are going to be removing some legitimate traffic.
Is this really true? All of the ports listed above are used by LAN protocols that were never intended to communicate directly across backbone networks -- that's why VPNs were invented.
and people use them all the time across the real Internet :( It's dumb, we can argue about it's 'correctness' or 'localness' or whatever until we are blue in the face, but people still do it.
Or, is your argument that some system somewhere MIGHT ignore the offical port numbers allocated by IANA and try to pass some other kind of traffic there instead?
Certainly, ssh over tcp/80 is common, other protocols can become agile as well... people SHOULD use the IANA port numbers, in practice they don't always abide by them :(
Perhaps set the rules to permit and log first, let it run for awhile and then see what you'll be missing.
Yep, this is always good advice. But don't give up just because of some naysayers rolling out the usual FUD. In the real world, security for the many outweighs the extremely unlikely edge cases of the few.
Or... use a system where your users can 'subscribe' to a 'better Internet' (define 'better Internet' as you like)
participants (8)
-
Christopher L. Morrow -
J.D. Falk -
John Kristoff -
Kim Onnel -
Randy Bush -
Sean Donelan -
Steven M. Bellovin -
Suresh Ramasubramanian