Protect your network
Firewall your home with Ipfire, a distro dedicated to keeping your network ports safe.
We covered firewalls last issue, so check that out if you want to learn the ins and outs of packetfiltering on Linux. Now we’re going to cover them again, but this time we’re going for a more practical approach with Ipfire, a dedicated distro for firewalls or other network appliances. You don’t need any particularly special hardware to run a firewall, an old machine or a Raspberry Pi is fine (we’ve included ISOS for 32-bit x86 machines as well as USB/SD Card images for 64-bit PCS and ARMV5 and later devices), but note that at least two network adapters are required. Be that as it may, you can also run Ipfire in a virtual machine (which you can add as many virtual Ethernet adapters to as you like). On reasonable hardware and small networks this will perform just fine, although if the host machine can be compromised then so can the virtual firewall, so we lose some security points doing things this way.
If you want to use a VM for Ipfire, you can use the 32-bit ISO from the Ipfire/ directory on the disc. If you really want to, grab the 64-bit ISO image from the website. For a small installation it’s unlikely to make any difference – memory requirements are low. For a larger or a more complex installation you probably won’t want to run a virtual Ipfire appliance, although thanks to virtio networking and other bits of virtual voodoo
(see our Virtualisation feature last issue: https:// linuxformat.com/archives) this will work fine for simple setups. VPN traffic encryption/decryption requires a fair bit of CPU power, so if you’re planning on allowing of data-hungry access to your VPN, be aware of this. You’ll find instructions on how to set up a cloud instances of Ipfire on AWS and Hetzner cloud on the Ipfire website.
Routing through Ipfire
You can route your entire home network through Ipfire (by setting it as the default gateway on your home router and shifting settings) or you can avoid upsetting other users of your home network by just routing selected machines through Ipfire. Installation (be it real or virtual) is simple, but note that the whole target drive will be erased – the installer provides no means to dual boot from a single drive. Once the system is installed, remove the installation media and reboot to perform initial system setup. Everything is pretty standard – localisation, users and what have you – the important part is the final network setup.
You’ll need at least two network adapters, there is no way around this. If you’re running a VM you can add a second one with a few clicks and reboot to continue the setup. If you’re using a Raspberry Pi 3B or other device with both wired and wireless networking, that will work fine (subject to you setting up an access point with
hostapd). For a two-adapter setup, we must assign one device the Green network and the other device the Red network. You can use up to four adapters with Ipfire, and things get even more colourful if you do that. Use the first option if you need to set up more adapters, and use the second option to assign colours to network hardware. Typically the Green network will be your
private network and the Red network refers to the one connected to the internet. In practice (if you’re not using Ipfire on a machine that connects directly to your ISP) these will both connect via your home router, but your Green network interface will connect (via crossover cable, wireless or another router switch) to the machines you want Ipfire to protect. The idea is that traffic can flow from Green to Red, but not the other way.
IP addresses must be set up for the network devices under Ipfire’s control. In the configuration described above, where we have a secure network ‘underneath’ our home LAN, the Red interface ought to conform to the rest of the LAN, so could be in the form of 192.168.0.something, and the Green interface can technically be anything you want, but it’s sensible to use another designated-private address such as 10.0.0.1 or (192.168.1.1 if you prefer). The Red interface (in this setup) can be set to receive an IP address via DHCP, which offers the easiest setup, but you’ll probably want to configure a static IP later otherwise you’ll be chasing your Ipfire instance after a reboot. Static IP will require you to set the gateway to that of your home router. If you’re running Ipfire virtually then DHCP will use your hypervisor’s NAT network, which should work fine.
Unless you want to mandate anyone using your private network use Static IP, the Green interface will need a DHCP server. Turn this on and use the following settings (or something like them):
Start address: 10.0.0.2
End address: 10.0.0.11
Primary DNS: 10.0.0.1
If you’re using libvirt or Virtualbox, this won’t work since the virtual NAT device has its own DHCP server, which will get in the way. So you’ll have to set up Static IP addresses for the VMS you want Ipfire to protect here. For desktop distros, this is most easily achieved by setting a static IP configuration in Network Manager
(see screenshot). For a physical machine you can connect to the Green interface Ipfire host by direct cable connection (older 100mbit cards need a crossover cable, gigabit Ethernet cards do not) or via a switch.
This should be all you need to complete the initial setup of the Ipfire instance. You should be able to connect to Ipfire from that machine by browsing to https://10.0.0.1:444. The first thing you’ll see is a nasty security warning, because Ipfire uses a self-signed certificate. You can safely ignore this, we promise. The next thing you’ll see is a login box, into which you should identify yourself as admin using the password you set up earlier. Then you’ll be presented with Ipfire’s intuitive web interface.
By default Ipfire forwards DNS requests to the DNS server on the Red interface, which is probably your ISP, via your home router. You may wish to use a public service for this, such as Cloudflare’s 1.1.1.1 or Google’s 8.8.8.8. This you can do by heading to Network > Domain Name System. Uncheck the Use Isp-assigned DNS box, and click the Add button at the top. Only an IP address is required.
We’ll set up a simple rule to allow the Red network to access the web interface on the host. This is not something you’d want to do in real life, but it serves to show the procedure for adding rules. Go to Firewall >
IPFIRE DEFAULT FORWARDING “Ipfire forwards DNS requests to the DNS server on the Red interface, which is probably your ISP, via your home router.”
Firewall Rules and click the New Rule button. In the Source section, select the Standard Networks option and choose RED. Check the Use NAT box below and choose Destination NAT. In the Destination section select the Firewall option and choose GREEN – 10.0.0.1. In the Protocol section choose TCPM, select Any in the Standard Networks dropdown, and in the Source section enter 444 in the External Port box. In the Additional Settings box, you can choose to log, limit, or rate-limit these connections, but we won’t trouble ourselves with that, so just click Add. Click Update, then you should be able to connect to Ipfire’s web interface from anywhere on your LAN.
KEYS ADD EXTRA SECURITY “While the password you set here may be brute-forced or known to an attacker, they still need access to the keys.”
No matter what you do with your Linux servers you will almost certainly have SSH access to them. Indeed this might be the only access you have, so it would be wise to secure it. Naturally, you will already be using a strong password and will have already turned off SSH access for the root account (if you use a login for it). The latter is very important, but generally not necessary on Debian/ Ubuntu servers which use sudo for elevating privileges. Correcting it on other distros is just a matter of adding Permitrootlogin No to the /etc/ssh/sshd_config file and restarting the service. But we can do more. Since we looked at alternatives to passwords on desktops earlier, we may as well study the same topic for servers. Besides passwords, SSH enables you to log in via public key. So by generating a key pair on the machine you log in from, and copying the public part of that pair to the server, you are no longer required to use your password. You may already have a keypair generated, look for a ~/.ssh directory (on your local machine, not your server) and then look in there for files named id.rsa (the private key) and id.rsa.pub (the public key). You probably don’t want to overwrite these if they’re already there, but if you created these a while ago, password-protected them (optional but wise) and forgot the password (these things happen), then you might.
Generating a key pair is easy, just run:
$ ssh-keygen
on the machine you’re going to log in from. You can optionally save the file in a different location, but then you’ll need to provide this (via ssh -i ) every time you use it. You can also provide a password, which might seem counter-intuitive since we are talking about avoiding passwords here. The rationale is that while the password you set here may be brute-forced or known to an attacker, they still need access to the keys for this to be useful. Conversely, if they have the keys, they still need the password, so there’s an additional security factor at a cost of only a minor inconvenience to you.
You can add the keys to the server manually, and cloud providers will let you do it from their management interfaces, but it’s easy enough to use the following command (again, all this is done on the ‘client’ side), change servername to where you’re logging in to:
$ ssh-copy-id servername
This will prompt you for your user password and the key password, before copying the details to the ~/.ssh/ authorized_keys file on the server. It doesn’t matter if you have a different username there, once it’s in place your next login will only prompt you for the key password.
There’s generally no need to try and manage multiple SSH IDS. Keys for multiple servers can be stored happily in the same file. It’s also not necessary to try and copy IDS from one machine to another (it won’t work). Simply set up a different key pair on each machine you plan on logging in from. Besides using keys, it’s wise – and common bread-and-butter security – to set up the
Fail2ban service to prevent bruteforce attacks on your SSH logins (for users not enjoying the recently extolled benefits of keys) and other services. We won’t cover setting it up here (there’s a fine tutorial at http://bit.ly/ lxf262fail2ban) but the idea is that IP addresses that repeatedly attempt to log in will be blocked (using
Iptables) for a set amount of time. Not only does this increase security, it also stops your logs being swamped with failed login attempts.
Nextcloud server audits
One of our favourite tools that you can host yourself is
Nextcloud. We use it all the time at LXF Towers because the Dropbox client on Linux is awful. However, with great self-hosting comes great responsibility, so it’s important to make sure your Nextcloud instance is kept up to date and secure. It’s easy to forget about these things if they don’t break all the time, and indeed this is what happened to us. Sort of. We and other purveyors of fine FOSS have been running Nextcloud on Debian for ages – it’s a strong combination. Debian will perform unattended updates for critical fixes, and manual
updates rarely go anything but smoothly. It’s easy to update Nextcloud from the web interface, it’ll even tell you what PHP commands to run to perform the more fragile parts of the upgrade. Running that a few times got us to Nextcloud 15.0.4, which is still supported but fairly long in the tooth.
Unfortunately ours was a Debian Stretch install (we did say we’ve been running it for ages), which only supports PHP 7.0. Since version 16, Nextcloud has required PHP 7.1. So there’s an important lesson right there: just because your OS hasn’t gone EOL yet (Stretch is supported until 2021) software that’s running on it may have dependencies it can’t provide. In this case we could have used the backported PHP 7.2 packages from https://deb.sury.org, but Debian upgrades are usually straightforward and the journey to Debian 10 (Buster) proved painless. So long as you remove all foreign packages from the system beforehand, you should be fine too. The process is well-documented.
Once you have an up-to-date Nextcloud there are a few headers the developers recommend setting on your webserver. On Apache, for example, the following should be added to your site’s configuration:
Header set X-frame-options sameorigin Header set X-content-type-options nosniff
The first will stop a modern browser from loading the site in a frame, unless it originates from the same webserver. The second prevents Mime-type sniffing, and prevents external CSS and Javascript resources from being used if they are not served with the correct text/html MIME type. Such requests are blocked, and the option will also prevent HTML, text, XML and Javascript resources from being loaded externally. For more information on securing your headers, check out the OWASP (Open Web Application Security Project) Foundation’s in-depth look at the subject at www. owasp.org/index.php/owasp_secure_headers_ Project#tab=headers.
If you have your own VPS, or even your own home server, then you may wish to use it to run your own VPN. These can help you if you’re using a connection you don’t trust, such as public Wi-fi. Data is encrypted between you and the VPS server, and then routed onto the destination from your trusted server. Ipfire can set this up in a few clicks if this is something you’d like to do at home. You may also subscribe to a commercial VPN service, but despite all the wonderful sponsored articles you’ll find offering listicles of the best VPN providers, there’s not really a good reason to trust these entities – even the ones with very shiny websites. You’re giving them carte blanche access to all your connection data, after all. If your goal is just to hide this data from your ISP, or get around any blocks they have in place, that’s fine, but consider why they’re blocking that material in the first place, and whether your circumvention of that block constitutes breaking the law.
If you want to read more about server and software weakness in general, we’d encourage you to read Seven Pernicious Kingdoms: A Taxonomy Of Software Security Errors by Katrina Tsipenyuk et al. This paper goes some way to categorising threats facing developers and system maintainers today. So stay safe out there.