{"id":1869,"date":"2016-09-05T11:33:16","date_gmt":"2016-09-05T16:33:16","guid":{"rendered":"http:\/\/swildow.darktech.org\/wp\/?p=1869"},"modified":"2016-09-05T11:33:16","modified_gmt":"2016-09-05T16:33:16","slug":"securing-your-linux-server-in-8-steps","status":"publish","type":"post","link":"https:\/\/www.wildow.com\/blog\/?p=1869","title":{"rendered":"Securing your Linux Server in 8 Steps"},"content":{"rendered":"
\n

Securing your Linux Server in 8 Steps<\/a><\/h1>\n<\/header>\n
\n

Before I get going with too many tutorials, it might be a good idea to just step back and talk about the very first thing you should be doing from the start: securing your server!<\/p>\n

Luckily this doesn’t need to take a long time – we can secure things pretty quickly. Let’s get started!<\/p>\n

STEP 1 – Update your server<\/strong><\/p>\n

Depending on your Linux distribution, your install ISO\/DVD could be months or even years old! Running updates on your server immediately will help get any vulnerable packages updated. We can do this in two lines:<\/p>\n

sudo apt-get update
\nsudo apt-get upgrade<\/p><\/blockquote>\n

STEP 2 – Disable root access via SSH<\/strong><\/p>\n

If you’ve ever watched your SSH logs after starting up a server, you’ll notice one thing very quickly: a lot of people are trying to access your server. The other thing you’ll notice is 95% of them are trying to access it via the root user.<\/p>\n

Let’s disable the root login by editing the sshd_config file.<\/p>\n

sudo nano \/etc\/ssh\/sshd_config<\/p><\/blockquote>\n

Find the PermitRootLogin line and change it to “no”:
\nPermitRootLogin no<\/code><\/p>\n

STEP 3 – Change your SSH port<\/strong><\/p>\n

After Step 2, you’ll notice your logs still are full of login attempts. Even though they can’t get in as the root user, they’ll still keep trying. Let’s change the OpenSSH server to use a different port. Open the sshd_config file once more and edit the “Port” line to use an atypical number. For example:
\nPort 5901<\/code><\/p>\n

Restart your SSH server in order to pickup the changes from Steps 2 and 3<\/p>\n

sudo service ssh restart<\/p><\/blockquote>\n

STEP 3.5 – Use SSH Key-based Logins<\/strong><\/p>\n

While this is a great to do on public-facing production servers, it’s really not necessary to need to be done on internal or development servers. If attackers can’t log in as root or even figure out what port SSH is on, you’re already avoiding 99.99% of attacks. If you’re interested in setting up key-based logins, check out this article<\/a> from Ubuntu.<\/p>\n

STEP 4 – Enable your firewall<\/strong><\/p>\n

Most Linux distributions come with iptables by default. Iptables is a very powerful firewall but has quite a steep learning curve for those of us coming from a Windows Server background (don’t hate!). While I plan on creating an iptables tutorial in the future, a much easier frontend for iptables is UFW.<\/p>\n

sudo apt-get install ufw<\/p><\/blockquote>\n

UFW’s context is very simple. The command is simply “ufw allow” followed by a port number. For example, this would open up traffic for an http server:<\/p>\n

ufw allow 80<\/p><\/blockquote>\n

For popular protocols, you can use the protocol name to do the same thing:<\/p>\n

ufw allow http<\/p><\/blockquote>\n

Make sure to allow the custom port number you gave your SSH server, otherwise you’ll lock yourself out! After you have all the rules added, just enable the firewall:<\/p>\n

ufw enable<\/p><\/blockquote>\n

If you ever need to see what rules are currently set, just run:<\/p>\n

ufw status<\/p><\/blockquote>\n

STEP 5 – Check for open ports<\/strong><\/p>\n

For some reason, I always seem to end up with services running that I have no idea how they ended up on my system. Maybe another package listed them as a dependency. Maybe it just came with the default install. Regardless, if a service is listening on a port, it leaves the door open for possible exploit.<\/p>\n

We can see what ports currently have services listening on them by running a quick command:<\/p>\n

sudo netstat -tulpn<\/p><\/blockquote>\n

Anything listening on 0.0.0.0:xxxx may be a problem. To fix, make sure your firewall is not allowing traffic to those ports through. Even better, uninstall the offending package by doing an apt-get remove <package><\/code><\/p>\n

STEP 6 – Install Fail2Ban<\/strong><\/p>\n

Fail2Ban is a program that monitors the authentication logs of various programs. When too many attempts are detected, it blocks the source IP address. First, we’ll need to install it:<\/p>\n

sudo apt-get install fail2ban<\/p><\/blockquote>\n

To configure, open up the configuration file in a text editor, find the services you want to have it watch (for example, SSH), and then restart the service.<\/p>\n

sudo nano \/etc\/fail2ban\/jail.conf<\/p><\/blockquote>\n

    \n
  1. [<\/span>ssh<\/span>]<\/span> #service name<\/span><\/code><\/li>\n
  2. <\/code><\/li>\n
  3. enabled <\/span>=<\/span> true<\/span> #set this to true to enable <\/span><\/code><\/li>\n
  4. port <\/span>=<\/span> 5901<\/span> #change this to the port you set in step 3 <\/span><\/code><\/li>\n
  5. filter <\/span>=<\/span> sshd <\/span><\/code><\/li>\n
  6. logpath <\/span>=<\/span> \/var\/<\/span>log<\/span>\/<\/span>auth<\/span>.<\/span>log <\/span><\/code><\/li>\n
  7. maxretry <\/span>=<\/span> 3<\/span> #set this to how many attempts are allowed <\/span><\/code><\/li>\n<\/ol>\n

    sudo service fail2ban restart<\/p><\/blockquote>\n

    STEP 7 – Disable responding to pings<\/strong><\/p>\n

    As lots of bots find your server by pinging, turning off pings is one way to help hide it (though this really only helps servers that you aren’t driving the public to). To prevent ping responses:<\/p>\n

    sudo nano \/etc\/sysctl.conf<\/p><\/blockquote>\n

    Insert the following into the file:
    \nnet.ipv4.icmp_echo_ignore_all = 1<\/code><\/p>\n

    Save the file and reload the service:<\/p>\n

    sudo sysctl -p<\/p><\/blockquote>\n

    STEP 8 – Read your logs<\/strong><\/p>\n

    This shouldn’t come as any surprise but actually reading the logs can help give you a better idea of what threats you are facing. If you’re getting a lot of invalid attempts coming in from IPs in a particular country, maybe download a geoip firewall tool to block a country. Things like that will help you adapt to threats as they come up.<\/p>\n

    Wrap Up<\/strong><\/p>\n

    If you’ve done the above steps, then you are off to a good start. Some of you will say “Chris, this is hardly enough and dangerous to run a server if this is all you do.” Well you’re right – these guidelines are really meant as a starting point. There are bunches of other things we can do, however a lot of the securing process is dependent on the server role and location (internal vs external facing). While this article<\/a> may go a bit overboard, I would definitely recommend looking over some of the other things you can do to secure your server.<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

    Securing your Linux Server in 8 Steps Before I get going with too many tutorials, it might be a good idea to just step back and talk about the very first thing you should be doing from the start: securing … Read More »<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[12],"tags":[],"class_list":["post-1869","post","type-post","status-publish","format-standard","hentry","category-linux"],"_links":{"self":[{"href":"https:\/\/www.wildow.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1869","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.wildow.com\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.wildow.com\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.wildow.com\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.wildow.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1869"}],"version-history":[{"count":1,"href":"https:\/\/www.wildow.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1869\/revisions"}],"predecessor-version":[{"id":1870,"href":"https:\/\/www.wildow.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1869\/revisions\/1870"}],"wp:attachment":[{"href":"https:\/\/www.wildow.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1869"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.wildow.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1869"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.wildow.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1869"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}