Hi John, I guess it totally makes sense as a new type of rule for QoS,
once the framework
is ready, it could make sense to add a "connection per second limit" or
"max connection limit"
type of rule.
John Joyce (joycej) wrote:
Gal:
I had seen the brute force blueprint and noticed how close the use
case was. Can you tell me the current status of the work? Do you feel
confident it can get into Liberty? Ideally, we think this fits better
with QoS. Also I don’t think of it as providing FWaaS as we see that
all VMs would be protected by this when enabled, but maybe that is
just terminology. We think these protections are critical so we are
more concerned with having the ability to protect against these cases
than the specific API or service it falls under. Yes we would be
interested in working together to get this pushed through.
John
From: Gal Sagie [mailto:[email protected]]
Sent: Wednesday, June 17, 2015 12:45 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: [email protected]; Derek Chamorro (dechamor); Eran Gampel
Subject: Re: [openstack-dev] [Neutron] [QOS] Request for Additional
QoS capabilities
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]<mailto:[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.
__________________________________________________________________________
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
