Blake <bleverett@pants.att.net> wrote:

>
> I set up hosts.allow like this:
>
> SSH: .company.com
> SSHD: .company.com
> SSH: 16.95.25.53
> SSHD: 16.95.25.53

First of all, Linux is, like all Unix-like operating systems, case
sensitive for file/service names. sshd is not the same as SSHD.

Secondly, was sshd compiled with tcpd support? Add "tcpd" to your USE
flags and do an "emerge --update --deep --newuse world".

For a rule that might work, try this:

sshd : 16.95.25.23/255.255.255.255, .company.com : ALLOW

> (Names/IP's have been changed, and I used both SSH and SSHD because I
> wasn't sure which one is right, and it takes a day to change the file
> and try it again.)

Neither is right. sshd is.

> My question is this: Shouldn't the hosts.allow rules block this
> invalid attacker from even attempting to get into SSH? I thought the
> hosts.allow config would drop the connection before sshd got
> involved. Obviously I am misunderstanding how this all works.

If sshd had been an inetd service, that would have been true. In those
cases, inetd passes control to tcpd, which drops the connection or
starts the service, depending on the success of the matching.
In the case of non-inetd services with tcpd support, they handle the
connection themselves, and hang up if hosts.{allow|deny} disallows it.
However, since they know about the connection, they might also log it.

> I don't have a hosts.deny file. Does that mean that everyone is
> allowed to access everything? The man page is not super clear to me.

If you are using the third field with the keywords ALLOW or DENY, you
only need hosts.allow
If not, you need to specify what you don't allow in hosts.deny, or have
a default there that denies everything.

Better yet,

Regards,
--
*Art