BOZZA.RU - сервер в кармане

Настройка VPN через SSH с использованием Putty

Обновлено: 15.01.2025

Теги: VPN

Дата последнего редактирования: 22.11.2011.

Сегодня пришлось вспоминать минут 20 как сделать сабж, попарился и решил написать на сайт, для себя как памятку и для других - вдруг кому пригодиться.

Итак, имеем:

компьютер на базе Windows (удаленная рабочая станция, условно КЛИЕНТ);
почтовый сервер (не важно, какой именно, будь то Kerio MailServer, MDaemon или другой, условно СЕРВЕР_ПОЧТЫ в локальной сети - ну предположим, что вам надо с ним работать, а просто так локальный почтовый сервер в мир не подключен);
шлюз (прокси-сервер) в интернет с запущенным сервером SSH (например, FreeBSD или Linux, которые во многих организациях стоят как брандмауэры, условно БРАНДМАУЭР).

Задача: осуществить безопасное (шифрованное) соединение от КЛИЕНТА к СЕРВЕРУ_ПОЧТЫ по протоколу POP3 (получение почты, обычно порт 110). Ну и пусть нам это надо не постоянно, а иногда (иначе надо все-таки настраивать нормальный VPN-сервер).

Безопасный VPN-туннель с использованием SSH и Putty

Решение

Т.к. по умолчанию трафик по протоколу POP3 передается открытым текстом, а мы передаем очень секретный пароль от почтового ящика, то почтовый трафик надо шифровать :) Чем мы будем его шифровать? Поднимать специальный VPN-сервер, редирект портов, настраивать сертификаты и прочее - часто не выход, т.к. это сложно даже для большинства системных администраторов, к тому же, как сказано чуть выше, нам все это надо для периодических сеансов работы, возможно, только для нас и нужных ;)

Мы будем делать соединение между КЛИЕНТОМ и СЕРВЕРОМ_ПОЧТЫ внутри шифрованного содинения по протоколу ssh.

Возьмем бесплатный клиент ssh для Windows - Putty - и установим его на КЛИЕНТА (т.е. на наш домашний компьютер).

Командная строка Putty

Далее установим зашифрованное соединение между КЛИЕНТОМ и БРАНДМАУЭРОМ так, чтобы для КЛИЕНТА работа с почтой внутри локальной сети была бы точно такой, как если бы он (клиент) был бы у себя в офисе.

У КЛИЕНТА запускаем консоль: Пуск -> выполнить -> cmd

В консоли набираем команды:

cd путь_к_папке_с_putty
putty.exe -v -ssh -2 -P 22 -C -l user -pw password -L 8110:192.168.1.10:110 81.222.111.10

где "-v" - т.н. verbose режим, с расширенными комментариями, "-ssh -2" - использовать протокол ssh версии 2, "-P 22" - порт, открытый на БРАНДМАУЭРЕ для подключения по ssh, "-C" - использовать сжатие, "-l user" - имя пользователя, который имеет право входить на сервер ssh на БРАНДМАУЭРЕ, "-pw password" - пароль этого пользователя,

далее (я специально сделал отступ от предыдущего текста):
"-L 8110:192.168.1.10:110" - локальный порт, который будет доступен на компьютере КЛИЕНТА, а 192.168.1.10 - локальный ip-адрес почтового сервера внутри организации, 110 - соответственно, порт POP3 на этом сервере;
"81.222.111.10" - внешний ip-адрес БРАНДМАУЭРА, к которому и будет соединяться КЛИЕНТ по ssh с помощью putty.

После набора последней команды:

putty.exe -v -ssh -2 -P 22 -C -l user -pw password -L 8110:192.168.1.10:110 81.222.111.10

откроется окно сеанса связи по протоколу ssh. Все, окно сворачиваем (не закрываем!), и настраиваем нашу почтовую программу на получение почты с адреса localhost и портом 8110, а не 110, который стоит по умолчанию.

Вроде бы все. Во время получения почты почтовая программа будет соединяться с портом 8110, который будет переадресован на удаленный почтовый сервер в офисе, при этом весь трафик соединения будет зашифрован. Завершить сеанс связи можно просто закрыв окно сеанса putty. После этого локальный порт 8110 уже не будет доступен.

... или же все это можно сделать немного проще:

GUI Putty

Для тех, кто пользуется графическим интерфейсом Putty, привожу скриншоты:

Source port: 8110 - порт к которому мы будем подключаться на нашей машине.
Destination ( [IP:]Port): 192.168.1.10:110 - удаленный почтовый сервер.
Нажимаем "Add" ("Добавить"). Думаю, многие могут не сделать этого и будут разочарованы, т.к. ничего не сработает.

Суть последнего скриншота: локальный порт 8110 прозрачно соединяет вас с 80 портом сервера 192.168.1.10.

Ну и, понятное дело, чтобы это не вписывать каждый раз, ПЕРЕД ТЕМ, КАК НАЖАТЬ "Open", вернитесь на вкладку Session (первый скриншот) и сохраните настройки. Только потом жмите "Open".

Резюме

Можно добавить, что похожим образом можно соединяться не только к почтовому серверу, но и к другим сервисам, например, я таким образом соединялся с RAdmin, установленным на компьютере в локальной сети, при этом никаких port-мапперов на самом шлюзе делать не надо. Вот что самое хорошее! Достаточно иметь актуальную версию сервера ssh на шлюзе и, желательно, фильтровать на брандмауэре подключения к порту 22 (ssh), например по ip-адресу, если у вас дома или где там еще подключение к интернет постоянное. Но это уже мелочи жизни и тема другой статьи.

Вообще у ssh и putty, есть ооочень много всяких разных приятностей, которые здесь не упомянуты. Надеюсь, эта статья подтолкнет вас к небольшому исседованию, начать которое очень просто: http://www.google.ru/search?complete=1&hl=ru&newwindow=1&q=ssh&lr=&aq=f.

Кроме того, упомянутые в статье программы (за исключением почтовых серверов и ОС самого клиента ;)) являются бесплатными и свободно распространяемыми, а стремление быть легальным и бесплатным - хороший стимул приглядеться к реализации подобного безопасного соединения через ssh.

И еще, конечно же, при написании этой заметки я использовал другие ресурсы для "освежения" памяти. Вот самая полезная ссылка, которая и стала финальной в моих тестовых экспериментах перед опубликованием статьи: http://wiki.kaytaz.ru/doku.php/ssh-tunnel_cherez_putty.

Примечания (составлены по итогам комментариев на 27.03.2008)

1. (isx) Если туннель простаивает некоторое время, то соединение рвется, потому стоит поменять параметры сервера: TCPKeepAlive. Увеличить LoginGraceTime, выставить ClientAliveInterval и ClientAliveCountMax. Убрать UseDns, иначе длительные ожидания при установке соединений.

2. (isx) А отчего не сделаешь все через ssl? Если не хочется возиться с почтовиком, то можно воспользоваться программой stunnel, поднимая ее на шлюзе(брандмауэре). // Stunnel (http://stunnel.mirt.net/) использует OpenSSl или SSLeavy для шифрования трафика. Используется для установления шифрованных тонелей связи между клиентом и сервером. Работает в Linux, Windows, OS/2 и прочих осях.

3. (Serg) Если человек не админ брендмауэра - могут быть проблемы. Кто-то может гарантировать, что в настройках sshd не выключен форвардинг и/или туннелирование? // Действительно, к данному решению надо подходить взвешенно и понимать, что указанный способ туннелирования действительно больше всего подходить только для админа.

Почему плохо работает WiFi

Обновлено: 26.08.2021

Теги: WiFi

Проблем с WiFi может быть настолько много, что перечислить все просто нереально, но все же, есть достаточно очевидные проблемы, которые можно решить или хотя бы улучшить ситуацию с плохим качеством WiFi.

Шифрование GPG (GnuPG, ex PGP)

Обновлено: 28.08.2021

Теги: Шифрование Безопасность Передача данных

Защита конфиденциальной информации периодически востребована всеми, кто пользуется электронной почтой и хранит документы на своем компьютере, т.е. практически каждый современный человек хоть раз, но сталкивался с проблемой защиты передавемых или хранимых данных. GnuPG - это полная и бесплатная реализация стандарта OpenPGP, определенного в RFC4880 (также известном как PGP). GnuPG позволяет вам шифровать и подписывать ваши данные и сообщения; он оснащен универсальной системой управления ключами, а также модулями доступа для всех видов каталогов открытых ключей. GnuPG, также известный как GPG, представляет собой инструмент командной строки с функциями для легкой интеграции с другими приложениями. Доступно множество интерфейсных приложений и библиотек. GnuPG также поддерживает S/MIME и Secure Shell (ssh).

Шифрование PGP

Обновлено: 28.08.2021

Теги: Шифрование

PGP (Pretty Good Privacy) - криптографическое приложение для обеспечения защиты и аутентификации данных. Используя его можно быть уверенным, что никто не сможет прочитать или изменить Вашу информацию. Подробнее о программе и истории ее создания можно прочитать на сервере www.pgpi.org. Защита гарантирует, что только получатель информации сможет воспользоваться ей. Оказавшись в чужих руках, она будет совершенно бесполезной, поскольку ее невозможно декодировать.

Идентификация и ограничение доступа в Apache

Обновлено: 15.01.2025

Директива Satisfy определяет способ взаимодействия директив идентификации (используемые для защиты паролем) с директивами доступа (например, Allow/Deny). С ее помощью вы, например, можете заставить Apache выполнять те запросы, которые удовлетворяют только требованиям идентификации, либо только требованиям доступа. Или вы можете сделать, чтобы запрос удовлетворял всем требованиям. Директива Satisfy принимает два значения:

Satisfy Any Пропускает запрос, если выполнено любое из требований (идентификация или проверка доступа)
Satisfy All Пропускает запрос, только если оба требования выполнены (и идентификация и проверка доступа).

Для примера возьмем следующий сценарий:

<Directory /home/www/site1/private>
AuthUserFile /home/www/site1-passwd
AuthType Basic
AuthName MySite
Require valid-user
</Directory>

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

<Directory /home/www/site1/private>
AuthUserFile /home/www/site1-passwd
AuthType Basic
AuthName MySite
Require valid-user
Order allow,deny
Allow from 172.17.10
Satisfy any
</Directory>

Такая конфигурация заставит всех "внешних" пользователей пройти процедуру идентификации, а тех, кто пришел с локальной сети, пропустит. Apache предоставит им полный доступ к каталогу private без идентификации.

Все вышеописанное также работает и с подкаталогами вашего защищенного каталога. Допустим, вам нужен незакрытый подкаталог nonprotect, который находится в каталоге private. Причем к каталогу nonprotect должен иметь доступ любой пользователь без ввода какого-либо пароля. Делается это следующим образом:

<Directory /home/www/site1/private/nonprotect>
Order allow,deny
Allow from all
Satisfy any
</Directory>

И, наконец, если у вас есть очень секретный каталог, тогда вы можете ограничить к нему доступ, как с помощью пароля, так и с помощью проверки IP пользователя.

<Directory /home/www/site1/super-secret>
AuthUserFile /home/www/site1-passwd
AuthType Basic
AuthName MySite
Require valid-user
Order allow,deny
Allow from 172.17.10
Satisfy all
</Directory>

В приведенном выше примере директива "Order allow, deny" по умолчанию блокирует доступ для всех, директива "Allow" разрешает доступ пользователям из локальной сети, а директива "Satisfy all" требует проверки как IP, так и пароля.

Источник: http://apachedev.ru/

Скрыть версию Apache

Обновлено: 15.01.2025

Прочитал недавно статью на сайте www.debuntu.org, в которой автор (chantra) описывает способ улучшения безопасности сервера за счет сокрытия информации о версии серверного ПО. Утверждение автора, что данный способ повышает безопасность Apache довольно спорно, но об этом ниже. А пока давайте посмотрим на эксперименты автора по работе с заголовками сервера. На любой GET или HEAD запрос, отправленный серверу, Apache, помимо запрошенного контента (для GET запроса), возвращает клиенту HTTP-заголовки. Вот типичный список заголовков, полученный от сервера Apache:

Date: Tue, 25 Jul 2006 10:47:13 GMT
Server: Apache/2.0.55 (Ubuntu) PHP/5.1.4-1.dotdeb.2
Last-Modified: Mon, 20 Mar 2006 09:51:25 GMT
ETag: “3057-1f8-1a0f4140?
Accept-Ranges: bytes
Content-Length: 504
Connection: close
Content-Type: text/html; charset=ISO-8859-1

Для получения этого списка автор заметки использовал telnet. C его помощью chantra отправил HEAD запрос на свой локальный сервер. Вот эта сессия telnet:

~$ telnet localhost 80
Trying 127.0.0.1…
Connected to localhost.
Escape character is ‘^]’.
HEAD / HTTP/1.0

Обычно данные заголовки скрыты от пользователей, так как содержат в основном служебную информацию. Однако есть много способов просмотреть этот список. Например, для пользователей браузера Firefox хочу порекомендовать плагин LiveHTTPHeaders. В этом списке нас интересует заголовок Server. Как видно из его значения [Apache/2.0.55 (Ubuntu) PHP/5.1.4-1.dotdeb.2], у автора установлено следующее ПО: ОС - Ubuntu, сервер - Apache 2.0.55 и PHP 5.1.4-1.dotdeb.2. Так вот, способ повышения безопасности, предложенный автором, состоит в том, чтобы скрыть от получателя (HTTP-клиента) эту информацию. Делается это с помощью директивы Apache - ServerTokens. Вот значения, которые принимает директива и соответствующие ей значения заголовка Server:

Значение директивы	Значение заголовка Server
ServerTokens Prod	Server: Apache
ServerTokens Major	Server: Apache/2
ServerTokens Minor	Server: Apache/2.0
ServerTokens Minimal	Server: Apache/2.0.55
ServerTokens Os	Server: Apache/2.0.55 (Ubuntu)
ServerTokens Full	Server: Apache/2.0.55 (Ubuntu) PHP/5.1.4-1.dotdeb.2 my_mod1/X.Y my_mod2/W.Z

Все очень просто. Одно лишь замечание по поводу значения Full. Если используется это значение, то сервер выдает не только версии ОС и сервера, но и версии модулей, установленных на сервере - PHP/5.1.4-1.dotdeb.2 my_mod1/X.Y my_mod2/W.Z. Причем модуль сам должен добавить свою версию. Делается это с помощью функции ap_add_version_component(server_pool, "my_mod1/X.Y"). По умолчанию в Apache используется значение Full, а автор статьи рекомендует использовать Prod, тем самым сокращая информацию, отправляемую клиенту, до одного названия сервера.

Также некоторыми возможностями в этой области обладает и PHP. В файле php.ini есть переменная expose_php, которая может принимать значения: On и Off. Которые, соответственно, добавляют или удаляют информацию о версии PHP в заголовок Server (а также в X-Powered-By).

Ну и для полноты картины опишем еще одну подобную директиву, про которую автор не упомянул, а именно ServerSignature. Она также выводит данные о версии ПО, но в отличие от ServerTokens делает это не в заголовок Server, а в некоторые HTML страницы, например: листинг каталогов, страницы ошибок и т.п. Вот ее значения и соответствующие результаты:

Значение директивы	Результат
ServerSignature On	Apache/2.0.59 (Ubuntu) PHP/4.3.10 Server at 127.0.0.2 Port 80
ServerSignature Off
ServerSignature Email	Apache/2.0.59 (Ubuntu) PHP/4.3.10 Server at 127.0.0.2 Port 80

Разница On и Email заключается в ссылке mailto на виртуальном хосте.

Теперь поговорим о том, насколько данный способ пригоден для повышения безопасности. Такой способ даже имеет свой термин - Security through obscurity (Безопасность через сокрытие). В практической жизни он применяется довольно часто, потому что только в теории системы безопасности могут обеспечить надежную защиту. А когда дело доходит до практики, то вся надежность улетучивается благодаря пресловутому "человеческому фактору", а точнее - ошибкам в ПО. Поэтому сокрытие всей информации о системе (помимо необходимой пользователю) повышает ее безопасность. Но, как было справедливо замечено в комментариях к статье, сегодня почти все атаки на веб-сервера производятся ботами, которые не утруждают себя проверкой версий серверного ПО - они берут количеством, а не качеством. Поэтому автор комментария рекомендует сперва использовать более надежные способы защиты, например - mod_security, а потом уж беспокоиться о заголовке Server.

Ну и напоследок, приведу цитату, касающуюся заголовка Server, из спецификации HTTP/1.1 - RFC 2616:
Note: Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks against software that is known to contain security holes. Server implementors are encouraged to make this field a configurable option.

Как вы видите, и тут есть неявная рекомендация скрывать "лишнюю" информацию о ПО. Но, как в принципе и всегда, окончательное решение остается за вами.

Автор: Сипягин Максим
Источник: ApacheDev.ru

Ограничение службы Apache в Windows

Обновлено: 15.01.2025

На Web Security Blog опубликовано письмо Юрия Зайцева (Yury Zaytsev), в котором он описывает свой опыт по изолированию Apache в ОС Windows. Под изолированием понимается максимальное ограничение возможности доступа к системе, что существенно понижает возможность выполнения злонамеренных действий. Вот выдержка из этого письма:

Сперва необходимо создать локального пользователя (например, "Apache") (вы можете даже установить пароль для него, но особого смысла в этом нет) и запретить для него локальный вход и вход из сети с помощью политик групп. Затем надо запретить пользователю "Apache" любой доступ к локальным дискам (запрещается все: листинг каталога, чтение, запись, изменение). Это делается через вкладку Свойства(Properties)->Безопасность(Security). Теперь любой процесс, созданный с правами "Apache" не сможет даже просматривать каталоги. У некоторых пользователей Windows вкладка Безопасность(Security) отсутствует. О том как это исправить можно прочитать тут.

Теперь нам надо разрешить этому пользователю чтение и листинг каталога сервера Apache (производиться через Свойства каталога(Properties)->Безопасность(Security)), а также разрешить запись для PID файла (/logs/httpd.pid) и для лог-файлов. И в завершении необходимо подправить службу (service) сервера Apache. В диалоге Службы (вызывается с помощью команды services.msc или через Панель управления->Администрирование->Службы) выбирается служба Apache и в свойствах меняется вход в систему от пользователя "Apache".

Далее перезагрузка, проверка с помощью диспетчера задач (Task Manager), что процесс сервера запущен от имени пользователя "Apache", проверка работоспособности сервера. Готово.

Изложенный выше метод значительно повышает безопасность выполнения скриптов: теперь, даже если кто-то будет использует уязвимость вашего PHP/Perl скрипта (при использовании SAPI/mod_perl), он не только не сможет просматривать каталоги выше каталога сервера, но даже не сможет изменить какой-нибудь файл внутри каталога Apache, кроме тех, которые вы явно разрешили изменять.

Мой метод полностью копирует Unix-ную технологию chroot (и chmod). Это примитивно и эффективно. В любом случае это не раз избавляло меня от использования эксплоитов уязвимостей PHP скриптов.

Источник: http://apachedev.ru/

Пример настроек правил брандмауэра FreeBSD, Linux и Windows (какие порты открыть и для чего)

Обновлено: 15.01.2025

Теги: FreeBSD Iptables IPFW

Когда сравнивают два брандмауэра, один с графическим интерфейсом, другой - с текстовым конфигурационным файлом, то для одних сложность в том, что через графический интерфейс не всегда можно добиться максимальной гибкости при постоении правил (как правило, это характерно либо для брандмауэров windows, либо надстроек GUI к консольным брандмауэрам, таким, как ipfw, iptables, pf операционных систем FreeBSD,Linux). Но и в тех и в других случаях частенько начинающим администраторам бывает не просто понять, как именно настроить правила брандмауэра. Что разрешить, что запретить и в каком направлении (входящий/исходящий пакет, TCP или UDP...). Приведенная ниже таблица поможет сориентироваться в том, что нужно разрешить, чтобы часто используемые приложения локальной сети могли иметь выход в интернет. На основании нижеприведенных примеров можно строить многие другие подобные правила. И последнее замечание: эта таблица полезна и тем, кто настраивает брандауэр через текстовый конфиг, и тем, кто юзает GUI.

Web Browsers
Description	Protocol	Local port	Remote port	Direction	Action
HTTP connection	TCP	Any or 1024:5000	80:83	Outbound	Accept
HTTPS connection			443	Outbound
SOCKS connection			1080	Outbound
PROXY connection			3128 8080:8083 8088 8100	Outbound
FTP connection			21	Outbound
FTP DATA connection			20	Inbound

Mail Clients
Description	Protocol	Local port	Remote port	Direction	Action
Send Mail (SMTP)	TCP	Any or 1024:5000	25	Outbound	Accept
Receive Mail (POP3)			110 995
IMAP connection			143 993

FTP Clients
Description	Protocol	Local port	Remote port	Direction	Action
FTP connection	TCP	Any or 1024:5000	21	Outbound	Accept
FTP DATA connection			20	Inbound
PASV FTP connection			1024:65535	Outbound

Download Managers
Description	Protocol	Local port	Remote port	Direction	Action
HTTP(s) connection	TCP	Any or 1024:5000	80:83 443 1080 3128 8080 8088 11523	Outbound	Accept
FTP connection			21	Outbound
FTP DATA connection			20	Inbound
PASV FTP connection			1024:65535	Outbound

ICQ & AOL Messengers
Description	Protocol	Local port	Remote port	Direction	Action
AOL connection	TCP	Any	443 5190	Outbound	Accept

MSN Messenger
Description	Protocol	Local port	Remote port	Direction	Action
MSN Messenger connection	TCP	1024:65535	1863	Outbound	Accept
MSN Messenger voice communications			6901	Outbound
MSN Messenger file transfer			6891:6900	All
MSN Messenger Remote Assistance			3389	Outbound
MSN Messenger Application Sharing and Whiteboard			1503	Outbound
MSN Messenger RTP connection			5004:65535	All

Odigo
Description	Protocol	Local port	Remote port	Direction	Action
Odigo connection	TCP	Any	80 3128 8080 1080 2562	Outbound	Accept

IRC
Description	Protocol	Local port	Remote port	Direction	Action
mIRC connection	TCP	Any	6660:6670	Outbound	Accept
mIRC AUTH connection	TCP	Any	113	Inbound	Accept

Windows Media Player
Description	Protocol	Local port	Remote port	Direction	Action
Windows Media Player Connection	TCP	Any	80 3128 8080 1755 8000:8001	Outbound	Accept

WinAmp
Description	Protocol	Local port	Remote port	Direction	Action
WinAmp Connection	TCP	Any	8000:8900	Outbound	Accept
WinAmp MiniBrowser Connection			80:83 443 1080 3128 8080 8088 11523

QuickTime Player
Description	Protocol	Local port	Remote port	Direction	Action
QuickTime Player Connection	TCP	Any	554	Outbound	Accept
QuickTime Player Connection	UDP		2001
QuickTime Player HTTP Connection	TCP		80:83 443 1080 3128 8080 8088 11523

Windows Time Synchronization
Description	Protocol	Local port	Remote port	Direction	Action
Windows Time Sync	UDP	Any	123	Send datagrams	Accept
Windows Time Sync	UDP	123	Any	Receive datagrams	Accept

Таблица взята по адресу: http://jetico.narod.ru/

VPN: не все йогурты одинаково полезны…

Обновлено: 15.01.2025

Кухтин С.Г.

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

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

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

Оценка степени влияния

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

Снижение пропускной способности сети
Накладные расходы на преобразование трафика
Задержки при передаче пакетов

Рассмотрим подробнее эти параметры.

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

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

Например, широко известный протокол IPSec добавляет (для алгоритма ГОСТ 28147-89) при преобразовании минимум 54 байта. Для IP-пакета длиной 1500 байт (стандартный пакет передачи данных) прирост составит порядка 4%, а для 56 байтного пакета (IP-телефония) - накладные расходы составят уже около 100%.

На российском рынке некоторые компании представляют протоколы собственной разработки (например, протокол шифрования данных семейства криптомаршрутизаторов "Континент-К"). Как правило, они лишены многих недостатков IP-Sec, имеют меньшее увеличение длины пакета, нередко также используют режим сжатия полей данных и/или заголовка.

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

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

Криптоанализ туннельного протокола типа точка-точка (PPTP) от Microsoft

Обновлено: 15.01.2025

Теги: VPN сервер VPN

Bruce Schneier, Peter Mudge, пер. Василий Томилин

1 Введение

Многие организации не являются централизованными. Филиалы, виртуальные корпорации и перемещающиеся сотрудники делают идею создания выделенного канала к любому требуемому пункту логически невозможной. Концепция виртуальных сетей обеспечивает решение возникшей проблемы путем туннелирования объединяемого сетевого пространства по другим, промежуточным и небезопасным сетям (например, Интернет), тем самым позвол удаленным пунктам стать локальными. Данное решение не требует вложений на проведение абонируемых или выделенных линий в любую точку. Такой способ иногда называют "тоннель".

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

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

Протокол PPTP (туннельный протокол типа точка-точка) был предназначен для решения задачи создания и управления VPN по общественной сети TCP/IP с использованием стандартного протокола РРР. Хотя протокол резервирует пространство для всех возможных типов шифрования и аутентификации, в большинстве коммерческих продуктов используется версия данного протокола для Windows NT. Именно эта реализация и подвергнута анализу в данной статье.

Мы обнаружили, что протокол аутентификации Microsoft слаб и уязвим путем атаки по словарю; большинство паролей можно вскрыть в течение нескольких часов. Мы обнаружили, что способы шифрования с использованием 40- и 128-разрядных ключей одинаково слабы и открыли ряд заложенных в реализацию неразумных идей, которые позволяют осуществлять другие атаки на данный шифр. Мы может открывать соединения через firewall, нарушая правила переговоров РРTР, и можем проводить различные атаки отказа в обслуживании на тех, кто использует Microsoft PPTP.

Оставшаяся часть работы разделена следующим образом: В параграфе 2 рассматривается РРТР, как стандарт протокола, так и реализация Microsoft. В параграфе 3 рассматриваются две функции хэширования паролей в Microsoft PPTP и способы атаки на них. В параграфе 4 проводится криптоанализ протокола аутентификации Microsoft, а в параграфе 5 - криптоанализ протокола шифрования Microsoft. Другие атаки на Microsoft РРТР рассмотрены в параграфе 6. Наконец, в параграфе 7 делаются некоторые выводы.

2 Туннельный протокол типа точка-точка

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

Функционирование РРТР заключается в инкапсулировании пакетов виртуальной сети в пакеты РРР, которые в свою очередь, инкапсулируются в пакеты GRE (Generic Routing Incapsulation), передаваемые по IP от клиента к шлюзу - серверу РРР и обратно. Совместно с каналом инкапсулированных данных существует управляющий сеанс на базе TCP. Пакеты управляющего сеанса позволяют запросить статус и сопровождать сигнальную информацию между клиентом и сервером. Канал управления инициируется клиентом на сервере на ТСР-порте 1723. В большинстве случаев это двунаправленный канал, по которому сервер посылает запросы на сервер и наоборот.

РРТР не оговаривает конкретных алгоритмов аутентификации и протоколов; вместо этого он обеспечивает основу для обсуждения конкретных алгоритмов. Переговоры не присущи только РРТР, они относятся к существующим вариантам переговоров РРР, содержащихся в ССР, СНАР и других расширениях и усовершенствованиях РРР.

2.1 РРТР от Microsoft

Microsoft РРТР является частью ОС Windows NT Server, данное программное обеспечение можно бесплатно получить с Web-сайта Microsoft. Подключение осуществляется с помощью панели управления и редактора реестра. Данная реализация РРТР широко используется в коммерческих применениях VPN, например Aventail и Freegate именно потому, что входит в состав ОС Microsoft.

Сервер Microsoft РРТР может существовать только для Windows NT, хотя клиентское программное обеспечение существует для Windows NT, некоторых версий Windows и Windows 98. Реализация Microsoft поддерживает три варианта аутентификации:

Текстовый пароль: Клиент передает серверу пароль в открытом виде.
Хэшированный пароль: Клиент передает серверу хэш пароля (см. параграф 3).
Вызов/Отклик: Аутентификация сервера и клиента с использованием протокола MS-CHAP (вызов/отклик), что описано в параграфе 4.

Третий вариант называется в документации для пользователей "Аутентификаци Microsoft", для шифрования пакетов РРТР его надо разрешить. При выборе любого из двух других вариантов шифрование неосуществимо. Кроме того, возможность шифрования (40- или 128-разрядное) гарантируется только в том случае, если клиент использует Windows NT. Некоторые клиенты Windows 95 не могут поддерживать зашифрованные сеансы¹.

3. Криптоанализ функций хэширования паролей Windows NT

В ОС Microsoft Windows NT для защиты паролей используются две однонаправленные хэш-функции: хэш Lan Manager и хэш Windows NT. Функция хэша Lan Manager была разработана Microsoft для операционной системы IBM OS/2, она была интегрирована в Windows for Workgroups и частично в Windows 3.1. Данная функция используется в некоторых протоколах аутентификации перед Windows NT. Хэш Windows NT был разработан специально для ОС Microsoft Windows NT. Функция хэша Lan Manager основана на алгоритме DES; Функция хэша Windows NT основана на односторонней хэш-функции MD4. Обе эти функции используются во многих протоколах аутентификации Windows NT, а не только в РРТР.

Функция хэша Lan Manager вычисляется следующим образом:

Превращение пароля в 14-символьную строку путем либо отсечки более длинных паролей, либо дополнения коротких паролей нулевыми элементами.

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

Словарные атаки на функцию хэша Lan Manager легко достигают успеха по следующим причинам:

Большинство людей выбирают легко угадываемые пароли.

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

Функция хэша Windows NT вычисляется следующим образом:

Преобразование пароля, длиной до 14 символов, с различением регистров в Unicode.
Хэширование пароля с помощью MD4, получение 16-символьного значения хэш-функции.

Хэш Windows NT обладает преимуществом по сравнению с функцией хэша Lan Manager - различаются регистры, пароли могут быть длиннее 14 символов, хэширование пароля в целом вместо разбиения его на маленькие части - хотя по-прежнему отсутствует индивидуальность. Таким образом, люди, имеющие одинаковые пароли, всегда будут иметь одинаковые хэшированные пароли Windows NT. Сравнение файла хэшированных паролей с заранее рассчитанным словарем хэшированных паролей может быть весьма эффективной атакой.

Кроме того, более серьезна проблема реализации существенно облегчает раскрытие паролей. Даже хотя хэш Lan Manager был включен по соображениям совместимости с предыдущими версиями, и не требуется в сетях Windows NT, оба значения хэш-функций всегда передаются вместе. Следовательно, можно выполнить грубый подбор пароля с помощью более слабой хэш-функции Lan Manager и затем выполнить тестирование с учетом регистра для подбора значения хэш-функции Windows NT.

4. Криптоанализ MS-CHAP

РРР содержит различные способы обработки аутентификации. Одним из способов является протокол аутентификации вызов-рукопожатие (СНАР). Реализация PPP СНАР компанией Microsoft (MS-CHAP) почти совпадает с методом аутентификации, используемым для аутентификации клиентов в Windows-сетях.

MS-CHAP функционирует следующим образом:

Клиент запрашивает вызов сетевого имени.
Сервер возвращает восьмибитовый случайный вызов.
Клиент вычисляет хэш-функцию Lan Manager, добавляет пять нулей для создания 21-байтовой строки и делит строку на три семибайтовых ключа. Каждый ключ используется для шифрации вызова, что приводит к появлению 24-разрядного шифрованного значения. Оно возвращается серверу как отклик. Клиент выполняет то же самое с хэш-функцией Windows NT.
Сервер ищет значение хэш-функции в своей базе данных, шифрует запрос с помощью хэш-функции и сравнивает его с полученными шифрованными значениями. Если они совпадают, аутентификация заканчивается.
Сервер может выполнять сравнение по хэш-функции Windows NT или по хэш-функции Lan Manager; результаты должны совпадать. Хэш, используемый сервером, зависит от конкретного флага в пакете. Если флаг установлен, то сервер выполняет тестирование с помощью хэш-функции Windows NT; в противном случае тестирование выполняется с помощью хэш-функции Lan Manager.

Протокол вызова/отклика является стандартным; использование случайного вызова имени делает невозможными словарные атаки на MS-CHAP и файл записанных хэш-функций от паролей. В то же время, поскольку даже в Windows NT-сетях используются оба значения хэш-функции, можно в каждом случае атаковать более слабую хэш-функцию Lan Manager. Поскольку ответ клиента разбит на три части, и каждая часть шифруется независимо от других, можно атаковать сам протокол MS-CHAP.

Последние восемь байт хэш-функции Lan Manager представляют собой константу в том случае, если длина пароля не превышает семи символов. Это верно, несмотря на случайный вызов. Следовательно, последние восемь байт отклика клиента будут представлять собой вызов, зашифрованный с помощью данной константы. Легко проверить, не превышает ли длина пароля семи символов. После того, как атакующий находит значение хэш-функции Lan Manager, он может использовать эту информацию для восстановления хэш-функции Windows NT.

Атака может быть существенно ускорена за счет активного использования предварительных вычислений и тщательного исследования слабостей хэш-функции Lan Manager и протокола MS-CHAP. Далее приводятся подробности оптимизированной атаки:

Р₀-Р₁₃ - байты пароля. Н₀-Н₁₅ - байты хэш-функции Lan Manager, которая преобразуется в 21-байтовый ключ К₀-К₂₀. S- фиксированная константа, используемая в хэш-функции Lan Manager. Вызов С и 24-байтовый отклик R_o-R₂3. Злоумышленник может знать C и R и хочет найти Р.

Попробуйте все возможные комбинации К₁₄, К₁₅. Правильное значение выделяется, когда С превращается в R₁₆, ..., R₂₃ с ключом К₁₄, К₁₅, 0,0,0,0,0. На это уходит примерно 2¹⁵ операций.
Попробуйте вероятные значения Р₇,...,Р₁₃. Неверные значения можно быстро отбросить путем шифрования S и проверки совпадения последних двух байт полученного значения с К₁₄ и К₁₅. (Так отбрасываются все биты 1 в 2¹⁶ неверных вариантах). Каждый оставшийся вариант Р₇,...,Р₁₃ предоставляет значение-кандидат для К₈,...,К₁₃. Чтобы проверить значение-кандидат, проверьте все возможные значения К₇, чтобы увидеть, есть ли такое, при котором С шифруется в R₈,...,R₁₅ при значении-кандидате К₈,...,К₁₅. Если есть такое К₇, то догадка для Р₇,...,Р₁₃ почти наверняка верна. Если нет, то надо выбрать другое значение для Р₇,...,Р₁₃. Если существуют N вероятных вариантов Р₇,...,Р₁₃, то подбор верного значения можно провести за N тестовых шифрований.
Обратите внимание, что поскольку в протоколе нет индивидуальной настройки, эта атака может быть существенно ускорена с помощью замены время/память. Если есть N заранее вычисленных тестовых шифрований, то восстановление верного значения Р₇,...,Р₁₃ потребует N/2¹⁶ операций.
После нахождения Р₇,...,Р₁₃, восстановление Р₀,...,Р₆ требует М попыток, где М - число вероятных значений Р₀,...,Р₆. Опять же, поскольку нет индивидуальной настройки, атака может быть выполнена за N/2⁸ попыток при М предварительно вычисленных значениях.

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

5. Криптоанализ МРРЕ 5.1 Описание МРРЕ

Протокол шифрования в одноранговых сетях (МРРЕ) обеспечивает методологию для шифрования пакетов РРТР. Он предполагает существование секретного ключа, известного обоим участникам соединения, и использует поточный шифр RC4 с 40- либо 128-разрядным ключом. Такой метод установки использования МРРЕ является одной из функций протокола управления сжатием РРР (ССР) и описан в приложении С. После установки режима работы начинается сеанс РРР по передаче пакетов зашифрованных данных. Важно отметить, что шифруются только те пакеты РРР, номера протоколов которых лежат в диапазоне 0x0021-0x00fa. Все остальные пакеты передаются без шифрования, даже если шифрование разрешено. Типы пакетов, шифрование которых осуществляется/не осуществляется, регламентируются документом RFC 1700. Для любых пакетов не обеспечивается аутентификация.

В МРРЕ 40-битовый ключ RC4 определяется следующим образом:

Генерация определяющего 64-битового ключа из хэш-функции Lan Manager пароля пользователя (известного пользователю и серверу) с помощью SHA.
Установка старших 24 бит ключа в значение 0xD1269E.

128-битовый ключ RC4 определяется следующим образом:

Объединение хэша Windows NT и 64-битового случайного значения, выданного сервером при работе по протоколу MS-CHAP. Данное число посылается клиенту по протоколу обмена, потому оно известно и клиенту, и серверу.
Генерация определяющего 128-битового ключа из результатов предыдущего этапа с помощью SHA.

Результирующий ключ используется для инициализации RC4 обычным способом, а затем для шифрования байт данных. После каждых 256 пакетов - МРРЕ поддерживает счетчик, в котором фиксируется число пакетов - генерируется новый ключ RC4 по следующим правилам:

Генерация определяющего ключа - 64-битового для 40-битового шифрования и 128-битового для 128-битового шифрования - путем хэширования предыдущего ключа и исходного ключа с помощью SHA.
Если требуется 40-битовый ключ, то установка старших 24 бит ключа в значение 0xD1269E.

Длина типичного пакета РРТР составляет 200 байт, включая заголовок.

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

5.2 Восстановление ключа

В МРРЕ степень защиты ключа не превышает степень защиты пароля. Большая часть паролей имеет существенно меньше 40 бит безопасности и раскрываются с помощью словарных атак. Хэш-функция Lan Manager еще боле уязвима: с учетом максимальной длины порции, ограниченного алфавита и отсутствия символов нижнего регистра, невозможно сгенерировать 128-битовый ключ, даже если пользователь хочет это сделать. В документации по МРРЕ описывается флаг для вычисления 40-битового ключа RC4 на основании хэш-функции Windows NT, а не Lan Manager, но эта функция еще не реализована. Нет способов вычисления 128-битового ключа RC4 на основании хэш-функции Windows NT, хотя такой вариант был бы более безопасным (хотя существенно менее безопасным, чем 128-битовый случайный ключ.)

В любом случае, общая степень защиты составляет не 40 или 128 бит, а количество бит энтропии пароля. На основании экспериментальных данных получено, что английскому языку свойственна энтропия 1,3 бита на символ. Изменения регистра, цифры и специальные символы существенно повышают это значение. Любая атака, которая использует словарь слабых паролей, может быть способна прочитать зашифрованный МРРРЕ трафик. Кроме того, стилизованные заголовки в пакете РРР облегчают сбор известных текстов и базы для проверки угаданного ключа.

40-битовый алгоритм RC4 подвержен более серьезным уязвимостям. Поскольку не предусмотрена индивидуальная настройка, атакующий может подготовить словарь зашифрованных заголовков РРР, а затем быстро найти данный зашифрованный текст в словаре. При поиске мест в пакетах МРРЕ, где может содержаться незашифрованный текст, атакующий может воспользоваться множеством связей по SMB и NetBIOS, которые происходят при стандартных соединениях Microsoft.

Более того, тот же 40-битовый ключ RC4 генерируется всякий раз, когда пользователь инициализирует протокол РРТР. Поскольку RC4 представляет собой способ шифрования с обратной связью по выходу, то просто взломать шифр за два сеанса. Серьезная уязвимость отмечается в большей части свежих спецификаций МРРЕ, хотя она исчезла из предыдущей версии. Ни в одной версии документации Microsoft не указано, что один и тот же ключ используется как в прямом, так и в обратном направлении, что гарантирует, что для шифрования двух разных текстов используется один и тот же поток ключей.

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

5.3 Атаки переворота битов

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

5.4. Атака путем ресинхронизации

Если в процессе передачи теряется пакет, либо приходит пакет с неверным номером в заголовке МРРЕ, то происходит ресинхронизация ключа. Сторона, принявшая неверный пакет, посылает отправителю запрос на ресинхронизацию. По принятию данного запроса, отправитель реинициализирует таблицы RC4 и устанавливает бит "сброшен" (flushed) в заголовке МРРЕ. Если система обнаруживает в пакете установленный бит "сброшен", она реинициализирует свои таблицы RC4 и устанавливает счетчик пакетов в соответствии с полученным значением.

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

6 Другие атаки на MS-PPTP

Несмотря на то, что атаки на протоколы MS-CHAP и МРРЕ приводят к полному отрицанию полезности и безопасности MS PPTP, необходимо упомянуть о нескольких интересных атаках.

6.1 Пассивный мониторинг

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

Путем установки стандартных средств просмотра и расшифровки общественных линий связи от серверов Microsoft PPTP была получена следующая информация:

IP-адрес клиента
IP-адрес сервера
Количество доступных на сервере виртуальных каналов РРТР
Версия RAS клиента
Имя клиента NetBIOS
Идентификация производителя клиента
Идентификация производителя сервера
IP-адрес клиента во внутреннем виртуальном туннеле
Внутренние DNS-сервера, обслуживающие клиента
Имя пользователя на клиенте
Достаточно информации для получения значений хэш-функций паролей пользователей
Достаточно информации для получения начального значения МРРЕ
Текущее значение шифрованного пакета для клиента перед реинициализацией RC4
Текущее значение шифрованного пакета для сервера перед реинициализацией RC4

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

6.2 Перехват переговоров РРР

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

Подмена конфигурационного пакета, описывающего DNS-сервер, позволяет направить всю систему распознавания имен на ложный сервер имен.

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

6.3 Канал управления и отказ в обслуживании на сервере

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

Другой причиной была реализация Microsoft канала управления. Мы быстро обнаружили, что просто нарушить работоспособность машины Windows NT с сервером РРТР, иногда это приводило к появлению "голубого экрана". На самом деле, трудно провести тестирование канала управления и не нарушить работу сервера РРТР. Настолько трудно, что большая часть атак, предпринимавшихс для изучения теоретических проблем безопасности канала управления, приводила к нарушению работы сервера раньше, чем атаки могли сработать. Далее описана малая часть тестов, приводивших к нарушению работы Windows NT Server с установленным Service Pack 3:

Цикл по пакетам PPTP_CLEAR_CALL_REQUEST с тем, чтобы пройти 16-разрядное пространство идентификаторов вызова.
Перебор всех возможных и невозможных значений, которые могут содержаться в поле Тип пакета заголовка пакета РРТР.
Передача недопустимых значений в заголовке пакета управления РРТР.

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

6.4. Потенциальные утечки информации на клиенте.

Клиент Windows 95 не выполняет требуемую очистку буферов, и потому допускается утечка информации в сообщениях протокола. Хотя в документации РРТР сказано, что в пакете PPTP_START_SESSION_REQUEST символы после имени компьютера и производителя должны быть сброшены в 0х00, Windows 95 этого не делает.

080: 0000 6c6f 6361 6c00 0000 3e1e 02c1 0000 ..local...>.....

096: 0000 85c4 03c1 acd9 3fc1 121e 02c1 2e00 ........?.......

112: 0000 2e00 0000 9c1b 02c1 0000 0000 0000 ................

128: 0000 88ed 3ac1 2026 02c1 1049 05c1 0b00 ....:. &...I....

144: 0000 3978 00c0 280e 3dc1 9c1b 02c1 041e ..9x..(........

160: 02c1 0e00 0000 121e 02c1 2e00 0000 2e00 ................

176: 0000 3dad 06c1 74ed 3ac1 1c53 05c1 9c1b .....t.:..S....

192: 02c1 041e 02c1 0e00 0000 121e 02c1 2e00 ................

208: 0000 ..

Выше показаны символы, содержащиеся после имени компьютера и строки производителя. В байтах 82-86 содержится имя компьютера, которое для клиента Windows 95 всегда равняется "local". Байт 113 - то место, где должна содержатьс строка производителя. При просмотре аналогичного пакета Windows NT обнаружено, что все символы "мусора" сброшены в 0х00.

Существует очевидная возможность утечки информации в зависимости от того, как и где используются и размещаются структуры данных и что происходит на клиентской системе. Для оценки данной утечки информации необходимо провести дальнейший анализ кода Windows 95.

7 Выводы

Реализация РРТР от Microsoft уязвима с точки зрения реализации, и обладает серьезными недостатками с точки зрения протокола. Протокол аутентификации имеет известные уязвимости, на которые указывалось не только здесь, но и в группах, например, L0pht. Шифрование выполнено неверно, в данной реализации используется поточный шифр с обратной связью по выходу, хотя более уместен был бы блоковый шифр "шифр-блок-цепочка" (CBC). Чтобы связать слабую аутентификацию с плохим шифрованием Microsoft задал ключ шифрования как функцию от пароля пользователя вместо использования сильного алгоритма обмена ключами типа Диффи-Хеллмана или ЕКЕ. Наконец, канал управления не аутентифицируется и не сильно защищен.

Мы не потратили много времени на изучение механизмов обеспечения локальных IP-адресов клиентов и того, как Microsoft пытался и смог ли он учесть уязвимость представления клиента с двумя адресами. Тем не менее, мы обнаружили проблемы с нестандартными масками подсети и внутренним трафиком туннеля, отправленного от РРТР сервера. Разработчики, будьте внимательны!

Наконец, хочется подчеркнуть, что криптоанализ не подвергал сомнению протокол РРТР (?), но лишь реализацию протокола от Microsoft. Хотя Microsoft использует свои собственные расширения (MS-CHAP, МРРЕ, МРРС) в РРР секции РРТР, стандарт РРТР не требует этого. Производители могут включить расширения Microsoft в свои продукты по соображениям совместимости, но они не обязаны ограничиватьс их использованием и, наверное, реализуют более безопасные решения. Конечно, новые расширения для корректной работы должны поддерживаться как клиентом, так и сервером.

В ходе экспериментов выяснилось, что некоторые клиенты Windows 95 поддерживают аутентификацию Microsoft, а некоторые - нет. Мы не смогли оценить различия или определить способы, позволяющие понять, поддерживает ли данная система Windows 95 аутентификацию Microsoft. Если протокол не поддерживается, то пункт в диалоговом окне недоступен. Это ограничение соответствует заявлению Microsoft, что Windows 95 не обеспечивает безопасность, и что те пользователи, которым она нужна, должны перейти на NT. Тем не менее, Microsoft заявлял, что Windows 95 не обрабатывает хэш Windows NT, а использует хэш Lan Manager. Однако клиенты Windows 95 передают обе хэш-функции. Из нашего анализа кода Windows 95 неясно, почему шифрование нельзя реализовать в клиентах Windows 95.

В документации Microsoft сказано, что длина паролей Windows NT может достигать 128 символов, и хэш-функция Windows NT принимает пароли такой длины. Однако, диспетчер пользователей ограничивает длину паролей до 14 символов. В документации MS-СНАР также упоминается это ограничение, которое подтвердилось в ходе экспериментов.

Известное средство хакеров, L0pthcrack, автоматизирует процесс подбора пароля по его хэш-значению. На Pentium Pro 200, L0phtcrack 2.0 может проверить файл с 200 паролями за минуту с использованием 8 мегабaйтного словаря паролей.

Мы не исследовали ни сам генератор псевдослучайных чисел, ни его криптографическую стойкость.

8. Благодарности Мы хотели бы поблагодарить Mark Chen, Chris Hall, Brad Kemp, Paul Jones, Ben McCann, Mark Seiden, Inderpreet Singh, David Wagner и Wray West за их ценные замечания.

Литература

[Ave98] Aventail Corp., 1998. http://www.aventail.com.

[BV98] L. Blunk and J. Vollbrecht, ``PPP Extensible Authentication Protocol (EAP),'' Network Working Group, RFC 2284, Mar 1998. ftp://ftp.isi.edu/in-notes/rfc2284.txt.

[CK78] T.M. Cover and R.C. King, ``A Convergent Gambling Estimate of Entropy,'' IEEE Transactions on Information Theory, v. IT-24, n. 4, Jul 1978, pp. 413--421.

[Fre98] FreeGate Corp., 1998. http://www.freegate.com.

[HLFT94] S. Hanks, T. Li, D. Farinacci, and P. Traina, ``Generic Routing Encapsulation (GRE),'' Network Working Group, RFC 1701, Oct. 1994. ftp://ftp.isi.edu/in-notes/rfc1701.txt.

[Hob97] Hobbit, ``CIFS: Common Insecurities Fail Scrutiny,'' Avian Research, Jan 1997. http://www.avian.org.

[HPV+97] K. Hamzeh, G.S. Pall, W. Verthein, J. Taarud, and W.A. Little, ``Point-to-Point Tunneling Protocol,'' Internet Draft, IETF, Jul 1997. http://www.ietf.org/internet-drafts/draft-ietf-pppext-pptp-02.txt.

[KSWH98] J. Kelsey, B. Schneier, D. Wagner, and C. Hall, ``Cryptanalytic Attacks on Pseudorandom Number Generators,'' Fast Software Encryption: 5th International Workshop, Springer-Verlag,1998, pp. 168-188

[Kle90] D.V. Klein, ``Foiling the Cracker: A Security of, and Implications to, Password Security,'' Proceedings of the USENIX UNIX Security Workshop, Aug 1990, pp. 5--14.

[Kli98] S. Klinger, ``Microsoft PPTP and RRAS for Windows NT Server 4.0,'' LAN Times, Feb ??, 1998. http://www.lantimes.com/98/98feb/802b065b.html.

[L97a] L0pht Heavy Industries Inc, L0phtcrack, 1997. http://www.L0pht.com/L0phtcrack/.

[L97b] L0pht Heavy Industries Inc, ``A L0phtCrack Technical Rant,'' Jul 1997. http://www.l0pht.com/l0phtcrack/rant.html.

[LS92] B. Lloyd and W. Simpson, ``PPP Authentication Protocols,'' Network Working Group, RFC 1334, Oct 1992. ftp://ftp.isi.edu/in-notes/rfc1334.txt.

[Mey96] G. Meyer, ``The PPP Encryption Control Protocol (ECP),'' Network Working Group, RFC 1968, Jun 1996. ftp://ftp.isi.edu/in-notes/rfc1968.txt.

[Mic96a] Microsoft Corpotation, Advanced Windows NT Concepts, New Riders Publishing, 1996. Relevent chapter at http://www.microsoft.com/communications/nrpptp.htm.

[Mic96b] Microsoft Corporation, ``Pont-to-Point Tunneling Protocol (PPTP) Frequently Asked Questions,'' Jul 1996. http://premium.microsoft.com/sdn/library/bkgrnd/html/pptpfax.htm.

[Mic97] Microsoft Corporation, ``Response to Security Issues Raised by the L0phtcrack Tool,'' Apr 1997, http://www.microsoft.com/security/l0phtcrack.htm.

[Mic98] Microsoft Corporation, ``Clarification on the L0phtcrack 2.0 Tool.'' Mar 1998.

http://www.microsoft.com.security/l0pht20.htm.

[MB97] P. Mudge and Y. Benjamin, ``Deja Vu All Over Again,'' Byte, Nov 1997.

http://www.byte.com/art/9711/sec6/art3.htm.

[NBS77] National Bureau of Standards, NBS FIPS PUB 46, ``Data Encryption Standard,'' National Bureau of Standards, U.S. Department of Commerce, Jan 1977.

[NIST93] National Institute of Standards and Technology, ``Secure Hash Standard,'' U.S. Department of Commerce, May 93.

[Pal96a] G.S. Pall, ``Microsoft Point-to-Point Compression (MPPC) Protocol,'' Network Working Group Internet Draft, Jul 1996.

[Pal96b] G.S. Pall, ``Microsoft Point-to-Point Encryption (MPPE) Protocol,'' Network Working Group Internet Draft, Jul 1996.

[PZ98] G.S. Pall and G. Zorn, ``Microsoft Point-to-Point Encryption (MPPE) Protocol,'' Network Working Group, Internet Draft, IETF, Mar 1998. http://www.ietf.org/internet-drafts/draft-ietf-pppext-mppe-00.txt.

[Ran96] D. Rand, ``The PPP Compression Control Protocol (CCP),'' Network Working Group, RFC 1962, Jun 1996. ftp://ftp.isi.edu/in-notes/rfc1962.txt.

[RP94] J. Reynolds and J. Postel, ``Assigned Numbers,'' Networking Group, Std 2, RFC 1700, Oct 1994. ftp://ftp.isi.edu/in-notes/rfc1700.txt.

[Riv91] R.L. Rivest, ``The MD4 Message Digest Algorithm,'' Advances in Cryptology --- CRYPTO '90 Proceedings, Springer-Verlag, 1991, pp. 303--311.

[Sch96] B. Schneier Applied Cryptography, 2nd Edition, John Wiley & Sons, 1996.

[Sim94] W. Simpson, ``The Point-to-Point Protocol (PPP),'' Network Working Group, STD 51, RFC 1661,, Jul 1994. ftp://ftp.isi.edu/in-notes/rfc1661.txt.

[Sim96] W. Simpson, ``PPP Challenge Handshake Authentication Protocol (CHAP)'' Network Working Group, RFC 1334, Aug 1996. ftp://ftp.isi.edu/in-notes/rfc1994.txt.

[ZC98] G. Zorn and S. Cobb, ``Microsoft PPP CHAP Extensions,'' Network Working Group Internet Draft, Mar 1998. http://www.ietf.org/internet-drafts/draft-ietf-pppext-mschap-00.txt.

Источник: http://bezpeka.com/

<< Назад Далее >>