Windows Server hardening checklist (practical, network side)

Most break-ins on Windows Servers do not need clever exploits. They walk through an open RDP port with a guessed password, an old SMB version or a firewall someone switched off "just for a test". This checklist covers exactly that side: what can be reached, who can log on, and whether you would notice.

1. Updates and a small attack surface

• Install security updates every month, including on Servers that "just run". Check Settings › Windows Update or Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5.
• Use a supported Windows Server version. Once support ends there are no more security updates.
• Install only the roles and features the Server needs. Review them with Get-WindowsFeature | Where-Object Installed. Server Core has fewer components to patch and attack.
• Remove software nobody uses: old remote tools (VNC, TeamViewer), test web servers, database engines from a past project.
• Switch off the Print Spooler on domain controllers and on Servers that do not print (Stop-Service Spooler; Set-Service Spooler -StartupType Disabled), as Microsoft recommends since PrintNightmare.

2. Windows Firewall: on everywhere, inbound blocked

• All three profiles on (Domain, Private, Public), with inbound blocked unless a rule allows it:

  Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction

  Expected: Enabled True, DefaultInboundAction Block (or NotConfigured, which means block).
• Check the network profile. A Server in a domain should show DomainAuthenticated in Get-NetConnectionProfile. A Server that falls back to Public after a restart suddenly gets different rules.
• Review allow rules with Remote address "Any". Every such rule is a door for the whole world if the port is forwarded or the Server has a public address.
• Delete rules for programs that no longer exist, especially in folders users can write to. Someone could put their own program there.

3. Open ports: close or scope them

List what is listening, with the program behind it:

Get-NetTCPConnection -State Listen | Sort-Object LocalPort |
  Select-Object LocalAddress, LocalPort, @{n='Program';e={(Get-Process -Id $_.OwningProcess).ProcessName}}

Listening is not the same as reachable: the firewall and your router decide that. For each port, ask: who really needs it, and from where?

Port	Service	Recommendation
3389	Remote Desktop	Never open to the whole internet. VPN, Remote Desktop Gateway, or the firewall rule's Remote IP address limited to your own addresses.
445, 139	SMB / file sharing	LAN only. Never forwarded from the internet.
135, 5985 / 5986	RPC, WinRM (remote PowerShell)	LAN or management network only.
1433, 3306, 5432	SQL Server, MySQL, PostgreSQL	Only from the application Servers that need them.
5900+	VNC	Remove, or reach it through a VPN only.

Also check your router or cloud security group for port forwardings nobody remembers.

4. RDP hardening

• Network Level Authentication on (System Properties › Remote › Allow connections only from computers running Remote Desktop with Network Level Authentication). The password is checked before a session is created.
• Only the people who need it in the Remote Desktop Users group; administrators are allowed by default, so keep that group small too.
• MFA for every remote access: VPN, Remote Desktop Gateway, Outlook on the web. A guessed or leaked password alone should not be enough.
• Log off disconnected sessions after a time limit (Group Policy: Remote Desktop Session Host › Session Time Limits).
• Changing the port from 3389 only hides it from the laziest scanners. It is not a protection on its own.

More on reading RDP attacks: Event ID 4625 and secure RDP without a VPN.

5. SMB and old protocols

• SMBv1 off. Check: Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol. Switch off: Set-SmbServerConfiguration -EnableSMB1Protocol $false. Since Windows Server 2019 it is not installed by default; older Servers often still have it. Make sure no old scanner or NAS still depends on it first.
• SMB signing on domain controllers and file Servers, following the Microsoft Security Baseline for your version.
• No anonymous shares, and share permissions as narrow as the NTFS permissions behind them.

6. Accounts and passwords

• A unique, long password for every local administrator. The same local admin password on all Servers lets an attacker move from one to all. Windows LAPS (built into current Windows and Windows Server versions) rotates and stores them for you.
• Separate admin accounts: no mail and web browsing with the account that administers the domain.
• No obvious user names for remote access. Attackers try administrator, admin, user first.
• Account lockout policy with care. It slows guessing, but an attacker can also lock out your real users. See Event 4740 and 4771.
• Service accounts with the least rights they need, or group managed service accounts (gMSA) where possible.

7. Logging: would you notice?

• Audit logons, success and failure, plus account lockout and account management. Check with auditpol /get /category:"Logon/Logoff". Use the Advanced Audit Policy, not the old nine categories, and do not mix the two.
• A bigger Security log. On a busy Server the default size is full within hours or days. Make it big enough to cover several weeks, or forward events to a central collector.
• Not too much either: auditing everything (e.g. Sensitive Privilege Use) can write dozens of events per second and slow the Server down without adding protection.
• Someone has to look. Logs nobody reads are only useful after the damage is done.

8. Backups that survive an attack

• At least one copy offline or immutable, not reachable with the domain admin password. Ransomware deletes the backups it can reach first.
• Test a restore regularly, including a full Server.

9. References

For the complete list of settings, use the CIS Benchmarks for Windows Server (cisecurity.org) and the Microsoft Security Baselines in the Security Compliance Toolkit. They cover hundreds of settings; this page covers the network and logon side that is attacked most often.

10. Keep it hardened: Coinetic checks and watches it for you

Doing this by hand means: running the checks above on every Server, understanding each result, and repeating it after every update, installer and colleague's "quick test", because a hardened Server does not stay hardened by itself. A firewall switched off on Friday or a new rule allowing everyone in is easy to miss until the logs show the damage.

Coinetic does the network side of this checklist with you, on every Windows Server and PC:

• A security check with plain explanations: open ports against the rules and profiles, risky settings, obsolete tunnels, duplicate rules and rules for programs that no longer exist. Every finding has a severity, an explanation and a fix: tick it, click Fix selected, and it can be undone.
• Every port open to the internet gets a decision: Coinetic closes it, or makes it invisible forever or until you unlock it from your phone. A port you keep open on purpose is watched, with every connection to it recorded.
• Visible at any time, not a one-off audit: the Open Ports page shows every open port, the program behind it and who can reach it through the firewall; the security check also runs in the background and notifies you when it finds a high risk.
• Firewall change watch: every 15 seconds Coinetic compares the firewall with what it saw before. If something switches the firewall off or sets a profile to allow all inbound, it alerts you and puts it back; a new rule that opens a port to any address is reported with the program that made it.
• Logging kept on: Coinetic keeps the audit settings and the Security log size it needs, and the security check reports audit settings that flood the log and slow the Server down.
• Password guessers and port scanners are banned automatically by a Windows Firewall rule, for RDP and Windows logons and more; your own network is never banned.
• Your AI security analyst (Pro + AI): right-click any line, ban, port or connection and choose Ask AI, e.g. “Which finding of the security check should I fix first, and why?”. It looks up this computer's Coinetic data itself and answers in plain words, with what to do on this machine.

More guides: all Coinetic guides.

Frequently asked

What is the most important Windows Server hardening step?

Not exposing Remote Desktop and SMB to the internet. Most attacks on Windows Servers start with password guessing on an open RDP port.

Is changing the RDP port enough?

No. Scanners find RDP on any port within minutes. Use a VPN or gateway, limit the rule to known addresses, and keep NLA and strong passwords.

Should I apply the whole CIS Benchmark?

Use it as the reference, but test before you apply it everywhere: some settings break older applications or remote management. Start with the network and logon items on this page.

How often should I check a hardened Server?

After every update, new software or change by a colleague, and at least monthly. Settings drift; a tool that watches continuously catches the changes in between.