Collecting syslog from firewalls and appliances

Syslog is how network equipment talks. A firewall, a switch, a VPN concentrator, a Linux server, a hypervisor and most storage appliances will all happily send you a stream of one-line messages over UDP or TCP if you give them an address. It is the oldest and least structured way to collect logs, and for anything that is not a cloud service or a Windows machine it is usually the only way.

This article explains what the platform accepts, and — at length, because it is the part that actually decides whether your logs are kept — how an inbound message is attributed to your organisation.

What the listener accepts

The receiver is described in its own source as a cheap RFC 3164 and RFC 5424 aware receiver, and that is a fair description. It reads the priority, timestamp, host and message from either the old BSD format or the newer structured one, and where a line names no host it falls back to the peer address the packet came from — which is nearly always what you want, because the most common misconfiguration on an appliance is a blank or wrong hostname.

Framing is newline-delimited only. The octet-counting framing described in RFC 6587 is not implemented. Most equipment sends newline-delimited by default; if yours offers a choice, choose that. A device using octet counting will produce lines with a stray length prefix rather than an error, which is a confusing symptom to debug from the other end.

Which host and port

Port 6514 — the IANA-registered port for syslog over TLS — at the hostname the console shows in the wizard's Your logs will arrive here line. The hostname matters more than usual here, because it is the name in our certificate and the name your sender pins: the rsyslog configuration we hand out sets StreamDriverPermittedPeers to it, so a sender pointed at a bare IP address instead will refuse to connect. Copy the hostname from the wizard rather than resolving it and using the address.

The listener is started by the collection worker with the port configured per deployment. The wizard reads that advertisement live — it is refreshed by the worker every minute and withdrawn when the worker stops — so if the wizard shows the address, the socket exists; and if the wizard says syslog is not available, it is not, whatever this article says.

The private certificate authority

Our server certificate is issued by a Qorionix certificate authority that is not in any operating system's trust store. That is deliberate: it lets us rotate the listener's certificate without waiting on a public issuer, and it means only senders you have explicitly configured with our CA will connect. The consequence is one extra step on your side — the sender needs the CA's certificate as a file. The wizard's Download CA certificate button fetches it from the console (signed in, as you) and saves it as qorionix-syslog-ca.pem; every configuration snippet the wizard produces already references that file name.

What typically sends syslog, and which parser to ask for

Anything with a management interface and no cloud API. In practice, for an organisation of this size, the list is short and predictable.

How a message is attributed to your organisation

This is the important section. A syslog message carries no credential. TLS proves to your sender that it reached us; it does not prove to us who the sender is — the client presents no certificate, and the line itself has no token or header. So the listener has to decide, for every single line, which customer it belongs to, using the only thing it has: the address the connection came from.

That decision is made by a resolver backed by a table of address ranges, one row per sending device or subnet, each owned by exactly one organisation. Matching is longest-prefix, so you can map a whole branch subnet to a tenant and still carve out a single appliance within it — a /32 entry beats the enclosing /24. Lookups are cached in memory for sixty seconds and the cache is bounded at 8,192 entries, so a scanner spraying a large range at the port cannot grow it without limit.

If no registration matches, the line is dropped. Not stored under a default tenant, not held for later, not guessed at — discarded, counted, and a message logged on our side. That is the correct behaviour and it is worth understanding why: the alternative to dropping an unattributable message is putting one customer's firewall logs into another customer's security telemetry, and there is no version of that which is acceptable. A connection that fails the TLS handshake is closed and counted the same way, before any of its bytes are read as syslog.

The rate limit on that message is not laziness. Without it, one misconfigured appliance sending thousands of lines a second would cause thousands of identical log lines a second on our side, which is its own outage.

Registering a sender in the console

Registration is done in the console under SIEM → Log sources → Connect something, choosing Firewall, switch or server (syslog over TLS). The form asks for a name, the address the device sends from, and the parser. The address is the registration: it is written to the table the listener's resolver reads, and the wizard's third step then shows the exact configuration for the device — the host and port, the CA download, and copy-paste blocks for rsyslog, syslog-ng, FortiGate, Palo Alto or Cisco ASA depending on the parser you chose — plus a firewall note. Nothing about that page is descriptive only; the row it writes is the row that decides attribution.

1. 1

   Register the sender's public address

   The address our listener sees is the one your traffic leaves your network from, which for a device behind NAT is your firewall's public address, not the device's private one. A single address becomes a /32 automatically; a range like 203.0.113.0/28 covers a site.

2. 2

   Install the CA on the sender

   Download qorionix-syslog-ca.pem from the wizard and put it where the snippet expects it (/etc/ssl/certs/ for rsyslog and syslog-ng; the certificate store on an appliance).

3. 3

   Apply the snippet and restart the sender

   Then come back to the Log sources list. The source moves from Waiting for the first event to Collecting when the first line is stored, usually within a minute.

One constraint applies regardless of who creates the row: address ranges owned by different organisations may not overlap. The database refuses it outright, because an ambiguous resolution on an ingest path is a cross-tenant leak waiting to happen. The refusal reads:

syslog peer_cidr <range> overlaps a range owned by organization <id>

In practice this only bites if you register private address space that another customer also claims, which is common — so register the public address your traffic leaves from, not only the private address of the appliance. The resolver sees the source address as it arrives.

The security trade you are making

Say this plainly: TLS encrypts the transport and lets your sender verify us, but it does not authenticate your sender to us. Anyone who can complete a TLS connection to the listener from an address inside your registered range can inject events attributed to your organisation. That is a much smaller set than with UDP — an attacker has to hold a real TCP connection from the right address, not spoof a datagram — but it is not zero, and the remaining controls are the ones you choose.

• Keep the registered range as small as you can. A /32 for a single firewall is better than the /24 it lives in, and far better than a cloud provider's shared egress range.
• Keep verification on. The snippets verify our certificate by name against the CA; leave them that way, so your sender can never be redirected.
• Use the HTTP Event Collector for anything that can speak HTTPS. It is authenticated with a token per sender, encrypted in transit, and tells you whether your events were stored. Syslog over TLS is what you use when the device cannot do better.

One more failure mode worth naming: if the storage layer rejects an accepted line, that is now logged as siem ingest: syslog sink rejected event rather than discarded. It used to be discarded, which made a listener that accepted and dropped everything look perfectly healthy.

What to read next

1. Send events with the HTTP Event Collector — the authenticated alternative, and the right choice wherever it is possible.
2. What a firewall log actually becomes — field by field, what each of the three appliance parsers extracts and what it leaves in the raw line.
3. How your logs are normalised — the schema a firewall line is written into, and which fields a device-specific parser fills in.
4. Connecting your first log source — the per-source status table for everything else.