Marho Atumu Key takeaways
- Server hardening reduces attack surface by limiting access, ports, software, and risky changes.
- Windows and Linux need similar controls, but the tools and setup steps differ.
- Access, patching, firewall rules, remote access, logs, and backups need regular review.
- Server hardening should reduce risk without breaking critical systems.
Server hardening is a specific part of system hardening that focuses on reducing the ways attackers can access, exploit, or disrupt a server. It applies to Windows, Linux, cloud, dedicated, VPS, and other server environments.
A good server hardening checklist should make systems safer while keeping them usable. The goal isn’t to lock everything down so tightly that normal work breaks. It’s to reduce risk, document changes, and keep critical systems protected.
What is server hardening?
Server hardening is the process of applying security-focused configuration changes to Windows or Linux servers.
Common server hardening tasks include removing unnecessary software, closing unused ports, disabling unused services, applying patches, securing remote access, monitoring logs, encrypting data, and testing backups.
Windows vs Linux server hardening
The main hardening principles are similar across Windows and Linux, but the tools differ.
| Hardening area | Windows examples | Linux examples |
| User access | Local users, Active Directory, Group Policy, RDP settings | Local users, sudoers, SSH keys, PAM settings |
| Firewall | Windows Defender Firewall | firewalld, iptables, nftables, ufw |
| Updates | Windows Update, WSUS, Microsoft baselines | Package managers like apt, yum, dnf, zypper |
| Encryption | BitLocker | LUKS, dm-crypt |
| Logging | Event Viewer, Windows Event Forwarding, SIEM | syslog, journald, auditd, SIEM |
| Benchmarks | Microsoft Security Baselines, CIS Benchmarks | CIS Benchmarks, distribution-specific guidance |
These server hardening checklist items are broad strokes that apply to Windows, Linux, and other types of servers. If you want a detailed breakdown, the NIST and CIS benchmarks have the resources you need.
16 key tips to know
Server hardening works best when it’s handled in a careful, step-by-step way. Use these tips to reduce unnecessary risk, protect critical access, and make your Windows or Linux server easier to manage over time.
1. Back up the server before hardening changes
Hardening can affect logins, firewall rules, services, applications, and remote access. Before making major changes, take a backup or snapshot and confirm you have a rollback plan.
Your backup plan should include:
- System backups
- Configuration backups
- Application and database backups
- Change documentation
If applied too quickly, a hardening change can block valid users, break an application, or interrupt a service. Backups and rollback steps give your team a safer path if something goes wrong.
2. Audit user accounts and permissions
Review all user accounts and permissions regularly. Disable unused accounts, remove former employees and vendors, and avoid shared admin accounts.
Hardening tasks should include:
- Disable or rename default accounts where appropriate
- Disable guest accounts
- Remove inactive users
- Revoke access for former employees and vendors
- Avoid shared administrator accounts
- Review privileged groups
- Use least privilege
- Use separate admin accounts for administrative work
For Windows, review local administrators, domain admins, and Group Policy. For Linux, review root login, sudo access, and service accounts.
3. Enforce MFA and strong password policies
A strong password policy should include length, complexity, password history, and account lockout after repeated failed login attempts.
Enable MFA for all accounts, especially accounts with administrative privileges.
Where MFA applies will depend on your environment. Review SSH, RDP, VPNs, cloud panels, identity providers, and control panels to confirm where it can be enforced.
4. Secure remote access
Remote access is a common attack target, so it should be tightly controlled.
Review these remote access tasks:
- Avoid exposing SSH or RDP directly to the public internet when possible
- Use VPNs, secure bastion hosts, or jump servers
- Restrict access by IP where appropriate
- Disable password-based SSH login when using key-based access
- Change default ports only as a supporting control
- Limit who can connect remotely
- Monitor remote login attempts
For Windows servers, review RDP and Network Level Authentication settings. For Linux servers, review SSH configuration, key management, and sudo access.
5. Configure firewalls with default-deny rules
Default-deny means blocking inbound traffic by default and allowing only required services.
Review:
- Perimeter firewalls
- Host-based firewalls
- Allowed inbound ports
- Outbound traffic where appropriate
- IP allowlists
- Network segmentation
- Firewall rule documentation
- Regular rule reviews
Only open ports that the server needs to do its job.
6. Close unused ports and disable unnecessary services
Unused ports, services, roles, and daemons create unnecessary exposure.
Review:
- Listening services
- Unused services
- Unnecessary server roles
- Legacy protocols
- Open ports after deployments
- Services added by new software
For Windows, review unnecessary roles, SMB exposure, and unused remote services. For Linux, review unused daemons and package services.
7. Remove unnecessary software and packages
Every installed application can add vulnerabilities, dependencies, and update requirements.
Remove software that the server doesn’t need, including:
- Unused applications
- Unnecessary utilities
- Unused language runtimes or packages
- Old third-party tools
- Software installed “just in case”
Keep required packages updated and document what is installed.
8. Patch the operating system and third-party software
Patching closes known security vulnerabilities, but updates should be tested so they don’t break production workloads.
Patch management should include:
- OS updates
- Security patches
- Kernel updates
- Third-party software updates
- Web server, database, and runtime updates
- Staging or testing where possible
- Maintenance windows
- Rollback plans
9. Encrypt data in transit and at rest
Use secure protocols for data in transit, including HTTPS, SSH, SFTP, and VPN connections where appropriate. Avoid legacy, unencrypted protocols like Telnet and FTP.
For data at rest, use full disk encryption or other encryption methods where the workload requires it. Examples include BitLocker for Windows and LUKS or dm-crypt for Linux.
Also review:
- Backup encryption
- Database encryption where appropriate
- Secure certificate management
- Key rotation
- Secure key storage
10. Secure removable media and boot settings
This step applies most to physical, dedicated, and colocation environments.
Review:
- Restrict boot from USB or external media
- Set BIOS or UEFI passwords where appropriate
- Disable or restrict USB storage when possible
- Control physical access to servers
- Use secure boot where supported
For critical systems, physical access should be treated as part of the security plan.
11. Configure logging, auditing, and monitoring
Hardening also means knowing what is happening on the server.
Monitor and audit:
- Login attempts
- Account lockouts
- Privilege changes
- Service changes
- Firewall changes
- File changes
- Object access
- Security events
- Application errors
- Disk, CPU, memory, and network alerts
Windows teams may use Event Viewer, Windows Event Forwarding, and SIEM tools. Linux teams may use syslog, journald, auditd, and SIEM tools.
12. Centralize logs and protect log data
Local logs may be deleted or altered after a compromise. Sending logs to a remote syslog server, SIEM, or centralized logging tool can help preserve evidence and make investigation easier.
Review:
- Remote log storage
- SIEM integration
- Alert routing
- Log retention
- Log access controls
- Sensitive data handling
Logs can contain technical details and sensitive operational information, so access should be limited to the right people.
13. Monitor configuration drift
Hardening can weaken over time as users, software, firewall rules, server roles, and settings change.
Use trusted baselines and recurring reviews to catch configuration drift.
Helpful resources may include:
- CIS Benchmarks
- Microsoft Security Baselines
- NIST guidance
- File integrity monitoring
- Baseline reviews
- Change documentation
The goal is to confirm the server still matches the secure configuration you intended.
14. Harden applications and services running on the server
Server hardening should include the applications running on the server, not just the operating system.
Review:
- Web servers
- Databases
- Control panels
- CMS or ecommerce platforms
- API services
- Mail services
- Application permissions
- Secrets and configuration files
- Dependency updates
Keep application-level hardening on the same review schedule as OS-level hardening.
15. Review hosting responsibilities
Server hardening responsibilities can vary based on the hosting environment and support level. Some hosting providers handle certain hardening tasks, such as patching, monitoring, backups, or server configuration support, while others leave more of that responsibility to the customer.
| Environment | Hardening considerations |
| Self-managed server | Customer typically manages the OS, applications, firewall rules, updates, monitoring, backups, access controls, and other server-level hardening tasks. This may include self-managed VPS or dedicated servers. |
| Managed server | Provider may handle more patching, monitoring, backups, and server configuration support, while the customer may still be responsible for application-level security, access management, and account-specific settings. This may include managed VPS or dedicated servers. |
| Cloud hosting | Customer and provider typically share responsibilities across the OS, network, identity, storage, and application layers. The exact division depends on the cloud platform, service model, and support plan. |
16. Test hardening changes before production
Hardening changes can block legitimate access or break application workflows if applied too quickly.
Use a safer change process:
- Test in staging first
- Apply changes in small batches
- Document what changed
- Confirm application functionality
- Confirm admin access still works
- Keep rollback steps ready
- Monitor after changes
Server hardening cadence
| Cadence | Tasks |
| Daily or ongoing | Monitor alerts, login attempts, critical logs, backups, and resource issues |
| Weekly | Review firewall changes, failed login patterns, software updates, open ports, and service status |
| Monthly | Review users, permissions, patch status, backup restores, and configuration drift |
| Quarterly | Review baselines, hardening policies, remote access, recovery plans, and audit settings |
| After major changes | Recheck firewall rules, exposed services, user access, monitoring, backups, and rollback plans |
Server hardening checklist FAQs
Server hardening checklist next steps
Server hardening reduces risk by limiting access, removing unnecessary services, patching systems, securing remote access, monitoring logs, and protecting backups.
Start by backing up the server, reviewing admin access, checking open ports, and applying outstanding security updates before moving into deeper baseline work.
Server hardening works best when the hosting environment, support model, and security controls fit the workload. Liquid Web offers managed hosting, dedicated servers, cloud hosting, and colocation options with the support teams need to run safer, more reliable environments. Explore Liquid Web hosting solutions to find the right fit.