Fail2Ban not blocking login attemps from ProFTP

SYSTEM INFORMATION
OS type and version Debian 12
Virtualmin version 7.30.4

Somehow my proftp.log gets hit constantly, like a few 100 times by one IP. It ends in USER root (Login failed): Incorrect password

I see proftp in fail2ban Jail Logs, but nothing blocked.

How can I troubleshoot that?

Also, my sftp.log (which seem to be in /) has swollen to a massive 1.7Gb - is that a part of proftp? Does that need to be specially included in fail2ban? After it works again I mean.

For the time being I stopped the ProFTP server since I don’t use it anyway.

You say you have fail2ban logs? Not sure what you mean by “Jail Logs”.
Long story short, if firewalld gets restarted, you must restart fail2ban in the default configuration.
grep -i notice /var/log/fail2ban.log
If you see ‘already banned’ then it is an order thing.

Isn’t it on rotate? Just checked on the weekly. Maybe disable proftp until sorted. Look like an attack.

double check its working. Even with alot of errors it shouldn’t get that big.

Is it activated?

1 Like

Sorry, Jail blocks
 (due to human memory issue :wink:)

mhm /var/log/proftpd/sftp.log was not in logrotate. I will add it.
For now I ProFTP is disabled. I rarely need it anyway.

In Filter Action Jails ProFTP is on [yes] - activated.

Added note: ProFTP was NOT in Dasboard > Server Status (I recall it was listed in my old old old virtualmin)

I think sftp is part of ssh so don’t confuse it with proftp.

To me it looks like it’s part of ProFTP though: /var/log/proftpd/sftp.log

After I disabled ProFTP yesterday I deleted the sftp.log (1.7Gb) and so far it didn’t build a new one.

OK. My bad there. sftp is part of ssh though. Since I don’t use proftpd I didn’t realize it used/logged like that. Since I use command line to upload I have no idea if standard GUI clients can use the openssh version instead of proftpd.

Quite interesting. I use ssh from commandline or sftp via Filezilla. I have the ftp ports blocked in the fw. But it I stop Proftp, Filezilla will not connect, just timeout.
On the mailserver that has no webmin/virualmin/proftp it works flawless
Just curious why

I think I remember reading somewhere that Debian 12 may need some modifications in fail2ban to work properly. It might have to do with where/how it logs in Debian 12. I don’t have time to chase it down at the moment.

A Virtualmin system has two ways to use sftp (FTP-over-SSH). On port 22, you will find OpenSSH, which will happily interact with an sftp client, assuming the user is allowed to login with a shell. On port 2222, you will find ProFTPd offering sftp and limited in the ways ProFTPd users are (confined to their home, but without the messiness and complexity of a chroot jail).

If you’re logging in on port 22, the log will be wherever OpenSSH is logging. And, that’s what you’d need fail2ban to follow in order to act on those failed logins.

If you’re logging in on port 2222, the log will be wherever ProFTPd is logging. And, that’s what you’d need fail2ban to follow to act on those failed logins.

OK. This is useful information I didn’t know about ProFTPd.

Unless you have changed the ssh port to something else, replace 22 with the actual ssh port

Just for clarity, that won’t change the logging.

When you have time grab sample log records you want to trigger fail2ban and put them in a temp file. Grab the jail.conf file you are using and run fail2ban-regex (see examples on a search) and you can quickly debug what’s happening

I used that recently to make a new jail for a bot that was hitting registration attempts faster than a human so i detected and banned with exponential ban time if they come back. Use a regex checker to get the regex right. .