There is no point in implementing a reverse proxy to servers that do not work themselves, it just adds an additional layer to debug. The aim is to have Apache httpd serving SSL on only port 8443 on acting as a reverse proxy to. No other ports will be served by Apache httpd. May 01, 2020 You can configure Apache HTTP Server as a reverse proxy for Rational DOORS Web Access. A reverse proxy server provides another layer of security, protects HTTP servers in the network, and improves the performance of Secure Sockets Layer (SSL) requests. With a reverse proxy, you can change your deployment topology later. Trying to configure my reverse proxy with basic authentication before forward the traffic to my back end server. Can any one give me a solution. Example here: User(internet) - reverse proxy / vhosts server (need to add basic authentication here ) - back end server ( non authenticated ). What is Reverse proxy and how Apache reverse proxy works how to configure and setup apache reverse proxy. Why Reverse proxy is being used. How to setup Reverse proxy with Load balancing and failover, modproxy balancer example, Apache Reverse proxy example with sample httpd.conf file and virtual host configuration file. This page describes how to integrate Apache HTTP Server (also referred to as httpd) with Jira, utilizing modproxyajp so that Apache operates as a reverse-proxy. AJP is a wire protocol and is an optimized version of the HTTP protocol to allow a standalone web server such as Apache to talk to Tomcat.

In 2003, Nick Kew released a new module that complements Apache'smod_proxy and is essential for reverse-proxying. Since then he getsregular questions and requests for help on proxying with Apache. Inthis article he attempts to give a comprehensive overview of theproxying and mod_proxy_html

This article was originally published at ApacheWeek in January 2004,and moved to ApacheTutor with minor updates in October 2006.

Web Proxies

A proxy server is a gateway for users to the Web at large. Usersconfigure the proxy in their browser settings, and all HTTP requestsare routed via the proxy. Proxies are typically operated by ISPs andnetwork administrators, and serve several purposes: for example,

• to speed access to the Web by caching pages fetched, so that popular pages don't have to be re-fetched for every user who views them.
• to enable controlled access to the web for users behind a firewall.
• to filter or transform web content.

Reverse Proxies

A reverse proxy is a gateway for servers, and enables one web serverto provide content from another transparently. As with a standardproxy, a reverse proxy may serve to improve performance of the web bycaching; this is a simple way to mirror a website. But the most commonreason to run a reverse proxy is to enable controlled access from theWeb at large to servers behind a firewall.

The proxied server may be a webserver itself, or it may be anapplication server using a different protocol, or an applicationserver with just rudimentary HTTP that needs to be shielded fromthe web at large. Since 2004, reverse proxying has been the preferredmethod of deploying JAVA/Tomcat applications on the Web, replacingthe old mod_jk (itself a special-purpose reverse proxy module).

Proxying with Apache

The standard Apache module mod_proxy supports both types of proxyoperation. Under Apache 1.x, mod_proxy only supported HTTP/1.0, butfrom Apache 2.0, it supports HTTP/1.1. This distinction isparticularly important in a proxy, because one of the most significantchanges between the two protocol versions is that HTTP/1.1 introducesrich new cache control mechanisms.

This article deals with running a reverse proxy with Apache 2. Usersof earlier versions of Apache are encouraged to upgrade and takeadvantage of the altogether richer architecture and improvedapplication support. At the time of writing, the reason most commonlycited for not upgrading is difficulties running PHP on Apache 2. Icannot speak from personal experience, but several well-informedsources tell me the difficulty lies with non-thread-safe code in PHP,and that it works well with Apache 2 if it is built with thenon-threaded Prefork MPM.

The Apache Proxy Modules

So far, we have spoken loosely of mod_proxy. However, it's a littlemore complicated than that. In keeping with Apache's modulararchitecture, mod_proxy is itself modular, and a typical proxy serverwill need to enable several modules. Those relevant to proxying andthis article include:

• mod_proxy: The core module deals with proxy infrastructure and configuration and managing a proxy request.
• mod_proxy_http: This handles fetching documents with HTTP and HTTPS.
• mod_proxy_ftp: This handles fetching documents with FTP.
• mod_proxy_connect: This handles the CONNECT method for secure (SSL) tunneling.
• mod_proxy_ajp: This handles the AJP protocol for Tomcat and similar backend servers.
• mod_proxy_balancer implements clustering and load-balancing over multiple backends.
• mod_cache, mod_disk_cache, mod_mem_cache: These deal with managing a document cache. To enable caching requires mod_cache and one or both of disk_cache and mem_cache.
• mod_proxy_html: This rewrites HTML links into a proxy's address space.
• mod_headers: This modifies HTTP request and response headers.
• mod_deflate: Negotiates compression with clients and backends.

Having mentioned the modules, I'm going to ignore caching for theremainder of this article. You may want to add it if you are concernedabout the load on your network or origin servers, but the details areoutside the scope of this article. I'm also going to ignore allnon-HTTP protocols, and load balancing.

Building Apache for Proxying

With the exception of mod_proxy_html, the above are all included inthe core Apache distribution. They can easily be enabled in the Apachebuild process. For example:

Of course, you may want other build options too, and you could just aswell build the modules as static.

If you are adding proxying to an existing installation, you should useapxs instead:

This leaves mod_proxy_html, which is not included in the coredistribution. mod_proxy_html is a third-party module, and requires athird-party library libxml2. At the time of writing, libxml2 isinstalled as standard or packaged for most operating systems. If youdon't have it, you can download it from xmlsoft.org and install ityourself. For the purposes of this article, we'll assume libxml2 isinstalled as /usr/lib/libxml2.so, with headers in/usr/include/libxml2/libxml/.

1. Check libxml2 is installed. If you have a version older than 2.5.10, then upgrade - there's a bug in earlier versions that can, in some particular cases, severely affect performance.
2. Download mod_proxy_html.c from http://apache.webthing.com/
3. Build mod_proxy_html with apxs:

A Reverse Proxy Scenario

Company example.com has a website at www.example.com, which has apublic IP address and DNS entry, and can be accessed from anywhereon the Internet.

The company also has a couple of application servers which haveprivate IP addresses and unregistered DNS entries, and are inside thefirewall. The application servers are visible within the network -including the webserver, as 'internal1.example.com' and'internal2.example.com', But because they have no public DNS entries,anyone looking at internal1.example.com from outside the companynetwork will get a 'no such host' error.

A decision is taken to enable Web access to the application servers.But they should not be exposed to the Internet directly, instead theyshould be integrated with the webserver, so thathttp://www.example.com/app1/any-path-here is mapped internally tohttp://internal1.example.com/any-path-here andhttp://www.example.com/app2/other-path-here is mapped internally tohttp://internal2.example.com/other-path-here. This is a typicalreverse-proxy situation.

Configuring the Proxy

As with any modules, the first thing to do is to load them inhttpd.conf (this is not necessary if we build them statically intoApache).

For windows users this is slightly different: you'll need to loadlibxml2.dll rather than libxml2.so, and you'll probably need toload iconv.dll and xlib.dll as prerequisites to libxml2 (youcan download them from zlatkovic.com, the same site thatmaintains windows binaries of libxml2). The LoadFile directive is the same.

Of course, you may not need all the modules. Two that are not requiredin our typical scenario are shown commented out above.

Having loaded the modules, we can now configure the Proxy. But beforedoing so, we have an important security warning:

Do Not set 'ProxyRequests On'. Setting ProxyRequests On turns yourserver into an Open Proxy. There are 'bots scanning the Web for openproxies. When they find you, they'll start using you to route aroundblocks and filters to access questionable or illegal material. Atworst, they might be able to route email spam through your proxy. Yourlegitimate traffic will be swamped, and you'll find your servergetting blocked by things like family filters.

Of course, you may also want to run a forward proxy withappropriate security measures, but that lies outside the scope of thisarticle. The author runs both forward and reverse proxies on the sameserver (but under different Virtual Hosts).

The fundamental configuration directive to set up a reverse proxy isProxyPass. We use it to set up proxy rules for each of the applicationservers:

Now as soon as Apache re-reads the configuration (the recommended wayto do this is with 'apachectl graceful'), proxy requests will work, sohttp://www.example.com/app1/some-path maps tohttp://internal1.example.com/some-path as required.

However, this is not the whole story. ProxyPass just sends trafficstraight through. So when the application servers generate referencesto themselves (or to other internal addresses), they will be passedstraight through to the outside world, where they won't work.

For example, an HTTP redirection often takes place when a user (orauthor) forgets a trailing slash in a URL. So the response to arequest for http://www.example.com/app1/foo proxies tohttp://internal.example.com/foo which generates a response:

But from the outside world, the net effect of this is a 'No such host'error. The proxy needs to re-map the Location header to its ownaddress space and return a valid URL

The command to enable such rewrites in the HTTP Headers isProxyPassReverse. The Apache documentation suggests the form:

However, there is a slightly more complex alternative form that Irecommend as more robust:

The reason for recommending this is that a problem arises with someapplication servers. Suppose for example we have a redirect:

This is a violation of the HTTP protocol and so should never happen:HTTP only permits full URLs in Location headers. However, it is also asource of much confusion, not least because the CGI spec has a similarLocation header with different semantics where relative paths areallowed. There are a lot of broken servers out there! In thisinstance, the first form of ProxyPassReverse will return the incorrectresponse

which, even allowing for error-correcting browsers, is outside theProxy's address space and won't work. The second form fixes this to

which is still broken, but will at least work in error-correctingbrowsers. Most browsers will deal with this.

If your backend server uses cookies, you may also need theProxyPassReverseCookiePath and ProxyPassReverseCookieDomaindirectives. These are similar to ProxyPassReverse, but deal with thedifferent form of cookie headers. These require mod_proxy fromApache 2.2 (recommended), or a patched version of 2.0.

Fixing HTML Links

As we have seen, ProxyPassReverse remaps URLs in the HTTP headers toensure they work from outside the company network. There is, however,a separate problem when links appear in HTML pages served. Considerthe following cases:

1. This link will be resolved by the browser and will work correctly.
2. This link will be resolved by the browser to http://www.example.com/otherfile.html, which is incorrect.
3. This link will resolve to 'no such host' for the browser.

The same problem of course applies to included content such as images,stylesheets, scripts or applets, and other contexts where URLs occurin HTML.

To fix this requires us to parse the HTML and rewrite the links. Thisis the purpose of mod_proxy_html. It works as an output filter,parsing the HTML and rewriting links as it is served. Twoconfiguration directives are required to set it up:

• SetOutputFilter proxy-html This simply inserts the filter, to enable ProxyHTMLURLMap
• ProxyHTMLURLMap from-pattern to-pattern [flags] In its basic form, this has a similar purpose and semantics to ProxyPassReverse. Additionally, an extended form is available to enable search-and-replace rewriting of URLs within Scripts and Stylesheets.

How it works

mod_proxy_html is based on a SAX parser: specifically the HTMLparsermodule from libxml2 running in SAX mode (any other parse mode would ofcourse be very much slower, especially for larger documents). It hasfull knowledge of all URI attributes that can occur in HTML 4 andXHTML 1. Whenever a URL is encountered, it is matched againstapplicable ProxyHTMLURLMap directives. If it starts with anyfrom-pattern, that will be rewritten to the to-pattern. Rules areapplied in the reverse order to their appearance in httpd.conf, andmatching stops as soon as a match is found.

Here's how we set up a reverse proxy for HTML. Firstly, full links tothe internal servers should be rewritten regardless of where theyarise, so we have:

Note that in this instance we omitted the 'trailing' slash. Since thematching logic is starts-with, we use the minimal matching pattern. Wehave now globally fixed case 3 above.

Case 2 above requires a little more care. Because the link doesn'tinclude the hostname, the rewrite rule must be context-sensitive. Aswith ProxyPassReverse above, we deal with that using<location>

Debugging your Proxy Configuration

The above is a simple case taken from mod_proxy_html version 1. Withthe more complex URLmapping and rewriting enabled by Version 2, youmay need a bit of help setting up a complex ruleset, perhaps involvinga series of complex regexps, chained anc blocking rules, etc. To helpwith setting up and troubleshooting your rulesets, mod_proxy_html 2provides a 'debug' mode, in which all the 'interesting' things it doesare written to the Apache error log. To analyse and fix your rulesets,set

Now run your testcases through your rulesets, and examine the apacheerror log for details of exactly how it was processed.

Do not leave ProxyHTMLLogVerbose On for normal use. Although theeffect is marginal, it is an overhead.

Extended URL Mapping

The previous section sets up remapping of HTML URLs, but leaves anyURL encountered in a Stylesheet or Script untouched. mod_proxy_htmldoesn't parse Javascript or CSS, so dealing with URLs in them requirestext-based search-and-replace. This is enabled by the directiveProxyHTMLExtended On.

Because the extended mode is text-based, it can no longer guarantee tomatch exact URLs. It's up to you to devise matching rules that canpick out URLs, just as if you were writing an old-fashioned Perl orPHP regexp-based filter (though of course it's still massively moreefficient than performing search-and-replace on an entire documentin-memory). To help with this, ProxyHTMLExtended supports both simpletext-based and regular expression search-and-replace, according to theflags. You can also use the flags to specify rules separately for HTMLlinks, scripting events, and embedded scripts and stylesheets.

A second key consideration with extended URL mapping is that whereasan HTML link contains exactly one URL, a script or stylesheet maycontain many. So instead of stopping after a successful match, theprocessor will apply all applicable mapping rules. This can be stoppedwith the L (last) flag.

Dealing with multimedia content

We just set up a proxy to parse and where necessary correct HTML. Butof course, the web isn't just HTML. Surely feeding non-HTML contentthrough an HTML parser is at best inefficient, if not totally broken?

Yes indeed. mod_proxy_html deals with that by checking theContent-Type header, and removing itself from the processing chainwhen a document is not HTML (text/html) or XHTML(application/xhtml+xml). This happens in the filter initialisationphase, before any data are processed by the filter.

But that still leaves a problem. Consider compressed HTML:

Feeding that into an HTML parser is clearly broken!

There are two solutions to this. One is to uncompress the incomingdata with mod_deflate.Uncompressing and compressing content radically reduces networktraffic, but increases the processor load on the proxy. It isworthwhile if and only if bandwidth between the proxy and thebackend is at a premium: this is common on the 'net at large,but unlikely to be the case on a company internal network.

The alternative solution is to refuse to supportcompression. Stripping any Accept-Encoding request header does thejob. So invoking mod_headers, we add a directive

This should only apply to the Proxy, so we put it inside our <location> containers.

A similar situation arises in the case of encrypted (https) content.But in this case, there is no such workaround: if we could decrypt thedata to process it then so could any other man-in-the-middle, and thesecurity would be worthless. This can only be circumvented byinstalling mod_ssl and a certificate on the proxy, so that the actualsecure session is between the browser and the proxy, not the originserver.

The Complete Configuration

We are now in a position to write a complete configuration for ourreverse proxy. Here is a bare minimum, that ignores extendedurlmapping:

Of course, there's more than one way to do it. Our configuration wouldactually have been simpler if we'd used Virtual Hosts for eachapplication server. But that takes you beyond the realm of Apacheconfiguration and into DNS. If you don't fully understand that (or ifyou think 'why can't I see my domain' is a webserver question), thenplease don't try using virtual hosts for this.

Further topics

Caching

We haven't dealt with caching in this article. In a company-intranetsituation, the connection from the proxy to the application servers isthe local LAN, which is probably fast and has ample capacity. In suchcases, caching at the proxy will have little effect, and can probablybe omitted.

If we want to cache pages, we can of course do so with mod_cache Butthat is beyond the scope of this article.

Content Transformation

Another powerful use for a proxy is to transform the contenton-the-fly according to the user's preferences. This author's flagshipmod_accessibility product (from which mod_proxy_html is a spinoff)serves to transform HTML and XHTML on-demand to enhance usability andaccessibility.

Filtering and Security

A reverse proxy is not the natural place for a 'family filter', but isideal for defining access controls and imposing security restrictions.We could, for example, configure the proxy to recognise a customheader from an origin server and block content based on it. Thisdelegates control to the application servers.

Questions and Answers

(A) It doesn't really, but it may appear to. Here are the possible causes:

1. Changing the FPI (the <!DOCTYPE ...> line) may affect some browsers. FIX: set the doctype explicitly if this bothers you.

2. mod_proxy_html has the side-effect of transforming content to utf-8 (Unicode) encoding. This should not be a problem: utf-8 is well-supported by browsers, and offers comprehensive support for internationalisation. If it appears to cause a problem, that's almost certainly a bug in the application server, or possibly a misconfigured browser. FIX: filter through mod_charset_lite to your chosen charset.

3. mod_proxy_html will perform some minor normalisations. If your HTML includes elements that are closed implicitly, it will explicitly close them. In other words:

   will be transformed to

   If this affects the rendition in your browser, it almostcertainly means you are using malformed HTML and relying onerror-correction in a browser. FIX: validate your HTML! Theonline Page Valet service will both validate and show yourmarkup normalised by the DTD, while a companion toolAccessValet will show markup normalised by the same parserused in the proxy, and highlight other problems. Both areavailable at http://valet.webthing.com/

Configuring Apache Httpd Reverse Proxy for Internal Virtualbox VM

Trying is only good when accompanied by commonsense.
, Random thoughts.
5 Nov 2019

Introduction

For small companies, some of their enterprise applications may reside on internal servers; but these applications may have to be made available to users over the public internet. An Apache HTTPD reverse proxy can be used to control access to such internal applications, improving security. This article describes how to set up an Apache HTTPD reverse proxy that will restrict access to an internal application running on a virtualbox virtual machine. The Apache HTTPD reverse proxy itself will be set up on a Ubuntu VM (virtual machine) in the same virtualbox host.

The Virtualbox virtual machines should be configured such that only the Apache HTTPD reverse proxy has access to the outside internet. The enterprise application VM (virtual machine) will be on an internal host-only network and is not directly exposed to the internet. For simplicity, the Apache proxy VM will also serve as a NAT (Network Address Translation) router/gateway for the internal enterprise VM. This allows the enterprise VM to retrieve patches from the internet.

The enterprise VM is a windows server and local windows firewall should be enabled to allow only authorized incoming and outgoing connections. The Apache proxy VM will have iptables firewall rules enabled. The virtualbox host machine itself should be secured with suitable local firewall rules. The small company network is connected to the internet through a router/gateway physical device.

Illustration of the VirtualBox and Network Set up

The following diagram shows how the virtual box server, the virtual machines and the network look like.

The Apache HTTPD reverse proxy VM is connected to both the internal host-only network (no access to internet) as well as to an interface that has access to the small company network. The company network is connected to the public internet through a gateway device. There is a firewall that protects the company network. This firewall may be integrated as part of the gateway device.

The gateway device has a public internet IP and will do port forwarding for 443 (TLS) to the Apache Proxy VM. The Apache HTTPD Reverse Proxy itself will then proxy the request to the enterprise application running on the enterprise VM.

To control access to the internal enterprise application, the Apache HTTPD reverse proxy enables basic authentication so that only authorized company users can access the enterprise application. The enterprise application itself has its own login and authentication mechanism.

Some Assumptions and PreRequisites

The following lists some of the assumptions and prerequisites. Other additional assumptions and requirements will be stated when required in the article.

• The virtualbox host server has been setup and installed with the latest version of virtualbox. At the time of writing, the latest virtualbox is 6.0.14.


• The virtualbox host server should be patched up with all the latest patches. It should also be hardened using relevant security baselines like those from Center for Internet Security.


• Local firewall should be enabled for the virtualbox host server and only required outgoing and incoming connections are allowed. In other words, all non-relevant inbound and outbound connections should be blocked.


• The virtualbox host server is physically secured in a location that only authorized personnel can access.


• The enterprise application VM has been set up and updated with all the latest patches. It is configured with a single interface on the host-only network that has no internet access. The enterprise application VM has also been hardened with relevant security benchmarks like those from Center for Internet Security. In addition, the enterprise application itself should also be hardened and secured based on the vendor instructions and security best practices.


• Strong login credentials are required for logging into both the virtualbox host server and the enterprise application vm.


• The small company network has been properly secured and segmented according to the company requirements.


• There should be a firewall device protecting the company internal network. The firewall must be enabled with the proper rules to block unnecessary incoming connections from the public internet. The company may choose to block unnecessary outgoing connections as well, according to its needs. The firewall may be a part of the gateway device.


• The gateway device should have a public IP address assigned to its internet facing network (WAN) interface. Port forwarding of port 443 should be enabled to the internal company network IP address of the Apache Proxy VM.


• All the network devices such as the firewall and gateway should be updated with the latest patches or firmwares and located in secure locations that only authorized personnel can access. All network devices must be secured with strong login credentials. No default passwords must be in use. Remote administrative access from the public internet must be disabled.


• There is a company process to apply and test patches, firmware updates on a regular basis for the entire IT infrastruction setup. Critical security updates must applied in a timely manner outside of the usual patching/update cycle.


• Additional protection mechanism like regular monitoring of firewall/gateway logs, enterprise application logs, windows security events, regular verification and reapplication of hardening baselines/benchmarks etc... should be implemented. Anti malware and antivirus protection should be enabled for the relevant systems and security signatures must be kept updated.


• It is assumed that proper backups of the existing virtual machines, configurations, important data on the virtual machine host server and any other important application or company data have been done and these are stored securely in a safe location.


• The company should have a regular backup mechanism/process that will backup all important data including virtual machines at a regular interval. All backups are stored securely in a safe location.


• There should be a regular process to test that all important data including virtual machines, enterprise application data etc... can be restored successfully from backups.

The rest of the article focuses on setting up Ubuntu 18.04 LTS with a Apache HTTPD reverse proxy, that will restrict access to the enterprise application VM. It does not cover in depth hardening of the Ubuntu 18.04 LTS or Apache HTTPD. Refer to the relevant benchmarks from Center for Internet Security to harden the Ubuntu and Apache HTTPD.

Setting a New Virtual Machine

Before we start, make sure that all the proper backups have been done. It is assumed that the virtualbox host-only network (192.168.89.0/24) has already been configured and the enterprise application VM is assigned ip address 192.168.89.30. DHCP (Dynamic Host Configuration Protocol) is not enabled for the host-only network.

To view the virtualbox host networks. Start up virtualbox. Select File -> Host Network Manager.

The host only network 192.168.89.0/24 should be configured like the one shown below.

From the virtualbox console, select Machine ->New.

The create new machine window will come up. In the name field, fill in 'Apache Proxy'. Under Machine Folder, select a suitable location where the virtual machine image will be created and stored. The type should be 'Linux' and version is 'Ubuntu (64-bit)'. Allocate it at least 1024MB of RAM. Choose the option, 'Create the virtual hard disk now'. Click on 'Create'.

At the Create Virtual Hard Disk window, set the file size to be at least 20GB. Select the 'fixed size' option. Click on 'Create'.

Once the disk image is created, a new virtual machine 'Apache Proxy' should appear in the virtualbox console.

Click on the settings option for the Apache Proxy VM. Select the 'Systems' on the left of the settings window. Select the 'Processor' tab. Set the number of processors to 2. Checked the 'Enable PAE/NX' option. Click 'Ok'.

Click on the settings option for the Apache Proxy VM again. Select 'Network' on the left of the settings window. Select the Adapter 1 tab. The 'Enable Network Adapter' option should be checked. Under the Attached To field, select 'Host-Only Adapter'. The name of the adapter should match the one in the Host Network Manager earlier when we view the network (192.168.89.0/24). In this case, the name is 'VirtualBox Host-Only Ethernet Adapter #2'.

Click on the Adapter 2 tab. Checked the 'Enabled Network Adapter' option. In the Attached To field , select 'Bridged Adapter'. The name of the adapter should correspond to the network interface card on the virtualbox host server. If the host server has multipe network interface cards, this should be the one that is connected to the small company network. Click 'Ok'.

The Apache Proxy VM configuration is mostly done. For more information on virtualbox configuratin, refer to the VirtualBox User Manual.

Installing Ubuntu Server 18.04 LTS

Download the latest ubuntu server 18.04 LTS iso file from https://ubuntu.com on your windows workstation. At the time of writing the latest Ubuntu Server LTS version is 18.04.3.

Verify the integrity of the iso file after it has been downloaded. On a windows workstation such as windows 8 or 10, the certutil utility is available for doing checksums. The ubuntu server 18.04.3 iso should have the following SHA256 checksum.

On the windows workstation, click on

At the powershell prompt type

Note you need to replace the location for the iso file in the above command to where you have saved the downloaded ubuntu iso file. The sha256 checksum generated should match the one stated earlier.

Take note that you should surfing the internet on the virtual server host machine. This is to avoid accessing malicious websites or files accidentally that can have serious security consequences. All web surfing, such as visiting ubuntu website and downloading the ubuntu iso should be done on a regular workstation with antivirus/malware protection. The downloaded file can then be transfered over to the server.

Setting the Apache Proxy VM to boot with the ISO

Transfer the ubuntu server iso file to the VirtualBox host server. Start up the virtualbox console and select the Apache Proxy VM. On the right side, the settings of the Apache Proxy VM should be shown. There should be a '[Optical Drive] Empty' option under storage category. Click on this '[Optical Drive] Empty' option.

Select 'Choose Disk Image' when the context menu comes up.

Select the Ubuntu Server 18.04.3 iso file when the file chooser comes up. Click 'Open'.

The '[Optical Drive]' field should now display the ubuntu server iso file instead of being empty. Click on 'Start' at the top menu to boot up the Apache Proxy VM. Upon booting up, the console for the Apache Proxy VM should show the ubuntu server installation screen. It should be prompting to choose a language. The default is 'English'. Just press 'Enter' to continue.

The next screen is the keyboard selection. Leave it as the default and press 'Enter' to continue.

The network configuration comes up next. There will be two network interface cards. The first one is for the host-only network (without internet access), the second is for the company network. For now, we continue without configuring the network. Leave the settings as default and press 'Enter' to continue.

Continue to press 'Enter' for the next few screens, Configure Proxy, Configure Ubuntu Archive Mirror, FileSystem Setup, FileSystem Setup (choose disk). Leave the settings for these as defaults.

Take note that the default disk partition is different from the CIS (Center for Internet Security) hardening recommendation. The CIS benchmark may specify that separate disk partitions be used for different filesystem mount points. For example, /tmp should be on its own disk partition.

To simplify the setup, this article doesn't go into details on how to partition up the virtual hard disk. The Apache Proxy VM will have a narrow scope of usage/role. Only running apache httpd as a reverse proxy and not hosting any web application scripts or data. The VM will also serve as a router cum firewall for the internal host-only network. The router/firewall role is to allow the enterprise VM to retrieve windows patches/updates. Apart from these 2 roles, the linux system is not used for any other purpose. This reduces the security risk associated with having a single disk partition.

That said, if time and effort permits, it is good security practice to follow the CIS hardening guide and provide seperate disk partitions for some of the filesystem mount points. This will enable filesystems to be mounted with different and stricter permission settings. For details, refer to the CIS hardening benchmark for Ubuntu 18.04 LTS.

At the FileSystem Summary screen showing the disk partition, press 'Enter'.

A confirmation box, 'Confirm destructive action' will pop up. Use the down arrow key to select the 'Continue' option. Press 'Enter'.

At the profile Setup page. Fill in the details for the linux user account. Enter the name of the user. In this case, we use 'Mr Apache Administrator'. Enter the server name, 'apacheproxy'. The 'pick a username' is referring to the login id. In this field, we type the userid 'apxyuser1'. Enter a long complex hard to guess password that is at least 8 characters long. The password should contain alphanumeric characters, both upper and lower case, and special characters.

Note, this is only a temporary password. We will change it to an even longer and more complex one (at least 20 characters) later. To make password management easier, use a password manager like Bruce Schneier Password Safe.

Select 'Done' and press 'Enter' to continue.

Next is the SSh Setup screen. Checked the 'Install OpenSSH server' option by using the enter key. Select 'Done' and press 'Enter' to continue.

Ubuntu will start installing. Once installation is completed. A reboot now option will appear. Click 'Enter' to reboot.

There will be another prompt to remove the installation medium. Simply press 'Enter' to continue.

When ubuntu boots up, you should see a login prompt. You can log in to the system by typing the userid 'apxyuser1' at the login prompt and then the password created for the account earlier.

For more detailed information on how to install Ubuntu, refer to the official Ubuntu Server LTS Installation Guide.

Initial Configuration of Ubuntu

In this section, we will start configuring the Ubuntu 18.04 LTS. The article will not go into details on hardening the system. Download the Center for Internet Security guide for Ubuntu 18.04 LTS and follow the benchmark to do a full hardening.

Login to the Ubuntu using the user 'apxyuser1' and its password. One of the first thing to do after logging in is to set the correct timezone.

From the screenshot above, it can be seen that the timezone is UTC. We need to set to Asia/Singapore. Type the following command and press 'Enter' to change to root user.

Enter the password for apxyuser1 when prompted. The following screenshot shows this.

Security and adminstrative best practices often state that one should not work on a linux system as root user. In this case, our system is newly setup and there is little risk of issue even if a root user mistake bring down the newly installed ubuntu server. For a live production system, follow the best security practice and evoke the required root privilege using the sudo command.

For the rest of the commands, it is assumed that we are using the root user account. Type the following command and press enter to change the timezone.

Let's change the UMASK of the system from the default 022 to 077. This make the default permissions of the files and directories created by the root user more secure. We will use the nano text editor to edit the /etc/login.defs file. Type and enter the following command.

The nano text editor is easier text editor for those new to linux. You can navigate a file using the arrow keys or page up/page down keys. At the bottom of the editor, you can see a menu of options like '^G Get Help', '^O Write Out', '^X Exit' etc... The '^' sign means control key and the character next to it is the keypress that together with the control key will evoke the option. For example, to exit (^X Exit), press the control key and the 'X' key together.

In the /etc/login.defs file, lines that start with a '#' are comments. Scroll down the file using the Page Down key or the down arrow key. Look for the UMASK setting.

Move the cursor to the setting using the right arrow key. Use backspace to delete the 022 and type 077 as replacement.

Press Ctrl key and the X key together to exit. When prompted to 'Save modified buffer', enter Y.

Press enter when the file name to write prompt comes up.

nano will exit and you will get back to the command prompt. The new UMASK setting 077 will only take effect after a reboot or a log out and log in. To reboot, type the following and press 'enter'.

After the server has come up, login again and change to the root user using 'sudo su -'. We will configure the networking for the Ubuntu server. As root, type the following and press 'enter'. In the linux command prompt, commands that have been typed in only execute after the 'enter' key is pressed.

There should be two network interfaces, enp0s3 and enp0s8.

enp0s3 should be the one for the host-only adapter that we created earlier. We can verify by comparing its MAC address with the adapter setting for Apache Proxy VM in virtualbox. From the screenshot above, the line 'ether 08:00:27:94:5f:55' under enp0s3 is MAC address for enp0s3.

On the virtualbox console, Select the Apache Proxy VM -> Settings -> Select Network -&gt Under the Adapter 1 Tab -&gt Click on the Advance option.

It can be seen that the MAC address '080027945F55' matches the one for enp0s3. Note, the colon in the linux mac address value is a seperator that can be ignored.

We will assign the IP address 192.168.89.50 in the host-only network to the Apache Proxy VM. The network settings are in the file /etc/netplan/50-cloud-init.yaml. Edit this file using nano editor.

Modify the existing network setting and enter the following

Notice the indentation in the text. These are not entered using tab key. Use space bar for the indentations. 4 spaces per indent.

Press 'Ctrl X' to exit. Enter 'Y' when prompted to 'Saved Modified Buffer'. At the 'File Name to Write' prompt, leave it as the default ' /etc/netplan/50-cloud-init.yaml' and press 'enter'.

Type the following command to apply the setting.

Run ifconfig again and this time you see enp0s3 being assigned the IP address 192.168.89.50.

Setting up Putty Access

By now, you will have noticed that the ubuntu console is not a convenient interface. To make life easier, we can use the popular putty client and ssh into the linux server. Putty client supports cut and paste etc... The latest version of Putty can be downloaded from https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html

From a workstation download the 64 bit windows version of putty.zip. The SHA256 checksum for the zip should be

Use the certutil commmand to verify that the downloaded putty.zip has got the correct SHA256 checksum.

Transfer the putty.zip to the virtualbox server. Unzip the putty.zip at a directory where you want to store the putty binaries. Double click on the putty.exe to start up putty client.

At the host field, enter the ip address '192.168.89.50' that is configured in the ubuntu server. Enter the name 'Apache Proxy' on the 'Saved Sessions' field.

Click on 'save' to save this session so that we don't have to re-type the ip address each time. Click on 'Open'. You should get a prompt about the server host key. This prompt comes up the first time that putty connects to a server.

Click 'Yes' to accept the server host key. The login prompt should come up.

Log in using apxyuser1 and its password. For subsequent connections, you can start up putty and click on the 'Apache Proxy' session to start a new connection.

Restricting SSHD to host-only IP

After you have logged in through putty, change to the root user using the command 'sudo su -'. We will configure sshd to listen only on the IP address 192.168.89.50. This is important to prevent the Apache Proxy VM from being accessed by other computers on the company network. Edit /etc/ssh/sshd_config using nano text editor.

Lines beginning with '#' are comments. Add a ListenAddress setting specifying IP address 192.168.89.50.

Exit nano and save the changes. Restart the sshd using the following command.

To check that sshd is now listening on the host-only IP address 192.168.89.50, type the following and press enter.

You see the line '192.168.89.50:22' like in the following screenshot.

Refer to the CIS Ubuntu 18.04 benchmark for further hardenings of the SSHD.

Apache Http Reverse Proxy

Enable Internet Access

We will now enable internet access for the Apache Proxy VM. We assume that the office/company network IP address 10.1.0.175 is assigned for this VM. The gateway of the company is at 10.1.0.1 and the subnet mask is 255.255.0.0 (/16).

Login to Apache Proxy VM using putty client and change to the root user.The second interface enp0s8 on the ubuntu which is connected to the office/company network should be assigned the 10.1.0.175 IP address. Edit the file /etc/netplan/50-cloud-init.yaml using nano.

Apache Httpd Reverse Proxy Download

Add the entries for enp0s8 as follows. Note that it is important that the indentation uses space and keep it at 4 spaces per indent. We are using google public dns servers (8.8.8.8, 8.8.4.4) for name resolution.

Apply the settings using the following command.

Ping a website like www.google.com to check that we got internet access.

Update Ubuntu Kernel and Patches

Let's update the Ubuntu 18.04 LTS to the latest kernel and patches. Issue the following command to check for the latest packages.

The following screenshot shows this.

When the command completes, run the following to fetch the updated packages and upgrade Ubuntu 18.04 to the latest kernel and patches.

You will get a confirmation prompt saying which packages will be updated, the disk space usage etc... Enter 'Y' to confirm.

After the latest kernel and patches have been installed. Run the following command to clean up.

The following screenshot shows this.

Reboot the server for all the updates to be effective.

The Ubuntu 18.04 LTS server should be upgraded regularly. Run the steps in this section on a regular basis. These steps should also be performed when Canonical releases any critical security patches.

The Ubuntu 18.04 LTS will be supported until April 2023, after which Canonical (company behind ubuntu), may no longer release any new updates. A new version of Ubuntu will then have to be installed by then.

Refer to the following Ubuntu security notices, for the latest security notices for Ubuntu. You can also subscribe to the ubuntu-security-announce mailing list to get notices about security updates.

Installing VirtualBox Guest Addition

After the ubuntu server has booted up, login again using putty client. Change to the root user using 'sudo su -'. We shall now install the VirtualBox Guest Addition. The Guest Addition provides enhanced functionalities like the ability to synchronized the time with the virtualbox host server.

Go to the Virtualbox console for the Apache Proxy VM. At the top menu, select Devices ->Insert Guest Additions CD Image.

At the putty client, mount the cdrom using the following command.

The following screenshot shows this

Change to the /media directory using the following command.

Issue the following command to install build tools required for compiling software.

The following screenshot shows this.

Enter 'Y' to install the tools. Enter the following command to compile and install the guest addition.

The following illustrates this.

Remove the build tools. For security reason, the ubuntu server should not have build tools present. Issue the following command.

Enter 'Y' when prompted for confirmation.

Reboot the server for the guest addition to take effect

Whether virtualbox software is updated on the virtualbox host server, the guest addition in each of the virtual machines should be updated too. To update the guest addition, repeat the steps in the earlier section on update ubuntu kernel and patches. Then repeat the steps here to update to a newer guest addition.

Setting up IPtables firewall and NAT

In this section, we will set up the Apache Proxy VM running Ubuntu 18.04 LTS as a router with NAT(Network Address Translation) for the host-only network. Iptables firewall will be enabled as well. Take note that good security practice dictate that we should be using a dedicated machine or virtual machine for this function of router/NAT. In this article, we combine the router/NAT role with the apache httpd proxy role for simplicity.

It is actually possible to simply just install another linux VM and follow the instructions in the article, to set up a dedicated router/NAT. The recommended approach is to use a dedicated linux VM for router/NAT. If a dedicated linux router/NAT is used, the Apache Proxy VM should be created with only a single host-only adapter. It should not be able to access the internet directly but only through the linux router/NAT VM. In the company network, the physical gateway device should be doing port forwarding (port 443) to the linux router/NAT VM instead of the Apache Proxy VM.

Back to our setup. Login to Apache Proxy using the putty client. Change to the root user (sudo su -).

Edit the /etc/sysctl.conf using nano.

Apache2 Reverse Proxy Https

Scroll to the bottom of the file and add in these lines.

The following screenshot shows this.

Exit nano and save the changes.

The sysctl.conf controls the kernel parameters that are set when the system boots. The settings above are for the kernel network parameters. One of the kernel parameter, nf_conntrack_tcp_loose, seems to be difficult to set in Ubuntu 18.04 LTS. We need to create another file that will be run at start up.

Enter the following content in the file.

Exit nano and save the changes. Change the permission of the file with the following command.

rc.local is a script that will run when Ubuntu starts up. It will set the kernel parameter nf_conntrack_tcp_loose to 0. We need this because the sysctl.conf doesn't seem to set this parameter properly on Ubuntu 18.04 LTS.

Create a new file using nano for our iptables firewall rules.

Enter the following content. If your setup is using different IP addressing, you need to edit the IP addresses accordingly. In the content, lines starting with '#' are comments.

Exit nano and save the changes. Apply the rules using the following command.

There should not be any error messages. To check if the rules are applied, use the following command.

You should be able to see the following.

Check the rules for the other tables.

The following should be shown.

You should be able to match each of the lines shown to the rules in the firewall.sh file created earlier. To make the firewall and NAT rules persistent between reboots, we need the iptables-persistent package. Install it using the following command. When prompted to install, enter 'Y'.

When prompted for the location to save the firewall rules. Leave it as default and press 'enter'.

As part of the iptables-persistent package installation, the current firewall rules are saved. However, if we want to be really sure; we can manually save it again. Save the firewall rules using the following command.

Logging is enabled in the firewall rules. By default the logs will go the system syslog. This can clutter up the syslog. We need to separate out the firewall logging to another log file. Create a file /etc/rsyslog.d/20-iptables.conf using nano.

Enter the following into the file.

The following screenshot shows this.

Exit nano and save the changes. Now that we got a separate log file for iptables firewall, we need to ensure that this file doesn't keep growing until it takes up all the disk space. There is a need to rotate the log file. Create the following file with nano.

Enter the following content.

Exit nano and save the changes. Let's do another reboot for all the settings to take effect.

To allow the enterprise application VM to access the internet through the Apache Proxy VM. It has to be configured with the Apache Proxy VM as its gateway. Assuming the enterprise application vm is a windows server and is assigned the host-only IP address 192.168.89.30; the following shows a sample of the network configuration.

The enterprise vm is configured to use the public google dns servers 8.8.8.8 and 8.8.4.4 for dns resolution. To test the Apache Proxy VM router/NAT configuration. You can login to the enterprise application vm and ping www.google.com from the command line. You should be able to get replies.

To further harden and secure the Apache Proxy VM, refer to the CIS benchmark for Ubuntu 18.04 LTS.

Configure Apache Httpd as Reverse Proxy

In this section, we will install and set up Apache as a reverse proxy for the internal enterprise application. We will not cover details on hardening apache httpd. Refer to the Center for Internet Security Apache httpd benchmark on instructions to harden the Apache httpd.

Login to the Apache Proxy VM using putty client. Change to the root user. If you forgotten how to do this, check the earlier sections. Someone new to linux who has followed through the earlier sections will have been much more familiar with linux command line by now. This section, we will be going slightly faster.

Install the latest version of Apache Httpd using the following two commands.

The first updates the packages list, getting the latest versions. The second command installs the apache2 package. Running the 2 commands, one after the other ensures that the latest apache2 package will be installed. Enter 'Y' when prompted for confirmation.

Notice the line asking the user to run 'apt autoremove' to remove some unneeded packages ? Let's run 'apt autoremove' after apache2 has been installed.

Enter 'Y' when prompted.

Disable some of the apache modules that we do not need. Run the following commands one by one.

When disabling some of the modules, you may be prompted to type a phrase. Type the phrase and press 'Enter'.

Edit /etc/apache2/apache2.conf using nano.

Look for the following

Change the above to the following.

This commented out /usr/share and hence access is prevented. For our use case here, we do not need /usr/share to be accessible by apache httpd. Look for the following section of text.

Change the '/var/www' to '/var/www/empty'. Add in a directive to limit the HTTP access methods to GET, POST and HEAD.

/var/www/html is usually the web root of the apache httpd server. In this case, the earlier 'Directory /var/www' section, allows access to /var/www and its subdirectories which includes /var/www/html. We tightened the access and changed it to '/var/www/empty' and any subdirectories or files inside /var/www/empty. We will create an empty directory there.

Create the empty directory /var/www/empty and set its permissions with the following 2 commands.

Let's put in an empty index.html file in the empty directory. Run the following commands.

Our reverse proxy should use TLS and listen on 443. For an actual production server, you can get SSL certificates from a CA (Certificate Authority). In our case, we will generate a self signed certificate.

Enter the relevant information when prompted by openssl. For common name, we use a test domain 'apxy.nighthour.sg'

On a workstation, browse to https://ssl-config.mozilla.org/. We will generate a TLS/SSL configuration using the Mozilla SSL Configuration generator and use this as a base for our own configuration. Select 'Apache' on the web form and the 'Intermediate' option. Enter '2.4.29' for server version. Openssl version is 1.1.1.

Copy out the configuration, we will modify it and use it for our TLS/SSL configuration. Enable the following modules, mod_ssl, mod_headers, mod_proxy, mod_proxy_http and mod_allowmethods.

Take note that the mod_allowmethods is experimental status, we are using it here to restrict the HTTP methods that can be proxied. A trade off is made as we considered the internal application to be far 'less secured' than even an apache httpd module that is still experimental. As such, we want to reduce as much as possible the attack surface of the internal application and this includes restricting the HTTP methods.

Create a configuration file for our SSL virtualhost using nano.

Add in the following content.

Exit nano and save the changes. The ServerName and ServerAlias are set to 'apxy.nighthour.sg'. You should set this to your own actual domain name. The ProxyPass setting enables the proxying to the internal enterprise application IP address (192.168.89.30). It proxies to the '/myinternalapp/' directory. You can change these to suit your environment setup.

Basic Authentication is enabled for accessing the '/myinternalapp/' location. Let's create the password file storing the credentials for basic authentication. Take note that the CIS Apache Httpd hardening benchmark warns that both basic authentication and digest authentication are outdated and should be disabled.

In this case, the internal enterprise application has got its own login mechanism. The basic authentication is just a means to enhance security and reduce the attack surface by restricting access to company users. Instead of exposing to the whole public internet, it is now exposed only to company users who have the basic authentication credentials.

To restrict the HTTP methods for proxying, the allow methods module is used. Only HTTP GET, POST are allowed. Note that the HEAD method is allowed when GET is allowed. The SSLProxyEngine option turns on TLS/SSL proxying. This allows proxying to a TLS/SSL enabled backend application.

Take note that two environment variables 'SetEnv force-proxy-request-1.0 1' and 'SetEnv proxy-nokeepalive 1' are set so that the proxying to the backend server uses HTTP 1.0. This is a mitigation against HTTP request smuggling attack. HTTP request smuggling makes use of the different interpretation of multiplexed HTTP requests by the proxy and the backend server, to compromise the proxy setup.

Many proxy setups will be affected by this. It is necessary to mitigate against this vulnerability through the use of WAF or to use a non multiplexed protocol like HTTP 1.0. Another possible mitigation is to use the same software for both the proxy and the backend webserver, this way they will both interpret HTTP requests similarly.

Run the following commands to create the securesite directory and create a basic authentication user credential.

Enter a strong complex password, use at least 14 characters, alphanumeric, upper and lower case, as well as special characters.

Ok, now enable our new ssl virtualhost.

We can disable the default port 80 virtualhost. Since this setup is for company users, it is relatively easy to let the users know that they should only access the TLS/SSL website.

Edit the /etc/apache2/ports.conf using nano. Replace the content with the following.

10.1.0.175 is the company IP address assigned to the Apache Proxy VM. You can change this if your IP is different.

Edit /etc/apache2/conf-enabled/charset.conf using nano. Uncomment the 'AddDefaultCharset UTF-8'. The content of the file should look like this.

Edit /etc/apache2/conf-enabled/security.conf using nano. Replace the content with the following.

The security configuration only set a small number of HTTP headers that can improve application security. It also has minimal hardening settings. To harden the apache httpd, refer to the CIS Apache httpd benchmark. To set application security header, refer to OWASP Secure Headers Project. The internal enterprise application should also be hardened according to the vendor advice as well as security best practices.

Disable the cgi-bin configuration. We do not need cgi functionality.

We are done for simple basic configuration. Reboot the server and test the proxying to the internal application.

After the Apache Proxy VM boots up. We can test our proxying. Open up a browser on a workstation and surf to https://10.1.0.175/myinternalapp/, we should get the basic authentication prompt. The security warning on the webpage is due to the use of self signed certificate in our setup. In this case, we can just accept the risk and proceed since it is our own self signed certificate and website. For actual production use, you should be using a proper CA signed certificate.

Once we enter the right credentials, we should get to a test page on the internal application.

For more information on configuring apache httpd as a reverse proxy, refer to the Apache Reverse Proxy Guide.

Apache Reverse Proxy Configuration

Changing Password

Now that we have a basic Apache Proxy VM set up, it is time to change the password for the apxyuser1 account. Login as apxyuser1 using the putty client. Issue the following command.

Enter a new password that is at least 20 characters long, alphanumberic with both upper and lower case characters, and special characters. This is important to prevent unauthorized brute forcing. To make managing passwords easier, a password management tool like Bruce Schneier Password Safe can be used.

Password Safe can be used together with a friendly SSH client like Putty. This makes logging in using different long complex passwords, a simple matter of copying and pasting from password manager to ssh client.

While password login may be sufficient for the use case of a single small company with limited number of internal servers. To really secure SSH access, the recommendation is to use PKI (Public Key Infrastructure), key based authentication. The concept is generate a public/private key pair, the public key is copied over to the linux server and the private key protected with a long complex passphrase stored securely on the user workstation.

Ssh is then configured to disable password login and only allow key based login. When the user wants to ssh into the linux server, he or she needs to supply the passphrase to the local private key to allow authentication. Access is now based on both what you have (private key) and what you know (your passphrase).

Different keys should be used for different servers, and the private keys protected by different long complex passphrases. Password manager like Pass Safe can be used.

Some of the disadvantages of key based authentication is the issue of key management and how to revoke keys which are compromised etc... But this method is generally more secure than password authentication.

Do a google search on the internet and there are many good articles on how to setup key based ssh authentication. The Ubuntu Commnity Wiki has an article on this.

Further Enhancements

The article focuses mainly on getting the simple proxy system up and running. It doesn't contain a lot of details and steps for hardening the system. To enhance and improve the setup; first and foremost is to harden the system. Refer to the CIS benchmarks and use it as a base guide for securing and hardening the system.

The reverse proxy setup can be improved through the use of a web application firewall like Mod Security and the setting up of more HTTP/web security headers. If greater performance is required, a possible alternative is to consider using Nginx as a replacement for Apache httpd.

Nginx is an extremely high performance web server that can serve as a reverse proxy. In recent years, it has gained much market share from Apache httpd.

In our setup, we have two roles for the Apache Proxy VM, as a reverse proxy and as a gateway/NAT/firewall. The gateway/NAT/firewall role can be separated out and setup on another dedicated linux vm. This will help to improve security as the attack surface for each system (single use/single role) is now much smaller.

Conclusion and Afterthought

This is a long article focusing on infrastructure setup. It tries to balance between simplicity and having the required security, so that a beginner can follow and use this as a first step to build up their own system.

Some of the basics of infrastructure management remain the same despite the move to cloud computing in recent years. The phrase that the cloud is just someone else computer holds true. It takes some of administrative tasks away from end users but the cloud providers' engineers are working behind the scene to manage/administer and maintain the physical infrastructure. Their maintainence may be made easier through the use of modern automation techniques, tools and customized software/setup that big cloud providers can develop inhouse on their own.

Cloud computing may not be for everyone though. For some enterprises, it may actually be cheaper to maintain their own infrastructure. An example is Dropbox which moves to its own inhouse cloud infrastructure. For others, it can be due to the need for security, like government agencies that deal with classified and national security information. Yet, there can others like small companies that don't really have a need to go to the cloud, or those who prefer to have control over their own infrastructure.

Whatever the choice, infrastructure management is changing in our modern times. There are more virtualization, containerizations, orchestrations and automation. Information Secrity or Cyber Security is part of all these; to ensure the Confidentiality, the Integrity and the Availability of our critical infrastructure and data.

Useful References

• Center for Internet Security, provides a number of security hardening benchmarks for ubuntu, apache httpd etc...
• VirtualBox User Manual, The official virtualbox user manual on how to use and operate virtualbox.
• Putty SSH Software, Useful ssh client and tools.
• Ubuntu Security Notice, Canonical website that provides security alerts on Ubuntu Linux.
• Mozilla SSL Config Generator, Mozilla website that helps to generate recommended configuration for TLS/SSL for popular web servers.
• OWASP Secure Headers Project, OWASP project that focuses on application security headers.
• Apache Httpd 2.4 Documentation, Official Apache Httpd documentation that provides details on how to configure and use Apache httpd 2.4.
• Apache Reverse Proxy Guide, A short how to on configuring Apache Httpd as a reverse proxy.
• Ubuntu Server Guide, Official Ubuntu guide on how to configure Ubuntu 18.04 LTS.
• Ubuntu Community Wiki Article on SSH Key login, An article on how to configure ssh key based authentication.
• Password Safe, The password manager designed by Bruce Schneier. It is useful utility to manage many long complex passwords for different applications.
• Mod Security, A popular opensource Web Application Firewall.
• Nginx, A fast opensource web server that can serve as a reverse proxy.
• Web Application Security Headers, An earlier article on some of the security headers for web applications.
• HTTP Request Smuggling, An article explaining HTTP request smuggling attack. This attack can affect many proxy setups. Mitigations need to be taken against such a vulnerability.
• HTTP request smuggling: HTTP/2 opens a new attack tunnel, An article about how HTTP request smuggling can affect proxy setups that use HTTP/2.
• Amazon HTTP Desync library, an opensource library that can be used by HTTP engines such as Nginx to defend against HTTP Desync/HTTP Request Smuggling attacks.

If you have any feedback, comments, corrections or suggestions to improve this article. You can reach me via the contact/feedback link at the bottom of the page.