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.

Week 4: Check the Documentation Gap

Pull your hardening standard — the written policy, the CIS benchmark profile you’re working toward, the SOC 2 control specification, whatever document says what a hardened server in your environment is supposed to look like. Then pull a real server sample, three to five systems across different roles, and check them against it, setting by setting.

This isn’t a vulnerability scan. You’re not looking for CVEs or missing patches. You’re looking for the gap between what the documentation says is configured and what’s actually configured.

Specifically, look for:

Settings the standard requires that aren’t in place
Password complexity, audit logging scope, account lockout thresholds, service restrictions — pick any section of your hardening standard and check whether the servers you sampled actually reflect it. In environments with active change management and drift detection, there’s usually a small gap. In environments running manual processes, the gap is frequently larger than anyone expected.

Approved exceptions that were never formally logged
An exception to the standard might have been granted in a conversation, in a ticket that’s since been closed, or not at all. If a setting doesn’t match the standard and there’s no exception record, that setting is either unauthorized drift or an undocumented exception — neither of which looks good in an audit.

Settings that matched the standard at build time but drifted since
This is the most common finding, and the least visible. A server was built correctly against a baseline in 2022. Patches were applied. Applications were installed and updated. Support sessions happened. Two years later the configuration has moved, but the documentation still describes the 2022 state. Nobody updated either one.

Documentation that describes intent, not implementation
Watch for standards written at a level of abstraction that can’t actually be audited — “remote access shall be secured” rather than “SSH PermitRootLogin no, PasswordAuthentication no, Protocol 2.” If the standard can’t be checked against a real server setting, it’s a policy document, not a hardening standard. That’s a documentation problem to fix before the next audit cycle.

How to run this check

On Linux, pull the settings most commonly specified in hardening standards and compare them to your documentation line by line:

• /etc/ssh/sshd_config — PermitRootLogin, PasswordAuthentication, MaxAuthTries, ClientAliveInterval
• /etc/pam.d/common-password or /etc/security/pwquality.conf — password complexity and history requirements
• /etc/audit/auditd.conf and audit rules — what’s being logged versus what your standard says should be logged
• systemctl list-unit-files --state=enabled — services running versus services your standard permits
• /etc/sudoers and /etc/sudoers.d/ — compare scope of sudo access to what’s documented as authorized

On Windows, check resultant security policy against your standard directly:

• Run secedit /export /cfg baseline_check.cfg and compare the output to your documented settings for password policy, account lockout, audit policy, and user rights assignments
• Run Get-GPResultantSetOfPolicy to see what’s actually applied versus what the GPO is supposed to deliver — these sometimes diverge after manual changes
• Check installed software and enabled features against your standard’s permitted-applications list, if you maintain one

What to do with the gap

Most teams find two categories of discrepancy. The first is straightforward: the server is wrong and the documentation is right, so the server needs to be brought back into compliance. The second is more complicated: the documentation was written for an environment that no longer exists, and the servers have been correctly adjusted along the way while the documentation stayed behind. Both categories need remediation, but they’re different kinds of remediation — one is a configuration change, the other is a documentation and approval exercise.

Either way, you now have a prioritized list of items that are either out of compliance or inadequately documented. That list is more useful than a general sense that “things are probably fine.”

If you ran the baseline snapshot from Week 1, compare this week’s findings against it too. Discrepancies between your documentation, your baseline, and the current state tell you whether the gap is new or has been there for a while.

Week 5: Look for Drift, Not Just Vulnerabilities

Patch management and vulnerability scanning can tell you if there are known weaknesses with available fixes. However, they can’t always tell you if a server’s configuration moved from the baseline it was built to match. Patch management and vulnerability scanning can tell you if there are known weaknesses with available fixes. However, they can’t always tell you if a server’s configuration moved from the baseline it was built to match. That gap has a name: configuration drift. [We covered the topic in depth in our webinar, Drift Happens]

Your servers can show up clean on a vulnerability scan, and that’s good news. But a clean scan doesn’t mean your configuration is still aligned to your baseline. For auditors reviewing against a CIS Benchmark or a HIPAA or FFIEC control set, those are two different checks, and passing one doesn’t cover the other.

What to check this week

Go back to the baseline from Week 1. For each server in your sample, look for settings that have changed since you took the snapshot. A setting may have changed a support session, an application install, a one-off fix, an access change. Quite possibly, its something an IT technician intended to revert back or switch and then didn’t. Ask if the change was documented, approved, and if its ok the way it is now.

On Linux:

• Compare current enabled services against the Week 1 snapshot — systemctl list-unit-files --state=enabled
• Check listening ports against the snapshot — ss -tulpn
• Review sudoers for entries that weren’t there in Week 1
• Check SSH config for any changes since the baseline — sshd_config

On Windows:

• Run secedit /export /cfg current.cfg and diff against the Week 1 export
• Check scheduled tasks against the snapshot — Get-ScheduledTask
• Review local group membership against Week 1 — Get-LocalGroupMember -Group Administrators

For any setting that changed, the question isn’t whether the change was patching-related. It’s whether the change was expected, documented, and still needed.

Where this surfaces in audits

Auditors running configuration reviews against a CIS Benchmark or another control set are checking settings, not patch levels. A server with a clean vulnerability scan and undocumented configuration drift will still generate findings. The vulnerability scan and the configuration review are two different exercises, and passing one doesn’t cover the other.

If your Week 1 baseline is in reasonable shape, this week’s check should be straightforward. If you haven’t taken one yet, this is a good week to start there are still three weeks left in the series.

Week 6: Review the Rollback Plan

Hardening projects stall for a lot of reasons. Not knowing how to roll back a change is near the top of the list.

A hardening change applied to a production server can affect running applications, authentication, network connectivity, or services that depend on specific configuration states. Getting it wrong with no clear path back is enough to keep legitimate hardening work sitting in a backlog for months. The fear of not knowing how to rollback a change keeps IT teams from making the changes in the first place.

Therefore, it’s necessary to answer the rollback question before the change goes anywhere near production.

Three things to have in place before making hardening changes

Use a hardening solution with rollback ability built in. Testing in a separate non-production environment is a common solution, but its expensive and time consuming. The more reliable answer is a hardening tool that includes rollback as a core capability so you can apply a change, and revert it from the same place you made it, without a separate testing environment or a manual backup procedure.

Stage the rollout. Apply the change to a small group of servers before the full environment. If something unexpected breaks, the damage is limited and there’s less to roll back.

Don’t consider rollback a not failure and don’t be afraid to use it. Even well-planned hardening changes can have unexpected effects on production systems. Knowing how to reverse a change before you make it isn’t pessimism. Things go wrong. Having a tested or built-in rollback procedure means things going wrong doesn’t have to mean things staying wrong.

What this looks like in practice

On Linux, for a change to SSH configuration:

• Back up the current config before touching it: cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
• Test the new config before restarting the daemon: sshd -t
• Keep an existing session open while testing the new one — don’t restart SSH and close your only connection at the same time
• Document the exact revert command: cp /etc/ssh/sshd_config.bak /etc/ssh/sshd_config && systemctl restart sshd

On Windows, for a Group Policy change:

• Document the current resultant policy before the change: secedit /export /cfg pre_change.cfg
• Test in a separate OU with a small pilot group before linking to production
• Know which GPO to unlink or which setting to revert, and have it written down before the change window opens

Fear of breaking things is one of the main reasons hardening work stays theoretical. A change you can undo confidently is a change you can actually make.

Week 7: The Later List

Every team has one, and some are impressively long. The tasks that have been deferred, delayed, or otherwise put off. Whether its the baseline cleanup that got deprioritized in June, the old exceptions nobody has revisited or an unsupported system still running because replacing it is a whole project, or even a full hardening initiative that has been “next quarter” for two quarters running.

Welcome to, “The Later List,” where important and well-intentioned projects go to die.

The risk of course is when “later” quietly becomes “never,” and nobody noticed.

This week’s check is simple: write down what’s on your Later List. A deferred item with a name and an owner is a very different thing from a vague sense that there’s something you’ll deal with eventually. This isn’t the most technical part of your summer hardening project. But it may be the most important because of how it starts to change the culture around hardening work long term. Teams that name their deferred items, own them, and make deliberate decisions about them are the ones that don’t end up with the same list a year from now.

Common things that end up on the list:

• Exceptions approved during a crunch that were never reviewed afterward
• Hardening changes tested but never promoted to production
• Baseline documentation that hasn’t been updated since last year
• Audit evidence that exists somewhere but hasn’t been organized
• Systems past end of life that are still running because the replacement project keeps slipping

If it’s on your Later List, it’s already a risk. Writing it down is the first step to deciding what to do about it.

Week 8: Did You Know Everything That Changed?

Eight weeks ago, the first task was simple: take a snapshot of one server group and put it somewhere you’d find again.

If you did it, this is the week to pull it out. Compare it to what’s running now. For every difference, ask yourself three questions –

1. Was the change expected, or were you surprised by it?
2. Is the change fully documented? (and could you explain it to an auditor?)
3. Should it be approved, rolled back, or investigated?

Most teams find more changes, more drift, than they anticipated, even over a relatively quiet summer. That’s not a judgement about a team’s process. It’s what happens to configurations when nobody is actively watching it — it drifts, in small increments, until a comparison like this one makes the total visible all at once.

What to look at

On Linux, compare your current state against the Week 1 snapshot:

• User and group accounts — any additions, removals, or privilege changes
• Sudoers configuration — anything broader than it was in June
• SSH config — any settings that moved
• Enabled services and listening ports — anything running that wasn’t there before
• Firewall rules — any additions that were never removed

On Windows:

• Run secedit /export /cfg current.cfg and diff against your Week 1 export
• Compare local group membership, especially local Administrators
• Check scheduled tasks against the snapshot
• Review installed software for anything added since June

What to do with what you find

Sort your findings into three buckets:

• Expected and documented – a change that was planned, approved, and recorded. No action needed beyond confirming the record is complete.
• Expected but undocumented – a change that happened for a legitimate reason but nobody wrote it down. Document it now, and figure out why the process didn’t catch it.
• Unexpected – a change with no clear origin. This is your priority list. Start with privileged access changes and network-facing configuration, and work from there.
  

The first bucket is housekeeping. Confirm the record is complete and accurate and move on.

The second bucket is a process conversation. The change was legitimate but nobody wrote it down. The goal should be to find out why and what’s missing in your internal process. Was there a ticket or review step? No one responsible for closing the loop? Fix the gap in your work flow, in addition to the record.

The third bucket is where you spend your time. Unexpected changes to privileged access, network-facing configuration, or authentication settings are your first priority. For each one, find out when it happened, who made it, and whether it needs to be rolled back or formally approved. If you can’t answer those questions, that’s the finding.

Most teams work through the first two buckets quickly. The third one is where the summer check really demonstrates its own importance, because those are the changes that would have stayed invisible without a comparison to go back to.

What to do next

Repeating this 8-week project this as an annual summer project is a good idea. It will help your organization stay secure in the long run. But what actually keeps configuration under control isn’t just a yearly check, it’s continuous monitoring. Knowing when something changes the day it happens, not when you remember to look.

The manual version of what you’ve been doing for eight weeks, including the steps of snapshot, compare, investigate, document is exactly what configuration drift monitoring automates. If your team found more than you expected this summer, that’s a reasonable moment to ask whether doing this by hand every few months is the right long-term answer.

CalCom Hardening Suite monitors your environment against your approved baseline continuously, flags unauthorized changes as they happen, and generates the remediation evidence your auditors expect. If the summer check surfaced a backlog you’d rather not repeat next year, that’s what it’s built for.

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