The end of port-based rules
Classic firewall logic was simple: decide which ports are open. Port 80 for web, 443 for secure web, 25 for mail. That model is now useless because almost all traffic flows over 443 — social media, your business application and data-exfiltrating malware alike. "Allow 443" has become close to "allow everything". Meaningful control requires understanding which application the traffic belongs to, which means moving up to Layer 7.
SNI: the field left in the open
The Client Hello, the first packet of a TLS handshake, is sent before encryption begins. It carries the Server Name Indication (SNI) field, which states in plaintext which domain the client wants to reach. SNI exists for a technical reason: when several HTTPS sites share one IP, the server must know which certificate to present, and it needs that before the handshake completes — so it cannot be encrypted.
The security consequence: you can see the destination domain without decrypting the traffic. The filtering decision is made on that field; if a rule matches, the TLS connection is cut with an RST.
The big advantage is that this needs no SSL inspection. SSL inspection requires installing a corporate certificate on every client, is contentious for privacy, and breaks applications that use certificate pinning. SNI-based filtering avoids all of that.
Know the limits too: SNI shows only the domain, not a specific page beneath it, and as Encrypted Client Hello (ECH) spreads, the method's coverage will narrow. SNI filtering should therefore be combined with DNS-layer controls and other signals rather than used alone.
What DPI sees
Deep Packet Inspection looks at packet contents, not just headers. In unencrypted traffic, HTTP headers (Host, User-Agent, Referer, Content-Type) can be read directly and DNS queries and responses analysed. Libraries such as nDPI recognise hundreds of protocols and applications — YouTube, Netflix, Teams, WhatsApp, BitTorrent — from their traffic patterns.
JA3: fingerprinting encrypted traffic
JA3 hashes the parameters in a TLS Client Hello — supported cipher suites, extensions, elliptic curves and their ordering — into a fingerprint of the client; JA3S does the same for the server response. Clients built on the same library produce the same fingerprint, so if a malware family uses a particular TLS stack it can be recognised even when the domain it contacts changes every time. That makes it effective against traffic trying to evade domain-based blocking.
Binding the rule engine to the user
IP-based rules fall short in a modern network: DHCP changes addresses, one person uses a laptop, phone and tablet, and shared devices have many users. Meaningful policy binds to identity through Active Directory / LDAP with NTLM or Kerberos authentication, so a user gets the same policy on any device, group membership changes update rules immediately, and guests fall back to IP-based rules.
Rate limiting and QoS
Not every problem is solved by blocking. Video streaming, cloud backup and large downloads should be limited rather than banned. A Token Bucket algorithm applies bandwidth limits per IP, per user or per application/domain, with separate packet-per-second limits. On breach you can block, throttle, or lower QoS priority via DSCP marking.
DSCP marking is particularly useful: traffic is not blocked, it is simply sent last when the network is congested — the right tool for protecting latency-sensitive video conferencing while pushing bulk downloads into the background.
Rule versioning: being able to go back
The most expensive firewall mistake is a bad rule taking down production. Version every change: each configuration edit is stored as an immutable, timestamped commit recording who changed what and when, with one-click rollback to the last known-good version and a visual diff between versions. Add a four-eyes approval step and the chance of a misconfiguration reaching production drops sharply.
Central management for distributed deployments
Connecting to each device individually does not scale. Rule sets must be pushed centrally to branches, regions or device groups, with deployment status (deployed / pending / failed) visible in real time. Region-specific rule sets handle local exceptions — a machine network in a plant need not follow the same policy as the office network.
Visibility and SIEM
Writing rules is half the job; seeing what happens is the other half. A live flow view of allowed and blocked connections — source IP, user, destination domain, protocol, matched rule and action — is the basis of troubleshooting. Per-rule hit counters matter for hygiene too: a rule that has not matched in months is either unnecessary or written incorrectly, and both deserve a look.
Shipping events over syslog (RFC 5424) in structured JSON or CEF lets you correlate firewall data with other sources in Splunk, IBM QRadar, Elastic SIEM or Wazuh.
Our Cloud Firewall Management Platform
The L7 DPI firewall we build in house and the Cloud Firewall Management Platform that manages it implement exactly this approach: nDPI-based L7 analysis, filtering by parsing SNI from the TLS Client Hello, JA3/JA3S fingerprinting for encrypted traffic classification, a user- and group-aware rule engine integrated with AD/LDAP, Token Bucket rate limiting with DSCP marking, instant rule distribution to branches and regions from the cloud panel, Git-like rule versioning with one-click rollback, four-eyes approval, a real-time traffic monitor and SIEM integration over syslog/CEF.
Contact us for a review of your current rule set and a demo of L7 visibility.