Централизованные средства «анонимности» Сразу отмечу главное: никакое централизованное решение высокий уровень анонимности обеспечить не может, так как необходимо доверять центральному узлу. Мы не будем рассуждать об организационных, политических и бюрократических сложностях на пути раскрытия анонимности. Возможно, VPN-сервер в Панаме действительно более безопасен, чем такой же сервер в Испании. А возможно — нет. Также как и не будем говорить про цепочки узлов, так как их надежность с трудом поддаётся оценке. С одной стороны, в виду организационных сложностей, риск раскрытия ниже, а с другой — мы должны быть достаточно уверены в каждом узле. Перейдём к конкретике. Прокси-серверы: http и SOCKSx Рассмотрим подробнее http-заголовки в http-прокси. HTTP-заголовок – это строка в http-сообщении с некоторыми параметрами вида: «Имя: Значение». Заголовков существуют достаточно много, ими при взаимодействии обмениваются между собой клиенты и серверы. Например, следующее поле: «Date: Sat, 12 Dec 2012 15:41:52 GMT» возвращает от сервера клиенту текущее время и дату. Один из таких заголовков: X-Forwarded-For, по сути, является стандартом для получения сервером оригинального адреса клиента при доступе к серверу через HTTP-прокси. И вот в этом заголовке, если его не фильтровать, передаётся вся цепочка прокси-серверов от начала до конца, например: X-Forwarded-For: client1, proxy1, proxy2 … X-Forwarded-For: 169.78.138.66, 169.78.64.103... Также к заголовкам, разглашающим деанонимизирующую информацию, относятся: HTTP_VIA, HTTP_FORWARDED и др. HTTP-прокси-серверы, которые скрывают ip-адрес клиента, называют анонимными. Такие серверы подразделяются на виды, деление это весьма условно, но, тем не менее, существуют: Простые анонимные прокси (anonymous). Эти серверы не скрывают факта использования http-прокси, однако они подменяют ip-адрес клиента на свой. Элитные анонимные (high anonymous/elite). Такие серверы ещё скрывают и сам факт использования http-прокси. SOCKS-прокси, как вы помните, никаких заголовков не передают. Рассмотрим разницу между SOCKS 4, 4a и 5. Существуют разные версии SOCKS: SOCKS4. Такие серверы требуют от клиента, например, веб-браузера, только ip-адрес ресурса, к которому он обращается (адресата). Следовательно, клиенту надо как-то этот ip-адрес узнать, а узнать его клиент может только прямым DNS-запросом в обход прокси. Это может привести к деанонимизации, так как интернет-провайдер может видеть DNS-запросы в открытом виде, данная уязвимость называется DNS-leaks, она описана далее, во второй части статьи. SOCKS4a. Является расширением SOCKS4. Главное отличие состоит в том, что SOCKS4a-сервер принимает от клиента только DNS-имя адресата, а не его ip-адрес. Это бывает необходимо, когда клиент не может самостоятельно определить ip-адрес адресата по DNS-имени. SOCKS5. Также является расширением SOCKS4. Сервер SOCKS5 поддерживает UDP, IPv6, авторизацию и пр. И хотя SOCKS5-прокси могут принимать от клиента как ip-адрес, так и DNS-имя целевого ресурса, некоторые приложения, поддерживающие SOCKS5, могут сами получать ip-адрес адресата до того, как обратиться к SOCKS5-прокси, что также может привести к утечке DNS-запросов. SSH. Сравнение SSH и VPN SSH туннель — это туннель, создаваемый посредством SSH-соединения и используемый для шифрования передаваемых данных. Как гласит одноимённая статья в Википедии: «SSH (англ. Secure SHell — «безопасная оболочка») — сетевой протокол прикладного уровня, позволяющий производить удалённое управление операционной системой и туннелирование TCP-соединений (например, для передачи файлов)». При использовании SSH-туннеля открытый траффик какого-либо протокола шифруется на одном конце SSH-соединения, клиенте, и расшифровывается на другом, SSH-сервере. Схема работы SSH-туннеля показана на рисунке: Протокол SSH поддерживает несколько вариантов работы: В первом варианте туннелируемое приложение должно иметь настройки HTTP/SOCKS-прокси для направления траффика через локальный прокси-сервер в SSH-туннель. Если таких настроек нет, то можно использовать программы-соксификаторы, которые отправляют траффик через прокси-сервер. Во втором случае можно организовать практически полноценное VPN-соединение и обойтись без настройки SOCKS. Начиная с версии 4.3, открытая реализация SSH, OpenSSH, может использовать туннельные сетевые интерфейсы 2-го и 3-го уровней модели OSI, то есть организовывать аналоги VPN-соединений. Сравним VPN и SSH с точки зрения анонимности. Цели Исторически VPN и SSH предназначались для разных целей, что и объясняет их плюсы и минусы. VPN призван обеспечить защищённый удалённый доступ к ресурсам корпоративной сети. Как только компьютер подключается к VPN-серверу, он становится частью «локальной» сети, а, следовательно, может получать все её сервисы: общие ресурсы, локальный сервис VoIP, также становятся возможными NetBios-, UDP-, и широковещательные запросы, единые VPN-политики и т.д. Через VPN в большинстве случаев отправляется траффик всей операционной системы и приложений. SSH изначально предназначался для защищенного удаленного управления устройствами. SSH-соединение — это соединение с «конкретным устройством», а не с «сетью». Хотя мастера SSH могут делать с помощью него много крутых вещей. Безопасность Протоколы VPN и SSH достаточно безопасны за исключением разве что PPTP. Большинство возможных атак сводится к Ссылка доступна только зарегистрированным пользователям и подмене сертификатов или ключей, однако это проблема аутентификации и внимательности пользователя. Удобство Удобство — понятие условное и субъективное, оно зависит от ваших целей и опыта. К VPN-серверу легко подключиться, но для новичков может быть непросто его настроить. Тогда как SSH-сервер более прост в настройке, но, например, вручную настраивать SSH-туннель для каждого приложения кому-то может показаться не совсем удобным. Скорость Скорость каждого средства зависит от конкретной реализации и используемых протоколов. Если сравнивать SSH и OpenVPN, поделюсь уже проведённым Ссылка доступна только зарегистрированным пользователям: network — 96.5 Mbps. network/SSH — 94.2 Mbps. network/VPN — 32.4 Mbps. Подводя итог, стоит отметить, что VPN-серверы более популярны, чем SSH. В интернете существует много коммерческих VPN-провайдеров. Однако и SSH-туннели тоже продаются в избытке на специализированных форумах. Что разворачивать на своём сервере в Антарктиде — дело ваше. Полезный совет Иногда бывает ситуация, когда VPN-соединение по каким-либо причинам может разрываться. Если в случае с прокси-сервером, сетевое взаимодействие прекращается, то в случае с VPN траффик продолжит идти напрямую. Наиболее надёжным вариантом для недопущения этого является использование таблицы маршрутизации, где в качестве основного шлюза по умолчанию указан только шлюз VPN-сервера. Делается это просто: 1. Удаляем любые маршруты по умолчанию: 2. Разрешаем доступ в интернет только к адресу VPN-сервера: 3. Добавляем маршрут по умолчанию со шлюзом – VPN-сервером: Где: 192.168.0.1 — шлюз интернета, 55.55.55.55 — VPN-шлюз. Еще одним способом является установка в свойствах открытого интернет-соединения несуществующих DNS-серверов, например, 127.0.0.1. В таком случае веб-сёрфинг и другие подобные задачи становятся невозможными без подключения к VPN-серверу. Также существуют специальные программы, например, VPN-watcher, которые для заданных приложений проверяет VPN-соединение несколько раз в секунду и приостанавливает их работу, если VPN-соединение обрывается. Спасибо за еще один способ Ссылка доступна только зарегистрированным пользователям: Еще один способ обезопасить себя от разрыва vpn — это настройка файрвола. Подойдет в том числе и стандартный windows firewall. Есть Ссылка доступна только зарегистрированным пользователям. Причем блокирующие правила можно не создавать, а ограничиться 10-м пунктом. Для отдельных программ (например для openvpn) можно отдельно создать разрешающие правила, чтобы эти программы работали даже если впн не подключен. Спасибо за еще один способ Ссылка доступна только зарегистрированным пользователям: Я думаю, если строить защищённую конструкцию, то следует просто выделять две сессии — защищённую и не защищённую. Лидера сессии положить в cgroups, откуда не-vpn интерфейс просто не доступен для использования — в этом случае информация будет отправляться только через этот интерфейс. p>
