Si tienes un teléfono rooteado, ve por nethogs (para la supervisión en directo) o iptables (para obtener estadísticas) herramientas de línea de comandos. El uso de VPN o de aplicaciones basadas en estadísticas de Android es la única solución posible que no sea Root. O consulte esta respuesta para un logcat / dumpsys solución basada en la tecnología.
En primer lugar, el seguimiento de un UID o PID de un flujo de red no es sencillo porque no son parámetros relacionados con la red sino con el sistema operativo. Propuestas y proyectos abandonados existen.
Android asigna un UID único a cada aplicación instalada, al igual que cada usuario humano en Linux tiene un UID. Así que podemos capturar los paquetes enviados por un UID específico a través de las interfaces de red para rastrear el uso.
TCPDUMP:
Ahora, ¿cómo podemos capturar el tráfico de la red? La mayoría de los sniffers de red utilizan libpcap familia de bibliotecas independientes del sistema para este fin. Soporta Filtro de paquetes BSD (BPF) para el filtrado de paquetes en el núcleo. Algunas utilidades populares que utilizan libpcap incluye tcpdump , nmap , tshark/wireshark , dumpcap , nethogs etc. Aplicación Android Utilidades de red y otros también hacen uso de tcpdump .
Sin embargo, la información del UID no se propaga a través del AF_PACKET / PF_PACKET canal que pcap utiliza en Capa 2 de OSI . Así que lo que podemos hacer aquí es hacer uso de los sockets de red (combinación de IP y puerto) que son creados y utilizados por una aplicación. netstat -tup o ss -tup mostrará todos los sockets de red con conexiones activas/establecidas. Ambas herramientas están disponibles en Android (o puedes conseguir un binario estático), ss es el más nuevo. Socket vs. UID la información también puede leerse directamente desde /proc/net/{tcp,udp} . Aplicación Android Netstat Plus funciona según el mismo principio. Esto proporcionará la dirección local (socket) utilizada por un proceso.
Una vez que sabemos qué sockets están siendo utilizados por una aplicación (UID), tcpdump -i wlan0 src <IP> and port <PORT> volcará todo el tráfico originado en ese proceso.
Del mismo modo, una toma de corriente remota (si no está conectada a varias aplicaciones) también puede utilizarse para filtrar los resultados.
LIMITACIONES:
Sin embargo, hay algunos problemas con este enfoque:
- Las aplicaciones de Android suelen lanzar más de un proceso a la vez en paralelo, es decir múltiples PIDs trabajando bajo el mismo UID . Así que tenemos que capturar el tráfico de todos los procesos.
- Las aplicaciones siguen creando y borrando sockets. Manteniendo un registro de cambio continuo de tomas de corriente es casi imposible, especialmente cuando hay un gran número de aplicaciones que acceden a la red simultáneamente.
- Existe -aunque rara- la posibilidad de que los locales los enchufes están siendo compartidos por múltiples procesos en sistemas operativos tipo UNIX. Los sockets remotos compartidos, como UDP/53, que se utiliza para la resolución de DNS, no pueden ser rastreados por un solo proceso. Esto debilita aún más el enfoque.
NetHogs atraviesa procfs y hace frente a las limitaciones mencionadas (aunque no siempre con mucho éxito):
![]()
IPTABLES:
Las deficiencias descritas anteriormente de una herramienta de capa 2 pueden mitigarse utilizando iptables LOG o NFLOG . Capa 2 está justo por encima de la Capa Física, es decir, es lo último que encuentran los paquetes antes de salir del dispositivo. Por eso, al estar en la capa de enlace de datos y trabajar en un nivel inferior de la pila de red, el BPF es una especie de mecanismo de filtrado de paquetes sin estado en comparación con netfilter / iptables que trabaja en el OSI Capa 3 (más cerca de los programas del espacio del usuario). Así que iptables también puede obtener información de la pila TCP/IP ( Capa 4 ). Filtra los paquetes en función de los UIDs de sus creadores utilizando el módulo owner que interactúa con las tomas de corriente para encontrar la propiedad del paquete.
iptables escribe en el registro del kernel que se puede leer con dmesg o logcat . El UID de una aplicación puede obtenerse mediante alguna aplicación o leerse desde /data/system/packages.list o 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
La salida puede guardarse en un archivo y formatearse con herramientas como grep , awk , printf etc. Registro de la red - aunque muy anticuado- funciona de forma similar. AFWall+ es un cortafuegos basado en iptables que puede registrar/notificar la actividad de red de una aplicación cuando ésta se bloquea.
El único inconveniente de este enfoque es que no se puede utilizar para olfatear el tráfico de un proceso cuando hay varios procesos que se ejecutan con el mismo UID . iptables no puede capturar paquetes basados en PIDs. Decidieron no usar iptables con procesos porque el proceso se inicia antes de ser bloqueado / olfateado, y el programa podría fácilmente generar un proceso hijo con un nuevo PID que no sería bloqueado / olfateado. Además, los PIDs se crean y destruyen tan rápido como los sockets. Así que siempre hay espacio para que el tráfico se filtre.
QTAGUID:
owner no funcionará para tráfico entrante o reenviado porque los paquetes IP no llevan información de propiedad. Para medir el uso de la red entrante/saliente por aplicación, Android parcheó el kernel para incluir qtaguid módulo. Podemos leer las estadísticas de /proc/net/xt_qtaguid/stats . Con algunas secuencias de comandos de shell obtener el uso de datos en vivo desde el reinicio:
![]()
Sin embargo, en Android 9+, qtaguid está siendo sustituido con ampliado BPF (que también está previsto sustituir netfilter en el núcleo de Linux). Relacionado: ¿Qué proceso es responsable de capturar la utilización de los datos?
IPTABLES + TCPDUMP:
Una alternativa es poner el tráfico saliente de una aplicación en un NFLOG grupo y posteriormente capturas tcpdump paquetes de ese grupo:
# iptables -I OUTPUT -m owner --uid-owner 1000 -j NFLOG --nflog-group 30
# tcpdump -i nflog:30
Esto es para asegurar que nos acercamos a la capa física al olfatear el tráfico saliente. Pero todavía puede dar falsos positivos Por ejemplo, si los paquetes se caen / se pierden en las tablas de enrutamiento. Por eso olfateadores trabajan en la capa 2 de OSI. O incluso mejor es ver desde el exterior, por ejemplo, utilizando un servidor proxy / VPN o en un PC atado o en el router. Pero esto no capturará el tráfico por UID/PID.
OTRAS OPCIONES:
- Utilice herramientas de diagnóstico como
strace para rastrear syscalls relacionados con la actividad de red de un proceso. force_bind y tracedump también funcionan con el mismo principio. El núcleo de Linux subsistema de auditoría puede utilizarse para lo mismo.
- Utilice Clasificador de red cgroup con
iptables NETFILTER_XT_MATCH_CGROUP para olfatear el tráfico de ciertos procesos.
- Utilice
Network Namespaces para aislar los procesos y leer el uso de datos por interfaz. nstrace funciona según el mismo principio.
- Si la intención es bloquear por completo el tráfico procedente de determinados procesos,
SELinux y seccomp se puede utilizar para restringir la capacidad de los procesos de crear sockets definiendo restricciones policies y la supresión de syscalls respectivamente.
La mayoría de ellas no son opciones directamente viables para Android y requieren configuraciones avanzadas.
APIs de Android (OPCIONES NO ROTAS):
Algunas aplicaciones como NetGuard utilice VpnService API de Android para bloquear el tráfico en la capa 3 (interfaz TUN). La aplicación puede "notificar cuando una aplicación accede a internet" . Captura y seguimiento por aplicación ( 1 , 2 ) es posible utilizando la API de VPN ya que Android hace uso de UIDs y SOcket_MARKs ( 1 , 2 ) para controlar el tráfico en la red Política de enrutamiento ( RPDB ), justo antes de dejar el dispositivo.
Algunas aplicaciones como NetLive utilizar NetworkStatsManager pero va a la zaga del uso en tiempo real y "no se actualiza con la suficiente rapidez" Es "destinado a proporcionar datos históricos" .
NOTA: No estoy afiliado a ninguna de las aplicaciones mencionadas.
RELACIONADO:
