Les applications Java peuvent être surveillées grâce à la technologie JMX, via des outils comme JConsole ou JVisualVM ou n’importe quel programme Java utilisant l’API JMX. Cette technologie permet également de modifier la configuration d’une application Java.

Dans la pratique la JVM expose un serveur JMX auquel il est possible de se connecter localement (depuis la même machine) ou à distance. Elle permet de consulter le comportement de la JVM (threads, cpu, heap, etc…) ou de consulter et modifier sa configuration. JMX constitue donc une porte d’entrée particulièrement sensible vers une application Java. Cet accès doit être protégé afin que seules les personnes ou applications habilités puissent l’utiliser.

Cet article se propose de montrer comment sécuriser la relation entre un outil tel que JConsole ou JVisualVM et une application java, qu’elle tourne dans un serveur j2ee ou non.

Il existe plusieurs niveaux de configuration qu’on met en jeu avec les propriétés com.sun.management.jmxremote.xxxx :

Fermeture des accès locaux et distants.

Les accès JMX sont impossibles depuis l’extérieur de la JVM que ce soit en local depuis la même machine ou depuis une autre machine. Seule une application se trouvant dans la même JVM que l’application Java pourra accéder éventuellement aux fonctions JMX.

[pastacode lang= »java » manual= »-Dcom.sun.management.jmxremote%3Dfalse » message= » » highlight= » » provider= »manual »/]

 

Accès local uniquement, non sécurisé

• Le serveur JMX de l’application est joignable uniquement en local.
• Aucune authentification n’est requise pour se connecter au serveur.
• Le client utilise l’API Java Attach.

[pastacode lang= »java » manual= »-Dcom.sun.management.jmxremote » message= » » highlight= » » provider= »manual »/]

Accès locaux et distants, non sécurisés

• Le serveur JMX de l’application java est joignable en local et à distance.
• Pas d’authentification du client auprès de l’application Java
• Pas d’authentification l’application Java auprès du client.
• Pas de chiffrement des communications avec SSL/TLS

[pastacode lang= »java » manual= »-Dcom.sun.management.jmxremote.port%3D6229%0A-Dcom.sun.management.jmxremote.authenticate%3Dfalse%0A-Dcom.sun.management.jmxremote.ssl%3Dfalse » message= » » highlight= » » provider= »manual »/]

C’est la propriété com.sun.management.jmxremote.port qui permet d’activer l’accès distant.

Ne pas oublier d’ouvrir le port (6229 dans l’exemple) au niveau des pare-feux.

Accès local et distant – One-way SSL

• Le serveur JMX de l’application Java est joignable en local et à distance.
• Pas d’authentification du client auprès de l’application Java
• Authentification de l’application Java auprès du client avec un certificat électronique (One-way SSL).

[pastacode lang= »java » manual= »-Dcom.sun.management.jmxremote.port%3D6229%0A-Dcom.sun.management.jmxremote.authenticate%3Dfalse%0A-Dcom.sun.management.jmxremote.ssl%3Dtrue » message= » » highlight= » » provider= »manual »/]

Accès local et distant – Authentification client par mot de passe

• Le serveur JMX de l’application Java est joignable en local et à distance.
• Le client doit s’authentifier auprès du serveur JMX de l’application Java avec un mot de passe.
• Pas d’authentification de l’application java auprès du client JMX.
• Pas de chiffrement des communications avec SSL/TLS

[pastacode lang= »java » manual= »-Dcom.sun.management.jmxremote.port%3D6229%0A-Dcom.sun.management.jmxremote.authenticate%3Dtrue%0A-Dcom.sun.management.jmxremote.ssl%3Dfalse » message= » » highlight= » » provider= »manual »/]

Il est possible de configurer un login module JAAS ou d’indiquer les mots de passe dans un fichier dans la configuration de la JVM. Les détails sont disponibles dans cette documentation. En cas d’utilisation du fichier il faut savoir que les mots de passe sont stockés en clair sur le disque dur.

Accès local et distant – Two-way SSL

• Le serveur JMX de l’application Java est joignable en local et à distance.
• Le client doit s’authentifier auprès du serveur JMX de l’application Java avec un certificat électronique.
• Authentification de l’application java auprès du client JMX avec un certificat électronique
• Chiffrement des communications avec SSL/TLS

[pastacode lang= »java » manual= »-Dcom.sun.management.jmxremote.port%3D6229%0A-Dcom.sun.management.jmxremote.authenticate%3Dfalse%0A-Dcom.sun.management.jmxremote.ssl%3Dtrue%0A-Dcom.sun.management.jmxremote.ssl.need.client.auth%3Dtrue » message= » » highlight= » » provider= »manual »/]

 

Les configurations mettant en jeu SSL/TLS vont donc nécessiter la configuration des éléments suivants :

• One-Way SSL
  • Une paire de clef publique/privée et d’un certificat (auto-signé éventuellement) pour l’application Java
  • Un keystore (identity) côté application Java pour stocker les clefs et le certificat du serveur
  • Un keystore (trust) côté client JMX pour stocker la clef publique et le certificat du serveur
• Two-Way SSL
  • Une paire de clef publique/privée et d’un certificat (auto-signé éventuellement) pour l’application Java
  •  Une paire de clef publique/privée et d’un certificat (auto-signé éventuellement) pour le client JMX (JConsole par exemple)
  • Côté Application Java
    • Un keystore (identity) pour stocker les clefs et le certificat du serveur
    • Un keystore (trust) pour stocker la clef publique et le certificat du client JMX
  • Côté Client JMX
    • Un keystore (identity) pour stocker les clefs et le certificat du client JMX
    • Un keystore (trust) pour stocker la clef publique et le certificat du serveur

Conclusion

Si l »accès JMX à l’application n’est pas nécessaire, pensez à le désactiver complètement afin de verrouiller également les accès locaux.

Si cet accès est nécessaire, seule la sécurisation two-way SSL permet d’avoir une sécurité maximale en mettant en jeu la double authentification et le chiffrement des données échangées entre le client JMX et l’application à surveiller.