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 ?
The mere network topology doesn't support this opinion in any possible way.
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).
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.
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.
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.
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.
It does work in the real world, though many people seem to be reluctant to do it right, because the other way is so much easier. In fact I pointed out two ways how to make it work.
[...]
LAN nodes connecting to a server in the DMZ don't break the DMZ. A DMZ does not mean to prohibit any traffic between LAN and DMZ, it just means that no connections can be initiated *from* DMZ *to* LAN. That's what stateful filtering is for.
It's possible to have setups like that.
Both setups are more or less equivalent. Having two firewalls gives a little more protection to your LAN (because the inner firewall, running a different system on different hardware, isn't vulnerable to the same exploits as the outer firewall), but adds some more complexity, because you need to maintain two different systems. A three-way setup is a little easier to maintain (and thus probably a little less prone to configuration glitches), but if an attacker manages to compromise the firewall he has access to either DMZ and LAN.
However, you still don't want any server in the DMZ to be able to initiate connections to hosts inside tha LAN.
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.
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.
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).
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.
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.
Again, it's not going to hold in a web to database design. You should never put the database server in the DMZ and you would never put the web server in the LAN - so, you punch a IP:PORT hole through the DMZ>LAN for
1433 between the exact two IP, and then your web app can access the MSSQL Server in the protected LAN. Port 1433 isn't going to allow access to Enterprise manager, and as long as your DB Server is patched, then allowing 1433 from the DMZ to LAN vial IP:PORT>IP:PORT won't compromise the network.
Our exchange installs, many of them with many large clients, don't have the Exchange server sitting/connected to the LAN Domain, in fact, there is no DOMAIN Authentication with the Exchange servers. User accounts are createded in the Exchange DOMAIN (as stand alone domain), passwords are GIVEN to the employees, and access is setup for them. The Exchange server IS NOT part of the company LAN or domains. If you have a FE/BE setup you can change that, but we do a lot of single Exchange server setups for medical groups with 300+ accounts and have been able to maintain a single Server in the DMZ for ages.
The firewall is setup to only allow the Exchange server to "respond" to requests from the LAN - and users can OWA or Outlook via exchange connector, etc....
With this method, although it means more overhead in maintenance and setup, we've never had a compromised client/server/node.
No. It's probably what you wanted to say, but not what you did say. And not what I am talking about at all.
No, my ruleset isn't necessarily that simple, though this is the basic rule.
Of course it is.
That's a completely different story. Of course you can't enforce this without being backed by management. And guess what: sometimes you actually get this backup.
There is no need to "restructure" Protocols. You "just" need to choose the right protocols and the right topology. Yes, it's not always as simple as it looks.
Wrong, because you are by no means limited to a single DMZ. Neither must each DMZ be accessible from each other DMZ or even from the Internet.
This is exactly what I was saying, and why connections from DMZ to LAN should not be allowed. Why do we argue about this, then?
Nope. There is no law forcing me to make a DMZ accessible from the Internet. Think of something like this (single firewall setup to keep the example simple):
Internet | DMZ_1 -- Firewall -- DMZ_2 | LAN
DMZ_1 holds the webserver, DMZ_2 holds the DB server. The following connections are allowed (plus established traffic, of course):
Internet -> DMZ_1 (e.g. only on port 80) DMZ_1 -> DMZ_2 (e.g. only on the DB server port) LAN -> Internet LAN -> DMZ_1 LAN -> DMZ_2
Now tell me: where exactly did I reduce all my security here?
DB & servers which hold financial and legal information should be put into separate networks with no access whatsoever to the Internet.
What the hell are you talking about? Of course I can do all of that. I can use internal NTP server which get (pull!) their time from NTP servers outside my network. I just described how an SMTP gateway would be set up. I can have internal DNS servers for my LAN and forwarders to resolve external addresses. I don't need print servers outside of my LAN (much less print servers that are accessible from anywhere outside my LAN). I don't need one central log host if I need to compromise my network security for that. And of course I can have FTP servers for anything I want. Though I usually don't want them.
I have never had such a setup myself and I haven't used Echange in a while, so I am in no position to prove them wrong, though I would guess there had to be better ways to OWA other than allowing access to the internal network.
True. But I wasn't discussing political issues here. I was talking about the technical aspects and feasibility of DMZ setups. And especially in the OPs case I don't see any real problem.
Please tell me: why would I punch a hole into the firewall protecting my LAN rather than putting a DB server into a (separate) DMZ and opening that hole only between the two DMZs? Or (if the requirements allow this) do put a DB server into the DMZ, and have the "real" DB server in the LAN from where only the required subset is pushed to the DMZ-DB?
No, I don't think I'm going to do this.
And with one of the setups I described above, my network wouldn't be compromised even *if* the webserver got compromised *and* there was an unpatched vulnerability in the DBMS *and* an attacker had a 0-day. Defense in depth.
The only problem I see with putting a critical DB in a DMZ off the Internet-edge firewall is that it is now on the doorstep of the internet. If the firewall is comprimised you've lost the DB already. Further in, you can have a critical DB behind a second firewall or implement acl control. Also combining DMZs on one firewall is common, but can result in rule confusion and unintended opening of access.
Other than that you can do exactly that. However it is common for DB to interact with multiple backend servers and applications, not to mention admin/desktops. Rather than open one rule WEB->DBport, you now have to open many more to allow all the different internal servers to access the DMZ-DB or possbily in the reverse direction--although I imagine you wouldn't allow any such thing. And think about that... you may be placing a DB in a less-secure DMZ than INSIDE. In a PIX all inside hosts would have access to the DB by default. The DB would be consider an insecure network by definition. Typically the DB is considered the most secure element so the DB would run batch jobs and reach out to other servers. This is a common structure. However, if it had to reach out to an Internal server that wouldn't be permitted, because the DMZ-DB is less secure.
If you're going to do real-time replication between a LAN DB and a Second DMZ DB and expect it to be any different than a DMZ Web to the LAN DB via only PORT 1433, then you're mistaken.
Fine, don't, I didn't ask you to change anything anywhere.
Wrong - If the database server in DMZ2 is compromised by a 0-Day exploit, and you've setup replication between the DMZ1 DB server, so that you have real-time information available, then the same 0-Day exploit will reach through and compromise that server too.
You can put the DB server and th DB App server in separate DMZ's though, and apply IPS to the in-band traffic to filter out attacks for the few ports and protocols you have to allow in and out of each zone -- an IPS is going to update faster than Microsoft patches.
That would depend on the router/firewall topology. You may very well use two or three firewalls in this setup, avoiding the risk you mentioned at the cost of somewhat increased complexity, e.g. like this:
Internet -- Firewall -- DMZ_1 -- Firewall -- LAN | Firewall | DMZ_2
True. But who said maintaining security in complex scenarios was easy?
If that's necessary, I think the whole application and DB design should seriously be re-considered. It is very likely to be flawed.
Unless being forced to allow it.
No. DMZ and DB are just as secure as the LAN in the scenario proposed by Leythos. Only in my scenario the security of my LAN is *not* reduced.
Wrong approach. You're looking at the hardware first and then consider what security you can achieve with that hardware. I try to work out what security I need first and then consider what hardware it would take to implement this. I'll admit that in the real world you'll have to cut back sometimes, but you should *never* restrict yourself from the beginning. That's simply the wrong approach to security.
No. Simply because replication and web application use different mechanisms to access the server. Besides, I didn't say anything about real-time replication.
No, you didn't, but lets take an online ordering system, or a project management system or anything else that doesn't use a Static DB, and then you either punch a hole or setup replication, so you're back to having a security issue that you have to deal with one way or another.
Data lives in DMZ1. Only connection to it is an administrative interface like RDP, from the trust zone, and some sort of file transfer method like sftp, both initiated from particular trusted, hardened hosts.
Server lives in DMZ 2. Only connection to DMZ1 is SQL. Only connection to outside is via incoming http. No connection to trust.
Hacker must compromise web server first using only inline in-line port 80, and then inject an in-line SQL compromise to the DB server in DMZ1, which in fact has no outbound policies to anywhere, and therefore can only reply to SQL sessions initiated from that web server.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.