Fail2Ban not blocking login attemps from ProFTP

I’ve noticed FTP getting turned on. I noticed last time it happened that some of my php updates had ftp in the name so I’m kinda watching with every update now to see if it comes back on. I used the interface to tell it to NOT start on reboot. At this point I’m dead certain it is set properly via the interface.

Last php update had no mention of an ftp module and I have deleted php7 in the meantime.

Updating php-net-ftp cannot possibly effect the state of the ProFTPd service.

And, unless there’s a bug in the package, updating ProFTPd packages also will not re-enable a service that has been disabled. Updates are supposed to respect the current configuration.

After the last time it popped up, knowing I hadn’t rebooted, and noted that it seemed to come back about the same time as some updates. For now, I’m just keeping an eye on it. First couple of times I assumed I’d inadvertently turned it on somehow. Last time I’m sure I didn’t. So… Just confirming what the OP saw. I’m on D11, they are D12.

Could be a buggy package. :man_shrugging:

Yeah. I wasn’t going to mention it until I knew what was going on but then this came up here.

You could just uninstall proftpd, as well. That’d really prevent it from started again on updates.

Er, I guess it’s proftpd-basic and proftpd-mod-crypto packages.

1 Like

Proftp just updated and started. Sigh.


Synchronizing state of proftpd.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable proftpd
Created symlink /etc/systemd/system/multi-user.target.wants/proftpd.service -> /lib/systemd/system/proftpd.service.
Setting up proftpd-mod-crypto (1.3.7a+dfsg-12+deb11u5) ...
Setting up proftpd-mod-wrap (1.3.7a+dfsg-12+deb11u5) ...
Setting up proftpd-basic (1.3.7a+dfsg-12+deb11u5) ...
Processing triggers for man-db (2.9.4-2) ...

root@main:~# systemctl status proftpd
● proftpd.service - ProFTPD FTP Server
     Loaded: loaded (/lib/systemd/system/proftpd.service; enabled; vendor preset: enabled)
     Active: active (running) since Sun 2025-03-02 17:37:07 EST; 2min 10s ago
   Main PID: 433746 (proftpd)
      Tasks: 1 (limit: 19031)
     Memory: 4.3M
        CPU: 167ms
     CGroup: /system.slice/proftpd.service
             └─433746 proftpd: (accepting connections)

That’s expected. It is enabled.

Or, are you saying the package update re-enabled it after it was previously disabled?

Did you actually use systemctl disable proftpd to disable it (or do the same in Bootup and Shutdown?). Merely stopping it will not disable it.

Though, I guess it does look like it’s creating the “wants” symlink during the update.

If it really is re-enabling, it is a packaging bug, and should be filed upstream with the Debian folks, as they maintain that package. Packages should not re-enable themselves.

I can’t try to reproduce as I only see one version of the proftpd packages in the Debian 12 repos.

But, again, if you’re not using it, you can just uninstall it.

Yeah, it restarts. It was disabled via the B/S menu. Like I said earlier in the thread, just mentioned it to backup OP’s observation. But, yeah. Package problem.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.