Service Hardening

Why and when to use SocketBindAllow The setting SocketBindAllow is used together with SocketBindDeny and defines restrictions on the usage of the system call bind on a network socket. Settings Both SocketBindAllow and SocketBindDeny use a bind-rule. See SocketBindDeny for the details. Generic advice This setting is useful in combination with SocketBindDeny to create an allow-list. Examples Allow binding on TCP port 80 [Service] SocketBindDeny=any SocketBindAllow=tcp:80 Allow binding on port 443 (IPv4/IPv6, TCP/UDP)

Why and when to use SocketBindDeny The setting SocketBindDeny can be used alone or together with SocketBindAllow to set restrictions on the usage of the system call bind on a network socket. Settings If the SocketBindDeny list is used alone, then it is a deny-list. Everything except the defined ports/protocols will be allowed. By defining the value ‘any’, all combinations are denied. This is typically used in combination with SocketBindAllow to open up one or more ports.

Why and when to use DevicePolicy The setting DevicePolicy aims to reduce access to devices in /dev. By default, there is no limitation to access devices. Settings The value strict is the most strict, as the name implies. This is suitable for services that do not need any access, like custom shell scripts. Unless output is being redirect to /dev/null, then access could be granted with DeviceAllow=/dev/null. Generic advice Aim for using ‘strict’ when possible and define entries that should be allowed.

Why and when to use DeviceAllow The setting DeviceAllow aims to reduce access or its level to devices in /dev. By default, there is no limitation to access devices. Settings Define DeviceAllow with the path and access level. DeviceAllow=/dev/sda3 r General advice For most services it might be easier to use ProtectDevices=yes to reduce the devices that can be access.

Why and when to use MemoryDenyWriteExecute The setting MemoryDenyWriteExecute will block the creation or alteration of a memory segment to become writable and executable as well. By enabling this limitation, it will increase the bar software exploits to change running code dynamically. Usage [Service] MemoryDenyWriteExecute=yes InaccessiblePaths=/dev/shm SystemCallFilter=~memfd_create Caveats To prevent circumvention of this setting, access to /dev/shm and the syscall memfd_create should be blocked as well. Generic advice For most common services this option can be implemented and will increase the security of a service.

Why and when to use InaccessiblePaths The setting InaccessiblePaths defines paths that should never be accessible. Instead of using the principles of an allow list, it is an explicit deny list. It can be used to block access by a process to a location with sensitive data or a path commonly misused for exploits. Values Define the paths that are granted write access. [Service] InaccessiblePaths=/dev/shm When a path is prefixed with a minus (-), it is ignored if it does not exist When a path is prefixed with a plus (+), the path is considered relative to root of directory (e.

Why and when to use ReadWritePaths The setting ReadWritePaths grants read and write permissions to defined paths. It can be used in combination with other settings like ‘ProtectSystem=strict’ to make the full file system read-only, and then open up a few paths that are required for a service to run correctly. Values Define the paths that are granted write access. [Service] ProtectSystem=strict ReadWritePaths=/run /var/log/nginx When a path is prefixed with a minus (-), it is ignored if it does not exist When a path is prefixed with a plus (+), the path is considered relative to root of directory (e.

Why and when to use RestrictAddressFamilies The setting RestrictAddressFamilies aims to restrict what socket address families can be used. When using it, the default is that it is used as an allow-list and define what address families can be used. Settings When this setting is not configured, there are no restrictions to what address families can be used. Setting the value to none will block all address families. To block specific address families only, a ~ can be used to turn the allow-list into a deny-list.

Why and when to use ProtectProc The setting ProtectProc aims to protect information that normally can be retrieved from /proc. Settings The value default, which is also the default, will not restrict access. Value invisible will hide information, where ptraceable restrict the set to only processes that be monitored with the system call ptrace(). The value noaccess is the most strict option. Caveats This setting will not have effect if the kernel does not support the hidepid mount option per individual mount point.

Explanation Kernel modules can provide additional functionality when using a modular Linux kernel, which is applicable to most systems. When this setting is set to yes, it tries to prevent the unit from loading kernel modules. This is achieved by removing the CAP_SYS_MODULE from the capability bounding set. Generic advice Most units do not need the permission to load kernel modules, so typically a unit can be configured with ProtectKernelModules=true.