RE: Outbound Firewall Rules for a Web Server

From: Jared Valentine (hidden@xmission.com)
Date: 05/16/02


Date: Thu, 16 May 2002 14:32:05 -0600 (MDT)
From: Jared Valentine <hidden@xmission.com>
To: Robert Buel <rbuel@solubility.com>

3Com has an Embedded Firewall on a PCI card that can be used to secure individual machines (including webservers). The PCI card can restrict inbound/outbound traffic such that the machine in question could be a webserver, but is unable to initiate connections back out into the network.

http://www.3com.com/security/efw_info.html

It's a good product for hardening a server (making sure it only uses approved ports, protocols, directions, etc.) as well as desktop PCs.

Jared Valentine
Network Security Consultant
3Com Corporation
jared_valentine@3com.com

On Wed, 15 May 2002, Robert Buel wrote:

> Is the Web server located on your internal private network (LAN)? I
> believe that it is a very bad idea to locate a web server on your
> internal LAN. If the box is rooted, then they have full access to your
> data and internal operations. If it is in a DMZ, then that is fine...
> Definitely secure outbound ports. Stephen was right on...
>
> Bob
>
> -----Original Message-----
> From: Stephen Kemler [mailto:stk5@po.cwru.edu]
> Sent: Tuesday, May 14, 2002 1:55 PM
> To: Craig Brauckmiller; security-basics@securityfocus.com
> Subject: Re: Outbound Firewall Rules for a Web Server
>
> > I have our IIS 5 server sitting on a private network with
> > an IP of 10.2.32.20. It is being NAT'd via CheckPoint NG.
> > I only allow HTTP traffic in to the web server but I allow
> > the server unrestricted access out from the network.
> >
> > 1. Is this a good idea?
> >
> > 2. Should I lock down the web server's outbound ports to
> > prevent Nimda/CodeRed type infections from propigating from
> > my server?
>
> You should definately lock down your outbound traffic for all systems,
> especially systems that accessible from outside the network. Consider a
> very simple example: An attacker compromises your IIS server, installs
> an
> SSH client, and then uses your compromised host to launch further
> attacks.
> The idea here is to minimize damage. If you system is compromised, you
> have
> problems to deal with. If your system is compromised, and used to
> launch a
> further attack, you could have law enforcement agents to deal with.
>
> > 3. What ports should I allow the server to go out on if any?
>
> What do you use your Webserver for? If it is used strictly for serving
> HTTP, then you should not have to allow much. Although you could
> probably
> get away with allowing no outbound traffic, you will probably want to be
> able to resolve names in your logs, so probably DNS. Have any pages
> that
> generate emails? Then you will need to open SMTP. Also keep in mind
> that
> you can restrict where the outbound traffic goes -- so even if you
> decide to
> open up DNS, you could specify only to your DNS server.
>
> If you really want to determine what you have to open, close everything,
> and
> see what stops working, or who complains. Otherwise, set up a snifffer
> for
> a couple of days to determine that same information with less
> disruption.
>
> Hope this helps,
> Steve
>
>