Miten tarkastella tietyn sovelluksen pyytämää verkkoliikennettä?

BY admin
|

Jos sinulla on rootattu puhelin, käytä nethogs (live-seurantaan) tai iptables (tilastojen saamiseen) komentorivityökaluja. VPN:n tai Android-tilastoihin perustuvien sovellusten käyttäminen on ainoa mahdollinen ei-juuritettu ratkaisu. Tai katso tästä vastauksesta logcat/dumpsys-pohjainen ratkaisu.

Aluksi verkkovirran UID:n tai PID:n seuraaminen ei ole suoraviivaista, koska nämä eivät ole verkkoon vaan käyttöjärjestelmään liittyviä parametreja. Ehdotuksia ja hylättyjä projekteja on olemassa.

Android antaa jokaiselle asennetulle sovellukselle yksilöllisen UID:n aivan kuten jokaisella ihmiskäyttäjällä Linuxissa on UID. Voimme siis kaapata tietyn UID:n lähettämiä paketteja verkkoliitäntöjen kautta käytön seuraamiseksi.

TCPDUMP:

Miten voimme nyt kaapata verkkoliikennettä? Useimmat verkon haisteluohjelmat käyttävät tähän tarkoitukseen libpcap-perheen järjestelmäriippumattomia kirjastoja. Se tukee BSD Packet Filteriä (BPF) ytimen sisäistä pakettien suodatusta varten. Joitakin suosittuja apuohjelmia, jotka käyttävät libpcap, ovat tcpdump, nmap, tshark/wireshark, dumpcap, nethogs jne. Android-sovellusten verkkoapuohjelmat ja muut käyttävät myös tcpdump.

UID-tietoa ei kuitenkaan välitetä AF_PACKET/PF_PACKET-kanavan kautta, jota pcap käyttää OSI-kerroksella 2. Voimme siis hyödyntää sovelluksen luomia ja käyttämiä verkkopistorasioita (IP:n ja portin yhdistelmä). netstat -tup tai ss -tup näyttää kaikki verkon pistorasiat, joissa on aktiivisia/vakiintuneita yhteyksiä. Molemmat työkalut ovat saatavilla Androidissa (tai voit hankkia staattisen binäärin), ss on uudempi. Socket vs. UID -tiedot voidaan lukea myös suoraan /proc/net/{tcp,udp}:sta. Android-sovellus Netstat Plus toimii samalla periaatteella. Se antaa prosessin käyttämän paikallisen osoitteen (socket).

Kun tiedämme, mitä socketteja sovellus käyttää (UID), tcpdump -i wlan0 src <IP> and port <PORT> dumppaa koko kyseisestä prosessista lähtevän liikenteen.
Vaikka etäsocketia (jos siihen ei ole yhdistetty useampia sovelluksia) voidaan käyttää myös tulosten suodattamiseen.

RAJOITUKSET:

Tässä lähestymistavassa on kuitenkin joitain ongelmia:

  • Android-sovellukset käynnistävät yleensä useamman kuin yhden prosessin kerrallaan rinnakkain eli useampi PID toimii saman UID:n alla. Meidän on siis kaapattava kaikkien prosessien liikenne.
  • Sovellukset luovat ja poistavat jatkuvasti socketteja. Jatkuvasti muuttuvien socketien seuraaminen on lähes mahdotonta erityisesti silloin, kun suuri määrä sovelluksia käyttää verkkoa samanaikaisesti.
  • On olemassa – vaikkakin harvinainen – mahdollisuus, että UNIX-tyyppisissä käyttöjärjestelmissä useat prosessit jakavat paikalliset socketit. Etäisiä jaettuja pistorasioita, kuten DNS-resoluutioon käytettävää UDP/53:aa, ei voida seurata yksittäisen prosessin osalta. Tämä heikentää lähestymistapaa entisestään.

NetHogs ylittää procfs ja selviytyy edellä mainituista rajoituksista (joskaan ei aina kovin onnistuneesti):

IPTABLES:

Edellä kuvatut Layer 2 -työkalun puutteet voidaan lieventää iptablesin LOG tai NFLOG avulla. Layer 2 on juuri fyysisen kerroksen yläpuolella eli se on viimeinen asia, jonka paketit kohtaavat ennen laitteesta poistumista. Siksi BPF on datayhteyskerroksessa ja toimii alemmalla tasolla verkkopinossa, ja se on eräänlainen tilaton pakettien suodatusmekanismi verrattuna netfilter / iptables:een, joka toimii OSI-kerroksessa 3 (lähempänä käyttäjäalueen ohjelmia). iptables voi siis saada tietoa myös TCP/IP-pinosta (taso 4). Se suodattaa paketteja niiden luojien UID-tunnusten perusteella käyttäen moduulia owner, joka on vuorovaikutuksessa socketien kanssa pakettien omistajuuden selvittämiseksi.

iptables kirjoittaa ytimen lokiin, joka voidaan lukea käyttämällä dmesg tai logcat. Sovelluksen UID voidaan saada käyttämällä jotain sovellusta tai lukea /data/system/packages.list:sta tai pm list packages -U:stä.

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

Tulos voidaan tallentaa tiedostoon ja muotoilla käyttäen työkaluja kuten grep, awk, printf jne. Network Log – vaikkakin hyvin vanhentunut – toimii samalla tavalla. AFWall+ on iptables pohjautuva palomuuri, joka voi kirjata / ilmoittaa sovelluksen verkkotoiminnasta, kun sovellus on estetty.

Ainoa huono puoli tässä lähestymistavassa on se, että sitä ei voi käyttää yhden prosessin liikenteen nuuskimiseen, kun useita prosesseja on käynnissä samalla UID:llä. iptables Ei voi kaapata paketteja PID:n perusteella. He päättivät olla käyttämättä iptables:ää prosessien kanssa, koska prosessi käynnistetään ennen kuin se estetään/nuuskitaan, ja ohjelma voisi helposti synnyttää lapsiprosessin uudella PID:llä, jota ei estettäisi/nuuskittaisi. Lisäksi PID:t luodaan ja tuhotaan yhtä nopeasti kuin socketit. Joten aina on tilaa liikenteen vuotamiselle.

QTAGUID:

owner moduuli ei toimi saapuvaan tai välitettävään liikenteeseen, koska IP-paketit eivät sisällä omistustietoja. Jotta voidaan mitata sovelluskohtaista saapuvaa / lähtevää verkonkäyttöä, Android korjasi ytimen sisältämään qtaguid-moduulin. Voimme lukea tilastoja /proc/net/xt_qtaguid/stats-moduulista. Joidenkin komentosarjakomentosarjojen avulla saat live-tiedonkäytön uudelleenkäynnistyksen jälkeen:

Mutta Android 9+:ssa qtaguid korvataan laajennetulla BPF:llä (jonka on myös tarkoitus korvata netfilter-kehys Linux-ytimessä). Liittyy asiaan: Mikä prosessi vastaa datan käytön kaappaamisesta?

IPTABLES + TCPDUMP:

Vaihtoehtoisesti sovelluksen lähtevä liikenne laitetaan NFLOG-ryhmään ja myöhemmin tcpdump kaappaa paketteja kyseisestä ryhmästä:

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

Tämän tarkoituksena on varmistaa, että pääsemme lähemmäs fyysistä kerrosta, kun haistelemme lähtevää liikennettä. Mutta se voi silti antaa vääriä positiivisia tuloksia esim. jos paketteja on pudotettu / kadonnut reititystaulukoihin. Siksi snifferit toimivat OSI-kerroksella 2. Tai vielä parempi on tarkkailla ulkopuolelta esim. välityspalvelimen / VPN-palvelimen avulla tai kytketyllä tietokoneella tai reitittimellä. Mutta tämä ei kaappaa liikennettä UID/PID-perusteisesti.

Muut vaihtoehdot:

  • Käytä diagnostiikkatyökaluja, kuten strace jäljittääksesi syscalls, jotka liittyvät prosessin verkkotoimintaan. force_bind ja tracedump toimivat myös samalla periaatteella. Linux-ytimen audit-alijärjestelmää voidaan käyttää samaan.
  • Käytä verkkoluokittajaa cgroup ja iptables NETFILTER_XT_MATCH_CGROUP nuuskiaksesi tiettyjen prosessien liikennettä.
  • Käytä Network Namespaces eristääksesi prosesseja ja lukeaksesi datan käyttöä rajapintakohtaisesti. nstrace toimii samalla periaatteella.
  • Jos tarkoituksena on kokonaan estää tietyistä prosesseista lähtevä liikenne, voidaan SELinux:llä ja seccomp:llä rajoittaa prosessien kykyä luoda pistorasioita määrittelemällä restricted policies ja suppressing syscalls vastaavasti.

Molemmat näistä eivät ole suoraviivaisesti käyttökelpoisia vaihtoehtoja Androidille ja vaativat edistyneempiä konfiguraatioita.

ANDROIDIN API:t (NON-ROOT OPTIONS):

Jotkut sovellukset, kuten NetGuard, käyttävät Androidin VpnService API:ta estääkseen liikennettä Layer 3:lla (TUN-liitäntä). Sovellus voi ”ilmoittaa, kun sovellus käyttää internetiä”. Sovelluskohtainen kaappaus ja seuranta (1, 2) on mahdollista VPN API:n avulla, koska Android käyttää UIDs ja SOcket_MARKs (1, 2) verkon reitityskäytäntöjen (RPDB) liikenteen hallintaan juuri ennen laitteesta poistumista.

Jotkut sovellukset, kuten NetLive, käyttävät NetworkStatsManageria, mutta se laahaa reaaliaikaisen käytön perässä eikä ”päivity riittävän nopeasti”, vaan sen ”tarkoitus on tarjota historiatietoja”.