In short: A CIS Benchmark for web servers provides concrete, version-specific settings for the operating system and web server, for example for Ubuntu, Debian, RHEL, Nginx or Apache. The modules of the BSI (German Federal Office for Information Security) IT-Grundschutz describe in addition which requirements apply to web servers, web applications, patch management and logging. Together they make up a verifiable hardening specification; you add the PHP-specific settings yourself.
Why "Well Set Up" Is Not a Standard
After an incident, management, insurers or auditors sooner or later ask the same question: according to which standard was the server set up? In many companies the honest answer is: to the best knowledge of the admin who set it up back then. That is not necessarily bad, but it is neither traceable nor repeatable.
PHP2Shell made this visible. Anyone who wanted to know which servers were affected, which PHP operating mode was running and when patching last took place had to start by searching in many places. A hardening standard does not replace an update, but it creates exactly this order: defined settings, an inventory and regular checks.
Two works have proven themselves for this: the CIS Benchmarks of the Center for Internet Security and the IT-Grundschutz of the BSI.
What a CIS Benchmark for Web Servers Contains
CIS Benchmarks are consensus-based configuration recommendations that experts from many organizations develop together. According to CIS, they exist for more than 25 product families. For PHP web servers, these are particularly relevant: Ubuntu Linux, Debian Linux and Red Hat Enterprise Linux for the operating system, and Apache HTTP Server 2.4 and NGINX for the web server.
Each benchmark is a list of individual recommendations with rationale, audit instructions and remediation. Many benchmarks distinguish a basic profile that can be implemented without major side effects and a stricter profile for higher protection needs. For automatic checking, CIS offers tools, in the benchmark ecosystem under the name CIS-CAT.
The advantage is precision: instead of "secure SSH", it states which setting should have which value and how you check it. The disadvantage is the scope. A complete benchmark for a Linux system contains a great many items, and not every one fits every operation.
Also pay attention to the version. Benchmarks apply to specific releases: the CIS overview lists, for example, separate editions for Ubuntu LTS versions up to 26.04, for Debian 9 to 13 and for RHEL 8, 9 and 10. Anyone who applies a benchmark for an older version to a new system partly checks settings that no longer exist there and overlooks new ones. If a server still runs an operating system without vendor support, that in itself is the most important finding.
The Matching BSI Modules for PHP Web Servers
The BSI's IT-Grundschutz works with modules that describe requirements for systems and processes. The current version is the IT-Grundschutz Compendium in the 2023 edition. The BSI is currently converting IT-Grundschutz into a process-oriented, machine-readable set of rules; according to the BSI, the existing compendium remains applicable during a transition period of several years.
For a PHP web server, these modules are the most important:
| Module | Content | Relevance to the PHP web server |
|---|---|---|
| APP.3.2 Web Server | Operation and configuration of the web server | Nginx, Apache, LiteSpeed |
| APP.3.1 Web Applications and Web Services | Requirements for the application | CMS, shop, custom PHP software |
| SYS.1.3 Servers under Linux and Unix | Operating system hardening | Basis of every Linux web server |
| OPS.1.1.3 Patch and Change Management | Regulated application of updates | PHP updates, restarts, evidence |
| OPS.1.1.5 Logging | Recording and evaluating events | Access and error logs |
| CON.3 Data Backup Concept | Backups and restoration | Backup of code and database |
| CON.10 Development of Web Applications | Secure development | Custom PHP projects |
Grundschutz is less concrete than a CIS Benchmark but covers processes that are not written in any configuration file: who patches, who checks, who is informed.
CIS or BSI: What Fits Your Company?
The choice depends less on the technology than on the environment. A rule of thumb:
- Technical baseline for individual servers: CIS Benchmark for the operating system and web server, supplemented by a PHP specification of your own.
- Public administration, clients with a Grundschutz reference, regulated sectors: IT-Grundschutz as the framework, CIS Benchmarks for the concrete implementation.
- Companies with ISO 27001 or TISAX: Both works are suitable as technical underpinning for your own policies, see ISO 27001 and TISAX: What Affects Web Servers.
- Companies subject to NIS2: A documented hardening standard helps to demonstrate appropriate measures. What the directive requires is summarized in NIS2 and Web Server Security; in individual cases, your legal counsel decides.
For PHP itself, you should supplement the server specifications: locked values in php.ini, separate FPM pools, no execution in upload folders. A good basis is offered by the guide Configuring php.ini Securely.
Your Own Hardening Specification in Six Steps
A standard is useful only if it reaches operations. This approach has proven itself:
- Create an inventory: Which servers, operating systems, web servers and PHP versions run where?
- Select benchmark and modules, matching version and protection needs.
- Check the current state, preferably automated, and collect deviations.
- Evaluate deviations: implement, accept deliberately or compensate through other measures, each with a justification.
- Fix the specification, ideally as configuration automation, so that new servers are hardened from the start.
- Check again regularly and after major updates, because new packages sometimes bring new default values.
Step 6 connects hardening with the patch process. How to apply updates in a plannable rather than hectic way is described in Patch Management as a Process Instead of Firefighting.
Test strict profiles on a staging system first. Some recommendations, for example on file systems or network services, can interrupt applications or remote access.
How does PHP SOS help?
- We record your web servers and assign each the matching CIS Benchmark and the relevant Grundschutz modules.
- We check the current state and deliver a prioritized list of deviations with effort and benefit.
- We supplement the specification with a PHP baseline for php.ini, FPM pools and file permissions.
- We document deliberate exceptions so that auditors and insurers can follow them.
We carry out the implementation as part of server hardening for PHP web servers.
Frequently asked questions
Do I have to implement every recommendation of a CIS Benchmark?
No. Benchmarks are a yardstick, not a law. Some recommendations do not fit your operations or would interfere with functions. What matters is to decide on deviations deliberately, justify them and document them.
Are CIS Benchmarks and IT-Grundschutz competitors?
Rather, they complement each other. CIS Benchmarks provide concrete settings per product and version. IT-Grundschutz describes requirements for systems and processes, such as patch management and logging, and places them in a management system.
Is there a hardening standard specifically for PHP?
PHP settings are usually only touched on in the common server standards. In practice, you add your own PHP baseline to the server specifications, for example for php.ini, FPM pools and file permissions, and use the modules on web applications as guidance for the application.
Would a CIS Benchmark have prevented PHP2Shell?
No. PHP2Shell consists of vulnerabilities in the PHP interpreter, against which only the update helps. A hardened server can, however, limit the consequences of a break-in and, through regulated patch management, ensure that updates are applied faster and demonstrably.
Is IT-Grundschutz too big for small companies?
As a complete management system, often yes. The individual modules, however, work well as a checklist for web servers and web applications without adopting the entire approach.