将java远程调试器端口暴露给Internet是否安全?

Dmi*_*san 6 java security exploit remote-debugging

我打算通过互联网公开一个用于远程调试基于Java的Web服务的端口,但是我想了两次,我意识到它没有任何身份验证.

从理论上讲,似乎可以编写一个附加到远程调试器端口的工具,并通过Java API执行任意系统命令.或者修改/转储数据库,依此类推.至少这种利用似乎是这种情况http://securityaffairs.co/wordpress/36394/hacking/paypal-remote-code-execution.html

我不记得曾经强烈警告过暴露远程调试器端口.但是现在,当数百个僵尸网络扫描端口寻找漏洞时,应该更好地做广告.

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

Mar*_*ged 7

您可以配置远程调试以使用SSL和身份验证,这适用于Windows和Linux,但有点麻烦.港口一直开着.

我确信您有充分的理由调试您的实时/高效应用程序,并知道当您真正调试它时,不仅使用连接来获取对JMX数据的访问权限,例如,当您连接调试器时,您的应用程序将停止运行.

Oracle 记录了一些风险,一些风险更高或更低,具体取决于您配置代理的方式:

注意 - 当客户端从不安全的RMI注册表(默认)获取远程连接器时,已发现潜在的安全问题,即远程连接器的密码验证.如果攻击者在合法注册表启动之前在目标服务器上启动虚假RMI注册表,则攻击者可以窃取客户端的密码.此方案包括使用系统属性com.sun.management.jmxremote.port = portNum启动启用了远程管理的Java VM的情况,即使启用了SSL也是如此.尽管可能会注意到这种攻击,但它仍然是一个漏洞.

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

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

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

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

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