Re: Possible method to prevent spread of CodeRed and other similar worms

[Chris Brenton <cbrenton () altenet com>]

dave.goldsmith () intelsat com wrote:
> Is there normally any reason for a web server to initiate OUTBOUND
> connections to the Internet?  If not, why not block such outbound packets?

<shameless plug>
This is exactly what I preach in my security course. :)
</shameless plug>

Most of us have some form of DMZ/service network which contain publicly
accessible systems. If you look at the connectivity needs of each
(commentary is in reference to the direction of connection
establishment):

DNS server = Inbound UDP/53, possibly TCP/53. Outbound UDP/53 and
TCP/53. 

Mail server = Outbound TCP/25. Inbound TCP/25. 
Possibly inbound and outbound TCP/113 if Auth is used)

Web server = Inbound TCP/80. Possible inbound TCP/443.

Obviously some environments may vary a bit from this. For example my
systems create additional connections for syslog and NTP but this is to
only specific IP addresses. You may also need to support inbound SSH
(TCP/22) for management.

So given the above known types of acceptable connectivity, what if your
Web server starts generating outbound TCP/80, TCP/21 and/or TCP/22
sessions? This is a pretty good indication that the box has been
whacked. Not only should you block this traffic, but IMHO it should set
off every alarm you have so the reason for the traffic can be addressed
ASAP.

> If an IIS (or any other) web server were to become infected with a worm that
> then tried to spread, that system would be blocked from sending out viral
> traffic.

Agreed. By implementing the above you:
1) Get a heads up that the box has been whacked
2) Stop your system from attacking other systems

In the case of a manual compromise, you may even prevent the purp from
yanking down a rootkit which keeps the amount of damage actually caused
by the intrusion at a recoverable level.

HTH,
Chris
-- 
**************************************
cbrenton () altenet com

$ chown -R us:us yourbase

----------------------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management 
and tracking system please see: http://aris.securityfocus.com