_{Original file}

Mozilla InvestiGator : quand vos serveurs se prennent pour Sherlock Holmes

Julien Vehent – dresseur d'alligators chez Mozilla

Avec suffisamment de serveurs à surveiller, l'investigateur expérimenté se retrouve souvent à chercher l'aiguille dans la botte de foin. Pour peu que l'infrastructure soit hétérogène, la recherche peut prendre plusieurs heures et souvent ne pas couvrir l’intégralité du domaine. Si vous êtes familier de ce problème et que PSSH ne fait plus l'affaire, la suite devrait vous intéresser.

Une note toutefois : les personnages et situations qui suivent sont purement fictifs et ne représentent pas forcément la routine des investigations réalisées par l'auteur dans le cadre de son activité.

Image : MIG-logo-CC.jpg

Jean-Kevin a un bon lundi matin. Il fait beau sur San Francisco et il est de bonne humeur. Il gare son vélo devant le bâtiment du ferry de l'Embarcadero et commande un café organique du Guatemala chez Blue Bottle Coffee. Douze minutes de goutte-à-goutte et huit dollars plus tard, Jean-Kevin ressort, prend son vélo et se dirige au bureau. La matinée est calme, ce qui est rare dans son open space. Il en profite donc pour terminer la réécriture de l'API de gestion des instances SPOT sur AWS, celles utilisées pour convertir les vidéos de chats en GIF animés.

Midi arrive, Jean-Kevin n'a pas bu son café à huit dollars, trop amer. Il se concentre sur la routine de nettoyage des instances avant destruction. Il a presque terminé, tous ses tests passent, il décide donc de pousser ses changements dans la branche du projet sur GitHub et d'aller déjeuner. Jean-Kevin tape la même commande qu'il a tapé mille fois auparavant :

$ git add .

$ git commit -m 'work in progress' -a

$ git push origin

Il est vingt-deux heures quinze à Minsk, Biélorussie, quand le cyanogen de Boris clignote avec une alerte. “Probablement un autre bitcoin-kiddie qui s'est fait avoir” se dit l’ingénieur qui arrondit ses fins de mois en “empruntant” les portefeuilles virtuels des amateurs peu prudents. Le SMS est toutefois différent :

PRIVATE KEY FOUND : https://github.com/jean-kevin/spotapimanager/blob/conf/id-rsa

“Cool !”. La course commence. Boris sait que GitHub effectue le même type de scan que lui et va certainement découvrir la clé et alerter son propriétaire rapidement. Il clone le code source, récupère la clé et scanne le répertoire : deux noms de serveurs et une clé AWS, jackpot !! L'un des deux serveurs écoute sur le réseau et c'est un bastion SSH. Boris essaie la clé sur l'utilisateur root, rien. Il essaie avec jean-kevin et se retrouve connecté au serveur. Pas de sudo, dommage. Mais la clé AWS donne d'autres accès intéressants : en quelques minutes, Boris a démarré 8 c3.2xlarge en Irlande et commence à miner des bitcoins. La soirée s'annonce plutôt pas mal.

Jean-kevin a bien déjeuné et s'est permis une demi-heure supplémentaire pour discuter de l’efficacité des goroutines comparées aux callbacks de NodeJS. Il retourne à son bureau, ouvre ses emails, clique paresseusement sur un email intitulé “alerte de sécurité sur votre compte github.com”. Probablement un autre phishing.

Nous avons détecté un contenu potentiellement secret sur votre dépôt “spotapimanager”. https://github.com/jean-kevin/spotapimanager/blob/conf/id-rsa

Jean-Kevin sursaute, renverse son café organique guatémaltèque sur son bureau, soulève son ordinateur portable d'un geste vif pour éviter le drame et se rue sur les serviettes en papier. Cinq minutes, et de nombreux jurons plus tard, il retourne à ses emails et suit la procédure de suppression fournit par GitHub. Une heure trente, se dit-il, ça n'a pas pu aller bien loin. Dans le doute, il contacte son collègue de la sécurité pour lui demander son avis.

Gérard a une opinion différente de Jean-Kevin sur la dangerosité de l'alerte. Une clé privée sur GitHub, c'est mauvais signe. Il jette un œil sur le code source et en deux minutes trouve la clé AWS, et commence à sérieusement stresser. Il alerte son chef, regroupe l’équipe, et passe en DEFCON 3 : tout le monde se connecte sur le site de vidéo-conférence privée de l'entreprise pour évaluer les dégâts. Première bonne nouvelle : la clé privée n'est pas la clé principale de Jean-Kevin. Il l'utilise dans l'environnement de dev et sur un petit nombre de serveurs de test. Par contre, la clé AWS a un accès large sur le compte de l’équipe de Jean-Kevin. Tout d'abord, désactiver les accès, ensuite, lire les logs.

Gérard se prépare à inspecter les serveurs à la recherche de toutes traces des clés. Dans le doute, il ne se limite pas au compte AWS et recherche tous les serveurs de l'entreprise. Les serveurs font tourner l'agent de MIG et sont connectés au relais RabbitMQ central en attente de commandes. Gérard démarre la console de MIG pour vérifier l’état de l'infrastructure :

$ mig-console

## ## _.—._ .—.

# # # /-\ —|| | /\ …—' .—. '—'-. '. # #| | / || | /–\ .-.–' _.'( | )'. '. '._ : # # \_/ —| \_ \_/ \ .'-'_ .– ._'—'_.-. '. '-'. ### ~ -._ -._—. -. '-._ '. # |\ |\ /———| ~ -.._ _ _ _ ..-_ '. '-._–.._ # | \| \ / |- | | | -~ -._ '-. -. '-._–.._.–.

###| \ \/ —| | | ~ ~-. -._ '-. '. '. ##### ~~ ~—… _ ._ .' '.

# /\ — /-\ |–|—- ~ ~–…..–~

# ### /–\ | | ||-\ #####/ \ | \_/ | \__

+——

+——

mig>

Un total de 12000 endpoints lui semble correct. La plupart font tourner l'agent en tant que daemon mais un certain nombre préfère l'invoquer périodiquement dans une tâche cron et reporte donc un statut inactif (idle). Il quitte la console, préférant l'outil en ligne de commande pour lancer sa recherche.

Gérard utilise l'option -tpour spécifier une cible de recherche qui inclut les agents inactifs, en espérant que ces derniers se réveillent et lance la recherche avant que la date d'expiration ne soit atteinte. Pour éviter ce problème, il place l'expiration à six heures. Ça devrait être suffisant pour tout couvrir.

$ mig file -t “agents.status IN ('online', 'idle')” -e 6h \

-path /home -path /root -size “<1k” -maxdepth 5 -content “28zs0p1Ix00iCVtWVk5hCIeBwl|AKIAIAU26YJPLZX2JROA”

Il place ensuite les paramètres de recherche spécifiques au module “file” qu'il utilise. Pour le moment, rechercher les contenus de /root et /home sera suffisant. Il limite la recherche aux fichiers de moins d'un kilo-octet et pas plus de cinq niveaux d'arborescence pour éviter de se retrouver à scanner un serveur de fichier. Finalement, il place une regexp de recherche sur le contenu qui retournera soit les fichiers qui contiennent une partie de la clé SSH, soit les fichiers qui contiennent la clé AWS, en utilisant une barre verticale pour former un “ou“. La commande est prête, Gérard l’exécute :

12084 agents will be targeted. ctrl+c to cancel. launching in 5 4 3 2 1 GO

Following action ID 1427824392042957568.status=inflight..5% ….19% …21% …21% ….22% …

En arrière-plan, le client de ligne de commande “mig“ génère une action au format JSON et appelle l'agent GPG qui tourne sur le portable de Gérard pour calculer une signature en utilisant sa clé privée. Le fichier JSON signé est envoyé à l'API où l’identité de Gérard et la signature de l'action sont vérifiées. L'action est insérée dans la base de données Postgresql puis récupérée par le scheduler qui envoie une commande à chaque agent ciblé via RabbitMQ.

Image : MIG-Arch-Diagram.png

Les agents connectés au relais RabbitMQ reçoivent leur commande et en vérifie la signature, s'assurant ainsi de ne pas exécuter de commandes venant d'un investigateur inconnu. La signature de Gérard étant valide, chaque agent passe les paramètres de recherche au module “file“ qui inspecte le stockage local.

En quelques secondes, les agents les plus rapides renvoient déjà leurs résultats. Gérard les affiche depuis la console de MIG, laissant la ligne de commande afficher la progression en arrière-plan.

mig> action 1427824392042957568

action 568> results found

search 's1'

srv1.example.net /home/jean-kevin/.ssh/id-rsa [lastmodified:2015-02-12 15:56:47.37765893 +0000 UTC, mode:-rw-r–r–, size:54] in search 's1'

db3.example.net /root/.boto [lastmodified:2015-03-31 07:47:56.648579975 +0000 UTC, mode:-rw-r–r–, size:54] in search 's1'

dev1.us-east1.example.com /home/jean-kevin/.ssh/id-rsa [lastmodified:2015-03-31 07:48:21.352248964 +0000 UTC, mode:-rw-r–r–, size:54] in search 's1'

3 agents have found results

Deux fichiers id-rsa contenant probablement la clé SSH et un fichier .boto, typique de la libraire python pour AWS, sont trouvés. Il faut nettoyer ces fichiers et remplacer la clé AWS au plus vite. Des résultats arriveront certainement plus tard, mais c'est déjà un début.

Il décide de vérifier les logs de connexion SSH sur ses serveurs. Beaucoup sont reçus sur les serveurs syslog centraux mais quelques serveurs y manquent dont justement les instances de développements du compte AWS compromis, qui n'utilisent pas Puppet. La manière la plus sure est donc de lancer une recherche dans les fichiers de logs /var/log/secure (Red Hat) et /var/log/auth.log (Debian). Pour cela, il extrait l'empreinte de la clé privée de Jean-Kevin et l'utilise dans une recherche MIG.

$ ssh-keygen -yf ~/.ssh/jk_privkey > /tmp/jkpubkey

$ ssh-keygen -lf /tmp/jkpubkey

2048 c5:35:42:f4:26:ee:bc:e4:30:a6:3b:ed:f0:cb:2b:46 /tmp/jkpubkey (RSA)

$ mig file -t “status IN ('online', 'idle')” -e 6h -path /var/log -name “^(secure|auth.log)$” -content ” c5:35:42:f4:26:ee:bc:e4:30:a6:3b:ed:f0:cb:2b:46”

12084 agents will be targeted. ctrl+c to cancel. launching in 5 4 3 2 1 GO

Following action ID 1427835678713693440.status=inflight….88% …90% …92% .100%

dev1.us-east1.example.com /var/log/secure [lastmodified:2015-03-31 21:00:24.260976054 +0000 UTC, mode:-rw——-, size:6037203] in search 's1'

bastion.us-west1.example.com /var/log/auth.log [lastmodified:2015-03-31 21:00:28 +0000 UTC, mode:-rw——-, size:11773795] in search 's1'

criticalapp1.secure.example.net /var/log/auth.log [lastmodified:2015-03-31 21:00:28 +0000 UTC, mode:-rw——-, size:11773795] in search 's1'

git3.example.net /var/log/secure [lastmodified:2015-03-31 20:59:42.070241589 +0000 UTC, mode:-rw——-, size:550739] in search 's1'

4 agents have found results

Quatre résultats et donc quatre serveurs qui sont potentiellement compromis. Le bastion sur us-west1 donne probablement accès à d'autres serveurs. Gérard passe cette information à son équipe et décide de geler ces systèmes pour faciliter l'investigation. Il se connecte au bastion, tape “w” et voit une connexion pour Jean-Kevin.

jean-kevin pts/117 18.42.21.65 12:54 1:19m 0.14s 0.14s -bash

L'IP est localisée en Biélorussie. Gérard jure en triple exemplaires, son micro grand ouvert, avec le chef du chef qui venait de rejoindre la vidéo-conférence. Gérard coupe son micro, jure un peu plus, puis explique à ses collègues que le bastion s'est déjà fait prendre. Il faut geler tout le périmètre au plus vite.

Au même moment, Emmett, le spécialiste sécurité AWS de l’équipe, a identifié plusieurs instances c3.2xlarge récemment créées. La clé SSH utilisée pour accéder à ces instances n'est connue de personne. Deux indicateurs valent mieux qu'un : Jean-Kevin a clairement donné son infra en pâture à un mineur de bitcoins ! Boris ne le sait pas encore mais ses instances sont sur le point de disparaître et ses accès coupés. Tant pis, il aura tout de même réussi à les utiliser gratuitement pendant 3 heures.

Par prudence, Gérard vérifie que l'IP n'est pas connectée à d'autres systèmes. Il lance une action MIG qui inspecte le contenu de netstat sur tous les systèmes. Pour accélérer la recherche, il se limite aux agents qui sont “online”. De toute façon, les agents périodiques n'acceptent pas de connections directes de l'internet.

$ mig netstat -t “status='online'” -ci 18.42.21.65

7467 agents will be targeted. ctrl+c to cancel. launching in 5 4 3 2 1 GO

Following action ID 1427837049454201344.status=inflight….100% done in 12.942112905s

7467 sent, 7467 done, 0 inflight, 7467 succeeded, 0 failed

bastion.us-west1.example.com found connected tuple 18.42.21.65:53320 with local tuple 10.22.74.25:22 for netstat connectedip:'18.42.21.65'

1 agents have found results

Encore le bastion, et aucun autre serveur ne retourne de résultat. Au moins, il sait que l'intrus n'est pas connecté autre part. Enfin une bonne nouvelle.

Jean-Kevin retourne à son bureau, il est vingt heures et il vient de passer l’après-midi à faire des rotations de clés sur tous ses sites. Il ouvre son tiroir pour prendre ses clés d'appartement, pour s'apercevoir que le café a coulé à l’intérieur. Un dernier juron, pour la forme, et il quitte les bureaux. Fichu lundi !

Mike est fâché. Il vient de se faire souffler dans les bronches par son chef.

”- Vous vous souvenez de l'incident du serveur NTP qui s'est fait démonter par un script kiddie ? Et bien maintenant les grands chefs veulent comprendre comment l'intrus a réussi à télécharger tout son barda sur un serveur qui est censé ne faire que de l’UDP sur le port 123.

- Tu leur as expliqué que la moitié des serveurs ont accès complet à l'internet ?

- Ouais, forcément, et j'aurais mieux fait de me taire. Maintenant ils veulent la liste de tous les serveurs qui ne sont pas derrière un proxy.

- Oh la bonne blague. Et on est censé trouver ça comment ? On se farcit à la main les 4000 lignes de règles du firewall en bordure pour lister les serveurs qui ne sont pas bloqués ?

- C'est une option, si t'as rien à faire ce week-end… Sinon j'avais pensé pousser un script via puppet qui fait un curl de google.com. On stocke le code retour dans une entrée syslog et on grep tout ça sur le serveur de logs. C'est bourrin et il va nous en manquer un peu, mais ça passe.”

L’équipe continue de discuter de différente manière d'obtenir la liste des serveurs ayant accès à l'internet lorsque Gérard passe par là, une Sierra Nevada dans une main, son portable dans l'autre.

”- C'est pas pour m’immiscer, mais vous êtes au courant que MIG a un module ping ?

- Comment ça un module ping ?

- Ben ouais…”

Gérard ouvre son portable sur le bar où s’est accoudé Mike, appuie sur CTRL+SHIT+T pour ouvrir un terminal et tape :

$ mig ping -t “name like '%dc1%'” -d google.com -dp 80 -p tcp

“- Je mets '%dc1 %', c'est juste pour limiter aux serveurs qui sont sur le datacenter 1. Mais on peut lancer le ping de n'importe où vers n'importe quelle destination : tcp, udp ou icmp.”

Sur l’écran, les résultats s'accumulent :

471 agents will be targeted. ctrl+c to cancel. launching in 5 4 3 2 1 GO

Following action ID 1427841641368046848.status=inflight…99% .- 98.9% done in 11.78508943s

471 sent, 466 done, 5 inflight, 421 succeeded, 0 failed

dbmkt1.dc1.example.net tcp ping of google.com:80 (74.125.224.101) succeeded. Target is reachable.

bkp1.dc1.example.net tcp ping of google.com:80 (74.125.224.97) succeeded. Target is reachable.

ns.dc1.example.net tcp ping of google.com:80 (74.125.224.98) succeeded. Target is reachable.

ntp1.dc1.example.net tcp ping of google.com:80 (74.125.224.104) succeeded. Target is reachable.

…etc…

Gérard essaie de cacher sa satisfaction d'un air blasé qui ne trompe pas ses collègues.

“- C'est un étudiant qui a écrit le module il y a pas très longtemps. On vient juste de le déployer partout dans la dernière version de mig-agent.”

Mike sourit : “Bon ben ça c'est fait. Du coup, on reprend une bière ?”

13h29, un dimanche pluvieux, sur IRC :

«<llota> ping

<rflu> pong, quoi de neuf ?

<llota> Serge vient de donner sa démission. En fanfare, un dimanche, pendant son astreinte. Je viens d’être appelé par son chef pour fermer ses accès…

<rflu> Sympa ! Tu veux un coup de main ?

<llota> Si ça t’embête pas, oui. J'ai désactivé son LDAP et puppet a enlevé son compte de la plupart des serveurs, mais pas partout. Il me faudrait la liste.

<rflu> Ok, c'est quoi son login ?

<llota> skaramazov… aucun liens, fils unique

<rflu> Sans déconner !“

rflu ouvre son terminal et lance la recherche.

$ mig file -path /etc/passwd -content “^skaramazov:”

”<rflu> J'ai trouvé une trentaine de serveurs qui ont toujours son compte. Je t'envoie la liste par email.

<llota> Merci. Tu as moyen de voir s'il fait tourner des processus avec son compte utilisateur ?

<rflu> Bonne question… ça doit être possible si on grep /proc pour son login. Par contre, pas moyen de savoir s'il a un processus root en backdoor.

<llota> On peut peut-être vérifier si son IP est connectée ?

<rflu> Donne-moi son IP et je vais regarder.“

Chercher un processus lancé par un utilisateur est un peu plus complexe que les recherches habituelles que rflu lance via MIG. Une chance que les UID des utilisateurs sur les serveurs sont synchronisées avec LDAP. Il requête le gestionnaire d’identité et trouve l'UID de Serge : 6352. C'est suffisant pour rechercher un processus qui tourne avec cet UID, en vérifiant les fichiers status dans /proc.

$ mig file -path /proc -name “^status$” -content “^Uid:\s+6352\s+” -maxdepth 2

Following action ID 1427852086793310720.

status=inflight…74% 92% ..92% …92% ..- 93.3% done in 4m45.984075313s

1379 sent, 1287 done, 92 inflight, 1284 succeeded, 3 failed

lb1.dc2.example.net /proc/461/status [lastmodified:2015-03-04 12:08:10.845972326 +0000 UTC, mode:-r–r–r–, size:0] in search 's1'

bkpmaster.dc1.example.com /proc/15577/status [lastmodified:2015-03-31 00:45:02.056660431 +0000 UTC, mode:-r–r–r–, size:0] in search 's1'

”<rflu> J'ai trouvé deux processus qui tournent sous son utilisateur. Je suis en SSH sur les machines et il y a un tmux qui fait tourner un script dans /home/skaramazov/rrdupdate.sh. On dirait un analyseur pour les logs de HAProxy. L'autre, c'est un process mosh qui tourne le serveur de backup. Aucune idée pourquoi mais c'est un bon candidat pour un coup de hache.

<llota> Argh… le script RRD date de l’antiquité. On risque de casser des choses si on le déconnecte.

<rflu> Je te laisse gérer les dommages. As-tu pu trouver son IP que je teste les connections ?

<llota> Oui, c'est 71.103.206.54. Il a aussi une IPv6 a fe80::bada:5aff:fe99:120f/64.

<rflu> Ok, je regarde.“

Prudence oblige, rflu décide d'envoyer un email à son collègue lahcim qui s'occupe des IDS des datacenters. Quitte à surveiller des adresses IP, autant le faire au point d'inspection de tout le trafic.

Il lance toutefois une inspection immédiate des connections réseaux des serveurs, via le module netstat.

$ mig netstat -ci 71.103.206.54 -ci fe80::bada:5aff:fe99:120f/64

1407 agents will be targeted. ctrl+c to cancel. launching in 5 4 3 2 1 GO

Following action ID 1427854610404422656.status=inflight…89% …90% 100%

ssh.dc1.example.net found connected tuple 71.103.206.54:43409 with local tuple 10.22.72.158:22 for netstat connectedip:'71.103.206.54'

os2 found connected tuple 71.103.206.54:43409 with local tuple 192.168.1.3:3306 for netstat connectedip:'71.103.206.54'

2 agents have found results

Un brin perplexe, rflu inspecte les résultats. ssh.dc1 est un relais SSH. Normal donc d'y trouver une connexion vers le domicile de l'administrateur travaillant à distance. os2, par contre, est un serveur dont rflu n'a jamais entendu parler. Avec 1500 serveurs actifs, ça n'est pas vraiment étonnant. Par contre, l'IP locale sur un réseau de classe C indique que ce système ne suit pas les assignations habituelles. Curieux de localiser l'anomalie, il lance la console de MIG pour générer une carte des résultats.

mig> action 1427854610404422656

action 56> results found map

map written to /tmp/migmap_416485565

En arrière-plan, la console émet une requête de recherche à l'API de MIG demandant les résultats au format géolocalisé. Cette dernière récupère les résultats de la base de données et transforme l'adresse IP publique des deux agents en latitude et longitude via la base de données de Maxmind. Les résultats sont retournés à la console au format JSON, ce qui lui permet de générer le javascript nécessaire pour les afficher dans Google Maps.

Image : netstat_geolocalisation.png

”<rflu> J'ai trouvé deux serveurs connectés à son IPv4. ssh.dc1 est l'un deux, il faudrait penser à couper sa connexion.

<llota> Bien vu, je m'en occupe tout de suite. Et l'autre ?

<rflu> C'est un peu bizarre. Un serveur qui s'appelle “os2”. Jamais entendu parler. Vu la localisation, on dirait une instance qui tourne sur AWS dans us-east1. En plus, la connexion est directe sur 3306, donc ça doit faire tourner Mysql. T'as une idée?

<llota> Pas sur… on a bien un compte AWS qui sert à faire tourner un peu de tout.

<rflu> Vous n’aviez pas fait un PoC pour faire tourner wordpress dans AWS il n’y a pas longtemps ?
<llota> Ha si, c'est bien possible. Je vais jeter un œil mais un mysql qui tourne ouvert sur l'internet, ça sent bien le poc wordpress… Merci du coup de main.

<rflu> Pas de soucis, je suis là si besoin. De toute façon, aujourd'hui, il tombe des cordes…“

Retour dans le monde réel pour un rapide épilogue. MIG a été créé à l’été 2013 pour améliorer la collecte d'intelligence au sein des infrastructures de Mozilla. Deux ans et plusieurs milliers de lignes de Go plus tard, nous l'utilisons au quotidien pour mesurer la sécurité des systèmes et faciliter l'investigation des incidents. Une présentation complète de la plate-forme se trouve surhttp://mig.mozilla.org, et je me contenterai ici de mentionner les avantages de MIG sur d'autres projets du même type.

Tout d'abord, MIG impose des règles de sécurité stricte pour protéger son infrastructure. Les composants de MIG (API, scheduler, relais et base de données) peuvent être compromis sans propager le problème aux agents et systèmes de l'infrastructure. La sécurité des opérations réside dans la sécurité des clés PGP des investigateurs, qui doivent donc être conservées de manière sécurisée sur leurs ordinateurs. Ce modèle nous permet de déployer l'agent dans des environnements de haute sécurité sans craindre d'induire de nouveaux risques.

Ensuite, MIG ne transfère jamais de données brutes depuis les serveurs. Les recherches retournent des metadata, comme des noms de fichiers ou des paramètres de connexion, etles contenus ne sont jamais transférés. Cela permet de préserver la vie privée dans l’hypothèse où MIG serait déployé sur des postes utilisateurs, et de garantir que les contrôles d’accès aux données ne sont pas contournés par MIG. Ce principe réduit également la pression sur la base de données de MIG qui limite ainsi son stockage à de faibles quantités de metadata, quand d'autres outils transfèrent des tera-octets de données par le réseau pour effectuer des analyses du même type.

Enfin, MIG est portable et discret. Notre expérience des solutions de sécurité des systèmes nous a appris que déployer un outil sur un grand nombre de systèmes hétérogènes est très difficile soit parce que le nombre de dépendances est important, soit parce que la configuration est complexe, et parfois les deux. A contrario, l'agent de MIG se déploie avec un binaire unique sans dépendances et sans configuration (ou avec, au choix, si déployer des binaires qui contiennent des clés privées ne vous plaît pas). Il est discret, très stable, et peut tourner aussi bien sur un container LXC que sur une base de données avec 64 processeurs. Dans les deux cas, l'agent s'assurera de ne pas consommer des quantités astronomiques de ressources.

Mozilla InvestiGator est en croissance rapide. Nous ajoutons des fonctionnalités en permanence. L'objectif premier est d'améliorer les capacités d'introspection de l'agent (système de fichiers, réseau et mémoire) sur Linux, MacOS et Windows. MIG tourne déjà sur les deux premiers et le troisième est très proche. Nous travaillons également à améliorer la complexité de déploiement, par exemple en automatisant la gestion des règles d’accès et la distribution des clés des investigateurs.

Image : MIG_capabilities.png

En résumé, MIG fournit un service puissant pour réaliser des investigations en temps réel sur de grands nombres de serveurs, sans pour autant compromettre la sécurité de son infrastructure.

Julien Vehent, OpSec @ Mozilla

Remerciements à Corentin Masson pour le logo, ainsi que Guillaume Destuynder et Laurent Levier pour les relectures.