Gui774ume/network-security-probe

# 网络安全探针 作为应用程序安全工程师，我们要不断寻找保护服务安全的新方法，并将其权限降至仅绝对必要的最低限度。在网络方面，切断通往外界的出口流量并根据逐个服务减少内部访问权限，一直是两项首要任务。然而，随着云计算服务和容器编排系统（如 Kubernetes）的普及，基于静态 IP 的解决方案正变得过时。 随着 Kubernetes 等容器编排技术的普及，部署微服务变得前所未有的容易。尽管 Kubernetes 开创了 DevOps 的突破，但也引入了一个新的安全隐患：过去托管在独立机器上的服务，现在可以在容器中并肩运行，共享相同的内核和其他主机级资源。这意味着，如果没有 Kubernetes 级别的控制，任何主机级别的访问控制都很难区分不同的服务。 网络安全探针为这一局限性提供了解决方案，重点利用 eBPF 执行进程级的网络安全监控和执行。尽管已有多种工具利用 eBPF 来监控和执行网络规则（例如 Kubernetes 中的 [Cilium](https://docs.cilium.io)），但其中大多数仅在接口级别应用这些规则。通过引入更细粒度的解决方案，恶意网络活动可以被映射回特定进程。这极大地改善了调查工作，通过提高执行准确性避免了不必要的停机，并为更快的响应时间铺平了道路。 如需了解该项目的更完整介绍及其架构描述，请前往 [SSTIC 2020 大会发表的文章](https://www.sstic.org/2020/presentation/process_level_network_security_monitoring_and_enforcement_with_ebpf/)。 ## 需求 该项目是在 Linux ubuntu-bionic 上开发的，内核版本为 4.15.0。 脚本 `env_setup.sh` 将为您设置一个包含所需依赖项的 vagrant 虚拟机（需要 virtualbox 和 vagrant）。 ## 入门指南 1. Vendor go 依赖项。如果您想通过使用 `hack/update-codegen.sh` 来更改 SecurityProfile 自定义资源，则需要手动克隆 `https://github.com/kubernetes/code-generator`（分支 `v0.17.0`）到 `/vendor/code-generator`。 ``` go mod vendor ``` 2. 构建网络安全探针。 ``` make build ``` 3. （可选）构建演示所用的 ping、pong 和 attacker 容器。 ``` make demo ``` 4. 网络安全探针将警报发送到 [Datadog](https://www.datadoghq.com/)。获取并导出您的 Datadog API 密钥。 ``` export DD_API_KEY=**** ``` 5. 启动 Datadog Agent ``` make run_agent ``` 6. （可选）启动一个 minikube 集群，该集群将用于演示。 ``` sudo minikube start --vm-driver=none --kubernetes-version=1.17.0 ``` 7. 启动网络安全探针。 ``` make run ``` 8. （可选）启动 ping-pong 演示。 ``` sudo helm install ping-pong static/charts/ping-pong ``` 9. （可选）在修改 `static/charts/ping-pong/templates` 中的配置文件后，您可以使用以下命令更新它们 ``` sudo helm upgrade ping-pong static/charts/ping-pong ``` 更改将自动被 NSP 识别，新的配置文件应在几秒钟内应用。 ## Ping-pong 演示 Ping-pong 演示包含 3 个简单的 Pod： - 一个 `pong` Pod，包含一个监听 `0.0.0.0:80` 的简单 Web 应用。其 SecurityProfile 定义在 `static/charts/ping-pong/templates/pong-profile.yaml` 中。 - 一个 `ping` Pod，定期访问 pong 端点。其 SecurityProfile 定义在 `static/charts/ping-pong/templates/ping-profile.yaml` 中。 - 一个 `attacker` Pod，没有任何配置文件。 您可以使用这个简单的应用程序在运行时阻止或允许 `ping` 和 `pong` Pod 之间的通信。您还可以使用 `attacker` Pod 触发 `pong` 服务中的 RCE（远程代码执行）漏洞，并查看该项目具有何种日志、警报和执行能力。SSTIC 大会录制了一个完整的演示，您可以在[这里](https://www.sstic.org/2020/presentation/process_level_network_security_monitoring_and_enforcement_with_ebpf/)观看。 ## 性能与开销 使用基于 eBPF 的工具时，需要评估两种开销。第一种开销是用户空间程序的资源使用情况。分配给我们的安全代理的资源越多，生产环境中运行的服务可用的资源就越少，因此服务的响应速度就越慢。第二种开销是内核内开销。换句话说，这是工具对每个出口或入口数据包引入的延迟。在 eBPF 程序中推入的逻辑越多，每个数据包的开销就越大。 我们决定将基准测试工作的重点放在我们已知开销最大的数据包上：DNS 请求和响应数据包。由于我们在内核中解析 DNS 请求和响应以匹配域名，因此这些数据包是延迟最严重的。我们还想将我们的结果与 Cilium 进行比较，后者在处理 DNS 数据包时采用了不同的策略：Cilium 将 DNS 流量转发到 DNS 代理，并在用户空间进行评估。那么，该项目与像 Cilium 这样生产就绪的解决方案相比如何呢？  每个域名的平均往返时间（每个域名平均超过 5000 次 A 记录查询）。测试在 Linux ubuntu-bionic 4.15.0-88-generic，2 vCPU，8 GB 内存的环境下进行。请记住，Cilium 的功能比网络安全探针多得多，比较的目的仅仅是评估该项目与生产就绪解决方案相比的开销。  用户空间程序随时间变化的 CPU 和 RAM 使用情况。 尽管确实需要更多测试才能准确评估真实环境中的开销，但这些结果似乎证实了将网络数据包映射回进程并在运行时评估每个数据包的做法并没有危险信号。最坏情况下的开销约为 400 微秒，大约是 Cilium 开销的一半。这似乎证实了从性能角度来看，内核内 DNS 解析是一个好策略（但请记住，我们的 DNS 支持目前仅是部分的，没有循环的 DNS 解析很难）。此外，请记住，400 微秒是针对需要最多处理的数据包的最坏情况。我们的基准测试显示，对于普通数据包，我们工具的实际开销接近 200 微秒，而 Cilium 为 250 微秒。无论哪种情况，这些开销在生产环境中都是可以接受的。

标签：CISA项目, DLL注入, Docker镜像, EVTX分析, EVTX分析, IP 地址批量处理, JSONLines, Lerna, Linux内核, Syscall, Web开发, Web截图, 子域名突变, 容器安全, 微服务安全, 数据处理, 日志审计, 时间线生成, 流量审计, 溯源分析, 监控工具, 策略执行, 网络安全, 网络策略, 网络访问控制, 进程级监控, 隐私保护, 零信任