Что такое журналы связи
Интернет-связь не обязательно полностью исчезает сразу после передачи.
На Web-сайтах, серверах, DNS, у операторов связи, на роутерах и файрволах могут оставаться записи о связи.
Такие записи обычно называют журналами связи.
Журналы связи могут включать не только само содержимое, но и окружающую информацию: время связи, IP-адрес источника, назначение, URL, сведения браузера, , DNS-запросы и другое.
При размышлении об анонимности недостаточно смотреть только на то, зашифровано ли содержимое связи.
Даже если содержимое не читается, метаданные связи могут стать признаками для отслеживания.
Где остаются журналы связи
Журнал связи — это запись, связанная со связью.
Например, при доступе к Web-сайту на стороне Web-сервера может записываться, когда, с какого IP-адреса, к какому URL и с какими сведениями браузера был доступ.
Однако журналы не остаются одинаково во всех средах. Что записывать, зависит от настроек сервера, проектирования приложения, облачного сервиса, сетевой конфигурации и политики хранения.
Важно, что в интернет-связи есть несколько точек наблюдения. На стороне сайта, DNS, оператора связи, роутера, внутренней сети, облачной платформы могут оставаться разные виды журналов.
| Где могут оставаться журналы | Что может записываться | Основная цель |
|---|---|---|
| Web-сервер | Время доступа, IP-адрес, URL, User-Agent, Referer и т.п. | Аналитика доступа, устранение сбоев, обнаружение атак |
| Приложение | История входов, история операций, ошибки, ID аккаунта и т.п. | Борьба со злоупотреблениями, эксплуатация сервиса |
| DNS-резолвер | Запрошенное доменное имя, время запроса, сведения источника и т.п. | Разрешение имен, управление сетью |
| Оператор связи | Время подключения, назначенный IP-адрес, объем связи, часть сведений о назначении и т.п. | Эксплуатация линии, управление подключением |
| Роутер / файрвол | Назначение, объем связи, заблокированная связь, внутренние устройства и т.п. | Управление сетью, безопасность |
Зачем остаются журналы
Журналы существуют не только для наблюдения за пользователями. Во многих случаях они нужны для стабильной работы сервисов и сетей.
Если на сайте произошла ошибка, администратор смотрит журналы и выясняет, на каком URL, в какое время и какая ошибка возникла.
При подозрениях на незаконный вход, массовый доступ, сканирование уязвимостей, заражение вредоносным ПО, утечку данных журналы тоже становятся важным материалом расследования.
| Цель | Как используются | Пример |
|---|---|---|
| Устранение сбоев | Исследование причин ошибок и остановок | Проверить, растут ли ошибки 500 на конкретном URL |
| Безопасность | Обнаружение подозрительного доступа | Проверить, нет ли множества попыток входа за короткое время |
| Борьба со злоупотреблениями | Поиск признаков нарушений и атак | Проверить необычные запросы и неестественный источник |
| Улучшение сервиса | Понимание использования | Проверить часто читаемые страницы и часы высокого доступа |
Журналы — базовый механизм защиты сервиса. Но они могут содержать сведения о поведении пользователя, поэтому при плохом управлении становятся риском приватности.
Журналы на стороне Web-сайта
При доступе к Web-сайту на стороне Web-сервера могут оставаться журналы доступа.
Типичный журнал доступа включает IP-адрес источника, время доступа, HTTP-метод, URL, статус-код, User-Agent, Referer и другое.
Пример URL:
Пример URL : https[:]//example.com/article/network-log
Здесь example.com — демонстрационный домен, часто используемый для объяснений.
Даже при HTTPS сторона сайта получает путь и query URL, Cookie и сведения запроса. HTTPS делает содержимое труднее читаемым на маршруте, но не мешает самому сайту назначения получать запрос.
Однако информация, которую Web-сервер получает, и информация, которую он фактически сохраняет в журнале, не одно и то же. Cookie и тело запроса могут записываться или не записываться в зависимости от настроек сервера и приложения.
| Информация | Содержание | Внимание |
|---|---|---|
| Время доступа | Когда был доступ | Может стать признаком для сопоставления с другими журналами |
| IP-адрес источника доступа | С какого IP было подключение | При CDN или прокси непосредственный источник может быть промежуточным сервером |
| URL | Какая страница или API открыты | Query string может содержать идентификаторы |
| User-Agent | Тип браузера, OS, приложения и т.п. | Может быть материалом для предположения среды |
| Cookie | Идентификатор, который сайт сохраняет и отправляет через браузер | Может использоваться для повторного посещения и состояния входа |
| Referer | С какой страницы был переход | Может не отправляться или отправляться частично из-за Referrer-Policy |
| Статус-код | Результат запроса | 200, 301, 403, 404, 500 и т.п. показывают результат обработки |
Если сайт использует CDN, балансировщик нагрузки или reverse proxy, IP-адрес источника, видимый Web-серверу, может быть IP промежуточного сервера, а не пользователя. В этом случае исходный IP клиента может записываться в заголовках вроде X-Forwarded-For или в журналах CDN.
Журналы приложений и систем аутентификации
Серверные журналы — это не только access log Web-сервера.
Записи об операциях и поведении системы могут оставаться в функциях входа, платежах, админке, API, базе данных, системах мониторинга ошибок и другом.
Например, сервис с входом может записывать:
- успешный вход
- неуспешный вход
- смену пароля
- попытку двухфакторной аутентификации
- выдачу сессии
- изменение настроек аккаунта
- доступ к админке
Сервис с API может записывать, к какому endpoint, с какого аккаунта или IP-адреса и в какое время был отправлен запрос.
Эти журналы используются для обнаружения незаконного входа, захвата аккаунта, злоупотребления правами, аномального API-использования и другого.
Возможные записи у оператора связи
При подключении к интернету связь пользователя обычно проходит через сеть оператора связи или оператора линии.
У оператора могут оставаться записи о подключении: когда линия была подключена, какой IP-адрес был назначен, какой объем связи был.
В домашних и мобильных линиях IP-адрес пользователя может быть не фиксированным и меняться со временем. Поэтому информация «какая договорная линия использовала этот IP в такое время» связана с записями оператора связи.
В мобильных и некоторых других линиях может использоваться механизм, где многие пользователи делят один глобальный IP. В этом случае для различения подключения могут быть важны не только IP-адрес, но и время, номер порта и другие сведения.
Однако наличие записей у оператора связи и возможность их свободного просмотра кем угодно — разные вещи. Журналы оператора обычно не доступны обычным пользователям свободно.
Записи, связанные с DNS
При доступе к Web-сайту браузер или OS должны преобразовать доменное имя в IP-адрес. Этот механизм называется DNS.
Например, при доступе к такому URL устройство ищет IP-адрес для example.com.
Пример URL : https[:]//example.com
В записях DNS-запросов может оставаться, с какого устройства или сети и о каком домене был запрос.
DNS-журнал не записывает сам текст Web-страницы. Но он может показывать, к какому домену была попытка доступа.
Важно, что место записи DNS-запроса зависит от среды. Если используется DNS оператора связи, запрос может попадать к DNS-резолверу оператора. Если браузер или OS использует другой резолвер или зашифрованный DNS, адресат запроса меняется.
Поэтому при размышлении о DNS-журналах нужно смотреть, к какому DNS-резолверу выполнялся запрос.
Журналы роутеров и файрволов
Журналы связи остаются не только на Web-сайтах и у операторов связи.
Домашний роутер, сетевое оборудование компании или школы, облачный файрвол, прокси-сервер, -шлюз и другое тоже могут оставлять записи о связи.
В организационных сетях могут записывать, какое устройство, когда и к какому внешнему серверу подключалось. Это используется для расследования заражения вредоносным ПО, незаконного доступа, утечки данных, внутренних злоупотреблений.
На стороне серверов тоже могут существовать разные журналы: журналы аутентификации OS, журналы файрвола, SSH-журналы, журналы приложений, облачные audit logs.
Например, в управлении сервером важны такие журналы:
| Тип журнала | Что может записываться | Как используется |
|---|---|---|
| Журнал аутентификации | Успешный вход, неуспешный вход, IP-адрес источника и т.п. | Проверка незаконных входов и brute force |
| Журнал файрвола | Разрешенная и заблокированная связь, номер порта, назначение | Обнаружение подозрительной связи и атак |
| Журнал прокси | Доступ внутренних устройств к внешним сайтам | Управление и расследования в организации |
| Облачный audit log | Административные операции, API-вызовы, изменения прав | Отслеживание изменений настроек и злоупотребления правами |
| Журнал приложения | Ошибки, история операций, результаты обработки | Устранение сбоев и расследование злоупотреблений |
Так журналы связи существуют не только как запись доступа к сайту, а распределены по сети и системам.
Отношение HTTPS и журналов
HTTPS важен для шифрования содержимого связи и проверки, что другая сторона — нужная.
Но использование HTTPS не означает, что вся информация о связи становится неизвестной всем.
Главная цель HTTPS — содержимое, видимое третьим лицам на маршруте. Например, содержимое формы, текст страницы, многие HTTP-заголовки, путь URL и query обычно труднее прочитать на маршруте.
С другой стороны, Web-сервер назначения расшифровывает связь и обрабатывает запрос. Поэтому стороне сайта передаются URL, Cookie, User-Agent, данные входа, отправленные формы и другое.
Также на маршруте могут наблюдаться время подключения, IP-адрес источника, IP-адрес назначения, объем связи, часть сведений о TLS-подключении.
То есть HTTPS очень важен, но он не стирает проблему журналов.
| Сторона наблюдения | Что может быть видно | Что труднее увидеть |
|---|---|---|
| Web-сайт | URL, Cookie, User-Agent, отправленные данные, операции входа и т.п. | Содержимое, которое не должно быть видно третьим лицам на маршруте |
| Третья сторона на маршруте | IP источника, IP назначения, время связи, объем связи и т.п. | Текст страницы, содержимое формы, путь и query URL |
| DNS-резолвер | Запрошенное доменное имя, время запроса и т.п. | Текст Web-страницы и конкретные операции |
| Роутер / файрвол | Назначение, объем связи, разрешение / блокировка и т.п. | Текст внутри HTTPS и многие HTTP-заголовки |
Журналы не обязательно плохи
С точки зрения анонимности и приватности журналы связи требуют внимания. Но сами журналы не являются злом.
Без журналов трудно расследовать причины сбоев, обнаруживать незаконный доступ, реагировать на захват аккаунтов, расследовать заражение вредоносным ПО и стабильно эксплуатировать сервис.
Важно, зачем сохраняются журналы, какой объем записывается, как долго хранится и кто имеет доступ.
Наличие журналов и возможность свободного просмотра кем угодно — разные вещи. Правильно управляемые журналы важны для защиты сервиса, но чрезмерно хранимые или плохо защищенные журналы становятся риском приватности.
В анонимности журналы становятся подсказками
При размышлении об анонимности недостаточно смотреть только на то, зашифровано ли содержимое связи.
Даже если содержимое не читается, время связи, IP-адрес источника, назначение, DNS-запрос, Cookie, User-Agent, Referer и другое могут записываться в другой форме.
Эти сведения по отдельности не всегда прямо идентифицируют человека. Но при сочетании нескольких записей они могут помогать предположить одного и того же пользователя, маршрут доступа, временную последовательность действий, сеть источника.
| Информация | Что может стать понятно | Внимание для анонимности |
|---|---|---|
| Время доступа | Когда была связь | Может сопоставляться с другими записями по времени |
| IP-адрес | Из какой сети было подключение | Может быть материалом для предположения линии, региона, организации |
| DNS-запрос | К какому домену была попытка доступа | Даже без текста страницы дает признак назначения |
| Cookie | Был ли доступ из того же браузера | Может использоваться для повторного посещения и состояния входа |
| User-Agent | Тип браузера и OS | Может быть особенностью среды |
| Referer | С какой страницы пришел пользователь | Может показать часть маршрута перехода |
| Query в URL | Может содержать поисковые слова, идентификаторы, сведения сессии | Если остается в журнале сервера, становится признаком действий |
В анонимности «содержимое связи не читается» и «следов связи не остается» — не одно и то же.
Даже при шифровании содержимого может оставаться окружающая информация связи. Поэтому для анонимности нужно думать не только о шифровании, но и о том, где и какие журналы могут оставаться.
Итоги
Журналы связи — это записи, связанные со связью.
На Web-сайтах, в приложениях, DNS, у операторов связи, на роутерах, файрволах, облачных платформах могут оставаться разные сведения о связи.
Типичные сведения: время доступа, IP-адрес источника, URL, User-Agent, Cookie, Referer, DNS-запросы, назначение, объем связи, история аутентификации, история операций.
Журналы используются для устранения сбоев, безопасности, расследования злоупотреблений, улучшения сервиса. Поэтому сами журналы важны для безопасной эксплуатации интернет-сервисов.
С другой стороны, с точки зрения анонимности журналы могут стать признаками отслеживания. Даже если содержимое связи зашифровано, источник, назначение, время, DNS-запросы, Cookie, User-Agent могут записываться в другой форме.
Понимание журналов связи помогает разложить, что может записываться в интернете. А при размышлении об анонимности оно помогает смотреть не только на то, видно ли содержимое связи, но и на то, где может оставаться окружающая информация связи.