JMX未授权访问？授权别慌，先堵住这个口子

上个月帮一家电商公司做安全巡检，访问方法他们的漏洞生产环境里，一台订单服务的解决JVM直接裸奔在公网上。我随手用jconsole连上去，授权CPU、访问方法堆内存、漏洞线程栈，解决甚至线上配置中心的授权密码都看得一清二楚。更离谱的访问方法是，我直接调用了`javax.management.MBeanServer`里的漏洞方法，把某个缓存的解决热数据给清空了——整个过程没输一个密码。

这就是授权JMX未授权访问的典型场景。Java管理扩展（JMX）默认监听在`com.sun.management.jmxremote`端口（通常是访问方法1099或随机端口），如果没配认证，漏洞任何能访问该端口的人都能远程操控你的JVM。攻击者不仅能窃取敏感信息，还能通过MBean执行任意代码，比如用`java.lang.Runtime`调系统命令。

解决思路分三步：关掉公网暴露、强制认证、限制操作范围。别想着只靠防火墙，内网横向渗透时，这玩意儿照样是突破口。

第一步：别让JMX裸奔在公网
最直接的办法——别把JMX端口映射到外网。如果业务必须远程管理，用SSH隧道或VPN兜底。比如这样启动Java进程：
java -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=1099 -Dcom.sun.management.jmxremote.local.only=true -jar app.jar
`local.only=true`会强制JMX只绑定回环地址，配合SSH隧道访问。别嫌麻烦，这比任何密码都靠谱。

第二步：开启认证和SSL
只设密码不够，JMX的密码是明文传输的，抓包就能看到。必须同时开SSL。在`JAVA_HOME/jre/lib/management/jmxremote.password`和`jmxremote.access`里配好账号权限，然后启动参数加上：
-Dcom.sun.management.jmxremote.authenticate=true -Dcom.sun.management.jmxremote.ssl=true -Dcom.sun.management.jmxremote.password.file=/path/to/jmxremote.password -Dcom.sun.management.jmxremote.access.file=/path/to/jmxremote.access
注意，密码文件权限要设成600，否则JVM会拒绝启动。我曾经见过有人把密码文件设成644，结果启动直接报错，折腾半天。

第三步：控制MBean的操作范围
认证通过后，默认所有MBean都能操作。这权限太大。用`jmxremote.access`文件限制——比如只给监控角色只读权限，给管理员角色才放开写操作。文件内容类似：
monitorRole readonly
adminRole readwrite
但说实话，很多生产环境里，连只读都不该给外部。如果只是监控JVM状态，建议用Prometheus的JMX exporter，只暴露指标数据，完全不给操作接口。我之前帮客户改造时，直接把JMX端口彻底关掉，改用Prometheus拉取，结果安全扫描直接通过。

还有个坑——JMX的RMI端口是动态的。即使你固定了1099，RMI还会随机开一个端口。很多人在防火墙里只放行了1099，结果发现连接失败，然后干脆全部放行，反而更危险。正确做法是同时固定RMI端口：
-Djava.rmi.server.hostname=你的内网IP -Dcom.sun.management.jmxremote.rmi.port=1100
这样防火墙只需放行这两个端口。

最后说句实在的，如果应用不是非得用JMX远程管理，直接禁用最省心。在启动参数里去掉`com.sun.management.jmxremote`相关配置，或用`-Dcom.sun.management.jmxremote=false`彻底关掉。很多框架（比如Spring Boot）默认不开启JMX，别手贱去打开。

我见过最惨的案例，某金融公司因为JMX未授权被入侵，攻击者通过MBean调用`javax.management.loading.MLet`加载恶意类，直接植入挖矿程序。事后排查，发现漏洞存在了两年多，监控系统居然没告警——因为JMX端口在防火墙规则里被归类为“内部管理”，没人细看。

所以，别迷信防火墙，别依赖默认配置。改完参数后，用`netstat -an | grep 1099`确认端口只监听在内网IP上，再用`jconsole`连一次试试，确保认证生效。安全这活儿，细心比技术重要。