mysql安装后如何设置防火墙规则_mysql网络安全配置

mysql默认端口3306仅在需外部访问时才需防火墙放行；本地连接走localhost不经过防火墙，盲目开放易致安全事件；应优先限制源ip、配置bind_address、强化mysql自身权限控制。

MySQL 默认端口是否需要放行？

MySQL 默认监听 3306 端口，但仅当服务需被外部主机（非本机）访问时才必须开放防火墙。本地应用（如 PHP、Python 脚本）通过 localhost 或 127.0.0.1 连接 MySQL 时，流量不经过系统防火墙，无需额外放行。

常见误操作：为“确保能连上”盲目开放 3306，结果暴露数据库到公网——这是绝大多数 MySQL 被暴力破解或勒索的起因。

• 确认是否真需远程访问：检查应用部署位置、连接字符串中的 host 值（127.0.0.1 vs 服务器公网IP）
• 若只需本机访问，直接跳过防火墙配置，转而检查 MySQL 的 bind_address 配置项是否为 127.0.0.1（而非 0.0.0.0）
• 若确需远程访问，优先限制源 IP，例如只允许公司办公网段：192.168.10.0/24 或特定运维主机 IP

ufw 下如何精确放行 MySQL 端口？

ufw 是 ubuntu/debian 系统常用前端，配置简单但容易写宽泛规则。错误示例：ufw allow 3306 —— 这会放行所有来源的 TCP 和 udp 包到 3306，极不安全。

正确做法是限定协议、端口、来源 IP：

ufw allow from 192.168.5.100 to any port 3306 proto tcp

说明：

• from 192.168.5.100：只允许该 IP 访问（可替换为 CIDR 段，如 10.0.2.0/24）
• proto tcp：明确只放行 TCP（MySQL 不用 UDP）
• 务必在执行后运行 ufw status verbose 确认规则已生效且顺序合理（ufw 规则按添加顺序匹配，靠前的 deny 可能拦截后续 allow）

firewalld 中 MySQL 规则为何常失效？

centos/RHEL 系统用 firewalld，常见失效原因不是规则没加，而是 zone 配置错位。MySQL 流量默认走 public zone，但很多人把规则加到了 trusted 或 internal zone，导致不生效。

验证和修复步骤：

• 查当前活跃 zone：firewall-cmd --get-active-zones
• 查该 zone 下已有服务/端口：firewall-cmd --zone=public --list-all
• 正确添加端口（指定 zone）：firewall-cmd --zone=public --add-port=3306/tcp --permanent
• 如果要限制源 IP，不能只用 --add-port，得用富规则：firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" source address="172.16.1.5" port port="3306" protocol="tcp" accept' --permanent
• 每次修改后必须执行 firewall-cmd --reload，否则不生效

比防火墙更关键的 MySQL 层防护

防火墙只是第一道过滤，真正决定谁能登录、能做什么的，是 MySQL 自身权限体系。很多用户开了防火墙却仍被攻破，问题出在：

• 使用 root 用户远程登录（CREATE USER 'root'@'%' IDENTIFIED BY ...）
• 未禁用匿名用户：DROP USER ''@'localhost';
• 未限制用户允许连接的 host：CREATE USER 'app'@'10.0.3.%' 比 'app'@'%' 安全得多
• 忘记刷新权限：FLUSH PRIVILEGES; 在某些版本中仍是必需的（尤其手动改了 mysql.user 表后）

防火墙规则再严，只要 MySQL 允许 'admin'@'%' 登录且密码弱，攻击者拿到内网 IP 后就能绕过所有网络层限制。