What security precautions should I set up with a new VPS?

Portal Home > Knowledgebase > Articles Database > What security precautions should I set up with a new VPS?

Posted by brainbuzzmedia, 06-07-2012, 05:17 PM
I just set up a new unmanaged vps and I was told that I need to make it more secure. I am not sure what would make a linux centos5 vps properly secure enough for running regular websites. All I know is I can enable SElinux and have a good password.
Posted by Burnouts, 06-07-2012, 05:27 PM
change shell port, lock down all services and remove things not being used. i would hire somebody who is a professional in the area however.
Posted by quantumphysics, 06-07-2012, 05:30 PM
password? don't you mean disable password login and use keys?
Posted by brainbuzzmedia, 06-07-2012, 05:31 PM
I don't have any idea about any of that. How much would it cost to hire a professional and where would I find one?
Posted by Orien, 06-07-2012, 05:33 PM
Contact Steven at Rack911.com.
Posted by Burnouts, 06-07-2012, 05:36 PM
I have used bobcares.com before, seem to do a good job
Posted by SAHostKing, 06-08-2012, 02:10 AM
SSH port change Use Keys for SSH Access Install rootkithunter,etc. and setup cronjob Install ClamAV and setup cronjob Ensure your IPtables are setup correctly (Use an online portscanner to check) Use good partition structure - I know CPanel documentation can help even if you don't use CPanel secure /tmp folder I assume you using Apache - Use Suexec, suphp, suhosin if required (Though they do need quite a bit of experience to manage) Thats the main ones I would look into first.
Posted by brainbuzzmedia, 06-08-2012, 04:20 AM
The quote I got was $130 for security setup and ~$45/month. Is this normal? Isn't there just good stable hosting that I can get for $45-65/month? Are all unmanaged vps in need of someone to do security stuff every month?
Posted by racknap1, 06-09-2012, 02:13 PM
if your running with not non managed vps then please install CSF(Configure security firewall ) and CP Hulk brute force protection for your VPS clients.
Posted by kbeezie, 06-09-2012, 02:30 PM
Easily done if we're talking bout using Cpanel/whm or Directadmin. On something like a VPS with no control panel I would do the following (bear in mind, my needs don't exactly mean your needs) 1) Change SSH Port 2) Create a secondary unprivileged user 3) create your ssh keys for either account using ssh-keygen (which will put files in the ~/.ssh folder, you can then copy their id_rsa.pub key into authorized_keys file , and any computer you got a pub key for you can add to it to authenticate). * Make sure you can actually login using the pub key authentication method from least two of your locations, or make sure your VPS/etc provider offers a VNC/IPKVM type of login in case you get locked out upon restarting SSH with new configurations. 4) edit the /etc/ssh/sshd_config file (which you would have done for port changes) to do stuff like: - PermitRootLogin no (or use without-password to only allow root over pub key authentication, no is safer) - StrictModes yes - PubkeyAuthentication yes (authorized key files defaults to .ssh/authorized_keys) - PasswordAuthentication no (make sure your pub key works before enabling this option, better yet make sure you got other locations that can get in as well, like another VPS) - PermitEmptyPasswords no - UsePAM no (usually if you just want to be a bit more strict, as PAM can override some of the above) - UseDNS yes (can help protect against spoofs and such to reverse lookup a hostname etc) - UsePrivilegeSeparation yes (runs sshd in a unprivileged child to help prevent some exploits) 5) Use Fail2Ban (it's available for most linux distributions), but also make sure there's a rule for your SSH server on a non-22 port or you risk the firewall locking you out. 6) Disable all non-essential services. For example in my case: - disable sendmail/exim/etc if you will use an external mail service via SMTP (i.e.: google apps like I do) - Disable bind/DNS service if you will use an external DNS server (registrar, dns.he.net, or paid solution) mainly handy if you're not using a control panel to manage it anyways, also both mail and DNS usually takes the bulk of CPU/Ram when you're getting hit with attacks or exploit attempts - if using database server make sure there's no public access to it, for example MySQL on most installations will allow outside connections, so instead bind it to 127.0.0.1 so only local services can connect to it (if you need to connect from outside, use a client that supports SSH tunneling) - disable or forgo the use of an FTP server, SFTP works over SSH just fine, and FTP tends to be less secure especially as it transmits your password in plain text over the connection, which can be a problem if you happened to have a virus or trojan on your system listening and relaying that password to a bot on the net. I've seen too many customers victimized by this as such most of them use SFTP/SCP now. 7) read into specific security issues with the services you do leave on. Examples ( http://kbeezie.com/view/securing-nginx-php/ ) - Nginx : one of the main ones I use, most of the time it's simply making sure the file exists, and not to pass unnecessary requests back to php, and making sure that it does not serve hidden files (which is not done by default). - PHP same basic type of stuff turning off stuff like register globals, not running either webserver or PHP as root or privileged user (i.e.: running both nginx and php as www while the web files are owned by a different user in the group of www allowing you better control over the files via chmod) The biggest thing is making sure everything looks ok before hand or risk locking yourself out. You can instead keep password authentication on, but just make sure root login is not permitted with a password (or better yet at all) and just su - up into root once you log into the unprivileged user.
Posted by kbeezie, 06-09-2012, 02:36 PM
Oh another nice thing to do , if for example you're using FreeBSD is to separate your services into Jails, for example eon my personal VPS I have 1 Jail with the database server running, and a second jail with the web/php server running, and a third one for various testing and such. The idea being that if one is compromised or affected it won't as likely affect the other services. But also that way it doesn't hit the main server installation.

Add to Favourites Print this Article