August 21, 2026
11 min read
By Kokil Thapa | Last reviewed: September 2026
Your server passes a quick security review, then a client asks for proof. Vague advice about strong passwords does not satisfy auditors, insurers, or procurement teams. CIS hardening gives you a named baseline: the Center for Internet Security (CIS) Benchmarks translate best practice into testable settings for Ubuntu, WordPress, and application stacks like Laravel. This guide maps server security practices for Nepal-hosted infrastructure to the CIS standards Google already associates with this topic—Level 1 profiles, checklists, WordPress coverage, and automated validation.
Quick answer: CIS hardening means applying CIS Benchmark configuration profiles—usually Level 1 first—to lock down OS settings, services, permissions, and logging, then verifying compliance with tools like OpenSCAP or CIS-CAT against the official benchmark for your platform.
I apply these controls on production VPS instances that run legal-tech portals and eCommerce stores. The work is not theoretical. You disable root SSH, tighten file permissions, reduce open ports, and scan weekly so package upgrades do not silently undo your work. If you manage servers for clients, CIS hardening is how you replace "we think it is secure" with evidence.
What Is CIS Hardening and How Do CIS Benchmarks Work?
CIS hardening is the process of aligning a server to a published CIS Benchmark profile. Each benchmark is a consensus document: hundreds of numbered recommendations with rationale, audit steps, and remediation commands. They map to broader CIS standards and frameworks such as NIST SP 800-53 and ISO 27001 control families, which is why enterprise RFPs and CIS compliance mandates reference them by name.
Unlike a blog post checklist, every control is binary. Either PermitRootLogin is set to no in /etc/ssh/sshd_config, or it is not. That precision matters when you maintain ten client VPS instances across Kathmandu and overseas hosting regions. On a legal-tech portal handling case documents, I start with the Ubuntu 24.04 LTS benchmark and treat failed scan items as a prioritized backlog—not optional suggestions.
Official benchmarks are free to download from the CIS Benchmarks portal. Ubuntu, Debian, Amazon Linux, Docker, Kubernetes, and WordPress each have dedicated documents. For PHP workloads, the OS benchmark is your foundation; application benchmarks add CMS-specific controls on top. If you prefer hands-on help, our Linux system administration service includes baseline hardening on client servers.
What Is the Difference Between CIS Benchmark Level 1 and Level 2?
Every major OS benchmark ships two profiles. Understanding CIS Level 1 vs Level 2 is the first decision in any CIS hardening guide, because choosing wrong either leaves gaps or breaks production.
CIS benchmark Level 1 (often split into Level 1 Server and Level 1 Workstation) targets essential controls with minimal operational impact. Disable root login, enforce password complexity, restrict cron, enable automatic security updates, configure a host firewall. These are the controls I apply on every Laravel VPS before go-live. They should not break normal web application behaviour.
Level 2 adds defence-in-depth: stricter kernel parameters, mandatory access control (AppArmor or SELinux in enforcing mode), comprehensive auditd rules, and tighter network stack settings. Use Level 2 when the data justifies it—payment processing, health records, or a client portal with document sharing and payments. Expect trade-offs. Verbose audit logging can increase I/O under load; some legacy PHP extensions conflict with strict MAC policies.
| Profile | Goal | Typical Use Case | Operational Impact |
|---|---|---|---|
| Level 1 Server | Baseline CIS server hardening | Laravel/WooCommerce VPS, staging, most SMB sites | Low—designed for servers |
| Level 1 Workstation | Desktop-oriented controls | Developer laptops (skip on headless VMs) | Irrelevant on cloud VPS |
| Level 2 | Maximum benchmark coverage | Legal-tech, fintech, regulated workloads | Medium to high—plan exceptions |
A practical tiering model: Level 1 everywhere, Level 2 only where risk warrants it. Document every deviation. Auditors accept justified exceptions; they reject unexplained failures. For background on control frameworks, see our overview of ISO 27001 basics for engineers.
How Do You Implement CIS Hardening on Ubuntu 24.04?
CIS benchmark hardening on Ubuntu starts with a staging mirror of production. Never run blind scripts against a live database server. Integrate controls into provisioning—Ansible playbooks, cloud-init, or your existing Deployer 7 deployment workflow—so every new release inherits the same baseline.
Filesystem and permission controls
World-readable .env files are the most common audit failure I see. CIS section 6.x requires strict permissions on sensitive configuration. Apply these on a Laravel 12 app running PHP 8.4 under PHP-FPM:
sudo chown root:www-data /var/www/html/.env
sudo chmod 640 /var/www/html/.env
sudo sed -i 's/^#PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sudo sed -i 's/^#MaxAuthTries.*/MaxAuthTries 4/' /etc/ssh/sshd_config
sudo systemctl restart ssh
sudo rm -f /etc/cron.deny
sudo touch /etc/cron.allow
sudo chmod 600 /etc/cron.allow
sudo chown root:root /etc/cron.allowOwnership root:www-data lets PHP-FPM read secrets while blocking other local users. Pair this with SSH key-only authentication and the guidance in our SSH hardening article for a complete access-control layer.
Network stack and service reduction
Every listening port is attack surface. For a typical Nginx + PHP-FPM stack, only 22, 80, and 443 should appear in ss -tulpn output.
- Audit listeners:
sudo ss -tulpn - Disable unused daemons:
sudo systemctl disable --now rpcbind avahi-daemon cups 2>/dev/null - Set UFW defaults:
sudo ufw default deny incoming && sudo ufw allow 22/tcp && sudo ufw allow 80/tcp && sudo ufw allow 443/tcp - Harden sysctl: add
net.ipv4.tcp_syncookies=1andnet.ipv4.conf.all.rp_filter=1to/etc/sysctl.d/99-cis.conf, thensudo sysctl --system
Nepal VPS providers sometimes enable compatibility services by default. Verify after every reboot. Our UFW firewall guide and fail2ban configuration for PHP sites extend these network controls with brute-force protection.
How Can You Automate CIS Hardening Compliance With OpenSCAP?
Manual review of 200+ controls does not scale. OpenSCAP scans your server against official XCCDF profiles and produces pass/fail evidence. This turns CIS hardening standards from a PDF on a shelf into a repeatable pipeline step.
Install the SCAP Security Guide packages on Ubuntu 24.04:
sudo apt update
sudo apt install -y ssg-base ssg-debderived ssg-debian \
libopenscap25 openscap-scanner openscap-utilsRun a Level 1 Server scan and write an HTML report:
sudo oscap xccdf eval \
--profile xccdf_org.ssgproject.content_profile_cis_level1_server \
--results-arf /var/log/cis-scan-arf.xml \
--report /var/log/cis-compliance.html \
/usr/share/xml/scap/ssg/content/ssg-ubuntu2404-ds.xmlThe OpenSCAP documentation explains profile selection and report formats. Store reports outside the web root or behind authentication—public compliance reports advertise your exact gaps. I schedule weekly scans via cron on servers I maintain through GitLab CI. Pair this with secrets scanning in CI with gitleaks and CI/CD secrets management for defence across infrastructure and code.
How Do CIS Benchmarks Apply to Laravel, WordPress, and PHP?
OS benchmarks do not replace application security. They complement it. Several control areas map directly to PHP runtimes and CMS deployments—including CIS benchmarks for WordPress when you run WooCommerce 11.1 on WordPress 7.1.
| CIS Area | Benchmark Rule | Laravel / WordPress Adaptation | Risk if Ignored |
|---|---|---|---|
| File permissions | No world-writable files | storage/ and bootstrap/cache/ group-writable by www-data only | App crash, log injection |
| PHP hardening | Disable dangerous functions | Add exec,passthru,shell_exec,system to disable_functions | Remote code execution |
| Session security | Secure cookie flags | SESSION_SECURE_COOKIE=true, SESSION_SAME_SITE=lax | Session hijacking |
| Logging | Centralized audit trail | Laravel log channel to syslog; WordPress audit plugin | No forensic data after breach |
| Dependencies | Vulnerability management | composer audit and npm audit in CI | Known CVE exploitation |
Laravel nuance: CIS recommends disabling exec(), but PDF generators or media processors may need it. Create a dedicated PHP-FPM pool at /etc/php/8.4/fpm/pool.d/app.conf with a narrower disable_functions list instead of weakening global php.ini. For API backends, follow Laravel API best practices and store tokens hashed via Sanctum—not plaintext columns.
WordPress adds a dedicated CIS benchmark covering wp-config hardening, admin URL restrictions, plugin vetting, and database prefix conventions. Cross-reference it with our WordPress security hardening checklist. Disable file editing in wp-config (DISALLOW_FILE_EDIT), move wp-config above the web root where possible, and restrict xmlrpc.php if unused.
Generate strong credentials during setup using our password generator tool—weak admin passwords fail both CIS intent and basic hygiene regardless of what the scan reports.
What Should a CIS Hardening Checklist Include for Production?
A practical CIS hardening checklist groups controls by implementation order and verification method. Use it during initial provisioning, after major upgrades, and before client handover.
- Access: SSH keys only, root login disabled, fail2ban active, non-standard SSH port optional
- Network: UFW or nftables deny-by-default, only required ports open, sysctl hardening applied
- Filesystem: No world-writable files outside app cache dirs,
.envmode 640, cron.allow configured - Updates:
unattended-upgradesfor security patches, reboot schedule documented - Logging: auth.log monitored, Laravel/WordPress logs shipped to persistent storage
- Backups: encrypted off-site copies tested monthly—see automated server backups setup
- Validation: OpenSCAP Level 1 scan passes or failures documented with remediation dates
- Application:
composer audit, HTTPS everywhere, security headers via Nginx
High-value, low-cost items belong in week one. Auditd blanket rules and SELinux enforcing mode need staging tests first. On a high-traffic WooCommerce store, selective audit paths—/etc/, .env, authentication logs—preserved forensic value without the I/O penalty of full filesystem watches.
Controls that make no sense on cloud VMs—USB storage module blacklists, screen locks on headless servers—belong on an exception register with justification. The same applies to disabling debug tooling in development staging environments that mirror production.
For a full server build that incorporates these steps, follow our Laravel on Ubuntu VPS deployment guide and the broader Ubuntu security hardening guide. Support and maintenance plans can include quarterly rescans if you prefer ongoing oversight.
Key Takeaways
- Start with CIS benchmark Level 1 Server on every production VPS before considering Level 2.
- Automate validation with OpenSCAP weekly—manual checklists alone cannot track 200+ controls.
- Adapt PHP and Laravel settings via per-pool PHP-FPM overrides instead of weakening global php.ini.
- Apply the WordPress CIS benchmark alongside the OS profile when running WooCommerce or WordPress 7.1.
- Document every intentional exception; auditors accept reasoned deviations, not silent failures.
- Store scan reports securely and pair OS hardening with CI secrets scanning and dependency audits.
People Also Ask
Is CIS hardening required by law?
No single law mandates CIS benchmarks globally. However, PCI-DSS, HIPAA, and many enterprise contracts reference CIS-aligned controls as acceptable evidence. Nepal-based clients handling cross-border payments or legal documents increasingly ask for documented baselines during vendor review.
How long does initial CIS hardening take on a Ubuntu VPS?
Level 1 implementation on a fresh Ubuntu 24.04 LTS web server typically takes four to eight hours including staging validation and a first OpenSCAP scan. Level 2 adds one to two days depending on audit logging scope and AppArmor profile tuning for your PHP application.
Can CIS hardening break my Laravel application?
Yes, if applied blindly. Strict disable_functions, overly aggressive AppArmor profiles, or wrong ownership on storage/ directories cause common breakages. Always test on staging, run your test suite after each control batch, and use PHP-FPM pool exceptions where packages legitimately need shell functions.
What is the difference between CIS Controls and CIS Benchmarks?
CIS Controls v8 are 18 high-level security outcomes—inventory assets, manage vulnerabilities, configure securely. CIS Benchmarks are the platform-specific implementation guides that tell you exactly which settings achieve those outcomes on Ubuntu, Windows, AWS, WordPress, and other targets. Hardening work happens at the benchmark level; controls provide the strategic map.
Build Durable Server Security
CIS hardening is an engineering discipline, not a one-time checkbox. Pick Level 1 for every production server, automate proof with OpenSCAP, layer application controls for Laravel and WordPress, and treat your checklist as a living document that survives package upgrades and staff turnover. Sustainable security beats perfect compliance scores that collapse under real traffic.
Need help hardening Laravel infrastructure or meeting compliance for a Nepal legal-tech or eCommerce platform? Contact us to discuss your server hardening requirements, or reach out directly about your current audit gaps. Strong baselines protect client data and the reputation you have spent years building.
Frequently Asked Questions
CIS Benchmarks are vendor-agnostic, consensus-based security configuration standards published by the Center for Internet Security. They provide specific, testable settings for operating systems like Ubuntu 24.04, web servers, and databases to reduce attack surface. Unlike vague best practices, they offer numbered recommendations with audit scripts and remediation steps validated by global cybersecurity experts.
Download CIS-CAT Lite from the CIS SecureSuite portal after free registration. Extract the archive to /opt/cis-cat-lite, ensure Java 17+ is installed via apt install openjdk-17-jre-headless, and run ./CIS-CAT.sh -b benchmarks/xccdf.xml -p profile_name. The tool generates HTML/XML reports showing pass/fail status against selected benchmark profiles without modifying system files during assessment mode.
CIS-CAT Lite and benchmark PDFs are free for individual use. CIS SecureSuite membership costs USD 3,500 annually (approximately NPR 465,000) for commercial entities requiring automated reporting and unlimited assessments. For most Nepal-based SMEs, using free open-source alternatives like OpenSCAP with official CIS XCCDF content provides sufficient compliance validation without licensing fees.
Use the CIS Ubuntu Linux 24.04 LTS Level 1 Server profile as your baseline. Level 1 controls are practical, non-disruptive, and essential for any internet-facing system. Avoid Level 2 initially, as those controls often break application functionality or require extensive tuning. In my experience deploying Laravel applications, Level 1 covers critical filesystem permissions, SSH hardening, and firewall rules without impacting PHP-FPM or Nginx operations.
Yes, if applied blindly without testing. Common breaking points include disabling unused kernel modules required by hosting plugins, restrictive file permissions blocking wp-content/uploads writes, and tightened sudo rules preventing WP-CLI execution. Always apply benchmarks incrementally on staging first. On WooCommerce sites I maintain, I whitelist specific directories from strict permission controls and document exceptions rather than forcing full compliance that breaks checkout flows.
CIS Benchmarks provide prescriptive technical configurations (specific file permissions, registry values, command syntax), while NIST SP 800-53 and ISO 27001 define risk management frameworks and control objectives without implementation details. Think of CIS as the how-to manual for achieving NIST/ISO compliance. Many organizations map CIS controls directly to NIST 800-53 Rev 5 families because CIS offers measurable, auditable technical evidence that satisfies framework requirements.
Absolutely, and you should. Community-maintained roles like ansible-lockdown/ubuntu24-cis implement Level 1 and Level 2 controls idempotently. However, never run these playbooks directly against production without customization. Fork the role, disable controls conflicting with your stack (like aggressive log rotation or kernel parameter changes affecting database performance), and test thoroughly. I use Deployer 7 alongside Ansible for hardened Laravel deployments, applying CIS controls during provisioning but excluding runtime-sensitive settings.
Run automated scans weekly via cron and immediately after any infrastructure change, package update, or deployment. Configuration drift is inevitable as developers troubleshoot issues or add services. Schedule CIS-CAT Lite or OpenSCAP scans Sunday nights, store reports in version control, and alert on regression. On client projects, I integrate scanning into GitLab CI pipelines so every deploy triggers a lightweight compliance check before traffic switches to new releases.
Frequent false positives include warnings about disabled USB storage when running headless cloud VMs, IPv6 disablement flags on systems using internal IPv6 DNS, and partition separation alerts on containerized environments where mount namespaces already provide isolation. Audit each failure manually before remediating. Document accepted risks with business justification. Blindly fixing every warning creates fragile systems; understanding why a control exists matters more than achieving 100% score.
Not directly in the OS benchmark. CIS publishes separate benchmarks for Nginx and Apache HTTP Server, but PHP-FPM lacks an official standalone benchmark. Apply the Ubuntu 24.04 Level 1 server benchmark first, then layer Nginx-specific controls from CIS Nginx Benchmark v2.0. For PHP-FPM, follow OWASP secure configuration guides and harden pool configs manually: restrict chroot, disable dangerous functions via disable_functions, enforce open_basedir, and set appropriate pm.max_children based on available RAM.
Strict outbound firewall rules (CIS 3.5.x) commonly block payment webhook callbacks or API endpoints. Before applying network controls, inventory all external dependencies including eSewa, Khalti, ConnectIPS, and IME Pay callback URLs. Whitelist their IP ranges and domains explicitly in UFW or iptables. Test transaction flows end-to-end after hardening. On Nepal Gift Card and similar platforms, I discovered post-hardening that restrictive DNS settings broke SSL verification for local gateways, requiring careful resolver configuration adjustments.
No explicit mandate exists yet, but government RFPs increasingly reference international security standards. Demonstrating CIS alignment strengthens bids for legal-tech portals, municipal systems, or health platforms where data sensitivity matters. Even without contractual requirements, following CIS Level 1 protects against common vulnerabilities exploited in Nepali cyberspace. Clients appreciate documented hardening as proof of due diligence, especially when handling citizen data or financial transactions through systems like court marriage portals or notary services.
Shared hosting environments cannot implement most CIS controls due to lack of root access and multi-tenant constraints. Focus on application-level hardening: secure file permissions within your account, disable directory listing, enforce HTTPS, and validate input sanitization. Reserve full CIS benchmark implementation for dedicated servers or VPS instances where you control the OS. For WordPress clients on shared hosting, I prioritize moving security-sensitive workloads to managed VPS setups where proper hardening is actually achievable.
Monitor /var/log/auth.log for failed SSH attempts and sudo abuse, /var/log/syslog for service failures caused by restrictive controls, and application-specific logs for permission errors. CIS recommends centralized logging (control 4.2.x), so configure rsyslog forwarding to a remote collector early. Set up fail2ban jails aligned with CIS authentication thresholds. After hardening legal-tech portals, I found increased auth.log noise from legitimate users hitting new password complexity requirements, requiring user communication alongside technical changes.
Indirectly, yes. Removing unnecessary services reduces resource contention, improving TTFB and server response times. Enforcing HTTP/2 and TLS 1.3 (covered in web server benchmarks) directly impacts LCP and INP metrics. Secure configurations prevent malware injection that destroys search rankings. However, CIS prioritizes security over performance; some controls add latency. Balance both by profiling before and after hardening. Technical SEO gains come from stable, uncompromised infrastructure rather than benchmark scores themselves.
0 Comments
Leave a comment
Your email is not published. Comments appear once they have been read. Sign in to have your details filled in.
