S 2.75 Selection of a suitable application-level gateway

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: IT Security Officer, Administrator

In the application layer, the functions of a security gateway are assumed by application-level gateways (ALG). Implicitly, ALGs also perform functions in layers 1 to 3. ALGs are often referred to as "security proxies", but in this safeguard the term "proxy" will be used for short. Proxies are positioned in the network in such a way that they come between the source and destination, thus interrupting the direct flow of data between the two. When a client on one side of the proxy and a server on the other side of a proxy communicate, the proxy receives the requests from the client and forwards them to the server. Where the connection is established in the opposite direction, i.e. from the server to the client, the proxy does the same, but in the opposite direction. In this case, all communications between the two computers run directly through the proxy.

Some of the advantages and disadvantages of security proxies are summarised below:

Advantages of proxies

• Often they contain fewer programming errors than the client or server utility programs protected by the proxy.
• Filtering of individual protocol commands (e.g. the POST command in the case of HTTP) is possible, depending on the parameter settings for commands, time and user.
• Unwanted content is removed from the data transmitted.
• Protection is provided against attacks based on suspect header data.
• The sender address in a forwarded IP packet is replaced by the IP address of the network interface over which the packet leaves the proxy. As a result, the IP addresses of the trusted network are concealed. Moreover, only one IP address needs to be entered in the DNS.
• Strong authentication can be enforced.
• There are plenty of logging possibilities. Application-level logging is possible for every connection:
  • User identification
  • IP address of the source and destination computer
  • Port numbers
  • Time and date

Depending on the service, more extensive data can be logged (e.g. URL in the case of HTTP).

Disadvantages of proxies

• Maximum data throughput is reduced.
• It takes longer to retrieve information (longer latencies).

There may be restrictions on the functionality of client programs (e.g. through filtering of active content).

Proxies can function in two different modes of operation, transparent and non-transparent. A transparent proxy does not have to be communicated to the clients. It reads all the IP packets in the network and decides on the basis of IP address and port number which of them should be forwarded to another network. Where a non-transparent proxy is used, on the other hand, its IP address and port number have to be entered in the client software (e.g. the web browser) before a connection can pass through the proxy.

Before purchasing anything, it is necessary to check which of the requirements listed below the ALG will need to meet. Depending on the application context, it may be possible to dispense with some of the requirements.

The requirements listed must be evaluated in the context of the application. If one particular protocol is not used, then the ALG does not need to offer support for that protocol. If the ALG supports protocols that are not used, then it should be possible to deactivate the protocol concerned.

If it has been specified in the security gateway policy that one or more of the protocols listed below should not be allowed, then it goes without saying that they do not have to be supported.

The criteria used in the evaluation and the decisions made must be documented in a comprehensible manner.

General information

• Support for the most important protocols used (e.g. Telnet, FTP, SMTP, NNTP, HTTP, and HTTPS) in the application layer. Generic proxies for TCP and UDP should be available so that other services can be used.
• It should be possible for the application-level gateway proxies to be operated transparently.
• To enable several MTAs in different trusted networks to be operated, if necessary, it should be possible for a separate MTA to be integrated on the ALG.
• There should be an interface providing a link to external analysis programs that are used to search for malware (e.g. virus scanning programs).
• Communication with a directory service for authentication of the users should be supported.
• Filtering according to the criteria specified in S 2.76 Selection and implementation of suitable filter rules must be possible for every protocol supported. In particular, it must be possible to make the filter rules depend on the user and to bring several users together into one group.
• Filtering for content should be supported, so that central virus scanning and the blocking of active content are possible (see T 5.23 Malicious software and T 5.88 Abuse of active content).
• When an application-level gateway is used, no changes should be necessary to the software in the network requiring protection or in the external network.
• For every connection established and rejected in the application layer, the IP addresses of the source and destination computers, port numbers, time, date and the applicable rules should all be logged, and it should be possible to impose restrictions on particular connections.
• It should be possible to log the data volume transmitted.
• It should be possible to log the time at which the connection was set up and terminated.

Some more specific requirements for particular protocols that are commonly used are presented below:

HTTP:

• Filtering on the basis of request method, e.g. GET, HEAD, PUT or CONNECT
• Blocking of web pages and websites on the basis of URL
• Filtering on the basis of MIME type
• Removal of active content and cookies from web pages
• Filtering on the basis of HTTP header data
• Filtering of the following header fields should be possible:
  • Referrer
  • Via
  • From
  • Server

• Filtering of "web bugs"
• Enforcement of strong authentication on the proxy
• Accounting to determine the volume of data retrieved by a user
• Support for the signature verification of signed active content
• Logging of web pages retrieved
• Logging of the use of blocked request methods

HTTPS:

• Temporary decryption of data traffic so as to enable the removal of active content from web pages that are retrieved using HTTPS. Temporary decryption means that data transmitted is only decrypted after it has been filtered for active content, following which it is re-encrypted.
• Logging of web pages retrieved
• Notification of any expired or invalid certificates to the administrator during automatic update

SMTP:

• Removal of active content from HTML e-mails
• Filtering on the basis of MIME type
• Filtering on the basis of sender and recipient address
• Filtering on the basis of the IP address of the MTA
• Checking for e-mail relaying on the basis of domain name
• Checking that delivery of e-mail is feasible on the basis of domain name
• Removal of suspicious e-mail attachments on the basis of file suffix. It should be possible to freely specify attachments to be blocked.
• Detection of spam e-mail using a combination of different filtering methods
• It should be possible to handle detected spam e-mails as follows:
  • delete it
  • isolate it ("quarantine")
  • flag it

• Provision of an interface that enables a spam filter to be connected
• Blocking of (outgoing) e-mails on the basis of the detection of keywords
• Logging of sender's and recipient's e-mail addresses
• Logging of whether an e-mail has been forwarded successfully or not
• It should be possible to set up
  • a mail relay (i.e. forwarding by an MTA in the trusted network to an MTA in the non-trusted network)
  • a mail server (the possibility of retrieval with POP3 or IMAP and forwarding with SMTP)

FTP (passive and active):

• Filtering on the basis of FTP commands (e.g. GET, PUT, PASV, PORT)
• User-based release or blocking of FTP commands
• Restrictions on the basis of the file name (e.g. blocking of *.exe)
• Enforcement of strong authentication on the proxy
• Logging of the use of blocked request methods
• Logging of user name following authentication and of the file name

NNTP:

• Filtering on the basis of request method, e.g. ARTICLE, BODY, HEAD and STAT
• Logging of the use of blocked request methods
• Removal of active content and cookies from web pages
• Enforcement of strong authentication on the proxy
• Selective blocking of particular forums

Telnet:

• Enforcement of strong authentication on the proxy
• Logging of user name following authentication

POP:

• Filtering on the basis of request method, e.g. STAT, LIST, RETR or DELE
• Removal of active content and cookies from HTML e-mails
• Logging of the use of blocked request methods

UDP and TCP relays:

• Enforcement of strong authentication on the proxy
• Logging of user name following authentication

IP relay:

• The establishment of VPNs through the application-level gateway should be supported with IP relays.

DNS:

• Provision of an integrated solution consisting of public and private DNS servers
• Secure compartmentalisation of DNS proxy from the rest of the operating system of the ALG

Plaintext protocols like Telnet and FTP should if possible no longer be used in public networks, and should be replaced by more secure alternatives (SSH/SCP). Even on internal networks, they should only continue to be used if there are compelling reasons that prevent switching to SSH or another secure protocol.

If required and feasible, POP should continue to be used internally. If e-mails are retrieved from an external mail server (possibly with a provider), the variant "POP over SSL" is to be preferred. However, in this case an SSL proxy (analogous to the HTTPS proxy) that interrupts the encrypted connection on the security gateway and thus enables e-mails to be centrally scanned for viruses and other malicious content is required.

Review questions:

• Have the selection and evaluation of the requirements for the ALG been documented?
• Do the proxies used meet the requirements listed?