04 — Windows Firewall & Endpoint Network Security — Firewall Configuration and Connectivity Validation - rafaelribeiro-s/it-support-sysadmin-portfolio GitHub Wiki

📋 Case Study: Windows Firewall & Endpoint Network Security — Firewall Configuration and Connectivity Validation

🏢 Enterprise Environment Context

  • Company Name: NexaCorp Solutions Ltd.
  • Industry: Cloud Financial Services
  • Ticket ID: INC-804638
  • Department: Finance Operations
  • Requester: Finance Operations Team

👤 Employee Profile

  • Full Name: Daniel Carter
  • Username: d.carter
  • Employee ID: NX-8821
  • Job Title: Financial Operations Analyst
  • Department: Finance Operations
  • Assigned Workstation: NX-WS-FIN02

🛠️ IT Support Assignment

  • Assigned Analyst: Rafael Ribeiro
  • Role: IT Support & Systems Administrator

Endpoint Firewall Security Review

Following a reported network security incident, IT Support has been assigned to review the host-based firewall configuration of workstation NX-WS-FIN02 and demonstrate the enforcement of an outbound application-level network restriction.

The endpoint firewall configuration must be reviewed before the controlled test is performed.

The IT Support team must:

  • Verify the operational status of Microsoft Defender Firewall.
  • Review the status of the available firewall profiles.
  • Access Windows Defender Firewall with Advanced Security.
  • Identify the appropriate firewall rule type and traffic direction.
  • Create an outbound program-based firewall rule for Mozilla Firefox.
  • Configure the rule to block network connections generated by the application.
  • Validate the expected connectivity restriction.
  • Disable or remove the temporary test rule after validation.
  • Verify application connectivity after the rule has been rolled back.
  • Document the configuration, test results, and supporting evidence.

The security control selected for this lab is Microsoft Defender Firewall, using Mozilla Firefox as the controlled test application.

📩 Help Desk Ticket Description

  • Ticket: INC-804638
  • Subject: Endpoint Security Review — Windows Firewall Configuration and Outbound Traffic Validation

Request

Following a reported network security incident, the Finance Operations department has requested an endpoint firewall configuration review for workstation NX-WS-FIN02, assigned to Daniel Carter.

IT Support must verify that Microsoft Defender Firewall is enabled and review the relevant firewall profiles.

As part of a controlled security validation exercise, an outbound program-based firewall rule must be configured for Mozilla Firefox to block its network connections.

The resulting behavior must be tested and documented. After the validation is complete, the temporary test rule must be disabled or removed, and application connectivity must be tested again.

The final report must document the firewall configuration, observed test results, rollback procedure, and validation evidence.

This ticket represents a simulated enterprise IT support assignment created for educational and portfolio purposes. It does not represent an actual security incident at a real organization.

🎯 Key Technical Objectives for the Lab

The purpose of this lab is to demonstrate the configuration and validation of a host-based firewall control on a Windows endpoint.

The following objectives must be completed:

  1. Validate the workstation hostname and active user context before beginning the firewall configuration.
  2. Verify the operational status of Microsoft Defender Firewall.
  3. Review the status of the available firewall profiles and document the observed configuration.
  4. Access Windows Defender Firewall with Advanced Security.
  5. Identify the appropriate firewall rule type and traffic direction for the test.
  6. Create an outbound program-based firewall rule targeting the Mozilla Firefox executable.
  7. Configure the rule action to block the connection.
  8. Review the rule configuration before performing the connectivity test.
  9. Test Firefox network connectivity while the blocking rule is enabled.
  10. Document the observed connectivity behavior and the active firewall rule state.
  11. Disable or remove the temporary test rule after completing the validation.
  12. Retest Firefox connectivity and determine whether the expected connectivity has been restored.
  13. Document the implementation evidence, validation results, and final firewall configuration.
  14. Record any actual troubleshooting activities, observations, and lessons learned.

The lab follows an evidence-based validation process:

Workstation & User Validation
        ↓
Firewall Status Verification
        ↓
Firewall Profile Review
        ↓
Outbound Rule Configuration
        ↓
Rule Configuration Review
        ↓
Connectivity Test — Rule Enabled
        ↓
Blocked Behavior Validation
        ↓
Disable / Remove Test Rule
        ↓
Connectivity Test — Rule Rolled Back
        ↓
Final State Validation & Documentation

The primary technical distinction in this lab is that the test uses an outbound program-based firewall rule, not a port-based rule. The rule targets the Mozilla Firefox executable and is configured to block its outbound network connections.

A failed browser connection alone will not be treated as conclusive proof of firewall enforcement. The results must be evaluated alongside the initial connectivity baseline, the rule configuration, and the rule's enabled state.

The temporary rule is intended only for controlled testing and must be disabled or removed after validation so that the workstation is not left with an unnecessary application connectivity restriction.

🧪 Lab Environment

The firewall configuration and validation will be performed on an existing virtualized Windows workstation previously used in Lab 02. Reusing the same virtual machine maintains continuity across the portfolio's endpoint security exercises while allowing a new set of baseline checks and firewall-specific validation.

The environment represents a standalone corporate workstation assigned to the Finance Operations department of NexaCorp Solutions Ltd.

Component Configuration
Virtualization Platform Oracle VirtualBox
Guest Operating System Windows 11 Enterprise
Architecture x64
CPU 4 vCPUs
Memory 8 GB
Storage 80 GB VDI
Firmware UEFI
Secure Boot Enabled
TPM 2.0
Network NAT
Workstation Name NX-WS-FIN02
Test User d.carter
User Role Standard User
Administrative Account NexaAdmin
Host-Based Firewall Microsoft Defender Firewall
Test Application Mozilla Firefox
Firewall Rule Type Outbound Program Rule
Rule Action Block the Connection

🛠️ Implementation & Evidence Documentation

The firewall configuration and validation will be performed on workstation NX-WS-FIN02, reusing the virtual machine previously used in Lab 02. The test user is d.carter, and authorized administrative elevation may be required to configure firewall rules.

The implementation follows a controlled endpoint firewall validation workflow:

Workstation & User Validation
        ↓
Firewall Status Verification
        ↓
Active Network Profile Review
        ↓
Baseline Firefox Connectivity Test
        ↓
Advanced Firewall Configuration
        ↓
Outbound Program Rule Creation
        ↓
Rule Configuration & Enforcement Validation
        ↓
Firefox Connectivity Test with Rule Enabled
        ↓
Temporary Rule Rollback
        ↓
Post-Rollback Connectivity Validation

The following evidence will document the process from the initial workstation and firewall assessment through rule enforcement testing and post-rollback connectivity validation.

Evidence will be captured during implementation, and all reported results will reflect the actual behavior observed in the lab environment.

EV-01 — Workstation and User Context

Action Performed: Verified the workstation hostname and the currently signed-in user by running the hostname and whoami commands in Command Prompt.

Observed Result: The workstation hostname was confirmed as NX-WS-FIN02, and the logged-in account was identified as nx-ws-fin02\d.carter.

Security Significance: This validation establishes the endpoint identity and user context before making firewall configuration changes. It also confirms that the initial assessment was performed under the intended standard-user account.

Evidence File:

EV-02 — Standard User Group Membership

Action Performed: Executed the net user d.carter command in Command Prompt to inspect the local account properties and group memberships.

Observed Result: The command output showed *Users under Local Group Memberships, confirming that d.carter belongs to the local standard-users group.

Security Significance: This result supports the validation that d.carter is intended for standard-user activity rather than administrative configuration tasks.

Evidence File:

Local Administrators Group Membership

Action Performed: Executed the net localgroup Administrators command to identify the accounts belonging to the workstation's local Administrators group.

Observed Result: The output listed NexaAdmin as a member. The account d.carter was not listed in the group.

Security Significance: This confirms that the test user does not have membership in the local Administrators group, while the separate NexaAdmin account provides the administrative context required for the firewall configuration.

Evidence File:

EV-03 — Initial Firewall Status

Action Performed: Opened the Start menu, searched for Windows Security, and launched the application to access the endpoint security settings.

Observed Result: The Windows Security home screen displayed the available protection areas, including Virus & threat protection, Account protection, Firewall & network protection, and App & browser control.

Security Significance: This step establishes the starting point for inspecting the workstation's built-in security controls before applying the test firewall rule.

Evidence File:

Firewall Profile Status

Action Performed: Selected Firewall & network protection in Windows Security to inspect the firewall status across the available network profiles.

Observed Result: Windows Security reported that Microsoft Defender Firewall was enabled for all three profiles: Domain network, Private network, and Public network. The Public network profile was identified as the active network profile during the assessment.

Security Significance: The initial status confirms that the built-in firewall was already enabled before the lab rule was created. Identifying the active Public profile was important because the test rule was designed to apply only to that profile.

Evidence:

EV-04 — Baseline Firefox Connectivity

Action Performed: Before creating the outbound firewall rule, launched Mozilla Firefox while signed in as the standard user d.carter and navigated to https://www.google.com to verify normal internet connectivity.

Observed Result: Google loaded successfully in Firefox, confirming that the browser could access the website before the test rule was applied.

Security Significance: Establishing a successful baseline provides a reference point for the subsequent enforcement test. It helps distinguish connectivity behavior observed after the firewall rule is enabled from the browser's normal behavior before the configuration change.

Evidence File:

EV-05 — Advanced Firewall Console: Access Control Validation

Action Performed: Opened the Start menu and searched for Windows Defender Firewall with Advanced Security while signed in as the standard user d.carter.

Observed Result: The advanced firewall management console was selected for launch. The subsequent access-denied message is documented in the next evidence item.

Security Significance: This step records the attempt to access advanced firewall management from the standard-user session, before switching to the authorized administrative account.

Evidence File:

Administrative Permission Denied

Action Performed: Attempted to open Windows Defender Firewall with Advanced Security on the local computer under the d.carter account.

Observed Result: Windows displayed an error stating that the account did not have the correct permissions to open the console. The message specified that membership in the local Administrators or Network Operators group was required and returned error code 0x5.

Security Significance: This result demonstrates the administrative privilege boundary enforced by Windows. It is consistent with the earlier group membership checks, which showed that d.carter belongs to the local Users group and is not a member of Administrators. The error message also identifies Network Operators as an alternative group authorized to access the console.

Evidence File:

EV-06 — Advanced Firewall Console: Administrative Access

Action Performed: Signed in using the authorized administrative account NexaAdmin, opened the Start menu, and searched for Windows Defender Firewall with Advanced Security. Right-clicked the search result and selected Run as administrator to launch the management console with administrative privileges.

Observed Result: The Windows Defender Firewall with Advanced Security console opened successfully and displayed the available firewall management options, allowing access to advanced configuration settings.

Security Significance: This result demonstrates that advanced firewall management was accessible from the authorized administrative account after access had been denied in the d.carter standard-user session. It supports the principle of least privilege by separating routine user activity from administrative security configuration.

Evidence File:

EV-07 — FireFox Executable Path

Action Performed: Opened the Start menu, searched for Firefox, and selected Open file location to identify the shortcut used to launch the browser.

Observed Result: Windows opened the Start Menu Programs directory at C:\ProgramData\Microsoft\Windows\Start Menu\Programs, where the Firefox shortcut was located.

Security Significance: Identifying the shortcut provided the starting point for locating the browser's actual executable. A program-based firewall rule must reference the executable rather than the Start Menu shortcut.

Evidence File:

Firefox Executable Location

Action Performed: Right-clicked the Firefox shortcut, selected Open file location, and inspected the destination directory to identify the browser application file.

Observed Result: Windows opened C:\Program Files\Mozilla Firefox, where the Firefox application executable was located. The executable's full path was identified as:

C:\Program Files\Mozilla Firefox\firefox.exe

Security Significance: Confirming the executable path was essential for configuring the outbound program-based firewall rule against the intended application. Using an incomplete or incorrect path could prevent the rule from matching Firefox's network traffic, even if the rule itself was enabled.

Evidence File:

EV-08 — Outbound Firewall Rule Configuration

Action Performed: In the NexaAdmin session, opened Windows Defender Firewall with Advanced Security and selected Outbound Rules in the left navigation pane.

Observed Result: The Outbound Rules view displayed the available outbound firewall rules and the administrative actions, including New Rule, for creating a new rule.

Security Significance: Access to the outbound rule management interface allowed the authorized administrator to configure a program-specific network restriction without granting administrative privileges to the standard user d.carter.

Evidence File:

Rule Type Selection

Action Performed: Selected New Rule from the Outbound Rules pane to launch the New Outbound Rule Wizard. On the Rule Type screen, selected Program and clicked Next.

Observed Result: The wizard proceeded to the Program configuration screen, allowing the rule to target a specific application executable.

Security Significance: A program-based rule provides application-specific control over outbound connections, rather than applying a blanket restriction to all applications or network traffic.

Evidence File:

Program Path Configuration

Action Performed: On the Program screen, selected This program path and entered the verified Firefox executable path:

C:\Program Files\Mozilla Firefox\firefox.exe

Then clicked Next.

Observed Result: The rule was configured to target the Mozilla Firefox executable at the specified path.

Security Significance: Specifying the full executable path associates the rule with the intended application. An incorrect or incomplete path can prevent the rule from matching the application's network traffic.

Evidence File:

Firewall Action Selection

Action Performed: On the Action screen, selected Block the connection and clicked Next.

Observed Result: The wizard was configured to block connections matching the rule's program, profile, and other applicable conditions.

Security Significance: The Block action provides an explicit restriction on outbound connections from the selected application when the rule applies.

Evidence File:

Network Profile Selection

Action Performed: On the Profile screen, selected Public while leaving Domain and Private unchecked, then clicked Next.

Observed Result: The rule was configured to apply only when the Public network profile is active.

Security Significance: Restricting the rule to the Public profile limits its intended scope and avoids applying this specific test restriction to the Domain and Private profiles.

Evidence File:

Rule Name and Description

Action Performed: On the Name screen, entered the following rule details:

Name: Firefox Outbound Block Test

Description: Temporary outbound program-based firewall rule for validating Mozilla Firefox connection blocking on the Public network profile. Disable or remove after testing.

After entering the details, clicked Finish to create the rule.

Observed Result: The rule was created with the specified name and description. Its enabled state and configured properties were subsequently inspected in the Outbound Rules list and rule properties.

Security Significance: A clear name and description make the purpose, scope, and temporary nature of the rule identifiable during troubleshooting and future administration.

Evidence File:

EV-09 — Outbound Firewall Rule Validation

Action Performed: In Windows Defender Firewall with Advanced Security, running under the NexaAdmin account, selected Outbound Rules in the left navigation pane and located the rule Firefox Outbound Block Test.

Observed Result: The rule appeared in the Outbound Rules list, allowing its configuration and status to be inspected.

Security Significance: Confirming the rule's presence in the management console establishes that the firewall configuration was created and can be identified for subsequent validation.

Evidence File:

General Rule Properties Validation

Action Performed: Opened the properties of Firefox Outbound Block Test and inspected the General tab to verify the rule's enabled state and configured action.

Observed Result: The rule was shown as enabled, and its action was set to Block the connection.

Security Significance: These settings confirm that the rule was enabled to block matching outbound connections rather than merely existing as an inactive configuration.

Evidence File:

Advanced Profile Validation

Action Performed: Opened the Advanced tab in the rule properties and inspected the network profile selection.

Observed Result: The Public profile was selected for the rule.

Security Significance: This confirms that the rule's configured scope matches the lab requirement: blocking Firefox outbound connections when the Public network profile is active, without intentionally applying this test rule to the Domain or Private profiles.

Evidence File:

EV-10 — Firewall Rule Enforcement Validation

Action Performed: Returned to the standard-user session d.carter and launched Mozilla Firefox to test application connectivity with the outbound firewall rule enabled.

Observed Result: Firefox opened successfully under the standard-user session, allowing the application connectivity test to proceed.

Security Significance: Performing the test under d.carter verifies the rule's observed impact from the intended employee-user context rather than from the administrative session used to configure the firewall.

Evidence File:

Outbound Connection Blocked

Action Performed: In Firefox, navigated to https://www.google.com and waited for the page to load while Firefox Outbound Block Test remained enabled.

Observed Result: Firefox failed to establish a connection to www.google.com and displayed the Unable to connect message. The browser indicated that the site might be unavailable or that a firewall or proxy could be preventing access.

Security Significance: Compared with the successful baseline connectivity test documented in EV-04, this failure occurred after the program-based outbound rule was configured and enabled. Combined with the verified executable path, Block action, and Public profile, the result supports the conclusion that the rule successfully restricted Firefox connectivity during the test.

Evidence File:

🛠️ Troubleshooting

No unrelated network configuration failure was identified during the initial connectivity assessment. The troubleshooting process focused on validating the firewall rule configuration, confirming its enforcement, and maintaining the separation between standard-user activity and administrative configuration.

1. Access Denied When Opening the Advanced Firewall Console

Issue: The standard user d.carter received an access-denied error when attempting to open Windows Defender Firewall with Advanced Security. Windows returned error code 0x5.

Investigation: The local account and group membership information was reviewed. The d.carter account belonged to the local Users group and was not a member of the local Administrators group.

Resolution: The firewall management console was opened using the authorized administrative account NexaAdmin. The standard-user account was retained for application connectivity testing.

Result: Administrative access to the firewall console was successfully established without changing the standard user's group membership.

Security Significance: This behavior was consistent with the intended privilege boundary. Routine application testing and administrative security configuration were performed under separate account contexts.

Related Evidence: EV-02, EV-05, EV-06

Resolution Status: RESOLVED

2. Identifying the Correct Firefox Executable

Issue: A program-based firewall rule requires the actual application executable rather than its Start Menu shortcut.

Investigation: The Firefox shortcut was inspected to identify the installation directory and executable location.

Resolution: The verified executable path was used when configuring the outbound firewall rule:

C:\Program Files\Mozilla Firefox\firefox.exe

Result: The rule was configured to target the intended Firefox executable.

Security Significance: An incorrect executable path could prevent a program-based rule from matching the intended application's traffic. Verifying the path before creating the rule reduced this configuration risk.

Related Evidence: EV-07, EV-08

Resolution Status: RESOLVED

3. Validating Outbound Rule Enforcement

Issue: The lab required evidence that an application-specific outbound firewall rule could restrict network connectivity.

Investigation: Firefox connectivity was tested before and after enabling the Firefox Outbound Block Test rule. The rule properties were also reviewed to confirm its enabled state, blocking action, and selected network profile.

Resolution: The rule was configured with the following properties:

  • Rule type: Program
  • Program: C:\Program Files\Mozilla Firefox\firefox.exe
  • Direction: Outbound
  • Action: Block the connection
  • Network profile: Public
  • Rule name: Firefox Outbound Block Test

Result: Firefox successfully accessed Google during the baseline test. After the blocking rule was enabled, Firefox displayed an inability-to-connect message when accessing the same destination. This change in observed behavior, combined with the verified rule configuration, supported the conclusion that the outbound restriction was being enforced.

Security Significance: Testing the same application and destination before and after the configuration change provided a meaningful comparison. A browser connection failure alone would not prove that the firewall caused the failure; the baseline and rule properties were also considered.

Related Evidence: EV-04, EV-09, EV-10

Resolution Status: BLOCKING BEHAVIOR OBSERVED

Troubleshooting Summary

The troubleshooting process demonstrated the importance of validating account permissions, identifying the correct executable, inspecting firewall rule properties, and comparing application behavior before and after a security configuration change.

The key distinction was between creating a firewall rule and proving its operational effect. The baseline and blocking tests provided evidence of the rule's behavior.

🧠 Lessons Learned

This lab reinforced several practical concepts related to Windows Firewall administration, outbound application control, endpoint security, and network connectivity validation.

1. Outbound Firewall Rules Provide Application-Level Control

Windows Defender Firewall can restrict network connections generated by a specific application without requiring a blanket restriction on all outbound traffic.

In this lab, the Firefox Outbound Block Test rule targeted the Firefox executable and was configured to block matching outbound connections. This demonstrated how application-specific rules can support controlled security testing and endpoint traffic restrictions.

2. Correct Rule Configuration Is Essential

A firewall rule must match the intended application, direction, action, and network profile to produce the expected behavior.

Verifying the full Firefox executable path helped ensure that the rule targeted the intended program. Reviewing the enabled state, Block action, and Public profile provided additional evidence that the configuration matched the lab requirements.

3. Baseline Testing Makes Results Meaningful

A failed network connection does not automatically indicate a firewall problem. DNS resolution issues, proxy settings, remote service availability, and other network conditions can also affect connectivity.

Testing Firefox against the same destination before and after enabling the rule provided a reference point for evaluating the observed behavior. Combining those tests with the rule properties produced stronger evidence than relying on the browser error alone.

4. Administrative Privileges Should Remain Controlled

The standard user d.carter could perform routine application testing but could not open the advanced firewall management console with the required permissions.

Using the separate administrative account NexaAdmin demonstrated the importance of keeping routine user activity separate from security configuration tasks.

This approach supports the principle of least privilege by avoiding unnecessary administrative access for standard users.

5. Network Profiles Affect Rule Scope

Windows Defender Firewall supports Domain, Private, and Public network profiles. A rule configured for only one profile should be evaluated in the context of that profile.

The test rule was configured for the Public profile. Reviewing the selected profile helped establish the intended scope of the restriction and highlighted why administrators should confirm the active network profile when troubleshooting unexpected connectivity behavior.

6. Security Controls Must Be Validated Through Observable Behavior

Creating a rule successfully does not, by itself, demonstrate that the intended security control is working.

This lab compared the initial Firefox connectivity test with the test performed while the outbound blocking rule was enabled. The observed change supported the conclusion that the restriction was effective under the tested conditions.

7. Evidence Improves Troubleshooting and Auditability

Recording the workstation identity, user permissions, firewall status, executable path, rule properties, and connectivity observations creates a traceable record of the configuration process.

The evidence also helps distinguish between a correctly configured rule, an observed blocking result, and a fully completed validation that includes connectivity restoration.

Key Takeaway

Effective endpoint network security requires more than creating firewall rules. Administrators must understand rule scope, preserve appropriate privilege boundaries, validate actual network behavior.

✅ Final Result

The Windows Firewall configuration and outbound application-control test for workstation NX-WS-FIN02 demonstrated the practical use of Microsoft Defender Firewall to restrict application network connectivity.

The controlled test used Mozilla Firefox and the temporary outbound program-based rule Firefox Outbound Block Test. The rule was configured to block connections generated by the verified Firefox executable when the Public network profile was active.

Security Validation Summary

The following results were documented during the lab:

Requirement Observed Result Status
Workstation and user context Hostname and standard-user context verified PASS
Standard-user privilege boundary Administrative console access denied to the standard user PASS
Administrative firewall access Console opened using NexaAdmin PASS
Initial firewall status Microsoft Defender Firewall enabled across the three profiles PASS
Baseline application connectivity Firefox accessed Google before the rule was enabled PASS
Executable identification Firefox executable path verified PASS
Outbound rule configuration Program-based blocking rule created PASS
Rule properties Enabled state, blocking action, and Public profile verified PASS
Blocking behavior Firefox could not connect to Google while the rule was enabled PASS

Final Assessment

The documented tests established that the outbound firewall rule was configured for the intended application and that Firefox connectivity failed after the rule was enabled, following a successful baseline test.

The lab therefore demonstrated the configuration and observed enforcement of an application-specific outbound network restriction using Windows Defender Firewall.

Overall Lab Status

OUTBOUND FIREWALL CONFIGURATION AND BLOCKING TEST — VERIFIED