This report maps an Artica appliance against the French ANSSI guide “Configuration recommendations of a GNU/Linux system” (ANSSI-BP-028, version 2.0), the reference used by French public bodies, operators of vital importance and their suppliers when they harden a Linux server.
It reflects the state of Artica in September 2026 and sorts every topic of the guide into four tables:
- Compliant out of the box — nothing to do.
- Compliant after an administrator action — the feature exists, you have to enable or configure it.
- Not compatible with the nature of an Artica appliance — a deviation you must document in your security concept.
- Planned or possible in a future version.
ANSSI-BP-028 grades each recommendation with a hardening level: Minimal, Intermediate, Enhanced and High.
The guide itself states that a server does not have to reach the highest level everywhere:
The expected level depends on the sensitivity of the system, and every recommendation that is not applied must be justified.
Table 3 gives you that justification for the points that an appliance cannot meet by design.
The report is organised by topic rather than by recommendation number, so that it stays valid across editions of the guide.
Use the “ANSSI topic” column to find the matching chapter.
Note: Artica ships a daily CIS Benchmark audit.
CIS and ANSSI overlap on kernel parameters and file permissions, but they are different references: a CIS score is not an ANSSI compliance statement.
These settings are applied by the appliance itself.
The generated configuration files are re-checked every 5 minutes to 4 hours and rewritten if they drift; a value changed live with sysctl -w is restored at the next reboot or configuration rebuild. Appliances installed before September 2026 receive the new kernel settings automatically within minutes after the update, without a reboot.
| ANSSI topic | What Artica enforces | Comment |
|---|---|---|
Kernel configuration (sysctl kernel.*) |
kernel.dmesg_restrict = 1kernel.kptr_restrict = 2kernel.randomize_va_space = 2kernel.sysrq = 0kernel.perf_event_paranoid ≥ 2kernel.unprivileged_bpf_disabled ≥ 1kernel.kexec_load_disabled = 1kernel.pid_max ≥ 65536 |
Values marked “≥” are minimums: when the Debian kernel is already stricter (for example perf_event_paranoid = 3,unprivileged_bpf_disabled = 2,pid_max = 4194304), the stricter value is kept.kexec_load_disabled can only be cleared by a reboot; Artica never uses kexec. |
| Yama security module | kernel.yama.ptrace_scope = 1 |
A process can only debug its own descendants. |
| File system configuration | fs.protected_hardlinks = 1fs.protected_symlinks = 1fs.protected_fifos = 2fs.protected_regular = 2fs.suid_dumpable = 0 |
Core dumps are also forbidden for every user (/etc/security/limits.d/99-artica-hardening.conf). |
| IPv4 network configuration | accept_redirects = 0, secure_redirects = 0, accept_source_route = 0, shared_media = 0, route_localnet = 0, log_martians = 1net.ipv4.tcp_syncookies = 1net.ipv4.icmp_ignore_bogus_error_responses = 1net.core.bpf_jit_harden = 2rp_filter = 1 and ip_forward = 0 when the appliance is not a gateway |
When the appliance routes traffic (gateway or transparent proxy), see table 3. |
| IPv6 | IPv6 is disabled by default (disable_ipv6 = 1 on all interfaces). When enabled, ICMPv6 redirects are refused. |
The guide recommends disabling IPv6 when it is not used. |
| Kernel modules | Automatic loading is blocked for rarely used file systems and protocols: cramfs, freevxfs, jffs2, hfs, hfsplus, squashfs, udf, usb-storage, dccp, sctp, rds, tipc, and algif_aead (CVE mitigation). |
Managed centrally in /etc/modprobe.d/00-security.conf. See also Disable USB storage. |
| Default umask | umask 077 for interactive sessions (/etc/profile.d/99-artica-hardening.sh). |
|
| Sensitive files | Account files and their backups, sshd_config, cron and at configuration, /var/log/btmp, /boot/System.map-* (0600), SQLite databases of the appliance (0660). |
|
| Files without owner, sticky bit, setuid | Files whose owner or group does not exist are repaired in the Artica trees; World-writable shared directories carry the sticky bit; The setuid bit is removed from ksu and, when unused, from the D-Bus activation helper. |
The ownership check reads /etc/passwd and /etc/group directly,never a directory service, so an unreachable Active Directory cannot trigger a mass change of ownership. |
| Service accounts | Service accounts have no login shell (/usr/sbin/nologin). |
|
| Remote administration (SSH) | Key exchange without SHA-1 (curve25519, ECDH, DH group 16/group exchange SHA-256) MACs hmac-sha2-256, hmac-sha2-512, umac-128Ciphers: OpenSSH defaults, or when you enable a custom list, chacha20-poly1305, aes-gcm, aes-ctr — no CBC, no 3DESIgnoreRhosts yes, HostbasedAuthentication no, AllowTcpForwarding no, AllowAgentForwarding no, PermitUserRC no, GatewayPorts no, LoginGraceTime 120 |
A custom cipher list saved by an administrator is kept as is. The former default list (which offered CBC and 3DES) is replaced automatically. Every generated configuration is validated with sshd -t before it is applied. |
| Time synchronisation | Chrony is configured with public NTP pools by default. | Accurate time is a prerequisite for usable logs. |
These features exist in Artica but are not enabled by default, either because they cost resources or because they depend on your environment.
| ANSSI topic | What to do | Comment |
|---|---|---|
| Audit of system activity (auditd) | Enable Auditd, and optionally the kernel option audit=1 (reboot required). |
Installs the audit rule set (identity changes, privileged commands, kernel modules, time changes…), makes it immutable, and forwards the events to your SIEM. |
| Integrity sealing of the system | Enable File Integrity Monitoring (AIDE). | Daily check of system files against a baseline, with a review workflow for every change. |
| Logging and log centralisation | Forward the system logs to a remote collector or SIEM (Log Sink / syslog forwarding). |
The guide asks for logs to be kept outside the system they describe. |
| Accountability of administrator actions | Enable administrator tracking (TrackAdmins) requires a Corporate license. |
Writes one audit line per console login, account change and privilege change to /var/log/auth.log (authpriv, tag artica-audit). See BSI IT-Grundschutz SYS.1.1 for the event list. Without a Corporate license, logins are still written to /var/log/artica-webauth.log. |
| Named administrator accounts | Create one account per administrator (local, LDAP, Active Directory, RADIUS, SAML or certificate) and keep the Manager superadmin for emergencies only. |
A shared account defeats accountability. |
| Strong authentication of administrators | Enable two-factor authentication for the console, and restrict the console by network and client certificate (mTLS). |
|
| SSH: root and password logins | In the SSH service settings, disable “Permit root login” and password authentication, and use keys. Restrict the allowed users. Or uninstall SSH entirely: the Web Unix Console covers occasional needs. |
Both options are enabled by default so that a freshly installed appliance stays reachable. SSH two-factor authentication is available when the Google Authenticator PAM module is installed. |
| Minimising exposed services | Uninstall every Artica service you do not use, and use the local firewall to limit which networks reach the remaining ones. |
See the security compliance section. |
| Regular updates | Apply system and Artica updates from the console, and enable the CVE scanner to list the vulnerable packages. |
The CVE scanner needs about 2 GB of free disk space. |
| Compliance monitoring | Enable the daily CIS Benchmark audit. | Read-only audit; it never changes the system. It measures CIS, not ANSSI (see the note above). |
| Boot loader password | Manual: set a GRUB superuser password (grub-mkpasswd-pbkdf2), and mark the default entry --unrestricted so that the appliance still boots unattended. |
Artica does not manage GRUB passwords. Without --unrestricted, every reboot waits for a password at the console. |
An Artica appliance is a network appliance that loads features on demand, routes or intercepts traffic, and is administered as a whole by a management daemon. The following recommendations conflict with that design. Declare them as accepted deviations in your security concept, with the justification below.
| ANSSI topic | Recommendation | Why it does not apply |
|---|---|---|
| Kernel modules | Forbid module loading after boot (kernel.modules_disabled = 1). |
Firewall matches, ipset, connection tracking, GeoIP filtering, bonding, VPN tunnels and bridges load their kernel modules when you enable the feature. Locking module loading would make every feature enabled later unusable until the next reboot. |
| UEFI Secure Boot and kernel lockdown | Boot only signed kernels and modules. | Some firewall extensions (xtables-addons, GeoIP matching) are compiled by Artica and are not signed by Debian. Secure Boot would refuse them. |
| Kernel command line hardening | Options such as iommu=force, slab_nomerge, init_on_free=1, page_poison=1. |
Measurable throughput cost on a proxy that handles thousands of connections per second, and effective only after a reboot. Can be set manually by an administrator who accepts the cost. |
| Hardened kernel build | Compile-time kernel options. | Artica uses the stock Debian kernel so that it receives Debian security updates. |
| Partitioning | Separate /tmp, /var, /var/log, /var/tmp, /home with nodev, nosuid, noexec. |
The installer uses a single system partition, and an installed appliance cannot be repartitioned without reinstalling. Artica stores programs and working files under /home/artica, so noexec there would break features. |
| Router mode | ip_forward = 0, rp_filter = 1, send_redirects = 0. |
When the appliance is a gateway or a transparent proxy, forwarding is its function, and loose reverse-path filtering (rp_filter = 2) is needed for asymmetric routing. The guide explicitly allows these values on a router. |
| ARP hardening | arp_ignore = 2, arp_filter = 1, drop_gratuitous_arp = 1. |
The HaCluster fail-over moves a virtual IP between nodes with gratuitous ARP, and appliances often carry several addresses on one interface. These settings would break fail-over. |
| perf sampling limits | kernel.perf_event_max_sample_rate = 1, kernel.perf_cpu_time_max_percent = 1. |
These limits also apply to root and would make the performance profile of the support package useless. Unprivileged users already have no access to perf events ( perf_event_paranoid ≥ 2). |
| Least privilege of the management daemon | Every service runs with the minimal privileges it needs. | The Artica management daemon configures the network, the firewall, the services and the users: it runs as root by design. It is reachable only through a local socket (root:www-data 0660) and, over TCP, from authorised networks with authentication. |
| Minimal installation | Install only the packages the server needs. | Artica is a multi-purpose appliance: components of features you do not use may be present on disk. Uninstall the services you do not use (table 2) to keep them from running. |
| Packages from trusted repositories only | Use only the distribution's signed repositories. | Several network services (proxy, load balancer…) are built and delivered by Artica to provide versions that Debian does not ship. Their security follow-up is Artica's responsibility and comes with Artica updates, not with Debian security updates. |
These points are compatible with the appliance but not implemented yet.
They are listed so that you can plan them in your security concept; no delivery date is committed.
| ANSSI topic | Possible improvement | Workaround today |
|---|---|---|
| Session timeout | Automatic logout of idle shell sessions (TMOUT). |
SSH already closes dead connections (ClientAliveInterval). You can add TMOUT=900; readonly TMOUT in a file of /etc/profile.d/. |
| Password policy | Complexity rules and lock-out after failures for system accounts (pam_pwquality, pam_faillock). |
Use SSH keys only and disable password authentication (table 2). |
| SSH defaults | Root login restricted to keys (prohibit-password) on new installations. |
Change the setting in the SSH service (table 2). |
| Mandatory access control | AppArmor profiles for the most exposed daemons (proxy, web server, PHP workers). | Network restrictions and the local firewall. |
| Separation of the web console | The web console user is currently a member of the adm group so that the console can display system logs. Serving those logs through the management API would let this membership be removed. |
Restrict console access (network, mTLS, two-factor authentication). |
| Log file permissions | Create every Artica log file with mode 0640 from the start (some per-session SSH logs are still created with wider permissions). |
|
| Service umask | umask 027 for every service. |
|
| ANSSI audit | A read-only daily audit against the ANSSI profiles (OpenSCAP / ComplianceAsCode anssi_bp28), next to the CIS audit. |
Run OpenSCAP from an administration workstation, or use the CIS audit as a partial indicator. |