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防火墙, 实时处理, 应用安全, 服务器加固, 系统运维