Configuration

Introduction This is a hardening profile to help securing nginx by using systemd unit configuration. It’s goal is to restrict what nginx can do and make it harder for any possible vulnerability to be misused. The rationale for the selected settings is based on the analysis as part of the article Hardening nginx with systemd security features.

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 SystemCallFilter The setting SystemCallFilter aims to prevent misuse of syscalls that are not needed for normal functioning of a process. This powerful filtering restricts the abilities of a process, but requires understanding of processes by the system administrator. See the overview of Linux syscalls for more details. Configuration This setting takes a space-separated list and may be specified multiple times. Allow-listing By default the list contains the entries of allowed system call names.

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 ProcSubset The setting ProcSubset controls the “subset” mount option of /proc for the unit. Caveats This function does not if the “subnet” option for procfs is not supported. Generic advice The Linux kernel shares information from various kernel APIs via /proc. When activating this setting, these kernel APIs are also made unavailable, which might break common software, unless it is a trivial process. So this option is to be used with care.

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.

Why and when to use ProtectHome The setting ProtectHome aims to protect home directories. These three paths are included: /home /root /run/user Settings The default no will not restrict access to the home directories. Using yes will active full protection, not allowing access. The value read-only will make the paths read-only, so no data can be written to it. With tmpfs a temporary file system is being used, also read-only, yet it hides the actual home directories.

Background The Linux kernel exposes its kernel log ring buffer to userspace via /dev/kmsg and /proc/kmsg. When this setting is defined as yes, the capability CAP_SYS_MODULE will be removed from the capability bounding set. This means that all processes in the unit will no longer have access to the kernel log ring buffer. Generic advice For most common services access to the kernel log ring buffer is not need, therefore safe to disable (ProtectKernelLogs=yes).

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.

The file /etc/ssh/ssh_config is the main configuration file of the OpenSSH server daemon (sshd). Purpose It defines the system-wide settings for the SSH client. It can be overriden by storing settings in ~/.ssh/config that takes precedence. Configuration To learn more about the available configuration settings, have a look at the section OpenSSH client configuration.

The file /etc/ssh/sshd_config is the main configuration file of the OpenSSH server daemon (sshd). Purpose It defines the primary set of settings, with the option of being overridden by configuration files from /etc/ssh/sshd_config.d/*.conf. Configuration To learn more about the available configuration settings, have a look at the section OpenSSH server configuration.