Skip to content
downpipes docs

Forward the downpipes audit trail to Wazuh through S3

Wazuh reads the downpipes audit trail from an object store rather than a socket. On the scheduler tick the engine writes each batch of audit events as one NDJSON object into an S3-compatible bucket you choose, and Wazuh’s aws-s3 module reads the objects from that bucket. This is the universal fallback: any Wazuh that can reach an S3 API can consume it, with no open inbound port and no syslog listener.

The one-time step is to configure the aws-s3 module (a Wazuh wodle) to read your bucket. If you want event-driven pickup rather than a fixed poll, that step also wires an SQS queue the bucket notifies when a new object lands.

Because the engine writes outbound to the bucket, a Cloudflare Access perimeter on your console hostname is not involved at all.

What you need

  • A Wazuh manager where you can edit ossec.conf and enable the aws-s3 module, plus a key pair (an access key id and secret) that can read the bucket.
  • An S3-compatible bucket reachable by both Wazuh and your engine (AWS S3, Cloudflare R2, or any S3 API), and Owner access to the downpipes console with a key pair that can write to that bucket.

Set it up

  1. Create or choose an S3-compatible bucket for the audit objects. If you want Wazuh to pick up new objects as they land rather than on a fixed poll, create an SQS queue and set the bucket to notify it on object-create.
  2. 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).
  3. Set Delivery to S3 bucket (drop). Enter the S3 endpoint URL, Bucket, Region (use auto for Cloudflare R2), an optional Key prefix, and the Access Key ID and Secret Access Key that can write to the bucket. The drop always writes NDJSON, one raw event per line, so the Format select does not apply to this sink.
  4. Choose Test send to write one object, confirm it appears in the bucket (the cursor does not advance), then choose Enable. From the next tick the engine writes each batch as one NDJSON object under your prefix, keyed by timestamp and sequence range.
  5. In Wazuh, enable the aws-s3 module in ossec.conf, point it at the same bucket (and the SQS queue if you created one), and give it credentials that can read the objects. Reload Wazuh and confirm it ingests the NDJSON.

What lands in the bucket

Each batch is one NDJSON object, and each line is a raw audit event:

{"seq":4097,"ts":"2026-06-19T02:14:08.221Z","actorEmail":"ops@acme.example","actorMethod":"access","sourceIp":"203.0.113.7","action":"restore-approve","outcome":"success","target":{"kind":"restore","runId":"run_01H...","approverEmail":"lead@acme.example"},"prevHash":"sha384:11ab...90","hash":"sha384:22cd...01"}

Wazuh’s aws-s3 module reads each object line by line, so the action, outcome, actorEmail and sourceIp fields are available to your Wazuh rules and decoders.

Good to know

  • The S3 drop is the universal fallback. It needs no open inbound port and no syslog listener, and the bucket is yours, so its retention and access policy are yours to set. Because the engine only ever writes new objects, you can point other readers at the same bucket without affecting Wazuh.
  • Delivery is at-least-once, not exactly-once. Every event carries a stable seq and a hash; dedup 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 Wazuh data-handling rules to it as you would any access log. For the shared push mechanics and the pull alternative, see Forwarding the audit log to your SIEM.

Last updated .