Welcome readers to the third article in the UserGate Getting Started series, which discusses the NGFW solution from the company . In the previous article, we described the process of installing the firewall and carried out its initial setup. Now we will look more closely at creating rules in sections such as “Firewall”, “NAT and Routing”, and “Throughput”.
The ideology of UserGate rules is that they are executed from top to bottom, up to the first match. Based on the above, it follows that more specific rules should be placed above more general ones. However, it should be noted that since rules are checked in order, it's better for performance to create general rules first. Conditions when creating any rule are applied according to “AND” logic. If “OR” logic is needed, this is achieved by creating several rules. Thus, what is described in this article is also applicable to other UserGate policies.
Firewall
After installing UserGate, there is already a simple policy in the “Firewall” section. The first two rules block traffic from botnets. Following that are examples of access rules from various zones. The last rule is always called “Block All” and is marked with a lock symbol (indicating that the rule cannot be deleted, modified, moved, or disabled; it can only have logging enabled). As a result, due to this rule, all explicitly unauthorized traffic will be blocked by the last rule. If you need to allow all traffic through UserGate (although this is strongly discouraged), you can always create a second-to-last rule called “Allow All”.
When editing or creating a firewall rule, the first tab is “General”, where you need to take the following actions:
Use the “On” checkbox to enable or disable the rule.
Enter the rule name.
Provide a description for the rule.
Select one of two actions:
Deny — blocks traffic (when setting this condition, there is the option to send ICMP host unreachable, just check the corresponding box).
Allow — permits traffic.
The Scenario Item allows you to select a scenario that is an additional condition for the rule to trigger. This is how UserGate implements the SOAR (Security Orchestration, Automation, and Response) concept.
Logging - to record traffic information in the log when the rule is triggered. Options available:
Log the session start. In this case, only the information about the session start (the first packet) will be recorded in the traffic log. This is the recommended logging option.
Log every packet. In this case, information about each transmitted network packet will be recorded. For this mode, it is recommended to enable logging limits to prevent high device load.
Apply the rule to:
All packets
Fragmented packets
Non-fragmented packets
When creating a new rule, you can choose a position in the policy.
Next the 'Source' tab. Here we specify the source of the traffic; it can be a zone from which the traffic originates, or you can specify a list or a specific IP address (Geoip). In practically all rules that can be set on the device, an object can be created from the rule; for example, without going to the 'Zones' section, you can use the 'Create and add a new object' button to create the zone we need. A checkbox labeled 'Invert' is often found; it changes the action in the rule condition to the opposite, which is analogous to the logical operation of negation. The 'Destination' tab is similar to the source tab, just instead of the source of the traffic, we specify the destination of the traffic. The 'Users' tab is where you can add a list of users or groups for which this rule applies. The 'Service' tab allows us to choose the type of service from the predefined ones or specify our own. The 'Application' tab is where specific applications or groups of applications are selected. And the 'Time' tab specifies the time when this rule is active.
From the last lesson, we have a rule for internet access from the 'Trust' zone; now I will show you as an example how to create a blocking rule for ICMP traffic from the 'Trust' zone to the 'Untrusted' zone.
To begin, create a rule by clicking the 'Add' button. In the window that opens, under the 'General' tab, fill in the name (ICMP Block from trusted to untrusted), check the 'Enable' checkbox, select the action to block, and most importantly, correctly choose the location of this rule. According to my policy, this rule should be placed above the 'Allow trusted to untrusted' rule.
In the 'Source' tab, there are two options for my task:
Select the 'Trusted' zone.
Select all zones except 'Trusted' and check the 'Invert' checkbox.
The 'Destination' tab is configured similarly to the 'Source' tab.
Next, go to the 'Service' tab. Since UserGate has a predefined service for ICMP traffic, by clicking the 'Add' button, we can choose the service named 'Any ICMP' from the list provided.
It may have been intended by the creators of UserGate, but I found that I could create several completely identical rules. Although only the first rule in the list will be executed, the ability to create functionally different rules with the same name could cause confusion when multiple administrators are working with the device.
NAT and Routing
When creating NAT rules, we see several similar tabs as in the firewall. On the 'General' tab, a 'Type' field has appeared, which allows us to choose what this rule will be responsible for:
NAT — Network Address Translation.
DNAT — Redirects traffic to a specified IP address.
Port Forwarding — Redirects traffic to a specified IP address but allows modification of the port number of the published service.
Policy-based Routing — Allows routing of IP packets based on extended information, such as services, MAC addresses, or servers (IP addresses).
Network Mapping — Allows replacement of source or destination IP addresses from one network to another.
After selecting the appropriate type, the settings for it will become available.
In the SNAT IP field (external address), we explicitly specify the IP address that will be used to replace the source address. This field is necessary when multiple IP addresses are assigned to the interfaces of the destination zone. If this field is left empty, the system will use a random address from the list of available IP addresses assigned to the destination zone interfaces. UserGate recommends specifying the SNAT IP to improve the performance of the firewall.
As an example, I will publish the SSH service of the Windows server located in the 'DMZ' zone using the 'port forwarding' rule. To do this, we click the 'Add' button and fill out the 'General' tab, specifying the rule name 'SSH to Windows' and the type 'Port Forwarding':
On the 'Source' tab, we select the 'Untrusted' zone and proceed to the 'Port Forwarding' tab. Here, we must specify the protocol 'TCP' (four options are available — TCP, UDP, SMTP, SMTPS). The original destination port 9922 is the port number to which users send requests (the following ports cannot be used: 2200, 8001, 4369, 9000-9100). The new destination port (22) is the port number to which user requests will be forwarded to the internally published server.
On the 'DNAT' tab, we set the IP address of the computer in the local network that will be published on the internet (192.168.3.2). Optionally, SNAT can be enabled, in which case UserGate will change the source address in packets from the external network to its own IP address.
After all the settings are completed, the result is a rule that allows access from the 'Untrusted' zone to the server with the IP address 192.168.3.2 using the SSH protocol, using UserGate's external address for the connection.
Throughput
This section defines rules for managing bandwidth. They can be used to limit the channel of specific users, hosts, services, and applications.
When creating a rule, the conditions on the tabs define the traffic to which the restrictions apply. You can choose a bandwidth from the options provided or set your own. When creating a bandwidth, you can specify a traffic prioritization label DSCP. An example of when DSCP labels are applied: by specifying a scenario in the rule to which this rule applies, the rule can automatically change these labels. Another example of the scenario's operation: the rule will be triggered for a user only when a torrent is detected or the traffic volume exceeds the specified limit. Fill in the other tabs just as in other policies, based on the type of traffic to which the rule should apply.
Conclusion
In this article, I discussed the creation of rules in the sections 'Firewall', 'NAT and Routing' and 'Bandwidth'. At the very beginning of the article, I described the rules for creating UserGate policies, as well as the principle of operation of conditions when creating a rule.
Stay updated through our channels (, , , )!
Source: habr.com
