Hardening Debian


GNU/LINUX is popular amongst paranoid types due to the audit-able nature of its codebase (or at least most of it).

Many, however, are ultimately misled into thinking that mainstream distributions of GNU/Linux are more secure than windows out of the box. If you scrutinize a newly installed machine, you will find that this is not the case. In fact, almost all distributions start off without a host firewall: That means the machine is open to all incoming connections within its network!

Linux machines are generally unsecured by default. On first boot, most distros do not even have firewalls running by default: they are open to the world. This ultimately implies that Windows 10 is more hardened out of the box than nearly every GNU/Linux. But if a user is willing to experiment and tinker, a Linux machine can be made to compete with Windows in a serious way. Linux machines are, after all, a prime choice for enterprise servers, but are typically maintained by experienced admins.

I'll lay out a number of tips in this post for how to harden one particular distribution of GNU/Linux: Debian. Debian is maintained by the non-profit Debian Project (also: http://sejnfjrq6szgca7v.onion/). It is used as the basis for non-privacy oriented distributions like Ubuntu, but also for security and privacy focused distributions such as the ephemeral operating system Tails, an anonymizing operating system made to be run as a virtual machine called Whonix, etc. There are many more, but I will leave it there.

Debian has one strong benefit: its default software is free software/open sources open license/public. And the software made available via its package manager is verified via a reproducible builds which prevent developers from offering compiled software that is different than the source code they release publicly. Nearly every package offered by the Debian project is complied multiple times by multiple people, so that the hashes of each compilation can by referenced against the package maintainers version to verify he/she has not secretly modified the package. The Debian infrastructure has removed as much trust as possible between the user and the developer, and has thus weakened a serious avenue of attack (an attack made all the more real after the Snowden revelations).

I will start by offering a couple guides that are already available elsewhere:

The AnonGuide is one of the best available starting points for a hardened Debian. It walks you through verifying that your Debian installation file is legitimate, directing debian to update over Tor to official Debian .onion servers, use Whonix within a virtual box, harden your kernels network stack, and even use a keyfile when encrypting your hardrive (the keyfile thing is next level paranoid, but losing that keyfile is losing your data).

The securing Debian manual, the age shows in this own. Some of its suggested tools no longer exist, and there are more that could be added.

Remember that the goal is to make attacks expensive to carry, not impossible. I am assuming the user is relatively new to using Debian. So many readers will not find this helpful.

Now for my tips:

  1. Use disk encryption, particularly with laptops.

  2. In the installation of Debian, you will be offer the opportunity tor partition the drive use LVM with disk encryption.

    Do so, and utilize a strong passphrase

  3. Put strong passwords on your root user and any sudoer/sudo enabled user

    You want to reduce the likelihood of malware being executed by root. An easy way to do so is to make root passwords too strong for malware to guess.

  4. Create separate users for less trustworthy applications

  5. Separate users based on the trustworthiness of applications. Keeping essential files and software away from

  6. Start by activating some kind of firewall and setting it to blocking incoming connections. This will allow your machine to initiate connections, but not accept unsolicited.

  7. If you're a newbie, try UFW (uncomplicated firewall):

    sudo apt-get install ufw

    sudo ufw default deny incoming

    Also (from anondistro):

    sudo nano /etc/ufw/before.rules


    Now search for "icmp"

    Add "#" before each line under "# ok icmp codes" until the line "# allow dhcp client to work"

    sudo ufw enable

  8. Configure Debian to update over TOR with apt-transport tor

  9. When Debian fetches software via its package manager, apt, it uses a locally available public key to verify/authenticate the packages it receives to ensure only legitimate software is installed. A bad guy, including one who had taken control of the server you update from, cannot tamper with the software unless he has the private key used to sign the software. The problem is, however, that most servers do not provide any encryption. You can see this when your run apt-get update and see "http://arbitrary-mirrorserver". That means a bad guy can still see what you're installing and utilize that information in an attack.

    The Debian project thus responded with quite a leap in privacy by providing the apt-transport-tor utility, which forces apt to anonymize its traffic, then by providing official .onion servers in order to prevent the apt traffic from leaving the tor network.

    sudo apt-get install apt-transport-tor

    sudo nano /etc/apt/sources.list

    Modify to match the following:

    deb tor+http://vwakviie2ienjx6t.onion/debian stretch main

    deb tor+http://vwakviie2ienjx6t.onion/debian stretch-updates main

    deb tor+http://sgvtcaew4bxjd7ln.onion/debian-security stretch/updates main

    You may add "tor+" to any repo's address you wish. But the traffic will leave the tor network if it is not .onion.

  10. Utilize sandboxing

  11. Sandboxing constrains running programs under default or user written rules. These rules can vary from file and directory access rules to network and window manager rules

    Two popular sandboxing solutions on linux are Apparmor and Firejail. Both are easy to use, and are widely available in distros.

    You also have the option of installing applications through Flatpak

    I have another post on firejailing steam, which can be used as a guide for how to utilize private directories within firejail. A use feature if that application is taking in files and remote code from the outside world.

    It's important to note that the X11 problem, wherein any application listening on X11 can see anything other applications receive or send through the GUI, can be mitigated by firejail.

    Firejail offers a --x11 option that can designate an alternative display server such as xephyr. Adding "--x11=xephyr" will pick up its configuration from /etc/firejail/firejail.conf and open up a strange, unadjustable window on your screen containing the sandboxed software. You will notice that the xephyr window is effectively its own desktop. A window manager can be run within the xephyr X11 sandbox window, meaning the sandboxed programs can be resized within the statically sized xephyr window.

    If you read that last paragraph without trying it yourself, you will probably not have understood a word of it. Try it out, and you'll see.