• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx

  • We are developing a new feature in Plesk that will help you promote your websites or business on social media. We want to conduct a one-hour online UX test to present the prototype and collect feedback. If you are interested in the feature, please book a meeting via this link.
    Thank you in advance!
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Issue fail2ban doesn't ban port scan

PeterKi

Regular Pleskian
Yesterday, my Ubuntu 18 server with Obsidian 18.0.36 was port scanned with ssh.
Plesk fail2ban did not block this scan.

Why doesn't the ssh filter kick in here?

The log lines in auth.log look like this:
Jul 2 01:14:30 host12907 sshd[14010]: Failed password for root from 64.225.102.51 port 41676 ssh2
Jul 2 01:14:30 host12907 sshd[14011]: Failed password for root from 64.225.102.51 port 41696 ssh2
Jul 2 01:14:30 host12907 sshd[14032]: Failed password for root from 64.225.102.51 port 42768 ssh2
Jul 2 01:14:30 host12907 sshd[14008]: Failed password for root from 64.225.102.51 port 41610 ssh2
Jul 2 01:14:30 host12907 sshd[14019]: Failed password for root from 64.225.102.51 port 41958 ssh2
Jul 2 01:14:30 host12907 sshd[14027]: Failed password for root from 64.225.102.51 port 42528 ssh2
Jul 2 01:14:30 host12907 sshd[14038]: Failed password for root from 64.225.102.51 port 43020 ssh2
Jul 2 01:14:30 host12907 sshd[14030]: Failed password for root from 64.225.102.51 port 42660 ssh2
Jul 2 01:14:30 host12907 sshd[14035]: Failed password for root from 64.225.102.51 port 42860 ssh2
Jul 2 01:14:31 host12907 sshd[14041]: Failed password for root from 64.225.102.51 port 43112 ssh2
Jul 2 01:14:31 host12907 sshd[14022]: Failed password for root from 64.225.102.51 port 42360 ssh2
Jul 2 01:14:31 host12907 sshd[14029]: Failed password for root from 64.225.102.51 port 42584 ssh2
 
I did check the filter with
fail2ban-regex --print-all-matched /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf
and the lines were filtered correctly.
Thus, it obviously is the ssh jail which doesn't block the scan as expected.
The current jail shows:

[ssh]
enabled = true
filter = sshd
action = iptables[name=ssh, port=ssh]
logpath = /var/log/auth.log
maxretry = 5


How can I get the jail to process failed attempts on all ports?
 
@PeterKi This is Not the answer to your Fail2Ban specific questions, but it's an alternative method for hardened ssh protection, than say, using Fail2ban .
You can use your server provider's panel and allow access to port 22, ONLY, via specified IPv4 and IPv6 adresseses (...those YOU use regularly!) We use IONOS and this is an easy option to configure. Then, you can replicate this 'access ONLY, via specified IPv4 and IPv6 adresseses' (just in case ;) ) within the Plesk Firewall setup > https://your-hosting domain:8443/plesk/modules/firewall/ > SSH (secure shell server) You can then create, apply and test (to verify) SSH access ONLY via Private Key and once that's complete, you can disable SSH password acccess within etc/sshd. If you configure all of the preceding correctly, you can forget about any SSH port scans concerns, plus safely ignore any "...you should change ssh from port22 to a.n.other port number) type posts too.

In addition, if you want to (we did & its work perfectly ever since including chrooted domains) you can re-configure all of your FTP access, by disabling any access via FTP and allowing access ONLY via SFTP, which can use all of your SSH setup criteria above and yes, all SFTP access can ONLY be via Private Key too.
 
+1 for what @learning_curve said. Proper security practices should dictate discretionary ACLs for accessing any service. Things like SFTP/FTP are hard in a "shared hosting" environment. Everything else should be perfectly possible, and ideally you have more authentication than just a priv key/ssh pass :)
 
Thanks for all the replies.
As I said, the fail2ban filter for ssh works correctly.
That is, the sshd filter detects all the failed attempts via ssh, as can be verified with:
fail2ban-regex --print-all-matched /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf
After the filter, the jail kicks in and as the given jail for ssh reads, it bans repeated failed attempts to the actually configured sshd port.
It does not ban failed attempts to other ports, though.
I know, that those other ports are not configured for ssh, but I nevertheless want to have the port scanning IP banned for good.
I suppose the action line in the sshd jail can be configured to not only ban failed attempts to the single actually configured sshd port, but to any port.
Alas, I don't know how to change the action line so that fail2ban sums up failed ssh attempts to any port in its maxretry counter.
Would it work correctly if I leave out the port specification at all?
Or should the port specification just specify port=all?
Or should the jail specification look totally different?
 
Why are those ports even open then? Just close them up with a firewall

F2b uses regexs for matching so you can always write your own filter (which is generally recommended over modifying Plesk default filters)

F2b docs and the preexisting f2b templates are good starting points.
 
I did not modify the plesk default filter, and the high ports are not open.
I want to ban a scanning system because it creates system load, obfuscates other problems by cluttering the log file and possibly tries other methods to find a vulnerability.
 
Back
Top