Hardening and vulnerabilities
The InfraFence hardening check and software audit - what is checked, the fixes that apply in one click with verification and rollback, CVE matching against OSV and CISA KEV, and security updates.
Last updated:
Blocking attacks is half the job; the other half is closing what let them in. Each server runs a hardening check and a software audit 10 minutes after the agent starts, then once a day. Run check now and Check software now on the server's Security tab run them at once.
The hardening check
It looks at:
- SSH: root login, password authentication, the default port, X11 forwarding, maximum authentication attempts;
- files: permissions of
/etc/shadow,/etc/passwd,sshd_configand root'sauthorized_keys; - ports: services listening on the public network;
- users: accounts with UID 0 other than root, accounts without a password;
- firewall and processes (zombies);
- credentials: world-readable
.envfiles,.gitdirectories exposed in web roots, the permissions of.sshdirectories; - web server: version disclosure, directory listing, the TRACE method, TLS protocols, security headers, rate limiting, request body size and performance settings;
- versions: end-of-life operating system, kernel, pending security updates, PHP, MySQL, OpenSSH and the web server.
- PHP: the configuration of every PHP runtime and PHP-FPM pool (see PHP hardening below).
Each check explains what it is, why it matters and how to fix it.
The SSH checks read the configuration sshd really uses: sshd -T, or, when it can't run, the files in sshd's own order (agent 1.0.35 or later). sshd keeps the first value it reads, and sshd_config includes the drop-ins of /etc/ssh/sshd_config.d/ at its top on current distributions, so a drop-in wins: on a fresh cloud server, cloud-init's 50-cloud-init.conf often turns password login back on. The finding names the file and line that set the value, for example /etc/ssh/sshd_config.d/50-cloud-init.conf:1: change it there.
How many checks a server gets depends on the server: 40 to 50 on most. The web server checks depend on whether nginx, Apache or both are installed, and the PHP checks (six to nine) run for each PHP runtime and each PHP-FPM pool, so a server with many pools gets more.
One-click fixes
Ten checks can be fixed with Fix automatically:
| Check | Change |
|---|---|
| X11 forwarding | X11Forwarding no |
| Maximum authentication attempts | MaxAuthTries 4 |
/etc/shadow permissions |
0640 or stricter |
/etc/passwd permissions |
0644 or stricter |
sshd_config permissions |
0600 or stricter |
root's authorized_keys permissions |
0600 or stricter |
| nginx version disclosure | server_tokens off |
| Apache version disclosure | ServerTokens Prod |
| Apache signature | ServerSignature Off |
| TRACE method | TraceEnable Off |
InfraFence writes each change in a file of its own (/etc/ssh/sshd_config.d/00-infrafence-hardening.conf, or zz-infrafence-hardening.conf for nginx and Apache), tests the configuration (sshd -t, nginx -t, apachectl configtest) and reloads the service: open sessions and connections are not cut. Undo fix takes it back.
Some checks are never automatic, because done wrong they could lock you out or change how your sites behave: root login, password authentication, the SSH port, directory listing, TLS protocols and the security headers. Their page says how to fix them by hand. On a server whose configuration a hosting panel or a configuration-management tool owns, only the permission fixes are automatic.
PHP hardening
The check reads the effective configuration of every PHP runtime on the server: the distribution's PHP, ondrej, remi, cPanel EA4, Plesk and CloudLinux alt-php. It follows php.ini and the scan directory in PHP's own order, and checks each PHP-FPM pool with its php_value and php_admin_value overrides. The command-line PHP is not checked.
| Setting | Reported when | Fix |
|---|---|---|
allow_url_include |
on (critical) | automatic, AutoMode too |
display_errors |
on (high) | automatic, AutoMode too: display_errors = Off, log_errors = On |
expose_php |
on (low) | automatic, AutoMode too |
cgi.fix_pathinfo |
1 on PHP-FPM with nginx installed |
with approval: 0 |
disable_functions |
exec, system, passthru, shell_exec, proc_open or popen allowed (advisory) |
with approval: the missing ones are added |
open_basedir |
not set on a pool that serves two or more sites (advisory) | by hand: the finding gives the line for the pool |
session.cookie_httponly |
off | by hand |
session.cookie_secure |
off on a pool whose sites use HTTPS | by hand |
allow_url_fopen |
on (information) | by hand |
"With approval" needs two-factor authentication. The
cgi.fix_pathinfoanddisable_functionsfixes are applied only by an owner or admin signed in with two-factor authentication: with Review and apply on the server's Security tab, or on Approvals when AutoMode asks. Without 2FA the dashboard does not apply them. Turn it on under Settings › Security.
Each finding names the runtime, the pool, the value and the file and line it comes from. Before you approve a disable_functions fix, the dashboard lists the site files that call those functions (up to 20).
Fixes go in a file InfraFence owns, zz-infrafence-hardening.ini in the runtime's scan directory; php.ini and your pool files are never edited. When a pool sets the value in its own file, a drop-in can't override it: the finding then gives the exact line to change in that file, by hand. The agent tests the configuration (php-fpm -t), checks that the new value is the effective one, reloads PHP-FPM gracefully (never a restart) and runs the same site check as the other fixes: if a site stops answering, the change is undone. A fix in the runtime's file applies to every pool of that runtime that does not set the value itself.
The agent also watches these files. When allow_url_include or display_errors is turned on, the Risky PHP setting appeared event names the file, once per change. If someone else changes InfraFence's own file (a panel, a package, a person), you get an event too.
On cPanel, Plesk and CloudLinux the PHP configuration is reported, never changed, and the per-site files (Plesk's php.ini, cPanel's .user.ini) are only reported.
This is configuration hardening and watching. Nothing is loaded into PHP and it does not stop an attack inside your application: the web firewall and the malware scanner do that part.
Verification and rollback
Before a fix the agent notes which SSH ports accept connections and which sites answer without a server error, over HTTP and HTTPS (up to 20 sites). After the reload it checks them again for up to 20 seconds. If one stops answering, it undoes the change by itself and the result says Rolled back. Permission fixes have no rollback: a stricter mode does not break a service.
The same verification protects port closing, outbound blocks and virtual patches.
Vulnerabilities (CVE)
The software audit sends the list of installed packages to the dashboard, which checks it against the OSV database. This works on Debian, Ubuntu, AlmaLinux and Rocky Linux. The Vulnerabilities (CVE) panel lists the packages with a fix available, and marks the ones on the CISA list of vulnerabilities known to be exploited (Exploited in the wild (CISA KEV)): update those first.
Security updates
Update all or Update this package installs the fixed versions. The agent upgrades only those packages (nothing new is installed or removed), keeps your configuration files, refuses to start while another package operation runs, and never reboots the server. A package's own upgrade may restart its service for a moment. When a reboot is needed, or a service still runs old code, the result says so.
Security score
The results feed the server's security score, from 0 to 100, with the top fixes listed first. See Servers.