DiegoRSMachado/automacao-apache-ufw
GitHub: DiegoRSMachado/automacao-apache-ufw
一套 Bash 自动化脚本,用于 Apache Web 服务器的安全加固、UFW 防火墙边界策略配置以及只读安全状态审计。
Stars: 0 | Forks: 0
# 实验 — Webserver Apache Endurecido + Firewall UFW (Linux Avançado / SOC)
Apache 服务器的配置与 **hardening**,使用 **UFW** 进行边界策略
(default-deny) 以及安全状态的 **只读审计**。明确区分
*更改*系统的操作与仅*观察*的操作 —— 包含 MITRE ATT&CK/D3FEND 映射。
学术/监督实验 (SENAC-DF)。防御性 —— Blue Team / hardening。
## 为什么使用 3 个脚本(而不是 2 个混合脚本)
最初的实验将安装 + 更新 + 审计合并在同一个脚本中。更改系统的审计
不是真正的审计。在这里,每个脚本都有**单一的职责**:
| 脚本 | 角色 | 是否更改系统? |
|---|---|---|
| `apache_hardening.sh` | 安装并对 Apache 进行 hardening | **是** |
| `ufw_firewall.sh` | 应用防火墙策略 | **是** |
| `apache_audit.sh` | 收集安全状态 | **否** (只读) |
## 从原始实验中修正了什么
- **`netstat` → `ss`**: `net-tools` 已被弃用且在现代系统中缺失;旧
脚本在端口步骤中会失败。`ss -tulpn` 是正确的替代方案。
- **UFW:策略而非表面工作**: 真正的控制是 `default deny incoming`。当默认规则已经阻止所有内容时,显式拒绝
21/23/23 是多余的。去除了冗余操作,
应用了 default-deny。
- **`ufw --force enable`**: 纯 `enable` 是交互式的,会导致脚本卡住(并且可能
中断 SSH)。`--force` 解决了这个问题,同时之前已通过 `limit`/作用域保证了 SSH 的连通。
- **带有 `ufw limit` 的 SSH**: 原生限流以对抗暴力破解 (T1110),而不是原始的 `allow`。
- **真正的 Apache hardening**: `ServerTokens Prod`, `ServerSignature Off`, `TraceEnable Off`,
并禁用 `autoindex`/`status` —— 封堵了版本泄露和侦察 (recon)。
## 控制映射表
| 向量 | ATT&CK | 控制 | D3FEND |
|---|---|---|---|
| 暴露的 Banner/版本 | T1592 | ServerTokens Prod, Signature Off | D3-PH |
| 服务面 | T1190 | patch + 关闭高风险模块 | D3-PH |
| 目录列出 / server-status | T1083/T1046 | `a2dismod autoindex status` | D3-PH |
| 暴露的未授权服务 | T1021 | UFW `default deny incoming` | D3-NTF |
| 暴力破解 SSH | T1110 | `ufw limit` 或 `MGMT_NET` 作用域 | D3-ITF |
## 执行顺序
```
# 1. 加固并启动 Apache (应用前验证配置)
sudo bash apache_hardening.sh
# 2. 应用 firewall 策略
# (可选: 将 SSH 限制在管理网络内)
sudo MGMT_NET="192.168.56.0/24" bash ufw_firewall.sh
# 3. 审计 — 只读, 生成带日期的 apache_audit_AAAA-MM-DD_HHMMSS.txt 报告
sudo bash apache_audit.sh
```
## 验证
```
# 版本信息不得泄露给客户端:
curl -sI http://localhost | grep -i '^Server:' # esperado: apenas "Server: Apache"
# 目录列表必须被禁用:
# 创建一个没有 index 的目录并访问 — 必须返回 403, 而不是列出文件。
# Firewall 生效:
sudo ufw status verbose # web/SSH allow, resto deny
# 暴力破解被拦截 (来自 Kali): 重复的 SSH 连接会触发 UFW 的 limit。
```
## [SOC] — 将 Web 服务器转变为检测源
Hardening 缩小了攻击面;SOC 负责监控仍然在尝试访问的请求。将日志接入 Wazuh:
```
apache /var/log/apache2/access.log
apache /var/log/apache2/error.log
syslog /var/log/ufw.log
```
需要追踪的信号(Wazuh 原生规则 + 关联分析):
- **Web 扫描/枚举 (T1595):** 来自同一源的大量 404/403 → 侦察 (recon)。
- **路径遍历 / LFI 尝试 (T1083):** URL 中的 `../`, `/etc/passwd`。
- **关联的 UFW 阻断:** 来自同一源的大量 `[UFW BLOCK]` → 端口扫描 (T1046)。
- **对 `server-status`/`.git`/`.env` 的访问:** 表明正在探测暴露的配置信息。
## 硬件开销 (i5 2013 / 16GB / HDD)
UFW 和 Apache hardening: 开销微乎其微。`apt upgrade` 是消耗资源的步骤(网络 + HDD 的 I/O) —— 因此它被单独放在 hardening 脚本中,可以注释掉,并且位于审计之外。
审计非常轻量,不会在系统中写入内容,只会生成 `.txt` 报告。
## 下一步计划
1. **强 TLS**: `a2enmod ssl`,证书,以及安全 headers (HSTS, X-Content-Type-Options, CSP)。
2. **带有 OWASP CRS 的 ModSecurity (WAF)** —— 在应用边界阻断 SQLi/XSS (T1190)。
3. **fail2ban** 读取 `error.log`/`access.log` 以封禁扫描器和 Web 登录暴力破解。
4. **带有上述检测的 Wazuh Dashboard** —— 阻断攻击的直观证据。
**作者:** Diego Machado · Lab SENAC-DF · Blue Team / Hardening / SOC
标签:Apache, CISA项目, UFW防火墙, 实时处理, 应用安全, 服务器加固, 系统运维