detecting-port-scanning-with-fail2ban

Create iptables rules that log SYN packets to closed ports with a PORTSCAN_DETECTED prefix, then write a Fail2ban filter matching that prefix and a jail pointing at /var/log/kern.log. Validate matches with fail2ban-regex before enabling the jail.

Enable the built-in sshd jail in jail.local with maxretry 3, findtime 300, and a bantime of 7200 seconds. Fail2ban parses /var/log/auth.log for failed logins and bans the source IP using iptables-multiport.

Common causes are a backend mismatch (backend = systemd reads the journal, not /var/log/kern.log), log entries never being written because an earlier iptables ACCEPT rule matched, or a filter regex that matches zero lines. Run fail2ban-regex against the actual log file to confirm non-zero matches.

No. Fail2ban is per-source and log-driven, so nmap -T1 slow scans evade short findtime windows and distributed scans across many source IPs cannot be correlated. Pair it with a network IDS and widen findtime or add a long-window jail for slow scans.

Install iptables-persistent and run netfilter-persistent save to preserve the iptables rules across reboots. Fail2ban itself recreates its chains on service start, but custom logging chains like PORTSCAN must be restored from saved rules.