[{"data":1,"prerenderedAt":212},["ShallowReactive",2],{"seo-verification":3,"blog-fail2ban-enhanced-on-vps-blocking-repeated-attacks-ma-en":6,"promo-bar-likely":211},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-fail2ban-enhanced-on-vps-blocking-repeated-attacks-ma-en",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"noindex":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":33,"intro":36,"sections":37,"ctaTitle":152,"ctaBody":153,"ctaButton":154,"ctaUrl":155,"relatedPosts":156},109,"fail2ban-enhanced-on-vps-blocking-repeated-attacks",{"fr":12,"en":10,"ar":13,"es":14},"proteger-vps-fail2ban","fail2ban-enhanced-على-خادم-vps-حجب-الهجمات-المتكررة","fail2ban-en-vps-bloquear-ataques-repetidos","Fail2Ban Enhanced on VPS: blocking repeated attacks","Link Fail2Ban Enhanced to the ServOrbit catalog: SSH\u002FNginx banning, readable logs and official documentation.",11,1,false,"2026-03-03T00:00:00+00:00","2026-11-01T14:14:36+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},8,"Security & Monitoring","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[29],{"id":23,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fproteger-vps-fail2ban-poster.svg",{"categorySlug":34,"appSlug":35},"securite","fail2ban-enhanced","As soon as a VPS exposes SSH or a web application, automated attempts arrive quickly. Fail2Ban Enhanced provides a simple safety net: read the logs, detect repeated failures and ban the IPs that persist. This guide goes from the initial setup to day-to-day operation: jails and thresholds, choosing the backend, checking that a jail is still watching, troubleshooting with the real error messages, fitting it with the VPS firewall, and backing up the configuration. The options cited come from the upstream Fail2Ban documentation.",[38,42,52,55,80,83,87,90,114,117,132,135,146,149],{"type":39,"title":40,"body":41},"h2","Why self-host Fail2ban on a VPS","Fail2ban is one of the simplest and most widespread protection tools for an exposed server: it continuously reads your logs, applies regular expressions (the filters) to spot intrusion attempts, and bans the offending IP by adding it to nftables or iptables for a configurable duration. On a VPS, it is a first line of defense to put in place before the rest, because it depends on no external service, uses little and protects SSH against bruteforce as soon as the jail is enabled. Beyond SSH, you can extend it to Nginx (authentication attempts, URL scans), Postfix, WordPress or any service that writes logs. Everything runs locally on your machine: no data leaves, no third-party service is involved. It is a self-contained, easy-to-audit solution, provided you check on it from time to time, as we will see below.",{"type":43,"title":44,"items":45},"ul","The concrete benefits of this template",[46,47,48,49,50,51],"**Automatic banning** — IPs that bruteforce SSH are banned as soon as the `maxretry` threshold is reached within the `findtime` window.","**Filters for many services** — SSH, Nginx, Apache, Postfix, WordPress, and custom filters written in `filter.d`.","**Minimal footprint** — it runs without trouble on the smallest of VPSes.","**Progressive banning (repeat offense)** — the more an IP reoffends, the longer the ban.","**Email notifications** — possible on each ban, with the `action_mw` or `action_mwl` actions from `jail.conf`.","**Self-contained and local** — no network dependency day to day, simple to audit and version.",{"type":39,"title":53,"body":54},"Quantified requirements to host it","Fail2ban is frugal: a VPS with 1 vCPU and 512 MB of RAM is enough to run it, with no perceptible impact (an editorial recommendation, to be measured against your own load). On the software side, the upstream README for version 1.1.1 asks for Python 3.5 or later. Two components are optional: pyinotify 0.8.3 or later to watch files (Linux kernel 2.6.13 or later), and systemd 204 or later with the python-systemd package to read the journal. Fail2ban installs directly on the system (no need for Docker) and requires root access, a firewall backend (nftables or iptables) and access to the logs of the services to protect: the systemd journal or `\u002Fvar\u002Flog\u002Fauth.log` for SSH depending on the distribution, and the Nginx access and error logs. It keeps its state in a SQLite database, `\u002Fvar\u002Flib\u002Ffail2ban\u002Ffail2ban.sqlite3` by default. No additional domain or port is needed. The golden rule: fill in `ignoreip` with your IP before enabling banning, so you don't lock yourself out of your own server.",{"type":56,"title":57,"steps":58},"steps","Install and configure Fail2ban on your VPS",[59,62,65,68,71,74,77],{"title":60,"body":61},"Install Fail2ban","On Debian or Ubuntu: `sudo apt update && sudo apt install fail2ban`. The service starts automatically. Check with `sudo systemctl status fail2ban`.",{"title":63,"body":64},"Create a jail.local","Never modify `jail.conf` directly. Write your settings in `\u002Fetc\u002Ffail2ban\u002Fjail.local`, which overrides them: that's where you define `bantime`, `findtime`, `maxretry` and above all `ignoreip = 127.0.0.1\u002F8 ::1 VOTRE_IP` to protect yourself from a self-ban. The defaults in `jail.conf` are `bantime = 10m`, `findtime = 10m` and `maxretry = 5`.",{"title":66,"body":67},"Enable SSH protection","All jails are disabled by default in `jail.conf`: explicitly enable `[sshd]` in `jail.local` with `enabled = true`, for example `maxretry = 3` and `bantime = 1h`. After 3 failures within the `findtime` window, the IP is banned for one hour at the firewall level.",{"title":69,"body":70},"Add a jail for Nginx","Enable the `[nginx-http-auth]` and `[nginx-botsearch]` jails, provided by `jail.conf`, and make sure `logpath` points to your Nginx logs. This blocks repeated authentication attempts and malicious URL scans.",{"title":72,"body":73},"Test the configuration, then reload it","Check the syntax first: `sudo fail2ban-client -t`. Then apply it: `sudo fail2ban-client reload` (or `sudo systemctl restart fail2ban`). `sudo fail2ban-client status` lists the active jails and `sudo fail2ban-client status sshd` shows the currently banned IPs.",{"title":75,"body":76},"Test a ban and the unban","Check the filter against your own log with `sudo fail2ban-regex systemd-journal sshd`. To simulate a ban without attacking anyone: `sudo fail2ban-client set sshd banip 203.0.113.10`, then read `sudo fail2ban-client status sshd`. To release a legitimate IP blocked by mistake: `sudo fail2ban-client set sshd unbanip X.X.X.X`.",{"title":78,"body":79},"Logging in for the first time","There is no web interface and no account to create: fail2ban is a system daemon that, with the template's setting, bans IP addresses after 4 failed SSH attempts within 10 minutes. Over SSH: `fail2ban-client status sshd` (banned IPs), `fail2ban-client set sshd unbanip \u003CIP>` (to unban). Adjust these thresholds in `jail.local`.",{"type":39,"title":81,"body":82},"ignoreip, ban duration and repeat offenders","`ignoreip` accepts IP addresses, CIDR masks or DNS host names, separated by spaces or commas. By default `ignoreself = true`: the server's own local addresses are never banned, but your office or home IP is not covered by that. If it changes often, declare a dynamic host name or use `ignorecommand`, an external command that receives the IP and answers whether it should be ignored. Also keep a fallback access that does not depend on SSH, such as your VPS provider's console: a self-ban can then be fixed without outside help. The duration is set with `bantime`, in seconds or with the suffixes `m`, `h`, `d`, `w`, `mo` and `y`. It acts as the initial duration when progressive banning is enabled. For repeat offenders, `jail.conf` also ships a `recidive` jail, which reads fail2ban's own log.",{"type":84,"title":85,"body":86},"tip","Progressive banning: formula, cap and memory","Enable progressive banning in `jail.local` with `bantime.increment = true`. The default formula multiplies `bantime` by 1, 2, 4, 8, 16 and so on at each reoffense; `bantime.factor` (1 by default) is a common multiplier, and `bantime.maxtime` caps the duration in seconds, for example `bantime.maxtime = 604800` for seven days. One point is often missed: fail2ban finds earlier bans in its database, which is purged according to `dbpurgeage` (one day by default in `fail2ban.conf`). For widely spaced reoffenses to be found, raise it; the comment on the `recidive` jail in `jail.conf` cites 648000 seconds. Pair all this with disabling password authentication (SSH keys only): Fail2ban then becomes a safety net rather than your only rampart.",{"type":39,"title":88,"body":89},"Choosing the backend: auto, pyinotify, polling or systemd","The backend is the way a jail reads its logs. The default in `jail.conf` is `backend = auto`, which each jail can override. On Debian and Ubuntu, the `paths-debian.conf` file in the upstream 1.1.1 archive sets `sshd_backend = systemd`: sshd is then read from the systemd journal, not from `\u002Fvar\u002Flog\u002Fauth.log`. Read `sudo fail2ban-client status sshd` to learn what is really being watched: the `File list` line indicates files, the `Journal matches` line indicates the journal. A distribution may change these values, so assume nothing: observe. Changing backend is done jail by jail, in `jail.local`, followed by `sudo fail2ban-client reload`.",{"type":91,"title":92,"headers":93,"rows":97},"comparison","The four Fail2ban backends",[94,95,96],"Backend","What it watches","Worth knowing",[98,102,106,110],[99,100,101],"auto","Files (pyinotify, then polling); switches to systemd if no `logpath` file exists and the filter defines `journalmatch`","Default value in `jail.conf`",[103,104,105],"pyinotify","Files, through kernel inotify events","Linux only, Python pyinotify module required; better suited to files than polling according to the documentation",[107,108,109],"polling","Files, by re-reading at regular intervals","No external library, the simplest fallback",[111,112,113],"systemd","The systemd journal, through python-systemd","`logpath` is not valid; the filter goes through `journalmatch`; `journalflags` and `rotated` settings",{"type":39,"title":115,"body":116},"Checking that the jail is still watching","A started jail is not necessarily a jail that reads. Reported, not confirmed by the maintainers: in \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Ffail2ban\u002Ffail2ban\u002Fissues\u002F4250\" target=\"_blank\" rel=\"noopener noreferrer\">fail2ban issue 4250\u003C\u002Fa>, opened in October 2026, an administrator on Debian with fail2ban 1.1.1 describes an `sshd` jail on the `systemd` backend that stops banning one to two days after start, while the Nginx and Postfix jails keep working. Two other administrators, both on FreeBSD according to their messages, report a similar symptom with the `pyinotify` backend; one says things became stable after switching to `polling`. A maintainer pointed out that the original issue was about the `systemd` backend and that the two symptoms may not be related. A last participant, on Arch with the `systemd` backend, describes the same stop after a journal rotation and puts forward a hypothesis about the `rotated` setting: it remains unconfirmed. The cause is not established to date, and nothing allows generalizing to your server. The check itself takes a minute.",{"type":56,"title":118,"steps":119},"Check in four steps that the jail still reads",[120,123,126,129],{"title":121,"body":122},"Read the jail status","`sudo fail2ban-client status sshd` shows `Currently failed` and `Total failed` for the filter, `File list` or `Journal matches` for the source, then `Currently banned`, `Total banned` and `Banned IP list` for the action. Note `Total failed`.",{"title":124,"body":125},"Compare with the log","Count the real failures over the same period: `sudo journalctl _COMM=sshd --since \"1 hour ago\" | grep -c \"Failed password\"`, or `sudo grep -c \"Failed password\" \u002Fvar\u002Flog\u002Fauth.log` if the jail reads that file. Then read `Total failed` again: it should have grown. Compare the trend, not exact equality, because IPs in `ignoreip` do not count.",{"title":127,"body":128},"Read fail2ban's own log","`sudo tail -n 50 \u002Fvar\u002Flog\u002Ffail2ban.log`: a healthy jail writes `Found` lines followed by `Ban`. Several days of lone `Unban` lines, while the authentication log shows attempts, point to a blind jail.",{"title":130,"body":131},"Restart and change backend if needed","`sudo systemctl restart fail2ban` restarts the reading; the issue describes normal operation for one to two days after each start. For a file-based jail, `backend = polling` is the simplest fallback. Schedule this check (cron or a monitoring tool) rather than relying on the absence of alerts.",{"type":39,"title":133,"body":134},"Troubleshooting: the real error messages","These messages come from the Fail2ban 1.1.1 source code (clients and configuration readers); the default logging level is `INFO`. For each case the starting command is the same: `sudo fail2ban-client -t` tests the configuration, `sudo journalctl -u fail2ban` gives the beginning of the story.",{"type":43,"title":136,"items":137},"Common error messages and fixes",[138,139,140,141,142,143,144,145],"**`Have not found any log file for 'sshd' jail.`** — the jail's `logpath` points to no existing file and startup fails, unless `skip_if_nologs = true`. With the `auto` backend, a jail whose filter defines `journalmatch` switches to systemd instead. Fix the path or set `backend = systemd`.","**`No file(s) found for glob \u002Fvar\u002Flog\u002Fnginx\u002Ferror.log`** — a `logpath` pattern matches nothing. Check the real location of the Nginx logs with `ls \u002Fvar\u002Flog\u002Fnginx`.","**`Unable to read the filter 'nginx-xyz'`** — the name given to `filter =` does not exist in `filter.d`. Fix the typo or add your filter file.","**`Failed to access socket path: \u002Fvar\u002Frun\u002Ffail2ban\u002Ffail2ban.sock. Is fail2ban running?`** — the client cannot find the server socket. The service is stopped or failing: `sudo systemctl status fail2ban`, then its log.","**`Permission denied to socket: ... (you must be root)`** — the `fail2ban-client` command was run without sufficient rights. Run it again with `sudo`.","**`Unable to contact server. Is it running?`** — the socket exists but the server does not answer. Restart the service, then read its startup log.","**`[sshd] Journal reader seems to be offline, reopen journal`** — fail2ban detected that its reading of the systemd journal had stopped (rotation) and reopens it. This message is at the `MSG` level, below `INFO`: its absence from a normal log proves nothing, hence the check in the previous section.","**`Error reading line from systemd journal`** — a read error on the systemd journal, followed by the system cause. Check the service's rights and the journal state with `journalctl --verify`.",{"type":39,"title":147,"body":148},"nftables or iptables, the VPS firewall and backup","The ban action is chosen with `banaction`. `jail.conf` offers `iptables-multiport` as a commented example; the `paths-debian.conf` file in the 1.1.1 archive sets `banaction = nftables` and `banaction_allports = nftables[type=allports]`. The nftables action creates by default the `f2b-table` table (`inet` family) and the `f2b-chain` chain, hooked on input with priority -1; `sudo nft list table inet f2b-table` shows the banned IPs. Pick a single family of actions, the same as the rest of your firewall, otherwise you look for your rules in the wrong table. The VPS firewall acts upstream: it filters what reaches the machine, for example by limiting SSH to your addresses, while Fail2ban reacts to what the logs say. The two complement each other, but keep `ignoreip` consistent with your rules. Behind a proxy or a CDN, the logs show the proxy's IP: restore the real IP before banning, otherwise you ban the proxy. For backup, archive the configuration (`sudo tar czf fail2ban-config.tar.gz \u002Fetc\u002Ffail2ban`) and the output of `sudo fail2ban-client --dp`, which documents the effective configuration. The `\u002Fvar\u002Flib\u002Ffail2ban\u002Ffail2ban.sqlite3` database holds the memory of past bans.",{"type":84,"title":150,"body":151},"The official documentation","For advanced configuration, options specific to the tool, and version changes, refer to the \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Ffail2ban\u002Ffail2ban\u002Fwiki\" target=\"_blank\" rel=\"noopener noreferrer\">official Fail2Ban documentation\u003C\u002Fa>. This guide covers deployment on a ServOrbit VPS; the vendor's documentation remains the reference for fine-tuning.","Armor access to your VPS","The ServOrbit Cloud VPS gives you root access and a ready-to-use firewall to configure Fail2ban in a few minutes and stop bruteforce attacks cold.","Get my Cloud VPS","\u002Fvps-cloud",[157,176,193],{"id":158,"slug":159,"slugs":160,"title":164,"excerpt":165,"readTime":23,"views":166,"isPinned":19,"noindex":19,"publishedAt":167,"updatedAt":168,"category":169,"categories":170,"featuredImage":30,"bgImage":31,"posterImage":172,"relatedSolution":173},105,"monitoring-your-vps-with-uptime-kuma",{"fr":161,"en":159,"ar":162,"es":163},"superviser-vps-uptime-kuma","مراقبة-خادمك-الافتراضي-vps-باستخدام-uptime-kuma","supervisar-vps-con-uptime-kuma","Monitoring your VPS with Uptime Kuma","Deploy Uptime Kuma on your VPS to monitor your sites and services self-hosted, with alerts and a public status page.",0,"2026-03-07T00:00:00+00:00","2026-11-09T20:55:19+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[171],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fsuperviser-vps-uptime-kuma-poster.svg",{"categorySlug":174,"appSlug":175},"monitoring-observability","uptime-kuma",{"id":177,"slug":178,"slugs":179,"title":183,"excerpt":184,"readTime":17,"views":18,"isPinned":19,"noindex":19,"publishedAt":185,"updatedAt":186,"category":187,"categories":188,"featuredImage":30,"bgImage":31,"posterImage":190,"relatedSolution":191},106,"vps-monitoring-with-grafana-and-prometheus",{"fr":180,"en":178,"ar":181,"es":182},"monitoring-vps-grafana-prometheus","مراقبة-الخادم-الافتراضي-vps-باستخدام-grafana-و-prometheus","monitorizacion-vps-grafana-prometheus","VPS Monitoring with Grafana and Prometheus","Deploy Prometheus 3.x, Grafana 13.x, Node Exporter and Alertmanager on your VPS with Docker Compose. Dashboards, alerts and hardening.","2026-03-06T00:00:00+00:00","2026-10-05T14:05:27+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[189],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fmonitoring-vps-grafana-prometheus-poster.svg",{"categorySlug":174,"appSlug":192},"grafana",{"id":194,"slug":195,"slugs":196,"title":200,"excerpt":201,"readTime":202,"views":18,"isPinned":19,"noindex":19,"publishedAt":203,"updatedAt":204,"category":205,"categories":206,"featuredImage":30,"bgImage":31,"posterImage":208,"relatedSolution":209},107,"monitor-your-vps-in-real-time-with-netdata",{"fr":197,"en":195,"ar":198,"es":199},"monitorer-vps-netdata","راقب-خادمك-الافتراضي-vps-في-الوقت-الفعلي-باستخدام-netdata","monitorizar-vps-en-tiempo-real-con-netdata","Monitor your VPS in real time with Netdata","Install Netdata on your VPS for per-second real-time monitoring: thousands of metrics, zero configuration, alerts included.",3,"2026-03-05T00:00:00+00:00","2026-09-07T11:26:10+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[207],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fmonitorer-vps-netdata-poster.svg",{"categorySlug":174,"appSlug":210},"netdata",true,1794270402537]