3. UserGate Getting Started. Network Policies

Greetings to the readers in the third article in the UserGate Getting Started article series, which tells about the NGFW solution from the company UserGate… In the last article, the process of installing a firewall was described and its initial configuration was made. For now, we’ll take a closer look at creating rules in sections such as Firewall, NAT and Routing, and Bandwidth.

The ideology of UserGate rules is that rules are executed from top to bottom, until the first one that works. Based on the above, it follows that more specific rules should be higher than more general rules. But it should be noted that since the rules are checked in order, it is better to create general rules in terms of performance. Conditions when creating any rule are applied according to the “AND” logic. If it is necessary to use the logic “OR”, then this is achieved by creating several rules. So what is described in this article is applicable to other UserGate policies as well.

Firewall

After installing UserGate, there is already a simple policy in the “Firewall” section. The first two rules deny traffic to botnets. The following are examples of access rules from different zones. The last rule is always called “Block all” and is marked with a lock symbol (it means that the rule cannot be deleted, changed, moved, disabled, only the logging option can be enabled for it). Therefore, due to this rule, all explicitly not allowed 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 the penultimate “Allow all” rule.

When editing or creating a firewall rule, the first General tab, you need to perform the following actions on it:

  • Use the “On” checkbox to enable or disable the rule.

  • enter the name of the rule.

  • specify a description for the rule.

  • choose from two actions:

    • Deny – blocks traffic (when this condition is set, it is possible to send ICMP host unreachable, you just need to set the corresponding checkbox).

    • Allow – allows traffic.

  • Script item – allows you to select a script that is an additional condition for triggering the rule. This is how UserGate implements the SOAR (Security Orchestration, Automation and Response) concept.

  • Logging – log information about traffic when a rule is triggered. The options are:

    • Log the beginning of the session. In this case, only information about the beginning of the session (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 the logging limit to prevent high device utilization.

  • Apply rule to:

    • All packages

    • to fragmented packages

    • to unfragmented packages

  • When creating a new rule, you can choose a place in the policy.

Next Source tab… Here we indicate the source of traffic, this can be the zone from which the traffic comes, or you can specify a list or a specific ip-address (Geoip). In almost all the rules that can be set in the device, an object can be created from a rule, for example, without going to the “Zones” section, you can create the zone we need by clicking the “Create and add a new object” button. Also, the “Invert” checkbox is often encountered, it changes the action in the rule condition to the opposite, which is similar to the logical negation action. Assignment tab is similar to the source tab, but instead of the traffic source, we set the traffic destination. Users Tab – in this place you can add a list of users or groups for which this rule applies. Service Tab – we choose the type of service from the already predefined one or you can set your own. Application Tab – specific applications or application groups are selected here. AND Time tab we indicate the time when this rule is active.

From the last lesson we have a rule for accessing the Internet from the “Trust” zone, now I will show as an example how to create a deny rule for ICMP traffic from the “Trust” zone to the “Untrusted” zone.

First, create a rule by clicking on the “Add” button. In the window that opens, on the general tab, fill in the name (Prohibit ICMP from trusted to untrusted), set a checkmark in the “On” checkbox, select the action to deny, and most importantly, select the correct location for this rule. According to my policy, this rule should be placed above the “Allow trusted to untrusted” rule:

There are two options for my task on the “Source” tab:

  • By selecting the “Trusted” zone

  • By selecting all zones except “Trusted” and putting a tick in the “Invert” checkbox

The “Destination” tab is configured in the same way as the “Source” tab.

Next, go to the “Service” tab, since UserGate has a predefined service for ICMP traffic, by clicking the “Add” button, we select a service named “Any ICMP” from the list provided:

Perhaps this was intended by the creators of UserGate, but I managed to create several completely identical rules. Although only the first rule from the list will be executed, the ability to create rules of different functionality with the same name, I think, can cause confusion when several device administrators work.

NAT and routing

When creating NAT rules, we see several tabs similar to those for the firewall. On the “General” tab, the “Type” field has appeared, it allows you to select what this rule will be responsible for:

  • NAT – Network Address Translation.

  • DNAT – Forwards traffic to the specified IP address.

  • Port forwarding – Forwards traffic to the specified IP address, but allows you to change the port number of the published service

  • Policy-based routing – Allows you to route IP packets based on extended information such as services, MAC addresses, or servers (IP addresses).

  • Network mapping – Allows you to replace the source or destination IP addresses of one network with another network.

After selecting the appropriate type of rule, settings for it will be available.

In the SNAT IP (external address) field, we explicitly indicate the IP address to which the source address will be replaced. This field is required if you have multiple IP addresses assigned to the destination zone interfaces. If you leave this field blank, the system will use an arbitrary address from the list of available IP addresses assigned to the destination zone interfaces. UserGate recommends specifying SNAT IP to improve the performance of the firewall.

For example, I will publish the SSH service of a Windows server located in the “DMZ” using the “port forwarding” rule. To do this, click the “Add” button and fill in the “General” tab, specify the rule name “SSH to Windows” and the “Port forwarding” type:

On the “Source” tab, select the “Untrusted” zone and go to the “Port Forwarding” tab. Here we must specify the “TCP” protocol (four options are available – TCP, UDP, SMTP, SMTPS). The original destination port is 9922 – the port number to which users send requests (you cannot use ports: 2200, 8001, 4369, 9000-9100). New destination port (22) – port number to which user requests will be forwarded to the internal published server.

On the “DNAT” tab, set the ip-address of the computer in the local network, which is published on the Internet (192.168.3.2). And you can optionally enable SNAT, then UserGate will change the source address in packets from the external network to its own IP address.

After all the settings, a rule is obtained that allows access from the “Untrusted” zone to a server with an IP address of 192.168.3.2 via SSH using the external UserGate address when connecting.

Bandwidth

This section defines the rules for bandwidth control. They can be used to restrict the channel of certain users, hosts, services, applications.

When creating a rule with the conditions on the tabs, we define the traffic to which the restrictions apply. Bandwidth can be selected from the proposed, or set your own. When creating bandwidth, you can specify a DSCP traffic prioritization label. An example of when DSCP labels are applied: By specifying in a rule a scenario in which this rule is applied, this rule can automatically change these labels. Another example of how this scenario works: the rule will be triggered for the user only when a torrent is detected or the traffic volume exceeds the specified limit. Fill in the rest of the tabs, as in other policies, based on the type of traffic to which the rule should be applied.

Conclusion

In this article, I covered rule creation in the Firewall, NAT and Routing, and Throughput sections. And at the very beginning of the article, I described the rules for creating UserGate policies, as well as how conditions work when creating a rule.

Stay tuned for updates in our channels (Telegram, Facebook, VK, TS Solution Blog)!

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *