That���s true, but not true for a couple of reasons. Firstly, the options don���t specify where the firewalls are, so you can have as many firewalls as you like with all three options. Secondly, the argument that a server can get hacked is a slippery slope argument that logically leads to placing hardware firewalls between every single host because once a host is hacked, any adjacent hosts are now vulnerable according to that argument. The next thing to remember is that firewalls don���t stop your hosts from getting broken into. That must be the case if you are assuming that your web servers (which are behind firewalls) are going to be broken in to. Of course, what you have described is also correct, because it���s current best practice. It is a balance between cost and risk mitigation and like all balances, you get to adjust it until it feels right for you.
On 9/12/2013, at 8:57 pm, Jean-Francois Pirus <jfp@clearfield.co.nz> wrote:
> Never do 1 or 3. When you server gets hacked (which is what you should aways assume) then your internal lan also get hacked bypassing your internal firewall.
> You need a firewall in front of your server, which you are doing and another firewall between the server and your internal network, no bypassing of any sort.
> So you get 2 internal networks, DMZ and Internal.
On top of that, Christoph wants to know how to assign addresses to his web servers, which isn���t affected by any firewall placement. I have deployed option 1 in the past (with two layers of firewalls behind it rather than the one that Jean-Francois recommends ;-) and it has worked well. If you have public IP addresses then use them, not only because that���ll set you up well for IPv6, but also because network reporting can get a bit interesting when you have NAT.
Cheers,
Lloyd
_______________________________________________
NZNOG mailing list
NZNOG@list.waikato.ac.nz
http://list.waikato.ac.nz/mailman/listinfo/nznog