In a previous blog post, I wrote how to secure OpenSSH against brute force attacks. However, what if someone manages to get a shell on your system, despite all your efforts? You want to protect your system from your users doing nasty things? It is important to harden your system further according to the principle of defense in depth in order.
Software updates
Make sure you are running a supported distribution, and by preference the most recent version one. For example, Debian Jessie is still supported, however upgrading to Debian Stretch is strongly recommended, because it offers various security improvements (more recent kernel with new security hardening, PHP 7 with new security related features, etc…)
Install amd64-microcode (for AMD CPU’s) or intel-microcode (for Intel CPU’s) which are needed to protect against hardware vulnerabilities such as Spectre, Meltdown and L1TF. I recommend installing it from stretch-backports in order to have the latest firmware.
Automatic updates and needrestart
I recommend installing unattened-upgrades . You can configure it to just download updates or to download and install them automatically. By default, unattended-upgrades will only install updates from the official security repositories. This way it is relatively safe to let it do this automatically. If you have already installed it, you can run this command to reconfigure it:
# dpkg-reconfigure unattended-upgradesWhen you update system libraries, you should also restart all daemons which are using these libraries to make them use the newly installed version. This is exactly what needrestart does. After you have run apt-get, it will check whether there are any daemons running with older libraries, and will propose you to restart them. If you use it with unattended-upgrades, you should set this option in /etc/needrestart/needrestart.conf to make sure that all services which require a restart are indeed restarted:
$nrconf{restart} = 'a';Up-to-date kernel
Running an up-to-date kernel is very important, because also the kernel can be vulnerable. In the worst case, an outdated kernel can be exploited to gain root permissions. Do not forget to reboot after updating the kernel.
Every new kernel version also contains various extra security hardening measures. Kernel developer Kees Cook has an overview of security related changes in the kernel.
In case you build your own kernel, you can use kconfig-hardened-check to get recommendation for a hardened kernel configuration.null
Firewall: filtering outgoing traffic
It is very obvious to install a firewall which filters incoming traffic. However, have you considered also filtering outgoing traffic? This is a bit more difficult to set up because you need to whitelist all outgoing hosts to which connections are needed (I think of your distribution’s repositories, NTP servers, DNS servers,…), but it is a very effective measure which will help limiting damage in case a user account gets compromised, despite all your other protective efforts.
Ensuring strong passwords
Prevent your users from setting bad passwords by installing libpam-pwquality, together with some word lists for your language and a few common languages. These will be used for verifying that the user is not using a common word as his password. libpam-quality will be enabled automatically after installation with some default settings.
# apt-get install libpam-pwquality wbritish wamerican wfrench wngerman wdutchPlease note that by default, libpam-pwquality will only enforce strong passwords when a non-root user changes its password. If root is setting a password, it will give a warning if a weak password is set, but will still allow it. If you want to enforce it for root too (which I recommend), then add enforce_for_root in the pam_pwquality line in /etc/pam.d/common-password:
password requisite pam_pwquality.so retry=3 enforce_for_rootAutomatically log out inactive users
In order to log out inactive users, set a timeout of 600 seconds on the Bash shell. Create /etc/profile.d/tmout.sh:
export TMOUT=600
readonly TMOUTPrevent creating cron jobs
Make sure users cannot set cron jobs. In case an attacker gets a shell on your system, often cron will be used to ensure the malware continues running after a reboot. In order to prevent normal users to set up cron jobs, create an empty /etc/cron.allow.
Protect against fork bombs and excessive logins and CPU usage
Create a new file in /etc/security/limits.d to impose some limits to user sessions. I strongly recommend setting a value for nproc, in order to prevent fork bombs. maxlogins is the maximum number of logins per user, and cpu is used to set a limit on the CPU time a user can use (in minutes):
* hard nproc 1024
* hard maxlogins 4
1000: hard cpu 180Hiding processes from other users
By mounting the /proc filesystem with the hidepid=2 option, users cannot see the PIDs of processes by other users in /proc, and hence these processes also become invisible when using tools like top and ps. Put this in /etc/fstab to mount /proc by default with this option:
none /proc proc defaults,hidepid=2 0 0Restricting /proc/kallsyms
It is possible to restrict access to /proc/kallsyms at boot time by setting 004 permissions. Put this in /etc/rc.local:
chmod 400 /proc/kallsyms/proc/kallsyms contains information about how the kernel’s memory is laid out. With this information it becomes easier to attack the kernel itself, so hiding this information is always a good idea. It should be noted though that attackers can get this information from other sources too, such as from the System.map files in /boot.
Harden kernel configuration with sysctl
Several kernel settings can be set at run time using sysctl. To make these settinsg permanent, put these settings in files with the .conf extension in /etc/sysctl.d.
It is possible to hide the kernel messages (which can be read with the dmesg command) from other users than root by setting the sysctl kernel.dmesg_restrict to 1. On Debian Stretch and later this should already be the default value:
kernel.dmesg_restrict = 1From Linux kernel version 4.19 on it’s possible to disallow opening FIFOs or regular files not owned by the user in world writable sticky directories. This setting would have prevented vulnerabilities found in different user space programs the last couple of years. This protection is activated automatically if you use systemd version 241 or higher with Linux 4.19 or higher. If your kernel supports this feature but you are not using systemd 241, you can activate it yourself by setting the right sysctl settings:
fs.protected_regular = 1
fs.protected_fifos = 1Also check whether the following sysctl’s have the right value in order to enable protection hard links and symlinks. These work with Linux 3.6 and higher, and likely will already be enabled by default on your system:
fs.protected_hardlinks = 1
fs.protected_symlinks = 1Also by default on Debian Stretch only root users can access perf events:
kernel.perf_event_paranoid = 3Show kernel pointers in /proc as null for non-root users:
kernel.kptr_restrict = 1Disable the kexec system call, which allows you to boot a different kernel without going through the BIOS and boot loader:
kernel.kexec_load_disabled = 1Allow ptrace access (used by gdb and strace) for non-root users only to child processes. For example strace ls will still work, but strace -p 8659 will not work as non-root user:
kernel.yama.ptrace_scope = 1The Linux kernel includes eBPF, the extended Berkeley Packet Filter, which is a VM in which unprivileged users can load and run certain code in the kernel. If you are sure no users need to call bpf(), it can be disabled for non-root users:
kernel.unprivileged_bpf_disabled = 1In case the BPF Just-In-Time compiler is enabled (it is disabled by default, see sysctl net/core/bpf_jit_enable), it is possible to enable some extra hardening against certain vulnerabilities:
net.core.bpf_jit_harden = 2Take a look at the Kernel Self Protection Project Recommended settings page to find an up to date list of recommended settings.
Lynis
Finally I want to mention Lynis, a security auditing tool. It will check the configuration of your system, and make recommendations for further security hardening.
Further ideas
- Install AIDE, the Advanced Intrusion Detection Environment, which warns you when files are unexpectedly modified.
- Use pam_namespace to give every user a private /tmp and /var/tmp.
- Use John The Ripper to test whether passwords are safe.
- Harden your web server using ModSecurity and the OWASP Core Rule Set.
- Protect PHP applications with Snuffleupagus.
- Limit the impact of security exploits with AppArmor.
- Use OpenVAS to scan your system for security vulnerabilities.
- Enable login and process accounting to keep track of logged in users and the commands they are running.