Part 9 - Application Control, URL Filtering and Content Awareness

[_Val_]

In this lecture, we add Application Control, URL Filtering and Content Awareness functionalities to our Access Control policy. We also touch on the HTTPS Inspection feature.

Application Control & URL Filtering

Application Control and URL Filtering Software Blades enable security policies to identify and control usage of URLs and applications, including Web and social networking. While URL Filtering blade is Web oriented, Application Control works regardless of port and protocols.

Let’s take a look at the categories and applications. Open Object Explorer and chose Application Categories there:

You can look up specific categories and applications by:

If you do not have SmartConsole installed, refer to Check Point AppWiki:

Content Awareness

Content Awareness (CTNT) is a new blade introduced in R80.10 as part of the new Unified Access Control Policy. Using Content Awareness blade as part of the Access Control policy allows the administrator to enforce additional control based on the content of the traffic by identifying files and its content.

CTNT restricts the Data Types that users can upload or download and inspects HTTP, HTTPS, FTP and SMTP protocols.

Content Awareness can be used together with Application Control to enforce more interesting scenarios, for example, identify which files are uploaded to Dropbox.

You can review the supported file types and contents in the Object Explorer:

A full list of supported files and contents can be found in sk114640.

CTNT enforces control over both inbound (Download) and outbound (Upload) traffic. In this lecture, we will be blocking download of executable files.

Building Multi-Layer Access Policy

Let’s start by enabling the required blades on the Security gateway. In SmartConsole, open the gateway object and mark Application Control, URL Filtering, and the Content Awareness Software Blades:

Press OK button to exit.

Now, add an additional Layer to the Access Control policy. Right-click on Access Control > Policy and click Edit:

Add a new Layer:

Name the Layer “Application” and enable Applications & URL Filtering and Content Awareness Blades in General:

Go to Advanced tab and chose Accept option for Implicit Cleanup Action:

Press OK button to finish:

You should now see the new Application Layer in the Access Control Policy, with the default Cleanup Rule – Accept:

This Layer will be now used to control access to Web resources and applications.

Our Access Policy is based on two layers: Network layer and Application Layer. Traffic is filtered through Network Layer first before being matched through Application Layer. This is how it looks:

Refer to this video for more details.

Note: with R80.x product family, Access policy can be layered, as we are doing now, or Unified, where Network filtering, Application Control, URL Filtering and Content Awareness can be used in a single rulebase as a unified layer. You can get more information about the logic and capabilities of Unified policy rulebase on CheckMates, or in the official R80.10 documentation.

HTTPS Inspection Settings

According to different sources, today between 50% and 75% of Internet traffic is HTTPS. That means HTTPS Inspection is essential for effective control over web traffic.

In essence, HTTPS inspection is a man-in-the-middle attack, where the Security Gateway is decrypting and re-encrypting TLS traffic in both client to server and server to client directions. This is how it looks:

Before setting up Security Policy, you need to activate HTTPS Inspection. Double-click the Security Gateway object and choose HTTPS Inspection tab. Here you can either import an existing certificate that is already trusted by your users or to create a new one. Choose the Create option, set up DN (testlab.local in our case) and the key password:

Once the certificate is created, you need to export it, to install onto your end users’ computers. Choose Export and save it:

Finish the changes by marking “Enable HTTPS Inspection” checkbox and press OK.

We have finished the initial configuration of HTTPS Inspection feature.

Inspection Policy

Now we need to create a new Inspection Policy. Go to Application Layer and add a new rule with the following parameters:

• Put LanNetwork as a Source.
• In the Services & Application column add Anonymizer & Social Networking categories, as shown below:

In the Action column, choose Drop > Blocked Message:

Add another rule below and put Executable File into Content:

Right-click on Any Direction and choose Down. Set Action to Drop > Blocked Message:

In the Cleanup rule in this section, set Action to Accept and enable Detailed Log:

Your policy should now look like this:

Choose Install Policy. Now we are ready to test our Inspection Policy.

Installing the Certificate and Tests

Before we can test how effective our Inspection Policy is, we need to install the self-signed Security Gateway certificate on the Lab User PC.

Copy the certificate to that machine and open. Choose Install Certificate:

During the Import Wizard process, choose Local Machine:

Press Yes:

Select Trusted Root Certificate Authorities store to install:

Press Next:

Complete the Installation Wizard:

We are all set to test HTTPS Inspection. Open your browser and go to google.com. Press on the lock icon to see the certificate details:

You can see that the original google.com certificate is changed to one issued by testlab.com. That means HTTPS inspection is working as expected, and our Security is playing the man-in the-middle role, decrypting and re-encrypting HTTPS traffic between the user and a web server.

Important note: If you are using Google Chrome, HTTPS Inspection may not be triggered with the browser default settings. Chrome uses QUIC protocol to access Google resources. QUIC is UDP based and will not be a subject of HTTPS inspection. To force HTTPS communication, you will have to block QUIC in your policy. Alternatively, use browsers other than Chrome.

Now, try accessing facebook.com through your browser. In this case you should see Certificate Error warning and redirection to an IP address of the Security Gateway (192.168.1.254).

That is because you have been redirected to the UserCheck Portal, where we should see the blocking message. Since we did not install UserCheck certificate on the User Lab PC, the browser is trying to warn us about potential security issue. To avoid this in the future tests, you can establish trust to this certificate as well.

Alternatively, you can import a third party trusted certificate as shown below:

If you did not import UserCheck certificate, press Continue to this website. In the browser. You will be shown a Block Message:

Review the certificate and install it:

Try accessing Twitter. You do not have the certificate warning anymore and get the Block Message directly:

Now, check functionality of Content Awareness Software Blade. Try downloading any .exe file, for example, Wireshark:

The download will be blocked:

Go back to Security Policy to review the corresponding access logs:

Next time we will discuss Identity Awareness.

----------------------------

Authors and contributors

Author - Evgeniy Olkov‌, CTO at TS Solution. 
Founded in 2010, the TS Solution is a fast growing Russian company, focused on integrating high-tech networking, security and server virtualization systems and technologies, along with maintenance and professional services.

Translation and editing - Valeri Loukine‌

Review and editing - Dameon Welch-Abernathy