Some issues with forwarding the correct HTTP headers to the backend server

The Apache software Foundation's HTTP server project (often called Apache) is the WEB server that dominates today's internet, and it occupies more than 60% of its market share. Apache servers are part of the increasingly popular LAMP software configuration. LAMP is a free software program and is a WEB platform built on Linux, Apache, MySQL, and PHP, among other open source technologies. In this article, you will learn a way to improve LAMP security using the Mod_proxy module and multiple back-end servers. I'll discuss the pros and cons of this approach, and provide a sample configuration.

PHP and Apache: Security challenges

A challenge for LAMP administrators is to provide all the features of a full PHP system while ensuring a secure environment for all users of the system. Using PHP's security model is a technique to achieve this goal, but it also restricts users too much, and when this facility is enabled, some PHP applications do not work.

The root of the PHP security problem is the way most Apache servers are configured. Because most Apache configurations run under a special Www-data user ID, all users hosting the Web site must ensure that the user can read their files by default. Therefore, all other users on the system may access all Web-accessible files of a user, so a security vulnerability that is not related to you on the system can be a breach of your Web site. This can be more serious if the file or directory must be set to Www-data user writable.

By using CGI programs, such as those written in popular languages such as Perl and Python, you can eliminate some of the effects of this problem when using the suexec mechanism. Simply put, suEXEC uses a special intermediate program to execute a CGI program with the user ID of the program owner. This is a very effective mechanism that has been used for many years.

However, when using mod_php module hosting, the PHP page is executed as part of the Apache master process. Therefore, they inherit all the credentials of the Apache process, and any work they perform on the file system must be performed as Www-data users.

Run Apache under multiple user IDs

For the problem described above, the obvious solution is to require that all requests for a user domain come from an Apache instance that only has credentials for that user. Apache can be configured to obtain credentials for any user at startup. This approach solves the problem with a simple setting that assigns each user a separate Internet-visible IP address/port combination.

For more complex settings (where the IP address is valuable), this method is not valid. When a single Apache instance can control a specific IP address/port combination, only the virtual host is used, a technology that is widely used in the Apache system. This excludes the possibility of using the same IP address/port combination for multiple domains that belong to multiple users.

Apache 2.0 introduces the concept of a multi-processing module (multiprocessing module,mpm). In the MPM provided in the Basic Apache 2.0 package, there is an experimental module perchild, which can assign a distributor thread to an IP address/port combination and pass the request to a sub-thread running under a separate user's credentials to implement a virtual host under multiple user IDs. Unfortunately, Perchild is still experimental, it does not necessarily work, and it was removed from the official Apache release package when Apache 2.2 was released. Prior to that, the recognition of the need for a stable and functioning perchild-like Mpm,apache community began to develop many MPM to compensate for this deficiency. METUXMPM and process-oriented peruser are working in this direction.

One solution: Mod_proxy

Although no official Apache MPM can directly provide virtual hosts under multiple user IDs, this behavior can still be implemented in the Apache system through some configuration and management. The core concept of this approach is to use the Mod_proxy module, which, together with other features, enables Apache to forward a page request to another server and pass the response back to the client that originally made the request.

Listing 1. Sample reverse proxy configuration for basic request forwarding

Proxyrequests OFF
　
Proxypass/foo Http://foo.example.com/bar
Proxypassreverse/foo Http://foo.example.com/bar

The code in Listing 1 is a simple example that forwards a request for any page in a host's/foo hierarchy to the corresponding page of Http://foo.example.com/bar. For example, a request to a/foo/index.htm page is forwarded to http://foo.example.com/bar/index.htm. You can use this principle to solve a problem.

Sample Scenario

Let's consider a scenario in which the Apache administrator must establish two domains for two individual clients. A customer is an online startup and is concerned about online security. The other is a personal customer, who is lax on site security and may upload unsafe code to this site. Therefore, the Apache administrator must take steps to isolate the two sites.

Therefore, the administrator has two domains: Www.startup.tld, which belongs to the online startup enterprise (user ID startup), and Www.reckless.tld, which belongs to the individual (user ID Nimrod). To solve this problem, the administrator decides to use the Mod_proxy solution. The administrator gives each user a separate Apache instance that runs under the user's own user ID, uses a private IP address/port combination, and uses the Mod_proxy solution to provide access to the two users ' domains through a facade server as a www-d ATA runs, using a common IP address/port combination. Figure 1 illustrates the entire scenario.

Figure 1. Scenario Example

Recommended version of Apache

For each element in the sample application configuration, the Apache administrator should use the Apache version listed in table 1.

Table 1. Apache version used in the sample application

Elements Apache Version Reason
Facade Server Apache 2, running worker or event MPM Apache 2 has made significant improvements to the Mod_proxy module. Worker and event MPM are threaded to help reduce the memory overhead of the facade server.
The backend server Apache 1.3, or Apache 2 Apache administrator running Prefork MPM must be aware that the PHP module should not run in a inline environment. Both of these solutions provide a process-based environment for the PHP module.

Configuration of back-end Apache instances

The code snippet in Listing 2 and listing 3 illustrates the basic differences from the standard Apache configuration. They should be added to the appropriate configuration as needed, such as the PHP feature configuration that is ignored here.

Listing 2. Apache Configuration of online startup enterprise

# Stuff every Apache configuration needs
ServerType Standalone
Lockfile/var/lock/apache/accept.startup.lock
Pidfile/var/run/apache.startup.pid
　
ServerName Necessaryevil.startup.tld
DocumentRoot "/home/startup/web"
　
# Essential Modules
LoadModule access_module/usr/lib/apache/1.3/mod_access.so
　
# which user to run this Apache configuration as
User Startup
Group Startup
　
# This must is off else the host isn ' t passed correctly
Usecanonicalname OFF
　
# The Ip/port combination to listen on
Listen 127.0.0.2:10000
　
# Using name-based Virtual hosting allows you to host multiple sites per Ip/port combo
Namevirtualhost 127.0.0.2:10000
　
<virtualhost 127.0.0.2:10000>
ServerName Www.startup.tld
　
# can add aliases so long as the facade server is aware of them!
Serveralias Startup.tld
　
DocumentRoot "/home/startup/web/www.startup.tld"
　
<Directory/home/startup/web/www.startup.tld/>
Options Indexes followsymlinks multiviews execcgi includes
AllowOverride All
Order Allow,deny
Allow from all
</Directory>
　
</VirtualHost>

Listing 3. Apache Configuration for individual customers

# Stuff every Apache configuration needs
ServerType Standalone
Lockfile/var/lock/apache/accept.nimrod.lock
Pidfile/var/run/apache.nimrod.pid
　
ServerName Necessaryevil.nimrod.tld
DocumentRoot "/home/nimrod/web"
　
# Essential Modules
LoadModule access_module/usr/lib/apache/1.3/mod_access.so
　
# which user to run this Apache configuration as
User Nimrod
Group Nimrod
　
# This must is off else the host isn ' t passed correctly
Usecanonicalname OFF
　
# The Ip/port combination to listen on
Listen 127.0.0.2:10001
　
# Using name-based Virtual hosting allows you to host multiple sites per Ip/port combo
Namevirtualhost 127.0.0.2:10001
　
<virtualhost 127.0.0.2:10001>
ServerName Www.reckless.tld
　
# can add aliases so long as the facade server is aware of them!
Serveralias Reckless.tld
　
DocumentRoot "/home/nimrod/web/www.reckless.tld"
　
<Directory/home/nimrod/web/www.reckless.tld/>
Options Indexes followsymlinks multiviews execcgi includes
AllowOverride All
Order Allow,deny
Allow from all
</Directory>
　
</VirtualHost>

Listing 4 illustrates the configuration of the façade Apache instance.

Listing 4. Apache configuration for façade Apache instances

# Stuff every Apache configuration needs
Lockfile/var/lock/apache/accept.www-data.lock
Pidfile/var/run/apache.www-data.pid
　
ServerName Necessaryevil.facade.server
DocumentRoot "/home/www-data"
　
# Essential Modules
LoadModule proxy_module/usr/lib/apache2/modules/mod_proxy.so
LoadModule proxy_http_module/usr/lib/apache2/modules/mod_proxy_http.so
　
# which user to run this Apache configuration as
User Www-data
Group Www-data
　
# These must be set else the host isn ' t passed correctly
Usecanonicalname OFF
Proxyvia on
Proxyrequests OFF
# This must also is set, though it's only a option in Apache2
Proxypreservehost on
　
# The Ip/port combination to listen on
Listen 9.20.1.1:80
　
# Using name-based Virtual hosting allows you to host multiple sites per Ip/port combo
Namevirtualhost 9.20.1.1:80
　
# Configuration to forward requests for STARTUP.TLD
<virtualhost 9.20.1.1:80> 2881064151
ServerName Www.startup.tld
Serveralias Startup.tld
　
Proxypass/http://127.0.0.2:10000/
Proxypassreverse/http://127.0.0.2:10000/
Proxypassreverse/http://www.startup.tld:10000/
Proxypassreverse/http://startup.tld:10000/
</VirtualHost>
　
# Configuration to forward requests for RECKLESS.TLD
<virtualhost 9.20.1.1:80>
ServerName Www.reckless.tld
Serveralias Reckless.tld
　
proxypass/http://127.0.0.2:10001/
proxypassreverse/http://127.0.0.2:10001/
proxypassreverse/http://www.reckless.tld:10001/
proxypassreverse/http://reckless.tld:10001/
</VirtualHost>

Be sure to pay attention to the proxypreservehost instructions here. This command is provided by Apache 2, which solves some problems in forwarding the correct HTTP headers to the backend server. Therefore, it is highly recommended to use the Apache 2 instance as the facade server.

Run the sample configuration

The root user should run each configuration. Apache obtains the privileges specified in the configuration file and uses it for all host-related processes. Listing 5 shows how to run the sample.

Listing 5. Start the sample server

/usr/sbin/apache-f/etc/apache/startup.tld.conf
/usr/sbin/apache-f/etc/apache/nimrod.tld.conf
/usr/sbin/apache2-f/etc/apache2/facade.tld.conf

Limitations of the Mod_proxy method

It is important to note that the methods described in this article do not apply to domains that require SSL connections. This is because the SSL protocol does not allow the domain's virtual hosts. Due to this limitation, any SSL host must be executed in an appropriate manner so that each SSL domain uses its own ip/port combination. This restriction exists for all Apache configurations, and Apache with this solution is no exception. You can still run the SSL domain under the user ID of their owner.

Some issues with forwarding the correct HTTP headers to the backend server