[arin-ppml] IPv6 Non-connected networks

[Owen DeLong]

On Mar 24, 2010, at 8:50 AM, Chris Engel wrote:

> Owen DeLong wrote:
> 
>> Why on earth is your web server on the same network as your
>> internal hosts to begin with? Machines which do not belong in
>> the same security zone shouldn't be on the same network any
>> more than a box which is not a security boundary device
>> should have interfaces in multiple security zones.
>> 
>> Ideally, you would also want a different firewall either
>> between the DMZ and your internal network or between the
>> external network and your internal network so that this can not occur.
> 
> Owen this is largely irrelevent. Most commercial grade firewalls come with multiple interfaces  so that you can setup different security zones off the same physical device. Saves the cost and labor of maintaining 15 different physical devices when you can simply have one or two. Many firewalls are written where you can have rules that span multiple interfaces or that apply across all interfaces. Furthermore alot of small to medium size Enterprises are going to have some mixing of devices in zones. It's not ideal but people do operate under resource constraints. Alot of Enterprises are going to go with simply a mail server.... rather then one that acts as a mailbox store and access for internal mail.... another that's used to exchange SMTP with other mail servers... another that provides Webmail (i.e. a Webserver) for mobile users.... another to provide synching services for Blackberries and mobile phones, etc.

On such a firewall, you would want software which specifies valid entry/exit interface combinations in addition to IP addresses which would also
preclude the error you describe since the DMZ would be on a different interface than the internal network. So, again, NAT still doesn't actually
do anything that you can't accomplish with good software and topology without NAT.

Furhtermore, your alleged "mail server" should live in the DMZ, like the web server.  The server should be reachable for IMAP/SMTP from inside. It should also be reachable for SMTP and possibly IMAP from outside. It should NOT have physical interfaces on the internal and external networks which would allow it to act as a router bypassing your firewall. In such a topology, there is, again, no gain from NAT.

> Even in cases where you do have a strict seperation of devices into zones.... that seperation though valuable isn't as strong a security measure as most assume. Since often those external facing devices are going to need SOME connectivity to internal resources (i.e. a Webmail server is going to need to connect to the information store that holds the mailbox data) and thus can be used as a proxy to attack into the private zone. This is just the way things tend to work in real world scenerios.
> 
Arguably the information store belongs in the DMZ rather than the inside, but, even if that is the case, NAT won't help you there.

My point wasn't that this separation is absolute security. My point was that in a properly structured network, NAT doesn't improve security.

Even if the webmail server is a proxy for attacking the internal mailstore, NAT won't prevent that attack. It won't even make it more difficult.

> All this is beside the point however. The point is that at your network bounderies you ARE going to deploy firewalls and those firewalls are going to have rules to filter traffic that passes across thier boundary. If those rules are misconfigured, ANY device that is advertised on the firewalls external interface becomes vulnerable. Regardless of the segmentation of zones that happens behind it, chances are that ANY edge firewall is going to be getting both INBOUND and OUTBOUND traffic on it's EXTERNAL interface.... unless you use different ISP's for INBOUND and OUTBOUND which is a pretty bizzare arrangement that I haven't personaly heard of anyone doing before. Yet even then you ARE going to be getting INBOUND traffic on that interface....even if it's all traffic that you don't want and ALL it takes is one misconfiguration of a rule that breaks the DENY ALL IN default rule you've setup.
> 
This is true.  However, the point is that the addition or subtraction of NAT from the equation does not improve or reduce security if you have good firewall software and a well designed topology.
> 
>> How is the firewall administrator less likely to misconfigure
>> the address mapping than the rule? Perhaps I'm confused, but,
>> I would think that one mistake would not preclude the other.
> 
> He's not and one mistake does not preclude the other. The point is under this scenerio he has to make 2 mistakes (the address mapping and the filtering rule) rather then just one. That's the whole point behind the Defense in Depth approach. Putting in controls that require multiple mistakes to happen (the more the better) in order for damage to actualy be done.
> 
Not really... With good firewall software, he already needs to make two mistakes (misconfigure IP and exit interface), so, bungling the address map becomes a third mistake.  While I'll agree anyone is likely to make one mistake, I'll argue that the guy who makes both of the earlier mistakes is pretty likely to make the third as well.
> 
>> Well, the default permit scenario you described is far more
>> of a security issue than the lack of NAT. Why would anyone
>> configure their firewall that way?
> 
> The scenerio I posited didn't require a "default permit" situation. In fact it would work just the same with a DENY ALL IN & DENY ALL OUT (the most secure default setting...other then unplugging the network cable). The point is that in all firewall configs you poke holes in those default settings to allow the traffic that needs to get through. The Admin makes a mistake and allows a much broader hole then intended. It's not hard to do if the Admin isn't paying attention. Lets say for example both those default DENY rules are in place. The Admin is configuring a firewall through a GUI (most have them these days) and he intends to create a rule that allows all workstations to ALLOW HTTP OUT (so they can browse the web). If he accidently clicks the checkbox IN/OUT instead... he's just exposed them (if they have public addresses) and probably doesn't even know about it...since they have the access they need. If they don't have public addresses...they still aren't exposed.
> 
If the checkbox is IN/OUT rather than requiring separate rules for IN and OUT, then, yes, you fall victim to terrible software design on your firewall GUI and your 1:MANY NAT may save your bacon. In IPv6 where even if NAT is implemented, it would hopefully be limited to 1:1, it probably won't help.

> 
> 
>> More than likely even if there is NAT, the following configuration
>> 
>> NAT  External: 2001:db8:4f00::/48 Internal: 2001:db8:9200::/48 1:1
>> 
>> Would exist in IPv6, so, even if you got NAT, you most likely
>> lose that.
> 
> Yes, I agree...if you staticly NAT your entire network then you DO loose most of the security value of NAT and may as well be running Public Address Space on your network and save yourself the hassle of a seperate address scheme. However, I don't know anyone who values NAT that would actualy DO THAT. It's why I've lobbied so hard that BOTH 1:1 and Many:1 Address translation should exist under IPV6. Lack of support for that is one of the reasons (though certainly not the only) that IPV6 is a bit of a disaster in the making.... and why alot of Admins are shaking thier heads at IPv6 and saying "Naw I really don't WANT to deploy that unless I'm forced to".

I'd much rather fix the firewall software than break the internet, but, perhaps I'm the only one who things that problems should be resolved where they are broken rather than break something else instead.

> You guys would have had ALOT more buy-in (and saved a good chunk of the pain/cost in adoption) if you had kept pretty much everything the same as it worked in IPv4 and just doubled or tripled the number of octets used.
> 
I didn't design IPv6. I wasn't much involved in its development. However, I do remember the IPv4 internet before NAT and a non-NATted network is well worth the effort to fix those things which are deficient in such a way as to make NAT seem attractive.

Owen