Privileged Vault Web Access 是 CyberArk 的 Privileged Access Security 解决方案中最直接的负载平衡组件,但尽管如此,仍然很容易错误配置最重要的方面之一:健康检查。

可以使用任何负载平衡解决方案的“默认”健康检查,但这通常会给您留下基于服务器的健康检查与基于应用程序的健康检查。这可能会导致您的负载平衡器仍将流量中继到运行 IIS 但 PVWA 服务不起作用的服务器。

CyberArk 为其他组件提供有关利用各种端点完成基于应用程序的健康检查的文档(特权会话管理器,特权会话管理器 HTML5 网关),对于 PVWA,它仅提供(https://docs.cyberark.com/Product-Doc/OnlineHelp/PAS/Latest/en/Content/PAS%20INST/PVWA-install-multiple-PVWA-env.htm?tocpath=Installation%7CInstall%20PAS%7CInstall%20PVWA%7C_____8#Loadbalancerrequirements)0120 最基本的负载平衡要求 zwz1(https://docs.cyberark.com/Product-Doc/OnlineHelp/PAS/Latest/en/Content/PAS%20INST/PVWA-install-multiple-PVWA-env.htm?tocpath=Installation%7CInstall%20PAS%7CInstall%20PVWA%7C_____8#Loadbalancerrequirements).

使用 HAProxy,我们将使用健康检查设置负载平衡,评估 PVWA 服务(我们的“应用程序”)的健康状况,而不仅仅是 IIS。

什么是HAProxy?

从官方HAProxy网站来看,它是“......一个免费、非常快速和可靠的反向代理,为基于 TCP 和 HTTP 的应用程序提供高可用性、负载平衡和代理。”它可以满足 PVWA 的基本负载平衡要求,也可以满足这篇知识文章中的“显着”负载平衡器设置。正如描述所暗示的那样,我们可以在更复杂的场景中使用它来进行负载平衡,例如负载平衡 PSM。

设置HAProxy

与大多数软件一样,HAProxy 以 Docker 映像的形式提供。使用 Docker,我们可以快速启动并运行 HAProxy,在挂载的卷中传递我们的haproxy.cfg和 TLS 证书。

我们需要一个地方来存储我们的haproxy.cfg配置 HAProxy 和一个地方来存储我们的证书和它的私钥,所以让我们首先创建这些目录。

tim@docker01:~$ mkdir haproxy
tim@docker01:~$ mkdir haproxy/haproxy
tim@docker01:~$ mkdir haproxy/certificates

我们将生成一个自签名证书,因为这是一个实验室环境,但在生产中,我们需要一个由受信任的证书颁发机构颁发的证书。

tim@docker01:~$ cd haproxy/certificates/
tim@docker01:~/haproxy/certificates$ openssl req -x509 -newkey rsa:4096 -keyout tls.pem.key -out tls.pem -sha256 -days 365 -nodes
Generating a RSA private key
..........++++
.......................++++
writing new private key to 'tls.pem.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:192.168.0.115
Email Address []:
tim@docker01:~/haproxy/certificates$

使用文件权限和所有权,使用容器内的 HAProxy 进程创建的私钥将无法读取它。我们将文件更改为由 HAProxy 在容器内运行的用户 ID 拥有。

tim@docker01:~/haproxy/certificates$ chown 99 tls.pem.key

创建我们的haproxy.cfg

在haproxy.cfg中,您将看到两个主要部分:一个代表前端,一个代表后端。

在前端部分,我们指定有关 HAProxy 接收流量的设置。这包括 HAProxy 正在侦听流量的地址和端口等配置,用于保护 HAProxy 和客户端之间通信的 TLS 证书,以及将 HTTP 流量重定向到 HTTPS 的选项。

在后端部分,我们指定 HAProxy 将流量中继到的服务器以及负载平衡策略、更复杂的健康检查和持久会话等选项。

我们将从一些简单的事情开始,以确保它有效:

tim@docker01:~/haproxy/haproxy$
tim@docker01:~/haproxy/haproxy$ vi haproxy.cfg

与内容

frontend pvwa_loadbalancer
  bind *:443 ssl crt /usr/local/etc/certs/tls.pem
  default_backend pvwas

backend pvwas
  server pvwa1 192.168.0.102:443 ssl verify none
  server pvwa2 192.168.0.116:443 ssl verify none

我们的haproxy.cfg非常基础。我们定义一个前端来监听 443 端口并告诉它使用我们之前生成的证书(我们可以只定义证书,HAProxy 将在同一目录中查找名为<certificate filename>.key的私钥,在我们的例子中名为tls.pem.key.) 使用default_backend我们定义了来自前端的流量应该被中继到的后端的名称。

在后端部分,我们定义了将中继到的各个服务器流量。服务器的名称pvwa1和pvwa2是任意的,我们可以随意调用它们,但后端必须命名为pvwas,因为我们将其用作前端中default_backend的值。在指定服务器的地址和 IP 后,我们声明要使用 ssl 连接,因为这是一个实验室环境,我们允许使用verify none在后端 PVWA 服务器上使用无效的 TLS 证书。

生成证书和初始haproxy.cfg后,我们可以启动容器,确保挂载本地卷。

tim@docker01:~/haproxy$ sudo docker run -p 443:443 -v /home/tim/haproxy/haproxy:/usr/local/etc/haproxy:ro -v /home/tim/haproxy/certificates:/usr/local/etc/certs:ro haproxy:latest
[NOTICE]   (1) : haproxy version is 2.5.1-86b093a
[NOTICE]   (1) : path to executable is /usr/local/sbin/haproxy
[WARNING]  (1) : config : missing timeouts for frontend 'pvwa_loadbalancer'.
   | While not properly invalid, you will certainly encounter various problems
   | with such a configuration. To fix this, please ensure that all following
   | timeouts are set to a non-zero value: 'client', 'connect', 'server'.
[WARNING]  (1) : config : missing timeouts for backend 'pvwas'.
   | While not properly invalid, you will certainly encounter various problems
   | with such a configuration. To fix this, please ensure that all following
   | timeouts are set to a non-zero value: 'client', 'connect', 'server'.
[NOTICE]   (1) : New worker (8) forked
[NOTICE]   (1) : Loading success.

启动容器时,我们看到一些关于没有超时的警告,但是通过它加载的负载均衡器导航到 PVWA!

但是在登录后,我们会立即收到有关会话到期的错误消息。

我们基本的haproxy.cfg有点太基本了。没有粘性会话,并且我们没有配置负载平衡方法,因此 HAProxy 在 PVWA 中循环,将下一个请求发送到下一个服务器。另外:我们没有任何健康检查,更不用说可以被视为基于应用程序的健康检查了。

添加粘性会话和应用程序健康检查

我们可以通过简单地将check关键字添加到后端部分中定义的每个服务器来添加基本的健康检查,但仅此一项不会检查 PVWA 的健康状况,而只会检查 IIS 的健康状况。我们还需要将选项 httpchk关键字添加到我们的后端部分。

option httpchk允许我们定义一个 URI。它将向该 URI 发出请求,如果响应返回 2xx 或 3xx 的 HTTP 代码,则 HAProxy 认为服务器是健康的。

由于我们希望 HAProxy 不将流量中继到 PVWA 服务不工作或即使 IIS 正在运行也无法连接到 Vault 的 PVWA,所以我们需要找到正确的 URI,该 URI 将在这些条件下返回不是 2xx 或 3xx 的内容.为了找到这一点,让我们从浏览 Firefox 中的请求开始,当我们浏览到功能性 PVWA 时,当 PVWA 出现问题时,一个或多个返回应该不是 2xx 或 3xx。

为我们的健康检查找到一个URI

让我们通过直接浏览 Firefox 中的 PVWA 来接近客户的方式。在 Web 开发工具](https://developer.mozilla.org/en-US/docs/Tools/Network_Monitor)的焦点中打开[网络监视器选项卡并仅过滤 HTTP 和 XHR 类型的请求,我们导航到 PVWA 之一:

查看所有请求,我们希望将重点放在返回 200 的请求上。理论上所有这些都适用于运行状况检查,但即使 PVWA 不起作用,也可能仍然返回 200。我们应该故意破坏 PVWA 并查看返回的内容。

让我们使用 Windows 防火墙和在 PVWA 上创建一个规则,阻止端口 1858上的出站流量:

确保我们的规则已启用,我们刷新 PVWA:

即使没有与 Vault 的连接,PVWA 仍然会加载 - 有点。在非正常运行状态下,IIS 仍然为加载登录屏幕的前几个请求返回 200,减去要输入凭据的字段。然而,对https://192.168.0.102/PasswordVault/api/settings/authentication的请求失败了,因此它似乎是用于我们的健康检查的完美候选者。

让我们将它作为option httpchk的一部分添加到我们的后端haproxy.cfg中,同时为超时配置添加值,我们在第一次启动 HAProxy 时看到警告:

defaults
  timeout client 10s
  timeout connect 10s
  timeout server 10s

frontend pvwa_loadbalancer
  bind *:443 ssl crt /usr/local/etc/certs/tls.pem
  default_backend pvwas

backend pvwas
  option httpchk GET /PasswordVault/api/settings/authentication
  server pvwa1 192.168.0.102:443 check ssl verify none
  server pvwa2 192.168.0.116:443 check ssl verify none

此外,我们必须将check关键字添加到我们希望对其进行健康检查的后端中的每个服务器。我们需要这个,否则我们的option httpchk实际上一文不值。

粘性会话

粘性会话可以通过多种方式完成,包括通过 cookie 或基于散列的方法。我们将使用棍子表。

我们将使用一个棒表来捕获客户端 IP 地址的信息并将其关联到后端服务器。每次客户端 IP 地址连接时,HAProxy 都会查看棒表以查看先前关联的服务器并将流量中继给它。我们还为这个关联设置了一个过期时间,这样客户端就不会永远“卡”在特定的服务器上。

defaults
  timeout client 10s
  timeout connect 10s
  timeout server 10s

frontend pvwa_loadbalancer
  bind *:443 ssl crt /usr/local/etc/certs/tls.pem
  default_backend pvwas

backend pvwas
  stick-table type ip size 1m expire 15m
  stick on src
  option httpchk GET /PasswordVault/settings/authentication
  server pvwa1 192.168.0.102:443 check ssl verify none
  server pvwa2 192.168.0.116:443 check ssl verify none

用stats完成它

HAProxy 提供了一个方便的统计页面,我们可以使用它来查看我们的前端和后端的大量信息,其中包括后端服务器的运行状况。在我们使用新的haproxy.cfg启动容器之前的最后一步,让我们为统计页面添加一个前端。

defaults
  timeout client 10s
  timeout connect 10s
  timeout server 10s

frontend pvwa_loadbalancer
  bind *:443 ssl crt /usr/local/etc/certs/tls.pem
  default_backend pvwas

backend pvwas
  option httpchk GET /PasswordVault/api/settings/authentication
  server pvwa1 192.168.0.102:443 check ssl verify none
  server pvwa2 192.168.0.116:443 check ssl verify none

frontend stats
  mode http
  bind *:8404
  stats enable
  stats uri /stats
  stats refresh 10s
  stats admin if TRUE

我们在它自己的前端运行stats页面。它将每 10 秒自动刷新一次,因为我们仍处于实验室环境中,所以我们使用stats admin始终返回TRUE(如果我们想要这个产品,我们应该使用至少基本身份验证来保护它,如 HAProxy 示例中所示](https://cbonte.github.io/haproxy-dconv/2.5/configuration.html#4.2-stats%20admin))所以我们可以执行管理任务,例如禁用服务器或整个后端的健康检查,将单个服务器标记为健康或不健康。

我们还需要记住在启动容器时为我们的统计页面发布端口。

运行和测试我们的新haproxy.cfg

首先我们像一开始一样启动我们的容器,但是为我们的统计页面发布了端口 8404:

docker run -p 443:443 -p 8404:8404 -v /home/tim/haproxy/haproxy:/usr/local/etc/haproxy:ro -v /home/tim/haproxy/certificates:/usr/local/etc/certs:ro haproxy:latest

当我们加载统计页面时,我们可以看到我们定义的前端和后端以及关于它们的各种统计信息。在我们的后端,我们能够管理单个服务器或整个后端:

查看其中一个 PVWA,我们可以观察 IIS 日志以查看运行状况检查:

停止 IIS 服务或重新启用我们创建的 Windows 防火墙规则以模拟 PVWA 无法连接到 Vault,后端的服务器在我们的统计页面中变为红色,并且不再将流量中继到它:

前进

通过简单的配置,我们就拥有了一个强大的负载均衡器和基于应用程序的健康检查。我们可以轻松地添加更多功能,例如ZWZ100111标题,使用ZWZ100094 ZWZ100112 ZWZ100095 ZWZ100093关键字到ZWZ100097捕获真实的客户端IP地址,访问我们的Load Balancer ZWZ100010010010010010001000 ZWZ1000 ZWZ1000POR,balance方法的负载均衡方法。

由于 HAProxy 是第 4 层负载均衡器,它不仅限于 HTTP 用例。它可用于负载均衡Privileged Session Manager和Privileged Session Manager for SSH。