Screen functionality helps to protect the network against certain basic types of attacks and malicious traffic. As a bonus it can help to save precious system resources because it is evaluated in the very early stages of traffic processing sequence. Simply put when screens detect and block an attack the SRX does not have to perform the following and more intensive processing. Next, information and few tips about screens are presented that might be helpful when working with them.
The screens are able to detect and block attacks and malicious traffic such as:
- basic ICMP protection (ping of death, icmp fragments, ip sweep, flooding, etc.)
- basic IP attacks (ip options, spoofing, tear drop, unknown protocols, etc.)
- basic TCP attacks (port scan, land attack, incorrect TCP flag combinations, flooding, etc.)
- basic UDP attacks (port scan and flooding)
- limiting the number of sessions allowed from and/or to and one IP address
Most of the options are pretty easy to understand and configure. But for clarity sake lets have a bit closer look at some of the TCP settings because they might not be so straight forward.
SYN-ACK-ACK-PROXY option:
Defines the limit for the number of “TCP connections” from a single IP address. Here the “TCP connections” mean only TCP session that have completed only the 3-way handshake. Additionally ACKs can be sent to prevent the session from timeout but no other data is transmitted from the source. Destination hosts as well as firewalls spend resources for theses sessions even though they do nothing. The SRX enforces the given threshold and the drops further connections from that IP once it is reached.
The source session limit option might look the same but there a difference. The syn-ack-ack-proxy considers only TCP connections whereas the session limit options consider all types of connections (UDP, ICMP, TCP, etc.). As a result if you configure source-ip-based session limit lower than syn-ack-ack-proxy threshold the syn-ack-ack-proxy limit will never be reached.
TCP syn flood options:
The source-threshold and destination-threshold define the limits for the number of sent SYN packets within one second from and to a single IP address respectively. SYN packets above these thresholds are dropped.
Timeout defines the time period for completing the 3-way handshake (called also an embryonic session).
White-list, as the name indicates, contains IP addresses that are excluded from the SYN flood screen checking.
The remaining two parameters – attack-threshold and alarm-threshold – keep track of the SYN packets sent to destination IP address and port combinations. Once the number of SYN packets sent to a destination IP address and port combination (also within one second) reaches the attack-threshold the SRX device starts to proxy the 3-way handshakes for that IP and port combination. The standard proxy method used by default can be changed to syn cookie through configuration (“set security flow syn-flood-protection-mode syn-cookie” command). When the number of incomplete 3-way handshakes being proxied by the SRX reaches the alarm-threshold the device will generate an alarm. In other words the alarm-threshold counts only the SYN packets that arrive after the attack-threshold has been reached. As an simple example – lets assume the attack-threshold is set to 500 and alarm-threshold to 250. The alarm will be generated if 750 (or more) SYN packets destined to the same IP address and port combination arrive at SRX within one second.
To actually enable screen protection on the SRX you have to configure an “ids-option” (can be considered sort of a screen profile). In the ids-option you define the options the device should check for. Then you just need to associate the ids-option with a security zone. You can have multiple ids-options configured on a device.
An example screen configuration:
One ids-option can be associated with multiple zones (shown also on the example above). However each zone can be association with at most one ids-option. This means the screens are enforced on per zone basis.
Use the “show security screen statistics zone
Unfortunately the command output lists all screen options and not only the ones being checked in the defined zone. The statistic values will increase (if detected) only for used screens, the not defined screens statistics will have value of 0. This makes analyzing the command output a bit less pleasant. To identify which screens are actually used in that zone you have to first find out which ids-option is referenced by the zone and then examine that ids-option. Looking at the configuration is one way how to achieve it (configuration excerpts were already shown earlier in the text).
Much better approach is, however, to use operational mode commands.
The “show security zones
The “show security screen ids-option
One very good reason why operational mode commands should be favored over the examining the configuration is displaying the default values. Operational mode commands show them and configuration does not.
An example:
Additionally the operational mode commands help to detect “internal dependencies” in screen options, i.e. when one configured option enables other option/s (with default values) automatically.
For example syn-flood option defined only with attack-threshold and alarm-threshold parameters results in enabling the source-threshold and destination-threshold with their default values as well:
Similar situation was with the session limit option. In Junos releases prior 11.1 if only one options was defined the other one was enabled automatically with the default value. Since release 11.1 the behavior changes and enforced only the explicitly configured session limits.
Junos provides traceoptions for deeper troubleshooting purposes. They are available for screens as well. An example traceoptions configuration is shown below.
The possible values for flag are all, configuration or flow. I my own experience however the trace file contained only configuration related messages regardless of the configured flag.
The line “drop by firewall check” in the trace file of the [edit security flow traceoptions] (flag basic-datapath) indicates the screens did drop the packet. Unfortunately no further information (which attack, packet IPs, zone involved, etc. ) is provided in the entry. This makes a bit limiting for troubleshooting.
The syslog tends to be more helpful than traceoptions when troubleshooting screens processing. Each time an attack or malicious traffic has been detected by screens the module generates a syslog message that contains details about the attack. The syslog messages related to screens are easily identified with the RT_SCREEN string.
Sometimes, such as in the initial deployment phase, it might not be known which particular attacks to look for. In these cases the parameter called “alarm-without-drop” can come very handy. If enabled for an ids-option the screen module will generate only a syslog message and not execute the drop action when an attack is detected. The system should be left operating with this parameter for some time. Then the screen generated syslog messages should be analyzed to find out which attacks really to look for. At last the screen configuration should be adjusted to reflect the analysis result and the “alarm-without-drop” parameter removed.
Conclusion
The screen functionality available on Junos devices can aid in securing your environment and saving system resources on the firewall at the same time. This article shed some light on few screens that are might not be so straight forward to understand. Next, few tips about monitoring and verifying screens are described which can be found helpful in troubleshooting efforts.
