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. 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 ruserrhost=wsip-24-234-149-156.lv.lv.cox.net THanks, Jerry
If your circumstances allow it, I suggest moving your sshd to a port other than 22. That stopped it for me. Marko On Sun, August 21, 2005 3:03 pm, Jerry Geis said:> 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. > > 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 at centos.org > http://lists.centos.org/mailman/listinfo/centos >
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 at centos.org > http://lists.centos.org/mailman/listinfo/centos-- Rich Huff <rich at richhuff.com>
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 at 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 at centos.org > > http://lists.centos.org/mailman/listinfo/centos > -- > Rich Huff <rich at richhuff.com> > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos >-- -- Jeffrey D. Means meaje at meanspc.com Owner / CIO for MeansPC http://www.meanspc.com/ Custom Web Development For Your Needs. (970)308-1298 - The stupidity of a stupid person is exercised in a restricted field; the stupidity of an intelligent individual has a much broader diffusion, and far greater effect, aided as it is by the element of surprise.
CentOS mailing list <centos at centos.org> wrote:> On Sun, 2005-08-21 at 21:09, Jeffrey Means wrote: > > One other method I have sucessfully used / am using is to change the portnumber> > of the service being attacked. If we are talking about ssh this can be donein> > the /etc/ssh/sshd_config file by changing / adding a Port xxxx line to thefile.> > > > I hope this helps you it has drastically decreased the number of peopletrying> > to break down my front door. > > --Jeff Means > > MeansPC - Custom Web Development for your needs. > > > > CentOS mailing list <centos at 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. > > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos >This is a very good point as a rule I only allow PKCS (public key) logins from offsite so I have little to worry about this particular issue, again this is a line item chage you can make in the sshd_config file. I am running two sshd servers one for internal access wich does run on port 22 but is firewalled from the outside and one on port xxxx wich only allows connections with PKCS auth. If you want a copy of my sshd startup script wich starts daemons for all the files ending in .config contained in the /etc/ssh/ directory let me know and I'll gladly make that available. Using PKCS it makes it really hard to break a password that is over 256 characters, has builtin validity tests and travels nicely on a usb key (even old small ones which makes this very inexpensive to implement even for a medium to large business.) Note to the wise: Be sure to password protect the keys issued for if they fall into the wrong hands you just gave away the keys to your server / network. -- -- Jeffrey D. Means meaje at meanspc.com Owner / CIO for MeansPC http://www.meanspc.com/ Custom Web Development For Your Needs. (970)308-1298 - The stupidity of a stupid person is exercised in a restricted field; the stupidity of an intelligent individual has a much broader diffusion, and far greater effect, aided as it is by the element of surprise.
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. > > 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 >Heh. Welcome to the club. If you've got a well connected machine, and it's listening on any ports, you'll get these. I sometimes get 100-200k logwatch reports and it's all idiots trying to run dictionary attacks against ssh. It comes in waves. Some days I don't get any. All you can really do is filter the naughty IP addresses, but that doesn't really do a whole lot of good since they rarely come from the same place twice. Back in the days when this was so common, I'd make an effort to find the netblock owner and warn them that one of their machines had been compromised, but that's not even worth the effort anymore. A lot of times, it's from some big ISP who just drops those complaints on the floor...especially if it's in the far east. Cheers,