DEV Community: Christopher Smith

Finding What Deleted Your Windows Firewall Rules

Christopher Smith — Wed, 14 Oct 2026 14:52:33 +0000

This post first appeared on the ET Ducky blog. I build ET Ducky, an RMM that reads ETW on Windows and eBPF on Linux.

Windows servers that suddenly block all traffic, and start working again when the firewall is turned off, often have a firewall with no rules left in it. The default inbound action blocks anything no rule allows, so an empty rule set looks like a network outage. This post covers how to confirm the rules are gone, how to find the program and account that deleted them, and how to restore them so the same change doesn't remove them again.

A recent r/sysadmin thread had this across servers in several domains at once. The poster later wrote that new Microsoft Defender for Endpoint policies caused it, and reversing that change fixed every server.

Confirm the rules are gone

Count the rules Windows is enforcing right now. The active store is the sum of the local rules, the Group Policy rules, and the Windows service rules.

(Get-NetFirewallRule -PolicyStore ActiveStore | Measure-Object).Count

A count of zero, or a count far below a working server in the same role, confirms the rules were removed. Then check the default actions for each profile.

Get-NetFirewallProfile -PolicyStore ActiveStore | Select-Object Name,Enabled,DefaultInboundAction,DefaultOutboundAction

Run both commands on one working server as well, so you have a baseline to compare with.

Find what deleted them

The firewall writes its own log under Applications and Services Logs > Microsoft > Windows > Windows Firewall With Advanced Security > Firewall in Event Viewer. Event 2033 reads "All rules have been deleted from the Windows Defender Firewall configuration on this computer." On Windows 11 the same message is event 2059. Event 2006 records a single rule being deleted, and event 2032 records the firewall being reset to its default configuration.

List those events with the time they were written.

Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Windows Firewall With Advanced Security/Firewall'; Id=2006,2032,2033,2059} -MaxEvents 30 | Select-Object TimeCreated,Id,Message | Format-List

Each of these events has a Modifying User field and a Modifying Application field. Modifying Application holds the full path of the program that made the change, and Modifying User holds the account it ran as. A path to netsh.exe, powershell.exe, or an installer points at a script or a person. A path to svchost.exe running as SYSTEM is likely a Windows service applying policy, such as Group Policy or device management. Compare the time of the first event with the time the outage started.

When several servers are affected, run the same query on each of them. The same Modifying Application at the same minute on every server points at a central change rather than something local to one machine.

Find where the policy comes from

Rules can come from the local store, from Group Policy, or from a device management service. List the source of every active rule.

Get-NetFirewallRule -PolicyStore ActiveStore -TracePolicyStore | Group-Object PolicyStoreSourceType | Select-Object Name,Count

Run it on the broken server and on a working one. When the working server has rules from GroupPolicy and the broken one has none, check the Group Policy result next.

gpresult /h C:\Temp\gp.html

Open C:\Temp\gp.html in a browser and find the Windows Defender Firewall with Advanced Security section. It names the GPO that sets the firewall policy. A setting that turns off rule merging for local rules means only the rules in that policy apply. When the servers are also managed by Intune or by Microsoft Defender for Endpoint security settings management, check the firewall policies assigned to them there, along with the date each policy was last changed.

Turn on the audit events before the next change

The Security log can also record each rule that is added, modified, or deleted. Enable the audit subcategory on the affected servers, or set it in the GPO that applies to them.

auditpol /set /subcategory:"MPSSVC Rule-Level Policy Change" /success:enable /failure:enable

Event 4946 is then written when a rule is added, 4947 when one is modified, and 4948 when one is deleted. Event 4954 records a change in the firewall Group Policy settings.

Restore the rules

Fix the source first. When the change came from a GPO, an Intune policy, or a Defender for Endpoint policy, reverse it there. A local repair is overwritten at the next policy refresh when the policy still deletes the rules.

When the change was local, restore the default rule set from the server console.

netsh advfirewall reset

The reset removes every rule you added and returns Remote Desktop access to the Windows default, so run it from the console and not over RDP. To bring back your own rules, export the policy from a working server in the same role and import it on the broken one.

netsh advfirewall export "C:\Temp\working.wfw"
netsh advfirewall import "C:\Temp\working.wfw"

Run gpupdate /force afterward, then count the active rules again and compare the count with the working server. Check the Firewall log again the next day in case the same program deletes the rules a second time.

Where ET Ducky shows it

I build ET Ducky, and its Windows agent reads process creation events from the kernel through ETW. The netsh or PowerShell process that ran in the minute before the rules disappeared shows up in that event stream with its parent and its command line. ET Ducky has custom behavior detection by reading kernel logs and can be configured to look for things like this, so a rule that matches a firewall reset or a delete-all command raises an alert when it runs.

When several servers fail at once, you'd start a Multi-Agent Session across a broken server and a working one in the same role. It compares the kernel events from each host to find the shared cause and the outlier, and the raw events stay on the hosts. You can also open a Live Session shell from the browser without the need for a VPN and run the PowerShell commands above on each server.

One Windows or Linux server on the Free query tier with your own AI key costs $5 a month. Pricing is at https://etducky.com/pricing.

Drafted with AI.

Ransomware Detection for Windows and Linux using ETW and eBPF

Christopher Smith — Sat, 26 Sep 2026 17:24:31 +0000

I build ET Ducky, an RMM that reads the kernel event stream on each endpoint. We launch on Product Hunt on Wednesday, September 30, and today I'm writing about the behavioral rule engine.

Every managed agent runs thirteen built-in rules against its own kernel event stream. ETW supplies the events on Windows and eBPF tracepoints supply them on Linux. We funnel both into one event format, so each rule has one configurable definition that fires on either OS.

The rules run on the same thread that delivers events, so a rule must never block. The engine is tuned to prefer false positives over false negatives. Per-process cooldowns suppress repeated firings of the same pattern, and the dashboard deduplicates duplicate firings.

mass-file-rename fires at 25 or more files renamed to ransomware extensions within 60 seconds. file-encryption-sweep fires at 20 or more files given the same destination extension within 30 seconds, and a policy can change that window. mass-file-access fires at 200 or more distinct paths across 3 user-data root directories within 5 seconds. shadow-copy-deletion and ransom-note-pattern fire on a single match.

The ransomware kill-chain rule is the only agent-side rule that reads the rule engine's output instead of raw events. It fires at Critical when two or more of shadow-copy-deletion, mass-file-rename, and ransom-note-pattern fire on the same process within five minutes. Its evidence list is the component detections, so the dashboard shows which base rules led to it without another database query.

One definition has a limit on Linux. ETW gives both the old and the new file name for a rename. Our eBPF programs currently emit only the destination path for rename, renameat, and renameat2.

ET Ducky is not an antivirus engine and does not replace one. The full rule set, thresholds, and evidence formats are in the original post at https://etducky.com/blog/behavioral-security-monitoring-rules.

What Polling, auditd, and eBPF Can See Through Linux RMM Agents

Christopher Smith — Wed, 23 Sep 2026 03:41:33 +0000

This post first appeared on the ET Ducky blog. I build ET Ducky, an RMM that reads ETW on Windows and eBPF on Linux.

This is for anyone comparing RMM products for a fleet that includes Linux hosts. An RMM agent on Linux can be built three ways. It can poll /proc on a timer, it can subscribe to the kernel audit subsystem, or it can attach eBPF programs to kernel tracepoints. All three are described as Linux support. They answer different questions, and the difference shows up the first time you investigate something that already happened.

Polling /proc on a timer

The simplest agent reads /proc every fifteen or thirty seconds and reports what it finds. Load average, memory, disk usage, the process list at that instant, listening sockets. This is cheap, portable, and requires no privileges beyond the ability to read /proc.

It is a sampling technique, so it sees what was true at the moment it looked. A process that starts, writes a file, opens a socket, and exits inside one polling interval leaves no trace at all. A build script that spawns four hundred short-lived children shows up as a CPU spike with no explanation of what produced it. When someone asks why the disk filled at 02:14, the answer available from polling is that it was not full at 02:00 and was full at 02:30.

That is enough for capacity alerts and inventory. It is not enough for diagnosis, because the thing you need to look at has usually already exited.

The audit subsystem

Linux has a kernel audit subsystem, configured with auditd and rules written against syscalls. Unlike polling it is event-driven, so a process that lives for eighty milliseconds still produces a record. The records carry the fields an investigation needs: the syscall, the arguments, the resolved path, the user and group, the process and parent.

Two things make it awkward for an agent to own. The first is that auditd is a system-wide singleton. The rules are global, the log is global, and an agent that installs its own rules is editing configuration that the host's administrator, a compliance tool, or a security product may also be editing. Two products writing audit rules on the same host is a support conversation.

The second is cost. Audit records are generated in kernel context and written out through a userspace daemon. A rule broad enough to be useful for diagnosis, such as auditing every openat, produces enough volume to be visible in benchmarks and to fill a disk on a busy host. The usual response is to narrow the rules until the volume is acceptable, which narrows what you can answer later.

eBPF programs on tracepoints

eBPF programs run inside the kernel in a verified, sandboxed virtual machine. They attach to tracepoints, kprobes, and uprobes, filter and aggregate in kernel context, and emit only what the program decides to emit into a ring buffer the agent reads.

The filtering location is the whole difference. An audit rule captures everything matching it and discards the excess in userspace, after paying the cost of generating and writing every record. An eBPF program decides in the kernel, so a rule like "process exec events, but rate-limited per process so a build loop cannot flood the buffer" costs nothing for the events it drops.

The verifier is what makes this safe to ship to a customer fleet. It rejects programs that could fail to terminate, crash the kernel, or read memory outside permitted regions. A kernel module with the same access carries no such guarantee.

The constraint is portability. eBPF programs read kernel structures, and those structures change between kernel versions. A program compiled against one kernel's layout reads the wrong offsets on another. CO-RE, compile once run everywhere, solves this by building against generic field accessors and relocating them at load time using the kernel's own BTF type data. Kernels that do not ship BTF need that type data supplied from elsewhere.

Questions that separate the three

These are answerable about any product, including this one, and the answers are specific rather than a yes or no on a feature grid.

If a process starts and exits between two heartbeats, does the agent have a record of it? This separates polling from everything else.

Does the agent install auditd rules? If so, what happens on a host where something else already manages them?

What is the measured overhead under load, and what limits the agent's own resource use? A cgroup limit is a specific answer. "Lightweight" is not.

What privileges does the agent hold at rest? CAP_BPF and CAP_PERFMON are narrower than root, and narrower than CAP_SYS_ADMIN.

Which kernels are supported, and what happens on one that ships no BTF? Silent degradation and a clear error are both acceptable. Not knowing is not.

Do Linux events reach the same queries and rules as Windows events, or is Linux a separate view with its own subset of features?

That last question is the one most often skipped. An agent can capture excellent Linux telemetry and still leave you with two consoles, two rule languages, and a report that cannot span both halves of the fleet.

How ET Ducky answers them

The Linux agent attaches eBPF programs to tracepoints in three provider groups, each of which can be switched off independently in AgentConfig.json: process exec and exit, file open and close, and network connect and accept over IPv4 and IPv6. Capture is rate-limited per process inside the kernel programs. No auditd rules are installed.

Portability is CO-RE against the kernel's own BTF, which is standard on Ubuntu 22.04 and Fedora 36 onward. On RHEL 8, Ubuntu 18.04, and Amazon Linux 2, a matching .btf file dropped into /opt/etducky/agent/bpf/btfhub/ supplies the type data. Where neither is available the agent runs in a no-op capture mode: heartbeats, health metrics, live sessions, and remote desktop continue, and only kernel events are off. KernelEventsEnabled: false in the same config file turns capture off deliberately without uninstalling.

The agent runs as an unprivileged etducky user under a hardened systemd unit. On kernel 5.8 and later it holds CAP_BPF and CAP_PERFMON rather than CAP_SYS_ADMIN; older kernels fall back to broader capabilities. Privileged actions go through operator-authorized elevation with an audit row per request. The unit applies cgroup limits of 512 MB of memory, 50% of a CPU, and 256 tasks.

Events are normalized into the same shape the Windows agent produces and handed to the same downstream pipeline, so live-session analysis, inflection-bracketed correlation, and behavioral detections work identically on both platforms. A behavioral rule that detects a shell spawning a downloader runs on either operating system without being rewritten, and a cross-fleet query for top memory consumers returns rows from both.

Two things the Linux agent does not do. It has no fine-grained user-mode provider taps equivalent to the Windows agent's user-mode ETW providers. It does not automatically isolate a host on encryption-sweep detection, which the Windows agent does. The cross-platform rule engine provides earlier-stage detection on Linux instead.

Trying it on one host

The quickest way to see the difference is to put one host under a kernel-event agent and ask it about something that finished before you looked. With a workspace and an enrollment token from the Agents page, the install is one line:

curl -fsSL https://etducky.com/install.sh \
| sudo bash -s -- --token=<TOKEN_ID> --subdomain=<SUBDOMAIN>

Then run something on that host that exits in well under a second:

bash -c 'cat /etc/hostname > /tmp/etd-probe; rm /tmp/etd-probe'

Open a live session on the host and ask about recent process and file activity. The analysis is built from the kernel events, so a process that lived for a few milliseconds and a file that existed for less than that are both in it. Repeat the same command on a host under a polling agent and there is nothing to find. That is the whole difference, and it takes about ten minutes.

The Linux agent guide covers the package options, the systemd unit, the sudoers policy, and the kernel requirements in full.

The ten-minute test at the end works against any Linux agent. Start a sub-second process and check whether the agent recorded it.

Drafted with AI, reviewed by me.