If you use an external load balancer (LB), you must reconfigure ARIS LB to prevent system failiure caused by ARIS brute-force protection.
When you put an HTTP-based application server behind an external load balancer (LB), the HTTP application will only see the IP address of the LB as apparent client IP. Likewise, when TLS is terminated at the external LB, the HTTP server will see that it is accessed via HTTP, as it has no way of knowing that the actual clients had been using HTTPS up to the external LB.
For various reasons listed below, it is important for the HTTP application to know the true clients' IP addresses, the true protocol used from the client's perspective, and the TCP port used:
If the ARIS LB does not know the true client IP, it cannot log it in its access log - the access log will only show the IP of the external LB all the time. This might not be a problem until you try to find out which client did a bad request.
ARIS has a mechanism to limit the number of failed logon attempts, so that an attacker cannot brute-force passwords. This mechanism logs the number of attempts individually for each client IP. If the attacker at 1.2.3.4 tries to brute force his way into the system he will be slowed down after a few failed attempts. This will not affect other users accessing the system from other IPs. But if the application only sees the IP of the external LB, failed logon attempts all seem to come from the same IP. This makes the brute-force protection become active much earlier because all failed attempts, even if it is not an attack but just a typo, are counted for the same IP - that of the external LB.
in some situations ARIS server needs to create a link to itself and send that to the client. For example, when Process Governance processes are sending notification mails that contain links to a certain resource in the application, these links should use the host name, protocol and port that the actual end users are using to access the application. Not the host name, protocol and port that the external LB is using to communicate with ARIS. A similar mechanism is going on with the download client download mechanism.
Because of this, it is necessary that ARIS in some way gets information about:
The true IP address of the client.
The protocol the client originally used to access the application.
The port used.
The host name used.
With an external LB in front and without additional mechanisms, all this information would be lost if you did not use the X-Forwarded-* header mechanism. Slightly simplified it work like this:
X-Forwarded-For contains the original client IP address.
X-Forwarded-Port contains the port that the client originally used.
X-Forwarded-Proto contains the protocol (HTTPS or HTTP) that the client originally used.
X-Forwarded-Host contains the original host name that the client used.
There is also a more recent header specified (Forwarded header), which puts all this information into a single header, but the concept is the same.
To make all the functionality above work properly, an external LB has to add the X-Forwarded-* headers or the Forwarded header to the request, putting in the true client information.
However, if ARIS would simply accept these headers from anywhere, an attacker could create requests that already contain these headers. For example, using the X-Forwarded-For header, he could circumvent the login attempt limitation. He could use on physical IP address, but change the IP in the X-Forwarded-For header for each attempt. For this and similar reasons, ARIS LB will by default not accept any of the X-Forwared-* headers from anyone. They will simply be removed from the request before passing it on to the actual application micro services.
Using the HTTPD.X-Forwarded-For.trusted.proxy.regex parameter, you can specify a regular expression. Any client IP that matches this regex will be considered trustworth, and only from those the ARIS LB will accept the X-Forwarded-* headers.
Note that while this parameter name suggests that it is only relevant for the X-Forwarded-For it is now used for all of these headers - we merely decided to keep the parameter name for compatibility.
Therefore, in any scenario where clients do not directly access ARIS LB, but go through external LBs, you must declare the IPs of your external LBs as trustworthy to ARIS LBs. Therefore, reconfigure each ARIS LB. And if your external LB is using more than one IP address to access ARIS, you must change the regex so that all of these IP addresses match. The regex syntax used is that of the perl-compatible regular expressions library (PCRE) http://www.pcre.org/. The only caveat is that if you need to use a backslash in your regex (like to escape the "." in the above proposal), it has to be replaced by four backslashes.
Example
If the IP of your external LB is 198.20.212.156 and you are using two ARIS LBs, enter the following ARIS Cloud Controller (ACC) commands:
on n1 reconfigure loadbalancer_l HTTPD.X-Forwarded-For.trusted.proxy.regex="198\\\\.20\\\\.212\\\\.156"
on n2 reconfigure loadbalancer_l HTTPD.X-Forwarded-For.trusted.proxy.regex="198\\\\.20\\\\.212\\\\.156"