PT NGFW — межсетевой экран нового поколения

An event in the "PROdemo: Software Solutions Laboratory" series — a special project by the OCS Soft team. During the online meeting, Alexander Kanin, pre-sale expert in information security and network equipment at OCS, discusses PT NGFW — a next-generation firewall for high-load systems.

The event was opened by Alexander Kanin, pre-sale expert in information security at OCS Distribution. Today we will be talking about the new product Positive Technologies Next Generation Firewall.

I would like to start the discussion with an overview of the device lineup. All PT NGFW models have the same functionality and differ only in performance. Let's consider how the platforms differ from each other, and what they have in common.

The youngest series, PT NGFW 1010, in a desktop form factor and its related series, PT NGFW 1050, as well as the 20xx - 30xx series, look approximately the same. If we compare the platforms, the younger models PT NGFW 1010 and PT NGFW 1050 are built on the Intel Atom platform with 4 and 16 cores respectively, the middle or corporate line PT NGFW 2010-2020 has 16 and 24 cores, and PT NGFW 2050 is a dual-socket platform, i.e., two processors with 16 cores each, totaling 32. The older models, which are positioned as devices for data centers, are also dual-socket platforms, two with 24 cores and two with 32 cores. In terms of RAM, PT NGFW 1010, PT NGFW 1050 have 16 and 64 cores, PT NGFW 2010 has 128 GB of RAM, PT NGFW 2020, PT NGFW 2040 have 256 each. In the 30th series, the top models all have 512 GB of memory. In terms of storage, PT NGFW 1010 and PT NGFW 1050 have 250 GB hard drives, differing only in interfaces: SATA on PT NGFW 1010 and NVMe on PT NGFW 1050. In the middle line, all devices have 240 GB NVMe standard, and the top ones have 960 GB, also NVMe.

Now about the interfaces. The younger devices PT NGFW 1010 and PT NGFW 1050 have a fixed port configuration. These are two SFP+ ports, at 10 Gbps, two combined, i.e., shared, either SFP, or copper RG45, at 1 Gbps, and four dedicated copper gigabit ports. PT NGFW 1050 additionally has 4 slots for nanoSIM. This is a provision for the future; they are not used in any way yet. In the future, an LTE module should appear, which will allow using this interface as well. The older 20th and 30th series do not have data ports in the base, but have the ability to install up to 5 network cards. Currently available network cards include a four-port gigabit copper card, a two- or four-port 10-25 gigabit per second SFP28 card, and a card with two 100 gigabit QSFP28 ports.

From the point of view of management, controlling these devices. All models have a console port, as any normal network device should. The 20th and 30th series have a BMC port for remote management of the server platform. Also, all models absolutely have a VGA connector; it is provided for managing hardware trusted boot modules, which are used in certified PAKs. Either Sobol or Accord is used as boot modules in certified PAKs.

All, even the youngest models, have redundant power supplies, which is very important for ensuring fault tolerance. Even the PT NGFW 1010 also has two power supplies. I would also like to note that the PT NGFW 1010 is made in a fanless design.

It can also be noted that, in addition to the VT-PAK versions, NGFW is available as virtual machines, which are supplied as ready-made virtual machines, ready-made images for KVM and VMware. There are also two options: 1Dp and 10Dp. They differ in requirements. 1Dp is 4 virtual processors, 12 GB of RAM memory, and 30 GB of storage. The other virtual machine has 14 vCPUs, 22 GB of RAM, and 30 GB of storage.

Now let's talk about how the models differ from each other in terms of performance.

I would note that initially, when developing NGFW, Positive Technologies focused on the high performance of their product. To do this, they had to write the product core almost from scratch. They completely abandoned the standard Linux approach to traffic processing, and the result was impressive. As you can see, the figures presented on this slide correspond to the level of top foreign vendors, and are definitely higher than any domestic competitors. This is achieved by abandoning the standard packet processing pipeline used in Linux systems. In NGFW, all processing is done in userspace. Positive Technologies abandoned the use of kernel functions for this, the so-called kernelbypass for packet processing. And they isolated the resources that NGFW uses. These are CPU cores, memory, network adapters. The zero-copy approach is also used. In the standard Linux PAKclone, different spaces are used for packet processing, and data has to be constantly copied when switching between them, which introduces significant delays and performance limitations. In this case, the network card uses DMA (Direct Memory Access) to write data directly to userspace, and then at all stages of processing, the application operates on the original data without copying it each time. Also, each functional block supports processing packets in batches, rather than one at a time, which also reduces overhead. We can also talk about the indivisible processing pipeline as a whole. This implies that packet processing from the moment it is received on the network card until it is output to the output port occurs strictly on the same CPU core. That is, the course of the stream is not interrupted by interrupt execution or preempted by other streams.

As you can see, even the youngest platform can provide 5.5 gigabits per second and 1.3 million packets per second in LR7 firewalling mode and up to 900 megabits per second with IPS. The figures here are presented in two versions. This is just firewalling and firewalling with IPS. If you turn on all security modules at all, including antivirus, Rally filtering, and streaming antivirus, RL filtering, descript TLS, probably the most demanding of the modules, then in all modules mode, the youngest device will provide 100 Mbps, PT NGFW1050 - 500 Mbps, PT NGFW 2010 - 1Gbps, PT NGFW 2020 - 2 Gbps, PT NGFW 2050 - 5 Gbps, and the older models will give 10 Gbps with a difference in the number of packets per second, 15 or 20 million.

These figures are taken from the results of load tests.

PT uses established methodologies to conduct its tests so that the assessment is objective and can be trusted. The tests are based on 2 RFC 3511, which is now obsolete because it was written for previous generation firewalls, i.e. for ordinary firewalls. And the other RFS they took was 9411. Of course, it includes security, IPS, attacks in traffic. It also includes TLSDecrypt, i.e. traffic decryption. It contains information on how to organize the test environment, contains specific client-server configurations, and describes in detail various tests for performance evaluation.

Here is one of the RFC options, such an average traffic mix that is most representative of corporate networks. Most of it is TLS, which accounts for 73%, followed by SMB, HTTP, RDP, and other application protocols. Actually, Positive Technologies actively shares the testing results. Not only the results, but also the methodology. They describe and show in detail how they do it. Therefore, when reading the datasheet, you can really believe the figures. It's no secret that datasheets for similar devices from other manufacturers have inflated figures.

On this slide, we see more detailed results for the oldest device, the PT NGFW 3040. Here, it's 160 Gbps in firewalling mode at the application level with EMIX traffic. If we turn on IPS with 100,000 signatures, we will get 60 Gbps, and with all security modules, it will be 10 Gbps.

Let's discuss control plane protection.

On this slide, we see the output from the device's console of the H-TOP command. This command shows how the processors are used, how they are used. As you can see, almost all processors are used at 100%, except for one. This indicates the same resource reservation that I mentioned earlier. That is, most of the processors are occupied by the kernel. This does not mean that they are actually fully loaded. They look loaded to the Linux kernel, that they are busy. One core is always allocated for managing the device itself, i.e., it is fully reserved for these purposes. Thus, regardless of the data stream that is fed to the security gateway, whether it is overwhelmed or not, the administrator will always be able to log in and solve the problem. One core, as I said, is reserved for management, all the others are for dataplane, and one core may also be slightly less loaded, this is such a broker between other cores, between NGFW applications. Of course, fault tolerance is a very important component for any network device, and for NGFW in particular.

Positive Technologies implemented a classic scheme, only they abandoned VRRP, although it does not have to be used. Instead of VRRP, they use their own development. Currently, Positive Technologies is talking about an approximate figure of 300 ms for switching. Of course, since we are talking about Stateful Firewalling, i.e. with maintaining session information, all necessary tables and session tables, art records, fibs, and other information are synchronized between Active-Standby nodes. In order for the convergence of dynamic routing protocols to occur when switching from the active to the backup node, Graceful-Restart is supported. The same applies to Garpa, it is supported to notify clients that a migration has occurred. Modern data center architectures, Leek-Spine, are supported. It is important to note that there is a special license for the backup node, since in order to build a fault-tolerant cluster, you need two identical devices and with identical licensing.

Management system. It is worth noting right away that from the point of view of device management, a separate module is used here, and a separate virtual machine or virtual appliance. That is, if we are talking about a fault-tolerant cluster of two NGFWs, then, in fact, there will still be three devices. This is a separate management module to which security gateways are connected, and two security gateways.

Management occurs through this management module. Gateways are connected to it internally, and they are built into a hierarchy. If we talk about fault tolerance, then two connected security gateways in the management system will look like one. Inside, we build a hierarchy, everything starts from the global level, we create various groups of devices that we add and already administer. It turns out to be very convenient, a hierarchy of both management and assignment of security policies is built.

Also, each physical device can be divided into logical firewalls. A virtual context is the same as a virtual router in the context of routing. If we need to somehow logically divide the management, divide the firewalling, in accordance with some segmentation of our business infrastructure, then this can be done with one device.

Currently, up to 256 contexts are supported on any of the NGFWs, and no additional licensing is required for this.

Security policies are also applied to groups of devices in accordance with the built hierarchy, which allows you to adapt to your business logic. There is a combination of pre-rules and post-rules.

We can write global rules that will apply to our entire infrastructure. They consist of pre- and post- rules. Pre-rules go to the beginning of the list, post- rules, respectively, to the end of the list. Our entire nested hierarchy, i.e. what we had under global, such as a group of devices, will be inside. Pre-rules, for example, on this slide from PRE offices, will not be in the middle between inside global, thus ensuring a common logic for the entire infrastructure. Then the entire list of rules is applied in turn to the processed traffic until the first rule is triggered. User control is supported, integration with Active Directory and Open LDAP is assumed. Currently, only Active Directory is supported. How is this implemented? There is a separate agent, which is currently located together with the management module, but it is supposed to be taken out separately later, depending on the load, on the performance that will be required.

This agent connects to ActiveDirectory using secure protocols (everything is encrypted), reads PLDAP information about groups, information about users from there. It also reads the event log, from which it takes information about which users connected to which machines, where they were authorized, compares this information of users with machines and with their IP addresses. And then, this information can already be used in security rules.

Control of applications and sub-applications. The product has a fairly large number of application signatures. It is important to note here that, since this is a domestic development, the product takes into account a large number of domestic applications.

We can recognize the most popular things. At the same time, not only the application is determined, but also the actions within this application. Thus, we can, for example, allow downloading from Yandex.Disk and prohibit uploading to Yandex.Disk. Or, for example, prohibit music, allow video. Actions within the application are recognized in the same way as the application itself.

At the same time, the application signature database is quite wide, currently 1687 applications are identified there, and this list is constantly updated.

The product also has a GeoIP database, which allows you to match IP addresses that we see in triggers, which we see in traffic, with their geographical affiliation, which can be important and convenient for building your security.

That is, we can, for example, completely prohibit interaction with IP addresses associated with the United States. And the database that is presented is relevant specifically for the Russian market.

Of course, the main ingredient of a firewall is IPS. Here it is necessary to note that the IPS rules that are used in PT NGFW are written by the experts of Postive Technologies themselves, and these are not reused rules. They are deeply integrated into the traffic processing pipeline in order to ensure high performance.

If, for example, you try to insert just your own similar rules, then any one rule can lead to a strong degradation of performance. Therefore, you should not do this. Postive Technologies has taken all this into account here, such high performance is ensured only by its own rules. In addition, Postive Technologies has been in the information security market for a long time. They often conduct various investigations, conduct security audits, and pin tests. A fairly large customer base turns to them.

I would note that the number of rules is different on different devices. In younger models, up to 10 thousand rules, in older lines, up to 100 thousand rules. IPS rules can be profiled. We can select from them those that are interesting and relevant for our infrastructure or for some specific segments of our infrastructure, and use only them. And others, for example, either completely exclude from our profile, or hang rules on them so that they are skipped, not paid attention to.

TLS inspection. Currently, Decrypt TLS 1.2 and TLS 1.3 are supported. Using encryption rules, you can specify which traffic should be decrypted, which traffic should be excluded from this process.

This functionality is required in order to be able to generally recognize the application in encrypted traffic, to apply security rules to it, and to analyze it with external systems. The mechanism of direct transparent TLS-PROXY is used. Also, decrypted traffic can be mirrored. When mirroring, a copy of such decrypted traffic is sent to some external system. This can be a traffic analysis system, for example, PTNAT, or it can be a DLP system. In order to configure such a function, you need to specify a mirroring profile in the decryption rule.

And in the profile, the interfaces to which the copy of traffic will be transmitted are already specified.

If we talk about the flexibility in the settings that are now in the system, then here it can be noted that there is an extensive set of actions for each rule.

For example, you can allow traffic, you can "deny", i.e. prohibit with notification, you can simply drop, i.e. drop the packet without notifying the parties to the communication that something has happened, you can terminate the session by sending a TSP reset to the client, a TSP reset to the server, or to both ends.

The same applies to logging. Logging is configured in quite detail. Here you can also choose different options for actions when rules are triggered.

You can log something, not log something. You can write to the log every time a rule is triggered. You can make it so that at the beginning of the session for a TCP session, i.e. after the completion of the TCP-handshake, after that it needs to be created, it needs to be created at the end of the session, you can make it so that both ways, both options, and you can completely disable logging. At the same time, there are several different logs in the system, one is dedicated to traffic, where the triggering of security rules is recorded. Another log is dedicated to traffic decryption. There is a separate log for IPS, a log for antivirus, a log for audit, which records changes in the management system and actions in it, and there is also an authentication log, where logins and logouts to the management system are recorded.

I want to note an interesting and useful feature. When we configure security rules, the interface immediately highlights the traffic that falls under this rule. And we don't even have to go to the log to see it.

On the right side of the security rules there is a trigger counter, which immediately shows this. The system has a convenient interface for working with both the log and the security rules themselves, which allow us to filter information, highlight interesting information, and in a few clicks we can find exactly what is interesting, what is important. At the same time, the system itself can suggest exactly what you need to enter.

Also from the functions you need to note URL filtering with categories. They are already in the database, all the most popular firewalls. Accordingly, you can write security rules that will prohibit communication in social networks, but allow reading the news feed. All profiles are already there. You can also create your own profiles if we want to include or exclude something at our own discretion.

The system also uses a role-based access model. There are predefined roles of super-administrator, system administrator, and security administrator. Each role corresponds to a set of accesses to various functions.

In general terms, they provide either just viewing entities, creating and performing actions on entities, changing them, and deleting them. And a different combination of these possibilities forms different role-based accesses.

Syslog support has also appeared, also a mandatory function.

Now you can send all events to some external systems. Support for streaming antivirus has appeared, which allows you to detect an infected file in the transmitted traffic. A file is considered infected if its hash sum matches the antivirus signatures.

Files transmitted over HTTP and HTTPS are checked, respectively, when decrypting HTTPS. To check, you need to include the security module in the rule that allows traffic transmission. Blocking the transmission of an infected file is accompanied by a TSP reset to both the client and the server, and logging of this event.

The event card in the NGFW logs has been expanded. Now each specific line can be opened and you can see all the detailed possible information in it.

Action logging has appeared. When I say that it has appeared, I am talking about the already penultimate version, version 1.5. If we summarize, then this is what the functionality of PT NGFW looks like at the moment.

From the point of view of routing, everything necessary is here. This is OSPF, BGP static routing, SourceNAT and DestinationNAT support, VRF support. From the point of view of security, there are virtual contexts, IPS, streaming antivirus, URL filtering. From the point of view of maintenance administration, of course, class Active/Standby, VLAN support for configuration. Here, I understand, it means VLAN support on subinterfaces and in terms of traffic re-tagging in vWire transparent mode. GeoIP support, user identification, AppControl, logging, FQDN, TLS inspection. And everything you see on the slide.

If we talk about the development of the product, about what is expected in the near future, then in March 2025 we are waiting for the appearance of the side-to-sideVPN function. Of course, this is an extremely important function.

In May 2025, PBR (policy-based-routing) will appear. As far as I know, it is already in some mode, it remains to be "delivered" to the product interface. SNMP support for monitoring and management will appear. Well, at the end of 2025, we are waiting for the appearance of Remote-AccessVPN, along with it a VPN client will appear in order to use it, and a geographically distributed cluster will appear.

Of course, like any network device, NGFW can occasionally break down, so all devices are supplied with technical support.

Extended technical support is also provided, which includes replacing the failed device on the next calendar day. Support 24/7, because NGFW is on the perimeter and is a critical device. A short response time to requests and equipment replacement is provided. There is also the possibility of replacing equipment without returning hard drives if you want to save your data. In this screenshot, you can find additional materials on NGFW.

Illustrations are provided by the press service of Positive Technologies