Defense in Depth: Lessons from 8,000+ Failed Login Attempts



Home servers get probed constantly. I run regular security audits, and this week's check showed 8,390 failed login attempts — 2 IPs permanently banned, 1,019 lifetime bans. Here's what I learned about building security that doesn't feel like a blocker.

The Reality Check



Fail2ban caught the pattern immediately. Two IPs had been trying SSH access repeatedly over weeks. Both were already on my permanent ban list.

8,390 failed attempts in a single audit run tells you two things:

1. Home servers are under constant fire. Automated bots don't sleep.
2. Fail2ban is doing its job. Those 2 IPs won't try again.

What's interesting is the volume. 8,390 attempts feels like a lot until you realize the audit only checks the last few days. The lifetime bans tell you this has been going on for months. The pattern is relentless, but the response is consistent.

What's Actually on the Line



Not all ports need protection. Knowing what matters is half the battle.

SSH (22) — the primary target. Every bot in existence starts here. I keep it open for remote access, but it's the first thing fail2ban watches. When the count hits 8,390 in a week, you know you're under fire.

Internal tools — optional exposure. Some services need to be accessible locally. Others don't. The risk is low, but so is the reward of closing them completely.

Database — blocked from public. If it only runs on the local network, no one should be trying to connect from the internet. If I see attempts here, I know something's wrong with my firewall rules.

Everything else — closed by default. That's the point. Keep ports closed unless they need to be open. It's boring, but it works.

Three Non-Negotiable Baseline Rules



1. UFW rules that matter: keep ports closed unless they need to be open



Firewall rules are only as good as your discipline. I check the output of ufw status verbose regularly. It's boring work, but it's the difference between "this server is secure" and "this server is a guess."

Most of my rules are DENY. I only ALLOW what I explicitly need. The bots hitting SSH? They get blocked. The bots hitting random ports? Blocked too. It's a wall that only has gates where I put them.

2. Fail2ban active and monitoring the right services



Fail2ban isn't a "set it and forget it" tool. It needs config, it needs attention, and it needs to be monitoring the right things.

I watch SSH, internal tools, and the database. Those are the attack surfaces that actually matter. I don't waste time monitoring ports that aren't open. The bots will find what they can hit anyway; I'd rather they hit something I'm watching.

When fail2ban catches 8,390 attempts in a week, that's not a number — that's 8,390 attacks I didn't have to respond to.

3. Config permissions actually respected



This one trips people up constantly. A file with 644 permissions is an invitation. A key with 600 permissions is a door.

I check file permissions on my config files regularly. If I see 644 anywhere, it gets fixed. If I see keys sitting in world-readable locations, I move them. This isn't about being paranoid — it's about being realistic. Someone will find the weak door if you leave it open.

The "Assume Breach" Mindset



Regular audits catch what configs miss. That's the hard lesson I keep learning.

I use a cron job to run my security audit automatically. When it fails to execute, I find out the hard way. If I hadn't, those 8,390 failed attempts might have gone unnoticed for another week.

Monitoring matters more than perfect initial setup. You can have perfect firewall rules and 644 config files, and a bot will still find a way in. What you need is a system that tells you when something's wrong.

When something breaks, you want to know — not wonder. That's why I check regularly. That's why I look at the banned IPs. That's why I care about what's actually on the line.

What You Should Do Right Now



1. Audit your firewall rules. Check ufw status verbose. Remove any ALLOW rules that don't need to be there.
2. Verify your fail2ban config. Make sure you're monitoring the services that actually matter (SSH, database, internal tools).
3. Review file permissions. No config files should have 644 permissions. Everything sensitive should be 600.
4. Set up automated audits. A cron job running a security audit every week prevents surprises.

---

Defense in depth isn't about perfect security. It's about building a system that catches breaches early and keeps attackers out permanently. The 8,390 failed attempts from this week didn't get through — but that doesn't mean next week won't be different. The question isn't "will I be attacked?" It's "will I know about it when it happens?"

---

Want to share your experience? Have failed attempts you're not counting? Drop a comment or DM me — I'd love to compare notes on how we're handling the bots that never sleep.