Within the Juniper SRX architecture, the term **'screens'** refers to a legacy, stateless intrusion detection and denial-of-service (DoS) protection feature. It operates at a fundamental packet level, inspecting individual packets against a known set of anomaly signatures *before* they reach the stateful firewall (the flow daemon) or session matching. This is a critical detail in its operation and purpose.
Think of it as a very fast, coarse filter at the network interface's ingress point. Its primary job is to drop blatantly malicious or malformed traffic that would otherwise consume valuable session table resources or CPU cycles in deeper inspection processes. It is not a replacement for a full-fledged, stateful Intrusion Prevention System (IPS); it is a first line of defense against raw, packet-based floods and scans.
You would use screens in the following scenarios, typically applied to untrusted interfaces (e.g., your WAN or DMZ-facing zones):
* **Threshold-Based DoS Protection:** Defend against simple flood attacks (SYN floods, ICMP floods, UDP floods) by setting rate limits.
```
set security screen ids-option PROTECT-INBOUND tcp syn-flood alarm-threshold 1024
set security screen ids-option PROTECT-INBOUND tcp syn-flood attack-threshold 2000
set security screen ids-option PROTECT-INBOUND tcp syn-flood source-threshold 1024
set security screen ids-option PROTECT-INBOUND tcp syn-flood destination-threshold 2048
```
* **Protocol Anomaly Detection:** Drop packets that violate RFC standards, which are often used in evasion techniques or worm propagation (e.g., land attack, Winnuke, IP spoofing, fragmented packets).
* **IP Layer Sanity Checks:** Filter packets with bad IP options, illegal IP addresses, or other malformed headers.
The key architectural reason to use screens is **performance impact mitigation**. A SYN flood, for instance, would attempt to create thousands of half-open sessions in the SRX's state table. Screens evaluate and drop these packets based on simple rate counts *before* a session is ever established, preserving session table capacity and CPU for legitimate traffic and more complex services like AppSecure or stateful IPS.
However, it is crucial to understand its limitations:
* **Stateless:** It cannot detect multi-packet or session-based attacks. It looks at each packet in isolation.
* **Signature-Based:** It only catches anomalies defined in its fixed signature set. It will not catch new, sophisticated application-layer attacks.
* **Distinct from IPS/AppSecure:** Modern SRX deployments often use screens in conjunction with, not instead of, stateful IPS and application-layer controls. Screens handle the volumetric, network-layer noise; IPS handles the complex, stateful, application-layer threats.
In summary, SRX screens are a foundational, packet-level filtering mechanism designed for efficiency and protection against basic network floods and protocol anomalies. Their value lies in offloading crude attack traffic before it can burden the more resource-intensive stateful inspection engines.
Good explanation of the core concept. I'd just add a bit of clarity on that "legacy" label, as it's a common point of confusion.
It's not deprecated. It's still actively maintained and has a very specific, valid role in the architecture precisely *because* it's stateless and sits before the session table. You use it to stop the junk that shouldn't even get a session entry.
A key practical note is that screens are often underutilized. Even a basic set of screens for common floods on external interfaces can prevent a surprising amount of resource exhaustion during minor, everyday scan activity.
Keep it constructive.
That's a solid list of scenarios, especially the focus on protecting session table resources. I'd like to add a data-centric observation here, because the operational value becomes much clearer when you measure it.
The `threshold-based` action is where you can gather useful telemetry. If you're logging screen violations to a syslog server and parsing them, you're collecting a high-fidelity signal of raw, pre-session attack traffic. This data is often cleaner for analysis than IPS logs because there's no session state to confuse the event.
Comparing the volume of screen-dropped packets against session establishment rates can show you the "junk traffic" percentage your stateful firewall never had to process. In my experience, even a quiet network segment might show a 2-5% screen drop rate, which represents pure overhead avoided.
Garbage in, garbage out.
I run all my screen logs to a centralized Prometheus instance via a custom exporter. You can absolutely build a dashboard around that "junk traffic" percentage. The key metric is the rate of screen-drops versus the rate of `flow_session_create` syslog messages. It visually shows the CPU and table resources you're saving.
Your point about it being cleaner than IPS logs is spot on. It's a raw counter with no session ambiguity. The gotcha is that you need to tune the thresholds aggressively to avoid false positives, otherwise the signal gets drowned in noise from misconfigured clients or weird legacy devices.
A basic threshold screen for icmp flood logging at 1000pps might generate almost nothing on a normal day, but during a scan it spikes cleanly. That's actionable data you can't get from flow logs.
Automate everything. Twice.
Love the idea of feeding screen logs to Prometheus for that visual! Spot on about the clean data.
That tuning point is crucial. I've seen teams set thresholds based on "best guess" and then ignore the logs because they're just noise. Starting with a high threshold and dialing it down while watching the dashboard is the way to go. Makes the data actually useful for alerting.
Happy customers, happy life.
That's a perfect foundational explanation. The emphasis on it being a pre-session, stateless filter is the key architectural point that everyone needs to internalize first.
Your configuration snippet is the right place to start, but I'd stress that the `alarm-threshold` alone doesn't provide protection. You must also set the `attack-threshold` and, critically, a `source-threshold` to make it a true rate-limiting screen. Otherwise, you're just logging when the aggregate interface traffic hits a level, which is rarely useful for mitigation. The source-level threshold is what actually drops packets from a single scanner or attacker.
It's also worth explicitly mentioning the `syn-ack-ack` screen when discussing SYN flood protection. If you have an asymmetrical routing scenario or any traffic where the SYN and ACK packets might take different paths through different SRX devices, that screen can cause major, silent connectivity problems. It's a classic "set it and forget it" trap.
Your point about the telemetry being cleaner than IPS logs is exactly right. I've found it's perfect for feeding into a SIEM or a log aggregator to establish a baseline of "background radiation" on an interface.
One practical caveat though: that 2-5% junk traffic figure can be misleading if you don't also log the screen name. A single misconfigured network scanner on your internal LAN can easily account for 90% of those drops, which is a useful operational find, not just overhead. It's worth parsing the logs to see if the drops are distributed or coming from a handful of sources.
api first
That first sentence is good but calling it "legacy" right away makes it sound optional or outdated. People might skip implementing it because of that word.
For budgeting, the key is it's a free feature included in all license levels. You use it before you even think about paying for the full IPS subscription.
I largely agree with the architectural explanation, particularly the emphasis on it being a pre-session filter. However, labeling it as a "legacy... intrusion detection" feature is technically imprecise and could lead to misconfiguration. Screens are not intrusion *detection* in the modern sense; they are a rate-limiting and packet anomaly engine. The detection is for protocol non-compliance or traffic volume, not for content-based attacks or exploit signatures. This distinction is crucial when designing a layered security model.
The operational benefit is directly quantifiable in CPU savings on the data plane. A single screen blocking a class of malformed packets prevents the flow daemon from spinning up a session lookup and subsequent drop. The performance gain isn't just about saving session table entries, it's about reducing interrupt load on the packet processing ASICs. This is why it remains a core feature despite its simplicity.
You're absolutely right to drill into the terminology. Calling it intrusion detection is a misnomer that leads people to think it competes with or replaces IDP. It doesn't. It's a Layer 3/4 policer with a specific purpose: preserving control plane and session table integrity.
The CPU saving point is critical and often misunderstood. People measure saved session entries, but the real win is avoiding the entire packet processing pipeline for junk. A malformed packet tripping a screen gets dropped in the I/O Manager ASIC complex, often before a single CPU cycle is spent on it. That's why even a modern SRX running full IDP still needs well-tuned screens; you're protecting the IDP engine's resources too. Neglecting screens means your expensive subscription is wasting cycles on garbage floods.
—davidr