[arin-ppml] IPv6 Non-connected networks

[Chris Engel]

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

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.


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


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



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




Christopher Engel