blockhosts with proftpd-mysql

i use blockhosts on sshd and previously with proftpd succesfully, enjoying the fact that logs are a lot smaller now.
recently i switched from system based ftp users to mysql users with proftpd-mysql. the problem i see now is that for instance last night, it took an hour and 761 login attempts for proftpd before the ip was added to hosts.deny.

can someone tell me what's causing this?

i've tested it myself also by logging in with an unknown user and pass and after 15 mins i'm still not even "watched" by blockhosts....

add info

only after a sshd login (failure) it picks up the proftpd login failures.

my blockhosts additions in hosts.deny look like this:

sshd, proftpd, in.proftpd:ALL:spawn (usr/bin/blockhosts.py --verbose >> /var/log/blockhosts.log 2>&1 )&:allow

since i've moved to proftpd-mysql the name of the process in auth.log is still proftpd, the only difference with sshd login failures reports in auth.log is that in proftpd reports, the ip is enclosed in [ ] but than again, it picks up the ip correctly as soon as sshd reports login failures....

auth.log:

Aug 10 21:36:21 localhost proftpd[16748]: localhost.localdomain (web30.3w-server.com[212.112.231.212]) - USER Administrator: no such user found from web30.3w-server.com [212.112.231.212] to ***********:21
Aug 10 21:36:21 localhost proftpd[16748]: localhost.localdomain (web30.3w-server.com[212.112.231.212]) - Maximum login attempts (3) exceeded

#actually this was the 761st login attempt.

tcpd-wrapper issue?

See this article - vsftpd not well suited to tcpd wrappers

That describes how vsftpd is not suited to tcp-wrappers - the similar thing may be happening with the proftpd configuration on your system.

You can confirm this by looking at the process id [16748 in your example] - is it the same for all the 761 attempts? If yes, there is no way blockhosts can get in; tcpd-wrappers will not kick it in.

i know about this, but the

i know about this, but the id increases every attempt. also, in the tcpd-wrapper issue post they mentio n the fact that proftpd IS suited to use with blockhosts cause of the fac it has a Max Login failure. in my conf it's set to 3, so after 3 times the connection should be reset so that when they connect again the hosts.deny file gets read which triggers the blockhosts script right?
the strange thing is, it doesn't with proftpd! but today i "disturbed" someone in his brute force attacks just by connecting to my server through ssh which triggered the blockhosts script and putting his ip inthe deny file. so he may have tried 1 or 2 times after that before his connection ggot reset.
anyway, it used to work with proftpd and now not with proftpd-mysql and i just can't see why....

additional debugging...

Not sure what could be going on, looks like proftpd-mysql should work same as proftpd.

I would recommend adding more verbose logging for blockhosts - that way you can check if blockhosts is even being called for each ftp attempt (after the 3 failed attempts from a IP address).

--verbose --echo "%c-%s"
are the arguments to add to the blockhosts.py invocation in hosts.allow, see INSTALL file for more details, example.

That will help narrow down the issue - if it is tcpd wrapper, or blockhosts.py

as far as i can see now is

as far as i can see now is that it's just not running at all after failed ftp logins. only when i run blockhosts manually ofcourse it works...
maybe let proftpd go through PAM like is configured with my ssh?

anyway thanks for suggestions ac:)

found it!

i am stupid, i'm running proftpd as standalone , not throught inetd!!

that should be the root of my problem...

so proftpd-mysql can only

so proftpd-mysql can only run as standalone? as sson as i change it to inetd it won't startup at all. anybody any suggestions how i can perhaps trigger blockhosts in another way for proftpd? (in real time, not cron;)

Inetd mode

Im no expert but,

when running as inetd it spawns a process when a conenction is formed, rather than running as a system process.

so no need for invoke.rc.d

http://www.castaglia.org/proftpd/doc/contrib/ProFTPD-mini-HOWTO-ServerType.html

Hope this helps