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.



Friday, 30 November 2012

SRX Transparent Mode

Transparent Mode is listed as a topic on the JNCIE-SEC exam blueprint. It is also supported on all SRX platforms as of Junos 11.1. The idea behind transparent mode is that the device does not do any routing of transit traffic, only bridging (switching). Some components operate the same between transparent mode and normal routed mode. Others are different or not supported altogether.  The following will step through some key topics related to transparent mode. Following these topics a basic configuration exercise will be demonstrated.

Bridge Domain
A bridge domain is a grouping of L2 interfaces in the same broadcast domain (very similar to VLAN). It is possible to configure a bridge domain with multiple VLANs using the `list`statement, however keep in mind the subsystem still creates a bridge domain for each VLAN. This method allows for a more manageable configuration is some scenarios.

Integrated Routing & Bridging Interface (IRB)
Integrated routing and bridging interfaces are used by the router to send/receive traffic. They are NOT used to forward or route any transit traffic. They may be needed to manage the device or for such things as firewall user authentication and to stream logs from the data plane. IRB interfaces cannot be configured on bridge domains which contain multiple VLAN-ids. They are also not configured under any L2 security zone.

L2 Security Zones
Layer 2 security zones are very similar to regular (routed) security zones. The main difference is that they contain logical Layer 2 interfaces instead of routed layer 3 interfaces.

L2 Security Policies
Layer 2 security policies are also similar to regular (routed) security policies. Due to the nature of Transparent Mode some features are not supported such as;
1. NAT
2. IPSec VPN
3. IDP

Forwarding Table
Just as a router would have a routing table a switch (or SRX in transparent mode) has a forwarding table. The default learning mode for an SRX in transparent mode is the same method a switch uses to build its forwarding table. The SRX device will monitor traffic and learn source MAC addresses sent on a port. If the device needs to forward a frame and does not have an entry in the forwarding table it will flood the frame out all L2 interfaces in that broadcast domain except the port it was received on. Address resolution protocol (ARP) can also be used to learn MAC addresses. This option is not on by default and needs to be configured. It provides a slightly more secure option as the ARP frame is flooded not the transit traffic frame.



Configuring Transparent Mode
The diagram below visually outlines this exercise. The SRX240 in the diagram below is configured in transparent mode, it will be segmenting the 192.168.1.0/24 subnet. Devices connected from the top of the subnet will be in the L2 security zone of 'LAN-L2-Untrust' and devices connected from the bottom of the subnet will be in the L2 security zone of 'LAN-L2-Trused'. Multiple subnets and VLANs could be used on a single device in transparent mode, however this example will use one.

1. Configure Bridge Domain
In this step the bridge domain is created and a VLAN is assigned. The screenshot below outlines the configuration for the bridge domain.

2. Configure Interface ge-0/0/0 (Access Port)
This step outlines the procedure to configure an access port. The device connected to this port would not need to tag frames with a VLAN-id. The act of configuring VLAN-id 192 will place this logical interface in the bridge domain created in step #1. The screenshot below outlines the commands.

3. Configure Interface ae0 (Trunk Port)
This step outlines the procedure to configure a trunked port. In this case the trunked port is configured on interface ae0 as these ports are in a Link Aggregation Group. The configuration done on interface ae0 would be the same procedure to configure a standalone port as a trunked port. The screenshot below outlines the commands.

4. Configure Security Zones
In this step L2 security zones are configured. They are configured in the same fashion as regular security zones. The screenshot below outlines the commands.

5. Configure Security Policies
Security policies are also configured in the same manner as regular security policies. Just remember to keep in mind what options are not supported (they are listed near the beginning of the post). In this example I have created a rule permitting all traffic in both directions. It is important to remember that even though these are called Layer 2 security policies we can still match traffic by IP and application (layer3&4). Address book entries and custom applications can still apply here.

6. Configure IRB Interface
In this step the IRB interface is created. It is also important to note that this interface is not added into any security zones. You might ask, how access could be controlled via host-inbound-traffic if it is not a member of any zone? How it works is that host-inbound-traffic is still applied to the IRB interface, however it is applied from the source zone of the traffic destine for the IRB interface. If I am attempting to ping the IRB interface and I am coming from the source zone of L2-LAN-Untrust ping will need to be defined under host-inbound-traffic for this zone. The screenshot below outlines the commands to configure the IRB interface.

7. Change MAC Learning Process (Optional)
This is an optional step to change the method of MAC learning. By default the SRX will learn MAC addresses similar to a switch (flood MAC if destination is unknown). This option changes the learning to use ARP requests. ARP requests are still flooded, however the ARP frame is less sensitive that potential data that might be flooded in the event the SRX does not know its destination.

7. Reboot SRX
This is required step when configuring interfaces in transparent mode (using the bridge statement). The output below uses the command 'commit check' to demonstrate the warning message that will appear. If the device is later reconfigured to be back in normal (routed) mode another reboot will be required. 




Verify Transparent Mode
1. Show Bridge Domain
The command 'show bridge domain' outlines the configured bridge domains along with logical interface members. 

2. Show MAC Table
The command 'show bridge mac-table' displays all of the learned MAC addresses. The output also confirms on what interface they were learned and the method that they were learned.

3. Show Global MAC Count
The command 'show l2-learning global-mac-count' displays the number of MAC addresses learning globally. Each SRX model has limits on the number of MAC addresses that can be learned, this command can be used to confirm the number of MAC addresses learned is within safe limits.



Configure VLAN Rewriting
In this quick exercise I will configure and demonstrate the VLAN rewriting feature that is present in transparent mode. The diagram below outlines the basic topology for this exercise. It is almost exactly the same as the previous exercise with one minor difference. The switch near the bottom of the diagram does not have VLAN 192 configured, instead it is using VLAN 1192. The VLAN rewriting feature can be used to 'translate' VLAN 1192 to VLAN 192 on the transparent SRX interface of ae0 (ge-0/0/1 and ge-0/0/2).

1. Configure VLAN Rewriting
The screenshot below outlines the existing configuration on interface ae0. Then the command to configure VLAN rewriting is executed. Then the modified configuration is show again. Basically we have configured interface ae0 to expect frames with a VLAN-id of 1192 and then translate them to VLAN-id 192. Keep in mind this is done in both directions.



Verify VLAN Rewriting
The command 'show bridge rewrite statistics interface ae0' displays the rewriting configuration along with egress and ingress packet counters. The screenshot below confirms that frames are being translated.



Conclusion
This post demonstrates the flexibility of the SRX product. Although transparent mode might not be a common option it is good to understand the capabilities of the SRX as a scenario might arise where this type of deployment is needed. If anyone has comments or suggestions regarding transparent mode please leave comments.


Saturday, 24 November 2012

SRX UTM - Antivirus

The antivirus UTM module monitors traffic on all supported UTM protocols (SMTP, POP3, IMAP, HTTP and FTP) and will detect/block malicious code. In this post  'Full Antivirus (Kaspersky)' will be configured. I'm unable to demonstrate 'Express Antivirus' as this is not supported on the hardware I am using for this lab (SRX100). I will also not demonstrate Sophos Protection, however the Sophos Protection will follow the same configuration structure as the Full Antivirus Protection. This post builds on UTM knowledge discussed in the UTM Overview Post, please feel free to reference this post first. The diagram below outlines the basic lab setup for this exercise.

Configure Full Antivirus Protection (Kaspersky)
1. Confirm Licensing 
A license is required to use the antivirus UTM module. The command 'show system license' displays the installed licenses. The license 'av_key_kaspersky_engine' is needed for this exercise.

2. Create Custom Objects
Custom objects can be created and used as various black and whitelists. The antivirus module supports multiple black and whitelists, one for MIME patterns and another for URL patterns. The screenshot below outlines some examples of custom objects.

3. Create Antivirus Feature-Profile
The antivirus feature profile contains settings for the whole antivirus UTM module as well as profile specific information. Black and whitelist are defined for the whole antivirus module. Also the type of scanning engine is defined (in this case we are using 'kaspersky-lab-engine'). After these settings are complete a profile is created by the name of 'KASP-AV' and profile specific parameters are set. In this option we set a specific notification option in the profile. Many other options exists in the profile such as default action in certain conditions (file size, too many compression levels, etc.).

4. Create UTM Policy
In this step a UTM policy is created. Protocol-profiles are specified within the utm policy for the respective module (in this example anti-virus). The screenshot below outlines the commands used to configure a UTM policy for antivirus on all supported protocols.

5. Attach UTM Policy to Security Policy
This step is referencing the UTM policy on the desired security policy. In the example below the UTM policy created in step#3 is configured under the existing security policy 'OUTBOUND-INTERNET-ACCESS'



Verify Full Antivirus Protection (Kaspersky)
1. Browse to AV test site eicar.org
The website www.eicar.org is a well-known antivirus test site. The site itself does not contain any viruses, however it is present in all antivirus databases. The website has a section where files can be downloaded, I downloaded eicar_com.zip file and was promted with the message "VIRUS FOUND!". This was the custom string we configured under the antivirus profile.

2. Show UTM stats via CLI
The command 'show security utm anti-virus status' outlines the antivirus signature version, update interval and when the next update will occur.

The command 'show security utm anti-virus statistics' outlines high level antivirus statistics such as number of screened files, clean files, and threats found.

3. View Antivirus Logs
Antivirus logs can also be written to a syslog file or sent to an external syslog server. Matching on 'AV_' seemed to do the trick however, this might cause some other non-antivirus events to be captured. To be absolutely sure only UTM Antivirus events are captured you could alternatively set the match statement to be 'RT_UTM: AV_'. The screenshot below outlines the commands to create a syslog file and log antivirus events.

The screenshot below is an example of an antivirus event. This event is generated when a virus is detected, this includes the source and destination clients involved, URL, and infected object details.




Conclusion
The configuration of Kaspersky vs. Sophos Protection is very similar, however they are different scan engines and do have different profile related settings. For detailed options please reference the Junos 11.1 documentation. This post concludes the UTM topic.