Traditional perimeter security is built around appliances: dedicated firewall hardware or virtual appliances that sit at the network boundary, inspect traffic, and make allow/deny decisions. This model made sense when the perimeter was well-defined and traffic was predictable. Neither is true anymore for most infrastructure — traffic flows between containers, between hosts, between cloud regions, and between on-premise and hosted services in ways that appliance-based firewalls were never designed to handle efficiently.
47Sentry takes a different approach. Instead of sitting in the traffic path as an appliance, it instruments the Linux kernel directly using eBPF and XDP to observe and filter traffic at the lowest possible layer — without the overhead of userspace packet processing, without a separate network hop, and without a single point of failure.
What eBPF actually is
eBPF (extended Berkeley Packet Filter) is a kernel subsystem that allows you to run sandboxed programs inside the Linux kernel without modifying kernel source or loading kernel modules. The key properties that make it useful for security work:
- Verifier safety: The kernel verifies every eBPF program before loading it. Programs that could crash the kernel, loop infinitely, or access memory out of bounds are rejected at load time. You can't brick a production system by loading a malformed eBPF program — the verifier catches it.
- Hook points: eBPF programs can attach to dozens of kernel hook points — network socket operations, system calls, kernel functions, tracepoints, perf events. Each hook gives you visibility and control at a different layer of the stack.
- Maps: eBPF programs communicate with userspace through maps — shared data structures that both the kernel program and userspace process can read and write. A running eBPF program can have its behaviour updated in real time by writing new values into its maps, without reloading the program.
- Performance: Because eBPF programs run in kernel context, there's no userspace/kernel boundary crossing for each packet. For high-traffic paths this is a significant difference — processing that would require syscall overhead in a userspace daemon happens inline in the kernel.
XDP: processing packets before the network stack
XDP (eXpress Data Path) is an eBPF hook point that fires at the lowest point in the receive path — immediately after the NIC driver has received a packet and before the kernel's network stack processes it. An XDP program returns one of four verdicts for each packet: XDP_PASS (hand to the network stack normally), XDP_DROP (discard silently), XDP_TX (transmit back out the same interface), or XDP_REDIRECT (forward to another interface or socket).
For filtering purposes, XDP_DROP at this level is extremely efficient. The packet is discarded before any memory allocation has been done for it by the network stack, before any protocol processing has occurred, and before any interrupts have been delivered to userspace. A volumetric DDoS attack that would saturate a userspace firewall can often be absorbed transparently at XDP rates because the drop cost is so low — you're measuring throughput in millions of packets per second, not thousands.
Limitation: XDP programs run at packet receive time on a specific interface. They see raw Ethernet frames, not reassembled TCP streams. For stateful inspection (tracking TCP connection state, detecting protocol anomalies across multiple packets) you need to combine XDP with TC (Traffic Control) hooks and maintain connection state in eBPF maps.
How 47Sentry uses these primitives
47Sentry is composed of several eBPF programs, each attached at a different hook point, communicating through shared maps and exporting data to a userspace control plane.
Traffic Sentinel: XDP-based packet filtering
The Traffic Sentinel component is an XDP program that implements the core packet filter. It maintains several eBPF maps:
- A blocklist map (LPM trie) containing IP prefixes that should be dropped. The trie structure allows longest-prefix matching, so you can block a /24 with a single entry and still allow a specific /32 within it by adding a more specific entry.
- A rate limit map (hash map keyed by source IP) tracking packet counts per second per source. Sources that exceed the configured threshold receive
XDP_DROPfor the remainder of the time window. - A SYN cookie map used during SYN flood conditions to validate TCP handshake completion without allocating connection state for unverified sources.
The blocklist map is updated from userspace without reloading the XDP program — the control plane writes new entries into the map, and the running XDP program reads them on the next packet. Block rule changes take effect in microseconds, not seconds, because there's no program reload and no kernel module operation.
NetMapper: topology from observed traffic
NetMapper is one of the more practically useful parts of 47Sentry. It builds a live topology map of your network by observing actual traffic flows — not by reading configuration files or querying APIs, but by watching what packets actually flow between which hosts.
The Flow Tracker eBPF program (TC hook) records connection tuples: source IP, destination IP, destination port, protocol, byte counts, packet counts, first-seen and last-seen timestamps. The control plane aggregates these into a graph where nodes are hosts and edges are observed connections, weighted by traffic volume and recency.
The resulting map shows you things that configuration-based asset inventories miss: lateral movement between hosts that shouldn't be communicating, services listening on unexpected ports, connections to external IPs that don't appear in your allowlists, and the actual dependency graph between services — which is often quite different from what the architecture diagram says.
DNS resilience
47Sentry's DNS resilience component intercepts DNS resolution at the kernel level and maintains a local cache of recently resolved names. If upstream DNS becomes unavailable, resolution continues from this cache for configured TTL values extended beyond the original record TTL. For infrastructure that depends on DNS resolution to reach critical services (monitoring, logging, secret stores), this prevents a DNS outage from cascading into a broader service outage.
The DNS monitor also logs unusual patterns: newly-seen domains, domains with very short TTLs (characteristic of fast-flux infrastructure), domains resolving to IPs in unusual ASNs, and resolution spikes that could indicate DNS tunnelling or beaconing. These events are surfaced in the 47Sentry dashboard without requiring traffic decryption — the anomaly is in the resolution pattern, not the content.
Deployment and resource usage
47Sentry runs as a DaemonSet in Kubernetes or as a systemd service on bare metal. The eBPF programs are loaded at startup and run in kernel context — there's no persistent userspace process in the traffic path. The userspace control plane runs as a lightweight daemon that reads map data, manages updates, and exports metrics. Resource usage is low: typically under 2% CPU on a modern server at high packet rates, and memory usage is bounded by the configured map sizes.
The control plane exports metrics in Prometheus format. NetMapper topology data is available via a REST API. Both integrate naturally with a Grafana/Prometheus observability stack if you're already running one.
What 47Sentry does not do
It's worth being direct about the limitations. 47Sentry is a host-based perimeter tool. It gives you deep visibility and filtering capability on the hosts it runs on. It does not:
- Replace a network-level firewall for traffic between subnets or VPCs — you still want security groups or ACLs at the infrastructure level for east-west filtering at scale
- Do deep packet inspection of encrypted traffic — DNS monitoring and flow analysis work without decryption, but content-based filtering of HTTPS traffic requires a TLS-terminating proxy layer
- Correlate events across hosts automatically — the control plane on each host exports independently; cross-host correlation requires aggregating the Prometheus metrics and NetMapper data centrally
- Substitute for a comprehensive security information and event management (SIEM) system for compliance purposes
What it does do well: eliminate the appliance dependency for host-level perimeter filtering, give you real topology visibility from observed traffic, and provide a DDoS absorption layer that scales with your hardware rather than with a licenced appliance capacity.