There's no such thing as a stupid question, but they're the easiest to answer.
JoinTour
Login
Search
Tag Cloud
access acer asus batch bios bsod computer crash desktop driver drivers error ethernet excel freeze gaming hard drive hardware hdmi internet laptop lcd malware memory modem monitor motherboard network printer problem ram registry router slow software sound toshiba trojan usb video virus vista wifi windows windows 7 windows 7 32 bit windows 7 64 bit windows xp wireless xbox
Search
Search for:
Tech Support Guy Forums > Operating Systems > Linux and Unix >
Problem using hosts.allow with vsftpd

Reply  
Thread Tools
coulterp's Avatar
Senior Member with 1,625 posts.
 
Join Date: Oct 2003
Location: Surrey, UK
Experience: Advanced, but always ready to learn more!
12-May-2007, 08:14 AM #1
Problem using hosts.allow with vsftpd
I've asked this question on a couple of dedicated Linux forums but so far not got any responses. Perhaps more luck here!

OS: Linux CentOS 4.4 (2.6.9-42.0.10.EL)

Two issues. First more significant, the second an inconvenience more than anything.

1. VSFTPD rule and logging problem

I am seeking to use hosts.allow to allow/deny some application accesses to my Linux box. Reduce the hits on sshd for a start: one evening >3600 in a 3hr period from a single remote IP address (I use public key authentication so trying to get in on user/password is a bit of a waste of time) but in an effort to reduce those hits I am using hosts.allow/deny.

However, I have encountering a funny when trying to log attempted accesses to vsftpd.

Starting with something that is working flawlessly, here are the lines for sshd:
Code:
sshd: LOCAL  \
123.123. .some-domain.com \
    : spawn ( /bin/echo "`/bin/date` access GRANTED [process %d, server %H, address %a, client %h, info %c, username %u]" | \
    tee -a /tmp/log/my-hosts-allow-allow-rule.log | \
    /bin/mail -s "hosts.allow (sshd\:SELECTIVE) GRANTED rule triggered" name@valid-address ) & \
    : allow

# catch all other attempts, deny access and log attempt
sshd: ALL \
    : spawn ( /bin/echo "`/bin/date` access DENIED [process %d, server %H, address %a, client %h, info %c, username %u]" | \
    tee -a /tmp/log/my-hosts-allow-deny-rule.log | \
    /bin/mail -s "hosts.allow (sshd\:SELECTIVE) DENIED rule triggered" name@valid-address ) & \
    : deny
Both of these work perfectly logging the results to file and emailing the logs. The match on 123.123. (my office IP/domain) works.

Now for vsftpd:
Code:
vsftpd: ALL \ : allow
This works perfectly; my SmartFTP client from an office PC logs straight in as expected.
But I want to log attempts to access vsftpd, so now the issue. I try:
Code:
vsftpd: LOCAL 192.168. \
123.123. .some-domain.com \
    : spawn ( /bin/echo "`/bin/date` access GRANTED [process %d, server %H, address %a, client %h, info %c, username %u]" | \
    tee -a /tmp/log/my-hosts-allow-allow-rule.log | \
    /bin/mail -s "hosts.allow (vsftpd\:SELECTIVE) GRANTED rule triggered" name@valid-address ) & \
    : allow
These lines write out an "access" granted line to the tee'd log file and even successfully send the email of the log file (saying access is granted!), all as expected - but SmartFTP actually fails to logon, times out, re-tries, time-outs, repeating until the re-try limit is reached. Access is blocked. Remove the logging lines again ... and SmartFTP gets straight in as before.
What is happening here? The SSHD rule(s) prove the (same) logging and emailing lines work fine, and the vsftpd: ALL test rules show SmartFTP can log on fine from the office PC. So why is the addition of the logging/emiling lines to the vsftpd rules causing FTP logon to fail?

I have noticed that for the sshd allow/deny rule the log file is written with permissions 0644.
When the vsftpd logging rule variant is applied the log file is written with permissions 0600. I cannot see why.

What is different about vsftpd? Is there something in the vsftpd configuration I am not setting?
Any suggestions welcome.

2) Second point, although not so much as an issue

Regarding the line:
Code:
123.123. .some-domain.com \
I find if I use:
Code:
123.123. \
I get access granted or denied (as appropriate to whether this is a match un an access or deny rule) with this fine.

But if I use:
Code:
.some-domain.com \
I do not get a match and fail to logon (if it is an access grant rule).
So the match in the first line is because of the IP address matching and not the domain name. Why? I should get access matching in a rule for either IP or domain name (where I have double-checked both are valid), or am I misunderstanding something.

If you've read this far ... apologies for being rather long-winded!
TIA.
Reply

THIS THREAD HAS EXPIRED.
Are you having the same problem? We have volunteers ready to answer your question, but first you'll have to join for free. Need help getting started? Check out our Welcome Guide.

Search Tech Support Guy

Find the solution to your
computer problem!




Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
WELCOME TO TECH SUPPORT GUY! Are you looking for the solution to your computer problem? Join our site today to ask your question -- for free! Our site is run completely by volunteers who want to help you solve your computer problems. See our Welcome Guide to get started.
Thread Tools



Facebook Facebook Twitter Twitter TechGuy.tv TechGuy.tv Mobile TSG Mobile
You Are Using:
Server ID
Advertisements do not imply our endorsement of that product or service.
All times are GMT -4. The time now is 09:14 AM.
Copyright © 1996 - 2011 TechGuy, Inc. All rights reserved.

Powered by Cermak Technologies, Inc.