La construction d'un laboratoire robuste d'analyse de logiciels malveillants repose souvent sur la virtualisation pour gérer les instantanés, permettant aux enquêteurs de partir d'un état propre ou de revenir en arrière après des étapes critiques. Cependant, cette commodité s'accompagne d'un risque significatif : le retour d'une machine virtuelle à un instantané précédent entraîne la perte totale de tous les changements appliqués pendant cette session. Pour les analystes utilisant Ghidra, où le travail est stocké dans des fichiers de projet locaux contenant des fonctions renommées, des commentaires et des structures, cela signifie que des heures d'analyse peuvent disparaître instantanément si la machine virtuelle rencontre des problèmes ou est réinitialisée.
Pour atténuer cette perte de données, les experts recommandent le déploiement d'un serveur Ghidra local, un composant inclus dans la distribution standard qui ne nécessite aucune licence supplémentaire. Ce serveur transforme les projets locaux en référentiels partagés soutenus par un emplacement central situé en dehors de la machine virtuelle volatile. L'avantage principal est la persistance ; les analystes peuvent réinitialiser leurs machines virtuelles aussi souvent que nécessaire tout en gardant les programmes annotés en sécurité sur le serveur. De plus, le système offre des capacités de versionnement similaires à Git, permettant aux utilisateurs de suivre les modifications avec des commentaires, de comparer différents états d'une analyse et de restaurer des versions précédentes.
L'architecture prend en charge plusieurs clients, permettant à un analyste de commencer son travail sur une machine et de le poursuivre sur une autre, comme un ordinateur portable ou la station de travail d'un collègue. Elle facilite également la collaboration en permettant à plusieurs analystes de travailler sur les mêmes échantillons avec des permissions granulaires, incluant l'accès en lecture seule, lecture/écriture ou administrateur. Crucial pour les interventions de réponse aux incidents, cette configuration garantit la confidentialité en gardant tous les échantillons et binaires liés aux clients au sein du réseau du laboratoire, évitant ainsi le besoin de pousser des données vers des services tiers.
D'un point de vue technique, le serveur est léger et peut s'exécuter sur une petite machine virtuelle Linux ou un conteneur séparé des machines d'analyse. Les spécifications recommandées incluent deux cœurs CPU, 4 Go de RAM et 8 Go de stockage, exécutant JDK 21 ou plus récent. Il est essentiel d'aligner la version de Ghidra entre le serveur et les clients pour éviter les problèmes d'incompatibilité. La configuration réseau nécessite que les ports TCP 13100 et 13101 soient accessibles depuis les machines clientes, et les clients doivent pouvoir résoudre le nom d'hôte annoncé par le serveur.
Les considérations de sécurité sont primordiales lors du déploiement de ce service. Puisque le serveur héberge des référentiels contenant des octets bruts de code malveillant, il doit être traité comme hébergeant des logiciels malveillants actifs et maintenu strictement au sein du réseau du laboratoire d'analyse de logiciels malveillants. Il ne doit jamais être exposé à Internet. La configuration implique la création d'un compte système dédié, le dépaquetage de la distribution Ghidra et la configuration du fichier server.conf pour définir le répertoire du référentiel, la méthode d'authentification et le nom d'hôte annoncé. Les modes d'authentification incluent les mots de passe locaux, la PKI avec des certificats clients, ou l'intégration JAAS avec LDAP ou Active Directory.
Une fois installé, les utilisateurs créent des référentiels via le client Ghidra en sélectionnant "Projet partagé" et en se connectant au serveur. Bien que les projets partagés génèrent toujours des fichiers .gpr locaux et des répertoires .rep pour la mise en cache et les paramètres de connexion, les binaires restent privés jusqu'à ce qu'ils soient explicitement ajoutés au contrôle de version. Le flux de travail reflète les systèmes de contrôle de source standard : les analystes sortent des programmes pour travailler dessus, valident les modifications avec des commentaires pour créer de nouvelles versions, et gèrent les listes d'accès pour les autres membres de l'équipe. Si une machine virtuelle est réinitialisée et que les données locales sont perdues, les analystes peuvent récupérer leur travail en se connectant au référentiel existant, bien que les fichiers privés jamais ajoutés au contrôle de version et les modifications non validées restent irrécupérables.
Sources: SANS Internet Storm Center.