Windows 11 · Lesson 06

Windows Defender Firewall

Learn how firewall profiles, inbound and outbound rules, ports, programs, services, and remote scope work together without breaking required Windows connectivity.

The goal is not to block everything. The goal is to reduce unnecessary exposure while preserving the exact network paths the scenario requires.

Lesson Snapshot

Firewall profiles3

Rule properties8

Required-service examples4

Main goalNarrow required access

Learning objectives

What firewall review should help you do

Explain how Windows Defender Firewall profiles, rules, applications, ports, protocols, and scope work together.

Distinguish inbound rules from outbound rules and understand why their security impact differs.

Review firewall state without disabling protection globally or breaking required services.

Recognize how Remote Desktop, file sharing, remote management, and other required functions depend on specific firewall access.

Use Windows Security, Windows Defender Firewall with Advanced Security, and PowerShell to inspect firewall configuration.

Verify both reduced exposure and continued required connectivity after firewall changes.

Core concept

A firewall rule is a decision about who may communicate

Direction, action, application, port, profile, and remote scope combine to define the real exposure. Reviewing only the port misses important context.

Availability warning

Blocking traffic can also break the mission

RDP, shares, remote management, and required applications may depend on firewall access.

Never disable or delete a high-impact rule until you understand which required function depends on it.

Firewall profiles

The network context changes the policy

Domain profile

Used when Windows identifies the device as connected to an authenticated domain network. Competition images may or may not use a domain.

Ask

Is the image actually domain-connected, and is this profile active?

Private profile

Intended for trusted networks such as an internal home, lab, or organization network when the network is marked private.

Ask

Does the scenario expect trusted internal connectivity such as file sharing or remote management?

Public profile

Designed for less-trusted networks and is normally more restrictive.

Ask

Is the system on a network that should be treated as untrusted or minimally trusted?

Rule anatomy

Read the entire rule before judging it

Direction

Inbound rules govern traffic entering the Windows host. Outbound rules govern traffic leaving the host.

Action

A rule may allow or block traffic. Understand whether a rule creates access or explicitly denies it.

Program or service

Rules can apply to a specific executable or service rather than all traffic using a port.

Protocol and port

TCP, UDP, ICMP, and other protocols may be filtered by local or remote port.

Scope

A rule can restrict which local or remote IP addresses are allowed, reducing unnecessary exposure.

Profile

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

Interface and edge conditions

Advanced rule properties can further constrain where traffic is allowed.

Enabled state

A rule can exist without being active. Read the rule state before assuming it is affecting traffic.

Traffic direction

Inbound traffic

Inbound rules are often the most visible competition concern because they determine which services can receive connections from other systems.

Example

A broad inbound rule allowing any remote address to reach a management service deserves careful review.

Traffic direction

Outbound traffic

Windows commonly allows more outbound traffic by default, but outbound rules can still matter when the scenario or system requires tighter egress control.

Example

Blocking all outbound traffic without understanding application dependencies can break updates, authentication, or required services.

Required services

Firewall decisions must preserve dependencies

Remote Desktop

RDP service state, user rights, authorized users/groups, firewall rules, and network reachability all have to align.

Caution

Disabling every RDP-related rule may secure one exposure while breaking required remote administration.

File and printer sharing

Share configuration, NTFS permissions, firewall rules, network profile, and authorized users interact.

Caution

Broadly blocking sharing can break required collaboration; broadly allowing it can expose unnecessary access.

Remote management

Tools such as PowerShell remoting or management services may rely on specific services, listeners, and firewall rules.

Caution

Confirm whether remote administration is actually required before tightening or enabling access.

Application-specific services

A required application may listen on a particular port or use a specific executable rule.

Caution

Prefer narrowly scoped application or service rules over broad port exposure when appropriate.

Inspection tools

Build a firewall picture before changing it

Windows Security

Windows Security → Firewall & network protection

Quickly shows active network profile and whether Microsoft Defender Firewall is enabled for each profile.

Advanced Security console

wf.msc

Provides detailed inbound rules, outbound rules, connection security rules, monitoring, profiles, ports, programs, and scope.

PowerShell profile review

Get-NetFirewallProfile

Shows firewall profile state and selected default behavior.

PowerShell rule review

Get-NetFirewallRule

Lists firewall rules so you can inspect enabled state, direction, action, display name, and profile context.

PowerShell inspection

Query firewall rules efficiently

Enabled inbound rules

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

Creates a quick view of active inbound rules that may expose services.

Enabled outbound rules

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

Shows active outbound controls when the scenario or investigation requires them.

Review rule filters

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

Helps connect a selected rule to its protocol and port configuration in an authorized lab.

Review address scope

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

Shows local and remote address scope, which is critical when deciding whether a rule is broader than necessary.

Before a firewall change

Ten questions to answer

Which firewall profile is active right now?

Is the firewall enabled for every profile that matters?

What service or application does this rule support?

Is the rule inbound or outbound?

Does the scenario require the service?

Who or what should be allowed to connect?

Can the rule be narrowed by program, port, profile, or remote address?

Could disabling the rule break RDP, file sharing, remote management, or another required function?

Is there a safer way to reduce exposure without removing the required service?

How will the team test the service after the rule changes?

Scope and least exposure

Keep required access as narrow as practical

Any address is broad

A rule that permits any remote address may be appropriate in some cases, but it creates more exposure than a rule limited to known required sources.

Program rules can be narrower

When a specific application needs network access, program-based rules can sometimes reduce exposure compared with a broad port-only rule.

Profiles reduce accidental exposure

A rule needed on a trusted Private network may not need to apply on Public networks.

Required service does not mean unrestricted service

A service can remain available while access is narrowed to the users, networks, or profiles that actually need it.

Decision cases

Firewall decisions in context

Required RDP with a very broad rule

The scenario requires RDP for one authorized administrator. The inbound Remote Desktop rule is enabled on every profile and allows any remote address.

RDP must remain available, but the current exposure may be broader than necessary.

Response

Keep required RDP functionality, narrow profile or remote-address scope when the scenario supports it, then test authorized remote access.

Firewall disabled on Public

The Public profile firewall is disabled and the scenario gives no reason for that state.

The host may be exposed whenever Windows uses the Public network profile.

Response

Confirm no approved security product replaces the control, enable expected protection, and verify required network functions.

Unknown inbound application rule

An enabled inbound rule allows an unfamiliar executable to accept connections.

The rule is suspicious enough to investigate, but the executable may support a required application.

Response

Identify the executable, service, owner, port, and scenario purpose before disabling the rule.

Required share stops working

After tightening file-sharing rules, authorized users can no longer reach a required project share.

The security change reduced exposure but also broke required functionality.

Response

Review the active profile, sharing rules, remote scope, and required client addresses; restore the narrowest working authorized path.

Profile review

Confirm the foundation first

Confirm which network profile is active.

Confirm firewall is enabled on Domain, Private, and Public as appropriate.

Review default inbound behavior.

Review default outbound behavior.

Identify profile-specific exceptions.

Compare active profile with scenario network requirements.

Inbound rule review

Find exposure without breaking services

Start with enabled inbound Allow rules.

Identify the program, service, protocol, and local port.

Review the remote address scope.

Check which profiles the rule applies to.

Map the rule to a scenario-required service or application.

Investigate rules with no clear purpose before disabling them.

Prefer narrowing over removing when a service is required.

Fictional defensive lab

Reduce exposure while preserving RDP and file sharing

Step 01

Read the fictional scenario

Morgan must use RDP from the internal lab network. A project share must remain available to two authorized workstations. No public-network access is required.

Step 02

Inspect profiles

Private is active. Firewall is enabled on Private and Domain but disabled on Public.

Step 03

Inspect inbound rules

RDP is allowed on all profiles from any remote address. File sharing is allowed on Private from any remote address. An unfamiliar media-service rule is also enabled.

Step 04

Classify the findings

Public firewall protection should be restored. RDP is required but overly broad. File sharing is required but may be scoped more tightly. The media-service rule needs investigation.

Step 05

Apply controlled changes

Enable expected Public protection, narrow required RDP and share access to the authorized environment when possible, and leave the unfamiliar rule unchanged until its purpose is known.

Step 06

Verify

Test authorized RDP and share access, confirm firewall profiles are enabled, re-check rule scope, and document unresolved investigation items.

Troubleshooting

When a required connection stops working

RDP stops working

Is the Remote Desktop service running? Is the correct firewall rule enabled for the active profile? Is the authorized client inside the allowed remote scope? Does the user have RDP rights?

File sharing stops working

Is the network profile correct? Are file-sharing firewall rules enabled? Does the share exist? Do NTFS and share permissions still allow the user?

A rule looks enabled but traffic still fails

Is another blocking rule or profile in effect? Does the application listen on the expected port? Is the rule tied to the correct program or service?

The firewall keeps appearing disabled

Is another approved security product managing firewall behavior? Is policy controlling the setting? Is the team checking the correct profile?

Verification model

Five things to prove after a firewall change

Firewall state

Confirm the expected profiles remain enabled and the intended rule is actually enabled or disabled.

Exposure

Confirm the rule is no broader than needed by checking program, port, profile, and remote scope.

Required service

Test RDP, shares, remote management, or the application function that depends on the rule.

Error evidence

Check service logs, Event Viewer, or application messages if connectivity fails after the change.

Team state

Record high-impact changes so another teammate does not undo or duplicate the firewall work.

Common mistakes

Firewall habits that create avoidable problems

Turning the firewall off to troubleshoot

That removes a major security control and can hide the real cause of the connectivity problem.

Deleting all allow rules

Required RDP, shares, management tools, and applications may depend on specific inbound rules.

Ignoring the active profile

A rule can be correct for Private but irrelevant or unsafe on Public.

Reviewing only port numbers

Program, service, profile, action, and remote scope can be just as important as the port.

Broadening access to make it work

Opening access to any address may fix the symptom while creating unnecessary exposure.

No connectivity test

A saved firewall rule is not complete until the required application or remote path is tested.

Reflection

Test your firewall reasoning

Question 1

What is the difference between an inbound rule and an outbound rule?

Question 2

Why does the active network profile matter when reviewing firewall rules?

Question 3

Why is a required service not the same as unrestricted access?

Question 4

What parts of a firewall rule can be narrowed besides the port?

Question 5

Why should an unfamiliar rule be investigated before it is disabled?

Question 6

What should be verified after changing an RDP or file-sharing rule?

Firewall checklist

Review before leaving the firewall area

Confirm the active network profile.

Confirm firewall protection is enabled where expected.

Review enabled inbound Allow rules.

Map each important rule to a required service or application.

Review program, service, protocol, port, profile, and remote scope.

Investigate unfamiliar rules instead of deleting them blindly.

Preserve required RDP, sharing, and management paths.

Narrow broad exposure when the scenario supports it.

Test required connectivity after every high-impact change.

Check logs or service state if connectivity fails.

Document major firewall changes and unresolved rules.

Re-check the final profile and rule state before leaving the firewall area.

Next Windows lesson

Windows Update & Patch Management

Next, learn how to evaluate update status, security patches, restart requirements, update history, and competition-time tradeoffs without treating every pending update the same.

Open Lesson 07 →

Back to Windows 11 CyberPatriot Hub

← Previous Lesson Next Lesson →