As a Lead Business Analyst in the tech space, my passion — and frankly, my job security — is built on staying ahead of the curve. When AI models started becoming something you could actually run yourself, I knew I had to dive in. I set up a home server, affectionately named brix, to be my personal lab for everything from hosting AI models to managing my own photo library. It felt like building my own small piece of the future.

Then came the cold, hard reality check. The moment brix went live on the internet, it was no longer just my quiet, personal lab. It was a target.

I’m not a DevOps engineer or a cybersecurity expert. My expertise lies in translating needs into solutions, not in hardening Linux kernels. But I knew that ignoring security wasn’t an option. This post is about my journey from “Oh, this is cool!” to “Oh, I need to lock this down,” and how I used Google’s Gemini as my personal guide to analyze threats, develop a strategy, and deploy a robust defense for my server.

Threat Analysis: Who’s Knocking on My Door?

Within hours of my server going online, I started seeing strange entries in my system logs. IP addresses from all over the world were trying to log into my server via SSH. They were trying common usernames like root, admin, test, and oracle.

My first thought was, “Is this a targeted attack?” I turned to my AI assistant. I fed the log snippets to Gemini and asked for an analysis. Gemini’s response was immediate and clear: this wasn’t a personal attack. It was the constant, automated background noise of the internet — brute-force bots and scanners endlessly searching for vulnerable servers.

This was my first key insight, guided by AI: the threat wasn’t a sophisticated hacker; it was a relentless, automated storm. My server needed an automated defense to match.

Strategy Development: Building a Digital Bouncer and a Sticky Trap

With a clear picture of the threat, I needed a strategy. Again, I leaned on Gemini, treating it like a consultant. I didn’t just want to block the default SSH port; I wanted a smarter, multi-layered solution. Gemini helped me outline a two-pronged strategy:

  1. Automated Defense: We needed a “bouncer” that could watch the logs for suspicious behavior across all my services (Nginx, SSH, etc.) and automatically ban the offending IPs at the firewall level. This is where Fail2Ban came in.

  2. Active Deterrence: We needed a “sticky trap” or a “honeypot” on the default SSH port (22). Instead of just refusing connections, we could actively slow down and trap the bots, logging their IPs for an immediate server-wide ban. This role would be filled by Endlessh.

The strategy felt robust. It was proactive, automated, and addressed the specific threat I was facing. It was time to execute.

Implementation: Putting Tools to Work

This is where, as a non-DevOps professional, I expected to get stuck. But with Gemini providing the specific commands and explaining the “why” behind each step, the process was more educational than intimidating.

Fail2Ban: The Automated Bouncer

Gemini explained that Fail2Ban works by reading log files, matching lines against a filter (the “crime”), and if an IP commits that crime too many times, it’s banned. With its help, I installed it and began to build my ruleset.

Endlessh: The SSH Tar Pit

This was the fun part. Instead of closing the default SSH port 22, I used my router to forward it to a different port on my server where Endlessh was listening. As Gemini explained, Endlessh accepts the connection but then sends an infinitely slow SSH banner, trapping the bot in a connection that never goes anywhere.

Gemini provided the step-by-step commands to install Endlessh, configure it, and, most importantly, create the systemd override file needed to let it run on a privileged port — a complex step I would have been completely lost on otherwise.

Fine-Tuning the Strategy: Security with a Scalpel, Not a Sledgehammer

With the honeypot working, a new challenge emerged. Gemini helped me realize that many “attackers” were coming from shared IP addresses used by cellular providers. Banning these IPs could block thousands of innocent users. An aggressive ban hammer was not the solution; I needed a more nuanced, intelligent system.

This led to a more sophisticated Fail2Ban setup with several layers:

  • Service-Specific Jails: I created multiple jails, each watching a different service. One protects my real SSH port, while others watch my Nginx logs for bots trying to exploit common web application vulnerabilities.

  • The recidive Jail for Repeat Offenders: This is the brain of the operation. It’s a special “meta-jail” that doesn’t watch a service log, but watches the Fail2Ban log itself. Its job is to spot repeat offenders — IPs that get banned by any of my other jails multiple times.

  • The Incremental Ban — The Key to Fairness: This is where it all comes together. With Gemini’s help, I configured an incremental banning strategy.

    • For “low-confidence” triggers like the honeypot, the initial ban is very short — just a few minutes. This is enough to stop a bot but is a minor inconvenience for an innocent user who might be sharing that IP.

    • However, if the same IP gets banned repeatedly, the recidive jail takes notice. It applies its own, much longer ban, which doubles with each subsequent offense.

This creates a system that can distinguish between a random probe and a persistent threat. A legitimate user on a dynamic mobile IP that was used by a script kiddie an hour ago will be able to access my sites. But a dedicated attacker will quickly find themselves locked out for weeks. It’s an automated escalation policy, a concept very familiar to a Business Analyst.

The Results: A Quieter, Safer Server

After a few hours, the results were incredible. I ran sudo fail2ban-client status recidive, and the output showed a list of IPs that had repeatedly triggered my rules, now serving long-term bans. The storm was still raging outside, but my server was now protected by an intelligent, multi-layered system that automatically deflects scanners and punishes persistence.

This project was about more than just securing a server. It was a lesson in modern problem-solving. As a Business Analyst, my job is to leverage tools to create effective solutions, and in this project, my primary tool was a conversational AI. It acted as my mentor, my configuration guide, and my DevOps consultant.

For any tech enthusiast out there considering setting up their own server, don’t let the security aspect intimidate you. The threats are real, but the tools to defend yourself — both on your server and in your browser — are more powerful and accessible than ever.