Hi Jimmy Perhaps you could post this advice to the MLUG site in form of an article. It would be useful content and a convenient link to send when this question comes up as it often does.
Alan On 11/26/2009 07:22 AM, Jimmy wrote: > 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
