Description: It is recommended to apply the configuration recommendations for Hardware support mentioned in ANSSI DAT-24.
Levels:Automated: yes
Selections:Description: It is recommended to apply the configuration recommendations for BIOS/UEFI mentioned in ANSSI DAT-24.
Levels:Automated: no
No rules selected
Description: It is recommended to apply UEFI Secure Boot configuration of the distribution.
Levels:Automated: no
No rules selected
Description: It is recommended to replace the UEFI preloaded keys with new keys used to sign; the bootloader and Linux kernel, or; the image of the Linux kernel in EFI format.
Levels:Automated: no
No rules selected
Description: A password protecting the boot loader must exist. This password must prevent any user from changing their configuration options.
Levels:Automated: yes
Selections:Description: It is recommended that UEFI Secure Boot is used to protect the Linux Kernel command line parameters during boot.
Levels:Automated: no
No rules selected
Description: The iommu = force directive must be added to the list of kernel parameters during startup in addition to those already present in the configuration files of the bootloader (/boot/grub/menu.lst or /etc/default/grub).
Levels:Automated: yes
Selections:Description: None
Levels:Automated: yes
Selections:Description: None
Levels:Automated: yes
Selections:Description: The loading of the kernel modules can be blocked by the activation of the sysctl kernel.modules_disabled: Prohibition of loading modules (except those already loaded to this point) kernel.modules_disabled = 1
Levels:Automated: yes
Selections:Description: It is recommended to load the Yama security module at startup (by example passing the security = yama argument to the kernel) and configure the sysctl kernel.yama.ptrace_scope to a value of at least 1.
Levels:Automated: yes
Selections:Description: None
Levels:Automated: yes
Selections:Description: None
Levels:Automated: yes
Selections:Description: None
Levels:Automated: yes
Selections:Description: None
Levels:Automated: yes
Selections:Description: None
Levels:Automated: yes
Selections:Description: None
Levels:Automated: yes
Selections:Description: None
Levels:Automated: yes
Selections:Description: None
Levels:Automated: yes
Selections:Description: None
Levels:Automated: yes
Selections:Description: None
Levels:Automated: yes
Selections:Description: None
Levels:Automated: yes
Selections:Description: None
Levels:Automated: yes
Selections:Description: None
Levels:Automated: no
No rules selected
Description: None
Levels:Automated: yes
Selections:Description: None
Levels:Automated: no
No rules selected
Description: None
Levels:Automated: yes
Selections:Description: None
Levels:Automated: yes
Selections:Description: When possible, it is recommended not to automatically mount the /boot partition. In any case, access to the /boot folder should only be allowed for the root user.
Levels:Automated: yes
Selections:Description: Unused user accounts must be deleted from the system.
Levels:Automated: no
No rules selected
Description: None
Levels:Automated: yes
Selections:Description: Local user sessions (console TTY, graphical session) must be locked after a certain period of inactivity.
Levels:Automated: yes
Selections:Description: None
Levels:Automated: yes
Selections:Description: None
Levels:Automated: no
No rules selected
Description: Each service must have its own system account and be dedicated to it exclusively.
Levels:Automated: no
No rules selected
Description: The default value of UMASK for the shells must be set to 0077 in order to allow read and write access to its owner only. This value can be defined in the configuration file /etc/profile that most shells (bash, dash, ksh…) will use. The default value of UMASK for services must be determined for each service, but in most cases, it should be set to 0027 (or more restrictive). This allows read access to its owner and its group, and a full access to its owner. For services such as systemd, this value can be defined directly in the configuration file of the service with the directive UMask=0027.
Levels:Automated: yes
Selections:Description: It is recommended to use the mandatory access control (MAC) features in addition to the traditional Unix user model (DAC), or possibly combine them with partitioning mechanisms.
Levels:Automated: yes
Selections:Description: A group dedicated to the use of sudo must be created, and only members of this group are allowed to execute sudo.
Levels:Automated: yes
Selections:Description: None
Levels:Automated: yes
Selections:Description: The targeted users of a rule should be, as much as possible, non privileged users.
Levels:Automated: yes
Selections:Description: The commands requiring the execution of sub-processes (EXEC tag) must be explicitly listed and their use should be reduced to a strict minimum.
Levels:Automated: no
No rules selected
Description: The sudoers configuration rules should not involve negation.
Levels:Automated: yes
Selections:Description: None
Levels:Automated: yes
Selections:Description: A file requiring sudo to be edited, must be edited through the sudoedit command.
Levels:Automated: no
No rules selected
Description: All AppArmor security profiles on the system must be enabled by default.
Levels:Automated: no
No rules selected
Description: It is recommended to enable the targeted policy when the distribution supports it and that it does not operate another security module than SELinux.
Levels:Automated: yes
Selections:Description: Interactive non-privileged users of a system must be confined by associating them with a SELinux confined user.
Levels:Automated: no
No rules selected
Description: It is recommended to set the following Booleans: allow_execheap to off, forbids processes to make their heap executable; allow_execmem to off, forbids processes to have both write and execute rights on memory pages; allow_execstack to off, forbids processes to make their stack executable; secure_mode_insmod to on, prohibits dynamic loading of modules by any process; ssh_sysadm_login to off, forbids SSH logins to connect directly in sysadmin role.
Levels:Automated: yes
Selections:Description: SELinux policy manipulation and debugging tools should not be installed on a machine in production.
Levels:Automated: yes
Selections:Description: None
Levels:Automated: yes
Selections:Description: All sensitive files and those contributing to the authentication mechanisms must be set up as soon as the system is installed. If default secrets are preconfigured, they must be replaced during, or immediately after, the installation phase of the system.
Levels:Automated: no
No rules selected
Description: None
Levels:Automated: no
No rules selected
Description: None
Levels:Automated: yes
Selections:Description: None
Levels:Automated: yes
Selections:Description: Each user or service account must have its own temporary directory and dispose of it exclusively.
Levels:Automated: yes
Selections:Description: None
Levels:Automated: yes
Selections:Description: The executables with setuid executables root and setgid root special rights should be as few as possible. When only administrators are expected to execute them, these special rights should be removed and prefer them commands like su or sudo, which can be monitored
Levels:Automated: no
No rules selected
Description: The selection of packages installed should be as small as possible, limiting itself to select only what is required.
Levels:Automated: no
No rules selected
Description: Only up-to-date official repositories of the distribution must be used.
Levels:Automated: yes
Selections:Description: When the distribution provides several types of repositories, preference should be given to those containing packages subject to additional hardening measures. Between two packages providing the same service, those subject to hardening (at compilation, installation, or default configuration) must be preferred.
Levels:Automated: no
No rules selected
Description: None
Levels:Automated: yes
Selections:Description: Only the components strictly necessary to the service provided by the system should be installed. Those whose presence can not be justified should be disabled, removed or deleted.
Levels:Automated: no
Selections:Description: Services are often installed with default configurations that enable features potentially problematic from a security point of view. The features configured at the level of launched services should be limited to the strict minimum.
Levels:Automated: no
No rules selected
Description: The deployed services must have their access restricted to the system strict minimum, especially when it comes to files, processes or network.
Levels:Automated: yes
Selections:Description: None
Levels:Automated: no
No rules selected
Description: Each component supporting the virtualization must be hardened, especially by applying technical measures to counter the exploit attempts.
Levels:Automated: no
No rules selected
Description: When authentication takes place through a remote application (network), the authentication protocol used by PAM must be secure (flow encryption, remote server authentication, anti-replay mechanisms, ...).
Levels:Automated: yes
Selections:Description: Any password must be protected by cryptographic mechanisms.
Levels:Automated: no
Selections:Description: When the user databases are stored on a remote network service, NSS must be configured to establish a secure link that allows, at minimum, to authenticate the server and protect the communication channel.
Levels:Automated: yes
No rules selected
Description: None
Levels:Automated: no
No rules selected
Description: The configuration of the service must be performed according to the 'Security Recommendations for the architecture of a logging system' (DAT-PA-012 v2.0) accessible on the ANSSI website (https://www.ssi.gouv.fr/journalisation).
Levels:Automated: yes
Selections:Description: Each service must have a dedicated event logging journal on the system. This log must only be accessible by the syslog server, and must not be readable, editable or deletable by the service directly.
Levels:Automated: no
No rules selected
Description: The logging of the system activity must be done through the auditd service.
Levels:Automated: yes
Selections:Description: None
Levels:Automated: yes
Selections:Description: None
Levels:Automated: yes
Selections:Description: Any file that is not transient (such as temporary files, databases, etc.) must be monitored by a sealing program. This includes: directories containing executables, libraries, configuration files, as well as any files that may contain sensitive elements (cryptographic keys, passwords, confidential data).
Levels:Automated: yes
Selections:Description: The sealing database must be protected from malicious access by cryptographic signature mechanisms (with the key used for the signature not locally stored in clear), or possibly stored on a separate machine of the one on which the sealing is done. Check section "Database and config signing in AIDE manual" https://aide.github.io/doc/#signing
Levels:Automated: no
No rules selected
Description: Network services should as much as possible be hosted on isolated environments. This avoids having other potentially affected services if one of them gets compromised under the same environment.
Levels:Automated: no
No rules selected
Description: None
Levels:Automated: no
Selections:Description: All network services must be listening on the correct network intefaces.
Levels:Automated: no
No rules selected