Juniper SRX screen options provide the ability to detect and prevent attacks primarily at Layer 3 and Layer 4. between them, the most well-known attacks are ICMP flood, UDP flood and TCP syn flood.
Juniper SRX screen policy is the first policy applied to traffic in the ingress direction of the interface for both packets from new sessions or belonging to the existing sessions.
Juniper SRX screen options Fundamental
If you remember from the section, “juniper SRX traffic Flow”, the screen policy is the first policy applied to incoming traffic for both new and existing sessions.
The target of the Screen Policy is to detect and prevent attacks primarily at Layer 3 and Layer 4.
There is a large list of attacks that screen policy can prevent. But they are divided into two main categories.
The first category includes attacks that are detected based on statistics, such as ICMP flood, UDP flood, and TCP syn flood.
In the second category, attacks are detected based on known signatures. and if the packet contains a pattern of a specific attack signature, then the attack will be detected.
Juniper SRX screen options definition
In this section, I am not going to define the attacks that are detected by the screen policy as they are mostly self-explanatory.
Additionally, you can easily find the definition of each attack on the Juniper CLI Explorer website.
For example, when I enter the keyword “tear” to discover the description of the “tear-drop” attack, it is written that it identifies and discards overlapping fragmented IP packets.
You can find easily the description of all screen options over the internet or on this website.
Juniper SRX default screen policy
By the juniper SRX version 22.1R1.10 that I am working on, there is default screen policy with the name of “untrust-screen”, applied to the interfaces in untrust zone.
On this policy, “ping-death” attack in ICMP category, “source-route-option” and “tear-drop” attack in IP category and “tcp syn-flood” and “tcp land” in TCP category are active.
rayka# run show configuration security screen
ids-option untrust-screen {
icmp {
ping-death;
}
ip {
source-route-option;
tear-drop;
}
tcp {
syn-flood {
alarm-threshold 1024;
attack-threshold 200;
source-threshold 1024;
destination-threshold 2048;
queue-size 2000; ## Warning: 'queue-size' is deprecated
timeout 20;
}
land;
}
}
rayka# run show configuration | display set | grep screen
set security screen ids-option untrust-screen icmp ping-death
set security screen ids-option untrust-screen ip source-route-option
set security screen ids-option untrust-screen ip tear-drop
set security screen ids-option untrust-screen tcp syn-flood alarm-threshold 1024
set security screen ids-option untrust-screen tcp syn-flood attack-threshold 200
set security screen ids-option untrust-screen tcp syn-flood source-threshold 1024
set security screen ids-option untrust-screen tcp syn-flood destination-threshold 2048
set security screen ids-option untrust-screen tcp syn-flood queue-size 2000
set security screen ids-option untrust-screen tcp syn-flood timeout 20
set security screen ids-option untrust-screen tcp land
# applied to the interfaces in untrust zone
set security zones security-zone untrust screen untrust-screenIn the last line, the screen policy with the name of “untrust-screen” is applied to the untrust zone.
All traffic incoming to the interfaces in untrust zone are inspected by this policy.
review Juniper SRX screen policy options
Just to review the list of attacks covered by the screen policy, we enter the command “set security screen ids-option NAME ?”.
rayka# set security screen ids-option outside-screen ?
Possible completions:
> aggregation Configure the source and Destination prefix for a ids-option
alarm-without-drop Do not drop packet, only generate alarm
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
description Text description of screen
> icmp Configure ICMP ids options
> ip Configure IP layer ids options
> limit-session Limit sessions
> tcp Configure TCP Layer ids options
> udp Configure UDP layer ids options
[edit]As you can see the attacks are classified in four categories. IP, TCP, UDP and ICMP.
There are two other options, “alarm-without-drop” and “limit-session”.
The “alert-without-dropping” option is to log an alert for an offending packet but not drop the packet. By default, offending packets are dropped and you must enable this option to not drop offending traffic.
rayka# set security screen ids-option outside-screen alarm-without-drop Unfortunately it is not possible to enable this feature per attack. Therefore, in my opinion, it does not make sense to enable this feature for all attacks at once.
The second option, “limit-session” is to limit the number of sessions per source or per destination IP. For example you can limit that no sources over the internet can open more than 100 session to our network.
rayka# set security screen ids-option outside-screen limit-session ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
destination-ip-based Limit sessions to the same destination IP (1..2000000)
source-ip-based Limit sessions from the same source IP (1..2000000)As another example, you can specify that the maximum number of sessions for each of our target servers does not have to be more than 1000.
Unfortunately it is not possible to enable this feature for a specific source or destination IP. Therefore, in my opinion, most of the time it does not make sense to enable this feature for all source and destination IP addresses at once.
Now let’s review the list of attacks covered by screen policy in each category. I am not going to give any description for these attacks. I am going to just show the list of attacks in each category once.
In the category of ICMP, “ping flood” and “ping-death” are probably the most well-known attacks/
rayka# set security screen ids-option outside-screen icmp ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
> flood Configure icmp flood ids option
fragment Enable ICMP fragment ids option
icmpv6-malformed Enable icmpv6 malformed ids option
> ip-sweep Configure ip sweep ids option
large Enable large ICMP packet (size > 1024) ids option
ping-death Enable ping of death ids option
[edit]In the category of IP, we hear a lot about “bad-option”, “source-route-option”, ‘IP spoofing’ and “tear-drop” attacks.
rayka# set security screen ids-option outside-screen ip ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
bad-option Enable ip with bad option ids option
> block-frag Enable ip fragment blocking ids option
> ipv6-extension-header Configure ipv6 extension header ids option
ipv6-extension-header-limit Enable ipv6 extension header limit ids option (0..32)
ipv6-malformed-header Enable ipv6 malformed header ids option
loose-source-route-option Enable ip with loose source route ids option
record-route-option Enable ip with record route option ids option
security-option Enable ip with security option ids option
source-route-option Enable ip source route ids option
spoofing Enable IP address spoofing ids option
stream-option Enable ip with stream option ids option
strict-source-route-option Enable ip with strict source route ids option
tear-drop Enable tear drop ids option
timestamp-option Enable ip with timestamp option ids option
> tunnel Configure IP tunnel ids options
unknown-protocol Enable ip unknown protocol ids option
[edit]In the category of TCP, “port-scan”, “syn-flood” and “tcp-sweep” are probably the most well-known attacks.
rayka# set security screen ids-option outside-screen tcp ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
fin-no-ack Enable Fin bit with no ACK bit ids option
land Enable land attack ids option
> port-scan Configure TCP port scan ids option
> syn-ack-ack-proxy Configure syn-ack-ack proxy ids option
syn-fin Enable SYN and FIN bits set attack ids option
> syn-flood Configure SYN flood ids option
syn-frag Enable SYN fragment ids option
tcp-no-flag Enable TCP packet without flag ids option
> tcp-sweep Configure TCP sweep ids option
winnuke Enable winnuke attack ids option
[edit]And finally In the category of UDP, we have “UDP flood”, “port-scan” and “udp-sweep” options to be configured.
rayka# set security screen ids-option outside-screen udp ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
> flood Configure UDP flood ids option
> port-scan Configure UDP port scan ids option
> udp-sweep Configure UDP sweep ids option
[edit]Another point regarding screen policy is that sometimes we want to exempt some IP addresses from being inspected by screen policy.
For example the computers in security operation center are allowed to simulate attacks for penetration testing and security analysis. It is expected that traffic from these IP addresses are not blocked with screen policy.
With the command “set security screen white-list”, you are allowed to exempt some IP addresses from being inspected by screen policy.
rayka# set security screen white-list WHITELIST address 192.168.1.100/32Juniper SRX screen options configuration example
Just to have a sample configuration, let’s enable the screen option “icmp flood” with threshold 10. This means that a maximum of “10” ICMP packets are allowed per second and for a given source and destination IP.
[edit]
rayka# set security screen ids-option outside-screen icmp flood threshold 10
[edit]
rayka# set security zones security-zone outside screen outside-screen
[edit]
rayka# show | compare
[edit security screen]
+ ids-option outside-screen {
+ icmp {
+ flood threshold 10;
+ }
+ }
[edit security zones security-zone outside]
+ screen outside-screen;
[edit]
rayka# Juniper SRX Screen Policy Monitoring
To make sure that it works, I ping it the outside interface of juniper device itself with “-f” or “force option”.
majid@majid-ubuntu:~/yang/vendor/cisco/xe/1711$ sudo ping -f 192.168.1.250
PING 192.168.1.250 (192.168.1.250) 56(84) bytes of data.
....................................................................................................................................................................................................................................................................................................................................................................................................................................................^C
--- 192.168.1.250 ping statistics ---
476 packets transmitted, 40 received, +1 duplicates, 91.5966% packet loss, time 6986ms
rtt min/avg/max/mdev = 0.134/0.426/2.553/0.393 ms, pipe 4, ipg/ewma 14.708/0.228 msThe output shows that more than 90% of packets are dropped. It shows clearly that only 10 ICMP packets are allowed per second and all other ICMP packets are dropped.
In the output of command “show security screen statistics zone outside”, you can see also the statistics regarding different attacks detected by screen policy.
rayka# run show security screen statistics zone outside
Screen statistics:
IDS attack type Statistics
ICMP flood 436
UDP flood 0
TCP winnuke 0
TCP port scan 0
UDP port scan 0
ICMP address sweep 0
TCP sweep 0
UDP sweep 0
IP tear drop 0
TCP SYN flood 0
...
The output shows that 436 packets are detected as “ICMP flood” attack and are dropped by screen policy.