auditd与iptables需联动，因auditd记录进程级行为（如谁执行curl），iptables记录网络五元组（如连向哪个ip），二者日志分离且无上下文关联，仅联动才能拼出“www-data用curl访问185.120.219.44”等完整攻击链。
Linux 运维中，单靠 auditd 或 iptables 各自记录，容易出现行为断点：auditd 知道“谁执行了命令”，但不知道“这个命令连到了哪里”；iptables 知道“哪个IP发起了连接”，却不清楚“是哪个进程、哪个用户发起的”。把两者联动起来，才能拼出完整攻击链——比如定位到是 /usr/bin/curl 以用户 www-data 身份，向一个异常 IP（如 185.120.219.44）发起了出站 HTTPS 请求。
为什么 auditd 和 iptables 需要联动？
auditd 记录的是进程级行为（系统调用、文件访问、命令执行），粒度细但无网络上下文；iptables/nftables 记录的是网络连接五元组（源IP、目的IP、端口、协议、状态），有网络路径但无进程归属。两者日志时间戳可能差几毫秒，又分属不同日志文件（/var/log/audit/audit.log vs /var/log/messages 或 journalctl -u systemd-journald），不关联就等于各记各的“半本账”。联动不是为了炫技，而是让一次可疑出站行为能同时被“进程画像”和“网络画像”交叉验证。
用 auditd 捕获出站进程信息
核心思路：监控所有 execve 系统调用，并过滤出明确用于网络通信的命令（如 curl、wget、nc、python -c "import socket" 等）。不建议全量监控 execve（日志爆炸），应聚焦高风险工具：
- 在 /etc/audit/rules.d/10-network-tools.rules 中添加规则：
-a always,exit -F arch=b64 -S execve -F exe=/usr/bin/curl -k net_curl
-a always,exit -F arch=b64 -S execve -F exe=/usr/bin/wget -k net_wget
-a always,exit -F arch=b64 -S execve -F exe=/usr/bin/nc -k net_nc
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/python3 -F argc=3 -k net_python
- 加载规则：sudo augenrules --load && sudo systemctl restart auditd（RHEL 8+/Ubuntu 22.04+）或 sudo service auditd reload（CentOS 7）
- 验证是否生效：sudo ausearch -k net_curl -i | grep -E "(exe|comm|cwd|cmdline)"，应能看到完整命令行（如 curl -X POST https://185.120.219.44/api）
用 iptables/nftables 记录对应出站连接
仅记录 OUTPUT 链中的新连接（--ctstate NEW），避免日志冗余。重点打标，便于与 auditd 日志对齐：
- 对于使用 iptables 的系统（如 Ubuntu 20.04、Debian 11）：
sudo iptables -t filter -I OUTPUT -m state --state NEW -m tcp -p tcp --dport 443 -j LOG --log-prefix "NET-OUT-HTTPS: "
sudo iptables -t filter -I OUTPUT -m state --state NEW -m tcp -p tcp --dport 80 -j LOG --log-prefix "NET-OUT-HTTP: "
sudo iptables -t filter -I OUTPUT -m state --state NEW -m udp -p udp --dport 53 -j LOG --log-prefix "NET-OUT-DNS: "
- 对于使用 nftables 的系统（如 RHEL 9、Ubuntu 22.04+）：
sudo nft add rule ip filter output ct state new tcp dport { 80, 443 } log prefix "NET-OUT-WEB: "
sudo nft add rule ip filter output ct state new udp dport 53 log prefix "NET-OUT-DNS: "
- 确保日志写入 /var/log/messages 或 journald，并确认 rsyslog/rsyslogd 已配置接收 kern.* 或 kern.info 级别日志
日志关联分析实战技巧
联动的价值体现在分析阶段。关键不是堆日志，而是建立时间与行为锚点：
- 提取 auditd 中某次可疑 curl 的精确时间戳（单位为秒+纳秒，如 1749482641.123456789），转换为标准时间：ausearch -k net_curl -i | head -1 | awk '{print $3" "$4}' | xargs -I{} date -d @{} "+%b %d %H:%M:%S"
- 在同一分钟内搜索 syslog/journal 中带对应前缀的日志：journalctl -S "2026-06-09 15:24:00" -U "2026-06-09 15:25:00" | grep "NET-OUT-HTTPS"
- 若发现目标 IP 匹配，再反查该 IP 是否在 auditd 日志中还触发过其他命令（如 python + nc 组合），即可判断是否为横向移动或 C2 通信
- 进阶：用脚本自动关联，例如用 ausearch -k net_curl -i --raw | aureport -f -i --key net_curl 提取 cmdline，再用 awk 提取域名/IP，最后用 grep 在 iptables 日志中匹配
