The pattern is recognizable from any distance: an SRX gets hardened with a full screen set — icmp-flood, syn-flood, port-scan, ip-sweep — and shortly afterwards, monitoring reports drops, backups stall, or a monitoring host goes dark. Nothing in the security policy changed. The screens did it. Juniper's screens documentation defines the attack types; this guide covers the operational side — recognizing, counting and tuning false positives.
Step 1: Confirm the Screen Is the Dropper
show security flow session destination-prefix 10.20.0.5
show security screen statistics zone UNTRUST
show security screen ids-option SCREEN-UNTRUSTThe statistics output names each screen with an attack-drop counter. If icmp-flood counts climb while your monitoring host pings, the screen is the dropper — a session-level check shows no deny because screens act before policy evaluation, which is exactly why these drops surprise people.
Understand the Thresholds You Set
Screens are simple rate or behavior triggers, not intelligence:
- icmp-flood threshold — ICMP packets per second to a single destination. Default 1000, but a monitoring platform pinging hundreds of devices through one SRX zone can plausibly cross it.
- syn-flood thresholds — attack, alarm, source and destination thresholds interact; a single busy load balancer behind the SRX looks identical to an attack.
- port-scan / ip-sweep thresholds — packets to different ports or different destinations per microsecond window. Vulnerability scanners, discovery tools and legitimate NMSes trip these constantly.
- udp-flood — same shape as icmp-flood; DNS-heavy environments hit it via responses through the firewall.
Tuning: Keep the Protection, Lose the False Positives
Raise the Threshold to Match Real Load
set security screen ids-option SCREEN-UNTRUST icmp flood threshold 4000
set security screen ids-option SCREEN-UNTRUST tcp syn-flood attack-threshold 3000
commitMeasure first: show security screen statistics during peak legitimate traffic tells you what real load looks like; set thresholds a few times above it.
Whitelist Trusted Sources
Monitors and scanners should not traverse the screened zone at all. Put the NMS on the trust side of the SRX, or exempt it by zone: apply aggressive screens only on the UNTRUST zone and gentler ones on the TRUST-to-DMZ path. Screens are per-zone attachments — use that granularity.
Alarm Without Dropping (Trial Mode)
When you are unsure whether a screen will hurt, several screens support counting legitimate traffic into alarm state without drop on lower thresholds — and the logs tell you what would have been dropped:
show log messages | match RT_SCREENRun a week, read the counts, then commit tuned values. The zone/screen interaction is layered on top of the policy model described in the SRX zone and policy guide.
The False-Positive Signature Table
| Broken thing | Screen that did it | Tuning |
|---|---|---|
| Monitoring pings disappear | icmp-flood | Raise threshold / exempt NMS subnet |
| Website load stalls under peak | syn-flood | Raise attack-threshold above real connection rate |
| Scanner runs kill connectivity | port-scan, ip-sweep | Schedule scans off-screen, or whitelist scanner |
| DNS responses lost | udp-flood | Raise threshold; watch DNS traffic volume |
Screens Are One Layer of Several
Do not disable the whole screen set because one threshold was wrong — flood protection at the edge is cheap insurance against real attacks, and the STIG baselines mandate most of it. Tune per zone instead. If after tuning you still see drops, check whether the flow itself is being created at all with the SRX NAT flow-session method, verify policy hits per the zone guide, and if the box spends its CPU on attack processing, the RE high-CPU guide shows which processes to watch.
Discussion (0)