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
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
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
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
In practice, it is nearly certain that your users won't care (or
even notice) -- but grumpygeeks will argue about it anyway.
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)
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
> 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.
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
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.
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?
> > 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)
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.
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
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?