Hi John, We were trying to push a very similar spec to enhance the security group API, we covered both DDoS case and another use case for brute force prevention (We did a research to identify common protocols login behaviour in order to identify brute force attacks using iptables) and even some UI work
You can view the specs and implementations here: 1) https://review.openstack.org/#/c/184243/ 2) https://review.openstack.org/#/c/154535/ 3) https://review.openstack.org/#/c/151247/ 4) https://review.openstack.org/#/c/161207/ The spec didn't got approved as there is a strong opinion to keep the security group API compatible with Amazon. I think this and your request fits much more into the FWaaS and if this is something you would like to work together on and push i can help and align the above code to use FWaaS. Feel free to contact me if you have any question Thanks Gal. On Wed, Jun 17, 2015 at 6:58 PM, John Joyce (joycej) <[email protected]> wrote: > Hello everyone: > > I would like to test the waters on some new functionality we think > is needed to protect OpenStack deployments from some overload situations > due to an excessive user or DDOS scenario. We wrote this up in the style > of an RFE. Please let us know your thoughts and we can proceed with a > formal RFE with more detail if there are no concerns raised. > > > > > > *What is being requested* > > This request is to extend the QOS APIs to include the ability to provide > connection rate limiting > > *Why is it being requested* > > There are many scenarios where a VM may be intentionally malicious or > become harmful to the network due to its rate of initializing TCP > connections. The reverse direction of a VM being attacked with an > excessive amount of TCP connection requests either intentionally or due to > overload is also problematic. > > *Implementation Choices > > There might be a number of ways to implement this, but one of the > easiest would appear to be to extend the APIs being developed under: > https://review.openstack.org/#/c/187513/. An additional rule type > “connections per-second” could be added. > > The dataplane implementation itself may be realized with netfilter and > conntrack. > > *Alternatives > > It would be possible to extend the security groups in a similar fashion, > but due to the addition of rate limiting, QoS seems a more nature fit. > > *Who needs it* > > Cloud operators have experienced this issue in real deployments in a > number of cases. > > > > [image: http://www.cisco.com/web/europe/images/email/signature/logo05.jpg] > > *John Joyce* > PRINCIPAL ENGINEER.ENGINEERING > [email protected] > Phone: *+1 978 936 0227 <%2B1%20978%20936%200227>* > > *Cisco Systems Limited* > 1414 Massachusetts Ave. > BOXBOROUGH > MASSACHUSETTS > 01719 > US > Cisco.com <http://www.cisco.com> > > > > [image: Think before you print.]Think before you print. > > This email may contain confidential and privileged material for the sole > use of the intended recipient. Any review, use, distribution or disclosure > by others is strictly prohibited. If you are not the intended recipient (or > authorized to receive for the recipient), please contact the sender by > reply email and delete all copies of this message. > > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [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
