dave.goldsmithat_private 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 -- ************************************** cbrentonat_private $ 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
This archive was generated by hypermail 2b30 : Wed Aug 01 2001 - 14:25:49 PDT