iptables本身不直接做异常分析，而是通过计数器、LOG模块和conntrack提供原始流量数据，供后续工具进行行为识别与关联分析。
iptables 本身不直接做“异常分析”，但它是最底层、最可靠的流量数据采集入口。真正实现异常行为识别，需要把 iptables 采集的原始计数、连接状态或日志，交给后续工具处理。关键在于：怎么采得准、采得轻、采得可关联。
用计数器做轻量级流量统计
这是最常用也最省资源的方式，适合长期运行、按 IP/端口/协议维度做粗粒度监控。
- 添加规则时指定目标链（如 INPUT/OUTPUT），并确保规则位置合理（一般放在链开头或结尾，避免被 DROP 规则截断）
- 示例：统计发往 192.168.1.100:80 的所有入向流量
sudo iptables -I INPUT -d 192.168.1.100 -p tcp --dport 80 -j ACCEPT - 查看时加 -v -n -x 参数，输出精确字节数和包数：
sudo iptables -L INPUT -v -n -x | grep "192.168.1.100" - 注意：计数器只累计匹配该规则的数据包，不区分 ESTABLISHED/NEW，也不记录时间戳，所以适合趋势观察，不适合会话还原
用 LOG 模块捕获事件级行为
当需要知道“谁在什么时候尝试了什么”，比如暴力破解、扫描、非常规端口访问，LOG 是首选。
- 规则中加入 -j LOG --log-prefix "SSH-SCAN: "，日志会写入 /var/log/messages 或 rsyslog 配置的专用文件
- 推荐搭配 --log-level 4（warning 级别）避免刷屏，再用 rsyslog 把特定前缀日志分离到独立文件，例如：
if $msg contains 'SSH-SCAN' then /var/log/iptables-ssh.log - 日志包含源IP、目标IP、协议、端口、TCP标志位等字段，可直接被 fail2ban、ELK 或自定义脚本消费
- 慎用无限制 LOG：建议配合 -m limit --limit 5/min 防止日志爆炸
用 conntrack 实时跟踪连接状态
iptables 计数器和日志都偏静态，而 conntrack 提供的是动态连接视图，对识别扫描、短连接洪泛、NAT 映射异常特别有用。
- sudo conntrack -L 查看当前所有 tracked 连接（含超时时间、状态、方向）
- sudo conntrack -E 实时监听连接创建/销毁事件（需 root 权限），适合对接流处理系统
- 结合过滤更高效：比如只看新建立的 SSH 连接
sudo conntrack -E -p tcp --dport 22 --state NEW - 注意：conntrack 表大小有限，高并发场景需调大 net.netfilter.nf_conntrack_max
与后端分析系统衔接的关键点
采集只是第一步，让数据真正可用，要解决三个问题：时间对齐、字段标准化、上下文关联。
- 所有采集源（iptables 日志、conntrack 事件、tcpdump 样本）务必启用 NTP 时间同步，否则多源比对会失真
- 日志格式尽量统一：例如用 JSON 输出（可通过 rsyslog template 或 logrotate 后处理），方便下游解析
- 不要孤立看单条规则——比如 INPUT 中某 IP 的大量 NEW 包 + OUTPUT 中对应大量 REJECT 包，可能就是探测响应；这类模式需跨链、跨工具聚合判断
- 中小型 VPS 推荐组合：iptables LOG + rsyslog 分流 → Telegraf 读取日志 → InfluxDB 存储 → Grafana 可视化告警
