Continent 4 Getting Started 2.0. Web filtering

We welcome all readers to the fifth article in the series “Continent 4 NGFW Getting Started 2.0”.

In the previous article, we looked at setting up an authentication portal, creating a local user and adding a domain group. We also created a rule that works only with authorized users.

In this material we will get acquainted with:

1. Filtering by SNI

2. SSL/TLS inspection

3. Web/FTP filtering

4. ECAP services

5. ICAP servers

You can see all the virtual machines used in this article in the block diagram below:

FILTERING BY SNI

Server Name Indication (SNI) is an extension of the TLS protocol that sends the domain name with which a network connection needs to be established. Most regular browsers transmit the hostname to which the encrypted HTTPS connection is made in clear text. This allows you to filter resources without opening the SSL/TLS session.

This is the only web filtering method that, at the time of writing, does not require SSL/TLS inspection in Continent 4 NGFW.

There is a limitation: only preset lists from SkyDNS can be filtered by SNI. Support for custom lists is announced in the following version: 4.1.9.

This type of filtering is configured in the “Access Control – Firewall” section in the “Protocol/Application” rule parameter.

Let's clone the Access for User rule and block it for online stores.

It is also necessary to enable the “URL filtering by category” module in the properties of the UX with the central control center.

Let's save and set the policy.

Let's try to open any online store.

For example, we will open Ozon and Wildberries. They should not open, and the following entry should appear in the monitoring system

SSL/TLS INSPECTION

For all other web filtering mechanisms, we require SSL/TLS inspection.

For SSL/TLS inspection we need to issue two certificates:

These certificates are needed to carry out a Man in the middle (MITM) attack. She is the “man in the middle.”

Continent 4 NGFW intercepts the user's request and escalates the session from itself to the destination address. With its certificate, it returns a response to the user, which allows them to examine the contents of encrypted packets and make filtering decisions.

The original purpose of MITM is to attack data delivery security.

SSL/TLS inspection by some resources will be perceived as an attack against which there is a protective mechanism – a repository of global trusted certificates. The end resource can recognize the certificate substitution and block access. Such resources, as a rule, include software update repositories, banks and specific sites. You can solve this problem by adding the resource to the list of exceptions for SSL/TLS inspection.

At the time of writing, Continent 4 NGFW supports SSL/TLS inspection for TLS versions 1.0−1.3

We have already issued the root certificate for the monitoring system, so we will immediately proceed to issuing the SSL/TLS inspection certificate.

Go to “Administration” – “Certificates” – “Intermediate Certification Authorities”.

• Certificate type: SSL/TLS inspection

• Content: arbitrary

• Root certificate: the previously created RSA root certificate

We add this certificate to the UB.

We deliver the RSA root certificate to workstations that require SSL/TLS inspections. We install this certificate as a trusted certification authority.

WEB/FTP FILTERING

Let's move on to setting up web filters. “Access control” – “Firewall” – “Web/FTP filter groups”.

The list contains pre-installed groups of filters from Kaspersky Lab, Security Code and SkyDNS.

Their editing and deletion is prohibited.

Filter groups:

• Kaspersky: Botnets (botnet network viruses);

• Kaspersky: Malicious URLs (URLs with low reputation);

• Kaspersky: Phishing URLs (phishing sites);

• SkyDNS: Content Delivery Network (content delivery network consisting of geo-distributed server and network infrastructure);

• Continent: Threat Intelligence (indicators of compromise);

• SkyDNS (other) – websites by category

These groups are applicable for HTTP and HTTPS Web/FTP filtering schemes.

Let's create a group of WebFTP filters for HTTP.

In this group we will add two Web/FTP filter triggers:

• By get request to the resource lenta.ru;

• By two MIME types: for *.zip archives and *.exe executable files

We will create a similar group of Web/FTP filters for HTTPS traffic.

Now we need to make two profiles for Web/FTP filtering, which we will later use on the firewall.

Let's create the first profile for HTTP traffic:

• Block action for everything except manually created lists;

• Action “Redirect” to the site “https://tssolution.ru” for lists created manually

We copy the created profile and change the scheme from HTTP to HTTPS.

Next, we will include the created profiles in the filtering rules.

For applied filtering, you only need a rule with the same service. For example, if the rule filters over HTTP, then in the “Service” field you must select “HTTP”. For HTTPS – “TLS”.

Also, application filtering must be specified in a separate filtering rule without protocol inspection and application control.

If, in addition to the filtering rule with a profile, translation rules are created that specify the same sender/recipient. As with the filtering rule, these translation rules will not take effect.

Let's create two rules for testing web filters. In this case, we need to disable the rule with SNI. The joint operation of SNI application control rules and SSL/TLS inspection is described in the documentation and requires fine tuning.

We will include the “Protection against malicious websites” module in the properties of the user interface with the central control system.

Let's save and set the policy.

Let's launch the browser and open any web page. Let's open the certificate viewer and make sure that we are replacing the certificate.

Let's try to switch to the website lenta.ru.

The redirection to the tssolution.ru website will work almost immediately.

The Monitoring System logs will contain the following entries:

Now let's try to open an online store website. In our case, this is ozon.ru. The message “reset” appears.

Events appear accordingly. Let’s also add that in the screenshot below you can see the difference between blocking using a WebFTP filter and SNI: the recipient’s domain is now visible.

ECAP SERVICES

Continent 4 NGFW has the ability to add services to Web/FTP filtering profiles to scan traffic using hashes of malicious files or, more simply, streaming antivirus functionality.

In this case, a copy of the traffic is processed by the ECAP service, and the processing result is returned to the UB, which makes a decision about blocking or transiting the traffic further.

Traffic is checked using predefined Kaspersky hashes and user hashes. User hashes are generated by the administrator and can be additionally downloaded.

For streaming antivirus to work you need:

1. Create an ECAP service

2. Add ECAP service to WebFTP filtering profile

3. Enable the Anti-Virus component in the UX properties

1. Let's create an ECAP service.

It works regardless of the selected scheme. The settings can be left as default.

2. Add the created ECAP service to the previously created Web/FTP filtering profiles for HTTP and HTTPS traffic.

Since we already have these profiles, there is no need to create new rules in the firewall rules.

In the properties of the user interface with central control system, you must activate the “Anti-Virus” component. You can then save and install the policy.

For testing, we use the most famous test file, the hash of which is available in almost any antivirus: eicar.

When you try to download it, a corresponding notification appears:

Log entry about this event in the Monitoring System:

ICAP SERVERS

The “Getting Started” format course does not provide for integration with third-party services (for example: antiviruses, sandboxes, etc.) using the ICAP protocol. However, it is worth mentioning that such an opportunity exists.

You can find more materials on Security Code products Here

Continent 4 NGFW has the ability to add addresses of external ICAP servers to Web/FTP filtering profiles to scan traffic for viruses. In this case, a copy of the traffic is processed on the ICAP server, and the processing result is returned to the UB, which makes a decision about blocking or transiting the traffic further.

ICAP servers are configured in the MK in the section “Access Control – Firewall – ICAP Servers”.

CONCLUSION

To recap, in this article we looked at the web filtering process. Namely: we set up SNI filtering, worked with WebFTP filtering, and tested streaming antivirus.

In conclusion, we recall the most important points and provide additional useful information:

• In version Continent 4.1.7.1395, SNI support was added, but only for groups of SkyDNS websites. SNI support for custom groups has been announced since version 4.1.9;

• SSL/TLS inspection, Application Control, SNI and IDS may not work correctly with each other. To do this, it is necessary to fine-tune their joint work according to Best Practices from the Vendor;

• Streaming antivirus in Continent 4 NGFW is not a complete replacement for antivirus on end devices. Please remember this!

In the next article we will look at VPN in detail: organizing L3VPN and L2VPN, as well as connecting remote access.

See you at TS University!