Difference between revisions of "30 April 2008"
From Organic Design wiki
m |
(link to 'pedia section on strong passwords with examples) |
||
| Line 1: | Line 1: | ||
{{news|title=Crackbot Alert!|img=[[Image:CrackBot.jpg]]<br>A real robot called [http://www.theoldrobots.com/crackbot.html CrackBot]|msg= | {{news|title=Crackbot Alert!|img=[[Image:CrackBot.jpg]]<br>A real robot called [http://www.theoldrobots.com/crackbot.html CrackBot]|msg= | ||
After reading this [http://www.securityfocus.com/infocus/1876 Analyzing Malicious SSH Login Attempts] article I decided to do some checking of our own logs (on Debian ''/var/log/auth.log'' is the one showing SSH login information), and there are many bots attempting to access our server via SSH just as there were on the [[w:Honeypot (computing)|Honeypot]] discussed in the article. In fact we've had around ''two thousand'' login attempts per day for at least the last few months! It looks like we've not had any successful attempts thanks to being strict with strong passwords, but the article suggests some simple things which will prevent most attacks from succeeding. | After reading this [http://www.securityfocus.com/infocus/1876 Analyzing Malicious SSH Login Attempts] article I decided to do some checking of our own logs (on Debian ''/var/log/auth.log'' is the one showing SSH login information), and there are many bots attempting to access our server via SSH just as there were on the [[w:Honeypot (computing)|Honeypot]] discussed in the article. In fact we've had around ''two thousand'' login attempts per day for at least the last few months! It looks like we've not had any successful attempts thanks to being strict with strong passwords, but the article suggests some simple things which will prevent most attacks from succeeding. | ||
| − | *Always use strong passwords, don't assume that a normal word with a bit of [[w:leet|leet]] in it is going to fool the crackbots! | + | *Always use [[w:Password_strength#Guidelines for strong passwords|strong passwords]], don't assume that a normal word with a bit of [[w:leet|leet]] in it is going to fool the crackbots! |
*Ensure you have ''root'' login disabled as that is the most common account attempted by the crackbots. Always log in as a standard user then use ''su'' or ''sudo''. | *Ensure you have ''root'' login disabled as that is the most common account attempted by the crackbots. Always log in as a standard user then use ''su'' or ''sudo''. | ||
*Changing your SSH port to something other than 22 will put most bots off the scent since their resource is best spent trying logins on known SSH connections rather than port-scanning for others on non-standard ports. | *Changing your SSH port to something other than 22 will put most bots off the scent since their resource is best spent trying logins on known SSH connections rather than port-scanning for others on non-standard ports. | ||
Latest revision as of 01:22, 1 May 2008
|
Crackbot Alert!
After reading this Analyzing Malicious SSH Login Attempts article I decided to do some checking of our own logs (on Debian /var/log/auth.log is the one showing SSH login information), and there are many bots attempting to access our server via SSH just as there were on the Honeypot discussed in the article. In fact we've had around two thousand login attempts per day for at least the last few months! It looks like we've not had any successful attempts thanks to being strict with strong passwords, but the article suggests some simple things which will prevent most attacks from succeeding.
- Always use strong passwords, don't assume that a normal word with a bit of leet in it is going to fool the crackbots!
- Ensure you have root login disabled as that is the most common account attempted by the crackbots. Always log in as a standard user then use su or sudo.
- Changing your SSH port to something other than 22 will put most bots off the scent since their resource is best spent trying logins on known SSH connections rather than port-scanning for others on non-standard ports.
- Disable access from all but users who really require it rather than the default which is to allow all users to shell in.
In addition to these things I also brought our server OS and software up to date which hadn't been done in quite a while, so many new security patches will have been applied during that process.
