Skip to content
downpipes docs

Forward the downpipes audit trail to LogRhythm

LogRhythm receives the downpipes audit trail as CEF carried over real syslog transport. On the scheduler tick the engine shapes each audit event as a CEF line, wraps it as an RFC 5424 syslog record, and writes the batch over one TLS socket to your LogRhythm collector.

Unlike QRadar, LogRhythm ships no generic CEF parser, so it does not understand the fields until you have built a bespoke Log Source Type and a matching MPE (Message Processing Engine) rule yourself. This is the heaviest setup of the SIEM guides, and it is closer to writing a parser than clicking a wizard: budget time to author the rule, send test events, and iterate on the regex until the fields extract the way you want.

Because the engine makes the outbound call, a Cloudflare Access perimeter on your console hostname never blocks this: there is no inbound request for Access to turn away.

CEF only parses when it arrives over real syslog transport, an RFC 5424 record over TCP with TLS, by default on port 6514, which is the Syslog over TLS delivery. A plain HTTPS POST of a CEF line is never parsed, and the console blocks the CEF-over-HTTP pairing outright. Cloudflare does not document whether a Worker can open an outbound connection to port 6514, so confirm the connection lands from your own engine with Test send before you rely on it.

What you need

  • A LogRhythm role that can create a custom Log Source Type and author an MPE rule, plus a collector (a System Monitor agent or a syslog relay) that accepts TLS syslog.
  • Owner access to the downpipes console, and confirmation that your engine can reach the collector on port 6514.

Set it up

  1. In LogRhythm, create a custom Log Source Type for this feed, then author an MPE rule (a regex parse policy) that extracts the CEF values you care about from the CEF line, and associate the rule with the Log Source Type. The field names to match are in the sample below. Until the rule exists and matches, LogRhythm stores the events but does not parse them.
  2. Point your LogRhythm collector at a TLS syslog listener and note the address and port it accepts on.
  3. In the downpipes console, open Integrations, choose this vendor’s tile, and set up the SIEM audit push there (owner-only, asks for a fresh step-up sign-in).
  4. Set Delivery to Syslog over TLS, Format to CEF, enter your LogRhythm collector’s address as Syslog host, and leave Port at 6514.
  5. Choose Test send to write one event over the socket (the cursor does not advance), then check whether your MPE rule parsed the fields. Iterate on the rule until it does. Only once the fields extract correctly, choose Enable.

What lands in LogRhythm

Each event is one CEF line wrapped as an RFC 5424 syslog record and octet-counted per RFC 6587, so your MPE rule matches one event per record:

CEF:0|Maelstrom AI|Downpipes|<engine version>|restore-approve|Restore approve|3|rt=1750299248221 suser=ops@acme.example src=203.0.113.7 act=restore-approve outcome=success cs3Label=targetKind cs3=restore cn1Label=seq cn1=4097 flexString1Label=hash flexString1=sha384:22cd...01

The act field is the audit action, suser the operator email, src the source IP, cn1 the sequence number and flexString1 the event hash. Those cn1 and flexString1 values are the ones your rule should capture so a re-sent event dedups rather than double-counts.

Good to know

  • Delivery is at-least-once, not exactly-once. Every event carries a stable seq and a hash; index on either and a re-sent event lands as a duplicate you can drop rather than a second incident. The feed carries operator identity (member emails, source IPs, roles and approver emails) and no backup data or secret values, so apply your LogRhythm data-handling rules to it as you would any access log.
  • The parse work lives entirely on the LogRhythm side; the engine sends the same well-formed CEF regardless. For the shared push mechanics and the pull alternative, see Forwarding the audit log to your SIEM.

Last updated .