Linux测试环境弱密码与漏洞排查：Nacos、MySQL、Redis误报控制实战

直接说结论：在测试环境做弱密码和漏洞排查，最怕的不是扫不出问题，而是扫出一堆误报后没人愿意看，最后整个报告被当成噪声丢弃。我自己在内部演练时踩过这个坑——第一版扫描报告里，Nacos被标了十几个“高危”，结果人工复核后绝大多数是测试人员自己留下的调试配置和默认账号，真正该修的数据库弱密码反而被淹没在里面。所以这篇内容的核心思路不是“扫描器跑一遍出结果”，而是“如何在Linux测试主机上，用可控的一套命令和脚本，把Nacos、应用配置、数据库这三块的弱密码和已知漏洞捋清楚，同时把误报压到最低”。所有步骤都可以直接复制到测试环境执行，不需要额外装商业工具，纯命令行加简单脚本就能完成。

适合谁来参考：需要给团队做安全自查的运维、刚接手测试环境想做一次基线梳理的后端开发、以及准备做上线前安全评审但对自家测试环境心里没底的人。下面这套排查方案是我在实际环境中反复调整过的，至少能帮你省下一轮人工复核的时间。

1. 排查范围与误报控制的底层逻辑

1.1 为什么测试环境的“漏洞”很多都是假警报

测试环境比生产环境更容易出现弱密码，这是常态，但不代表所有弱密码都值得修。这里的关键在于区分“可被利用的弱密码”和“看起来像弱密码但实际无害”的情况。举个例子：Nacos控制台有个默认账号nacos/nacos，如果测试环境只在内网且没有映射端口，这个弱密码的真实风险其实很低。但如果你用商业扫描器去扫，它会把这个标记成“高危”，因为它只看端口暴露和默认口令，不看网络边界。

所以，降低误报的第一条原则是：先做资产和边界梳理，再做弱口令验证，最后才谈漏洞扫描。下面是具体的分层排查思路：

• 第一层：确认哪些端口是真正对外开放的（监听在0.0.0.0还是127.0.0.1决定了暴露面）
• 第二层：确认哪些服务有真实的弱密码风险（能登录进去才算风险，登不进去的只能算疑似）
• 第三层：确认哪些已知漏洞在当前版本上真实存在（版本匹配比泛泛的CVE扫描可靠得多）

这三层下来，误报率能降低一半以上。

1.2 在动手排查前，先建好这三张清单

在开始执行命令之前，建议先花十分钟建立三张基础清单。这不是浪费时间，而是为了避免排查过程中漏掉关键对象，也为了让后续的复核有据可依。

第一张清单是端口清单，用ss -tlnp或netstat -tlnp列出当前主机上所有监听端口，重点记录端口号、对应进程、监听地址（是0.0.0.0还是127.0.0.1）。第二张清单是服务清单，把主机上跑的应用列出来，特别是Nacos、MySQL、Redis、PostgreSQL这类带认证的中间件，记录它们的版本号和部署方式（容器/Docker、二进制、K8s）。第三张清单是配置清单，包括Nacos的application.properties、数据库的配置文件、应用代码里的数据源配置等，重点找明文密码和默认配置。

建立清单的命令很简单，但很重要：

bash复制# 查看所有监听端口及其所属进程
ss -tlnp

# 查看主机的监听地址明细，区分内网/外网暴露
ip addr show | grep -E "^[0-9]+:|inet "

# 查看Docker容器列表（如果测试环境用了容器化部署）
docker ps --format "table {{.Names}}\t{{.Image}}\t{{.Ports}}"

# 查看当前所有Java进程（Nacos是Java应用，优先确认）
ps -ef | grep java | grep -v grep

这三张清单为什么要先建？因为在排查弱密码时，你总得知道哪些服务是这次要纳入范围的。如果连本机起了哪些服务、每个服务监听在哪个地址都不清楚，后面的扫描和验证就没有靶子。更重要的是，这个清单本身就是排查报告的一部分，出了报告之后，复核的人可以拿着这个清单去核对，而不是从头再摸一遍环境。

2. 系统层弱密码排查：比跑字典更靠谱的是策略爆破

2.1 账号密码策略检查：先看“门锁”强度，再试“钥匙”

在很多人的直觉里，弱密码排查等于跑一遍暴力破解工具，比如Hydra、Medusa。这种思路不能说错，但在测试环境里效率很低——如果账号密码策略本身就允许弱密码存在，就算你这次没跑出来，下次还是会出问题。所以我的排查顺序是：先检查系统的密码策略和账号状态，再对确认真实存在的弱密码做定向验证。

在Linux主机上，第一件事是查密码策略配置：

bash复制# 查看密码策略（有效期限、最小长度、过期提醒）
grep -E "PASS_MAX_DAYS|PASS_MIN_DAYS|PASS_MIN_LEN|PASS_WARN_AGE" /etc/login.defs

# 查看当前所有用户的密码状态，重点看哪些用户没有锁定、哪些密码为空
awk -F: '($2==""){print $1" 空密码"}' /etc/shadow
awk -F: '($3==0){print $1" UID为0，等价于root"}' /etc/passwd

这里有个容易忽略的地方：/etc/shadow里的密码字段如果是!或*，表示该账号已锁定或无法通过密码登录，这是正常状态，不是弱密码。但如果某个非系统账号的密码字段是明文可见的哈希且哈希强度很低（比如DES算法的13位哈希），那就要警惕了。不过更实用的做法是直接对系统账号做一轮“不锁定的策略爆破”——注意是不锁定，意思是只做验证，不做真正的暴力尝试，因为真正跑字典容易触发账号锁定机制，导致测试环境账号被锁，反而添乱。

2.2 用chage和passwd -S快速筛选高风险账号

对于测试环境，我一般用下面这组命令来快速识别高风险账号：

bash复制# 查看所有用户最近一次修改密码的时间，超过90天没改的老账号要关注
chage -l root
chage -l nacos
chage -l mysql

# 查看指定账号的密码状态，L开头表示锁定，P开头表示可用
passwd -S root
passwd -S nacos

这里要特别提醒一个测试环境常见的坑：很多测试环境喜欢把root密码设为123456或root，但shell历史记录和用户目录下的脚本里经常会残留明文密码。扫描器不会帮你扫这个，只有人工检查才能发现。所以当我排查弱密码时，一定会带上这一步：

bash复制# 查找家目录和临时目录下的可疑脚本文件，重点看里面是否有密码字段
grep -rE "password|passwd|pwd" /home/*/ --include="*.sh" --include="*.sql" --include="*.env" 2>/dev/null

# 查找环境变量文件里的敏感信息
find /etc/profile.d/ /root/ -name "*.sh" -exec grep -lE "password|passwd" {} \; 2>/dev/null

这一步不算是“弱密码排查”的传统动作，但实测中它的产出率比跑字典高得多。很多测试环境都是开发同学本机起的服务，密码直接写在启动脚本里，一找一个准。

3. Nacos弱密码与已知漏洞：从控制台到配置中心全部过一遍

3.1 Nacos默认口令和弱口令的验证思路

Nacos作为注册中心和配置中心，在测试环境里出现弱密码的几率非常高。原因很简单：开发同学本地起了Nacos就直接用默认配置，密码从来没改过，而且Nacos 1.x和2.x的默认密码都是nacos/nacos。 要验证当前Nacos是否存在弱密码，不需要跑工具，直接用curl请求Nacos的API接口就行。

先确认Nacos的版本和端口：

bash复制# 查看Nacos进程信息
ps -ef | grep nacos | grep -v grep

# 查看Nacos监听端口，通常在8848
ss -tlnp | grep 8848

然后验证默认口令：

bash复制# 尝试用默认账号登录Nacos控制台
curl -X POST 'http://127.0.0.1:8848/nacos/v1/auth/login' -d 'username=nacos&password=nacos'

# 如果登录成功，返回的JSON里会包含accessToken

返回结果里如果出现accessToken字段，那就说明默认密码还没改。要注意的是，此时不要继续用这个token去操作Nacos配置，因为排查任务只是确认弱口令是否存在，改配置是修复阶段的事情。在测试环境里确认弱密码后，我一般直接在文档里标记“确认存在”，然后由开发同学去改，而不是在排查阶段顺手改掉——排查和修复要分开，这样报告才清晰。

3.2 Nacos未授权访问与配置文件泄露的检测点

除了控制台弱密码，Nacos还有一个更隐蔽的问题：部分API接口存在未授权访问风险，可以直接读取配置信息或用户列表。这个在Nacos 1.4以前比较常见，2.x版本有所收敛。

检测方法如下：

bash复制# 尝试直接获取用户列表
curl -X GET 'http://127.0.0.1:8848/nacos/v1/auth/users' -d 'pageNo=1&pageSize=9'

# 尝试直接读取某个配置
curl -X GET 'http://127.0.0.1:8848/nacos/v1/cs/configs?dataId=application-dev.yml&group=DEFAULT_GROUP'

如果这两个接口返回了用户列表或者配置内容，那就是未授权访问漏洞。但这里要强调一个误报控制点：Nacos自带的一些公开接口本身就不需要鉴权，比如健康检查、配置查询在某些版本下默认开放，这是设计如此，不代表漏洞。所以不要一看到能返回数据就报漏洞，要先对照版本确认接口是否有鉴权要求。最稳妥的方法是看Nacos的官方文档，确认当前版本的接口鉴权规则；否则很容易把正常功能误判成安全漏洞。

3.3 Nacos配置中心里暗藏的数据库连接串和密钥

Nacos弱密码排查的最终目的，不只是保护Nacos本身，更要防止攻击者通过Nacos控制台拿到配置中心的敏感数据。所以在排查Nacos时，除了验证弱口令，我还会主动去检查已经存在的配置内容里有没有泄露数据库连接串和密钥。

具体做法是在确认能登录Nacos后（或者是通过未授权访问接口），查看配置列表中的关键配置项：

bash复制# 通过API读取配置列表
curl -X GET 'http://127.0.0.1:8848/nacos/v1/cs/configs?search=accurate&dataId=&group=&pageNo=1&pageSize=100' -H "accessToken: <你的token>"

然后从返回的配置内容里，用grep筛选敏感字段：

bash复制# 提取配置中包含password、url、username的字段
curl -X GET 'http://127.0.0.1:8848/nacos/v1/cs/configs?dataId=xxx&group=xxx' -H "accessToken: <你的token>" | grep -iE "password|passwd|username|jdbc:mysql|jdbc:postgresql|redis://"

这一步能帮你快速定位那些“可以连数据库”的配置项。我在实际排查中经常发现，Nacos配置里会把MySQL的root密码或者Redis的明文密码放在dataId为application-xxx.yml的配置里。这些问题往往比Nacos本身弱口令更严重，因为攻击者一旦拿到这些配置，等于拿到了整个测试环境的数据访问权限。

4. 应用侧排查：从端口反查进程到日志中的明文密码

4.1 通过端口反查是哪个应用在监听，再做定向检测

在测试环境里，应用五花八门，最有效的排查方式是从端口反查进程，再根据进程确认应用类型，而不是泛泛地扫描所有端口。这样做的好处是能减少误报——你只会对真实存在的服务做深入检查，而不是因为端口开放就臆测存在某个漏洞。

bash复制# 根据端口查进程
ss -tlnp | grep 3306    # MySQL
ss -tlnp | grep 6379    # Redis
ss -tlnp | grep 8848    # Nacos
ss -tlnp | grep 8080    # 常见的Java应用
ss -tlnp | grep 5432    # PostgreSQL

# 查看端口所属进程的详细信息
lsof -i :8080

拿到进程后，进入进程对应的部署目录，查看应用的配置文件：

bash复制# 找到进程的启动路径和参数
ps -ef | grep 8080 | grep -v grep

# 查看Java应用的启动参数中的配置文件名
# 通常会带--spring.config.location=xxx参数

4.2 应用配置文件中最常见的四类弱配置

在测试环境的Spring Boot、Node.js、Python项目中，日志里打明文密码和配置文件里写死口令极其常见。我自己总结过应用侧常见的四类弱配置，每次排查都会固定检查这四类：

第一类是数据库连接串里的明文密码。不管是什么语言写的应用，配置文件里大概率有一行spring.datasource.password=xxxx或db_password=xxxx，而且几乎所有测试环境这里都是明文。第二类是Redis未设密码或弱密码。Redis默认没密码，如果配置里没有requirepass，那可以直接连接，这比弱密码还严重。第三类是日志文件里残留的密码或token。应用启动时如果打了debug日志，经常把参数一并打出来，密码就在其中。第四类是前端的静态文件里内嵌API密钥。开发的同学偶尔图方便，把一些密钥直接写在JS文件里。

排查命令参考如下：

bash复制# 在应用目录下搜索配置文件中的密码字段
find /opt/apps -name "*.yml" -o -name "*.yaml" -o -name "*.properties" | xargs grep -lE "password|passwd" 2>/dev/null

# 在日志目录中搜索可能的明文密码记录
find /var/log /opt/apps/logs -name "*.log" -exec grep -lE "password=|passwd=" {} \; 2>/dev/null

# 检查Redis是否设置了密码
redis-cli -h 127.0.0.1 -p 6379 ping
# 如果返回PONG，说明没有密码保护，可以直连

4.3 Tomcat和Nginx里的后门与调试接口

测试环境中，Tomcat和Nginx也是弱配置的重灾区。Tomcat的manager页面经常是空密码或者tomcat/tomcat，Nginx则可能出现alias配置导致的路径穿越漏洞。

检测Tomcat弱密码：

bash复制# 尝试访问Tomcat manager页面
curl -u tomcat:tomcat http://127.0.0.1:8080/manager/html
curl -u admin:admin http://127.0.0.1:8080/manager/html

如果返回HTTP 200或包含“Manager”字样的页面，说明弱密码存在。如果返回403或401，说明有访问控制或密码正确性校验，此时不建议继续尝试多次，避免触发锁定机制。

检测Nginx路径穿越，重点检查alias配置：

bash复制# 查看Nginx配置
cat /etc/nginx/conf.d/*.conf

# 检测是否配置了alias且没有加“/”约束
# 示例：location /file { alias /home/wrong; }
# 这种常见配置容易引发目录穿越

Nginx路径穿越的检测如果用curl做，要注意请求路径的拼法，否则容易误报。比如location /file配置了alias /var/www/，正确路径应该是/file/xxx，但如果你直接请求/file../可能不触发漏洞。所以我在这一块更倾向于直接看配置文件，而不是用工具扫描。配置检查的误报率远低于主动扫描。

5. 数据库弱密码检测：针对MySQL、Redis、PostgreSQL分别给出验证命令

5.1 MySQL：从空密码到已知CVE，分两步走

MySQL是测试环境里最常出现弱密码的组件。通常存在的形态有三类：root密码为空、root密码是123456或root、使用了存在已知漏洞的旧版本。针对前两类弱密码，验证方式很简单：

bash复制# 测试空密码能否直接登录
mysql -h 127.0.0.1 -u root -P 3306

# 测试弱密码
mysql -h 127.0.0.1 -u root -proot -P 3306
mysql -h 127.0.0.1 -u root -p123456 -P 3306

需要注意，-p和密码之间不要有空格，不然MySQL会把空格当成密码的一部分。这一步如果返回了Welcome to the MySQL monitor，说明弱密码确认存在。

针对旧版本MySQL的已知CVE，不能只靠登录验证，还要查版本号：

bash复制# 登录后查询版本号
mysql -h 127.0.0.1 -u root -proot -e "SELECT VERSION();"

# 对比版本是否存在已知漏洞，例如：
# MySQL 5.6.x 以下版本存在提权漏洞
# MySQL 5.7.x 存在特定的身份验证绕过漏洞

5.2 Redis：最容易被忽略的“裸奔”状态

Redis在测试环境里比MySQL更危险，因为很多开发同学根本不会给Redis设密码，而Redis一旦未授权访问，攻击者可以直接写入SSH公钥、计划任务甚至直接控制主机。所以Redis的排查优先级应该比MySQL更高。

验证Redis是否存在未授权访问：

bash复制# 直接连接Redis，不需要密码
redis-cli -h 127.0.0.1 -p 6379 ping

# 如果能返回PONG，说明未授权访问，严重级别直接拉满
# 查看Redis当前配置中的requirepass
redis-cli -h 127.0.0.1 -p 6379 CONFIG GET requirepass

如果CONFIG GET requirepass返回空值，说明Redis没有密码。如果返回一个字符串但长度很短（比如123或123456），那么就是弱密码。Redis弱密码的验证可以这样：

bash复制# 尝试登录
redis-cli -h 127.0.0.1 -p 6379 -a 123456 ping
# 如果返回PONG，说明弱密码可登录

这里提醒一句：redis-cli -a带了密码会打印警告，内容是无所谓的，执行完就自动切换，实际使用不受影响。不过如果在生产环境操作，建议先加-a参数后还是注意日志记录，避免密码被记录到shell历史里。

Redis相关的已知漏洞，比较著名的有未授权访问配合Cron计划任务、SSH公钥写入，以及Redis 4.x/5.x的Lua沙箱逃逸。判断版本：

bash复制redis-server --version

如果版本低于6.x，建议在报告中标记“存在旧版本已知风险”，因为官方对4.x和5.x的维护已经非常有限，即使没有利用到的漏洞，也应该升级。

5.3 PostgreSQL和MongoDB也需要纳入检查

虽然题目里重点提到了MySQL和Redis，但很多测试环境里也会有PostgreSQL和MongoDB。这两个组件的弱密码检测逻辑是一样的，只是命令不同：

bash复制# PostgreSQL弱密码验证
psql -h 127.0.0.1 -U postgres
# 会提示输入密码，可以尝试postgres、123456、admin

# MongoDB无认证检测
mongo --host 127.0.0.1 --port 27017
# 如果直接进入shell，说明未开启认证

PostgreSQL还有一个容易出问题的点：pg_hba.conf里trust认证方式。如果使用的是trust而不是md5或scram-sha-256，那就不需要密码就能登录。检查方式：

bash复制cat /etc/postgresql/*/main/pg_hba.conf | grep -v "^#" | grep trust

这个比弱密码更严重，因为不需要试密码。

5.4 数据库弱密码排查中容易误判的情况

有一个坑必须单独讲一下：某些应用连数据库用的是专用账号，密码长度很长且随机，但应用配置里数据库连接串暴露在Nacos或代码中。这种情况下，账号本身不是弱密码，但因为配置泄露，风险等级其实比弱密码还高。所以做数据库弱密码排查时，不能只试弱密码，更要把“配置中是否泄露了数据库密码”当成独立的检查项纳进来，这也是前面Nacos和应用排查部分为什么一直强调读配置的原因。

还有一类误报：MySQL 8.0的默认认证插件是caching_sha2_password，如果你用旧版本客户端去连，会报认证失败，但这不是弱密码问题，是版本兼容问题。所以验证时如果登录失败，要多确认一下是不是客户端版本太旧导致的，别把认证失败当成密码错误。

6. 已知漏洞的版本匹配式排查：比泛泛地CVE扫描好用得多

6.1 为什么通用扫描器的结果需要人工复核

通用漏洞扫描器（比如一些开源工具）确实能扫出不少问题，但它的缺陷在于依赖版本数据库匹配和主动探测的规则集，在测试环境里经常出现两类误报：

• 一类是版本误报：扫描器识别到服务版本为X，但不知道这个版本在特定发行版里已经打了补丁，于是仍然报漏洞
• 另一类是逻辑误报：扫描器通过响应判断存在某个漏洞，但实际上它触发的只是一个无害的页面，并非真实的漏洞入口

所以我在测试环境排查时，更倾向于**“按版本号手动匹配已知CVE”**的方式来降低误报。具体方法是：

1. 先用命令拿到各组件的精确版本号
2. 然后在CVE库中按“产品名+版本号”关键字检索
3. 只把官方公告中确认受影响且当前环境在影响范围内的漏洞写入报告

6.2 Nacos、MySQL、Redis、JDK的精确版本提取

bash复制# Nacos版本获取
cat /opt/nacos/conf/application.properties | grep version
curl -X GET 'http://127.0.0.1:8848/nacos/v1/console/health/readiness'

# MySQL版本获取
mysql --version

# Redis版本获取
redis-server --version

# JDK版本获取（Java应用通用）
java -version 2>&1

# 查看应用使用的基础镜像版本（容器部署时）
docker inspect <容器名> | grep Image

拿到版本后，可以用CVE列表对比。比如Nacos 1.4.1之前存在认证绕过漏洞，MySQL 5.7.41之前存在特定提权问题，Redis 4.x存在主从复制利用链等。这里不用把所有CVE编号全罗列出来，但至少要把主版本号匹配上。

6.3 用Nuclei做一次定向的POC级验证以降低误报

在版本匹配的基础上，我还会用Nuclei做一次定向的POC级验证。Nuclei最大的价值在于它不是靠版本号猜，而是真正发送探测请求，并判断响应是否符合漏洞特征。这样能过滤掉大量“版本匹配但实际不能利用”的误报。

bash复制# 下载Nuclei并更新模板
# 这里只演示思路和常用命令，具体安装方式参考官方README
nuclei -u http://127.0.0.1:8848 -t cves/2021/ -rl 3

# 指定Nacos相关模板
nuclei -u http://127.0.0.1:8848 -tags nacos -rl 3

# 扫描常见数据库管理端口
nuclei -u http://127.0.0.1:8080 -tags tomcat -rl 3

这里有个经验：扫描时加-rl 3（每秒最多3个请求）是为了不把测试环境的服务打挂，尤其是Nacos这类对性能敏感的应用。如果你在测试环境用默认速率跑，Nacos很可能会因为线程池被打满而假死，到时候你分不清是“服务真的有问题”还是“被扫挂了”。

Nuclei的模板更新也很重要，最好在扫描前执行一次更新，因为CVE模板一直在补充，隔段时间不更新，很多新漏洞根本扫不出来。不过要注意，Nuclei是按需发送POC，扫描结果中仍然可能出现误报，尤其是那些依赖特定响应码判断的模板，可能会因为应用的自定义错误页面而误判。所以Nuclei的结果也要结合前面的端口反查和配置检查来交叉验证，不要直接作为最终结论。

7. 自动化脚本与报告整理：把排查结果变成可执行清单

7.1 一个轻量级的排查脚本框架

手动执行上面这些命令，一次完整的排查大概需要半小时到一小时，其实还好。但如果要反复在多台测试主机上执行，还是建议把命令整理成一个脚本框架。我自己用的结构很简单，就是一个Bash脚本加几个子函数，输出结果统一落到/tmp/audit_result/目录下。

bash复制#!/bin/bash
# 测试环境弱密码和漏洞排查脚本（轻量版）
AUDIT_DIR=/tmp/audit_result
mkdir -p $AUDIT_DIR

echo "[+] 1. 收集系统账号信息"
awk -F: '($3>=1000){print $1,$3,$7}' /etc/passwd > $AUDIT_DIR/system_users.txt
awk -F: '($2==""){print $1" 空密码"}' /etc/shadow > $AUDIT_DIR/system_empty_passwd.txt

echo "[+] 2. 收集端口监听信息"
ss -tlnp > $AUDIT_DIR/listening_ports.txt

echo "[+] 3. Nacos弱口令检测"
curl -s -X POST 'http://127.0.0.1:8848/nacos/v1/auth/login' -d 'username=nacos&password=nacos' > $AUDIT_DIR/nacos_default_login.txt
grep -q "accessToken" $AUDIT_DIR/nacos_default_login.txt && echo "Nacos默认密码可登录" >> $AUDIT_DIR/findings.txt

echo "[+] 4. Redis未授权检测"
redis-cli -h 127.0.0.1 -p 6379 ping > $AUDIT_DIR/redis_ping.txt
grep -q "PONG" $AUDIT_DIR/redis_ping.txt && echo "Redis未授权可连接" >> $AUDIT_DIR/findings.txt

echo "[+] 5. MySQL弱密码检测"
mysql -h 127.0.0.1 -u root -proot -e "SELECT 1;" > /dev/null 2>&1 && echo "MySQL root/root可登录" >> $AUDIT_DIR/findings.txt
mysql -h 127.0.0.1 -u root -p123456 -e "SELECT 1;" > /dev/null 2>&1 && echo "MySQL root/123456可登录" >> $AUDIT_DIR/findings.txt

echo "[+] 6. 搜索配置文件中的明文密码"
grep -rE "password[[:space:]]*[:=][[:space:]]*[^/].{0,20}" /opt/apps --include="*.yml" --include="*.properties" --include="*.env" 2>/dev/null > $AUDIT_DIR/config_plaintext_passwords.txt

echo "[+] 完成，报告文件已保存到 $AUDIT_DIR"

这个脚本只做信息收集和初步判定，不执行任何修复动作。如果需要输出完整建议，可以在这个脚本基础上对每个findings.txt中的条目追加“建议操作”字段，例如“将Nacos默认密码改为强密码，并开启鉴权”。

需要注意的是，MySQL的探测密码不要写太多组，建议只测最常见的三到五个。因为MySQL如果配置了max_connect_errors参数，连续错误会暂时锁IP，反而影响后面正常使用。

7.2 如何给每条发现定级，确保修复的人能分清轻重缓急

排查结果的输出不能是一堆“存在风险”的平铺列表，那样等于没排查。我建议按“可利用性、影响范围、是否需要立即修复”三个维度给每条发现定级：

• 紧急：可未授权访问且可直接获取数据（如Redis未授权可写、Nacos配置泄露、MySQL root空密码）。这一类必须当天修
• 高：弱密码可登录但影响范围有限（如仅本机可访问的MySQL弱密码、Nacos默认密码但无法未授权读取配置）。建议一周内修
• 中：版本匹配但无法在测试环境直接验证利用（比如某个旧版本组件存在潜在CVE但没有公开利用工具，且服务仅内网可访问）。可以排到迭代计划里

表格输出示例：

这个表格可以直接贴到排查报告里，也可以转成Excel给团队共享。

7.3 排查完成后应该立即做的三件事

排查完成不意味着事情结束，后面还有三件事要做，缺一不可：

第一件事是修正测试环境的基线配置。把Nacos、Redis、MySQL、应用配置里的弱密码和默认口令全部改掉，如果测试环境有Terraform或Ansible之类的自动化管理，应该把这些配置一起改了，防止下次重建环境时又复现弱密码。

第二件事是把排查步骤沉淀成团队手册。这次你手动执行的命令、脚本、判断标准、定级规则，都是可以复用的资产。下次新人接手时，对着手册就能独立完成同样的排查，不用再从零摸索。

第三件事是在测试环境外建立一个“定期复查”提醒。测试环境变化很快，今天修完的弱密码，下周开发同学可能又改回来了。所以每两周或每轮迭代结束时，跑一遍排查脚本，成本很低，但效果很实在。我自己就是把上面的脚本配置了一个定期任务，每次跑完自动把报告发到群里，不用人工提醒，大家自己看到就会去修。

我在实际测试环境中跑完这套流程后，最大的感受是：弱密码和漏洞风险在测试环境里几乎永远存在，但真正值钱的是把你自己的排查方法论固定下来，让它成为团队能复用的能力。如果一篇报告只能证明“我们环境里有弱密码”，那它的价值是有限的；但如果它能带动团队把Nacos、Redis、MySQL、应用配置的基线都理顺，以后每次环境更新都有一道自动检查的防线，那这次排查的收益就是长期的。这套步骤未必每个环节都适合你的环境，但只要把“先摸资产、再验证弱口令、最后做版本匹配”这条主线抓住，误报和漏报的平衡点就能掌握在你手里。