New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Building the Ultimately Secure VPS - add to this list
raindog308
Administrator, Veteran
Yeah, I know - no VPS is ever completely secure because if the host node is compromised, you're out of luck.
But setting that aside, as an educational exercise, how would you build the ultimately secure VPS?
Let's set an arbitrary purpose: a VPS that allows ssh and serves static web files to allowed sites only.
What else should I add to this list?
- ssh run on a random high port
- no root login
- only ssh key login
- if possible, one-time passwords
- iptables: ssh from pre-defined IPs, ssh to pre-defined IPs, port 80 to pre-defined IPs, outgoing email to one IP port 587, inbound DNS, everything else closed
- httpd run in a jail?
- all logins trigger an email
- backed up nightly (which I guess means opening rsync to one IP and running rsyncd or out of cron)
- I suppose the web root could be htaccess-protected
- fail2ban (though it could only be banning the IPs allowed since nothing is open to the world)
- only systems running are syslog, cron, ssh, httpd, postfix (to send mail - or since mail is not big volume, perhaps run that out of cron periodically)
- have 2 remote sites that nightly run nmap (to make sure nothing more is open) and perhaps nessus
- nightly report of packages available for update
- of course, the owner should subscribe to security announcements for that distro :-)
- some kind of tripwire - the lack of read-only media for the list of hashes makes this difficult - perhaps have the vps create a .txt file with hashes and then have two or more other hosts (perhaps one other VPS and my home PC) suck it down and compare it nightly, on the assumption that they won't all be compromised? :-)
- everything on the box approached with the idea that it could fall into enemy hands. That means encrypting anything that is sensitive, using passwords not stored on the VPS.
Now let's crack it open a little...what would you add if I wanted to serve static + php to the general internet? Obviously the iptables rules change but what else?
Thanked by 1yomero
Comments
Yep that's pretty paranoid, but I guess you can never be too secure.
-ssh run on a random high port
---As long as it's not the default port, it'll be hidden from 99% of all bot scans.
-no root login
---Pointless. A user with sudo access can do just as much damage.
-only ssh key login
---Simplicity over security. Acquiring a key is easier than sniffing a password as root logs in.
-if possible, one-time passwords
---For what? What purpose would this serve? What problem does this fix?
-iptables: ssh from pre-defined IPs, ssh to pre-defined IPs, port 80 to pre-defined IPs, outgoing email to one IP port 587, inbound DNS, everything else closed
---Predefined IPs can be useful if you always log in from the same system... but what if you're away? What if that system goes down? What if your IP somehow gets blocked? And only allow port 80 to predefined IPs? Why even have a web server at that point?
-httpd run in a jail?
---If you setup Apache correctly, there's no reason to do this.
-all logins trigger an email
---Good idea. Or just have a nightly cron that sends a list of all that days logins.
...and at this point I stopped. If you're running something that needs this much security, you sure as hell wouldn't have it on a vps. You would be running a dedicated server node and each service would be in it's own container.
I didn't mean passwordless - they still have to know the password to use the key. non-passwordless ssh key requires the key + password, instead of just a password.
In a perfect world, nothing. However, virtually all corporate/government VPN setups use SecureID to prevent keylogging, etc.
"as an educational exercise" :-)
Fair enough. That's just not very common. I don't think I've come across a client of mine who uses keys with a password in the last five years.
@subigo that's why LOWENDTALK is a SERIOUS INTERNET BUSINESS.
Goddamned right it's serious Internet business. Serious. Internet. Business.
-no root login
---Pointless. A user with sudo access can do just as much damage.
Why is this pointless?
An attacker would then also have to guess the username.
---Pointless. A user with sudo access can do just as much damage.
An attacker would then also have to guess the username.
I guess... but you'd have to have MaxAuthTries not commented out for someone to bruteforce you and nobody keeps it not commented out... do they?
Interesting ideas, ill use
Well, fail2ban if you want.
The mail triggers and so are too much for me. I have enough spam already u_u
Tripwire probably, when the server is ready for production.
The best possible security is 10cm air gap between the network cable and the server. Even windows NT was certified as secure, as long as it was not connected to any network
-no root login
---Pointless. A user with sudo access can do just as much damage.
In my vps no user is in sudoers list
Doesn't everyone use keys with secure passphrases to SSH into their VPSs? Not sure why but i thought it was the norm...
I have a sudoer user, and no root login. But if you want to use sudo you have to guess the root password, not the user login password. Maybe not the best solution, but in this way two different password is needed to be able to use root privileges.
Most importantly, don't step into the trap of an 'encrypted VPS'. If something can run automatically, that means it can be automatically decrypted, and any encryption that is applied is nothing more than a false sense of security.
If you're paranoid about your own fate as well, and not just that of the VPS, don't forget to set up a simple cronjob that checks whether a control file has been modified in the past 24 hours, and if not, undertakes an action such as publishing sensitive information automatically (dead man's switch). You only need to touch the 'control file' every 24 hours at least.
I suspect 99% of people just ssh in with a password and not a key.
I bet 99% finger-macro past all host key warnings, too :-)
---Pointless. A user with sudo access can do just as much damage.
Hardly with "AllowUsers oneandonlyaccount" (on my personal VPSs).
That brings up an interesting thought.
Barring a keylogger (but if you can implement a keylogger, you can probably steal keys too...), have there been any instances where utilizing key-based authentication would have prevented the security issue that resulted from password-based authentication?
In my life? No.
In the general world? Probably.
The gold standard in my mind is something like SecureID. You need to know your login+password+a 6 digit number that changes every 60 seconds. Someone would have to learn your pin and steal your fob.
SecureID has been used for every VPN in every corp/gov't org I've worked at. In some places, it's used for every login, which is fine but painful for admins (you can only use a number once a minute, so if you have to hop around it can be tedious).
@Damian - well, key-based authentication is pretty much immune to guessing/dictionary attacks, for one, and those do succeed against passwords in the real world. Of course, they shouldn't, if people picked good passwords, but way too many don't.
(Obviously you can also do other things to try to thwart dictionary attacks, like rate-limiting or restricting IP ranges, but defense in depth is always good, right?)
I think the linux/leb equivalent for this would be using Google Authenticator.
That would be relying on a third party... that does not really constitute paranoid-level security in my eyes :P
Could create your own two stage PAM.
Maybe even using this: http://sleevage.com/wp-content/uploads/2007/08/dial-a_pirate_spinner.jpg
Oh, the 2 step annoying authentication from Google
use barada for two step auth (if you use android phone).
---Pointless. A user with sudo access can do just as much damage.
Not necessarily, if you know how to configure the sudoers: https://help.ubuntu.com/community/Sudoers
http://www.chrisbrenton.org/2009/08/breaking-out-of-a-sudo-shell/