Is it a good idea to only allows connections to be established in the LAN->DMZ direction?

Question

I'm trying to setup the usual thing, with a DMZ containing servers that can be accessed from the internet, and a LAN that should be as secure as possible.

I happen to also have total freedom on the architecture. Given that I want to make my LAN area as secure as possible, I though to myself "What can be better than not being able to access the LAN from the DMZ". To do so, I would configure the firewall to block any incoming connection in the DMZ->LAN direction.

Of course, I still need my front-end applications to in the DMZ to contact the trusted LAN servers. In order to make this possible, I was thinking of only allowing connections to be established in the LAN->DMZ direction.

This means that in a reversal of the usual situation, it is my trusted LAN services that would connect to the untrusted DMZ front-end servers. Once the TCP connection is established, all requests and responses between the two endpoints would be multiplexed on that connection.

Is that a good idea in terms of security? Is there anything else I could do to make my LAN servers even harder to reach? Have you heard of somebody else already securing their LAN this way? Is something eluding me that just makes this a stupid idea?

Answer 1

OK, minimising connections between the DMZ and the LAN is a good rule of thumb though I wouldn't become a slave to this idea (if you have on-site email servers then your email service will be interesting to say the least if you force it to abide by your idea).

Also, don't think this is a magical hacking defence. If someone compromises a server in the DMZ then there's a potential still there for them to penetrate your network depending on how the servers in the DMZ are configured (e.g. having the LAN-side open connections between an LAN-side SQL database and a DMZ-side web server does little to help you if the web server has been rooted and credentials for accessing the SQL server are stored on the DMZ server.

Also, if the information you're using/storing is valuable in its own right and it can still be stolen by someone who has rooted the server in the DMZ then again, what you propose won't help much.

Answer 2

As with all security related questions, the answer is "it depends". It depends on the type of company you are, the type of services you run, how hardened your Internet facing services are, the data you are in custody of, what legislation you have to adhere to, Etc., Etc.

Short answer - minimise the "attack surface" by limiting the addresses/ports between your DMZ and trusted network. If possible, deploy technologies that use a reverse-proxy type arrangement, so that initiation of a conversation from DMZ->Trust isn't possible. Of course, this isn't always going to be possible. Consider having an intermediary firewalled zone containing a "Internet only" databases. Finally, make sure you limit the ports/addresses from Trust->DMZ as well. A lot of malware makes use of reverse-proxy style connections (but in the opposite direction), that is, they rely on an inbound connection to break out in to the source network.

The problem with this sort of question, is that you'll get different answers from pretty much everyone, and it's your job to pick what's best for you. Additional security inevitably makes day-to-day operations more awkward, and over-complicated security configurations quite often fall foul of configuration errors, leaving holes that go unnoticed.

Security is all about layers of defence, and no solution, no matter what people tell you is 100% secure. What ever you decide to do, consider getting it pen-tested before going live, and make sure you keep the DMZ services patched. Finally, review your configuration at least once a year.

Answer 3

Well you already pretty much list one of the issues with this setup, it is TCP only. Not only that but a session can be faked with relative ease from inside the DMZ. The ideal ideal solution to me sounds like treating the trusted LAN just like a regular user, send them out of your network and back again.