CIS Benchmarks: Harden Your Systems

By Kokil Thapa | Last reviewed: September 2026

CIS Benchmarks: Harden Your Systems is the practical answer when a production Ubuntu box passes a client security questionnaire but still feels wide open. The Center for Internet Security publishes vendor-specific configuration guides that turn vague "make it secure" requests into numbered, testable controls. On real client projects — Laravel apps on Apache and PHP-FPM, MySQL backends, shared EC2 hosts — I treat CIS as a baseline, not a religion. This guide walks through assessment, profile choice, and implementation without breaking the applications you actually run. If you maintain Linux servers for web applications in Nepal, these benchmarks belong in your standard deployment checklist.

What are CIS Benchmarks and why do they matter for hardening systems?

CIS Benchmarks are consensus-built configuration standards. Security researchers, vendors, and practitioners agree on settings that reduce attack surface on specific platforms. Each benchmark splits into sections: initial setup, services, network, logging, access control, and maintenance.

Unlike ad-hoc hardening blog posts, every control has a rationale and an audit procedure. You can answer "Are we compliant?" with evidence, not opinions. That matters when you host client portals — document uploads, payment callbacks, admin panels — on a single VPS with a small ops team.

The benchmarks cover the stack I work with daily: Ubuntu 22.04 and 24.04, Apache, MySQL 8.4 or 9.7, PostgreSQL 18, Redis 8.10, and container runtimes. WordPress 7.1 and WooCommerce 11.1 inherit OS-level controls from the underlying Linux host. Laravel 12 and Laravel 13 apps depend on the same PHP-FPM and web-server hardening underneath.

Official benchmarks live on the CIS Benchmarks portal. Free PDF downloads cover most platforms. CIS Workbench adds machine-readable formats for automated scanning. For teams without enterprise budget, the PDF plus OpenSCAP on Ubuntu covers most needs.

I align CIS work with broader architecture reviews — similar to how the AWS Well-Architected Framework treats security as a pillar, not an afterthought. CIS gives you the checkbox list. Your deployment pipeline still has to enforce it.

How do you assess a server against CIS Benchmarks?

Assessment comes before remediation. You need a score and a gap list. Manual PDF review works for ten controls. It fails on a 200-control Ubuntu benchmark.

Use automated auditors that map benchmark rules to your host state. Common options include CIS-CAT Pro (commercial), OpenSCAP with SCAP content, and Lynis (not CIS-native but overlaps heavily). On Ubuntu 24.04 servers I maintain, OpenSCAP plus the Ubuntu STIG or CIS-derived content gives a repeatable baseline.

Run an OpenSCAP assessment on Ubuntu

Install the scanner and fetch content aligned to your OS version:

sudo apt update
sudo apt install -y openscap-scanner scap-security-guide
oscap info /usr/share/xml/scap/ssg/content/ssg-ubuntu2404-ds.xml

sudo oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis_level1_server \
  --results /tmp/cis-results.xml \
  --report /tmp/cis-report.html \
  /usr/share/xml/scap/ssg/content/ssg-ubuntu2404-ds.xml

Open /tmp/cis-report.html in a browser. Failed rules show remediation text. Pass the report to stakeholders who ask for audit evidence.

Document exceptions before you fix anything

Not every failed rule should be "fixed." Some break legitimate workflows. Record each exception with owner, business reason, compensating control, and review date. A law-firm portal that sends webhooks to a payment gateway may need outbound HTTPS rules that a strict firewall section flags. Document it.

1. Inventory hosts by role: web, database, queue worker, bastion.
2. Pick the correct benchmark per role — do not run the Docker benchmark on bare metal by mistake.
3. Run automated scan during a maintenance window; heavy checks touch many files.
4. Export HTML and XML results to your ticket system.
5. Triage failures into quick wins, planned changes, and accepted risks.
6. Re-scan after each remediation batch until Level 1 pass rate meets your policy.

For password and key policy checks outside the scanner, pair the audit with a dedicated password generator tool so your team stops reusing credentials across staging and production.

Which CIS Benchmark profile should you choose: Level 1 or Level 2?

Every major CIS Benchmark defines two implementation profiles. Level 1 is the practical production baseline. Level 2 is defense-in-depth for high-assurance environments. Choosing wrong is a common mistake — Level 2 on a shared hosting box breaks more than it protects.

Level 1 Server on Ubuntu covers what most of my deployments need: disable unused services, configure UFW, harden SSH, enforce password quality, enable auditd, and tune kernel parameters. Level 2 adds controls that can interfere with PHP-FPM socket paths, Deployer symlink releases, or GitLab CI runner behaviour.

Database benchmarks follow the same split. MySQL 8.4 on a dedicated database host might target Level 2 if it holds PII from a client portal with document sharing. The web tier stays at Level 1 so deploys keep working.

How do you implement CIS Benchmark controls on Ubuntu Linux?

Implementation is control-by-control, grouped by area. I batch changes by risk: network and SSH first, then logging, then filesystem niceties. Always test on staging that mirrors production PHP version — PHP 8.4 versus 8.5 matters when you tune FPM pools.

SSH and access control

CIS Ubuntu benchmarks devote significant space to SSH. These settings align with dedicated guides on hardening SSH on Linux servers and SSH key auth with fail2ban:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

sudo tee /etc/ssh/sshd_config.d/99-cis-hardening.conf <<'EOF'
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 0
AllowUsers deploy
EOF

sudo sshd -t && sudo systemctl reload sshd

Install and enable fail2ban after SSH hardening. Pair with UFW default-deny:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 'Apache Full'
sudo ufw enable

Logging and audit

CIS expects auditd for security-relevant events. Enable it and ship logs off-box when budget allows — even rsync to a backup VPS beats losing logs after a compromise.

sudo apt install -y auditd audispd-plugins
sudo systemctl enable --now auditd
sudo auditctl -l

Forward auth and audit logs to a central location if you run multiple sister sites on shared EC2 — the same pattern I use across legal-tech properties deployed via Deployer 7 and GitLab CI.

Automate with Ansible for repeatability

Manual hardening rots after the next urgent hotfix. Encode Level 1 controls in Ansible roles applied during provisioning. Tag tasks by benchmark section so you can skip or override per host role.

• Role cis-ubuntu-base: SSH, UFW, sysctl, unattended-upgrades.
• Role cis-apache: disable directory listing, set security headers, hide version tokens.
• Role cis-mysql: remove test database, enforce require_secure_transport, audit user accounts.
• Role cis-php-fpm: disable dangerous functions, set open_basedir where feasible.

Run the Ansible playbook on staging, re-scan with OpenSCAP, then promote to production during a window. This mirrors the discipline in CIS benchmarks for server hardening articles — automation beats one-time manual fixes.

Web stack specifics for Laravel and WordPress

Application benchmarks are not separate from OS benchmarks — they stack. For Laravel 12 on PHP 8.2 or higher, ensure .env is outside the web root, disable APP_DEBUG in production, and restrict write permissions on storage/ and bootstrap/cache/. CIS filesystem controls on the host support those app-level rules.

For WordPress 7.1, disable file editing in admin, block execution in uploads/, and keep wp-cron off public HTTP when possible. WooCommerce 11.1 adds payment webhook endpoints — document them before tightening ModSecurity or WAF rules.

Authentication design still belongs in application code. Cross-read the secure authentication systems guide for session, MFA, and password-reset patterns that complement OS hardening.

What CIS hardening mistakes break production web applications?

I've seen compliant servers take down live sites. The benchmark is correct for a generic server. Your app has specific needs. Learn the failure modes before you enforce every rule.

Mount options and PHP release directories

Level 2 may recommend noexec on /tmp or additional partitions. Composer and npm sometimes write executables to temp during deploys. Deployer 7 release paths under /var/www need consistent ownership for www-data and your deploy user. Apply mount changes on staging first. Run a full deploy plus smoke test before production.

Over-aggressive ModSecurity or WAF rules

CIS Apache sections encourage web application firewalls. Default OWASP rules block legitimate JSON POST bodies, file uploads on legal portals, and payment gateway callbacks. Tune exclusions for known endpoints. Log before block during the first week.

Disabling cron or mail without replacements

Some controls push you toward disabling postfix or restricting cron. Laravel scheduled tasks and system crons drive queue workers, backups, and certificate renewal. Replace — do not remove. Use systemd timers with explicit service units where cron is restricted.

MySQL bind-address and replication

Binding MySQL to localhost satisfies many CIS database rules. It breaks remote reporting tools and replica setups. Bind to a private VPC interface instead of 0.0.0.0, and enforce security groups or UFW source restrictions. Document the compensating control in your exception log.

Production rule: Never harden production on Friday afternoon Nepal time. Dashain and Tihar traffic spikes do not forgive untested SSH lockouts.

Capacity matters too. Heavy auditd rules on a small VPS already running MySQL and Redis can add I/O pressure. Review capacity planning for growing systems before enabling every logging control at once.

Fold CIS into your maintenance contract

Hardening is not a one-time project. New packages, kernel updates, and emergency SSH changes drift you away from baseline. Quarterly rescans catch drift before auditors do. If you lack in-house ops time, ongoing support and maintenance should include a CIS Level 1 re-check after major upgrades.

Hosting choices matter as well. Cheap shared hosting rarely lets you apply CIS controls at the OS layer. VPS or dedicated servers — configured through domain registration and hosting setup — give you the access you need. Managed platforms may publish their own compliance attestations instead.

For application-layer security on new builds, pair infrastructure hardening with enterprise application development practices: Form Request validation, RBAC via Spatie Permission, and encrypted document storage on legal-tech portals like those in our Notary Nepal portfolio case.

Performance testing after hardening avoids surprises. Auditd and stricter TLS cipher suites can add latency. Run load tests through testing and optimization services when you harden a high-traffic WooCommerce or Laravel storefront.

Key Takeaways

• Start with CIS Level 1 Server on Ubuntu for production web hosts — Level 2 only when regulation or contract demands it.
• Automate assessment with OpenSCAP or CIS-CAT; store HTML/XML reports as audit evidence.
• Batch remediation: SSH and firewall first, then auditd, then filesystem and kernel tunables.
• Document every exception with a compensating control — payment webhooks and deploy paths often need them.
• Encode controls in Ansible and run them at provision time; manual hardening drifts within weeks.
• Re-scan quarterly and after every major OS or PHP upgrade to catch configuration drift early.

People Also Ask

Are CIS Benchmarks free to use?

Yes. CIS publishes free PDF benchmarks for most operating systems, databases, and browsers. CIS Workbench offers free community access with registration. Commercial tools like CIS-CAT Pro add reporting features and faster updates, but OpenSCAP on Ubuntu covers baseline auditing at no cost.

How long does CIS hardening take on a single Ubuntu server?

A first Level 1 pass on a fresh Ubuntu 24.04 web server typically takes four to eight hours including scan, triage, and remediation. Automation cuts subsequent servers to under an hour. Complex stacks with legacy PHP apps or custom payment integrations need extra time for WAF and webhook exceptions.

Do CIS Benchmarks replace PCI DSS or ISO 27001?

No. CIS provides technical configuration baselines. PCI DSS and ISO 27001 cover broader governance, processes, and policies. CIS controls often satisfy technical portions of those frameworks. You still need policy documentation, access reviews, and vendor management for full compliance.

Can I harden Docker containers with CIS Benchmarks?

Yes. CIS publishes a Docker benchmark separate from the Linux host benchmark. Harden both the host OS and container runtime. Run containers as non-root, drop capabilities, and use read-only root filesystems where possible. The host Level 1 profile still applies to the underlying Ubuntu node.

Build a defensible baseline on your next deployment

CIS Benchmarks: Harden Your Systems turns security from a vague promise into numbered, testable controls you can prove in an audit. Start with Level 1 on Ubuntu, automate scans, document exceptions, and re-check after every upgrade. Your Laravel apps, WordPress sites, and client portals inherit the win. Need help applying CIS on a live fleet — or hardening a new web development project from day one? Review our portfolio of production deployments, read what clients say on customer reviews, and contact us to schedule a baseline assessment. For broader context on secure infrastructure design, see the about page and explore related API hardening patterns in our API development service and the bpftrace system-call tracing guide for post-incident forensics.