DiegoRSMachado/lab-firewall-iptables
GitHub: DiegoRSMachado/lab-firewall-iptables
基于 iptables 的 Linux 主机防火墙加固脚本，集成 Wazuh 实现端口扫描与暴力破解等安全事件的 SOC 检测与告警。
Stars: 0 | Forks: 0
# 实验室 — 防火墙加固 + SOC 检测 (iptables → Wazuh)
使用 `iptables` 进行主机边界加固（白名单机制，IPv4 + IPv6，
暴力破解防护，受控日志记录与持久化），**集成**到
Wazuh 的检测中，并将映射到 MITRE ATT&CK 的端口扫描和 SSH 暴力破解进行关联。
学术/受监督实验室 (SENAC-DF)。防御性 — Blue Team。
## 文件
| 文件 | 功能 | 目标 |
|---|---|---|
| `hardening_firewall.sh` | 应用并持久化防火墙规则 | 目标主机 |
| `local_decoder.xml` | 解析 `FIREWALL_DROP` 日志 (srcip, dstport…) | `/var/ossec/etc/decoders/` |
| `local_rules.xml` | 关联规则 (扫描 / 暴力破解) | `/var/ossec/etc/rules/` |
| `sigma_iptables_portscan.yml` | 便携式 Sigma 规则 (T1046) | 检测仓库 |
## 防御架构
入站采用 **default DROP** 策略；仅放行严格必要的流量，顺序如下：
丢弃无效状态 → loopback → 已建立的连接 → 受控的 ICMP →
SSH (限制网络范围 + rate limit) → web → 受限的 NRPE → 其余流量均被记录并丢弃。
| 向量 | ATT&CK | 应用的控制措施 | D3FEND |
|---|---|---|---|
| SSH 暴力破解 | T1110 | `recent`：来自同一源 IP 的 >3 个 NEW 连接/60秒 → LOGDROP；范围限制在 `MGMT_NET` | D3-ITF |
| 端口/服务扫描 | T1046 | default DROP + 按源 IP 关联丢弃事件 | D3-NTF |
| 暴露服务漏洞利用 | T1190 | NRPE 5666 仅限 Nagios IP 访问；web 可选 | D3-ITF |
| 欺骗 / 逃避 | T1090 | 丢弃 `INVALID` 状态；loopback 反欺骗 | D3-NTF |
| 利用 IPv6 绕过 | — | 镜像 `ip6tables` 配置 (保留 ICMPv6/NDP) | D3-ITF |
## 如何使用
### 1. 调整参数
在 `hardening_firewall.sh` 的顶部编辑您实验室的 IP：
```
MGMT_NET="192.168.56.0/24" # rede autorizada a falar SSH
NAGIOS_SERVER="192.168.56.10" # único IP liberado no NRPE
ALLOW_WEB="true" # 80/443
ALLOW_PING="true" # ICMP echo rate-limited
```
### 2. (前置条件) 持久化
```
sudo apt update && sudo apt install -y iptables-persistent netfilter-persistent
```
### 3. 防止锁定自己的安全网 (远程执行)
在通过 SSH 应用规则之前，安排一个补救任务，以便在您将自己锁定在外时清除防火墙规则：
```
echo "iptables -P INPUT ACCEPT; iptables -F" | sudo at now + 5 minutes
# 如果在验证后仍保持连接，请取消兑换：
sudo atq # veja o ID do job
sudo atrm
```
### 4. 应用
```
sudo bash hardening_firewall.sh
sudo iptables -L -n -v --line-numbers # conferir
```
### 5. 接入 Wazuh 检测
```
sudo cp local_decoder.xml /var/ossec/etc/decoders/
sudo cp local_rules.xml /var/ossec/etc/rules/
sudo systemctl restart wazuh-manager
```
确保 agent 收集了 kernel 日志 (iptables 写入的位置)。在 agent 的 `ossec.conf` 中：
```
syslog
/var/log/kern.log
```
## 验证 (证明其有效)
```
# 1. 从实验室的另一台机器（例如：Kali），访问一个关闭的端口会生成 FIREWALL_DROP：
nmap -sS -p 1-1000
# 2. 在主机上，查看正在生成的 log：
sudo grep "FIREWALL_DROP" /var/log/kern.log | tail
# 3. 在 Wazuh 中，使用一个示例 event 测试 parse 和 rule：
sudo /var/ossec/bin/wazuh-logtest
# 粘贴一行来自 kern.log 的包含 "FIREWALL_DROP:" 的真实日志，并检查它是否匹配 rule 100100/100101
```
预期结果：扫描将触发规则 **100101** (端口扫描，级别 10)，因为同一源 IP 产生了过多的丢弃事件；对 22 端口的重复尝试将触发 **100102** (暴力破解，级别 12)。
## 分流排查 (减少误报)
在将其作为安全事件处理之前，请排除合法原因：
- 该源 IP 是否为 **已授权的扫描器** (Nessus/OpenVAS) 且处于计划内的测试窗口期？ → 误报。
- 是否是 **健康检查 / 监控** 访问了已关闭的端口？ → 调整监控工具或按 IP 创建例外。
- 源 IP 是 `NAGIOS_SERVER` 本身吗？它不应该触发丢弃事件 — 如果触发了，请检查 NRPE 规则。
否则 (未知来源，大范围扫描)：将其视为 **侦察 (T1046)**，并检查后续是否在某个开放端口上发生了成功的连接。
## 硬件开销 (i5 2013 / 16GB / HDD)
对于这种流量负载，`iptables` 在 CPU/RAM 上是无状态的 — 开销可忽略不计。敏感点在于
**日志记录的磁盘 I/O**：因此 `LOGDROP` 使用了 `-m limit --limit 5/min`，以防止 flood 填满 `/var/log` 并卡死 HDD。如果没有这个上限，激进的扫描每秒会产生数千行日志。这在您的硬件上完全可行且非常轻量。
## 下一步
1. **出站过滤 (D3-OTF，反 C2 / T1571)：** 将 `OUTPUT ACCEPT` 更改为 default DROP，
仅放行 DNS、NTP、HTTP/S 及必要的目标地址。减少数据泄露和 C2 通信。
2. **针对 SSH 使用 fail2ban 或 CrowdSec**，通过动态封禁作为内核 rate limit 的补充。
3. **迁移到 nftables** (`nft`)，这是目前内核的标准 — 相同的策略，统一的语法。
4. **Wazuh Dashboard** 结合 1001xx 规则，以可视化展示被拦截的攻击尝试。
**作者：** Diego Machado · SENAC-DF 实验室 · Blue Team / SOC
标签：CISA项目, Cutter, Shell脚本, Wazuh, 插件系统, 系统加固, 防火墙