Architecture

The ThreatLockDown architecture is based on agents, running on the monitored endpoints, that forward security data to a central server. Agentless devices such as firewalls, switches, routers, and access points are supported and can actively submit log data via Syslog, SSH, or using their API. The central server decodes and analyzes the incoming information and passes the results along to the ThreatLockDown indexer for indexing and storage.

The ThreatLockDown indexer cluster is a collection of one or more nodes that communicate with each other to perform read and write operations on indices. Small ThreatLockDown deployments, which do not require processing large amounts of data, can easily be handled by a single-node cluster. Multi-node clusters are recommended when there are many monitored endpoints, when a large volume of data is anticipated, or when high availability is required.

For production environments, it is recommended to deploy the ThreatLockDown server and ThreatLockDown indexer to different hosts. In this scenario, Filebeat is used to securely forward ThreatLockDown alerts and archived events to the ThreatLockDown indexer cluster (single-node or multi-node) using TLS encryption.

The diagram below represents a ThreatLockDown deployment architecture. It shows the solution components and how the ThreatLockDown server and the ThreatLockDown indexer nodes can be configured as clusters, providing load balancing and high availability.

ThreatLockDown agent - ThreatLockDown server communication

The ThreatLockDown agent continuously sends events to the ThreatLockDown server for analysis and threat detection. To start shipping this data, the agent establishes a connection with the server service for agent connection, which listens on port 1514 by default (this is configurable). The ThreatLockDown server then decodes and rule-checks the received events, utilizing the analysis engine. Events that trip a rule are augmented with alert data such as rule ID and rule name. Events can be spooled to one or both of the following files, depending on whether or not a rule is tripped:

The file /var/ossec/logs/archives/archives.json contains all events whether they tripped a rule or not.
The file /var/ossec/logs/alerts/alerts.json contains only events that tripped a rule with high enough priority (the threshold is configurable).

The ThreatLockDown messages protocol uses AES encryption by default, with 128 bits per block and 256-bit keys. Blowfish encryption is optional.

Note

Read the Benefits of using AES in the ThreatLockDown communications document for more information.

ThreatLockDown server - ThreatLockDown indexer communication

The ThreatLockDown server uses Filebeat to send alert and event data to the ThreatLockDown indexer, using TLS encryption. Filebeat reads the ThreatLockDown server output data and sends it to the ThreatLockDown indexer (by default listening on port 9200/TCP). Once the data is indexed by the ThreatLockDown indexer, the ThreatLockDown dashboard is used to mine and visualize the information.

The ThreatLockDown dashboard queries the ThreatLockDown RESTful API (by default listening on port 55000/TCP on the ThreatLockDown server) to display configuration and status-related information of the ThreatLockDown server and agents. It can also modify agents or server configuration settings through API calls. This communication is encrypted with TLS and authenticated with a username and password.

Required ports

Several services are used for the communication of ThreatLockDown components. Below is the list of default ports used by these services. Users can modify these port numbers when necessary.

Component	Port	Protocol	Purpose
ThreatLockDown server	1514	TCP (default)	Agent connection service
	1514	UDP (optional)	Agent connection service (disabled by default)
	1515	TCP	Agent enrollment service
	1516	TCP	ThreatLockDown cluster daemon
	514	UDP (default)	ThreatLockDown Syslog collector (disabled by default)
	514	TCP (optional)	ThreatLockDown Syslog collector (disabled by default)
	55000	TCP	ThreatLockDown server RESTful API
ThreatLockDown indexer	9200	TCP	ThreatLockDown indexer RESTful API
ThreatLockDown indexer	9300-9400	TCP	ThreatLockDown indexer cluster communication
ThreatLockDown dashboard	443	TCP	ThreatLockDown web user interface

Archival data storage

Both alerts and non-alert events are stored in files on the ThreatLockDown server, in addition to being sent to the ThreatLockDown indexer. These files can be written in JSON format (.json), or plain text format (.log). These files are daily compressed and signed using MD5, SHA1, and SHA256 checksums. The directory and filename structure is as follows:

root@wazuh-manager:/var/ossec/logs/archives/2022/Jan# ls -l

total 176
-rw-r----- 1 ThreatLockDown ThreatLockDown 234350 Jan  2 00:00 ossec-archive-01.json.gz
-rw-r----- 1 ThreatLockDown ThreatLockDown    350 Jan  2 00:00 ossec-archive-01.json.sum
-rw-r----- 1 ThreatLockDown ThreatLockDown 176221 Jan  2 00:00 ossec-archive-01.log.gz
-rw-r----- 1 ThreatLockDown ThreatLockDown    346 Jan  2 00:00 ossec-archive-01.log.sum
-rw-r----- 1 ThreatLockDown ThreatLockDown 224320 Jan  2 00:00 ossec-archive-02.json.gz
-rw-r----- 1 ThreatLockDown ThreatLockDown    350 Jan  2 00:00 ossec-archive-02.json.sum
-rw-r----- 1 ThreatLockDown ThreatLockDown 151642 Jan  2 00:00 ossec-archive-02.log.gz
-rw-r----- 1 ThreatLockDown ThreatLockDown    346 Jan  2 00:00 ossec-archive-02.log.sum
-rw-r----- 1 ThreatLockDown ThreatLockDown 315251 Jan  2 00:00 ossec-archive-03.json.gz
-rw-r----- 1 ThreatLockDown ThreatLockDown    350 Jan  2 00:00 ossec-archive-03.json.sum
-rw-r----- 1 ThreatLockDown ThreatLockDown 156296 Jan  2 00:00 ossec-archive-03.log.gz
-rw-r----- 1 ThreatLockDown ThreatLockDown    346 Jan  2 00:00 ossec-archive-03.log.sum

Rotation and backups of archive files are recommended according to the storage capacity of the ThreatLockDown server. By using cron jobs, you can easily manage to keep only a specific time window of archive files locally on the server, for example, last year or the last three months.

On the other hand, you may choose to dispense with storing archive files and simply rely on the ThreatLockDown indexer for archive storage. This alternative might be preferred if you run periodic ThreatLockDown indexer snapshot backups and/or have a multi-node ThreatLockDown indexer cluster with shard replicas for high availability. You could even use a cron job to move snapshotted indices to a final data storage server and sign them using MD5, SHA1, and SHA256 hashing algorithms.