01 / Challenge
A firewall rule is only useful when its behavior can be proven.
Embedded Linux controls sit across several layers: the Yocto-built operating system, kernel Netfilter support, userspace policy, network identifiers, and logging. The lab objective was not merely to write rules, but to show that intended traffic passed, disallowed traffic was blocked, and the decision left usable evidence.
Scope noteThe four weekly reports document the work of a six-member internship team. I present this as a team deliverable to which I contributed—not as solo work—and separate measured results from interpretation.
02 / Method
Baseline → control → capture → verify.
We used the same evidence loop across attack simulations and legitimate traffic. Establishing a baseline first made it possible to distinguish a working security control from a broken network path.
Windows + Scapy→IPv4 / IPv6 / VLAN→Netfilter / nftables→NFLOG→Text + JSON evidence
- Generate controlled valid, invalid, and spoofed traffic from a Windows host.
- Observe packet receipt before enforcement to validate connectivity and test data.
- Apply explicit firewall controls and repeat the same traffic profile.
- Compare counters, receiver output, journal logs, and structured ulogd2 records.
03 / Four-week build
Controls first. Context and telemetry next.
Week 01Kernel & Netfilter
Built webOS OSE for Raspberry Pi 4 and enabled the Netfilter modules needed for rate limits, connection matching, ranges, logging, recent-source tracking, TCP MSS, hash limits, and accounting. Tested SYN flood, LAND, Smurf, and random-source patterns.
Week 02IPv6, VLAN & identity
Created Python/Scapy sender and receiver workflows, inspected remote interfaces, changed IPv4/IPv6, VLAN ID, and MAC values, then tested whitelist behavior with legitimate and spoofed identifiers.
Week 03Traffic semantics
Compared unicast, broadcast, multicast, and anycast behavior across IPv4 and IPv6. Combined group membership with firewall policy to avoid relying on a single enforcement layer.
Week 04Structured observability
Integrated ulogd2 with NFLOG and produced parallel human-readable LOGEMU output and JSON records for SYN flood, broadcast, multicast, Smurf, and valid outbound audit cases.
04 / Validation
Measured behavior, not a “works on my machine” claim.
10 / 10IPv4 unicast test packets dropped when the source was not whitelisted
29IPv6 anycast packets accepted and recorded by the rule counter
2 formatsParallel text and JSON security event outputs from ulogd2
| Traffic case | Control | Observed result |
| IPv4 unicast | Source whitelist | Non-whitelisted 10-packet test dropped |
| IPv4 broadcast | Service-port policy | Approved service traffic accepted |
| IPv4 multicast | Membership-specific rule | Only expected group traffic accepted |
| IPv6 unicast | IPv6 source whitelist | Non-whitelisted source dropped |
| IPv6 multicast | Group-specific rule | Target group allowed; other group dropped |
| IPv6 anycast | Destination policy + counter | Accepted; 29 packets recorded |
05 / Engineering decisions
The useful learning lived in the edge cases.
Listener conflictSeparate NFLOG groups
Two ulogd2 stacks could not bind the same NFLOG group. We split text and JSON pipelines into different groups, using a documented JSON = TEXT + 100 convention.
Missing metadataFix the plugin order
JSON records lacked input-interface metadata. Adding IFINDEX and HWHDR before IP2STR supplied the data needed for interface-name resolution.
Test designMatch the rule semantics
A default nmap SYN scan did not exercise an RST-only scan rule. We revised the traffic and validation approach instead of interpreting a zero counter as proof.
Kernel behaviorLog spoofing early
Linux reverse-path filtering can drop spoofed LAND traffic before later hooks. Spoofing visibility therefore belongs in mangle/PREROUTING, not only in downstream chains.
Next stepOperationalize the telemetry with logrotate retention and nfacct-based accounting, then map structured events into a SIEM detection pipeline.
06 / Reflection
What this demonstrates.
This work connects embedded Linux engineering with analyst thinking: understand packet paths, define a falsifiable control objective, generate repeatable traffic, and preserve evidence. It strengthened my ability to debug why a security control appears silent—whether the cause is traffic semantics, hook order, kernel filtering, or logging architecture.
The related firewall-manager repository ↗ extends the same interest in making Linux firewall administration easier to inspect.