Skip to main content

Log agents and collectors

The syslog collector receives syslog from anything on your network that can send it - firewalls, switches, servers, appliances - and ships it to the CyberOptix CTEM Platform for normalization, search, and detection.

It exists because most log sources cannot talk to the platform directly. They speak syslog over TCP to something on their own network, and the collector is that something.

Two processes ship in one package:

ServiceRole
syslog-collectorListens for inbound syslog and writes it to a local queue
syslog-shipperDrains that queue to the platform

They are separate so a break in connectivity to the platform does not drop inbound logs: the collector keeps accepting and queueing, and the shipper catches up when the link returns.

Install​

The collector runs on Ubuntu Server 24.04 and installs from the same repository as the scanner. If this host has never had a Purple Team Software package on it, add the repository first - including the rm -f, which is what keeps the step re-runnable:

sudo rm -f /usr/share/keyrings/purpleteamsoftware-archive-keyring.gpg
wget -O - https://apt.fury.io/purpleteamsoftware/gpg.key | sudo gpg --dearmor -o /usr/share/keyrings/purpleteamsoftware-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/purpleteamsoftware-archive-keyring.gpg] https://apt.purpleteamsoftware.com/ /" | sudo tee /etc/apt/sources.list.d/purpleteamsoftware.list

Install:

sudo apt update && sudo apt install cyberoptix.syslog-collector -y

Same two-stage pattern as a scanner: installing does nothing until the host is bound to your organization.

sudo syslog-link -url https://<your-api-hostname>/ -organization_id <your-organization-id>

That writes baseurl, credentials, mode and organization_id into /etc/optix/collector-config.json.

Configure the listener​

The rest of /etc/optix/collector-config.json decides what the collector listens on. It is not fixed to a particular port - listen_port is yours to choose, and it has to match whatever you configure your log sources to send to.

{
  "baseurl": "https://<your-api-hostname>",
  "organization_id": "<your-organization-id>",
  "mode": "running",
  "listen_port": 6514,
  "tls": true,
  "tls_crt": "/etc/optix/collector.crt",
  "tls_key": "/etc/optix/collector.key"
}
FieldMeaning
listen_portTCP port the collector binds on 0.0.0.0
tlsWhen true, the listener is TLS. When false, syslog arrives in the clear
tls_crt / tls_keyPEM certificate and key, read at startup
moderunning to process, anything else to pause
Use TLS

With tls: false the collector accepts plaintext syslog on an open TCP port, and syslog routinely carries usernames, hostnames, internal addresses and command lines. Terminate TLS at the collector unless the traffic is already inside an encrypted transport.

The certificate has to be valid for the hostname your sources will send to, because senders verify it - rsyslog's StreamDriverAuthMode="x509/name" checks exactly that. TLS 1.2 is the floor.

Start it:

sudo systemctl enable --now syslog-collector.service syslog-shipper.service

Verify​

Both services should be active (running):

systemctl status --no-pager syslog-collector syslog-shipper

Confirm it is bound where you expect:

sudo ss -lntp | grep syslog-collector

Send a test message from another host, replacing the port with your listen_port:

logger -n <collector-host> -P 6514 -T "collector reachability test"

Then watch it arrive:

sudo journalctl -u syslog-collector.service -f

The collector logs the negotiated TLS version and cipher for each connection, so this is also the fastest way to confirm TLS is actually in use rather than silently falling back.

Pointing sources at it​

Configuring the senders - rsyslog, Apache, NGINX, network appliances - is covered in Telemetry and collection, because that is where you manage what the platform ingests rather than how the collector is deployed.

Next​

Last updated on