Skip to content

On-premise Security

In the cloud version of LogSentinel SIEM we take all necessary operational security measures. However, in on-premise deployments this becomes the responsibility of the customer. Here are a few recommendations for keeping the installation secure.

Install TLS certificate

By default the LogSentinel SIEM appliance uses a self-signed certificate. If you want to use another certificate, e.g. Let's encrypt, you should configure that on the load balancer that you use (e.g. check "High availability" or on the appliance itself, for example following this Let's encrypt tutorial .

TLS certificate per application node

In some cases the load balancer-to-application node communication needs to be encrypted. In that case, a TLS certifciate can be configured on each application node:

server.ssl.key-store=/var/logsentinel/tls-store.jks
server.ssl.key-store-password=123456
server.ssl.key-password=123456
server.ssl.keyStoreType=JKS
server.ssl.keyAlias=cert
server.ssl.enabled-protocols=TLSv1.2
server.ssl.enabled=true
server.port=8080
server.servlet.session.cookie.http-only=true
server.servlet.session.cookie.secure=true

Creating the tls-store.jks can be done by following this guide

Configure data store encrypted communication

Communication between LogSentinel SIEM and its data stores (Cassandra, Elasticsearch, Kafka) can be encrypted. Cassandra is encrypted by default, the rest requries additional configuration that is usually handled by LogSentinel SIEM implementing partners if requested.

Changing Cassandra encryption keys

By default, all Cassandra communication for virtual appliance setups is encrypted. If you want to change the keys, on each node running Cassandra, the following can be executed to configure TLS. You need to have previously generated /tmp/install/rootCa.key and the corresponding /etc/cassandra/conf/truststore.jks, containing the public key:

BIND_IP= # put local IP here
keytool -genkeypair -keyalg RSA -alias $BIND_IP -keystore /etc/cassandra/conf/node.jks -storepass cassandra -keypass cassandra -validity 2095 -keysize 2048 -dname "CN=$BIND_IP, OU=LogsentinelCluster, O=LogSentinel"
keytool -certreq -keystore /etc/cassandra/conf/node.jks -alias $BIND_IP -file node.csr -keypass cassandra -storepass cassandra -dname "CN=$BIND_IP, OU=LogsentinelCluster, O=LogSentinel"
openssl x509 -req -CA /tmp/install/rootCa.crt -CAkey /tmp/install/rootCa.key -in node.csr -out /tmp/install/node.crt_signed -days 2095 -CAcreateserial -passin pass:123456
keytool -importcert -keystore /etc/cassandra/conf/node.jks -alias rootCa -file /tmp/install/rootCa.crt -noprompt -keypass cassandra -storepass cassandra
keytool -importcert -keystore /etc/cassandra/conf/node.jks -alias $BIND_IP -file /tmp/install/node.crt_signed -noprompt -keypass cassandra -storepass cassandra
shred -v -n 1 -z -u /tmp/install/rootCa.key

Configuring Elasticsearch TLS

Elasticsearch has two types of communication: inter-node and client-to-cluster. TLS can be enabled on both.

Configuration Kafka TLS

Kafka node authentication and encryption can be configured by following this guide

Configure network restrictions

The LogSentinel SIEM instances should only have the required ports opened. For a single, non-clustered appliance, that includes only 80 and 443.

For clustered setups, check the ports below:

* application nodes: 
    * incoming: 8080 (for web requests), 1514, 1515, 1516 (for syslog), 5701 (for hazelcast) and 22 for SSH.
    * outgoing: 80, 443, 9200 (for elastic search), 9042 (for cassandra), 5701, 465 (for smtp)
* database nodes:
    * incoming:  7000, 7001, 7199, 9042, 9160 and 22
    * outgoing: 80, 443, 7000, 7001
* search nodes:
    * incoming: 9200, 9300, 22
    * outgoing: 80, 443, 9300
* load balancer node:
    * incoming: 80, 443, 22
    * outgoing: 80, 443, 8080

Firewalld commands

Below is a list of firewalld commands to execute in order to allow the ports described above:

sudo firewall-cmd --zone=public --permanent --add-port=22/tcp
sudo firewall-cmd --zone=public --permanent --add-port=435/tcp
sudo firewall-cmd --zone=public --permanent --add-port=5701/tcp
sudo firewall-cmd --zone=public --permanent --add-port=7000/tcp
sudo firewall-cmd --zone=public --permanent --add-port=7001/tcp
sudo firewall-cmd --zone=public --permanent --add-port=8080/tcp
sudo firewall-cmd --zone=public --permanent --add-port=9042/tcp
sudo firewall-cmd --zone=public --permanent --add-port=9092/tcp
sudo firewall-cmd --zone=public --permanent --add-port=9200/tcp
sudo firewall-cmd --zone=public --permanent --add-port=9300/tcp
sudo firewall-cmd --reload

Configure administrator access restrictions

Ideally SSH access to all nodes should be protected via 2-factor authentication. You can do that by executing the following setup-2fa.sh script:

    #!/bin/sh
    # Execute manually AFTER the host has been setup
    # Based on https://aws.amazon.com/blogs/startups/securing-ssh-to-amazon-ec2-linux-hosts/
    sudo yum -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
    sudo yum -y install google-authenticator
    # Execute this line for each user manually, before they can login. Use > sudo su <user> before that
    google-authenticator --time-based --disallow-reuse --force --rate-time=30 --rate-limit=3 --window-size=8
    sudo echo "auth required pam_google_authenticator.so" >> /etc/pam.d/sshd
    sudo sed -i -- 's/ChallengeResponseAuthentication no/ChallengeResponseAuthentication yes/g' /etc/ssh/sshd_config
    sudo sed -i -- 's/auth       substack     password-auth/#auth       substack     password-auth/g' /etc/pam.d/sshd
    sudo echo "\nAuthenticationMethods publickey,keyboard-interactive" >> /etc/ssh/sshd_config

    sudo service sshd restart

Track administrative access through a custom PAM

We provide a custom PAM which you can get by following the instructions here. The PAM makes sure that each administrative access is pushed directly to external sources (e.g. a qualified trust service provider). That way, in case an administrator tries to manipulate the logs that will not only be detected, but they won't be able to cover who they were. The PAM does some additional checks, e.g. if the network is not blocked, and does not let the administrator login if the log event can't be pushed properly.

Internal audit log

Every activity performed in the system is logged in a specialized admin account (initial values configurable through application.properties - admin.username and admin.password).

The audit log contains all authentication attempts, all configuration changes and all queries executed. Alert rules can be defined in this account to monitor the security of the SIEM deployment itself.