<div dir="ltr">Awesome! Hope it reaches Juno!   :-)<div>This is important...</div><div><br></div><div>Best,</div><div>Thiago</div><div class="gmail_extra"><br><div class="gmail_quote">On 16 September 2014 13:17, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
There is current work in review to use conntrack to terminate these<br>
connections [1][2] much like you suggested.  I hope to get this in to<br>
RC1 but it needs another iteration.<br>
<br>
For Kilo, I'd like to explore stateless forwarding for floating ips.<br>
Since conntrack is the root of the security issue in the first place,<br>
the idea here is to eliminate it from the floating ip data path<br>
altogether [3].  The patch I have up is really just a placeholder with<br>
some notes on how it might be accomplished.  My hope is that this<br>
stateless NAT for floating ips could ease some of the pressure that<br>
I've observed on conntrack and increase performance.  It needs some<br>
more investigation.<br>
<br>
Carl<br>
<br>
[1] <a href="https://bugs.launchpad.net/neutron/+bug/1334926" target="_blank">https://bugs.launchpad.net/neutron/+bug/1334926</a><br>
[2] <a href="https://review.openstack.org/#/c/103475" target="_blank">https://review.openstack.org/#/c/103475</a><br>
[3] <a href="https://review.openstack.org/#/c/121689/" target="_blank">https://review.openstack.org/#/c/121689/</a><br>
<div><div><br>
On Mon, Sep 15, 2014 at 11:46 PM, Martinx - ジェームズ<br>
<<a href="mailto:thiagocmartinsc@gmail.com" target="_blank">thiagocmartinsc@gmail.com</a>> wrote:<br>
> Hey stackers,<br>
><br>
> Let me ask something about this... Why not use Linux Conntrack Table at each<br>
> Tenant Namespace (L3 Router) to detect which connections were<br>
> made/established over a Floating IP ?<br>
><br>
> Like this, on the Neutron L3 Router:<br>
><br>
> --<br>
> apt-get install conntrack<br>
><br>
> ip netns exec qrouter-09b72faa-a5ef-4a52-80b5-1dcbea23b1b6 conntrack -L |<br>
> grep ESTABLISHED<br>
><br>
> tcp      6 431998 ESTABLISHED src=192.168.3.5 dst=193.16.15.250 sport=36476<br>
> dport=8333 src=193.16.15.250 dst=187.1.93.67 sport=8333 dport=36476<br>
> [ASSURED] mark=0 use=1<br>
> --<br>
><br>
> Floating IP: 187.1.93.67<br>
> Instance IP: 192.168.3.5<br>
><br>
> <a href="http://conntrack-tools.netfilter.org/manual.html#conntrack" target="_blank">http://conntrack-tools.netfilter.org/manual.html#conntrack</a><br>
><br>
> ----<br>
><br>
> Or, as a workaround, right after removing the Floating IP, Neutron might<br>
> insert a temporary firewall rule (for about 5~10 minutes?), to drop the<br>
> connections of that previous "Floating IP + Instance IP couple"... It looks<br>
> really ugly but, at least, it will make sure that nothing will pass right<br>
> after removing a Floating IP... Effectively terminating (dropping) the NAT<br>
> connections after disassociating a Floating IP...     ;-)<br>
><br>
> ----<br>
><br>
> Also, I think that NFTables can bring some light here... I truly believe<br>
> that if OpenStack moves to a "NFTables_Driver", it will be much easier to:<br>
> manage firewall rules, logging, counters, IDS/IPS, atomic replacements of<br>
> rules, even NAT66... All under a single implementation... Maybe with some<br>
> kind of "real-time connection monitoring"... I mean, with NFTables, it<br>
> becomes easier to implement a firewall ruleset with a Intrusion Prevention<br>
> System (IPS), take a look:<br>
><br>
> <a href="https://home.regit.org/2014/02/suricata-and-nftables/" target="_blank">https://home.regit.org/2014/02/suricata-and-nftables/</a><br>
><br>
> So, if NFTables can make Suricata's life easier, why not give Suricata's<br>
> power to Netutron L3 Router? Starting with a new NFTables_Driver...     =)<br>
><br>
> I'm not an expert on NFTables but, from what I'm seeing, it perfectly fits<br>
> in OpenStack, in fact, NFTables will make OpenStack better.<br>
><br>
> <a href="https://home.regit.org/2014/01/why-you-will-love-nftables/" target="_blank">https://home.regit.org/2014/01/why-you-will-love-nftables/</a><br>
><br>
> Best!<br>
> Thiago<br>
><br>
> On 15 September 2014 20:49, Nathan Kinder <<a href="mailto:nkinder@redhat.com" target="_blank">nkinder@redhat.com</a>> wrote:<br>
>><br>
>> -----BEGIN PGP SIGNED MESSAGE-----<br>
>> Hash: SHA1<br>
>><br>
>> Disassociating floating IPs does not terminate NAT connections with<br>
>> Neutron L3 agent<br>
>> - ---<br>
>><br>
>> ### Summary ###<br>
>> Every virtual instance is automatically assigned a private IP address.<br>
>> You may optionally assign public IP addresses to instances. OpenStack<br>
>> uses the term "floating IP" to refer to an IP address (typically<br>
>> public) that can be dynamically added to a running virtual instance.<br>
>> The Neutron L3 agent uses Network Address Translation (NAT) to assign<br>
>> floating IPs to virtual instances. Floating IPs can be dynamically<br>
>> released from a running virtual instance but any active connections are<br>
>> not terminated with this release as expected when using the Neutron L3<br>
>> agent.<br>
>><br>
>> ### Affected Services / Software ###<br>
>> Neutron, Icehouse, Havana, Grizzly, Folsom<br>
>><br>
>> ### Discussion ###<br>
>> When creating a virtual instance, a floating IP address is not<br>
>> allocated by default. After a virtual instance is created, a user can<br>
>> explicitly associate a floating IP address to that instance. Users can<br>
>> create connections to the virtual instance using this floating IP<br>
>> address. Also, this floating IP address can be disassociated from any<br>
>> running instance without shutting that instance down.<br>
>><br>
>> If a user initiates a connection using the floating IP address, this<br>
>> connection remains alive and accessible even after the floating IP<br>
>> address is released from that instance. This potentially violates<br>
>> restrictive policies which are only being applied to new connections.<br>
>> These policies are ignored for pre-existing connections and the virtual<br>
>> instance remains accessible from the public network.<br>
>><br>
>> This issue is only known to affect Neutron when using the L3 agent.<br>
>> Nova networking is not affected.<br>
>><br>
>> ### Recommended Actions ###<br>
>> There is unfortunately no easy way to detect which connections were<br>
>> made over a floating IP address from a virtual instance, as the NAT is<br>
>> performed at the Neutron router. The only safe way of terminating all<br>
>> connections made over a floating IP address is to terminate the virtual<br>
>> instance itself.<br>
>><br>
>> The following recommendations should be followed when using the Neutron<br>
>> L3 agent:<br>
>><br>
>> - - Only attach a floating IP address to a virtual instance when that<br>
>> instance should be accessible from networks outside the cloud.<br>
>> - - Terminate or stop the instance along with disassociating the floating<br>
>> IP address to ensure that all connections are closed.<br>
>><br>
>> The Neutron development team plans to address this issue in a future<br>
>> version of Neutron.<br>
>><br>
>> ### Contacts / References ###<br>
>> This OSSN : <a href="https://wiki.openstack.org/wiki/OSSN/OSSN-0020" target="_blank">https://wiki.openstack.org/wiki/OSSN/OSSN-0020</a><br>
>> Original LaunchPad Bug : <a href="https://bugs.launchpad.net/neutron/+bug/1334926" target="_blank">https://bugs.launchpad.net/neutron/+bug/1334926</a><br>
>> OpenStack Security ML : <a href="mailto:openstack-security@lists.openstack.org" target="_blank">openstack-security@lists.openstack.org</a><br>
>> OpenStack Security Group : <a href="https://launchpad.net/~openstack-ossg" target="_blank">https://launchpad.net/~openstack-ossg</a><br>
>> -----BEGIN PGP SIGNATURE-----<br>
>> Version: GnuPG v1<br>
>><br>
>> iQEcBAEBAgAGBQJUF3r6AAoJEJa+6E7Ri+EVo+AH/i4GhZsFD3OJWlasq+XxkqqO<br>
>> W7g/6YQuKgRndl63UjnWAfpvJCA8Bl1msryb2K0tTZpDByVpgupPAf6+/NMZXvCT<br>
>> 37YF236Ig/a/iLNjAdHRNHzq8Bhxe7tIikm1ICUH+Hyhob7soBlAC52lEJz9cFwb<br>
>> Hazo2K0jjt4TEyxAae06KsIuOV/n+tO7ginYxxv2g8DkhKik5PMi4x8j//DYFz92<br>
>> +SwPvUKeWiZ3JmD1M84Yj4VgPxah6fKDtCYKdTdcv7pYJGlcac8DTXbJkoFVd6H/<br>
>> v+XbBGWjg7+M7WlZJmDlC2XfWLVKBsREs3BAN/hagE6aKAyImT/gfyT0WxLpVIU=<br>
>> =Gk3u<br>
>> -----END PGP SIGNATURE-----<br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</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>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</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>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</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>
</div></div></blockquote></div><br></div></div>