VPN: зачем и как скрывать свой IP и шифровать трафик. Что знает провайдер о пользователе? Удаленный доступ VPN

Мы рассказали нашим читателям о принципах работы VPN и показали на примере недорогих сервисов VPN услуг, как и для чего использовать VPN-туннели.

Сегодня мы хотим еще раз затронуть тему VPN-услуг, тем более, что спрос на эти услуги растет с каждым днем, так как усиливается государственное регулирование сети Интернет в России и других странах СНГ, пользователи сталкиваются с целым рядом ограничений в Интернете, а также ситуация с информационной безопасностью в сети ухудшается с каждым днем.

Выбирая поставщика VPN услуг мы нашли достаточно качественный сервис: TheSafety.US

Сразу скажем, что цены на услуги VPN у TheSafety.US не из самых низких, подписка стоит где-то от 30 долларов за месяц, но зато это компенсируется высоким качеством предоставляемых услуг и разнообразием пакетов и подписок. Итак, приступим к тестированию TheSafety.US и оценим данный сервис VPN на практике.

Для других операционных систем см. настройки :

Что сразу мне понравилось? Что можно выбрать сервер в удобной для Вас стране. Обычный VPN, Double VPN и Offshore VPN доступен для Вас в 20 странах: США, Канада, Германия, Великобритания (Англия), Нидерланды, Италия, Украина, Франция, Испания, Бельгия, Польша, Чехия, Португалия, Швейцария, Ирландия, Литва, Финляндия, Люксембург, офшорный VPN в Панаме и Малайзии. Можно самому выбрать различные страны и направления, включая VPN в офшорных странах (Offshore VPN) - это высочайший уровень безопасности, так как в этих странах отсутствует жесткий контроль со стороны государства.

Когда нужно выбрать именно конкретную страну VPN сервера? Когда перед Вами стоит задача не просто скрыть свой IP-адрес, а показать, что он именно из Германии, США или Польши, например. Это нужно для доступа к таким Интернет-ресурсам, владельцы которых ставят фильтры для посетителей из определенных стран.

В нашей статье мы уже ознакомились, как работает технология VPN. Расскажем, как работает услуга Double VPN.

Технология Double VPN - цепочка из двух серверов с отличием входного и выходного IP адресов. В данном случае вы подключаетесь к IP1 первого сервера с шифрованием всех данных, дальше ваш трафик шифруется во второй раз и посылается на IP2 второго сервера. В итоге Вы будете находиться в Интернете с IP3. Данная технология помогает обеспечить высокоэффективную защиту, потому что весь ваш трафик будет дважды шифроваться и пройдет через разные страны.

Например, я тестировала цепочку Германия - Чехия , зашифрованный трафик сначала прошел через сервер в Германии, затем через сервер в Чехии, и только затем поступил на внешние ресурсы сети Интернет. Это позволило обеспечить очень сильную безопасность, как при цепочке из соксов, плюс двойное шифрование передаваемых данных. Таким образом, мой внешний IP не будет знать даже первый сервер, ни тем более мой Интернет провайдер.

На скриншоте проверка моего IP, выполненная на сайте 2ip.ru , показывает IP адрес в Праге.

Если загрузить поисковик yandex.ru , то он нам выдаст главную страницу для Праги:

Как мы знаем, что в последнее время Интернет-провайдеры "пишут" весь Интернет-трафик пользователей и хранят его определенное время. Такое положение вещей существует в России, Белоруссии, Китае и др. странах с сильным государственным регулированием Интернета.

Т.е. определенные организации и должностные лица будут в курсе какие сайты Вы посещаете, какую информацию получаете и передаете в сети Интернет. Это не «пустые страшилки», давайте проверим на практике, что же записывается в логи провайдеров после нашего визита в сеть Интернет.

Для этого эксперимента воспользуемся анализаторами трафика (снифферами) или Wireshark , которые являются бесплатным свободным ПО.

Я для своих экспериментов использовала программу Packetyzer. Итак, что мы видим, когда работаем в Интернете под своим IP адресом, без VPN:

На скриншоте выше видно, что я смотрела погоду по адресу: pogoda.tut.by (это выделено на рис. маркером).

А на следующем скриншоте видно вообще, какие я сайты посещала в это время:

А теперь используем VPN сервис от TheSafety.US , попробуем проанализировать трафик сниффером Packetyzer и видим, что весь трафик зашифрован стойким алгоритмом, посмотреть какие сайты посещались невозможно:

Кстати, при , тоже шифруется весь трафик, см. скриншоты ниже:

Также на серверах TheSafety.US логи не пишутся и подключение происходит к IP адресу, а не к имени домена.

Для еще большей анонимности на серверах TheSafety.US используется принудительное изменение параметра TTL.

TTL - time to live или время жизни отправленного пакета. Для ОС семейства Windows стандартное значение TTL = 128, для Unix TTL = 64. Отправленному пакету присваивается значение TTL, и это значение уменьшается на единицу каждым хостом на пути его следования (например, при открытии определенного сайта, Ваш пакет-запрос проходит через несколько хостов, до тех пор пока не дойдет до сервера, на котором расположен открываемый сайт). Когда значение TTL отправленного пакета становится равно 0, то данный пакет исчезает. То есть, можно сказать, что с помощью значения TTL передаваемого пакета можно узнать, сколько хостов прошел пакет. Значит, косвенно можно выявить, за сколько хостов находится именно Ваш компьютер. Сервера TheSafety.US принудительно изменяют это значение на стандартное. Это можно проверить с помощью стандартных команд ping и tracert. См. ниже скриншоты выполнения этих команд:

Первое, что приходит в голову при упоминании VPN, - это анонимность и защищенность передаваемых данных. Так ли это на самом деле? Давай разберемся.

Когда необходимо получить доступ к корпоративной сети, безопасно передать важную информацию по открытым каналам связи, скрыть свой трафик от бдительного взора провайдера, скрыть свое реальное местоположение при проведении каких-либо не совсем законных (или совсем не законных) действий, обычно прибегают к использованию VPN. Но стоит ли слепо полагаться на VPN, ставя на кон безопасность своих данных и собственную безопасность? Однозначно - нет. Почему? Давай разбираться.

WARNING

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

VPN нам нужен!

Виртуальная частная сеть, или просто VPN, - обобщенное название технологий, позволяющих обеспечить одно или несколько сетевых соединений (логическую сеть) поверх другой сети, например интернета. Несмотря на то что коммуникации могут быть реализованы через публичные сети с неизвестным уровнем доверия, уровень доверия к построенной логической сети не зависит от уровня доверия к базовым сетям благодаря использованию средств криптографии (шифрования, аутентификации, инфраструктуры открытых ключей, средств для защиты от повторов и изменений передаваемых по логической сети сообщений). Как видишь, в теории все радужно и безоблачно, на практике же все несколько иначе. В этой статье мы рассмотрим два основных момента, которые обязательно нужно принимать во внимание, пользуясь VPN.

Утечка VPN-трафика

Первая проблема, связанная с виртуальными частными сетями, - это утечка трафика. То есть тот трафик, который должен быть передан через VPN-соединение в зашифрованном виде, попадает в сеть в открытом виде. Данный сценарий не является следствием ошибки в VPN-сервере или клиенте. Здесь все гораздо интереснее. Самый простой вариант - внезапный разрыв VPN-соединения. Ты решил просканировать хост или подсеть с помощью Nmap, запустил сканер, отошел на несколько минут от монитора, и тут VPN-соединение внезапно отвалилось. Но сканер при этом продолжает работать. И сканирование идет уже с твоего адреса. Вот такая неприятная ситуация. Но есть сценарии и интересней. Например, утечка VPN-трафика широко распространена в сетях (на хостах), поддерживающих обе версии протокола IP (так называемые dual-stacked сети/хосты).

Корень зла

Сосуществование двух протоколов - IPv4 и IPv6 - имеет множество интересных и тонких аспектов, которые могут приводить к неожиданным последствиям. Несмотря на то что шестая версия протокола IP не имеет обратной совместимости с четвертой версией, обе эти версии как бы «склеены» вместе системой доменных имен (DNS). Чтобы было понятней, о чем идет речь, давай рассмотрим простенький пример. Например, возьмем сайт (скажем, www.example.com), который имеет поддержку IPv4 и IPv6. Соответствующее ему доменное имя (www.example.com в нашем случае) будет содержать DNS-записи обоих типов: А и АААА. Каждая А-запись содержит один IPv4-адрес, а каждая АААА-запись содержит один IPv6-адрес. Причем для одного доменного имени может быть по несколько записей обоих типов. Таким образом, когда приложение, поддерживающее оба протокола, захочет взаимодействовать с сайтом, оно может запросить любой из доступных адресов. Предпочитаемое семейство адресов (IPv4 или IPv6) и конечный адрес, который будет использоваться приложением (учитывая, что их существует несколько для четвертой и шестой версий), будет отличаться от одной реализации протокола к другой.

Это сосуществование протоколов означает, что, когда клиент, поддерживающий оба стека, собирается взаимодействовать с другой системой, наличие А- и АААА-записей будет оказывать влияние на то, какой протокол будет использоваться для связи с этой системой.

VPN и двойной стек протоколов

Многие реализации VPN не поддерживают или, что еще хуже, полностью игнорируют протокол IPv6. При установке соединения программное обеспечение VPN берет на себя заботу по транспортировке IPv4-трафика - добавляет дефолтный маршрут для IPv4-пакетов, обеспечивая тем самым, чтобы весь IPv4-трафик отправлялся через VPN-соединение (вместо того чтобы он отправлялся в открытом виде через локальный роутер). Однако, если IPv6 не поддерживается (или полностью игнорируется), каждый пакет, в заголовке которого указан IPv6-адрес получателя, будет отправлен в открытом виде через локальный IPv6-роутер.

Основная причина проблемы кроется в том, что, хотя IPv4 и IPv6 - два разных протокола, несовместимых друг с другом, они тесно используются в системе доменных имен. Таким образом, для системы, поддерживающей оба стека протоколов, невозможно обеспечить безопасность соединения с другой системой, не обеспечив безопасность обоих протоколов (IPv6 и IPv4).

Легитимный сценарий утечки VPN-трафика

Рассмотрим хост, который поддерживает оба стека протоколов, использует VPN-клиент (работающий только с IPv4-трафиком) для подключения к VPN-серверу и подключен к dual-stacked сети. Если какому-то приложению на хосте нужно взаимодействовать с dual-stacked узлом, клиент обычно запрашивает и А-, и АААА-DNS-записи. Так как хост поддерживает оба протокола, а удаленный узел будет иметь оба типа DNS-записей (А и АААА), то одним из вероятных вариантов развития событий будет использование для связи между ними IPv6-протокола. А так как VPN-клиент не поддерживает шестую версию протокола, то IPv6-трафик не будет отправляться через VPN-соединение, а будет отправляться в открытом виде через локальную сеть.

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

Преднамеренно вызываем утечку VPN-трафика

Атакующий может преднамеренно вызвать подключение по протоколу IPv6 на компьютере жертвы, посылая поддельные ICMPv6 Router Advertisement сообщения. Подобные пакеты можно рассылать при помощи таких утилит, как rtadvd , SI6 Networks" IPv6 Toolkit или THC-IPv6 . Как только соединение по протоколу IPv6 установлено, «общение» с системой, поддерживающей оба стека протоколов, может вылиться, как рассмотрено выше, в утечку VPN-трафика.

И хотя данная атака может быть достаточно плодотворной (из-за растущего числа сайтов, поддерживающих IPv6), она приведет к утечке трафика, только когда получатель поддерживает обе версии протокола IP. Однако для злоумышленника не составит труда вызвать утечки трафика и для любого получателя (dual-stacked или нет). Рассылая поддельные Router Advertisement сообщения, содержащие соответствующую RDNSS-опцию, атакующий может прикинуться локальным рекурсивным DNS-сервером, затем провести DNS-спуфинг, чтобы осуществить атаку man-in-the-middle и перехватить соответствующий трафик. Как и в предыдущем случае, такие инструменты, как SI6-Toolkit и THC-IPv6, могут легко провернуть такой трюк.

Совсем не дело, если трафик, не предназначенный для чужих глаз, попадет в открытом виде в сеть. Как же обезопаситься в таких ситуациях? Вот несколько полезных рецептов:

1. Если VPN-клиент сконфигурирован таким образом, чтобы отправлять весь IPv4-трафик через VPN-соединение, то:

• если IPv6 VPN-клиентом не поддерживается - отключить поддержку шестой версии протокола IP на всех сетевых интерфейсах. Таким образом, у приложений, запущенных на компьютере, не будет другого выбора, как использовать IPv4;
• если IPv6 поддерживается - убедиться, что весь IPv6-трафик также отправляется через VPN.

1. Чтобы избежать утечки трафика, в случае если VPN-соединение внезапно отвалится и все пакеты будут отправляться через default gateway, можно:
2. принудительно заставить весь трафик идти через VPN route delete 0.0.0.0 192.168.1.1 // удаляем default gateway route add 83.170.76.128 mask 255.255.255.255 192.168.1.1 metric 1

• воспользоваться утилитой VPNetMon , которая отслеживает состояние VPN-соединения и, как только оно пропадает, мгновенно завершает указанные пользователем приложения (например, торрент-клиенты, веб-браузеры, сканеры);
• или утилитой VPNCheck , которая в зависимости от выбора пользователя может либо полностью отключить сетевую карту, либо просто завершить указанные приложения.

1. Проверить, уязвима ли твоя машина к утечке DNS-трафика, можно на сайте , после чего применить советы, как пофиксить утечку, описанные .

Расшифровка VPN-трафика

Даже если ты все настроил правильно и твой VPN-трафик не утекает в сеть в открытом виде - это еще не повод расслабляться. Все дело в том, что если кто-то перехватит зашифрованные данные, передаваемые через VPN-соединение, то он сможет их расшифровать. Причем на это никак не влияет, сложный у тебя пароль или простой. Если ты используешь VPN-соединение на базе протокола PPTP, то со стопроцентной уверенностью можно сказать, что весь перехваченный зашифрованный трафик можно расшифровать.

Ахиллесова пята

При VPN-соединениях на базе протокола PPTP (Point-to-Point Tunneling Protocol) аутентификация пользователей проводится по протоколу MS-CHAPv2, разработанному компанией Microsoft. Несмотря на то что MS-CHAPv2 устарел и очень часто становится предметом критики, его продолжают активно использовать. Чтобы окончательно отправить его на свалку истории, за дело взялся известный исследователь Мокси Марлинспайк, который на двадцатой конференции DEF CON отчитался, что поставленная цель достигнута - протокол взломан. Надо сказать, что безопасностью этого протокола озадачивались и ранее, но столь долгое использование MS-CHAPv2, возможно, связано с тем, что многие исследователи концентрировались только на его уязвимости к атакам по словарю. Ограниченность исследований и широкое число поддерживаемых клиентов, встроенная поддержка операционными системами - все это обеспечило протоколу MS-CHAPv2 широкое распространение. Для нас же проблема кроется в том, что MS-CHAPv2 применяется в протоколе PPTP, который используется многими VPN-сервисами (например, такими крупными, как анонимный VPN-сервис IPredator и The Pirate Bay’s VPN).

Если обратиться к истории, то уже в 1999 году в своем исследовании протокола PPTP Брюс Шнайер указал, что «Microsoft улучшил PPTP, исправив основные изъяны безопасности. Однако фундаментальная слабость аутентификации и шифрования протокола в том, что он безопасен настолько, насколько безопасен выбранный пользователем пароль». Это почему-то заставило провайдеров поверить, что ничего страшного в PPTP нет и если требовать от пользователя придумывать сложные пароли, то передаваемые данные будут в безопасности. Сервис Riseup.net настолько проникся этой идеей, что решил самостоятельно генерировать для пользователей пароли длиной в 21 символ, не давая им возможности установить свои. Но даже такая жесткая мера не спасает от расшифровки трафика. Чтобы понять почему, давай поближе познакомимся с протоколом MS-CHAPv2 и посмотрим, как же Мокси Марлинспайк сумел его взломать.

Протокол MS-CHAPv2

Как уже было сказано, MSCHAPv2 применяется для аутентификации пользователей. Происходит она в несколько этапов:

• клиент посылает запрос на аутентификацию серверу, открыто передавая свой login;
• сервер возвращает клиенту 16-байтовый случайный отклик (Authenticator Challenge);
• клиент генерирует 16-байтовый PAC (Peer Authenticator Challenge - равный отклик аутентификации);
• клиент объединяет PAC, отклик сервера и свое user name в одну строку;
• с полученной строки снимается 8-байтовый хеш по алгоритму SHA-1 и посылается серверу;
• сервер извлекает из своей базы хеш данного клиента и расшифровывает его ответ;
• если результат расшифровки совпадет с исходным откликом, все ОK, и наоборот;
• впоследствии сервер берет PAC клиента и на основе хеша генерирует 20-байтовый AR (Authenticator Response - аутентификационный ответ), передавая его клиенту;
• клиент проделывает ту же самую операцию и сравнивает полученный AR с ответом сервера;
• если все совпадает, клиент аутентифицируется сервером. На рисунке представлена наглядная схема работы протокола.

На первый взгляд протокол кажется излишне сложным - куча хешей, шифрование, случайные challenge. На самом деле все не так уж и сложно. Если присмотреться внимательней, то можно заметить, что во всем протоколе остается неизвестной только одна вещь - MD4-хеш пароля пользователя, на основании которого строятся три DES-ключа. Остальные же параметры либо передаются в открытом виде, либо могут быть получены из того, что передается в открытом виде.

Так как почти все параметры известны, то мы можем их не рассматривать, а остановить свое пристальное внимание на том, что неизвестно, и выяснить, что это нам дает.

Итак, что мы имеем: неизвестный пароль, неизвестный MD4-хеш этого пароля, известный открытый текст и известный шифртекст. При более детальном рассмотрении можно заметить, что пароль пользователя нам не важен, а важен его хеш, так как на сервере проверяется именно он. Таким образом, для успешной аутентификации от имени пользователя, а также для расшифровки его трафика нам необходимо знать всего лишь хеш его пароля.

Имея на руках перехваченный трафик, можно попробовать его расшифровать. Есть несколько инструментов (например, asleap), которые позволяют подобрать пароль пользователя через атаку по словарю. Недостаток этих инструментов в том, что они не дают стопроцентной гарантии результата, а успех напрямую зависит от выбранного словаря. Подбирать же пароль простым брутфорсом тоже не очень эффективно - например, в случае с PPTP VPN сервисом riseup.net, который принудительно устанавливает пароли длиной в 21 символ, придется перебирать 96 вариантов символа для каждого из 21 символов. Это в результате дает 96^21 вариантов, что чуть больше, чем 2^138. Иными словами, надо подобрать 138-битный ключ. В ситуации же, когда длина пароля неизвестна, имеет смысл подбирать MD4-хеш пароля. Учитывая, что его длина равна 128 бит, получаем 2^128 вариантов - на данный момент это просто нереально вычислить.

Разделяй и властвуй

MD4-хеш пароля используется в качестве входных данных для трех DES-операций. DES-ключи имеют длину 7 байт, так что каждая DES-операция использует 7-байтовый фрагмент MD4-хеша. Все это оставляет возможность для классической атаки divide and conquer. Вместо того чтобы полностью брутить MD4-хеш (а это, как ты помнишь, 2^128 вариантов), мы можем подбирать его по частям в 7 байт. Так как используются три DES-операции и каждая DES-операция абсолютно независима от других, это дает общую сложность подбора, равную 2^56 + 2^56 + 2^56, или 2^57.59. Это уже значительно лучше, чем 2^138 и 2^128, но все еще слишком большое число вариантов. Хотя, как ты мог заметить, в эти вычисления закралась ошибка. В алгоритме используются три DES-ключа, каждый размером в 7 байт, то есть всего 21 байт. Эти ключи берутся из MD4-хеша пароля, длина которого всего 16 байт.

То есть не хватает 5 байт для построения третьего DES-ключа. В Microsoft решили эту задачу просто, тупо заполнив недостающие байты нулями и фактически сведя эффективность третьего ключа к двум байтам.

Так как третий ключ имеет эффективную длину всего лишь два байта, то есть 2^16 вариантов, его подбор занимает считаные секунды, доказывая эффективность атаки divide and conquer. Итак, можно считать, что последние два байта хеша известны, остается подобрать оставшиеся 14. Также разделив их на две части по 7 байт, имеем общее число вариантов для перебора, равное 2^56 + 2^56 = 2^57. Все еще слишком много, но уже значительно лучше. Обрати внимание, что оставшиеся DES-операции шифруют один и тот же текст, только при помощи разных ключей. Можно записать алгоритм перебора следующим образом:

Но так как текст шифруется один и тот же, то правильнее сделать вот так:

То есть получается 2^56 вариантов ключей для перебора. А это значит, что безопасность MS-CHAPv2 может быть сведена к стойкости одного DES-шифрования.

Взлом DES

Теперь, когда диапазон подбора ключа известен, для успешного завершения атаки дело остается только за вычислительными мощностями. В 1998 году Electronic Frontier Foundation построила машину Deep Crack, которая стоила 250 тысяч долларов и позволяла взламывать DES-ключ в среднем за четыре с половиной дня. В настоящее время Pico Computing, специализирующаяся на построении FPGA-оборудования для криптографических приложений, построила FPGA-устройство (DES cracking box), которое реализует DES как конвейер с одной DES-операцией на каждый тактовый цикл. Обладая 40 ядрами по 450 МГц, оно позволяет перебирать 18 миллиардов ключей в секунду. Обладая такой скоростью перебора, DES cracking box в худшем случае взламывает ключ DES за 23 часа, а в среднем за полдня. Данная чудо-машина доступна через коммерческий веб-сервис loudcracker.com . Так что теперь можно взломать любой MS-CHAPv2 handshake меньше, чем за день. А имея на руках хеш пароля, можно аутентифицироваться от имени этого пользователя на VPN-сервисе или просто расшифровывать его трафик.

Для автоматизации работы с сервисом и обработки перехваченного трафика Мокси выложил в открытый доступ утилиту chapcrack. Она парсит перехваченный сетевой трафик, ища MS-CHAPv2 handshake’и. Для каждого найденного «рукопожатия» она выводит имя пользователя, известный открытый текст, два известных шифртекста и взламывает третий DES-ключ. Кроме этого, она генерирует токен для CloudCracker, в котором закодированы три параметра, необходимые, чтобы сервис взломал оставшиеся ключи.

CloudCracker & Chapcrack

На случай, если тебе понадобится взломать DES-ключи из перехваченного пользовательского трафика, приведу небольшую пошаговую инструкцию.

1. Скачиваем библиотеку Passlib , реализующую более 30 различных алгоритмов хеширования для языка Python, распаковываем и устанавливаем: python setup.py install
2. Устанавливаем python-m2crypto - обертку OpenSSL для Python: sudo apt-get install python-m2crypto
3. Скачиваем саму утилиту chapcrack , распаковываем и устанавливаем: python setup.py install
4. Chapcrack установлена, можно приступать к парсингу перехваченного трафика. Утилита принимает на вход cap-файл, ищет в нем MS-CHAPv2 handshake’и, из которых извлекает необходимую для взлома информацию. chapcrack parse -i tests/pptp
5. Из выводимых утилитой chapcrack данных копируем значение строки CloudCracker Submission и сохраняем в файл (например, output.txt)
6. Идем на cloudcracker.com, на панели «Start Cracking» выбираем File Type, равный «MS-CHAPv2 (PPTP/WPA-E)», выбираем предварительно подготовленный на предыдущем шаге файл output.txt, нажимаем Next -> Next и указываем свой e-mail, на который придет сообщение по окончании взлома.

К небольшому сожалению, сервис CloudCracker платный. К счастью, за взлом ключиков придется отдать не так уж много - всего 20 баксов.

Что делать?

Хоть Microsoft и пишет на своем сайте, что на данный момент не располагает сведениями об активных атаках с использованием chapcrack, а также о последствиях таких атак для пользовательских систем, но это еще не значит, что все в порядке. Мокси рекомендует всем пользователям и провайдерам PPTP VPN решений начинать миграцию на другой VPN-протокол. А PPTP-трафик считать незашифрованным. Как видишь, налицо еще одна ситуация, когда VPN может нас серьезно подвести.

Заключение

Так сложилось, что VPN ассоциируется с анонимностью и безопасностью. Люди прибегают к использованию VPN, когда хотят скрыть свой трафик от бдительных глаз провайдера, подменить свое реальное географическое положение и так далее. На деле получается, что трафик может «протечь» в сеть в открытом виде, а если и не в открытом, то зашифрованный трафик могут достаточно быстро расшифровать. Все это еще раз напоминает, что нельзя слепо полагаться на громкие обещания полной безопасности и анонимности. Как говорится, доверяй, но проверяй. Так что будь начеку и следи за тем, чтобы твое VPN-соединение было по-настоящему безопасным и анонимным.

Сегодня по всему миру появляется все больше различных ограничений в сети Интернет. Правительства озабочены использованием OpenVPN и нам приходится обходить их и искать способы подключать сервисы как обычно. Великий Китайский Файрвол, к примеру, блокирует некоторые VPN-сети, как в самом Китае, так и за его пределами.

Конечно же, данные, проходящие по VPN-тунелям увидеть невозможно. Однако сложные брандмауэры эффективно используют DPI-техники, позволяющие дешифровать пакеты, даже те, при шифровании которых использовалось SSL-шифрование.

Существуют различные способы решения проблемы, однако большинство из них предполагает изменение настроек самого сервера. В данной статье мы рассматриваем различные способы, доступные вам. Если вы хотите скрыть сигналы VPN и у вас отсутствует переадресация порта 443, вам нужно связаться с провайдером VPN и уточнить, готовы ли они предоставить вам какое-либо решение из представленных ниже.

Переадресация через TCP порт 443

Это один из самых простых способов. Вам не потребуется сложная настройка сервера, чтобы переадресовать VPN-трафик через порт 443.

Помните, что по умолчанию VPN использует TCP порт 80. Обычно брандмауэры проверяют порт 80 и не пропускают зашифрованный трафик через него. HTTPS по умолчанию перенаправляет данные через порт 443. Этот порт также используется веб-гигантами, такими, как Twitter, Gmail, также с ним работают банки и другие ресурсы.

OpenVPN использует SSL-шифрование, как и HTTPS, и его достаточно сложно засечь при использовании порта 443. Блокирование его не позволит использовать интернет, так что оно не подходит интернет-цензорам.

Переадресация поддерживается практически любым клиентом VPN, так что вы без труда сможете переключиться на порт 443. Если ваш VPN-провайдер не предлагает такой возможности в клиенте, вам нужно связаться с ним немедленно.

К сожалению, OpenVPN не использует стандартный метод SSL, так что если будет использован метод углубленной проверки пакетов, как, например, происходит в Китае, можно будет распознать зашифрованный трафик. В этом случае вам потребуются дополнительные средства защиты.

Obfsproxy

Сервер шифрует данные при помощи обфускации, запутывает код и не позволяет определить использование OpenVPN. Эта стратегия используется Tor, чтобы обойти блокировки в Китае. Шифрование доступно для OpenVPN

Obfsproxy требует установки как на компьютер клиента, так и на сервер VPN. Конечно же, это не так безопасно, как методы туннелирования, трафик не кодируется, однако при этом канал не слишком перегружен. Это прекрасно подходит для пользователей в таких странах, как Сирия или Эфиопия, где существуют проблемы с доступом в интернет. Obfsproxy довольно просто настроить и установить, что является безусловным преимуществом.

SSL туннелирование для OpenVPN

Протокол защиты сокетов (SSL) может быть использован как эффективная замена OpenVPN. Многие прокси-сервера используют его для защиты подключения. Кроме того, этот протокол полностью скрывает использование VPN. Поскольку OpenVPN основывается на шифровании TLS или SSL, этот протокол сильно отличается от стандартных каналов SSL и его нетрудно обнаружить при помощи глубинного анализа пакетов. Чтобы избежать этого, можно добавить дополнительный уровень шифрования, так как самостоятельные слои SSL-каналов DPI не распознает.

Заключение

Конечно же, без глубинного анализа, OpenVPN не отличается от стандартного трафика SSL. Защиту можно повысить путем переадресации через порт 443. Однако, в таких странах, как Китай или Иран, этого будет недостаточно. Правительства таких стран разработали сложные комплексы мер по отслеживанию интернет-трафика. Обязательно учитывайте эти факторы, чтобы избежать лишних неприятностей.

Всем ясно, что ваш провайдер в курсе всех ваших передвижений по Интернету, частенько встречаются истории о том, что сотрудники компаний мониторят трафик клиентов. Как это происходит, можно ли этого избежать?.

Как за тобой следят

Провайдеры в РФ обязаны анализировать трафик пользователей на соответствие нормам российского законодательства. В частности, п. 1.1 Федеральный закон от 07.07.2003 N 126-ФЗ (ред. от 05.12.2017) «О связи» гласит :

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

Сам трафик провайдер, естественно, не хранит. Однако он выполняет его обработку и классификацию. Результаты записываются в лог-файлы.

Анализ основной информации ведётся в автоматическом режиме. Обычно трафик выбранного пользователя зеркалируется на СОРМ-сервера (средства оперативно-розыскных мероприятий), которые контролируют МВД, ФСБ и др., и анализ проводится уже там.

Составной частью современных систем СОРМ-2 является циклический буфер хранения данных. В нём должен храниться проходящий через провайдера трафик за последние 12 часов. С 2014 года внедряется СОРМ-3. Её главное отличие – дополнительное хранилище, в которое должен складываться трехлетний архив всего биллинга и всех логов соединений.

Как читают трафик с помощью DPI

Пример схемы от VAS Expert

В составе СОРМ либо отдельно могут использоваться DPI (Deep Packet Inspection). Это системы (обычно программно-аппаратные комплексы – железо со специальным ПО), которые работают на всех, кроме первого (физического, битового), уровнях сетевой модели OSI.

В простейшем случае провайдеры используют DPI для контроля доступа к ресурсам (в частности, к страницам сайтов из «черного» списка Роскомнадзора по ФЗ № 139 о внесении изменений в закон «О защите детей от информации, причиняющей вред их здоровью и развитию» или торрентам). Но, вообще говоря, решение могут применить и для чтения вашего трафика.

Противники DPI заявляют, что право на неприкосновенность переписки закреплено в конституции, к тому же технология нарушает сетевой нейтралитет. Но это не мешает задействовать технологию на практике.

DPI без проблем разбирает содержимое, которое передаётся по незашифрованным протоколам HTTP, FTP.

Некоторые системы также используют эвристику – косвенные признаки, которые помогают опознать сервис. Это, к примеру, временные и численные характеристики трафика, а также особые последовательности байт.

С HTTPS сложнее. Однако в уровне TLS, начиная с версии 1.1, который сегодня нередко используется для шифрования в HTTPS, доменное имя сайта передаётся в открытом виде. Таким образом, провайдер сможет узнать, на какой домен вы заходили. Но что там делали, он без закрытого ключа не узнает.

В любом случае провайдеры не проверяют всех подряд

Это слишком затратно. А вот мониторить чей-то трафик по запросу теоретически могут.

То, что отметила система (или товарищ майор), обычно исследуется вручную. Но чаще всего никакого СОРМ у провайдера (особенно если это мелкий провайдер) нет. Всё ищется и находится рядовыми сотрудниками в базе данных с логами.

Как отслеживают торренты

Торрент-клиент и трекер, как правило, обмениваются данными по протоколу HTTP. Это открытый протокол, а значит, смотрите выше: просмотр трафика пользователя с помощью атаки MITM, анализ, расшифровка, блокировка с помощью DPI. Провайдер может исследовать очень много данных: когда стартовало или завершилось скачивание, когда стартовала раздача, какое количество трафика было роздано.

Сидеров найти труднее. Чаще всего в таких случаях специалисты сами становятся пирами. Зная IP-адрес сидера, пир может направить провайдеру уведомление с именем раздачи, её адресом, временем начала раздачи, собственно, IP-адресом сидера и т.д.

В России пока что это безопасно – все законы ограничивают возможности администрации трекеров и других распространителей пиратского контента, но не рядовых пользователей. Однако в некоторых европейских странах пользование торрентами чревато большими штрафами. Так что если едете за границу, не попадайтесь.

Что происходит, когда вы заходите на сайт

Провайдер видит URL, который вы открыли, если анализирует содержимое пакетов, которые вам приходят. Сделать это можно, к примеру, с помощью MITM-атаки (атака “man-in-the-middle”, человек посередине).

Из содержимого пакетов можно получить историю поиска, проанализировать историю запросов, даже прочитать переписку и логины с паролями. Если, конечно, сайт использует для авторизации нешифрованное HTTP-соединение. К счастью, такое встречается всё реже.

Если сайт работает с HTTPS, тогда провайдер видит только IP-адрес сервера и имя домена, а также время подключения к нему и объём трафика. Остальные данные проходят в зашифрованном виде, и без приватного ключа расшифровать их невозможно.

Что насчёт MAC-адреса

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

Но MAC-адреса на многих роутерах можно подменять вручную. Да и на компьютерах MAC-адрес сетевого адаптера устанавливается вручную. Так что если сделать это до первой авторизации (или поменять позднее и попросить перепривязать аккаунт к новому MAC-адресу), истинный MAC-адрес провайдер видеть не будет.

Что происходит, если у вас включен VPN

Если вы используете VPN, то провайдер видит, что шифрованный трафик (с высоким коэффициентом энтропии) отправляется на определённый IP-адрес. Кроме того, он может узнать, что IP-адреса из этого диапазона продаются под VPN-сервисы.

Куда идёт трафик с VPN-сервиса, провайдер автоматически отследить не может. Но если сопоставить трафик абонента с трафиком любого сервера по временным меткам, можно выполнить дальнейшее отслеживание. Просто для этого нужны более сложные и дорогие технические решения. От скуки никто такое точно разрабатывать и использовать не будет.

Бывает, что внезапно VPN «отваливается» – такое может произойти в любой момент и в любой операционной системе. После того, как VPN прекратил работу, трафик автоматически начинает идти открыто, и провайдер может его анализировать.

Важно, что даже если анализ трафика показывает, что слишком большой объём пакетов постоянно идёт на IP-адрес, который потенциально может принадлежать VPN, вы ничего не нарушите. Пользоваться VPN в России не запрещено – запрещено предоставлять такие услуги для обхода сайтов из «чёрного списка» Роскомнадзора.

Что происходит, когда вы включаете Tor

Когда вы подключаетесь через Tor, провайдер также видит зашифрованный трафик. И расшифровать, что вы делаете в интернете в данный момент, он не сможет.

В отличие от VPN, где трафик обычно направляется на один и тот же сервер в течение большого промежутка времени, Tor автоматически меняет IP-адреса. Соответственно, провайдер может определить, что вы, вероятно, пользовались Tor, по шифрованному трафику и частой смене адресов, а затем отразить это в логах. Но по закону вам за это тоже ничего не будет.

При этом вашим IP-адресом в сети Tor кто-то может воспользоваться, только если вы сконфигурировали Exit Node в настройках.

А как насчёт режима «инкогнито»

Этот режим не поможет скрыть ваш трафик от провайдера. Он нужен, чтобы сделать вид, что вы не пользовались браузером.

В режиме «инкогнито» не сохраняются файлы cookie, данные сайтов и история просмотров. Однако ваши действия видят провайдер, системный администратор и веб-сайты, на которые вы заходите.

Но есть и хорошая новость

Провайдер знает о вас многое, если не всё. Однако бюджет мелких компаний не позволяет купить оборудование DPI, установить СОРМ или настроить эффективную систему мониторинга.

Если совершать легальные действия в интернете открыто, а для действий, предполагающих конфиденциальность, пользоваться VPN, Tor или другими средствами обеспечения анонимности, вероятность «попасть на карандаш» к провайдеру и спецслужбам минимальна. Но 100% гарантию дают только 100% легальные действия.

Сегодня мы поговорим о том, какие данные хранит провайдер о пользователе, а также вообще о том что он может знать, а что нет. Вот например, видно ли какие сайты вы посещаете? И почему провайдер следит за пользователями?

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

• Если пользователь открывает определенный сайт, то видно ли это провайдеру?. Да, в большинстве случаев видно именно доменное имя, редко — просто IP-адрес. Также записывается и время, когда вы заходили на сайт. Содержимое сайтов также видно
• А если я захожу на сайт по защищенному протоколу https? Тогда провайдер видит только имя сайта или его IP-адрес и все, содержимое он не видит, так как https это защищенное соединение шифрованием, поэтому и рекомендуется его использовать.
• Как провайдер может просечь что я скачал фильм или программу через торрент? Все дело в том, что торрент-качалкя общается с торрентр-трекером по протоколу HTTP, поэтому увидеть провайдер может все что вы качали (просто при помощи анализа страницы, откуда был скачан.torrent-файл) и когда (начали/закончили). Возможно подключение и по HTTPS, но почему-то даже крупнейший торрент СНГ не поддерживает такой протокол, но вот почему — загадка.
• Провайдер сохраняет все то что я качаю? Нет, это физически просто невозможно, не хватило бы никаких жестких дисков. Трафик на лету обрабатывается, сортируется и ведется статистика, вот как раз она то и складируется годами.
• Может ли провайдер узнать что я скачал.torrent файл? Да, может, именно это они и стараются отслеживать — взаимодействие между торрент-клиентом и сервером, анализировать трафик внутри торрент-сети они не могут, ибо это очень и очень накладно.
• А если я использую VPN, то провайдер ничего не видит? Тут как раз штука такая, что при VPN таки да, провайдер видит кашу — то есть зашифрованные данные и анализировать их, а уж тем более расшифровать он не станет, ибо это почти нереально. Но вот узнать по IP серверам, что это VPN специально для шифрования трафика — он может. Это означает, что пользователю есть что скрывать, делайте выводы сами
• Если я буду использовать OpenVPN, то через него будет работать все программы в том числе и обновление Windows? В теории да, и вообще так должно быть. Но на практике все зависит от настроек.
• Может ли провайдер узнать реальный IP адрес определенного сайта, если я зашел на него через VPN? Вообще-то нет, но тут есть другой момент. Если вдруг VPN перестанет работать, или если какая-то ошибка, то Windows просто начнет работать в обычном режиме, то есть без использования VPN — просто напрямую. Чтобы это исправить, во-первых нужно настроить сам OpenVPN, а во-вторых использовать дополнительно фаервол (рекомендую Outpost Firewall), в котором можно создать глобальные правила движения трафика.
• То есть если VPN глюканул, провайдер увидит на каком сайте я сижу? К сожалению да, при этом автоматически будет все записано.
• Может ли TOR обеспечить анонимность? Может, но желательно его немного настроить на использование IP-адресов все кроме СНГ, а также чтобы адреса менялись чаще, например каждые три минуты. Также для лучшего эффекта советую использовать ретрансляторы (мосты).
• Что видит провайдер, когда я получаю пакеты с постоянно разных IP аресов? У провайдеров есть система обнаружения использования TOR, но, я не уверен работает ли эта система при наличии ретрансляторов. Факт использования TOR также записывается и также говорит провайдеру о том, что этот пользователь может что-то скрывать
• Видит ли провайдер адрес сайта через Tor или VPN? Нет, только IP-адрес VPN или выходной узел Tor.
• Видно ли провайдеру полное имя адреса при использовании HTTPS-протокола? Нет, видно только адрес домена (то есть только site.com), время подключения и переданный обьем. Но эти данные не особо полезны для провайдера в плане инфы. Если использовать HTTP, то видно все что передается — и полный адрес и все что вы написали/отправили в сообщение по почте например, но опять же, вот к Gmail это не относится — там трафик шифруется.
• То есть если я использую шифрование соединения, то я уже могу быть в списке подозреваемых? Нет, не совсем так. С одной стороны — да, но с другой шифрование данных а то и глобальное шифрование всей сети могут использовать не только какие-то хакеры или пользователи — но и простые организации, которые обеспокоены безопасной передачей данных, что и логично, особенно в банковской сфере.
• Видит ли провайдер факт использования I2P? Видит, но пока этот вид сети мало знакома провайдерам так, как например Tor, который из-за своей популярности привлекает все больше внимания со стороны спецслужб. Трафик I2P провайдер видит как шифрованные подключения к разным IP-адресам, что говорит о том, что клиент работает с P2P сетью.
• Как узнать, нахожусь ли я под СОРМ? Расшифровывается эта аббревиатура так — Система технических возможностей для оперативно-розыскных мероприятий. И если вы подключены к интернету в РФ, то вы уже пол умолчанию под надзором. При это эта система полностью официальная и трафик обязан проходить через нее, иначе у провайдеров интернета и операторов связи просто аннулируют лицензию.
• Как увидеть весь трафик на компе так, как его видят провайдеры? В этом вам поможет утилита для сниффинга трафика, лучшая в своем роде это анализатор Wireshark.
• Можно ли как то понять, что за тобой следят? На сегодняшний почти нет, иногда, возможно при активной атаке типа MitM (Man in the middle). Если применяется пассивная слежка, то обнаружить ее нереально чисто технически.
• Но что делать тогда, можно ли как-то затруднить слежку? Можно разделить интернет, то есть ваше подключение к нему, на две части. Сидите в соцсетях, на сайтах знакомств, смотрите развлекательные сайты, фильмы, все это делайте по обычному подключению. А зашифрованное соединение используйте отдельно и при этом параллельно — например установите для этого виртуальную машину. Таким образом у вас будет более-менее естественная среда так бы сказать, ибо, шифруют трафик многие сайты, и Google в своих сервисах, и другие крупные компании. Но с другой стороны, почти все развлекательные сайты трафик НЕ шифруют. То есть это норма — когда и открытый и зашифрованный трафик есть у пользователя. Другое дело, когда провайдер видит, что у пользователя трафик только зашифрован, конечно тут могут возникнуть вопросы.

Надеюсь, что вы нашли некоторые полезные ответы