Wie kann ich den von einer bestimmten App angeforderten Netzwerkverkehr anzeigen?

Es gibt viele Diskussionen darüber, wie man sieht, welche App eine Netzwerkverbindung anfordert. Folgende Apps habe ich ausprobiert:

tcapturepacket
wifi monitor
connection tracker

Allerdings war keiner von ihnen nützlich. Beispielsweise habe ich für kurze Zeit eine 30-KB-pcap-Datei hochgeladen, die hier angezeigt werden kann . Ich habe immer noch nicht herausgefunden, welche App eine Verbindung anfordert und wohin sie versucht, eine Verbindung herzustellen.

Ich habe auch versucht, nachzusehen adb logcat, aber keine nützlichen Informationen gefunden. Vielleicht wurde hier etwas übersehen. Irgendwelche Ideen?

Antworten (3)

Wenn Sie ein gerootetes Telefon haben, wählen Sie nethogs(für die Live-Überwachung) oder iptables(um Statistiken zu erhalten) Kommandozeilen-Tools. Die Verwendung von VPN- oder auf Android-Statistiken basierenden Apps ist die einzig mögliche Nicht-Root-Lösung. Oder beziehen Sie sich auf diese Antwort für eine logcat/ dumpsysbasierte Lösung.


Zunächst einmal ist das Verfolgen einer UID oder PID eines Netzwerkstreams nicht einfach, da es sich nicht um netzwerkbezogene, sondern um betriebssystembezogene Parameter handelt. Es gibt Vorschläge und aufgegebene Projekte .

Android weist jeder installierten App eine eindeutige UID zu, so wie jeder menschliche Benutzer unter Linux eine UID hat. So können wir Pakete erfassen, die von einer bestimmten UID über die Netzwerkschnittstellen gesendet werden, um die Nutzung zu verfolgen.

TCPDUMP:

Wie können wir nun den Netzwerkverkehr erfassen? Die meisten Netzwerk-Sniffer verwenden zu diesem Zweck die libpcap- Familie systemunabhängiger Bibliotheken. Es unterstützt BSD Packet Filter (BPF) für Paketfilterung im Kernel. Einige beliebte Dienstprogramme, die verwendet werden, sind libpcap, tcpdump, nmap, usw. Die Android-App Network Utilities und andere verwenden ebenfalls .tshark/wiresharkdumpcapnethogstcpdump

UID - Informationen werden jedoch nicht über den AF_PACKET/ -PF_PACKET Kanal weitergegeben , der pcapauf OSI - Schicht 2 verwendet wird . Was wir hier also tun können, ist die Verwendung von Netzwerk-Sockets (Kombination aus IP und Port), die von einer App erstellt und verwendet werden. netstat -tupoder ss -tupzeigt alle Netzwerk-Sockets mit aktiven/hergestellten Verbindungen an. Beide Tools sind auf Android verfügbar (oder Sie können eine statische Binärdatei erhalten), ssist das neuere. Socket vs. UID- Informationen können auch direkt aus gelesen werden /proc/net/{tcp,udp}. Die Android-App Netstat Plus funktioniert nach dem gleichen Prinzip. Dadurch wird die lokale Adresse (Socket) bereitgestellt, die von einem Prozess verwendet wird.

Sobald wir wissen, welche Sockets von einer App (UID) verwendet werden, tcpdump -i wlan0 src <IP> and port <PORT>wird der gesamte Datenverkehr aus diesem Prozess ausgegeben.
Ebenso kann ein Remote-Socket (sofern nicht mit mehreren Apps verbunden) auch zum Filtern von Ergebnissen verwendet werden.

EINSCHRÄNKUNGEN:

Es gibt jedoch einige Probleme mit diesem Ansatz:

  • Android-Apps starten normalerweise mehr als einen Prozess gleichzeitig parallel, dh mehrere PIDs, die unter derselben UID arbeiten . Wir müssen also den Datenverkehr von allen Prozessen erfassen.
  • Apps erstellen und löschen weiterhin Sockets. Es ist fast unmöglich , den Überblick über ständig wechselnde Steckdosen zu behalten , insbesondere wenn eine große Anzahl von Apps gleichzeitig auf das Netzwerk zugreift.
  • Es besteht – wenn auch selten – die Möglichkeit, dass lokale Sockets von mehreren Prozessen auf UNIX-ähnlichen Betriebssystemen gemeinsam genutzt werden . Remote Shared Sockets wie UDP/53, das für die DNS-Auflösung verwendet wird, können nicht für einen einzelnen Prozess verfolgt werden. Dies schwächt den Ansatz weiter.

NetHogs durchquertprocfsund bewältigt die oben genannten Einschränkungen (wenn auch nicht immer sehr erfolgreich):

IP-TABELLEN:

Die oben beschriebenen Mängel eines Layer-2-Tools können mit iptables LOGoderNFLOG gemildert werden . Schicht 2 befindet sich direkt über der physikalischen Schicht, dh es ist das Letzte, was Pakete treffen, bevor sie das Gerät verlassen. Aus diesem Grund ist BPF, da es sich auf der Sicherungsschicht befindet und auf einer niedrigeren Ebene des Netzstapels arbeitet, eine Art zustandsloser Paketfiltermechanismus im Vergleich zu netfilter/ , das auf OSI- Schicht 3 (näher an Userspace-Programmen) iptablesarbeitet . So können auch Informationen vom TCP/IP-Stack ( Layer 4 ) abgerufen werden. Es filtert Pakete basierend auf ihren Ersteller-UIDs unter Verwendung eines Moduls , das mit Sockets interagiert , um den Paketbesitz zu finden.iptablesowner

iptablesdmesgschreibt in das Kernel-Log, das mit oder gelesen werden kann logcat. Die UID einer App kann mit einer App abgerufen oder von /data/system/packages.listoder gelesen werden pm list packages -U.

# iptables -I OUTPUT -m owner --uid-owner <UID> -j LOG --log-level 7 --log-prefix 'SNIFFER: ' --log-uid
# dmesg -w | grep SNIFFER

Die Ausgabe kann in einer Datei gespeichert und mit Tools wie grep, awk, printfusw. formatiert werden. Das Netzwerkprotokoll – obwohl sehr veraltet – funktioniert auf ähnliche Weise. AFWall+ ist eine darauf basierende Firewall iptables, die die Netzwerkaktivität einer App protokollieren/benachrichtigen kann, wenn die App blockiert ist.

Der einzige Nachteil dieses Ansatzes besteht darin, dass er nicht verwendet werden kann, um den Datenverkehr von einem Prozess zu schnüffeln, wenn mehrere Prozesse mit derselben UID ausgeführt werden . iptableskann keine Pakete basierend auf PIDs erfassen. Sie haben sich gegen die Verwendung iptablesmit Prozessen entschieden , da der Prozess gestartet wird, bevor er blockiert/gesnifft wird, und das Programm leicht einen untergeordneten Prozess mit einer neuen PID erzeugen könnte, der nicht blockiert/gesnifft würde. Außerdem werden PIDs genauso schnell erstellt und zerstört wie Sockets. Es gibt also immer Raum für durchgesickerten Datenverkehr.

QTAGUID:

ownerDas Modul funktioniert nicht für eingehenden oder weitergeleiteten Datenverkehr, da IP-Pakete keine Eigentumsinformationen enthalten. Um die eingehende/ausgehende Netzwerknutzung pro App zu messen, hat Android den Kernel so gepatcht, dass er das qtaguidModul enthält. Wir können Statistiken von lesen /proc/net/xt_qtaguid/stats. Mit einigen Shell-Skripten erhalten Sie die Live-Datennutzung seit dem Neustart:

Auf Android 9+ qtaguidwird es jedoch durch erweitertes BPF ersetzt (das auch das Framework im Linux-Kernel ersetzen soll ). Verwandte Themen: Welcher Prozess ist für die Erfassung der Datennutzung verantwortlich? netfilter

IPTABLES + TCPDUMP:

Eine Alternative besteht darin, den ausgehenden Datenverkehr von einer App in eine NFLOGGruppe zu stellen und später tcpdump Pakete aus dieser Gruppe zu erfassen:

# iptables -I OUTPUT -m owner --uid-owner 1000 -j NFLOG --nflog-group 30
# tcpdump -i nflog:30

Dadurch soll sichergestellt werden, dass wir beim Sniffen des ausgehenden Datenverkehrs näher an die physische Schicht herankommen. Aber es kann immer noch falsche positive Ergebnisse geben , zB wenn Pakete in Routing-Tabellen verworfen werden oder verloren gehen. Aus diesem Grund arbeiten Sniffer auf OSI-Schicht 2. Oder noch besser ist es, von außen zuzusehen, z. B. über einen Proxy- / VPN-Server oder auf einem angebundenen PC oder Router. Dies erfasst jedoch keinen Datenverkehr auf UID/PID-Basis.

ANDERE OPTIONEN:

  • Verwenden Sie Diagnosetools, um die Netzwerkaktivität eines Prozesses stracezu verfolgen . force_bind und tracedump arbeiten ebenfalls nach dem gleichen Prinzip. Das Audit-Subsystem des Linux-Kernels kann für dasselbe verwendet werden.syscalls
  • Verwenden Sie die Netzwerkklassifikator-cgroup mit, iptables NETFILTER_XT_MATCH_CGROUPum Datenverkehr von bestimmten Prozessen zu schnüffeln.
  • Wird verwendet Network Namespaces, um Prozesse zu isolieren und die Datennutzung pro Schnittstelle zu lesen. nstrace arbeitet nach dem gleichen Prinzip.
  • Wenn die Absicht besteht, den Datenverkehr, der von bestimmten Prozessen stammt, vollständig zu blockieren, SELinuxund seccompkann verwendet werden, um die Fähigkeit der Prozesse zum Erstellen von Sockets einzuschränken, indem eingeschränkt policiesbzw. unterdrückt wird syscalls.

Die meisten davon sind nicht ohne weiteres praktikable Optionen für Android und erfordern erweiterte Konfigurationen.


ANDROID-APIs (NICHT-ROOT-OPTIONEN):

Einige Apps wie NetGuard verwenden die VpnService- API von Android, um den Datenverkehr auf Layer 3 (TUN-Schnittstelle) zu blockieren. Die App kann „benachrichtigen, wenn eine Anwendung auf das Internet zugreift“ . Das Erfassen und Verfolgen pro App ( 1 , 2 ) ist mithilfe der VPN-API möglich, wie sie Android verwendet, UIDsund SOcket_MARKs ( 1 , 2 ) , um den Datenverkehr in der Netzwerk-Routing-Richtlinie ( RPDB ) zu steuern, kurz bevor das Gerät verlassen wird.

Einige Apps wie NetLive verwenden NetworkStatsManager , aber es hinkt der Echtzeitnutzung hinterher und „aktualisiert nicht schnell genug“ , es ist „dazu gedacht, historische Daten bereitzustellen“ .

HINWEIS: Ich habe keine Zugehörigkeit zu irgendeiner App, auf die verwiesen wird.


VERWANDT:

Mit PCAPdroid können Sie die einzelnen Verbindungen sehen, die von den Apps hergestellt wurden. Es ist ein von mir entwickeltes Open-Source-Tool, das ohne Root funktioniert (Root ist optional). Es hat viele interessante Funktionen für die Sicherheit und Privatsphäre der Benutzer, sehen Sie es sich an

Das ist genau das, was ich brauchte, und ich habe es in 5 Minuten zum Laufen gebracht. Danke schön.

Wenn Sie nur verfolgen möchten, welche App Verbindungen zu welchem ​​Server durchführt, empfehle ich Ihnen die App
Net Monitor .
Es fungiert als lokales VPN und ist daher in der Lage, den gesamten Netzwerkverkehr zu erkennen. Darüber hinaus zeigt es an, welche App die Netzwerkanfrage ausgeführt hat (einschließlich Remote-Host, Ports und sogar, ob die Verbindung einfach oder SSL/TLS ist).

Wenn Sie diese App daher in Kombination mit den bereits in Ihrer Frage erwähnten Erfassungstools verwenden, sollten Sie in der Lage sein, jede einzelne Netzwerkverbindung zurückzuverfolgen.