# 信息安全综合实践<br><span style="font-size: 70%">第二次汇报</span> 穆柯橪 谢庆贺 王纪开 白泽龙 刘相儒 ---- **目录** - OpenStack 环境搭建 —— 白泽龙 - OpenStack 测试环境 MicroStack，CentOS 7 镜像制作及Wazuh 搭建测试 —— 穆柯橪 - `Docker` 环境搭建&安全问题调研 —— 谢庆贺 - 针对 OpenStack 的攻击防御 —— 王纪开 ---- ## OpenStack 环境搭建 白泽龙 ---- ### 安装 此处为手动安装OpenStack环境，由于OpenStack为组件的方式，我们需要类似搭积木一样搭建OpenStack环境。 - 配置统一NTP服务 - 安装依赖组件 - Memcached （身份认证） - MySQL （数据存储） - etcd （KV存储） - RabbitMQ （消息队列 组件间通信） ---- - 安装相关组件 - keystone 身份认证 - glance 镜像服务 - placement 安置服务 - nova 计算服务 Compute - neutron 网络服务 SDN ----  ----  ----  ----  ----  ----  ----  ---- <img src="https://md.byr.moe/uploads/upload_446a99d0f574850270cea31370f119ad.png" height="80%" width="80%"> ----  ---- ### 值得注意的问题 在配置neturon时，`vxlan`的local_ip由于官方文档的说明不够详细，我们需要将其设置为当前出口网络的物理ip地址  ---- 默认安装情况无法发现硬盘，解决方法暂时使用cinder <img src="https://md.byr.moe/uploads/upload_f2b0b3e533e4bfa075f7ec789fb9f79c.png" width="60%" height="60%"> ----  ---- ## OpenStack 测试环境 MicroStack，CentOS 7 镜像制作及Wazuh 搭建测试 穆柯橪 ---- ### MicroStack ```bash sudo snap install microstack --beta --devmode sudo microstack init --auto --control 两句话搞定 keystone, glance, nova, neutron 等服务 ``` - MicroStack 是 Ubuntu 提供的用于快速搭建 OpenStack All-In-One 环境的 snap 工具； - 适合在单机测试环境使用。 ---- **问题一：配置 cinder-volumes** <span style="font-size: 90%"> - cinder 是 OpenStack 的云硬盘组件，类比阿里云的云盘，可以为实例提供额外的存储空间；（Flavors 处配置的 Root Disk 为默认给虚拟机配置的根目录空间，不能被多个虚拟机共享） - MicroStack 自动配置的 cinder 组件没有自动对 pv（Physical Volumes）vg（Volume Groups）做调整，而 cinder 服务默认使用名为 cinder-volumes 的 vg 分配云硬盘，即建立 lv（Logical Volumes）； - 需要手动使用 parted 建立一个独立的物理分区，然后使用 pvcreate 创建这个 pv，最后使用 vgcreate 创建名称为 cinder-volumes 的 vg。 </span> ----  ----  ----  ---- **问题二：cinder 服务容易 down** 还未找到问题根源 ---- ### CentOS 7 镜像制作 <span style="font-size: 90%"> - 目的：避免每次申请云主机后重复对系统进行安装配置； - 过程：提前在虚拟环境中完整安装系统，并**安装云环境需要的组件**，再将所有需要的额外工具和包安装在系统中，最后做收尾工作，即删除敏感信息，并打包为 qcow2 镜像文件，并上传至 glance 镜像服务。 - 注意事项：安装系统最好使用 QEMU（OpenStack 使用 QEMU 作为虚拟化引擎），使用 VMware 等其他的虚拟化工具可能会影响系统安装参数，影响在 QEMU 中的系统运行。 </span> ---- **CentOS 7 推荐安装的组件** <span style="font-size: 80%"> |组件|作用| |---|---| |acpid|处理 libvirt 发出的软重启、软关机事件| |qemu-guest-agent|类似于VMWare Tools，在客户机中安装一个设备，作为 QEMU 外部控制的 “后门”，可以用于外部修改用户密码（需要在镜像 metadata 中设置 hw_qemu_guest_agent=yes）| </span> ---- <span style="font-size: 80%"> |组件|作用| |---|---| |cloud-init|cloud-init 是云环境虚拟机利器，cloud-init 服务会自动请求 OpenStack metadata 服务获取配置信息，完成主机名设置、密码初始化、SSH 密钥注入等操作| |growpart|Flavor 中指定的根目录大小需要自动扩容，growpart 能帮助完成该工作| </span> ---- CentOS 7 需要执行的配置： <span style="font-size: 80%"> |配置|作用| |---|---| |echo "NOZEROCONF=yes" >> /etc/sysconfig/network|关闭 zeroconf 服务自动建立的 169.254.0.0 路由，保证 metadata 服务地址 169.254.169.254 能够被访问| </span> - 配置完成后，在宿主机使用 virt-sysprep 工具移除宿主机网络等信息，并使用 glance 上传镜像。 ---- **问题三：glance 镜像上传不完整导致实例无法启动**  - nova-compute 服务中的 log 如上图，导致这个的原因有可能是因为使用 openstack 命令上传镜像时出现异常，导致镜像损坏； - 事实上即使使用命令行上传镜像返回成功也有可能导致该问题； - 解决方案是删除镜像后重新上传。 ----  ---- **问题四：qemu-system-agent sock 文件创建失败** ``` Unable to bind to UNIX socket path '/var/lib/libvirt/qemu/org.qemu.guest_agent.0.instance-0000001a.sock': No such file or directory ``` - 在启用 hw_qemu_guest_agent 后出现上述错误，初步猜测是 QEMU 并没有正常地生成 sock 文件，可能和 QEMU 的配置有关。 ----  ----  ----  ----  ---- ### Wazuh 搭建测试 - Wazuh Server 依赖于 ElasticSearch、Filebeat 和 Kibana； - 其中 ElasticSearch 作为数据的汇总、搜索和分析引擎；Filebeat 负责收集 Server 产生的警告和事件并存储至 ElasticSearch 中；Kibana 为 ElasticSearch GUI，Wazuh 编写了 Kibana 插件提供 Wazuh 的 GUI。 ---- Wazuh 特点 - Wazuh 不带远程控制功能，所有 Agent 的配置在本地，无法远程进行修改； - Server 仅负责收集并处理数据； - 所有扫描为主机 Agent 服务监控/定时运行并反馈。 ----  ----  ---- <img src="https://md.byr.ac.cn/uploads/upload_6c0986a20a970a59b8e3af1076172f4b.png" height="80%" width="80%"> ---- ## `Docker`环境搭建&安全问题调研 谢庆贺 ---- 首先需要卸载本机`oldversion`的`docker` ```shell= sudo yum remove docker \ docker-client \ docker-client-latest \ docker-common \ docker-latest \ docker-latest-logrotate \ docker-logrotate \ docker-engine ``` ---- 此外在`/var/lib/docker/`目录下存放着用户所有的`images`, `containers`, `data volumes`和`networks`。 - 想要彻底清除`docker`可以将此文件夹清空。 - 想保留本地镜像容器等信息可以不做处理，重新安装不同版本`docker`后镜像容器等不会受到影响。 ---- `CentOS 7`用脚本安装指定版本`docker`，方便快捷 ```shell= curl -fsSL https://get.docker.com -o get-docker.sh && \ sudo VERSION=version_you_want sh get-docker.sh sudo systemctl start docker ``` ---- - `Docker`安全的攻击面多与容器相关，例如针对容器运行时的攻击等。 - 容器运行时（Container Runtime) 的定义是：能够基于在线获取的镜像来创建和运行容器的程序，`1.11`版本后的`runC`和其之前的`containerd`是典型代表。 ---- - 所以`Docker`安全大多数时也更通俗的被人们理解为容器安全(实际上容器只是`docker`的一个重要组件)。 - **而容器的本质为进程，只不过其与普通的进程相比多了`Linux`内核支持的各种资源隔离**，其没有自己的`kernel`，与宿主机共享`kernel`，只有一套自己的`bins/libs`，这也是其轻量级的原因，没有`VM`冗余的开机等待时间。 ---- `VM`和`Docker`的区别 <img src="https://md.byr.moe/uploads/upload_0642e161672b915f6d58d868dcba36aa.png" style="zoom:100%;" /> <img src="https://md.byr.moe/uploads/upload_dc2d5e32ea4e65e91722bb3e29103411.png" style="zoom:100%;" /> ---- `Docker`的核心技术有三： - **NameSpaces** - **CGroups** - **UnionFS/Storage Driver** ---- - `NameSpaces`负责进程间，文件系统，网络的隔离。 - `CGroups`负责物理资源上的隔离，对容器的资源使用进行限制。 - `Storage Driver`是存储驱动，主要涉及镜像的产生原理和`lay`的概念(可读写的容器层建立在只读的镜像层上)，所以镜像可被多个容器引用。 ---- 简单的进程隔离  ---- - 众所周知，`Docker Engine`为开源的`go`项目，`go`本身自带内存安全，内存的安全管理无需开发人员顾虑，而是由编译器负责。 - 这导致在代码层面挖掘/利用`docker`的安全漏洞变得非常困难，目前还没有`1day`从`docker`代码层面攻击成功。 ---- - 更多的安全研究员们将目光朝向**逻辑漏洞**。 - 成熟且复杂的系统(eg. Linux)的魅力在于其能够提供强大的功能和机制，**而问题则往往出现在这些功能与机制同时或交替生效的场景中**，有时我们会把这类问题称为逻辑漏洞。 - 针对逻辑漏洞的利用可以是简单甚至优雅的，但最初把各种机制放在一起检查到底有没有漏洞、有什么漏洞却并不容易。 ---- - A机制是安全的，B机制是安全的，但当A和B交叠在一起并在某些特殊状态下可能会产生一些让人意想不到的漏洞，逻辑漏洞的发现往往需要对机制较深的理解和一定的想象力和观察能力。 - `Open Source Summit Europe 2019`上，有议题展示了“命名空间”与“符号链接”两个概念放在一起出现的一系列问题 => [传送门](https://osseu19.sched.com/event/TLC4/in-and-out-security-of-copying-to-and-from-live-containers-ariel-zelivansky-yuval-avrahami-twistlock)。 ---- - 除去`docker`本身的漏洞之外，还有其他方面的漏洞也会导致`docker`逃逸。 - 配置特权模式方面 - `--privileged`参数赋予容器对宿主机所有文件系统/设备访问的权限，非常危险。 - `-cap-add=SYS_ADMIN`参数开启时容器被允许执行mount、umount等一系列系统管理操作，同样非常危险。 - 配置挂载不当 - 暴露到公网的`Docker.sock`。 - 内核提权漏洞 - 存在`Dirty Cow`漏洞(CVE-2016-5195)时逃逸。 ---- - 我对部分`Docker`自身的逻辑漏洞进行了调试研究。 ---- <span style="font-size: 120%"> CVE-2019-5736 </span> - `docker version`<`18.09.2` 或 - `runc version` <= `1.0-rc6` - 漏洞: `docker`对容器运行时加入容器`NameSpaces`后对`/proc/self/exe`此`magic link`防范缺失。 - 攻击效果: 以宿主机`root`权限任意代码执行。 ---- 攻击效果 <img src="https://md.byr.moe/uploads/upload_8c4661d04b1f2fa56bedbca3e05e467c.png" style="zoom:140%" /> ---- <span style="font-size: 120%"> CVE-2019-14271 </span> - `docker version`=`19.03.0` - 漏洞: `docker-tar`进程加载`image`内的动态库。 - 攻击效果: 修改宿主机文件系统。 ---- 攻击效果  ---- <span style="font-size: 120%"> CVE-2020-15257 </span> - `containerd.io version`<=`1.3.7` - `containerd.io version`<=`1.4.1` - 漏洞: 以`--network=host`启动容器时，由`containerd-shim`监听的不受`mntns`隔离的抽象`UnixSocket`将暴露在容器中。 - 攻击效果：以宿主机`root`权限任意代码执行。 ---- 攻击效果  ---- ## 针对 OpenStack 的攻击防御 王纪开 ---- - 能否使用qemu相关漏洞攻击openstack？ - qemu中不少漏洞发生在有问题的设备驱动程序中，需要确定openstack/libvirt最终能用到哪些设备，从而确定进一步的调研方向。 ---- ```xml <domain type='kvm'> <name>demo2</name> <uuid>4dea24b3-1d52-d8f3-2516-782e98a23fa0</uuid> <memory>131072</memory> <vcpu>1</vcpu> <os> <type arch="i686">hvm</type> </os> <clock sync="localtime"/> <devices> <emulator>/usr/bin/qemu-kvm</emulator> <disk type='file' device='disk'> <source file='/var/lib/libvirt/images/demo2.img'/> <target dev='hda'/> </disk> <interface type='network'> <source network='default'/> <mac address='24:42:53:21:52:45'/> </interface> <graphics type='vnc' port='-1' keymap='de'/> </devices> </domain> ``` ---- - OpenStack生成libvirt的xml实例配置。 - libvirt的xml转换成qemu命令行参数：`virsh domxml-to-native` 但是会大量使用预先打开的资源（继承给qemu） - libvirt本身的安全机制。 ---- - 理论上说，使用qemu提供的任意设备是可能的。qemu支持的设备都可以分配给虚拟机 openstack通过libvirt调用底层虚拟化组件（qemu），通过libvirt的[特殊配置](https://libvirt.org/drvqemu.html#qemucommand)可以向qemu传递任意命令行，开启qemu的对应设备。而openstack也可以通过一定方法自行修改虚拟机实例的libvirt的配置文件。 ---- <span style="font-size: 120%"> CVE-2020-25743 </span> - QEMU < 5.1.1 - IDE硬盘的DMA传送=>Null Pointer解引用漏洞 - 攻击效果:qemu崩溃，造成拒绝服务 ---- - ide_cancel_dma_sync 函数没有检查空指针，导致拒绝服务攻击 - `void ide_cancel_dma_sync(IDEState *s)`函数中`IDEState`结构体的`blk`成员为null时，调用该函数会使Qemu崩溃。 - 攻击者使用恶意的系统镜像，即可导致计算节点的底层虚拟化组件（qemu）崩溃。