学习 eBPF

第 9 章 安全的 eBPF

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

你已经看到 eBPF 如何用于观察整个系统的事件，并将这些事件的相关信息报告给用户空间工具。在本章中，你将了解如何在事件检测概念的基础上创建基于 eBPF 的安全工具，以检测甚至阻止恶意活动。首先，我将帮助你理解安全与其他类型的可观察性的不同之处。

备注

本章的示例代码位于GitHub 代码库的chapter9目录中。

安全可观察性需要政策和背景

安全工具与报告事件的可观察性工具的区别在于，安全工具需要能够区分正常情况下的预期事件和表明可能正在发生恶意活动的事件。例如，假设有一个应用程序在正常处理过程中会向本地文件写入数据。假设该应用程序会写入/home/<username>/<filename>，那么从安全角度来看，您不会对这种活动感兴趣。但是，如果应用程序写入 Linux 中的许多敏感文件位置之一，您会希望得到通知。例如，它不太可能需要修改存储在/etc/passwd 中的密码信息。

策略不仅要考虑系统完全正常运行时的正常行为，还要考虑预期的错误路径行为。例如，如果物理磁盘满了，应用程序可能会开始发送网络信息来提醒这种情况。这些网络信息不应被视为安全事件--即使它们不寻常，也不可疑。考虑到错误路径可能会给创建有效策略带来挑战，我们将在本章稍后讨论这一挑战。

定义什么是预期行为，什么不是预期行为是策略的工作。安全工具会将活动与策略进行比较，并在活动超出策略范围、变得可疑时采取一些措施。这种行动通常包括生成安全事件日志，该日志通常会被发送到安全信息事件管理（SIEM）平台。它还可能导致向人工发出警报，后者将被要求调查所发生的事件。

调查人员获得的上下文信息越多，就越有可能找出事件的根本原因，并确定这是否是一次攻击、哪些组件受到了影响、攻击是如何发生的、何时发生的以及谁应对此负责。如图 9-1 所示，能够回答这样的问题使工具从单纯的日志记录转变为 "安全可观察性"。

图 9-1. 为实现安全可观察性，在检测政策外事件的同时还需要上下文信息

让我们来探讨一下 eBPF 程序用于检测和执行安全事件的一些方法。如你所知，eBPF 程序可以附加到各种事件上，而多年来常用于安全的一组事件是系统调用。我们将从系统调用开始讨论，但正如你所看到的，系统调用可能并不是使用 eBPF 实现安全工具的最有效方法。本章稍后我们将介绍一些更新、更复杂的方法。

使用系统调用处理安全事件

系统调用（或称系统调用）是用户空间应用程序与内核之间的接口。如果能限制一个应用程序所能发出的系统调用，就能限制它所能做的事情。例如，如果您阻止一个应用程序发出open*() 系列的系统调用，它就无法打开文件。如果你有一个应用程序，而你从未指望它打开文件，那么你可能想创建这种限制，这样即使该应用程序被入侵，它也无法恶意打开文件。如果你在过去几年中一直在使用 Docker 或 Kubernetes，那么你很有可能已经接触过一种使用 BPF 限制系统调用的安全工具：seccomp。

Seccomp

seccomp是 "安全计算 "的缩写。在其原始或 "严格 "形式中，seccomp 用于将一个进程可使用的系统调用限制为一个很小的子集：read() ...