Thanks for the compliments guys. One of the great things about this setup is you can completely ignore the brute force attacks. No password access allowed, so brute force all you want, they don't have my ssh private key.
On 11/26/09, Peter Silva <[email protected]> wrote: > That was good. One thing to add is that the net is filled with low-level > noise of automated programs trying to brute force ssh, all day, all night, > all the time. > > The simplest way to deal with brute force attacks is > install something like fail2ban, that monitors ssh login attempts and adds a > firewall rule to drop requests from IP addresses that fail to often. > > > On Wed, Nov 25, 2009 at 11:21 PM, Jean-Francois Theroux > <[email protected]>wrote: > >> Very good crash course on basic security Jimmy. I would recommend however >> to always set a passphrase on your SSH keys. Also, it's a very good >> practice >> to have your $HOME encrypted, so that in the event your machine was >> stolen, >> your keys are doubly safe. >> >> >> On Wed, Nov 25, 2009 at 11:01 PM, Jimmy <[email protected]> wrote: >> >>> Its exciting to see so many people interested in using Linux more and >>> more. I am often asked about setting up a "small server" for web, >>> mail, etc... However what seems to come up more and more are basic >>> security concerns. Recently on this list and others this topic is >>> coming up more frequently. The number of times someone has asked me >>> for help and sent me an IP root username and password in clear text >>> mail dumbfounds me. So I decided to write a very basic security guide >>> that will work with pretty much any linux distro out there. This is >>> all about remote shell access over ssh. Once any other port is open, >>> you always open yourself to another angle of attack. Also, there are >>> more ways to do this, this is the one I like. >>> >>> Last note... proceed at your own risk. Disclaimer disclaimer >>> disclaimer.... Know what you are doing before putting any of this >>> into place. I purposely try to stay vague enough to make sure you do >>> some research before blindly following a posted howto. All that said, >>> I hope someone finds this useful. :) >>> >>> >>> Passwords over the Internet are bad! Use keypairs whenever you can. >>> I am a big advocate of eliminating passwords for remote authentication >>> all together. Use ssh key pairs. There are already a number of guides >>> on how to setup ssh key pairs, so google what you don't understand >>> below. >>> - create your users key pair on your workstation >>> ssh-keygen -t dsa -b 1024 >>> - copy the public key securely to your destination server and put it >>> in ~/.ssh/authorized_keys2 >>> - don't forget to set the correct permissions (number one reason why >>> this does not work) >>> chmod 700 ~/.ssh >>> chmod 600 ~/.ssh/authorized_keys2 >>> - test to make sure it is working. You should be able to ssh from >>> your workstation to the destination server as your user without a >>> password. >>> >>> Once setup and tested, remove the possibility of logging in with a >>> password over ssh. >>> - in sshd_config set: >>> PasswordAuthentication no >>> - restart ssh >>> I hope you tested your passwordless access before you restarted ssh. >>> >>> >>> Direct root logins are bad! Use sudo or su. >>> First make sure you have a normal non-root user on your system. That >>> should have been the user you used to create your keypair with and now >>> have ssh access to your server with. If you did all this with your >>> root user, create a new user and start over. Make sure that user can >>> su to root or use sudo. >>> >>> Eliminate the possibility of sshing into your box as root. >>> - in sshd_config set: >>> PermitRootLogin no >>> - restart ssh >>> >>> Limit who can use sudo or su to root. If you are using any flavor of >>> Ubuntu, the sudo setup is already done for you and you should already >>> be used to using sudo, so you are already half way there. Look at >>> /etc/sudoers and make any required changes. If you prefer su, look at >>> using wheel (http://lmgtfy.com/?q=pam+wheel) >>> >>> Finally, now that you know what user you will always be using to login >>> to your server, make sure ONLY that user can ever login. This is a >>> little more drastic and can have some evil side affects, but I will >>> get into that in a sec. So PAM access.conf. What a wonderful >>> invention. Its a shame its not setup by default. Anyways, here is >>> the basic way to setup and start using access.conf >>> >>> Find your pam.d config directory, normally in /etc/ and look for your >>> sshd pam config file. On ubuntu, you will find it here: >>> /etc/pam.d/sshd >>> Edit it and enable pam_access >>> (in ubuntu, you simply need to uncomment the following line, in other >>> distros, you need to add it in manually) >>> account required pam_access.so >>> Do the same in pam.d/login >>> >>> Now edit your access.conf, in ubuntu, you will find it here: >>> /etc/security/access.conf >>> The most basic setup will look something like this. >>> >>> -:root:ALL EXCEPT LOCAL >>> +:jimmy:ALL >>> -:ALL:ALL >>> >>> With this in your access.conf, root can only login from a local >>> console, the jimmy user can login from anywhere, and everyone else is >>> not allowed to login at all. In combination with key pair shell >>> access and blocked ssh access for root, you can sleep more soundly >>> knowing that the only way into your server remotely is from your >>> workstation using your user's key. If your workstation is not secure, >>> well, then you have other issues. With a setup like this, if you need >>> someones help remotely, create them a user, ask for their public key, >>> drop it into their users' authorized keys file and add their name to >>> the access.conf file. Yes its a little more setup, but afterwards, >>> you don't have to worry about them keeping access, as soon as you >>> remove their user you are safe. Even if they copy your public key or >>> try and setup a backdoor user, if they are not in the access.conf >>> file, they are not shelling in. (Make sure they did not put their >>> public key in your authorized_keys file) :) >>> >>> Hope this can be useful! >>> Jimmy >>> _______________________________________________ >>> mlug mailing list >>> [email protected] >>> https://listes.koumbit.net/cgi-bin/mailman/listinfo/mlug-listserv.mlug.ca >>> >> >> >> >> -- >> :(){ :|:& };: >> >> >> _______________________________________________ >> mlug mailing list >> [email protected] >> https://listes.koumbit.net/cgi-bin/mailman/listinfo/mlug-listserv.mlug.ca >> >> > -- Sent from my mobile device _______________________________________________ mlug mailing list [email protected] https://listes.koumbit.net/cgi-bin/mailman/listinfo/mlug-listserv.mlug.ca
