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

The obvious one is to change the SSH port.

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

«13

Comments

  • 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
    
    Thanked by (2)Janevski localhost

    ServerFactory aff best VPS; HostBrr aff best storage.

  • 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.

    Ionswitch.com | High Performance VPS in Seattle and Dallas since 2018

  • Install control panel

    Thanked by (1)evnix
  • Install CSF/LFD and change SSH port, that's about it.

    Thanked by (1)evnix
  • ouvounouvoun OG
    edited December 2019

    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
    
    Thanked by (5)evnix havoc FAT32 dosai souen

    It don’t be like it is until it do.

  • @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.

    Thanked by (1)ouvoun
  • havochavoc OGContent Writer

    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.

    Thanked by (1)evnix
  • @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.

    It don’t be like it is until it do.

  • @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!

    Thanked by (1)evnix

    It don’t be like it is until it do.

  • @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 :)

    Thanked by (1)vimalware
  • @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. :D

    It don’t be like it is until it do.

  • havochavoc OGContent Writer

    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

  • havochavoc OGContent Writer

    @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_stanionswitch_stan OGRetired
    edited December 2019

    @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.

    Thanked by (1)evnix

    Ionswitch.com | High Performance VPS in Seattle and Dallas since 2018

  • evnixevnix OG
    edited December 2019

    @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.

  • @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.

    Ionswitch.com | High Performance VPS in Seattle and Dallas since 2018

  • jvnadrjvnadr OG
    edited December 2019
    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
    Thanked by (1)localhost

    • If a program actually fits in memory and has enough disk space, it is guaranteed to crash.
    • If such a program has not crashed yet, it is waiting for a critical moment before it crashes.

  • havochavoc OGContent Writer
    edited December 2019

    @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

    Thanked by (1)dariox
  • @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/

    • If a program actually fits in memory and has enough disk space, it is guaranteed to crash.
    • If such a program has not crashed yet, it is waiting for a critical moment before it crashes.

  • @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.

  • @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.

    Thanked by (1)AlwaysSkint

    It don’t be like it is until it do.

  • evnixevnix OG
    edited December 2019

    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
    
    Thanked by (1)dosai
  • NeoonNeoon OG
    edited December 2019

    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
  • @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. :)

    It don’t be like it is until it do.

  • @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.

    Thanked by (1)AlwaysSkint

    Hey teamacc. You're a dick. (c) Jon Biloh, 2020.

  • @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.

  • FAT32FAT32 OG
    edited December 2019

    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.

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

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

  • @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 :joy:

    Thanked by (1)Dewlance

    For domain registrations, create an account at Dynadot (ref) and spend $9.99 within 48 hours to receive $5 DynaDollars!
    Looking for cost-effective Managed/Anycast/DDoS-Protected/Geo DNS Services? Try ClouDNS (aff).

Sign In or Register to comment.