Windows Hardening in Practice: A Hands-On Journey with Microsoft Defender Firewall and IIS Security

When people first hear "Windows hardening," it often sounds abstract — policies, controls, frameworks, and a lot of theory. But in practice, it's much more concrete: you are simply reducing attack surface, controlling access, and removing information that attackers could use.

In this walkthrough, I'll break down a practical Windows hardening exercise using Microsoft Defender Firewall and IIS (Internet Information Services). The goal is not just to "secure a system," but to understand why each control matters from an attacker's perspective.

1. Thinking Like an Attacker: Why Hardening Matters

Before applying any controls, it helps to understand the attack surface:

Open ports = entry points
Exposed services = potential vulnerabilities
Misconfigurations = easy wins for attackers
Information leakage = recon advantage

Most real-world attacks don't start with zero-days — they start with exposed services and weak configurations.

That's where Windows hardening comes in.

2. Microsoft Defender Firewall: Controlling What Comes In

One of the most effective host-based defenses in Windows is the Windows Defender Firewall with Advanced Security.

Instead of treating all traffic equally, it lets you define exactly what is allowed.

🔹 Service-Specific Controls

We started by controlling services based on ports:

Allow FTP (TCP 21) for required business use
Block MSRPC (TCP 135) due to high risk exposure

This is called service-specific firewall control — you are directly deciding which services are reachable.

👉 Think of it as: "Which doors should exist in the first place?"

🔹 Profile-Based Access Control: Trusting the Network You're On

Windows Firewall introduces a powerful concept called network profiles:

Domain → Corporate trusted environment
Private → Home or trusted network
Public → Untrusted networks (cafés, airports, guest Wi-Fi)

We used this concept to refine access:

FTP allowed only on Domain profile
MSRPC blocked on Public profile

This is not about ports anymore — it's about trust level of the network itself.

👉 Think of it as: "Even if the door exists, when should it be open?"

🔹 IP-Based Restrictions: Enforcing Network Boundaries

Next, we hardened Remote Desktop (RDP).

Instead of allowing global access, we restricted it:

RDP allowed only from a corporate subnet (e.g., 192.168.10.0/24)

This is scope-based firewall control, which is different from profiles.

👉 Now we're asking: "Who exactly is allowed to knock on this door?"

This introduces network segmentation principles at the host level.

3. Attack Surface Reduction in Action

By combining:

Service-specific controls (ports/services)
Profile-based restrictions (Domain / Public / Private)
IP-based scope restrictions (corporate subnet)

We effectively reduced:

Unnecessary service exposure
External accessibility
Lateral movement opportunities

This is classic attack surface reduction and least privilege access in action.

4. IIS Hardening: Removing Information an Attacker Doesn't Need

Hardening isn't only about blocking access — it's also about hiding unnecessary details.

We applied several IIS security controls:

🔹 Removing X-Powered-By Header

This hides backend technology details like ASP.NET.

Why it matters:

Reduces fingerprinting
Slows attacker reconnaissance

🔹 Disabling Directory Browsing

Instead of listing files in a folder:

/samples/
→ sample1.txt
→ backup.zip

/samples/
→ sample1.txt
→ backup.zip

We disabled directory browsing so attackers cannot map the application structure.

🔹 Custom Error Messages

Instead of verbose stack traces:

No file paths
No framework versions
No internal code references

Attackers see only generic messages.

👉 This prevents information leakage during exploitation attempts.

🔹 Content Security Policy (CSP)

We added:


default-src 'self';


default-src 'self';

This ensures the browser only loads content from the same origin.

Impact:

Blocks malicious external scripts
Reduces XSS impact
Strengthens browser-side security

5. Identity and Access Management: Securing Administrative Accounts

Not every vulnerability can be fixed by closing a port or changing a web server setting. Sometimes the easiest path for an attacker is through weak credentials.

During the lab, I remediated a finding related to default or weak administrative credentials by using Local Users and Groups Manager (lusrmgr.msc) to review local accounts and strengthen password security.

This highlighted an important security lesson:

"Attackers don't always need to exploit a vulnerability if they can simply log in."

By enforcing stronger passwords for administrative accounts, I reduced the risk of:

Brute-force attacks
Password guessing attacks
Unauthorized administrative access

While firewall and IIS hardening focused on controlling network access and reducing information exposure, this remediation focused on Identity and Access Management (IAM) — protecting the accounts that have privileged access to the system.

Just as we restricted who could connect to services, we also strengthened who could authenticate to the server, reinforcing the principle of least privilege and secure access control.

6. Vulnerability Management Perspective

All of these controls map directly to the vulnerability management lifecycle:

Identify → scanning and reporting findings
Evaluate → risk, severity, exploitability
Prioritize → focus on high-impact issues taking into account prioritization based on vulnerability criticality, asset sensitivity, threat landscape and profile of the organization, and the business objectives.
Remediate → firewall rules, IIS hardening, configuration changes
Report → document security improvements

In this lab, remediation wasn't theoretical — it was practical configuration work.

7. Key Security Concepts You Actually Practiced

This exercise wasn't just about tools — it covered real security principles:

Least privilege access
Attack surface reduction
Network segmentation principles
Information disclosure prevention
Secure configuration management
Host-based firewall enforcement
Web server hardening

Final Thoughts

Windows hardening is not about making systems "fully secure" — that doesn't exist. It's about making systems harder to exploit, slower to attack, and less informative to an attacker.

Every firewall rule, every header removal, every disabled feature is one more obstacle in an attacker's path.

And in cybersecurity, obstacles are everything.

Contents