Server Hardening Checklist: 8 Weekly Checks to Reduce Configuration Drift

Summer is a good time to catch up on hardening work that gets postponed the rest of the year. Change freezes ease up, project calendars thin out, and the servers that quietly drifted out of spec during Q1 and Q2 finally get some attention.

Over the next eight weeks, we’re publishing one practical hardening review each week. None of these require a project plan or a change advisory board meeting. They’re checks you can run against your own environment, on your own schedule, using tools you probably already have.

Whether you’re managing ten servers or ten thousand, a few minutes a week now beats a scramble before an audit later.

Week 1: Take a Baseline Snapshot

Week 1: Take a Baseline Snapshot

You can’t spot drift without a reference point. This week is about capturing one.

Pick a representative sample of production servers — enough to cover your major OS versions, roles, and network zones. You don’t need every host, and you don’t need to review every setting line by line yet. You’re building a snapshot to diff against later.

What to capture, at minimum:

Linux:

• User and group accounts, including UID 0 members and any accounts with nologin shells that shouldn’t have them
• Sudoers configuration (visudo -c to validate syntax, then export the resolved ruleset)
• SSH daemon config (sshd_config — pay attention to PermitRootLogin, PasswordAuthentication, and AllowUsers/AllowGroups)
• Listening services and ports (ss -tulpn or netstat -tulpn)
• Enabled services (systemctl list-unit-files --state=enabled)
• Cron jobs and systemd timers across all accounts, not just root
• Firewall rules (iptables-save, nft list ruleset, or your cloud security group config)
• Installed package versions and patch level

Windows:

• Local group membership, especially local Administrators (Get-LocalGroupMember -Group Administrators)
• Applied GPOs and resultant security policy (Get-GPResultantSetOfPolicy or secedit /export /cfg)
• Scheduled tasks (Get-ScheduledTask)
• Listening ports and owning processes (netstat -ano)
• Local security policy settings — password policy, audit policy, user rights assignments
• Installed software and patch level (Get-HotFix, WSUS/SCCM reporting)

If you’re already running CIS-CAT, OpenSCAP, or Chef InSpec, this is a good week to run a full scan and archive the output rather than starting from scratch. If you’re not, a scripted export using the commands above, saved to source control or a version-controlled share, works as a starting point.

The point of this week isn’t a perfect inventory. It’s a timestamped reference you can compare against as the summer goes on. When you look at that reference in Week 3 or Week 6, you’ll be asking:

• What changed?
• Why did it change?
• Was the change intentional?
• Should it still be there?

Even in well-run environments, this baseline tends to surface things nobody remembers approving — a debug flag from a troubleshooting session, a firewall rule opened for a vendor call six months ago, a service account that picked up admin rights during a migration and never lost them.

Week 2: Find the Temporary Fixes

Now compare this week’s state against the baseline from Week 1.

You’re looking specifically for changes that trace back to troubleshooting, vendor support sessions, audits, or urgent deployments — the category of change that gets made under pressure and rarely gets revisited once the pressure is off.

Common examples:

• A firewall rule opened to a vendor’s IP range for a support session that ended weeks ago
• A service account added to a privileged group during a migration or cutover
• Debug or verbose logging left enabled on a production system
• PasswordAuthentication re-enabled on SSH to work around a key distribution issue
• A WAF or IDS rule set to alert-only instead of block, to unblock a deployment
• TLS configuration temporarily loosened to accommodate a legacy client or integration

For each one you find, run it through three questions:

• Is it documented — is there a change ticket, an approval, a reason on record?
• Is it still needed — does the underlying issue it solved still exist?
• Is it still approved — would it pass review today, or was the approval scoped to a specific window that’s already closed?

Temporary changes almost never cause a problem on the day they’re made. They cause problems months later, when the person who made the change has moved teams, the ticket (if there was one) is closed and forgotten, and an auditor or an attacker finds it first.

If your change management process ties tickets to specific hosts and settings (ServiceNow, Jira Service Management, or similar), Week 2 is a good week to cross-reference: for every drifted setting you find, look for a corresponding ticket. Settings with no matching ticket are your highest-priority review items.

Week 3: Review Administrative Access

This week has two parts: who has admin rights, and what your service accounts and privileged groups are doing with theirs.

Human accounts. Pull a current list of accounts with administrative access across your servers — domain admin, local admin, root and sudo access — and check it against who actually needs that access for their current role. The usual findings: contractors whose engagements ended, employees who changed teams, and admin rights granted “just for this one project” that never got revoked.

Also check for:

• Local accounts on individual servers that exist outside your central identity provider — easy to miss because they don’t show up in an Active Directory or IAM export
• Shared or generic admin accounts still in use. If you can’t tie a privileged action to a specific person, that’s a finding an auditor will make for you
• MFA enforcement on privileged access specifically. It’s common to have MFA enforced org-wide for standard logins but gaps on service consoles, out-of-band management interfaces, or break-glass accounts

Service accounts. These don’t get logged into interactively, so nobody notices when their privileges creep. For each one, check:

• What it can actually do, versus what it needs to run. A monitoring agent with domain admin, a backup account with write access it only needed for one migration, a database service account still holding sysadmin from a troubleshooting session — these accumulate quietly
• Where it can log in from. Service accounts with interactive logon rights, or that can authenticate from any host instead of the specific systems they run on, are a common finding
• Whether the password ever rotates. Many are set up once with “password never expires” checked and never revisited

On Linux, check for service accounts with a valid shell (/bin/bash instead of /usr/sbin/nologin) and sudoers entries scoped to a service account rather than a person. On Windows, review “Log on as a service” rights under local security policy and check Get-ADServiceAccount or your credential vault’s rotation logs.

Stay Tuned

We’ll publish a new Summer Hardening Check every week through the summer. Follow our LinkedIn page to catch each one as it goes up.

Why Go It Alone?

Doing this manually works, but it takes recurring time, disciplined documentation, and someone remembering to actually run the comparison every week. That last part is where most manual drift-tracking efforts quietly stop.

CalCom Hardening Suite continuously monitors your environment against your approved security baselines, flags unauthorized changes as they happen, and helps you remediate drift before it turns into a security gap or an audit finding. It’s built for server and system hardening specifically — baseline definition, drift detection, and remediation evidence. It’s not a full GRC platform, and it won’t manage your broader compliance program end to end. What it does is make sure the hardening layer underneath that program stays where you set it.

Schedule a demo to see how CalCom Hardening Suite automates baseline monitoring and gives you the evidence your auditors expect.