安全加固审计策略不能直接拦截DDoS攻击，但支撑攻击识别、溯源分析与事后响应；其价值在于让攻击“可看见、可定位、可复盘”，需覆盖登录、账户、特权、对象访问及系统事件，并配合网络限速、应用层控制与服务最小化等非审计措施构建纵深防御。
一、审计策略需覆盖的关键DDoS关联行为
DDoS攻击虽由海量外部流量发起，但常伴随内部异常行为：恶意脚本调用、异常进程创建、高危权限滥用、日志篡改等。这些行为可通过Windows/Linux审计策略捕获：
- 登录事件审计（成功+失败）：识别攻击者是否利用弱口令或已泄露凭证，在攻击前渗透跳板机或管理节点
- 账户管理审计：记录新建/禁用账号操作，发现攻击者创建隐蔽后门账号用于后续横向控制
-
特权使用审计：监控
netsh interface、iptables、systemctl等命令执行，判断是否有人篡改防火墙规则或禁用防护服务 -
对象访问审计（含文件/注册表/配置）：启用对
/etc/iptables.rules、C:\Windows\System32\drivers\etc\hosts等关键路径的读写审计，捕捉配置劫持痕迹 - 系统事件审计：捕获服务启停、系统重启、时间同步异常等，辅助判断攻击是否触发了自毁或掩盖动作
二、Linux/Windows平台审计配置要点
仅开启策略不够，必须确保日志留存完整、防篡改、可聚合：
-
Linux（rsyslog + auditd）：启用
auditctl -w /etc/sysconfig/iptables -p wa -k ddos_rule_change，并配置远程日志转发至独立SIEM服务器 -
Windows（本地安全策略 + Event Forwarding）：除勾选全部8项审核策略外，务必启用
Advanced Audit Policy Configuration → System Audit Policies → Object Access → File System，并对关键配置目录设置SACL - 日志保留周期 ≥ 90天：DDoS攻击常具潜伏性（如先渗透、再囤积僵尸主机），短期日志无法支撑回溯
-
禁止本地存储明文日志：避免攻击者通过shell直接
rm /var/log/audit/audit.log擦除证据
三、审计日志在DDoS实战追踪中的典型用法
当发生疑似DDoS时，审计日志不是用来“挡流量”，而是快速锁定攻击链中的薄弱环节：
-
确认是否为内网协同攻击：比对
Security Event ID 4624（登录）与4688（进程创建）时间戳，若大量curl/hping3/ab进程在非运维时段由低权限账号启动，极可能是内网傀儡机被控 -
识别攻击准备阶段动作：搜索
Event ID 4732（将用户添加到安全组）或4728（成员加入），发现攻击者是否已提权至Administrators或Network Configuration Operators -
验证防护措施是否被绕过：检查
Event ID 4697（计划任务创建），确认是否新增了定时执行iptables -F或ufw disable的任务 -
关联网络流与主机行为：将NetFlow/Sflow中异常IP的首次连接时间，与该IP对应主机上
4624登录事件时间对齐，判断是真实用户还是扫描器/肉鸡
四、必须搭配的非审计类加固动作
审计是“眼睛”，但防御靠“盾”和“墙”。以下加固项与审计形成闭环：
- 网络层限速：在边界设备或云平台（如Azure DDoS Protection、阿里云Anti-DDoS）配置SYN Flood/UDP Flood阈值，自动触发清洗
-
应用层准入控制：Nginx配置
limit_req、OpenResty集成BotGuard，拦截HTTP Flood中的无头浏览器请求 -
服务最小化：关闭
cups、rpcbind、telnet等默认监听端口，减少攻击面 -
凭证与权限收敛：MySQL删除
test库、禁用匿名用户；SSH禁用密码登录、强制证书认证——防止DDoS工具链依赖的初始入口
