Varnish的安全问题

在Varnish中，安全问题是一项非常重要的设计驱动力，当你意识到”他为什么 _那样_ 做呢？”，就需要使用安全角度来寻找答案。

Varnish安全模型基于一些粗糙但是易于理解的障碍实现，障碍存在于各个组件之间:

              .-->- provides ->---------------------------------------.
              |                                          |            |
     (ADMIN)--+-->- runs ----->---.                      |            |
              |                   |                      |            |
              |-->- cli_req -->---|                      v            v
              '--<- cli_resp -<---|                     VCL        MODULE
                                  |                      |            |
     (OPER)                       |                      |reads       |
       |                          |                      |            |
       |runs                      |                      |            |
       |      .-<- create -<-.    |    .->- fork ->-.    v            |
       v      |->- check -->-|-- MGR --|            |-- 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-ART rules!)

真正重要的障碍

在Varnish中进程管理是一个关键角色，”MGR”是进程的管理员”(ADMIN)”，MGR启动在Varnish成为web缓存服务时。

以为我自己的经历来说，我不觉得”在凌晨3点起床重启一个dead进程又酷又重要”，事实上，我认为那是一个带有愚蠢思维的表示：假如我们没有电脑重启进程，那么我们为什么还要这么做？

“管理进程”的任务不是做网站内容缓存的，而是确保”CLD（子程序）”去做缓存内容的事情。

Varnish中现有的主要障碍是：所有的管理工作在一项进程中，所有实际流量操作在另一个中，并且管理进程完全不信任子进程。

子进程完全处于不被保护的区域：网络上任何电脑都可以连接子进程并请求网站缓存信息。

John D. Criminal如果想利用Varnish安全漏洞进行入侵，那他就需要干掉子进程，假如他要进行DoS工具，那么他就需要把子进程打下来。

所以在实际中，管理进程会以非常低权限启动子进程，我们关闭了这些子进程可以访问的所有范围脚本。

存在三种与管理进程后台通信的渠道：一类是退出代码，一类是CLI响应，还有用于统计和记录写入共享内存中的”VSM”文件，上面这三种都是靠”管理进程”来定义的。

管理/操作障碍

在图的左上角，你可以看到Varnish操作分为”ADMIN”和”Operator”角色。

管理员做的操作包括处理事情和修改某些等操作。操作员的做用是确保这些事情就是他们应该做的。

操作员通常是些脚本和数据收集工具，没有任何理由把他们假设成bugfree，所以Varnish不信任操作员这个角色，他们之间是一种纯粹的单向关系。

（小贴士：若子进程以”nobody”用户运行，让可信任人做访问’nobody’用户（例如使用.ssh/authorized_keys2），那么管理进程就会杀死这些子进程，并以相同的参数和设置重启。）

操作是管理员说了算，当然管理员可以决定再何种情况下将这一权力共享。

毫无疑问，如果varnish运行在一个不安全系统上，管理员的控制垄断就会受到危害。

其他障碍

在图中，还有很多障碍，这些障碍与”政治性的”相比，更近乎”技术性”，一般情况下，这些障碍更倾于妥协，与程序的漏洞而言。

例如在VCC编译里面运行一个独立子进程，为了确保内存缺陷和其他缺陷，不在管理进程里面不会堆积更多问题，

希望这个解释能有助理解为什么Varnish相对其他程序来说不是一个独立进程。

Poul-Henning, 2010-06-28