What is deep packet inspection?
What it actually means to look inside traffic, honestly, including what it can and cannot see.
A basic firewall reads the address on a packet and decides whether to let it through, the way a guard reads the address on an envelope. It never opens the envelope.
DPI is what happens when a firewall opens the envelope. It looks at the actual content of the traffic, not just where it is going, and checks that content against known attack patterns.
This matters because the address alone tells you very little. A packet heading to a normal web port can still carry an attack inside it. Checking only the address would let that packet straight through, because nothing about its destination looks unusual.
How looking inside traffic actually works
Firecradle uses Suricata, a widely used open-source engine, to do this job. Suricata compares traffic against a large, regularly updated list of signatures, each one describing a known attack.
This is closer to a spell-checker than to a mind-reader. A spell-checker does not understand your sentence. It compares each word against a dictionary and flags anything that matches a known mistake. Signature-based inspection works the same way, comparing traffic against a dictionary of known bad patterns, rather than reasoning about intent.
What it can see, and what it honestly cannot
Being straightforward about the limits here matters more than making the idea sound powerful. Two limits are worth knowing before you rely on this.
- Most traffic today is encrypted. A TLS connection scrambles the content between your browser and a website, on purpose, so that nobody in between, including your own firewall, can read it without extra setup.
- Signature matching only catches known patterns. A brand-new attack, one nobody has written a signature for yet, will not match anything on the list. It is detection by known fingerprint, not by guessing.
Some firewalls, Firecradle included, offer TLS inspection as an optional feature. It opens encrypted traffic to scan it, then re-encrypts it before it carries on. It needs a certificate installed on every device you inspect this way, and it is not something to turn on for every network without thinking about it first, since it means the firewall genuinely reads content that is normally private.
How this relates to intrusion prevention
IDS and IPS are the two things a firewall can do once it has spotted a match. An IDS, an intrusion detection system, watches and warns you. An IPS, an intrusion prevention system, does the same job but also blocks the traffic immediately, before it reaches its target.
Deep packet inspection is the looking part. IPS is the acting part. Firecradle runs both together through Suricata: traffic gets checked against signatures, and a match gets blocked on the spot, not just logged for later.
Alongside signature matching, Firecradle also watches for traffic that looks unusual compared to a device's normal pattern, a rule- and statistics-based check rather than a guess. A device that suddenly sends far more data than usual, for example, gets flagged even if no single packet matches a known signature.
Why the signature list has to keep updating
A signature only helps once someone has written it, which means new attacks are invisible until a signature for them exists. Signature lists are updated regularly precisely because of this gap. An inspection engine running on a signature list from a year ago is blind to everything discovered since.
This is also why deep packet inspection is best understood as one layer of defence, not the whole defence. It catches known attacks reliably. It is not designed to catch something nobody has ever seen before, and no honest vendor should claim it does.
What this looks like in Firecradle
Firecradle's threat detection runs on Suricata signatures, updated regularly, plus statistical baselining for traffic that looks unusual. It is rule-based, not a black box, and you can see exactly which signature triggered any alert.