Open Stack

Hi,

There is current work in review to use conntrack to terminate these
connections [1][2] much like you suggested.  I hope to get this in to
RC1 but it needs another iteration.

For Kilo, I'd like to explore stateless forwarding for floating ips.
Since conntrack is the root of the security issue in the first place,
the idea here is to eliminate it from the floating ip data path
altogether [3].  The patch I have up is really just a placeholder with
some notes on how it might be accomplished.  My hope is that this
stateless NAT for floating ips could ease some of the pressure that
I've observed on conntrack and increase performance.  It needs some
more investigation.

Carl

[1] https://bugs.launchpad.net/neutron/+bug/1334926
[2] https://review.openstack.org/#/c/103475
[3] https://review.openstack.org/#/c/121689/

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