Hello,
I've stumbled upon blockhosts looking for a denyhosts-like program to do what it does for ftp/imap/pop connections.
It's now running on a testbed where I've made the following changes to the blockhosts.conf file:
HOSTS_BLOCKFILE changed from /etc/hosts.allow to /etc/hosts.deny
COUNT_THRESHOLD changes from 7 to 20
LOGFILES changed to LOGFILES = [ "/var/log/auth.log", "/var/log/proftpd/auth.log", "/var/log/mail.log" ]
Then since I was running proftpd in standalone mode I've recompiled it with mod_wrap2 to support it looking through hosts.deny and that works without issue, it'll block when an IP is in the file.
However I'd very much like to use the spawn command to launch blockhosts upon a login to block faster, this works flawlessly for sshd, however I can't seem to let it trigger the command.
What I've included in my hosts.deny file:
sshd, proftpd, : ALL: spawn (/usr/bin/blockhosts.py --verbose --echo "%c-%s" >> /var/log/blockhosts.log 2>&1 )& : allow
Some logs from the /var/log/auth.log file:
Sep 26 10:03:26 mar proftpd[24572]: mar.co (::ffff:211.49.40.231[::ffff:211.49.40.231]) - USER Administrator: no such user found from ::ffff:211.49.40.231 [::ffff:211.49.40.231] to ::ffff:ip.of.the.server
Sep 27 16:21:45 mar proftpd[17123]: mar.co (::ffff:my.own.ip.address[::ffff:my.own.ip.address]) - USER test: no such user found from ::ffff:my.own.ip.address [::ffff:my.own.ip.address] to ::ffff:ip.of.the.server
Any help on how I could make this work? I'm currently running the script via a cron, which works, but it's not an optimal situation.
Travel Travel reports, it is all about food
Montreal: Schwartz's, Le Petit Alep
Albums: Pictures and some notes
ITRANS Song Book Hindi, Urdu, Marathi song lyrics
Online ITRANS Web Interface
BlockHosts block hosts
BlockHosts FAQ
BlockHosts Forum
CD Inserts & Envelopes Web Interface
Nisha Ganatra's Films
Cake: starring Heather Graham
Email: avinash@aczoom.com
Copyright © 1995-2016 Avinash Chopde, avinash@aczoom.com
Proftpd trigger
> However I'd very much like to use the spawn command to launch blockhosts upon a login
> to block faster, this works flawlessly for sshd, however I can't seem to let it trigger the command.
Things to look for:
1) Try a test run - when you connect with FTP, does a entry show up in blockhosts.log file?
If not, then the hosts.allow line is not working - the service may not be named proftpd for example.
2) Since cron entry works, the pattern is not a issue, that is being detected by blockhosts. One thing to look for, though may be unlikely, is to find out whether the proftpd log is not being written when blockhosts is spawned by hosts.access. This may be hard to check - look at timestamps in both log files. Or maybe if this is suspected to be a problem, add a
sleep 10 ;before /usr/bin/blockhosts in the spawn line.I've been doing tests using
I've been doing tests using an ftp client, which would show up in the auth.log file, however nothing in the blockhosts.log file. When I'd then connect with SSH it'd immediately trigger and also see the proftpd logfile and add it to the count.
So indeed I'd been thinking it's not picking up on the daemon. I did as you said and added in the sleep and checked the logs... however nothing, I did the same for ssh to make sure that the command was still running, which indeed activated after some seconds.
And I'm sure that proftpd checks the file as well as I can input my own ip and I'll be blocked, remove it again and I can log in without issue. The logs all start with the normal proftpd daemon name, so certainly that should be correct?
I'm running on a debian 5 with direct admin, incase that could be useful. Proftpd is compiled through the custombuild function, and proftpd --list gives me the following modules:
Compiled-in modules:
mod_core.c
mod_xfer.c
mod_auth_unix.c
mod_auth_file.c
mod_auth.c
mod_ls.c
mod_log.c
mod_site.c
mod_delay.c
mod_facts.c
mod_ident.c
mod_ratio.c
mod_readme.c
mod_tls.c
mod_wrap2.c
mod_cap.c
Any ideas what could be causing it not triggering?
Should not run as daemon
> So indeed I'd been thinking it's not picking up on the daemon.
Oh, if it is running as a daemon, then hosts.allow will never trigger - since it is not starting proftpd at all.
There are ways to setup proftpd to run under inetd - the help files there should have information - it should not be run standalone, so that would the place to check.
If it is running under inetd, then the thing is to find the right name - it might be in.proftpd for example, if proftpd does not still work.
Why does sshd trigger as daemon then?
Then... I wonder why sshd does trigger, considering that's a daemon as well?
sshd is always running and spawns a child process when someone's logged in, proftpd does the same.
But we're not checking for succesful logins..
I don't really want to run it under inetd but I guess there's no other way then.
use mod_wrap2
It is all in proftpd - there are two choices, using inetd (and then name is in.proftpd) or mod_wrap.
If you have mod_wrap, maybe it is not being loaded or running.
mod_wrap2 may have more details.
That's exactly what I've
That's exactly what I've compiled it with. Without it it would just ignore the hosts.allow file. After re-compiling and enabling it it would block access when an IP was in the hosts file and upon removal it'd indeed allow it again.
I'm not sure if you're familiar with the module but I'll try regardless, there are my settings for proftpd 1.3.3:
Note that I have compiled it with the submodule mod_wrap2_file, though it won't show that.
Compiled-in modules:
mod_core.c
mod_xfer.c
mod_auth_unix.c
mod_auth_file.c
mod_auth.c
mod_ls.c
mod_log.c
mod_site.c
mod_delay.c
mod_facts.c
mod_ident.c
mod_ratio.c
mod_readme.c
mod_tls.c
mod_wrap2.c
mod_cap.c
Built With:
configure '--prefix=/usr/local' '--sysconfdir=/etc' '--localstatedir=/var/run' '--mandir=/usr/local/man' '--without-pam' '--disable-auth-pam' '--with-modules=mod_ratio:mod_readme:mod_tls:mod_wrap2' 'LDFLAGS=-static'
from proftpd.conf:
WrapEngine On
WrapTables file:/etc/hosts.allow file:/etc/hosts.deny
WrapServiceName proftpd
So.. is there something (not so) obvious I'm missing?
Probably missing hosts_options support
> So.. is there something (not so) obvious I'm missing?
No, everything looks fine - especially since it does block IP addresses in hosts.allow
Most likely mod_wrap2 is very old and not updated "man 5 hosts_options" suggests that executing shell commands is a new option, and I don't see that mentioned in the mod_wrap2 page.
So, it is missing the full support for hosts.allow, that leaves only two options: inetd for proftpd or use cron to run blockhosts.py periodically.