DMZ design
in [Firewalls]
|
From: sc_wizard29 on 29 Nov 2005 10:27 Hi everyone, I would like to install a web-server on a DMZ. This web-server will access a database hosted on the private network. In a book called "The Practice of Network Security", the 2 following DMZ design are suggested : Design #1 (private network and DMZ connected to same FW) : internet -> FW -> private network | +--> DMZ Design #2 (2 FW) : internet -> FW -> DMZ -> FW -> private network. The author says that "The most notable problem with design #1 is that there is no way to securely update information on the servers. There are also no facilities in place to secure the database transactions between the web server and the database server, or any of the backend servers". I'm afraid I don't understand what the author means... if I use design #1 and if the FW is correctly configured, what can prevent me from securing the database transactions ? Thanks for helping...
From: Ansgar -59cobalt- Wiechers on 29 Nov 2005 11:14 sc_wizard29(a)hotmail.com wrote: > I would like to install a web-server on a DMZ. This web-server will > access a database hosted on the private network. In a book called "The > Practice of Network Security", the 2 following DMZ design are > suggested : > > Design #1 (private network and DMZ connected to same FW) : > > internet -> FW -> private network > | > +--> DMZ > > Design #2 (2 FW) : > > internet -> FW -> DMZ -> FW -> private network. > > The author says that "The most notable problem with design #1 is that > there is no way to securely update information on the servers. There > are also no facilities in place to secure the database transactions > between the web server and the database server, or any of the backend > servers". The mere network topology doesn't support this opinion in any possible way. > I'm afraid I don't understand what the author means... if I use design > #1 and if the FW is correctly configured, what can prevent me from > securing the database transactions ? You don't want *any* host in the DMZ to be able to establish connections into your private network, since that would break the DMZ. Put the backend servers into the DMZ (or a separate second DMZ). Replicate (push!) the relevant data from your backend servers to servers in the DMZ. But *never* *ever* allow connections from the DMZ to the internal network. cu 59cobalt -- "Another option [for defragmentation] is to back up your important files, erase the hard disk, then reinstall Mac OS X and your backed up files." --http://docs.info.apple.com/article.html?artnum=25668
From: DigitalVinyl on 29 Nov 2005 13:49 Ansgar -59cobalt- Wiechers <usenet-2005(a)planetcobalt.net> wrote: >sc_wizard29(a)hotmail.com wrote: >> I would like to install a web-server on a DMZ. This web-server will >> access a database hosted on the private network. In a book called "The >> Practice of Network Security", the 2 following DMZ design are >> suggested : >> >> Design #1 (private network and DMZ connected to same FW) : >> >> internet -> FW -> private network >> | >> +--> DMZ >> >> Design #2 (2 FW) : >> >> internet -> FW -> DMZ -> FW -> private network. >> >> The author says that "The most notable problem with design #1 is that >> there is no way to securely update information on the servers. There >> are also no facilities in place to secure the database transactions >> between the web server and the database server, or any of the backend >> servers". > >The mere network topology doesn't support this opinion in any possible >way. > >> I'm afraid I don't understand what the author means... if I use design >> #1 and if the FW is correctly configured, what can prevent me from >> securing the database transactions ? > >You don't want *any* host in the DMZ to be able to establish connections >into your private network, since that would break the DMZ. Put the >backend servers into the DMZ (or a separate second DMZ). Replicate >(push!) the relevant data from your backend servers to servers in the >DMZ. But *never* *ever* allow connections from the DMZ to the internal >network. In reality this is next to impossible in any real world scenario. What this would mean is near 100% of your servers would be DMZ'd. If you put SMTP servers in the DMZ they MUST reach in and deliver mail to exchange/notes. DMZ these and you open more problems then you solve because RPC uses 10s of thousands of high ports as service ports. >cu >59cobalt
From: DigitalVinyl on 29 Nov 2005 13:53 Leythos <void(a)nowhere.lan> wrote: >In article <3v3d40F13iu6tU2(a)individual.net>, usenet-2005 >@planetcobalt.net says... >> sc_wizard29(a)hotmail.com wrote: >> > I would like to install a web-server on a DMZ. This web-server will >> > access a database hosted on the private network. In a book called "The >> > Practice of Network Security", the 2 following DMZ design are >> > suggested : >> > >> > Design #1 (private network and DMZ connected to same FW) : >> > >> > internet -> FW -> private network >> > | >> > +--> DMZ >> > >> > Design #2 (2 FW) : >> > >> > internet -> FW -> DMZ -> FW -> private network. >> > >> > The author says that "The most notable problem with design #1 is that >> > there is no way to securely update information on the servers. There >> > are also no facilities in place to secure the database transactions >> > between the web server and the database server, or any of the backend >> > servers". >> >> The mere network topology doesn't support this opinion in any possible >> way. >> >> > I'm afraid I don't understand what the author means... if I use design >> > #1 and if the FW is correctly configured, what can prevent me from >> > securing the database transactions ? >> >> You don't want *any* host in the DMZ to be able to establish connections >> into your private network, since that would break the DMZ. Put the >> backend servers into the DMZ (or a separate second DMZ). Replicate >> (push!) the relevant data from your backend servers to servers in the >> DMZ. But *never* *ever* allow connections from the DMZ to the internal >> network. > >The never allow the DMZ to reach the LAN doesn't work in the real world >for Web/Database applications. In the case of a web server with a >database backend, you don't want the DB in the DMZ, you want the DB in >the DMZ. What you setup in the firewall is what makes the difference. In >these cases you allow (for MSSQL) DMZ:IP:1433 to LAN:DB IP:1433 but only >for that port and only those two IP. You don't do Windows >authentication, only SQL User authentication (and you don't use SA). This is what makes sense. What you *never* want to do is open administrative ports(RPC, RDP, telnet, SSH, X-windows) inward. Insecure servers should never have an opportunity to administrate more secure servers. This can be difficult to get across to programmers and operators who will not consider security when deciding where to build scripts and jobs to run. You want to design communication so secure servers reach INTO the DMZ as much as possible. FTP Get on a secure server to pull files, not FTP Put from the insecure one. >There are other instances, where you create a rule that allows Nodes in >the LAN to reach the Mail server in the DMZ (exchange in this example), >but the rule also permits the mail server to reach the Nodes, BUT only >if the nodes contact the exchange server first. A FE/BE design for >exchange would be better. > >We've used both design #1 and design #2 and I like to have the firewall >appliance setup with the LAN on jack 1 in a subnet like 10.4.0.0/16 and >the DMZ in a subnet on jack 2 like 192.168.4.0/24. The jacks are not >connected like the cheap NAT routers, they require rules to map between >them.
From: DigitalVinyl on 29 Nov 2005 14:02
sc_wizard29(a)hotmail.com wrote: >Hi everyone, I would like to install a web-server on a DMZ. This >web-server will access a database hosted on the private network. >In a book called "The Practice of Network Security", the 2 following >DMZ design are suggested : > >Design #1 (private network and DMZ connected to same FW) : > >internet -> FW -> private network > | > +--> DMZ > >Design #2 (2 FW) : > >internet -> FW -> DMZ -> FW -> private network. > >The author says that "The most notable problem with design #1 is that >there is no way to securely update information on the servers. There >are also no facilities in place to secure the database transactions >between the web server and the database server, or any of the backend >servers". > >I'm afraid I don't understand what the author means... if I use design >#1 and if the FW is correctly configured, what can prevent me from >securing the database transactions ? > >Thanks for helping... The difference between these two is that there are two physically different firewalls. And really that is the ONLY practical difference. You would setup all the same rules. In design #2 if the first FW is compromised, by that I mean the hacker has admin control over the firewall, the second FW is intact. You would write all the rules in the same ways, and you would still have to open the same ports through the firewall for Web->DB connectivity. The second advantage to 2 firewalls is administrative complexity. Writing rules can be easier when you don't have a lot of interfaces especially if you divide functional traffic across different boxes. -------OUTSIDE------ | | FW1 DMZ3--FW2--DMZ4 | | --------INISDE------ In the above example you can divide rules up across the two firewall. General Internet access can be handled by FW1, while FW2 focuses on DMZ related access only. People can easily create INSIDE->ANY rules that mistakenly give access to DMZs when the Internet rules mix in. Ifind it easier to screw up rules on the PIX, especially if you try to use their GUI. Checkpoint had better tools for avoiding those kinds of mistakes. |