cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From oleg yusim <>
Subject Re: max connection per user
Date Fri, 15 Jan 2016 01:24:01 GMT
Let me revive this thread a little.

I see, it is possible to limit concurrent connections based on IP or client:

# The maximum number of concurrent client connections.
# The default is -1, which means unlimited.
# native_transport_max_concurrent_connections: -1

# The maximum number of concurrent client connections per source ip.
# The default is -1, which means unlimited.
# native_transport_max_concurrent_connections_per_ip: -1

My question would be - what is the current recommendations Cassandra team
has for those? How many database can handle for sure?



On Wed, Jan 13, 2016 at 9:04 PM, oleg yusim <> wrote:

> Brian - absolutely.
> To give you are brief description of what I'm doing. I'm working for
> VMware as security architect, and they tasked me with creating a STIG
> (working with DISA ) for Cassandra DB. To create a STIG I would walk
> through the Database SRG security controls and assess them against
> Cassandra DB configuration. As the result, I would have to address all the
> security controls in SRG, proposing mitigations where Cassandra can't meet
> it by means of configuring and specifying desired configuration, where it
> would be possible to do so.
> At this particular place, I'm dealing with following security control:
> The DBMS must limit the number of concurrent sessions to an
> organization-defined number per user for all accounts and/or account types.
> Here is the brief dive into why it is needed:
> Database management includes the ability to control the number of users
> and user sessions utilizing a DBMS. Unlimited concurrent connections to the
> DBMS could allow a successful Denial of Service (DoS) attack by exhausting
> connection resources; and a system can also fail or be degraded by an
> overload of legitimate users. Limiting the number of concurrent sessions
> per user is helpful in reducing these risks.
> This requirement addresses concurrent session control for a single
> account. It does not address concurrent sessions by a single user via
> multiple system accounts; and it does not deal with the total number of
> sessions across all accounts.
> The capability to limit the number of concurrent sessions per user must be
> configured in or added to the DBMS (for example, by use of a logon
> trigger), when this is technically feasible. Note that it is not sufficient
> to limit sessions via a web server or application server alone, because
> legitimate users and adversaries can potentially connect to the DBMS by
> other means.
> The organization will need to define the maximum number of concurrent
> sessions by account type, by account, or a combination thereof. In deciding
> on the appropriate number, it is important to consider the work
> requirements of the various types of users. For example, 2 might be an
> acceptable limit for general users accessing the database via an
> application; but 10 might be too few for a database administrator using a
> database management GUI tool, where each query tab and navigation pane may
> count as a separate session.
> (Sessions may also be referred to as connections or logons, which for the
> purposes of this requirement are synonyms.)
> Now with that in mind, typical way to DoS database would be open more
> connections than database can support, bringing server to its knees.
> Typical way to counter it is limiting number of concurrent user sessions to
> two and number of concurrent administrator sessions to 10.
> With the answer Rob provided me with, I'm reduced to searching for
> mitigation control. That might be limiting maximum amount of connections to
> database, to the amount database for sure can support. I know JDBC driver
> has such configuration switches, allowing to go for that. The question now
> is - how many? What is the number of simultanious connections Cassandra
> would be able to bare?
> Thanks,
> Oleg
> On Wed, Jan 13, 2016 at 8:40 PM, Bryan Cheng <>
> wrote:
>> Are you actively exposing your database to users outside of your
>> organization, or are you just asking about security best practices?
>> If you mean the former, this isn't really a common use case and there
>> isn't a huge amount out of the box that Cassandra will do to help.
>> If you're just asking about security best-practices,
>> has a brief blurb, and there are many resources online for securing
>> Cassandra specifically and databases in general- the approaches are going
>> to be largely the same.
>> Can you describe what avenues you're expecting either intrusion or DOS?
>> On Wed, Jan 13, 2016 at 6:01 PM, oleg yusim <> wrote:
>>> OK Rob, I see what you saying. Well, let's dive into the long questions
>>> and answers at this case a bit:
>>> 1) Is there any other approach Cassandra currently utilizes to mitigate
>>> DoS attacks?
>>> 2) How about max connection per DB? I know, Cassandra has this parameter
>>> on JDBC driver configuration, but what be suggested value not to exceed?
>>> Thanks,
>>> Oleg
>>> On Wed, Jan 13, 2016 at 6:31 PM, Robert Coli <>
>>> wrote:
>>>> On Wed, Jan 13, 2016 at 1:41 PM, oleg yusim <>
>>>> wrote:
>>>>> Quick question, here: does Cassandra have a configuration switch to
>>>>> limit number of connections per user (protection of DoS attack, security)?
>>>> Quick answer : no.
>>>> =Rob

View raw message