🧩 CEF, But Not Quite: UniFi OS Events Break the Format

TL;DR: UniFi devices generate two types of CEF events—one from "UniFi Network" and one from "UniFi OS". Only the "UniFi Network" events are properly formatted. "UniFi OS" events are malformed, missing required fields, and cannot be parsed without custom workarounds. If you're relying on CEF parsers, expect frustration. Ubiquiti should fix these broken events.

In my previous post, I wrote that UniFi devices can generate CEF events for both UniFi OS and UniFi Network. I need to clarify that statement.

Because only one of those event types is correctly formatted as CEF. The other? Parsers won’t even touch it.

What CEF is supposed to look like

To make sense of this, let’s first recap what a CEF event is supposed to look like. The official documentation for the format is here:
👉 Micro Focus CEF Implementation Standard

According to the spec, a typical CEF header looks like this:

CEF:Version|Device Vendor|Device Product|Device Version|Device Event Class ID|Name|Severity|[Extension]

Here’s a partial sample CEF event from a UniFi Network device:

Aug 05 15:35:08 pandora CEF:0|Ubiquiti|UniFi Network|9.3.45|201|Threat Detected and Blocked|7|proto=TCP src=81.181.129.172…

Parsed out, we get:

  • Version: 0
  • Device Vendor: Ubiquiti
  • Device Product: UniFi Network
  • Device Version: 9.3.45
  • Device Event Class ID: 201
  • Name: Threat Detected and Blocked
  • Severity: 7
  • Extension: proto=TCP src=81.181.129.172…

No surprises there—everything is where it should be.

Now let’s look at a UniFi OS event

Aug 05 20:34:54 pandora CEF:0|Ubiquiti|UniFi OS|4.3.6|admins|1|msg=mindthelog accessed the UniFi OS via unifi.ui.com. Source IP: 1.2.3.4

Apply the same field breakdown:

  • Version: 0
  • Device Vendor: Ubiquiti
  • Device Product: UniFi OS
  • Device Version: 4.3.6
  • Device Event Class ID: admins
  • Name: 1
  • Severity: msg=mindthelog…

Wait—what?

“1” is not a meaningful event name, and the severity field is completely off. According to the CEF spec, the Severity field must either be a number (0–10) or one of the strings: Unknown, Low, Medium, High, or Very-High.

Here, it contains msg=…—which clearly belongs in the extension field.

My guess: the Device Event Class ID or Name field is missing. That would throw off the entire parsing structure, shifting everything after the Device Version field one field to the left.

Parsers don’t like this

Most CEF parsers throw errors when they see this malformed structure. For example, my log management system reports:

Parsing the CEF 'Severity' header failed. Please ensure that it is present and that it contains either a numeric value from 0 to 10, or one of the allowed strings: Unknown, Low, Medium, High, Very-High.

In my case, msg=… ended up in the Severity field, which is invalid. I had to split the event into two parts, insert a missing field in between the two parts, and reassemble it—just to make it parseable.

No, I’m not going to tell you what value I used for the missing field.

Conclusion

If the Device Product is UniFi OS, the event is not a properly formatted CEF message. It won’t be parsed by any standards-compliant CEF parser without custom logic or workarounds.

Dear Ubiquiti: I’ve created a workaround for my log management system. But wouldn’t it be better if the events were formatted correctly in the first place?

Comments

Post a Comment

Popular posts from this blog

🕰️ Inconsistent Time Zones in UniFi Logs

Image
TL;DR: UniFi logs from different processes don't use a consistent time zone. CEF events are timestamped in UTC, while other logs use the local device time (which may include daylight savings). This inconsistency causes confusion and breaks correlation in SIEMs and log management systems. Ubiquiti should standardise on UTC for all events. Looking at the logs from my UniFi Dream Machine Pro, it's clear that many different processes are responsible for providing all the awesome functionality it offers. In my previous post, I pointed out that, in this day and age, timestamps should include time zone information . But at the very least, you'd expect that all processes on the same device use the same time zone, right? Nope. Take a look at this screenshot from my log management system: First, you see an ingesttimestamp —the time when the log management system received the event. Then you see the raw event as sent by the UniFi Dream Machine. Look at the highlighte...
Read more

📅 UniFi Logs and the Missing Time Zone: Why It Matters

TL;DR: UniFi's syslog output still uses an outdated timestamp format that lacks time zone information. That's a problem for SIEMs and log management systems where correlation and accurate timelines matter. Modern formats like the one defined in RFC 5424 include time zone data—UniFi should adopt this. The logs from UniFi devices have historically been somewhat underwhelming—especially when it comes to integration with SIEMs and log management systems. But with version 8.5.6 of the UniFi Network Application, released in October 2024 , there was a welcome change: "Export all or specific System Logs shown on the Network Application to SIEM Servers (remote Syslog) such as Splunk, Microsoft Sentinel, IBM QRadar, and others." — Release notes for UniFi Network Application 8.5.6 I was genuinely excited to see this. At last, logs from UniFi devices were getting some SIEM love! 🕓 Time Stamps: The Basics Logs are chronological records of system activity. Ea...
Read more

Missing Fields in Teleport VPN Logs: Why the Remote IP Matters

TL;DR: UniFi Teleport VPN logs (in CEF format) are missing the client's remote IP address—the WireGuard endpoint—which is critical for threat detection, auditing, and correlation in SIEM tools. Although this IP is available in other events, it isn't included in the CEF event. Adding a field like UNIFIvpnClientRemoteIp would significantly improve log completeness and security monitoring value. When a Teleport VPN connection is made through a UniFi device, three IP addresses are involved: The remote IP of the Teleport client (the WireGuard endpoint) The WAN IP of the UniFi device The internal IP assigned to the Teleport client The CEF log that's generated captures a good deal of useful information, including the internal client IP, VPN type, and WAN interface. But one important piece is missing: the remote IP address of the Teleport client. Here's an example CEF event for a VPN connection: CEF:0|Ubiquiti|UniFi Network|9.3.45|522|Teleport Clie...
Read more