For this post I will be talking through the deployment and configuration of Shuffler.io in a self-hosted configuration.
Shuffler.io is a Security Orchestration Automation and Response (SOAR) platform which allows integrations with a number of OpenAPI services (two-way) to better expedite mundane and mandrolic tasks within a Security Operations Centre.
In this implementation, I will talking through the basics of installation and configuration, and some very basic testing through it’s interface.
Table of Contents
System Requirements
For this build I will be using a VM with 2 vCPUs, 4GB RAM and a 16GB Ubuntu Server 18.04 installation.
Installation
sudo apt-get update -y && sudo apt-get upgrade -y
sudo apt-get install -y apt-transport-https ca-certificates curl gnupg-agent software-properties-common
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
sudo apt-key fingerprint 0EBFCD88
sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
sudo apt-get install -y docker-ce docker-ce-cli containerd.io
sudo curl -L "https://github.com/docker/compose/releases/download/1.25.0/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose
docker-compose --version
git clone https://github.com/frikky/Shuffle
cd Shuffle
docker-compose up -d
As soon as docker has completed downloading and starting the containers, you should head over to the web interface pretty much straight-away and set the administrative username and password. If you are doing this on a live Internet accessible server, you may want to implement some form of IP whitelisting for incoming connections before commencing installation.
The first setup administration page will be found at http://yourservername:3001/adminsetup
There are no default logins for the first setup either, so whatever you set here will be the first account creation (also another reason why you should not do this on an Internet exposed system unless you have some other mitigations in place).
Initial Configuration
Now that the container is running, and you have access to Shuffle, initial configuration can commence. If you have supporting appliances such as MISP, Virustotal etc you should consider having your API keys and configuration handy as well.
All configuration of the individual API integrations are completed within the workflow creation screens which is where we will be heading next.
Creating your first workflow
Under the Workflows screen we are offered the option to create a New Workflow.
For this initial workflow I will be capturing events from external IP addresses which are attempting exploits against webservices we are monitoring. The objective I am trying to achieve here is to determine if the host is a known malicious host, and if not, trigger a separate event to submit to external sources a new disclosure.
The most basic configuration I will build off, is a workflow which creates a Case within TheHive, adds the IP address to the case as an observable, and then begins triggering Analyzers from within Cortex.
When I run this workflow and provide it with an IP address from an interesting range (for this case I have fed Shuffler an IP address from a North Korean IP allocation), I should see a new case created, an observable added, and two executions for analyzers.
Payload Formatting
There are some fiddly bits to be aware of for your POST payloads, and you really need to sort out what that payload structure looks like. For this test I have used the following payload structure.
{"body":"<value>"}When nodes within the workflow require the <value> in the payload, the variable can be accessed through $NODENAME.body, which can be mixed in with other data. An example of which can be seen in the CreateCase call for TheHive.
Workflows
Workflows can be very become very complex, but I will be covering this in subsequent posts.
If you have an interest in Shuffle workflows, feel free to subscribe to the blog to get updates.