Configuring FleetDM

What is FleetDM
- FleetDM is a manager that can scan for software and operating system (OS) level, and browser plugsins vulnerabilities outputting with a Common Vulnerabilities and Exposure (CVE) and Common Vulnerability Scoring System (CVSS) score system from from the MITRE organization.

How is fleets configuration managed

- Fleets configuration within Security Onion is through the saltstack; Ensures the proper configuration is in place at all times and when the service restarts and there are modifications in the local parallel directory, it will automatically be changed by the Saltstack. This was built on a system of simplicity and not complexity where no matter the project, anyone should be able to build a saltstack for better managing of there systems for there environment

Link - https://cve.mitre.org/

What is Common Vulnerabilies and Exposure system (CVE)

- This is a program to identify, define and catalog publicly known vulnerabilities within the community. This also helps other security researchers input there theories and assist in securing infrastructure regarding network infrastructure. MITRE manages the CVE program, master list, number schema, performs CVE items and production activities with processes, automation and CVE rules. Root CVE Number Authority (CNA) manage groups of sub-CNAs and manages, onboards and admits to Sub-CNAs. Sub-CNAs submit the vulnerabilities to the Root CNA from the Sub-CNA when they make it go public.

What is the Common Vulnerability Scoring System (CVSS)

- CVSS is a system on which the industry scores a vulnerbaility from a scale of 0.1 to 10.0 depending on the level of complexity to execute the Vulnerability whether it be from a Remote Code Execution (RCE) with requirements of user input or even without user input.

For example, we have an XSS vulnerability for the a-blog cms service where a user can inject arbitrary code (any kind of code) to the system. The resolution per the CVE was to update the software in regards to the CVE resources, which also demonstrates the vulnerabilities with examples.

Based on the standards of Confidentiality, Integrity and Availability, (CIA Triad) shows the score is based on the difficulty of vulnerability, Attack Vector, impact of the exploit and many more factors

CVE Link - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-24374

CVSS Link from NIST - https://nvd.nist.gov/vuln/detail/CVE-2022-24374

Link - https://jvn.jp/en/jp/JVN14706307/index.html

Risk Assessment

- We have the ability to use automation within Fleet to use the Mitre CVE and CVSS system to calculate probabilities of existing exploits and can input remediation techniques provided by the system and ensure we check both manually and automatically after remediation has been implemented throughout our environment.

Queries

- Within Fleet, you can run Server Query Language (SQL) queries throughout your environment for system checks, misconfigurations, crash dumps, logging of powershell. plugins for Domain Name Service (DNS) Dynamic Link Library (DLL) registry exits and you can even create your own queries.

What is the Saltstack

- Saltstack is built on Python using an event-driven remote execution framework to deploy, configure, and manage complex Information Technology (IT) systems such as Security Onion with many different services on one single host machine. This can help in managing servers, virtual machines, containers, databases, web servers, network devices and many more consisting of a network connection or hardware based. Salt is used for Configuration management, automation, provisioning and orchestration. The Salt Architecture consists of the Salt Master, Event Bus and Salt Minions

Salt-Master

- The salt-master issues out commands to the salt-minions who execute the command to a client. The salt-master is running a service. It issues commands to one or more Salt Minions which are servers running the salt-minion service within the particular salt master.

Salt-Minion

- The salt-minion is a server or servers that are running the salt-minion service when a job is ran from the salt-minion, it will run on the services that are running and return information back to the salt-master. Salt uses two ports by default for the minions to communicate with their master. These ports work in concert to receive and deliver data to the message bus. Salt's message bus is using ZeroMQ which creates an asynchronous network topology to provide fastest communication possible.

Open Event System (Event Bus)

- This is used for inter-process communications between the salt master and salt minions.

- Events are seen by both the master and minons

- Events can be monitored and evaluated by both

Minions see jobs and results by subscribing to events published on the event system. Salt uses a pluggable event system with two layers

- ZeroMQ (0MQ) - Current default socket-level library providing a flexible transport layer

- Tornado - Full TCP-based transport layer event system.

Salt States

- The sat states are a method of configuring minions by which state a minion should be in which makes configuration management possible. The salt staes can deploy and manage infrastructure with YAML files which you can automate with recursive and predictable tasks by queuing jobs for salt without any user input and can also add more conditional logic to state files with Jinja.

The top file top.sls

- This file maps the salt states to their applicable minions such as FleetDM for example

The top file Highstate execution

- This runs all the salt states outlined in the top.sls file in a single execution

Salt Pillar

- This takes the data defined on the Salt Master and distributes it to the Minions as needed and is primarily used to store secrets or other highly sensitive data, such as account credentials, cryptographic keys or passwords. The pillar is also useful for storing non-secret data that you can have in the state files such as configuration data.

The salt pillar brings data into the cluster from the opposite direction such as grains since the grains are data generated from the minion such as FleetDM, the pillar data is generated from the master.

Pillars are organized similar to the states in a Pillar state stree, where top.sls acts to coordinate pillar data to environments and minions to the data. Information is transferred using pillar has a dictionary generated for the targeted minion and encrypted with the minions key for secure data transfer.

Beacons and Reactors

- Beacons are a monitoring tool that can listen for a variety of system processes on Salt Minions. Beacons can also trigger reactors which can help implement a change or troubleshoot an issue such as a service response times out, the reactor will restart the service automatically.

The beacons are usually used for a lot of purposes such as

- Automated reporting

- Error log delivery

- Microservice monitoring

- User shell activity

- Resource monitoring

When beacons are added with reactors, beacons can automate pre-written responses to infrastructure and application issues. Reactors expand salt with automated responses with remediation states.

Example below modifying the Security Onion fleet salt configuration file, saving and restarting the Fleet minion, we notice the changes have been reverted in the configuration file.

Going to the minions configuration file for the os-query, you can modify the osquery-config.conf file

Location of FleetDM minion configuration file - /opt/so/conf/fleet/packs

Modifying the salt-minion configuration file for Fleet with vim, we can change a setting and restart the fleet minion

Command - vim osquery-config.conf

Changes made -

Set the enable_software_inventory from false to true

Added the following configuration to allow vulnerabilities to be scanned for CVEs below

vulnerbailities:

databases_path: /tmp/vulndbs

We can then restart the fleet service with the following command within security onion

Command (as root) - so-fleet-restart

Command as any other user requiring super user permissions - sudo so-fleet-restart

Salt Master sent the job to the minions confirming the Salt job was properly done and the Minion reported a change in the configuration file for osquery. It was then automatically changed by the minion as noticed below.

Diagram provided from saltstack documentation website:

https://docs.saltproject.io/en/latest/topics/salt_system_architecture.html

Scheduling Queries in your environment

- You have the ability to schedule queries throughout your environment every day, hour, 12 hours, weekly and even as little as every 15 minutes. Ensure you take note into your resource usage when running Queries as it may cause issues if you have a large database.

Policies

- Can create your own policies for all of your hosts to ensure you are following your organizations standards whether it's password lengths, updates are automatically enabled and you can even make your own!

Configuring FleetDM on Security Onion

How to install Security Onion - https://www.stephendick.tech/security-onion-1/how-to-install-security-onion

First, we need to allow network access to our Security Onion Manager node when installing the osquery packages on systems on port 8090

SSH into the security onion management node

Note - I require super user privileges to use the SSH protocol on my machine

Command - ssh sdick@192.168.80.50

Allow Security Onion network access by running the command below with super user permissions

Command - sudo so-allow

Select o for Osquery

Enter the IPv4 address of the system you want FleetDM to monitor or add a whole subnet

My input - 192.168.85.2

To confirm the firewall configuration successfully added, log in as the root user

Command - sudo su

Change directories into the firewall configuration rules

Command - cd /opt/so/saltstack/local/salt/firewall/

list the files to ensure you see 3 files listed
Command - ls

Files listed:
assigned_hostgroups.local.map.yaml

hostgroups.local.yaml

portgroups.local.yaml

Either use your favorite text editor to see the yaml file or use cat to show all the information in the file

I will be using the cat command

Command - cat hostgroups.local.yaml

And below, we can see that osquery is allowed within the Security Onion Firewall

Next we will allow the system in question to have access to the Security Onion web user interface for the agent installation,

Note - You can also create your own FTP server for file transfers for this as well as a substitute

Run the following command still as the Root user

Command - so-allow

Select a for the Analyst role to allow ports 80 and 443

Enter the IPv4 address of the system

IPv4 address - 192.168.85.2

On the system for implementing FleetDM (Windows Server 2022), navigate to the IP address of the Security Onion web user interface

https://192.168.80.50

Select Advanced

Select Continue to 192.168.80.50 (Unsafe)

Sign into the Security Onion console

On the left hand side, select Downloads

Under the section osquery Packages and Configs, choose the MSI (Windows) installer

Select to open the file

After finishing the install, lets verify it's connected to FleetDM in Security Onion on your management system, not the system you have installed the osquery package

On the left hand side, select the FleetDM application

Sign into FleetDM

Navigate to the Hosts tab at the top left of the screen and we will notice Windows Server 2022 has been added to our list of hosts

When selecting the Windows Server, we can now Query the system for any possible issues and monitor up-time and disk usage

Next we will turn on Software Inventory to search for installed software and manage automation for detecting any vulnerabilities/CVEs on any hosts we allow

We will start by connecting to the docker container hosting Fleet

Command - sudo docker exec -t so-fleet /bin/ash

We will now set the configuration IP address of the fleet configuration of the loopback address of the Security onion node with port 8080

Command - fleetctl config set --address https://127.0.0.1:8080/ --tls-skip-verify --url-prefix /fleet

Log into the fleetctl with the following command using the credentials you log into the web user interface of FleetDM

Command - fleetctl login

Next, we will copy the current configuration to a new file named fleet.config

Command - fleetctl get config > fleet.config

Change the vulnerability configuration setting to True with the following command

Command - sed -i 's/enable_software_inventory: false/enable_software_inventory: true/' fleet.config

Finally, Apply the configuration to fleet with the command below

Command - fleetctl apply -f fleet.config

Next we will exit the container and restart the fleet containers

Command - exit

Command - sudo so-fleet-restart

When this is finished, a confirmation will show such as below showing a change has happened successfully with no errors/failures

Navigate to Security Onion and sign in

On the left hand side, select the FleetDM tool

Sign into Fleet

As you can see, we have software loading for the agents

Select the Hosts tab on the top left corner for confirmation

Either select your user agent of Security onion or another Host

In my example, im choosing both to show the results of the software logs

The Security Onion list of software

Barebone basic install of Windows Server 2022 software configuration with Active Directory

Next, we will configure the CVE list for fleet to detect and notify us of the CVEs for our environment

Connect to security using ssh (I use sudo due to my user account policy

Connect to the Fleet docker container

Command - sudo docker exec -t so-fleet /bin/ash

2nd command to set the fleetctl config - fleetctl config set --address https://127.0.0.1:8080/ --tls-skip-verify --url-prefix /fleet

Log into fleet

Command - fleetctl login

Copy the current fleet configuration with the following command

Command - fleetctl get config > fleet.config

Take note of the directory where vulnerabilities be logged and stored within fleet with CVE history from NIST from 2002 up to the present year of 2023

Directory - /tmp/vulndbs

Navigate to the root directory with the following command

Command - cd /

Next, edit the text editor with your favorite text editor; I am using vi in this use case

Commands for vi - https://man7.org/linux/man-pages/man1/vi.1p.html

Command - vi fleet.config

Use the command cat to view the fleet.config file to confirm changes while still connected to fleetctl

Command - cat fleet.config

Confirm changes made as shown below

Modification - databases_path: "/tmp/vulndbs"

Apply the changes to the fleet.config file with the command below

Command - fleetctl apply -f fleet.config

Next, we will exit the fleet container and restart fleet

Command 1 - exit

Command 2 - sudo so-fleet-restart

Sign into Security Onion

Select the FleetDM tool on the left hand side

Sign into fleet

Select the Vulnerable tab at the bottom left corner and you will notice the vulnerabilities will populate in the location for all hosts showing all running services on all hosts available that are allowed through security onion

Next, select the Software tab at the top of the page

Select the host of your choice

Select the drop down menu and filter by Vulnerable software and you will notice all the vulnerable software for that specific host with hyper links to the specific CVE or CVEs listed for further analysis along with there CVSS scores