Skip to main content

Host isolation

What this page is​

The host isolation module, the two isolation backends (WFP primary, Windows Firewall fallback), the audit trail, the release procedure, and the decision log that records every isolation event.

Why it exists this way​

The architecture document requires the sensor to isolate a compromised endpoint from the network while preserving the management channel to the Collector so analysts can triage and release the host. Two backends exist because WFP provides fine-grained blocking but requires the Base Filtering Engine service and can be disabled by kernel-mode malware; Windows Firewall provides a stateless backup that survives service restarts.

How it works​

The edr_windows::isolation module implements IsolationPolicy with two modes:

WFP mode (primary)​

The edr_windows::wfp::WfpManager registers WFP callout drivers at the FWPM_LAYER_ALE_AUTH_CONNECT_V4 layer. The isolation policy adds a blocking filter with a high weight that overrides all allow rules. The management channel to the Collector (collector.<region>.example:9443) is whitelisted via a higher-priority permit filter keyed on the destination IP and port tuple.

Windows Firewall mode (fallback)​

When WFP is unavailable or its callout registration fails, IsolationPolicy falls back to Windows Firewall rules via the netsh advfirewall CLI. Three rules are created:

  1. Allow outbound TCP/9443 to the Collector.
  2. Allow outbound UDP/53 for DNS (required by the Collector hostname resolution).
  3. Block all other outbound traffic.

The same rules are also created for the inbound direction so the endpoint cannot receive unsolicited connections from lateral movement.

Audit trail​

Every isolation action is recorded in a DecisionLog entry that captures:

  • isolate_id: Uuid: the unique identifier for this isolation event
  • operator_id: String: the analyst who initiated isolation
  • mode: IsolationMode: which backend was used (Wfp or Firewall)
  • policy: IsolationPolicy: the applied rule set
  • applied_at: DateTime<Utc>: when the rules took effect
  • management_whitelist: Vec<SocketAddr>: the allowed destinations
  • outcome: IsolateOutcome: success or the specific failure reason

Decision logs are shipped to the Collector immediately via a separate gRPC unary call so the analyst sees confirmation before the network is fully blocked.

Release procedure​

Releasing isolation is the reverse: all WFP filters or firewall rules are deleted by their assigned IDs. The release is recorded as a separate DecisionLog entry with action: Release. After release, the sensor verifies connectivity to the Collector by sending a HealthCheck RPC; if it fails within 10 seconds, the sensor re-applies the isolation policy and escalates the error.

What goes wrong​

  • WfpManager registration fails because the Base Filtering Engine service is stopped. The policy auto-falls-back to Windows Firewall. A counter isolation_wfp_fallback_total increments.
  • WFP filter is removed by kernel-mode malware. The guard module polls WFP state every 30 seconds and re-applies filters if they are missing. If re-application fails 3 consecutive times, the sensor escalates to Windows Firewall.
  • Firewall rules are purged by Group Policy. The sensor detects rule removal within 60 seconds and re-creates the rules. If GP enforcement is too frequent, the sensor logs a recommendation to exclude AuroraEDR rules from the domain policy.
  • DNS whitelist is insufficient for environments with internal DNS servers that require Kerberos or LDAP queries. The policy schema includes an extra_whitelist field that fleet operators populate during enrollment for site-specific dependencies.