I'd modify the hosts.allow file a bit more...
i.e.
sshd: localhost 192.168.0.0/255.255.255.0 12.30.163.* ALL:ALL:DENY
This is a "catch-all" that is a best practice just incase the hosts.deny is misconfigured or not configured at all, although the ALL:ALL in your hosts.deny is correct. It will deny access to all services that tcpd monitors to everything as a last resort. Hence, if it's not explicitly defined to be allowed, it is by default denied.
Just an idea...
-----Original Message----- From: Jon Moss [mailto:jon.moss@cnonline.net] Sent: Thursday, October 21, 2004 7:03 AM To: kclug@kclug.org Subject: Re: It was bound to happen - suspected hack
I've been researching sshd and allowing/denying access and I think I have figured it out. Just please confirm that I'm on the right track.
I edited my hosts.allow as follows:
# # hosts.allow This file describes the names of the hosts which are # allowed to use the local INET services, as decided # by the '/usr/sbin/tcpd' server. # sshd: localhost 192.168.0.0/255.255.255.0 12.30.163.*
And then my hosts.deny as follows:
# # hosts.deny This file describes the names of the hosts which are # *not* allowed to use the local INET services, as decided # by the '/usr/sbin/tcpd' server. # # The portmap line is redundant, but it is left to remind you that # the new secure portmap uses hosts.deny and hosts.allow. In particular # you should know that NFS uses portmap! ALL : ALL
However, I don't really have anyway to test this as I allowed access from everywhere that I am. :)
Any suggestions and advice is still greatly appreciated.
I saw your modification in my research. Thanks for confirming it. I'll add it to my hosts.allow file.
Thanks for the quick responses.
Jon
I'd modify the hosts.allow file a bit more...
i.e.
sshd: localhost 192.168.0.0/255.255.255.0 12.30.163.* ALL:ALL:DENY
This is a "catch-all" that is a best practice just incase the hosts.deny is misconfigured or not configured at all, although the ALL:ALL in your hosts.deny is correct. It will deny access to all services that tcpd monitors to everything as a last resort. Hence, if it's not explicitly defined to be allowed, it is by default denied.
Just an idea...
Quoting Jon Moss jon.moss@cnonline.net:
I saw your modification in my research. Thanks for confirming it. I'll add it to my hosts.allow file.
Thanks for the quick responses.
You can also use iptables to restrict access to port 22, btw. You could combine this with tcpwrappers and have "security in layers." Hell, modify your sshd config file and further restrict access there too.
As for the attempted logins you're seeing in your secure.log file, I have 11 Linux servers that are hit daily by these attempts. It's a scripted attack that seems to wax and wain periodically. I wouldn't be too concerned about it. Sure keep an eye on your log files, check them every day. And be sure you've got good complex passwords on your accounts.
What you've seen is pretty mundane. It's not a hack... yet. It is an attempt to hack using common account names and passwords.
-- Dave Hull http://insipid.com
I checked my logs this morning and everything appears much better. I also solved my lastlog problem.
I made some modifications to ssh and su (wheel group access only). I will read up on iptables.
I agree that it was probably an automated attack probe looking for common usernames and passwords. While I have a couple of common user names, the passwords are not (I love creating wierd passwords - just ask my peers who groan out loud everytime I give them a new one!).
Thanks again,
Jon
You can also use iptables to restrict access to port 22, btw. You could combine this with tcpwrappers and have "security in layers." Hell, modify your sshd config file and further restrict access there too.
As for the attempted logins you're seeing in your secure.log file, I have 11 Linux servers that are hit daily by these attempts. It's a scripted attack that seems to wax and wain periodically. I wouldn't be too concerned about it. Sure keep an eye on your log files, check them every day. And be sure you've got good complex passwords on your accounts.
What you've seen is pretty mundane. It's not a hack... yet. It is an attempt to hack using common account names and passwords.
-- Dave Hull http://insipid.com
-
aaron hirsch -
Ben Kelley -
Dave Hull -
Jon Moss