Security first 安全第一
如果你仅仅抓专注于运行varnish,或者所有人都是这个观点,那么就可以跳过该节了.我们保护你的方方面面当http请求来的时候.
如果你的web基础设施是外包的,管理是分开的,那么你就需要考虑安全了. Varnish在4个权威的等级提供安全,大致关系到怎样让命令生效和在哪儿生效.
- the command line arguments,
- the CLI interface,
- VCL programs, and
- HTTP requests.
Command line arguments 命令行参数
最高安全定理是决定和定义varnish的启动参数在一个表单里面,我们使用这个策略是为了新的操作也是安全的. 最重要的的决定是确保这些:
- Who should have access to the Command Line Interface? 谁有命令行的权限?
- Which parameters can they change? 他们可以修改哪些参数?
- Will inline-C code be allowed? 哪些内建C代码是被允许的?
- If/how VMODs will be restricted? 是否VMODs是被限制,怎样被限制?
CLI interface access CLI接口权限
命令行接口可以通过三个方式进入. Varnish监听状态时，提供给CLI链接一个TCP套接字。你可以绑定这个套接字在内核接受的任意地方。
-T 127.0.0.1:631 -T localhost:9999 -T 192.168.1.1:34 -T ‘[fe80::1]:8082‘
默认配置‘-T localhost:0‘将挑选一个随机端口，通过使用varnishadm(8)可以在共享内存中了解到。
使用localhost地址，仅仅限制本机的链接。
你也可以绑定端口在网络可达的物理地址，然后让其他机器直接连接。
这不是保密的，CLI命令讲作为非加密的ASCII文本进行网络传输，但是-S/PSK需要远程终端知道共享密钥。
你可以绑定CLI端口在localhost，使用ssh/vpn或者类似的协议，给远程用户一个安全连接到本机的权限。
如果使用ssh每个用户可以执行那些命令，就像varnishadm，或者封装一个仅仅允许执行特定CLI命令的varnishadm.
你也可以配置varnishd反向监听模式，使用‘-M‘参数。varnishd尝试给指定的地址打开一个TCP连接，然后给vanish管理设备发起一个CLI连接。
这个连接也是非加密的，但是远程终端必须满足-S/PSK认证。
最后，如果你使用‘-d‘模式运行varnish，你可以获得一个CLI命令在标准输入和标准输出，但是一旦你开始进程，还有什么能阻止你活取CLI权限，不是么？
CLI interface authentication CLI接口认证
默认的CLI接口被一个简单却强壮的"Pre Shared Key"认证模式，但是不提供加密（例如，CLI命令和响应是非加密的）.
-S/PSK工作原理真的很简单：当varnish安装，使用随机内容创建了一个文件，这个文件仅仅只有启动varnish的用户（或者超级用户）才有权限。
为了认证和使用CLI连接，你需要知道这个文件的内容，为了了解挑战加密的问题。
(XXX: xref to algo in refman) .. XXX:Dunno what this is? benc
varnishadm 使用这些策略来限制权限，仅仅在varnishadm起作用和需要它的时候才读取密钥文件。
如果你打算允许其他用户，本地的和远程的，为了获得CLI的权限你可以创建自己的密钥文件，同时只可能被这些用户读取。
一个创建密钥文件的好方法是：
dd if=/dev/random of=/etc/varnish_secret count=1
当你启动varnishd，你通过‘-S‘指定密钥文件名,同时没有说明varnishd主进程也需要读取文件。
当varnishd运行的时候你也可以修改密钥文件的内容，因为每次CLI连接认证时都读取密钥文件。
在本地系统你可以通过共享内存来恢复密钥文件名，但是在远程系统，你需要使用‘-S‘参数给varnishadm复制一个密钥文件。
如果你要禁用 -S/PSK认证，指定‘-S‘一个空的参数给varnishd：
varnishd [...] -S "" [...]
Parameters 参数
varnish可以是通过命令行设置参数，同时添加‘-r‘参数作为只读模式，这样的话就不能在CLI接口修改参数了。
相当多的参数可能搞砸你的http服务,但是有些是更严重的:
user and group 用户和组 Access to local system via VCL 通过VCL认证本地系统. listen_address 监听地址 Trojan other TCP sockets, like ssh 入侵其他tcp套接字,不如ssh cc_command Execute arbitrary programs 执行随意程序. vcc_allow_inline_c Allow inline C in VCL, which would any C code from VCL to be executed by Varnish. 允许C代码在VCL中,哪些代码C代码可以在varnish里呗执行.
Furthermore you may want to look at and lock down: 此外你可能想看:
syslog_cli_traffic Log all CLI commands to syslog(8), so you know what goes on.CLI命令的所有日志你可以查看syslog(8) vcc_unsafe_path Restrict VCL/VMODS to vcl_dir and vmod_dir 限制VCL/VMODS的vcl_dir和vmod_dir. vmod_dir The directory where Varnish will will look for modules. This could potentially be used to load rouge modules into Varnish.
这个目录里可以看到很多模块,罗列了可以载入到varnish的潜在模块.
The CLI interface CLI接口
CLI接口功能强大,只要你有权限连接到CLI接口,你可以对varnish进程做几乎所有的事情.
正如之前的描述,一些有危害的参数可以被限制,但是这些都只能保护本地文件系统和操作系统,并不能保护你的http服务.
当前我们还没有办法对特定的CLI连接限制特定的CLI命令.有个办法就是封装可能有影响的连接在一个预认证的脚本里,
使用varnishadm(1)提交CLI审核命令,同时限定远程用户只能通过这些脚本来连接,例如使用sshd(8)的配置.
VCL programs VCL程序
在VCL模式中有两个危险的机制:VMODs和inline-C.
这两个机制允许执行任意代码,因此允许用户获得机器的权限和说有child进程的权限.
如果varnish使用root/supper启动,我们在沙箱里运行的child进程可以使用任何可以在操作系统上使用的工具,但是如果不是,就不需要考虑这些了.不要问我为什么你会用超级用户来启动一个只需要低权限的child进程.
Inline-C在varnish4.x启动时是不起作用的,除非启用了Inline-C,所以你不用担心它.
之前提到的参数可以限制加载VMODS只能在指定的目录,限制VCL争议者在一个VMODs的预认证子集.
如果你这样做,我们确信你的本地系统在使用VCL模式不可能缺乏攻击抵抗能力.
HTTP requests http请求
我们竭尽所能的使vanish抵抗那些通过套接字接收的http请求,同时你可能,通俗来说,不需要你进一步的保护.
这个警告自从VCL变成可编程语言,让你决定完全对HTTP请求做些什么的语言,你也可以使用VCL决定做些愚蠢和潜在危险的事情,包括开启你自己的各种攻击和破坏性的活动.
如果你需要管理(包括,修改,删除,产生新动作等等)‘HTTP‘请求,例如PURGE请求,我们强烈建议你限制这些操作,使用VCL的权限控制列表来允许信任的ip或着网络才能管理HTTP请求.