I built a DIY intrusion detection system (IDS) using a Zotac Nano mini PC with dual Ethernet ports. With my Windows laptop plugged into one NIC and the switch plugged into the other, the mini IDS could watch every single packet that came down the wire.

All I really needed was someone willing to do something suspicious, and thankfully I had a VM handy to do precisely that.

From a Linux box on the other side of the switch, I used Nmap to probe for 100 ports on my laptop. In under two seconds, it found four open ports. When I refreshed my IDS logs expecting to see the carnage, there wasn’t even a single new alert.

So, why didn’t the IDS see me?

I put the mini-IDS between my laptop and the switch

One wired client and two Ethernet ports

My cheap and, let’s face it, mediocre mini PC has a Celeron N3160 and 8 GB of RAM. It got this job not because of its compute specs but because it has dual Gigabit Ethernet ports around the back.

I wanted to experiment on a machine that I could reboot without taking the network down. After my household complained last time I attempted this and broke the network, I also wanted it isolated to test.

I installed Debian 13, connected the adapter assigned to enp3s0 to the switch, and plugged my laptop into ens1. These three lines in /etc/network/interfaces told Debian to bring up a bridge called br0, join the two ports, and get its management IP address over DHCP:

auto br0 
iface br0 inet dhcp     
    bridge_ports enp3s0 ens1

I turned the Wi-Fi off on the laptop, forcing the laptop to reach its usual gateway through the network bridge. Initial tests succeeded, so I knew Debian was forwarding traffic onto the Starlink router. But bridging the traffic was just the first step. I also needed something to spot anything suspicious in that traffic.

Next, I installed Suricata, an open-source network intrusion detection engine. I set it to listen on the laptop-facing port and then ran sudo suricata-update to fetch the Emerging Threats Open ruleset.

These rules are patterns that Suricata uses to identify threats and flag them. Since Suricata doesn’t have a GUI, and I dislike trawling through logs, I also installed EveBox to display and browse the records through a web interface.

To check the setup, I opened PowerShell on the laptop and sent a DNS query to my local resolver:

nslookup -type=A example.org 192.168.1.9

At 23:35:58, EveBox showed both the query for example.org and its response. I had the Windows Terminal and the matching events side by side, so despite the results of my next port scan, I knew I’d definitely set it up correctly.

My first port scan didn’t raise a single alert

The home-brew IDS needed a homemade rule

Before I ran the port scan, I wanted to see if I could trace back to something unscrupulous I’d done. On my Linux VM, I put uid=0(root) gid=0(root) groups=0(root) in a text file and served it with a temporary Python HTTP server. Using PowerShell on the laptop, I fetched the file across the bridge:

curl.exe http://192.168.1.249:8080/id.txt

Two alerts had appeared on EveBox. Suricata recognized Python’s HTTP server banner, then returned the entry I was looking for: “GPL ATTACK_RESPONSE id check returned root.” That stock rule had picked up the string in the response. My abilities as a hacker entirely consisted of being able to type the word root into a text file. Still, the detector had done its job.

That only made the IDS’s silence for my next test a bit harder to reconcile. From the very same Linux machine, I pointed Nmap at the Windows laptop and asked it to probe 100 of the most common TCP ports:

sudo nmap -sS -n -Pn --top-ports 100 --reason 192.168.1.208

Four ports answered as open, mostly consisting of remote management system ports. A further 96 ports were thankfully filtered. With no new alerts in EveBox, I checked Suricata’s flow log on the IDS.

It had detected 196 TCP flows with the SYN flag set between the two machines, covering all 100 destination ports. However, every single event had alerted set to false. The IDS had seen it. Suricata had just decided it wasn’t worth escalating.

I needed to add a local rule to flag 20 SYN packets from one source to my laptop within ten seconds. I called it “LAB TCP SYN burst to test laptop” to stop repeated attempts to reach a single port, also tripping the rule.

Once Suricata had loaded the rule, I repeated the Nmap scan. This time the alert made it to EveBox alongside the scanner’s IP.

The throughput test nearly had me fooled

Near-gigabit speeds but with one huge caveat

Catching a brief scan and a file transfer were promising. What I really wanted to know, though, was whether the mini-IDS would slow down my network speeds and keep up with the packets.

I ran three 15-second tests in each direction using the network tool iperf3 through the mini-IDS first, then plugged my laptop directly into the switch and repeated them. Both machines were on my home LAN, so the external Internet had no say in the result.

Those were the median speeds reported by the Linux VM, and I could definitely live with a 3 Mbps difference if it meant I was receiving network security alerts.

Then I checked Suricata’s capture counters.

Debian was able to forward each packet while offering Suricata a copy to inspect. Under a large sustained load, these copies arrived much faster than the detector could work through them. Once the capture buffer filled up, Debian started discarding incoming copies and just let the transfer carry on.

Across the bridged runs, 5.73 million of the 7.80 million packets on offer for capture were dropped, about 73.5%.

Obviously, that’s not really ideal because a rule can only match evidence that Suricata can actually see. If the packet carrying my fake uid=0(root) response was among those dropped copies, I could’ve just fetched the file and got no alerts.

Discord kept my detector busy

Twelve alerts for one platform during an ordinary browsing session

Once I’d finished hammering the Celeron with iperf3, I went back to the laptop for a timed normal use session. In 16 minutes and 43 seconds, the mini-IDS had managed to log 12,672 events, excluding its own statistics.

Only 12 of those were actual alerts, which sounded both manageable and interesting until I realized they had just mentioned Discord 12 times.

Six of those alerts came from DNS lookups for Discord domains. The remaining six came from hostnames visible when the laptop made encrypted connections.

Calling these false positives wouldn’t really be fair. Discord was running, and the rules had identified its traffic correctly. All that was left was for me to decide whether any of it warranted a closer look.

However, after examining the list of alerts more closely, the only thing I was confident about was that the laptop was running Discord. In other words, it was hardly what I’d call useful information.

The mini-IDS is going to stay on my lab bench

It hasn’t earned a place on the household network just yet

The mini-IDS impressed me with the first few scans. Its flow records showed me exactly where my probes went, and once I’d written a rule, I could run the same test and watch it fire.

The glaring issue was, of course, the dropped packets during the iperf3 tests. It’s likely the poor Celeron CPU just couldn’t keep up.

In light of this, I’d be happy to use the mini-IDS as a benchtop tester in my homelab, but that’s it. For a household playing AAA games, streaming media, and downloading huge files, 73.5% of dropped packets just isn’t going to cut it.

Still, Suricata would’ve performed much better if only I had given it enough compute to run properly. I’m also confident that the next time one of my servers, VMs, or even desktops starts talking to something I don’t recognize, I’ll be reaching for this mini-IDS box.