Day 9 - Diving into networking
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.
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
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.
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
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.
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 - do not “deny” ssh, or you’ll lose all contact with your server!)
and then enable this with:
sudo ufw enable
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
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.
POSTING YOUR PROGRESS
- As always, feel free to post your progress, or questions, to the forum.
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:
- 12 ss Command Examples to Monitor Network Connections
- UFW - Uncomplicated Firewall
- Collection of basic Linux Firewall iptables rules
- 10 Netstat Command Example
- UFW Uncomplicated Firewall (video)
- How to install nftables in Ubuntu
- No, moving your ssh port isn’t security by obscurity
Some rights reserved. Check the license terms here