如何加固SQL集群防注入_实施网络层访问控制策略

3次阅读

SQL 注入是应用层漏洞，网络层控制仅能缩小攻击面；防注入主战场在参数化查询、最小权限和数据库安全配置。

如何加固 SQL 集群防注入_实施网络层访问控制策略

加固 SQL 集群防注入，不能靠网络层访问控制“一招鲜”。SQL 注入 是应用层漏洞，发生在应用拼接用户输入、执行 SELECT 或INSERT语句时；而 iptables、security group、firewalld 这些网络策略只能限制谁“能连上数据库端口”，拦不住合法连接里的恶意 SQL。真有注入，攻击者早就在白名单 IP 里了。

网络层访问控制唯一靠谱的作用，是缩小攻击面——把数据库端口（比如3306、5432）只暴露给真正需要它的服务节点，其他一律拒绝。这不防注入，但能避免被扫描器批量爆破、防止未授权中间件直连、降低横向移动风险。

只允许应用服务器的内网 IP 段访问 3306，禁止0.0.0.0/0 或开发机公网 IP
数据库集群内部节点间通信（如 MySQL 主从复制、PostgreSQL 流复制）要单独放行，别用同一组规则混着管
禁用数据库监听 0.0.0.0:5432，改用10.10.20.5:5432 这类绑定具体内网地址，再配合防火墙双保险
云环境优先用安全组（security group）而非实例级防火墙，规则更易审计且不随重启丢失

常见翻车点不是“没设”，而是规则写得太糙。比如用 iptables -A INPUT -p tcp --dport 3306 -j DROP 丢弃所有入向，却忘了加 -i lo 放行本地回环，导致 mysqld 自己连不上自己的 socket 或健康检查失败；又或者主从复制走的是 3306 以外的端口（如 MySQL Group Replication 用33061），结果只开了3306，集群直接脑裂。

检查 netstat -tlnp | grep :3306 确认监听地址，别信配置文件里写的 bind-address = 127.0.0.1 就以为安全了——可能被覆盖
PostgreSQL 要额外放开 5432 之外的端口：流复制用 5432，但pg_basebackup 或逻辑复制槽可能走相同端口，也可能走独立端口，得看 pg_stat_replication 里client_addr和backend_start
容器环境（如 K8s）里，hostNetwork: true会绕过 Pod 防火墙，此时必须在节点宿主机或 CNI 插件层做控制，不能只靠 Pod 内iptables

网络层做完减法后，防注入的主战场在应用代码和数据库配置。重点不是“怎么封 IP”，而是“怎么让 SQL 本身不带毒”。

强制使用参数化查询：cursor.execute("SELECT * FROM users WHERE id = %s", [user_id])，绝不用"SELECT …… WHERE id = " + str(user_id)
数据库账号最小权限原则：应用账号只给 SELECT、INSERT 对应表，禁用 LOAD_FILE、INTO OUTFILE、EXECUTE 等高危权限
开启sql_mode=STRICT_TRANS_TABLES（MySQL）或check_function_bodies = on（PostgreSQL），让语法错误和隐式转换尽早暴露
Web 层 WAF（如 ModSecurity 规则）可拦截典型注入特征（UNION SELECT、sleep(、benchmark(），但别依赖它兜底——绕过太容易