Firewall purpose for Universität Hamburg internet access
Note
This strategy describes centralized security measures to be undertaken. These measures apply for all systems within the protected zone. They present the minimal level of protection required to protect against active external attacks. They do not provide any protection against internal attacks or data-driven attacks. They do not provide full protection against active external attacks, but only prevent known and particularly dangerous attacks. Even some known, very dangerous attacks cannot be prevented as this would interfere with important functions.
This strategy is a further step toward an overall security strategy.
This strategy does not relieve administrators from their duty to secure their systems.
1. Zones to be secured
The following security measures apply for the whole network with the prefix 134.100.0.0/16. All connections with other networks will be implemented using an access router. The following security measures will be implemented via access lists on the access router.
This strategy applies for all institutions using that IP address space.
2. Filter rules for ICMP
ICMP is a basic command protocol. Unfortunately, some types of ICMP packages can be used to attack IT systems. As only a certain number of types are actually required for operations, only these types are permitted and all other ICMP packages will be rejected, whether incoming or outgoing.
Permitted types are:
- type 0 (echo reply)
- type 3 (unreachable)
- type 4 (source quench)
- type 8 (echo request)
- type 11 (time exceeded)
- type 12 (parameter problem)
3. Filter rules for TCP
TCP protocols transport most data across the broader network connections of the internet. It is a connection-oriented protocol that filters by distinguishing between incoming and outgoing connections.
There are many TCP-based applications, with many new ones being created. Therefore, a comprehensive list of permitted applications is not possible—not only because of this diversity, but also because not all applications work with fixed port numbers.
For this reason, the following is a negative list of ports that carry known risks and whose use provides little value in comparison to that risk.
The following incoming ports are blocked:
- 111 (portmapper): This service is at the center of many attacks. It can itself be partially compromised and provide an attacker information about which ports are running other services critical to security. Blocking these services prevents RPC services being used from outside the network.
- 137-139, 445 (NetBIOS, smb): These services are used for Microsoft file and printer sharing. This provides many opportunities for abuse. Even Microsoft itself recommends blocking these ports. While these services are usually conducted via UDP, they are also defined for TCP.
- 161, 162 (snmp, snmptrap): These are network management services. Network management occurs from within a network and not externally. Attackers can use this service to obtain and potentially manipulate valuable information. The serious vulnerabilities in these protocols have recently become known. While these services are usually conducted via UDP, they are also defined for TCP.
- 515 (lpd): This service makes printers available without authorization. External users may not print in the University. There are also known and actively sought vulnerabilities in some widely used implementations.
- 540 (UUCP): This port was formerly used for transporting email and news. Although it is obsolete, it is often still activated.
- 2049 (NFS): This service is for file sharing on Unix systems. There are known and very dangerous attacks on this service. As NFS is based on RPC, which is already blocked, regular use of this service is not possible;
therefore, no ports need to be blocked.
The SMTP protocol (port 25) is a special position. Pursuant to the Universität Hamburg email strategy, this port is blocked, both incoming and outgoing, for all machines. A few specific email servers are excluded.
In future, the goal is to block protocols that use reusable plain text passwords. These include telnet, ftp, pop, imap, X11, and rlogin. Currently, use of these protocols is still so prevalent that blocking them is unfeasible. The importance of using secure protocols such as ssh, imaps, and spop should be impressed upon all users.
4. Filter rules for UDP
UDP is a connectionless protocol that does not distinguish between incoming and outgoing connections when filtering. The direction of an individual data packet can only be determined using the port number.
There are many UDP-based applications, with many new ones being created. Therefore, a comprehensive list of permitted applications is not possible—not only because of this diversity, but also because not all applications work with fixed port numbers.
For this reason, the following is a negative list of ports that carry known risks and whose use provides little value in comparison to that risk.
The following ports are blocked for incoming data packets:
- 67, 68, 69 (bootps, bootpc, tftp): These services are used when booting up devices. They only make sense for local networks and may be abused in very unpleasant denial-of-service (DoS) attacks and to snoop for configuration data.
- 111 (portmapper): This service is at the center of many attacks. It can itself be partially compromised and provide an attacker information about which ports are running other services critical to security. Blocking these services prevents RPC services being used from outside the network.
- 137-139, 445 (NetBIOS, smb): These services are used for Microsoft file and printer sharing. This provides many opportunities for abuse. Even Microsoft itself recommends blocking these ports.
- 161, 162 (snmp, snmptrap): These are network management services. Network management occurs from within a network and not externally. Attackers can use this service to obtain and potentially manipulate valuable information.
- 514 (syslog): This service provides central logging. It can be abused from outside the system to reveal or overwrite security relevant data.
- 1701 (L2TP): This protocol builds a tunnel. On this, see chapter 5.
- 2049 (NFS): This service is for file sharing on Unix systems. There are known and very dangerous attacks on this service. As NFS is based on RPC, which is already blocked, regular use of this service is not possible;
No ports are blocked for incoming data packets.
5. Tunnel through the access router
There are many tunneling protocols— for example, IP/IP, IP/GRE, IPsec, and L2TP.
Tunnels serve to transport packages across pathways that are not available using normal means or that are too insecure. If tunnels are configured through the access router, data packets may arrive in the University network without being filtered, as the access router cannot access tunnel content. That is why such tunnels pose a particular security risk.
If tunnels are essential, they should terminate at the access router, where possible, so tunnel termination points can be subject to filter rules.
Most such tunnel protocols are based on an IP protocol. These IP protocols are blocked at the access router. The known exception is the tunnel protocol L2TP, which is run using UDP. That is why UDP port 1701 is blocked.
Exceptions must be approved individually. In any case, it must be ensured that sufficient security measures are installed at the tunnel end point.
Exceptions:
- An L2TP tunnel from the operator’s backbone to a dedicated router in the University’s network is provided for DFN(at)HOME access, which the University provides to its students and staff. The router is administered by the operating company. DFN(at)HOME is only offered in this configuration. As legitimate internal users of the University dial in via this pathway, no special filtering is applied. It only blocks the sending of IP packets with falsified senders.
- A VPN solution is planned for the Hamburg university cooperation model. This will probably be based on L2TP and IPsec. This VPN is operated by the RRZ, and the University network is only accessible through its own firewall system, which has been very restrictively configured and is also operated by the RRZ.
6. Other protocols
Only IP-based protocols are supported.
At the moment, no known applications communicate with the outside world using IP protocols other than those listed in chapters 2 to 5. If such IP protocols become necessary, this need must be balanced against the security issues to be analyzed.
7. Other measures
There are a range of attacks that generate packets that are clearly not permitted. Such packets are not accepted. These include:
- packets leaving the University network without a sender address from this network
- packets coming from outside that are not permitted to be sent from the sender addresses (133.100.0.0/16, 127.0.0.0/8, 224.0.0.0/16)
- routing information coming from sources not permitted to participate in routing
- packets sent to broadcast addresses of a foreign subnet
8. Logging of rejected data packets
To ensure data protection, rejected data packets are generally not logged. Appropriate logging will be turned on only for pursuing specific problems.
9. Dynamic restrictions
Efforts are being made to create a device that supports intrusion detection for the next generation of the access router. This device can temporarily implement dynamic restrictions to fend off current attacks. Initial experience with the device has to be collected to precisely determine the rules.
10. Approval for exceptions
Justified exceptions must be submitted to the RRZ in writing for approval by the RRZ director. Approvals should only be granted when the number of exception rules in the access router for a department or cosupplied institution is very low. Efforts must be made to keep the number of exceptions low, as the length of the access lists has a direct influence on access router performance.
In any case, the department or cosupplied institution making the application must ensure the exception will not increase the risk for Universität Hamburg.