Preview
Rate this lesson

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.  

Juniper SRX Screen Policy in Traffic Flow taken _ photo taken from juniper contents
Juniper SRX Screen Policy in Traffic Flow taken _ photo taken from juniper contents

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.

juniper CLI explorer website
juniper CLI explorer website

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-screen

In 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/32

Juniper 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”.

[email protected]:~/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 ms

The 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.

Back to: Juniper Security Associate (JNCIA-SEC) (in Progress) > Junos Security Objects

Leave a Reply

Your email address will not be published. Required fields are marked *

Post comment