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

Table Of Contents

Previous topic

Picking platforms

Next topic

What were they thinking ?

This Page