Hardening Cassandra

Used scripts

Download the harden_cassandra_ports.sh script here.

Cassandra Authentication

By default, Cassandra is deployed with the AllowAllAuthenticator. This authenticator, as the name implies, is an anonymous authenticator which performs no checks.

If you require authenticated connections, you will need to make changes to your cassandra.yaml and change the authenticator to PasswordAuthenticator. If you are running a multi-node Cassandra cluster, you need to change the replication factor of the system_auth keyspace.

Detailed instructions can be found at https://docs.datastax.com/en/ddacsecurity/doc/ddacsecurity/secureConfigNativeAuth.html

After making the changes to Cassandra, you will need to update the Magic Collaboration Studio configurations to utilize authentication.

The required changes are as follows:

application.conf

auth-provider {
     # Enable this section to enable the cassandra authentication.
     class = PlainTextAuthProvider
     username = newcassandrauser
     password = newcassandrapassword
}

CODE

Where newcassandrauser and newcassandrapassword correspond to the user and credentials which you configured in Cassandra.

SSL authentication for Cassandra

If the Cassandra certificate is not signed by a public certificate authority, import the Cassandra public certificate to the product's Java cacerts by running the following command:

keytool.exe -import -trustcacerts -keystore cacerts -storepass changeit -noprompt -alias 'server-alias' -file server.cer

BASH

Java cacerts default location for the product (example): /etc/alternatives/jre_17/lib/security/cacerts

Cassandra Encrypted Connections

Starting from Magic Collaboration Studio version 2021x, encrypted communication with Cassandra is supported. To achieve this, the configuration of secure SSL communication is needed.

Data Encryption at Rest

Open source Cassandra does not support encryption at rest. If you require encryption at rest, you need to use a disk encryption layer.

Configuration file property encryption

Apache Cassandra (open source version) does not support encrypting cassandra.yaml properties values.

Port access for the firewall

When installing on Linux using our deployment scripts, all of the ports required by Cassandra for inter-node communication, as well as for the Teamwork Cloud nodes to communicate with Cassandra nodes, are opened globally. This configuration is deployed mostly to facilitate testing of the environment upon installation, prior to taking any measures to harden the installation. If we check the firewall upon installation, we will see an output similar to the one below:

# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: eth0
  sources:
  services: cassandra lmadmin ssh twcloud
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

CODE

In our deployment, we create a firewall service definition to facilitate the management of the rules. This file is located in /etc/firewalld/services/cassandra.xml, and contains the following:

# cat /etc/firewalld/services/cassandra.xml
<?xml version="1.0" encoding="utf-8"?>
<service version="1.0">
    <short>cassandra</short>
    <description>cassandra</description>
    <port port="7000" protocol="tcp"/>
    <port port="7001" protocol="tcp"/>
        <port port="9042" protocol="tcp"/>
        <port port="9160" protocol="tcp"/>
        <port port="9142" protocol="tcp"/>
</service>

CODE

The first step in securing Cassandra is to limit traffic only to Cassandra and Teamwork Cloud nodes. In the example below, we have a single-node Cassandra/product installation, with its IP address set to 10.254.254.56.

As can be seen below, the firewall configuration has been modified to only allow access from itself.

# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: eth0
  sources:
  services: lmadmin ssh twcloud
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:
        rule family="ipv4" source address="10.254.254.56" service name="cassandra" accept

CODE

The process to follow is to remove the general firewall allowance to the Cassandra service. After that, we want to ensure that if direct port rule assignments were made, they are removed. Finally, we want to create a set of rich rules that will allow access only to the required nodes.

If your deployment consists of a single-node or multi-node cluster where both Magic Collaboration Studio and Cassandra reside on the same nodes, automate this process by downloading and using the harden_cassandra_ports.sh script. The script is structured in such a way that it will output the rich rule commands to the screen to facilitate copying and modifying to add nodes, which is needed if you have Teamwork Cloud nodes that are not part of the Cassandra cluster.

The harden_cassandra_ports.sh script should be executed on all nodes of a multi-node Cassandra cluster, with all nodes being in an operational state.

For Windows users: Create firewall rules restricting access on the aforementioned ports only to authorized nodes - Cassandra nodes and Teamwork Cloud nodes.