I got inspired at the Bro conference to dust off OnionSalt and start adding some features. Currently it is in my dev branch. There are a couple of things to talk about before you start putting this code into your environment. Let's rap about some roadmap stuff real quick.
The Dedicated Master Skeleton
You will see in the release notes the talk about dedicated master support skeleton. The plan here is to give the option to not run OnionSalt on an actual sensor if you don't want to. This has been something that has been requested from several folks due to security reasons. They want to give people ability to modify rules but not give them full access to their actual sensors etc.
To accomplish this you will now see a new pillar called sensors. You will name your sls file the name of you sensor so that it will match the pillar correctly. This is where you will store all unique values specific to each sensor. For this example we will be using the Critical Stack API key. In the future you will be able to use this file to tune your individual sensors right from this file. For our example our sensor name is pwntsauced so the sls file would be like this:
Filename: pwntsauced.sls
File Contents:
############################################################
## ##
## Template File for Unique Sensor Variables ##
## ##
############################################################
sensorstuff:
hostname: pwntsauced
cskey: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
You will also need to comment out a section in the pillar/top.sls so that we match the pillar correctly.
#######################
## ##
## Pillar top.sls ##
## ##
#######################
# Pull the hostname grain
{% set hostn = salt['grains.get']('host', '') %}
# You shouldn't have to mess with this.
base:
'*':
- users
- sensors.{{ hostn }}
By using the grain, we don't have to modify the top.sls every time we add a sensor. If you have each sensor spelled out directly just add the - sensors.pwntsauced to the section for that sensor. You won't need the grain at that point.
So this code will lay the foundation for managing unique values on each of your sensors within your grid. Look for more to come on this as I find time.
Enable Critical Stack Intel Client Support
# Create the state directory
statedir:
file.directory:
- name: /etc/state
This will create the directory for us to use. Next lets create a folder under salt/sensor called scripts. You will see from the dev repo the actual script that we use to do install of the client called cstackinstall.sh:
###
## Script for Critical Stack Intel Client install
##
# Check for the drop....
if [ ! -f /etc/state/cstack.txt ]; then
curl https://packagecloud.io/install/repositories/criticalstack/critical-stack-intel/script.deb.sh | bash
apt-get install critical-stack-intel
critical-stack-intel api {{ salt['pillar.get']('sensorstuff:cskey', '') }}
touch /etc/state/cstack.txt
fi
Now from the script we can put together what we did in the first section of this post where we pull the unique value for this sensor. You see it in here as sensorstuff:cskey. This will pull the unique value and insert it into the script that runs.
Let's enable this script to run on all of our sensors. Uncomment the following code from the sensor/init.sls file.
This will run the script to make sure the client gets installed. I will be adding more features as I get time like ensuring the CS service is running etc but I wanted to get the skeleton out there for people to test. This code needs more testing so please submit pull requests if you find something wrong and fix it.## Enable Critical Stack Intel Client ## csinstall: cmd.script: - source: salt://sensor/scripts/cstackinstall.sh - shell: /bin/bash - template: jinja ## End Critical Stack Intel Client
Smooth out
Important Links:
Critical Stack:
https://intel.criticalstack.com/
OnionSalt DEV repo:
https://github.com/TOoSmOotH/onionsalt/tree/dev
