Protokollierung der Netzwerkaktivität

In diesem Dokument wird erläutert, wie ein Device Policy Controller (DPC) Netzwerkaktivitäten protokolliert. Lesen Sie weiter, um zu erfahren, wie Sie Ihrem DPC Netzwerkprotokollierung hinzufügen.

Übersicht

Das Protokollieren von Netzwerkaktivitäten kann Unternehmen helfen, die Verbreitung von Malware auf ihren Geräten zu erkennen und zu verfolgen. Ihr DPC kann Netzwerk-Logging APIs aufrufen, um TCP-Verbindungen und DNS-Lookups von Systemnetzwerkaufrufen zu melden.

Hinweis: Einige Anwendungen umgehen möglicherweise die protokollierten Netzwerk-APIs, indem sie eine direkte Verbindung zu Hosts herstellen. IT-Administratoren können Berichte auf Netzwerkebene erstellen, z. B. über das VPN-Gateway oder die Firewall eines Unternehmens, wenn sie eine absolute Überwachung benötigen. Berichte auf Netzwerkebene bieten zwar eine Abdeckung, doch die IP-Adresse einer Anfrage einer Anwendung, einem Gerät oder einem Nutzer lässt sich manchmal nur schwer zuordnen. Diese On-Device-Logging APIs können die Berichterstellung auf Netzwerkebene ergänzen, indem Anfragen mit einer App, einem Gerät oder einem Nutzer verknüpft werden.

Normalerweise sendet der DPC Protokolle an einen Server, der dem IT-Administrator präsentiert wird. Sie können die Logs auf Ihrem Server oder lokal auf dem Gerät weiter verarbeiten. Sie können beispielsweise DNS-Sperrlisten einrichten, um IT-Administratoren auf verdächtiges Verhalten aufmerksam zu machen.

Verfügbarkeit

Die Netzwerkprotokollierung wird ab Android 8 für Geräteeigentümer unterstützt. Wenn diese Option aktiviert ist, werden Daten zur Netzwerkaktivität des Geräts erhoben. Sie wird ab Android 12 auch für den Profilinhaber eines verwalteten Profils und einer delegierten App mit DELEGATION_NETWORK_LOGGING unterstützt. Wenn der Profilinhaber das Netzwerk-Logging aktiviert hat, enthalten die Netzwerkprotokolle nur Netzwerkaktivitäten im Arbeitsprofil. Es werden keine Daten aus dem privaten Profil erfasst.

Achtung :Der DPC kann keine Netzwerkprotokolle abrufen, wenn das Gerät nicht verbundene sekundäre Nutzer oder Arbeitsprofile hat. Während Sie darauf warten, dass neue Nutzer verbunden werden, verwirft das System Logs, sobald der interne Zwischenspeicher voll ist. Wir empfehlen dir, neue Profile zu verknüpfen, sobald sie von deinem DPC oder dem Gerätenutzer erstellt wurden. Sie warten auf Broadcasts oder Callbacks wie onUserAdded() und verknüpfen den Nutzer oder das Arbeitsprofil.

Weitere Informationen

Ereignisprotokolle

Bei aktiviertem Netzwerk-Logging zeichnet Android jedes Ereignis aus Apps auf, die die Systemnetzwerkbibliotheken verwenden. Beim Netzwerk-Logging werden zwei Arten von Ereignissen aufgezeichnet:

• DNS-Lookups
• Netzwerkverbindungen

DNS-Lookups

Beim Netzwerk-Logging wird ein Ereignis für DNS-Lookups aufgezeichnet, die Teil von Systemnetzwerkanfragen sind. In den Logs wird jede DNS-Anfrage erfasst, die einen Hostnamen in eine IP-Adresse auflöst. Andere unterstützende DNS-Abfragen, z. B. die Nameserver-Erkennung, werden nicht aufgezeichnet.

Logging-APIs für Netzwerkaktivitäten stellen jeden DNS-Lookup als DnsEvent-Instanz dar. Tabelle 1 beschreibt die Felder und typischen Werte, die in einem DnsEvent aufgezeichnet werden.

Tabelle 1 DNS-Ereignisfelder

Daten	Beispiel	Beschreibung
Hostname	host.beispiel.de	Der in der DNS-Abfrage gesendete Hostname.
Inet-Adressen	203.0.113.9, 198.51.100.25	Eine Liste von IPv4- oder IPv6-Adressen, die die DNS-Abfrage für den Hostnamen aufgelöst hat. Damit die Loggröße überschaubar bleibt, enthalten die Ergebnisse möglicherweise nicht alle IP-Adressen (siehe Anzahl der Adressen in der folgenden Zeile).
Anzahl der Adressen	4	Die Anzahl der IP-Adressen, die von der DNS-Abfrageauflösung zurückgegeben werden. Damit können Sie herausfinden, ob die protokollierten IP-Adressen eine Teilmenge der Ergebnisse sind. Ein Wert von 0 (Null) bedeutet, dass der Hostname nicht in eine IP-Adresse aufgelöst wurde.
Paketname	com.android.chrome	Der Paketname der App, von der die DNS-Abfrage durchgeführt wurde.
Zeitstempel	1506297600000	Zeitstempel, der den Zeitpunkt des DNS-Lookups erfasst. Der Wert entspricht dem Millisekundenintervall zwischen dem DNS-Lookup und Mitternacht am 1. Januar 1970 (UTC).
ID	25	Eine kontinuierlich ansteigende numerische ID. Verfügbar ab Android 9.0 (API-Level 28)

Während die DNS-Suche IT-Administratoren beim Verfolgen von Netzwerkverbindungen helfen kann, ist das Netzwerk-Logging keine universelle DNS-Aufzeichnungslösung. Hier sind einige DNS-Aufgaben, die eine Anwendung ausführen könnte, die aber nicht protokolliert werden:

• Direkte Kommunikation mit einem DNS-Nameserver
• Aufrufen einer Java DNS-Bibliothek für DNS-Abfragen
• DNS-Abfrage durch Herstellen einer Verbindung zu einer festen IP-Adresse vermeiden

Netzwerkverbindungen

Beim Netzwerk-Logging wird für jeden Verbindungsversuch ein Ereignis aufgezeichnet, das Teil einer Systemnetzwerkanfrage ist. In den Logs werden erfolgreiche und fehlgeschlagene TCP-Verbindungen erfasst. UDP-Übertragungen werden nicht aufgezeichnet.

Logging-APIs für Netzwerkaktivitäten stellen jede Verbindung als ConnectEvent-Instanz dar. Tabelle 2 beschreibt die Felder und typischen Werte, die in einem ConnectEvent aufgezeichnet werden.

Tabelle 2 Connect-Ereignisfelder

Daten	Beispiel	Beschreibung
Inet-Adressen	2001:db8::2f:abc:0	Die IP-Adresse, mit der sich das Gerät verbunden hat. Das kann eine IPv4- oder eine IPv6-Adresse sein.
Rufnummernmitnahme	80	Die TCP-Portnummer, mit der das Gerät verbunden ist.
Paketname	com.android.chrome	Der Paketname der verbundenen App.
Zeitstempel	1506297600000	Ein Zeitstempel, der aufzeichnet, wann die Netzwerkverbindung hergestellt wurde. Der Wert gibt das Millisekundenintervall zwischen der Verbindung und Mitternacht am 1. Januar 1970 (UTC) an.
ID	26	Eine kontinuierlich ansteigende numerische ID. Verfügbar ab Android 9.0 (API-Level 28)

Beim Netzwerk-Logging wird ein Ereignis aufgezeichnet, wenn eine App Standard-Netzwerkbibliotheken wie die integrierten APIs von Android oder beliebte Drittanbieterbibliotheken aufruft, um eine Verbindung zu einem Host herzustellen. Apps, die zur Kommunikation direkt Systemaufrufe senden, werden nicht protokolliert. Da UDP-Netzwerke nicht protokolliert werden, werden einige Medienstreaming-, Messaging- und Gaming-Anwendungen möglicherweise nicht in den Logs angezeigt.

Nutzer informieren

Gerätenutzer werden vom System darüber informiert, dass die Protokollierung der Netzwerkaktivitäten aktiviert ist. Auf der Benutzeroberfläche werden die folgenden Warnungen angezeigt:

• Ein Abschnitt im Dialogfeld Geräteverwaltung, in dem erläutert wird, wie Ihr DPC den Netzwerkverkehr überwacht. Nutzer können dieses Dialogfeld aufrufen, indem sie in den Schnelleinstellungen auf das Label mit den Informationen zu verwalteten Geräten tippen.
• Eine schließbare Systembenachrichtigung, die angezeigt wird, wenn der Nutzer noch keine Erfahrung mit dem Netzwerk-Logging hat. Wenn Sie auf die Benachrichtigung tippen, wird das Dialogfeld Geräteüberwachung mit weiteren Erläuterungen im Abschnitt zur Netzwerküberwachung angezeigt. Die Benachrichtigung verschwindet, wenn Ihr DPC die Netzwerkprotokollierung deaktiviert.

Netzwerk-Logging zu Ihrem DPC hinzufügen

Damit IT-Administratoren Netzwerkprotokolle prüfen können, muss Ihr DPC die folgenden Aufgaben ausführen können:

• Aktiviere oder deaktiviere die Netzwerkprotokollierung.
• Rufen Sie aufgezeichnete Logs ab, wenn ein neuer Batch bereit ist.
• Senden Sie die nützlichen Daten aus den Protokollen an einen Server.

Voraussetzungen

Das Netzwerk-Logging ist ab Android 8.0 (API-Level 26) für Geräteinhaber und Android 12 (API-Level 31) oder höher für Profilinhaber eines verwalteten Profils verfügbar. Bevor die Netzwerkaktivität protokolliert wird, sollte Ihr DPC prüfen, ob er ein Geräteinhaber oder ein Profilinhaber eines verwalteten Profils ist. Netzwerkprotokolle eines Geräteeigentümers mit einem Arbeitsprofil enthalten keine Netzwerkaktivitäten für das private Profil, wenn es vom Profilinhaber aktiviert wurde.

Netzwerkprotokollierung aktivieren

Rufen Sie zum Starten des Loggings der Netzwerkaktivität die DevicePolicyManager-Methode setNetworkLoggingEnabled() auf und übergeben Sie true als enabled-Argument. Der DPC kann isNetworkLoggingEnabled() aufrufen, um zu prüfen, ob die Netzwerkaktivität protokolliert wurde.

Nachdem der DPC das Netzwerk-Logging aktiviert hat, kann es einige Zeit dauern, bis der erste Batch von Logs bereit ist. Möglicherweise möchten Sie die Erwartungen an die Zustellung für IT-Administratoren in Ihrer Benutzeroberfläche festlegen.

Um das Logging von Netzwerkaktivitäten zu beenden, rufen Sie setNetworkLoggingEnabled() auf und übergeben Sie false. Wenn ein IT-Administrator das Netzwerk-Logging deaktiviert, löscht das System alle erfassten und nicht protokollierten Logs.

Logs abrufen

Ihr DPC kann Logs in Batches abrufen. Die Netzwerk-Logging-APIs bieten keinen zufälligen Zugriff auf frühere einzelne Einträge. Wenn ein neuer Batch von Logs verfügbar ist, empfängt die abgeleitete DeviceAdminReceiver-Klasse Ihres DPC den onNetworkLogsAvailable()-Callback. Der Callback enthält ein Batchtoken, mit dem Ihr DPC die Protokolle abrufen kann. Der DPC ruft die DevicePolicyManager-Methode retrieveNetworkLogs() auf, um eine Liste der Netzwerkereignisse abzurufen.

Das folgende Beispiel zeigt, wie Sie die Logs in Ihrer abgeleiteten Klasse DeviceAdminReceiver abrufen können:

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 ...
}

Der DPC sollte die Protokolle sofort abrufen, da das System sie löscht, um Platz für neue Batches zu schaffen. Sie sollten Ihre lokale Kopie der Logs aufbewahren, bis Sie sicher sind, dass Ihr DPC sie problemlos verarbeitet hat.

Protokolle verarbeiten

Ein Batch von Logs enthält normalerweise eine Mischung aus DnsEvent- und ConnectEvent-Instanzen. Weitere Informationen zu den Datenfeldern von DNS-Lookups und Netzwerkverbindungen finden Sie unter Ereignisprotokolle. Ereignisse werden in chronologischer Reihenfolge aufgelistet und jeder Batch enthält maximal 1.200 Ereignisse.

Prüfen Sie nach dem Aufruf der Protokolle, dass der Rückgabewert nicht null ist. Der Wert kann null sein, wenn einer der folgenden Fälle eintritt:

• Der durch das Batchtoken dargestellte Batch ist nicht mehr verfügbar. Der DPC kann den Batch nicht abrufen und sollte auf den nächsten Batch warten.
• Der IT-Administrator hat das Netzwerk-Logging deaktiviert.

Das folgende vereinfachte Beispiel zeigt, wie DPC die aufgelösten DNS-Hostnamen extrahieren kann. Der DPC benötigt eine ausgefeiltere Verarbeitung und Berichterstellung.

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());
  }
}

Das vorherige Beispiel zeigt auch, wie du die numerische ID für Ereignisse abrufen kannst, die in Android 9.0 (API-Ebene 28) oder höher enthalten sind. Da die ID mit jedem Ereignis kontinuierlich zunimmt, können IT-Administratoren Lücken in ihren Logs erkennen. Das System setzt die ID zurück, wenn ein DPC das Logging aktiviert oder das Gerät neu gestartet wird.

Ihr DPC kann die gesamte Sammlung an einen Server senden oder Sie filtern die Ereignisse auf dem Gerät. Sie können z. B. die Berichterstellung auf der Zulassungsliste für IT-Administratoren anbieten.

Entwicklung und Tests

Während Sie entwickeln und testen, möchten Sie möglicherweise onNetworkLogsAvailable()-Callbacks erhalten, ohne Hunderte von Webseiten durchsuchen zu müssen. Unter Android 9.0 (API-Level 28) und höher können Sie einige Beispiel-Netzwerkanfragen stellen und das System zwingen, einen Callback zu senden, der für Logs verfügbar ist. Führen Sie den folgenden Android Debug Bridge-Befehl (adb) auf Ihrem Terminal aus:

adb shell dpm force-network-logs

Das System schränkt ein, wie oft du das Tool verwenden kannst, und meldet eine absichtliche Verlangsamung in der Terminalausgabe. Wenn keine Logs zum Abrufen vorhanden sind, erhält der DPC keinen Callback.