One other method I have sucessfully used / am using is to change the port number of the service being attacked. If we are talking about ssh this can be done in the /etc/ssh/sshd_config file by changing / adding a Port xxxx line to the file.
I hope this helps you it has drastically decreased the number of people trying to break down my front door. --Jeff Means MeansPC - Custom Web Development for your needs.
CentOS mailing list centos@centos.org wrote:
On Sun, 2005-08-21 at 17:03 -0500, Jerry Geis wrote:
I have quite a few entries in /var/log/messages for connection attempts. Is there anything other than ignoring them I can do? Example is below.
There are a number of scripts (some Perl, some Python) out there to monitor the log and add an entry in hosts.deny to block any further attempts from the offending IP when too many failed password attempts are noted. You can find them with some "googling".
I am using a modified one to stop these breakin attempts on my servers.
Aug 21 15:48:19 machine sshd(pam_unix)[17903]: check pass; user unknown Aug 21 15:48:19 machine sshd(pam_unix)[17903]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=wsip-24-234-149-156.lv.lv.cox.net
THanks,
Jerry
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-- Rich Huff rich@richhuff.com
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Sun, 2005-08-21 at 21:09, Jeffrey Means wrote:
One other method I have sucessfully used / am using is to change the port number of the service being attacked. If we are talking about ssh this can be done in the /etc/ssh/sshd_config file by changing / adding a Port xxxx line to the file.
I hope this helps you it has drastically decreased the number of people trying to break down my front door. --Jeff Means MeansPC - Custom Web Development for your needs.
CentOS mailing list centos@centos.org wrote:
On Sun, 2005-08-21 at 17:03 -0500, Jerry Geis wrote:
I have quite a few entries in /var/log/messages for connection attempts. Is there anything other than ignoring them I can do? Example is below.
There are a number of scripts (some Perl, some Python) out there to monitor the log and add an entry in hosts.deny to block any further attempts from the offending IP when too many failed password attempts are noted. You can find them with some "googling".
I am using a modified one to stop these breakin attempts on my servers.
Aug 21 15:48:19 machine sshd(pam_unix)[17903]: check pass; user unknown Aug 21 15:48:19 machine sshd(pam_unix)[17903]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=wsip-24-234-149-156.lv.lv.cox.net
It is good to know that this type of attack against ssh is generally automated. Most likely run by script kiddies looking for a system with poor passwords or default passwords on that service.
If you take the actions others have already posted you should be in good shape. Just make sure you use non-trivial passwords, limit which users are allowed to login into ssh, and if you want to eliminate this type of traffic in your log files use a different port. It is important to realize that changing the port number is not a security measure. Any good hacker will scan your system and find it. But it does prevent these automated scripts from finding your system for the most part.
Jeffrey Means meaje@meanspc.com wrote:
One other method I have sucessfully used / am using is to change the port number of the service being attacked. If we are talking about ssh this can be done in the /etc/ssh/sshd_config file by changing / adding a Port xxxx line to the file. I hope this helps you it has drastically decreased the number of people trying to break down my front door.
Instead of rehashing my set of SSH recommendations on yet another list, I've added blog entry: http://thebs413.blogspot.com/2005/08/secure-shell-ssh-service-dos.html
I have the following in my firewall:
-A INPUT -p tcp --dport 12345 -m recent --set -A INPUT -p tcp --dport ssh -m state --state NEW \ -m recent --update --seconds 43200 -j ACCEPT
This will only allow SSH from a computer which has telneted to port 12345 (obviously I use something else) in the past 12 hours (even the simple windows telnet will work, it's just important to try to connect). Obviously the above could be made more complicated with more than 1 port having to be 'telneted' but I doubt it's worth the trouble.
Cheers, MaZe.
-
Bryan J. Smith -
Jeffrey Means -
Maciej Żenczykowski -
Scot L. Harris