Maltrail Docker 部署指南：单镜像承载 Server 与 Sensor 的构建、权限模型与安全姿态

Maltrail Docker 部署指南单镜像承载 Server 与 Sensor 的构建、权限模型与安全姿态【免费下载链接】maltrailMalicious traffic detection system项目地址: https://gitcode.com/GitHub_Trending/ma/maltrail本指南以仓库 docker/README.md 为主体系统讲解 Maltrail 的容器化部署一条命令用 Docker Compose 同时启动服务器Server与传感器Sensor、在非特权前提下通过精确的两个 Linux capabilities 完成抓包、解决 bind mount 与容器内非 root 用户之间的目录属主适配并掌握仅运行 Server、仅运行 Sensor、部署自检、健康检查与镜像供应链验证等实战技能。阅读并实践本文后你将能独立完成一套可对外接收远程 Sensor 上报、数据可持久化、权限最小化且可被 CI 验证的 Maltrail Docker 部署。快速开始一条命令启动全套仓库根目录下的 docker/docker-compose.yml 定义了两个服务server与sensor共用同一个镜像。从仓库根目录执行docker compose -f docker/docker-compose.yml up -d该命令会构建一个同时包含服务器与传感器Rust 实现的镜像并启动两者。构建上下文是仓库根目录context: ..因为 Dockerfile 需要整棵树来编译传感器并拷贝服务器代码。启动后报告界面reporting UI位于 http://localhost:8338服务器默认命令为python3 server.py监听 8338/tcp报告 UI与 8337/udp事件接收传感器运行maltrail-sensor使用network_mode: host并仅附加NET_RAW与NET_ADMIN两个 capability不以privileged运行。如需手动构建镜像同样必须从仓库根目录执行构建上下文需包含整个仓库树docker build -f docker/Dockerfile -t maltrail .镜像里到底跑什么服务命令说明serverpython3 server.py报告 UI 监听 8338/tcp事件接收监听 8337/udpsensormaltrail-sensornetwork_mode: hostNET_RAWNET_ADMIN——非privileged传感器刻意使用宿主机网络命名空间在默认 bridge 网络内它只能看到容器自身的流量而无法采集宿主机网络的真实流量。它不依赖privileged提权抓包恰好需要且只需要两个 capability镜像就只授予这两个见 docker/docker-compose.yml 中cap_add注释NET_RAW用于打开 AF_PACKET 套接字NET_ADMIN用于混杂模式与 PACKET_FANOUT。镜像构建是两阶段完成的见 docker/Dockerfile第一阶段在rust:1-slim-bookworm中编译maltrail-sensor先拷贝Cargo.toml/Cargo.lock以缓存依赖层再拷贝源码并strip二进制第二阶段基于python:3.12-slim-bookworm拷贝整个仓库与编译产物安装libpcap0.8仅运行库不安装 -dev与tini保证信号能送达进程并以tini作为 PID 1 入口。配置与数据bind mount 与命名卷maltrail.conf以只读方式从仓库根目录 bind mount 进容器compose 中的../maltrail.conf:/opt/maltrail/maltrail.conf:ro因此配置直接在宿主机上编辑、重启容器即可生效。两个命名卷承载必须在重建镜像后仍存活的状态maltrail-logs→/var/log/maltrail事件日志maltrail-state→/var/lib/maltrailtrail 规则集请将配置中的TRAILS_FILE指向/var/lib/maltrail/trails.csvmaltrail.conf 第 488-489 行给出了 systemd 语境下的同一路径这样每次容器启动时 trail 规则集不会被重复重建。关于该配置项core/settings.py 中会将其规范化未设置时回退到~/.maltrail/trails.csv并经过expanduser与abspath处理镜像内已通过ENV HOME/var/lib/maltrail将默认路径指向状态卷。此外docker/Dockerfile 特别注释了VOLUME的声明时机VOLUME必须在chown之后声明因为 Docker 会在声明VOLUME的瞬间对镜像内容做快照过早声明会让后续层的属主修复永远无法进入卷——这一点是通过实际运行镜像验证的而非阅读文档得出结论。bind mount 与非特权用户uid 自动适配两个进程默认以uid/gid 10001用户maltrail运行而非 root。但 bind mount 保留的是宿主机目录的属主它会覆盖镜像内预先准备好的属主设置。过去-v ./logs:/var/log/maltrail配合由登录用户拥有的./logs会导致容器无法创建当天的日志文件——而由于日志文件只在第一条事件到达时才打开容器表现为“启动了、UI 正常、却什么都没记录”的静默失败。现在无需任何手动处理docker/entrypoint.sh 以 root 身份运行几毫秒判断哪个 uid 能写入日志与状态目录然后在传感器或服务器启动前通过setpriv降权。其决策规则如下遇到的情况entrypoint 的做法命名卷或未挂载任何东西以 10001镜像自带用户运行属主为 uid 1000 的 bind mount以 1000 运行—— 你的文件仍是你的属主为root:1000且组可写保持 uid 10001采用 gid 1000root 所有的 bind mount接管该目录属主以 10001 运行设置了PUID/PGID一律使用指定值不管目录属主如何给了--user且目录不可写拒绝启动并明确指出是哪个目录、为什么因此docker run -v $PWD/logs:/var/log/maltrail ...无需在宿主机上执行任何chown写入的事件归属你的用户而不是需要sudo才能读取的系统 uid。这套行为由 docker/tests/entrypoint_test.sh 对真实 Docker daemon 逐行断言并运行于 CI。有两个值得记住的后果镜像没有USER指令因此docker exec进入的是 root。想以进程实际运行的用户身份获得 shell请用docker exec -u maltrail或-u 1000。--user会完全禁用这套自动适配——没有 root 就没有可用来适配的东西。此时容器只检查目录是否可写并在不可写时响亮地失败而不是带着一半功能启动。entrypoint 的实现细节docker/entrypoint.sh值得一提它用setpriv --reuid/--regid --clear-groups /usr/bin/test -w以“将要变成的用户”身份测试可写性而不是去推断 mode 位这样补充组、ACL 与只读挂载给出的答案与传感器实际运行时完全一致对 root 拥有但组可写的目录如root:staff 775它只“加入该组”而不 chown仅当目录内容确属镜像自建全新命名卷属主即默认 uid时才递归 chown对挂载进来的宿主机目录只改目录本身的属主绝不chown -R别人宿主的树。Trails 不烘焙进镜像早期版本在构建时运行更新器并在容器内放一个 cron 任务现在两者都不再做把约 200 万个指标烘焙进镜像会使镜像体积巨大且在发布那一刻就已过期容器内的 cron 则是需要额外监管的第二个进程没有任何收益。如今服务器与传感器都在启动时以及每个UPDATE_PERIODmaltrail.conf 默认 86400 秒自行刷新 trail数据落入状态卷。这也解释了为什么TRAILS_FILE必须指向/var/lib/maltrail/trails.csv只有落在持久卷上冷启动后的首次 trail 构建约一两分钟才不会反复发生。仅运行 Server接收远程 Sensor 上报docker run -d --name maltrail-server \ -p 8338:8338/tcp -p 8337:8337/udp \ -v /etc/maltrail.conf:/opt/maltrail/maltrail.conf:ro \ -v maltrail-logs:/var/log/maltrail \ -v maltrail-state:/var/lib/maltrail \ maltrail:latest这正是镜像的默认命令CMD [python3, server.py]因此无需覆盖任何东西——也无需任何 capability服务器不抓包既不需要NET_RAW也不需要NET_ADMIN。镜像内置的HEALTHCHECK请求服务器自身的/ping端点并期待pong响应常量定义于 core/settings.py 的PING_RESPONSE因此无需上述 capability 也能通过健康检查。仅运行 Sensor对接已有服务器docker run -d --name maltrail-sensor \ --network host --cap-add NET_RAW --cap-add NET_ADMIN \ -v /etc/maltrail.conf:/opt/maltrail/maltrail.conf:ro \ -v maltrail-state:/var/lib/maltrail \ maltrail:latest maltrail-sensor在该配置中将LOG_SERVER设为服务器 8337/udp 端口的地址maltrail.conf 中支持 IPv4、带作用域的 IPv6 等形式传感器即可把事件上报给远端服务器。检查一次部署是否可用docker compose -f docker/docker-compose.yml run --rm sensor maltrail-sensor -T-T即--test-config会校验配置、trails、白名单、日志目录、抓包过滤器和权限若传感器无法正常工作则非零退出。sensor/src/main.rs 中该选项的语义是“不抓包即可校验一切然后退出0 可用1 不可用”。Compose 的run --rm会临时拉起一个执行完即销毁的传感器容器非常适合作为部署后冒烟检查。安全姿态两个进程都以非特权用户maltrail默认 uid 10001运行与 systemd unit 保持一致。二者都不需要 root传感器获得CAP_NET_RAW与CAP_NET_ADMIN服务器只绑定非特权端口。compose 文件不是privileged的。只有 docker/entrypoint.sh 以 uid 0 运行且只持续到它决定采用哪个 uid 为止它通过setprivexec真正的命令因此容器内没有任何残留的 root 进程。这也正是cap_add之所以能生效的关键Docker 只会把请求的 capability 放进bounding集而ambient集保持为空ambient capability 只能由以 root 启动的进程提升。若把USER maltrail烘焙进镜像--cap-add NET_RAW会让传感器的CapEff变成0000000000000000抓包套接字以EPERM失败entrypoint 脚本注释中给出了 3.1 镜像上的实测记录。现在的实现是entrypoint 在降权前解析/proc/self/status的CapBnd仅当maltrail-sensor或sensor.py在命令行中时才通过setpriv --inh-caps/--ambient-caps携带net_rawbit 13与net_adminbit 12于是传感器以 uid 10001 获得CapEff: 0000000000003000——且只有传感器如此服务器保持零 capability。健康检查的设计同样值得展开镜像自带的HEALTHCHECK询问服务器是否在服务因为镜像默认命令是server.py请求/ping并期待pong。它不运行maltrail-sensor -T——那是对服务器容器提出的错误问题除非配置恰好设置了DISABLE_CHECK_SUDO-T会因缺少服务器既不需要也不拥有的CAP_NET_RAW而失败导致一个配置正确的 server-only 部署自报不健康issue #19596 中实测仅此一项就 exit 1。一个在正确配置下无法通过的健康检查比没有更糟——它会训练人们忽略健康状态。compose 文件中 sensor 服务覆盖了健康检查为maltrail-sensor -T于是“不健康”意味着传感器真正失去了检测能力——配置错误、trails 不可读、日志目录不可写——而不是“PID 1 还存在”。start-period: 180s覆盖首次 trail 构建。HEALTHCHECK不会经过ENTRYPOINT所以该覆盖显式调用/usr/local/bin/maltrail-entrypoint否则-T将以 root 运行而 root 能写任何日志目录——这恰恰是该检查要抓的问题之一。发布镜像为多架构linux/amd64、linux/arm64并携带构建来源build provenance证明可确认某个镜像是由此仓库的发布工作流构建的gh attestation verify oci://ghcr.io/stamparm/maltrail:3.0 --repo stamparm/maltrail小结Maltrail 的 Docker 化设计围绕三条主线最小权限非 root 运行 恰好两个 capability entrypoint 短暂提权后彻底降权、数据与镜像解耦trails 不入镜像、命名卷持久化、bind mount 属主自动适配与可验证性-T预检、针对服务器与传感器的差异化健康检查、针对 entrypoint 行为表的真实 daemon 测试。对照 docker/Dockerfile、docker/entrypoint.sh、docker/docker-compose.yml 与 docker/tests/entrypoint_test.sh 阅读本文即可把这套部署模型复用到你的监控网络中。【免费下载链接】maltrailMalicious traffic detection system项目地址: https://gitcode.com/GitHub_Trending/ma/maltrail创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考