ELSA to Elastic

Introduction

If you have an existing ELSA deployment, you can perform an in-place upgrade to the Elastic Stack. This will disable ELSA and enable the Elastic Stack.

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 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 standard command line tools 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:

sudo soup
sudo reboot
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

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

Run sostat to get a list of sensors and their reverse ports:

sudo sostat

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
sensor2 172.18.0.1 50001
sensor3 172.18.0.1 50002

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

Sensors

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

sudo soup
sudo reboot
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

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

Check Kibana and search for logs from the new sensor.