Analyse des VPC Flow Logs GCP : repérer l'exfiltration
Exploiter les VPC Flow Logs Google Cloud en investigation : champs, échantillonnage, trafic sortant par IP externe, IP d'attaquant rapprochées des VM.
En bref. Les VPC Flow Logs sont le seul journal Google Cloud qui montre ce qu'une VM compromise a envoyé sur le réseau. Ils n'existent que pour les sous-réseaux où ils avaient été activés au préalable, ils sont échantillonnés et les octets sont des estimations. Additionnez bytes_sent par IP de destination externe lorsque c'est votre VM qui rapporte le flux, regardez les principales destinations pendant la fenêtre d'incident et, surtout, rapprochez les IP d'attaquant issues des journaux d'audit des pairs de flux : une IP qui a appelé vos API et parlé à vos VM relie le plan de contrôle au plan de données.
Les journaux d'audit disent ce qui a été fait via les API Google Cloud. Des données lues par un processus dans une VM (un dump de base, des fichiers sur un disque, des secrets en mémoire) puis envoyées en HTTPS n'y apparaissent jamais. Les journaux de flux comblent ce trou, avec des limites qu'il faut énoncer dans le rapport.
Ce que contient un enregistrement de flux
Les journaux de flux sont écrits dans projects/PROJECT/logs/compute.googleapis.com%2Fvpc_flows avec un jsonPayload. La référence des enregistrements de Google liste les champs ; voici ceux qui portent l'investigation :
| Champ | Usage |
|---|---|
connection.src_ip, src_port, dest_ip, dest_port, protocol | Le quintuplet |
start_time, end_time | La fenêtre d'agrégation de l'enregistrement |
bytes_sent, packets_sent | Volume estimé de la source vers la destination |
reporter | SRC ou DEST : quelle VM a rapporté le flux |
src_instance, dest_instance | Nom de VM, zone, projet quand l'extrémité est une VM |
src_location, dest_location | Pour les IP publiques : ASN, pays, région, ville |
Trois propriétés tirées de la présentation des VPC Flow Logs de Google conditionnent tout le reste :
- Échantillonnage : le taux d'échantillonnage primaire est dynamique et non configurable ; le taux secondaire est de 50 % par défaut pour les configurations faites via l'API Compute Engine. Octets et paquets sont estimés à partir de paquets échantillonnés.
- Agrégation : les enregistrements couvrent un intervalle (5 secondes par défaut, configurable jusqu'à 15 minutes).
- Pas de charge utile : uniquement des métadonnées.
Et une propriété tirée de la pratique : les journaux de flux n'existent que là où quelqu'un les a activés (par sous-réseau, réseau ou organisation) avant l'incident. La rétention par défaut dans Cloud Logging est de 30 jours.
Le sens compte : lisez le champ reporter
Un flux entre deux de vos VM peut être rapporté deux fois, une fois par chaque côté. Un flux entre votre VM et Internet n'est rapporté que par votre VM. Pour mesurer le trafic sortant :
- gardez les enregistrements où
reporter = SRCet oùsrc_instanceest renseigné (votre VM est l'émetteur), et - où
dest_ipest une adresse publique (ni RFC 1918, ni les plages de l'accès privé à Google que vous utilisez).
Additionnez ensuite bytes_sent par dest_ip. Le haut de cette liste, restreint à la fenêtre d'incident, est votre liste de candidats à l'exfiltration. dest_location.asn et country aident à distinguer un CDN d'un VPS.
Corréler avec les journaux d'audit
Le meilleur usage des journaux de flux est la corrélation. Les journaux d'audit vous donnent les IP d'attaquant (requestMetadata.callerIp) côté API. Si la même IP apparaît dans les enregistrements de flux :
- En entrée sur le port 22 après un
setMetadataajoutantssh-keyset unresetde VM : l'attaquant s'est connecté avec la clé qu'il avait injectée. Voir l'abus de Compute Engine. - En sortie sur le 443 depuis la VM, avec de nombreux enregistrements et un volume croissant : une porte dérobée installée par script de démarrage qui contacte son serveur, ou des données qui sortent. MITRE T1071 pour le commande et contrôle, T1048 pour l'exfiltration par un autre protocole.
Ce lien, une IP côté API égale à un pair côté réseau, transforme deux récits partiels en une seule chronologie.
Interroger les journaux de flux
Logs Explorer suffit pour un premier coup d'œil :
logName:"compute.googleapis.com%2Fvpc_flows"
jsonPayload.connection.dest_ip="203.0.113.66"
Pour le volume par destination sur un mois, acheminez les journaux de flux vers BigQuery et agrégez-les là-bas, ou exportez-les en JSON (voir Types de Cloud Audit Logs expliqués ; les méthodes d'export sont identiques) et déposez-les dans l'analyseur avec les journaux d'audit.
Ce que l'analyseur fait des journaux de flux
L'analyseur agrège les enregistrements de flux dans le navigateur et produit :
- L'onglet Flux VPC : nombre total d'enregistrements et d'octets, octets envoyés vers des adresses Internet, et les plus gros flux (source, destination, port, octets, enregistrements).
- Les entités IP : pour chaque IP d'appel, les octets qui lui ont été envoyés et reçus d'elle d'après les journaux de flux.
flow_large_egress(moyenne, exfiltration, T1048) : au moins 1 Gio envoyé par vos VM vers une même IP publique.flow_ioc_match(haute, commande et contrôle, T1071) : une IP à l'origine d'un constat d'audit de sévérité haute (ou d'une clé utilisée depuis une nouvelle IP) a aussi échangé du trafic avec vos VM. La cible se lit ainsi :203.0.113.66 ↔ etl-worker-1 (1.9 GiB out, 47.1 KiB in).
Les deux alimentent la corrélation de chaîne d'attaque. Dans le cas fictif commenté, c'est la correspondance de flux qui montre que la porte dérobée du script de démarrage s'est réellement exécutée.
Limites à énoncer dans le rapport
- Pas de journaux de flux, pas de conclusion. Si le sous-réseau n'avait pas de journaux de flux, « pas de gros trafic sortant » ne signifie rien.
- Des estimations. Donnez les volumes comme approximatifs, avec la réserve sur l'échantillonnage.
- Des angles morts par construction. Le trafic qui ne sort jamais par une interface journalisée (via un proxy, par exemple, ou copié via les API Google plutôt que par le réseau) demande d'autres preuves : l'article exfiltration GCS et BigQuery couvre les copies côté API.
- Infrastructures partagées. Un attaquant qui utilise une plage IP d'un fournisseur cloud peut la partager avec des services légitimes ; confirmez avec les horaires et les ports.
Avant le prochain incident
Activez les journaux de flux sur les sous-réseaux qui hébergent des charges sensibles, choisissez un taux d'échantillonnage secondaire que vous pouvez vous permettre, et acheminez-les vers un stockage longue durée avec les journaux d'audit. La page utiliser les VPC Flow Logs explique les réglages.
Questions fréquentes
Les VPC Flow Logs montrent-ils le contenu du trafic ?
Non. Les VPC Flow Logs n'enregistrent que des métadonnées de flux : IP et ports source et destination, protocole, octets et paquets estimés, côté qui a rapporté le flux, informations sur la VM et la localisation. Il n'y a pas de charge utile.
Les volumes d'octets des VPC Flow Logs sont-ils exacts ?
Non. Google décrit bytes_sent et packets_sent comme des estimations fondées sur des paquets échantillonnés et recommande d'agréger sur de plus longues périodes ou plusieurs ressources pour plus de précision. Servez-vous-en pour classer les destinations et dimensionner une exfiltration, pas comme d'un chiffre exact.
Pour aller plus loin
- Présentation des VPC Flow Logs — documentation Google Cloud.
- Format des enregistrements de flux — documentation Google Cloud.
- MITRE ATT&CK T1048, Exfiltration Over Alternative Protocol.