Consignation de l'activité réseau

Ce document explique comment un outil de contrôle des règles relatives aux appareils (DPC) consigne l'activité réseau. Poursuivez la lecture pour découvrir comment ajouter la journalisation réseau à votre DPC.

Présentation

La journalisation de l'activité réseau peut aider les entreprises à détecter et à suivre la propagation des logiciels malveillants sur leurs appareils. Votre DPC peut appeler des API de journalisation réseau pour signaler les connexions TCP et les résolutions DNS à partir des appels réseau système.

En règle générale, votre DPC envoie les journaux à un serveur pour les présenter à un administrateur informatique. Vous pouvez souhaiter continuer à traiter les journaux sur votre serveur ou localement sur l'appareil. Par exemple, vous pouvez configurer des listes de blocage DNS pour détecter les comportements suspects et en avertir les administrateurs informatiques.

Disponibilité

La journalisation réseau est compatible avec Android 8 et versions ultérieures pour les propriétaires d'appareils. S'il est activé, il collecte des données sur l'activité réseau de l'appareil. Elle est également compatible avec Android 12 et versions ultérieures pour le propriétaire d'un profil géré et une application déléguée avec DELEGATION_NETWORK_LOGGING. Lorsque la journalisation réseau est activée par le propriétaire du profil, les journaux réseau n'incluent que l'activité réseau du profil professionnel et ne collectent pas les données du profil personnel.

Pour en savoir plus, consultez Utilisateurs affiliés.

Journaux des événements

Lorsque la journalisation réseau est active, Android enregistre chaque événement des applications à l'aide des bibliothèques de mise en réseau système. La journalisation réseau enregistre deux types d'événements:

  • Résolutions DNS
  • Connexions réseau

Résolutions DNS

La journalisation réseau enregistre un événement pour les résolutions DNS faisant partie des requêtes réseau du système. Les journaux capturent chaque requête DNS qui résout un nom d'hôte en une adresse IP. Les autres requêtes DNS compatibles, telles que la découverte du serveur de noms, ne sont pas enregistrées.

Les API de journalisation de l'activité réseau présentent chaque résolution DNS en tant qu'instance DnsEvent. Le tableau 1 décrit les champs et les valeurs types enregistrées dans un DnsEvent.

Tableau 1. Champs d'événement DNS

Données Exemple Description
Nom d'hôte hote.example.com Nom d'hôte envoyé dans la requête DNS.
Adresses Inet 203.0.113.9, 198.51.100.25 Une liste d'adresses IPv4 ou IPv6 que la requête DNS a résolue pour le nom d'hôte. Pour que la taille du journal reste raisonnable, les résultats peuvent ne pas inclure toutes les adresses IP (voir le nombre d'adresses sur la ligne suivante).
Nombre d'adresses 4 Nombre d'adresses IP renvoyées par la résolution de requête DNS. Utilisez-le pour savoir si les adresses IP consignées constituent un sous-ensemble des résultats. Une valeur de 0 (zéro) signifie que le nom d'hôte n'a pas été résolu en adresse IP.
Nom du package com.android.chrome. Nom du package de l'application qui a effectué la requête DNS.
Code temporel 1506297600000 Enregistrement du code temporel correspondant au moment où la résolution DNS s'est produite. Cette valeur correspond à l'intervalle de millisecondes entre la résolution DNS et le 1er janvier 1970 à minuit UTC.
ID 25 Identifiant numérique augmentant de manière monotone. Disponible sous Android 9.0 (niveau d'API 28) ou version ultérieure.

Bien que les résolutions DNS puissent aider les administrateurs informatiques à suivre les connexions réseau, la journalisation réseau n'est pas une solution d'enregistrement DNS à usage général. Voici quelques tâches DNS qu'une application peut effectuer et qui ne sont pas consignées:

  • Communiquer directement avec un serveur de noms DNS.
  • Appeler une bibliothèque DNS Java pour effectuer des requêtes DNS
  • Éviter une requête DNS en se connectant à une adresse IP fixe.

Connexions réseau

La journalisation réseau enregistre un événement pour chaque tentative de connexion faisant partie d'une requête réseau système. Les journaux capturent les connexions TCP réussies et échouées. Les transferts UDP ne sont pas enregistrés.

Les API de journalisation de l'activité réseau présentent chaque connexion en tant qu'instance ConnectEvent. Le tableau 2 décrit les champs et les valeurs types enregistrées dans un ConnectEvent.

Tableau 2. Associer des champs d'événement

Données Exemple Description
Adresses Inet 2001:db8::2f:abc:0 Adresse IP à laquelle l'appareil s'est connecté. Il peut s'agir d'une adresse IPv4 ou IPv6.
Transfert 80 Numéro de port TCP auquel l'appareil est connecté.
Nom du package com.android.chrome. Nom de package de l'application qui s'est connectée.
Code temporel 1506297600000 Enregistrement du code temporel correspondant au moment où la connexion réseau s'est produite. La valeur correspond à l'intervalle de millisecondes entre la connexion et le 1er janvier 1970 à minuit UTC.
ID 26 Identifiant numérique augmentant de manière monotone. Disponible sous Android 9.0 (niveau d'API 28) ou version ultérieure.

La journalisation réseau enregistre un événement lorsqu'une application appelle des bibliothèques réseau standards, telles que les API intégrées d'Android ou des bibliothèques tierces populaires, pour se connecter à un hôte. Les applications émettant des appels système directement pour communiquer ne sont pas consignées. N'oubliez pas que la mise en réseau UDP n'est pas journalisée. Par conséquent, certaines applications de streaming multimédia, de messagerie et de jeux peuvent ne pas apparaître dans les journaux.

Informer les utilisateurs

Le système avertit les utilisateurs de l'appareil que la journalisation de l'activité réseau est active. Les utilisateurs voient les avertissements suivants dans l'interface:

  • Section de la boîte de dialogue Gestion des appareils expliquant que votre DPC surveille le trafic réseau. Les utilisateurs peuvent voir la boîte de dialogue en appuyant sur le libellé d'informations sur l'appareil géré dans les Réglages rapides.
  • Notification système ignorable qui s'affiche lorsque l'utilisateur commence à utiliser la journalisation réseau. Si vous appuyez sur la notification, la boîte de dialogue Device monitoring (Surveillance des appareils) s'affiche avec des explications supplémentaires dans une section de surveillance du réseau. La notification disparaît lorsque votre DPC désactive la journalisation réseau.

Ajouter la journalisation réseau à votre DPC

Pour aider les administrateurs informatiques à examiner les journaux réseau, votre DPC doit être en mesure d'effectuer les tâches suivantes:

  • Activez et désactivez la journalisation du réseau.
  • Récupérez tous les journaux enregistrés lorsqu'un nouveau lot est prêt.
  • Envoyez les données utiles des journaux à un serveur.

Exigences

La journalisation réseau est disponible sur Android 8.0 (niveau d'API 26) ou version ultérieure pour un propriétaire d'appareil et sur Android 12 (niveau d'API 31) ou version ultérieure pour un propriétaire de profil géré. Avant de consigner l'activité réseau, votre DPC doit vérifier s'il s'agit du propriétaire d'un appareil ou du propriétaire d'un profil géré. Les journaux réseau d'un propriétaire d'appareil disposant d'un profil professionnel n'incluent pas l'activité réseau sur le profil personnel si elle est activée par le propriétaire du profil.

Activer la journalisation réseau

Pour commencer la journalisation de l'activité réseau, appelez la méthode DevicePolicyManager setNetworkLoggingEnabled() et transmettez true en tant qu'argument enabled. Votre DPC peut appeler isNetworkLoggingEnabled() pour vérifier si l'activité réseau est journalisée.

Une fois que votre DPC active la journalisation réseau, il peut s'écouler un certain temps avant que le premier lot de journaux ne soit prêt. Vous pouvez définir des attentes de livraison pour les administrateurs informatiques dans votre interface utilisateur.

Pour arrêter la journalisation de l'activité réseau, appelez setNetworkLoggingEnabled() et transmettez false. Lorsqu'un administrateur informatique désactive la journalisation réseau, le système supprime tous les journaux collectés et non consignés.

Récupérer les journaux

Votre DPC peut récupérer les journaux par lots. Les API de journalisation réseau ne fournissent pas d'accès aléatoire aux entrées individuelles précédentes. Lorsqu'un nouveau lot de journaux est disponible, la sous-classe DeviceAdminReceiver de votre DPC reçoit le rappel onNetworkLogsAvailable(). Le rappel inclut un jeton de lot que votre DPC peut utiliser pour récupérer les journaux. Votre DPC appelle la méthode DevicePolicyManager retrieveNetworkLogs() pour obtenir la liste des événements réseau.

L'exemple suivant montre que vous pouvez récupérer les journaux dans votre sous-classe DeviceAdminReceiver:

Kotlin

fun onNetworkLogsAvailable(
        context: Context, intent: Intent, batchToken: Long, networkLogsCount: Int) {

    val dpm = getManager(context)
    var logs: List<NetworkEvent>? = null

    // Fetch the batch of logs with the batch token from the callback's arguments.
    try {
        logs = dpm.retrieveNetworkLogs(getWho(context), batchToken)
    } catch (e: SecurityException) {
        // Perhaps an unaffiliated user - handle the exception ...
    }

    // Process any logs ...
}

Java

public void onNetworkLogsAvailable(
    Context context, Intent intent, long batchToken, int networkLogsCount) {

  DevicePolicyManager dpm = getManager(context);
  List<NetworkEvent> logs = null;

  // Fetch the next batch of logs using the callback's batch token argument.
  try {
    logs = dpm.retrieveNetworkLogs(getWho(context), batchToken);
  } catch (SecurityException e) {
    // Perhaps an unaffiliated user - handle the exception ...
  }

  // Process any logs ...
}

Votre DPC doit récupérer les journaux immédiatement, car le système les supprime pour libérer de l'espace pour de nouveaux lots. Vous pouvez conserver votre copie locale des journaux jusqu'à ce que vous soyez sûr que votre DPC les a tous traités sans problème.

Traiter tous les journaux

Un lot de journaux contient généralement un mélange d'instances DnsEvent et ConnectEvent. Pour en savoir plus sur les champs de données des résolutions DNS et des connexions réseau, consultez la page Journaux des événements. Les événements sont classés par ordre chronologique et chaque lot ne contient pas plus de 1 200 événements.

Après avoir appelé la récupération des journaux, vérifiez que la valeur renvoyée n'est pas null. Cette valeur peut être null dans les cas suivants:

  • Le lot représenté par le jeton de lot n'est plus disponible. Votre DPC ne peut pas récupérer le lot et doit attendre le lot suivant.
  • L'administrateur informatique a désactivé la journalisation réseau.

L'exemple simplifié suivant montre comment l'outil DPC peut extraire les noms d'hôte DNS résolus. Votre DPC nécessite un traitement et des rapports plus sophistiqués.

Kotlin

// Here, logs might be null. We can't fix because either the token doesn't match
// the current batch or network logging was deactivated.
// Confirm with isNetworkLoggingEnabled().

logs?.forEach {
    // For this example, report the DNS hosts and discard all other data.
    // Because we use the event ID, this example requires API level 28.
    if (it is DnsEvent) {
        reportDnsHostToServer(it.hostname, it.getTimestamp(), it.getId())
    }
}

Java

if (logs == null) {
  // Abandon processing because either the token doesn't match the current batch
  // or network logging was deactivated - confirm with isNetworkLoggingEnabled().
  return;
}

for (NetworkEvent event : logs) {
  // For this example, report the DNS hosts and discard all other data.
  // This example requires API level 28 because we use the event ID.
  if (event instanceof DnsEvent) {
    reportDnsHostToServer(
        ((DnsEvent) event).getHostname(), event.getTimestamp(), event.getId());
  }
}

L'exemple précédent montre également comment obtenir l'ID numérique des événements inclus dans Android 9.0 (niveau d'API 28) ou version ultérieure. Étant donné que l'ID augmente de manière monotone pour chaque événement, vous pouvez aider les administrateurs informatiques à détecter les lacunes dans leurs journaux. Le système réinitialise l'ID chaque fois qu'un DPC active la journalisation ou lorsque l'appareil redémarre.

Votre DPC peut envoyer l'intégralité de la collection à un serveur ou vous pouvez décider de filtrer les événements sur l'appareil. Par exemple, vous pouvez proposer aux administrateurs informatiques des rapports sur liste d'autorisation.

Développement et tests

Lorsque vous développez et testez votre application, vous pouvez recevoir des rappels onNetworkLogsAvailable() sans avoir à parcourir des centaines de pages Web. Dans Android 9.0 (niveau d'API 28) ou version ultérieure, vous pouvez envoyer quelques exemples de requêtes réseau et forcer le système à envoyer un rappel disponible pour les journaux. Exécutez la commande Android Debug Bridge (adb) suivante dans votre terminal:

adb shell dpm force-network-logs

Le système limite la fréquence d'utilisation de l'outil et signale tout ralentissement intentionnel dans la sortie du terminal. S'il n'y a pas de journaux à récupérer, votre DPC ne reçoit pas de rappel.