S 4.222 Correct configuration of security proxies

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: Administrator

This safeguard constitutes a compilation of recommendations regarding the default settings of the most important security proxies. However, the suggested settings may limit the functionality of the contents concerned (e.g. websites may no longer be opened due to the missing JavaScript) and must therefore be adapted to the individual needs.

HTTP

Filtering active content in websites is a central item for the security of the clients (see also S 4.100 Security gateways and active content). For clients with high protection requirements regarding confidentiality, active content in websites should be filtered out as a matter of principle. If required, active content may be permitted for trustworthy websites on a case-by-case basis (white list strategy). However, the corresponding white list must not become too comprehensive and must be checked and maintained at regular intervals.

The following advanced settings are recommended for HTTP proxies:

• blocking the HTTPS traffic if no HTTPS proxy is used,
• complete blocking of cookies (possible approval of individual websites),
• filtering and/or replacement of the browser ID,
• filtering of the following information from the request HTTP header:
  • Referrer (if a domain is left when surfing),
  • Via
  • From
• filtering of the following information from the response HTTP header:
  • Server
• approval of all URLs in principle. If required, blocking of individual, critical URLs, and
• limitation to necessary MIME types.
  
  Note: The white list strategy "block everything not expressly permitted" may only be poorly applied to blocking and/or approving MIME types. Due to the large number of MIME types used by websites, it is very difficult to block the relevant types and to simultaneously maintain the functionality of the WWW service at least in some degree. Blocking particularly critical MIME types constitutes a pragmatic approach. In order to achieve high levels of protection, such a white list must be constantly updated by the administrator, however.

HTTPS

Regarding the process of filtering malicious programs, the same procedure as for the HTTP proxy should be applied.

An HTTPS proxy is the central decision-making instance for the acceptance of certificates and largely takes over the control of the certificates from the users. For this reason, the settings of the HTTPS proxies are particularly important in terms of the approach regarding "problematic" certificates. The following table contains suggested settings for different cases:

Decision	Suggested setting
Acceptance of certificates issued by a certificate authority.	The certificate authorities listed in commonly used browsers are trustworthy. Here, it is assumed that the trustworthiness of the certificate authorities was checked by the browser manufacturer.Nevertheless, it should be regularly checked whether all certificate authorities are still trustworthy.If required, additional certificate authorities may be added. However, this must only be performed after having carefully checked the trustworthiness of the certificate authority.
Acceptance of certificates not issued by a certificate authority (self-signed certificates").	Self-signed certificates are exclusively intended for encryption purposes and do not offer any functions for securing the authenticity of a website.Such certificates should only be accepted in exceptional cases upon explicit examination.
Tunnelling of websites (i.e. these are characterised by end-to-end encryption).	Tunnelling bypasses the process of filtering for malicious programs. Therefore, tunnelling should only be permitted as an exception if the other party is particularly trustworthy.
Acceptance of certificates where the "common name" of the certificate does not match the retrieved URL.	If the common name of the certificate and the URL do not match, this is indicative of a manipulation in principle.Such certificates should not be accepted as a matter of principle.
Acceptance of certificates despite elapsed period of validity.	Trustworthy websites are well administered and always have a valid certificate.Therefore, certificates with elapsed period of validity should not be accepted as a matter of principle.

Table: Suggested settings

SMTP

S 4.100 Security gateways and active content should also be taken into consideration in connection with SMTP (i.e. the email service).

Spam filters are integrated into different security proxies. However, the capabilities of these filters often fall short of the functionality of dedicated spam filters (i.e. stand-alone components). Consequently, integrating a dedicated spam filter into the security gateway often allows more efficient email filtering.

Currently, there are no procedures with the capability of differentiating "useful" emails from spam emails with certainty. Therefore, it is only recommendable to use a spam email filter if the list of deleted emails is habitually (as a rule, daily) checked by an employee for emails deleted accidentally (false positives).

Suggestions regarding the configuration and operation of the spam filter:

• The spam filter should not return blocked emails to the sender and/or issue any messages regarding the fact that emails were blocked, since the spam sender will obtain additional information about the existence of the addressees in this case.
• Automatically deleting emails may be problematic for different reasons (amongst other things, legal reasons). Therefore, the spam filter should not automatically delete any emails, but instead mark the emails with a note stating that the email is presumably a spam email. Based on this note, the mail client and/or the user him/herself may sort the emails to different mailboxes or directories.
• The spam filter should be taken care of by employees working in the organisation. If filtering is purchased as a service, this may result in legal problems (regarding data protection).
• Before using spam filters, a comprehensive legal admissibility check should be performed on a case-by-case basis. The general legal situation for the use of spam filters is currently still unclear. Moreover, the introduction of spam filters should be coordinated with the Management and the Supervisory Board.
• Appliances for spam filtering may reduce the time required for installation. These products often offer comprehensive update options for improving the rate of detection.
• For incoming emails, it should be checked whether servers of the trustworthy networks are misused as email relay. In this connection, the incoming emails are checked as to whether the recipient's domain belongs to the trustworthy network. For outgoing emails, the sender's domain should belong to the trustworthy network.
• Outgoing emails should also be checked. This way, the damage can be contained if a client in the internal network is infected with an email worm despite all security safeguards. Moreover, an infection can often also be discovered immediately.
• Conspicuous email addresses should be blocked.

If no spam filter is integrated into the security gateway, the employees should be trained as to how to securely handle spam emails. Notes to the employees may include:

• delete spam emails without reading them,
• do not use the unsubscribe function of spam emails,
• consult the sender of "dubious" emails before opening the emails, if the sender is known, and
• some providers request to provide them with particularly conspicuous and/or dangerous spam emails. In exceptional cases, notifying the provider may also make sense.

Filtering file extensions

The following file extensions are not required in the majority of work environments and may be filtered (ordered according to the type of basic threat):

Access to the entire system:

• * .bat (DOS batch file)
• * .vbx (Visual Basic file)
• * .com (Windows application)
• * .hta (HTML applications)
• * .inf (installations script)
• * .js (Jscript file)
• * .jse (encoded Jscript file)
• * .wsh (Windows Scripting Host script)
• * .vbs (Visual Basic file)
• * .vbe (encoded Visual Basic file)

Execution of any applications:

• * .lnk (Link file)
• * .chm (compiled HTML file)
• * .pif (program information file)
• * .rm (RealMedia file)

Further problems:

• * .mdb (Access database. May contain macro viruses.)
• * .reg (Registry file. May perform changes to the registry.)

This list is inevitably incomplete. There are many other file types that can be used to compromise a terminal device that are sometimes absolutely required for the workflow (e.g. .html, .xls, .pdf). Filtering files only based on file extensions or MIME types alone may not provide sufficient levels of security, since files with malicious programs are often equipped with harmless extensions and executed anyway.

Telnet

Telnet should only be used in exceptional cases and be replaced by a more secure protocol if possible, for example SSH. If it is nevertheless absolutely necessary to use TELNET, the ALG or the packet filter must be used in order to limit the permitted connections to the minimum extent.

FTP

Similarly to Telnet, FTP should also only be used in exceptional cases and the permitted connections must also be limited to the minimum extent with the help of corresponding filter rules or access control lists.

The following protocols should be filtered:

• PORT (filtering prevents active FTP)

POP3

For POP3, S 4.100 Security gateways and active content should be taken into account.

Review questions:

• Have the settings of the security proxies regarding the use of the different protocols been adapted to the needs of the organisation?
• Is SMTP used by integrating a dedicated spam filter into the security gateway?
• Are file extensions filtered by the security gateway?
• Have the security safeguards implemented for using proxies and filtering file extensions been documented comprehensibly?