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
真正防SQL注入该盯住哪几处
网络层做完减法后，防注入的主战场在应用代码和数据库配置。重点不是“怎么封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(），但别依赖它兜底——绕过太容易
网络策略配得再严，只要应用还用string.format()拼SQL，或者ORM没关raw_query，注入就还在那儿。防线得落在离数据最近的地方，而不是在流量入口瞎拦。
