I generally have a VPN on a server which 'phone's home' to a heavily hardened vpn concentrator attached to a DMZ/jumphost -> internal networks. If(when) the server get's b0rked, you can simply regen a new cert, invalidate the old one and away you go.

I've done this with DRAC/ILO's using a small openwrt box connected to the ILO to do the vpn smarts (this also gives you a backup channel via cellular if you need it).

-Joel




On 10 December 2013 10:21, Christoph Berthoud <christoph@zeebob.co.nz> wrote:
Thanks all for the on and off-list replies.

I came to the same conclusion DNAT wasn't a favoured option.��

In my case, we are serving up the dreaded 'custom written app' on ASP.NET so I am 100% working on the assumption it will be compromised at some point.��

I'm now working on following method - it might be a bit OTT:

INTERNET ---- EXTERNAL FIREWALL ---- (PUBLIC IP) WEB SERVER (DMZ IP) ---- INTERNAL FIREWALL ---- LAN

- The web server's default route is to the internet
- The web servers only other route is the connected DMZ interface
- The external firewall only allows HTTP/HTTPS inbound, nothing outbound, so malware can't call home (easily anyway)
- The internal firewall only allows communication from the LAN to the DMZ (NAT'd also so I don't have to add the internal subnet to the DMZ servers route tables)


On Tue, Dec 10, 2013 at 8:22 AM, Lloyd Parkes <lloyd@must-have-coffee.gen.nz> wrote:

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.

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 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



--
Thanks
Christoph

_______________________________________________
NZNOG mailing list
NZNOG@list.waikato.ac.nz
http://list.waikato.ac.nz/mailman/listinfo/nznog