Firewall Engine
Firewall Engine
CyberWall uses the Windows Filtering Platform (WFP) for kernel-level network filtering with a default-deny architecture.
How It Works
Architecture
CyberWall operates at two levels:
| Layer | Technology | Description |
|---|---|---|
| Kernel | WFP (Windows Filtering Platform) | Intercepts network packets at the network layer |
| User | Windows Firewall COM API | Manages persistent firewall rules |
Detection Methods
| Method | Description |
|---|---|
| Event ID 5157 | Real-time WFP drop detection via Security Audit log |
| TCP Polling | 400ms connection polling for comprehensive coverage |
Default-Deny Philosophy
Unknown connections are blocked by default:
- App attempts network connection
- WFP intercepts the connection
- CyberWall checks for existing rules
- If no rule exists → prompt or block
- Allow always and Block become persistent rules; Allow once and dismissed prompts apply temporarily (about 10 minutes)
Firewall Modes
Ask to Connect (Default)
When an unknown app tries to connect:
- A popup prompt appears
- Choose Block, Allow once, or Allow always
- Allow once and dismissed prompts are temporary (about 10 minutes); Allow always and Block save a persistent rule
- Auto-block timeout for unanswered prompts
Block All
Silently blocks all unknown connections:
- No prompts shown
- Known apps with allow rules still work
Killswitch
Total network lockdown:
- Blocks all network traffic, including allowed apps
- No prompts shown
- Emergency use
Disabled
No filtering:
- All connections allowed
- Monitoring stops while disabled
- Useful for troubleshooting
Mode Switching
Change modes from:
- System tray icon → right-click menu
- Main window toolbar mode selector
Rules
Rule Types
Each rule combines a verdict with a direction:
| Type | Description |
|---|---|
| Allow | Permit network access for the app |
| Block | Deny network access for the app |
| Inbound / Outbound / Both | Separate verdicts can apply to incoming and outgoing connections |
Creating Rules
Rules are created when:
- You respond to a popup prompt with Allow always or Block
- You edit per-direction verdicts in the Edit rule dialog
Smart Toolchain Rules
CyberWall automatically resolves companion executables:
- Git → Auto-detects git-remote-https, git-remote-http, ssh, etc.
- Edge WebView2 → Maps host processes correctly
Rule Storage
Rules are stored in:
%ProgramData%\CyberWall\rules.json
Rule Properties
Each rule stores:
| Property | Description |
|---|---|
| App path | Full path to executable (matching key) |
| App name | Display name resolved from product info |
| Verdict | Allow or Block |
| Direction | Inbound, Outbound, or Both, with separate per-direction verdicts |
| Package identity | Package family name for Store / packaged apps |
Process Identity
How CyberWall Identifies Apps
Rules match by executable path and Store package identity. The UI also shows descriptive info:
| Method | Description |
|---|---|
| File path | Full executable path (rule matching key) |
| Package identity | UWP/MSIX package resolution |
| Product info | Version, company, product name shown in the UI |
| Digital signature | Signer / publisher info shown in the UI |
WebView2 Host Resolution
Maps Edge WebView2 runtime processes back to their host applications.
Auto-Block Timeout
Configuration
When a prompt is not answered:
- Enabled — Auto-block after timeout
- Duration — 30 seconds to 30 minutes (default: 5 minutes)
- Action — Block the connection
Use Case
Prevents indefinite prompts:
- If you step away from the computer
- If a prompt appears during a fullscreen app
- Reduces unwanted background connections
Rule Management
Main Window
The main window shows all rules:
- Search and filter
- Edit rule properties
- Delete rules
Context Menu
Right-click a rule for actions:
| Action | Description |
|---|---|
| Edit | Modify rule properties |
| Search online | Look up the process on the web |
| Copy path | Copy the executable path |
| Open folder | Show executable in Explorer |
| Remove | Delete the rule |