vsftp hanging

When I try to use blockhosts for vsftp I am allowed to give my username and password but then the session just hangs. The following is in my hosts.allow file:

vsftpd: ALL: spawn (/usr/bin/blockhosts.py --verbose --echo "%c-%s" >> /var/log/blockhosts.log 2>&1 )& : allow

and I changed the pattern in blockhosts.cfg to look like this:

"VSFTPD-Fail": re.compile(r"""vsftp\(pam_unix\)\[\d+\]: authentication failure; logname=\[(?P<user>.*)\] uid=\d+ euid=\d+ tty=\.* ruser=\.* rhost="(?P<host>\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})"""),

to match my entries in /var/log/messages which look like this

Dec 25 21:18:58 myhost vsftpd(pam_unix)[21989]: authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=210.118.217.194

Any thoughts?

what is hanging?

Not clear what is hanging - what do you mean by "session is hanging"?
If it is your FTP client, then it is likely related to something in VSFTPD itself, you may need to try their mailing lists for help, check up your DNS and reverse-DNS issues on your system, etc.

As for blockhosts, is there a specific reason you need to match the line you listed? Does it not print the following line in your logs:
Fri Jan 21 15:56:57 2005 [pid 6726] [test] FAIL LOGIN: Client "10.204.30.15"
The above line is already matched by the default rules in blockhosts.py

If you need to debug blockhosts, you can run it with the debug option, to see what it matched.

Well

When not using blockhosts, and connecting from an ftp client, I enter my username and password and
get an 'ftp>' prompt. When using blockhosts, I enter my username and password and then get nothing, no
prompt, no error, nothing it hangs. I have to ^Z the ftp client and kill it manually. I have tried to research this on other sites but have not found any useful information.

I changed the pattern for vsftp because I need to match the log line listed in my original post:

Dec 25 21:18:58 myhost vsftpd(pam_unix)[21989]: authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=210.118.217.194

check logs, run in debug mode

1-> what does your syslog show when you connect using FTP?
blockhosts.py sends messages to it.
Add --debug if needed to get more output.
Log file is likely named "messages" in /var/log

2-> what happens when you run the blockhosts.py by hand? Does it hang?

3-> try other commands in the spawn line, other than blockhosts.py, maybe there is something funny with hosts.allow?

I'm also getting VSFTPd hanging with BlockHosts

Hi, I'm also getting this problem. VSFTPd hangs immediately after login.

I've installed using BlockHosts-1.0.3-1.noarch.rpm and used the sample /etc/hosts.allow file listed in http://www.aczoom.com/tools/blockhosts/INSTALL . I have NOT altered /etc/blockhosts.cfg .

The only thing I have changed is that I have added vsftp and --debug in the hosts.allow file, thus:

sshd, proftpd, in.proftpd, vsftpd: ALL: spawn (/usr/bin/blockhosts.py --verbose --debug --echo "%c-%s" >> /var/log/blockhosts.log 2>&1 )& : allow

FTP sessions then hang after the client enters the password, thus:

$ ftp thoth.nam-vets.org
Connected to thoth.nam-vets.org (82.163.126.22).
220 (vsFTPd 1.2.1)
Name (thoth.nam-vets.org:aoakley): aoakley
331 Please specify the password.
Password:

(Hangs forever here until I hit ^z)
[1]+ Stopped ftp thoth.nam-vets.org

Here are the results of my /var/log/blockhosts.log file:

blockhosts 1.0.3 started: 2006-02-14 10:54:55
... echo tag: 207.210.77.4-vsftpd@192.168.0.253
return ("<%s at 0x%x: %r>"
Debug mode enabled.
from config file, got logfiles: ('/var/log/secure',)
File lock obtained (/tmp/blockhosts.lock) for excluding other instances
1: got line: # allowed to use the local INET services, as decided
1: got line: # by the '/usr/sbin/tcpd' server.
1: got line: ALL: 192.168.0. : allow
1: got line: # Always allow from MessageLabs/Star
1: got line: ALL: 62.231.149. : allow
1: got line: #---- BlockHosts Additions
... seen all state 1 lines, now inside blockhosts markers at offset 282
2: ignore line ALL: 71.198.151.6 : deny
2: got host-count-date 69.36.185.183 2 2006-02-14 10:27:00
2: got host-count-date 71.198.151.6 1569 2006-02-14 10:23:00
2: found logfile name line: /var/log/secure
... found both markers, count of hosts being watched: 2
block-file: Got previous abusive hosts data:
{'71.198.151.6': HostData(1569, datetime.datetime(2006, 2, 14, 10, 23)), '69.36.185.183': HostData(2, datetime.datetime(2006, 2, 14, 10, 27))}
-------------------
block-file: Got remaining lines:
['\n', '# Command to execute the blockhosts script\n', '# Denies access to IPs who repeatedly get SSH/FTP passwords wrong\n', 'sshd, proftpd, in.proftpd, vsftpd: ALL: spawn (/usr/bin/blockhosts.py --verbose --debug --echo "%c-%s" >> /var/log/blockhosts.log 2>&1 )& : allow\n']
-------------------
------- looking into log file: /var/log/secure
SecureLog open:
first_line: Feb 12 05:14:00 thoth vsftpd[9681]: pam_succeed_if: requirement "uid < 100" not met by user "aoakley"
file length: 291133
... securelog, loading: /var/log/secure 291133
------- finished looking into log file: /var/log/secure
------- collecting block file updates ---
Collecting abusive_hosts counts info for block-file
Collecting log file offset info for block-file
... updates: counts: hosts to block: 1; hosts being watched: 2

If I remove vsftpd from the hosts.allow blockhosts.py line then this problem goes away- FTP clients log in and can work with no problems. Any hints much appreciated, thanks.

no conclusions, try this - testing using /bin/echo?

From the blockhosts log output, looks like it exited normally, did not hang, so not clear why vsftpd hangs.

In hosts.allow, instead of:

vsftpd: ALL: spawn (/usr/bin/blockhosts.py --verbose --debug --echo "%c-%s" >> /var/log/blockhosts.log 2>&1 )& : allow

try something other than blockhosts.py - if that too hangs, then the problem is with the tcpd wrappers/hosts.allow use on your system:


vsftpd: ALL: spawn (/bin/echo "Testing: %c-%s" >> /var/log/blockhosts.log 2>&1 )& : allow

and then try ftp again, and see what lines show up in /etc/blockhosts.log and if vsftpd hangs again.

echo suggestion gives "Service not available"

Another "Me Too" to add to this one. I'm having the same problem, so I was investigating it.

/etc/hosts.allow empty, connects fine

Then adding:
vsftpd: ALL: spawn (/bin/echo "Testing: %c-%s" >> /var/log/blockhosts.log 2>&1 )& : allow

gives the following on the ftp client:
[jackie@jackie ~]$ ftp localhost
Connected to localhost.localdomain.
421 Service not available.
ftp>

gives an error in the syslog:
Mar 17 13:42:39 jackie vsftpd[30241]: error: /etc/hosts.allow, line 28: bad option name: "%c-%s""

The ":" messes up the line on hosts.allow.

Remove the ":" and the ftp client still doesn't get to a prompt, which says to me that the problem is with vsftpd's tcpwrappers and not a problem with blockhost.

I recently found and tried

I recently found and tried to use this updated filter. Only to find that my install doesn't like it? I get an error of " unknown specifier: ?P." on that filter and the script dies. Did something not copy/paste from the forum?

Try it now

The original posting was missing <user> and <host> after the ?P due to forum software display issues, now fixed it, if you cut-n-paste the regexp again, should work fine now.

You're so smart. ;-) I

You're so smart. ;-) I looked at it a good 30 minutes and didn't even catch that difference. But then, I haven't written any program in quite some time. Back before Windows 95, I think. So, I might be just a bit out of practice. Now we'll see if it catches my occasional ftp attack. I just don't understand why they changed the log entry with this latest version.

well, thought that was it....

2 days in a row, hundreds or thousands of failed login attempts on Administrator. The "fixed" filter doesn't cause an error, it just doesn't catch anything. Any suggestions?

think I found the problem...

I finally had time to look at the filter again (been real busy with work, lately). Are the brackets ([ and ]) required on that user field? I don't see them on the host field, and there aren't brackets around the attempted login name, anyway. I removed the brackets, and will try to give an update on whether or not that actually fixed it for me.

correct regular expression

The pattern as listed at the top of the forum topic will not work - it uses vsftp instead of vsftpd, and has brackets [ and ] around the logname, which don't exist in the lines in /var/log/messages.

Simpler regular expression (it is all on one line, and needs correct python spacing at beginning of line when adding to blockhosts.py or blockhosts.cfg):

"VSFTPD-pamunix": re.compile(r"""vsftpd\(pam_unix\)\[\d+\]: .* rhost=(?P<host>\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})"""),

log entries

This entire thread wouldn't have existed if they had just left the old log entries in the code. I really wish I knew why they changed that. Anyway, thanks for the updated filter. The vsftp/vsftpd difference was another thing I'd just overlooked. I'll be watching for the next FTP attack to see how things go and post the results.

what a nightmare....

That filter STILL isn't catching them. Yes, blockhosts.py is running per connection. Yes, tcpwrappers are in use (vsftpd is not running daemon mode, it's going through xinetd). And still, I have 3582 failed login attempts on Administrator (I'm NOT a stupid Windows box, so that account is never going to get through).

Here's my log line:

Jan 30 08:18:22 host vsftpd: pam_unix(vsftpd:auth): authentication failure; logname= uid=0 euid=0 tty=ftp ruser=Administrator rhost=src_ip

Seems obvious that I'm, for whatever reason, needing yet another filter. *grumble*

changed log line?

That log line is quite different from the original log line in this forum posting - I am surprised that vsftpd is changing log lines that often?

In the end, maybe we'll just have to part company with vsftpd - may not be possible to once and for all make it work with log-scanning tools like blockhosts.

Not tested, but this is a cut-down expression that should cover both the log lines, so may match multiple times, but that may be prefereble than not matching a single line:


"VSFTPD-pamunix": re.compile(r"""vsftpd.*pam_unix.*authentication failure; .*rhost=(?P<host>\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})"""),

I'm not sure it's all vsftpd to blame

Seems the version of PAM being used is what we're actually looking at here. vsftpd 2.0.5 seems to *only* generate xferlog entries now. I didn't see any configuration option to enable additional logging, but may have overlooked it, too. All in all, that log line, with the service ID ignored, could be used to catch any and all hack attempts on any service that uses PAM. So, SSH may be caught by the same filter, provided the ID token wasn't hard-coded. SMTP AUTH hacking, on my system, generates the same log entries, but with "qmail:" in place of "vsftpd:auth". Same with SSHD. And fewer filters could actually make it process faster. Right?

just a final note....

This last filter has finally done the trick. A mere 9 attempts were made on my server before the site was blocked. That's much better than the thousands I was seeing. As I said, I may play with that filter a little to see about having it catch more of the attacks. It's just the part within the parentheses that tells what service and function that log entry is for.

still not working

Kindoff new to blockhosts (was using denyhosts before but didn't liked the ssh only part), but that vsftpd regexp doesn't seem to work :(

Everything else works, no problems with vsftpd. Host is X/OS Linux 4 (RHEL4 clone) running vsftpd-2.0.1-5.XOS.1.EL4.5. I understand your problem with vsftpd, but at least with RHEL and simular Linux distro's one should not have the troubles of constantly changing log entries ;)

I have log entries like this one in /var/log/messages:

Jun 21 06:58:03 scorpion77 vsftpd(pam_unix)[19840]: authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=10.1.2.2 user=jeroen
Jun 21 07:06:32 scorpion77 vsftpd(pam_unix)[19933]: check pass; user unknown
Jun 21 07:06:32 scorpion77 vsftpd(pam_unix)[19933]: authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=127.0.0.1

nevermind

Nevermind, forgot about "ALL: myhosts in /etc/hosts.allow.... :$

However I do have those weird problems with vsftpd when used with blockhosts like others are describing here, will try to debug that one. Perhaps putting blockhosts in a cronjob is a (semi)nice solution to that one.

Hanging, continued

So, did you find a fix for the login hang ?

I am experiencing the same issue with vsftpd 2.0.1 and 2.0.5. Any process spawned from hosts.allow cause vsftpd login to timout.

Centos 4.4 x64

same here

hanging on CentOS 4.4 with vsftpd-2.0.1-5.EL4.5

Has anyone found a solution?

Any luck

I'm having the same problems.. did anyone have any luck fixing this?

vsftpd troubles

Was this ever resolved? vsftpd always hangs on connect when blockhosts is enabled.

Was there a final regex for this?

Same problem here

I'm having the same hanging issues with FC5 & VSFTPD... And I was actually looking forward to using this software...

Try the echo suggestion above?

vsftp hanging - testing using /bin/echo

shows how to test something other than blockhosts - if the /bin/echo command also results in failure, then take a look at the tcp wrappers requirements - listed in the BlockHosts page, maybe hosts options are not supported, or there is some other problem in that area.

Another thing to try is to remove the %c-%s and %h tags in the command - maybe those are causing delay in your hosts.access setup, remove the --echo and --check-ip options, make it look like:

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

Echo suggestion giving "service not available"

Same thing happening here, I get lots of ftp attacks and was hoping blockhosts would stop them. With this line:

vsftpd: ALL: spawn (/usr/bin/blockhosts.py --verbose --mail --echo "%c-%s" --check-ip "%h" >> /var/log/blockhosts.log 2>&1 )& : allow

ftp login attempts just time out after sending the password. With this line:

vsftpd: ALL: spawn (/bin/echo "Testing: %c-%s" >> /var/log/blockhosts.log 2>&1 )& : allow

I get "Service not available" when trying to connect.

The logs make it appear that blockhost is indeed completing its job.

With no vsftpd: line, ftp connects just fine.

Would running /usr/bin/blockhosts.py --verbose --mail --echo "%c-%s" --check-ip "%h" >> /var/log/blockhosts.log in a cron every minute instead of in hosts.allow be a possible workarond? I would rather not do that, but if it's the only way to make it work with vsftp...

no, running in cron would not help

1: if the vsftpd: ALL: spawn (/bin/echo.... ) line is not working, then most likely there is not support for TCP WRAPPERS - that should be easy to fix though, maybe check a forum on the OS you are using. On Fedora FC5 or later, it is certainly enabled by default.

2: running in cron may not help - unless vsftpd is 2.05 or later - see this topic for the configuration required to get vsftpd to exit after a fixed number of failed connections help-ftp-attack-not-being-caught - otherwise vsftpd will allow thousands of attacks in a single session

3: running in cron, for home servers, may be very wasteful in terms of resources - attacks may happen only 2-3 times a day, so most of the time it has to do nothing

Use xinetd instead - wrappers work there!!!

Couldn't get it to work either. Ended up having to use xinetd where the wrappers are working as intended.

I ran strace on the client side and could not discern anything strange with/without vsftpd in the hosts.deny file - other than the timeout message after 300 seconds! The next step would be to download the source and run the code turning on printf statements all over the place until an issue is identifiable. However, that would seem to be way too much work for something that has an alternative solution!

What's the big deal about running vsftpd as a daemon vs. via xinetd?

Cheers,
tkb.