S 4.238 Use of local packet filters

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: Administrator

The entire network of an organisation should be protected by an appropriate security gateway. Servers offering services to the outside should be set up in a Demilitarised Zone (DMZ). Nevertheless, it is still recommended to set up access restrictions to the application and network level on each computer. This also applies to servers that are only used internally and, not least, to clients.

A local packet filter can protect a computer against attacks mounted from the same sub-network. In addition, such a packet filter can be used to implement a finer scaled access control for individual services than with packet filters that are only located at network gateways.

Moreover, a local packet filter can also be used to restrict outgoing network connections, thus limiting the effects of a system that has been compromised. Although an attacker may be able to disable such a protection once the computer has been successfully compromised, the attacker will at least be impeded. In this way, a decisive amount of time can be gained for detection and possible reactions.

Finally, the log function of a local packet filter allows detection of certain attacks in the first place.

Virtually all current operating systems offer the possibility to define filters that examine and handle all received packets or packets to be sent according to certain rules. The filtering options differ considerably between the individual operating systems. However, they almost always allow the definition of rules based on the source and target address of the packet and on the type of protocol used (TCP/IP, UDP/IP, ICMP, etc.) and, if required, on the source or target port. Hence, with the help of packet filter rules, packets coming from certain computers or certain sub-networks can be rejected in a selective manner.

Some server applications have their own mechanisms for allowing or prohibiting access to the service from individual IP addresses or address domains. Compared with these mechanisms, a local packet filter on the operating system level has the advantage of protecting the service itself against potential attacks that lead to a compromising of the system before the built-in access restriction can even take effect.

On principle, all servers with high protection requirements should be protected by a local packet filter.

There are two general strategies according to which packet filter rules can be implemented: The black list strategy allows all kinds of connections that do not fulfil certain exclusion criteria (liberal strategy: "Everything is allowed that is not explicitly forbidden"). The advantage lies in a

possibly lower effort in administration and error detection. However, a serious drawback is that forgotten rules allowing access to unprotected network services can form the basis of an attack.

In the white list strategy, on the other hand, all types off connections are blocked that are not on a list of allowed services (restrictive strategy: "Everything is forbidden that is not explicitly allowed").

The white list strategy offers greater security and should therefore always be applied if no serious reasons speak against it. The drawback is that the administration effort tends to be higher because with each change of requirements new rules have to be defined. In exceptional cases, e.g. if a protocol does not operate on a firmly defined port, you can fall back on the black list strategy.

It is advisable to install a local packet filter on all servers in the framework of basic configuration with a basic set of rules that, on principle, reject all connection requests from outside. This set of rules should be active when the system is connected to the network. Depending on which services are to be offered by the system, the protocols and ports they require can be released after they have been configured. This approach should also be considered for clients if they are subject to special security requirements.

Packet filters usually allow detailed logging of network traffic. The installation of a local packet filter therefore also makes sense in secure networks that are separated by a security gateway from an insecure network like the Internet, because the collected information can assist in detecting attacks. However, care should be taken that no data protection provisions are breached in the process. If required, the corresponding persons (data protection officer, staff representative or others) should be involved.

Problem of ICMP

The Internet Control Message Protocol ICMP is used to communicate error messages when transmitting IP packets. For example, there are messages notifying the sender of a packet that the target network cannot be accessed or that the packet is too large to be routed to the target system. The function of the ping and traceroute tools is also based on ICMP.

Apart from many useful features, there are some ICMP message types through which attackers can indeed gain important information on the network and directly use this information to mount attacks. However, the radical approach of always blocking ICMP at the security gateway is unfortunately not a satisfactory solution, because this means that certain functions are no longer available. One can usually dispense with ping and traceroute on normal workstations and servers, but the global blocking of ICMP can lead to impairments that are difficult to diagnose. It should therefore be considered both at the security gateway and the local packet filter to apply a selective ICMP filtering, insofar as this is provided in an adequate way. This should always be performed under consideration of the operational purpose of the computer (server or workstation), its protection requirements and the safeguards implemented at the security gateway. For example, a greater number of message types can be allowed for the internal network than for the external network.

More information on filtering ICMP can be found in module S 3.1 Security gateway (firewall) and, in particular, in S 5.120 Handling of ICMP on the security gateway.

Implementation and check

Which filtering and logging options are available is a function of the operating system. Prior to installing a local packet filter, the available documentation should be consulted.

Packet filter rules should be configured with great care, since an error in a rule can result in the administrator, who is working on the computer via the network, "locking himself/herself out". He or she must then make the corrections from the system console.

After the local packet filter has been enabled, it should be checked whether the required services can still be accessed, and a port scan should be used to check whether the remaining ports are all blocked.

Example: Local packet filter rules for a web server

In the following example, local packet filter rules are recommended for a computer set up as a web server in a DMZ. It is assumed that the server is administrated from a workstation via an SSH connection and that the files for the web offer are also transferred to the computer via an SSH connection.

For the Web server, the name resolution via DNS was turned off; access to a DNS server is therefore not required. Hence, UDP can be completely blocked. Usually, ping or traceroute are not required from the Web server; only ICMP message type 3 (Destination unreachable) is allowed. For easier diagnosis in the internal network, other ICMP message types (e.g. type 8 and type 0: Echo request and Echo reply) can be allowed. In this example, incoming Echo requests and outgoing Echo replies are allowed for the internal network: This allows to "ping" the web server from the internal network.

It is furthermore important that the SSH connections are only made to the web server and not from it. The same applies to the connections to TCP Port 80, which belongs to the web server process: Only incoming connections are allowed to this port, but no outgoing connections. This means that, on principle, no outgoing connection requests (only the TCP SYN flag is set) are required, but that only outgoing TCP packets belonging to an existing connection (the TCP ACK flag is set) are allowed. As described above, the blocking of outgoing connection requests serves the purpose of at least delaying an attacker who has gained access to the computer via a security vulnerability in the Web server service, for example. Although the attacker can disable this lock, it does increase security, especially if it is combined with the appropriate logging and alarm functions.

Source address: Port Target address: Port Protocol TCP flags or ICMP type Decision
Internal:* Web server: 22 (SSH) TCP SYN or ACK Accept
External:* Web server: 22 TCP All Block
Web server: 22 Internal:* TCP ACK Accept
All:* Web server:80 (http) TCP SYN or ACK Accept
Web server: 80 All:* TCP ACK Accept
All Web server, neither 22 nor 80 TCP All Block
Web server:* All:* TCP Without ACK Block
All All UDP - Block
All Web server ICMP Type 3 Accept
Web server All ICMP Type 3 Accept
Internal Web server ICMP Type 8 Accept
Web servers Internal ICMP Type 0 Accept
Web servers All ICMP Others Block
All Web server ICMP Others Block

Table: Example configuration for a packet filter

In the table, * stands for an arbitrary port.

Even higher security can be achieved in this example if the internal addresses from which access via SSH is to be allowed are further restricted. For example, if only two administrators make access from both their workstations, access could be restricted to the addresses of these two computers.

More detailed information on packet filters can be found in module S 3.1 Security gateway (firewall).

Review questions:

© Federal Office for Information Security. All rights reserved.