Open Stack

On 05/15/2015 08:32 PM, Gal Sagie wrote:
> What i was describing in [2] is different, maybe the name "rate-limit"
> is wrong here and what we are doing is more of
> a "brute force prevention" .
> We are trying to solve common scenarios for east-west security attack
> vectors, for example a common vector is a compromised
> VM trying to port scan the network.

Interestingly enough, what I've come across mostly (virtually entirely) 
has been compromised instances being used in sending spewage out onto 
the Big Bad Internet (tm).

One thing I was thinking about to detect such instances was simply 
looking at the ratio of inbound and outbound traffic on the instances' 
tap device(s).  Once it crossed a certain threshold declare the instance 
suspect and in need of further scrutiny.

> By matching these port-scanning with "rate-limit" security rules we can
> detect this and either block
> that traffic or alert the admin/user.
> (An example of a "rate-limit" rule would be a VM pinging the same IP
> with different ports on a short period of time)
>
> For that there is the security API extension that is needed and the
> reference implementation, and we should discuss
> them both on the session [3] and how to support extending the API
> furthur for other user cases/vendors, hope to see you there!

Alas, I won't be able to attend :(

> [1] https://review.openstack.org/#/c/88599/
> [2] https://review.openstack.org/#/c/151247/
> [3] https://etherpad.openstack.org/p/YVR-neutron-sg-fwaas-future-direction
>
> On Fri, May 15, 2015 at 10:01 PM, Rick Jones <rick.jones2 at hp.com
> <mailto:rick.jones2 at hp.com>> wrote:
>
>         On May 14, 2015 9:26 PM, "Gal Sagie" <gal.sagie at gmail.com
>         <mailto:gal.sagie at gmail.com><mailto:gal.sagie at gmail.com
>         <mailto:gal.sagie at gmail.com>>> wrote:
>         Hello Ryan,
>
>         We have proposed a spec to liberty to add rate limit
>         functionality to security groups [1].
>         We see two big use cases for it, one as you mentioned is DDoS
>         for east-west and another
>         is brute force prevention (for example port scanning).
>
>         We are re-writing the spec as an extension to the current API,
>         we also have a proposal
>         to enhance the Security Group / FWaaS implementation in order to
>         make it easily extendible by such
>         new classes of security rules.
>
>         We are planning to discuss all of that in the SG/FWaaS future
>         directions session [2].
>         I or Lionel will update you as soon as we have the fixed spec
>         for review, and feel free to come to the discussion
>         as we are more then welcoming everyone to help this effort.
>
>         Gal.
>
>         [1] https://review.openstack.org/#/c/151247/
>         [2]
>         https://etherpad.openstack.org/p/YVR-neutron-sg-fwaas-future-direction
>
>
>     Isn't there already described a way to rate-limit instances
>     (overall) by putting qdiscs onto their tap devices?
>
>     Having looked only briefly at the spec, I would say you want to have
>     the option to "MARK" that traffic which is EDN enabled the rate
>     limiting might have otherwise dropped.
>
>     The extant mechanism I mentioned uses HTB in one direction (instance
>     inbound/tap outbound) and a policing filter in the other.  I've used
>     it (as a mostly end user) and have noticed that as described, one
>     can introduce non-trivial bufferbloat inbound to the instance.
>
>     And I've always wished (as in if wishes were horses) that the
>     instance outbound throttle were actually implemented in a way where
>     it becomes immediately apparent to the instance by causing the tx
>     queue in the instance to build-up.  That wouldn't be something on a
>     tap device though.
>
>     Does there need to be both a packet and bit rate limit?  I've some
>     experience with bit rate limits and have seen otherwise rather
>     throttled (bitrate) instances cause non-trivial problems with a
>     network node.
>
>     rick jones
>
>
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe:
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
> Best Regards ,
>
> The G.
>
>
> __________________________________________________________________________
> 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
>