Сегодня мы поговорим о том, какие данные хранит провайдер о пользователе, а также вообще о том что он может знать, а что нет. Вот например, видно ли какие сайты вы посещаете? И почему провайдер следит за пользователями?
Вообще с провайдерами не все так просто, они по закону должны прослушивать трафик пользователей — не нарушают ли они закон, что они там делают они конечно не смотрят, но записывают основные данные, люди их без причины не проверяют (то есть это все записывается в автоматическом режиме).
Надеюсь, что вы нашли некоторые полезные ответы
Любой администратор рано или поздно получает инструкцию от руководства: «посчитать, кто ходит в сеть, и сколько качает». Для провайдеров она дополняется задачами «пустить кого надо, взять оплату, ограничить доступ». Что считать? Как? Где? Отрывочных сведений много, они не структурированы. Избавим начинающего админа от утомительных поисков, снабдив его общими знаниями, и полезными ссылками на матчасть.
В данной статье я постараюсь описать принципы организации сбора, учёта и контроля трафика в сети. Мы рассмотрим проблематику вопроса, и перечислим возможные способы съема информации с сетевых устройств.
Это первая теоретическая статья из цикла статей, посвящённого сбору, учёту, управлению и биллингу трафика и IT-ресурсов.
Для передачи IP-пакета по проводам (или радио) сетевые устройства вынуждены «оборачивать» (инкапсулировать) его в пакет протокола 2го уровня (L2). Самым распространенным протоколом такого типа является Ethernet . Фактическая передача «в провод» идет на 1м уровне. Обычно, устройство доступа (маршрутизатор) не занимается анализом заголовков пакетов на уровне, выше 4го (исключение – интеллектуальные межсетевые экраны).
Информация из полей адресов, портов, протоколов и счетчики длин из L3 и L4 заголовков пакетов данных и составляет тот «исходный материал», который используется при учёте и управлении трафиком. Собственно объем передаваемой информации находится в поле Length («Длина пакета») заголовка IP (включая длину самого заголовка). Кстати, из-за фрагментации пакетов вследствие механизма MTU общий объем передаваемых данных всегда больше размера полезной нагрузки.
Суммарная длина интересных нам в данном контексте IP- и TCP/UDP- полей пакета составляет 2...10% общей длины пакета. Если обрабатывать и хранить всю эту информацию попакетно, не хватит никаких ресурсов. К счастью, подавляющий объем трафика структурирован так, что состоит из набора «диалогов» между внешними и внутренними сетевыми устройствами, так называемых «потоков». Например, в рамках одной операции пересылки электронного письма (протокол SMTP) открывается TCP-сессия между клиентом и сервером. Она характеризуется постоянным набором параметров {IP-адрес источника, TCP-порт источника, IP-адрес получателя TCP-порт получателя} . Вместо того, чтобы обрабатывать и хранить информацию попакетно, гораздо удобнее хранить параметры потока (адреса и порты), а также дополнительную информацию – число и сумму длин переданных пакетов в каждую сторону, опционально длительность сессии, индексы интерфейсов маршрутизатора, значение поля ToS и прочее. Такой подход выгоден для ориентированных на соединение протоколов (TCP), где можно явно перехватить момент завершения сессии. Однако и для не ориентированных на сессии протоколов можно проводить агрегацию и логическое завершение записи о потоке по, например, таймауту. Ниже приведена выдержка из SQL-базы собственной системы биллинга , осуществляющей протоколирование информации о потоках трафика:
Необходимо отметить случай, когда устройство доступа осуществляет трансляцию адресов (NAT , маскарадинг) для организации доступа в Интернет компьютеров локальной сети, используя один, внешний, публичный IP-адрес. В этом случае специальный механизм осуществляет подмену IP-адресов и TCP/UDP портов пакетов трафика, заменяя внутренние (не маршрутизируемые в Интернете) адреса согласно своей динамической таблице трансляции. В такой конфигурации необходимо помнить, что для корректного учета данных по внутренним хостам сети съём статистики должен производиться способом и в том месте, где результат трансляции ещё не «обезличивает» внутренние адреса.
О том, как настроить такой сервер, трансляцию адресов и маршрутизацию, написано много . Нас же интересует следующий логический шаг – сведения о том, как получить информацию о проходящем через такой сервер трафике. Существует три распространенных способа:
Работа libpcap требует поддержки со стороны операционной системы, что в настоящее время сводится к установке единственной бибилиотеки. При этом прикладная (пользовательская) программа, осуществляющая сбор пакетов, должна:
При передаче пакета через выбранный интерфейс, после прохождения фильтра эта функция получает буфер, содержащий Ethernet, (VLAN), IP и т.д. заголовки, общим размером до snaplen. Поскольку библиотека libcap копирует пакеты, заблокировать их прохождение при ее помощи невозможно. В таком случае программе сбора и обработки трафика придется использовать альтернативные методы, например вызов скрипта для помещения заданного IP-адреса в правило блокировки трафика.
Поскольку IP-пакет не копируется, а пересылается в программное обеспечение для анализа, становится возможным его «выброс», а следовательно, полное или частичное ограничение трафика определенного типа (например, до выбранного абонента локальной сети). Однако в случае, если прикладная программа перестала отвечать ядру о своем решении (зависла, к примеру), трафик через сервер просто блокируется.
Необходимо отметить, что описанные механизмы при существенных объемах передаваемого трафика создают избыточную нагрузку на сервер, что связано с постоянным копированием данных из ядра в пользовательскую программу. Этого недостатка лишен метод сбора статистики на уровне ядра ОС, с выдачей в прикладную программу агрегированной статистики по протоколу NetFlow .
Объем информации о трафике меньше самого трафика на несколько порядков, что особенно актуально в больших и распределенных сетях. Конечно же, блокировать передачу информации при сборе статистики по netflow невозможно (если не использовать дополнительные механизмы).
В настоящее время становится популярным дальнейшее развитие этого протокола – версия 9, основанная на шаблонной структуре flow record, реализации для устройств других производителей (sFlow). Недавно был принят стандарт IPFIX, который позволяет передавать статистику и по протоколам более глубоких уровней (например, по типу приложения).
Реализация netflow-источников (агентов, probe) доступна для ПК-маршрутизаторов, как в виде работающих по описанных выше механизмам утилит (flowprobe, softflowd), так и непосредственно встроенных в ядро ОС (FreeBSD: ng_netgraph , Linux: ). Для программных маршрутизаторов поток статистики netflow можно принимать и обрабатывать локально на самом маршрутизаторе, или отправлять по сети (протокол передачи – поверх UDP) на принимающее устройство (коллектор).
Программа - коллектор может собирать сведения от многих источников сразу, имея возможность различать их трафик даже при пересекающихся адресных пространствах. При помощи дополнительных средств, таких как nprobe возможно также проводить дополнительную агрегацию данных, раздвоение потоков или конвертацию протоколов, что актуально при управлении большой и распределенной сетью с десятками маршрутизаторов.
Функции экспорта netflow поддерживают маршрутизаторы Cisco Systems, Mikrotik, и некоторые другие. Аналогичный функционал (с другими протоколами экспорта) поддерживается всеми крупными производителями сетевого оборудования.
Естественно, вы можете настроить SPAN-порт и на самом устройстве доступа (маршрутизаторе), если оно это позволяет – Cisco Catalyst 6500, Cisco ASA. Вот пример такой конфигурации для коммутатора Cisco:
monitor session 1 source vlan 100 ! откуда берем пакеты
monitor session 1 destination interface Gi6/3! куда выдаем пакеты
Подведем небольшой итог. На практике существует большое количество методов присоединения управляемой вами сети (с клиентами или офисными абонентами) к внешней сетевой инфраструктуре, с использованием ряда средств доступа – программных и аппаратных маршрутизаторов, коммутаторов, 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, ставя на кон безопасность своих данных и собственную безопасность? Однозначно - нет. Почему? Давай разбираться.
Виртуальная частная сеть, или просто 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 не поддерживают или, что еще хуже, полностью игнорируют протокол IPv6. При установке соединения программное обеспечение VPN берет на себя заботу по транспортировке IPv4-трафика - добавляет дефолтный маршрут для IPv4-пакетов, обеспечивая тем самым, чтобы весь IPv4-трафик отправлялся через VPN-соединение (вместо того чтобы он отправлялся в открытом виде через локальный роутер). Однако, если IPv6 не поддерживается (или полностью игнорируется), каждый пакет, в заголовке которого указан IPv6-адрес получателя, будет отправлен в открытом виде через локальный IPv6-роутер.
Основная причина проблемы кроется в том, что, хотя IPv4 и IPv6 - два разных протокола, несовместимых друг с другом, они тесно используются в системе доменных имен. Таким образом, для системы, поддерживающей оба стека протоколов, невозможно обеспечить безопасность соединения с другой системой, не обеспечив безопасность обоих протоколов (IPv6 и IPv4).
Рассмотрим хост, который поддерживает оба стека протоколов, использует VPN-клиент (работающий только с IPv4-трафиком) для подключения к VPN-серверу и подключен к dual-stacked сети. Если какому-то приложению на хосте нужно взаимодействовать с dual-stacked узлом, клиент обычно запрашивает и А-, и АААА-DNS-записи. Так как хост поддерживает оба протокола, а удаленный узел будет иметь оба типа DNS-записей (А и АААА), то одним из вероятных вариантов развития событий будет использование для связи между ними IPv6-протокола. А так как VPN-клиент не поддерживает шестую версию протокола, то IPv6-трафик не будет отправляться через VPN-соединение, а будет отправляться в открытом виде через локальную сеть.
Такой вариант развития событий подвергает угрозе передаваемые в открытом виде ценные данные, в то время как мы думаем, что они безопасно передаются через VPN-соединение. В данном конкретном случае утечка VPN-трафика является побочным эффектом использования ПО, не поддерживающего IPv6, в сети (и на хосте), поддерживающей(ем) оба протокола.
Атакующий может преднамеренно вызвать подключение по протоколу 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, могут легко провернуть такой трюк.
Совсем не дело, если трафик, не предназначенный для чужих глаз, попадет в открытом виде в сеть. Как же обезопаситься в таких ситуациях? Вот несколько полезных рецептов:
- если IPv6 VPN-клиентом не поддерживается - отключить поддержку шестой версии протокола IP на всех сетевых интерфейсах. Таким образом, у приложений, запущенных на компьютере, не будет другого выбора, как использовать IPv4;
- если IPv6 поддерживается - убедиться, что весь IPv6-трафик также отправляется через VPN.
- воспользоваться утилитой VPNetMon , которая отслеживает состояние VPN-соединения и, как только оно пропадает, мгновенно завершает указанные пользователем приложения (например, торрент-клиенты, веб-браузеры, сканеры);
- или утилитой VPNCheck , которая в зависимости от выбора пользователя может либо полностью отключить сетевую карту, либо просто завершить указанные приложения.
Даже если ты все настроил правильно и твой 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 и посмотрим, как же Мокси Марлинспайк сумел его взломать.
Как уже было сказано, MSCHAPv2 применяется для аутентификации пользователей. Происходит она в несколько этапов:
На первый взгляд протокол кажется излишне сложным - куча хешей, шифрование, случайные 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-шифрования.
Теперь, когда диапазон подбора ключа известен, для успешного завершения атаки дело остается только за вычислительными мощностями. В 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, в котором закодированы три параметра, необходимые, чтобы сервис взломал оставшиеся ключи.
На случай, если тебе понадобится взломать DES-ключи из перехваченного пользовательского трафика, приведу небольшую пошаговую инструкцию.
К небольшому сожалению, сервис CloudCracker платный. К счастью, за взлом ключиков придется отдать не так уж много - всего 20 баксов.
Хоть Microsoft и пишет на своем сайте, что на данный момент не располагает сведениями об активных атаках с использованием chapcrack, а также о последствиях таких атак для пользовательских систем, но это еще не значит, что все в порядке. Мокси рекомендует всем пользователям и провайдерам PPTP VPN решений начинать миграцию на другой VPN-протокол. А PPTP-трафик считать незашифрованным. Как видишь, налицо еще одна ситуация, когда VPN может нас серьезно подвести.
Так сложилось, что VPN ассоциируется с анонимностью и безопасностью. Люди прибегают к использованию VPN, когда хотят скрыть свой трафик от бдительных глаз провайдера, подменить свое реальное географическое положение и так далее. На деле получается, что трафик может «протечь» в сеть в открытом виде, а если и не в открытом, то зашифрованный трафик могут достаточно быстро расшифровать. Все это еще раз напоминает, что нельзя слепо полагаться на громкие обещания полной безопасности и анонимности. Как говорится, доверяй, но проверяй. Так что будь начеку и следи за тем, чтобы твое VPN-соединение было по-настоящему безопасным и анонимным.
Возможность обхода региональных блокировок не единственная причина востребованности и популярности VPN
-сервисов. Они также служит гарантией анонимности и защищенности пользователя в сети, по крайней мере, так принято считать. Но действительно ли VPN способны обеспечить стопроцентную защиту и безопасность?
Возможно, кое-кого это разочарует, но ответ будет «нет»
. Данные по VPN
передаются в зашифрованном виде, но это вовсе не означает, что их нельзя перехватить.
А если можно перехватить, то теоретически можно и расшифровать, даже не то чтобы теоретически, а с полной гарантией, если в соединении используется, что, кстати, встречается нередко, уже порядком потрепанный протокол PPTP . Другое больное место VPN - это утечка трафика, на которой мы остановимся чуть подробнее. В данном сценарии трафик, который должен передаваться зашифрованным, попадает в интернет в открытом виде. Основных причин тому две: внезапный обрыв соединения, когда трафик начинает отправляться непосредственно с вашего хоста и отсутствие адекватной поддержки VPN -инструментом протокола IPv6 .
Последний случай весьма интересен. IPv4 и IPv6 протоколы совершенно разные, можно даже сказать несовместимые, тем не менее, в системе доменных имен они используются в тесной связке. В сущности, это означает, что если вы отправите в такую сеть данные, трафик IPv4 пойдет, как и положено, по VPN , те же пакеты, в заголовках которых будет указан IPv6 -адрес, полетят в сеть в незашифрованном виде.
Если у вас оборвется VPN , вы этого не заметите, если только вдруг в голову вам не придет идея проверить используемый в данный момент IP -адрес. Что делать? Использовать специальные утилиты, ведущие наблюдение за соединением и разрывающими его принудительно, если VPN внезапно отвалится.
Приложение для контроля над VPN -соединением. Бесплатная версия поддерживает мониторинг VPN PPTP , позволяет автоматически завершать работу программ, использующих туннельное соединение. Базовая настройка инструмента не представляет сложности. Нужно запустить утилиту, нажать Config -> Add file и добавить программу, которую собираетесь контролировать. Также необходимо заполнить поля «Login info» , указав имя вашего VPN -соединения и используемый для него логин и пароль . По умолчанию в настройках выставлено завершение работы контролируемой программы, но вы можете включить ее перезапуск (чекбокс Autorun) .
Еще одна утилита для наблюдения за VPN -соединением. Работает по тому же принципу, что и . Через меню «File» добавляем контролируемую программу, выбираем VPN и включаем мониторинг. Если вдруг произойдет отключение VPN , утилита принудительно разорвет соединение. Есть платная и бесплатная версия. Последняя позволяет добавлять в список контролируемых программ только одно приложение.
Принудительно завершить соединение можно также с помощью BAT -скрипта от LiquidVPN , бесплатно распространяемого в интернете. Всё, что требуется от пользователя, это запустить этот скрипт после подключения к VPN , вести в командной строке 1 и нажать ввод. Если вдруг соединение VPN оборвется, скрипт тут же удалит IP -адрес шлюза по умолчанию в настройках сетевой карты, в результате интернет будет полностью отключен. Чтобы восстановить исходные сетевые настройки, потребуется запустить скрипт повторно, ввести в консоли 2 и нажать ввод.
Можно обойтись и без сторонних инструментов, воспользовавшись самым обыкновенным планировщиком заданий Windows. Запустите его командой taskschd.msc , в правой колонке нажмите .
Дайте задаче произвольное имя, отметьте галочкой пункт «Выполнить с наивысшими правами» и перейдите на вкладку .
Здесь нажмите .
В открывшемся окне установите «При событии» , в поле «Журнал» выберите «Приложение» , в поле «Источник» - «RasClient» , в поле «Код события» вбейте 20226 .
Сохраните настройки, нажав «OK» .
В открывшемся окне в качестве действия выберите запуск программы, в поле «Программа или сценарий» вставьте taskkill.exe , в поле аргументов введите /f /im app.exe , где app.exe - название исполняемого файла контролируемого приложения. Сохраните настройки.