Cybersecurity / IoT

Smart Home Brute-force Detection and Mitigation

For my Master's thesis at Flinders University, I spent about six months building and testing a way to catch brute-force login attacks against a smart home system, specifically Home Assistant, one of the most widely used open-source smart home platforms. The problem I started from was simple: the tools that actually stop this kind of attack are either enterprise-grade, like SIEM platforms or dedicated firewall appliances, and overkill for a household, or lightweight host tools like Fail2Ban that work silently in the background, blocking IPs without ever telling the homeowner an attack happened.

I wanted to close that gap with something a home user could actually see working. So instead of building another silent blocker, I built a detection-and-response pipeline entirely in Node-RED that plugs directly into Home Assistant's own dashboard. When something suspicious happens, the homeowner sees it, not just a line buried in a log file.

The rule behind it is simple by design. Node-RED tails Home Assistant's authentication log and counts failed logins per IP address inside a five-minute sliding window. Five failures raises an alert on the dashboard. Ten failures triggers a block notification that states exactly when the block starts and ends, and after five minutes the system automatically lifts it, so a forgetful family member gets locked out briefly rather than permanently. Every alert, block and unblock is also written to a CSV log, so the whole sequence can be checked afterwards.

System architecture diagram: a Mac running Node-RED, connected over the local network to a Home Assistant OS VM and a Kali Linux attacker VM — System architecture: Node-RED on the host, Home Assistant as the target, Kali Linux as the attacker

Everything ran on hardware I already had: Node-RED on my own laptop, a Home Assistant OS virtual machine as the target, and a Kali Linux VM to run the attack. Rather than wiring this into a real router, the block and unblock actions were deliberately simulated — Node-RED builds the exact firewall command it would send and logs it, without touching a live network — which kept the whole experiment safe, self-contained and easy to repeat.

Node-RED workflow diagram showing the detection pipeline from log tailing through alerting, blocking, and CSV logging — The Node-RED workflow: log tailing → 5-minute buffer → alert / block → CSV log

Running a script that fired ten failed login attempts at Home Assistant, about one per second, the system behaved exactly as designed. Alert notifications appeared from the fifth attempt onward, a block notification landed at the tenth attempt with a clear time window, and five minutes later the system quietly issued the unblock, recorded in the CSV log rather than the dashboard so the notification panel didn't fill up with routine all-clear messages.

Home Assistant dashboard showing an IP Block Alert with the block time window, alongside the sequence of prior brute-force alerts — The Home Assistant dashboard at the 10th failed attempt: block alert with its time window

events.csv log showing a sequence of alert, block, and unblock rows with IP address and timestamp — The events.csv audit trail: alerts, then block, then unblock five minutes later

Part of the thesis compared this against tools people already use for the same job: Fail2Ban, Snort, FortiGate. None of them needed to be beaten technically — each already does its part well. What this project actually contributes is visibility. Those tools all work quietly in the background, while this one puts what's happening directly in front of the person living in the house, and it does that on hardware as modest as a Raspberry Pi.

It has real limits, and I documented them rather than glossing over them. The blocking was simulated rather than wired into an actual firewall, so it hasn't been tested against real network conditions. The attack I tested was also a straightforward burst from a single IP; a slower, distributed attempt designed to stay under the threshold would need different detection logic, which is the natural next step for this work.