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 流量默认走
publiczone，但很多人把规则加到了
trusted或
internalzone，导致不生效。
验证和修复步骤：
查当前活跃 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 后就能绕过所有网络层限制。
