What are the general things/setup that you do after getting a VPS/Dedicated server?

evnix

The obvious one is to change the SSH port.

Would be interesting to hear what are the other things that you do?

yoursunny

I never change SSH port, but I disable password authentication. Virmach support complains about this every time.

If the server is for idling, the best command to ensure security is:

sudo shutdown -h now

ionswitch_stan

Apply all updates (yum update, apt-get update, etc).

Enable SSH based key auth. Disable root logins. Consider hardening SSH via the Mozilla recommendations (https://infosec.mozilla.org/guidelines/openssh.html) turning off old insecure ciphers and such. As a warning this can cause some trouble if you have systems that don't support secure ciphers (ie, centos 6 sshing to centos 7). Consider changing the SSH port, but understand it is primarily to reduce log noise not really adding security.

Remove any unneeded services.

Enable syslog to publish logs remotely to either another server you own, or a free syslog aggrogator service. This way if you get compromised the compromisor can't delete logs.

Install monit if you have nothing better.

Firewall off all ports you aren't using.

Enable automatic installation of security patches.

Mustafamw3

Install control panel

tester4

Install CSF/LFD and change SSH port, that's about it.

ouvoun

I have a super scrappy script that I use to bootstrap Debian-based servers. Definitely a personal script, but it might help you out?

#!/bin/bash

# Editable variables
V_USER='xx'
V_SSH_PORT='xxxxx'

# Update user settings
echo '**** Updating root password'
passwd

echo '**** Creating user: '"$V_USER"
read -p "Press enter to continue"
adduser $V_USER
usermod -aG sudo $V_USER
#su - $V_USER

# Update SSH settings
echo '**** Updating SSH port to '"$V_SSH_PORT"
read -p "Press enter to continue"
sed -i '/PermitRootLogin yes/c\PermitRootLogin no' /etc/ssh/sshd_config
sed -i '/Port 22/c\Port '"$V_SSH_PORT" /etc/ssh/sshd_config

# Install basic packages
echo '**** Installing packages'
read -p "Press enter to continue"
apt -y update
apt -y upgrade
apt -y install sudo ufw fail2ban htop curl python-pip

# Set up firewall
echo '**** Setting up firewall'
read -p "Press enter to continue"
ufw allow http
ufw allow https
ufw allow ssh
ufw allow $V_SSH_PORT
ufw enable

# Other settings
echo '**** Tweaking settings'
read -p "Press enter to continue"
timedatectl set-timezone America/Los_Angeles

# Install Docker
echo '**** Installing docker'
read -p "Press enter to continue"
curl -fsSL https://get.docker.com -o get-docker.sh
sh get-docker.sh
rm get-docker.sh
usermod -aG docker $V_USER

# Install Docker Compose
echo '**** Installing docker-compose'
read -p "Press enter to continue"
pip install docker-compose

echo '**** Completed. Rebooting in 5...'
sleep 5
reboot

evnix

@ouvoun said:
I have a super scrappy script that I use to bootstrap Debian-based servers. Definitely a personal script, but it might help you out?

#!/bin/bash

# Setup Variables
V_USER='xx'
V_SSH_PORT='xxxxx'

# Update user settings
echo '**** Updating root password'
passwd

echo '**** Creating user: '"$V_USER"
read -p "Press enter to continue"
adduser $V_USER
usermod -aG sudo $V_USER
#su - $V_USER

# Update SSH settings
echo '**** Updating SSH port to '"$V_SSH_PORT"
read -p "Press enter to continue"
sed -i '/PermitRootLogin yes/c\PermitRootLogin no' /etc/ssh/sshd_config
sed -i '/Port 22/c\Port '"$V_SSH_PORT" /etc/ssh/sshd_config

# Install basic packages
echo '**** Installing packages'
read -p "Press enter to continue"
apt -y update
#apt -y upgrade
apt -y install sudo ufw fail2ban htop curl python-pip

# Set up firewall
echo '**** Setting up firewall'
read -p "Press enter to continue"
ufw allow http
ufw allow https
ufw allow $V_SSH_PORT

# Other settings
echo '**** Tweaking settings'
read -p "Press enter to continue"
timedatectl set-timezone America/Los_Angeles

# Install Docker
echo '**** Installing docker'
read -p "Press enter to continue"
# apt -y install apt-transport-https ca-certificates curl gnupg2 software-properties-common python-backports.ssl-match-hostname
# curl -fsSL https://download.docker.com/linux/debian/gpg | apt-key add -
# add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/debian $(lsb_release -cs) stable"
# apt update
# apt install -y docker-ce
# pip install docker-compose
# usermod -aG docker $V_USER
curl -fsSL https://get.docker.com -o get-docker.sh
sh get-docker.sh
rm get-docker.sh
usermod -aG docker $V_USER

# Install Docker
echo '**** Installing docker-compose'
read -p "Press enter to continue"
pip install docker-compose

echo '**** Completed. Rebooting in 5...'
sleep 5
reboot

This is amazing!! Exactly what everyone should be doing.
I hereby save it as ouvoun.sh
I might remove the docker part as I don't use docker for most of my projects.

Though would be interested to know how we could automate ssh keys here
Also, another important thing might be to configure/automate to somehow increase the ulimit. The default ulimits are always too small and often either slow down or crash most server software.

havoc

Basically as per @ouvoun except

Python3 not 2

I'd actually run the apt upgrade. Not sure why it's commented out

The firewall config section is broken. It's setting up the rules but never actually enabling the firewall. Add a ufw enable

And you'll also need a ufw allow 22 else it'll cut off your ssh session the second you enable it given that rule provides for custom port only.

ouvoun

@evnix said:
I might remove the docker part as I don't use docker for most of my projects.

Totally fair. Once I discovered Docker I was addicted to being able to set up my existing stack within a couple of minutes. I’d never go back now.

Though would be interested to know how we could automate ssh keys here

Yeah I’d like that too. Frankly I’m too lazy to use ssh keys, but I know I should.

ouvoun

@havoc said:
Basically as per @ouvoun except

Python3 not 2

I'd actually run the apt upgrade. Not sure why it's commented out

The firewall config section is broken. It's setting up the rules but never actually enabling the firewall. Add a ufw enable

And you'll also need a ufw allow 22 else it'll cut off your ssh session the second you enable it given that rule provides for custom port only.

Yeah, good catch on the firewall. I usually add a few more rules afterwards and then enable. I’ll edit the OP, thanks for the feedback!

seriesn

@ouvoun said:

@evnix said:
I might remove the docker part as I don't use docker for most of my projects.

Totally fair. Once I discovered Docker I was addicted to being able to set up my existing stack within a couple of minutes. I’d never go back now.

Though would be interested to know how we could automate ssh keys here

Yeah I’d like that too. Frankly I’m too lazy to use ssh keys, but I know I should.

Knowing how there’s so many idling VPs y’all keep, I would just whitelist 2/3 vms IP and lock down access to my servers

ouvoun

@seriesn said:
Knowing how there’s so many idling VPs y’all keep, I would just whitelist 2/3 vms IP and lock down access to my servers

Hey I’ve only got two idlers, and that’s one more than I usually have.

havoc

Anybody doing anything fancy with specific IPs? I've been toying with the idea of doing a dynamic dns type thing which tweaks firewall rules on the fly

Or alternatively blocking all countries except mine. I know iptables can do this via bulk rule import but havennt seen a clean way

havoc

@ionswitch_stan said: not really adding security.

I get what you're saying but don't agree 100%. Cutting down bot attempts from 100s to near zero has to have some security benefit

ionswitch_stan

@havoc said:
I get what you're saying but don't agree 100%. Cutting down bot attempts from 100s to near zero has to have some security benefit

This is classically known as security through obscurity. Changing the SSH port is obscuring it. If your SSHd/settings/users are secure, port 22 or 222 becomes simply a logging exercise. If your SSHd/settings/users are not secure, it becomes a hope that no one is scanning obscure ports, doing banner detection, and then brute forcing.

At the end of the day, SSH really shouldn't be exposed on a server to the public internet. In Amazon land (AWS) we Systems Manager that allows out-of-band access to VM's without SSH. In private datacenters you need (generally) a VPN. The majority of providers (myself included) do not offer an easy way to not expose SSH, but allow easy access when you need it.

To really go deeper, we would need a beer... It's a debatable gray area.

Anybody doing anything fancy with specific IPs? I've been toying with the idea of doing a dynamic dns type thing which tweaks firewall rules on the fly

Then I saw this -- which is exactly what I was suggesting.

./allow-access.sh instance
ssh instance
./remove-access.sh instance

Where allow and remove access would hit the providers API to open a network firewall to your instance.

evnix

@ionswitch_stan said: ./allow-access.sh instance
ssh instance
./remove-access.sh instance

This is neat, though I wouldn't be able to do this with multiple providers and I am not sure if all providers have such APIs.

Personally, I would probably use some kind of VPN server, but then again you would need another fallback VPN server if you loose access to the primary VPN server, you might end up locking yourself out.

ionswitch_stan

@evnix said: This is neat, though I wouldn't be able to do this with multiple providers and I am not sure if all providers have such APIs.

Personally, I would probably use some kind of VPN server, but then again you would need another fallback VPN server if you loose access to the primary VPN server, you might end up locking yourself out.

Unfortunately you are right... A next-best-thing is likely whitelisting a host or two as a jump-box that you keep updated and secured.

jvnadr

1. Update
2. Upgrade
3. Install necessary staff like sudo, wget, screen, fail2ban, unzip, git, curl etc.
4. Creating new user with sudo privileges
5. creating a SSH key
6. Disabling root login via password
7. Testing the configuration before exiting
8. Usually, install proxmox on top and NAT environment with bridged network
9. Disabling unnecessary ports
10. Changing root password
11. Then, idling

havoc

@ionswitch_stan said: This is classically known as security through obscurity

No its not.

Youre not relying on obscurity for safety. You're running the exact same security as normal. But moving it to a non 22 port.

Its a additional step on top of normal security measures that happens to cut login attempts dramatically. That's not security through obscurity. It's a big win basically for free

Given a choice do you want to be on a port that:
A) gets hammered 247 with login attempts
B.)does not

Forget the high level arguments. That's just common sense

jvnadr

@tester4 said: Install CSF/LFD and change SSH port, that's about it.

@ouvoun said: I have a super scrappy script that I use to bootstrap Debian-based servers. Definitely a personal script, but it might help you out?

Really, it is not necessary and won't give any extra to security the change of the ssh port. If you are so paranoid, this is a good article (even if it's old) and suggests another approach to keep attackers blind as of port 22: https://www.adayinthelifeof.nl/2012/03/12/why-putting-ssh-on-another-port-than-22-is-bad-idea/

skorous

@havoc said: Youre not relying on obscurity for safety.

It's a pretty simple argument, what security does moving the port provide other than obscurity? None. Therefore the only thing it provides is security through obscurity.

ouvoun

@jvnadr said:
Really, it is not necessary and won't give any extra to security the change of the ssh port. If you are so paranoid, this is a good article (even if it's old) and suggests another approach to keep attackers blind as of port 22: https://www.adayinthelifeof.nl/2012/03/12/why-putting-ssh-on-another-port-than-22-is-bad-idea/

My opinion on this:
1) All of the tools I use on my boxes support ports other than the default
2) It’s super easy to change
3) A non-default port won’t get slapped as hard

So for me, it’s a no brainer. Might not be that more secure, but I don’t see why it hurts at all.

Of course I understand there are setups where a non-default SSH port complicates things. That’s not the case for me and (I assume) quite a few others on this forum.

evnix

Here is an updated version of the script from @ouvoun and some enhancements(untested) by @HostDoc to support/deploy SSH keys and hostname.
Don't forget to replace the XX

#!/bin/bash

# Editable variables
V_USER='xx'
V_SSH_PORT='xxxxx'
V_KEY='ssh-rsa xxxxxxxxxxxxxx'
V_HOSTNAME='xxxxx'

# Update user settings
echo '**** Updating root password'
passwd

echo '**** Creating user: '"$V_USER"
read -p "Press enter to continue"
adduser $V_USER
usermod -aG sudo $V_USER
#su - $V_USER

# Update SSH settings
echo '**** Updating SSH port to '"$V_SSH_PORT"
read -p "Press enter to continue"
sed -i '/PermitRootLogin yes/c\PermitRootLogin no' /etc/ssh/sshd_config
sed -i '/Port 22/c\Port '"$V_SSH_PORT" /etc/ssh/sshd_config
sed -i '/PasswordAuthentication yes/c\PasswordAuthentication no' /etc/ssh/sshd_config
echo '****Adding SSH Key'
mkdir .ssh
chmod 700 .ssh
touch .ssh/authorized_keys
echo "$V_KEY" | dd of=.ssh/authorized_keys status=none
chmod 600 .ssh/authorized_keys

# Install basic packages
echo '**** Installing packages'
read -p "Press enter to continue"
apt -y update
apt -y upgrade
apt -y install sudo ufw fail2ban iotop htop curl python-pip

# Set up firewall
echo '**** Setting up firewall'
read -p "Press enter to continue"
ufw allow http
ufw allow https
ufw allow ssh
ufw allow $V_SSH_PORT
ufw enable

# Other settings
echo '**** Tweaking settings'
read -p "Press enter to continue"
timedatectl set-timezone America/Los_Angeles
hostnamectl set-hostname $V_HOSTNAME
echo xxxxx >/proc/sys/kernel/msgmax
sysctl vm.swappiness=xx

# Install Docker
echo '**** Installing docker'
read -p "Press enter to continue"
curl -fsSL https://get.docker.com -o get-docker.sh
sh get-docker.sh
rm get-docker.sh
usermod -aG docker $V_USER

# Install Docker Compose
echo '**** Installing docker-compose'
read -p "Press enter to continue"
pip install docker-compose

echo '**** Completed. Rebooting in 5...'
sleep 5
reboot

Neoon

Well, for me, it looks like, that script installs bloat, which makes the vps more insecure, instead of what it should do when you run it first, is making the vps more secure.

You may also try:

• Disable password auth + deploying your ssh keys
• Shutoff the SSH port via Firewall

ouvoun

@Neoon said:
Well, for me, it looks like, that script installs bloat, which makes the vps more insecure, instead of what it should do when you run it first, is making the vps more secure.

You may also try:

• Disable password auth + deploying your ssh keys
• Shutoff the SSH port via Firewall

The original poster asked for opinions on what people do on a new server. I assume by “bloat” you mean Docker. And that’s fair. But I depend on Docker; that’s why it’s included.

Of course if you want a secure box, disable login and shut it down forever.

teamacc

@skorous said:

@havoc said: Youre not relying on obscurity for safety.

It's a pretty simple argument, what security does moving the port provide other than obscurity? None. Therefore the only thing it provides is security through obscurity.

I like to think NOT getting hit with brute-force attempts lightens the load on the server, by not having to deal with that pesky aspect.

skorous

@teamacc said: I like to think NOT getting hit with brute-force attempts lightens the load on the server, by not having to deal with that pesky aspect.

Heh heh heh ... that I won't argue with but that's not really a security gain unless you're arguing it makes auditing the logs easier. I prefer iptables rate-limiting for that.

FAT32

I am low key afraid of limiting access of SSH for certain IP only because I keep thinking what if suddenly all my whitelisted IP are no longer usable? Given that no VNC, KVM or IPMI is available, that will cause more trouble and it compromised availability.

isunbejo

Change ssh port and set up IP allow SSH tcp wrapper on /etc/hosts.allow then /etc/hosts.deny for ssh deny all

sonic

Change SSH port, add new sudo user, disallow root, let idle till expired.

TheDP

@isunbejo said:
Change ssh port and set up IP allow SSH tcp wrapper on /etc/hosts.allow then /etc/hosts.deny for ssh deny all

I do this too.

On top of that, iptables ACCEPT/DROP