Skip to content
Resource Library
SIEM 6 min read

Getting logs from devices that can't run an agent

Firewalls, switches, NAS boxes, printers, hypervisors — half your attack surface can't run software. Syslog is how it gets watched, and it's simpler than it sounds.

The half of your network agents can't see

Endpoint agents cover laptops and servers, but walk your rack and count what's left: the firewall that sees every packet, the switches that know every port, the NAS holding backups, the hypervisor under your VMs, printers, badge controllers, UPS units. These devices authenticate administrators, accept configuration changes, and sit on attack paths — and none of them will ever run your agent. They are also disproportionately interesting to attackers, because a firewall admin login or a NAS wipe is high leverage.

Every one of them, however, speaks syslog — a protocol from 1980s Unix that survives because it is trivially simple: a device sends short text lines to an IP address and port you configure. That is the entire integration.

How the pattern works

The standard architecture is a collector on your LAN: devices send syslog (UDP or TCP port 514) to one always-on machine on the local network, and that machine forwards the stream to your SIEM over encrypted HTTPS. Local receipt matters for two reasons: raw syslog is unencrypted, so it should never cross the internet directly; and a LAN hop keeps device configuration simple — one IP address, no credentials, no cloud endpoints on your firewall.

In Cybermatic's case the collector already exists: the Discovery Agent — the one finding unmanaged devices on your network — doubles as the syslog receiver. If you run one, your syslog infrastructure is already installed; if not, it is a two-minute install on any always-on machine, one per network segment.

Configuring the sender: the five-minute version

On each device, find the logging or remote-syslog setting — vendors bury it in different menus but it always reduces to the same three fields: server (your collector's LAN IP), port (514), protocol (UDP is fine; TCP if offered). Firewalls: look under Log Settings or Log Forwarding. Managed switches: Logging host. Synology and QNAP NAS: Log Center → Log Sending. VMware ESXi: Syslog.global.logHost in advanced settings.

Send what the device considers security-relevant if it offers filtering — authentication, configuration changes, VPN events — rather than full debug output. Within a minute of saving, events should appear in your SIEM's search and the device should register as a log source. If nothing arrives, the usual culprits are a host firewall on the collector machine blocking 514, or a VLAN that can't reach the collector — which is why one collector per segment is the rule.

What to watch once it flows

Network-device logs shine in correlation. A brute-force run shows up as firewall denies, then SSH failures on a server, then a Windows lockout — three sources, one attacker, and a SIEM that correlates by entity turns them into a single offense instead of three disconnected alerts. Admin logins to network gear deserve alerts of their own: legitimate ones are rare and memorable, which makes the illegitimate ones easy to spot.

Also watch the silence. A log source that stops talking is either a dead device or someone covering tracks — both worth knowing within a day. Cybermatic flags sources silent for more than 24 hours on the Log Sources page, with per-source ingest history so a slow fade is as visible as a hard stop.

Security Essentials, Weekly

A practical weekly briefing on real-world security misconfigurations, why they matter, and how to fix them.

One email a week, unsubscribe any time. We use your address only to send the briefing — see our Privacy Policy.