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
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
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.