How to secure new VPS

cikatomo

Is there anywhere tutorial here on how to secure VPS first time, like disable root login, fail2ban, setup authentication key etc...? Like first steps in securing server

perennate

Yes.

• https://www.digitalocean.com/community/tutorials/an-introduction-to-securing-your-linux-vps
• https://www.vultr.com/docs/securing-ssh-on-ubuntu-14-04
• https://www.linode.com/docs/security/securing-your-server
• https://wiki.ubuntu.com/BasicSecurity
• http://plusbryan.com/my-first-5-minutes-on-a-server-or-essential-security-for-linux-servers
• http://serverfault.com/questions/11659/what-steps-do-you-take-to-secure-a-debian-server

cikatomo

@perennate said:
Yes.

• https://www.digitalocean.com/community/tutorials/an-introduction-to-securing-your-linux-vps
• https://www.vultr.com/docs/securing-ssh-on-ubuntu-14-04
• https://www.linode.com/docs/security/securing-your-server
• https://wiki.ubuntu.com/BasicSecurity
• http://plusbryan.com/my-first-5-minutes-on-a-server-or-essential-security-for-linux-servers
• http://serverfault.com/questions/11659/what-steps-do-you-take-to-secure-a-debian-server

I have two words for you:
youmyfriendare goingtohollywood

ATHK

@cikatomo said:
Is there anywhere tutorial here on how to secure VPS first time, like disable root login, fail2ban, setup authentication key etc...? Like first steps in securing server

I applaud you, most people would buy a VPS and change the root password and leave it at that, so congratulations on being smart and wanting to secure your server!

cikatomo

@ATHK said:
I applaud you, most people would buy a VPS and change the root password and leave it at that, so congratulations on being smart and wanting to secure your server!

Thank you very much!

GM2015

Make ssh key

mkdir ~/.ssh
chmod 0700 ~/.ssh
touch ~/.ssh/authorized_keys
chmod 0644 ~/.ssh/authorized_keys
ssh-keygen -t rsa -b 4096

Name your ssh key "key" and that code below pastes the pub into auth* keys and gives you your priv key to use.

cat "key.pub" >> ~/.ssh/authorized_keys
cat "key"

PremiumN

The fact that you know what fail2ban/authentication keys, you probably have done that before, so i have no idea why you didnt use google.

cikatomo

@PremiumN said:
The fact that you know what fail2ban/authentication keys, you probably have done that before, so i have no idea why you didnt use google.

I thought maybe there is more that i don't know about and is this what i know enough

deadbeef

yes secure > /bin/bash should keep people out.

singsing

GM2015 said: Name your ssh key "key" and that code below pastes the pub into auth* keys and gives you your priv key to use.

cat "key.pub" >> ~/.ssh/authorized_keys

cat "key"

Fail. You need to make the key pair on your client machine, and paste the public key to the server. There is no reason for a private key to ever go over the network. And I recommend -t ecdsa -b 521 over -t rsa -b 4096, it's faster and probably stronger. http://crypto.stackexchange.com/questions/2482/how-strong-is-the-ecdsa-algorithm

GM2015

Valid point.

I've got no clue about cryptography and so far I assumed I wouldn't get hacked on my servers over ssh by making the keys on the server. I've been making my keys in the last 1,5 month on my servers, so I assume this is a bad habit needing to stop. Thanks.

Though, my projects aren't worth hacking, though botnets don't care about that.

singsing said: Fail. You need to make the key pair on your client machine, and paste the public key to the server. There is no reason for a private key to ever go over the network. And I recommend -t ecdsa -b 521 over -t rsa -b 4096, it's faster and probably stronger. http://crypto.stackexchange.com/questions/2482/how-strong-is-the-ecdsa-algorithm

namhuy

secure ssh https://www.namhuy.net/999/how-to-install-config-and-secure-openssh-server.html or better yet use ssh keys https://www.namhuy.net/2433/ssh-login-without-password.html

cikatomo

i have fail2ban, using key, using sftp, firewall blocked all incoming except ssh which is not 22, blocked 25, now i need monitoring like Oessc. Is this secure enough?

4n0nx

singsing said: Fail. You need to make the key pair on your client machine, and paste the public key to the server. There is no reason for a private key to ever go over the network. And I recommend -t ecdsa -b 521 over -t rsa -b 4096, it's faster and probably stronger. http://crypto.stackexchange.com/questions/2482/how-strong-is-the-ecdsa-algorithm

No, you fail. DSA has problems with weak random number generators. The performance gain is non existent on any VPS OP might ever use. If OP is unlucky then it does not work on his client device.

RSA works flawlessly and is well tested.

If the connection can be spied on then it obviously doesn't fucking matter if he transfers they key used for the connection over aforementioned connection.

singsing

4n0nx said: If the connection can be spied on then it obviously doesn't ... matter if he transfers they key used for the connection over aforementioned connection.

No? If an attacker that can only passively eavesdrop sees a private key, he/she can now log in. If only a public key, then not.

4n0nx said: DSA has problems with weak random number generators.

ecdsa is not dsa. Please produces cites showing why ecdsa is weak. Update: I think I found it, yes, ecdsa has problems with completely broken random number generators (reusing k value). I think it's unlikely RSA works properly with completely broken random number generators either.

Entropy is another reason why you generate the keypair on a real desktop rather than in a VPS, by the way.

afterSt0rm

@4n0nx said:
DSA has problems with weak random number generators.

First of all a rule of thum: don't trust NIST.

Yes, ECDSA is bad for SSH, but RSA is vunerable to weak random number generators too. The Linux random number generator isn't that good at all if you don't provide enough entropy. Well, on OpenSSH, 4096bit RSA keys will be safe but the EdDSA ed25519 algorithm will be better, but it will broke compatibility with old versions of OpenSSH (<6.5).

To generate those keys you should use: ssh-keygen -t ed25519

Other option to look is -a that defaults to 16 rounds. Changing the default to a higher number will slow down the passphrase verification, making brute force attacks more difficult. A number of 1000 rounds will take ~30sec to verify the passphrase;

The key exchange cipher is important too, from OpenSSH 6.7 it supports the diffie-hellman EC ciphers and from 6.5 the curve25519-sha256 cipher. I would not trust the NIST ciphers as it has a bad history of being weak on purpose. To specify the key-ex cipher avaiable and it's order to use what is safest you should add to your sshd_config:

Host *
    KexAlgorithms [email protected],diffie-hellman-group-exchange-sha256

If you use GitHub, it still use some insecure ciphers so you can add it to match only the GitHub servers:

Host github.com
    KexAlgorithms [email protected],diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1

Depending on your version, some other steps should be required so, take a time to actually READ this page and finish your configuration.

GM2015

Interesting. My servers' ssh connections frequently time out and it's damn annoying. I'm not sure what I'do if my keys took 30 to decipher themselves by the passhphrase.

EkaatyLinux said: Other option to look is -a that defaults to 16 rounds. Changing the default to a higher number will slow down the passphrase verification, making brute force attacks more difficult. A number of 1000 rounds will take ~30sec to verify the passphrase;

singsing

EkaatyLinux said: but the EdDSA ed25519 algorithm will be better

It's not an unreasonable choice by any means. The tradeoff in crypto is always that older algorithms have more known flaws, while newer algorithms might have more unknown flaws. Admittedly, ed25519 is designed to require strong RNG only during key generation, and that is a plus over ecdsa. I do not worry about this, because I believe you have to be doing something pretty unusual for randomness to totally fail on Linux (e.g., you're running ssh from a headless system that lacks the usual sources of entropy). Broken OpenSSL RNG in 2008 was, of course, quite an eye-opener for everyone. But, remember, ed25519 is just one step of the process. Thinking you have security over your whole process despite broken RNG can't be right.

singsing

GM2015 said: My servers' ssh connections frequently time out and it's damn annoying. I'm not sure what I'do if my keys took 30 to decipher themselves by the passhphrase.

Set ServerAliveInterval 300 to avoid timeouts ...

But fiddling with -a is IMHO pure security theatre.

rincewind

Stribika's blog article has a nice article on SSHD config. Essentially, use a good-quality set of pre-generated group parameters in /etc/ssh/moduli for DH-SHA2. Combine it with a good selection of Ciphers and MACs.

I use HAVEGED to populate the entropy pool.

To mitigate an attack, I would suggest adding

LoginGraceTime 20

PermitRootLogin no

StrictModes yes

MaxAuthTries 1

UsePrivilegeSeparation sandbox