MySQL安全加固十项硬核操作：从账号权限到审计恢复

一提“MySQL安全加固”，不少人第一反应是“我的库部署在内网，又不对外，谁会来打”。我以前也这么想，直到有一次帮朋友排查一台“能用就行”的数据库，发现root账号密码是root123，3306端口对公网开放，库里还躺着几十万条用户信息。那一刻我就意识到，安全加固这件事，不是“被攻击之后才需要”，而是从数据库初始化那天就该做。

这篇文章我想把MySQL安全加固的十个硬核操作完整写一遍，覆盖账号权限、口令认证、网络边界、审计恢复四个维度。内容以MySQL 5.7和8.0为主，操作命令基本都是可以直接复制执行的，还会穿插一些我在真实环境里踩过的坑。不管你是刚入职的运维、自己折腾项目的后端，还是负责生产库的DBA，这篇文章都应该能帮上忙。

1. 先承认：默认安装的MySQL在很多团队里就是“裸奔”

很多MySQL“能用就行”的部署方式，安全隐患比想象中严重。我接手过不少这样的环境，随便一查就能列出一串问题：

• 安装完MySQL从来没设置过root密码，或者用的是123456、root这类弱口令；
• 默认存在匿名账号，任何人在本机执行mysql -u root都能连进去；
• test库没有删除，而这个库默认是任何人都能访问的；
• 3306端口直接暴露在公网或者0.0.0.0监听，防火墙规则等于没有；
• 没开任何审计日志，出事了查不到是谁在什么时候执行过什么命令；
• 备份文件裸放在服务器上，连权限都没设置。

这些问题的可怕之处在于，单看每一项好像都不致命，但组合起来就是一个完整的攻击链路：扫描器在公网扫到开放3306的MySQL实例，用弱口令字典爆破root密码，拿到root权限之后通过SELECT ... INTO OUTFILE写WebShell，或者直接拖库。整个过程不需要多高深的技术，靠的都是默认配置和运维的疏忽。

所以我把安全加固的目标总结成三句话：少暴露、强口令、留后路。

• 少暴露：不监听公网、不开放多余端口、不暴露版本信息、不给多余权限；
• 强口令：密码足够复杂、有周期性过期策略、登录失败有惩罚、认证插件用更安全的；
• 留后路：开启审计日志、二进制日志，做好加密备份和恢复演练，万一真被突破了还能追溯、还能恢复。

下面这十个操作，就是围绕这三句话展开的。建议对照自己管理的实例，逐条过一遍。

2. 账号与权限收敛：关好数据库的每一扇门

2.1 操作一：清理匿名账号、空密码账号，删除test库

新装完的MySQL，或者从旧版本升级上来的实例，用户表里经常会有一些多余账号。先看一遍用户列表：

sql复制SELECT user, host, authentication_string, plugin FROM mysql.user;

这个查询会列出所有账号。重点看这几种：

• user列是空字符串的匿名账号；
• authentication_string为空或者太短的账号；
• host是%的账号；
• 是不是有root之外、你完全不认识的账号。

清理匿名账号：

sql复制DROP USER ''@'localhost';
DROP USER ''@'主机名';

注意host要按实际查询结果写，不同机器上匿名账号的host可能不一样。如果提示账号不存在，说明这条记录本来就不需要处理，继续看下一条就行。

test库在MySQL初始化时自带，默认所有用户都能访问。在加固清单里，test库属于“看着不起眼但该删就删”的东西：

sql复制DROP DATABASE IF EXISTS test;
-- 同时清理mysql.db表里指向test库的授权记录
DELETE FROM mysql.db WHERE Db LIKE 'test%';
FLUSH PRIVILEGES;

很多人不理解为什么要删test库，觉得“开发偶尔临时建个表玩一玩”。问题是，test库是你不需要任何权限就能访问的公共区域，攻击者拿到一个低权限账号之后，第一件事就是去test库里探测、写临时数据、甚至作为存放恶意文件的落脚点。删除的成本很低，留着没必要。

还要顺带查一下空密码账号：

sql复制SELECT user, host FROM mysql.user WHERE authentication_string = '';

在5.7里，空密码的authentication_string会是空串；8.0里所有账号都要求有密码，基本不会出现空密码，但老实例升级上来的情况得注意。查到空密码账号之后，要么设密码，要么直接删除。

2.2 操作二：重建root账号，绑定登录来源，禁止root远程

很多团队用root作为日常开发和运维的公共账号，这是我最想纠正的习惯。root在MySQL里意味着最高权限，一旦密码泄露，攻击者能做的事情基本没有上限。更好的做法是：root只保留localhost登录，远程管理用独立的管理员账号。

初始化安装之后，第一步永远是给root设置强密码：

sql复制ALTER USER 'root'@'localhost' IDENTIFIED BY '一个足够复杂的密码';

如果用户表里存在root@'%'这种允许任意IP登录的账号，建议直接删掉：

sql复制SELECT user, host FROM mysql.user WHERE user = 'root';
-- 确认业务没有使用root远程连接后执行
DROP USER 'root'@'%';

这里特别提醒：执行DROP USER之前，必须确认全公司所有应用、脚本、监控系统都没有用root远程连接。我的做法是先在监控系统里查一下3306端口的连接来源，确认没有外部IP在连，再删除。曾经见过一个团队把root@'%'删了，结果第二天发现主从复制的账号也是root，直接导致同步中断。

远程管理账号单独创建，按需要授权：

sql复制CREATE USER 'dba'@'192.168.10.%' IDENTIFIED BY 'Dba@2024StrongPass';
GRANT ALL PRIVILEGES ON *.* TO 'dba'@'192.168.10.%' WITH GRANT OPTION;
FLUSH PRIVILEGES;

这里host字段限制为内网网段192.168.10.%，只有该网段的机器能连。如果你用的是云数据库，直接把安全组里的来源IP限制到公司出口IP或者跳板机IP。

2.3 操作三：最小权限审计，回收FILE、SUPER、PROCESS等高危权限

最小权限原则说起来简单，真正执行起来需要把每个账号都过一遍。先查所有账号的权限：

sql复制SELECT user, host FROM mysql.user;
-- 逐个查看指定账号权限
SHOW GRANTS FOR 'user'@'host';

在MySQL里，有几个全局权限属于“高危权限”，日常业务完全用不到，但安全风险极大：

回收命令：

sql复制REVOKE FILE, SUPER, PROCESS, RELOAD ON *.* FROM 'user'@'host';
REVOKE GRANT OPTION ON *.* FROM 'user'@'host';

业务账号就老老实实只授权自己所需的库和表：

sql复制-- 只允许app账号操作appdb库
GRANT SELECT, INSERT, UPDATE, DELETE ON `appdb`.* TO 'app'@'192.168.1.%';

这里要特别说一下MySQL 8.0的坑：8.0把SUPER权限拆成了多个动态权限，比如BINLOG_ADMIN、SYSTEM_VARIABLES_ADMIN、CONNECTION_ADMIN等。如果你在8.0里回收了应用账号的SUPER，而应用代码里有SET GLOBAL语句，它就需要SYSTEM_VARIABLES_ADMIN权限，否则直接报Access denied。所以收权限之前先和开发确认清楚，到底有没有依赖这些全局操作的逻辑。

3. 口令与认证体系升级：让弱口令和撞库彻底失效

3.1 操作四：启用validate_password，强制密码复杂度

MySQL 5.7开始提供了validate_password插件，但默认不启用。这也是很多弱口令能存活到生产环境的直接原因——创建用户的时候，密码再弱系统都接受。

5.7安装插件：

sql复制INSTALL PLUGIN validate_password SONAME 'validate_password.so';

8.0里改成了组件方式：

sql复制INSTALL COMPONENT 'file://component_validate_password';

安装之后，先看参数：

sql复制SHOW VARIABLES LIKE 'validate_password%';

生产环境我一般建议配置如下：

sql复制SET GLOBAL validate_password.policy = STRONG;
SET GLOBAL validate_password.length = 12;
SET GLOBAL validate_password.mixed_case_count = 1;
SET GLOBAL validate_password.number_count = 1;
SET GLOBAL validate_password.special_char_count = 1;

8.0里参数是validate_password.policy这种带点号的命名方式，5.7里则是validate_password_policy这种下划线命名方式，用的时候注意区分。STRONG策略会额外检查密码中不能包含字典里的常见词汇，暴力破解难度会上一个大台阶。

注意：这些SET GLOBAL语句只对当前运行实例生效，重启后会丢失。要持久化，把配置写进my.cnf的[mysqld]段。

踩坑提醒：这个组件一启用，以前能创建的弱密码账号就全建不出来了。很多老业务里写着CREATE USER 'xxx' IDENTIFIED BY '123456'，升级完之后运行到这一步直接报错。建议先在测试环境跑一遍，再通知开发调整初始化脚本。

3.2 操作五：设置密码过期策略和连续失败延迟

密码复杂度只能防止“新密码”太弱，解决不了“密码用五年不换”的问题。设置密码过期策略：

sql复制-- 全局：默认90天过期
SET GLOBAL default_password_lifetime = 90;

也可以针对单个用户设置：

sql复制ALTER USER 'app'@'192.168.1.%' PASSWORD EXPIRE INTERVAL 90 DAY;
-- 强制该用户下次登录必须改密码
ALTER USER 'app'@'192.168.1.%' PASSWORD EXPIRE;

还有个容易被忽略的加固点：登录失败处理。MySQL官方提供了connection-control插件，可以在同一来源IP连续多次登录失败后，增加延迟时间。

sql复制INSTALL PLUGIN CONNECTION_CONTROL SONAME 'connection_control.so';
INSTALL PLUGIN CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS SONAME 'connection_control.so';

安装后设置参数：

sql复制SET GLOBAL connection_control_failed_connections_threshold = 5;
SET GLOBAL connection_control_min_connection_delay = 1000;
SET GLOBAL connection_control_max_connection_delay = 86400000;

含义是：连续5次登录失败后，开始对该来源IP做延迟，第一次延迟至少1秒，之后逐步递增，最大延迟24小时。注意这个机制是“延迟”而不是“锁死”，攻击者的暴力破解会变得极其缓慢，而正常用户输错几次密码也只是等几秒钟。

这里有个实际运维中容易踩的坑：如果应用通过中间件（比如ProxySQL、MyCAT）统一连MySQL，那么所有连接在MySQL眼里都来自中间件的IP。一旦中间件连接池里的某个连接出问题反复重试，触发的延迟会波及整个连接池，表现为“应用突然变慢”。遇到这种情况，阈值要适当调高，或者把中间件IP单独设置为不限制。

3.3 操作六：升级认证插件，告别mysql_native_password

先看看现有账号用的什么认证插件：

sql复制SELECT user, host, plugin FROM mysql.user;

MySQL 5.7默认是mysql_native_password，8.0默认是caching_sha2_password。前者基于SHA1算法，口令哈希在快速硬件上可以离线爆破，安全性已经跟不上时代；后者基于SHA256，且支持RSA公钥加密传输密码，明显更安全。

把仍在使用老插件的账号迁移到新插件：

sql复制ALTER USER 'app'@'192.168.1.%' IDENTIFIED WITH caching_sha2_password BY '新密码';

这里最大的坑是兼容性。caching_sha2_password在MySQL 8.0引入后，很多老版本客户端驱动一开始是不支持的：

• 老版本的PHP mysqli、mysqlnd（7.4版本之前有兼容问题）；
• 老版本JDBC驱动（8.0.9之前）；
• Python老版本的PyMySQL、mysql-connector-python；
• 主从复制环境里，从库的账号协议如果太旧，也可能连不上新主库。

我的建议是：升级之前，先把所有应用使用的客户端驱动版本列出来，确认都支持caching_sha2_password再做切换。如果实在有暂时不支持的，宁可保留少数几个mysql_native_password账号做过渡，并加上密码复杂度和到期策略，也不要一次性把全部账号切换过去，否则线上事故分分钟教做人。

4. 网络边界与链路加密：让数据库从网络不可达开始

4.1 操作七：监听地址收敛与防火墙精确放行

MySQL默认监听在所有网卡上，意味着只要服务器有公网IP，3306端口就可能暴露在公网。设置bind-address是最直接有效的收敛手段。

编辑my.cnf：

ini复制[mysqld]
bind-address = 127.0.0.1

如果只有本机应用需要连，127.0.0.1就够了；如果局域网内有其他应用服务器，改成私网IP，比如bind-address = 192.168.1.10，绝不要写0.0.0.0。

改完重启MySQL，再看一下监听状态：

bash复制netstat -tlnp | grep 3306

如果输出里显示的是192.168.1.10:3306，说明已经不在公网监听了。

线上实践里，bind-address只能控制MySQL进程监听哪个网卡，不是防火墙。最稳妥的方式是双管齐下：数据库服务器本机防火墙只放行特定来源IP访问3306端口。

以firewalld为例：

bash复制# 移除公共区域的3306端口
firewall-cmd --permanent --zone=public --remove-port=3306/tcp
# 放行指定内网IP访问3306
firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source address="192.168.1.0/24" port port="3306" protocol="tcp" accept'
firewall-cmd --reload

如果是云服务器，检查安全组规则，把3306端口来源限制到公司出口IP或跳板机IP，而不是0.0.0.0/0。

4.2 操作八：修改默认端口，并尽量减少版本信息暴露

很多人的加固清单里会包含“改默认端口”，把3306换成33061之类的冷门端口。这个操作的本质不是防攻击者——扫描器扫的是整个IP段的所有端口，3306没人监听就会换下一个端口继续扫，改端口只是让自动化扫描工具“多走一步”。

我的看法是：改端口可以做，但优先级不高，而且要承受全局改动连接串的代价。如果决定改，my.cnf里加：

ini复制[mysqld]
port = 33061

开发环境、测试环境、生产环境的连接串、JDBC URL、Docker映射、数据库管理工具都要同步改，漏掉一个就会出一次“连接被拒”的工单。

另一个信息暴露问题是版本号。MySQL在客户端握手阶段就会暴露版本信息，用telnet ip 3306就能看到类似“5.7.44”的版本号。攻击者拿到精确版本号后，可以直接对照该版本的已知漏洞目录。

隐藏版本号这件事，MySQL官方并没有提供一个开关来彻底禁止握手包返回版本信息，更有效的做法是：

• 通过防火墙或代理（如ProxySQL、MySQL Router）屏蔽对端看到MySQL Server的真实版本；
• 及时升级补丁，让已知漏洞对当前实例失效；
• 错误日志会包含版本信息，注意日志文件的权限，避免普通用户可读。

换句话说，隐藏版本是“治标的装饰”，升级补丁才是“治本”。

4.3 操作九：开启SSL/TLS，强制传输加密

MySQL默认情况下，客户端和服务器之间是明文传输。在内网环境里，很多人觉得“没事”，但在安全要求较高的场景（等保、金融、客户合同里有数据安全条款），全链路加密是合规红线。而且内网也不等于绝对安全——同一网络里的任何一台机器都可能做了流量镜像。

MySQL自5.7开始，可以用官方工具生成SSL证书：

bash复制mysql_ssl_rsa_setup --datadir=/var/lib/mysql --uid=mysql

生成之后，在my.cnf里配置：

ini复制[mysqld]
ssl-ca = /var/lib/mysql/ca.pem
ssl-cert = /var/lib/mysql/server-cert.pem
ssl-key = /var/lib/mysql/server-key.pem

重启MySQL后验证：

sql复制SHOW VARIABLES LIKE 'have_ssl';
-- 应显示 YES

此时SSL已经支持，但客户端默认还是可以走非SSL连接。要让连接强制走SSL，有两种方式：

一是全局强制：

ini复制[mysqld]
require_secure_transport = ON

二是对特定账号强制：

sql复制ALTER USER 'app'@'192.168.1.%' REQUIRE SSL;

这里有个非常典型的踩坑：开启require_secure_transport或REQUIRE SSL之后，老应用如果连接串里没加ssl相关参数，会直接报类似“ACCESS REFUSED”的错误。Java JDBC需要在URL后面加?sslMode=REQUIRED，PHP mysqli需要在连接参数里开启ssl，Python的PyMySQL则需要传ssl参数。所有客户端驱动都要单独配置，建议先在一个测试应用上验证，再全量推广。

关于性能损耗，SSL加解密的开销在5%到10%左右，现代CPU基本无感。真正影响大的是频繁短连接场景——每次握手都要做一次TLS协商。解决办法是应用层使用连接池，减少握手次数。

5. 审计、备份与系统层兜底：被突破之后还要能追、能恢复

5.1 操作十：开启审计日志和二进制日志，配好轮转

安全加固不能只防“进不来”，还要防“进来了之后看不见”。审计能力是最后一道防线。

MySQL社区版默认没有像企业版那样强大的审计插件，但至少可以做到“有日志可查”：

• 通用日志（general_log）：记录所有客户端连接和执行的SQL；
• 二进制日志（binlog）：记录所有数据变更操作，可用于数据恢复和误操作回溯；
• 错误日志（error log）：记录连接异常、权限错误、复制错误等关键信息。

通用日志默认关闭，因为它在高并发下会产生海量日志，影响性能。生产环境的折中方案是：把general_log输出到表，便于后续按时间、用户、host检索，但必须配合定期转储和删除，否则表会无限膨胀。

ini复制[mysqld]
general_log = ON
general_log_file = /var/log/mysql/general.log
log_output = TABLE

binary log建议直接打开，这对数据恢复的意义远超安全审计本身：

ini复制[mysqld]
server-id = 1
log-bin = /var/log/mysql/mysql-bin
binlog_format = ROW
binlog_expire_logs_seconds = 604800

其中binlog_expire_logs_seconds = 604800表示binlog保留7天，具体保留时长根据你全量备份的频率来定。如果每天做一次全量备份，binlog保留2到3天就够用了；如果每周才做一次全量备份，那就必须保留至少7天以上。

还有一个容易被忽略的点：日志文件的系统级轮转。MySQL不会自动rotate错误日志和通用日志文件（尤其是一般日志输出为文件时），文件会无限增长直到把磁盘写满。配置logrotate：

bash复制/var/log/mysql/general.log /var/log/mysql/mysql-error.log {
    daily
    rotate 30
    compress
    delaycompress
    missingok
    notifempty
    create 640 mysql mysql
    sharedscripts
    postrotate
        # 让MySQL重新打开日志文件
        mysqladmin flush-logs
    endscript
}

5.2 系统层兜底：运行用户、文件权限、补丁升级

数据库层的加固做得再完善，服务器系统层漏洞也能直接绕过去。系统层的兜底操作有这几项：

**第一，mysqld进程绝对不能以root运行。**检查一下：

bash复制ps aux | grep mysqld

正常的运行用户应该是mysql或者mysqld。如果显示root，说明安装时没有正确处理运行身份，风险非常大——一个数据库的SQL注入漏洞都可能直接演变成服务器被提权。修正方式在不同发行版里不一样，Debian/Ubuntu的包安装默认会用mysql用户，编译安装的要多注意配置。

第二，配置文件和数据目录的权限要收紧。

bash复制chmod 640 /etc/my.cnf
chown root:mysql /etc/my.cnf
chmod 750 /var/lib/mysql
chown mysql:mysql /var/lib/mysql

my.cnf里有root密码等敏感参数，普通用户应该连读都读不到；数据目录权限设为750，防止其他系统用户直接读取物理文件，否则攻击者拿到服务器上的一个低权限账号，就能直接拷贝数据文件。

第三，清理命令历史。

MySQL客户端会把执行过的SQL记录到~/.mysql_history文件里，明文存储。系统中如果存在其他低权限用户，一旦可读这个文件，密码就泄露了。建议在DBA的shell配置里加上：

bash复制export MYSQL_HISTFILE=/dev/null

或者定期清理rm -f ~/.mysql_history。

第四，关注补丁。

MySQL小版本升级通常包含安全修复，关注官方安全公告，当出现高危CVE时，及时评估版本受影响程度，尽快升级到修复版本。我见过无数实例因为“升级麻烦”停留在5.7.30这种漏洞版本上，最后出了事故才追悔莫及。

5.3 备份加密与恢复演练：备份不等于能恢复

很多团队的备份策略是“mysqldump一份扔在服务器上”，既不加密，也不检查备份文件是否可恢复。这种备份在灾难面前等于没有。

先解决加密和权限问题。mysqldump本身不加密，一种常见做法是管道输出后直接加密：

bash复制mysqldump -u备份账号 -p --single-transaction --routines --triggers appdb | gzip | openssl enc -aes-256-cbc -salt -k '备份加密口令' > /backup/appdb_$(date +%F).sql.gz.enc

如果使用Percona XtraBackup做物理备份，可以加--encrypt参数：

bash复制xtrabackup --backup --encrypt=AES256 --encrypt-key-file=/etc/backup/backup.key \
  --target-dir=/backup/full_$(date +%F)

备份文件保存位置也有讲究，不要和数据库放在同一块磁盘上，否则磁盘损坏意味着数据库和备份一起丢。有条件就异地备份，或者至少上传到对象存储，并设置私有读权限。

最后，每个月必须做一次恢复演练。我见过不止一次：DBA说“我们有备份”，结果真出问题的时候发现备份命令早就因为参数变化失败了、备份文件损坏了、恢复步骤没人会操作。恢复演练是验证备份可用性的唯一方式，这个动作不能省。

6. 加固后的验证与排障：把业务影响控制在可控范围

6.1 验证清单：一遍摸清加固效果

做完上面的加固操作之后，不是就完事了。我的习惯是用一组查询和命令快速验证所有措施是否生效：

sql复制-- 1. 查看所有账号，确认无匿名、无空密码、无多余root
SELECT user, host, authentication_string, plugin FROM mysql.user;

-- 2. 查看高危权限账号
SELECT user, host, Grant_priv, File_priv, Super_priv, Process_priv, Reload_priv
FROM mysql.user
WHERE Grant_priv = 'Y' OR File_priv = 'Y' OR Super_priv = 'Y' OR Process_priv = 'Y' OR Reload_priv = 'Y';

-- 3. 验证SSL
SHOW VARIABLES LIKE 'have_ssl';
SHOW STATUS LIKE 'Ssl_cipher';

-- 4. 验证密码策略
SHOW VARIABLES LIKE 'validate_password%';

-- 5. 查看密码过期策略
SHOW VARIABLES LIKE 'default_password_lifetime';

bash复制# 6. 验证监听地址
netstat -tlnp | grep 3306

# 7. 验证防火墙规则
iptables -L -n | grep 3306

如果这些检查都符合预期，加固工作算是完成了80%。剩下的20%是持续的日常巡检，而不是一次性动作。

6.2 常见误伤场景：改完把业务改挂了怎么办

加固操作非常容易引发“业务无感知、运维背大锅”的事故。我总结几个高频坑和处理思路：

误伤场景一：启用密码复杂度后，应用连不上。

应用里写死了旧密码，不符合新策略，密码校验失败。处理方式：先把validate_password策略临时调低，让应用能连上，然后推动开发修改配置文件里的密码，改好后再恢复强策略。不要为了迁就应用长期保留低策略。

误伤场景二：REQUIRE SSL后，应用报SSL连接错误。

应用连接串没带SSL参数。处理方式：检查应用使用的驱动版本，JDBC连接串加?sslMode=REQUIRED，其他语言同理。如果应用短时间内无法改代码，可以把该账号的REQUIRE SSL暂时去掉，但一定要设置一个明确的整改截止日期。

误伤场景三：回收SUPER之后，运维脚本跑不动了。

8.0的SET GLOBAL需要SYSTEM_VARIABLES_ADMIN权限，主从操作需要REPLICATION_SLAVE_ADMIN权限。处理方式：按实际需求把对应动态权限授权给特定账号：

sql复制GRANT SYSTEM_VARIABLES_ADMIN ON *.* TO 'dba'@'192.168.10.%';
GRANT REPLICATION_SLAVE_ADMIN ON *.* TO 'rep'@'192.168.10.%';

误伤场景四：主从复制断开。

清理root账号时把复制账号也删了，或者认证插件切换后复制账号无法通过认证。处理方式：复制账号单独保留，权限只要REPLICATION SLAVE和REPLICATION CLIENT，密码同样遵循强策略，但不要牵连进root账号清理的范围内。

最后说说我的习惯：任何配置变更之前，先备份my.cnf和相关数据字典；变更之后，观察至少一个业务周期的监控曲线，确认无异常再宣布完成。安全加固不是一次性工程，而是一个持续循环：巡检、发现问题、加固、验证、再巡检。把十项操作当成起点，下一步你还可以把安全基线核查做成脚本或者运维平台的能力，让每一次配置变更都能自动校验是否越界。

做DBA这些年，我最大的体会是：安全加固这件事，功夫全在“执行十次操作之外”。一个数据库被攻破，往往不是因为某个单点做得不够好，而是因为“到处都是漏洞”给了攻击者太低的门槛。从少暴露开始，到强口令兜底，再到留后路收尾，这十个操作做完，至少能把绝大多数无差别攻击挡在门外。