Как просмотреть сетевой трафик, запрошенный конкретным приложением?

Если у вас есть рутированный телефон, используйте nethogs(для мониторинга в реальном времени) или iptables(для получения статистики) инструменты командной строки. Использование приложений, основанных на статистике VPN или Android, является единственным возможным решением без полномочий root. Или обратитесь к этому ответу для решения на основе logcat/ dumpsys.

Прежде всего, отслеживание UID или PID сетевого потока не является прямым, потому что они не связаны с сетью, а связаны с параметрами ОС. Предложения и заброшенные проекты действительно существуют.

Android присваивает уникальный UID каждому установленному приложению, точно так же, как каждый человек в Linux имеет UID. Таким образом, мы можем перехватывать пакеты, отправленные определенным UID через сетевые интерфейсы, чтобы отслеживать их использование.

TCPDUMP:

Теперь, как мы можем захватить сетевой трафик? Большинство сетевых снифферов используют для этой цели семейство системно-независимых библиотек libpcap . Он поддерживает пакетный фильтр BSD (BPF) для фильтрации пакетов в ядре. Некоторые популярные утилиты, которые используют, включают libpcap, tcpdump, , и т. Д. Сетевые утилиты приложения Android и другие также используют .nmaptshark/wiresharkdumpcapnethogstcpdump

Однако информация об UID не распространяется через канал AF_PACKET/PF_PACKET , который pcapиспользуется на уровне 2 OSI . Итак, что мы можем здесь сделать, так это использовать сетевые сокеты (комбинацию IP и порта), которые создаются и используются приложением. netstat -tupили ss -tupпокажет все сетевые сокеты с активными/установленными соединениями. Оба инструмента доступны на Android (или вы можете получить статический двоичный файл), ssэто более новый. Информация о сокетах и ​​UID также может быть напрямую прочитана из файлов /proc/net/{tcp,udp}. Android-приложение Netstat Plus работает по тому же принципу. Это предоставит локальный адрес (сокет), используемый процессом.

Как только мы узнаем, какие сокеты используются приложением (UID), tcpdump -i wlan0 src <IP> and port <PORT>мы сбросим весь трафик, исходящий от этого процесса.
Точно так же удаленный сокет (если к нему не подключено несколько приложений) также можно использовать для фильтрации результатов.

ОГРАНИЧЕНИЯ:

Однако есть некоторые проблемы с этим подходом:

• Приложения для Android обычно запускают более одного процесса одновременно, т. е. несколько PID, работающих под одним и тем же UID . Таким образом, мы должны захватить трафик со всех процессов.
• Приложения продолжают создавать и удалять сокеты. Отслеживание постоянно меняющихся сокетов практически невозможно, особенно когда к сети одновременно обращается большое количество приложений.
• Существует, хотя и редко, вероятность того, что локальные сокеты используются несколькими процессами в UNIX-подобных ОС. Удаленные общие сокеты, такие как UDP/53, которые используются для разрешения DNS, не могут отслеживаться для одного процесса. Это еще больше ослабляет подход.

NetHogs преодолеваетprocfsи справляется с вышеуказанными ограничениями (хотя и не всегда очень успешно):

ИПТАБЛИЦЫ:

Описанные выше недостатки инструмента уровня 2 можно смягчить с помощью iptables LOGилиNFLOG . Уровень 2 находится чуть выше физического уровня, т. е. это последнее, с чем сталкиваются пакеты перед тем, как покинуть устройство. Вот почему, находясь на уровне канала передачи данных и работая на более низком уровне сетевого стека, BPF является своего рода механизмом фильтрации пакетов без сохранения состояния по сравнению с netfilter/ iptables, который работает на уровне 3 OSI (ближе к программам пользовательского пространства). Таким образом iptables, также можно получить информацию из стека TCP/IP ( уровень 4 ). Он фильтрует пакеты на основе их UID создателя, используя модуль owner, который взаимодействует с сокетами , чтобы найти владельца пакета.

iptablesпишет в журнал ядра, который можно прочитать с помощью dmesgили logcat. UID приложения можно получить с помощью какого-либо приложения или прочитать из /data/system/packages.listили 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

Вывод можно сохранить в файл и отформатировать с помощью таких инструментов, как grep, awk, printfи т. д . Сетевой журнал , хотя и очень устаревший, работает аналогичным образом. AFWall+ — это брандмауэр, основанный на iptablesтом, что он может регистрировать/уведомлять сетевую активность приложения, когда приложение заблокировано.

Единственным недостатком этого подхода является то, что его нельзя использовать для прослушивания трафика от одного процесса, когда несколько процессов выполняются с одним и тем же UID . iptablesне может захватывать пакеты на основе PID. Они решили не использовать iptablesс процессами, потому что процесс запускается до того, как он будет заблокирован/сниффен, и программа может легко создать дочерний процесс с новым PID, который не будет заблокирован/сниффен. Также PID создаются и уничтожаются так же быстро, как и сокеты. Таким образом, всегда есть место для утечки трафика.

QTAGUID:

ownerмодуль не будет работать для входящего или переадресованного трафика, поскольку IP-пакеты не содержат информации о владельце. Чтобы измерить использование входящей/исходящей сети для каждого приложения, Android исправил ядро, включив в него qtaguidмодуль. Мы можем прочитать статистику из /proc/net/xt_qtaguid/stats. С помощью некоторых сценариев оболочки получите использование данных в реальном времени после перезагрузки:

Однако на Android 9+ он заменяетсяqtaguid расширенным BPF (который также планируется заменить фреймворком в ядре Linux) . Связанный: Какой процесс отвечает за сбор данных об использовании? netfilter

IPTABLES + TCPDUMP:

В качестве альтернативы можно поместить исходящий трафик из приложения в NFLOGгруппу, а затем tcpdump захватит пакеты из этой группы:

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

Это сделано для того, чтобы мы приблизились к физическому уровню при анализе исходящего трафика. Но он по-прежнему может давать ложные срабатывания, например, если пакеты отброшены/потеряны в таблицах маршрутизации. Вот почему снифферы работают на уровне OSI 2. Или, что еще лучше, наблюдать извне, например, используя прокси / VPN-сервер, или на привязанном ПК, или на маршрутизаторе. Но это не будет захватывать трафик на основе UID/PID.

ДРУГИЕ ВАРИАНТЫ:

• Используйте диагностические инструменты, такие как straceотслеживание syscallsсетевой активности процесса. force_bind и tracedump также работают по тому же принципу. Для этого можно использовать подсистему аудита ядра Linux .
• Используйте cgroup классификатора сети для iptables NETFILTER_XT_MATCH_CGROUPпрослушивания трафика от определенных процессов.
• Используйте Network Namespacesдля изоляции процессов и использования чтения данных для каждого интерфейса. nstrace работает по тому же принципу.
• Если намерение состоит в том, чтобы полностью заблокировать трафик, исходящий от определенных процессов, SELinuxи seccompможет использоваться для ограничения способности процессов создавать сокеты путем определения ограниченного policiesи подавления syscallsсоответственно.

Большинство из них не совсем подходят для Android и требуют расширенных настроек.

API-интерфейсы ANDROID (ВАРИАНТЫ НЕ ROOT):

Некоторые приложения, такие как NetGuard, используют VpnService API Android для блокировки трафика на уровне 3 (интерфейс TUN). Приложение может «уведомлять, когда приложение получает доступ к Интернету» . Захват и отслеживание для каждого приложения ^{( 1 , 2 )} возможны с использованием VPN API, поскольку Android использует UIDsи SOcket_MARKs ^{( 1 , 2 )} для управления трафиком в политике сетевой маршрутизации ( RPDB ) непосредственно перед выходом из устройства.

Некоторые приложения, такие как NetLive, используют NetworkStatsManager , но он отстает от использования в реальном времени и «не обновляется достаточно быстро» , он «предназначен для предоставления исторических данных» .

^{ПРИМЕЧАНИЕ. Я не имею отношения ни к одному из упомянутых приложений.}

СВЯЗАННЫЙ:

• Ограничение приложения только для отправки интернет-трафика, но не для его получения?
• Почему сетевая активность обнаруживается в приложениях после того, как их блокирует брандмауэр?
• Захват мобильного трафика на Wireshark

С PCAPdroid вы можете видеть отдельные соединения, установленные приложениями. Это инструмент с открытым исходным кодом, разработанный мной, который работает без рута (рут не является обязательным). Он имеет множество интересных функций для безопасности и конфиденциальности пользователей, проверьте это

Если вы хотите отслеживать только то, какое приложение выполняет подключения к какому серверу, я рекомендую вам приложение
Net Monitor . Он действует как локальная VPN и поэтому может обнаруживать весь сетевой трафик. Кроме того, он показывает, какое приложение выполнило сетевой запрос (включая удаленный хост, порты и даже является ли соединение обычным или SSL/TLS).

Поэтому, если вы используете это приложение в сочетании с инструментами захвата, которые вы уже упомянули в своем вопросе, вы сможете отслеживать каждое сетевое соединение.