AW: Secure those servers

From: Stefan Osterlitz (
Date: 08/10/01

From: "Stefan Osterlitz" <>
To: <>
Subject: AW: Secure those servers
Date: Fri, 10 Aug 2001 11:36:31 +0200
Message-ID: <>

> I think first of that
> we need to put
> the web servers behind a firewall allowing only port 80 to
> pass (here is
> where it gets foggy for me) then another firewall with open
> ports needed for
> the web servers to talk to the other servers, which ports I
> am not sure of
> yet. Should the web servers be multi homed? Where to use
> public IP’s and
> where not to? Should a domain model be used?

Maybe you should read in on the matter first:

The NSA has published papers on securing Win2K servers:

For IIS webservers, is a good resource, too.

Next, you should plan your implementation:

"Best practice" is to use a frontend/backend architecture:



internet-----firewall------internal net/backends

the outer firewall should be configured to let through port 80 to the cache.
nothing else.
The cache should communicate only with the web servers, via some internal
port (say 8080).
The webservers should communicate with the backends only when necessary.
If your database is used only for the webservers, put it into the dmz, too.
Otherwise put it into the internal net.

Personally, I prefer to push files and databases from the backends to the
dmz at regular intervals via ssh/scp/sftp.
This allows me to maintain a "known good" copy of the important data on
secure systems.
Additionally, i can block any connection from the dmz into the internal net.

It is important to set up a good IDS (Intrusion Detection System) on the
outer firewall.
Log any spoofed packets, any packets off port 80, packets off the cache's
ips, etc.
Try snort as IDS ( The Hogwash module might be interesting
for you, too.
you can use it to filter things like "code red" attacks and malformed urls.

Question to all: does anyone know of a good (url checking) protocol checker?
I am looking for a solution to block standard "buffer overrun" requests from
It should get "too/many/slashes/in/this/path//////" attacks as well as
"256times\x" requests, and things like that.
In 90% of cases, unicode expansion is not necessary for me.

Stefan Osterlitz