> ## Content Index > Fetch the complete content index at: https://linuxhandbook.com/llms.txt > Use this file to discover other available public pages before exploring further. # 12 Things to do After Installing a Linux Server - URL: https://linuxhandbook.com/things-to-do-after-installing-linux-server/ - Published: 2020-09-30T07:33:13.000Z - Updated: 2022-09-12T06:20:58.000Z - Description: Just deployed a server? Here are some recommended things to do after installing Linux server to make it more secure. Automated script is also provided. - Author: LHB Community - Tags: Tips Cloud computing has changed the server scenario drastically. Many platforms are providing [free Linux cloud servers](https://linuxhandbook.com/free-linux-cloud-servers/) and you can deploy your Linux servers in minutes though these cloud platforms. When you spin up a new server, especially if it is visible on the Internet, it will be immediately available to bad guys scouring exposed servers for misconfigurations and vulnerabilities through their automated bot scripts. There are a few things you must do after installing Linux server to ensure your server isn't compromised. Here's a screenshot of what [Fail2ban](https://www.fail2ban.org/wiki/index.php/Main%5FPage?ref=linuxhandbook.com) has seen recently on one of my servers. ![fail2ban Failed Login Attempts](https://linuxhandbook.com/content/images/2020/09/Failed-login-attempts.png) 212 bad login attempts and 6 blocked IP Addresses. All traffic from unauthorized people or scripts trying to log into my server. A few crucial first steps will help you protect your new server builds from compromise. ## Recommended things to do after installing a Linux server to beef up the security I have considered two of the most popular Linux server distributions here: [Ubuntu](https://ubuntu.com/download/server?ref=linuxhandbook.com) and [CentOS](https://www.centos.org/?ref=linuxhandbook.com)/Red Hat. Please [check which Linux you are running](https://linuxhandbook.com/check-linux-version/). Most of the advices are generic here and should be applicable to other Linux unless specifically mentioned. Here are the things I recommend you should check to ensure your Linux server's security. I have provided individual steps but if you want to do it quickly, ***I have also created a script that you can run quickly on any new server you deploy***. ### 1\. Ensure a non-root user is set up Root is almighty and you don't need the root permissions all the time. root is also a valid username on almost every Linux system. Meaning if it is enabled for remote authentication, half the attacker's job, obtaining a valid username is done. Also, if an attacker can get on as root, no further permissions are required to do anything on the system. For these reasons, it is best to log in as a non-root user and to disable root login for remote access using SSH (explained later). #### How to do it? I am assuming that you are logged in as root on your system. Add a new user with the [useradd command](https://linuxhandbook.com/useradd-command/). Replace with a username of your choice. ``` useradd ``` Set up a password with [passwd command](https://linuxhandbook.com/passwd-command/) for the newly added user: ``` passwd ``` ### 2\. Ensure the non-root user has sudo permission Since you'll be logging into this account remotely using Secure Shell (SSH), you'll want to be able to do privileged activities requiring root access. This means the account must have sudo permissions. #### How to do it? The [process for creating sudo user on Ubuntu](https://linuxhandbook.com/create-sudo-user/) and CentOS is similar, but the group you'll be adding the user to is different. You should be logged in as root to preform this step. On **CentOS and Red Hat**, the `wheel` group is the standard group used to give users sudo permissions. Add the user to this group with [usermod command](https://linuxhandbook.com/usermod-command/): ``` usermod -aG wheel ``` **Ubuntu** uses the `sudo` group to manage sudo users. ``` usermod -aG sudo ``` ### 3\. Enabling key based SSH authentication It is important to have key based authentication for SSH enabled so that it's working when we disable password based authentication. Cracked, brute forced, or compromised passwords are a very common way for bad actors to gain access to systems. Spear phishing, extremely targeted spam email that coaxes an unsuspecting user into providing credentials, is but one common method of obtaining credentials. If someone gets your username and password on a system where key-based authentication is enabled *and* password based authentication is disabled for remote access over SSH, that stolen password will no longer get them access to that server. By enabling key based authentication and in a later step disabling password based authentication you have greatly reduced your chances of SSH being used against you. This is one of the elementary [ways to secure SSH server](https://linuxhandbook.com/ssh-hardening-tips/). #### How to do it? You already have SSH enabled on your server, I presume. What you need to do is to generate SSH keys on your personal computer (from where you'll login to the server). Once you have the SSH keys, you should [add the public key to the authorized\_keys on our server](https://linuxhandbook.com/add-ssh-public-key-to-server/) for the non-root user. **Attention**! Do not lose the ssh keys from your personal computer. Make a backup of these keys. If you disable password-based authentication later and lose the SSH keys, you'll be locked out of your own server. ### 4\. Ensure SSH is allowed through the ufw firewall Before you enable the firewall on your system, you should make sure that SSH is allowed. Otherwise, you might be locked out of your system if you are accessing it remotely. #### How to do it? Ubuntu uses Uncomplicated Firewall ([ufw](https://wiki.ubuntu.com/UncomplicatedFirewall?ref=linuxhandbook.com)), and CentOS/Red Hat uses [firewalld](https://firewalld.org/?ref=linuxhandbook.com). On **CentOS/Red Hat**, use the firewall-cmd command: ``` sudo firewall-cmd --zone=public --add-service=ssh --permanent ``` On Ubuntu, use the ufw command like this: ``` sudo ufw allow ssh ``` ### 5\. Enable firewall (only after allowing SSH) A firewall ensures only traffic you specifically permit can flow into your server. If a bad actor gets malware on your server and tries to have it communicate over a port that isn't allowed, or if a service is accidentally enabled, it can't be used to compromise your server or compromise it further. #### How to do it? On CentOS/Red Hat systems, enable the firewalld [systemd service](https://linuxhandbook.com/systemd-list-services/): ``` sudo systemctl start firewalld sudo systemctl enable firewalld ``` On Ubuntu, use this command: ``` sudo ufw enable ``` ### 6\. Set SSH not to display banner One of the ways an attacker may compromise your server is through bugs in the software running your services. A banner can display information about what version of OpenSSH or operating system you're running. No sense in giving information to the bad guys. Make them work for it! #### How to do it? It is default behavior in CentOS/ Red Hat *not* to display a banner so no action is needed. On Ubuntu, you can use: ``` sudo echo "DebianBanner no" >> /etc/ssh/sshd_config.d/10-my-sshd-settings.conf ``` ### 7\. Disable all SSH forwarding While it is not uncommon for administrators to use SSH forwarding to encrypt traffic that may otherwise pass clear text, if you don't use it, you should turn it off. Forwarding could be used by a bad actor to encrypt traffic so it's harder for you to view, or to get traffic that would otherwise be blocked to pass using an authorized port and service. #### How to do it? On **CentOS/Red Hat, a**dd the following to `/etc/ssh/sshd_config`: ``` DisableForwarding yes ``` On **Ubuntu,** add `DisableForwarding yes` to the `10-my-sshd-settings.conf` file: ``` sudo echo "DisableForwarding yes" >> /etc/ssh/sshd_config.d/10-my-sshd-settings.conf ``` [![](https://static.shareasale.com/image/59485/linux-performance-tuning-banner-728x90.jpg)](https://shareasale.com/r.cfm?b=768083&u=747593&m=59485&urllink=&afftrack=&ref=linuxhandbook.com) ### 8\. Disable root login over SSH There's a root user on almost every Linux system. The risks of allowing that account to use SSH are twofold. 1. The username is known and frequently tried by bad guys. 2. If an attacker gets in as root, she has full system access. Disabling the use of the root account for SSH connections negates both risks. #### How to do it? On **CentOS/Red Hat**, find the line `PermitRootLogin yes` in `/etc/ssh/sshd_config` and change it to: ``` PermitRootLogin no ``` On Ubuntu, add `PermitRootLogin no` to the `10-my-sshd-settings.conf` file: ``` sudo echo "PermitRootLogin no" >> /etc/ssh/sshd_config.d/10-my-sshd-settings.conf ``` ### 9\. Disable password-based SSH authentication ***Before disabling password authentication in SSH, make sure that you have key-based authentication configured and tested as mentioned in step 3.*** Disabling password-based authentication blocks malicious actors who try to guess your password or who have socially engineered you into entering your credentials or stolen them by any means from getting onto your server using SSH. An attacker has to have your public and private keys to get to your server. #### How to do it? On **CentOS/Red Hat**, find the line `PasswordAuthentication yes` in `/etc/ssh/sshd_config` and change it to: ``` PasswordAuthentication no ``` On **Ubuntu**, add `PasswordAuthentication no` to the `10-my-sshd-settings.conf` file: ``` sudo echo "PasswordAuthentication no" >> /etc/ssh/sshd_config.d/10-my-sshd-settings.conf ``` ### 10\. Ignore rhosts `rhosts` is associated with rsh, a legacy protocol superseded by secure shell. If a user attempts to create a malicious `rhosts` file, this setting explicitly ignores it. #### How to do it? On **CentOS/Red Hat**, find the line `#IgnoreRhosts yes` in `/etc/ssh/sshd_config` and change it to: ``` IgnoreRhosts yes ``` On **Ubuntu**, add `IgnoreRhosts yes` to the `10-my-sshd-settings.conf` file: ``` sudo echo "IgnoreRhosts yes" >> /etc/ssh/sshd_config.d/10-my-sshd-settings.conf ``` ### 11\. Install fail2ban and configured it to protect SSH [Fail2ban](https://www.fail2ban.org/wiki/index.php/Main%5FPage?ref=linuxhandbook.com) keeps an eye on the log files for configured services like SSH and blocks malicious user's IP Addresses from connecting to your server after a set number of attempts for a set amount of time. If an attacker makes more than 5 failed attempts in a three-hour period, her IP Address will be blocked for 12 hours, for example. Fail2ban can be configured to protect other services too such as websites powered by [nginx](https://nginx.org/en/?ref=linuxhandbook.com) web server or [Apache](https://httpd.apache.org/?ref=linuxhandbook.com) web server. #### How to do it? You can follow our [detailed guide on using Fail2Ban](https://linuxhandbook.com/fail2ban-basic/). ### 12\. Configure automatic security updates (for Red Hat and CentOS) As mentioned previously, an outdated service with an exploit can let an attacker get on your server without even having to log in if the vulnerability is serious enough! It is crucial to have security updates applied quickly to reduce this risk. #### How to do it? For a default [Ubuntu server](https://ubuntu.com/download/server?ref=linuxhandbook.com) installation, automatic security updates are enabled so no action is necessary regarding updates. To configure automatic updates on CentOS / Red Hat, you'll install an application called [dnf-automatic](https://fedoraproject.org/wiki/AutoUpdates?ref=linuxhandbook.com) and enable a timer for it using the commands below: ``` sudo dnf upgrade sudo dnf install dnf-automatic -y sudo systemctl enable --now dnf-automatic.timer ``` You can check timer by running: ``` sudo systemctl status dnf-automatic.timer ``` Look for "loaded" under the Loaded: line and "active" under the Active: line. There may be more or fewer steps depending on your personal taste and what you typically set your servers up to do. ## Bonus Script: First 10 Seconds on a Linux Server As promised, [here's the script](https://github.com/TedLeRoy/first-ten-seconds-centos-ubuntu?ref=linuxhandbook.com) I wrote that does all the above steps I mentioned after you have a non-root user set up and configured for key-based authentication. The script can be run on both Ubuntu 20.04 and CentOS/Red Hat 8. > Please note that you should not run random shell scripts downloaded from the internet blindly, no matter how much you trust the source of the script. You must read the script and try to understand what it does. The entire script is open source and available to everyone and can be viewed [here](https://github.com/TedLeRoy/first-ten-seconds-centos-ubuntu/blob/master/first-ten.sh?ref=linuxhandbook.com). You may [download](https://raw.githubusercontent.com/TedLeRoy/first-ten-seconds-centos-ubuntu/master/first-ten.sh?ref=linuxhandbook.com), read and then [run the bash script](https://linuxhandbook.com/run-shell-script/). Here's a screenshot after a run on Ubuntu 20.04 server. ![After Running Script](https://linuxhandbook.com/content/images/2020/09/first-10-seconds-on-a-server.png) See, how easily you can complete some basic steps to secure your new server builds in CentOS, [Red Hat](https://www.redhat.com/en?ref=linuxhandbook.com), or Ubuntu by running just one script! You're also welcome to provide feedback on the script or request features. ## Conclusion These are just some of the very basic security checks but something that you must do after installing your Linux server. Manually doing these things on a number of servers can be painful and unnecessarily time-consuming. This is where you can take advantage of scripting and use my 'First 10 seconds on a Linux server' script or create your own. These are some of my recommendations. How about you? Do you have something to add to this list? Do provide your suggestion in the comment section. ✍🏻 Author [Ted LeRoy](https://ca.linkedin.com/in/theodoreleroy?ref=linuxhandbook.com) is an Enterprise Security Architect providing a variety of information and physical security guidance to businesses.