S 5.39 Secure use of protocols and services

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: IT Security Officer, Administrator

The following brief descriptions of protocols and services frequently used on the Internet are used to explain what information is transmitted by these protocols and is therefore available for filtering by a security gateway. Furthermore, this safeguard also covers some other basic points which should be taken into account when using various protocols and services.

Basic lower-layer protocols of the ISO/OSI layer model

IP

The Internet Protocol (IP) is the protocol on which practically all of the protocols commonly used in local networks are based. IP is a connectionless protocol. Among other information, an IP header contains two 32-bit addresses (IP addresses), one for the target computer and one for the source computer.

Since it is easy to fake IP addresses (see also T 5.48 IP spoofing), they can only be used in very specific topographies for the purpose of authentication, i.e. when it is ensured that the addresses cannot be changed. For example, packets coming from outside but having addresses located in the network to be protected as their source address should be rejected by the security gateway.

ARP

The Address Resolution Protocol (ARP) is used to find the 48-bit long MAC address (Media Access Control address, also called the hardware or Ethernet address) corresponding to a given 32-bit long IP address. Every computer maintains a table in its broadcast domain for other stations to store the IP addresses to their corresponding hardware addresses. If no corresponding entry for a given IP address is found in this table, then an ARP broadcast packet is sent that contains the IP address of the station whose MAC address was requested. The computer with this IP address then returns an ARP response packet containing its MAC address. ARP response packets can be manipulated, i.e. they are not tamper-proof (referred to as "ARP spoofing", see also T 5.112 Manipulation of ARP tables).

ICMP

The task of the Internet Control Message Protocol (ICMP, specified in RFC 792) is to transport error and diagnostics information for the IP protocol. It is triggered and processed internally by the IP, TCP, or UDP protocols. ICMP recognises a number of different so-called types of messages for a variety of purposes.

Depending on the operational scenario, certain ICMP message types should be allowed or blocked selectively. See S 5.120 Handling of ICMP on the security gateway for information on handling ICMP on the security gateway.

Routing protocols

Routing protocols such as RIP (Routing Information Protocol) or OSPF (Open Shortest Path First) are used to pass changes in the communication route between two networked systems to the systems involved, and therefore to permit the routing tables to be changed dynamically. It is very easy to generate false RIP packets, and therefore easy to configure undesired routes. For this reason, dynamic routing should only be used in very specific topographies.

The use of routing protocols on security gateways should be kept to the absolute minimum possible. Only secure routing protocols should be used wherever this is possible. More information on this subject can be found in S 5.112 Security aspects of routing protocols.

UDP

The User Datagram Protocol (UDP) is a connectionless protocol in the transport layer. It does not provide transport acknowledgements or any other security measures for ensuring the correctness of the transmission. Among other information, the UDP header contains (like TCP) two 16-bit port numbers, although these numbers are not related in any way to the port numbers used in TCP. Since it is easy to falsify these port numbers, they can only be used for authentication purposes in very specific topographies.

Since the protocol definition does not differentiate between a call connection and data transfer, a component of the security gateway must make this differentiation. It must be possible to check the status of the connection, and it must also be possible to identify clearly to which connection a packet belongs.

When making a UDP call connection, for example, this can be achieved by storing the target port and temporarily opening it, only permitting response packets to pass to this port, and blocking the port again after the connection has been terminated or has timed out.

Application layer protocols

DNS

The Domain Name Service (DNS) is used to convert computer names to IP addresses and vice-versa. It also provides information on the computer systems available in the network. DNS can be processed via TCP and via UDP, and the server uses port 53 by default for both carrier protocols. UDP is usually used as a carrier protocol.

The information transmitted is not protected by cryptographic procedures, which means spoofing attacks using falsified data are possible (see also T 5.78 DNS spoofing). This needs to be taken into account, especially for DNS replies coming from the Internet.

As a general rule, it must be noted that it is possible to misuse all of the information provided by DNS.

This is necessary to integrate DNS in a security gateway (see also S 2.77 Integration of servers in the security gateway and S 5.118 Integration of a DNS server into a security gateway.

SMTP

The Simple Mail Transfer Protocol (SMTP) is used for the transmission of e-mail. SMTP servers (mail servers, also referred to as Mail Transportation Agents or MTAs) use TCP port 25 by default. SMTP, which is defined in RFC 821, consists of a small set of commands, and some of these commands are questionable from a security perspective.

For example, the VRFY and EXPN commands can be used to request internal information on the users. For this reason, use of these commands should only be allowed in a protected network. For non-trusted users, and especially for user requests from the Internet, the VRFY and EXPN commands should be blocked on the ALG (Application Level Gateway) or directly on the MTA (Mail Transportation Agent or mail server).

Ideally, a security gateway should be able to encrypt SMTP connections between trusted users. The use of encryption only makes sense, though, when a strong authentication mechanism is used.

HTTP

The Hypertext Transfer Protocol (HTTP) is used to transmit data between web clients (usually web browsers) and web servers. HTTP and its various extensions are defined in a series of RFCs. RFC 2616, which specifies the current version of the hypertext transfer protocol HTTP 1.1, contains a series of references to older documents. Web servers use TCP port 80 for HTTP communication by default.

HTTP is a plain text protocol that does not offer any support for secure authentication or any guarantee of the confidentiality and integrity of the transmitted data. This should be taken into account when deciding which transactions are allowed to be processed via HTTP.

Additional information on safeguards relating to the use of HTTP can be found in S 4.222 Correct configuration of security proxies and S 4.100 Security gateways and active content.

HTTPS

HTTPS (HTTP over SSL or HTTP over TLS) is a version of HTTP in which the authentication procedure and transmission of data can be protected using encryption and certificates. HTTPS is specified in RFC 2818. A web server that supports HTTPS usually uses TCP port 443.

When using HTTPS, it must be noted that TLS also has an operating mode that does not use encryption. If this contradicts the security requirements, then the HTTPS proxy should be set up to prevent such connections from being established.

Further information can be found in S 4.222 Correct configuration of security proxies and S 4.100 Security gateways and active content, as well as in S 5.66 Use of TLS/SSL.

Secure Shell / Secure Copy

The Secure Shell (SSH) protocol allows secure command line connections to be established to a remote computer. The SSH protocol allows secure authentication using a variety of different authentication mechanisms (for example user names and passwords, special certificates, a centrally administered PKI infrastructure, or using Kerberos). SSH is therefore a suitable replacement for Telnet. SSH should be used instead of Telnet wherever possible. By default, an SSH server uses TCP port 22.

The Secure Copy Protocol (SCP), which uses the authentication and encryption mechanisms of SSH to transmit files, is also a member of the SSH protocol family. SCP constitutes a secure alternative to FTP.

For SSH, there are many different implementations for practically all commonly used operating systems as well as additional implementations which are independent of operating systems, for example in Java. However, the various implementations sometimes differ in terms of the number of authentication mechanisms supported and in other details.

Most SSH clients also offer the option of "tunnelling" other protocols through an existing SSH connection to avoid the disadvantages of plain text protocols, for example. However, use of this option also comes in conjunction with a certain risk since data transmissions can be "hidden" in this manner. When using SSH, it is therefore necessary to check carefully which connections are allowed to which communication partners. If necessary, a corresponding security proxy should be used that interrupts the encrypted connection at the security gateway.

There is a design error in the original version of the SSH protocol (ssh1) allowing man-in-the-middle attacks. For this reason, a new version of the protocol (ssh2) was developed to eliminate this vulnerability. The ssh1 version of the protocol should no longer be used, at least not across public networks. If a security proxy is used on the security gateway for SSH, then the proxy should offer the option of forcing ssh2 connections and prohibiting all ssh1 connections.

Telnet

The Telnet protocol is specified in RFC 854. It allows (similarly to SSH) users to open terminal sessions on remote computers. Telnet is a plain text protocol that does not offer any mechanisms to secure the authentication information or the data and commands transmitted. A Telnet server uses TCP port 23 by default.

Since Telnet allows full access to the command line of a computer, but does not offer any security mechanisms, SSH should be used instead of Telnet wherever this is possible. Alternatively, Telnet connections can be tunnelled via SSH. If there are compelling reasons for why Telnet cannot be replaced with SSH or if tunnelling is impossible, then Telnet can be still used in the internal network. In this case, though, the communication connections allowed should be restricted to the absolute minimum necessary using corresponding packet filter rules. Telnet should only be used in specially isolated administration networks for administration tasks.

Telnet connections can be taken over by an attacker who has access to one of the network components via which the corresponding connection runs (see T 5.89 Hijacking of network connections). For this reason, Telnet should not be used on insecure connections anymore (public networks) even when the Telnet server supports advanced authentication mechanisms such as one-time passwords.

FTP

The File Transfer Protocol (FTP) is specified in RFC 959. It allows remote computers to exchange files. Like Telnet, FTP is a plain text protocol that does not offer any security for the authentication information and data transmitted.

When using FTP, two connections are established, with commands being transmitted via TCP port 21 and data via TCP port 20. Telnet defines a number of standard commands which are used to control the type and format of data transmission and which allow a FTP client to navigate in the file tree of a FTP server. These standard commands are relevant for the security gateway, since they are the only commands actually transmitted.

An FTP command connection to port 21 of the server is established by the client. There are two operating modes in FTP for data connections, i.e. the active mode and the passive mode. In the active mode, the FTP server establishes the data connection to the client, whereas in the passive mode the data connection is also established by the client.

The active mode is a security gap, because an attacker could pretend to be a server and would therefore be able to establish a connection to the internal network. If FTP is used, then the passive mode should always be used, whereby both the command connection and the data connection are established by the protected network to the external network.

All commands which manipulate or read files or directories (CWD, CDUP, RETR, STOR, DELE, LIST, NLIST must be linked to an appropriate rights management system. Access by non-trusted users is then restricted to certain files or completely prohibited. This assumes the use of strong authentication mechanisms.

The SYST command used by clients to query the operating system version of the server should also be linked to a rights management system, and its use should be blocked for non-trusted users.

Furthermore, it must be possible to encrypt the transmission of files, directory information, and passwords.

FTP should not be used to transmit sensitive data over a public network. If sensitive data requiring protection is transmitted over an external FTP connection, then it must be protected in some other manner (for example using encryption). If possible, FTP should be replaced by a secure protocol such as SCP.

In many cases, FTP is used to retrieve files from publicly accessible servers. If no authentication information is used for this purpose that is already in use on other systems (for example in the case of anonymous FTP), then this is not critical as long as there are no requirements placed on the integrity and authenticity of the data retrieved (for example when downloading informational material). If the integrity and authenticity of the data is important (for example when downloading software program packages, patches or important documents), then the provider should provide digital signatures that can be used to check the correctness of the data.

POP3 and IMAP

The POP3 (Post Office Protocol Version 3, specified in RFC 1939) and IMAP (Internet Message Access Protocol, specified in RFC 3501) protocols are used by e-mail clients to retrieve e-mails from an e-mail server (POP3) or to manage the e-mails on an e-mail server (IMAP).

The default ports for these protocols are port 110/TCP (POP3) and port 143/TCP (IMAP). Both protocols are plain text protocols and therefore should not be used in public networks. There are versions of both protocols in which the connections can be protected using encryption (SSL and TLS respectively): POP3s (default port 995/TCP) and IMAPs (default port 993/TCP).

Even when e-mails will only be retrieved from the internal network, it is recommended only to use secure POP3 or IMAP variants. If e-mails will be retrieved from an external POP3 or IMAP server (from an e-mail provider, for example), then it is essential to use secure versions of the protocols, and including interruption of the encrypted connection on a corresponding security proxy, if necessary.

Additional services

Distributed file systems

Distributed file systems, in which data is stored on a file server accessed over the network instead of locally on a computer, have been around for a long time now, and it is hard to imagine the IT landscape without them.

The most frequently encountered example is a drive-sharing option under Microsoft Windows. The protocol on which it is based is SMB / CIFS (Server Message Block / Common Internet File System). There is also an implementation of this protocol with SAMBA available for various derivatives of Unix.

In the Unix world, distributed file systems have been implemented using NFS (Network File System) for a long time now. There are also NFS implementations available for Windows. In addition, there is a range of other distributed file systems such as AFS.

Distributed file systems should not be used across security gateways if this is possible because it comes with a series of problems (security of the authentication procedure, security of the data transmitted) that make it difficult to use a distributed file system securely across a security gateway.

If access to a distributed file system is necessary in exceptional cases, then such access should be protected as a rule using a VPN solution.

Remote Desktop protocols (Windows Terminal Server, X Windows etc.)

Both Microsoft Windows and the X Windows system used to implement graphic interfaces in Unix offer options allowing individual windows or the entire desktop to be displayed on a remote computer.

A Remote Desktop protocol that does not offer any security functions or only offers weak security functions should only be used in the internal network in exceptional cases. In addition, the use of Remote Desktop protocols across the security gateway should be prohibited in general. If this is nevertheless necessary in exceptional cases, then it is absolutely essential to take additional safeguards, such as using a suitable VPN that provides a sufficiently secure connection.

Streaming protocols

There is a series of protocols for the transmission of multimedia data (audio and video streaming) with different characteristics in terms of the bandwidth and ports used. These protocols are usually a problem for security gateways, since they are sometimes hard to secure using packet filter rules. When in doubt, refrain from the use of streaming applications or provide such applications via separate Internet PCs (see module 3.208 Internet PCs).

Voice over IP

There are various solutions available that allow voice communications to be transmitted over IP networks (referred to as Voice over IP or VoIP). VoIP solutions normally require the use of several different protocols, for example different protocols for signalling and for transmitting the actual voice data.

VoIP solutions (for example those conforming to the H.323 standard) are often a problem for security gateways, since some of the ports used are negotiated dynamically by the terminal devices, which means that it is impossible to protect the connections using simple packet filters.

If a VoIP solution is to be used to allow communication over VoIP with people located outside of the organisation's own network, then a supplemental security analysis is required in every case to prevent the security of the network from being threatened by the requirements of the VoIP solution, because the settings of the security gateway need to be "opened" too wide.

NTP

The Network Time Protocol (NTP) specified in RFC 1305 is used to obtain an exact time signal from a time server.

If NTP is used for time synchronisation in the internal network by servers or components of the security gateway, then a separate time server should be used in the internal network or in the security gateway wherever possible. If necessary, it is also possible to use an NTP proxy that retrieves the time from the central time server and then acts as the time server for the computers in the internal network. See also S 4.227 Use of a local NTP server for time synchronisation.

NNTP

The Network News Transfer Protocol (NNTP) specified in RFC 977 is used to transmit news articles. A news server uses TCP port 119 by default. Like most other "early" Internet protocols, NNTP is also a plain text protocol.

If an internal news server is operated or the internal network will be provided with access to an external news server, then the security gateway must be able to prevent the transmission of certain news groups entirely or only allow them to be transmitted to certain computers. It must be ensured when posting news from the internal network that no information on the network being protected (e.g. the names of the computers) is sent into the external network.

"r-services"

The services referred to as "r-services" such as rlogin, rsh, rcp and others are based on UDP and do not offer any functionality for secure authentication or for securing the connection.

For this reason, these services should only be used in the internal network in exceptional cases. They should never be used across a security gateway. The security gateway should block all corresponding packets.

For most applications, SSH can be used as a full replacement for "r-services".

Note on the so-called "privileged ports"

When communicating via TCP/IP, a client process generally establishes a connection from a randomly generated port with a port number > 1023 to a server process with a port number < 1024 (well-known port). Ports numbered < 1024 are also referred to as privileged ports because, in Unix for example, they may only be used by processes with root authorisation.

However, restricting the use of the ports < 1024 to processes with root authorisation only is just a convention that can be bypassed and that becomes irrelevant in any case if an attacker gains control over a computer. For this reason, a security concept must not assume that all IT systems actually protect their privileged ports in this manner. Even FTP connections established using ports 20 or 21, for example, may not be considered secure connections.

Review questions:

© Federal Office for Information Security. All rights reserved.