MySQL默认端口3306仅在需外部访问时才需防火墙放行；本地连接走localhost不经过防火墙，盲目开放易致安全事件；应优先限制源IP、配置bind_address、强化MySQL自身权限控制。
MySQL 默认端口是否需要放行？
MySQL 默认监听 3306 端口，但仅当服务需被外部主机（非本机）访问时才必须开放防火墙。本地应用（如 PHP、Python 脚本）通过 localhost 或 127.0.0.1 连接 MySQL 时，流量不经过系统防火墙，无需额外放行。
常见误操作：为“确保能连上”盲目开放 3306，结果暴露数据库到公网——这是绝大多数 MySQL 被暴力破解或勒索的起因。
- 确认是否真需远程访问：检查应用部署位置、连接字符串中的 host 值（
127.0.0.1vs服务器公网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 后就能绕过所有网络层限制。
