S 5.115 Integration of a web server into a security gateway
Initiation responsibility: Head of IT, IT Security Officer
Implementation responsibility: IT Security Officer, Administrator
Integrating a web server into a security gateway is in many cases critical, since a web server often has high requirements regarding the network bandwidth. Along with ensuring the availability, selecting the proper server placement variant is also important in order to provide for protection against targeted attacks, since web servers are particularly exposed to attacks due to their high "visibility" and web server programs have often contained security gaps in the past.
This document describes three scenarios of how a web server may be integrated into a security gateway:
- Integration without using a reverse proxy.
- Integration using a reverse proxy intended to reduce the utilisation of the web server.
- Integration using a reverse proxy and with additional protection provided by another packet filter.
In all three cases, the server is not installed downstream of an ALG, but only downstream of a packet filter, since the effects of the ALG on the total throughput of the system may be too significant. Therefore, the recommendations are only applicable if only a simple security gateway is used (consisting of only one packet filter). The web server must not be located in the internal network.
In the event of particular security requirements, it may nevertheless be necessary to secure the web server with a separate ALG protecting the web server and web applications executed thereon against certain types of attacks (cross-site scripting, command injection, and such like). There are different ALGs from different providers. For more complex web applications, the use of such an ALG is recommendable.
Web servers without using a reverse proxy
If there are no specific requirements regarding the security of the web server and if the server is able to manage the incoming queries without any problems, it is recommendable to locate the web server in a separate DMZ of the external packet filter.
By means of corresponding packet filter rules it should be ensured that the web server is protected as far as possible against attacks from the outside. Additionally, additional filter rules should be used in order to ensure that an attacker may cause as little additional damage as possible even after having successfully compromised the web server. The following table contains the recommendations.
| Source | Destination | Decision | Notes |
|---|---|---|---|
| General information | |||
| Web servers | External network and internal network | Only permit packages belonging to a connection initiated by the other computer | The web server only answers queries. There is no need to establish separate connections. |
| Communication of the web server with the internet | |||
| External network | Web server port 80 | Permit | Port 80 is the default port |
| External network | Other ports of the web server | Prohibit | |
| Communication of the web server with the internal network | |||
| Internal network | Web server port 80 | Permit | Use of the web server also from the internal network |
| Internal network (possibly restriction to administration network) | Web server port 22 (SSH) | Permit | Administration and data transmission are performed via SSH and SCP |
| Internal network | Other ports of the web server | Prohibit | |
| Logs | |||
| Web servers | Log host UDP port 514 | Permit | Transmission of the logged data to the log host |
Here, it is assumed that the web server is administered from the internal network using an SSH connection and that the WWW data is transmitted to the web server using SCP. Furthermore, it is assumed that no DNS is used on the web server. Name resolution is not required for normal operations. This may be performed at a later point in time for creation of the access statistics and other analyses. The logged data accruing on the web server is sent to a separate log host using the network (see also S 4.225 Use of a logging server on a security gateway).
Due to the fact that no connections initiated by the web server are permitted, an attacker who compromised the web server may be decisively impaired, for example. Usually, an attacker requires further tools he/she loads subsequently from external computers upon intrusion in order to continue the attack. If this is not possible or significantly more difficult due to the corresponding packet filter rules, less skilful or less determined attackers (for example Script Kiddies) may even cancel their attack.
If the web server is administered differently or if the WWW data is transmitted differently to the web server, corresponding filter rules should be implemented for the protocols used respectively.
Web servers using a reverse proxy
In the first scenario, the web server carries the entire load caused by incoming queries. If the web server is relieved from incoming queries, a reverse proxy answering frequently repeated queries from its cache and thereby reducing the load of the web server may be used.
In order to achieve the highest possible throughput, it is necessary to locate the web server and the reverse proxy in the same DMZ. Access from the untrustworthy network should only be permitted to the reverse proxy; any direct access to the web server from the untrustworthy network should be prevented by the outer packet filter.
Web server and reverse proxy in separate DMZs
Reverse proxies were usually not developed with the primary focus on security. Therefore, it should possibly be considered to separate the reverse proxy from the web server by an additional packet filter. This increases the security for the web server, but on the other hand may also result in a reduction of the available bandwidth.
In this way, undesired accesses from the reserve proxy to the web server (e.g. to administration ports) can be prevented in the event of the reserve proxy being compromised. This solution is shown in the following figure.
Figure: Integration of a web server using a (reverse) caching proxy and an additional packet filter for additionally protecting the web server
This solution is equivalent to locating the reverse proxy and the web server in different DMZs of the outer packet filter. Whether the additional filter level is to be used must be considered in the specific application scenario.
Review questions:
- Are the incoming and outgoing connections of the web server limited to the required extent by corresponding packet filter rules?
- With regard to web servers using a reverse proxy: Has the reverse proxy been installed in the same DMZ as the web server if high data throughput is required?
- With regard to web servers using a reverse proxy: Is direct access to the web server from the untrustworthy network prevented by an outer packet filter?
- With regard to web server and reverse proxy in separate DMZs: Is the reverse proxy separated from the web server by an additional packet filter?