ELSA to Elastic

Introduction

The Elastic Stack typically requires more CPU and more RAM than ELSA. In addition, you will most likely want SSD storage for Elastic data if at all possible. For best results, we recommend performing a fresh installation on new hardware designed to meet these requirements. If your ELSA hardware already meets these requirements and you really need to perform an in-place upgrade from ELSA to Elastic, this page will provide an overview of steps necessary.

Warning

The in-place upgrade process is still considered EXPERIMENTAL and so the usual warnings and disclaimers apply:

• This is BLEEDING EDGE and TOTALLY UNSUPPORTED!
• If this breaks your system, you get to keep both pieces!
• This may result in nausea, vomiting, or a burning sensation.

Exporting Data from ELSA

By default, this process does NOT export data from ELSA. If you need the data that is in ELSA, there is an experimental script called so-elsa-export that can export data from ELSA to raw logs in the filesystem. Before running this script, please check your disk space as this will duplicate all your logs. Once exported, you may want to move these logs off to a separate system for archival. They are standard cleartext logs so you can use standard command line tools such as grep, awk, and sed to search through them if necessary.

Importing Data to Elastic

The export script provides information on how to import the data into Elastic. However, please note the following caveats:

• this creates yet another copy of the data and so it is essential that you have plenty of free space
• Logstash only has parsers for the current version of Bro, so older Bro logs may not parse correctly

Upgrade Process

Standalone

For a single standalone box that doesn't have any separate sensor boxes connected to it:

Install all updates:

sudo soup

Reboot:

sudo reboot

Install and configure Elastic:

sudo apt update
sudo apt install securityonion-elastic
sudo so-elastic-download
sudo so-elastic-configure

Distributed Deployment

For distributed deployments consisting of a master server and one or more sensor boxes, start the upgrade process with the master server. Once the master server has been fully converted to the Elastic Stack, then start updating sensors one at a time.

Master Server

Before initiating the upgrade process on the master server, run sostat:

sudo sostat

At the very end of the sostat output, look for the section entitled "ELSA Log Node SSH Tunnels". Save the information in this section as you will need it later in this procedure.

Install all updates:

sudo soup

Reboot:

sudo reboot

Install and configure Elastic:

sudo apt update
sudo apt install securityonion-elastic
sudo so-elastic-download
sudo so-elastic-configure

For each sensor, add a line to /etc/nsm/crossclustertab like the following (replacing sensorX with the actual sensor name and 5000X with the actual reverse port):

sensor1 172.18.0.1:50000

For each sensor, add a firewall rule (replacing 5000X with the actual reverse port):

sudo ufw allow proto tcp from 172.18.0.0/24 to 172.18.0.1 port 50000

For each sensor ssh account, add lines to /etc/ssh/sshd_config like the following (replacing $SSH_USERNAME with the actual sensor ssh account):

Match User $SSH_USERNAME
   GatewayPorts clientspecified

Restart sshd:

sudo service ssh restart

Sensors

Perform the following steps on each sensor box, one at a time (finish the first sensor before starting the second sensor, etc.).

Install all updates:

sudo soup

Reboot:

sudo reboot

Install and configure Elastic:

sudo apt update
sudo apt install securityonion-elastic
sudo so-elastic-download
echo "KIBANA_ENABLED=no" | sudo tee -a /etc/nsm/securityonion.conf
echo "ELASTALERT_ENABLED=no" | sudo tee -a /etc/nsm/securityonion.conf
sudo so-elastic-configure
sudo so-autossh-restart

Manually add transport settings to /etc/elasticsearch/elasticsearch.yml (replacing $REVERSE_PORT with the actual reverse port):

transport.bind_host: 0.0.0.0
transport.publish_host: 172.18.0.1
transport.publish_port: $REVERSE_PORT

Restart Elasticsearch:

sudo docker restart so-elasticsearch

On the master server, run:

sudo so-crossclustercheck
curl http://localhost:9200/_cluster/settings?pretty

If everything worked, then you should see the new sensor listed in the output.

Check Kibana and search for logs from the new sensor.