Why Firewalls Cannot Block by Filename
The Windows Defender Firewall is designed to control inbound and outbound network traffic based on protocols, ports, and local or remote IP addresses. It does not inspect the internal contents of executable files or their names during process creation. When you attempt to add a rule in wf.msc, the interface only allows you to specify the program path, such as C:\Users\Name\AppData\Local\App\123.exe. This means if an attacker moves 123.exe to C:\Temp or renames the folder structure, the firewall rule fails to trigger. Therefore, relying on the firewall for filename-based blocking is technically impossible due to the architectural separation between network filtering and application execution policies.
Using AppLocker for Filename Restrictions
AppLocker is the most direct built-in solution for restricting execution based on file properties, including name, publisher, and path. While modern Windows 11 editions often default to WDAC, AppLocker remains available in Pro and Enterprise versions. You can configure it to deny any file named 123.exe from running, irrespective of where it resides on the drive. This method intercepts the process creation event before the application gains access to system resources, providing a more granular layer of protection than network filtering.
Configuring AppLocker Rules
To implement this restriction, follow these steps:
- Open the Local Security Policy editor by pressing
Win + R, typingsecpol.msc, and hitting Enter. - Navigate to Application Control Policies > AppLocker > Executable Rules.
- Right-click in the right pane and select Create New Rule.
- In the wizard, choose Deny as the action to prevent execution.
- Under Conditions, select File Name and enter
123.exe. - Ensure no other conditions like Path or Publisher are selected to guarantee the block applies everywhere.
- Complete the wizard and apply the policy changes.
This configuration ensures that any attempt to launch a file with that exact name will be blocked by the operating system kernel, returning an access denied error to the user.
Alternative: Windows Defender Application Control (WDAC)
If your organization requires stricter enforcement, WDAC provides code integrity policies that can also restrict execution. However, WDAC typically relies on digital signatures rather than simple filenames, making it more complex for blocking a generic name without affecting signed updates. For most individual users seeking a quick fix for a suspicious filename, AppLocker is the preferred tool. If you need to manage these policies across multiple devices, consider integrating with Microsoft Intune or Group Policy Objects. For deeper insights into how default settings interact with these policies, review our guide on Understanding Default Network Settings in Windows Defender Firewall.
Verifying the Block
After applying the rule, test the configuration by attempting to run 123.exe from various directories, such as C:\Windows\System32 or C:\Downloads. The system should prevent execution immediately. You can verify the denial in the Event Viewer under Applications and Services Logs > Microsoft > Windows > AppLocker. Look for Event ID 8003, which indicates a rule was triggered to block the executable. This logging confirms that the OS successfully identified and intercepted the process based on the filename condition.
Managing Exceptions and Updates
Be cautious when implementing blanket filename blocks, as legitimate software may occasionally use similar naming conventions during updates or installations. If a critical application uses 123.exe as part of its legitimate workflow, you will need to create an exception rule in AppLocker. Alternatively, you can refine the rule to include specific paths while denying others, though this reduces the "regardless of location" benefit. Regularly review your AppLocker audit mode settings to ensure no false positives are disrupting productivity. For managing firewall modifications via scripts, see Refresh Windows Firewall Modification with PowerShell's NetSecurity Module to understand the broader scope of security automation.
Frequently Asked Questions
Can I block a file name using PowerShell commands?
PowerShell alone cannot block execution by filename without invoking external tools like AppLocker or WDAC. You can use PowerShell to enable AppLocker auditing or to query existing rules, but the actual enforcement requires the underlying security policy engine. Direct command-line blocking of executables is not supported natively in standard PowerShell cmdlets.
Does this method work on Windows 11 Home edition?
No, AppLocker is not available on Windows 11 Home editions. Users on Home must rely on third-party endpoint protection solutions or manual monitoring tools to restrict execution based on filenames. Microsoft reserves AppLocker and advanced WDAC features for Pro, Enterprise, and Education editions.
Will blocking the filename stop network activity from the file?
Yes, effectively. Since the OS prevents the executable from launching at all, no network connections can be established by that process. This is superior to firewall rules which might allow the initial handshake before inspecting content. The process is terminated before it can allocate network sockets.
What happens if the file is renamed slightly, like 123_new.exe?
The rule will not block it if the condition is strictly set to the exact filename 123.exe. Attackers often rename malware to bypass such simple checks. To mitigate this, you can add additional rules for common variations or use hash-based blocking in WDAC, though hash-based rules require updating whenever the file changes.
How do I revert the AppLocker rule if it causes issues?
You can disable the rule by opening secpol.msc, navigating to the AppLocker rules, and deleting or disabling the specific deny entry. Ensure you are in Enforce mode when testing new rules to avoid accidental lockouts. If you accidentally lock yourself out, you can boot into Safe Mode to modify the security policy.