Chapter 5. Advanced features

It is very important to consider the way packets are handled in Kernun UTM. When combining packet filter rules, traffic shaping and application proxy access control lists, we need to take into account the order, in which network traffic is processed by individual components of the system.

Upon entering the system, network packets get inspected by the packet filter at first. The packet filter itself consists of a number of components. The order, in which these components handle network traffic, is always the same:

This order applies to both incoming and outgoing traffic, i.e. it is the same whether the packet is entering or leaving the system. As regards incoming packets, application proxies may take control only after they are processed by all the packet filter engines. On the other hand, traffic originated at application proxies goes through packet filter engines and then leaves the system for the network.

The packet filtering rules are defined in the system.packet-filter section. The following list introduces its items and subsections:

In the following sections we go through several typical configuration examples that involve capabilities of Kernun UTM's packet filter. We will start with the initial configuration as described in Section 2, “The Initial Configuration”. The resulting packet filter configurations can be found in the configuration sample file packet-filter.cml in the /usr/local/kernun/conf/samples/cml directory.

Packet filtering basically means controlling (either passing, or blocking) network traffic based on basic TCP/IP attributes, including the source and destination IP addresses and ports, the network interface the packet emerges on, its direction (inbound or outbound), and a few other protocol-specific characteristics.

Blocking traffic using the packet filter may be useful in many situations. For example, we may relieve application proxies of the burden of processing traffic that we know for certain is undesired. Also, application proxies always grab connections, and only then they may selectively deny them. This means that the connection is always established at first, and then immediately closed if denied by a policy. It may be advantageous to pretend to some clients that there is no application proxy in the way, which can be achieved by resetting those connections using the packet filter. Furthermore, there are antispoofing rules to block traffic with faked source addresses, see Section 1.3, “Antispoofing Using Packet Filter”, and it is possible to bypass the application proxy processing and forward some traffic directly to its destination, see Section 1.4, “Selective Packet Forwarding”.

Individual packet-filtering rules are located in filter-acl subsections within the system.packet-filter configuration section. The most important items in filter-acl are summarized here:

Example: If we want to block the traffic coming in on our external interface to the TCP port 22, we shall use the to, iface and deny items, as shown in Figure 5.1, “A simple blocking packet filter rule”.

Figure 5.1. A simple blocking packet filter rule

The deny part of the rule means that Kernun UTM will silently discard packets coming in to port 22. However, this behavior is not very effective, for several reasons. First, everyone knows that there is a filter blocking those connections, and that can attract unwanted attention. Furthermore, the standard application will not give up if there is no response to its connection attempts. Therefore, it is customary to send back information that the port is closed. We will do so by adding a return item to our filter rule, see Figure 5.2, “A blocking packet filter rule with return”.

Figure 5.2. A blocking packet filter rule with return

Figure 5.3. Option block-policy instead of return in rule

Should some specific clients be allowed to connect to port 22, we have to add a packet filter rule before the blocking rule we have just created. Rule evaluation abides by the so-called first-match principle. This means that rules are evaluated in the order, in which they appear in the configuration, and as soon as a matching rule is found, the evaluation stops and the remaining rules are ignored. Therefore, more specific rules must precede those with more generic matching criteria. Figure 5.4, “More specific rule must come first” shows how to add a rule allowing connections to port 22 to a set of IP addresses, preserving the default behavior of blocking port 22 to other clients.

Figure 5.4. More specific rule must come first

IP address spoofing is an attack based on counterfeiting the source IP address in order to confuse another computer system. It may be extremely dangerous if attackers from the outside pretend to have an internal source IP addresses; although they never get a response back, it may be sufficient to perform a successful denial-of-service or another kind of attack.

The goal of antispoofing is obviously to prevent spoofing attacks. We can stop intruders from the outside who pretend to have an internal source IP address quite easily. In general, internal network addresses can appear as the source of communication only on the internal network interface. As there may exist more than one protected network interface, this rule can be applied to other networks and interfaces as well.

A simple antispoofing rule consists of interface specification followed by the antispoof and deny items, see Figure 5.5, “Simple antispoofing rule”. In effect, the internal network 192.168.10.0/24 is blocked when it appears as a source IP address on any other interface than INT ^[26].

Figure 5.5. Simple antispoofing rule

This simple antispoofing rule works for networks directly connected to named interfaces. However, if our internal network is not flat, but consists of several routed networks instead, we need to involve all the internal networks in antispoofing. This can be achieved using the routes modifier in the antispoof item. The resulting rule is depicted in Figure 5.6, “Antispoofing rule including routes”.

Figure 5.6. Antispoofing rule including routes

Standard routers and filtering gateways accept all network datagrams, and if they are destined for another host, they send them out in accordance with the system's routing table. This mechanism is known under the name forwarding.

Kernun UTM does not forward network packets by default. Only traffic either destined for the system itself or grabbed transparently by application proxies will find its way through; everything else is thrown away. See transparency(7) for more detailed information.

It is possible to bypass application proxies and control the communication only with packet filter rules. To do so, we need to inform the transparent grabbing system which packets should be left untouched. For that purpose, a special tag NOTRANSP has been introduced.

To assign a tag to packets, add a tag item to a filter-acl rule inside the packet-filter section. Figure 5.7, “Selective packet forwarding rule” illustrates a rule causing the packet flow between two hosts to bypass transparent proxy processing, forwarding them directly to the network in accordance with the system routing table. Note that we have introduced a new interface, DMZ, representing a demilitarized zone with public accessible servers. The rule bypass-int-dmz permits bidirectional traffic between an internal host and a host in the DMZ.

Figure 5.7. Selective packet forwarding rule

Apart from tag, two more important filter-acl items are introduced in the sample rule bypass-int-dmz depicted in Figure 5.7, “Selective packet forwarding rule”: :

There are three types of NAT rules: mapping rules (nat-acl), redirection rules (rdr-acl) and bidirectional NAT rules (binat-acl).

1.5.1. Mapping Rules

Mapping changes source IP addresses (and often ports) of outgoing packets. It always applies to outbound traffic, but it also creates states for backward incoming communication. The state engine fully recognizes individual TCP connections, UDP sessions and ICMP control messages that belong to them. Hence, if a state is created, only legal communication is passed and translated forth and back.

The nat-acl sections allow for a similar set of items as filter-acl rules. The item from is used to match source IP addresses and ports, similarly to is matched against destination IP addresses and ports. The interface specification may not include the in/out direction as mapping rules apply only to outbound traffic. The deny modifier does not block traffic, but effectively denies any NAT mapping if matched.

A new important item is introduced for mapping rules: map-to. Its purpose is to specify the final address and port combination after the translation. A sample mapping rule is depicted in Figure 5.8, “Mapping NAT rule”. It illustrates the use of the map-to item; it specifies an IP address (using a reference to the outgoing interface's address ^system.DMZ.ipv4.host) and a port (0 in our example, meaning any port number available).

Figure 5.8. Mapping NAT rule

As always, mapping rules are implemented using the first-match principle, i.e. the first matching rule is applied immediately, without consulting the rest of the nat-acl rules.

1.5.2. Redirection Rules

Unlike mapping, redirection deals with destination IP addresses and ports. Redirection rules are thus applied to the inbound traffic, creating states. The same powerful state engine is in charge of matching backward outgoing packets and changing their addresses and ports back to their original values.

Apart from the target redirection address and port combination, which is specified using the rdr-to modifier, all other item names and features are the same in mapping and redirection rules. The example in Figure 5.9, “Redirection NAT rule” assumes connections from the 172.16.31.0/24 network, destined for the DMZ interface's local address 172.16.31.1 and port 80. Those connections get redirected to internal server at 192.168.1.20, port 80.

Figure 5.9. Redirection NAT rule

Imagine that we have an NAT network and want to bypass Kernun for some traffic (e.g. ICMP packets, in order to be able to ping to the internet from the local network). For that special case we need to create an NAT rule for the NAT and, at the same time, tag the traffic with the NOTRANSP tag to forward it, rather than give it to Kernun's proxies. The NAT rule automatically creates a state, so the reply to the ping should be delivered to the requester without the need to add any other rule.

However, there is a catch in the PF implementation. The NOTRANSP tag in combination with NAT rule gets lost and the returning packet is passed to Kernun, rather than forwarded. For this case, Kernun automatically generates a rule pass any to any tagged NOTRANSP no state tag NOTRANSP in the pf.conf file, in order to keep the tag. This rule permanently stores the NOTRANSP tag to the state of the tagged packet and is not applied to any other packets.

Figure 5.10. Forwarding of ICMP Packets over NAT

Figure 5.10, “Forwarding of ICMP Packets over NAT” shows a configuration of selective forwarding of ICMP packets on Kernun UTM for clients behind NAT. The filter-acl ICMP section tags the packet by the NOTRANSP tag to be passed through Kernun without giving it to the proxies, while the nat-acl ICMP-NAT rewrites the addresses and creates a state for the reply packets to be passed back. The returned packets are first NATed, then the above-mentioned rule is applied and restores the NOTRANSP tag, and the packet is therefore forwarded into the local network.

The packet filter, together with the network stack in the operating system kernel, provide some means for defense against Denial of Service (DoS) and Distributed Denial of Service (DDoS) attacks. Such attacks try to overload a target computer system or network by sending huge amount of traffic. A DoS attack is originated from a single malicious computer. A DDoS attack is similar, but data are sent by many computers at the same time. It allows the attacker to magnify the number of network packets many times in comparison with a single-origin DoS, hence making the effect on the target network worse and any defense harder.

Basic protection against some (D)DoS attacks on the transport layer of the TCP/IP is built into the network stack of the operating system kernel in form of the SYN cache and SYN cookies. They are effective especially against the SYN flood attack, when the attacker sends many TCP connection requests in the form of TCP SYN segments. The SYN cache keeps information about TCP connection handshakes that have not been completed yet. A SYN cache entry occupies less memory than the full state record of an established TCP connection. Hence the system is able to withstand much more SYNs. SYN cookies take one step further, keeping no state and encoding all information necessary to complete the handshake into the SYN/ACK segment sent to the client.

The SYN cache is always enabled. By default, SYN cookies are also enabled. They can be disabled by setting the sysctl variable net.inet.tcp.syncookies=0, see Section 2.6, “Kernel Parameters in /etc/sysctl.conf” for instructions on setting sysctl variables. SYN cookies are used when the SYN cache becomes full. It is possible to disable the SYN cache and use only SYN cookies by setting the sysctl variable net.inet.tcp.syncookies_only=1.

The SYN cache and SYN cookies protect only against SYN flood attacks on TCP-based application protocols handled by a proxy or by a server running locally on the Kernun system. Additional defenses are provided by the packet filter. They are effective for communication handled by the packet filter and not passing via any proxy, but can be combined with a proxy, too. They can also block attacks that perform full TCP handshake and then send excessively large volumes of application-layer data in order to overload a server.

The packet filter allows limiting numbers of simultaneous connections that match a filtering rule or originate from a single source addres. The limits are configured by adding per-rule options. There are two variants how to create such packet filter rules:

Available limit specifications are:

Example: The following rules will block any IP adress that initiates more than 100 HTTP connections per second.

table <dos_attack> persist
block quick from <dos_attack>
pass in proto tcp from any to any port 80 keep state \
    (source-track rule, max-src-conn-rate 100/1, overload <dos_attack> \
    flush global)

...