veth本身不劫持流量，但内核漏洞可破坏其依赖的隔离基础，导致逃逸后篡改网络配置；应封堵漏洞利用链、禁用高危模块、强化nftables策略并监控敏感系统调用。
宿主机内核漏洞本身不会直接让 veth 对“主动劫持”流量，但会破坏 veth 所依赖的隔离基础——比如通过命名空间逃逸、procfs/sysfs 越权访问、overlayfs 权限绕过等手段，使攻击者能在容器内篡改宿主机网络配置、注入恶意 iptables/nftables 规则、或直接修改 netns 内部路由和接口状态，从而间接控制 veth 通信路径。因此，解决思路不是修 veth，而是封堵漏洞利用链，加固底层执行边界。
快速验证是否已受内核漏洞影响
在容器内执行以下命令，若返回异常结果，说明隔离可能已被突破：
- 检查是否能访问宿主机 procfs：`ls /proc/1/ns/`（正常应 Permission denied）
- 尝试挂载伪文件系统：`mkdir /tmp/test && mount -t proc proc /tmp/test 2>/dev/null && ls /tmp/test/1/ 2>/dev/null`（成功即逃逸）
- 探测 AF_ALG/splice 利用面（针对 CVE-2026-31431）：`grep -q "authencesn" /proc/crypto && echo "AF_ALG enabled"`
从内核层切断常见劫持入口
多数 veth 流量劫持依赖于内核漏洞触发的越权操作，需针对性关闭高危子系统：
- 禁用危险模块：`echo 'install af_alg /bin/true' >> /etc/modprobe.d/disable-afalg.conf`，再 `sudo modprobe -r af_alg`
- 限制 proc/sysfs 暴露：启动容器时加 `--security-opt=no-new-privileges:true --read-only --tmpfs /tmp:rw,size=10m`
- 关闭未使用的命名空间：Docker 启动参数中显式禁用 `--userns-remap=default --ipc=private --uts=private`
- 对 overlayfs 漏洞（如 CVE-2021-3493），升级内核至 5.11+ 或打补丁，并避免在容器中执行 chmod/chown on whiteout 文件
强化 veth 通信本身的可控性
veth 是通道，不是防线，但可通过配置大幅压缩攻击窗口：
- 所有 veth 接口仅分配私有 CIDR（如 172.30.0.0/28），禁止使用 169.254.0.0/16 或宿主机所在网段
- 每个命名空间内只保留一条精确 host-route：`ip route add 172.30.0.2/32 via 172.30.0.1 dev veth0`，不设默认网关
- 在两端命名空间启用 nftables，默认 DROP，仅放行 ESTABLISHED/RELATED 和明确目的 IP+端口：`nft add rule ip filter forward iifname veth0 oifname veth0 ip daddr 172.30.0.2 tcp dport {22, 80} ct state new accept`
- 禁用 IPv6（除非必需）：`sysctl -w net.ipv6.conf.all.disable_ipv6=1`，并在 netns 内重复执行
运行时监控与阻断关键逃逸行为
即使内核存在漏洞，也可在利用链关键节点实时拦截：
- 部署 eBPF 工具（如 Tracee 或 Cilium Tetragon）监控 `mount`, `setns`, `capset`, `splice` 等敏感系统调用，对非白名单进程触发告警并 kill
- 定期扫描容器内是否存在异常 netns 挂载点：`find /proc/*/ns -lname "*net:*" 2>/dev/null | xargs -r ls -l`
- 用 `auditd` 记录 `iptables`, `nft`, `ip link` 命令执行日志，规则示例：-a always,exit -F arch=b64 -S execve -F exe=/usr/sbin/iptables -k firewall-change
