anssi_sle.yml

policy: 'ANSSI-BP-028'
title: 'Configuration Recommendations of a GNU/Linux System'
id: anssi_sle
version: '1.2'
source: https://www.ssi.gouv.fr/uploads/2019/03/linux_configuration-en-v1.2.pdf
levels:
  - id: minimal
  - id: intermediary
    inherits_from:
    - minimal
  - id: enhanced
    inherits_from:
    - intermediary
  - id: high
    inherits_from:
    - enhanced

controls:
  - id: R1
    levels:
    - minimal
    title: Minimization of installed services
    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.
    status: partial  # The list of essential services is not objective.
    notes: >-
      Performing a minimal install is a good starting point, but doesn't provide any assurance
      over any package installed later.
      Manual review is required to assess if the installed services are minimal.
      In general, use of obsolete or insecure services is not recommended and we remove some
      of these in this recommendation.
    rules:
    - package_dhcp_removed
    - package_rsh_removed
    - package_rsh-server_removed
    - package_sendmail_removed
    - package_talk_removed
    - package_talk-server_removed
    - package_telnet_removed
    - package_telnet-server_removed
    - package_tftp_removed
    - package_xinetd_removed
    - package_ypbind_removed
    - package_ypserv_removed

  - id: R2
    levels:
    - intermediary
    title: Minimization of configuration
    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.
    automated: no
    notes: >-
      Define a list of most problematic components or features to be hardened or restricted.

  - id: R3
    levels:
    - enhanced
    title: Principle of least privilege
    description: >-
      The services and executables available on the system must be analyzed in order to
      know the privileges they require, and must then be configured and integrated to use
      the bare necessities.
    status: partial # The system can be restricted even more with selinux-booleans or other technologies
    notes: >-
      SELinux policies limit the privileges of services and daemons to only what they require.
    # rules: TBD

  - id: R4
    levels:
    - high
    title: Using access control features
    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.
    notes: >-
      Other partitioning mechanisms can include chroot and containers and are not contemplated
      in this requirement.
    # rules: TBD

  - id: R5
    levels:
    - minimal
    title: Defense in-depth principle
    description: >-
      Under Unix and derivatives, defense in depth must be based on a combination of
      barriers that must be kept independent of each other.
    status: partial
    notes: >-
      Defense in-depth can be broadly divided into three areas - physical, technical and
      administrative. The security profile is best suited to protect the technical area.
      Among the barriers that can be implemented within the technical area are antivirus software,
      authentication, multi-factor authentication, encryption, logging, auditing, sandboxing,
      intrusion detection systems, firewalls and vulnerability scanners.
      The selection below is not in any way exaustive and should be adapted to the system's needs.
    rules:
    - sudo_remove_no_authenticate
    - package_rsyslog_installed
    - service_rsyslog_enabled
    related_rules:
    - package_audit_installed
    - service_auditd_enabled
    - package_ntp_installed
    - package_firewalld_installed
    - service_firewalld_enabled
    - sssd_enable_smartcards

  - id: R6
    levels:
    - enhanced
    title: Network services partitioning
    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.
    notes: >-
      Manual analysis is required to determine if services are hosted appropriately in
      separate or isolated system while maintaining functionality.
    automated: no

  - id: R7
    levels:
    - enhanced
    title: Logging of service activity
    description: >-
      The activities of the running system and services must be logged and
      archived on an external, non-local system.
    # rules: TBD

  - id: R8
    levels:
    - minimal
    title: Regular updates
    notes: Check the vendor CVE feed and configure automatic install of security related updates.
    status: automated
    rules:
    - security_patches_up_to_date
    - package_dnf-automatic_installed
    - timer_dnf-automatic_enabled
    # Configure dnf-automatic to Install Available Updates Automatically
    - dnf-automatic_apply_updates
    # Configure dnf-automatic to Install Only Security Updates
    - dnf-automatic_security_updates_only

  - id: R9
    levels:
    - intermediary
    title: Hardware configuration
    notes: >-
      Configurations recommended for this requirement are to be performed at the BIOS level.
      The content automation cannot really configure the BIOS, but can in some cases,
      check settings that are visible to the OS. Like for example the NX/DX setting.
    # rules: TBD

  - id: R10
    levels:
    - intermediary
    title: 32 and 64 bit architecture
    description: When the machine supports 64-bit operating systems, prefer it.
    notes: This requirement can be checked, but remediation requires manual reinstall of the OS.
    # rules: TBD

  - id: R11
    levels:
    - high
    title: IOMMU Configuration Guidelines
    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).
    # rules: TBD

  - id: R12
    levels:
    - intermediary
    title: Partitioning type
    # rules: TBD

  - id: R13
    levels:
    - enhanced
    title: Access Restrictions on the /boot directory
    description: >-
      When possible, the /boot partition should not be mounted. In any case, access to
      the /boot directory must only be allowed to the root user.
    notes: >-
      The rule disabling auto-mount for /boot is commented until the rules checking for other
      /boot mount options are updated to handle this usecase.
    #rules:
    #- mount_option_boot_noauto

  - id: R14
    levels:
    - intermediary
    title: Installation of packages reduced to the bare necessities
    description: >-
      The selection of packages installed should be as small as possible,
      limiting itself to select only what is required.
    notes: >-
      It is not possible to automatically decide in general way if a package is required or not for given system.
      As a future improvement, there could be rules assisting assessment by listing the installed packages.
    automated: no

  - id: R15
    levels:
    - minimal
    title: Choice of package repositories
    description: Only up-to-date official repositories of the distribution must be used.
    notes: >-
      It is not trivial to distinguish an official repository from an unofficial one.
      We cannot draw conclusions from the repo name or URL of the repo (as they can be arbitrary or behind a proxy).
      One approach to check the origin of installed packages is to check the signature of the packages.
      If the public key of a repository is not installed, the repo is not trusted.
    status: partial
    rules:
    - ensure_gpgcheck_never_disabled
    - ensure_gpgcheck_globally_activated
    - ensure_gpgcheck_local_packages
    - ensure_suse_gpgkey_installed

  - id: R16
    levels:
    - enhanced
    title: Hardened package repositories
    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.
    automated: no

  - id: R17
    levels:
    - enhanced
    title: Boot loader password
    description: >-
      A boot loader to protect the password boot must be to be privileged.
      This password must prevent any user from changing their configuration options.
    # rules: TBD

  - id: R18
    levels:
    - minimal
    title: Administrator password robustness
    notes: >-
      The rules selected below establish a general password strength baseline of 100 bits,
      inspired by DAT-NT-001 and the "Password Strenght Calculator"
      (https://www.ssi.gouv.fr/administration/precautions-elementaires/calculer-la-force-dun-mot-de-passe/).

      The baseline should be reviewed and tailored to the system's use case and needs.
    status: partial
    rules:
    # Renew passwords every 90 days
    - var_accounts_maximum_age_login_defs=90
    - accounts_maximum_age_login_defs

    # Ensure passwords with minimum of 18 characters
    - var_password_pam_minlen=18
    - accounts_password_pam_minlen
    # Enforce password lenght for new accounts
    - var_accounts_password_minlen_login_defs=18
    - accounts_password_minlen_login_defs
    # Require at Least 1 Special Character in Password
    - var_password_pam_ocredit=1
    - accounts_password_pam_ocredit
    # Require at Least 1 Numeric Character in Password
    - var_password_pam_dcredit=1
    - accounts_password_pam_dcredit
    # Require at Least 1 Uppercase Character in Password
    - var_password_pam_ucredit=1
    - accounts_password_pam_ucredit
    # Require at Least 1 Lowercase Character in Password
    - var_password_pam_lcredit=1
    - accounts_password_pam_lcredit

    # Lock out users after 3 failed authentication attempts within 15 min
    - var_accounts_passwords_pam_faillock_fail_interval=900
    - accounts_passwords_pam_faillock_interval
    - var_accounts_passwords_pam_faillock_deny=3
    - accounts_passwords_pam_faillock_deny
    - accounts_passwords_pam_faillock_deny_root
    # Automatically unlock users after 15 min to prevent DoS
    - var_accounts_passwords_pam_faillock_unlock_time=900
    - accounts_passwords_pam_faillock_unlock_time

    # Do not reuse last two passwords
    - var_password_pam_unix_remember=2
    - accounts_password_pam_unix_remember

  - id: R19
    levels:
    - intermediary
    title: Accountability of administration
    notes: >-
      By disabling direct root logins proper accountability is ensured.
      Users will first login, then escalate to privileged (root) access.
      Change of privilege operations must be based on executables to monitor the activities
      performed (for example sudo).
    # rules: TBD

  - id: R20
    levels:
    - enhanced
    title: Installation of secret or trusted elements
    description: >-
      All secret elements or those contributing to the authentication mechanisms
      must be set up as soon as the system is installed: account and administration
      passwords, root authority certificates, public keys, or certificates of the
      host (and their respective private key).
    notes: >-
      This concerns two aspects, the first is administrative, and involves prompt
      installation of secrets or trusted elements by the sysadmin.
      The second involves removal of any default secret or trusted element
      configured by the operating system during install process, e.g. default
      known passwords.
    automated: no

  - id: R21
    levels:
    - intermediary
    title: Hardening and monitoring of services subject to arbitrary flows
    notes: >-
      SELinux can provide confinement and monitoring of services, and AIDE provides
      basic integrity checking. System logs are configured as part of R43.
      Hardening of particular services should be done on a case by case basis and is
      not automated by this content.
    # rules: TBD

  - id: R22
    levels:
    - intermediary
    title: Setting up network sysctl
    # rules: TBD

  - id: R23
    levels:
    - intermediary
    title: Setting up system sysctl
    # rules: TBD

  
  - id: R24
    levels:
    - enhanced
    title: Disabling the loading of kernel modules
    description: >-
      The loading of the kernel modules can be blocked by the activation of the
      sysctl kernel.modules_disabledconf:
      Prohibition of loading modules (except those already loaded to this point)
      kernel.modules_disabled = 1
    # rules: TBD

  - id: R25
    levels:
    - enhanced
    title: Yama module sysctl configuration
    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.
    # rules: TBD

  - id: R26
    levels:
    - enhanced
    title: Disabling unused user accounts
    description: >-
      Unused user accounts must be disabled at the system level.
    notes: >-
      The definition of unused user accounts is broad. It can include accounts
      whose owners don't use the system anymore, or users created by services
      or applications that should not be used.
    automated: no

  - id: R27
    title: Disabling service accounts
    levels:
    - intermediary
    notes: >-
      It is difficult to generally identify the system's service accounts.
      UIDs of such accounts are generally between SYS_UID_MIN and SYS_UID_MAX, but their values
      are not enforced by the OS and can be changed over time.
      Assisting rules could list users which are not disabled for manual review.
    automated: no

  - id: R28
    levels:
    - enhanced
    title: Uniqueness and exclusivity of system service accounts
    description: >-
      Each service must have its own system account and be dedicated to it exclusively.
    notes: >-
      It is not trivial to identify whether a user account is a service account.
      UIDs of such accounts are generally between SYS_UID_MIN and SYS_UID_MAX, but their values
      are not enforced by the OS and can be changed over time.
    automated: no

  - id: R29
    levels:
    - enhanced
    title: User session timeout
    description: >-
      Remote user sessions (shell access, graphical clients) must be closed
      after a certain period of inactivity.
    notes: >-
      There is no specific capability to check remote user inactivity, but some shells allow the
      session inactivity time out to be configured via TMOUT variable.
      In OpenSSH < 8.2 the inactivity of the user is implied from the network inactivity.
      The server is configured to disconnect sessions if no data has been received within the idle timeout,
      regardless of liveness status (ClientAliveCountMax is 0 and ClientAliveInterval is > 0).
      In OpenSSH >= 8.2 there is no way to disconnect sessions based on client liveness.
      The semantics of "ClientAliveCountMax 0" has changed from "disconnect on first timeout" to
      "don't disconnect network inactive sessions". The server either probes for the client liveness
      or keeps inactive sessions connected.
    # rules: TBD

  - id: R30
    levels:
    - minimal
    title: Applications using PAM
    notes: >-
      Manual review is necessary to decide if the list of applications using PAM is minimal.
      Asssising rules could be created to list all applications using PAM for manual review.
    automated: no

  - id: R31
    title: Securing PAM Authentication Network Services
    levels:
    - intermediary
    # rules: TBD

  - id: R32
    levels:
    - minimal
    title: Protecting stored passwords
    description: Any password must be protected by cryptographic mechanisms.
    notes: >-
      The selection of rules doesn't cover the use of hardware devices to protect the passwords.
    status: automated
    rules:
    # ENCRYPT_METHOD, system default is SHA512
    - set_password_hashing_algorithm_systemauth
    # The default salt size is secure enough:
    # https://bugzilla.redhat.com/show_bug.cgi?id=1229472
    # SHA_CRYPT_MIN_ROUNDS 65536
    - var_password_pam_unix_rounds=65536
    - accounts_password_pam_unix_rounds_system_auth
    - accounts_password_pam_unix_rounds_password_auth

  - id: R33
    title: Securing access to remote user databases
    levels:
    - intermediary
    # rules: TBD

  - id: R34
    title: Separation of System Accounts and Directory Administrator
    levels:
    - intermediary
    # rules: TBD

  - id: R35
    levels:
    - enhanced
    title: umask value
    description: >-
      The system umask must be set to 0027 (by default, any created file can
      only be read by the user and his group, and be editable only by his owner).
      The umask for users must be set to 0077 (any file created by a user is
      readable and editable only by him).
    notes: >-
      There is no simple way to check and remediate different umask values for
      system and standard users reliably.
      The different values are set in a conditional clause in a shell script
      (e.g. /etc/profile or /etc/bashrc).
      The current implementation checks and fixes both umask to the same value.
    status: partial
    # rules: TBD

  - id: R36
    title: Rights to access sensitive content files
    levels:
    - intermediary
    status: automated
    rules:
    - file_owner_etc_shadow
    - file_permissions_etc_shadow
    - file_owner_etc_gshadow
    - file_permissions_etc_gshadow
    - file_permissions_etc_passwd
    - file_permissions_etc_group
    - file_permissions_sshd_private_key

  - id: R37
    levels:
    - minimal
    title: Executables with setuid and setgid bits
    notes: >-
      Only programs specifically designed to be used with setuid or setgid bits can have these privilege bits set.
      This requirement considers apropriate for setuid and setgid bits the binaries that are installed from
      recognized and authorized repositories (covered in R15).
      The remediation resets the sticky bit to intended value by vendor/developer, any finding after remediation
      should be reviewed.
    status: automated
    rules:
    - file_permissions_unauthorized_suid
    - file_permissions_unauthorized_sgid

  - id: R38
    levels:
    - enhanced
    title: Executable setuid root
    description: >-
      Setuid executables should be as small as possible. When it is expected
      that only the administrators of the machine execute them, the setuid bit
      must be removed and prefer them commands like su or sudo, which can be monitored
    # rules: TBD

  - id: R39
    levels:
    - intermediary
    title: Temporary directories dedicated to accounts
    description: >-
      Each user or service account must have its own temporary directory
      and dispose of it exclusively.
    notes: The approach of the selected rules is to use and configure pam_namespace module.
    # rules: TBD

  - id: R40
    levels:
    - intermediary
    title: Sticky bit and write access rights
    # rules: TBD

  - id: R41
    levels:
    - intermediary
    title: Securing access for named sockets and pipes
    # rules: TBD

  - id: R42
    levels:
    - minimal
    title: In memory services and daemons
    notes: >-
      Manual review is necessary to decide if the list of resident daemons is minimal.
      Asssising rules could be created to list sevices listening on the network for manual review.
    automated: no

  - id: R43
    title: Hardening and configuring the syslog
    levels:
    - intermediary
    description: >-
      The chosen syslog server must be hardened according to the security guides associated with this server.
      The configuration of the service must be performed according to the
      'Security Recommendations for the implementation of a logging system' (DAT-NT-012) accessible on the ANSSI website.
    notes: >-
      A lot of recommendations and requirements from the DAT-NT-012 document are administrative and hard to automate.
      The rules selected below address a few of the aspects that can be covered, keep in mind that these configurations should
      be customized for the systems deployment requirements.
    # rules: TBD

  - id: R44
    levels:
    - intermediary
    title: Partitioning the syslog service by chroot
    # rules: TBD

  - id: R45
    levels:
    - high
    title: Partitioning the syslog service by container
    description: >-
      The syslog services must be isolated from the rest of the system in a
      dedicated container.
    automated: no
    # rules: TBD

  - id: R46
    levels:
    - intermediary
    title: Service Activity Logs
    # rules: TBD

  - id: R47
    levels:
    - intermediary
    title: Dedicated partition for logs
    notes: This assumes that syslog stores its logs locally in "/var/log/audit".
    # rules: TBD

  - id: R48
    levels:
    - intermediary
    title: Configuring the local messaging service
    # rules: TBD

  - id: R49
    levels:
    - intermediary
    title: Messaging Aliases for Service Accounts
    status: partial # it is hard to define what are "service accounts"
    notes: >-
      Only the alias for root user is currently covered.
    # rules: TBD

  - id: R50
    levels:
    - enhanced
    title: Logging activity by auditd
    description: >-
      The logging of the system activity must be done through the auditd service.
    # rules: TBD

  - id: R51
    levels:
    - high
    title: Sealing and integrity of files
    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).
    status: automated
    # rules: TBD

  - id: R52
    levels:
    - high
    title: Protection of the seals database
    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
    automated: no

  - id: R53
    levels:
    - enhanced
    title: Restricting access of deployed services
    description: >-
      The deployed services must have their access restricted to the system
      strict minimum, especially when it comes to files, processes or network.
    notes: >-
      SELinux policies limit the privileges of services and daemons just to those which are required.
    # rules: TBD

  - id: R54
    levels:
    - enhanced
    title: Virtualization components hardening
    description: >-
      Each component supporting the virtualization must be hardened, especially
      by applying technical measures to counter the exploit attempts.
    notes: >-
      It may be interesting to point out virtualization components that are installed and
      should be hardened.
    automated: no

  - id: R55
    levels:
    - intermediary
    title: chroot jail and access right for partitioned service
    notes: >-
      Using automation to restrict access and chroot services is not generally reliable.
    automated: no

  - id: R56
    levels:
    - intermediary
    title: Enablement and usage of chroot by a service
    notes: >-
      Using automation to restrict access and chroot services is not generally reliable.
    automated: no

  - id: R57
    levels:
    - intermediary
    title: Group dedicated to the use of sudo
    description: >-
      A group dedicated to the use of sudo must be created, and only members of this
      group are allowed to execute sudo.
    notes: >-
      The rules below create and configure a group named sudogrp, to change the group customize the
      value of var_sudo_dedicated_group.
    # rules: TBD

  - id: R58
    levels:
    - intermediary
    title: Sudo configuration guidelines
    # rules: TBD

  - id: R59
    levels:
    - minimal
    title: User authentication running sudo
    description: >-
      The calling user must be authenticated before running any command with sudo.
    status: automated
    rules:
    - sudo_remove_nopasswd
    - sudo_remove_no_authenticate

  - id: R60
    levels:
    - intermediary
    title: Privileges of target sudo users
    description: The targeted users of a rule should be, as much as possible, non privileged users.
    # rules: TBD

  - id: R61
    levels:
    - enhanced
    title: Limiting the number of commands requiring the use of the EXEC option
    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.
    notes: >-
      Human review is required to assess if the set of commands requiring EXEC is minimal.
      An auxiliary rule could list rules containing EXEC tag, for analysis.
    automated: no

  - id: R62
    levels:
    - intermediary
    title: Good use of negation in a sudoers file
    description: The sudoers configuration rules should not involve negation.
    status: automated
    # rules: TBD

  - id: R63
    levels:
    - intermediary
    title: Explicit arguments in sudo specifications
    # rules: TBD

  - id: R64
    levels:
    - intermediary
    title: Good use of sudoedit
    description: A file requiring sudo to be edited, must be edited through the sudoedit command.
    notes: >-
      In R62 we established that the sudoers files should not use negations, thus the approach
      for this requirement is to ensure that sudoedit is the only text editor allowed.
      But it is difficult to ensure that allowed binaries aren't text editors without human
      review.
    automated: no

  - id: R65
    levels:
    - high
    title: Enable AppArmor security profiles
    description: >-
      All AppArmor security profiles on the system must be enabled by default.
    automated: no

  - id: R66
    levels:
    - high
    title: Enabling SELinux Targeted Policy
    description: >-
      It is recommended to enable the targeted policy when the distribution
      support it and that it does not operate another security module than SELinux.
    # rules: TBD

  - id: R67
    levels:
    - high
    title: Setting SELinux booleans
    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.
    notes:
      In RHEL, the SELinux boolean allow_execheap is renamed to selinuxuser_execheap, and the
      boolean allow_execstack is renamed to selinuxuser_execstack. And allow_execmem is not
      available, deny_execmem provides the same functionality.
    # rules: TBD

  - id: R68
    levels:
    - high
    title: Uninstalling SELinux Policy Debugging Tools
    description: >-
      SELinux policy manipulation and debugging tools should not be installed
      on a machine in production.
    # rules: TBD

  - id: R69
    levels:
    - high
    title: Confining interactive non-privileged users
    description: >-
      Interactive non-privileged users of a system must be confined by associating them with a SELinux confined user.
    notes: Interactive users who still need to perform administrative tasks should not be confined with user_u.
    automated: no