我被分配了一台服务器,它一直在向我们发送大量数据,但从未使用过。所以,它很可能被入侵了。服务器上似乎没有什么问题,除了 netstat 中这些 DGRAM 项目数不胜数。
unix 2 [ ] DGRAM 878377447 1165/java
unix 2 [ ] DGRAM 773862304 1165/java
unix 2 [ ] DGRAM 690302532 1165/java
unix 2 [ ] DGRAM 223108186 1165/java
unix 2 [ ] DGRAM 10318852 1165/java
unix 2 [ ] DGRAM 4196896942 1165/java
unix 2 [ ] DGRAM 3847577732 1165/java
unix 2 [ ] DGRAM 3754238011 1165/java
unix 2 [ ] DGRAM 3729499062 1165/java
unix 2 [ ] DGRAM 3686466054 1165/java
unix 2 [ ] DGRAM 3488420039 1165/java
unix 2 [ ] DGRAM 3357838223 1165/java
unix 2 [ ] DGRAM 3207591570 1165/java
unix 2 [ ] DGRAM 3128277321 1165/java
unix 2 [ ] DGRAM 3088626078 1165/java
unix 2 [ ] DGRAM 2958537971 1165/java
unix 2 [ ] DGRAM 2653604223 1165/java
unix 2 [ ] DGRAM 2591912878 1165/java
unix 2 [ ] DGRAM 2344638274 1165/java
unix 2 [ ] DGRAM 2328447790 1165/java
unix 2 [ ] DGRAM 2218612906 1165/java
经过进一步调查,该进程似乎是一个 Zimbra 邮件进程。
zimbra 1165 3.1 8.2 3717464 319584 ? Sl Sep22 1933:59 /opt/zimbra/common/lib/jvm/java/bin/java -XX:ErrorFile=/opt/zimbra/log -client -Xmx256m -Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2 -Djdk.tls.client.protocols=TLSv1,TLSv1.1,TLSv1.2 -Djava.net.preferIPv4Stack=true -Dzimbra.home=/opt/zimbra -Djava.library.path=/opt/zimbra/lib -Djava.ext.dirs=/opt/zimbra/common/lib/jvm/java/jre/lib/ext:/opt/zimbra/lib/jars:/opt/zimbra/lib/ext-common:/opt/zimbra/lib/ext/clamscanner:/opt/zimbra/lib/ext/zimbra-license:/opt/zimbra/lib/ext/twofactorauth:/opt/zimbra/lib/ext/com_zimbra_ssdb_ephemeral_store -Djava.io.tmpdir=/opt/zimbra/data/tmp -Dpython.cachedir.skip=true org.python.util.jython /opt/zimbra/libexec/zmconfigd
这些是什么?为什么有这么多?有人能为我提供一些见解吗?
谢谢
答案1
这些是 Unix 数据报套接字。它们的工作方式类似于 UDP(无连接协议),但使用 unix 套接字(如/dev/log
)。它们主要用于日志记录,或者用于进程/线程消息传递/同步。
zmconfigd
有一个错误,导致它在无限循环中分配新的 unix dgram 套接字。
可能的原因是这样的:
- 它是用 Python 编写的,编译为杰森,使其在 Java VM 中运行。
- Java 不了解 Unix 套接字(标准 Java API 可能故意忽略了它,以加强跨平台兼容性)。Unix 套接字只能通过使用杰尼提。JNI 是 Java 的 C 接口,因此它不会被垃圾收集(或者,如果编写不正确,它可能会被垃圾收集器认为是意外行为)。
- 处理 unix 套接字的 jython API 和 JVM 垃圾收集器之间可能存在一些意外的交互。
我不知道这个错误究竟何时发生。据我所知,它并没有在所有 zimbra 上发生。有可能,稍后 GC 将开始工作,并且 unix dgram 套接字的创建将停止,但这可能比您当前的系统限制更大。
但是,zmconfigd
它不是 Zimbra 的必要部分 - 它只会定期检查某些配置更改,并重新启动处理这些更改的 Zimbra 服务。如果您非常了解 Zimbra,则不需要它,因此您可以简单地将其关闭(不知何故 - 我不知道,如何在没有 Zimbra 黑客的情况下永久关闭单个 Zimbra 组件)。
另一个解决方法是定期重新启动 zmconfigd(zmconfigctl restart
以 zimbra 用户身份每小时从 cron 运行一次)。