In the current environment, with its ever-growing threat of hackers, viruses, and all kinds of intruders, protecting your infrastructure is becoming more and more important. Many companies employ load balancers and security appliances to improve security and reliability of their customer-facing sites.
This article is part of series on PRTG and reverse proxies: how to monitor and utilize them. In this first part, we will talk about how that is accomplished in general terms. Each security appliance has its own way to configure reverse proxies, so the following articles will cover the specifics for some popular platforms.
PRTG, like any other well-behaved web site/application, relies on the HTTPS (TLS/SSL) protocol for security. Like most applications that encrypt communications, PRTG utilizes a revision of OpenSSL for the encryption/decryption of the data streams. There are three separate loads in PRTG that rely on encryption:
Referring to the graphic of PRTG interfacing with "Remote and multiple Probes".
We see that all remote probe interaction that traverses a network is encrypted. In larger environments with many remote probes, the overhead of encryption/decryption of the data streams can be significant. An advanced processor that supports the AES-NI instruction set boasts up to a 60% performance increase in SSL. During my testing, I found it to be more like 40%. In order to remove the load completely, short of switching to HTTP, you have to employ a service in an external device or application. This service, called a "reverse proxy" (we’ll refer to it as "Rproxy"), is provided by either software packages or security appliances.
Please note: We have carefully compiled this information and it is provided to the best of our knowledge. As the solution is not part of PRTG itself, it is not officially supported by Paessler or PRTG Technical Support. Yet, we wanted to share it with you as it might be of interest for many PRTG users.
You must also be aware, that if you configure any of the parts incorrectly, you may leave yourself open to an intruder gaining access to anything configured within PRTG. This includes User ID’s, Passwords, ip’s names, etc. IE no warranties expressed or implied. Paessler, its employees or partners cannot be held liable for any damages that you may incur as a result of employing a Reverse Proxy.
Since the user enters sensitive information through the user interface, all traffic between PRTG and the client should be secured. The Rproxy will encrypt and decrypt the web traffic going between the PRTG server (PRTG Core) and the client (Browser). Essentially, the client (browser) talks HTTPS between itself and the Rproxy, and Rproxy translates the conversation to HTTP between itself (Rproxy) and the PRTG Core.
There are a couple of standard software packages that supply reverse proxy services. On the Paessler Knowledge Base site, there some articles on how to configure and use them:
Proxying the PRTG Web-based Graphical User Interface (Web-GUI)
The PRTG Web GUI is implemented as a web server and can be configured to run either over unsecured HTTP or secured HTTPS protocol. If your PRTG instance is exposed to any unsecured network, secured communications protocols are strongly recommended. When it is secured, PRTG does all the encryption and decryption of the communications internally. To use a Rproxy, you have to turn off the encryption on the PRTG web server, essentially making all the Web GUI interaction plain text.
Configured either through the Admin Tool or Web GUI Menu | Setup | System Administration | User Interface
Once PRTG is in plain HTTP mode, you can configure the Rproxy with the following:
iAn IP address (internet protocol address) is a numerical representation that uniquely identifies a specific interface on the network. IP addresses are binary numbers but are typically expressed in decimal form (IPv4) or hexadecimal form (IPv6) to make reading and using them easier for humans. Read more ...
Configure the DNS record for MyPRTGServer.xx to point to the IP address of the secured interface on the Rproxy the clients will use.
Most proxies do content caching, which also helps offloading work from the web server. Unfortunately, most of the proxies will not cache any URL that has a parameter (the URL as “…xxx?field=value,…” or a header directive to disable caching (Cache-Control: no-cache). As it happens, PRTG uses both, so caching is limited to things like icons and other “static” files.
It is important to re-iterate the importance of restricting access to the PRTG server interfaces in this configuration. All direct access to PRTG will leave the conversations vulnerable to snooping the conversations between the Rproxy and PRTG core. The best thing to do is to only accept conversations coming in on the IP the Rproxy is talking to. Or better yet, put the PRTG server in a vlan that has restricted access.
We will present a series of articles with details on how to implement the Rproxy with different security appliances.
