Professional Fail2Ban Setup: Protection Against Brute-Force Attacks

Setting Up Fail2Ban: Why Password Brute-Force Reaches the Service

A service entry point is exposed by definition — otherwise it wouldn't be used. Once a service is available externally, it becomes a target: automated credential guessing attempts flow continuously from distributed addresses, and each one leaves a record in the access logs.

Password brute-forcing doesn't require compromising anything specific — weak credentials and a complete lack of response to attempts are enough.

This is where control is lost. Logs record every failed login, but between the record appearing and the decision to block the source, time passes during which tens of thousands of requests get through.

Manual log review doesn't scale, and a simple threshold of "so many attempts from one address" is bypassed: an attack spreads attempts across hundreds of sources, and individually each remains below the trigger threshold.

For a running service, this is not an abstract threat. Authentication load grows, logs swell, legitimate users get slow responses and login denials during peak hours.

If credential guessing succeeds, the attacker gets the same session as a regular client, and then operates inside the perimeter without drawing attention.

Fail2Ban closes this gap: it reads logs as they appear and blocks the source at the network filter level while attempts continue.

But the result comes not from installation, but from configuring Fail2Ban for a specific entry point — custom filtering templates, separate ban durations for different services, a trusted address list, and a proven unban procedure. Even the safety lockout of your own administrator costs more than the attack itself.

Below we break down how this is covered without false positives.

What Changes After Implementation: Attack Classes and Response Time

Before setup, the main portion of requests to the entry point is password guessing, scanners and bots that go through login forms around the clock.

Such a flow doesn't break the service immediately, but it consumes connection slots, clogs logs and increases the chance that one of thousands of attempts succeeds.

Fail2Ban closes exactly this class of failures: the rule counts failed attempts in a given window, blocks the source when the threshold is exceeded, and holds the ban as long as needed.

Incident response time changes by an order of magnitude. Previously the chain looked like this: the duty engineer notices an anomaly, reviews logs, manually adds the address to filtering rules — from spike to response, hours passed, and at night it could be until morning.

Now triggering is automatic, and the engineer receives a notification about the fact of blocking, not about a problem that is still ongoing.

The load effect is also measurable: junk requests stop reaching the application, the entry point doesn't hit the concurrent connection limit, and service downtime due to resource exhaustion disappears as a class. Service availability stops depending on who is on duty and how quickly they managed to respond.

The order of work here is no less important than the result. First, monitoring mode and whitelists for office addresses, monitoring nodes and contractors, then selecting the threshold and window duration for the traffic profile, and only then actual blocking.

This way the setup doesn't cut off your own people, and the collected statistics show what share of requests was parasitic — usually it noticeably reduces the overall load on the service.

Fail2Ban Setup: Deployment Options and Blocking Modes

Brute-force protection is placed on the service itself, on an edge node, or in a separate perimeter.

There is one limitation: the filter sees only the traffic that passes through it, so the coverage of schemes differs, and the choice here is made by the number of entry points, not by habit.

Fail2Ban works in any of the three schemes: it reads service logs, applies rules and passes the block to the firewall, and in the perimeter variant it receives the same records from a central collection point.

Blocking Modes and Retention Periods

Mode severity is chosen according to the nature of the traffic: soft — delay and rate limiting of requests, medium — temporary address blocking for a short term, hard — full source blocking with an increasing term on repeats.

The offender retention period is set separately from the trigger threshold. A short one cuts off random spikes; a long and increasing one holds persistent brute force, but requires an allowlist — otherwise your own engineers and monitoring systems will be blocked.

Implementation Stages: From Log Audit to Handover to Support

Setting up Fail2Ban is not just installing a package: a rule set at random either blocks legitimate clients or stays silent during a real attack. So we proceed sequentially — from log observation to a document your team can use to maintain protection on its own.

1. Log audit. Take a snapshot for a period: which services report failed logins, in what format, how often, whether there are night spikes and source addresses repeating day after day.
2. Entry point inventory. Compile into one list the services, ports and accounts accessible from outside — otherwise protection covers part of the entry and the rest remains open.
3. Implementation plan and scheme. Record what is blocked, for how long, how exceptions are set for monitoring, backup and service addresses.
4. Filter setup. Write parsing templates for your log formats and select trigger thresholds so the rule doesn't cut off live users.
5. Testing on a staging environment. Reproduce the brute-force scenario: the rule triggers, a legitimate login passes, the ban is removed after the term expires.
6. Transition to production. For the first while, monitor, review disputed triggers and adjust thresholds — and only then hand the system over to support.
7. Handover of procedures. Provide a document: which rules apply, why false positives occur and what to do during an attack.

Handover Package: Filter Configurations, Rules and Procedures

Setup is not a one-time command, but a set of artifacts that remain in your repository and on the servers. We hand over everything with rationale: why this threshold was chosen, what will be blocked and how to roll it back. Below is what exactly you receive.

• Filter configurations — separate rule sets for specific services: SSH access, web server, mail, control panel. Each filter is tested on real log lines, not demo examples.
• Blocking thresholds — values of maxretry, findtime and bantime per service with rationale: for SSH and for a login form they differ, because the cost of a false positive differs.
• Trusted lists — addresses of the office, secure access egress nodes, monitoring and backup systems. A separate item — how to maintain the list when addresses change, so as not to block your own checks.
• Exception rules — filters against blocking legitimate search engine robots and internal scanners, which otherwise regularly get banned and create false notifications.
• Firewall interaction scheme — which chains are used, how the ban is removed early and how the configuration behaves when a node restarts.
• Response procedure — who receives the notification, within what time they review it, what to do during a mass attack from hundreds of addresses and when to escalate.
• Documentation — configuration map, log locations, procedure for reproducing the setup on a new node and a post-update checklist.

All of this survives a contractor change: an engineer who opens the package in six months will understand the logic of the decisions without contacting us.

Case: Protection Cut Off Brute Force Without Losing Legitimate Logins

Before

The authorization service exposed two entry points — remote administrator access and the control panel. Daily logs accumulated 40–60 thousand failed login attempts, and almost all reached password verification: the only barrier was password length.

Standard Fail2Ban rules were enabled formally — one set of conditions and a threshold at which blocking triggered at best once a day. Brute force clogged logs, real events were lost in them, and incident review took hours.

What Changed

We went through all entry points and created a separate rule set for each: remote access, panel, mail, web service.

The threshold was derived from the actual distribution — an observation window of 10 minutes, a ban after five failures, and a repeat from the same address increases the term.

The whitelist was compiled from office addresses, the secure channel and monitoring systems. Filtering rules were custom, not template: some attempts went through a proxy, and the log recorded the intermediary address, not the offender.

Result

Now about two hundred attempts per day reach the service instead of tens of thousands — the rest are cut off at the perimeter. Response time to a real incident was reduced from hours to minutes: only meaningful events remained in the logs.

False blocks in the first month — a few, and each was removed with one command without restarting the service, so access restoration took less than a minute. Legitimate users noticed no changes: the whitelist and soft threshold kept their usual login scenario.

How Does Perimeter Blocking Differ from Protection on the Server Itself?

The perimeter is the point of applying protection before traffic reaches the application: an external filter or load balancer cuts the entire request flow.

It handles mass attacks well, but sees only the network level and doesn't distinguish password brute force against an admin panel from credential guessing through an application interface.

Fail2Ban works on the server itself: a series of failed logins from the service journal becomes a firewall rule that blocks the address for a set time. It's visible which account was targeted and how often.

The downside — you need to parse logs of all services with login and maintain a whitelist, otherwise your own addresses or monitoring checks get banned.

Each option has its limit: the perimeter doesn't know application logic and misses slow brute force from different addresses, while server protection doesn't scale to dozens of machines — when adding new nodes, block lists diverge, and the node starts from scratch.

A hybrid scheme closes both gaps: the perimeter holds rough spikes, and precise reaction by logs runs on the servers. Bans are synchronized between nodes via shared storage, so the attacker doesn't switch to a neighboring server after blocking.

Attack visibility is configured separately: a summary of login attempts and blocked addresses shows whether protection works and where the threshold should be weakened or tightened. In Fail2Ban setup, this layer solves no less than the blocking rules themselves.

Common Concerns: False Positives, Access and Compatibility

Most concerns around brute-force filtering boil down to one: will protection block our own people. Bottlenecks are predictable — a shared address at the office or load balancer, mistaken password entries during peak hours, services writing logs in a non-standard format.

We address each, because the price of incorrect setup is not "inconvenient" but loss of access to the production environment.

A separate topic — enabling on a live environment. The rule and filter are set to monitoring mode, trigger statistics are collected for several days, and only then is blocking enabled. Setup proceeds without stopping services or a downtime window.

Access goes through a proxy or load balancer — what then?

Parsing of the address chain and handling of the forwarding header are required: otherwise all requests appear as one address and the first brute force cuts off the entire office. Trusted proxies are added separately, with verification on real traffic.

Is it compatible with services that write logs differently?

Yes, a custom filter and parsing template are written for a non-standard format. The logic is tested on real log lines, not synthetic examples — otherwise the rule either won't trigger or triggers on a normal login.

What to do with outdated rules?

Revision before launch: remove stuck bans, remove filters for services no longer present, verify the port map. Accumulated junk causes false positives and hinders incident review.

Let's Discuss the Task: What We Need from You for a Quick Start

To move the discussion into an engineering plane immediately rather than back-and-forth clarifications, a minimal set of information and access is enough.

A ready technical specification isn't needed — describe the situation in your own words, we'll gather the rest ourselves and return with an assessment and work plan.

• What we protect: list of servers and services where fail2ban already runs or should be deployed, and which branch is currently used.
• Entry points: which ports connections go to SSH, admin panels and web services, whether there are non-standard or publicly exposed ones.
• Access to start: account with rights to read configurations and restart the service, or connection via a secure channel with session logging.
• What is already configured: current blocking rules, whitelists, firewall integration, method of delivering configuration to nodes.
• How login works now: by keys or password, where logs are stored, how you distinguish your own from others.
• Priorities and deadlines: what is critical to close first, whether there is a maintenance window and restrictions on service restarts.
• Constraints: security requirements, prohibition on installing additional packages, requirements for storing blocking data.

Describe the task — we'll return with an assessment, plan and scope of work.