TurnKey Linux 应用设备倒置代理机后置

A. 国家反向代理服务器是一个服务器,它位于一个或多个“真正的”服务器之间,服务于想要的内容和另一个网络,通常是互联网。它可用于提供高可用性 (例如,如果您的主服务器崩溃,则会掉在服务器上)和/或一种通过单个(通常是公用)IP托管多个服务器的方法,通常包括SSL/TLS终止. 在"自我托管"(很多TurnKey用户都这样做)时,利用一个单一的IP托管多个服务器是相当常见的.

网络设置看起来有点像:

                                                backend server 1
                                               /
internet/external network <-> reverse proxy <-> backend server 2
                                               \
                                                backend server 3

背景和概览

有大量目的所建的逆向代理,加上常见的网络服务器,如Apache,Nginx和LigHTTPd都可以配置,以起到反向代理的作用. 因此,这个员额并不寻求提供任何软件建议,也不详尽地涵盖软件的具体配置. 当它提到配置时,一般会限于Apache和/或Nginx：作为最受欢迎的网络服务器. 它将触及一些特定配置,以用于有限的使用案例,但一般会更深入地审视一般的网络设计和考虑. 本页面的主要目的是检查和解释逆向代理服务器和后端服务器之间连接的不同选项. 它将主要关注反向代理服务器和后端服务器的连接的配置/设计.

历史上,默认配置反向代理的方法是在反向代理中执行TLS/SSL(即https)终止,并仅使用香草http(即. 未加密, 反向代理服务器和后端服务器之间的"平面文本"流量( plain text). 这样做是有效的,如果后端网络与任何潜在的恶意行为者或受损设备隔离,它也可以足够安全。

然而,这些天,这种设置一般被认为是不安全的。这是因为使用plain http可以让任何进入网络的人浏览网络流量,并截取密码等敏感数据. 也没有机制通过http、a确认服务器的身份。 MITM 密码攻击是微不足道的。

因此,一般建议在您的反端代理服务器和后端服务器之间使用 https 通信. 但即使可以以多种不同的方式配置, 每一种都提供它自己的优势和劣势。不管怎样,让我们快速看看各种选项。希望所有重要和共同的都被提及,但这不会是一份详尽的清单.

选项

所有选择方案都使安全和必要的努力之间达成妥协。我已经提供了一个总体的,更高层次的选项概述, 但是让我们得到一些更具体, 并更细分。我所看到的是共同的选择,其模糊的顺序不太安全,甚至更难(有些排名值得商榷)。然后我们潜入每个地方需要更多注意的努力

http - 未加密, 纯文本 http
https - 自签名证书; 由反向代理忽略证书
https - 由反向代理验证的自签名证书( Cert & CA; cert)
https - "适当" CA 签名通配符; 证书由反向代理验证
https - "proper" CA 签名特定的证书; 证书由反向代理验证

http - 未加密, 纯文本 http

如上所述,这是历史设定的"默认",一旦配置,一般"只是工作",并继续"永远"这样做,无需任何干预. 从前它也非常容易设置;因为大多数服务器经常被设计出从盒子中通过http主机.

然而,由于流量被传输到没有加密,任何与后端服务器相同的网络上的恶意演员/设备都很容易拦截流量(例如: .steal 密码等,也许更糟),同样由于没有验证后端服务器,使得MITM攻击变得微不足道.

至于努力,如果你正在从头开始建立自己的所有服务器,那么这可能需要最少的努力. 虽然您使用 TurnKey, 它将依赖于特定的应用设备。我们的许多应用设备重定向到 https, 至少是用于登录( 以减少密码浏览的风险 ) 。其中很多还需要能够通过特定预设域连接,因此将重新定向到此上. FQDN 密码默认情况下,域重定向可能不会是一个问题,一般情况下,你的反向代理只允许通过域连接,所以这不应该是一个问题。然而,显然将http重定向到https(支持只连接http)将引起问题。

总之,虽然这不是一个特别安全的设置,但假设你信任所有能够连接到后端服务器所在网络的人和装置,我认为这是完全合法的配置。

如何选择

要让这个设置与 TurnKey 后端服务器( 或者另一个将 https 重定向到 https 的服务器) 工作, 您需要禁用 https 重定向。事实上, 完全禁用 https 可能是合理的。在 Apache 配置中, 寻找端口 80 虚拟主机中以“ 重写” 或“ 重定向” 开头的行。 Nginx中,再次在端口中查找重定向 80 虚拟服务器配置;查找开始"返回 30x"(其中x为数字)或"方向"的行.

https - 自签名证书; 由反向代理忽略证书

使用此选项, 您的后端服务器会被反向代理通过 https 访问, 但是它们只是使用自签名的证书( 在您的网络中发出恐怖警告的证书) 。浏览器),这种配置模型是一种安全升级,因为它意味着流量被加密,因此监视被屏蔽. 然而,由于无法验证后端服务器是您认为的,MITM攻击仍然可行(并且和Plain http一样容易).

此选项需要您反向代理配置做一些更多的工作, 并且某些特定的反向代理软件可能不会支持这种方法。多数反向代理应该支持这个选项, 如果使用 TurnKey 作为您的后端服务器, 这将需要您的后端服务器零努力, 并且应该“ 工作” - 尽管如果有方向转向域, 您将会需要确保您不会在字体端上这样做, 这可能导致一个递归方向回路。

如何选择

制作此工作所需的所有配置都需要在反向代理上完成. AFAIK Nginx默认此行为 - 即. 它忽略了证书是自签名的证书的事实, 无论如何连接。对于更多关于 Nginx 配置的信息, 请检查指令文件.

Apache需要一些额外的配置。我不会去讨论细节,但需要使用 SSLProxy*指令指令,例如, SSLProxy 检查PeerCN 软件财务报告和已审计财务报表 SSLProxy 检查程序Name.

https - 由反向代理验证的自签名证书( Cert & CA; cert)

此选项是进一步的安保升级, 因为超越了先前选项, 验证也会发生。使用此选项意味着监视和MITM 攻击都行不通。缺点是,需要花费一些额外的努力来生成一个 CA(证书授权) 密钥和(再) 生成自签名的证书,由您的 CA 密钥签名。 CA(公用)密钥也需要存储在反向代理上.

风险在于如果CA私人密钥可以被恶意角色找到,那么他们也可以生成自己的证书,与你的反向代理一起工作. 可以通过生成和存储所需的证书到其他地方(如第三服务器),不允许任何访问私人 CA 密钥来缓解这种情况. 另一种缓解方式是确保解锁 CA 键对也需要密码句. 然后攻击者还需要知道密码,以及可以使用私人钥匙。有了这些缓解措施,这个选项可能就足够安全了。由于您控制 CA, 如果您愿意的话, 证书会非常长的寿命( 这意味着它很少需要更新) 。或者你可以设置第三个服务器,这样它就可以将更新的证书自动推到后端服务器(尽管降低了密码句的值).

如何选择

我知道,Apache和Nginx都可以使用这个选项. 可惜我并没有具体的指示需要手动,但几乎肯定会用他们的名字包含"sl"(sl)和可能"ca"(也可能是"代用"). 如前所述,由于Nginx默认不认证证书,所以您会希望启用此证书.

https - "适当" CA 签名通配符; 证书由反向代理验证

"wildcard"证书是特殊的TLS/SSL证书,对多个子域有效. E. *.example.com的通配符证书对www.example.com、docs.example.com和blog.example.com(etc)有效。在您的后端服务器上使用通配符,其安全配置与上下选项相似,尽管Vaildation是通用的,而不是具体的. I.e. 在验证证书的同时, 您无法确定您正在连接的后端服务器。仍然应该相当安全,虽然如果攻击者获得进入你的后端服务器, 他们可以偷取通配符并用它来做一些其他服务器/服务“ 有效 ”。

如何选择

除了在更新时获取和分发新证书的机制外,不应需要额外的配置. 虽然我在上面指出 Nginx默认不会验证证书,所以你会想启用这个.

https - "proper" CA 签名特定的证书; 证书由反向代理验证

在现代,我们拥有服务,例如 Let's Encrypt 密码, IMO 这是最简单和最好的选项。您可以得到一个反向代理的好处, 并且有一个“ 独立” 服务器的安全性, 它拥有自己的合法 CA 签名证书。如果有可能移动此服务器直接公开面对,则这是一个特别好的选择。并应该“工作”(而且仍然安全)。

由于您的后端服务器会拥有自己的合法 CA 签名证书, https 连接将有效, 并且应该"只工作" 。您还得到了一个“ 免费” 加密连接的加固安全性。

如何选择

TurnKey 后端服务器, 您可以调用 Confconsole 高级菜单以获取“合适的” Let's Encrypt 证书。默认( HTTP-01) 验证也需要访问端口 80, 但这不应该要求您反向代理上过多的额外配置。域权威验证也可以通过DNS(DNS-01)进行,后者是一个替代选项(也支持DNS-01),尽管IMO HTTP更容易.