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:
- 2.0 (Host and Containerized). For more information, see Agent Release Changelog
- 1.9.0 (Host). For more information, see Agent Release Changelog
- 1.8.0C (Containerized). For more information, see Agent Release Changelog
- 1.8.0 (Host). For more information, see Agent Release Changelog
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:
Note
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.
- app.threatstack.com (TCP 443)
- cssensors.threatstack.com (TCP 443)
Review Configure Agent Network Access article for additional whitelisting instructions.
Note
Threat Stack does not support proxying our platform with customer environments.
Containers
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.
Workaround
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.
Note
tsauditd logs contain far more information than the standard tsaudit logs.
To enable raw_log for the Threat Stack Agent:
- Navigate to /opt/threatstack/etc/
- In your text editor of choice, open the audit.config.json file.
- In "raw_log":, at the same depth as filter, nnsleep, and noop, add the following:
"/opt/threatstack/cloudsight/logs/tsaudit-raw.log"
For an example, see below
- Restart the Threat Stack Agent with the following command:
sudo cloudsight restart
- On the OS, disable auditd.
- 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,
"raw_log":"/opt/threatstack/cloudsight/logs/tsaudit-raw.log",
"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).
Note
Threat Stack renames tsaudit-raw.log to tsaudit-raw.log.1 and then creates a new tsaudit-raw.log file with new content.
Comments
Article is closed for comments.