«Трафик, который мы отправляем через сеть, часто кажется чем-то абстрактным. Мы доверяем приложениям, а они за нашими спинами отправляют данные, о которых мы можем и не подозревать. Мне удалось перехватить этот поток, и за час я обнаружил четыре разных способа, по которым мои данные ‘сбегали’ из моего устройства. Это не всегда злонамеренные программы, чаще — настройки по умолчанию и стандартные механизмы разработчиков, которые противоречат представлению о приватности.»
Постановка задачи и нужные инструменты
Цель была проста: понять, что именно уходит из моего компьютера в интернет в реальном времени, не полагаясь на общие отчёты антивирусов или брандмауэров. Для этого нужен инструмент, который видит трафик на уровне протоколов. В России для таких задач часто используют связку из прокси-сервера, который направляет весь трафик через себя, и сниффера, который этот трафик анализирует.
Вместо иностранных решений типа Wireshark в качестве основного анализатора можно взять отечественный NetworkMiner или воспользоваться встроенными возможностями mitmproxy — консольного прокси для перехвата HTTP/HTTPS. Mitmproxy, хотя и иностранного происхождения, остаётся популярным инструментом у российских специалистов по безопасности для анализа веб-трафика.
mitmproxy -p 8080Этой командой запускается прокси-сервер на порту 8080. В настройках сети операционной системы нужно указать этот прокси как системный. После этого весь HTTP и HTTPS-трафик будет проходить через него.
Первая утечка: фоновые запросы нативного ПО
Первое, что бросилось в глаза, это не запросы браузера, а поток данных от фоновых служб и приложений, которые я считал либо офлайн, либо не требующими постоянной связи.
- Клиент облачного хранилища, даже с приостановленной синхронизацией, каждые 5 минут отправлял пакет с метаданными (идентификатор устройства, версия ПО, статус сессии) на центральный сервер. Это позволяло сервису всегда знать о состоянии клиента.
- Графический редактор при запуске, помимо проверки лицензии, отправлял в аналитику информацию о разрешении экрана, установленных шрифтах и версии ОС. Это было описано в лицензионном соглашении, но на практике происходило без какого-либо уведомления.
- Системное ПО для обновления драйверов отправляло хеши установленного оборудования на свой сервер при каждом сканировании системы, даже если я отказывался от обновлений.
В терминалах mitmproxy эти запросы выглядели как регулярные HTTPS-вызовы к доменам вроде telemetry.software.com или stats.client.ru с данными в теле POST-запроса или параметрах URL.
Вторая утечка: веб-сокеты и живые соединения в браузере
Когда я начал изучать трафик браузера, стало ясно, что даже на статичной странице блога могут работать скрытые каналы связи.
- Виджет онлайн-консультанта (чата) на сайте магазина. После загрузки страницы он устанавливал постоянное WebSocket-соединение с сервером. Это соединение не разрывалось даже после закрытия всплывающего окна чата. Через него передавались технические данные о сессии, которые позволяли идентифицировать мой браузер при повторном визите.
- Сервис аналитики на новостном портале использовал не только стандартные HTTP-запросы, но и отправлял пакеты через WebSocket при прокрутке страницы, фиксируя время чтения каждой статьи с точностью до секунды.
- Фоновая синхронизация вкладок в самом браузере. Когда я открывал несколько вкладок одного сервиса (например, веб-интерфейс почты), между ними устанавливалось внутреннее соединение, но часть технической информации о состоянии этих вкладок уходила на внешний сервер для синхронизации сессий.
Это показывает, что перехвата обычных HTTP-запросов недостаточно. Нужно анализировать и другие типы соединений. В mitmproxy для этого нужно включить опцию --websocket при запуске или работать с сырым трафиком через сниффер.
Третья утечка: DNS как канал утечки информации
Самый неочевидный канал. Даже если приложение не устанавливает прямого HTTP-соединения, оно может «просигналить» о себе с помощью DNS-запросов. Многие программы используют DNS для предварительных проверок доступности серверов или для сбора аналитики.
- Плеер для потокового видео при запуске делал DNS-запрос к домену вида
device-status.cdn-provider.ru. По самому факту такого запроса (и его структуре) сервер мог понять, какая версия приложения запущена и на каком устройстве. - Браузерные расширения периодически опрашивали свои серверы обновлений через DNS, прежде чем сделать HTTP-запрос. В логах появлялись запросы к случайным поддоменам, которые содержали в себе закодированную информацию (например, хеш идентификатора расширения).
- Операционная система (а именно её служба телеметрии) использовала DNS-запросы для проверки доступности конечных точек перед отправкой больших пакетов данных.
Для перехвата DNS-трафика пришлось перенастроить системные настройки, указав в качестве DNS-сервера локальный адрес (127.0.0.1) и поднять на нём DNS-сервер с логированием, например, dnsmasq.
sudo dnsmasq --no-daemon --log-queriesЧетвёртая утечка: скрытые вызовы из внутрикорпоративных библиотек
Этот тип сложнее всего обнаружить, потому что он связан не с самим приложением, а со сторонними библиотеками, которые разработчики встраивают в свои продукты. Зачастую даже сами разработчики не в курсе всего спектра активности этих библиотек.
- Библиотека для работы с рекламой в мобильном приложении. Помимо загрузки баннеров, она в фоне отправляла на свои серверы информацию о других установленных приложениях (определяла это по косвенным признакам, таким как наличие определённых файлов или портов).
- Crash-репортер в десктопной программе. Он активировался не только при падении, но и при «необычном» поведении программы (например, очень частом вызове определённой функции), отправляя дамп памяти или логи на сервер разработчика.
- SDK для push-уведомлений. Для своей работы он должен регистрировать устройство на сервере, но вместе с токеном регистрации отправлял и детальную информацию о системе, которую можно использовать для создания уникального цифрового отпечатка устройства.
Чтобы идентифицировать такие вызовы, нужно смотреть не только на конечный домен, но и на путь запроса и заголовки. Запросы от одного и того же приложения, но к разным поддоменам api.sdk-vendor.com, metrics.sdk-vendor.com, crash.sdk-vendor.com — явный признак работы встроенных библиотек.
Что делать с найденными утечками? Технические и организационные меры
Обнаружение — только первый шаг. Дальше нужно принимать решения, основываясь на уровне риска и законах.
| Тип утечки | Возможная техническая блокировка | Организационная мера (в контексте 152-ФЗ) |
|---|---|---|
| Фоновые запросы ПО | Настройка правил в файрволе (например, Windows Firewall или iptables) для блокировки исходящих соединений конкретных .exe-файлов к определённым доменам. | Если ПО используется для обработки персональных данных, его фоновые запросы с ПДн могут считаться незаконной передачей. Требуется либо отключение телеметрии в настройках, либо выбор другого ПО. |
| WebSocket и живые соединения | Использование браузерных расширений, контролирующих WebSocket (например, uBlock Origin в расширенном режиме). Настройка прокси-правил для разрыва долгих неактивных соединений. | Сбор данных о поведении на сайте через скрытые каналы требует информированного согласия пользователя (ст. 9 152-ФЗ). Без явного согласия такая практика рискованна. |
| DNS-утечки | Перенастройка DNS на доверенный сервер (например, внутрикорпоративный) с фильтрацией запросов. Использование DNS-over-HTTPS (DoH) или DNS-over-TLS (DoT) для шифрования, но с контролем на стороне своего DNS-резолвера. | DNS-запросы, содержащие идентификаторы устройства или пользователя, могут обрабатываться ПДн. Необходимо проводить аудит используемых приложений на предмет такого поведения. |
| Вызовы из SDK и библиотек | Анализ сетевой активности приложения в песочнице перед внедрением в продуктив. Использование фаерволов уровня приложений (WAF) или reverse proxy для фильтрации исходящих запросов от бэкенд-сервисов. | Использование сторонних SDK в продукте делает вас оператором, передающим ПДн третьей стороне. Требуется проверка договора с поставщиком SDK на соответствие 152-ФЗ и включение его в Перечень действий с ПДн. |
Выводы
Час активного анализа трафика показал, что утечки данных, это не обязательно результат действий вредоносного ПО. Чаще это системная проблема: стандартные настройки коммерческого софта, механизмы аналитики, встроенные в библиотеки, и технологии, обеспечивающие удобство пользователя, одновременно создают постоянный фоновый обмен информацией. Даже при отсутствии злого умысла такой обмен может противоречить принципам минимальности обработки персональных данных, закреплённым в 152-ФЗ.
Для специалиста, отвечающего за ИБ, такой практический эксперимент — самый наглядный способ оценить реальный, а не декларируемый уровень сетевой активности инфраструктуры. Он позволяет перейти от абстрактных политик безопасности к конкретным правилам фильтрации и контроля. После этого анализа файрволл перестаёт быть просто включённой опцией, а превращается в точный инструмент, правила для которого вы пишете, понимая, что именно вы блокируете и зачем.