this post was submitted on 10 Jan 2024
8 points (100.0% liked)

Linux Upskill Challenge

696 readers
5 users here now

Daily lessons, support and discussion for those following the month-long "Linux Upskill Challenge" course material. Aimed at those who aspire to get Linux-related jobs in industry - junior Linux sysadmin, devops-related work and similar.


founded 1 year ago
MODERATORS
 

INTRO

The two services your server is now running are sshd for remote login, and apache2 for web access. These are both "open to the world" via the TCP/IP “ports” - 22 and 80.

As a sysadmin, you need to understand what ports you have open on your servers because each open port is also a potential focus of attacks. You need to be be able to put in place appropriate monitoring and controls.

YOUR TASKS TODAY

  • Secure your web server by using a firewall

INSTRUCTIONS

First we'll look at a couple of ways of determining what ports are open on your server:

  • ss - this, "socket status", is a standard utility - replacing the older netstat
  • nmap - this "port scanner" won't normally be installed by default

There are a wide range of options that can be used with ss, but first try: ss -ltpn

The output lines show which ports are open on which interfaces:

sudo ss -ltp
State   Recv-Q  Send-Q   Local Address:Port     Peer Address:Port  Process
LISTEN  0       4096     127.0.0.53%lo:53        0.0.0.0:*      users:(("systemd-resolve",pid=364,fd=13))
LISTEN  0       128            0.0.0.0:22           0.0.0.0:*      users:(("sshd",pid=625,fd=3))
LISTEN  0       128               [::]:22              [::]:*      users:(("sshd",pid=625,fd=4))
LISTEN  0       511                  *:80                *:*      users:(("apache2",pid=106630,fd=4),("apache2",pid=106629,fd=4),("apache2",pid=106627,fd=4))

The network notation can be a little confusing, but the lines above show ports 80 and 22 open "to the world" on all local IP addresses - and port 53 (DNS) open only on a special local address.

Now install nmap with apt install. This works rather differently, actively probing 1,000 or more ports to check whether they're open. It's most famously used to scan remote machines - please don't - but it's also very handy to check your own configuration, by scanning your server:

$ nmap localhost

Starting Nmap 5.21 ( http://nmap.org ) at 2013-03-17 02:18 UTC
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00042s latency).
Not shown: 998 closed ports
PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http

Nmap done: 1 IP address (1 host up) scanned in 0.08 seconds

Port 22 is providing the ssh service, which is how you're connected, so that will be open. If you have Apache running then port 80/http will also be open. Every open port is an increase in the "attack surface", so it's Best Practice to shut down services that you don't need.

Note that however that "localhost" (127.0.0.1), is the loopback network device. Services "bound" only to this will only be available on this local machine. To see what's actually exposed to others, first use the ip a command to find the IP address of your actual network card, and then nmap that.

Host firewall

The Linux kernel has built-in firewall functionality called "netfilter". We configure and query this via various utilities, the most low-level of which are the iptables command, and the newer nftables. These are powerful, but also complex - so we'll use a more friendly alternative - ufw - the "uncomplicated firewall".

First let's list what rules are in place by typing sudo iptables -L

You will see something like this:

Chain INPUT (policy ACCEPT)
target  prot opt source             destination

Chain FORWARD (policy ACCEPT)
target  prot opt source             destination

Chain OUTPUT (policy ACCEPT)
target  prot opt source             destination

So, essentially no firewalling - any traffic is accepted to anywhere.

Using ufw is very simple. It is available by default in all Ubuntu installations after 8.04 LTS, but if you need to install it:

sudo apt install ufw

Then, to allow SSH, but disallow HTTP we would type:

sudo ufw allow ssh
sudo ufw deny http

BEWARE! Don't forget to explicitly ALLOW ssh, or you’ll lose all contact with your server! If not allowed, the firewall assumes the port is DENIED by default.

And then enable this with:

sudo ufw enable

Typing sudo iptables -L now will list the detailed rules generated by this - one of these should now be:

“DROP       tcp  --  anywhere             anywhere             tcp dpt:http”

The effect of this is that although your server is still running Apache, it's no longer accessible from the "outside" - all incoming traffic to the destination port of http/80 being DROPed. Test for yourself! You will probably want to reverse this with:

sudo ufw allow http
sudo ufw enable

In practice, ensuring that you're not running unnecessary services is often enough protection, and a host-based firewall is unnecessary, but this very much depends on the type of server you are configuring. Regardless, hopefully this session has given you some insight into the concepts.

BTW: For this test/learning server you should allow http/80 access again now, because those access.log files will give you a real feel for what it's like to run a server in a hostile world.

Using non-standard ports

Occasionally it may be reasonable to re-configure a service so that it’s provided on a non-standard port - this is particularly common advice for ssh/22 - and would be done by altering the configuration in /etc/ssh/sshd_config.

Some call this “security by obscurity” - equivalent to moving the keyhole on your front door to an unusual place rather than improving the lock itself, or camouflaging your tank rather than improving its armour - but it does effectively eliminate attacks by opportunistic hackers, which is the main threat for most servers.

But, if you're going to do it, remember all the rules and security tools you already have in place. If you are using AWS, for example, and change the SSH port to 2222, you will need to open that port in the EC2 security group for your instance.

EXTENSION

Even after denying access, it might be useful to know who's been trying to gain entry. Check out these discussions of logging and more complex setups:

RESOURCES

TROUBLESHOOT AND MAKE A SAD SERVER HAPPY!

Practice what you've learned with some challenges at SadServers.com:

Some rights reserved. Check the license terms here

no comments (yet)
sorted by: hot top controversial new old
there doesn't seem to be anything here