Windows Server · Lesson 08

Windows Defender Firewall

Protect server network exposure without breaking DNS, DHCP, SMB, RDP, WinRM, web services, or other scenario-required roles.

Strong firewall hardening is not about closing everything. It is about allowing exactly what required services need and reducing unnecessary exposure around them.

Lesson Snapshot

Profiles3

Primary consolewf.msc

Main concernRequired exposure

GoalNarrow + functional

Learning objectives

What this lesson should help you do

Review Windows Defender Firewall profiles, rules, services, and exposure on Windows Server.

Use Windows Defender Firewall with Advanced Security and PowerShell to inspect firewall state without changing rules blindly.

Understand how Domain, Private, and Public profiles affect server behavior.

Recognize the relationship between firewall rules and required server roles such as DNS, DHCP, SMB, RDP, and WinRM.

Evaluate rule direction, protocol, port, program, service, profile, action, and remote scope before making changes.

Verify required services from the client perspective after firewall hardening.

Core concepts

Understand how firewall decisions are made

Profile

A firewall configuration context associated with Domain, Private, or Public network classification.

Inbound rule

Controls traffic entering the server and is especially important for required server roles and remote administration.

Outbound rule

Controls traffic leaving the server. Many environments allow outbound traffic broadly unless a stricter policy is required.

Action

A rule can allow or block matching traffic. The action only matters when the rule actually matches the connection.

Scope

Defines which local or remote addresses can use the rule, helping limit exposure without disabling the service.

Service dependency

A firewall rule often exists because a role or service must communicate. Removing the rule may break a required function.

Core idea

Required service does not mean unlimited exposure

Keep the service available while limiting profiles, protocols, ports, programs, services, and remote networks to what the scenario actually requires.

Availability warning

Firewall changes can break the entire server role

DNS, DHCP, SMB, RDP, WinRM, IIS, and other required services can become unreachable even when their Windows services are healthy.

Verify every major firewall change from an authorized client.

Tool map

Exactly where to review firewall state

Windows Defender Firewall with Advanced Security

Win + R → wf.msc

Primary GUI for reviewing profiles, inbound rules, outbound rules, monitoring, and connection-security settings.

Server Manager

Start → Server Manager → Local Server → Windows Defender Firewall

Provides a high-level firewall status view and a path into firewall configuration.

Windows Security / Firewall status

Start → Windows Security → Firewall & network protection

Useful when the Windows Security interface is available, but Advanced Security provides the deeper rule view.

Group Policy firewall settings

Group Policy Management → edit the intended GPO → Computer Configuration → Policies → Windows Settings → Security Settings → Windows Defender Firewall with Advanced Security

Use when firewall configuration is centrally managed by domain Group Policy.

Services

Win + R → services.msc

Confirm the required service is running before assuming the firewall is the reason a connection fails.

PowerShell

Start → search PowerShell → Run as administrator when required

Use Get-NetFirewallProfile and Get-NetFirewallRule with related filter cmdlets for read-only inspection.

Firewall profiles

Domain, Private, and Public are different security contexts

Domain

Normally applies when the server is connected to a network where it can authenticate to its Active Directory domain.

Most domain-member servers and domain controllers rely heavily on this profile for required role communication.

Private

Used for trusted non-domain networks when the network is classified as Private.

A server unexpectedly using Private instead of Domain may indicate network or domain-detection issues.

Public

Designed for untrusted networks and usually deserves the most restrictive exposure.

Required server roles should not be exposed broadly just because a permissive rule applies to Public.

Rule anatomy

Ten parts of a firewall rule to inspect

Enabled

An existing rule does nothing if it is disabled.

Direction

Inbound and outbound rules affect opposite connection directions.

Action

Allow or Block determines what happens when the rule matches.

Profile

A rule may apply only to Domain, Private, Public, or a combination of profiles.

Program / service

A rule can be tied to a specific executable or Windows service instead of a broad port allowance.

Protocol

TCP, UDP, ICMP, and other protocols behave differently and should match the service requirement.

Local port

The server-side port the rule allows or blocks when port filtering is used.

Remote port

The remote-side port can also be part of the match conditions.

Local address

Can restrict the rule to specific local network interfaces or addresses.

Remote address

Allow only the protocol, port, profile, and scope needed by the hosted service.

Verify

Open the required site or application from an authorized client.

PowerShell inspection

Inventory rules and filters without changing them

Firewall profiles

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

Shows profile state and default actions.

Enabled inbound rules

Get-NetFirewallRule -Direction Inbound -Enabled True | Select-Object DisplayName, Action, Profile, Direction

Creates a broad inventory of enabled inbound rules.

Enabled outbound rules

Get-NetFirewallRule -Direction Outbound -Enabled True | Select-Object DisplayName, Action, Profile, Direction

Creates a broad inventory of enabled outbound rules.

Rule details

Get-NetFirewallRule -DisplayName "Rule Name" | Format-List *

Shows deeper rule metadata. Replace Rule Name with the rule being reviewed.

Port filters

Get-NetFirewallRule -DisplayName "Rule Name" | Get-NetFirewallPortFilter

Shows protocol and port conditions for a specific rule.

Address filters

Get-NetFirewallRule -DisplayName "Rule Name" | Get-NetFirewallAddressFilter

Shows local and remote address scope for a specific rule.

Application filters

Get-NetFirewallRule -DisplayName "Rule Name" | Get-NetFirewallApplicationFilter

Shows whether a rule is tied to a specific executable.

Service filters

Get-NetFirewallRule -DisplayName "Rule Name" | Get-NetFirewallServiceFilter

Shows whether a rule is tied to a particular Windows service.

Rule review questions

Ten questions before editing a firewall rule

Which server role or service needs this rule?

Is the rule enabled?

Is it inbound or outbound?

Does the action allow or block traffic?

Which profile or profiles does it apply to?

Is the protocol correct for the required service?

Is the port range narrow or overly broad?

Is the rule tied to a specific program or service?

Can the remote-address scope be narrowed safely?

How will you verify the required service after changing the rule?

Exposure signals

Signs a rule may be broader than necessary

Any program

A rule that is not tied to a specific program can be broader than necessary.

Any port

Rules allowing broad port ranges deserve extra review.

All profiles

A rule applying to Domain, Private, and Public may expose the service more broadly than intended.

Any remote address

The rule may accept connections from more networks or clients than necessary.

Duplicate rules

Multiple similar rules can make it hard to understand which configuration actually permits traffic.

Unknown application path

A rule tied to an unfamiliar executable should be investigated before being kept or removed.

RDP from management subnet only

RDP is required, but only systems on a management subnet should connect.

Approach

Keep the required RDP rule and narrow Remote IP address scope to the authorized management network rather than disabling RDP completely.

Verify

Test RDP from an authorized management host and confirm an unrelated host is not permitted.

SMB for one internal network

A file server must serve internal clients but should not expose SMB broadly.

Approach

Keep File and Printer Sharing rules for the required profile and network scope only.

Verify

Open the required share from an authorized client and confirm unintended networks cannot reach it.

IIS application on one required port

A required internal web application listens on a known port.

Approach

Allow the specific protocol and port tied to the required service instead of creating a broad Any/Any rule.

Verify

Open the application from an authorized client and confirm unrelated ports remain closed.

Change discipline

Ten steps for controlled firewall hardening

Read the scenario and identify required network services.

Record the active firewall profile.

Record existing rule state before editing.

Confirm the related Windows service or role is actually required.

Narrow one condition at a time.

Avoid broad Any/Any allow rules.

Preserve remote administration before high-impact changes.

Test from an authorized client after each major change.

Check Event Viewer and service health if connectivity breaks.

Document the final rule and why it exists.

Decision cases

Firewall decisions in server context

RDP rule is enabled for all profiles

The server only needs RDP on the domain network.

RDP is required, but the profile exposure is broader than the scenario needs.

Response

Confirm the active domain-management path, then narrow the rule to the required profile and scope rather than disabling RDP entirely.

Unknown inbound allow rule

The rule allows an unfamiliar executable from any remote address.

The rule could be unnecessary or malicious, but it may also belong to a required application.

Response

Inspect the executable path, publisher, service dependency, listening port, installed application, and scenario requirement before disabling it.

DNS rule is disabled

The server is a required DNS server and clients cannot resolve names.

The disabled firewall rule may be blocking a required service.

Response

Confirm DNS Server is healthy and the correct rule/profile is intended, then restore only the required DNS access and verify from a client.

Local firewall rule keeps returning

A student disables a rule locally, but it reappears after policy refresh.

Group Policy may own the firewall configuration.

Response

Use gpresult and Group Policy Management to identify the controlling GPO before making further changes.

Fictional defensive lab

Harden FILE-SRV without breaking TeamDocs or RDP

Step 01

Identify required roles

In the fictional environment, FILE-SRV must provide the TeamDocs SMB share and RDP access for Morgan from the management network.

Step 02

Open Advanced Security

Run wf.msc and record the active profile plus the relevant File and Printer Sharing and Remote Desktop inbound rules.

Step 03

Confirm with PowerShell

Use Get-NetFirewallProfile and Get-NetFirewallRule to compare GUI state with the PowerShell inventory.

Step 04

Review scope

The RDP rule allows any remote address. The TeamDocs SMB rule applies to more profiles than the scenario requires.

Step 05

Harden narrowly

Preserve both required services, but narrow RDP to the authorized management network and restrict SMB to the required profile and client network.

Step 06

Verify

From authorized clients, confirm Morgan can still use RDP and required users can still reach TeamDocs. Confirm unintended access is not permitted.

Common mistakes

Firewall mistakes that trade security for outages

Disabling the firewall to make a service work

That removes a major control instead of solving the actual rule, profile, or service problem.

Deleting rules before understanding them

Role-specific rules may be required by DNS, DHCP, SMB, RDP, WinRM, IIS, or another server function.

Opening Any/Any rules

Broad allow rules solve connectivity by creating unnecessary exposure.

Ignoring the active profile

A correct rule on the wrong profile may not affect the connection at all.

Testing only on the server

Firewall behavior must be verified from the clients that actually depend on the service.

Ignoring Group Policy

Locally edited firewall rules may be centrally managed and re-applied later.

Reflection

Test your firewall reasoning

Question 1

Why should a required service usually be narrowed instead of simply blocked?

Question 2

Why does the active firewall profile matter?

Question 3

How can remote-address scope reduce exposure without disabling a service?

Question 4

Why can a firewall rule look correct while the service is still unreachable?

Question 5

What should you inspect before disabling an unfamiliar inbound rule?

Question 6

Why is client-side verification essential after firewall changes?

Verification checklist

Confirm protection and connectivity

The intended firewall profile is enabled.

Default inbound and outbound actions are understood.

Required role-specific rules remain enabled.

Unnecessary broad allow rules have been investigated.

Remote-address scope is as narrow as the scenario allows.

Required DNS, DHCP, SMB, RDP, WinRM, or IIS functions still work as applicable.

Authorized remote administration still works.

Group Policy is not unexpectedly overriding the intended firewall state.

No required application lost network access.

The final firewall configuration is documented.

Competition checklist

Before leaving firewall review

Open wf.msc.

Record Domain, Private, and Public profile state.

Run Get-NetFirewallProfile.

Review enabled inbound rules.

Review enabled outbound rules when relevant.

Inspect protocol and port filters.

Inspect program and service filters.

Inspect remote-address scope.

Identify role-specific firewall dependencies.

Check for Group Policy-managed rules.

Avoid broad Any/Any rules.

Verify required services from an authorized client.

Next Windows Server lesson

Windows Update & Patch Management

Next, review update state, patch categories, restart planning, servicing risk, and post-update verification for servers that may host critical roles.

Open Lesson 09 →

Back to Windows Server CyberPatriot Hub

← Previous Lesson Next Lesson →