瓦尼什的安全障碍

在Varnish中，安全性是一个非常重要的设计驱动因素，如果您发现自己在想“他为什么要这么做”，很可能不是这样 _that_ ？答案与安全有关。

Varnish安全模型基于各种组件之间的一些非常粗糙但易于理解的障碍：

              .-->- provides ->---------------------------------------.
              |                                          |            |
     (ADMIN)--+-->- runs ----->---.                      |            |
              |                   |                      |            |
              |-->- cli_req -->---|                      v            v
              '--<- cli_resp -<---|                     VCL        MODULE
                                  |                      |            |
     (OPER)                       |                      |reads       |
       |                          |                      |            |
       |runs                      |                      |            |
       |      .-<- create -<-.    |    .->- fork ->-.    v            |
       v      |->- check -->-|-- MGT --|            |-- VCC <- loads -|
      VSM     |-<- write --<-'    |    '-<- wait -<-'    |            |
     TOOLS    |                   |                      |            |
       ^      |     .-------------'                      |            |
       |      |     |                                    |writes      |
       |reads |     |->- fork ----->-.                   |            |
       |      |     |->- cli_req -->-|                   |            |
      VSM ----'     |-<- cli_resp -<-|                   v            |
       |            '-<- wait -----<-|                VCL.SO          |
       |                             |                   |            |
       |                             |                   |            |
       |---->----- inherit --->------|--<-- loads -------'            |
       |---->-----  reads ---->------|                                |
       '----<----- writes ----<------|--<-- loads --------------------'
                                     |
                                     |
                                     |
         .--->-- http_req --->--.    |    .-->-- http_req --->--.
(ANON) --|                      |-- CLD --|                     |-- (BACKEND)
         '---<-- http_resp --<--'         '--<-- http_resp --<--'

(ASCII-艺术规则！)

真正重要的障碍

Varnish中的中心角色是管理器进程“mgt”，这是管理员“(Admin)”开始获取Web缓存服务的进程。

我自己也去过那里，我并不赞同“当我凌晨3点醒来重新启动一个死进程时，我觉得自己很酷、很重要”的学派，事实上，我认为这是愚蠢的一个明显迹象：如果我们不能让电脑重启一个死进程，我们为什么还要有它们？

因此，管理器进程的任务不是缓存Web内容，而是确保始终存在这样一个进程，即子“CLD”进程。

这是Varnish中的主要障碍：所有管理都发生在一个进程中，所有实际的流量移动都发生在另一个进程中，而管理器进程根本不信任子进程。

子进程处于完全不受保护的域中：Internet上的任何计算机(Anon)都可以连接到子进程并请求一些Web对象。

如果说约翰·D·罪犯成功地利用了瓦尼什的安全漏洞，那么他所颠覆的就是儿童进程。如果他实施DoS攻击，那么他试图攻击的是子进程。

因此，管理器实际上以尽可能低的特权启动该子进程，并关闭它不应该访问的所有文件脚本，依此类推。

返回管理器进程的通信通道只有三个：退出代码、CLI响应或将内容写入用于统计和日志记录的共享内存文件“VSM”，所有这些都由管理器进程很好地保护。

管理/操作障碍

如果您查看该图的左上角，您将看到Varnish使用单独的管理员“(Admin)”和操作员“(Opper)”角色进行操作。

管理员做事情，改变事情等等。操作员密切关注事情，以确保它们是应该的。

现在操作员通常是脚本和数据收集工具，没有理由认为它们是无错误的，所以Varnish不信任操作员角色，这是纯粹的单向关系。

(诀窍：如果子进程在用户“noboble”下运行，您可以允许受信任程度较低的操作人员访问“noboble”帐户(例如，使用.ssh/AUTHORIZED_KEYS2)，他们将能够终止子进程，并提示管理器进程使用相同的参数和设置再次重新启动它。)

管理员拥有最终决定权，当然，管理员可以决定在哪些情况下共享该权限。

不用说，如果运行Varnish的系统没有得到适当的保护，管理员对控制的垄断将受到损害。

所有其他障碍

有更多的障碍，您可以通过图中的箭头发现它们，但它们更多的是一种“技术”而不是“政治”，通常试图防止编程缺陷以及安全危害。

例如，VCC编译器在一个单独的子进程中运行，以确保编译器中的内存泄漏或其他缺陷不会为管理器进程积累麻烦。

希望这一解释有助于理解为什么Varnish不像所有其他服务器程序那样只是一个进程。

保尔-亨宁，2010-06-28