We are configuring a reverse proxy protecting access to the application and shielding the application server from the internet. In doing so, we\u2019ll become familiar with several configuration methods and will be working with ModRewrite for the first time.<\/p>\n
A modern application architecture has multiple layers. Only the reverse proxy is exposed to the internet. It conducts a security check on the HTTP payload and forwards the requests found to be good to the application server in the second layer. This in turn is connected to a database server located in yet another layer. This is referred to as a three-tier model. In a staggered defense spanning three levels, the reverse proxy or to be technically correct, the gateway server, provides the first look into the encrypted requests. On the way back it is in turn the last instance in which the responses can be checked one last time.<\/p>\n
There are a number of ways for converting an Apache server into a reverse proxy. More importantly, there are multiple ways of communicating with the application server. In this tutorial we will be restricting ourselves to the normal HTTP-based The following is a recommended set of requirements. You do not really need all of these, but if you follow them diligently, I am sure all the examples will work 1:1. If you take a short cut, it will probably need some tweaking with paths and predefined aliases.<\/p>\n The purpose of a reverse proxy is to shield an application server from direct internet access. As somewhat of a prerequisite for this tutorial, we\u2019ll be needing a backend server like this. In principle, any HTTP application can be used for such an installation and we could very well use the application server from the third tutorial. However, it seems appropriate for me to demonstrate a very simple approach. We\u2019ll be using the tool Using this complex command we instruct socat to bind a listener to local port 8000 and to use several echoes to return an HTTP response when a connection occurs. The additional parameters make sure that the listener stays permanently open and error output works.<\/p>\n We have set up a backend system with the simplest of means. So easy, that in the future we might come back to this method to verify that a proxy server is working before the real application server is running.<\/p>\n Several modules are required to use Apache as a proxy server. We compiled them in the first tutorial and can now simply link them.<\/p>\n The proxying feature set is provided by a basic proxy module and a proxy HTTP module. Proxying actually means receiving a request and forwarding it to another server. In our case we will be defining the backend system from the beginning and then accept requests from different clients for this backend service. It\u2019s a different situation if you set up a proxy server that accepts requests from a group of clients and sends then onward to any server on the internet. This is referred to as a forward proxy. This is useful for when you don\u2019t want to directly expose clients on a corporate network to the internet since the proxy server appears as a client to the servers on the internet.<\/p>\n This mode is also possible in Apache, even if for historical reasons. Alternative software packages offering these features have become well established, e.g.\u00a0squid. The case is relevant insofar as a faulty configuration may have fatal consequences, particularly if the forward proxy accepts requests from any client and sends them onward to the internet in anonymized form. This is referred to as an open proxy. It\u2019s essential to prevent this since we don\u2019t want to operate Apache in this mode. That requires a directive in the past used to reference the risky default This directive actually means forwarding requests to servers on the internet, even if the name indicates a general setting. As mentioned before, the directive is correctly set for Apache 2.4 and it is only being mentioned here to guard against questions or incorrect settings in the future.<\/p>\n This brings us to the actual proxying settings: There are many ways for instructing Apache to forward a request to a backend application. We\u2019ll be looking at each option in turn. The most common way of proxying requests is based on the ProxyPass directive. It is used as follows:<\/p>\n The most important directive is ProxyPass. It defines a On the next line comes a related directive that despite having a similar name performs only a small auxiliary function. Redirect responses from the backend are fully qualified in http-compliant form. Such as Continuing on in the configuration: now comes the Proxy block where the connection to the backend is more precisely defined. Specifically, this is where requests are authenticated and authorized. Further below in the tutorial we will also be adding a load balancer to this block.<\/p>\n The proxy block is similar to the location and the directory block we have previously become familiar with in our configuration. These are called containers. Containers specify to the web server how to structure the work. When a container appears in the configuration, it prepares a processing structure for it. In the case of The You often see configurations that forward the entire namespace below An essential directive which may optionally be part of the proxy concerns the timeout. We defined our own timeout value for our server. This timeout is also used by the server for the connection to the backend. But this is not always wise, because while we can expect from the client that it will quickly make its request and not take its sweet time, depending on the backend application, it can take a while until the response is processed. For a short, general timeout which is wise to have for the client for defensive reasons, the reverse proxy would interrupt access to the backend too quickly. For this reason, there is a ProxyTimeout directive which affects only the connection to the backend. By the way, time measurement is not the total processing time on the backend, but the duration of time between IP packets: When the backend sends part of the response the clock is reset.<\/p>\n Now comes time to fix the host header. Via the HTTP request host header the client specifies which of a server\u2019s VirtualHosts to use for the request. If there are multiple VirtualHosts being operated using the same IP address, this value is important. However, when forwarding the reverse proxy normally sets a new host header, specifically the one from the backend system. This is often undesired, because in many cases the backend system sets its links based on the host header. Fully qualified links for a backend application may be a bad practice, but we avoid conflicts if we make clear from the beginning that the host header should be preserved and forwarded as is by the backend.<\/p>\n Backend systems often pay less attention to security than a reverse proxy. Error messages are one place this is obvious. Detailed error messages are often desirable since they enable the developer or backend administrator to get at the root of the problem. But we don\u2019t want to distribute them over the internet, because without authentication on the reverse proxy an attacker could always be lurking behind the client. It\u2019s better to hide error messages from the backend application or to replace them with an error message from the reverse proxy. The In addition to the ModRewrite defines its own rewrite engine used to manipulate, or change, HTTP requests; This rewrite engine can run in the server or VirtualHost context. Strictly speaking, we are using two separate rewrite engines. The rewrite engine in the VirtualHost context can also be configured from the Proxy container that we learned about above. If we define a rewrite engine in the server context, then it could be shortcut if there is an engine in the VirtualHost context. In this case we have to manually ensure that the rewrite rules are being inherited. We are therefore setting up a rewrite engine in the server context, configuring an example rule and initiating the inheritance.<\/p>\n We initialize the engine on the server level. We then instruct the engine to pass on our rules to other rewrite engines. Specifically, so that our rules are performed before the rules further down. Then comes the actual rule. We tell the server to instruct the client to send a new request to Then appearing within square brackets come the flags influencing the behavior of the rewrite rule. As previously mentioned, we want a redirect and tell the engine that this is the last rule to process ( Let\u2019s have a look at a request like this and the redirect returned:<\/p>\nmod_proxy_http<\/code>. We will not be discussing other methods of communication such as FastCGI proxy or AJP here. There are also several ways of getting the proxy process going in Apache. We will start by looking at the normal setup using ProxyPass and will afterwards discuss other options using ModRewrite.<\/p>\nRequirements<\/h3>\n
\n
Step 1: Preparing the backend<\/h3>\n
socat<\/code> short for SOcket CAt.<\/p>\n<\/a>$><\/span> socat<\/span> -v -v TCP-LISTEN:8000,bind=127.0.0.1,crlf,reuseaddr,fork SYSTEM:"echo HTTP\/1.0 200;\\<\/span><\/span>\n<\/a>echo Content-Type\\: text\/plain; echo; echo 'Server response, port 8000.'"<\/span><\/span><\/code><\/pre><\/div>\n<\/a>$><\/span> curl<\/span> -v http:\/\/localhost:8000\/<\/span>\n<\/a>*<\/span> Hostname was NOT found in DNS cache<\/span>\n<\/a>*<\/span> Trying 127.0.0.1...<\/span>\n<\/a>*<\/span> Connected to localhost (127.0.0.1) port<\/span> 8000 (#0)<\/span>\n<\/a>><\/span> GET<\/span> \/ HTTP\/1.1<\/span>\n<\/a>><\/span> User-Agent<\/span>: curl\/7.35.0<\/span>\n<\/a>><\/span> Host<\/span>: localhost:8000<\/span>\n<\/a>><\/span> Accept<\/span>: *\/*<\/span>\n<\/a>><\/span> <\/span>\n<\/a>*<\/span> HTTP 1.0, assume close after body<\/span>\n<\/a><<\/span> HTTP\/1.0<\/span> 200<\/span>\n<\/a><<\/span> Content-Type<\/span>: text\/plain<\/span>\n<\/a><<\/span> <\/span>\n<\/a>Server<\/span> response, port 8000<\/span>\n<\/a>*<\/span> Closing connection 0<\/span><\/code><\/pre><\/div>\nStep 2: Enabling the proxy module<\/h3>\n
<\/a>LoadModule<\/span> proxy_module modules\/mod_proxy.so<\/span>\n<\/a>LoadModule<\/span> proxy_http_module modules\/mod_proxy_http.so<\/span><\/code><\/pre><\/div>\non<\/code> value, but is now correctly predefined as off<\/code>:<\/p>\n<\/a>ProxyRequests<\/span> Off<\/span><\/code><\/pre><\/div>\nStep 3: ProxyPass<\/h3>\n
<\/a>ProxyPass<\/span> \/service1 http:\/\/localhost:8000\/service1<\/span>\n<\/a>ProxyPassReverse<\/span> \/service1 http:\/\/localhost:8000\/service1<\/span>\n<\/a><\/span>\n<\/a><<\/span>Proxy<\/span> http:\/\/localhost:8000\/service1><\/span><\/span>\n<\/a><\/span>\n<\/a> Require<\/span> all granted<\/span>\n<\/a><\/span>\n<\/a> Options<\/span> None<\/span>\n<\/a><\/span>\n<\/a><<\/span>\/Proxy<\/span>><\/span><\/span><\/code><\/pre><\/div>\n\/service1<\/code> path and specifies how it is mapped to the backend: To the service defined above running on our own host, localhost, on port 8000. The path to the application server is again \/service1<\/code>. We are proxying symmetrically, because the frontend path is identical to the backend path. This mapping is however not absolutely required. Technically, it would be entirely possible to proxy service1<\/code> to \/<\/code>, but this results to administrative difficulties and misunderstandings, if a path in the application log file no longer maps to the path on the reverse proxy and the requests can no longer be correlated easily.<\/p>\nhttps:\/\/backend.example.com\/service1<\/code>, for example. The address is however not accessible by the client. For this reason, the reverse proxy has to rewrite the backend\u2019s location header, backend.example.com<\/code>, replacing it with its own name and thus mapping it back to its own namespace. ProxyPassReverse, with such a great name, only has a simple search and replace feature touching the location headers. As already seen in the ProxyPass directive, proxying is again symmetric: the paths are rewritten 1:1. We are free to ignore this rule, but I urgently recommend keeping it, because misunderstandings and confusion lie beyond. In addition to accessing location headers, there is a series of further reverse directives for handling things like cookies. They can be useful from case to case.<\/p>\nStep 4: Proxy stanza<\/h3>\n
mod_proxy<\/code> the backend can also be accessed without a Proxy container. However, access protection is not taken into account and other directives no longer have any place where it can be inserted. Without the Proxy block the processing of complex servers remains a bit haphazard and it would do us well to configure this part as well. Using the ProxySet directive, we could intervene even more here and specify things like the connection behavior. Min, max and smax can be used to specify the number of threads assigned to the proxy connection pool. This can impact performance from case to case. The keep-alive behavior of the proxy connection can be influenced and a variety of different timeouts defined for it. Additional information is available in the Apache Project documentation.<\/p>\nStep 5: Defining exceptions when proxying and making other settings<\/h3>\n
ProxyPass<\/code> directive we are using has forwarded all requests for \/service1<\/code> to the backend. However, in practice it is often the case that you don\u2019t want to forward everything. Let\u2019s suppose there\u2019s a path \/service1\/admin<\/code> that we don\u2019t want to expose to the internet. This can also be prevented by the appropriate ProxyPass<\/code> setting, where the exception is initiated by using an exclamation mark. What\u2019s important is to define the exception before configuring the actual proxy command:<\/p>\n<\/a>ProxyPass<\/span> \/service1\/admin !<\/span>\n<\/a>ProxyPass<\/span> \/service1 http:\/\/localhost:8000\/service1<\/span>\n<\/a>ProxyPassReverse<\/span> \/service1 http:\/\/localhost:8000\/service1<\/span><\/code><\/pre><\/div>\n\/<\/code> to the backend. Then a number of exceptions to the pattern above are often defined. I think this is the wrong approach and I prefer to forward only what is actually being processed. The advantage is obvious: scanners and automated attacks looking for their next victim from a pool of IP addresses on the internet make requests for a lot of non-existent paths on our server. We can now forward them to the backend and may overload the backend or even put it in danger. Or we can just drop these requests on the reverse proxy server. The latter is clearly preferable for security-related reasons.<\/p>\n<\/a>ProxyTimeout<\/span> 60<\/span><\/code><\/pre><\/div>\n<\/a>ProxyPreserveHost<\/span> On<\/span><\/code><\/pre><\/div>\nProxyErrorOverride<\/code> directive intervenes in the HTTP response body and replaces it if a status code greater than or equal to 400 is present. Requests with normal statuses below 400 are not affected by this directive.<\/p>\n<\/a>ProxyErrorOverride<\/span> On<\/span><\/code><\/pre><\/div>\nStep 6: ModRewrite<\/h3>\n
ProxyPass<\/code> directive, the Rewrite module can be used to enable reverse proxy features. Compared to ProxyPass, it enables more flexible configuration. We have not seen ModRewrite up to this point. Since this is a very important module, we should take a good look at it.<\/p>\n<\/a>LoadModule<\/span> rewrite_module modules\/mod_rewrite.so<\/span>\n<\/a><\/span>\n<\/a>...<\/span><\/span>\n<\/a><\/span>\n<\/a>RewriteEngine<\/span> On<\/span>\n<\/a>RewriteOptions<\/span> InheritDownBefore<\/span>\n<\/a><\/span>\n<\/a>RewriteRule<\/span> ^\/$ %{REQUEST_SCHEME}<\/span>:\/\/%{HTTP_HOST}<\/span>\/index.html [redirect,last]<\/span><\/code><\/pre><\/div>\n\/index.html<\/code> for a request without a path or a request for \u201c\/\u201d respectively. This is a redirect. What\u2019s important is for the redirect to indicate the schema of the request, http or https as well as the host name. Relatives paths won\u2019t work. But because we are outside the VirtualHost, we don\u2019t see the type. And we don\u2019t want to hard code the host name, but prefer to take the host names from client requests. Both of these values are available as variables as you can see in the example above.<\/p>\nlast<\/code>).<\/p>\n<\/a>$><\/span> curl<\/span> -v http:\/\/localhost\/<\/span>\n<\/a>*<\/span> Hostname was NOT found in DNS cache<\/span>\n<\/a>*<\/span> Trying 127.0.0.1...<\/span>\n<\/a>*<\/span> Connected to localhost (127.0.0.1) port<\/span> 80 (#0)<\/span>\n<\/a>><\/span> GET<\/span> \/ HTTP\/1.1<\/span>\n<\/a>><\/span> User-Agent<\/span>: curl\/7.35.0<\/span>\n<\/a>><\/span> Host<\/span>: localhost<\/span>\n<\/a>><\/span> Accept<\/span>: *\/*<\/span>\n<\/a>><\/span> <\/span>\n<\/a>