I'm familiar with 'port-knocking' and after mulling it over decided to simply use the 'PermitRootLogin without-password' option to sshd. I looked at the user names being testing in the scripts and decided that it was unlikely anyone would hit one of our users, especially with the security script I had installed. Forcing DSA keys for root access solved my last concern. Kirk Bocek Maciej Żenczykowski wrote: > Instead of keeping the ssh port open, use something like the following: > > -A INPUT -p tcp --dport SECRETPORT# -m recent --set > -A INPUT -p tcp --dport ssh -m state --state NEW -m recent --update > --seconds 43200 -j ACCEPT > > and then before ssh'ing in from outside telnet the SECRETPORT# on the > machine in order to open the ssh port for the next 12 hours. > Gets rid of script kiddies. > > Cheers, > MaZe. > > On Tue, 6 Sep 2005, Sam Drinkard wrote: > >> Kirk, >> >> If you don't mind, could you let me know where that script is? I'm >> seeing the same thing -- kiddies trying to log in. I use something >> similar, but manual entry on my mail server that is in a co-lo site >> running FreeBSD. Here at home, I thought I'd be pretty well protected >> behind the router, but I have to have the ssh port open, and I'm >> seeing hundreds of attempts. Thanks... >> >> Sam >> >> Kirk Bocek wrote: >> >>> Good question Alex. However, I've never studied the scripts that >>> 'script kiddies' use and so have no answer. >>> >>> Part of what has prompted this change is the recent surge of >>> brute-force password attacks. From the timing of the password >>> attempts, it's clear that these are script driven. >>> >>> I found a perl script that watches for failed logins. After a >>> configurable number, the script enters the IP address into >>> /etc/hosts.deny. After a configurable number of days, the script then >>> removes the IP address. >>> >>> What I see in /var/log/secure is a whole series of 'Invalid user' >>> messages followed by 'Failed password for invalid user' messages. >>> These will then, because of the script, be terminated by a 'refused >>> connect from' message when the address is entered into hosts.deny. >>> >>> My point in all this is that I only ever see *one* 'refused connect' >>> message. So at least for this script, it gives up when it can't >>> connect anymore. >>> >>> Kirk Bocek >>> >>> >>> >>> >> >> >> > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos