Re: MALICIOUS Witty worm -- port block recommendations

[Gary Flynn <flynngn () JMU EDU>]

Doug Pearson wrote:

> A method to slow down infection is through blocking of source port UDP 4000 inbound and outbound at your border and within 
> your network if possible. Blocking source UDP 4000 can cause hit-and-miss problems due to its use as an ephemeral port for 
> DNS and other services. It's possible these services will recover through a retry to the next ephemeral.
You can minimize or eliminate problems like that if you have Cisco
routers by using reflexive ACLs. They are session aware.

So, for example, you make a rule to permit incoming traffic to one of
your system's port 4000 only if that system initiated traffic from port
4000 to the outside host on the same port. For example, for a DNS
lookup to an outside server.

Example:

Outbound ACL:
permit udp yournetwork any eq 4000 reflect reflexive-list
 (tells the router to save prot/src/dst/srcport/dstport information
  in a temporary "reflexive-list" on any outgoing sessions from
  UDP port 4000 for later matching to inbound traffic)

Inbound ACL:
 evaluate reflexive-list
   (tells the router to allow in any traffic that is the reverse of
    the criteria saved in the reflexive-list by the outgoing request)
 deny udp any eq 4000 yournetwork
   (tells the router to block "unsolicited" traffic from port 4000)

The entries will stay in the temporary tables for 300 seconds
by default for UDP since, unlike TCP, UDP is stateless and
a timer is the only thing available to build state around. You can
set the timer to anything you like.

You can intermix other ACEs around the reflexive ACEs for
versatility and they will be processed normally and in normal
order. You can have different reflexive ACEs for different
protocols. You may be able to have multiple reflexive ACEs
for different ports. I  haven't tested it for functionality yet. It
doesn't complain when I load the configuration and it seems
to be working judging solely by the contents of the temporary
list. For example, if you already implemented reflexive ACLs
in an attempt to block MS Messenger exploits, you may be able
to add a second reflexive ACE with the same protocol but
different port ranges:

Outbound ACL:
 permit udp yournetwork range 1024 1040 any reflect reflexive-list
 permit udp yournetwork any eq 4000 reflect reflexive-list

Inbound ACL:
 evaluate reflexive-list
 deny udp any eq 4000 yournetwork
 deny udp any yournetwork range 1024 1050

You can see the temporary entries created by doing a "sh access-list".
They will show up at the bottom of the listing.

I've been running reflexive lists here since xmas break for fear someone
would figure out how to exploit the Messenger service overflow defect
(MS03-043) directly rather than going through the port mapper. It stops
the direct Messenger spam too. I didn't notice a big increase in CPU
utilization and nobody has reported problems. We're running 7200's on
full 45Mbps links with hundreds of ACEs. I'm troubleshooting a problem
with the Halo game but I think its something else at this point. (Sometimes
the idea of securing a corporate network, as opposed to an "educational"
one, seems rather attractive even though, perhaps, mundane. :)

Cisco docs:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/secur_c/scprt3/screflex.htm

Any applications that use ports different than the original request pair
will
be troublesome but I haven't run into any yet.

That takes care of the inbound problem. You can do the same with an
outbound list or you can monitor Snort and shut down internal, infected
systems as they're found. Or, if you have an inline IDP, you can create a
signature for the traffic (one has been published for Snort), and tell the
IDP to drop the packets and send you a message if it is from one of your
systems.. ;)

Out of curiosity, does anyone know if any of the IDP vendors provide a
signature for the defect before the worm was released?

Gary Flynn
Security Engineer
James Madison University

**********
Participation and subscription information for this EDUCAUSE Discussion Group discussion list can be found at 
http://www.educause.edu/cg/.