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: 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.
From: DigitalVinyl on 29 Nov 2005 14:58 Ansgar -59cobalt- Wiechers <usenet-2005(a)planetcobalt.net> wrote: >DigitalVinyl wrote: >> Ansgar -59cobalt- Wiechers <usenet-2005(a)planetcobalt.net> wrote: >>> 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. > >Wrong. Go into any decent sized enterprise and you will not find that all inbound traffic from the DMZ is blocked. That's what that says. Your ruleset set is ONE simple line a DENY SRC:ALL-DMZ-NETS DST:INSIDE ANY. In a small company with almost no servers that could be possible largely because you don't do much. But once your shop starting developing apps and you have dozens of DMZ servers that concept is not enforceable. Politically you won't win. I wonder if the financial world manages to maintain that standard. Where SMTP, DNS, NTP, and every other protocol is restructured to only permit pushes into the DMZ. >> What this would mean is near 100% of your servers would be DMZ'd. > >Yeah. So? So one comprimised server in the DMZ could lead to a hundred. It could increase the layer 2 security requiremnt in the DMZ to be administratively painful. The rule I use is if the Internet must reach in and touch the server it should be in a DMZ. Everything else should be further in. This is a fairly safe thing, since the DMZ must protects your company from IT'S OWN SERVERS. This is sometimes forgotten. The Firewall is protecting your inside network from compromised DMZ servers. Load your DMZs up with non-internet servers and you've reduced all your security to that of an internet-accessible server. DB & servers which hold financial and legal information should be reviewed if there is a legal obligation to up the protectio even further (FW'ing the DB from the Inside network as well). >> If you put SMTP servers in the DMZ they MUST reach in and deliver mail >> to exchange/notes. > >No. It can easily be *pulled* from the SMTP server and fed to Exchange. >Outbound mail is sent through a smarthost. BTDT. Don't know about Notes, >though. I've never heard of that setup. But you'd have to do the same with every protocol and transfer in existence. You can't use internal NTP servers, or SMTP gateways, or DNS, or printservers, or sysloggers, or FTP servers. It all has to be reversed or you need to establish all those services within the DMZ. >> DMZ these and you open more problems then you solve because RPC uses >> 10s of thousands of high ports as service ports. > >There's no need to DMZ them. The exchange team here insists that OWA (the web-access server for Exchange) must be in the same network as Exhcnage and domain controller. It's likely that it is total hogwash but it sets up a common political problem. The network/security group is pitted against other departments trying to reasearch/prove/discredit what tehy say is true to justify that the above guidelines are adhered to. That's where this stuff falls apart over time. The human element makes it impossible. >cu >59cobalt
|
Next
|
Last
Pages: 1 2 3 Prev: REQ: Sonicwall SOHO3 Firmware Next: Firewall port 1105 (FTRANHC) & port 1239 (NMSD) ? |