将 java 远程调试器端口公开到互联网是否安全? [英] Is it safe to expose java remote debugger port to the internet?

问题描述

我打算公开一个端口，用于通过 Internet 远程调试基于 Java 的 Web 服务，但三思而后我意识到它没有任何身份验证.

I was going to expose a port for remote debugging of Java-based web service over the internet, but thinking twice I realised that it has no any authentification.

理论上，似乎可以编写一个工具，连接到远程调试器端口，并通过 Java API 执行任意系统命令.或者修改/转储数据库，等等.至少这个漏洞似乎是这种情况http://securityaffairs.co/wordpress/36394/hacking/paypal-remote-code-execution.html

Theoretically, it seems to be possible to write a tool, that attaches to remote debugger port, and executes arbitrary system commands via Java API. Or modifies/dumps database, and so on. At least this exploit seems to be the case http://securityaffairs.co/wordpress/36394/hacking/paypal-remote-code-execution.html

我不记得曾被强烈警告过要公开远程调试器端口.但如今，当数百个僵尸网络扫描端口寻找漏洞时，应该更好地宣传.

I don't remember being strongly warned about exposing remote debugger port ever. But nowadays, when hundreds of botnets scan ports looking for vulnerabilities, it should be better advertised.

能否请任何人评论它是否安全和/或如何在任意基于 Java 的网络服务上以安全的方式做到这一点?我的目标是能够在生产服务器上进行远程调试.

Can please anybody comment whether it is safe and/or how to do that in a secure manner on an arbitrary java-based web-service? My goal is to be able to perform remote debug on production server.

推荐答案

您可以配置远程调试以使用 SSL 和身份验证，这适用于 Windows 和 Linux，但有点麻烦.并且端口一直是开放的.

You can configure remote debugging to use SSL and authentication, this works for both Windows and Linux but is a bit cumbersome. And the port is open all the time.

我相信您有充分的理由调试您的实时/生产应用程序，并且知道当您真正调试它时，不仅使用连接来访问 JMX 数据，例如当您连接调试器时，您的应用程序将停止运行.

I am sure you have good reason to debug your live / productive application and know that when you really debug it and not only use the connection to gain access to JMX data for example your application will stop running when you connect the debugger.

Oracle 文档 一些风险，一些更高或更低，具体取决于您配置代理的方式:

Oracle documents some risks, some higher or lower, depending on how you configure the agent:

注意 - 密码存在潜在安全问题当客户端获得远程连接器的身份验证来自不安全 RMI 注册表的远程连接器(默认).如果攻击者在目标服务器上启动一个伪造的 RMI 注册表启动合法的注册表，然后攻击者可以窃取客户端的密码.此场景包括您启动 Java VM 的情况启用远程管理，使用系统属性com.sun.management.jmxremote.port=portNum，即使启用了 SSL.虽然此类攻击很可能会被注意到，但它仍然是一个漏洞.

Caution - A potential security issue has been identified with password authentication for remote connectors when the client obtains the remote connector from an insecure RMI registry (the default). If an attacker starts a bogus RMI registry on the target server before the legitimate registry is started, then the attacker can steal clients' passwords. This scenario includes the case where you launch a Java VM with remote management enabled, using the system property com.sun.management.jmxremote.port=portNum, even when SSL is enabled. Although such attacks are likely to be noticed, it is nevertheless a vulnerability.

注意 - 此配置不安全.任何知道的远程用户(或猜测)您的 JMX 端口号和主机名将能够监视和控制您的 Java 应用程序和平台.虽然它可能可用于开发，不推荐用于生产系统.

Caution - This configuration is insecure. Any remote user who knows (or guesses) your JMX port number and host name will be able to monitor and control your Java application and platform. While it may be acceptable for development, it is not recommended for production systems.

注意 - 此配置是不安全的:任何知道(或猜测)您的端口号和主机名将能够监视并控制您的 Java 应用程序和平台.此外，可能危害不仅限于您在 MBean 中定义的操作.一种远程客户端可以创建一个 javax.management.loading.MLet MBean 和使用它从任意 URL 创建新的 MBean，至少在有没有安全经理.换句话说，一个流氓远程客户端可以使您的 Java 应用程序执行任意代码.

Caution - This configuration is insecure: any remote user who knows (or guesses) your port number and host name will be able to monitor and control your Java applications and platform. Furthermore, possible harm is not limited to the operations you define in your MBeans. A remote client could create a javax.management.loading.MLet MBean and use it to create new MBeans from arbitrary URLs, at least if there is no security manager. In other words, a rogue remote client could make your Java application execute arbitrary code.

因此，虽然禁用安全性可能是可以接受的开发中，强烈建议您不要禁用生产系统的安全性.

Consequently, while disabling security might be acceptable for development, it is strongly recommended that you do not disable security for production systems.

即使涉及最高安全性的配置(移动端口、启用 ssl、通过 ssl 客户端证书进行身份验证)仍然存在风险.如果您仍然需要调试连接，我建议您使用可能已经存在的到服务器的 ssh 连接，并使用这个连接来创建到调试器端口的 ssh 隧道.您可以在此处阅读更多相关信息:无法通过 SSH 隧道远程调试 JVM(因为它已经在所以我不复制细节)

Even the configuration with the highest security involved (port moved, ssl enabled, authentication by ssl client certificate) still bears risks. If you still need the debug connection I suggest you use the presumably already existing ssh connection to the server and use this one to create a ssh tunnel to the debugger port. You can read more about this here: Cannot remotely debug JVM via SSH tunnel (because it is already on SO I don't copy the details)

在没有加密和身份验证的情况下打开端口将使任何人都可以连接到您的 jvm.这将允许读取和写入 JMX 值、停止执行代码、修改值、创建堆转储、覆盖代码和所有其他不良内容.

Opening the port without encryption and authentication will enable anyone to connect to your jvm. This will allow for reading and writing JMX values, halting the execution of your code, modifying values, creating heapdumps, overwriting code and all the other bad stuff.

这篇关于将 java 远程调试器端口公开到互联网是否安全?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！