System Requirements


Supported Agents

An explanation of the Threat Stack support policy is available in the Threat Stack Support Policy article

Threat Stack supports the following Agents:

Supported OSs

An explanation of the Threat Stack support policy is available in the Threat Stack Support Policy article

Threat Stack supports the following 64-bit Linux OSs:

Amazon CentOS CoreOS Debian RedHat Ubuntu
Supported Versions Minimum Kernel Notes
amzn2-20181024 4.14

Only supported by Agent 2.0.

amzn-2018.03 4.14 N/A
amzn-2017.09 4.9.51 N/A
amzn-2017.03 4.9 N/A


Threat Stack validates performance against the supported OS list. Customers who choose to use a different Linux OS will fall outside the Threat Stack Support Policy.

Supported Browsers

Threat Stack supports the latest versions of the following browsers:

  • Google Chrome (latest stable release)
  • macOS Safari (latest stable release)

Network Access

Threat Stack Agents require outbound access (TCP 443) to communicate to the platform.

  • (TCP 443)
  • (TCP 443)

Review Configure Agent Network Access article for additional whitelisting instructions.


Threat Stack does not support proxying our platform with customer environments.


Threat Stack offers support for behavior and event monitoring on Docker containers running natively on the host.

Version Minimum Kernel Notes                                                                                         
Docker 1.8.0 - 17.03.2-ce 3.10  N/A

Known Conflicts in Agent 1.x Series

Linux Limitation with auditd

There is a known Linux issue where the default auditd process only allows one connection for audit socket control. As a result, any applications that use auditd conflict with the Threat Stack Agent over access to socket control. This can cause customer issues for several reasons:

  • The customer uses non-Threat Stack audit rules to process logs.
  • The customer sends all logs to an SIEM or other log aggregator.
  • The customer deploys non-Threat Stack agents that need access to auditd data.


Enable raw_log for the Threat Stack Agent. The raw_log outputs all logging from tsauditd to log files. Those log files are then stored in two locations:

  • Threat Stack tsaudit.log
  • The OS's defined auditd log in /var/log/, through which all other applications can access auditd data, thus preventing the audit socket control conflict.


tsauditd logs contain far more information than the standard tsaudit logs.

To enable raw_log for the Threat Stack Agent:

  1. Navigate to /opt/threatstack/etc/
  2. In your text editor of choice, open the audit.config.json file.
  3. In "raw_log":, at the same depth as filter, nnsleep, and noop, add the following:

    For an example, see below

  4. Restart the Threat Stack Agent with the following command:
    sudo cloudsight restart
  5. On the OS, disable auditd.
  6. Point any application that needs access to auditd data to the raw event stream, in this case /opt/threatstack/cloudsight/logs/tsaudit-raw.log. This prevents non-Threat Stack applications from subscribing to the audit socket and causing conflicts with the Threat Stack Agent.

Example of raw_log enabled for the Threat Stack Agent:


"threatstack": {

"auditd": {

"cpumon": {

"inc-by": 300,

"dec-by": 50,

"avg-after": 5,

"ival-sec": 1,

"ival-usec": 0


"extra-netinfo": true,

"max-eoe-flush": 100,

"noop": 3,

"nnsleep": 1,


"filter": "/opt/threatstack/etc/tsauditd.lua",

raw_log Name Rotation

The raw_log naming convention rotates between the name provided in audit.config.json (in the example above, tsaudit-raw.log) and the name with a ".1" appended (using the example above, tsaudit-raw.log.1).


Threat Stack renames tsaudit-raw.log to tsaudit-raw.log.1 and then creates a new tsaudit-raw.log file with new content.

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request



Article is closed for comments.