JBoss等保测评命令全集：身份鉴别、访问控制与安全加固实战指南

做等保测评这些年，每次遇到JBoss我都会多留个心眼。这倒不是说JBoss本身有多脆弱，而是它在国内政企系统里的存量太大，很多还是十多年前的JBoss 4.x/5.x版本，默认配置下几条命令就能把管理后台和反序列化入口摸得一清二楚。不少同行问过我：等保测评命令——jboss到底该跑哪些命令、看哪些输出？所以这篇就把我在现场最常用的一套命令、检查思路和踩过的坑整理出来，给做测评、做运维、做安全加固的读者一个能直接抄作业的参考。

如果你正好要对JBoss做等保测评，或者被领导安排去排查一台老旧的JBoss服务器，这篇文章会比较对口。命令本身不难，但每一条输出对应哪个控制点、哪个结果是高风险项，我会一并讲清楚。

1. 等保测评中JBoss检查的整体思路

1.1 先搞清楚你面对的是哪个JBoss

JBoss这个名称下至少分三个时代：4.x/5.x/6.x属于老架构，核心是JMX微容器，管理控制台是JSP页面，部署走deploy目录热部署；7.x开始改名JBoss AS 7，后面演变成WildFly，配置中心变成standalone.xml/domain.xml，管理方式变成CLI。如果你拿老版本路径去找新版本，或者反着来，测评现场就会很尴尬。

我一般会先用一组命令快速定位版本和安装位置：

ps -ef | grep java | grep -i jboss ls -d /usr/local/jboss* /opt/jboss* /app/jboss* 2>/dev/null find / -maxdepth 3 -name "run.jar" -o -name "jboss-modules.jar" 2>/dev/null rpm -qa | grep -i jboss 2>/dev/null

ps -ef看进程启动参数，里面通常会带-Djboss.server.base.dir或-Djboss.home.dir，直接暴露JAVA路径和服务器目录；ls和find用于定位安装目录；如果是通过rpm方式安装的发行版，rpm -qa能直接给出精确版本号。看到jboss-4.2.3.GA、jboss-as-7.1.1.Final、wildfly-26.0.0.Final这类目录名，测评对象的基本画像就有了。

版本直接决定后续检查项的侧重点：老版本重点看jmx-console、JMXInvokerServlet这类反序列化入口，新版本则重点看management realm、CLI用户、SSL配置。这一步别省，我见过有人拿着WildFly的命令去查JBoss 5，结果因为路径不存在，白白浪费半天。

1.2 把等保控制点翻译成命令检查项

等保测评不是漏洞扫描，所有命令最终要对应到《测评要求》的控制点上。做JBoss时我习惯把检查项分成四类：

• 身份鉴别：管理后台是否有认证、有无默认口令、口令强度、登录失败限制；
• 访问控制：管理端口是否暴露、危险路径或服务是否可匿名访问、部署权限是否最小化；
• 安全审计：登录、部署、策略变更等操作是否记录，日志留存和保护是否到位；
• 入侵防范：是否关闭不安全的Invoker、是否有webshell或异常进程、补丁版本是否更新。

每一类命令都围绕“取证”展开。测评不是让你证明系统“可能有问题”，而是要用命令输出固定证据：端口暴露情况、HTTP状态码、配置文件内容、日志记录。这些才是写进报告的依据。所以下面的命令，我会顺带说一句“这条输出对应哪个检查项”，这样你回填结果表时不需要再猜。

2. 环境信息收集：先摸清JBoss装了啥、跑在哪

2.1 进程、端口和监听地址一锅端

进入现场第一件事不是翻配置文件，而是看进程和端口。我常用的命令就几条：

ps -ef | grep -i jboss netstat -tlnp | grep 8080 ss -antp | grep java

8080是JBoss默认HTTP端口，但生产环境常被改掉，所以更好用ss -antp | grep java一把梭，把所有java进程监听的端口都拉出来。重点关注监听地址是0.0.0.0还是127.0.0.1，这对应等保“访问控制”里管理接口应仅限管理网段访问的要求。我看到不少系统，jmx-console监听在0.0.0.0，等保三级基本一查一个准。

另外，一个机器上可能同时装了Tomcat和JBoss，只grep java会分不清。ps -ef里看启动参数，JBoss通常会有org.jboss.Main或jboss-modules.jar，Tomcat一般是catalina.jar，别认错。我在现场还会顺手执行：

curl -s -I -m 5 http://127.0.0.1:8080/

目的是确认JBoss的HTTP服务本身是活的。如果curl返回curl: (7) Failed to connect，说明端口判断有误，要么不是8080，要么服务没启动，先别急着往下查。

2.2 从目录结构和配置文件名反推架构

定位端口后，进安装目录看结构和关键配置，老版本和新版本路径差异很大，这里给你一个我平时用的对照表：

可以用下面命令快速确认目录内容：

ls -la /usr/local/jboss/server/default/deploy/ cat /usr/local/jboss/bin/run.conf | grep -v "^#" | grep .

只看目录里有哪些war/ear，就能判断业务组件和风险入口。比如看到jmx-console.war、web-console.war、invoker.war躺在deploy目录里，那基本等于给测评报告送了一份“大礼”——这几个war在等保检查里几乎必看，暴露给外部就是高危。

对于7.x/WildFly，部署目录和配置路径不同，但思路一样：先ls standalone/deployments，再grep -n "management" standalone/configuration/standalone.xml看管理接口配置。路径对了，后面才不会被海量文件带偏。

3. 身份鉴别：账号、口令、认证策略必须查三样

3.1 管理控制台是否裸奔，curl一眼看出

JBoss身份鉴别最经典的检查点是JMX管理控制台和Web控制台是否可未授权访问。老版本JBoss默认部署了jmx-console.war，如果配置不当，任何人都可以直接打开管理页面，这是等保测评里身份鉴别和访问控制两个控制点的高频不符合项。

我在现场用最多的是curl探测命令：

curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:8080/jmx-console/ curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:8080/web-console/ curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:8080/invoker/JMXInvokerServlet

返回200说明没有认证或认证被绕过，赶紧截屏留证；返回401说明有基础认证，但还要继续检查口令是否弱；返回404可能war未部署或路径改了，这时去deploy目录确认一下是否存在，避免漏测。有个细节：curl -I发的是HEAD请求，有时候应用对HEAD请求的处理跟GET不一致，我通常curl -s -I和curl -s两个都试一次，同时加-m 5超时，避免接口卡死。

3.2 口令存储文件：拿到手才能判断策略是否合规

等保三级里“身份鉴别”强调管理用户身份标识唯一、口令复杂度、登录失败处理。JBoss老版本默认把管理账号写在props/jmx-console-users.properties和roles.properties里，很多系统装完就没改。我常用这两条命令查看：

cat /usr/local/jboss/server/default/conf/props/jmx-console-users.properties grep -v "^#" /usr/local/jboss/server/default/conf/props/roles.properties | grep -i "jmx-console\|web-console"

我曾经在一台测评机器上看到文件里写着明文密码admin=admin，用户名和口令居然一样。这种结果不需要再做复杂的验证，直接判定“未修改默认口令”，因为在真实攻击者手里，这就是一键进后台。

新版JBoss 7+/WildFly的管理用户存在mgmt-users.properties，口令是加盐哈希，比明文好了不少，但同样要检查是否存在弱口令（如admin），以及是否只允许本机或管理网段访问管理接口：

grep -v "^#" /usr/local/wildfly/standalone/configuration/mgmt-users.properties

如果文件里能看到用户名和哈希，还要确认对应的角色是否被授予了admin、deployer等敏感角色，这对应“权限分离”要求。别只盯着口令强度，权限分配越权也是等保扣分项。

3.3 登录失败策略和超时机制也要看

等保要求“采取技术措施，对登录失败进行处理”。JBoss老版本靠登录模块的配置来限制，但很多默认配置根本没有失败锁定。检查时我会在login-config.xml里搜关键配置：

grep -i -n "lockout\|maxLoginAttempts\|session-timeout" /usr/local/jboss/server/default/conf/login-config.xml

搜不到内容不代表没问题——恰恰说明没有登录失败限制。新版WildFly可以在elytron里配置lockout，配置更复杂，但测评逻辑一样：看管理端点有没有失败锁定、会话超时、访问日志记录。如果厂商说“靠防火墙挡着”，等保测评不认这个，必须落实到应用层配置。

4. 访问控制与部署权限：危险入口和文件权限一个不能少

4.1 用ss和curl锁定管理接口暴露面

看管理接口是否暴露，不能只看有没有认证。即使有认证，如果管理端口直接暴露到互联网，一样不符合“应仅允许白名单地址访问”的要求。我先看监听地址，再看服务是否响应：

ss -antp | grep 8080 ss -antp | grep 9990

9990是WildFly管理控制台默认端口，8080是HTTP服务端口。输出里的listen地址如果显示0.0.0.0:*就要格外注意。再配合curl -s -I http://目标IP:9990/验证外部请求能否到达。我在等保三级系统里见过把WildFly的management端口直接映射到公网的方案，一问厂商，说是为了远程维护方便。测评视角下这就属于高风险项，端口能做到仅内网访问，或通过堡垒机代理访问，才是合规做法。

4.2 部署目录查风险文件，别放过备份和临时文件

访问控制还涉及文件权限和敏感数据泄露。部署目录里除了war包，经常能看到以下几种东西：

• .bak、.zip、.sql、.war.zip之类的备份文件；
• .svn、.git目录残留；
• 解压后的war目录里藏着JSP源码。

我用这组命令快速排查：

find /usr/local/jboss -name "*.bak" -o -name "*.zip" -o -name "*.sql" 2>/dev/null find /usr/local/jboss -type d -name ".svn" -o -type d -name ".git" 2>/dev/null ls -la /usr/local/jboss/server/default/deploy/*/ 2>/dev/null

有一次我在deploy目录下直接发现一个db_backup.zip，解压出来是数据库脚本，包含生产库表结构和部分字段注释。这类文件在等保测评中属于“敏感信息泄露”隐患，如果业务网段被其他设备渗透，等于把数据库目录送给对方。写报告时我会把文件路径、大小、修改时间全部记下来，作为证据附件。

文件权限也要用ls -l检查，尤其是配置文件。配置文件如果对普通用户可读，甚至全局可写，就是“配置信息保护”方面的问题。我常看这两个文件：

ls -l /usr/local/jboss/server/default/conf/login-config.xml ls -l /usr/local/jboss/standalone/configuration/standalone.xml

正常的部署建议是属主root或jboss用户，权限640即可。如果看到-rw-r--r--或-rwxrwxrwx，我通常建议整改收紧。

4.3 Hot Deploy和Invoker：方便和安全二选一

老版本JBoss默认开启热部署，deploy目录里丢一个war就自动发布。开发环境很方便，生产环境却可能成为风险面。检查是否开启热部署，看配置文件：

grep -i -n "auto.deploy\|ScanEnabled\|Deployer" /usr/local/jboss/server/default/deploy/hsqldb-ds.xml /usr/local/jboss/server/default/conf/jboss-service.xml

另一个重点是JMXInvokerServlet。这个Servlet本质上是把JMX调用封装成HTTP接口，如果对外开放，等于把服务器的JMX操作暴露出去，是反序列化攻击最常利用的入口。检查命令：

curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:8080/invoker/JMXInvokerServlet

老版本新装即默认有，且这个路径不需要额外的认证配置，很多系统把整个deploy目录原样搬到生产。等保测评里我遇到这类开放路径，一般直接下“高危”结论——不是一定被打了，而是攻击链太成熟，不想赌运气。整改建议就是删除war包，或在防火墙层面封禁路径，同时确认业务不受影响。

5. 安全审计与日志：该记住的必须有记录

5.1 找到日志文件，先看时间范围和敏感操作

安全审计在等保里通常要求覆盖每个用户、覆盖重要安全事件，且日志留存不少于6个月。JBoss自身日志如果只开info级别，很多操作记录其实是不够的。我常用下面命令定位并检查日志：

ls -lh /usr/local/jboss/server/default/log/ tail -n 100 /usr/local/jboss/server/default/log/server.log

看server.log、boot.log、audit.log是否滚动归档，归档大小和时间跨度。再用grep筛选登录、部署、异常事件关键词：

grep -i -n "authentication\|login\|deploy\|undeploy\|error\|exception" /usr/local/jboss/server/default/log/server.log | tail -n 50

如果日志里只有启动信息，没有用户登录、部署变更等操作记录，说明审计范围不全。新版WildFly的审计日志可以在standalone.xml里配置audit-log，默认也可能不记录到文件，要现场确认。

5.2 系统层审计和日志保护也不能缺席

JBoss应用日志只是审计的一个层面，系统层的审计同样在等保测评范围里。我通常会检查系统auditd、syslog和日志文件权限：

systemctl status auditd auditctl -l tail -n 30 /var/log/audit/audit.log ls -l /usr/local/jboss/server/default/log/server.log ls -l /var/log/audit/

auditctl -l列出规则，看看有没有对关键目录和系统调用的审计；tail /var/log/audit/audit.log看系统审计日志是否有内容；日志文件权限如果所有人都能改，就等于没有审计。另外时间同步也是审计完整性的一部分，因为审计记录必须能还原事件时间线：

timedatectl status ntpq -p

审计记录也建议抄写目录的大小和最后修改时间，留作测评证据。一个小技巧是查看历史归档日志时用zcat，别解压半天再找内容。

5.3 用日志反推攻击痕迹，这是测评的加分项

安全审计这块，测评人员容易只做“有没有日志”的静态检查，更好的做法是用日志确认入侵防范状态。我在现场会直接搜异常请求和可疑访问：

grep -i -n "jmxinvoker\|web-console\|jmx-console" /usr/local/jboss/server/default/log/server.log /usr/local/jboss/server/default/log/access_log.* 2>/dev/null

如果日志里能看到来自陌生IP对/invoker/JMXInvokerServlet的大量POST请求，那基本说明系统可能已经被扫描甚至攻击过。如果access log被关闭，反而说明审计本身有缺失，这也是报告里的扣分点。这部分内容既能满足安全审计检查项，又能在“入侵防范”控制点里提供额外证据，测评结论下来会更有说服力。

6. 入侵防范与恶意痕迹排查：不放过每个异常迹象

6.1 找webshell和可疑文件的命令组合

JBoss被入侵后最常见的就是web目录被扔了webshell，路径一般在解压后的war目录或tmp目录。我会用find命令搜特定后缀和近期修改的可疑文件：

find /usr/local/jboss -name "*.jsp" -mtime -30 -type f 2>/dev/null | grep -v -i "admin\|index\|error" find /tmp /var/tmp -type f -mtime -30 2>/dev/null | grep -E "\.(jsp|jspx|war|class|sh)$"

搜出来的结果如果包括cmd.jsp、eval.jsp、upload.jsp这类名字，基本是webshell无疑。不要只看文件名，还要看文件修改时间和war包原始文件的差异。有一次我通过对比war包内jsp的原始列表和deploy目录实际文件，发现多出来三个JSP，最后确认是入侵设备留下的后门，这就是经验和命令结合的价值。

也可以用grep针对webshell常见特征做内容检索：

grep -i -r -l "Runtime.getRuntime\|ProcessBuilder\|exec(" /usr/local/jboss/server/default/deploy/ 2>/dev/null

注意：这条命令在测评现场执行前，最好先确认对CPU和IO的影响，别在大目录上全量grep，用timeout 30兜底。

6.2 异常外连和临时目录里的“小动作”

入侵者一般不会留在原地，检测异常网络连接非常关键：

netstat -antp | grep ESTABLISHED | grep -v "127.0.0.1\|:80\|:443" lsof -i -n | grep java | grep ESTABLISHED

过滤本地回环和常见HTTP/HTTPS，剩下的可疑外联就要重点追问。如果发现java进程有一条连到未知IP 443端口的长连接，可能需要进一步对照业务地址表，甚至提交给厂商确认。老版本JBoss的临时目录server/default/tmp也会保存反序列化攻击产生的临时class文件，检查有没有异常的文件：

find /usr/local/jboss/server/default/tmp -name "*.class" -newermt "2024-01-01" 2>/dev/null

结合日志里的异常POST请求，这类临时文件往往是入侵痕迹的重要证据。

6.3 系统账户、history和补丁情况一起查

入侵防范不止应用层，系统层也要排查。我会顺手看系统账户和命令历史：

cat /etc/passwd | grep -v "nologin\|false" history | tail -n 50 find / -maxdepth 2 -name "authorized_keys" 2>/dev/null

检查是否存在可疑的超级权限账号、空口令账号；history能看到近期是否有管理员执行过危险命令，也是判断入侵痕迹的辅助证据；authorized_keys文件如果多出陌生公钥，那是非常硬的失陷证据。

补丁情况可以这样看：

rpm -qa | grep -i jboss ls -d /usr/local/jboss*

把版本号和官方安全公告对照，如果老版本长时间不升级，报告里“漏洞和补丁更新”这条基本就是不符合。给整改建议时，至少要提到升级到受支持版本，而不是“能用就行”。

7. 实操中常见问题与排查经验

7.1 命令权限不足，什么都看不到

现场最尴尬的是用普通用户执行命令，/opt/jboss没有读权限，netstat看不到进程信息，lsof输出空白。我的经验是尽量使用root或具备sudo权限的测评账号，拿到授权后执行：

sudo -s

如果确实无权限，先看目录权限，别硬猜。有一次我拿不到root，但又必须看配置内容，最后通过sudo -u jboss cat的方式读取，前提是测评授权允许。所有命令执行前，先跟系统管理员确认窗口时间，避免在业务高峰期跑全盘find和全目录grep。

7.2 JBoss版本太多，路径对不上

测评新人最容易倒在这。老版本和全新版本路径完全不同，搜到的命令直接套用，结果cat run.conf不存在。我的习惯是：

• 先跑find / -maxdepth 4 -name "standalone.sh" -o -name "run.sh" 2>/dev/null定位启动脚本；
• 从启动脚本反推目录，再根据server/default还是standalone判断版本代际；
• 直接用ls看目录，最快。

版本判断表可以保存在本地，现场直接对照。

7.3 curl探测受网络隔离影响

有些系统做了网络隔离，管理网段里curl不到应用端口。这时候不急着下结论“不存在”，应该先在应用服务器本机执行curl 127.0.0.1，然后再确认外部网络到应用端口是否可达。如果外部不可达，反而是符合“访问控制”要求的表现。

同理，如果管理后台存在但只允许特定IP访问，我会在测评报告里写“已验证存在认证机制，并限制管理地址访问”，然后附上本机访问成功的状态码，证据链更完整。

7.4 注意命令本身带来的安全影响

测评命令不是“越猛越好”。在目标服务器上全盘grep -r可能导致IO飙高，netstat/ss频繁刷新问题不大，但大规模压缩扫描尽量别做。另外，修改系统时间的命令绝对不要碰，日志一旦被改动，证据就失去了意义。

我在现场有一个原则：只读优先，动态验证后置。先通过配置文件、日志、进程参数获取静态证据，再做最小化的动态验证，比如curl探测，尽量不影响业务。

最后说点个人体会。等保测评命令——jboss这套检查，本质上不是在“打系统”，而是在“读系统”。命令只是手段，真正值钱的是你看到输出后能不能判断出风险链路。我比较推荐测评人员给自己维护一个“命令速查本”，把每次现场用过的命令、遇到过的版本差异、踩过的坑都记下来，下次现场能省一半时间。特别是在JBoss这种老项目遍布的环境里，能快速判断出4.x和WildFly的检查差异，比背一百个命令有用得多。希望这篇文章能帮你少走点弯路。