seccomp通过禁用socket、bind、connect、listen、accept4、sendto、recvfrom等底层系统调用实现网络限制，推荐采用defaultaction: scmp_act_allow配合scmp_act_errno拒绝策略，并确保规则文件路径正确、权限可读。
Seccomp 本身不直接识别“网络”或“Socket”这类语义概念，它只按系统调用名称（syscall name）和参数做过滤。所谓“禁止网络 Socket 系统调用”，实际是指禁用 socket、bind、connect、listen、accept4、sendto、recvfrom 等与网络通信强相关的底层 syscall。但需注意：盲目全禁会导致容器无法启动（如 Go 程序初始化时会尝试读取 /proc/sys/net/ 目录，触发 socket 相关探测），因此必须结合应用行为精准控制。
明确要禁用的核心 Socket 相关系统调用
以下是最常被用于主动建立或管理网络连接的系统调用，属于高风险拦截目标：
- socket：创建套接字，是所有网络通信起点
- bind：绑定地址端口，常用于服务监听
- connect：发起客户端连接，攻击者常用其外连 C2
- listen 和 accept4：服务端接受连接，暴露监听面
- sendto/recvfrom：UDP 通信主调用，也用于某些原始套接字操作
编写可落地的 Seccomp JSON 规则片段
推荐采用“默认允许 + 显式拒绝”策略（defaultAction: SCMP_ACT_ALLOW），避免白名单遗漏导致容器崩溃。以下规则将阻止任意进程调用 socket 类系统调用，并返回 EPERM 错误：
{
"defaultAction": "SCMP_ACT_ALLOW",
"syscalls": [
{
"names": ["socket", "bind", "connect", "listen", "accept4", "sendto", "recvfrom"],
"action": "SCMP_ACT_ERRNO"
}
]
}
说明：
• 使用 SCMP_ACT_ERRNO 而非 SCMP_ACT_KILL，避免因日志采集、健康检查等短暂调用直接杀死进程；
• 若需更严格防护（如无任何网络需求的离线计算容器），可改用 SCMP_ACT_KILL，内核将立即终止违规进程；
• 不建议对 getsockopt、setsockopt 盲目禁用——它们常被 glibc 或运行时用于查询本地 socket 状态，禁用易致 panic。
验证规则是否生效并定位失败调用
禁用后若容器异常退出或功能失效，需快速确认是否为 Seccomp 拦截所致：
- 在宿主机上运行：dmesg -T | grep "SECCOMP"，查看内核日志中是否有类似 "seccomp killed process" 的记录
- 进入正在运行的容器，执行：strace -f -e trace=socket,connect,bind 2>&1 | head -20，观察哪些调用被阻断及返回值（EPERM 即被 Seccomp 拦截）
- 使用 docker inspect
检查 HostConfig.SecurityOpt是否正确挂载了 seccomp 配置路径
部署注意事项：路径、权限与兼容性
规则文件必须被 Docker daemon 正确加载，否则配置无效：
- 文件须存放在 daemon 可读路径，例如 /etc/docker/seccomp-no-network.json，不能用
./或~/ - 确保 root 用户（daemon 运行身份）有读权限：sudo chmod 644 /etc/docker/seccomp-no-network.json
- 启动容器时显式指定：docker run --security-opt seccomp=/etc/docker/seccomp-no-network.json ...
- Kubernetes 用户需通过
securityContext.seccompProfile字段挂载，且 profile 必须预置于节点/var/lib/kubelet/seccomp/下
