Syslog ingestion

Syslog is how most non-Windows gear announces what it’s doing, and for a lot of that gear it’s the entire monitoring story — a firewall, switch, camera, or intercom that can’t hold a certificate can still tell Skans the instant something happens. Skans runs a syslog listener that accepts those messages, ties each one to the device that sent it, and lands it where the alert engine can act on it. This is push-first monitoring for anything with a syslog target field: point the device at Skans and it announces on occurrence, no polling interval to tune.

Where the listener runs #

The syslog listener is part of the Skans collector service — a separate, low-privilege worker Skans calls Plane B. It is deliberately isolated from the control plane because syslog is untrusted network input: anything on the wire can send a UDP packet to port 514, so the code that parses it runs with the least privilege it can and never sits inside the control plane.

The listener binds udp/514 and accepts both common wire formats:

Skans auto-detects which format a message is in — you don’t configure it per device.

What happens to a message #

Every accepted message runs the same short path:

1. Parse — the raw datagram is decoded as RFC 3164 or RFC 5424.
2. Tag / correlate — the message is matched to the device that sent it, so the log line is attached to a real entity in the console, not just a source IP.
3. Land — it’s written to OpenSearch index skans-netlog-* with Source=syslog.
4. Evaluate — the always-on alert engine reads netlog and turns occurrences into correlated, per-device findings — not a raw log firehose.

This is the same push-first, event-driven model the rest of Skans monitoring uses: the device announces on occurrence, Skans correlates, and you see a bounded number of meaningful alerts rather than every line the device ever emitted.

Security: source-IP allowlist #

Because the listener takes untrusted input, it does not accept syslog from anything on the network. Only configured device IPs are accepted; everything else is dropped. This is part of the same untrusted-input isolation that puts the collector on its own plane.

The allowlist lives in C:\Skans\collectors.json under Syslog.AllowedSources:

JSONCopy
{
  "Syslog": {
    "AllowedSources": [
      "192.168.103.1",
      "192.168.103.254"
    ]
  }
}

What to point at it #

Any syslog-capable device is a candidate — firewalls, switches, cameras, intercoms, gateways, and similar network and OT gear. Set the device’s syslog/remote-logging target to the Skans host on udp/514, then add its source IP to the allowlist. For gear that can’t hold a certificate and can’t run an agent, syslog is frequently the entire monitoring value Skans provides for it.

Proven live #

This is built and exercised end-to-end, not just wired up: an OPNsense firewall configured to send syslog to udp/514 was ingested through the whole path — RFC 5424-parsed, device-tagged to the firewall, and searchable in skans-netlog with Source=syslog. That’s the honest state today: one real device class proven through the full pipeline; other syslog-capable gear uses the identical path.

Retention #

Netlog data lands in OpenSearch under a ~365-day retention posture. Be clear that this is a policy, not a physical limit — retention is governed by index lifecycle configuration and the storage you give it, and it can be tuned. The default intent is roughly a year of searchable network log history.

Next #

• Monitoring & alerts
• Ports & protocols
• Install & approve the Windows agent
• Enroll a device