¿Cómo ver el tráfico de red solicitado por una aplicación específica?

Si tiene un teléfono rooteado, busque nethogs(para monitoreo en vivo) o iptables(para obtener estadísticas) herramientas de línea de comandos. El uso de aplicaciones basadas en estadísticas de VPN o Android es la única solución no root posible. O consulte esta respuesta para una solución basada en logcat/ .dumpsys

En primer lugar, el seguimiento de un UID o PID de un flujo de red no es sencillo porque no están relacionados con la red sino con los parámetros relacionados 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. Entonces podemos capturar paquetes enviados por un UID específico a través de las interfaces de red para rastrear el uso.

DESCARGA TCP:

Ahora, ¿cómo podemos capturar el tráfico de red? La mayoría de los rastreadores de red utilizan la familia libpcap de bibliotecas independientes del sistema para este propósito. Es compatible con BSD Packet Filter (BPF) para el filtrado de paquetes en el núcleo. Algunas utilidades populares que se usan libpcapincluyen tcpdump, nmap, tshark/wireshark, dumpcap, nethogsetc. La aplicación de Android Network Utilities y otras también hacen uso de tcpdump.

Sin embargo, la información de UID no se propaga a través del canal AF_PACKET/PF_PACKETpcap que se usa en la capa 2 de OSI . Entonces, lo que podemos hacer aquí es utilizar los sockets de red (combinación de IP y puerto) creados y utilizados por una aplicación. netstat -tupo ss -tupmostrará todos los enchufes de red con conexiones activas/establecidas. Ambas herramientas están disponibles en Android (o puede obtener un binario estático), sses la más nueva. La información de socket vs. UID también se puede leer directamente desde /proc/net/{tcp,udp}. La aplicación de Android Netstat Plus funciona con el mismo principio. Esto proporcionará la dirección local (socket) que utiliza un proceso.

Una vez que sabemos qué sockets está utilizando una aplicación (UID), tcpdump -i wlan0 src <IP> and port <PORT>volcaremos todo el tráfico originado en ese proceso.
De manera similar, también se puede usar un enchufe remoto (si no está conectado a varias aplicaciones) para filtrar los resultados.

LIMITACIONES:

Sin embargo, hay algunos problemas con este enfoque:

• Las aplicaciones de Android generalmente inician más de un proceso a la vez en paralelo, es decir, varios PID que funcionan con el mismo UID . Entonces tenemos que capturar el tráfico de todos los procesos.
• Las aplicaciones siguen creando y eliminando sockets. Hacer un seguimiento de los enchufes que cambian continuamente es casi imposible, especialmente cuando hay una gran cantidad de aplicaciones que acceden a la red simultáneamente.
• Existe, aunque es poco frecuente, la posibilidad de que múltiples procesos compartan sockets locales en sistemas operativos similares a UNIX. Los sockets compartidos remotos, como UDP/53, que se utilizan para la resolución de DNS, no se pueden rastrear para un solo proceso. Esto debilita aún más el enfoque.

NetHogs atraviesaprocfsy hace frente a las limitaciones anteriores (aunque no siempre con mucho éxito):

IPTABLES:

Las deficiencias descritas anteriormente de una herramienta de Capa 2 se pueden mitigar utilizando iptables LOGoNFLOG . La capa 2 está justo encima de la capa física, es decir, es lo último que encuentran los paquetes antes de abandonar el dispositivo. Es por eso que, al estar en la capa de enlace de datos y trabajar en un nivel más bajo de la pila de red, BPF es una especie de mecanismo de filtrado de paquetes sin estado en comparación con netfilter/ iptablesque funciona en la capa 3 de OSI (más cerca de los programas de espacio de usuario). Por lo tanto iptables, también puede obtener información de la pila TCP/IP ( Capa 4 ). Filtra paquetes en función de los UID de su creador mediante un módulo ownerque interactúa con los sockets para encontrar la propiedad del paquete.

iptablesescribe en el registro del kernel que se puede leer usando dmesgo logcat. El UID de una aplicación se puede obtener usando alguna aplicación o leer desde /data/system/packages.listo 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 se puede guardar en un archivo y formatear usando herramientas como grep, awk, printfetc. Network Log , aunque está muy desactualizado, funciona de manera similar. AFWall+ es un cortafuegos iptablesque puede registrar/notificar la actividad de red de una aplicación cuando la aplicación está bloqueada.

El único inconveniente de este enfoque es que no se puede utilizar para rastrear el tráfico de un proceso cuando hay varios procesos ejecutándose con el mismo UID . iptablesno puede capturar paquetes basados ​​en PID. Decidieron no utilizar iptablescon procesos porque el proceso se inicia antes de que se bloquee o detecte, y el programa podría generar fácilmente un proceso secundario con un nuevo PID que no se bloquearía ni detectaría. Además, los PID se crean y destruyen tan rápido como los sockets. Por lo tanto, siempre hay espacio para que se filtre el tráfico.

QTAGUID:

ownerEl módulo no funcionará para el tráfico entrante o reenviado porque los paquetes IP no contienen información de propiedad. Para medir el uso de la red entrante/saliente por aplicación, Android parcheó el kernel para incluir qtaguidel módulo. Podemos leer estadísticas de /proc/net/xt_qtaguid/stats. Con algunas secuencias de comandos de shell, obtenga el uso de datos en vivo desde el reinicio:

Sin embargo, en Android 9+, qtaguidse está reemplazando con BPF extendido (que también está planeado para reemplazar netfilter el marco en el kernel de Linux). Relacionado: ¿Qué proceso es responsable de capturar el uso de datos?

IPTABLES + TCPDUMP:

Una alternativa es colocar el tráfico saliente de una aplicación en un NFLOGgrupo y luego tcpdump captura los paquetes de ese grupo:

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

Esto es para garantizar que nos acerquemos a la capa física cuando rastreamos el tráfico saliente. Pero aún puede dar falsos positivos, por ejemplo, si los paquetes se descartan o se pierden en las tablas de enrutamiento. Es por eso que los sniffers funcionan en la capa 2 de OSI. O incluso mejor es mirar desde el exterior, por ejemplo, usando un servidor proxy/VPN o en una PC conectada o en un enrutador. Pero esto no capturará el tráfico por UID/PID.

OTRAS OPCIONES:

• Utilice herramientas de diagnóstico como straceel seguimiento syscallsrelacionado con la actividad de red de un proceso. force_bind y tracedump también funcionan con el mismo principio. El subsistema de auditoría del kernel de Linux se puede usar para lo mismo.
• Use el clasificador de red cgroup con iptables NETFILTER_XT_MATCH_CGROUPpara rastrear el tráfico de ciertos procesos.
• Úselo Network Namespacespara aislar procesos y leer el uso de datos por interfaz. nstrace funciona con el mismo principio.
• Si la intención es bloquear completamente el tráfico que se origina en ciertos procesos, SELinuxpuede seccompusarse para restringir la capacidad de los procesos para crear sockets definiendo restringido policiesy suprimiendo syscallsrespectivamente.

La mayoría de estas no son opciones directamente viables para Android y requieren configuraciones avanzadas.

API DE ANDROID (OPCIONES NO ROOT):

Algunas aplicaciones como NetGuard usan la API VpnService 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" . La captura y el seguimiento por aplicación ^{( 1 , 2 )} es posible mediante la API de VPN, ya que Android utiliza UIDsy SOcket_MARKs ^{( 1 , 2 )} para controlar el tráfico en la política de enrutamiento de la red ( RPDB ), justo antes de abandonar el dispositivo.

Algunas aplicaciones como NetLive hacen uso de NetworkStatsManager , pero retrasa el uso en tiempo real y "no se actualiza lo suficientemente rápido" , está "destinado a proporcionar datos históricos" .

^{NOTA: No tengo ninguna afiliación con ninguna aplicación a la que se haga referencia.}

RELACIONADO:

• ¿Restringir una aplicación para que solo envíe tráfico de Internet pero no lo reciba de vuelta?
• ¿Por qué se detecta la actividad de red de las aplicaciones después de que el firewall las bloquee?
• Captura de tráfico de telefonía móvil en Wireshark

Con PCAPdroid puede ver las conexiones individuales realizadas por las aplicaciones. Es una herramienta de código abierto desarrollada por mí que funciona sin root (la raíz es opcional). Tiene muchas características interesantes para la seguridad y privacidad de los usuarios, échale un vistazo.

Si solo desea rastrear qué aplicación realiza conexiones a qué servidor, le recomiendo la aplicación
Net Monitor . Actúa como una VPN local y, por lo tanto, puede detectar todo el tráfico de la red. Además, muestra qué aplicación ha realizado la solicitud de red (incluido el host remoto, los puertos e incluso si la conexión es simple o SSL/TLS).

Por lo tanto, si usa esta aplicación en combinación con las herramientas de captura que ya mencionó en su pregunta, debería poder rastrear todas y cada una de las conexiones de red.