Brute Force Attack in Cassandra

middleBrick can detect missing brute‑force mitigations by scanning the HTTP API that fronts your Cassandra cluster (e.g., DataStax Astra DB REST API or a custom gateway). Because the scan is unauthenticated and black‑box, it probes the authentication endpoint and measures the server’s response to rapid failed login attempts.

The scanner runs the following relevant checks in parallel:

• Authentication – verifies whether the endpoint requires valid credentials and whether error messages leak useful information (e.g., distinguishing "unknown user" from "wrong password").
• Rate Limiting – measures if the service imposes any delay or throttling after successive authentication failures.
• Data Exposure – checks for verbose error messages that could aid an attacker in refining guesses.

If the service returns identical rapid responses for each failed attempt without increasing latency or HTTP 429 responses, middleBrick flags a high‑severity finding under the Authentication category, noting the absence of login attempt throttling.

Example CLI usage:

middlebrick scan https://api.example.com/v1/keyspaces

The resulting JSON report (excerpt) might look like:

{
  "findings": [
    {
      "check": "Authentication",
      "severity": "high",
      "description": "No detectable delay or lockout after failed login attempts; enables brute force credential guessing.",
      "remediation": "Configure login_attempts_throttle_ms and credentials_validity_in_ms in cassandra.yaml; enable audit logging."
    }
  ]
}

The Dashboard displays the same finding with a trend line, allowing you to see whether a configuration change has improved the score over time.

To mitigate brute force attacks on Cassandra, apply the following native controls:

1. Enable and tighten authentication – ensure authenticator is set to PasswordAuthenticator (or an external LDAP/Kerberos plugin) and authorizer to CassandraAuthorizer.
2. Introduce login throttling – add login_attempts_throttle_ms (e.g., 2000) to impose a fixed delay after each failed attempt, and set credentials_validity_in_ms to 0 to prevent caching of valid credentials that could be reused.
3. Use role‑based access control (RBAC) – create roles with the minimum required privileges and avoid granting superuser rights to application accounts.
4. Enable audit logging – set audit_logging_options in cassandra.yaml to capture AUTH_ATTEMPT events; monitor for spikes in failed attempts.
5. Enforce strong password policy – if using PasswordAuthenticator, integrate with an external LDAP directory that enforces length, complexity, and rotation, or use the system_auth table to store passwords with a salted hash (default) and require regular rotation via application logic.

Configuration example:

# cassandra.yaml
authenticator: PasswordAuthenticator
authorizer: CassandraAuthorizer
role_manager: CassandraRoleManager
credentials_validity_in_ms: 0
login_attempts_throttle_ms: 2000  # 2‑second delay after each failed auth
audit_logging_options:
    enabled: true
    included_categories: AUTH, DDL, DML
    excluded_keyspaces: system_auth, system_distributed, system_schema, system_traces, system_views

After editing the file, reload the configuration on each node:

nodetool reloadtriggers
nodetool refreshsystem_auth
# or simply restart the node if preferred

Application‑side example using the DataStax Java driver:

import com.datastax.oss.driver.api.core.CqlSessionBuilder;
import com.datastax.oss.driver.api.core.auth.PlainTextAuthProvider;

PlainTextAuthProvider authProvider = new PlainTextAuthProvider("app_user", "StrongP@ssw0rd!");

CqlSession session = CqlSession.builder()
        .addContactPoint(new InetSocketAddress("cassandra-node1.example.com", 9042))
        .withLocalDatacenter("datacenter1")
        .withAuthProvider(authProvider)
        .build();
// Use session for CQL queries...
session.close();

With these controls in place, a brute force attempt will encounter a configurable delay after each failed login, greatly increasing the time required to guess credentials and allowing audit logs to trigger alerts before an attacker succeeds.