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.


Friday, 23 November 2012

SRX UTM - Antispam

The antispam module can block email messages using third party server block lists (SBL) and/or user configured blacklists and whitelists. The goal of the antispam module is to block and filter spam email messages. This module only supports the SMTP application. 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 Antispam
1. Confirm Licensing
The antispam UTM module does require a license. The command 'show system license' can be used to display the installed licenses. The license 'anti_spam_key_slb' is needed for this exercise.

2. Create Custom Objects
The custom objects 'url-pattern' can be used to identify SMTP servers by dns name or IP address. In this exercise I will test antispam using a laptop with an IP address of 192.168.1.102. I have used this IP address in the blacklist. The whitelist has an example of a dns name. Shaw is my internet provider so I have added them to the whitelist. The screenshot below outlines these commands.

3. Configure Feature Profile
In this step a feature profile is created. Back and whitelists are defined by referencing the url-pattern lists created in step#1. The action of tagging the message is also defined. The screenshot below outlines these commands.

4. Configure UTM Policy
In this step a UTM policy is created. The smtp-profile we created in the previous step is referenced for the antispam module. The screenshot outlines this command.

5. Attach UTM Policy to Security
In this step the UTM policy is configured under the desired security policy. In this example we are using a preconfigured security policy that is used for general outbound internet access. The screenshot below outlines the command.




Verify Antispam
1. Verify antispam status.
The command 'show security utm anti-spam status' outlines the SLB server used.

2. Verify block from domain or user on blacklist
To test the antispam module I connected to an SMTP server from the laptop of 192.168.1.102. This laptop IP was placed in the blacklist.

The command 'show security utm anti-spam' can be used to see detailed statistics. In the screenshot output below you can see that the blacklist count is 1.


3. View Antispam Logs from CLI
First a syslog file has to be created with a match statement. The match statement to use for antispam is ANTISPAM_'. The screenshot below outlines the commands to create this log file

The command 'show log {log-file name}' can be used to view the log file. The events give the source IP (sender), the source email address and the reason the message was blocked. The screenshot below displays an example of the antispam log event.



3. Verify if an IP address is on the SLB Block list
The SLB service is provided by Sophos. They have a handy web page (http://www.sophos.com/en-us/threat-center/ip-lookup.aspx) where you can test names and IP addresses to see how they are classified by the SBL server.

4. Test IP address against an Antispam Profile
The command 'test security utm anti-spam' is also very handy. This command will test an IP address or name against a configured antispam policy. The screenshot below highlights some examples of this command.  Notice that the laptop IP address I configured in the blacklist is correctly identified in the first example.



Conclusion
The next post will focus on the UTM Antivirus module.


Thursday, 22 November 2012

SRX UTM - Content Filtering

The content filtering UTM module can block specific content on SMTP, POP3, IMAP, HTTP and FTP protocols based on MIME type, file extension or protocol commands. In this post content filtering will be configured. 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 Content Filtering
1. Create Custom Objects
Content filtering supports three custom object types protocol-command, filename-extension and mime-pattern. For protocol-commands the FTP command of 'user' was configured under the protocol-command list of 'PROTO-BLOCK'. For filename-extensions the extension of '.exe' was configured under the filename-extension list of 'EXTENSION-BLOCK'. For mime-patterns the pattern of 'video/quicktime' was configured under the mime-pattern list of 'MIME-BLOCK'. The screenshot below outlines these commands.

2. Configure Feature Profile
The previously created custom object lists can be specified in feature profile for content filtering. Some objects can be configured to be blocked directly in the feature profile without referencing a custom object list (active x, exe, http cookies, java-applets and zip). This example did not use any of these options, we simply referenced the custom object lists created in step#1. Also a custom-message was defined to prompt users that the content was blocked. The screenshot below outlines the commands.

3. Configure UTM Policy
This step is slightly more involved than in the post on web filtering. You will notice that profiles are specified for all UTM protocols. This is because the content filtering module supports all UTM protocols, where as the web filtering only supports HTTP. If content filtering was only needed for certain protocols only the needed profiles would be specified here. If no profile is specified for a protocol under the UTM module, that protocol will not be inspected and will be permitted. The screenshot below outlines the commands used to configure a UTM policy for content filtering on all supported protocols.

4. Attach UTM Policy to Security Policy
This step is simply 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 Content Filtering
1. Verify blocking of Protocol Command
To verify blocking of protocol commands I opened an FTP session to ftp.mozilla.net and attempted to issues to command 'user' by entering a username of anonymous. If you recall the custom object for protocol commands had the command 'user' listed and was referenced under the 'block-command' configuration statement on the content filtering feature profile. The result can be seen in the screenshot below, as expected the FTP command 'user' is blocked by the content filter.

2. Verify blocking of File Extension
To verify blocking of file extension I browsed to the wireshark.com downloads page and attempted to download the most current release of wireshark (which is an .exe file). If you recall the custom object for file extension had 'exe' listed and was referenced under the 'block-extension' configuration statement on the content filtering feature profile. The result can be seen in the screenshot below, as expected the .exe file download is blocked by the content filter.
(keep in mind this same example could have been done a different way by specifying 'block-content-type exe' under the feature profile)


3. Verify blocking of MIME Pattern
To verify blocking of MIME pattern I browsed to the trailer.apple.com site and attempted to watch a preview of a movie (which is in quicktime format). If you recall the custom object for mime-pattern had 'video/quicktime' listed and was referenced under the 'block-mime list' configuration statement on the content filtering feature profile. The result is not as clear in the screenshot below, but the video did not load.

4. Verify Content Filtering Statistics from CLI
The command 'show security utm content-filtering statistics' can be used to see counts on content filtering block types.

5. View Content Filtering Logs from CLI
First a syslog file has to be created with a match statement. The match statement to use for content filtering is 'CONTENT_FILTERING'. The screenshot below outlines the commands to create this log file.

The command 'show log {log-file name}' can be used to view the log file. The screenshot below demonstrates this. Log events for the three tests performed above are in the log file. The events give the source IP, the protocol and the reason the content was blocked.



Conclusion
The next post will focus on UTM Anti-spam Module.


Wednesday, 21 November 2012

SRX UTM - Web Filtering

The Web filtering UTM module can block access to (HTTP) websites based on IP address or URL. Local and integrated web filtering will be configured. 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 Local Web Filtering
1. Create Custom Objects for Black/Whitelists
To create a white or black list a url-pattern list must be created containing URLs. These url-pattern lists must be added to a 'custom-url-category'. The screenshot below outlines the commands.

2. Create Feature Profile
In this step a feature profile is created. Black and white lists are defined using the custom-url-categories created in the previous step. The default action is also set (the default action is used if a URL doesn't match the black or white list). The screenshot below outlines the commands.

3. Create UTM Policy
In this step a UTM policy is created. An http-profile is set for the web filtering UTM module, in this case it is the feature profile we created in the previous step. The screenshot below outlines the commands.

4. Attach UTM Policy to Security Policy
In this step the UTM policy is configured under the desired security policy. In this example we are using a preconfigured security policy that is used for general outbound internet access. The screenshot below outlines the commands.



Verify Local Web Filtering
1. Browse to www.cnn.com
The output below confirms that we cannot browse to www.cnn.com as this URL is on the blacklist.

2. Configure a Syslog File & View Web Filtering Logs
The screenshot below outlines the creation of a syslog file to capture web filtering logs. The match statement of "WEBFILTER_" is used to capture all web filtering logs.

The output below displays the log file. The default action was set to 'permit-and-log' this is why permitted URLs are shown in the log file.

To only view the blocked urls we can run the same command but match on URL_BLOCKED. This displays only the web filtering url blocked log events. The log file configuration could also be modified to match 'WEBFILTER_URL_BLOCKED' this would only write these types of events to the log file.



Configure Integrated Web Filtering (Surf Control)
1. Confirm Licensing
The integrated web filtering (SurfControl) does require a license. The command 'show system license' can be used to display the installed licenses. The license 'wf_key_surfcontrol_cpa' is needed for this exercise.

2. Create Custom Objects for Black/Whitelists
Whitelists and blacklists are used in conjunction with integrated web filtering. We will use the existing whitelist / blacklist that were configured in Step#1 on the previous exercise.

3. Create Feature Profile
In this step surf-control-integrated needs to be set as the type of filtering. Also a feature profile needs to be created. This profile will contain block or permit statements against surf control predefined categories along with default action and block message. The screenshot below outlines the commands  In this policy I set the category of 'Sports' to an action of block.

4. Create UTM Policy
A UTM policy is created and an http-profile is assigned to the web filtering module. Other than the feature profile name being different this step is the same as the previous exercise.

5. Attach UTM Policy to Security Policy
We intentionally used the same UTM policy as the previous example. This policy is already attached to our outbound internet security policy. Please see step #4 in the previous exercise for details.



Verify Integrated Web Filtering
1. Browse to a sports related website.
In the screenshot below I attempt to browse to www.mysportsite.com. I am not permitted to browse to this site as it is classified in the category of 'sports' and the action for this category is deny.

2. View Logs
Again, when the web filter logs are reviewed we can see the site was blocked and the reason was 'by predefined category'.

3. Confirm Surf Control Server is Operational
The command 'show security utm web-filtering status' can be used to verify that the surf control server is available.

4. Show Web Filter Statistics
The command 'show security utm web-filtering statistics' can be used to view overall statistics such as queries to servers and counters for categories and lists.

5. Test URL against Web Filtering Profile
The command 'test security utm web filtering' is a nice way to quickly verify a URL against a web filter policy. The screenshot below tests the URL www.cnn.com against the policy WEBFILT-SURF.



Update Surf Control Cache Size and use Default SurfControl profile
1. Adjust Surf Control Cache
As mentioned in the UTM summary post, the SRX will maintain a cache of URL/Category mappings. This reduced the amount of requests that are sent to the Surf Control service as common used web sites categorization will reside in cache. This cache size is 500kB by default, the screenshot below outlines the command to change the cache size.

2. Update UTM Policy to use Predefined Feature Profile.
It can take quite a long time to create a feature-profile and specify actions for all categories. For people who want a quicker approach default feature profiles can be used. The screenshot below outlines the configuration of a default feature profile against our already configure UTM policy.


Test Predefined Feature Profile
1. Confirm the settings in predefined feature profile
The command 'show configuration groups junos-defaults security utm feature-profile web-filtering' can be used to view the predefined feature profiles for web filtering.





























2. Browse to site in a blocked category. 
From looking at the default feature-profile in the previous step we can see that the gambling category is blocked. The screenshot below tests the policy by browsing to a gambling site, as expected access to the site is denied.

3. View Logs
The log files also confirm that the website was blocked. The log messages also list the profile used, we can confirm that the default feature profile (junos-wf-cpa-default) is being used in this example.


Conclusion
The Websense-redirect method requires a server to redirect URLs to. For this reason I did not test this option. I would be curious to know if Websense offers this as a service so that customers don't need to have a physical server on premise.

The juniper-local filtering is a nice (license free) way of creating and managing a small number of sites on black and white lists. This option would not be feasible for full detailed URL filtering needs as it would become unmanageable very quickly.

The integrated web filtering provided by Surf Control is a good way to reduce the complexity by only managing categories. Configuration complexity can further be reduced by used a predefined feature profile.

In the next post I will review the UTM Content Filtering module.