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.


Saturday, 1 December 2012

Firewall Filters

Firewall filters are synonymous to Cisco's access control lists (ACL). They evaluate traffic without respect to session state and will perform a configured action if a match condition is met. Firewall filters can be applied to an input interface, output interface or to both. When thinking about security and attack prevention it usually makes sense to apply filters on the input interface. This also helps preserve system resources as the traffic is not further inspected or processed (if the firewall filter action is reject or discard).

The diagram below outlines the SRX flow module and order of events. Firewall filters are referenced as 'per packet filter' in this diagram. This diagram gives a good visual representation of where firewall filters are applied in the sequence of events.



Definitions
Firewall Filters are created consisting of terms. Terms are processed in order. The firewall filter has a default-deny/drop action at the end.

Terms consist of from(match) and then(action) statements.

From statements specify parameters to match traffic. The match options vary based on protocol family.

Then statements specify actions to take if the from condition is matched. This actions vary based on protocol family.



Configuration Framework
1. Create firewall filter with term(s).
2. Apply filter to logical interface for a specific direction.
*remember last term must be accept or all traffic will be dropped*

It should be noted that when configuring firewall filters directly under the [edit firewall filter name] stanza that inet (IPv4) firewall filters are actually created. Inet (IPv4) firewall filters can also be configured under [edit firewall family inet filter name]. The reason for this (from what I could find) is that older versions of Junos originally only supported the protocol family inet firewall filters and did not have the need to specify protocol family. This method of allowing both options allows for backward compatibility with legacy configurations.

Firewall filters configured for a specific protocol family can only be configured on interfaces which are configured under the same protocol family. For example you cannot apply a 'family inet' firewall filter to an interface configured as 'family bridge'.




Logging
Logging is important whenever action is taken on traffic, and firewall filters are no exception. There are two logging actions that can be defined under the 'then' statement within a firewall filter term. The first is 'log', in this statement events are generated and stored on the packet forwarding engine (PFE) and not the control plane (RE). The second is 'syslog', with this statement configured events are generated and sent to the control plane (RE) for processing. They can be send to external syslog servers or written to local files with the appropriate syslog configuration.



Applications & Examples
The following basic topology will be used for the following examples.

1. Block specific Protocol/IP Address
This example outlines how specific protocols and/or IP prefixes can be blocked on the ingress of an interface. This could be useful for purging unwanted traffic before it is processed by the flow module. In this specific example I set up a firewall filter with two terms. The first term is set to match icmp-echo-request traffic destine for the IP address of 8.8.8.8. The second term is to pass (or accept) all other traffic. Without the second term all traffic not matching the first term would be dropped. Lastly the filter is applied to an interface on the inbound direction. The screenshot below outlines the commands.

In the above configuration example 'log' was configured under the then statement for term BLOCK8888. This ensures that events are logged on the PFE. To display these events the command 'show firewall log' can be used. The screenshot below displays the output.

As mentioned above there is a second logging method of syslog. The screenshot below modifies the example so that term BLOCK8888 is configured to log the syslog method. See the screenshot below for command details.

Syslog files can now be created so that firewall filter log events are written to local files. The screenshot below outlines the commands to create two log files. The first is a file which is created with a match statement. In this case we can match on firewall filter events by matching 'PFE-FW'. The second log file uses a pre-canned definition of 'firewall' which will also log firewall filter events. Although it is not done in this example, we could also specific external syslog servers to have these events send to an external syslog server.

The command 'show log logfilename' can be used to display the contents of the log file. The immediate screenshot below displays the log file where a match statement is specified. The second screenshot displays the log file where the predefined syslog firewall log was used.



2. Bypass Flow Module
This example outlines how identified traffic can be set to bypass the flow module. The SRX does allow you to enable packet mode on the entire device (making it function like a traditional router). If you need to apply this kind of treatment for only certain traffic then using firewall filters with the action of 'packet-mode' will allow you to do this. In this specific example I have created a firewall filter to identify traffic from the subnet 192.168.1.0/24 to the IP address of 192.168.1.1 (interface of the SRX). The then statement is 'packet-mode' meaning traffic matching this statement will be processed as if the device was a router (no flow module processing).
**Keep in mind that if using firewall filters to bypass flow module for transit traffic, firewall filters will be needed in both directions.**

The command 'show log logfilename' can be used to verify that traffic is matched and therefore bypassing the flow module.

We can also confirm the flow management is bypassed by accessing the JWeb management page. The screenshot following this one displays the security zone configuration. You will notice that (https) is not listed under host-inbound-traffic. This would be that access to the JWeb page on https should not be allowed. In this case it is as the traffic is bypassing the flow module. 




Conclusion
Firewall filters offer a very flexible and light-weight method of controlling traffic. The conditions traffic can be matched on are very powerful and extensive. Some tasks would be better done in the security policy, others with firewall filters. Overall it is another feature to leverage in the SRX product when needed.