AW: Firewall DMZ

From: Holger Reichert (holger.reichert@holysword.de)
Date: 08/30/02 

From: "Holger Reichert" <holger.reichert@holysword.de>
To: <security-basics@securityfocus.com>
Date: Fri, 30 Aug 2002 09:54:38 +0200

Hello Bryan,

here a few security guidelines for publishing data:

I suggest to place the database also in the DMZ, but it depends on the
information you have on it. First of all I do not know whether the data is
primarily for public information or not.
I suspect that you have a mix of private and public information on the
database and the webserver also. From a security standpoint you should
depart these informations.
Place all public information in a DMZ and the private in the LAN. If your
Webserver or Database gets conmpromised they only have the information which
just everybody is allowed to have.

Now to the rules:
1. Don't allow any connections be opend form the DMZ to your LAN.
        Because of the nature of the data and the architecture, there is no need to
pull information.
        So there is no need for the DMZ-Servers to know your internal
IP-Adress-Space, respectively if they are compromised there is no route to
your LAN.
        Everything gets blocked by the firewall.
        You can handle this with an extra deny rule. This gives you the oppertunity
to get secifically alerted if someone tries to connect your LAN through
your DMZ-Servers.
2. Only allow connections to be initiated from the LAN to the DMZ
        Push your update-information to the Database and the Webserver.

Now to your Mail Server. I suggest to place only a mail proxy with a
virus-scan-engine on it in the DMZ. Let him pass the mail traffic to your
real mailserver in the LAN.
This helps to hold the number of needed communication paths as few as
possible.
Every path is a way to be attacked. Fewer paths and less complex systems are
easilier defended.

Last, check your systems you place into the DMZ for vulnerabilities with a
scanner
like nessus or internet scanner from ISS or anything else(depends on
budget).
Look for OS-hardening and do not place a default installation system in a
DMZ, otherwise it gets compromised within a few days!!!

Hope this helps

Best wishes

Holger Reichert
business manager
Holysword GbR
www.holysword.de

-----Ursprüngliche Nachricht-----
Von: Daniel Miessler [mailto:danielrm26@hotmail.com]
Gesendet: Mittwoch, 28. August 2002 20:29
An: 'dts'; 'Bryan Brannigan'; security-basics@securityfocus.com
Betreff: RE: Firewall DMZ

> Would it not make more sense to place the database servers (unless for
> some reason they needed to talk to the main network) in a separate
> private segment of your internal network and not mixed in with the
rest
> of the internal network, just in case the Database server was owned?

I don't see what would be wrong with that; my main point is for the
webserver to be in the DMZ and the database to be on a protected network
that is ONLY accessed by ODBC. Further breaking down of your internal
network can be a good thing if you have the resources.

> Could you also us IPSEC (If this is a 2000 network) security from the
> Webserver to the Database server and tunnel the ODBC port through it.
> This would increase your encryption lvl between the servers and setup
> server to server authentication? This should also work for the mail
> server talking to a database...but then again this is based on a 2000
> network setup.

More security is always a good thing, but why do this if there is no one
able to sniff that traffic anyway. If the interaction between the
webserver and database is still functional (as it would of course have
to be) then any exploit that is going to while the communication is
un-encrypted is also going to run when it IS encrypted. I think if you
are on a private segment with no sniffer attacks possible then this will
be overkill. The webserver can decrypt the IPSEC anyway because it is
one of the communicating parties, and since it is going to be the source
of the attack on the database anyway, the encryption offers no
protection.

--danielrm26

Quantcast