Continent 4 Getting Started 2.0. Access control

In the previous article, we examined in detail the process of installing a Security Node with a Network Management Center (NS with NCC), carried out its initial setup through the Configuration Manager (MC), configured the Monitoring System, connected a subordinate Security Node (NS) to the NCC and updated all libraries.

If you are considering Continent 4 NGFW as a solution to which you plan to migrate from a foreign solution, we strongly recommend that you read the conclusion to this article. There you will find a list of useful materials.

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

You can find a video tutorial on this article here

NCC OBJECTS

All rules for Continent 4 NGFW consist of elements called NCC Objects.

NCC objects are selection criteria for transit traffic that must be transferred for processing according to filtering rules.

The following objects can be used in filtering rules:

Continent 4 NGFW allows you to import network objects from tables. To do this, a file must be generated in .csv format indicating the network objects.

The file structure is shown in the screenshot:

Path to import the list: RMB in “Network objects” – Import.

For laboratory work we will need various NCC objects.

Let's create them and simultaneously get acquainted with each object.

1. Network objects.

Network objects can be of three types:

• Host: a single network object (for example, 10.0.0.10);

• Network: subnet (for example, 10.0.0.0/24);

• Address range: host range (for example 10.0.0.1−10.0.0.10)

Let's create the network objects that are shown in the diagram:

• Protected subnet at the Central Office 192.168.1.0/24;

• Protected subnet in the branch 10.0.0.0/24;

• DMZ subnet 172.16.20.0/24;

• Administrator host 192.168.1.10;

• Host MS AD 172.16.20.100;

• User host in branch 10.0.0.10

• The external IP address of the Central Office gateway is 10.77.128.231;

• External IP address of the branch gateway 10.77.128.233

2. Services

By default, Continent 4 NGFW has basic services (TCP, UDP and ICMP), which can be expanded.

3. Users

User accounts can be created in the local NCC database or imported from Active Directory.

They will be discussed in more detail in the article “Working with Users”

4. Applications

Application signatures controlled by the complex are divided into categories for user convenience. Basic application control includes about 100 applications.

The following categories are available: business applications, virtualization, social networks, voice communications, cloud storage, remote access, etc.

When using extended control of applications and protocols, additional application signatures are loaded into the NCC database. The component is activated in the properties of the security node. Advanced Application Control includes approximately 4,000 applications and protocols.

Important! Basic and advanced application control cannot work together!

Applications included in advanced application and protocol control can be modified. To do this, a specific application attribute is selected. For example, we will prohibit file transfer in Yandex Disk.

In the search bar, look for the desired application and follow the path: RMB – Create application – Check the “file transfer” attribute.

You can also create application groups.

Let's create groups of applications and protocols:

• P2P;

• Messengers

5. Country

The Continent 4 NGFW has a built-in GeoProtection module. The administrator can restrict access to and from resources based on their geographic location.

6. DNS name

Using DNS name objects, you can limit access by DNS name for users.

At the same time, Cyrillic writing of FQDN with automatic resolution using Punycode is also supported.

FW RULES

The logic behind the firewall rules in Continent 4 NGFW is classic:

• Packets pass according to the rules from top to bottom (from first to last);

• Packets are passed down until they completely match all criteria of the rule. Further, the traffic of this session follows the matching rule;

• Logical “AND” is used between the criteria (columns) of the rule;

• If the packet does not fall under any rule, the packet is discarded

The following actions are possible with the rules:

1. Enter the name of the rule

2. Assign the sender and recipient of the package

3. Data transfer protocol

4. List of controlled applications/protocols

5. Skip or drop traffic

6. Select enhanced filtration profile

7. Enable or disable intrusion detection for a specific rule

8. Assign a time interval for the rule to be valid

9. Logging

10. Security node on which the rule will be installed

Let's write three blocks of rules for our scheme:

1. CO-Branch. In this block we will allow the passage of ICMP traffic between the subnets of the central office and the branch. The rules will be required when discussing L3VPN in the VPN article;

2. DMZ. In this block, we will allow DNS traffic to flow from local networks to the DNS server, and we will allow the DNS server to travel to public DNS servers using the DNS protocol. We will also allow external connections via port 8080 and 80 to the published IIS resource;

3. Central office local network access to the Internet. We will prohibit the circulation of traffic to two resources via DNS, we will prohibit access to Messaging and P2P applications, we will prohibit access to foreign resources

We will also install logging everywhere and select the UBs on which these rules will be installed.

Additionally, we note that there are “invisible” system rules. For example, at the very bottom there is the classic “CleanUP” or “drop any any” rule. If necessary, the administrator can specify it explicitly.

NAT RULES

When selecting a broadcast mode, the following options may be specified:

• “Do not broadcast.” Translation rules do not apply to traffic. Used for exception rules when transmitting part of the traffic without broadcasting.

• “Hide.” Masquerading (Hide NAT). Outgoing packets are assigned the IP address of the sender through which the recipient of the packet will be reachable.

• “Sender”. Changing the sender's IP address (Source NAT)

• “Recipient”. Changing the destination IP address (Destination NAT)

• “Display”. Broadcast the sender's IP address in one-to-one mode

For the scheme we need three rules:

• Do not broadcast local network and DMZ addresses;

• Hide NAT for central office and branch;

• Destination NAT for publishing a resource to an external network with port substitution

Additionally, we note that you need to pay attention to occupied system ports. For example, in a UB with a central control system in version 4.1.7.1395 and older, by default ports 80 and 443 are occupied for service operations.

You won't be able to publish HTTP/HTTPS without changing ports!

Before installing the policy, you must activate the “Advanced Protocol and Application Control” and “GeoProtection Module” components.

Let's go to the properties of the management system with the central control system and activate the necessary components:

TESTING THE RULES

Let's start checking with the GeoProtection module. Let's try to ping to the foreign resource google.com and the Russian resource vk.com.

The first resource is unavailable, there is no allow rule, and packets are dropped. The second one answers correctly, since there is a rule that allows access to Russian resources.

In addition to the ping command, the vk.com resource is available in a web browser. The rule with the geo module works correctly.

Let's try to turn to the resource where-emphasis.rf. This resource is located in Russia.

The site will take a long time to load, but will not open. Blocking will be triggered by the rule with the DNS name.

Let's try to open the official Telegram website, but it also does not open, since it falls into the Messaging application group and is detected by the DPI system.

We can see all events in the Monitoring System.

As we can see, connecting to the resource where-emphasis.rf is no different from accessing an IP address. In the case of Telegram, we see a signature. When you open an event, you can get extended information.

QOS

To ensure improved quality of data transmission, the Continent complex uses a special Quality of Service (QoS) mechanism. This technology gives different classes of traffic priorities in service.

The Continent complex supports the following QoS control mechanisms:

8 traffic priorities are presented (non-priority, low, below average, average, above average, high, highest, real time)

• minimizing jitter for real-time priority traffic

• IP packet marking

• managing traffic priorities when transmitting in VPN tunnels

The marking of an IP packet is determined by the DSCP mark in the IP packet header. The DSCP code is the six most significant bits of the DiffServ field.

DffServ is a model in which traffic is processed in intermediate systems based on its relative priority based on the value of the Type of Service (ToS) field.

It looks like this:

The DSCP label of the EF group has the highest priority class. The DSCP tag value is 46. This means that the traffic will be transmitted in the best possible way.

Best Effort. DSCP value 0. Means that traffic will be transmitted whenever possible.

To process priorities, the HFSC method is used to ensure queuing bandwidth allocation.

Let's test this functionality.

To do this, activate the “Traffic Prioritization” component and create rules.

The created rules establish that traffic from the central office to the branch via DNS protocols (udp/53 and tcp/53) will be given high priority and transmission will be carried out in the best possible way. ICMP traffic is defined as non-priority and will be forwarded whenever possible.

A traffic prioritization profile is created to determine the bandwidth for each priority type. Created for both outgoing and incoming traffic. The profile is applied in the security node settings.

Let's save and install the policy with QoS. Let's execute the ping commands and make several connections to the Internet. After that, let's turn to the Logging System. New entries with the “Priority” action have appeared (the QoS mechanism is working).

Let's also take a look at the extended information:

MULTI-WAN

The complex has the ability to configure a network while simultaneously connecting the UB to several external networks.

The following Multi-WAN modes are provided:

• transmitting traffic in accordance with the routing table;

• ensuring fault tolerance of the communication channel;

• balancing traffic between external interfaces of the management system.

However, the Multi-WAN mechanism has some limitations in its operation.

Multi-WAN settings are made in the properties of the security node in the Multi-WAN tab.

CONCLUSION

So, in this article of the series, we looked at the firewall settings and created basic firewall and NAT policies. We also checked the operation of the firewall and QoS.

As usual, we remind you of the most important points and provide additional useful information:

• NCC objects can be imported as *.csv tables;

• There are invisible firewall rules: access to the control center at the very top, the “drop any any” rule at the very bottom and other system rules;

• The QoS mechanism significantly loads the device;

• The Multi-WAN mechanism has some usage limitations

At the very beginning of the article, we mentioned that in conclusion we would share useful information for those migrating from foreign solutions.

Continent 4 NGFW has several converters that allow you to automate migration from Fortinet, CheckPoint and Cisco solutions.

If there is no converter yet, you can perform an intermediate conversion through CheckPoint. For example: Palo Alto – CheckPoint – Continent 4 NGFW.

Link to repository with tools

See you in the next article, in which we will look at working with users in detail: local and domain.