S 2.76 Selection and implementation of suitable filter rules
Initiation responsibility: Head of IT, IT Security Officer
Implementation responsibility: Administrator
The Setting up and necessary updating of the filter rules for a security gateway are no easy tasks. The administrators must possess in-depth knowledge of the protocols used and must receive the corresponding training.
When setting up the filter rules, the following items should be taken into consideration:
- The reason for and initiator of setting up the rules must be documented appropriately. This is important in order to be able to comprehend later why the respective filter rule was implemented. Without this information, it is often difficult to promptly identify the contact persons of the approved applications and to decide whether the rule may be deleted or modified.
- As a basic principle, the white list strategy should be applied, i.e. the rules should be formulated in such a way that all accesses not expressly permitted are forbidden.
- If there is a need for user-specific authentication, it must be clarified which users from the internal network may use which services and which authentication procedures are to be used.
- All computers in the internal network must be taken into consideration.
- It must be defined which services are to be available at which times.
The filter rules for packet filters should be summarised in a table, one axis of which reflects the destination IP addresses and the other axis of which reflects the source IP addresses. The entries then contain the permissible port numbers, with the upper number being the source port and the lower number being the destination port. Packet filters may check the packets immediately upon receipt or immediately prior to forwarding, amongst other things. Normally, the first variant should be selected. Furthermore, the packet filters must be configured in such a way that only the numbers of the computers connected to the interface are admissible as sender address (ingress filtering). Addresses linked to the other interfaces may not be allowed to pass through. This reduces the risk of IP spoofing attacks.
Example:
The following table contains filter rules for the internal interface of a packet filter between an internal network and the intermediate network located between the internal and the external packet filters.
The entries contain the permissible connections, with the upper entry being the source port and the lower entry being the destination port.
| Source system | Destination system | Source port | Destination port |
|---|---|---|---|
| Internal mail server | External mail server in the intermediate network | TCP > 1023 | TCP: 25 |
| Internal DNS server | External DNS server in the intermediate network | UDP : 53 | UDP: 53 |
| IT system with IP address 192.168.0.5 | Application level gateway in the intermediate network | TCP > 1023 | TCP: 20.21 |
| IT system with IP address 192.168.0.7 | Application level gateway in the intermediate network | TCP > 1023 | TCP: 23 |
| IT system in the IP address range 192.168.0.* | Application level gateway in the intermediate network | TCP > 1023 | TCP: 22.80 |
| IT system in the IP address range 192.168.1.* | Application level gateway in the intermediate network | TCP > 1023 | TCP: 80 |
Table 1: Filter rules for the internal interface of the packet filter
It must not be possible to establish any connection between the systems not contained in this table, e.g. between internal mail server and external DNS server. All port numbers not listed must be blocked. If additional services or communication relations are required, table 1 must be supplemented accordingly.
For example, this means that the internal mail server may use TCP to access port 25 (SMTP) of the external mail server in the intermediate network from a port with a port number > 1023. Ports having a port number > 1023 are also referred to as unprivileged ports, as opposed to ports having lower port numbers that are referred to as privileged or "well-known" ports, since the services behind those port numbers were assigned by the "Internet Assigned Numbers Authority" (IANA).
In this case, this table must be implemented in corresponding filter rules. This is often not easy and so must be checked very carefully.
If required, the filter rules can be implemented with the help of tools facilitating the process of modelling the network and the related filter rules with the help of user interfaces. Regular tests must be performed in order to check that the filter rules correspond to the current requirements and that all filter rules have been implemented properly. In particular, it must be ensured that only those services are permitted that are planned for in the security policy.
Regarding the rules of an application level gateway, analogue tables must be drawn up and implemented in the corresponding filter rules.
Example:
| Organisational unit | Service | Commands | Authentication |
|---|---|---|---|
| F23 | FTP | ..., RETR, STOR | One-time password |
| R01 | FTP | ..., RETR | Chip card |
Table 2: Table for the rules of an application level gateway
The users of organisational unit F23 may (amongst other things) use the commands RETR and STOR of the FTP service, i.e. they are allowed to upload and send files using FTP, while the users of organisational unit R01 may only upload files.
Review questions:
- Is the white list procedure applied to the filter rules of the security gateway in order to prohibit all connections not expressly permitted?
- Have all computers in the internal network been taken into consideration in the filter rules?
- Have the set up filter rules of the security gateway been documented, e.g. by describing the respective function?
- Does the security gateway only allow services complying with the requirements of the security policy?