You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
the lsc is installed on one of our ubuntu servers and synchronizes some OUs between two LDAP servers. A Qualys Cloud Agent has been installed on most of the servers recently. This agent scans for vulnerabilities, and one vulnerability found (altough only severity 2 out of 5) is being introduced by LSC, because it utilizes JMX without SSL authentication. The possible attack poses the threat, that when remotely connecting to the JMX interface the credentials could be sniffed at the network level. The solution of Qualys proposed is that either the connection is only possible via SSL or from localhost.
We do not utilize JMX via the network (in fact, not at all), therefore I fully understand, that this vulnerability can never be exploited in our case. However it's a running server with a running service that may be exploited in the future by other ways.
I have read the documentation and tried so see how to disable or secure JMX, but it seems that this is currently not implemented / designed for LSC. I have found the following in the lsc-project.org documentation at the documentation for LSC_JMXPORT=1099:
! Warning
But doing such settings, please notice that anyone can send commands to your LSC instance listening on all your network interfaces on the 1099 TCP port ! (At this time this is not a simple task to bind JMX to the local interface only, RFU :)
Therefore, I think a change except for the port of JMX is not yet implemented / designed. I have checked the /etc/default/lsc file and tried to remove the LSC_JMXPORT="1099" instruction and restarted the service, but the JMX is still running.
As far as I understand, this is only enabled in order for the command lsc-agent to work. To start, stop and list jobs and do some other tasks. However, we are not utilizing the this command line interface anyway, so fully disabling JMX would also be a good possibility for us.
Is there already a way that I did not find to achieve this? Either disabling it, or enabling authentication and SSL via a certificate? If not, I'd like to do a request to add the follwing options in the following priority:
Configuration option to disable the JMX interface fully
Configuration option to to set the interface binding of the JMX interface
Configuration option to enable SSL for the connection to JMX
Configuration option to enable authentication for the connection to the JMX interface
A step by step implementation - or just the option to disable it at all - would be awesome in order to remediate this very small but existent security issue.
Maybe the implementation of an option like LSC_JMXENABLED with true and false as possible values is enough, to configure com.sun.management.jmxremote=true/false in the background.
The text was updated successfully, but these errors were encountered:
Hello @coudot thank you very much for your answer. That fully answers my question, thank you for pointing me to the right code place. I can see that a bash script and a shell script exists to launch lsc via Java. I am pretty familiar with bash and windows batch. If I adapt the code to add support to bind JMX to a specific ip address / interface and also maybe for SSL, would that PR be accepted?
Dear LSC-project team,
the lsc is installed on one of our ubuntu servers and synchronizes some OUs between two LDAP servers. A Qualys Cloud Agent has been installed on most of the servers recently. This agent scans for vulnerabilities, and one vulnerability found (altough only severity 2 out of 5) is being introduced by LSC, because it utilizes JMX without SSL authentication. The possible attack poses the threat, that when remotely connecting to the JMX interface the credentials could be sniffed at the network level. The solution of Qualys proposed is that either the connection is only possible via SSL or from localhost.
We do not utilize JMX via the network (in fact, not at all), therefore I fully understand, that this vulnerability can never be exploited in our case. However it's a running server with a running service that may be exploited in the future by other ways.
I have read the documentation and tried so see how to disable or secure JMX, but it seems that this is currently not implemented / designed for LSC. I have found the following in the lsc-project.org documentation at the documentation for
LSC_JMXPORT=1099
:Therefore, I think a change except for the port of JMX is not yet implemented / designed. I have checked the
/etc/default/lsc
file and tried to remove theLSC_JMXPORT="1099"
instruction and restarted the service, but the JMX is still running.When I check
ps auxf
on the system, it returns:As far as I understand, this is only enabled in order for the command
lsc-agent
to work. To start, stop and list jobs and do some other tasks. However, we are not utilizing the this command line interface anyway, so fully disabling JMX would also be a good possibility for us.Is there already a way that I did not find to achieve this? Either disabling it, or enabling authentication and SSL via a certificate? If not, I'd like to do a request to add the follwing options in the following priority:
A step by step implementation - or just the option to disable it at all - would be awesome in order to remediate this very small but existent security issue.
Maybe the implementation of an option like
LSC_JMXENABLED
withtrue
andfalse
as possible values is enough, to configurecom.sun.management.jmxremote=true/false
in the background.The text was updated successfully, but these errors were encountered: