Building CCCS’ AssemblyLine for Static Analysis

Building CCCS’ AssemblyLine for Static Analysis

System Requirements

For this build, I will be deploying AssemblyLine on my bare-metal hypervisor exposed to the Internet. This is not always a good idea, however, my build will be further hardened by additional controls which I will explain in subsequent articles within this series.

The virtual machine I will be using is Ubuntu 18.04 Server and has been allocated 8 vCPUs, 16GB of RAM, a 16GB Host partition, and a 128GB /var partition.

Partition layout for AssemblyLine

It is worth noting though, CCCS recommends a much beefier system configuration to run this platform. However, I have had success in operating it on a much smaller configuration.

Prerequisities

First of all, since I will be making this VM internet accessible, some very fundamental hardening must be performed on the host. For this, I will be using the following hardening script to provide a solid base Operating System.

sudo apt update -y && sudo apt upgrade -y
sudo apt-get install curl apt-transport-https ca-certificates software-properties-common cockpit firewalld -y

I tend to use Cockpit when it comes to system administration remotely, you can however choose to omit this requirement if you are not comfortable with using it.

Installing Docker

AssemblyLine relies on Docker and Docker-Compose to pull, build and run the platform. So we will need to install Docker-CE, Compose, and add the current user to the Docker user group.

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
sudo apt update -y
sudo apt install docker-ce -y
sudo usermod -aG docker $USER
sudo curl -L "https://github.com/docker/compose/releases/download/1.27.4/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose

After downloading and chmod’ing docker-compose, you may need to logout of the current user, and then re-login so that the appropriate permissions can be applied.

At this stage, this would be best achieved by rebooting Ubuntu gracefully using ‘sudo reboot’.

Installing AssemblyLine

AssemblyLine can be installed as a fully functional appliance once the Git repository has been cloned. In addition, an SSL/TLS certificate will be required to enable the HTTPS service. In the meantime, we will use a self-generated key and certificate, however in subsequent articles, we will be generating a LetsEncrypt key and certificate and having that key auto regenerate.

cd /etc/
sudo git clone https://github.com/CybercentreCanada/assemblyline-docker-compose.git
cd assemblyline-docker-compose/full_appliance
openssl req -nodes -x509 -newkey rsa:4096 -keyout ./config/nginx.key -out ./config/nginx.crt -days 365 -subj "/C=CA/ST=Ontario/L=Ottawa/O=CCCS/CN=assemblyline.local"

Further to this, the contents of .env and ./config/bootstrap.py will need to be updated with your intended hostnames, usernames, and passwords.

A word of warning: When setting the initial usernames and passwords for AssemblyLine, try to avoid using special characters. The build may fail when using special characters which are incorrectly parsed as part of the installation.

Now we can pull the containers, and start the services.

docker-compose pull
docker-compose up -d
docker-compose -f bootstrap-compose.yaml pull
docker-compose -f bootstrap-compose.yaml up -d 

Configuring AssemblyLine

Now that AssemblyLine is running, it can be logged into for the first time using the credentials you have configured within ./config/bootstrap.py.

First login for AssemblyLine

Out of the box, AssemblyLine is ready to start performing static analysis tasks. There are however some elements that should be considered for keeping this appliance operational, some of which are identified within the Troubleshooting AssemblyLine section of this article.

Troubleshooting AssemblyLine

Disk Full Errors

Eventually, your installation of AssemblyLine may start to consume disk space, at which point logging errors from Elasticsearch may occur (when you have less than 10% disk space left). These repeated errors are committed to logs, and actually accelerate disk space usage and cause Elasticsearch to fail eventually. Thus causing other docker containers to generate more logs pertaining to Elasticsearch not being contactable.

To alleviate this, we can implement log pruning for docker containers to keep those log sizes down.

Leave a Reply

nine − 7 =