Working with UserCheck Interaction Objects

• UserCheck client adds the option to send notifications for applications that are not in a web browser, such as Skype, iTunes, or browser add-ons (such as radio toolbars). The UserCheck client can also work together with the UserCheck portal to show notifications on the computer itself when:
• The notification cannot be displayed in a browser, or
• The UserCheck engine determines that the notification will not be shown correctly in the browser.

For more about configuring UserCheck on the gateway and the UserCheck client, see Configuring UserCheck.

Creating UserCheck Interaction Objects

Create a UserCheck Interaction object from the Access Tools > UserCheck page of the Access Control tab.

To create a UserCheck object that includes a message:

1. In the Security Policies view of R80 SmartConsole, go to the Access Control Policy.
2. Click Access Tools > UserCheck.
3. Click New, and select one of these interaction modes:
   • Ask UserCheck- Show a message to users that asks them if they want to continue with the request or not.
   • Block UserCheck- Show a message to users and block the application request.
   • Inform UserCheck - Show an informative message to users. Users can continue to the application or cancel the request.

   The UserCheck Interaction window opens on the Message page.

4. Enter a name for the UserCheck object and, optionally, a comment.
5. Select a language (English is the default) from the Languages tabs.
6. Enter the message content. You can:
   • Use the formatting toolbar to change text color, alignment, add or remove bullets.
   • Use the Insert field variables.
7. In the Settings tab, configure optional settings:
   • Fallback Action - When UserCheck notification cannot be displayed, this action is taken
   • External Port - When selected, redirects the user to the specified External Port (enter the URL), and the UserCheck message is not shown to the end-user
     Select Add UserCheck Incident ID to the URL query, to log the incident
8. Click OK.

   This creates the UserCheck object and web page notification for the portal.

Localizing and Customizing the UserCheck Portal

After you set the UserCheck interaction object language, you can translate the Portal OK and Cancel buttons to the applicable language. For more information, see: sk83700.

The UserCheck predefined notifications are translated to English, French, Spanish, and Japanese.

To support more languages:

1. In UserCheck Interaction > Message, click Languages.
2. In the list, select the languages.

UserCheck Frequency and Scope

You can set the number of times that users get UserCheck messages for accessing applications that are not permitted by the policy. You can also set if the notifications are based on accessing the rule, application category, or application itself.

To set how often UserCheck notifications show:

1. Select the Action cell of a rule in the Access Control Policy, and click More.
2. In the Action Settings window, select the UserCheck Frequency.

   The options are:

   • Once a day
   • Once a week
   • Once a month
   • Custom frequency
3. Select Confirm UserCheck. This sets if the notifications are:
   • Per rule
   • Per category
   • Per application
   • Per data type

Example:

In a rule that contains:

Services & Applications	Action
Social Networking category	Inform

If you select a UserCheck Frequency of Once a day, and Confirm UserCheck of Per rule:

A user who accesses Facebook and then LinkedIn on the same day gets one Inform message.

If you select a UserCheck Frequency of Once a day, and Confirm UserCheck of Per application:

A user who accesses Facebook and then LinkedIn on the same day gets one Inform message for Facebook and one for LinkedIn.

In new installations, the Confirm UserCheck Scope default is Per category.

In upgrades from a version before R75.40, the Confirm UserCheck default is Per Rule.

The Application and URL Filtering Database

The Check Point Application and URL Filtering Database contains thousands of known applications, social media widgets, and more than 150 million categorized URLs. Check Point continuously updates this database with new and changed applications and URLs. Each database record contains a description, one or more categories, and a risk level.

Security Gateways keep these resources on its local disk to improve inspection performance:

• A database with the most commonly used URLs and their related categories.
• A local cache that can return results for up to 99% of URL categorization requests.

If the cache does not contain the category information for a URL, Application and URL Filtering looks in the local database and then goes to the Check Point Online Web Service. If a URL is likely to be a widget, Application and URL Filtering goes directly to the Check Point Online Web Service.

Working with the Application and URL Filtering Database

You can work with the Application and URL Filtering Database from:

• R80 SmartConsole - From the Application Control Rule Base in R80 SmartConsole, click the plus sign in the Services & Application column. You can select and add applications and categories directly into a Rule Base.
• AppWiki - Click Access Tools > AppWiki on the lower, left side of the Access Control page, or go to the Check Point AppWiki website.

Security Category Updates

The local cache on each Security Gateway keeps URL categorization data up to 24 hours. The frequency of local cache updates are based on the security category.

It is possible that the category assigned to a site or application changes on the Check Point Online Web Service while it is still in the local cache. For example, a URL that was categorized as Search Engines / Portals, changed to phishing. The Online Web Service updates the local cache for URLs with critical security categories (such as phishing, malware, botnet, and spam) more frequently.

Application Categories

In the Application Database, each application has one primary category based on its most defining aspect. You can see the category in the description of each application and in the logs.

Each application can also have additional categories, called Tags, which are secondary application characteristics. For example, the primary category for Gmail is 'Email'. Gmail also has these additional Tags:

• 'Sends mail'
• 'Encrypts communications'

When you use the AppWiki or add applications to a Rule Base, you can filter by Tags and risk level to see all applications with that characteristic. This is a good way to see which types of applications you can block or allow.

Access Control Rules match an application's primary category and its Tags. If the primary category changes, or if Tags are added or deleted, the rule matching behavior changes automatically when the Application and URL Filtering Database is updated. For example, if you have a rule that:

• Blocks all applications with the 'High Bandwidth' Tag

  and

• And the 'High Bandwidth' tag is added to some applications in the Application and URL Filtering Database

Rules that once allowed these applications now block them. If an allowed application is suddenly blocked, use the AppWiki to see if a Tag or the primary category changed.

Application Risk Levels

The Application and URL Filtering Database and AppWiki show a Risk Level for each application.

This table explains what each risk level means and gives examples of applications or types of applications with that level.

Risk Level	Definition	Examples
5 - Critical	Can bypass security or hide identities	Web Anonymizers, VPN4ALL, VTunnel, Kazaa
4 - High	Can cause data leakage or malware infection without user knowledge	Remote Desktop, File sharing, P2P sharing (uTorrent), Instant Messaging
3 - Medium	Can cause data leakage or malware infection	Instant messaging, File storage (Dropbox, OneDrive, iDisk, SharePoint-Online), WebEx, Gmail, Instant messaging
2- Low	Potentially not business related, but low risk	Gaming, Facebook, YouTube, Media
1- Very Low	Usually business related with no or very low risk	SalesForce, Google Finance

You can filter an AppWiki or Application and URL Filtering Database search based on the risk level. For example, select risk level 5 to see all applications with a critical risk level. The risk level is also a Tag that shows in the details of each application.

Updating the Application and URL Filtering Database

The Application and URL Filtering Database on the Security Gateway gets regular, automatic updates that make sure that you have the most current data and newly added applications and websites in the Application and URL Filtering Layer of the Access Control Policy.

By default, updates run on the Security Management Server and Security Gateways once a day. You can change the update schedule or choose to manually update the management server. The updates are stored in a few files on each Security Gateway.

To manually update the Application and URL Filtering Database on the management server:

1. In R80 SmartConsole, click Security Policies > Access Tools > Updates.
2. In the Application and URL Filtering section, click Update Now.

To change the schedule for Application and URL Filtering Database updates on the management server:

1. In R80 SmartConsole, click Security Policies > Access Tools > Updates.
2. Click Schedule Update.
3. Select Enable Application Control & URL Filtering Scheduled Update.
4. Click Configure to schedule when the updates will run. By default, a scheduled update runs once a day.

In Multi-Domain Security Management, update the database for all Domain Management Servers in the Global R80 SmartConsole and not from Domain Management Servers.

Connecting to the Internet for Updates

The gateway or Security Management Server connects to the Internet to get the Application and URL Filtering Database updates. To make sure that it can get the updates successfully:

• Make sure that there is a DNS server configured.
• Make sure a proxy is configured for each gateway and the Security Management Server, if necessary.

Security Policies > Access Tools > Updates shows if the Security Management Server uses a proxy to connect to the Internet.

To configure a proxy for the Security Management Server:

1. Select Security Policies > Access Tools > Updates.
2. Click Configure Proxy.
3. In the Proxy Configuration window, in the Use proxy field, enter the domain name or IP address of the proxy, and the Port number.

To Configure IPv6 proxy support:

If the proxy uses an IPv6 address:

1. On the Windows computer, running R80 SmartConsole client, go to Start menu and open Control Panel > System and Security > System > Advanced System Settings.
2. Open the Advanced tab > Environment variables.
3. Create a new User Variable.
4. Set the value to: updates_over_IPv6=1

Scheduling Updates

To change the update schedule from the default scheduled Application and URL Filtering Database updates:

1. Select Security Policies > Access Control > Access Tools > Updates.
2. Click Schedule Update.
3. Select the target for updates:
   • Security Management Server
   • Security Gateway
4. Click Configure.

   Configure the Security Management Server updates and the Security Gateway updates separately.

5. Set the Time of Event. Set the update interval, and a time of day for updates to occur.
6. Click OK.

If you have Security Gateways or Security Management Servers in different time zones, they will not be synchronized until all of them are updated.

Application and URL Filtering Advanced Settings

You can configure advanced Application and URL Filtering settings. These are global settings that apply to all Security Gateways that have Application and URL Filtering enabled.

To work with advanced settings:

1. On the Main Navigation bar, click Manage & Settings.
2. Select Blades > Application and URL Filtering > Advanced Settings.

   The Application Settings window opens.

3. Configure settings in the General tab view:
   • Fail mode - Select to Allow all requests or to Block all requests when an internal error happens
   • URL Filtering - Select one or more of these - Categorize HTTPS websites, Enforce safe search on search engines, Categorize cached pages and translated pages in search engines
   • Connection unification - Set Session unification timeout (the default is 180 minutes)
   • Application Control Web Browsing Services - Modify service match criteria for web applications

     Select Match web application on 'Any' port when used in 'Block' rule, to optimize resources for processing blocked traffic

   • Web browsing - Select Enable web browsing logging and policy enforcement
   • HTTP Inspection - Select Enable HTTP Inspection on non-standard ports for Application and URL Filtering
   • Compatibility with R75 and R75.10 gateways settings - Select Unify connections from the same User/IP to a specific application into a single session/log and Issue a separate log per each domain accessed, if needed
4. Configure settings in the Check Point online web service tab view:
   • Block requests when web service is unavailable - Select to minimize unnecessary traffic processing
   • Website categorization mode: Hold - Select Hold to block requests until categorization is complete, Background - to allow requests until categorization is complete, or Custom - to configure different settings for different services
   • Categorize social networking widgets - Select to ensure user privacy
5. Click OK.
6. Publish the session and install the policy.

Application Control Web Browsing Services

Application Control Web browsing services are the services that match a Web-based custom Application/Site.

These are the default Application Control Web browsing services:

• http on port 80
• https on port 443
• HTTPS_proxy on port 8080
• HTTP_proxy on port 8080

Other services, such as SSH are not matched.

To add to the list of services that match Web applications:

1. Go to Manage & Settings > blades > Application and URL Filtering > Advanced Settings.
2. In the Application and URL Filtering Settings window:
   1. Click the add icon to open the list of services.
   2. Select a service.

Match Web application on ‘Any’ port when used in Block rule - By default, this is selected, and applications are matched on all services when used in a Block rule.

HTTPS Inspection

You can enable HTTPS traffic inspection on Security Gateways to inspect traffic that is encrypted by the Secure Sockets Layer (SSL) protocol. SSL secures communication between internet browser clients and web servers. It supplies data privacy and integrity by encrypting the traffic, based on standard encryption ciphers.

However, SSL has a potential security gap. It can hide illegal user activity and malicious traffic from the content inspection of Security Gateways. One example of a threat is when an employee uses HTTPS (SSL based) to connect from the corporate network to internet web servers. Security Gateways without HTTPS Inspection are unaware of the content passed through the SSL encrypted tunnel. This makes the company vulnerable to security attacks and sensitive data leakage.

The SSL protocol is widely implemented in public resources that include: banking, web mail, user forums, and corporate web resources.

There are two types of HTTPS inspection:

• Inbound HTTPS inspection - To protect internal servers from malicious requests originating from the internet or an external network.
• Outbound HTTPS inspection - To protect an organization from malicious traffic being sent by an internal client to a destination outside of the organization.

The Security Gateway acts as an intermediary between the client computer and the secure web site. The Security Gateway behaves as the client with the server and as the server with the client using certificates.

To optimize performance, inbound HTTPS traffic is inspected only if the policy has rules for HTTPS. For example, if the IPS profile does not have HTTP/HTTPS-related protections activated, HTTPS Inspection is not started.

All data is kept private in HTTPS Inspection logs. This is controlled by administrator permissions. Only administrators with HTTPS Inspection permissions can see all the fields in a log. Without these permissions, some data is hidden.

Configuring Outbound HTTPS Inspection

To enable outbound HTTPS traffic inspection, you must do these steps:

• Set the Security Gateway for HTTPS Inspection.
• Generate a CA certificate on the Security Management Server or import a CA certificate already deployed in your organization.
  • If you created a CA certificate, you must deploy it in the Trusted Root Certification Authorities Certificate Store on the client computers. This lets the client computers trust all certificates signed by this certificate.
• Generate an HTTPS inspection policy by defining relevant rules in the HTTPS inspection Rule Base.
• Configure the conditions for dropping traffic from a web site server.

  When required, you can update the trusted CA list in the Security Gateway.

Creating an Outbound CA Certificate

The outbound CA certificate is saved with a P12 file extension and uses a password to encrypt the private key of the file. The Security Gateways use this password to sign certificates for the sites accessed. You must keep the password as it also used by other Security Management Servers that import the CA certificate to decrypt the file.

After you create an outbound CA certificate, you must export it so it can be distributed to clients. If you do not deploy the generated outbound CA certificate on clients, users will receive SSL error messages in their browsers when connecting to HTTPS sites. You can configure a troubleshooting option that logs such connections.

After you create the outbound CA certificate, a certificate object named Outbound Certificate is created. Use this object in rules that inspect outbound HTTPS traffic in the HTTPS inspection Rule Base.

To create an outbound CA certificate:

1. In R80 SmartConsole, go Manage & Settings > Blades > HTTPS Inspection > Configure In SmartDashboard.
2. In SmartDashboard, right-click the Security Gateway object and select Edit.

   The Gateway Properties window opens.

3. In the navigation tree, select HTTPS Inspection.
4. In the HTTPS Inspection page, click Create.
5. Enter the necessary information:
   • Issued by (DN) - Enter the domain name of your organization.
   • Private key password - Enter the password that is used to encrypt the private key of the CA certificate.
   • Retype private key password - Retype the password.
   • Valid from - Select the date range for which the CA certificate is valid.
6. Click OK.
7. Export and deploy the CA certificate.

Exporting and Deploying the Generated CA

To prevent users from getting warnings about the generated CA certificates that HTTPS inspection uses, install the generated CA certificate used by HTTPS inspection as a trusted CA. You can distribute the CA with different distribution mechanisms such as Windows GPO. This adds the generated CA to the trusted root certificates repository on client computers.

When users run standard updates, the generated CA will be in the CA list and they will not receive browser certificate warnings.

To distribute a certificate with a GPO:

1. From the HTTPS Inspection window of the Security Gateway, click Export certificate.
2. Save the CA certificate file.
3. Use the Group Policy Management Console to add the certificate to the Trusted Root Certification Authorities certificate store.
4. Push the Policy to the client computers in the organization.

   Note - Make sure that the CA certificate is pushed to the client computer organizational unit.

5. Test the distribution by browsing to an HTTPS site from one of the clients and verifying that the CA certificate shows the name you entered for the CA certificate that you created in the Issued by field.

The HTTPS Inspection Policy

The HTTPS inspection policy determines which traffic is inspected. The primary component of the policy is the Rule Base. The rules use the categories defined in the Application and URL Filtering Database, network objects and custom objects (if defined).

The HTTPS inspection Rule Base lets you inspect the traffic on other network blades. The blades that HTTPS inspection can operate on are based on the blade contracts and licenses in your organization and can include:

• Application Control
• URL Filtering
• IPS
• DLP
• Threat Prevention

If you enable Identity Awareness on your Security Gateways, you can also use Access Role objects as the source in a rule. This lets you easily make rules for individuals or different groups of users.

To access the HTTPS Inspection Rule Base:

1. In R80 SmartConsole, click Manage & Settings > Blades > HTTP Inspection > Configure in SmartDashboard.
2. In SmartDashboard, click Policy.

Bypassing HTTPS Inspection for Software Update Services

Check Point dynamically updates a list of approved domain names of services from which content is always allowed. This option makes sure that Check Point updates or other 3rd party software updates are not blocked. For example, updates from Microsoft, Java, and Adobe.

To bypass HTTPS inspection for software updates:

1. In R80 SmartConsole, go Manage & Settings > Blades > HTTPS Inspection > Configure In SmartDashboard.
2. In SmartDashboard, click the HTTPS Inspection tab.
3. Click Policy.
4. In the Policy pane, select Bypass HTTPS Inspection of traffic to well known software update services (list is dynamically updated). This option is selected by default.
5. Click list to see the list of approved domain names.

HTTPS Validation

Server Validation

When a Security Gateway receives an untrusted certificate from a web site server, the settings in this section define when to drop the connection.

Untrusted server certificate

When selected, traffic from a site with an untrusted server certificate is immediately dropped. The user gets an error page that states that the browser cannot display the webpage.

When cleared, a self-signed certificate shows on the client machine when there is traffic from an untrusted server. The user is notified that there is a problem with the website's security certificate, but lets the user continue to the website (default).

Revoked server certificate (validate CRL)

When selected, the Security Gateway validates that each server site certificate is not in the Certificate Revocation List (CRL) (default).

If the CRL cannot be reached, the certificate is considered trusted (this is the default configuration). An HTTPS Inspection log is issued that indicates that the CRL could not be reached. This setting can be changed with GuiDBedit. Select Other > SSL Inspection > general_confs_obj and change the attribute drop_if_crl_cannot_be_reached from false to true.

To validate the CRL, the Security Gateway must have access to the internet. For example, if a proxy server is used in the organizational environment, you must configure the proxy for the Security Gateway.

To configure the proxy:

1. In R80 SmartConsole, from the Gateways & Servers view, double-click the Security Gateway that requires proxy configuration.
2. Select Network Management > Proxy.
3. Select Use custom proxy settings for this network object and Use proxy server and enter the proxy IP address.
4. Optionally, you can use the default proxy settings.
5. Click OK.

When cleared, the Security Gateway does not check for revocations of server site certificates.

Important - Make sure that there is a rule in the Rule Base that allows outgoing HTTP from the Security Gateway.

Expired server certificate

• When selected, the Security Gateway drops the connection if the server certificate has expired.
• When cleared, the Security Gateway creates a certificate with the expired date. The user can continue to the website (default).

Track validation errors

Choose if the server validation traffic is logged in in the Logs tab of the R80 SmartConsole Logs & Monitor view or if it triggers other notifications. For the options, see Track.

Automatically retrieve intermediate CA certificates

• When selected, intermediate CA certificates issued by trusted root CA certificates that are not part of the certificate chain are automatically retrieved using the information on the certificate (default).
• When cleared, a web server certificate signed by an intermediate CA and not sent as part of the certificate chain, is considered untrusted.

HTTP/HTTPS Proxy

In R80 SmartConsole, in the Gateways & Servers view, or in SmartDashboard, in the HTTPS Inspection tab > Gateways pane, you can edit a Gateway object. In the HTTP/HTTPS Proxy page, you can configure a gateway to be an HTTP/HTTPS proxy. When it is a proxy, the gateway becomes an intermediary between two hosts that communicate with each other. It does not allow a direct connection between the two hosts.

Each successful connection creates two different connections:

• One connection between the client in the organization and the proxy.
• One connection between the proxy and the actual destination.

Proxy Modes

Two proxy modes are supported:

• Transparent - All HTTP traffic on specified ports and interfaces is intercepted and sent to a proxy. No configuration is required on the clients.
• Non Transparent - All HTTP/HTTPS traffic on specified ports and interfaces directed to the gateway is sent to a proxy. Configuration of the proxy address and port is required on client machines.

Access Control

You can configure one of these options for forwarding HTTP requests:

• All Internal Interfaces - HTTP/HTTPS traffic from all internal interfaces is forwarded by proxy.
• Specific Interfaces - HTTP/HTTPS traffic from interfaces specified in the list is forwarded by proxy.

Ports

By default, traffic is forwarded only on port 8080. You can add or edit ports as required.

Advanced

By default, the HTTP header contains the Via proxy related header. You can remove this header with the Advanced option.

You can also use the Advanced option to configure the X-Forward-For header that contains the IP address of the client machine. It is not added by default because it reveals the internal client IP.

Logging

The Security Gateway opens two connections, but only the Firewall blade can log both connections. Other blades show only the connection between the client and the gateway. The Destination field of the log only shows the gateway and not the actual destination server. The Resource field shows the actual destination.

To configure a Security Gateway to be an HTTP/HTTPS proxy:

1. From the General Properties window of a Security Gateway object, select HTTP/HTTPS Proxy from the tree.
2. Select Use this gateway as a HTTP/HTTPS Proxy.
3. Select the Transparent or Non Transparent proxy mode.

   Note - If you select Non Transparent mode, make sure to configure the clients to work with the proxy.

4. Select to forward HTTP requests from one of these options:
   • All Internal Interfaces
   • Specific Interfaces - Click the plus sign to add specified interfaces or the minus sign to remove an interface.
5. To enter more ports on which to forward traffic, select Add.
6. To include the actual source IP address in the HTTP header, select Advanced > X-Forward-For header (original client source IP address).

   The X-Forward-For header must be configured if traffic will be forwarded to Identity Awareness Security Gateways that require this information for user identification.

7. Click OK.

HTTPS Inspection Logs

Logs from HTTPS Inspection are shown in the Logs & Monitor > Logs tab. Under Favorites, there is a predefined query for HTTPS Inspection logs. It shows all HTTPS traffic that matched the HTTPS Inspection policy and was configured to be logged.

The log includes an HTTP Inspection Action field. The field value can be inspect or bypass. If the traffic did not go through HTTPS inspection, the field does not show in the log.

Permissions for HTTPS Logs

An administrator must have HTTPS inspection permissions to see classified data in HTTPS inspected traffic.

To set permissions for an administrator in a new profile:

1. In R80 SmartConsole, select Manage & Settings > Permissions and Administrators > Administrator.
2. Double-click an administrator to edit it.
3. In the General page in the Permissions Profile field, select the permission profile and click New.
4. In the New Profile window:
   • Enter a Name for the profile.
   • Select Customized.
5. In the Monitoring and Logging page, select HTTPS Inspection logs for permission to see the classified information in the HTTPS Inspection logs.
6. Click OK on all of the open windows.

To edit an existing permissions profile:

1. In R80 SmartConsole, select Manage & Settings > Permissions and Administrators > Permission Profiles.
2. Double-click a profile to edit it.
3. In the Monitoring and Logging page, select HTTPS Inspection logs for permission to see the classified information in the HTTPS Inspection logs.
4. Click OK on all of the open windows.

Using Identity Awareness in the Rule Base

The Security Gateway examines packets and applies rules in a sequential manner. When a Security Gateway receives a packet from a connection, it examines the packet against the first rule in the Rule Base. If there is no match, it then goes on to the second rule and continues until it matches a rule.

In rules with access roles, you can add a property in the Action field to enable the Captive Portal. If this property is added, when the source identity is unknown and traffic is HTTP, the user is redirected to the Captive Portal. The packet is matched according to the other fields in the rule. After the system gets the credentials from the Captive Portal, it can examine the rule for the next connection.

In rules with access role objects, criteria matching works like this:

• When identity data for an IP is known:
  • If it matches an access role, the rule is enforced and traffic is allowed or blocked based on the action.
  • If it does not match an access role, the next rule is examined.
• When identity data for an IP is unknown and:
  • All rule fields match, other than the source field with an access role.
  • The connection is http.
  • The action is set to redirect to the Captive Portal.

    If all the conditions apply, the traffic is redirected to the Captive Portal to get credentials and see if there is a match.

    If not all conditions apply, there is no match and the next rule is examined.

    Note - When you set the option to redirect http traffic from unidentified IP addresses to the Captive Portal, make sure to place the rule in the correct position in the Rule Base to avoid unwanted behavior.

To redirect http traffic to the Captive Portal:

1. In a policy rule that uses an access role in the Source column, right-click the Action column and select More.

   The Action Settings window opens.

2. Select the Enable Identity Captive Portal.
3. Click OK.

   The Action column shows that a redirect to the Captive Portal occurs.

This is an example of a Rule Base that describes how matching operates:

No.	Source	Destination	Services & Applications	Action
1	Finance_Dept (Access Role)	Finance_Web_ Server	Any	Accept (display Captive Portal)
2	Admin_IP	Any	Any	Accept
3	Any	Any	Any	Drop

Example 1 - If an unidentified Finance user tries to access the Finance Web Server with http, a redirect to the Captive Portal occurs. After the user enters credentials, the Security Gateway allows access to the Finance Web Server. Access is allowed based on rule number 1, which identifies the user through the Captive Portal as belonging to the Finance access role.

Example 2 - If an unidentified administrator tries to access the Finance Web Server with http, a redirect to the Captive Portal occurs despite rule number 2. After the administrator is identified, rule number 2 matches. To let the administrator access the Finance Web Server without redirection to the Captive Portal, switch the order of rules 1 and 2 or add a network restriction to the access role.

Using Application and URL Filtering with VSX

When you configure Virtual Systems to use the Application Control and URL Filtering, make sure that the VSX Gateway (VS0) can connect to the Internet. Updates are done only through this Virtual System.

To enable Application and URL Filtering Categories on Virtual Systems:

1. If applicable, configure proxy settings for the VSX Gateway (VS0):
   1. In R80 SmartConsole, from the Gateways & Servers view, double-click the VSX Gateway (VS0).
   2. From the navigation tree, select Network Management > Proxy.
   3. Configure the proxy settings, and click OK.
2. Enable Application Control and URL Filtering on the required Virtual Systems.

   Note - You do not have to enable them on the VSX Gateway (VS0).

3. Install policies on the relevant Virtual Systems.