CentOS - Oct 2007 - denyhosts

Hi,

My denyhosts stop working. How do i check why isnt it working anymore for 
me?

Thanks

Oct  2 22:59:17 beyond sshd[15690]: Failed password for root from 
221.7.37.142 port 49836 ssh2
Oct  2 22:59:17 beyond sshd[15692]: Received disconnect from 221.7.37.142: 
11: Bye Bye
Oct  2 22:59:18 beyond sshd[15701]: pam_unix(sshd:auth): authentication 
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=221.7.37.142  user=root
Oct  2 22:59:20 beyond sshd[15701]: Failed password for root from 
221.7.37.142 port 50929 ssh2
Oct  2 22:59:20 beyond sshd[15702]: Received disconnect from 221.7.37.142: 
11: Bye Bye
Oct  2 22:59:22 beyond sshd[15706]: pam_unix(sshd:auth): authentication 
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=221.7.37.142  user=root
Oct  2 22:59:24 beyond sshd[15706]: Failed password for root from 
221.7.37.142 port 51911 ssh2
Oct  2 22:59:24 beyond sshd[15707]: Received disconnect from 221.7.37.142: 
11: Bye Bye
Oct  2 22:59:30 beyond sshd[15718]: pam_unix(sshd:auth): authentication 
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=221.7.37.142  user=root
Oct  2 22:59:32 beyond sshd[15718]: Failed password for root from 
221.7.37.142 port 52741 ssh2
Oct  2 22:59:32 beyond sshd[15719]: Received disconnect from 221.7.37.142: 
11: Bye Bye
Oct  2 22:59:33 beyond sshd[15724]: pam_unix(sshd:auth): authentication 
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=221.7.37.142  user=root
Oct  2 22:59:36 beyond sshd[15724]: Failed password for root from 
221.7.37.142 port 54591 ssh2
Oct  2 22:59:36 beyond sshd[15725]: Received disconnect from 221.7.37.142: 
11: Bye Bye
Oct  2 22:59:41 beyond sshd[15735]: pam_unix(sshd:auth): authentication 
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=221.7.37.142  user=root

CentOS List wrote:
> Hi,
> 
> My denyhosts stop working. How do i check why isnt it working anymore
> for me?
> 
> Thanks
> 
[snipped log entries]

at the risk alarming you at this point I strongly recommend you run
chkrootkit on your system. If your system has been compromised then
that in and of itself warrants a system reload.

after that, if it appears that you haven't been compromised I would
suggest checking the processes controlling that part of the system;
not sure off the top of my head which systems those are - sorry
about that. I recently had an experience where my web server was
cracked via the ssh service. I was running it on port 22, however I
did have it locked down to a degree meaning I was only accepting
connections from specific IP's or subnets (local), but they still
managed to get in. After reloading the machine, an entire weekend's
worth of work because the box is specifically configured as web and
email server it was only two days and they'd dropped in another root
kit. fortunately I caught it before they were able to compromise any
of the critical systems and I was able to lock things up real good
and clean up the mess.

What I did next has taught me plenty and also contributed to kicking
my own ass for not taking these steps in the past:

1. changed the port that sshd listens on to a non-standard port. in
my case I changed it to something completely random that isn't
really used for anything else. (check the /etc/services file for
ports that aren't already assigned)

2. the second thing I did was Google locking down the ssh service.
The following web address outlines the steps necessary that I used
successfully to accomplish this. All it amounts to is disabling root
logins to ssh service and the use of passwords to authenticate to an
sshd service. I'm not using keys to authenticate and very lengthy
pass-phrases from both windows and Linux clients.

    a.
http://thinkhole.org/wp/2006/10/30/five-steps-to-a-more-secure-ssh

3. while reading through the above howto I saw what looked like just
the ticket for monitoring ssh attacks on my servers. As I read it
made more and more sense, so I went there and read some more. After
I was done reading I grabbed the package and install and configured
it. It's not hard, but it is a little tedious, but works wonderfully.

    b.
http://www.howtoforge.com/preventing_ssh_dictionary_attacks_with_denyhosts

Since taking care of these things I've had no more trouble and since
installing DenyHosts I haven't had to spend anywhere the amount of
time making adjustments to my firewall either.

Deny Hosts Information:
----------------------------------
http://denyhosts.sourceforge.net/

-- 
Mark

"If you have found a very wise man, then you've found
a man that at one time was an idiot and lived long enough
to learn from his own stupidity."
=============================================Powered by CentOS5 (RHEL5)