Discopter Pi Guide

Chapter 6: Further Lock Down the Pi and Conduct a Security Audit

This chapter contains optional security enhancements. These are considered optional as they are either not strictly necessary, not applicable to all users, sometimes redundant, potentially inflicting of large accessibility penalties, or considered by some to be counterproductive. Your mileage may vary on some or all of these options. Skipping all of them will still leave you with an extremely well secured Pi.

Option: Display Banners

Security banners do nothing to actually prevent unauthorized access. What they do is act as a “No Trespassing” sign. It doesn't stop illegal activity but anyone wandering into the system cannot claim ignorance that what they are doing is not allowed. There is an argument that it makes your system a more appealing target, so consider whether you want to implement them or not.

+----------------------------------------------------+
| This is a controlled access system. The activities |
| on this system are monitored.                      |
| Evidence of unauthorized activities may be         |
| disclosed to the appropriate authorities.          |
+----------------------------------------------------+

You are logged in as $USER. Your IP address and host information have been logged.
If you are not authorized access, log off immediately.

Option: Enforce Passwords with sudo

Many security professionals will say that allowing sudo commands without a password is a serious security violation. Generally, they are coming from their perspective of a more visible or professional use of Linux. For a home setup, the benefits of enforcing passwords on sudo commands may not justify the loss of convenience, but for those serious about locking down their Pi, it may be worth considering.

1. Open the pi-nopasswd file for editing as root.
   sudo nano /etc/sudoers.d/010-pi-nopasswd
2. Remove all instances of NOPASSWD in the file.

Option: Disable Root Login

This is a common security measure taken by Linux administrators. It disables the root account for SSH sessions. You can still use sudo commands, but the only way to login in as root is physically on the device itself. In a professional setting, this could make sense. After all other lockdown procedures though, the greatest risk to our Pi is now physical access, so for a hobbyist, this doesn't provide as much security as it would in an office or enterprise setting. That being said, if you can easily hook your Pi up to a display with an HMDI cord when needed, it can't hurt to disable root login over SSH.

1. Open the sshd_config file for edits.
   sudo nano sshd_config
2. Find the line that says #PermitRootLogin yes
3. Remove the # symbol to uncomment the line and change yes to no. Should be:
   PermitRootLogin no

Option: Remove Non-Secure Services

The services listed below either allow unauthenticated connections or send passwords in clear text over a network. Only older versions of Raspberry Pi OS still have them, so chances are you can skip this. If you have any other Linux workstations though, it may be worth seeing if you can remove them from there.

1. Remove the following packages with sudo apt remove :
   ypserv
rsh-server
vsftpd*
telnet-server
tftp-server

Option: Disable Wi-Fi and Bluetooth

The best and most secure option is to directly plug a Pi into a router with an ethernet cable. The speeds will be faster and it is one less radio you have to worry about. Same with Bluetooth. Unless you know you need it, you might as well turn it off. This is considered optional as many users may legitimately need to connect over Wi-Fi. With all of the network defenses already put in place, unauthorized physical access to the Pi is the greater security threat. If putting the Pi in a more controlled physical location means not being able to plug into a router, then Wi-Fi should remain turned on. But for most users, considering the Pi part of their normal home internet setup along with a router and modem means they will all be collocated with little reason to use Wi-Fi.

1. Use rfkill to disable Wi-Fi and Bluetooth.
   sudo rfkill block wifi
sudo rfkill block Bluetooth
2. Change block to unblock to reverse.

Option: Disable Device Automounting

Our Raspberry Pis are going to be very secure from a networking perspective. The biggest vulnerability is physical access. A hacker remotely getting in without your user credentials, after all of the security steps we've taken, is next to impossible. Physically connecting a USB drive and copying the contents of your Pi is still possible. You can disable automounting to help prevent this. The downside is you'll have to manually mount any devices attached to the Pi. Some consider this an upside as it give you more control over the mount point. If you intend on just setting the Pi next to your router and not plugging much into it, there's not much of a downside. This is also more of a Linux-in-general thing, as automounting is usually disabled by default in most Pis.

1. Disable automounting of devices:
   sudo systemctl stop autofs
sudo systemctl disable autofs
2. To mount a device manually, you first identify the device.
   lsblk
   

   You might see a lot of “loop” entries, but you're looking for something like /dev/sda or /dev/sdb. It can often be helpful to run lsblk before plugging in a device and then again after plugging it in to easily see the device that's been added.

3. You can then create a custom mount point. Traditionally, this is done in the /media directory, but it does not have to be. The below is an example using this directory for an external hard drive used to make backups.
   sudo mkdir /media/external_backups
4. Mount the device identified with lsblk to the mount point you created.
   sudo mount /dev/sda /media/external_backups
   

   Replace the device and mount point as needed.

5. Unmount with sudo umount /dev/sda.

Option: Restrict New File Permissions

By default, new files are usually created with permissions of 644. This allows group members and unaffiliated users to read files, but not modify or execute them. A more secure setup is to change the default so at the very least unaffiliated users cannot read a file. An added bonus is if you try to edit root-owned files without sudo, you won't type all of your modifications only to be told that you can't save them. Permissions of 644 are set by the umask filter of 022, which subtracts those values from the initial value of 666. By changing to 077, you will ensure that only a file owner can access the file. The downside is that other applications run by service accounts may no longer function as they may depend on reading files or group membership. Setting umask to 027 is perhaps a good compromise, allowing group member accounts to still read a file while locking out unaffiliated users. Still, be ready to add affected service accounts to groups to allow access, or take note of files that may need more liberal access policies and change them with the chmod command as needed.

1. Open the login.defs file for modification.
   sudo nano /etc/login.defs
2. Look for the line UMASK 022 and change it to UMASK 077 to lock out all non-file owners, or UMASK 027 to allow for group members to still read file contents.
3. Save and exit the file.
4. That unfortunately will only cover auto-created files unless we disable groups, which we don't want to do. Instead, we'll create a script to run on startup that will change the UMASK setting. Create the following file:
   sudo nano /etc/profile.d/umask_set.share
5. Type the below, replacing 027 with 077 if you'd like to lock down your system even more.
   umask 027
6. The script just calls that command. You can also just type that directly into a terminal session. It will only be in effect for that session though without the script.

Option: Install Security Auditing Software

Lynis is an example of an application that performs adaptive scans of your system looking for vulnerabilities. It's free, runs on a host machine, and provides granular control over system security rather than an automated approach that could break your system. It's designed for UNIX-like systems, which includes Raspberry Pi OS. Other similar options include Bastille, OpenVAS, and Nessus. Running Lynis will give you a detailed report of potential weaknesses in your security. Many of these potential vulnerabilities are more applicable to a SOHO setting, but still worth at least noting.

1. Download and install Lynis.
   sudo apt install lynis
2. Conduct a Lynis security audit.
   lynis audit system --quick
3. There are many other flags and options for Lynis. Check out its man page for more ways in how to use it. If you see a vulnerability that you'd like to patch, researching how to fix it can become a good exercise for learning more about Linux in general. Just be aware that some “fixes” can wind up breaking your system. It is not required to patch every vulnerability identified by Lynis.