Skip to content

Instantly share code, notes, and snippets.

@peanutpi

peanutpi/server_config.md

Last active August 18, 2016 12:11
Show Gist options
  • Save peanutpi/e733bcdc53db08fdf4d41286e4e5a9e3 to your computer and use it in GitHub Desktop.
Save peanutpi/e733bcdc53db08fdf4d41286e4e5a9e3 to your computer and use it in GitHub Desktop.
Download ZIP
server config
Raw
server_config.md

Notes

Steps to secure Ubuntu server

1. Get started

passwd

Change the root password to something long and complex. You won't need to remember it, just store it somewhere secure - this password will only be needed if you lose the ability to log in over ssh or lose your sudo password.

NOTE

use a password manager's password generater set to the most difficult setting. The PW manager saves the password and it is encrypted with access only given by a long master password.

apt-get update
apt-get upgrade

The above gets us started on the right foot.

2. Install Fail2ban

apt-get install fail2ban

Fail2ban (Source) is a daemon that monitors login attempts to a server and blocks suspicious activity as it occurs. It's well configured out of the box.

Out of the box Fail2Ban comes with filters for various protocols (HTTPS, STMP, SSH, etc). It also has integration with a lot of services like Apache and Nginx which can provide a certain level of DDoS or brute force attack protection. You'll want to be careful with using it in this way though because depending on the IP address where the DDoS is coming from, you could lock out real users for a time as well. It offers a lot of configuration options including integration with SendMail to notify you when an IP gets banned. Feel free to take a look at some of the links and see if any of the other options interest you.

If you're going to use fail2ban with ufw then

sed 's/^banaction = .*/banaction = ufw/' /etc/fail2ban/jail.conf > /etc/fail2ban/jail.local

And now fail2ban will use standard ufw commands when blocking people which will show up in 'ufw status'

Now, let's set up your login user. Feel free to name the user something besides 'deploy', it's just a convention we use:

useradd deploy
mkdir /home/deploy
mkdir /home/deploy/.ssh
chmod 700 /home/deploy/.ssh

NOTE

Remember chmod 700 means that owner can read, write, execute. We're still root but in a minute we'll recursively chown this folder for the deploy user and deploy group. Only this user should have access to do anything with the .ssh folder.

With a larger team best practice would dictate that different users would be setup with different levels of permission only granting sudo permissions to a select few. Setup your prefered shell for the deploy user, here we use bash:

usermod -s /bin/bash deploy

3. Require public key authentication

The days of passwords are over. You'll enhance security and ease of use in one fell swoop by ditching those passwords and employing public key authentication for your user accounts. Here are a few notes on this:

  1. ssh keys are better than passwords only because they contain and require more information.
  2. Passwords can be brute forced. Guessing a public key is so essentially impossible that they can be considered perfectly secure
  3. What about a stolen machine? Yes, they have your private key, but expiring an ssh-key is easy, just remove the public key from authorized_keys. You should also have your private key protected by a secure and long passphrase. See next point.
  4. All of this works, AS LONG AS YOU HAVE A LONG AND SECURE PASSPHRASE PROTECTING YOUR KEY. Repeated because it's bloody important.
vim /home/deploy/.ssh/authorized_keys

Add the contents of the id_rsa.pub on your local machine and any other public keys that you want to have access to this server to this file.

chmod 400 /home/deploy/.ssh/authorized_keys
chown deploy:deploy /home/deploy -R

chmod 400 sets permissions so that the file can be read by owner. The second command, chown makes the user deploy and group deploy owners (recursively) of their home directory. We referenced this earlier in when setting read/write/execute permissions to owner for this directory.

4. Test The New User & Enable Sudo

Now test your new account logging into your new server with the deploy user (keep the terminal window with the root login open). If you're successful, switch back to the terminal with the root user active and set a sudo password for your login user:

passwd deploy

Set a complex password - you can either store it somewhere secure or make it something memorable to the team. This is the password you'll use to sudo.

visudo

Add the %sudo group below the root user as shown below. Make sure to comment out any other users and groups with a #. (users have no prefix and groups start with %.) Most fresh installs won't have any there, but just make sure.

root    ALL=(ALL) ALL
%sudo   ALL=(ALL:ALL) ALL

Then add deploy user to the sudo group.

usermod -aG sudo deploy

deploy now has access to sudo permissions. Now normally you need exit and re-login to the shell in order to start having access to the group's permissions. There's a little trick though to prevent having to do that:

exec su -l deploy This starts a new interactive shell for the deploy user with the new permissions to the sudo group. It will require your deploy's password, but feels faster than logging out and logging back in.

5. Lock Down SSH

Configure ssh to prevent password & root logins and lock ssh to particular IPs:

vim /etc/ssh/sshd_config

Add these lines to the file, inserting the ip address from where you will be connecting:

PermitRootLogin no
PasswordAuthentication no
AllowUsers deploy@(your-ip) deploy@(another-ip-if-any)
AddressFamily inet

Now restart ssh:

service ssh restart

6. Set Up A Firewall

There are usually two camps. Those who use IPtables directly and those who use a handy interface called ufw which is a layer on top of IPtables meant to simplify things. Simple is generally better with security. The DigitalOcean ufw is really good and goes over the basics.

ufw is installed by default on Ubuntu and is just an apt-get install ufw away on Debian.

By default ufw should deny all incoming connections and allow all outgoing connections, however, it won't be running (because otherwise how would you be connected?). We'll go through and explicitly allow the connections that we deem okay.

First we'll want to make sure that we are supporting IPv6. Just open up the config file.

vim /etc/default/ufw

Set IPv6 to yes.

IPV6=yes

For the rest of the ports that we're going to open up, we can just use the ufw tool from command line which is very handy.

sudo ufw allow from {your-ip} to any port 22
sudo ufw allow 80
sudo ufw allow 443
sudo ufw disable
sudo ufw enable

This sets up a basic firewall and configures the server to accept traffic over port 80 and 443. You may wish to add more ports depending on what your server is going to do.

7. Enable Automatic Security Updates

I've gotten into the apt-get update/upgrade habit over the years, but with a dozen servers, I found that servers I logged into less frequently weren't staying as fresh. Especially with load-balanced machines, it's important that they all stay up to date. Automated security updates scare me somewhat, but not as badly as unpatched security holes.

apt-get install unattended-upgrades
vim /etc/apt/apt.conf.d/10periodic

Update the file to look like this:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "7";
APT::Periodic::Unattended-Upgrade "1";

The idea here is that you don't want an application going down without you knowing about it because some package was updated that it relies on while security patches very rarely create dependency nightmares at an application level.

One more config file to edit:

vim /etc/apt/apt.conf.d/50unattended-upgrades

Update the file to look like below. You should probably keep updates disabled and stick with security updates only:

Unattended-Upgrade::Allowed-Origins {
        "Ubuntu lucid-security";
//      "Ubuntu lucid-updates";
};

8. Install Logwatch To Keep An Eye On Things

Logwatch is a daemon that monitors your logs and emails them to you. This is useful for tracking and detecting intrusion. If someone were to access your server, the logs that are emailed to you will be helpful in determining what happened and when - as the logs on your server might have been compromised.

apt-get install logwatch
vim /etc/cron.daily/00logwatch

add this line:

/usr/sbin/logwatch --output mail --mailto test@gmail.com --detail high

Reference

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment