iptables 的 -m owner 模块不能可靠按 gid 限制出站连接，因主流内核（centos 7+/ubuntu 18.04+）在 output 链不支持 --gid-owner，会报错或静默失效；仅 --uid-owner 稳定可用，建议改用专用 uid 或 cgroup/systemd 方案。

iptables 可以通过 owner 模块 对特定用户组（GID）发起的出站连接实施网络访问控制，但仅限于 OUTPUT 链，且有明确适用边界。

适用前提与限制

该能力依赖内核模块 xt_owner，需满足：

• 内核已启用 CONFIG_IP_NF_MATCH_OWNER=y/m（主流发行版默认支持）
• 执行命令需 root 权限或 CAP_NET_ADMIN
• 运行 iptables -m owner --help 能显示 --gid-owner 选项
• 仅对本机主动发起的新连接（SYN 包）生效；已建立连接不受影响
• 不适用于 systemd 服务、setuid 程序（如 sudo/ping）、容器内进程——这些场景下 GID 信息在协议栈中不可靠

按 GID 设置基础策略

假设目标用户组名为 developers，GID 为 1002：

• 先查 GID：getent group developers | cut -d: -f3 或 id -g developers
• 放行必要基础通信（顺序关键，必须在拒绝前）：
  iptables -A OUTPUT -m owner --gid-owner 1002 -d 127.0.0.0/8 -j ACCEPT
iptables -A OUTPUT -m owner --gid-owner 1002 -p udp --dport 53 -j ACCEPT
• 拒绝其余所有外连：
  iptables -A OUTPUT -m owner --gid-owner 1002 -j REJECT --reject-with icmp-host-prohibited

实际生效范围说明

规则只管控该组成员以普通权限启动的交互式进程，例如：

• 用户 alice 属于 developers 组，她运行的 curl、wget、git clone 会受控
• 但若她用 sudo apt update，因 sudo 是 setuid 程序，实际 socket 创建 UID/GID 不匹配，规则不触发
• 同样，systemd 启动的 nginx 即使配置为 Group=developers，也不受此规则约束

验证与维护建议

确认规则是否起效：

• 切换到组内用户测试：sg developers -c "curl -I http://example.com"，应失败
• 查看匹配计数：iptables -L OUTPUT -v -n | grep "gid-owner 1002"，观察 packets 是否增长
• 清理残留连接（可选）：conntrack -D --orig-src 0.0.0.0/0 --orig-dst 0.0.0.0/0，避免旧连接绕过新策略
• 保存规则持久化：iptables-save > /etc/iptables/rules.v4（Debian/Ubuntu）或 service iptables save（RHEL/CentOS 6）

不复杂但容易忽略：它不是“禁止某个组上网”，而是“禁止该组普通用户进程发起的新外连”，设计时需结合实际使用模式评估效果。