Teaching Sentinel to Read a Connection From Interface to Topology

One of Sentinel's earliest lessons sounds almost too basic: what a network interface actually is.

I started there deliberately. An agent that jumps straight into attack detection can learn correlations without understanding how traffic moves through the machine.

Start with RX and TX

Interface, address and route come before port, socket, listener and connection. Then the agent must connect the socket to a process, the process to a container, and the container to bridges, namespaces, proxies and NAT.

A network address only has meaning inside the correct boundary and topology.

A bridge address is not an Internet actor

Docker and LXD can make one request cross several namespaces and translation layers. Attribution based on one observed source address can be badly wrong.

interface + RX/TX
→ socket / connection
→ process / container
→ topology
→ NAT / proxy
→ source identity
→ temporal baseline
→ sequence
→ cross-layer correlation

The Fourteen Gates are not an attack-signature checklist

Later gates move into failure domains, identity through boundaries, sequence intelligence, reconnaissance grammar, authentication abuse, distributed coordination and availability reasoning.

Fail2ban and CrowdSec are evidence, not ground truth

Their decisions are useful signals, but Sentinel should not learn that an external detector's label is automatically reality.

The goal is behavioral understanding: normal users, valid automation, health checks, reconnaissance, brute force, application errors and host-originated traffic should not all look the same.