Deploying MozDef in AWS

Hello dear reader!

I am extremely happy to announce that I have recently finished a master degree in Cybersecurity! Therefore I will be doing a series of posts on topics related to it. In this one we will be diving into what a SIEM (Security Information and Event Management) system is, what open source alternatives there are, and we will be deploying one of them (MozDef) to AWS. Lets get started!

What is a SIEM?

Security Information and Event Management (SIEM) is a software solution that aggregates and analyzes activity from multiple resources across the entire infrastructure. There are two types of SIEMs, open source and commercial. In this post we will only consider open source systems.

The one that makes most sense in the cloud native approach we are considering is MozDef (https://github.com/mozilla/MozDef), since it is one of the most modern with a microservice approach where each one is run in a separate Docker container. This means it is extremely scalable, efficient and cloud ready. It is also worth noting it relies on popular open source systems like ElasticSearch for log indexing, Meteor for the web interface, and Kibana for data visualization. Data can be accessed and analysed with typical ElasticSearch queries, which immensely simplifies the learning curve. The architecture is shown below.

According to Mozzilla, MozDef can process over 300 million events per day. Its only limitation is that out of the box it only works with JSON files, but the system can be extended to add more types like XML.

Deploying MozDef in AWS

            In this section we will be deploying MozDef in AWS to run a Proof of Concept (PoC) of the solution and test it out. For that endeavor we will provision an EC2 instance and run the docker containers to set up the system. All this process will be documented in this section.

The first step is to create an EC2 instance, since this is a PoC we will be using a T2.Medium type instance, which is capable of CPU bursts in case it was needed.

After this we need to choose a VPC in which to deploy it. We will use the main one for services in Sister.

Since the default hard drive size is 8GB, we will need to add more to successfully install and run all the docker containers needed in the installation. This is shown in below.

It is always a good practice to add a tag with a name so that the EC2 instance can be located easily in case it is needed.

            Finally, the security group must be configured to allow access to the system. In this case we need the following ports:

• HTTP – 40
• HTTPS – 443 – For the main Web access
• SSH – 22 – For administration until we put it behind the bastion like the rest of the system.
• Kibana – 9090
• Loginput – 8080
• Syslog input – 514

The configuration of the security group is shown in the folowing image.

Once all of this is completed, we can create a PEM (Privacy Enhanced Mail) to connect to the instance via SSH.

It is key before connecting to add an elastic IP to the system. If we do not do so the DNS configuration will change every time the instance is restarted. This is shown below.

The system allocated and assigns an automatic one. For this sample test, we will use 3.231.121.156, which means the instance DNS will be ec2-18-208-230-253.compute-1.amazonaws.com. The assignment process can be seen in the following image.

            With all of this completed we can finally connect to the instance. For that the first step is to assign permissions to the PEM file using chmod 400 MozDefUNED.pem and connect using the commannd ssh -i “MozDefUNED.pem” ec2-user@ec2-3-231-121-156.compute-1.amazonaws.com.

               Once inside, the code for MozDef can be downloaded using wget https://github.com/mozilla/MozDef/archive/v3.1.2.zip (Figure 34) and extracted using unzip v3.1.2.zip (Figure 35).

            With the files extracted, we can navigate into the directory cd MozDef-3.1.2/. Before continuing it is always interesting to update the dependencies using sudo yum update. Once updated, we can install Docker using the Yum package manager (the one available in the AMI) using sudo yum install -y Docker. We can check the version using docker version.

Installing Docker Compose is a bit trickier, but we need to generate the Docker images using the makefiles available. In order to install it we need to download it using sudo curl -L https://github.com/docker/compose/releases/download/1.25.0/docker-compose-`uname -s`-`uname -m` | sudo tee /usr/local/bin/docker-compose > /dev/null

            This will install version 1.25.0 of Docker compose. Once installed we need to add permissions using sudo chmod +x /usr/local/bin/docker-composeand create a symbolic link using ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose.

            It is important to note that trying to use make build to create the docker images will render the following error: ERROR: Couldn’t connect to Docker daemon at http+docker://localhost – is it running?

            In order to solve this, we need to start the docker service using sudo systemctl start docker and finally relaunch using make build. This will initiate the creation of all the Docker images, which is a time-consuming process.

We can finally check to see all the containers are running using docker ps (shown below).

 Summarizing, we have the following addresses:

• http://3.231.121.156  – meteor (Main Wen interface)
• http://3.231.121.156:9090/app/kibana – kibana
• http://3.231.121.156:8080 – loginput
• http://3.231.121.156:514 – syslog input

The main web interface is shown in the following image.

Connecting and testing MozDef in AWS

            Since CloudWatch, the default logging application on AWS uses JSON logs it is really easy to import and connect them to MozDef.

            When a breach is detected, MozDef can be configured to run investigations for a given time. Normally they are run as investigations initially.

Investigations can be scaled up to incidents.

            The main dashboard also allows to pinpoint information geographically, this helps understand possible DDoS attacks from a region for instance.

            Incidents, like the one we triggered before to test the system appear as monsters. This is both a fun and an effective way to be alerted and can easily be used to block an IP address.

            It is important to note, that all of this is handled via Kibana. Which means the panel can be accessed directly to extract and correlate data if more advanced manipulations are needed.

Whew! That was a lot of work! What do you think? Do you find a SIEM useful? Did you like setting up MozDef? Drop me a line in the comments!