How long does it take to harden a new web server?

A baseline hardening of a single, well-understood web server can often be completed within a day by an experienced engineer, especially when using scripts or configuration management. Complex applications, compliance requirements and testing add time.

Do I still need hardening if I use a managed cloud provider?

Yes, in most cases. Cloud providers secure the underlying infrastructure, but the operating system, applications, access and configuration of your virtual server are usually your responsibility under the shared responsibility model.

Should I change the SSH port?

Changing the port reduces noise from automated scans in your logs, but it is not a real security control on its own. Key-based authentication, disabling root login and restricting access by IP or VPN matter far more.

How often should a hardened server be reviewed?

Review the configuration at least quarterly, and after any major change such as a new application, operating system upgrade or change of team members with access. Automated compliance scans can flag drift between reviews.

Linux Server Hardening Checklist for Web Applications

A newly provisioned Linux server is designed to be easy to use, not to be secure for a public web application. Within minutes of going online, it will be probed by automated scanners looking for weak passwords, outdated software and exposed services. This server hardening checklist gives a practical baseline for Linux servers that run websites and web applications, such as Laravel platforms and PHP sites. It is organized so a business owner can use it to ask informed questions and an engineer can use it to work through the tasks.

Before you start: principles

Three principles underpin every item below:

Least privilege. Every user, process and service gets only the access it needs.
Minimal surface. Anything not required is removed or disabled.
Defence in depth. No single control is relied on; layers back each other up.

Document what you change. Hardening that nobody understands later tends to be undone during the next emergency.

1. Access and authentication

Create named user accounts for each administrator; never share a single login.
Use SSH key authentication and disable password logins for SSH.
Disable direct root login over SSH; use sudo with logging.
Restrict SSH access by IP address, VPN or bastion host where practical.
Protect control panels and admin interfaces with two-factor authentication and IP restrictions.
Remove access promptly when staff or contractors leave, and review access quarterly.
Store server credentials and keys in a password manager or secrets vault, not in documents or chat.

2. Updates and patching

Enable automatic security updates for the operating system, or a defined patch schedule with monitoring.
Track end-of-life dates for the operating system, PHP, database and web server, and plan upgrades early.
Subscribe to security advisories for the frameworks and major packages you use.
Keep application dependencies updated, and run dependency vulnerability checks as part of deployments.
Schedule reboots when kernel updates require them.

3. Network and firewall

Control	Recommended baseline
Host firewall	Default deny inbound; allow only HTTP/HTTPS and restricted SSH
Database ports	Not exposed publicly; local or private network only
Cache/queue services (e.g. Redis)	Bound to localhost or private network, with authentication
Brute-force protection	Fail2ban or equivalent for SSH and admin logins
Outbound traffic	Restrict where feasible to limit what a compromised app can reach
Edge protection	CDN or web application firewall for public sites

A surprising number of incidents begin with a database or cache service accidentally exposed to the internet with weak or no authentication.

4. Services and software

Remove or disable unused services — FTP, mail servers on web-only machines, sample applications.
Run each application under its own system user, not as root or a shared user.
Set strict file permissions: application code should not be writable by the web server process, except for specific directories like storage, cache and uploads.
Hide version information in web server and PHP headers.

Key takeaway: Most compromised web servers are not breached through exotic attacks. They fall to weak or shared credentials, unpatched software, exposed services and overly permissive file permissions — all addressed by routine hardening.

5. Web server and PHP configuration

Enforce HTTPS with modern TLS settings and HSTS once all subdomains support it. Our SSL certificate guide covers the details.
Add security headers: Content-Security-Policy (where feasible), X-Content-Type-Options, Referrer-Policy, and frame protections.
Set the document root to the application's public directory only — for Laravel, the public folder — so configuration files, .env and source code are never web-accessible.
Block access to hidden files and directories such as .git and .env.
Disable risky PHP functions not needed by the application, and turn off error display in production while logging errors privately.
Set sensible upload limits and prevent execution of scripts in upload directories.
Ensure debug mode is off in production. A Laravel application with debug enabled can expose configuration and secrets in error pages.

6. Database security

Create a dedicated database user per application with only the privileges it needs.
Use strong, unique passwords stored outside the code repository.
Remove default or anonymous accounts and test databases.
Enable encrypted connections when the database runs on a separate server.
Encrypt particularly sensitive fields at the application level where appropriate, such as health or identity data.

7. Logging and monitoring

Centralize logs for authentication, web server access and errors, and application events, ideally off the server itself.
Alert on suspicious patterns: repeated failed logins, new admin users, unexpected outbound connections, sudden spikes in mail sending.
Monitor file integrity for critical directories so unexpected changes are noticed.
Keep logs for a defined period that balances investigation needs with privacy obligations.

Our article on uptime monitoring and incident response explains how to turn alerts into a response process.

8. Backups and recovery

Hardening reduces risk; it does not eliminate it. Make sure you can recover:

Automated, encrypted backups with at least one off-site, immutable copy.
Backup credentials that cannot be used to delete backups from the production server.
Regular restore tests with documented steps.

The 3-2-1 backup strategy sets out a structure that works for most web applications.

9. Application-level security

Server hardening protects the platform, but many attacks target the application itself: injection, broken access control, insecure file uploads and vulnerable dependencies. Pair this checklist with secure development practices and periodic testing. Our plain-language overview of the OWASP Top 10 is a good starting point for non-technical stakeholders.

Keeping it hardened

A server hardened once and then left alone will drift. Keep it secure with a light routine:

Weekly: review security alerts and failed login reports.
Monthly: confirm patches are applied, check user accounts, and test a backup restore.
Quarterly: review firewall rules, open ports, installed software and access lists against this checklist.
After every major change: re-run the checklist for the affected areas.

Using configuration management or scripted builds makes it easier to rebuild servers consistently and detect configuration drift.

Containers and cloud-specific considerations

Many web applications now run in containers or on managed cloud services. The same principles apply, with a few additions:

Use minimal, maintained base images and rebuild them regularly so security fixes are included.
Do not run containers as root unless absolutely necessary, and avoid mounting sensitive host directories into containers.
Keep secrets out of images and repositories; inject them at runtime from a secrets manager or protected environment configuration.
Restrict cloud management access with strong identity policies, multi-factor authentication and separate accounts for production and testing.
Review security groups and network rules in the cloud console, which can expose services even when the host firewall looks correct.
Enable audit logging for the cloud account itself, so changes to infrastructure are recorded as well as activity on the servers.

Prioritizing when time is limited

If you can only do a few things this week, start with the controls that block the most common attacks:

Key-based SSH with root login disabled and access restricted.
Operating system and application updates applied, with automatic security updates enabled.
Database and cache services closed to the public internet.
Debug mode off and .env and .git blocked from web access.
Off-site backups with a recent successful restore test.

These five items alone remove a large share of the real-world risk facing a typical web server.

Next steps

Use this list as a conversation starter with whoever manages your servers: which items are in place, which are partly done, and which are missing. DigiVort applies a documented hardening baseline to every server we manage through our hosting services, and our security and compliance team can audit existing environments and produce a prioritized remediation plan. Start a project to arrange a review.