Cum să vizualizați traficul de rețea solicitat de o anumită aplicație?

BY admin
|

Dacă aveți telefonul înrădăcinat, mergeți la instrumentele din linia de comandă nethogs (pentru monitorizare live) sau iptables (pentru a obține statistici). Utilizarea VPN sau a aplicațiilor bazate pe statistici Android este singura soluție posibilă fără root. Sau consultați acest răspuns pentru o soluție bazată pe logcat/dumpsys.

În primul rând, urmărirea unui UID sau PID al unui flux de rețea nu este simplă, deoarece aceștia nu sunt parametri legați de rețea, ci de sistemul de operare. Există propuneri și proiecte abandonate.

Android atribuie un UID unic fiecărei aplicații instalate, la fel cum fiecare utilizator uman pe Linux are un UID. Astfel, putem captura pachetele trimise de un anumit UID prin interfețele de rețea pentru a urmări utilizarea.

TCPDUMP:

Acum cum putem captura traficul de rețea? Majoritatea sniffer-elor de rețea folosesc în acest scop familia libpcap de biblioteci independente de sistem. Aceasta suportă BSD Packet Filter (BPF) pentru filtrarea pachetelor în kernel. Printre utilitarele populare care utilizează libpcap se numără tcpdump, nmap, tshark/wireshark, dumpcap, nethogs etc. Utilitățile de rețea ale aplicațiilor Android și altele utilizează, de asemenea, tcpdump.

Cu toate acestea, informațiile UID nu se propagă prin canalul AF_PACKET/PF_PACKET pe care pcap îl utilizează la nivelul 2 OSI. Așadar, ceea ce putem face aici este să ne folosim de socket-urile de rețea (combinație de IP și port) create și utilizate de o aplicație. sau ss -tup va afișa toate socket-urile de rețea cu conexiuni active/stabilite. Ambele instrumente sunt disponibile pe Android (sau puteți obține un binar static), ss este cel mai nou. Informațiile Socket vs. UID pot fi, de asemenea, citite direct din /proc/net/{tcp,udp}. Aplicația Android Netstat Plus funcționează pe același principiu. Aceasta va furniza adresa locală (socket) folosită de un proces.

După ce știm ce socket-uri sunt folosite de o aplicație (UID), tcpdump -i wlan0 src <IP> and port <PORT> va descărca întregul trafic provenit de la acel proces.
În mod similar, un socket la distanță (dacă nu este conectat de mai multe aplicații) poate fi, de asemenea, folosit pentru filtrarea rezultatelor.

LIMITĂRI:

Cu toate acestea, există câteva probleme cu această abordare:

  • Aplicațiile Android lansează de obicei mai multe procese în paralel, adică mai multe PID-uri care lucrează sub același UID. Așadar, trebuie să capturăm traficul de la toate procesele.
  • Aplicațiile continuă să creeze și să șteargă socket-uri. Este aproape imposibil să se țină evidența socket-urilor care se schimbă continuu, în special atunci când există un număr mare de aplicații care accesează simultan rețeaua.
  • Există – deși rar – posibilitatea ca socket-urile locale să fie partajate de mai multe procese pe sistemele de operare de tip UNIX. Socketurile partajate la distanță, cum ar fi UDP/53, care este utilizat pentru rezoluția DNS, nu pot fi urmărite pentru un singur proces. Acest lucru slăbește și mai mult abordarea.

NetHogs traversează procfs și face față limitărilor de mai sus (deși nu întotdeauna cu mare succes):

IPTABLES:

Deficiențele descrise mai sus ale unui instrument de nivel 2 pot fi atenuate folosind iptables LOG sau NFLOG. Stratul 2 se află chiar deasupra stratului fizic, adică este ultimul lucru pe care îl întâlnesc pachetele înainte de a părăsi dispozitivul. De aceea, fiind la nivelul Data Link Layer și lucrând la un nivel inferior al stivei de rețele, BPF este un fel de mecanism de filtrare a pachetelor fără stare, în comparație cu netfilter / iptables care funcționează la OSI Layer 3 (mai aproape de programele din spațiul utilizatorului). Astfel, iptables poate obține informații și de la stiva TCP/IP (Layer 4). Acesta filtrează pachetele pe baza UID-urilor creatorilor lor folosind modulul owner care interacționează cu socket-urile pentru a găsi proprietatea pachetelor.

iptables scrie în jurnalul kernel-ului care poate fi citit folosind dmesg sau logcat. UID-ul unei aplicații poate fi obținut cu ajutorul unor aplicații sau poate fi citit din /data/system/packages.list sau 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

Succesul poate fi salvat într-un fișier și formatat folosind instrumente precum grep, awk, printf etc. Network Log – deși foarte învechit – funcționează în mod similar. AFWall+ este un firewall bazat pe iptables care poate înregistra / notifica activitatea de rețea a unei aplicații atunci când aplicația este blocată.

Singurul dezavantaj al acestei abordări este că nu poate fi folosită pentru a adulmeca traficul de la un proces atunci când există mai multe procese care rulează cu același UID. iptables nu poate captura pachete bazate pe PID-uri. Ei au decis să nu folosească iptables cu procesele deoarece procesul este pornit înainte de a fi blocat/sniffat, iar programul ar putea genera cu ușurință un proces copil cu un nou PID care nu ar fi blocat/sniffat. De asemenea, PID-urile sunt create și distruse la fel de repede ca și socket-urile. Așadar, există întotdeauna loc pentru ca traficul să fie scurs.

QTAGUID:

owner modulul nu va funcționa pentru traficul de intrare sau redirecționat deoarece pachetele IP nu poartă informații de proprietate. Pentru a măsura utilizarea rețelei de intrare/ieșire per aplicație, Android a corectat kernelul pentru a include modulul qtaguid. Putem citi statisticile din /proc/net/xt_qtaguid/stats. Cu ajutorul unor scripturi shell, obțineți utilizarea datelor în direct de la repornire:

Cu toate acestea, pe Android 9+, qtaguid este înlocuit cu BPF extins (care este, de asemenea, planificat să înlocuiască cadrul netfilter în kernelul Linux). În legătură cu aceasta: Ce proces este responsabil pentru capturarea utilizării datelor?

IPTABLES + TCPDUMP:

O alternativă este de a pune traficul de ieșire de la o aplicație într-un grup NFLOG și mai târziu tcpdump captează pachetele din acel grup:

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

Aceasta este pentru a ne asigura că ne apropiem de stratul fizic atunci când adulmecăm traficul de ieșire. Dar poate da totuși rezultate fals pozitive, de exemplu, dacă pachetele sunt abandonate / pierdute în tabelele de rutare. Acesta este motivul pentru care sniffer-ele lucrează la nivelul 2 OSI. Sau chiar mai bine este să urmăriți din exterior, de exemplu, folosind un server proxy / VPN sau pe un PC conectat sau la router. Dar acest lucru nu va capta traficul pe bază de UID/PID.

ALTE OPȚIUNI:

  • Utilizați instrumente de diagnosticare precum strace pentru a urmări syscalls legate de activitatea de rețea a unui proces. force_bind și tracedump funcționează, de asemenea, pe același principiu. Subsistemul de audit al kernelului Linux poate fi utilizat pentru același lucru.
  • Utilizați clasificatorul de rețea cgroup cu iptables NETFILTER_XT_MATCH_CGROUP pentru a adulmeca traficul de la anumite procese.
  • Utilizați Network Namespaces pentru a izola procesele și a citi utilizarea datelor pe bază de interfață. nstrace funcționează pe același principiu.
  • Dacă intenția este în întregime de a bloca traficul provenit din anumite procese, SELinux și seccomp pot fi folosite pentru a restricționa capacitatea proceselor de a crea socket-uri prin definirea restricției policies și, respectiv, a suprimării syscalls.

Cele mai multe dintre acestea nu sunt opțiuni direct viabile pentru Android și necesită configurații avansate.

API-urile ANDROID (OPȚIUNI NON-ROOT):

Câteva aplicații precum NetGuard utilizează API-ul VpnService al Android pentru a bloca traficul la nivelul 3 (interfața TUN). Aplicația poate „notifica atunci când o aplicație accesează internetul”. Capturarea și urmărirea per aplicație (1, 2) este posibilă folosind VPN API, deoarece Android folosește UIDs și SOcket_MARKs (1, 2) pentru a controla traficul în politica de rutare a rețelei (RPDB), chiar înainte de a părăsi dispozitivul.

Câteva aplicații precum NetLive folosesc NetworkStatsManager, dar întârzie utilizarea în timp real și „nu se actualizează suficient de repede”, este „menită să furnizeze date istorice”.

.