Sending UniFi firewall events to the Artica SIEM using UDR,UDR7...

• Back to Artica SIEM main section.

Applies to UniFi consoles running UniFi OS: UDR, UDR7, UDR 5G Max, Express, Express 7, UDM, UCG-Ultra and UXG-Lite.
Enabling Remote Logging in the UniFi Network application is not enough on these consoles. 
This page explains why, and what to change so that firewall events actually reach the SIEM.

This procedure must be repeated after every UniFi firmware update. 
Both files you are about to edit are regenerated by ubios-udapi-server and carry the header “Generated automatically”. 
An update — and sometimes a simple re-provisioning — silently reverts them, and the event flow stops without any error being raised. 
See After every UniFi update.

Symptom

Remote Logging is enabled in the UniFi Network application, the SIEM address and port 514 are correct, the SIEM listener is up and reachable — and no event ever arrives. 
On the SIEM, syslog_received_total does not even exist, which in Prometheus means nothing was ever received.

Why it does not work out of the box

On UniFi OS, firewall events never travel through syslog. 
They are captured by ulogd from a netfilter NFLOG group and delivered as JSON over a Unix socket to the controller — that is what feeds the event list in the UniFi interface.

ulogd ships with a second processing stack that renders the same events as classic netfilter text (SRC=… DST=… PROTO=…), which is exactly the format the Artica SIEM parses. 
That stack exists, is enabled, and writes into a pipe that syslog-ng already reads.

The problem is a single number: 

1. the text stack listens on NFLOG group 0, while every firewall rule logs to a different group (group 1 on the consoles verified). 
2. Nothing feeds group 0, so the pipe stays silent, and there is simply nothing for syslog to forward.

Everything needed is already installed. 
Only the wiring is missing.

Prerequisites

• SSH access to the UniFi console as root (enable SSH in UniFi OS settings).
• The Artica SIEM reachable from the console on UDP port 514.
• Firewall rules that actually log. 
  On a console with no logging rule at all there is nothing to forward — check this first (see step 1).

Step 1 — Identify your NFLOG group

Do not copy the value blindly. The group number is a property of your console and its firmware. Read it on your own device before editing anything.

List the groups your firewall rules actually use:

iptables -S | grep -oP "nflog-group \K[0-9]+" | sort | uniq -c

Typical output on a UDR — 188 rules, all on group 1:

        188 1

If this command returns nothing, your firewall produces no log at all: enable logging on the relevant firewall rules in the UniFi Network application first, otherwise the rest of this page will change nothing.

Now read which group each ulogd stack listens to:

awk '/^\[/{s=$0} /^group=/{print s"  "$0}' /etc/ulogd.conf

[iptables_nflog]  group=0      <-- the text stack, listening to nobody
[ip_reputation_block]  group=3
[mcad_fw]  group=1            <-- where the rules actually log
[mcad_geo]  group=2

Step 2 — Point the text stack at the right group

Back up the file first:

cp -a /etc/ulogd.conf /root/ulogd.conf.bak-siem

Edit /etc/ulogd.conf and change only the group of the [iptables_nflog] section, to the value found in step 1:

[iptables_nflog]
group=1

Leave [mcad_fw], [mcad_geo] and [ip_reputation_block] untouched. mcad_fw keeps the same group: both stacks then read it, the controller keeps receiving its events, and the UniFi interface keeps working.

Step 3 — Forward to the SIEM

Create a new file /etc/syslog-ng/conf.d/99-siem.conf, replacing 10.1.15.3 with your SIEM address:

# Firewall events forwarding to the Artica SIEM.
#
# NOTE 1: this directory is managed by ubios-udapi-server; this file may be removed
#         by a firmware update. Re-apply it if the flow stops.
# NOTE 2: the anti-loop filter is MANDATORY. See below.
filter f_siem_noloop {
        not (match("DST=10.1.15.3" value("MESSAGE")) and match("DPT=514" value("MESSAGE")));
};
destination d_siem { network("10.1.15.3" transport("udp") port(514)); };
log { source(s_ulogd); filter(f_siem_noloop); destination(d_siem); };

Never omit the anti-loop filter. 
Every message sent to the SIEM is itself an outbound packet to <SIEM>:514, which the firewall logs, which is then forwarded, which produces another log entry… 
On a quiet home network this loop was measured at 56 % of all events and 145 events/s. 
With the filter in place, the same console settled at 12 events/s of genuine traffic.

The s_ulogd source already exists in the stock configuration — do not redefine it.

Step 4 — Apply

syslog-ng-ctl reload
kill $(cat /run/ulog/ulogd.pid)

ulogd is supervised and restarts on its own within a few seconds. 
Confirm it before going further — a console left without ulogd no longer feeds the UniFi interface either:

ps -eo pid,args | grep "[u]logd"

If it does not come back, start it with the exact same arguments:

/usr/sbin/ulogd --daemon --uid ulog --pidfile /run/ulog/ulogd.pid

Check that the text stack now produces events:

timeout 5 head -c 300 /run/ulog/ulogd.pipe

Aug 17 14:45:32 Dream-Router 684df252…;PREDEFINED_FIREWALL_RULE;ACCEPT IN= OUT=br2 MAC= SRC=10.1.15.1 DST=10.1.15.3 LEN=313 TOS=00 PREC=0x00 TTL=64 ID=13255 DF PROTO=UDP SPT=39840 DPT=514 LEN=293 UID=0 GID=0 MARK=1a0000

Step 5 — Declare the source on the SIEM

Declare the address the console sends from, not its LAN address. 

A UniFi console is a router: 

• it sources its packets from the interface facing the SIEM.
• A console known as 10.1.14.1 may well emit from 10.1.15.1. Declaring the wrong address is not a hard failure
• Events are filed under the default tenant instead of yours, which is worse, because it looks like it works.

Read the real source address from the SIEM itself:

tcpdump -ni any port 514 -c 3

Then declare that address in Firewall > Sources of the Artica console, with the device name and tenant of your choice.

After every UniFi update

Both files are generated by UniFi:

• /etc/ulogd.conf — header “Generated automatically by ubios-udapi-server”
• /etc/syslog-ng/conf.d/ — same generator owns the directory

A firmware update, and sometimes a simple re-provisioning of the console, restores them to their stock state: group=0 comes back and 99-siem.conf disappears. 
The flow then stops silently — syslog never acknowledges anything, so neither the console nor the SIEM raises an error. 
Nothing will tell you; the events simply stop.

Two practical consequences:

1. Re-apply the procedure after every UniFi update, and re-run the verification.
2. Monitor the silence. In the Artica console, an emitter whose last event is old is the only signal you will get. Watching the age of the last event per source is what turns this silent failure into a visible one.

Known limitations

• The device appears as an IP address. 
  On cleartext syslog listeners, the SIEM uses the sender address as the device name. 
  A readable name requires the mTLS listener (port 6514), which UniFi consoles cannot use — they have no rsyslog and no TLS syslog driver.
   
• Verdicts are partial. 
  The UniFi log prefix does not always carry a keyword the parser recognises. 
  On a verified console: accept 10 352, deny 336, but log 12 132 — more than half. 
  Read log as “undetermined”, never as “not blocked”.
   
• Verified on a UDR (UniFi OS 5.1.19, Network 10.5.67). 
  The other consoles listed share the same UniFi OS architecture and the procedure is expected to apply unchanged, but the NFLOG group number must be read on each device (step 1) rather than assumed.

Rollback

cp -a /root/ulogd.conf.bak-siem /etc/ulogd.conf
rm -f /etc/syslog-ng/conf.d/99-siem.conf
syslog-ng-ctl reload
kill $(cat /run/ulog/ulogd.pid)

The console returns to its stock behaviour: firewall events keep feeding the UniFi interface, and nothing is forwarded any more.