<div dir="ltr"><div>><span style="font-size:12.8000001907349px">This sounds like a different bug than 1359523.</span><br></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">You're right, I just filed a bug for this: <a href="https://bugs.launchpad.net/neutron/+bug/1463589">https://bugs.launchpad.net/neutron/+bug/1463589</a></span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div>><span style="font-size:12.8000001907349px">Just curious has anyone hit this in the wild or is this totally contrived?</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">I initially contrived it, but it was also brought up to me a concern to me from one of our in-house scalability testers. I highly doubt someone will notice this in the wild because nothing loudly breaks. It just makes your VMs vulnerable to unexpected connections.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">></span><span style="font-size:12.8000001907349px">My first reaction to this is that if you set this up like this, you deserve it.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">No</span></div><div><br></div><div>><span style="font-size:12.8000001907349px">I'm not inclined to invest a lot of effort in to this. I don't see it as a big security hole. Is there a way to exploit this that I cannot see?</span><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">If you have a large virtual topology and then have a couple of VMs attached to a shared network that has overlapping addresses with anything in your virtual topology, your VMs on the shared network will be vulnerable to connections from anything that shares an address with the VMs on your private topologies.</div><div class="gmail_extra"><br></div><div class="gmail_extra">My example scenario in the previous email was more contrived to get to the heart of the issue, but the above is a lot more likely to happen. </div><div class="gmail_extra"><br></div><div class="gmail_extra">Our security group grouping model implies that you are allowing specific neutron ports. That happens to be rendered into iptables rules based on the IP addresses, which violates the API intent whenever ports land in different overlapping subnets.</div><div class="gmail_extra"><br></div><div class="gmail_extra">We can continue the discussion on the bug report.</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 9, 2015 at 12:33 PM, Carl Baldwin <span dir="ltr"><<a href="mailto:carl@ecbaldwin.net" target="_blank">carl@ecbaldwin.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><span class=""><p dir="ltr">On Mon, Jun 8, 2015 at 3:52 PM, Kevin Benton <<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>> wrote:<br>
> There is a bug in security groups here:<br>
> <a href="https://bugs.launchpad.net/neutron/+bug/1359523" target="_blank">https://bugs.launchpad.net/neutron/+bug/1359523</a><br>
><br>
> In the example scenario, it's caused by conntrack zones not being isolated.<br>
> But it also applies to the following scenario that can't be solved by zones:<br>
><br>
> create two networks with same <a href="http://10.0.0.0/24" target="_blank">10.0.0.0/24</a><br>
> create port1 in SG1 on net1 with IP 10.0.0.1<br>
> create port2 in SG1 on net2 with IP 10.0.0.2<br>
> create port3 in SG2 on net1 with IP 10.0.0.2<br>
> create port4 in SG2 on net2 with IP 10.0.0.1</p>
</span><p dir="ltr">This sounds like a different bug than 1359523. It isn't what was described in the bug report and has a different underlying cause. While it looks similar on the surface, could we open up a new bug to track this? Just curious has anyone hit this in the wild or is this totally contrived?</p>
<p dir="ltr">My first reaction to this is that if you set this up like this, you deserve it. Maybe we just advise that people plan to avoid scenarios that intersect multiple security groups across disparate L2 networks using overlapping IP address space. Don't use overlapping subnets. Or, if you do, don't use the same security group across them. But, that is just a cop out if we haven't had a discussion.</p><p>Using address scopes will prevent any overlap and fix this situation in the following way. I think this is what Kevin had in mind:</p><p>create two networks with same <a href="http://10.0.0.0/24" target="_blank">10.0.0.0/24</a> allocating the subnets from an address pool. They must be allocated from different subnet scopes. We know because if they were the same scope, overlap wouldn't be allowed. A fundamental design feature of address scopes is that address overlap is prevented within the scope.</p><p> Net1 has address scope a and net2 has address scope b. All the subnets on a network from the same address family are required to be from the same pool. Hence, they'll be in the same scope.</p><p> create port1 in SG1 on net1 with IP 10.0.0.1. Has address scope a<br> create port2 in SG1 on net2 with IP 10.0.0.2. Has address scope b<br> create port3 in SG2 on net1 with IP 10.0.0.2. Has address scope a<br> create port4 in SG2 on net2 with IP 10.0.0.1. Has address scope b<br></p><p>The scope names are arbitrary and contrived but we know that port1 and port3 must be in the same scope because they are on the same network. We also know that a != b because the same scope wouldn't allow the overlap.</p>
<p dir="ltr"><span class="">> port1 can communicate with port3 because of the allow rule for port2's IP<br>
> port2 can communicate with port4 because of the allow rule for port1's IP<br><br></span>These would be prevented if the security group code notices that port1 and port2 are not in the same scope and therefore will never be able to communicate without some sort of NAT in between. It should leave out the allow rules because of this.</p><p dir="ltr">Same for port3 and port4 in the other SG.<br></p><span class=""><p dir="ltr">
> The solution will require the security groups processing code to understand<br>
> that a member of a security group is not actually reachable by another<br>
> member and skip the allow rule for that member.<br></p></span><p>I said the same thing just with a little more specificity and referring to the example.</p><p><span class="">> With the current state of things, it will take a tone of kludgy code to<br>> check for routers and router interfaces to see if two IPs can communicate<br>> without NAT. However, if we end up with the concept of address-scopes, it<br>> just becomes a simple address scope comparison.<br><br></span>I'm not inclined to invest a lot of effort in to this. I don't see it as a big security hole. Is there a way to exploit this that I cannot see? I'm still inclined to say that we should come up with some kind of advise for how to manage SGs and networks to avoid it.<br><br>> Implement address scopes.</p>
<p dir="ltr">I will. Stay tuned. I did not, however, include any kind of integration with security groups with my address scopes spec. I don't think I should necessarily stop everything to include it either. I still tend to think that this example is a bit contrived which is why I've asked if this was hit in the wild.</p><p dir="ltr">You should keep in mind that address scopes will not be forced on anyone. You will get the same thing as today if you continue to make all the same API calls to set it up. Address scopes will only come in to play if you use subnet pools. If you don't use subnet pools, you can still create overlapping address ranges. So, we can make security groups address scope aware but it won't fix the problem for existing models.<span class=""><font color="#888888"><br></font></span></p><span class=""><font color="#888888">
<p dir="ltr">Carl</p>
</font></span></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div>Kevin Benton</div></div>
</div></div>