Wifi подключение по сертификату

Обновлено: 06.07.2024

Проблема защиты корпоративных данных с каждым годом все актуальнее. Все больше критических данных передается по беспроводным сетям, и информационная безопасность (ИБ) все больше зависит от квалификации ИТ-специалистов.

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

Wi-Fi — история хакерских успехов

Изначально в стандарт Wi-Fi 802.11 был заложен режим аутентификации WEP с алгоритмом шифрования RC4, который использует обычный статический или динамический ключ длиной 64 или 128 бит. Впервые WEP взломали в 2000 году. Популярному в те годы компьютеру с процессором Pentium 4 требовалось порядка 1 часа для дешифрации. Использование ресурсов современных облачных серверов и доступный мобильный интернет через 3G/LTE позволяет вскрыть защиту за считанные секунды.

Фото 1: Типы сетей в зависимости от надежности шифрования

В 2003 г. появился WPA с алгоритмом TKIP, который генерирует ключ для каждого пакета. Сегодня WPA-TKIP при определённом везении можно взломать за несколько часов. Например, летом 2015 г. бельгийские исследователи смогли перехватить зашифрованные cookie-файлы и за час получить доступ к компьютеру.

С 2006 г. обязательным стандартом для Wi-Fi устройств является поддержка более совершенного алгоритма шифрования WPA2 AES. Он более надежен, поэтому предыдущие алгоритмы использовать нет смысла. Однако, как и TKIP этот алгоритм также может быть взломан "в лоб" с помощью перебора вариантов пароля с использованием словаря. Специальное ПО при помощи массированный DDoS-атаки выводит из строя точку доступа. Далее, эмулирует работу точки с тем же SSID. После попытки авторизации «жертвы» на такой точке, хакер получает хэш-функцию ключа PMK-R0. Следующим этапом запускается процесс подбора пароля. Простые пароли подбираются за несколько часов, в то время как на подбор сложных паролей может потребоваться несколько недель и даже месяцев.

Дополнительные меры защиты

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

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

Режим скрытого идентификатора сети SSID — популярный способ дополнительной защиты сети Wi-Fi. Каждая сеть имеет свой уникальный идентификатор SSID (название сети). В режиме скрытого идентификатора клиентские устройства не видят сеть в списке доступных. Подключиться к сети в режиме Hide SSID можно, только если точно знаешь ее идентификатор и есть заранее готовый профиль подключения.

Обнаружить скрытую сеть довольно просто с помощью таких утилит, как Kismet. Cамо по себе подключение к скрытой сети выдает ее существование и идентификатор хакеру. Дальше сценарий взлома такой же, как и в обычных сетях Wi-Fi. Как видим, Hide SSID также не является надежным способом защиты, но при этом также создает проблемы. Прежде всего нужно вручную подключать новые устройства. К тому же стандарты Wi-Fi изначально предусматривали открытую трансляцию SSID, поэтому у большинства устройств возникнут проблемы с автоподключением к Hide SSID. В целом использование Hide SSID нецелесообразно.

Отличия между персональной (PSK) и корпоративной (Enterprise)

Следует различать разные подходы к обеспечению персональных и корпоративных сетей. Дома и в небольших офисах обычно применяют PSK (Pre-Shared Key) — пароль от 8 символов. Этот пароль у всех одинаковый и часто слишком простой, поэтому уязвим для подбора или утечек (увольнение сотрудника, пропавший ноутбук, неосторожно приклеенный на виду стикер с паролем и т. п.). Даже самые последние алгоритмы шифрования при использовании PSK не гарантируют надежной защиты и поэтому в серьезных сетях не применяется. Корпоративные решения используют для аутентификации динамический ключ, который меняется каждую сессию для каждого пользователя. Ключ может периодически обновляться во время сессии с помощью сервера авторизации — обычно это сервер RADIUS.

WPA2-Enterprise + 802.1X и сертификаты безопасности — самая надежная защита

Корпоративные сети с шифрованием WPA2-Enterprise строятся на аутентификации по протоколу 802.1x через RADIUS-сервер. Протокол 802.1x (EAPOL) определяет методы отправки и приема запроса данных аутентификации и обычно встроен в операционные системы и специальные программные пакеты.

802.1x предполагает три роли в сети:

клиент (supplicant) - клиентское устройство, которому нужен доступ в сеть;
cервер аутентификации (обычно RADIUS);
аутентификатор — роутер/коммутатор, который соединяет множество клиентских устройств с сервером аутентификации и отключает/подключает клиенсткие устройства.

Фото 3: Схема работы WPA2-Enterprise 802.1x

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

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

Фото 2: Внутренние протоколы (методы) EAP

Использование сервера RADIUS позволяет отказаться от PSK и генерировать индивидуальные ключи, валидные только для конкретной сессии подключения. Проще говоря, ключи шифрования невозможно извлечь из клиентского устройства. Защита от перехвата пакетов обеспечивается с помощью шифрования по разным внутренним протоколам EAP, каждый из которых имеет свои особенности. Так, протокол EAP-FAST позволяет авторизоваться по логину и паролю, а PEAP-GTC — по специальному токену (карта доступа, карточки с одноразовыми паролями, флешки и т. п.). Протоколы PEAP-MSCHAPv2 и EAP-TLS проводят авторизацию по клиентским сертификатам.

Максимальную защиту сети Wi-Fi обеспечивает только WPA2-Enterprise и цифровые сертификаты безопасности в сочетании с протоколом EAP-TLS или EAP-TTLS. Сертификат — это заранее сгенерированные файлы на сервере RADIUS и клиентском устройстве. Клиент и сервер аутентификации взаимно проверяют эти файлы, тем самым гарантируется защита от несанкционированных подключений с чужих устройств и ложных точек доступа. Протоколы EAP-TTL/TTLS входят в стандарт 802.1X и используют для обмена данными между клиентом и RADIUS инфраструктуру открытых ключей (PKI). PKI для авторизации использует секретный ключ (знает пользователь) и открытый ключ (хранится в сертификате, потенциально известен всем). Сочетание эти ключей обеспечивает надежную аутентификацию.

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

Сегодня WPA2-Enterprise в сочетании с сертификатами безопасности обеспечивает надежную защиту корпоративных Wi-Fi-сетей. При правильной настройке и использовании взломать такую защиту практически невозможно "с улицы", то есть без физического доступа к авторизованным клиентским устройствам. Тем не менее, администраторы сетей иногда допускают ошибки, которые оставляют злоумышленниками "лазейки" для проникновения в сеть. Проблема осложняется доступностью софта для взлома и пошаговых инструкций, которыми могут воспользоваться даже дилетанты.

Хакерский софт доступен всем

WPA2-Enterprise с аутентификацией по логину и паролю без использования сертификатов можно взломать с помощью хакерского дистрибутива Kali Linux и Wi-Fi-карточки в режиме точки доступа. Суть взлома — в создании поддельной точки доступа с сервером RADIUS для получения пакетов EAP и логина защищенной сети. Создать поддельную точку сегодня не проблема с помощью таких утилит, как Mana Toolkit, встроенной в Kali.

Фото 4: Обычно злоумышленники используют смартфон с подключенной к нему карточкой и мобильной версией Kali NetHunter

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

В результате хакер получает доступ к учетным записям для входа в корпоративную сеть Wi-Fi или VPN.

"Человек посередине" — основная угроза

Хакерская атака под названием "человек посередине" (Man in the middle или сокращенно MITM) является наиболее серьезной угрозой для правильно организованной WPA2-Enterprise с сертификатами безопасности.

Фото 5: Суть атаки "человек посередине”: хакер превращает прямое защищенное соединение в два разных с хакерским клиентом посередине

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

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

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

Защита от посредника

Атака MITM не является абсолютным оружием хакера. При соблюдении всех требований ИБ внедрение посредника невозможно.

Администратор обязан регулярно проверять сетевой трафик на предмет подозрительной активности, включая задержки при передаче пакетов. В зонах, где осуществляются критичные транзакции, рекомендуется устанавливать Wi-Fi-сенсоры для выявления хакерской активности в режиме реального времени. Подробнее читайте в статье «Мониторинг Wi-Fi сети»

Вывод: Поэтому на первое место выходит подготовка специалистов и эффективное использование существующих технологий защиты данных. Так, шифрование WPA2-Enterprise может стать непробиваемым барьером для злоумышленников, если знать, как правильно его организовать. Доверьте вопрос информационной безопасности профессионалам!

Очень часто, в качестве реализации LDAP используется Active Directory. С данным сервером не возникаем много сложностей, так как существует огромная практика у администраторов и, как следствие, множество рабочей документации. Мы же рассмотрим другую реализацию — FreeIPA, при работе с которой есть нюансы. В моих примерах команды выполняются на Rocky Linux (CentOS / Red Hat).

Предполагается, что у нас уже установлены следующие сервисы:

Наша инструкция будет разбита на подразделы:

Как будет выполняться настройка

Для выполнения задачи по настройке авторизации на WiFi через RADIUS сервер может использоваться множество решений. Какие-то из них более удобные в настройке, какие-то в эксплуатации. В данной инструкции сделан упор на максимальное удобство со стороны пользователя.

Фреймворк аутентификации EAP включает в себя множество протоколов. Одним из самых популярных является PEAP (EAP-TLS) — его поддержка реализована в большинстве устройств. Данный протокол, в свою очередь, работает совместно с такими методами аутентификации, как EAP-MSCHAPv2 и EAP-GTС.

Для работы с FreeIPA нам подойдет MSCHAP, но для его использования потребуется небольшое расширение схемы и добавление поля хранения хэша пароля. Сервер RADIUS (в нашем случае, Freeradius) будет его вытаскивать и сравнивать с хэшем введенного пароля.

Перейдем к реализации задуманного.

Настройка FreeIPA

На стороне сервера LDAP нам необходимо:

Добавить атрибут ipaNTHash для хранения в нем хэша пароля
Создать роли и привилегии для возможности читать данный атрибут.
Создать сервисный аккаунт и предоставить ему права на чтение атрибута ipaNTHash.

В нашем примере будет использоваться домен dmosk.local.

Настройка атрибута ipaNTHash

Начнем с установки пакета:

yum install freeipa-server-trust-ad

Данный пакет необходим для запуска утилиты ipa-adtrust-install, с помощью которой мы создаем атрибут ipaNTHash:

Команда запросит пароль для пользователя admin:

После мы получим предупреждение о существовании файла smb.conf и о том, что команда ipa-adtrust-install его заменит. Соглашаемся на изменения:

WARNING: The smb.conf already exists. Running ipa-adtrust-install will break your existing samba configuration.

Do you wish to continue? [no]: yes

На все последующие вопросы можно ответить по умолчанию, нажав Enter. Ждем окончания операции. Теперь при смене пароля или создании нового пользователя, у учетной записи будет добавлен атрибут ipaNTHash.

Чтобы в этом убедиться нужно поменяем пароль у существующей записи:

ipa user-mod test --password

* в данном примере мы работаем с учетной записью test.

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

Теперь проверяем, что у нашей учетной записи есть нужный нам атрибут:

* в данном примере мы обращаемся к серверу LDAP localhost и вытаскиваем данные по учетной записи test. Чтобы не получать множество данных, мы фильтруем, вытаскивая только атрибут ipaNTHash.

Система запросит пароль — вводим его от учетной записи администратора FreeIPA. Мы должны получить, примерно, такой ответ:

Enter LDAP Password:
dn: uid=test,cn=users,cn=compat,dc=dmosk,dc=local

dn: uid=test,cn=users,cn=accounts,dc=dmosk,dc=local
ipaNTHash:: b1hf+P9igLWcziUv21AOuA==

* где b1hf+P9igLWcziUv21AOuA== — хэш пароля.

Создание ролей и привилегий

Нам необходимо создать настройки безопасности для возможности предоставить доступ к атрибуту ipaNTHash. Разберемся с этим по шагам.

1. Создаем разрешение:

ipaNTHash reader — имя разрешения.
attrs — атрибут, для которого действует разрешение.
type — тип учетной записи, для которой будет применимо разрешение.
right — уровень прав.

2. Добавляем привилегию:

* данной командой мы создадим привилегию с именем Radius services.

3. Добавим созданное разрешение в созданную привилегию:

4. Создадим роль:

* где Radius server — имя роли.

5. Добавим в созданную роль созданную привилегию:

Итого, мы получили роль Radius server, в которую входит привилегия Radius services, в которую входит разрешение ipaNTHash reader для чтения атрибута ipaNTHash.

Создание и настройка сервисной учетной записи

Создадим пользователя, с помощью которого Freeradius будет подключаться к FreeIPA и получать доступ к атрибуту ipaNTHash.

* где freeradius — имя сервисного аккаунта; ipa-server.dmosk.local — FQDN-имя сервера IPA.

* в данном примере файл будет сохранен по пути /root/radiusd.keytab.

kinit -t /root/radiusd.keytab -k freeradius/ipa-server.dmosk.local

Мы должны увидеть что-то на подобие:

Default principal: freeradius/ipa-server.dmosk.local@DMOSK.LOCAL

Valid starting Expires Service principal
08/23/2021 12:48:14 08/24/2021 12:48:14 krbtgt/DMOSK.LOCAL@DMOSK.LOCAL

Также выполним who a mi в LDAP:

ldapwhoami -Y GSSAPI

Ответ должен быть на подобие:

SASL/GSSAPI authentication started
SASL username: freeradius/ipa-server.dmosk.local@DMOSK.LOCAL
SASL SSF: 256
SASL data security layer installed.
dn: krbprincipalname=freeradius/ipa-server.dmosk.local@dmosk.local,cn=services,cn=accounts,dc=dmosk,dc=local

* freeradius/ipa-server.dmosk.local@dmosk.local,cn=services,cn=accounts,dc=dmosk,dc=local — полный путь учетной записи в LDAP. Он нам понадобиться для дальнейшей настройки.

Теперь зададим пароль для сервисного аккаунта. Для этого создаем ldif файл:

dn: krbprincipalname=freeradius/ipa-server.dmosk.local@dmosk.local,cn=services,cn=accounts,dc=dmosk,dc=local
changetype: modify
add: objectClass
objectClass: simpleSecurityObject
-
add: userPassword
userPassword: my_password

* где krbprincipalname указывает на полный путь к сервисной учетной записи, а userPassword — пароль, который мы хотим ей задать.

Применяем настройки из файла:

modifying entry "krbprincipalname=freeradius/ipa-server.dmosk.local@dmosk.local,cn=services,cn=accounts,dc=dmosk,dc=local"

Проверим, выполнив запрос:

Система от нас потребует пароль для сервисной учетной записи (в нашем примере, my_password) — вводим его. Мы должны получить что-то на подобие:

Снова получаем билет для привилегированного пользователя:

Добавляем сервисный аккаунт в роль Radius server:

С настройкой FreeIPA мы закончили и можем переходить к настройке Freeradius.

Настройка сервера RADIUS

Устанавливаем дополнение к Freeradius для работы с ldap:

yum install freeradius-ldap

Активируем установленный модуль:

ln -s /etc/raddb/mods-available/ldap /etc/raddb/mods-enabled/ldap

Открываем на редактирование файл ldap:

Внесем некоторые изменения в настройки конфигурации:

server — перечисление наших серверов FreeIPA. Если их несколько, создаем несколько строчек.
identity — путь до учетной записи пользователя, под которой мы будем подключаться к Freeradius.
password — пароль для учетной записи, которую мы используем в опции identity.
base_dn — базовый путь в ldap для поиска объектов.
control:NT-Password — атрибут, в котором Freeradius должен найти пароль пользователя.

Настраиваем модуль EAP:

Достаточно внести изменение в одной строке:

systemctl restart radiusd

Для проверки устанавливаем утилиту freeradius-utils:

yum install freeradius-utils

И вводим команду:

radtest -t mschap test test12345 localhost:1812 0 testing123

* где test и test12345 — логин и пароль для учетной записи во FreeIPA. Именно для нее в данной инструкции выше был создан хэш пароля.

Мы должны увидеть что-то на подобие:

Проверка прошла успешно.

Что дальше

Описание настройки WiFi не входит в рамки данной инструкции. В двух словах, выполняем следующие шаги:

На WiFi контроллере или точке доступа указываем тип проверки подлинности с использованием RADIUS. В качестве последнего указываем его IP-адрес, а также парольную фразу, которую планируем использовать для проверки подлинности.
На Freeradius в конфигурационном файле clients.conf создаем раздел с указанием IP-адреса устройства, с которого будет отправляться запрос на проверку подлинности, также указываем парольную фразу.
Подключаемся к WiFi с использованием учетных данных, хранимых во FreeIPA.

Возможные проблемы

Для диагностики проблем, удобнее всего запускать freeradius в режиме дебага. Для этого сначала остановим его:

systemctl stop radiusd

После запускаем радиус командой:

После проведения диагностики не забываем снова запустить сервис:

systemctl start radiusd

Рассмотрим проблему, с которой столкнулся я.

eap_peap: ERROR: TLS Alert write:fatal:protocol version

При подключении некоторых устройств мы можем получить ошибку:

(18) eap_peap: ERROR: TLS Alert write:fatal:protocol version
tls: TLS_accept: Error in error
(18) eap_peap: ERROR: Failed in __FUNCTION__ (SSL_read): error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol
(18) eap_peap: ERROR: System call (I/O) error (-1)
(18) eap_peap: ERROR: TLS receive handshake failed during operation
(18) eap_peap: ERROR: [eaptls process] = fail
(18) eap: ERROR: Failed continuing EAP PEAP (25) session. EAP sub-module failed

Причина: по умолчанию, eap настроен на использование TLS версии 1.2. Если устройство, с которого мы подключаемся использует версию протокола выше или ниже, то мы получим ошибку.

Решение: в настройках RADIUS-сервера есть возможность указать, какие версии TLS должны поддерживаться. Открываем конфигурационный файл:

Приводим к следующему виду опции:

* в данном примере указаны не самые лучшие параметры с точки зрения безопасности. Лучше всего отказаться от TLS 1.0 и 1.1. — для этого, как правило, необходимо установить обновления на клиентском устройстве.

В статье рассказывается о взломе WPA2-Enterprise с аутентификация через RADIUS-сервер.

Автор: Дмитрий Трифонов, исследовательский центр Positive Technologies

Статей о взломе Wi-Fi в Интернете достаточно много, но большинство из них касаются режима работы WEP/WPA(2)-Personal, в котором необходимо перехватить процедуру «рукопожатия» клиента и Wi-Fi-точки. Во многих корпоративных Wi-Fi-сетях используется режим безопасности WPA2-Enterprise, с аутентификацией по логину и паролю — как наименее затратный способ. При этом аутентификация осуществляется с помощью RADIUS-сервера.

ОС клиента устанавливает соединение с RADIUS-сервером, используя шифрование при помощи TLS, а проверка подлинности в основном происходит при помощи протокола MS-CHAPv2.

Для тестирования на проникновение в такой сети мы можем создать поддельную Wi-Fi-точку с RADIUS-сервером — и получить логин, запрос и ответ, которые использует MS-CHAPv2. Этого достаточно для дальнейшего брутфорса пароля.

Нам необходимы Kali Linux и карточка, поддерживающая работу в режиме Access Point, что можно проверить при помощи команды iw list, нас интересует строка:

Еще год назад нужно было проделать множество манипуляций для того, чтобы подделать такую точку доступа с возможностью получения учетных данных. Необходимо было пропатчить, собрать и правильно настроить определенные версии hostapd и FreeRADIUS. В августе 2014 года появился набор инструментов Mana Toolkit, позволяющий автоматизировать множество векторов атак на беспроводные клиенты.

Поскольку использовать ноутбук не всегда удобно, будем использовать более компактный вариант — телефон. Кроме того, можно использовать Raspberry Pi + FruityWifi. WiFi Pineapple, к сожалению, не поддерживает Mana.

Подключаем Wi-Fi-карточку через USB-OTG-кабель. Запускаем приложение NetHunter.

Первое, что необходимо сделать, — определить интерфейс подключенной Wi-Fi-карточки. Для этого в меню выбираем Kali Launcher и запускаем Wifite.

В нашем случае это интерфейс wlan1.

В меню выбираем MANA Evil Access Point.

интерфейс, определенный на предыдущем шаге (interface),
SSID взламываемой Wi-Fi-сети (ssid)
использование протокола аутентификации 802.1x(ieee8021x=1),
опции wpa(wpa) (0 = без WPA/WPA2; 1 = WPA; 2 = IEEE 802.11i/RSN (WPA2); 3 = WPA и WPA2),
список принимаемых алгоритмов управления ключами (wpa_key_mgmt=WPA-EAP),
набор принимаемых алгоритмов шифрования (wpa_pairwise),

В нашем распоряжении комплект из пяти скриптов, которые запускают, помимо точки доступа, дополнительные утилиты для осуществления MITM-атак. Нас интересует скрипт mana-noupstream-eap, который предназначен для точек с аутентификацией 802.1x.

По умолчанию скрипт пытается «сбрутить» полученный хеш, подключить клиент и провести MITM-атаку. Поскольку взлом хешей на телефоне — не самая лучшая идея, комментируем ненужные строки, добавляем команду, которая будет записывать перехваченные данные в файл на флешке, — и запускаем Mana.

Как только Wi-Fi-клиент окажется достаточно близко к нашей точке доступа, он попробует аутентифицироваться на ней. Хорошее место для засады — у входа в офис или бизнес-центр, время — начало или конец рабочего дня, когда потенциальные жертвы минуют проходную.

Останавливаем Mana и проверяем, что же мы поймали.

Формат полученных данных: Protocol | Login | Challenge | Response

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

В этом нам помогут:

— Asleap (используется в оригинальном скрипте),
— John the Ripper (требуется слегка модифицировать полученные хеши: cat HASHES.txt | sed 's/://g' | sed 's/$[^|]*$|$[^|]*$|$[^|]*$|$[^|]*$/\2:$NETNTLM$\3$\4/' > john-HASHES.txt)

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

Как оказалось, перехватить хеши пользователей можно не всегда. Настольные ОС (Windows, MacOS, Linux), а также пользователи iOS защищены лучше всего. При первичном подключении ОС спрашивает, доверяете ли вы сертификату, который используется RADIUS-сервером в данной Wi-Fi-сети. При подмене легитимной точки доступа ОС спросит про доверие к новому сертификату, который использует RADIUS-сервер. Это произойдет даже при использовании сертификата, выданного доверенным центром сертификации (Thawte, Verisign).

При использовании устройств на базе Android сертификат по умолчанию не проверяется, но существует возможность указать корневой сертификат, который может использоваться в данной Wi-Fi-сети.

Устройства на основе Windows Phone по умолчанию проверяют сертификат. Также доступны опции проверки сертификата сервера:

Резюмируя все сказанное, эксперты Positive Technologies рекомендуют следующие меры безопасности:

Уже были описаны некоторые примеры организации корпоративного WiFi. Здесь я распишу как реализовал подобное решение и проблемы с которыми пришлось столкнуться при подключении на разных устройствах. Будем использовать уже имеющейся LDAP с заведенными пользователями, поднимем FreeRadius и настроим WPA2-Enterprise на контроллере Ubnt. Вроде все просто. Посмотрим…

Немного о методах EAP

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

Из википедии:

Сами методы:

LEAP — проприетарный протокол, разработан CISCO. Найдены уязвимости. В настоящее время не рекомендуется использовать
EAP-TLS — хорошо поддерживаемый среди вендоров беспроводных соединений. Является безопасным протоколом, поскольку является преемником SSL стандартов. Настройка клиентской достаточно сложна. Нужен клиентский сертификат помимо пароля. Поддерживается во многих системах
EAP-TTLS — широко поддерживается во многих системах, предлагает хорошую безопасность, используя PKI сертификаты только на сервере аутентификации
EAP-MD5 — другой открытый стандарт. Предлагает минимальную безопасность. Уязвим, не поддерживает взаимную аутентификацию и генерацию ключей
EAP-IKEv2 — основан на Internet Key Exchange Protocol version 2. Обеспечивает взаимную аутентификацию и установление сеансового ключа между клиентом и сервером
PEAP — совместное решение CISCO, Microsoft и RSA Security как открытый стандарт. Широко доступен в продуктах, обеспечивает очень хорошую безопасность. Схож с EAP-TTLS, требуя только сертификат на серверной стороне
PEAPv0/EAP-MSCHAPv2 — после EAP-TLS, это второй широко используемый стандарт в мире. Используется клиент-серверная взаимосвязь в Microsoft, Cisco, Apple, Linux
PEAPv1/EAP-GTC — создан Cisco как альтернатива PEAPv0/EAP-MSCHAPv2. Не защищает аутентификационные данные в любом случае. Не поддерживаются в Windows OS
EAP-FAST — метод, разработанный Cisco для исправления недостатков LEAP. Использует Protected Access Credential (PAC). Полностью не доработан

Из всего этого разнообразия, выбор все таки не велик. От метода аутентификации требовалось: хорошая безопасность, поддержка на всех устройствах (Windows 10, macOS, Linux, Android, iOS) и, собственно, чем проще, тем лучше. Поэтому выбор пал на EAP-TTLS в связке с протоколом PAP.
Возможно возникнет вопрос — Зачем же использовать PAP? ведь он передает пароли в открытом виде?

Да, все верно. Общение между FreeRadius и FreeIPA будет проходить именно в так. В режиме дебага можно отследить как отправляются username и password. Да и пусть отправляются, только у вас есть доступ к серверу FreeRadius.

Подробнее о работе EAP-TTLS можно почитать тут

FreeRADIUS

FreeRadius будем поднимать на CentOS 7.6. Здесь ничего сложного, ставим обычным способом.

После этого FreeRadius уже работает. Можно в /etc/raddb/users расскоментировать строчку

Запустить в сервер в режиме дебага

И делаем тестовое подключение с localhost

Получили ответ Received Access-Accept Id 115 from 127.0.0.1:1812 to 127.0.0.1:56081 length 20, значит все хорошо. Идем дальше.

Подключаем модуль ldap.

И сразу его изменим. Нам нужно, чтобы FreeRadius мог обращаться к FreeIPA

mods-enabled/ldap

Перезапускаем radius-сервер и проверяем синхронизацию пользователей LDAP:

Редактируем eap в mods-enabled/eap
Здесь добавим два экземпляра eap. Они будут отличаться только сертификатами и ключами. Чуть ниже объясню, почему именно так

mods-enabled/eap

Далее редактируем site-enabled/default. Интересуют разделы authorize и authenticate.

site-enabled/default

В секции authorize убираем все модули, которые нам не нужны. Оставляем только ldap. Добавляем проверку клиента по username. Именно для этого мы добавляли выше два экземпляра eap.

Multi EAPДело в том, что подключая некоторые устройства мы будем использовать системные сертификаты и указывать домен. У нас есть сертификат и ключ от доверенного центра сертификации. Лично по моему мнению такая процедура подключения проще, чем кидать на каждое устройство самоподписанный сертификат. Но и без самоподписанных сертификатов все же не получилось уйти. Samsung девайсы и Android =< 6 версии не умеют использовать системные сертификаты. Поэтому для них создаем отдельный экземпляр eap-guest с самоподписанными сертификатами. Для всех других устройств будем использовать eap-client c доверенным сертификатом. User-Name определяется по полю Anonymous при подключении устройства. Разрешено использовать только 3 значения: Guest, Client и пустое поле. Остальное все отбрасывается. Это настраиватся в политиках. Пример приведу чуть позже

Отредактируем секции authorize и authenticate в site-enabled/inner-tunnel

site-enabled/inner-tunnel

Далее нужно прописать в политиках, какие имена можно использовать для анонимного входа. Редактируем policy.d/filter.

Нужно найти строчки похожие на это:

И ниже в elsif добавить нужные значения:

Теперь нам нужно переместиться в директорию certs. Сюда нужно положить ключ и сертификат от доверенного центра сертификации, который у нас уже есть и нужно сгенерировать самоподписанные сертификаты для eap-guest.

Изменяем параметры в файле ca.cnf.

Такие же значения прописываем в файле server.cnf. Меняем только
commonName:

Готово. Полученные server.crt и server.key у нас уже прописаны выше в eap-guest.

И последнее, добавим наши точки доступа в файл client.conf. У меня их 7. Чтобы не добавлять каждую точку отдельно, пропишем только сеть в котороый они находятся (у меня точки доступа находятся в отдельном VLAN).

Контроллер Ubiquiti

На контроллере поднимаем отдельную сеть. Пусть будет 192.168.2.0/24
Идем в настройки -> профиль. Cоздаем новый:

Прописываем адрес и порт radius-сервера и пароль, который прописывали в файле clients.conf:

Создаем новое имя беспроводной сети. В качестве метода аутентификации выбираем WPA-EAP (Enterprise) и указываем созданный radius-профиль:

Все сохраняем, применяем и идем дальше.

Настройка клиентов

Начнем с самого сложного!

Windows 10

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

Далее нужно создать новое подключение. Для этого идем в параметры сети и Интернет -> Центр управления сетями и общим доступом -> Создание и настройка нового подключения или сети:

Вручную прописываем имя сети и меняем тип безопасности. После нажимаем на изменить параметры подключения и во владке Безопасность выбираем проверку подлинности сети — EAP-TTLS.

Заходим в параметры, прописываем конфиденциальность аутентификации — client. В качестве доверенного центра сертификации выбираем добавленный нами сертификат, ставим галочку «Не выдавать пользователю приглашение, если не удается авторизовать сервер» и метод проверки подлинности выбираем — незашифрованный пароль (PAP).

Далее заходим в дополнительные параметры, ставим галочку на «Укажите режим проверки подлинности». Выбираем пункт «Проверка подлинности пользователя» и нажимаем на сохранить учетные данные. Здесь надо будет ввести username_ldap и password_ldap

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

Linux

Я проверял на Ubuntu 18.04, 18.10, Fedora 29, 30.

Для начала, скачиваем себе сертификат. Я не нашел в Linux, есть ли возможность использовать системные сертификаты и есть ли там вообще такое хранилище.

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

Все подключение делается в одном окне. Выбираем нашу сеть:

anonymous — client
domain — домен, на который выпущен сертификат

Android

non-Samsung

C 7 версии при подключении WiFi можно использовать системные сертификаты, указав только домен:

domain — домен, на который выпущен сертификат
anonymous — client

Samsung

Как уже писал выше, Samsung-устройства не умеют использовать системные сертификаты при подключении WiFi, и у них нет возможности подключаться по домену. Поэтому надо вручную добавить корневой сертификат центра сертификации (ca.pem, берем на Radius сервере). Вот здесь будет использовать самоподписанный.

Скачиваем сертификат себе на устройство и устанавливаем его.

Установка сертификата

При этом, надо будет установить рисунок разблокировки экрана, пин-код или пароль, если он еще не установлен:

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

Когда сертификат установлен, можно переходить к подключению:

сертификат — указываем тот, который устанавливали
анонимный пользователь — guest

macOS

Яблочные устройства из коробки могут подключаться только к EAP-TLS, но все равно нужно закидывать им сертификат. Чтобы указать другой метод подключения, нужно воспользоваться Apple Configurator 2. Соответственно нужно предварительно скачать его на мак, создать новый профиль и добавить все необходимые настройки WiFi.

Apple Configurator

Здесь указываем имя своей сети
Security Type — WPA2 Enterprise
Accepted EAP Types — TTLS
User Name и Password — оставляем пустыми
Inner Authentication — PAP
Outer Identity — client

Вкладка Trust. Здесь указываем наш домен

Все. Профиль можно сохранять, подписывать и распространять на устройства

После того, как профиль готов, его нужно скачать на мак и установить. В процессе установки нужно будет указать usernmae_ldap и password_ldap пользователя:

Процесс аналогичен macOS. Нужно использовать профиль (можно прям такой же как для macOS. Как создавать профиль в Apple Configurator, смотреть выше).

Скачиваем профиль, устанавливаем, вводим учетные данные, подключаемся:

На этом все. Мы настроили Radius сервер, синхронизировали его с FreeIPA и указали точкам доступа Ubiquiti использовать WPA2-EAP.

Возможные вопросы

В: как передавать профиль/сертификат сотруднику?

О: Все сертификаты/профили я храню на фтп с доступом через веб. Поднял гостевую сеть с ограничением по скорости и доступом только в интернет, за исключением фтп.
Аутентификация держится 2 дня, после чего сбрасывается и клиент остается без интернета. Т.о. когда сотрудник хочет подключиться к WiFi, сначало он подключается к гостевой сети, заходит на фтп, скачивает нужный ему сертификат или профиль, устанавливает их, и после может подключаться к корпоративной сети.

В: почему не использовать схему с MSCHAPv2? она же более безопасная!

О: во-первых, такая схема хорошо работает на NPS (Windows Network Policy System), в нашей реализации необходимо дополнительно настраивать LDAP (FreeIpa) и хранить хэши паролей на сервере. Доп. настройки делать не желательно, т.к. это может привести к различным проблемам сихронизации УЗ. Во-вторых, хеш представляет собой MD4, так что это не особо повышает безопасность

В: можно ли авторизовывать устройтсва по mac-адресам?

О: НЕТ, это не безопасно, злоумышленник может подменить мак-адреса, и тем более авторизация по мак-адресам не поддерживается на многих устройствах

В: зачем вообще все эти сертификаты использовать? можно же и без них подключаться

О: сертификаты используются, чтобы авторизовать сервер. Т.е. устройство при подключении проверяет тот ли это сервер, которому можно доверять или нет. Если тот, то аутентификация проходит дальше, если нет, соединение закрывается. Можно подключаться без сертификатов, но если злоумышленик или сосед поднимет у себя дома radius-сервер и точку доступа с таким же именем как у нас, он сможет легко перехватить учетные данные пользователя (не забываем, что они передаются в открытом виде). А когда используется сертификат, враг увидит у себя в логах только наши вымышленные User-Name — guest или client и ошибку типа — Unknown CA Certificate

еще немного про macOSОбычно на macOS переустановка системы делается через интернет. В режиме восстановления мак надо подключить к WiFi, и здесь не сработает ни наш корпоративный WiFi, ни гостевая сеть. Лично я поднял еще одну сеть, обычную по WPA2-PSK, скрытую, только для технических операций. Либо еще можно заранее сделать загрузочную флешку с системой. Но если мак после 2015 года, надо будет еще найдит адаптер для это флешки)

Читайте также: