如何配置数据库入侵检测规则？

本文目录导读：

1. 核心配置原则：从“基准”出发
2. 四大类典型入侵检测规则配置
3. 不同平台的配置方法（举例）
4. 最关键的配置避坑指南
5. 总结配置流程

配置数据库入侵检测规则（如针对MySQL、PostgreSQL、SQL Server等）通常依赖数据库审计系统（DB Audit）、网络入侵检测系统（如Snort、Suricata）或云平台的安全服务（如阿里云DAS、AWS GuardDuty）。

由于不同系统配置差异巨大，下面提供一个通用且核心的配置方法论以及具体的规则示例,帮助你根据自身场景进行调整。

核心配置原则：从“基准”出发

不要直接套用通用规则,建议先：

1. 基线学习：记录正常业务模式（如：哪些IP访问？什么时间？执行哪些SQL类型？）。
2. 脱敏白名单：将应用服务器、运维堡垒机、备份系统的IP加入白名单,避免误报。
3. 分层防御：规则分为安全威胁（必告警）、违规操作（必告警）、异常行为（需评估阈值）。

四大类典型入侵检测规则配置

SQL注入攻击（最核心）

检测逻辑：识别非正常SQL语法、尝试绕过WAF的编码、联合查询、报错注入。

• 规则示例（正则表达式）：

  • 检测联合查询：(?i)^.*(UNION|UNION ALL)\s+SELECT.*(FROM|INTO).*$
  • 检测注释符尝试：(?i)^.*(--\s|#|/\*).*$ （结合非白名单IP时告警）
  • 检测执行函数：(?i)^.*(EXEC|EXECUTE|XP_CMDSHELL|MYSQL_HELP).*$ （极高危策略）
  • 检测sleep/延时：(?i)^.*(SLEEP\(|BENCHMARK\(|PG_SLEEP\().*$
  • 检测布尔注入：(?i)^.*(AND|OR)\s+1[^\d]=1'.*$ （如：OR 1=1）

• 配置建议：开启后，建议先进入“告警”模式（不拦截），观察误报情况，再逐步启用“拦截”。

异常登录与账号爆破

检测逻辑：短时间内失败的登录尝试、来自非业务区域IP的登录。

• 规则示例：

  • 失败阈值：同一源IP在5分钟内登录失败5次。
  • 低频调用：一个账号在1分钟内被从10个不同IP尝试登录。
  • 异地登录：登录IP的城市或国家与历史记录不符。
  • 非工作时间登录：凌晨2-6点非运维窗口的失败登录。

• 配置建议：该规则误报率较高，建议将堡垒机和应用服务器IP加入白名单。

数据泄露与批量操作

检测逻辑：返回大量数据、下载敏感字段、未授权的导出操作。

• 规则示例：

  • 返回行数：单条SELECT语句返回>10000行数据（阈值需根据业务表调整）。
  • 敏感表操作：对users, payment, credit_card等表执行SELECT *。
  • 批量导出：执行SELECT ... INTO OUTFILE或COPY ... TO（高危）。
  • 大量DELETE：无WHERE条件的DELETE或UPDATE。

• 配置建议：需要定义“敏感表”列表（如：user.*, order.*, log.*）。

权限滥用与提权

检测逻辑：非DBA角色执行高权限操作。

• 规则示例：

  • DDL操作：普通应用账号执行DROP TABLE, ALTER TABLE, TRUNCATE。
  • 权创建：非管理员执行GRANT, CREATE USER, REVOKE。
  • 系统命令：执行LOAD DATA INFILE, CREATE FUNCTION（提权常用手段）。

• 配置建议：这是最可靠的规则之一,通常只有DBA或运维账号才有权限。

不同平台的配置方法（举例）

使用数据库本身审计（如 MySQL Enterprise Audit / PostgreSQL Audit）

• MySQL：

  -- 安装审计插件
  INSTALL PLUGIN audit_log SONAME 'audit_log.so';
  -- 设置过滤规则：只记录非root用户的DROP和ALTER
  SET GLOBAL audit_log_policy = 'ALL';
  -- 更精细的控制通常需要配合变量如 audit_log_include_commands

• PostgreSQL（pgAudit）：

  -- 加载共享库
  shared_preload_libraries = 'pgaudit'
  -- 配置要审计的事件（WRITE表示INSERT/UPDATE/DELETE）
  pgaudit.log = 'write,ddl,role'

缺点：自身审计功能会消耗性能，且在复杂攻击面前,其规则引擎能力较弱。

使用专用数据库审计系统（推荐）

主流方案：Imperva, Guardium, 阿里云DAS, 腾讯云CDB-Audit。

• 配置步骤（以通用平台为例）：
  1. 添加数据库实例：填写IP、端口、账号。
  2. 创建策略 -> 规则组。
  3. 选择“高风险操作”模板。
  4. 自定义规则：
     • 条件：Source_IP NOT IN (白名单) AND SQL_Command IN (DROP, TRUNCATE) AND Return_Rows > 0。
     • 动作：记录详细日志、实时发送短信/邮件、阻断执行。
  5. 测试生效：使用模拟攻击语句验证告警是否触发。

使用网络层IDS（如 Snort / Suricata）

• 需配置端口镜像流量并解析数据库协议。

• 规则示例（Snort）：

  alert tcp $EXTERNAL_NET 3306 -> $SQL_SERVERS 3306 (msg:"MySQL SQL Injection - Union Select";
  content:"UNION"; nocase; content:"SELECT"; nocase; distance:0;
  classtype:web-application-attack; sid:1000001; rev:1;)

• 缺点：协议解析复杂（尤其是加密TLS流量），误报率高，已逐渐被DAAS（数据库即审计服务）取代。

最关键的配置避坑指南

1. 避免“带库级”扫描：许多规则会匹配SELECT *，但如果这是应用框架Hibernate的findAll()，就会疯狂误报。必须将应用服务器IP加入白名单。
2. 参数化查询处理：如果你的应用完全使用了PreparedStatement（参数化查询），那么绝大多数SQL注入规则不应匹配到它，如果仍然匹配,说明审计系统解析能力不足。
3. 低错误阈值：不要一开始就设置为“阻断”，先设置为“仅记录”，观察一周,根据误报数量调整白名单或正则表达式。
4. 加密流量处理：目前主流数据库（MySQL 8.x以上）默认开启SSL。如果不配置SSL解密，IDS和网络级系统几乎无法检测内容，必须依赖数据库侧的审计插件。
5. 性能影响：开启全量审计并配置复杂正则，数据库CPU可能飙升，建议：
   • 只审计关键操作（DDL、DML、登录）。
   • 使用异步文件流（异步写入日志）。

总结配置流程

1. 确定审计目标：是合规（如等保2.0）还是防攻击？
2. 选择工具：数据库自带审计（轻量） / 日志转发至ELK（DIY） / 商业DAAS（推荐）。
3. 获取白名单：收集所有应用的IP、VIP、运维IP。
4. 启用基础规则（登录失败、DDL、无WHERE删除）。
5. 观察一周 -> 调整白名单和阈值。
6. 启用高级规则（SQL注入、批量查询、异常时间）。
7. 定期复盘：每月分析一次误报和漏报数据。

如果你有具体的数据库类型（如Oracle或MongoDB）或特定的业务场景（如金融、电商）,可以进一步细化配置方案。