Sunday, 2 December 2012

Screens

Screens offer pre-configured policies which protect zones against specific attacks, vulnerabilities and anomalies. They are processed after firewall filters, and are the first items to be process in the flow module. As they are processed first in the flow module they offer another line of defence to protect network and system resources.

Screen capabilities can be summarized into 5 categories.
1. ICMP (attacks, vulnerabilities and anomalies related to ICMP protocol)
2. IP (attacks, vulnerabilities and anomalies related to Internet Protocol)
3. Limit-Session (threshold based configuration to limit specifically against denial of service attacks)
4. TCP (attacks, vulnerabilities and anomalies related to TCP Protocol)
5. UDP (attacks related to UDP Protocol)
A more detailed explanation of each configurable screen option will be explained during the configuration.

Configuration
The diagram below outlines the basic topology for this exercise.

1. Create Screen & Configure ICMP Screen Options
In this step a screen profile (ids-option) is created, and ICMP related screen options are configured. Here is some descriptions for the various screen options.

flood: monitors and blocks IP packets where the configured number of ICMP packets/second is exceeded. The default is 1000 packets/second. The configurable range is 1 to 100,000 packets/second.

fragment: monitors and blocks any ICMP frame where the more fragments flag is set.

large: monitors and blocks any ICMP frame larger than 1020 bytes.

ping-death: Similar to 'large' option but focused on ICMP frames larger than 65535 bytes as related to an legacy OS vulnerability.

See the screenshot below for command details.

2. Configure IP Screen Options
In this step IP related screen options are configured. Here is some descriptions for the various screen options.

bad-option: monitors and blocks packets with IP options in the IP header for anomalies.

block-frag: monitors and blocks all IP fragments. Some vulnerabilities use IP fragmentation to evade layer 7 detection mechanisms.

loose-source-route-option: monitors and blocks packets with IP option#3 (loose source route). Loose source route is an IP option that allows partial route path manipulation by the client.

record-route-option: monitors and blocks packets with IP option#7 (record route). Record route is an IP option that records the route path of the IP packet.

security-option: monitors and blocks packets with IP option#2 (security). Security is an mostly unused IP option that can contain security parameters.

source-route-option: monitors and blocks packets with data in the source-route-option.

spoofing: monitors and blocks packets that are not expected on interfaces, uses forwarding table to know what source IP addresses should be received on what interfaces.

stream-option: monitors and blocks packets with IP option#8 (stream ID). Stream ID is an unused IP option that can contain security parameters.

strict-source-route-option: monitors and blocks packets with IP option#9 (strict source route). Strict source route allows is an IP option that allows full route path manipulation by the client.

tear-drop: monitors and blocks a specific sequence of fragmentation, and IP options that are used to target hosts.

timestamp-option: monitors and blocks packets with IP option#4 (timestamp). Timestamp is an mostly unused IP option.

unknown-protocol: monitors and blocks packets with IP protocol field greater than 137. IP protocol numbers higher than 137 are considered reserved and undefined. Do not get this confused with TCP protocol numbers, this option focuses on IP protocol number (for example UDP is IP protocol #17).

See the screenshot below for command details.

3. Configure Limit-Session Screen Options
In this step session limiting related screen options are configured. Here is some descriptions for the various screen options.

destination-ip-based: monitors and blocks IP packets where sessions exceed default or configured thresholds to a single destination IP address. The default is 128 sessions/IP address.

source-ip-based: monitors and blocks IP packets where sessions exceed default or configured thresholds from a single source IP address. The default is 128 sessions/IP address.

See the screenshot below for command details.

4. Configure TCP Screen Options
In this step TCP related screen options are configured. Here is some descriptions for the various screen options.

fin-no-ack: monitors and blocks IP packets where FIN flag is set but ACK flag is not. This is unexpected behaviour and can be used to identify a host operating system.

land: monitors and blocks IP packets where the IP address of the destination is the IP address in the source and destination fields of the IP header. This is an attack targeting hosts that send SYN-ACK packet to self-creating an empty session that must time out.

port-scan: monitors and rejects IP packets where a source address sends TCP SYN packets to a single destination addresses on 10 different TCP ports within the default or specified time. Default time is 5000 microseconds (0.005s). The configurable range is between 1000 and 1,000,000 microseconds.

syn-ack-ack-proxy: monitors and rejects IP packets where the source address creates more than the configured number of sessions to a single destination, attempts made past the threshold are rejected. The default threshold is 512 sessions/IP address. The configurable range is between 1 and 250,000.

syn-fin: monitors and blocks IP packets where the SYN and FIN flags are set. This is unexpected behaviour.

syn-flood: monitors and block IP packets where configured thresholds are exceeded. This option is to mitigate basic denial of service (DoS) attacks. SYN, Destination and Source thresholds can be configured.

winnuke: monitors and blocks IP packets where NetBIOS traffic has the URG flag set. This was a vulnerability identified in legacy Microsoft operating systems.

syn-frag: monitors and blocks IP packets where SYN packets are fragmented. SYN packets are not large and would rarely be fragmented.

tcp-no-flag: monitors and blocks IP packets where no TCP flags are set. This is unexpected behaviour and could be used to identify host operating systems.

tcp-sweep: monitors and rejects IP packets where a source address sends TCP SYN packets to 10 destination addresses within the default or specified time. Default time is 5000 microseconds (0.005s). The configurable range is between 1000 and 1,000,000 microseconds.

See the screenshot below for command details.

5. Configure UDP Screen Options
In this step UDP related screen options are configured. Here is some descriptions for the various screen options.

flood: monitors and blocks IP packets where the configured number of UDP packets/second is exceeded. The default is 1000 packets/second. The configurable range is 1 to 100,000 packets/second.

udp-sweep: monitors and rejects IP packets where a source address sends UDP packets to 10 destination addresses within the default or specified time. Default time is 5000 microseconds (0.005s). The configurable range is between 1000 and 1,000,000 microseconds.

See the screenshot below for command details.

6. Verify Screen Option Configuration
The screenshot below outlines the overall screen ids-option configuration completed in the previous steps.

7. Apply Screen to Zone(s)
The next configuration step is attaching the previously configured screen to a zone. Keep in mind that screen are evaluated on the inbound zone. I had intended this zone to be placed on the INTERNET zone, however I also have attached it to the TRUSTED zone so examples could be displayed. The screenshot below outlines the configuration.


8. Create Syslog File for Logging
As stated in previous posts, logging is especially critical when configuring elements that allow/deny transit traffic, at the very least for troubleshooting traffic if not for accounting and auditing purposes. By default screens log events to the control plane (RE) without any special configuration. The screenshot below outlines the commands to create a syslog file to write screen events to. The match statement 'RT_SCREEN' is used to capture screen events. Although it is not done in this example, screen events could also be configured to sent to an external syslog server.


Verify Screen
1. Verify Running Screen Configuration
The command 'show security screen ids-option screenname' is a very useful command not only does it highlight what screen options are configured but it also displays the configured values.

2. Trigger Screen Option
A large ping will be used to test the screen. By running the command 'ping 8.8.8.8 -l 65500' from the windows command prompt we create and send a very large ICMP packet from the client. Two things are going to happen by doing this. First we will trigger the screen option 'ICMP large' as this ICMP packet is over the default threshold of 1024 bytes. Second, we will trigger the 'ICMP flood' option as this large ICMP packet will be fragmented and the number of fragmented packets will exceed the configured threshold  of 10.

3. Verify Screen Statistics
The command 'show security screen statistics zonename' can be used to see the screen options that have been hit or triggered.

4. Verify Screen Logs
The screenshot below displays the output from the configured log file. ICMP large and ICMP flood events can be confirmed along with details such as the source IP address and source zone.



Use Screens in Monitor Only
Predicting what screen will block in a large network environment is difficult. One feature that can be leveraged is alarm-without-drop. This is enabled at the screen policy level and will ensure only log events are generated but traffic is not dropped or rejected. This is great for an administrator who wants to introduce a screen policy and monitor how it performs first. The screenshot below outlines the command to enable alarm-without-drop on the screen we created in the exercise above.



Conclusion
Screens provide an excellent set of features in the Layer 3 & 4 protocol stack that are not excessive on resources. Some of the screen options address very old vulnerabilities. Even though vulnerabilities may not be common screens still offer an excellent layered approach to the security model in the SRX. If anyone notices any errors in my explanations of screen options please feel free to leave comments.


No comments:

Post a Comment