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

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