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? Thanks, Oleg On Wed, Jan 13, 2016 at 9:04 PM, oleg yusim <olegyu...@gmail.com> 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 <br...@blockcypher.com> > 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, >> http://www.datastax.com/wp-content/uploads/2014/04/WP-DataStax-Enterprise-Best-Practices.pdf >> 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 <olegyu...@gmail.com> 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 <rc...@eventbrite.com> >>> wrote: >>> >>>> On Wed, Jan 13, 2016 at 1:41 PM, oleg yusim <olegyu...@gmail.com> >>>> 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 >>>> >>>> >>> >>> >> >
