Как найти утечки данных, перехватив собственный трафик

«Безопасность часто кажется абстрактной, пока не поймёшь, сколько твоих данных утекает в чужие руки без твоего ведома. Это не про ‘большого брата’, а про обычные приложения и сайты. Перехватив собственный трафик, можно увидеть реальную картину и закрыть самые очевидные дыры, на которые обычно не обращают внимания.»

Зачем перехватывать свой трафик

Большинство инструментов для анализа уязвимости работают на уровне кода или конфигурации. Они ищут SQL-инъекции, проблемы с правами, устаревшие библиотеки. Но есть целый пласт утечек, который остаётся невидимым до тех пор, пока не посмотришь на то, что покидает компьютер или смартфон в реальном времени: в сеть. Это отправка различных идентификаторов, технических логов, метрик использования, геоданных или даже содержимого буфера обмена в непредназначенные для этого сторонние сервисы. Такие передачи часто зашифрованы, но их конечные точки и размеры пакетов многое расскажут внимательному наблюдателю. Для специалиста в области ИБ, особенно работающего с требованиями регуляторов про защиту персональных данных и коммерческой тайны, этот навык превращается из любопытного эксперимента в необходимую практику контроля.

Подготовка инструментов

Для перехвата трафика понадобится прокси-сервер, который сможет расшифровывать HTTPS-соединения. В этом поможет Burp Suite Community Edition или OWASP ZAP. Настройка сводится к установке самоподписанного корневого сертификата прокси в доверенные на вашем устройстве, чтобы браузеры и приложения не блокировали соединения.

Второй ключевой инструмент — сетевой сниффер вроде Wireshark. Он полезен для анализа незашифрованного трафика или случаев, когда нельзя установить сертификат прокси (например, в некоторых мобильных приложениях). Также полезно иметь под рукой простой веб-сервер для эмуляции эндпоинтов, куда может утекать информация. Это поможет не только зафиксировать факт утечки, но и получить её содержимое.

Проверка трафика веб-браузера

Всё начинается с привычных сайтов

Настройте браузер на использование локального прокси-сервера. Откройте сайт, с которым часто работаете, например, почтовый сервис или внутренний корпоративный портал. В интерфейсе прокси появятся все HTTP(S) запросы.

Сначала обратите внимание на домены, отличные от основного сайта. Запросы к доменам вроде google-analytics.com или doubleclick.net ожидаемы. Но часто встречаются запросы к менее известным доменам третьих сторон, которые передают вместе с запросом уникальные идентификаторы сессии, email в параметрах URL или токены авторизации. Это классическая утечка чувствительной информации через реферера.

  • На что смотреть: Параметры в URL запросов, заголовки Referer, содержимое POST-запросов (даже если они выглядят как служебные «пинги» или «метрики»).

Анализ мобильных приложений

Здесь всё сложнее. Многие приложения используют certificate pinning — технику, которая игнорирует системные доверенные сертификаты и проверяет специфичный сертификат сервера. Обойти это можно, запустив эмулятор Android с инструментами вроде Frida или разместив устройство в сети, где весь трафик перенаправляется через анализирующий прокси с предустановленным корневым сертификатом.

Мобильные приложения — рекордсмены по скрытому сбору данных. Часто можно обнаружить отправку на серверы аналитики полного списка установленных приложений, данных о местоположении с высокой точностью (даже когда разрешение отключено в настройках), информации о модели устройства и его статусе.

Проверка фоновых служб и ПК-софта

Не стоит забывать про десктопные приложения: облачные хранилища, мессенджеры, системы для совместной работы. Некоторые из них в фоновом режиме отправляют детальную телеметрию: какие файлы открывались, сколько времени было активно окно, какие функции использовались. В терминах 152-ФЗ такая агрегированная информация может косвенно раскрывать персональные данные или характер работы, относящийся к коммерческой тайне.

Запустите Wireshark и отфильтруйте трафик по IP-адресам вашей машины. Обратите внимание на регулярные DNS-запросы к неочевидным доменам и установленные фоновые TCP-соединения, особенно после запуска того или иного ПО.

Реальные кейсы утечек за час анализа

За час целенаправленной работы можно найти как минимум четыре типа распространённых утечек.

  1. Утечка через заголовки веб-запросов. Корпоративный SaaS-сервис при каждом обращении к API включал в заголовки внутренний идентификатор пользователя и его роль (например, ‘admin’), которые затем уходили на сторонний CDN для загрузки скриптов.
  2. Отправка технических логов на публичные сервисы. Мобильное приложение одного из популярных российских банков в отладочном режиме отправляло логи, содержащие фрагменты SMS с кодами подтверждения, на сервер разработчиков, защищённый только HTTP Basic Auth.
  3. «Фоновый сбор» десктопным софтом. Приложение для управления проектами в фоне передавало структуру рабочих пространств и заголовки задач (часто содержащие ФИО и названия проектов) на сервер метрик в США.
  4. Утечка через «безобидные» виджеты. Виджет обратного звонка на сайте передавал в параметрах URL не только номер телефона, но и полный URL страницы, с которой была совершена заявка, раскрывая внутренние пути и идентификаторы сессий.

Что делать с найденными утечками

Обнаружив проблему, зафиксируйте её. Сохраните сниппеты запросов и ответов из прокси или Wireshark. Далее действия зависят от контекста.

  • Собственные разработки. Уберите отправку чувствительных данных в сторонние сервисы, очистите логи от персональных данных, настройте фильтрацию заголовков при использовании CDN.
  • Сторонние сервисы и библиотеки. Обратитесь к вендору с доказательствами проблемы. Если реакция отсутствует, рассмотрите возможность отказа от сервиса или его изоляции (например, блокировкой доменов на корпоративном файрволе).
  • Настройка мониторинга. Внедрите регулярный анализ исходящего трафика в критически важных сегментах сети. Это можно частично автоматизировать с теми же Burp Suite или ZAP, настраивая регулярные сканирования.

Как это связано с ФСТЭК и 152-ФЗ

Требования регуляторов часто воспринимаются как необходимость поставить «галочку»: сертифицировать СКЗИ, составить модель угроз. Однако суть защиты информации — в контроле над её потоками. Несанкционированная передача персональных данных или сведений, составляющих коммерческую тайну, за пределы контролируемой зоны является прямым нарушением.

Практика перехвата трафика помогает верифицировать положения политик безопасности на практике, а не на бумаге. Она позволяет ответить на ключевые вопросы: куда реально уходят данные, указанные в согласии на обработку ПДн? Проверяет ли ваш WAF или межсетевой экран утечки через SSL или нестандартные порты? Без этого понимания система защиты остаётся неполной, с брешами, которые невозможно увидеть стандартными средствами аудита.

Оставьте комментарий