2017年4月，洞修某电商平台的洞修运维团队在凌晨三点被监控告警炸醒——服务器CPU飙到100%，日志里全是洞修奇怪的POST请求。排查到天亮才发现，洞修攻击者利用的洞修正是JBoss默认配置里的JMX Console漏洞。这不是洞修个例。JBoss AS 4.x到6.x系列，洞修只要没改过默认端口和路径，洞修几乎就是洞修敞着大门等贼进来。

JBoss的洞修问题出在它"开箱即用"的设计哲学上。安装完就能跑，洞修但那些方便管理的洞修组件——JMX Console、Web Console、洞修admin-console——全挂在HTTP端口上，洞修有些版本连密码都不设。洞修攻击者扫到8080端口，访问 /jmx-console/，如果返回200，基本就确定猎物上门了。更麻烦的是JBoss的部署机制，通过JMX可以远程部署war包，等于直接给了webshell。

我见过最离谱的案例是一家医院的HIS系统，JBoss 4.2.3跑了八年没动过。默认的 jmx-console 账号密码是admin/admin，他们连这个都没改。后来被植入挖矿程序，CPU风扇响得跟直升机似的，信息科的人还以为是服务器老化。

修复这件事得分版本看。JBoss 4.x和5.x，最直接的办法是删掉 server/default/deploy/jmx-console.war 和 web-console.war 这些目录。别犹豫，生产环境根本用不到这些管理界面。如果非要用，至少把 jmx-console-users.properties 里的默认密码改掉，顺便在 web.xml 里加上IP白名单限制。有个细节很多人忽略：JBoss的 JMXInvokerServlet 也是重灾区，对应路径是 /invoker/JMXInvokerServlet，同样要删掉或者限制访问。

JBoss 6.x和EAP 6以后，架构变了，漏洞面小了很多，但management接口的默认端口9990如果暴露在公网，照样危险。我习惯的做法是在 standalone.xml 里把 management 的 socket-binding 绑到127.0.0.1，只允许本机访问。远程管理？走SSH隧道，别图省事。

打补丁这件事，JBoss的更新节奏让人头疼。Red Hat把JBoss EAP的补丁放在客户门户后面，没订阅账号连下载都下不了。很多小公司用的还是社区版JBoss AS 7，这个版本2014年就停止维护了，官方补丁早没了。我的建议很直接：要么花钱买EAP订阅，要么迁移到WildFly。WildFly 10以后的版本，默认配置安全得多，管理接口默认只监听本地，远程部署需要显式开启。

临时缓解措施也有。在JBoss前面挂个Nginx，把 /jmx-console、/web-console、/invoker 这些路径全挡掉，返回403。这招能挡住大部分自动化扫描工具。但别指望它治本，攻击者换个路径或者用其他漏洞照样能进来。有次应急响应，客户说已经用WAF拦了jmx-console，结果攻击者走的是 /admin-console，照样中招。

最后说个真实教训。某金融机构的JBoss修复方案是"改端口+加防火墙规则"，把8080改成18080，以为没人找得到。结果内部渗透测试时，用nmap扫全网段，三分钟就发现了新端口。安全这事儿，藏是藏不住的，该删的组件删掉，该打的补丁打上，别耍小聪明。

JBoss漏洞修复没有银弹。删管理组件、改默认配置、限制访问来源、及时升级版本——这几件事做到位，能挡住90%的攻击。剩下的10%，靠的是持续监控和应急响应速度。毕竟，攻击者也在进化。