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.
- For client-to-cluster communication, follow this guide (skip the parts about Kibana)
- For inter-node communication, follow this guide
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
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
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.