Home › Forums › BlockHosts

blockhosts causes tcp-wrappers to block SIGALRM

Tue, 2011–Jul–12

after I ssh to a host with blockhosts enabled...
jason@ellymay ~ $ perl -e '$SIG{ALRM}=sub{print"ALARM\n";}; alarm 1; sleep 5'
jason@ellymay ~ $

after I ssh to a host withOUT blockhosts enabled...
jason@ellymay ~ $ perl -e '$SIG{ALRM}=sub{print"ALARM\n";}; alarm 1; sleep 5'
ALARM
jason@ellymay ~ $

for a gentoo system this wreaks havoc when compiling programs.. i.e.

example..

checking for mntctl function and struct vmount... no
checking for one-argument getmntent function... yes
checking sys/mntent.h usability... no
checking sys/mntent.h presence... no
checking for sys/mntent.h... no
checking for struct statfs.f_fstypename... no
checking for library containing nanosleep... none required
checking for working nanosleep...
(and the compile will hang here until a ctrl-c is sent)

here is how my /etc/hosts.allow is set up..
sshd: ALL: spawn (/usr/bin/blockhosts.py --verbose --echo "%c-%s" >> /var/log/blockhosts.log 2>&1 )& : allow

any ideas?

-dirtbag

‹ Trying to add custom regex strings... Mar 10 15:18:01 domains blockhosts[5599]: ERROR: failed to parse date for ip 189.114.199.51, using now value:#012 time data ' ›
Tue, 2011-07-12 19:23 — admin

Strange... is there any ssh command going on?

So this is not really any ssh command - it is actually a ssh terminal that is showing different behavior?

I tried this on a Fedora 13 system

ssh into the system, opens up bash shell.
Run your perl command.
It works - shows ALARM output.

When running local commands, there is no TCP wrapper calls involved, so there should be no blockhosts.py invocation at all.

After you ssh into a system, note down last entry in /var/log/blockhosts.log
Then run your perl command. Is there any other entry in /var/log/blockhosts.log? If not, then blockhosts.py did not run.
That would narrow down things to TCP wrapper or some other thing going on.

Another thing: before all the blockhosts lines in /etc/hosts.allow, add something like this:
ALL: 10.0.0. : allow
ALL: 127.0.0.1 : allow

Replace 10.0.0. with your localhost address as appropriate. That would ensure that if a ssh localhost or something like that is being executed, it won't even get to the blockhosts.py line.

Wed, 2011-07-13 11:28 — Anonymous (not verified)

ok, so I did what you asked..

I did what you wanted and after I sshd to the system (with blockhosts enabled)
I saw the following in the log

blockhosts 2.5.0 started: 2011-07-13 10:55:48 EDT
... echo tag: ....................
... loaded /etc/hosts.allow, starting counts: blocked 0, watched 0
... loading log file /var/log/messages, offset: 138032974
... discarding all host entries older than 2011-07-12 10:55:48 EDT
... final counts: blocked 0, watched 0

then I ran the perl script

jason@ellymay ~ $ perl -e '$SIG{ALRM}=sub{print"ALARM\n";}; alarm 1; sleep 5'
jason@ellymay ~ $

there were no further entries in the blockhosts.log.
its the sshd shell that gets started by tcp-wrappers (via blockhosts) that has the problem.

with the ALL: 10.0.0. : allow
this is for a server that allows ssh connections from the internet.. I have already allowed the local lan traffic.. when I ssh in from another host on the internet (not in the allows) is where the problem comes into play.

-dirtbag

Wed, 2011-07-13 11:46 — admin

No ideas ...

That is very strange. In the above example, there is no ALARM output, so was that using ssh from a remote box?

In any case, if commenting out the tcp wrapper line makes things work, can't think of anything else to try. If you do find a root cause, please post an update.

If the following also shows the problem, then it is something to do with TCP wrappers and sshd interaction on that box - though I can't think of anything that could exhibit such behavior.
sshd: ALL: spawn (/bin/echo "ECHO-ONLY %c-%s" >> /var/log/blockhosts.log 2>&1 )& : allow

Finally - this may not be applicable, but ssh -t could be used to pass ^C from local keyboard to remote command.