Re: [SLE] stopping dictionary attacks on sshd
Dan Abernathy <dapub@charter.net> 11/07/2005 07:52 PM Please respond to dapub To: suse-linux-e@suse.com cc: Subject: [SLE] stopping dictionary attacks on sshd Hello all I notice several automated break-in attempts appearing in /var/log/messages regarding sshd. A small sample: Nov 7 14:34:10 d8400 sshd[18607]: Invalid user a from 71.129.198.189 Nov 7 14:34:11 d8400 sshd[18609]: Invalid user aaron from 71.129.198.189 Hundreds of entries like the above, working their way through every English letter using common first names, also names of services like Apache. I ran across this Novell Cool Solutions article: http://www.novell.com/coolsolutions/trench/16341.html It describes the use of a shell script, run once per minute using a cron job, that parses information from /var/log/messages and adds offending IP addresses to /etc/hosts.deny. I saved the script as ssh-block.sh in my home folder, in a subdirectory named cronjobs. I used su to become root and ran crontab -e, and added the script to run once per minute. Entries in /var/log/messages confirm that the shell script is indeed being run every minute, but the contents of /etc/hosts.deny hasn't changed at all, despite the presence of failed sshd log-ins (also written to /var/log/messages). Can someone knowledgeable about shell scripts take a look at the URL above and see if there is a problem with the script? If not, what did I do incorrectly? What's the proper way to run this job regularly? I assume it must be run as root, both to read /var/log/messages and to write to /etc/hosts.deny. Dan -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com The simple solution to this problem is to disable password logins and make use of public key authentication. With no chance to log in, there is no chance to brute force.
for a start your log says "Invalid user" and the Script says "Illegal User" ----- Original Message ----- From: <kevin.j.lisciotti@jpmchase.com> To: <dapub@charter.net> Cc: <suse-linux-e@suse.com> Sent: Tuesday, November 08, 2005 3:49 PM Subject: Re: [SLE] stopping dictionary attacks on sshd Dan Abernathy <dapub@charter.net> 11/07/2005 07:52 PM Please respond to dapub To: suse-linux-e@suse.com cc: Subject: [SLE] stopping dictionary attacks on sshd Hello all I notice several automated break-in attempts appearing in /var/log/messages regarding sshd. A small sample: Nov 7 14:34:10 d8400 sshd[18607]: Invalid user a from 71.129.198.189 Nov 7 14:34:11 d8400 sshd[18609]: Invalid user aaron from 71.129.198.189 Hundreds of entries like the above, working their way through every English letter using common first names, also names of services like Apache. I ran across this Novell Cool Solutions article: http://www.novell.com/coolsolutions/trench/16341.html It describes the use of a shell script, run once per minute using a cron job, that parses information from /var/log/messages and adds offending IP addresses to /etc/hosts.deny. I saved the script as ssh-block.sh in my home folder, in a subdirectory named cronjobs. I used su to become root and ran crontab -e, and added the script to run once per minute. Entries in /var/log/messages confirm that the shell script is indeed being run every minute, but the contents of /etc/hosts.deny hasn't changed at all, despite the presence of failed sshd log-ins (also written to /var/log/messages). Can someone knowledgeable about shell scripts take a look at the URL above and see if there is a problem with the script? If not, what did I do incorrectly? What's the proper way to run this job regularly? I assume it must be run as root, both to read /var/log/messages and to write to /etc/hosts.deny. Dan -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com The simple solution to this problem is to disable password logins and make use of public key authentication. With no chance to log in, there is no chance to brute force.
participants (2)
-
Andre Venter -
kevin.j.lisciotti＠jpmchase.com