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 <[email protected] <mailto:[email protected]>> wrote: On May 14, 2015 9:26 PM, "Gal Sagie" <[email protected] <mailto:[email protected]><mailto:[email protected] <mailto:[email protected]>>> 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: [email protected]?subject:unsubscribe <http://[email protected]?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: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
