Unlock The Secrets Of Simulation Lab 9.2: Module 09 Configuring Defender Firewall‑Ports – Don’t Miss This!

Ever tried to set up a Windows Defender Firewall rule and felt like you were speaking a foreign language?
You click through a dozen dialogs, stare at cryptic port numbers, and wonder whether you just opened a back‑door for every hacker on the planet.

That’s the exact moment the Simulation Lab 9.2 – Module 09 on configuring Defender firewall ports was born. It’s the hands‑on part of the course where theory finally meets the “real‑world” screen you’ll be staring at every day.

If you’ve ever been stuck on that lab, or you’re just curious how to lock down ports without locking yourself out, keep reading. This guide walks you through what the lab expects, why each step matters, and the shortcuts most students miss Nothing fancy..

What Is Simulation Lab 9.2: Module 09 Configuring Defender Firewall‑Ports

In plain English, this lab is a sandbox inside the Microsoft Learn environment that forces you to create, modify, and test Windows Defender Firewall rules for specific TCP and UDP ports.

The lab’s scenario is simple: a fictional company, Contoso Tech, runs a web server on port 80, an internal database on port 1433, and a remote management tool on port 3389. Your job?

• Allow the web traffic,
• Block the database from the internet, and
• Restrict remote desktop to the IT subnet only.

You do all of that using the built‑in Windows Defender Firewall with Advanced Security snap‑in, PowerShell cmdlets, and a few command‑line utilities to verify the results Worth knowing..

The Core Pieces You’ll Touch

• Inbound Rules – where you tell the OS what traffic to let in.
• Outbound Rules – often overlooked, but crucial when you don’t want a compromised machine calling home.
• Profiles (Domain, Private, Public) – each profile can have a different rule set, mirroring how a laptop behaves at home vs. the office.
• Port Numbers & Protocols – the “numbers” that actually move the data.

If you’ve never opened the wf.msc console, now’s the time. It’s the visual hub for everything you’ll be doing in the lab.

Why It Matters / Why People Care

You might wonder: “Why spend an entire lab on firewall ports? I can just click ‘Allow’ and be done.”

First off, ports are the front doors of a computer. In practice, open the wrong one and you hand a burglar a key. In practice, a mis‑configured rule is the #1 cause of data breaches in small‑to‑medium businesses.

Second, many compliance frameworks—PCI‑DSS, HIPAA, ISO 27001—explicitly require documented firewall configurations. If you can’t prove you only opened ports 80 and 443 for web traffic, an auditor will raise a red flag That alone is useful..

Finally, the lab teaches you to audit your own rules. Consider this: that skill pays off when you inherit a server that’s been “firewalled” by a well‑meaning but clueless admin. You’ll know exactly how to spot a rogue rule that allows “any” inbound traffic on “any” port It's one of those things that adds up..

How It Works (or How to Do It)

Below is the step‑by‑step workflow that the lab expects. Feel free to deviate once you get the hang of it, but follow this path if you want that perfect “Pass” badge That alone is useful..

1. Open the Firewall Console

• Press Win + R, type wf.msc, hit Enter.
• You’ll see three panes: Overview, Inbound Rules, Outbound Rules.

2. Create an Inbound Rule for HTTP (Port 80)

1. Right‑click Inbound Rules → New Rule…
2. Choose Port, click Next.
3. Select TCP, enter 80 in the Specific local ports box.
4. Click Next, pick Allow the connection.
5. Choose the profiles you want—typically Domain and Private for a corporate web server.
6. Name it “Contoso‑Web‑HTTP” and finish.

Pro tip: Add a description like “Allows inbound HTTP for public website” so future admins know the purpose The details matter here..

3. Block the SQL Server Port (1433) from the Internet

1. New Inbound Rule → Port → TCP, enter 1433.
2. This time select Block the connection.
3. Apply the rule only to the Public profile.
4. Name it “Block‑SQL‑Public”.

Why only Public? Because the database should still be reachable from the internal network (Domain profile). The lab checks that the rule’s scope is set correctly Not complicated — just consistent..

4. Restrict Remote Desktop (3389) to IT Subnet

1. New Inbound Rule → Port → TCP, 3389.
2. Choose Allow the connection.
3. In the Scope step, under Remote IP address, click These IP addresses and add the IT subnet, e.g., 10.0.1.0/24.
4. Apply to Domain and Private profiles.
5. Name it “RDP‑IT‑Only”.

If you skip the Scope step, you’ll open RDP to the whole world—big no‑no.

5. Verify with PowerShell

Open PowerShell as admin and run:

Get-NetFirewallRule -DisplayName "*Contoso*" | Get-NetFirewallPortFilter

You should see three entries with the correct ports and actions.

Next, test connectivity:

Test-NetConnection -ComputerName localhost -Port 80   # should be open
Test-NetConnection -ComputerName localhost -Port 1433 # should be blocked on Public profile
Test-NetConnection -ComputerName localhost -Port 3389 -RemoteAddress 10.0.1.45 # should be open

If any test fails, double‑check the profile assignments Nothing fancy..

6. Export the Policy (Optional but Handy)

Export-WindowsFirewallRules -FilePath "C:\Temp\ContosoFirewall.wfw"

The lab sometimes asks you to submit the exported file as proof that the rules exist Nothing fancy..

Common Mistakes / What Most People Get Wrong

1. Mixing up Profiles – newbies often tick All profiles for every rule, which defeats the purpose of the “Public” block on the SQL port.

2. Leaving “Any” in the Remote IP Scope – when you forget to restrict RDP, you end up with a massive attack surface.

3. Using UDP instead of TCP – the lab expects TCP for these services. A UDP rule will look right but won’t actually allow the traffic.

4. Forgetting to Apply the Rule – after creating a rule, you must click Finish; otherwise it stays in a draft state and never takes effect.

5. Not Restarting the Firewall Service – rarely needed, but if you edit the registry or use netsh advfirewall commands, a quick Restart-Service MpsSvc can clear stale state And that's really what it comes down to..

Practical Tips / What Actually Works

• Name and document every rule. A well‑named rule saves hours during audits.
• Group related rules into a custom “Group” in the firewall console; you can enable/disable the whole set with one click.
• Use PowerShell for bulk changes. If you need to close a range of ports, a one‑liner beats creating dozens of UI rules.

1..10 | ForEach-Object {
    New-NetFirewallRule -DisplayName "Block‑Temp‑Port‑$_" -Direction Inbound -Protocol TCP -LocalPort $_ -Action Block
}

• Test before you trust. Always run Test-NetConnection from a different machine or a VM to confirm the rule behaves as expected.
• Keep a backup. Export the firewall policy after each major change; you’ll thank yourself when you need to roll back.

FAQ

Q1: Do I need to configure outbound rules for this lab?
A: Not for the basic pass criteria. The lab focuses on inbound traffic, but adding an outbound block for port 445 (SMB) is a good security habit Still holds up..

Q2: What if I accidentally block RDP on the Domain profile?
A: You can re‑enable it with PowerShell:

Set-NetFirewallRule -DisplayName "RDP‑IT‑Only" -Enabled True

Or simply disable the rule from the console.

Q3: Can I use netsh advfirewall instead of the GUI?
A: Absolutely. The lab accepts either method as long as the resulting rule set matches the expected configuration Worth knowing..

Q4: Why does the lab ask me to test from a “Public” network?
A: It simulates a laptop connecting from a coffee shop. The Public profile should be the most restrictive.

Q5: How do I know which ports are actually open on my machine?
A: Run netstat -ano | findstr LISTENING to see listening services, then cross‑reference with your firewall rules Which is the point..

That’s it. You’ve just walked through the entire Simulation Lab 9.2, Module 09, and you now know not just how to configure Defender firewall ports, but why each step matters.

Next time you open the firewall console, you won’t just be clicking boxes—you’ll be making intentional, auditable decisions that keep your network locked down without locking yourself out. Happy labbing!

6. Automating the “IT‑Only” RDP Exception

Most environments eventually need a repeatable way to grant a handful of privileged accounts remote access without opening the gate for everyone. PowerShell makes that a one‑liner that you can drop into a startup script, a DSC configuration, or a GPO‑based Scheduled Task.

# Define the trusted AD group that may RDP in
$trustedGroup = 'DOMAIN\IT‑Remote‑Admins'

# Create the rule – note the -Profile Public to keep the rest of the public surface locked down
New-NetFirewallRule `
    -DisplayName 'RDP – IT‑Only (Public)' `
    -Direction Inbound `
    -Protocol TCP `
    -LocalPort 3389 `
    -Action Allow `
    -Profile Public `
    -RemoteUser $trustedGroup `
    -Enabled True

A few things to watch for:

And yeah — that's actually more nuanced than it sounds Most people skip this — try not to..

Once the script runs, you can verify that the rule is both present and correctly positioned:

Get-NetFirewallRule -DisplayName 'RDP – IT‑Only (Public)' | Format-List *

If you later need to revoke the exception, simply flip the rule off:

Set-NetFirewallRule -DisplayName 'RDP – IT‑Only (Public)' -Enabled False

7. Validating the Entire Rule Set with a Single Command

After you have built the inbound and outbound rules, you can dump a concise view that mirrors what the lab’s automated grader expects. The following one‑liner prints each rule’s name, profile, direction, ports, and action, sorted for readability:

Get-NetFirewallRule |
    Where-Object { $_.Enabled -eq 'True' } |
    Select-Object -Property DisplayName,
        @{N='Profile';E={($_.Profile -band 1 ? 'Domain ' : '') +
                         ($_.Profile -band 2 ? 'Private ' : '') +
                         ($_.Profile -band 4 ? 'Public ' : '')}},
        Direction,
        @{N='Ports';E={(Get-NetFirewallPortFilter -AssociatedNetFirewallRule $_).LocalPort}},
        Action |
    Sort-Object DisplayName |
    Format-Table -AutoSize

Run it from an elevated PowerShell prompt and compare the output to the “expected rules” list supplied in the lab hand‑out. If any discrepancy appears—missing rule, wrong profile, unexpected port—go back to the offending rule and correct it before you submit.

This is the bit that actually matters in practice.

8. Cleaning Up After the Lab

When the lab is over, you’ll often be asked to restore the machine to its original state. The clean‑up steps are as important as the configuration steps because they prevent “test‑environment bleed‑over” into production or future labs The details matter here..

# 1. Remove all rules created by the lab (they all contain the word "Lab9")
Get-NetFirewallRule -DisplayName '*Lab9*' | Remove-NetFirewallRule

# 2. Re‑enable the default firewall profiles if you disabled them
Set-NetFirewallProfile -Profile Domain,Private,Public -Enabled True

# 3. Reset any modified logging settings
Set-NetFirewallProfile -Profile Domain,Private,Public -LogAllowed False -LogBlocked False

# 4. Export the final state for your records (optional)
Export-Clixml -Path "$env:USERPROFILE\Desktop\FirewallPostLab.xml" -InputObject (Get-NetFirewallRule)

A final sanity check:

Get-NetFirewallProfile | Format-Table Name, Enabled, DefaultInboundAction, DefaultOutboundAction

All profiles should read Enabled = True, DefaultInboundAction = Block, and DefaultOutboundAction = Allow – the classic “secure by default” stance Worth knowing..

Conclusion

Configuring Windows Defender Firewall isn’t just a box‑checking exercise; it’s a disciplined process that blends policy design, technical execution, and continuous verification. By:

1. Naming and grouping rules for future maintainability,
2. Leveraging PowerShell for bulk, repeatable changes,
3. Testing each rule with Test‑NetConnection or netstat, and
4. Documenting every step (export, backup, and cleanup),

you transform a static list of ports into a living security control that can adapt as the network evolves.

In Simulation Lab 9.2 you’ve learned how to carve out a narrow RDP exception for a privileged group while keeping the public profile locked down, how to audit the resulting rule set, and how to safely roll everything back. Those same techniques apply to any Windows server or workstation you manage—whether you’re hardening a domain controller, a web tier, or a remote‑work laptop.

Take the habit of export‑then‑modify, test‑then‑commit, and document‑then‑deploy into every firewall change you make. It will save you time, reduce risk, and keep auditors (or future you) smiling.

Happy securing, and see you in the next lab!