[
https://issues.apache.org/jira/browse/QPID-8369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16942677#comment-16942677
]
Alex Rudyy edited comment on QPID-8369 at 10/2/19 10:08 AM:
------------------------------------------------------------
The suggested limits (number of connections per user and maximum frequency of
connections per user) can be implemented as settings in ACL rules. We already
have {{VirtualHost}} access rule which can be expressed like below:
{noformat}
ACL ALLOW-LOG quest ACCESS VIRTUALHOST
{noformat}
Potentially, the rule can be expanded to something like below
{noformat}
ACL ALLOW-LOG quest ACCESS VIRTUALHOST connection_limit=10
connection_frequency_limit=60
{noformat}
The {{connection_limit}} setting in the {{ALLOW}} ACL rule above would limit
the number of connections allowed to create by "guest" to {{10}} . Whilst the
{{connection_frequency_limit}} would limit the maximum frequency of connection
creation for "guest" to {{60}}.
Essentially, any user or a group of users could be limited in such way. Absence
of {{connection_limit}} and {{connection_frequency_limit}} settings would
incicate about unlimited access.
Providing such settings in {{DENY}} rule does not looks to me as having much
sense. Thus, only {{ALLOW}} ACL {{ACCESS}} rule can have such limits.
What do you think about such approach?
Obviously, the rule will limit only AMQP connections. If malicious user would
try to perform DOS attack, the rule would be applied on finishing of
authentication stage. Thus, before the authentication any number of TCP
connections can be created. I am wondering whether a similar limits can be
applied to IP or domain addresses in order to restrict the number of TCP
connections which can be open from given host or domain address. Thus, if
IP/domain address check is performed immediately after opening of TCP
connection, it would eliminate the need to wait for applying the limit for
connection principal, if IP/domain address limit is breached. Thus, such
breaching connection would be closed immediately and might save some host
resources. I am not sure whether adding such check make sense. Perhaps, it
should be a responsibility of some proxy/gateway sitting in front of the broker
instance. What do you think?
was (Author: alex.rufous):
The suggested limits (number of connections per user and maximum frequency of
connections per user) can be implemented as settings in ACL rules. We already
have {{VirtualHost}} access rule which can be expressed like below:
{noformat}
ACL ALLOW-LOG quest ACCESS VIRTUALHOST
{noformat}
Potentially, the rule can be expanded to something like below
{noformat}
ACL ALLOW-LOG quest ACCESS VIRTUALHOST connection_limit=10
connection_frequency_limit=60
{noformat}
The {{connection_limit}} setting in the {{ALLOW}} ACL rule above would limit
the number of connections allowed to create by "guest" to {{10}} . Whilst the
and {{connection_frequency_limit}} would limit the maximum frequency of
connection creation for "guest" to {{60}}.
Essentially, any user or a group of users could be limited in such way. Absence
of {{connection_limit}} and {{connection_frequency_limit}} settings would
incicate about unlimited access.
Providing such settings in {{DENY}} rule does not looks to me as having much
sense. Thus, only {{ALLOW}} ACL {{ACCESS}} rule can have such limits.
What do you think about such approach?
Obviously, the rule will limit only AMQP connections. If malicious user would
try to perform DOS attack, the rule would be applied on finishing of
authentication stage. Thus, before the authentication any number of TCP
connections can be created. I am wondering whether a similar limits can be
applied to IP or domain addresses in order to restrict the number of TCP
connections which can be open from given host or domain address. Thus, if
IP/domain address check is performed immediately after opening of TCP
connection, it would eliminate the need to wait for applying the limit for
connection principal, if IP/domain address limit is breached. Thus, such
breaching connection would be closed immediately and might save some host
resources. I am not sure whether adding such check make sense. Perhaps, it
should be a responsibility of some proxy/gateway sitting in front of the broker
instance. What do you think?
> [Broker-J] Limit number of connections per user
> -----------------------------------------------
>
> Key: QPID-8369
> URL: https://issues.apache.org/jira/browse/QPID-8369
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
> Reporter: Tomas Vavricka
> Priority: Major
> Labels: connection, limit, user
> Fix For: qpid-java-broker-8.0.0
>
>
> There is only limit for number of connections per amqp/amqps port.
> If some user creates too much connections, he can prevent other users from
> connecting to amqp ports.
> Qpid Broker-J should support some limitation for connections per user.
> Broker should also support limitation of number of created connections per
> time frame ex: create 60 connections per one minute at maximum
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
