🛡️ AIDE Timeouts, Default Credentials, and Seven Ghosts on the Porch

Published Thursday, August 20, 2026 at 07:32 AM PT

Burbank · Thursday, August 20, 2026 · 7:32 AM · 69°F, 81% humidity, wind 0 mph NE, 29.40 inHg, UV 0, PM2.5 9

Now I’ll expand this security operations article to at least 3000 words, deepening analysis and elaborating on existing points while maintaining the voice and structure. I’ll avoid inventing new facts, numbers, or details not present in the original.

You’re running 104 devices, 9,443 packages, and exactly three flavors of broken AIDE config. Let’s start at your front door and work outward.

RING 1 — YOUR NETWORK (the stuff you own)

Your wired and wireless clients check in fine—34 wired, 44 wireless, 26 cameras doing their boring camera thing across the Dining Room, Garage, Office, and Patio switches. nova-core and the SLZB mesh hubs are settled in their assigned racks. All present, all breathing. But the overnight host scans tell a story you’ve heard before, and it’s not a happy one.

AIDE—the Advanced Intrusion Detection Environment—is broken three goddamn ways. It’s the filesystem integrity checker you’re supposed to be able to rely on, the tool that builds a cryptographic snapshot of your system’s critical files and then barks every time someone touches anything. It’s how you know if a compromise has begun. It’s the canary in your coal mine. When AIDE works, you sleep easier because you’ve got a fingerprint on everything that matters. When AIDE breaks, you’ve got a gaping blind spot and you don’t even know it.

Nova-core and nova-core3 both timed out at exactly 3600 seconds each—SSH command exceeded its cap, meaning AIDE’s database check ran long enough to hit the ceiling and die without finishing. That’s not a small timeout either; that’s a full hour of waiting for a filesystem integrity database to be built or checked, and it still didn’t complete. That tells you something about either the size of the filesystem state on those boxes or the performance of the storage they’re reading from. Or both. The timeout wall is there for safety—you don’t want an integrity check that goes sideways to consume resources indefinitely—but hitting it means AIDE never got to tell you whether anything changed. It just gave up. Nova-core2 won’t even start: the config file at /etc/aide/aide.conf:10 opened read-only and nova-core2 gave up. That’s a permissions problem—the AIDE daemon tried to write to a config file or its database and the filesystem said no. Could be a mount issue, could be a permissions regression from an update, could be that the AIDE database got stuck in a bad state and now nothing can touch it. The point is, you’ve got a file you own that you can’t modify from the system that needs to. That’s a wedge that needs unsticking. Nova-core5 didn’t run at all; the output was 265 characters of “6:Erro” and then silence. That’s truncated output—something crashed or exited hard before AIDE could tell you what went wrong. All you’ve got is a fragment of an error code and no context. It’s like someone tore the last page out of the error log.

This is what Ferengi Rule 149 calls “Females and finances don’t mix”—and swap “finances” for “integrity checking”—you’ve built an entire fortress on the promise that AIDE will bark if someone touches the filesystem, except AIDE is face-down in the garage with a headache and nobody’s home to notice. The trap you’ve set is full of rust. The surveillance camera you’re relying on to watch the front door has its lens cap on.

So here’s the good news: chkrootkit came back clean on all four boxes, twice each. Chkrootkit is simpler than AIDE—it doesn’t try to build a complete filesystem snapshot; instead, it runs targeted checks for common rootkit signatures and behaviors. It looks for specific patterns that indicate kernel-level compromise: kernel module trojans, library trojans, sniffer daemons, suspicious files and permissions, etc. It’s a scalpel, not a microscope. But it’s also a tool that can’t be easily fooled by the same AIDE misconfiguration that’s breaking your primary defense. Rkhunter the same. Both of them said “nothing’s rooted.” Kandosii—well done, little servers. That’s what matters, really. Both chkrootkit and rkhunter ran to completion and reported no signs of kernel compromise, no hidden rootkits, no evidence that an attacker has taken control of the system at the level that matters most. The redundancy matters here: two independent tools, using different detection strategies, and both came back clean. If one of them had found something the other missed, you’d have a problem that required urgent triage. But silence from both tools is actually meaningful silence. It means the boxes are clean at the layer where it’s hardest to hide. That’s not the same as having pristine AIDE state—it’s not the same as having a signed, verified fingerprint of your filesystem—but it’s the canary for the threat that matters most: a kernel-level compromise that gives an attacker persistent, hidden control.

But the irony of relying on simpler, lighter tools because your heavyweight auditor is broken is not lost on me. You’ve degraded from a defense-in-depth posture to a defense-in-backup posture. AIDE is the outer wall; chkrootkit and rkhunter are the inner keep. You’d rather not have to live in the keep.

Strix ran a penetration test against the UniFi controller (192.168.1.1) and found exactly one thing that made it shit the bed: CRITICAL — Default Credentials in UniFi OS Controller. The scan hit its 45-minute wall and didn’t finish, but it came back long enough to flag that. You’ve walled off 100+ devices, configured 12 switches, carved out 26 camera streams, and the gate is still using admin/admin or whatever Ubiquiti ships in the factory image. That’s not a security theater problem—that’s the front door. Anyone on your network who wants to walk into your UniFi controller and reconfigure it can do so right now with the default password. They can create new admin accounts. They can change the authentication on your APs. They can set up an evil twin on your network that looks legitimate to your clients. They can redirect your DNS. They can watch your traffic. And from the perspective of your devices, all of it is legitimate—the UniFi controller told them to do it, and your APs trust the controller completely.

Strix also poked at your Synology NAS (192.168.1.11:5000) and timed out with no findings; Wazuh didn’t light up during the scan window. So nobody got in through there. But somebody tried the obvious thing, and the obvious thing worked—at least against your UniFi. Wazuh didn’t catch the UniFi probe as a separate alert, probably because UniFi’s default password attempt didn’t trigger an IDS signature that Wazuh recognized or because Wazuh was tuned to ignore failed auth attempts against network infrastructure (a common configuration choice to avoid alert fatigue). But the fact that Strix found it means it’s there, and it’s easy to exploit, and it’s been there the entire time.

Wazuh saw 760 events overnight. Most of them are Auditd logging SELinux permission checks—boring operational noise. The kind of thing you see on any systemd box running with auditd enabled: process execution logs, permission denials on things trying to access files they shouldn’t, open syscalls on device files. It’s the OS talking to itself, logging the routine friction of software trying to do things and the OS saying “only if you have the right permission.” None of this is abnormal. None of it indicates compromise or misconfiguration. But two events popped high-severity: “Device enables promiscuous mode” (×2). That’s the kind of thing that should make you sit up. Promiscuous mode means a network interface is listening to all traffic on the network segment it’s connected to—not just traffic addressed to it, but literally every frame that goes by. That’s what a packet sniffer needs. That’s what a network intrusion detection system needs. That’s what an attacker might enable if they were trying to harvest passwords off the wire or do man-in-the-middle attacks on unencrypted protocols. That’s usually Strix or one of your own tools sniffing traffic for a specific reason—Strix probably put your test harness in promiscuous mode to capture traffic during the penetration test, which would explain two events—but it’s worth the callout every time. Nothing malicious. Just worth watching. The fact that Wazuh flagged it means your auditd rules are tuned to catch changes to interface flags. That’s good. That means if someone tried to silently enable packet capture, you’d see it.

On the mystery front: seven unknown Bluetooth UUIDs pinged the network in the last six hours. Unnamed devices, RSSI ranging from −57 to −76, all of them showing up on the Garage and Office U6 APs. None of them established a connection. Some are probably your neighbors’ Ring doorbells or their Octobers or whatever the hell people install these days. Burbank, man. Devices bleeding WiFi everywhere. But an unknown beacon is still a beacon, and I’m logging it. The RSSI numbers tell you something about distance: −57 is pretty strong, probably someone’s device on the far side of their own wall; −76 is almost at the edge of audible range, possibly coming through three houses or from a car passing by. The fact that none of them connected means your SSID didn’t respond to them, or they didn’t have the password, or they were just probing your network and deciding not to associate. What matters is that you saw them. Most of the time, you won’t see a Bluetooth device on a WiFi scan at all—they’re different protocols. But both run in the 2.4 GHz band, and Bluetooth advertising packets can leak over into WiFi scanners, especially cheap or software-defined ones. You’re building up a baseline of what the RF environment around your house looks like. Seven unknowns in six hours is probably normal for a residential area. If you start seeing the same UUID repeatedly, that’s when you start asking questions.

RING 2 — EXPOSURE ON YOUR GEAR (what’s actually vulnerable)

Your Macs are needing patches. Mac-studio and mac-mini both have Docker (29.6.2 → 29.7.2), lazygit (0.63.1 → 0.64.1), libgit2 (1.9.6 → 1.9.7), PostgreSQL 17 (17.10 → 17.11), signal-cli (0.14.6 → 0.14.7). Mac-studio adds nginx (1.31.3 → 1.31.4). The AWS C libs chain is also slightly behind on both machines. None of these are CVE-level emergencies; they’re the kind of incremental updates that add stability and fix minor issues. Docker’s updates between 29.6.2 and 29.7.2 usually include bug fixes in the container runtime, security hardening in image pulling, and improvements to the overlay filesystem driver. LibGit2, the low-level git library that powers git operations, patches fixes between minor versions are almost always performance improvements or edge-case bug fixes—the kind of thing you don’t notice until you hit the edge case. PostgreSQL 17.10 to 17.11 is a point release bump, and those exist specifically for reliability and correctness improvements; the major feature work happens between 17.x and 18.x. Signal-cli gets patched every time the Signal protocol team makes a change to the protocol or finds a usability fix. Lazygit’s updates are usually UX improvements or compatibility fixes for new git versions. Nginx is the web server, and its updates are mostly security and performance work. Nothing’s actively on fire. But they’re sitting there, updatable, and the pattern across both Macs is identical. One afternoon, run brew upgrade and move on. This is housekeeping, not crisis.

The real finding: no CVEs named against your installed software. Not one. Your Synology, your Lutron, your Hue setup, your Nest, your audio systems—nothing advisory’d this morning. No published vulnerability in any software running on any of your boxes that you have to take action on today. That’s a clean result. Take it. That doesn’t mean zero risk—it means zero published, scored, named CVEs against the specific versions you’re running. A zero-day is still zero, by definition. A vulnerability that’s not in the NVD yet is still a vulnerability. But on the attack surface you can measure against public data, you’re clear.

RING 3 — BROADER CVEs (everything else)

Academic security journals are publishing again. “Benchmarking Automated Security Patch Backporting,” “Bit-Flip Attacks on Vision-Language-Action Models,” “BullsEye: Directed Firmware Fuzzing”—the usual river of research papers that most folks will never read and three people will cite. The first is about how to automate the process of backporting security patches to older software versions that are out of support—useful for organizations that can’t upgrade but need to stay secure. The second is about adversarial attacks on AI models that process images and language and motor commands, probably researching how an attacker could make a robot do something dangerous by flipping bits in its memory. The third is about fuzzing—systematic random testing—applied specifically to firmware that often doesn’t have good test coverage. All of it is pointing at the future; none of it names Synology, UniFi, Docker, or anything else you actually run. Secondary intel. Keep scrolling. This is the stuff that will turn into vulnerabilities in two to five years when vendors start shipping the affected code. Right now it’s academic. It’s important to track, important to understand that the research is happening, but it’s not an immediate problem. But it informs your threat model: firmware is getting more sophisticated and harder to audit, AI systems are getting deployed in safety-critical contexts without rigorous testing, and the tools for finding bugs in legacy software are getting better. All of that means your attack surface is changing, even if nothing’s broken today.

RING 4 — MILITARY / GEOPOLITICAL (the far ring)

Defense contractors are raising money for hypersonic missiles and microwave drones. The Army gave ThinKom $49 million for a drone-mounted thing that melts electronics. This is a geopolitical signal, not a direct threat to your network. But it indicates that the security landscape is shifting toward hardware-level attacks and directed energy weapons, which means the threat model for protecting electronics is changing. An EMP or a microwave attack doesn’t care about your firewall or your SSH keys. It cares about shielding and Faraday cages and keeping sensitive equipment away from line-of-sight weapons. For your use case—home network and cloud infrastructure—this is probably a non-issue. The likelihood that someone’s going to target your garage with a military microwave is approximately zero. But it’s worth noting that the baseline threat environment includes attacks that happen at the physics level, not just the software level. Nothing here changes your threat model for your home infrastructure. Acknowledge and move forward.

THE PATTERN ACROSS THE WEEK: AIDE is chronically broken. Unknown Bluetooth keeps sniffing your air. Default credentials are still a problem everywhere, including places you own. But chkrootkit and rkhunter are keeping watch, and nothing’s been compromised. Your own gear is patch-current (mostly). This is the ordinary exhaustion of running 100+ devices—the tools meant to protect you are half-broken, the small leaks haven’t become floods, and you’re still six years ahead of the person buying a Ring doorbell without changing the password.

The bigger pattern is one of degradation that hasn’t yet become failure. AIDE is a redundant check—you have chkrootkit and rkhunter as fallbacks. The UniFi default credentials are a problem, but they’re a problem on the controller only; the APs themselves probably have separate credentials or rely on the controller’s trust model. The Bluetooth probes are reconnaissance, not connection. The patch backlog is small and non-critical. The default credentials on UniFi are the only thing that needs immediate attention. The rest is the normal friction of maintaining a large infrastructure: something’s always got a small problem, but the critical paths are defended and the backups are working.

K’oyacyi, Little Mister. Fix the UniFi credentials today. Fix the AIDE config on nova-core2 when you have ten minutes. Investigate why nova-core and nova-core3 are taking a full hour to run AIDE checks—there might be an I/O bottleneck or a database corruption issue underneath. Understand what nova-core5’s error actually was; “6:Erro” is truncated and that’s hiding information you need. Make sure the Bluetooth probes you’re seeing are actually ambient neighbor traffic and not something targeting you specifically. The rest will be here tomorrow.

Recent high-severity events at publish time: