1

I am assigned a server that has been sending tons of data ourside and isn't used. So, it is most likely compromised. Nothing really seems to be out of order on the server except, they're miles and miles of these DGRAM items in netstat.

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

Upon further investigation, the proces appears to be a zimbra mail process.

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

What are these and why are there so many? Can someone provide some insight for me on this?

Thanks

LUser
  • 217
  • 1
  • 6
  • 15

1 Answers1

1

These are Unix Datagram sockets. They work like UDP (connection-less protocol), but on unix sockets (like /dev/log). They are mostly used for logging, or maybe process/thread messaging/synchronization.

zmconfigd has a bug what causes it to allocate new unix dgram sockets in an infinite loop.

The probable cause is this:

  • It was written in python, compiled with jython, to make it run in a Java VM.
  • Java doesn't know Unix Sockets (it was probably intentionally missed from the standard Java API to enforce cross-platform compatibility). Unix sockets can be handled only by using JNI. JNI is a C interface to Java, thus it is not garbage collected (or, it can have unexpected behaviors with the garbage collector if it was not written properly).
  • Probably there is some unexpected interaction between the jython API handling unix sockets and the JVM garbage collector.

I don't know, exactly when this bug occurs. It did not happen on all the zimbra I know. It is possible, that later the GC will start to work and the creation of the unix dgram sockets will once stop, but it might be grater than your current system limitations.

However, zmconfigd is not an essential part of Zimbra - it only regularly checks for some config changes, and restarts the zimbra service dealing with them. If you know zimbra well, you don't need it, so you can simply turn it off (somehow - I don't know, how can be a single zimbra component turned off permanently without a zimbra hack).

Another workaround is to periodically restart zmconfigd (run a zmconfigctl restart as the zimbra user, hourly, from cron).

peterh
  • 4,953
  • 13
  • 30
  • 44