On Saturday night at 1am, much to my alarm my phone started blowing up every few minuets from my @ubiquiti Dream Machine reporting malicious traffic! What was going on? I promise this is a real thread 🧵
The first place I looked was the Unifi network traffic inspector, which allowed me to easily figure out which IP the requests were coming from. It turns out there were two different alerts that were both coming from the wired and WiFi IPs for my work laptop.
The 192.168.4.3 IP is the PiHole I run on my Dream Machine (You can see the network setup on GitHub github.com/micahhausler/h…), and the two alerts were around “Opcode 8 through 15 set” and “Reserved bit set”.
What I did next was SSH into the dream machine and ran tcpdump for a few minuets to find the corresponding packets and have a look. After opening the pcap in Wireshark showed that the DNS opcode and reserved bits were clean, so what could be happening?
If you list the processes running on a Unifi console, you’ll see Suricata is running. Suricata is an open source intrusion detection/prevention system that Unifi uses. Having run Suricata in the past, I suspected that one of it’s rules must be triggering this alert.
So what did I do? I grepped the UDM’s file system for the alert and found it!
If you look for the reference URL in the rule its no longer valid, but was migrated to this post blog.talosintelligence.com/2008/08/checki…. This post doesn’t describe this specific rule, but is a guide for rule authors on how to do some bit math.
So what gives? I now know where the rule is, but why am I getting alerts? Well I also googled the rule’s MD5 reference and found and older copy on the GitHub github.com/seanlinmt/suri…
These rules appear to be the same, but just to be sure, I looked at a side-by-side vimdiff (I added newlines after semicolons and commas for readability). This is where things start to come together
The second word in the rule was changed from “udp” to “dns”, with an “updated_at” date of July 15, the day before I started getting alerts! Remember back to the original alert and packet dump? The protocol in both cases was TCP!
If we look at the Suricata documentation for the byte_test line, it basically tells you that this field is used to identify offending packets. suricata.readthedocs.io/en/suricata-6.…
So what does this all mean? Well, TCP and UDP packets have different byte structures, and the original byte_test is looking at the wrong bits. And of course after having this glorious ah-ha moment, I found my issue on the Unifi community board! /fin community.ui.com/questions/Intr…
• • •
Missing some Tweet in this thread? You can try to
force a refresh
I often hear people ask why Kubernetes and Firecracker (FC) can’t just be used together. It seems like an intuitive combination, Kubernetes is popular for orchestration, and Firecracker provides strong isolation boundaries. So why aren’t they compatible yet? Read on 🧵
First a brief explanation of Firecracker. Firecracker is a virtual machine monitor (vmm) written in Rust (read: cool) that was open sourced by AWS in 2018. I _highly_ recommend reading the FC paper for a more thorough explanation of what it is and is not. amazon.science/publications/f…
The short version is that FC prioritizes isolation/security, density, compatibility (w/ Linux APIs), speed, and performance. FC manages VMs and Kubernetes manages containers, and certain Linux container features don’t exactly translate to VMs. We’ll get to specifics shortly