Connect an Artica reverse-proxy to the Artica SIEM

• Back to the reverse-proxy main section | Back to main Artica SIEM page | SIEM Multi-tenancy

An Artica reverse-proxy knows every HTTP request it serves and every ModSecurity rule that fires — and keeps that knowledge only as long as its own logs.
Connecting it to an Artica SIEM appliance streams both over mutual TLS, in real time, into a store that answers questions months later.

Two operations, in this order: issue a client certificate on the SIEM, then import it on the reverse-proxy and point it at the appliance.

What gets forwarded

• HTTP requests served by nginx — host, path, status, bytes, upstream, cache decision, response time.
• ModSecurity rule hits — the WAF events, with the rule that fired and its severity.
• Backend health measurements — how each upstream is answering, over time.

Each family is a separate switch: you can forward requests without the WAF, or the WAF alone.

Why connect it

• Retention without loading the reverse-proxy. 
  Events are stored on the appliance and pre-aggregated. 
  The reverse-proxy keeps only what it needs to run, and a question about last quarter is still answerable.
   
• Several reverse-proxies read as one. 
  Five nodes behind a load balancer answer as a single dataset.
  One search, one ranking — instead of five consoles to open and reconcile by hand.
   
• An appliance outage costs nothing. 
  The forwarder holds events in memory and spills to a disk spool when the appliance is unreachable, then drains when it comes back. 
  Stopping the SIEM does not stop the reverse-proxy, and does not lose its traffic.
   
• Mutual TLS, both ways. 
  The appliance proves who it is, and the reverse-proxy proves who it is. 
  Nothing is accepted from an unregistered node, and the tenant the data lands in is decided by the certificate — never by the sender.
   
• The WAF becomes searchable. 
  A ModSecurity hit stops being a line in a file: 
  it joins the same timeline as the request that triggered it.

Typical use cases

• Incident forensics. 
  "What did this address do on our public sites last Tuesday?" 
  Answered from one place, across every reverse-proxy node.
   
• Tuning WAF. 
  Which rules fire most, on which host, and how many are false positives 
  Measured before touching the ruleset rather than after complaints.
   
• Managed hosting. 
  One tenant per customer: 
  The customer's own staff read their sites' traffic and nothing else.
  see Granting tenant privileges to a group.
   
• Capacity and backend SLA. 
  Response times and upstream health kept over months.
  A slow degradation is visible as a slope rather than as a bad morning.
   
• Compliance retention. 
  Access logs stored off the serving node, on an appliance you own.

Before you begin

• The proxy must reach the SIEM on TCP 9443 (the ingestion port). 
  Check it from the proxy before starting.
• At least one tenant must exist on the SIEM (Statistics/SIEM > Tenants). 
  The reverse-proxy form cannot be saved without one.
• The SIEM ingestion port must be serving TLS. 
  See Troubleshooting below: 
  if it serves cleartext, the proxy install fails with an error that appears to blame the certificate.
• You need an account with the global role on the SIEM console; 
  the Proxies page is refused otherwise.

Declare the reverse-proxy on the SIEM

• On the SIEM console, open Statistics/SIEM > Nodes. 
  The page lists every declared collector with its tenant, its status, when it was last seen, and its certificate.

Two columns answer “is this collector alive?” together, and they are not redundant. 
Last seen tells you a packet arrived. Events (24h) tells you how much traffic actually flowed over the last day — a proxy that reconnects every minute and forwards nothing looks perfectly healthy on Last seen alone. 

A dash in that column means the SIEM could not compute the figure, which is not the same statement as a zero.

• Click New Node to open the declaration form.

• Click Apply. 

Generate the client certificate

On the left menu, choose Status > mTLS clients

• Usage - What is the node: A proxy, A reverse-proxy…
• Device — choose the saved nodes from the list
• Select the validity day period of the certificate.

Generating downloads a .tar.gz holding three files: client.crt, client.key and ca.crt. 
Keep it: it contains a private key, and the appliance does not store a second copy.

Regenerating replaces. 
Issuing a new certificate for an existing node registers the new fingerprint and retires the old one — the node stops being accepted until it imports the new bundle.

Import it (on the reverse-proxy)

On the reverse-proxy console, open Web services > Artica SIEM forwarding. 
Before the import, the page states plainly that nothing is configured:

Click Import certificate and upload the archive as it was downloaded — do not unpack it.

The page then shows what it installed: 
The node name, the fingerprint and the expiry date. 
Check the fingerprint matches the one the SIEM registered — that pair is the whole authentication.

Step 3 — Point it at the appliance

Open Communication settings.

• Appliance URL — the base HTTPS address including the ingestion port, for example https://siem.example.com:9443. 
  Routes are appended automatically, so do not put a path here.
• Artica SIEM forwarding 
  The master switch.
• Forward HTTP requests / Forward ModSecurity events / Forward backend SLA — one per family.
• Batch size, flush interval, ring and spool sizes — leave the defaults unless the appliance asks for smaller batches.

Then use Test connection. It sends one real event through the whole path — TLS, certificate, ingestion route — and reports what came back.

Once forwarding is on, the page reports it as active, and the Effective state line tells you whether the daemon is really forwarding right now — as opposed to merely being configured to.

Step 4 — Confirm on the SIEM

Back on the appliance, Statistics/SIEM > Proxies lists every collector. 
The reverse-proxy appears with its node name, a nginx-v1 badge that identifies the family, and a Last seen that moves as it forwards.

Its Events (24h) column shows -, not a number, and that is deliberate: reverse-proxy events are stored without a collector identifier, so the appliance cannot attribute a count to one node. A 0 there would claim the node sends nothing, which is a different — and wrong — statement. Compare with the proxies below it, whose counts are real.

From then on, the traffic shows up in the reverse-proxy dashboards under Statistics/SIEM > Reverse-proxies.

Troubleshooting

Certificate lifetime

The bundle carries an expiry, shown on the reverse-proxy page and recorded on the appliance. When it passes, the node stops being accepted — the forwarder spools, it does not lose events, but nothing reaches the SIEM until a new certificate is imported.

Re-issue from the same Installation screen by selecting the existing node rather than creating a new one: the node keeps its identity, its history and its tenant, and only the certificate changes.

• Back to main Artica SIEM page