Open Stack

Hi Jon,

As part of our FWaaS V2 efforts [1] we have been rethinking FWaaS and Security Groups. The idea is that eventually to augment Security Groups with some richer functionality and provide a default FWaaS policy to add to the (vm) port. Furthermore there is a way to “share” Firewall rules with others so you could have a set the user could pick from. I think one of the problems highlighted in this thread is that we can’t think independently of securing a VM port and the perimeter security. To use the example the user wants to have ssh access to his VM and he does’t care if it’s blocked at the vm, the router, or some perimeter firewall — it should just work. So just looking at Security Groups as this thread has done si probably too limited and we likely need a bigger effort to unify network security in OpenStack…

Thanks,
German




[1] https://www.openstack.org/summit/tokyo-2015/videos/presentation/openstack-neutron-fwaas-roadmap

On 3/3/16, 7:12 AM, "Jonathan Proulx" <jon at csail.mit.edu> wrote:

>On Wed, Mar 02, 2016 at 10:19:50PM +0000, James Denton wrote:
>:My opinion is that the current stance of ‘deny all’ is probably the safest bet for all parties (including users) at this point. It’s been that way for years now, and is a substantial change that may result in little benefit. After all, you’re probably looking at most users removing the default rule(s) just to add something that’s more restrictive and suits their organization’s security posture. If they aren’t, then it’s possible they’re introducing unnecessary risk. 
>
>
>I agree whole heartedly that reversing the default would be
>disasterous.
>
>It would be good if a site could define their own default, so I could
>say allow ssh from 'our' networks by default (but not the whole
>internet). Or maybe even further restrict egress traffic so that it
>could only talk to internal hosts.
>
>To go a little further down my wish list I'd really like to do be able
>to offer a standard selection of security groups for my site no tjust
>'default', but that may be a bit off this topic.  Briefly my
>motivation is that 'internal' here includes a number of differnt
>netblock some with pretty weird masks so users tend to use 0.0.0.0/0
>when they don't really meant to just to save some rather tedious
>typing at setup time.
>
>-Jon
>
>
>:
>:There should be some onus put on the provider and/or the user/project/tenant to develop a default security policy that meets their needs, even going so far as to make the configuration of their default security group the first thing they do once the project is created. Maybe some changes to the workflow in Horizon could help mitigate some issues users are experiencing with limited access to instances by allowing them to apply some rules at the time of instance creation rather than associating groups consisting of unknown rules. Or allowing changes to the default security group rules of a project when that project is created. There are some ways to enable providers/users to help themselves rather than a blanket default change across all environments. If I’m a user utilizing multiple OpenStack providers, I’m probably bringing my own security groups and rules with me anyway and am not relying on any provider defaults.
>: 
>:
>:James
>:
>:
>:
>:
>:
>:
>:
>:On 3/2/16, 3:47 PM, "Jeremy Stanley" <fungi at yuggoth.org> wrote:
>:
>:>On 2016-03-02 21:25:25 +0000 (+0000), Sean M. Collins wrote:
>:>> Jeremy Stanley wrote:
>:>> > On 2016-03-03 07:49:03 +1300 (+1300), Xav Paice wrote:
>:>> > [...]
>:>> > > In my mind, the default security group is there so that as people
>:>> > > are developing their security policy they can at least start with
>:>> > > a default that offers a small amount of protection.
>:>> > 
>:>> > Well, not a small amount of protection. The instances boot
>:>> > completely unreachable from the global Internet, so this is pretty
>:>> > significant protection if you consider the most secure system is one
>:>> > which isn't connected to anything.
>:>> 
>:>> This is only if you are booting on a v4 network, which has NAT enabled.
>:>> Many public providers, the network you attach to is publicly routed, and
>:>> with the move to IPv6 - this will become more common. Remember, NAT is
>:>> not a security device.
>:>
>:>I agree that address translation is a blight on the Internet, useful
>:>in some specific circumstances (such as virtual address load
>:>balancing) but otherwise an ugly workaround for dealing with address
>:>exhaustion and connecting conflicting address assignments. I'll be
>:>thrilled when its use trails off to the point that newcomers cease
>:>thinking that's what connectivity with the Internet is supposed to
>:>be like.
>:>
>:>What I was referring to in my last message was the default security
>:>group policy, which blocks all ingress traffic. My point was that
>:>dropping all inbound connections, while a pretty secure
>:>configuration, is unlikely to be the desired configuration for
>:>_most_ servers. The question is whether there's enough overlap in
>:>different desired filtering policies to come up with a better
>:>default than one everybody has to change because it's useful for
>:>basically nobody, or whether we can come up with easier solutions
>:>for picking between a canned set of default behaviors (per Monty's
>:>suggestion) which users can expect to find in every OpenStack
>:>environment and which provide consistent behaviors across all of
>:>them.
>:>-- 
>:>Jeremy Stanley
>:>
>:>__________________________________________________________________________
>:>OpenStack Development Mailing List (not for usage questions)
>:>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>:>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>:__________________________________________________________________________
>:OpenStack Development Mailing List (not for usage questions)
>:Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>:http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>-- 
>
>__________________________________________________________________________
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev