Сетевая анонимность: общие вопросы
Вычеркнутые вопросы перенесены в FAQ
Я хочу настроить своё рабочее место для возможности анонимной работы в сети. Какие риски для анонимности существуют и с чего мне начать?
Прежде всего, заметим, что анонимность немыслима без безопасности, которая отвечает за корректность и надёжность работы всех систем. Создание и настройка сколь-нибудь надёжного в плане анонимности рабочего места требует, как минимум, хорошего знакомства с устройством операционной системы (ОС), с основами сетевых технологий и с основными положениями информационной безопасности: именно поэтому настоятельно рекомендуется начинать разбираться с анонимностью только после получения хотя бы общих (схематических) представлений об указанных технологиях. Попытка описать проблему анонимности в нескольких абзацах или даже страницах заведомо упустит массу важных тонкостей, но мы всё же попытаемся дать краткое описание, которое могло бы послужить подспорьем при настоящем серьёзном изучении проблемы.
Проблема анонимности возникает при обработке служебной и целевой информации, покидающей компьютер, которая, если представлять схематически, проходит через систему следующим образом: прикладная программа -> ОС -> сеть. Каждый из этих уровней обработки информации (прикладной, системный (ОС) и сетевой) может влиять на анонимность пользователя. В силу сложившихся обстоятельств, в плане безошибочности и корректности реализации прикладной уровень наименее надёжен из всех, системный – существенно надёжнее, и самый надёжный – это сетевой.
Специалисты различают программные уязвимости по тому, на каком уровне они работают: прикладном, системном или сетевом. Наиболее часто используются следующие термины: уязвимость вида local root, remote root и 0day. Под local root понимается уязвимость, позволяющая получить самые высокие права (системного уровня) программе, выполняемой на этом же компьютере, под remote root понимается получение тех же прав по сети, программой, выполняемой удалённо на другом компьютере. Какую-либо уязвимость, уже кем-то открытую, но ещё не известную публично, называют 0day. Уязвимости вида local root в надёжных ОС типа Linux/BSD обнаруживают от силы несколько раз в год, remote root – не каждый год [в OpenBSD – 2 раза за всю историю её более чем десятилетнего существования], а фатальные ошибки в браузерах, позволяющие выполнить любой код от имени его запустившего пользователя, находят едва ли не ежедневно.
В силу того, что разные уровни по степени защищённости отличаются очень значительно, контроль за анонимностью работы с данными предпочтительнее возлагать на системный уровень, т.е. на средства самой ОС, а не прикладных программ. Перейдём теперь к рассмотрению того, что происходит внутри каждого уровня и какие угрозы для анонимности он в себе таит.
Прикладные программы помимо целевой информации отправляют массу служебных данных в сеть, начиная от списка своих опций и настроек, и кончая проверками обновлений софта или даже синхронизацией своего содержимого с какими-то хранилищами в сети. Исправить такое поведение иногда частично удаётся с помощью соответствующих настроек, предусмотренных рассматриваемой программой, или же с помощью дополнительных плагинов. Однако, приемлемо (но не полностью) решить эту проблему можно перелагая контроль на системный уровень: запускать программы в специальном окружении, на выделенной ОС в виртуальной или физически выделенной машине. Такой подход может существенно уменьшить ущерб, в том числе, и от передачи каких-то общесистемных файлов и данных, которые программа может попытаться отослать в сеть, став подконтрольной из-за уязвимости злоумышленнику.
На системном уровне возможны критические утечки служебных передаваемых данных из-за неверной настройки или несовместимости того, как работают отдельные прикладные программы и сама ОС. Как правило, эта проблема может быть полностью решена правильной настройкой firewall'а.
Сетевой уровень – один из самых сложных в силу многообразия связанных с ним проблем, но, к счастью, пользователь почти всегда может от него абстрагироваться в рамках своей модели угрозы. Как правило, рассматривают анонимные системы двух типов защиты: систему Tor, которая предоставляет доступ к ресурсам интернета в режиме реального времени без покрывающего трафика, и систему Freenet, являющуюся анонимной файлообменной сетью с покрывающим трафиком. Ограничения на анонимность каждой из этих сетей – предмет отдельного обсуждения, и пока мы от него абстрагируемся.
Стоит заметить, что прикладной и системный уровни могут быть программно изолированы друг от друга. Каждая прикладная программа (каждый процесс), как правило работает от отдельного пользователя, и имеет соответствующие ему права и привелегии в системе. Если уязвимости вида local root в системе нет, то такая программа никак не может получить прав больше, чем права запустившего её пользователя. Поскольку запуск программ от отдельных непривелегированных пользователей повышает защищённость системы, этим настоятельно рекомендуется пользоваться.
Вышеперечисленные проблемы, возникающие при построении анонимизирующих систем, могут быть решены исключительно в доверяемой среде – той, в которой можно прозрачно проконтролировать все стадии работы программ с данными. К примерам доверяемых сред можно отнести такие популярные ОС как Linux или *BSD. Поведение Windows настолько непрозрачно и плохо управляемо при работе с данными (например, отсутствует функциональный и надёжный firewall), доверие к производителям софта требуется настолько полное, а список всевозможных утечек столь велик, что попытка её анонимной настройки для специалиста средней руки едва ли подъёмная задача. Если говорить прямо, то понятия анонимности/безопасности и Windows с нашей точки зрения попросту несовместимы.
Равно как и безопасность, анонимность – это не свершившийся факт, а непрерывный процесс. Степень надёжности анонимной настройки можно постоянно повышать в соответствии с ростом своих знаний и кваификации, реализовывая защиту от всё большего числа возможных способов деанонимизации. В качестве наглядной демонстрации вышеизложенного подхода, рассмотрим постепенное повышение защиты при анонимном серфинге сети посредством Tor, показывая на каждом шаге включение иммунитета от тех новых угроз, которые он начинает учитывать.
- Установка плагина torbutton (tb) на firefox (ff), который запускается от обычного пользователя (полностью прикладной уровень). Это базовая защита от деанонимизации, в том числе и от утечек служебных данных. ff и tb здесь полагаются неограниченно доверяемыми программами – уязвимость в них потенциально полностью деанонимизирует пользователя. Уязвимые tb и ff могут получить полный доступ как к системным файлам, так и всем файлам из неанонимного профиля пользователя (из домашней директории).
- Запуск связки ff+tb под отдельным пользователем tor_user и отдельным X-сервером, с последующей блокировкой на уровне системного firewall'а всех соединений, инициируемых tor_user'ом, идущих не в сеть Tor (уже системный уровень защиты). Этот уровень защиты уже не позволяет уязвимым ff и tb что-либо послать в сеть в обход Tor, и они уже не могут получить без local root уязвимости доступа к неанонимному профилю пользователя. Однако, они ещё могут получить доступ к системным настройкам и файлам, часть которых потенциально может содержать информацию, достаточную для деанонимизации, т.к. эти же системные настройки используются и неанонимным профилем под другим пользователем.
- Запуск связки ff+tb при тех же условиях, что и в предыдущем пункте, но теперь уже в виртуальной машине, причём сам Tor-клиент запускается на основной (host) ОС, и она же отвечает за перенаправление всего трафика от виртуальной машины в сеть Tor. При такой защите tb или ff не могут получить доступа ни к актуальным сетевым настройкам на host ОС, ни к актуальным системным файлам на ней. Для того, чтобы добраться до них, требуется иметь одновременно уязвимость класса local root в гостевой ОС с уязвимостью в виртуальной машине.
- Запуск связки ff+tb на физически выделенной (не виртуальной) машине, которая используется только для работы в Tor и не содрежит никакой информации, позволяющей связать анонимную и неанонимную личность пользователя. Трафик от этой машины направляется в сеть Tor внешним рутером, и он единственный, кто знает сетевые настройки реальной сети провайдера. Неанонимный профиль пользователя находится на отдельной машине, трафик с которой так же пропускает через себя рутер (сетевой уровень защиты). Для того, чтобы уязвимые ff или tb смогли что-то узнать об актуальных настройках сети, требуется уязвимость класса remote root либо против рутера, либо против машины с неанонимным профилем пользователя (на последней содержатся настройки, позволяющие ходить в сеть не через Tor).
Небольшое пояснение: выше под уязвимостью понимаются не только программные ошибки в общепринятом смысле, но и какие-либо другие ошибки в настройке, приводящие к деанонимизации.