Hard linux

This guide is to help you secure your system against as many attacks as possible. This is different from the Arch Wiki's security guide because the Arch Wiki does not have everything and does not talk about privacy. The Arch Wiki still has a great guide and I recommend you to read it.

This should work on servers and desktops.

This will work for most other Linux distributions. Some settings may be different or some files may be placed elsewhere.

1. Kernels

An important part of Linux security is hardening the kernel against exploits. This can be with boot parameters, sysctl configs, kernel patches etc.

1.1 Sysctl

Sysctl is a great tool that can increase the kernel's security by changing certain settings. You can use 'sysctl -w (param [value]) ' to change settings temporarily. To change them permanently you can edit /etc/sysctl.conf (this does not exit on Arch) or add .conf files to /etc/sysctl.d. We will be using /etc/sysctl.d

In /etc/sysctl.d create a file called "kptr_restrict.conf" (the name does not matter as long as it ends in '.conf'). In this file add

"kernel.kptr_restrict=2"

This setting hides kernel symbols in /proc/kallsyms. Alternatively you can add "kernel.kptr_restrict=1" but this only hides kernel symbols for users other than the root user.

Now create "dmesg_restrict.conf" and add "kernel.dmesg_restrict=1". This blocks users other than root from being able to see the kernel logs. The kernel logs can give an attacker information about what to exploit in your system.

Create "harden_bpf.conf" and add

"kernel.unprivileged_bpf_disabled=1
net.core.bpf_jit_harden=2"

This makes it so that only root can use the BPF JIT compiler and to harden it. A JIT compiler opens up the possibility for an attacker to exploit many vulnerabilities. This does come with a performance decrease and probably shouldn't be used on servers.

Create "ptrace_scope.conf" and add "kernel.yama.ptrace_scope=2". This makes only root able to use ptrace. Ptrace is a system call that allows a program to alter and inspect a running process. By default it is restricted to allowing the user to only restrict their own process so this may be unnecessary.

Create "kexec.conf" and add "kernel.kexec_load_disabled=1". This disables kexec which can be used to switch the running kernel.

Create "tcp_hardening.conf" and add

"net.ipv4.tcp_syncookies=1"

This helps protect against SYN flood attacks which is a form of denial of service attack where an attacker sends a lot of SYN requests in an attempt to consume enough resources to make the system unresponsive to legitimate traffic.

"net.ipv4.tcp_rfc1337=1"

This protects against time-wait assassination. It drops RST packets for sockets in the time-wait state.

"net.ipv4.conf.default.rp_filter=1
net.ipv4.conf.all.rp_filter=1"

These enable source validation of packets received from all interfaces of the machine. This protects against IP spoofing methods in which an attacker can send a packet with a fake IP address.

"net.ipv4.conf.all.accept_redirects=0
net.ipv4.conf.default.accept_redirects=0
net.ipv4.conf.all.secure_redirects=0
net.ipv4.conf.default.secure_redirects=0
net.ipv6.conf.all.accept_redirects=0
net.ipv6.conf.default.accept_redirects=0"

These disable ICMP redirect acceptance. If these settings are not set then an attacker can redirect an ICMP request to anywhere they want.

"net.ipv4.conf.all.send_redirects=0
net.ipv4.conf.default.send_redirects=0"

These disable ICMP redirect sending when on a non-router.

"net.ipv4.icmp_echo_ignore_all=1"

This settings makes your system ignore ICMP requests.

This hardens the TCP/IP stack and tightens network security options.

Create "mmap_aslr.conf" and add

"vm.mmap_rnd_bits=32
vm.mmap_rnd_compat_bits=16"

These settings are set to the highest value to improve ASLR effectiveness for mmap. This may break some things that do not expect to be shoved high into memory.

Create "tcp_timestamps.conf" and add "net.ipv4.tcp_timestamps=0". This disables TCP timestamps which can be used to can remotely calculate the system uptime and boot time of the machine and the host's clock down to millisecond precision. This is more information an adversary can use to deanonymize you. If using a server then you should not do this as TCP timestamps provide protection against wrapped sequence numbers. This may also decrease performance.

Create "sysrq.conf" and add

"kernel.sysrq=0"

This disables the SysRq key which can make the kernel run certain commands regardless of whatever it is currently doing. Some of these commands are usually needed to be run as root but the SysRq key allows them to be run as anyone.

Create "unprivileged_users_clone.conf" and add

"kernel.unprivileged_userns_clone=0"

This disables unprivileged user namespaces. User namespaces add a lot of attack surface for privilege escalation so it's best to restrict them to root only. This may break some sandboxing programs such as bubblewrap. These can be fixed by making the sandbox binaries setuid.

Create "tcp_sack.conf" and add

"net.ipv4.tcp_sack=0"

This disables TCP SACK. SACK is commonly exploited and not needed for many circumstances so it should be disabled if you don't need it. To learn if SACK is needed for you or not, see https://serverfault.com/questions/10955/when-to-turn-tcp-sack-off.

1.2 Boot Parameters

Boot parameters pass settings to the kernel at boot using your bootloader. Some settings can be used to increase security. If using GRUB then edit /etc/default/grub and add your parameters at "GRUB_CMDLINE_LINUX_DEFAULT=".

If using Syslinux then edit /boot/syslinux/syslinux.cfg and add them to the 'APPEND' line.

Add "apparmor=1 security=apparmor". These enable the AppArmor module which we will setup later. If using SELinux or other security modules then do not use these settings.

Add "slab_nomerge" and "slub_debug=FZP". slab_nomerge disables the merging of slabs of similar sizes. Sometimes a slab can be used in a vulnerable way which an attacker can exploit.

slub_debug=FZP enables sanity checks (F), redzoning (Z) and poisoning (P). Sanity checks make sure that a claim is true. Redzoning adds extra areas around slabs that detect when a slab is overwritten past its real size, which can help detect overflows. Poisoning writes an arbitrary value to freed objects, so any modification or reference to that object after being freed or before being initialized will be detected and prevented.

Add "mce=0". This causes the kernel to panic on uncorrectable errors in ECC memory which could be exploited. This is not needed for systems without ECC memory.

Add "page_poison=1". This makes the kernel overwrite freed memory so it can't leak. This decrease performance for systems that allocate memory often like desktops or laptops

Add "pti=on". This enables Kernel Page Table Isolation which mitigates Meltdown and prevents some KASLR bypasses.

Add "mds=full,nosmt" to enable all mitigations for the MDS vulnerability and disable SMT. This may have a significant performance decrease as it disables hyperthreading.

Add "module.sig_enforce=1". This only allows kernel modules signed with a valid key to be loaded which increases security by making it harder to load a malicious module. This prevents all out-of-tree kernel modules from being loaded. This includes modules such as the virtualbox modules, wireguard and nvidia drivers which may not be wanted depending on your setup.

Optionally add "ipv6.disable=1" to disable the whole IPv6 stack which may have some privacy issues depending on your setup as it uses your MAC address to create an IPv6 address which can be used to track you. This can be solved with IPv6 privacy extensions rather than disabling it entirely. This also reduces attack surface so its best to disable it if not needed.

If you want to be able to create AppArmor profiles using aa-genprof then add "audit=1".

So now we have

GRUB_CMDLINE_LINUX_DEFAULT="apparmor=1 security=apparmor slab_nomerge slub_debug=FZP mce=0 page_poison=1 pti=on mds=full,smt module.sig_enforce=1 audit=1"

You will need to regenerate your GRUB configuration file to apply these by running

"grub-mkconfig -o /boot/grub/grub.cfg"

1.3 hidepid

/proc contains information about all process running on the system. By default this is accessible to all users. This can allow an attacker to get information about what services to attack. To restrict this information to the root account add "proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0" to /etc/fstab.

For user sessions to work correctly add this to /etc/systemd/system/systemd-logind.service.d/hidepid.conf
"[Service]
SupplementaryGroups=proc"

1.4 Netfilter's connection tracking helper

Netfilter's automatic conntrack helper assignment is dangerous as it enables a lot of code in the kernel that parses incoming network packets which is potentially unsafe. (https://home.regit.org/netfilter-en/secure-use-of-helpers/)

To disable this, create /etc/modprobe.d/no-conntrack-helper.conf and add

"options nf_conntrack nf_conntrack_helper=0"

1.5 Linux-hardened

In the Arch repositories there is a package with a hardened kernel. This contains patches for security, secure compiling options and more. You should install this and the linux-hardened-headers package.

1.6 Grsecurity

Grsecurity is a set of kernel patches that can increase kernel security. These patches used to be available for everyone but now it is commercial and you have to pay to get them. These patches offer a great increase in security but is a mess and very hard to use. You really should not use it on desktops.

Grsecurity may interfere with things like sandboxing.

2. Mandatory Access Control (MAC)

MAC systems can greatly increase security by giving fine-grained control over what a certain program can access. This means your browser won't have access to your entire home directory or something similar.

The main MAC systems are SELinux and Apparmor. SELinux is a lot more secure than AppArmor but is extremely difficult to use and isn't supported in Arch so we will be using AppArmor.

To enable Apparmor, install the AppArmor package, enable the AppArmor systemd service and set the kernel parameters required for AppArmor described above. Just installing AppArmor won't increase security. You need to develop profiles for certain applications to restrict them.

To enable caching of the profiles to increase boot speed, uncomment 'write-cache' in /etc/apparmor/parser.conf.

To create AppArmor profiles run "aa-genprof /usr/bin/(program)". Open the program and start using at as you normally would. AppArmor will detect what files it needs access to and will add them to the profile if you choose. This will not cover everything an application will do but it is a good starting point for creating profiles.

This is only a very basic explanation but I advise you to learn how to use AppArmor as it can help protect your system against lots of attacks.

AppArmor will break things and it will be very hard to manage profiles. Programs may need to randomly access a file that Apparmor or other MAC systems will block. This makes using programs properly with AppArmor very difficult.

I will be making AppArmor profiles that you can use here https://gitlab.com/madaidan/apparmor-profiles

3. Sandboxes

Sandbox programs allow you to run a program in an isolated space that has no, or limited access to the rest of your system. You can use these to secure your applications or run untrusted programs.

Some great sandbox programs are Firejail and Bubblewrap. Firejail by default comes with lots of profiles so you can run programs in sandboxes. Run 'firejail (program)' to run it in a sandbox. If there isn't a profile configured then Firejail will use the default profile.

To make it automatically run programs in sandboxes then run

"ln -s /usr/bin/firejail /usr/local/bin/(program)"

You can also symlink it to another area e.g. ~/.local/bin

To make it automatically run all programs with a profile configured in Firejail then run

"firecfg"

The problem with Firejail is that it has huge attack surface. This has led to Firejail having trivial privilege escalations and sandbox escapes. Bubblewrap is better in this regard as it tries to have minimal attack surface.

3.1 Sandboxing Xorg

Any Xorg window can have access to another window. This allows for keyloggers or screenshot programs that can even record the root password. You can sandbox Xorg with Xpra/Xephyr and Firejail. To use Xephyr install xorg-server-xephyr and to use Xpra install 'xpra'. To sandbox a program with Firejail and Xephyr run

"firejail --x11=xephyr (program)"

You can also run a whole other window manager with Firejail and Xephyr by running

"firejail --x11=xephyr (window-manager)"

Right click to get a list of all applications.

You can use Xpra the same way although I've had some problems with it.

Wayland isolates windows from each other by default and would be better to use than Xorg.

4. The Root Account

Root can do anything. It has access to your whole system. This means you should lock it down as much as possible so attackers cannot gain root access.

4.1 /etc/securetty

/etc/securetty tells the system where you are allowed to login as root. It is recommended to keep this file empty so nobody can login from a tty.

This may break some things so be careful when doing this.

4.2 Restricting su

su lets you switch users from a terminal. By default it tries to login as root. To restrict the use of su to users within the 'wheel' group then uncomment "auth required pam_wheel.so use_uid" in /etc/pam.d/su and /etc/pam.d/su-l (that's the letter l, not the number one).

To manually restrict su run
"chgrp wheel /usr/bin/su
chmod 4550 /usr/bin/su".

4.3 Locking the root account

You can run "passwd -l root" to lock the root account so you cannot login.

4.4 Denying Root Login via SSH

To prevent someone from logging in as root via SSH edit /etc/ssh/sshd_config and add "PermitRootLogin no". If you use keys to login instead of passwords for SSH then "PermitRootLogin prohibit-password" might be a better option.

4.5 Increase the Number of Hashing Rounds

You can increase the number of hashing rounds that shadow can use. This can increase the security of your hashed passwords. It makes an attacker have to compute a lot more hashes to crack your password. By default shadow uses 5000 rounds but you can increase this to as many as you want. The more rounds it does the slower it wil be to login. Edit /etc/pam.d/passwd and add the rounds option.

"password required pam_unix.so sha512 shadow nullok rounds=65536"

This makes shadow perform 65536 rounds.

Your passwords are not automatically rehashed after applying this setting so you need to reset the password with

"passwd username"

Replace 'username' with the user whose password you are changing.

This can be applied to your user account or the root account.

5. Systemd Sandboxes

Systemd has the ability to sandbox services so they can only access what they need. Here is an example of a sandboxed systemd service.

"[Service]
CapabilityBoundingSet= CAP_NET_BIND_SERVICE
ProtectSystem=strict
ReadWriteDirectories=/var/lib/tor/
ProtectHome=true
ProtectKernelTunables=true
ProtectKernelModules=true
ProtectControlGroups=true
PrivateTmp=true
PrivateUsers=yes
MemoryDenyWriteExecute=true
NoNewPrivileges=true
RestrictRealtime=true
RestrictAddressFamilies=AF_INET AF_UNIX
SystemCallArchitectures=native
RestrictNamespaces=yes
RuntimeDirectoryMode=0700
SystemCallFilter=~@clock @cpu-emulation @debug @keyring @module @mount @obsolete @raw-io
AppArmorProfile=/etc/apparmor.d/usr.bin.tor"

To learn more about the options you can set, read the systemd.exec manpage.

You can use 'systemd-analyze security' to see what security parameters a service needs e.g.

"systemd-analyze security tor.service"

This can help you when making systemd sandboxes.

To make a sandbox you need to create a directory in /etc/systemd/system called (service).d e.g. /etc/systemd/system/tor.service.d. In this directory add a file that has your sandbox. The file name needs to end in .conf.

6. Restricting Xorg Root Access

The following section does not apply to Arch Linux as it starts X rootless by default. This may help with other distributions.

Xorg is a massive amount of code and runs as root by default. This makes it more likely to have exploits that can gain root privileges. To stop it from using root create /etc/X11/Xwrapper.config and add "needs_root_rights = no".

To make sure that this works run this as root and check for Xorg.

"ps -U root -u root u"

7. Firewalls.

Firewalls increase security and is recommended that you always use one. They control incoming and outgoing network traffic and can be used to block or allow certain types of traffic. So you can make it block incoming connections to your machine which makes it a lot harder for an adversary to remotely access your system. UFW is a great and easy to use firewall. To set it to block all incoming connections run "ufw default deny incoming".

8. Tor

Tor is an anonymity network. It tries to make you anonymous online. To learn more about Tor see https://theprivacyguide1.github.io/tor.html

Tor can be used to anonymize your traffic and increase your privacy.

8.1 Tor browser

The Tor Browser is a browser based on Firefox that is configured for privacy and routes all connections through Tor. Get it from https://torproject.org

It is recommended not to use any other browser for Tor because you can easily misconfigure it and break it. It will also have a completely different browser fingerprint from the Tor Browser which can be used to deanonymize you.

You should use apparmor with the Tor Browser to increase security.

https://github.com/micahflee/torbrowser-launcher/tree/develop/apparmor

8.2 Torsocks

Torsocks can force apps' traffic through Tor. This is great for privacy because it is resistant to leaks.

8.3 Stream Isolation

Stream isolation makes programs use different Tor circuits from each other to prevent identity correlation. To enable this edit /etc/tor/torrc and configure more SocksPorts. 9050 is the default SocksPort. Once you have made more, configure your programs to use those new ports and you will have stream isolation.

Pacman can use stream isolation by editing /etc/pacman.conf. Add
"XferCommand = /usr/bin/curl --socks5-hostname localhost:9062 --continue-at - --fail --output %o %u" to /etc/pacman.conf. Replace 9062 with your SocksPort.

Forcing Pacman through Tor will make your downloads much slower.

8.4 Transparent Proxy

You can configure your whole system to use Tor by default with a transparent proxy. This can help prevent leaks.

To do this add
"TransPort 9040
DNSPort 5353
SocksPort 9050" to /etc/tor/torrc

We will use iptables to force all traffic through Tor.

"*nat
:PREROUTING ACCEPT [6:2126]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [17:6239]
:POSTROUTING ACCEPT [6:408]

-A PREROUTING ! -i lo -p udp -m udp --dport 53 -j REDIRECT --to-ports 5353
-A PREROUTING ! -i lo -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j REDIRECT --to-ports 9040
-A OUTPUT -o lo -j RETURN
--ipv4 -A OUTPUT -d 192.168.0.0/16 -j RETURN
-A OUTPUT -m owner --uid-owner "tor" -j RETURN
-A OUTPUT -p udp -m udp --dport 53 -j REDIRECT --to-ports 5353
-A OUTPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j REDIRECT --to-ports 9040
COMMIT

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]

-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
--ipv4 -A INPUT -p tcp -j REJECT --reject-with tcp-reset
--ipv4 -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
--ipv4 -A INPUT -j REJECT --reject-with icmp-proto-unreachable
--ipv6 -A INPUT -j REJECT
--ipv4 -A OUTPUT -d 127.0.0.0/8 -j ACCEPT
--ipv4 -A OUTPUT -d 192.168.0.0/16 -j ACCEPT
--ipv6 -A OUTPUT -d ::1/8 -j ACCEPT
-A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -m owner --uid-owner "tor" -j ACCEPT
--ipv4 -A OUTPUT -j REJECT --reject-with icmp-port-unreachable
--ipv6 -A OUTPUT -j REJECT
COMMIT". Add this to /etc/iptables/iptables.rules and symlink it to /etc/iptables/ip6tables.rules if using IPv6.

Edit /etc/resolv.conf and set it to 127.0.0.1. You may need to configure dnsmasq or any other resolver to set your DNS as 127.0.0.1:5353.

Edit /etc/dhcpcd.conf and add "nohook resolv.conf" to stop it from overwriting resolv.conf. Run "chattr +i /etc/resolv.conf" to prevent all services from overwriting it.

To use stream isolation with a transparent proxy then add more SocksPorts in your torrc and configure your programs to use those ports.

8.5 TorDNS

To use Tor for your DNS then configure a DNSPort in your torrc and edit /etc/resolv.conf to 127.0.0.1. /etc/resolv.conf can only use port 53 for DNS. If using any other ports like with a transparent proxy then use something like dnsmasq.

8.6 Tor over Tor

If you force Tor traffic to go through Tor again you will get Tor over Tor. For example if you use the default Tor Browser with a transparent proxy. You could get 6 hops from this but it is not guaranteed that these hops will be different. The user could end up with the same hops, possibly in reverse or mixed order.

The Tor Project recommends to not use more than three hops.

"We don't want to encourage people to use paths longer than this — it increases load on the network without (as far as we can tell) providing any more security. Remember that the best way to attack Tor is to attack the endpoints and ignore the middle of the path. Also, using paths longer than 3 could harm anonymity, first because it makes "denial of security" attacks easier, and second because it could act as an identifier if only a few people do it ("Oh, there's that person who changed her path length again"). " https://2019.www.torproject.org/docs/faq.html.en#ChoosePathLength

8.7 Configuring the Tor Browser to prevent Tor over Tor

If you use a transparent proxy and decide to use the Tor Browser then the Tor Browser's Tor traffic with get forced through Tor which gives you Tor over Tor.

A way around this is to disable Tor in the Tor Browser. In /etc/environment add

"## Deactivate tor-launcher
TOR_SKIP_LAUNCH=1

## Environment variable to disable the "TorButton"
## "Open Network Settings" menu item. It is not useful and confusing to have.
TOR_NO_DISPLAY_NETWORK_SETTINGS=1

## Environment variable to skip TorButton control port verification
TOR_SKIP_CONTROLPORTTEST=1"

Tor should now be disabled in the Tor Browser. You should also configure the proxy settings of the Tor Browser so you can use stream isolation. Create a user.js file in the default profile of the Tor Browser. Add

"user_pref("extensions.torlauncher.start_tor", false);
user_pref("network.proxy.socks", "127.0.0.1");
user_pref("network.proxy.socks_port", "9150");
user_pref("network.proxy.socks_remote_dns", true);
user_pref("network.proxy.type", 1);
user_pref("extensions.torlauncher.control_host", "127.0.0.1");
user_pref("extensions.torlauncher.control_port", "9150");"

Change 9150 to your configured SocksPort. I recommend to use 9150 as it is easier to use in the Tor Browser.

9. Hostnames and Usernames

Hostnames and usernames may leak information about you or your system. It is recommended to set your hostname to a generic one such as 'host' or 'localhost' and username to 'user'. This means an adversary cannot find information about you through these. For example, if your username is your first name and your hostname is your last an adversary can now easily see your full name.

10. Bluetooth and other wireless devices

Bluetooth and other wireless services can be used to attack your system by creating more ways an attacker can use to remotely access your system. You should disable as much of these as possible to reduce attack surface. Run 'rfkill block all' to block all wireless devices and 'rfkill unblock wifi' to unblock wifi.

You can also blacklist the certain modules to prevent them from loading. For example, to blacklist the bluetooth module, create /etc/modprobe.d/blacklist-bluetooth.conf and add

"install btusb /bin/true
install bluetooth /bin/true".

You should always use "install (module) /bin/true" instead of "blacklist (module)" as modules blacklisted via "blacklist" can still be loaded if another module depends on it.

11. MAC Address Spoofing

MAC addresses can be used to identify you. They are unique identifiers exposed when you connect to a network. To spoof them, install macchanger and run "macchanger -e (network interface)". To find out your network interfaces run "ip a".

"[Unit]
Description=macchanger on eth0
Wants=network-pre.target
Before=network-pre.target
BindsTo=sys-subsystem-net-devices-eth0.device
After=sys-subsystem-net-devices-eth0.device

[Service]
ExecStart=/usr/bin/macchanger -e eth0
Type=oneshot
CapabilityBoundingSet=CAP_NET_ADMIN
ProtectSystem=strict
ProtectHome=true
ProtectKernelTunables=true
ProtectKernelModules=true
ProtectControlGroups=true
PrivateTmp=true
MemoryDenyWriteExecute=true
NoNewPrivileges=true
RestrictRealtime=true
RestrictAddressFamilies=AF_INET AF_INET6
SystemCallArchitectures=native
SystemCallFilter=~@clock @cpu-emulation @debug @keyring @ipc @module @mount @obsolete @raw-io
RestrictNamespaces=yes

[Install]
WantedBy=multi-user.target
" Here is a systemd service to spoof the MAC address of eth0 at boot. Replace eth0 with your network interface. This service is also sandboxed.

You should always use "macchanger -e" rather than "macchanger -r". This is because "macchanger -r" completely randomizes the MAC address which makes it really obvious that you're spoofing your MAC address which makes you stand out. "macchanger -e" doesn't spoof the vendor bytes so it's much more believable.

If you use NetworkManager you can set it to randomize the MAC address while scanning for networks or set it to randomize the MAC address each time you connect to a network. This may be more useful than using macchanger as a systemd service. By default the MAC address is randomized while scanning for networks. To randomize each time you connect to a network create /etc/NetworkManager/conf.d/rand_mac.conf and add

"[connection-mac-randomization]
ethernet.cloned-mac-address=random
wifi.cloned-mac-address=random"

12. Umask

Umasks set the default file permissions for newly created files. The default is 022 which is not very secure. This gives read access to every user on the system for newly created files. Edit /etc/profile and change the umask to 0077 which makes new files not readable by anyone other than the owner.

13. USBs

USBs can be used to break your security and give you malware. It is good to block all newly connected USBs by default to prevent these attacks. USBGuard is good for this.

You could also use "nousb" as a boot parameter to disable all USB support. This isn't recommended if you will ever need to use a USB.

14. Thunderbolt and Firewire

Thunderbolt and Firewire allow any connected device to have full access to your system memory. Disable these modules by creating "/etc/modprobe.d/blacklist-dma.conf". Add

"install firewire-core /bin/true
install blacklist thunderbolt /bin/true"

to blacklist those modules from loading.

15. Virtual Machines

Virtual Machines (VMs) provide lots of security by isolating processes and making a virtual computer. You should use them if you want a lot of isolation from a process you want to run e.g. if testing malware. I recommend to use KVM/QEMU.

15.1 Virtualbox

You should not use Virtualbox for multiple reasons.

1) They use a non-free toolchain to compile their BIOS which is problematic for some free software projects.

2) They don't fix security bugs. Many bugs are left in because the developers are too lazy to fix them.

3) They rarely tell people about bugs. If they discover a bug they hide it from everyone else which makes it a lot harder for the community to make patches.

4) A lot of important features only come with the extension pack which is proprietary.

15.2 KVM/QEMU

KVM is a kernel module that allows the kernel to function like a hypervisor.

QEMU is an emulator that can use KVM.

Virt-manager and GNOME Boxes are both good GUIs to manage KVM/QEMU virtual machines.

15.3 Nested Virtualization

Running virtual machines inside virtual machines is called nested virtualization. I recommend you to not do this. Nested virtualization is not supported on some hypervisors and depending on your setup, will bring no security gain.

If you run virtualbox inside virtualbox then you will gain no security. If you run KVM/QEMU inside virtualbox you may gain security. The reason for this is that if malware can escape virtualbox then having a second virtualbox is useless as it can just use the same exploit. Combining different hypervisors may increase security although this has not been tested much.

16. Core Dumps

Core dumps contain the recorded state of the working memory of a program at a specific time, usually when that program has crashed. These can contain very important information such as passwords and encryption keys. You should disable these to prevent someone from accessing that information.

There are three ways to disable them. With sysctl, systemd and ulimit. The sysctl way may not properly disable core dumps as systemd overrides it. I use all three ways to make sure core dumps are disabled.

If you are a developer then you should not disable these or change the storage size to something small.

16.1 Sysctl

Create /etc/sysctl.d/coredump.conf or edit /etc/sysctl.conf (this does not exist on arch). Add this to possibly disable core dumps.

"kernel.core_pattern=|/bin/false"

16.2 Systemd

Create /etc/systemd/coredump.conf.d/custom.conf. You may need to create /etc/systemd/coredump.conf.d/ first. Add this to disable core dumps.

"[Coredump]
Storage=none"

16.3 Ulimit

In /etc/security/limits.conf add

"* hard core 0"

16.4 Disabling setuid processes from dumping their memory.

Process that run with elevated privileges (setuid) may still dump their memory even after these settings. To prevent them from doing this create /etc/sysctl.d/suid_dumpable.conf or edit /etc/sysctl.conf and add

"fs.suid_dumpable=0"

Arch sets this setting by default so there is no need to do this on Arch.

17. Microcode Updates

Microcode updates are important. They provide security benefits such as protection against the Meltdown and Spectre CPU bugs.

AMD uses the amd-ucode package and Intel uses the intel-ucode package.

To enable them on GRUB run

"grub-mkconfig -o /boot/grub/grub.cfg"

More information and ways to enable them on different bootloaders can be found here https://wiki.archlinux.org/index.php/Microcode.

18. Hardware/Firmware

This isn't necessarily related to Linux but is still important for security regardless. Backdoored hardware has access to your whole system. It is important that we try to secure our hardware as much as possible.

18.1 Open Source Hardware

A way around hardware backdoors is to use open source hardware. This means you can verify all the code you run and can make sure there are no backdoors.


18.2 Intel ME

All modern Intel CPUs come with an Intel ME (Management Engine). This is mainly used for businesses but can be used to compromise your computer. The ME has full access to memory, the TCP/IP stack, can send and receive network packets, can activate your computer remotely and is signed with an RSA 2048 key that cannot be bruteforced. The ME is completely proprietary so nobody can audit it. It is important that we try to minimize the risks it brings.

Intel ties the ME into the boot process so disabling it isn't an option.

You can use me_cleaner (https://github.com/corna/me_cleaner) to remove unnecessary partitions from the ME. This has a high risk of bricking your computer so be careful when using it.

18.3 AMD PSP

AMD CPUs come with the PSP. This is used to verify the firmware has not been tampered with. People believe that this can be used as a backdoor but there is no evidence to say it is or that it has access to anything that is not needed. The PSP is proprietary and AMD has repeatedly refused to release the source code of it which is worrying.

18.4 Coreboot

Coreboot (https://www.coreboot.org/) is an open source UEFI/BIOS replacement. It only has a few proprietary blobs and these shouldn't be a problem.

18.5 Libreboot

Libreboot (https://libreboot.org/) is a de-blobbed version of Coreboot so it removes all proprietary blobs. This makes it incompatible with newer computers and have a high risk of bricking your motherboard.

I do not recommend Libreboot as it does not allow microcode updates which are very important for security.

19. ICMP Timestamps

ICMP timestamps can expose your clock time. This is more information an adversary can use to track you down. You need to block them with a firewall. The easiest way is to block all incoming connections. You can do this with UFW by running

"ufw default deny incoming".

20. NTP

NTP is very insecure as it is unauthenticated and unencrypted. This means someone can do a man in the middle attack on your connection and give you a false time. This allows for fingerprinting as an attacker can give you a unique time and be able to track you with that. It also means you are vulnerable to replay attacks.

NTP leaks your local computer time in NTP timestamp format which can be used for clock skew fingerprinting. This can be used to de-anonymize users.

There is authentication for NTP called autokey but this is insecure and doesn't solve the problem of clock skew fingerprinting.

You might want to disable this and use your local system and hardware clock although this can make you more vulnerable to clock skew fingerprinting. I have developed a tool called Secure Time Synchronization (https://gitlab.com/madaidan/secure-time-sync) that securely syncs the time to the current UTC time. You may also want to look into Whonix's sdwdate.

Uninstall any NTP clients and disable it by running

"timedatectl set-ntp 0"

and

"systemctl disable systemd-timesyncd.service"

If you're on a server, then it is unrecommended to disable NTP as it is needed for highly accurate time synchronization.

21. IPv6 Privacy Extensions

IPv6 addresses are generated through your computer's MAC address. This makes every IPv6 address completely unique and tied directly to your computer. Since this can be used to track you, you should either use IPv6 privacy extensions or disable IPv6 entirely. As to not lose the benefits of IPv6 you could use privacy extensions rather than disabling it. Privacy extensions generate a random IPv6 address out of your original one to prevent you from being tracked by it.

To enable these create /etc/sysctl/ipv6_privacy.conf and add

"net.ipv6.conf.all.use_tempaddr = 2
net.ipv6.conf.default.use_tempaddr = 2
net.ipv6.conf.eth0.use_tempaddr = 2
net.ipv6.conf.wlan0.use_tempaddr = 2"

Replace "eth0" and "wlan0" with your network interfaces. You can find these by running

"ip a"

21.1 NetworkManager

NetworkManager does not use these settings and still uses your original IPv6 address. To enable privacy extensions for NetworkManager add these lines to /etc/NetworkManager/NetworkManager.conf

"[connection]
ipv6.ip6-privacy=2"

21.2 systemd-networkd

systemd-networkd also does not use these settings and will still use your original IPv6 address. To enable privacy extensiosn for systemd-networkd create /etc/systemd/network/ipv6.conf and add

"[Network]
IPv6PrivacyExtensions=kernel"

22. Bootloaders

It is very important that you protect your bootloader. An attacker can easily be dropped into a root shell by using "init=/bin/sh" or "init=/bin/bash" as a kernel parameter at boot. This tells the kernel to run /bin/sh instead of your normal init system. With this an attacker has access to your whole system. You can prevent this by encrypting /boot or setting a password for your bootloader.

22.1 GRUB

To set a password for GRUB, run

"grub-mkpasswd-pbkdf2"

Enter your password and a string will be generated from that password. It will be like grub.pbkdf2.sha512.10000.*, where * can be anything. Edit /etc/grub.d/40_custom and add

"set superusers="username"
password_pbkdf2 username (password)"

Replace "(password)" with the string generated by "grub-mkpasswd-pbkdf2". The username will be for the superusers who are users that are permitted to use the GRUB command line, edit menu entries, and execute any menu entry. For most people you can just keep this as "root".

Regenerate your configuration file with

"grub-mkconfig /boot/grub/grub.cfg"

GRUB will now be password protected.

To restrict only editing the boot parameters and accessing the GRUB console while still allowing you to boot, edit /boot/grub/grub.cfg and next to "menuentry 'OS Name'" add "--unrestricted" e.g.

"menuentry 'Arch Linux' --unrestricted"

You will need to regenerate your configuration file again.

GRUB also has support for encrypting /boot.

22.2 Syslinux

Syslinux can either set a master password or a menu password. A master password is required while booting any entry while a menu password is only required while booting a specified entry.

To set a master password for Syslinux, edit /boot/syslinux/syslinux.cfg and add

"MENU MASTER PASSWD (password)"

Replace "(password)" with the password you want to set.

To set a menu password, edit /boot/syslinux/syslinux.cfg and within a label that has the item you want to password protect, add

"MENU PASSWD (password)"

Replace "(password)" with the password you want to set.

These passwords can either be plaintext or hashed with MD5, SHA-1, SHA-2-256 or SHA-2-512.

Syslinux does not have support for encrypting /boot.

22.3 systemd-boot

systemd-boot has the option to prevent editing the kernel parameters at boot. In the loader.conf file add

"editor no"

This will disabling editing the boot parameters.

systemd-boot does not officially support password protecting the kernel parameters editor but you can do it with systemd-boot-password from the AUR. To install this run

"sbpctl install (esp)"

Replace "(esp)" with your esp directory. The editor needs to be enabled in loader.conf to be prompted for a password.

23. PAM

PAM is a framework for system-wide user authentication. It is what you use when you login. You can make it more secure by requiring strong passwords, locking out users etc.

To enforce strong passwords you can use pam_cracklib. It enforces a configurable policy for passwords throughout the system. If you want passwords to require 10 characters minimum (minlen), at least 6 different characters from the old password (difok), at least 1 digit (dcredit), at least 1 uppercase (ucredit), at least 1 other character (ocredit) and at least 1 lowercase (lcredit) then edit /etc/pam.d/passwd and add

"password required pam_cracklib.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1
password required pam_unix.so use_authtok sha512 shadow"

This can be changed to whatever you want.

To add a delay of at least 4 seconds between failed login attempts edit /etc/pam.d/system-login and add

"auth optional pam_faildelay.so delay=4000000"

4000000 is 4 seconds in microseconds.

To lockout user after three failed login attempts edit /etc/pam.d/system-login and add

"auth required pam_tally2.so deny=3 unlock_time=600 onerr=succeed file=/var/log/tallylog"

24. Blacklist Uncommon Network Protocols

There are a few network protocols that are very rarely used and may have unknown security vulnerabilites in them. Some of them have also have had bad security holes before so it would be best to blacklist these incase there are more. Create /etc/modprobe.d/uncommon-network-protocols.conf and add

"install dccp /bin/true
install sctp /bin/true
install rds /bin/true
install tipc /bin/true
install n-hdlc /bin/true
install ax25 /bin/true
install netrom /bin/true
install x25 /bin/true
install rose /bin/true
install decnet /bin/true
install econet /bin/true
install af_802154 /bin/true
install ipx /bin/true
install appletalk /bin/true
install psnap /bin/true
install p8023 /bin/true
install llc /bin/true
install p8022 /bin/true"

This will blacklist:

DCCP
SCTP
RDS
TIPC
HDLC
AX25
NetRom
X25
ROSE
DECnet
Econet
af_802154
IPX
AppleTalk
PSNAP
p8023
LLC
p8022

"install" tells modprobe to run a command instead of loading the module as normal. /bin/true is a command that returns 0 which will do nothing. Both of these together tells the kernel to run /bin/true instead of loading the module which will prevent the module from being loaded.

25. Partitioning and Mount Options

You should separate file systems into various partitions so you will have more fine grained control over their permissions and will add an extra layer of security. You can add different mount options to restrict what can happen on a file system. The main ones are:

nodev - Do not interpret character or block special devices on the file system.
nosuid - Do not allow setuid or setgid bits to take effect.
noexec - Do not allow direct execution of any binaries on the mounted file system.

You should put these mount options wherever possible. Nodev can be put everywhere except / and chroot partitions. Noexec can be put anywhere that doesn't execute binaries inside it.

You can do this in /etc/fstab.

An example of a /etc/fstab file:

/ / ext4 defaults 1 1
/tmp /tmp ext4 defaults,nosuid,noexec,nodev 1 2
/home /home ext4 defaults,nosuid,nodev 1 2
/var /var ext4 defaults,nosuid 1 2
/boot /boot ext4 defaults,nosuid,noexec,nodev 1 2
/tmp /var/tmp ext4 defaults,bind,nosuid,noexec,nodev 1 2

26. Disable Mounting of Uncommon Filesystems

There are a few uncommon filesystems that are very rarely used. These don't serve any purpose for most people and it would be best to disable mounting these to reduce your system's attack surface. Create /etc/modprobe.d/uncommon-filesystems.conf and add

"install cramfs /bin/true
install freevxfs /bin/true
install jffs2 /bin/true
install hfs /bin/true
install hfsplus /bin/true
install squashfs /bin/true
install udf /bin/true"

This tells the kernel to run /bin/true instead of loading the module for those filesystems. This disables cramfs, freevxfs, jffs2, hfs, hfsplus, squashfs and udf. You should make sure that these filesystems aren't being used anywhere before doing this.

27. Editing Files as Root

It is unrecommended to run ordinary text editors as root. This is because many text editors can do more than edit text files and this can be exploited. For example, open vi as root by running

"sudo vi"

Now enter ":sh". You now have a root shell with access to your entire system. This is dangerous as an attacker can easily exploit this.

A solution to this, is using sudoedit. This copies the file to a temporary location, opens the text editor as an ordinary user, edits the temporary file and overwrites the original file as root. This way, the actual editor doesn't run as root. To use sudoedit, run

"sudoedit /path/to/file"

By default, it uses vi but the default editor can be changed using the EDITOR or SUDO_EDITOR environment variable. For example, to use sudoedit with nano, run

"EDITOR=nano sudoedit /path/to/file"

This environment variable can be set globally in /etc/environment.

28. Entropy

Entropy is the randomness collected by an operating system. Entropy is crucial for things such as encryption so it is best to gather as much entropy as possible.

28.1 Haveged

Haveged is a random number generator that gathers more entropy. To install it, run

"sudo pacman -S haveged"

Enable it by running

"sudo systemctl enable --now haveged.service"

28.2 Jitterentropy

Jitterentropy is another random number generator. To install it, run

"sudo pacman -S jitterentropy"

29. Microphones and Webcams

Malware can take over microphones and webcams which can then be used to spy on you by recording a video of you or recording what you say. Because of this, it is recommended to remove any microphones or webcams. It is best to physically remove them but you can also blacklist the kernel modules for them. Speakers can also be turned into a microphone to spy on you.

To blacklist the webcam kernel module, create /etc/modprobe.d/blacklist-webcam.conf and add

"install uvcvideo /bin/true"

The kernel module for the microphone is the same as the one for the speaker. This means disabling the microphone in this method will also disable any speakers. To find the name of the module, look in /proc/asound/modules. Create /etc/modprobe.d/blacklist-mic.conf and add

"install (module) /bin/true"

Replace "(module)" with whatever you found in /proc/asound/modules. For example, if you found "snd_hda_intel", you would add

"install snd_hda_intel /bin/true"

You should also disable the webcam and microphone in your BIOS if possible.

30. Best Practices

Now you will have a secure system and there isn't really much more you can do. You should follow good privacy/security practices:

1. Disable/remove things you don't need.
2. Use strong passwords.
3. Stay updated. Configure a cron job to update your system daily.
4. Don't leak any information about you or your system.