sshd ignores /etc/hosts.allow and /etc/hosts.deny

andrej.podzimek · 2007-02-12 22:31:24

Hello everyone,

I've just found out that sshd ignores /etc/hosts.allow and /etc/hosts.deny completely on my machine. It doesn't make use of tcp_wrappers. I am using the standard Arch package. Either my settings are wrong, or this is a severe security problem. It was a terrible surprise to find out that my server is under severe dictionary attacks all the time, despite the denyhosts script I am using.

These are my settings:

/etc/hosts.deny:

ALL: ALL

/etc/hosts.allow:

# some nfs daemons: 192.168.1.0/255.255.255.0
sshd sshd1 sshd2: ALL EXCEPT /etc/hosts.evil
mysqld: 192.168.1.0/255.255.255.0

/etc/hosts.evil:

195.113.21.131
60.10.6.53

A simple experiment to verify the settings:

[root@charon etc]# tcpdmatch -d -i /etc/xinetd.conf sshd 195.113.21.131
warning: sshd: no such process name in /etc/xinetd.conf
client:   address  195.113.21.131
server:   process  sshd
matched:  hosts.deny line 5
access:   denied

[root@charon etc]# tcpdmatch -d -i /etc/xinetd.conf sshd 195.113.21.130
warning: sshd: no such process name in /etc/xinetd.conf
client:   address  195.113.21.130
server:   process  sshd
matched:  hosts.allow line 10
access:   granted

This seems to be fine. But when I go to the machine 195.113.21.131, I can simply log in with no trouble at all.

This is really strange. Does it have something to do with the xinetd warning? I am not using xinetd... Maybe I'm doing something wrong. If you have experienced such a trouble, please give me a hint.

andrej.podzimek · 2007-02-12 22:36:08

P. S. Sorry about the wrong line numbers in tcpdmatch output. I removed comments and unnecessary lines from hosts.allow and hosts. deny. In fact they do match the corresponding lines.

phrakture · 2007-02-12 22:36:55

I always thought you needed :DENY and :ALLOW after each entry in the hosts.* files. Can you try adding them?

andrej.podzimek · 2007-02-12 22:47:42

Additional information:
1) Removing the sshd line completely really disables ssh logins.
2) Adding EXCEPT <ip address> instead of the file name does not disable anything.

Conclusion:
Either the EXCEPT operator has different semantic than I thought or it simply does not work.

andrej.podzimek · 2007-02-12 22:54:34

phrakture wrote:

I always thought you needed :DENY and :ALLOW after each entry in the hosts.* files. Can you try adding them?

Done.

sshd:           ALL EXCEPT /etc/hosts.evil : ALLOW

ALL: ALL: DENY

The :ALLOW and :DENY suffixes didn't change anything. I know they are often included in the hosts.* files, but according to the man page, the third portion of the line (after the second colon) is a "shell_command". That's what I found in man 5 hosts_access. There are no such shell commands on my machine.

The behaviour of tcpdmatch remains unchanged. It grants/denies access correctly, according to the list in hosts.evil. But sshd simply ignores it. Removing the whole line still works, but doesn't solve the puzzle... :-D

Last edited by andrej.podzimek (2007-02-12 23:01:08)

ralvez · 2007-02-12 23:28:06

What has always worked for me is:
/etc/hosts.deny = ALL: ALL: DENY
/etc/hosts.allow = sshd: 192.168.1.21

or you can use the name of the host (instead of the IP if it is included in your /etc/hosts file).

andrej.podzimek · 2007-02-12 23:31:34

According to the man page, the library proceeds as follows:
1: Match found in hosts.allow ? return GRANT : proceed to 2
2: Match found in hosts.deny ? return DENY : return GRANT

I removed the line with sshd from /etc/hosts.allow and changed /etc/hosts.deny to look like this:

sshd: etc/hosts.evil
ALL EXCEPT sshd: ALL

Answers from tcpdmatch are still perfectly correct, but sshd ignores them. That's unbelievable. The EXCEPT operator is probably not the cause, as this line in hosts.deny fails as well - access is granted, although it shouldn't be:

sshd: 195.113.0.0/255.255.0.0

If any of you have access to a remote machine, could you please try this thing? It might be just a stupid mistake in my settings, but the vigorous dictionary attacks I found in the logs are a great motivation to solve the problem...

Also tried the :DENY and :ALLOW suffices. They seem to have no impact.

ralvez · 2007-02-12 23:55:42

I have access to a remote machine and with the settings I just sent if I go to another workstation not in the hosts.allow I get:

ssh 192.168.1.2
ssh_exchange_identification: Connection closed by remote host

as expected.

andrej.podzimek · 2007-02-13 00:06:33

ralvez wrote:

What has always worked for me is:
/etc/hosts.deny = ALL: ALL: DENY
/etc/hosts.allow = sshd: 192.168.1.21
or you can use the name of the host (instead of the IP if it is included in your /etc/hosts file).

OK, this works here, too. But I often log into the server from unpredictable addresses. Furthermore, I am not the only one who needs to use this machine remotely. There are multiple user accounts, all of them expected to work from any address. Anyway, the point is that well-formed hosts.allow and hosts.deny must be respected, no matter how complicated they are.

andrej.podzimek · 2007-02-13 00:20:09

ralvez wrote:

I have access to a remote machine and with the settings I just sent if I go to another workstation not in the hosts.allow I get:
ssh 192.168.1.2
ssh_exchange_identification: Connection closed by remote host
as expected.

Yes, my settings also work fine when one address (or a range of addresses) is allowed. However, they don't work when I want to deny a group (range) of addresses... That's what doesn't make sense to me. For example, if you want to allow anyone to log in through ssh except machines from the subnet a.b.X.X, there are two ways to do this.:

1) Using the EXCEPT operator in hosts.allow, leaving hosts.deny unchanged:

# hosts.allow
sshd: ALL EXCEPT a.b.0.0/255.255.0.0

2) Removing all the sshd stuff from hosts.allow and changing hosts.deny to:

# hosts.deny
ALL EXCEPT sshd: ALL
sshd: a.b.0.0/255.255.0.0

None of these two possibilities works on my server. I can easily grant access to one client or to a subnet of clients, but not to the "complement set".

ralvez · 2007-02-13 00:20:14

I'm not sure what you mean by "unpredictable addresses". In a properly set hosts.deny "unpredictable addresses" (or unidentified) are not allowed by default.
It seems to me, based on your postings, that you are interested in using all encompassing definitions like:

ALL: .example.com EXCEPT cracker.badnetwork.com

in which case the example above should be helpful.

R.

andrej.podzimek · 2007-02-13 00:50:38

ralvez wrote:

I'm not sure what you mean by "unpredictable addresses". In a properly set hosts.deny "unpredictable addresses" (or unidentified) are not allowed by default.
It seems to me, based on your postings, that you are interested in using all encompassing definitions like:
ALL: .example.com EXCEPT cracker.badnetwork.com
in which case the example above should be helpful.
R.

I haven't been specific enough, sorry about that. What I want is to use the "denyhosts" utility (script) to automatically ban those who attack my server.

As for "unpredictable addresses", I mean multiple school labs the user might be using and multiple home/work computers he/she might have access to. A "properly set" hosts.deny would certailny limit access to services like NFS and the like. As far as ssh is concerned, limiting access to it would do away with its main benefit (and purpose): the possibility to control the computer from any place.

andrej.podzimek · 2007-02-13 01:09:14

SOLVED!

This was tricky. Here's a thread that mentions a very similar problem: http://bbs.archlinux.org/viewtopic.php?id=28977 This time the machine was too strict. In man sshd_config, I found that the daemon listens on all local addresses by default. That sounds good, but amazingly, the default configuration caused all the problems.

After adding this to /etc/ssh/sshd_config, the problem disappeared.

ListenAddress 192.168.1.2

Everything works now, even the complement sets.

cute_dog · 2007-02-14 11:38:57

And use Iptables as second line of defense

elasticdog · 2007-02-15 16:23:49

So should our package not have the ListenAddress 0.0.0.0 line uncommented by default? My guess would be that since it listens on all local addresses by default, we're just overwriting that when specifying 0.0.0.0, which isn't valid. That was users don't have to specify their local IP address. Unless I'm wrong, shouldn't this be a bug/feature request for the packager?

ralvez · 2007-02-15 17:11:04

0.0.0.0 is the "network". I think that the default setting makes sense in so far that you do not know what IP address will be assigned in that specific machine.
If you have more than one interface in the particular system then setting it to listen to a particular one (or like in the case of this posting to a couple of them) may be what is desirable to exclude all adjacent interfaces.

Considering the widespread use of DHCP and that users sometimes may want to set their desktop system to allow connections via SSH the original settings are, IMHO, sensibly acceptable.

Dedicated use of a system (again, this particular case) will be using static IPs and the setting of ListenAddress xxx.xxx.xxx.xxx is not that difficult, so again, I think it is OK as it is.

R

andrej.podzimek · 2007-02-18 23:04:43

elasticdog wrote:

So should our package not have the ListenAddress 0.0.0.0 line uncommented by default? My guess would be that since it listens on all local addresses by default, we're just overwriting that when specifying 0.0.0.0, which isn't valid. That was users don't have to specify their local IP address. Unless I'm wrong, shouldn't this be a bug/feature request for the packager?

This doesn't seem to be a package bug... IMHO, sshd must respect all the settings in hosts.deny and hosts.allow, regardless the IP address it listens on. The behaviour I noticed seems to be much more complicated. Basic settings (daemon name mentioned in hosts.*) worked, as far as I didn't want a "per IP" configuration. For example, including the daemon in hosts.allow really enabled remote connections, but any closer specifications (subdomains, EXCEPT operator...) were ignored. Access was simply granted without further evaluation. Excluding sshd from hosts.allow worked as one would assume. When I specified ListenAddress, everything started to work properly. This is mysterious. There are millions of computers using tcp wrappers and ssh, so it's hard to believe there could be a bug.

Arch Linux

#1 2007-02-12 22:31:24

sshd ignores /etc/hosts.allow and /etc/hosts.deny

#2 2007-02-12 22:36:08

Re: sshd ignores /etc/hosts.allow and /etc/hosts.deny

#3 2007-02-12 22:36:55

Re: sshd ignores /etc/hosts.allow and /etc/hosts.deny

#4 2007-02-12 22:47:42

Re: sshd ignores /etc/hosts.allow and /etc/hosts.deny

#5 2007-02-12 22:54:34

Re: sshd ignores /etc/hosts.allow and /etc/hosts.deny

#6 2007-02-12 23:28:06

Re: sshd ignores /etc/hosts.allow and /etc/hosts.deny

#7 2007-02-12 23:31:34

Re: sshd ignores /etc/hosts.allow and /etc/hosts.deny

#8 2007-02-12 23:55:42

Re: sshd ignores /etc/hosts.allow and /etc/hosts.deny

#9 2007-02-13 00:06:33

Re: sshd ignores /etc/hosts.allow and /etc/hosts.deny

#10 2007-02-13 00:20:09

Re: sshd ignores /etc/hosts.allow and /etc/hosts.deny

#11 2007-02-13 00:20:14

Re: sshd ignores /etc/hosts.allow and /etc/hosts.deny

#12 2007-02-13 00:50:38

Re: sshd ignores /etc/hosts.allow and /etc/hosts.deny

#13 2007-02-13 01:09:14

Re: sshd ignores /etc/hosts.allow and /etc/hosts.deny

#14 2007-02-14 11:38:57

Re: sshd ignores /etc/hosts.allow and /etc/hosts.deny

#15 2007-02-15 16:23:49

Re: sshd ignores /etc/hosts.allow and /etc/hosts.deny

#16 2007-02-15 17:11:04

Re: sshd ignores /etc/hosts.allow and /etc/hosts.deny

#17 2007-02-18 23:04:43

Re: sshd ignores /etc/hosts.allow and /etc/hosts.deny

Board footer