- Ad freeradius google authenticator. установка с нуля для cisco anyconnect и не только
- Freeradius
- Linux
- Non-samsung
- Samsung
- Server.cnf
- Windows 10
- Возможные вопросы
- Клиент для проверки подключения
- Контроллер ubiquiti
- Конфигурация сервера freeradius
- Настройка клиентов
- Немного о методах eap
- О методах аутентификации
- Точка доступа
- Установка и настройка сервера radius
- Заключение
Ad freeradius google authenticator. установка с нуля для cisco anyconnect и не только
Итак, у нас встала задача включить двухфакторную аутентификацию для Cisco AnyconnectVPN и некоторых других пакетов. Общими у всех задач есть одно – они умеют аутентифицироваться в Radius.
Существует большое количество платных решений (например Cisco DUO), но – платное не значит лучше и зачем платить больше?
Да, критики скажут — это очередная статья как натянуть сову на глобус или как подружить FreeRadius, MS Acitve Directory и Google Authenticator. Но есть нюансы, которые я хочу показать.
Во-первых. Мне нужно несколько типов аутентификации. Я это реализую нестандартными настройками FreeRadius и получу на трех разных портах одного сервера три типа аутентификации:
- ADlogin, ADPasswordGoogleAuth (логин из AD, паролем выступает склееная фраза из пароля в AD и цифр от GoogleAuth )
- ADlogin, ADPassword (стандартный вариант логина и пароля от AD, по сути чисто технический вариант, но нужен для Anyconnect)
- ADLogin, GoogleAuth ( логин из AD, пароль цифры GoogleAuth. Так сказать GoogleAuthenticator в чистом виде)
Во-вторых.
Используя модуль shellinabox предоставляем возможность клиенту создать себе GoogleAuth токен самостоятельно, при этом не понижая уровня безопасности системы. Возможно не самое красивое решение – но 100% работающее.
И в-третьих. Мне так и не удалось победить проблему: когда истекает время жизни пароля в AD, FreeRadius перестает считать его валидным и пробрасывает дальше ошибку. Т.е перестает предлагать сменить пароль в такой ситуации. Решение shellinabox позволяет решить эту проблему, предлагая пользователю в такой ситуации зайти на URL shellinabox.
Все проверено на Centos7, но без особых изменений зайдет на любом RedHat дистрибутиве и с непринципиальными модификациями на Ubuntu и FreeBSD. Другие дистрибуты не проверял, но общий смысл обязан сохранится.
1) Включаем NTP – если не включено. Можно заменить любой аналогичной службой, важно чтобы время было синхронизировано корректно.
a) Установка
#yum install ntpb) Включение на старте и сразу запуск
#systemctl enable –now ntpdc) Проверка
#ntpq –p2)
Включаем Linux в AD.
Я предпочитаю SSSD.
a) Установка
#yum install –y sssd realmd oddjob oddjob-mkhomedir adcli samba-common samba-common-tools krb5-workstation openldap-clients policycoreutils-pythonЗдесь есть один момент. Возможно спецы меня поправят и часть пакетов лишняя именно для этой задачи, но я предпочитаю стандартизацию и именно такой набор работает у меня везде.
b) собственно ввод в домен
#realm join my.domen --user=имя-пользователя-доменаc) проверка
#realm listДолжно вывести нечто подобное:
my.domen
type: kerberos
realm-name: MY.DOMEN
domain-name: my.domen
configured: kerberos-member
server-software: active-directory
client-software: sssd
required-package: oddjob
required-package: oddjob-mkhomedir
required-package: sssd
required-package: adcli
required-package: samba-common-tools
login-formats: %U
login-policy: allow-permitted-logins
permitted-logins:
d) редактируем
/etc/sssd/sssd.conf
для ограничения по AD группам, которым можно ходить на эту машину. Читай – аутентифицироваться в AD с этой машины.
use_fully_qualified_names = False
simple_allow_groups = GroupLinuxAdmins@my.domen, GroupUseVPN@my.domen
ad_gpo_ignore_unreadable = Trueпервая группа
GroupLinuxAdmins@my.domen
, члены которой могут администрировать систему, вторая —
GroupUseVPN@my.domen
– это те кто потом будет ходить в VPN.
e) Запускаем sssd
#chown root.root /etc/sssd/sssd.conf&&chmod 600 /etc/sssd/sssd.conf
#systemctl restart sssd
Убеждаемся что sssd работает корректно:
#id имя-пользователя-доменаДолжно вывести список групп AD в которые входит пользователь домена «имя-пользователя-домена»
f) Разрешаем админам sudo
#echo "%GroupLinuxAdmins@my.domen ALL=(ALL) ALL" > /etc/sudoers.d/sudoadmin
#chown root.root /etc/sudoers.d/sudoadmin&&chmod 600 /etc/sudoers.d/sudoadming) Выключаем root для ssh, разрешаем ssh только членам группы
GroupLinuxAdmins@my.domen
.
Редактируем /etc/ssh/sshd_config, изменив или добавив строки ниже. ВАЖНО! Тут и дальше имена групп нужно использовать только в нижнем регистре.
PermitRootLogin no
AllowGroups grouplinuxadminsИ перезапускаем sshd
#systemctl restart sshd3)
Установка FreeRadius
a) Собственно установка
#yum -y install freeradius freeradius-utils
#ln -s /etc/raddb/mods-available/pam /etc/raddb/mods-enabled/pamb) Редактируем
/etc/raddb/sites-enabled/default
:
Находим в разделе authenticate строку вида
# pamи убираем комментарий в начале строки ( символ # )
c) Редактируем
/etc/raddb/sites-enabled/users
:
добавляем строку
DEFAULT Auth-Type := PAMd) Собственно базовый радиус установлен. Только для
localhost
но уже можем проверять.
Парольное слово в Radius для localhost по умолчанию: testing123
# radtest userVPN ‘password_for_userVPN’ localhost 0 testing123Правильный ответ будет если в конце ответа
Received Access-AcceptПри неправильном пароле (тоже стоит обязательно проверить).
В конце ответа будет
Received Access-Rejectи дальше
(0) -: Expected Access-Accept got Access-Rejecte) Добавляем систему, которой можно обращаться к Radius, т.е устройство, которое будет организовывать Cisco Anyconnect VPN. У меня это Cisco Firepower. Пусть у него будет IP 10.10.10.5.
Добавляем в файл /etc/raddb/clients.conf
client ftd {
ipaddr = 10.10.10.5
secret = secretFTD
}
f) Редактируем
/etc/raddb/radiusd.conf
. данная настройка нужна для того, чтобы Google Authenticator мог проверить файл $HOME/.google_authenticator для всех пользователей.
находим
user = radiusd
group = radiusd
и меняем на
user = root
group = root
И включаем радиус со стартом
#systemctl enable --now radiusdg) Radius установлен. Если при установке FreeRadius что-то идет не так, очень полезная возможность консольной работы с FreeRadius. Для этого стопаем службу и запускаем Radius в консольном режиме с debug
#systemctl stop radius
#radiusd -Xx4)
Ставим Google Autenticator
a) К сожалению, я не знаю как подружить Google Authenticator и selinux. Поэтому отключаем.
Файл
/etc/selinux/config
меняем:
SELINUX=enforcingна
SELINUX=permissiveПосле чего
#setenforce 0а лучше вообще перезагрузить машину
b)
#yum install –y epel-release
#yum install –y google-authenticator5) Модифицируем FreeRadius для 3 типов аутентификации
a) Редактируем /etc/raddb/mods-enabled/pam, добавляя строки
pam radius11812{
pam_auth = radiusd_ad
}
pam radius21812{
pam_auth = radiusd_ga
}b) В папке
/etc/pam.d
копируем ‘pam’ настройки для разных типов аутентификации
Для «просто в AD» берем системную
#ln –s /etc/pam.d/password-auth-ac /etc/pam.d/radiusd_adДля просто GoogleAuth пишем самостоятельно в
/etc/pam.d/radiusd_ga
#%PAM-1.0
#
auth required pam_google_authenticator.so nullok
auth required pam_permit.so
account required pam_nologin.so
account include password-auth
password include password-auth
session include password-auth!!! очень важный момент
. При такой конфигурации если отсутствует привязка пользователя в профиле к GoogleAuth то такой пользователь считается валидным. Если нужно без ввода цифр GoogleAuth не пускать вообще, не зависимо от привязки, то нужно в первой строке убрать nullok а вторую строку убрать вообще.
c) Копируем /etc/raddb/sites-enabled/default для двух дополнительных портов
# cp /etc/raddb/sites-enabled/default /etc/raddb/sites-enabled/radius11812
# cp /etc/raddb/sites-enabled/default /etc/raddb/sites-enabled/radius21812d) Редактируем /etc/raddb/sites-enabled/radius11812
Меняем имя
server defaultна
server radius11812Находим в секции listen
type = auth
port = 0 меняем на
type = auth
port = 11812 Находим в следующей секции listen
type = acct
port = 0 меняем на
type = acct
port = 11812 Остальные секции listen я рекомендую удалить. Если конечно вы не планируете работать с IP v6
Находим в разделе authenticate строку вида
pamи заменяем на
Auth-Type pam {
radius11812
}e) Аналогично
/etc/raddb/sites-enabled/radius21812
Находим в разделе authenticate строку вида
pamи заменяем на
Auth-Type pam {
Radius21812
}6)
Устанавливаем shellinabox
a)
#yum install –y shellinabox
#yum enable –now shellinaboxb) В принципе этого достаточно. Но некоторые любят красоту ;). Тогда дополнительно ставим еще figlet, и шрифт rebel.tlf ( взять с репозитория https://github.com/xero/figlet-fonts и положить в /usr/share/figlet ).
c) Добавляем вызов логики генерации GoogleAuth токена для всех пользователей
#echo ‘. /usr/local/etc/radius_user_profiles.sh’ >> /etc/skel/.bash_profiled) Создаем
/usr/local/etc/radius_user_profiles.sh
( то вариант с украшательствами)
#!/bin/bash
# Set groups for vpn, etc.
#
# !!! Names of groups without caps letters !!!
#
VPNissuer="MyCompany"
GROUP_VPN="groupusevpn"
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
# User specific environment and startup programs
# Make several commands available from user shell
# for group VPN that use 2FA Google authenticator
if [[ -n $(id $USER | grep $GROUP_VPN) ]]
then
clear
[[ ! -d $HOME/bin ]] && mkdir $HOME/bin
[[ ! -f $HOME/bin/id ]] && ln -s /usr/bin/id $HOME/bin/id
[[ ! -f $HOME/bin/google-auth ]] && ln -s /usr/bin/google-authenticator $HOME/bin/google-auth
[[ ! -f $HOME/bin/grep ]] && ln -s /usr/bin/grep $HOME/bin/grep
[[ ! -f $HOME/bin/figlet ]] && ln -s /usr/bin/figlet $HOME/bin/figlet
[[ ! -f $HOME/bin/rebel.tlf ]] && ln -s /usr/share/figlet/rebel.tlf $HOME/bin/rebel.tlf
[[ ! -f $HOME/bin/sleep ]] && ln -s /usr/bin/sleep $HOME/bin/sleep
# Set PATH env to <home user directory>/bin
PATH=$HOME/bin
export PATH
if [[ ! -e $HOME/.google_authenticator ]]
then
figlet -t -c -f $HOME/bin/rebel.tlf "Welcome to $VPNissuer GAuth setup portal"
sleep 1.5
echo "Please, run Google Authenticator to setup OTP and prepare to scan QR code.
If you don't have, please download that from market:
AppStore - https://apps.apple.com/us/app/google-authenticator/id388497605
Play Market - https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2&hl=en
"
sleep 1.5
google-auth -f -t -w 3 -r 3 -R 30 -d -e 1 -l "$VPNissuer" -i "$USER"
echo "Congratulations, now you can use an OTP token from application as a password to VPN."
logout
else
echo "You have already setup a Google Authenticator
"
logout
fi
fi
e) Устанавливаем разрешения на выполнение всем.
#chmod 755 /usr/local/etc/radius_user_profiles.shf) Можно файлы типа .google_authenticator вынести в отдельный каталог (по-умолчанию это файлы $HOME/.google_authenticator). Увеличивает ли это безопасность системы? Нет, а удобство — дело привычки. Для этого надо сделать несколько шагов:
7)
Теперь самое интересное.
Shellinabox это по-сути графическая web оболочка для шелла. Для того, чтоб не нарушить безопасность системы делаем отдельный sshd c ограничением по группе AD на нестандартном порту и направляем shellinabox на этот порт. Стандартный 22 остается для администраторов и снаружи недоступен.
a) Копируем systemd service скрипт и конфиг sshd:
#cp /usr/lib/systemd/system/sshd.service /usr/lib/systemd/system/sshd_web.service
#cp /etc/ssh/sshd/sshd_config /etc/ssh/sshd_web_configb) Редактируем /usr/lib/systemd/system/sshd_web.service заменяя строку
ExecStart=/usr/sbin/sshd -D $OPTIONSна
ExecStart=/usr/sbin/sshd -D -f /etc/ssh/sshd_web_config $OPTIONSc) Редактируем
/etc/ssh/sshd_web_config
добавляя или исправляя параметры:
port 2022
MaxAuthTries 3
MaxSessions 1
AllowGroups groupusevpnТаким образом мы запускаем дополнительный шелл sshd на порту 2022 не открывая его на firewall т.к обращения к нему исключительно по интерфейсу local.
d) Редактируем /etc/sysconfig/shellinaboxd изменив параметр на
OPTS=" -s /:SSH:localhost:2022"e) В папке
/var/lib/shellinabox
по умолчанию лежат самосгенеренные и самоподписанные сертификаты shellinabox. Лично у себя я установил дополнительно nginx в который внес реальные сертификаты ssl, вынеся shellinabox на порт 8443 ( любой нестандартный )
#yum install –y nginxКонфигурация для nginx:
server {
listen 443 ssl;
server_name shellinabox.my.domen;
add_header Strict-Transport-Security "max-age=15768000; includeSubDomains" always;
set $upstream https://localhost:8443;
proxy_intercept_errors on;
underscores_in_headers on;
location ~ ^/(.*) {
proxy_pass $upstream$request_uri;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_cache_bypass $http_upgrade;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
ssl_certificate /etc/ssl/fullchain.pem;
ssl_certificate_key /etc/ssl/ privkey.pem;
ssl_protocols TLSv1.2;
ssl_dhparam /etc/ssl/ssl-dhparams.pem;
}и в
/etc/sysconfig/shellinaboxd
меняем
PORT=8443f) Перезапускаем после всех изменений.
#systemctl daemon-reload
#systemctl enable –now sshd_web
#systemctl enable –now shellinaboxЕсли ставили nginx то
#systemctl enable –now nginxg) Открываем порты firewalld
firewall-cmd --new-zone=radius –permanent
firewall-cmd --zone=radius --add-source=10.10.10.5 --permanent
firewall-cmd --zone=radius --add-port=1812/udp --permanent
firewall-cmd --zone=radius --add-port=11812/udp --permanent
firewall-cmd --zone=radius --add-port=21812/udp --permanent
firewall-cmd --reload8)
Тестируем весь конструктор.
a) Заходим на shellinabox.my.domen
b) Логинимся пользователем VPN и получаем QR-код для GoogleAuth
c) Ставим на смартфон GoogleAuthenticator и сканим им QR-код.
d)
#radtest userVPN ‘password_for_userVPNXXXXXX’ localhost 0 testing123где XXXXXX – цифры с GoogleAuthenticator. Результат должен быть Received Access-Accept
e)
#radtest userVPN ‘password_for_userVPN’ localhost:11812 0 testing123Результат должен быть Received Access-Accept
f)
#radtest userVPN ‘XXXXXX’ localhost:21812 0 testing123 где XXXXXX – цифры с GoogleAuthenticator. Результат должен быть Received Access-Accept
9) Собственно VPN
a) Если все предыдущие этапы прошли успешно то прописываем сервер типа Radius c IP и портом 11812/UDP как первый фактор в CISCO AnyconnectVPN и его же с портом 21812/UDP как второй фактор.




b) Деплоим конфигурацию и проверяем.
Как понятно из процесса тестирования, те системы, которые не умеют отдельно спрашивать первый и второй фактор ( или мы не хотим факторы разделять специально) мы направляем на порт Radius 1812 и используем схему “пароль_AD”XXXXXX добавляя цифры с Google Authenticator сразу после пароля без пробела.
Незакрытые вопросы:
P.S. В статье использовались материалы
https://habr.com/ru/post/516362
, откуда взята идея shellinabox.
Freeradius
FreeRadius будем поднимать на CentOS 7.6. Здесь ничего сложного, ставим обычным способом.
yum install freeradius freeradius-utils freeradius-ldap -yИз пакетов ставится версия 3.0.13. Последнюю можно взять на
Linux
Я проверял на Ubuntu 18.04, 18.10, Fedora 29, 30.
Для начала, скачиваем себе сертификат. Я не нашел в Linux, есть ли возможность использовать системные сертификаты и есть ли там вообще такое хранилище.
Будем подключаться по домену. Поэтому нужен сертификат удостоверяющего центра, у которого был приобретен наш сертификат.
Все подключение делается в одном окне. Выбираем нашу сеть:

anonymous — clientdomain — домен, на который выпущен сертификат
Non-samsung
C 7 версии при подключении WiFi можно использовать системные сертификаты, указав только домен:

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

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

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

сертификат — указываем тот, который устанавливалианонимный пользователь — guest
Server.cnf
You need to edit client.cnf only if you are using EAP-TLS.
If not, then that file can be left as-is.
Once the ca.cnf and server.cnf files have been
edited, re-create the CA and Server certificates as before in the EAP howto. This process will destroy any existing
certificates, so you should make a backup of this directory before
continuing.
$ cd /etc/raddb/certs$ make
Depending on the version of FreeRADIUS, the output may be make:
Nothing to be done for `all’. In that case, you will have to
remove some files manually, and then re-create the certificates:
$ rm -f *csr *key$ make
Otherwise, you should see OpenSSL creating the keys and
certificates, as shown below:
openssl req -new -x509 -keyout ca.key -out ca.pem -config ./ca.cnf
Generating a 2048 bit RSA private key……………………………………………etc.
Windows 10
Сложность сводится к тому, что Windows пока еще не умеет подключаться к корпоративному WiFi по домену. Поэтому приходится вручную закидывать наш сертификат в хранилище доверенных сертификатов. Здесь можно использовать как самоподписанный так и от центра сертификации. Я буду использовать второй.
Далее нужно создать новое подключение. Для этого идем в параметры сети и Интернет -> Центр управления сетями и общим доступом -> Создание и настройка нового подключения или сети:

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

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

Возможные вопросы
В: как передавать профиль/сертификат сотруднику?
О: Все сертификаты/профили я храню на фтп с доступом через веб. Поднял гостевую сеть с ограничением по скорости и доступом только в интернет, за исключением фтп. Аутентификация держится 2 дня, после чего сбрасывается и клиент остается без интернета. Т.о. когда сотрудник хочет подключиться к WiFi, сначало он подключается к гостевой сети, заходит на фтп, скачивает нужный ему сертификат или профиль, устанавливает их, и после может подключаться к корпоративной сети.
В: почему не использовать схему с MSCHAPv2? она же более безопасная!
О: во-первых, такая схема хорошо работает на NPS (Windows Network Policy System), в нашей реализации необходимо дополнительно настраивать LDAP (FreeIpa) и хранить хэши паролей на сервере. Доп. настройки делать не желательно, т.к. это может привести к различным проблемам сихронизации УЗ. Во-вторых, хеш представляет собой MD4, так что это не особо повышает безопасность
В: можно ли авторизовывать устройтсва по mac-адресам?
О: НЕТ, это не безопасно, злоумышленник может подменить мак-адреса, и тем более авторизация по мак-адресам не поддерживается на многих устройствах
В: зачем вообще все эти сертификаты использовать? можно же и без них подключаться
Клиент для проверки подключения
В качестве платформы для проверки клиентского подключения — наиболее наглядно данный процесс отображается на последних версиях Mac OS X.
Контроллер ubiquiti
На контроллере поднимаем отдельную сеть. Пусть будет 192.168.2.0/24Идем в настройки -> профиль. Cоздаем новый:

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

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

Все сохраняем, применяем и идем дальше.
Конфигурация сервера freeradius
Это виртуальная машина со следующими характеристиками: RAM 1GB, 1xCPU, виртуальный диск 20GB (можно меньше, лишь бы разместилась операционная система и необходимые пакеты).
В роли гипервизора — Oracle Virtual Box 6.1.18
В качестве гостевой операционной системы для экспериментов использовался дистрибутив Oracle Linux 6.3. В принципе, можно выбрать любой другой дистрибутив, если нет специальных ограничений.
FreeRADIUS — из стандартного репозитория.
Настройка клиентов
Начнем с самого сложного!
Немного о методах eap
Прежде чем приступить к выполнению задачи, надо определиться какой метод аутентификации будем использовать в нашем решении.
Из википедии:
EAP — фреймворк аутентификации, который часто используется в беспроводных сетях и соединениях точка-точка. Формат был впервые описан в RFC 3748 и обновлён в RFC 5247.
EAP используется для выбора метода аутентификации, передачи ключей и обработки этих ключей подключаемыми модулями называемыми методами EAP. Существует множество методов EAP, как определенных вместе с самим EAP, так и выпущенных отдельными производителями. EAP не определяет канальный уровень, он только определяет формат сообщений. Каждый протокол использующий EAP имеет собственный протокол инкапсуляции сообщений 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? ведь он передает пароли в открытом виде?
О методах аутентификации
В предыдущих статьях, в частности: Особенности защиты беспроводных и проводных сетей. Часть 1 — Прямые меры защиты, — мы рассказывали о различных методах аутентификации.
Более или менее надёжным можно считать алгоритм защиты начиная с WPA2, а самый современный протокол аутентификации — WPA3, входящий в состав новшеств от WiFi 6. Но так как не все ещё перешли на WiFi 6, то WPA2 пока остаётся актуальным.
В свою очередь технология WPA2 подразделяется на два направления: WPA2 Personal и WPA2 Enterprise.
Вариант WPA2 Personal с PSK (Pre-Shared Key), проще говоря, «один-ключ-на все-устройства» используется в небольших (обычно в домашних сетях). При этом единственный ключ (длинная символьная строка не менее 8 символов) хранится на самой точке доступа и на каждом устройстве, подключаемом к беспроводной сети. Когда просят дать «пароль от WiFi», это тот самый ключ и есть.
При увеличении числа клиентов обслуживание такой беспроводной сети превращается в кошмар для сисадмина.
Если кто-то из пользователей со скандалом уволился, умудрился потерять ноутбук или случайно переслал ключ по почте (выложил общем чате, на форуме и так далее) …
В общем, при малейшем подозрении на компрометацию ключа выход может быть только один — сгенерировать новый ключ и заменить его везде: на всех точках доступа и у всех пользователей на всех устройствах. При этом нужно обязательно проверить работает ли доступ у всех пользователей на всех корпоративных (а иногда и личных) девайсах, а ещё ответить на 1000 и 1 вопрос из разряда: «А зачем?», «А почему так произошло?», «А что, теперь постоянно менять придётся?» и так далее и тому подобное.
Точка доступа
В качестве клиента (точки доступа) — используется модель Zyxel NWA210AX. Это современное устройство, поддерживающее интеграцию в облачной системе Zyxel Nebula и обладающее массой других достоинств.
Несмотря на то, что NWA210AX поддерживает новые протоколы безопасности WiFi 6 и может использовать сервис аутентификации Nebula, в нашем случае она прекрасно выступит в качестве устройства доступа в сети WPA 2 Enterprise.

Рисунок 2. Точка доступа NWA210AX.
Установка и настройка сервера radius
Перед установкой рекомендуется настроить файервольные правила, в частности, разрешить порты 1812, 1813, а также, если понадобиться, выполнить настройку SELinux. Нашей целью было показать взаимодействие с RADIUS, поэтому такие нюансы, как настройка сети, файервола, других средств безопасности выходят за рамки статьи и остаются за кадром. И мы сразу переходим к установке FreeRADIUS.
sudo install freeradius freeradius-utils -y
Обратите внимание, мы устанавливаем не только пакет freeradius, но и дополнительные инструменты freeradius-utils.
Из этого пакета нам понадобится утилита radclient для проверки пользователей.
После окончания установки настроим запуск сервиса при старте системы:
sudo systemctl enable radiusd
Для проверки запустим FreeRADIUS:
sudo systemctl start radiusd
Проверим его состояние:
sudo systemctl status radiusd
Пример ответа системы:
radiusd.service - FreeRADIUS high performance RADIUS server.
Loaded: loaded (/usr/lib/systemd/system/radiusd.service; enabled; vendor preset: disabled)
Active: active (running) since Thu 2021-02-04 13:36:11 EST; 7min ago
Process: 953 ExecStart=/usr/sbin/radiusd -d /etc/raddb (code=exited, status=0/SUCCESS)
Process: 872 ExecStartPre=/usr/sbin/radiusd -C (code=exited, status=0/SUCCESS)
Process: 821 ExecStartPre=/bin/sh /etc/raddb/certs/bootstrap (code=exited, status=0/SUCCESS)
Process: 810 ExecStartPre=/bin/chown -R radiusd.radiusd /var/run/radiusd (code=exited, status=0/SUCCESS)
Main PID: 970 (radiusd)
Tasks: 6 (limit: 12425)
Memory: 82.9M
CGroup: /system.slice/radiusd.service
└─970 /usr/sbin/radiusd -d /etc/raddb
Feb 04 13:36:10 localhost.localdomain systemd[1]: Starting FreeRADIUS high performance RADIUS server....
Feb 04 13:36:10 localhost.localdomain sh[821]: server.pem: OK
Feb 04 13:36:11 localhost.localdomain systemd[1]: Started FreeRADIUS high performance RADIUS server..Дополнительно проверить можно командой:
sudo ps aux | grep radiusd
Ответ системы должен быть примерно таким:
root 7586 0.0 0.2 112716 2200 pts/1 R 01:28 0:00 grep --color=auto radiusd
radiusd 13320 0.0 1.5 513536 15420 ? Ssl Dec23 0:00 /usr/sbin/radiusd -d /etc/raddbДля настройки нам понадобится только два конфигурационных файла из каталога /etc/raddb:
Заключение
Как видим, даже для такого простого примера нам потребовалось довольно много действий. Теперь представьте, что точек в сети довольно много. Позже мы рассмотрим, как можно обеспечить подобную систему аутентификации с меньшими усилиями благодаря облачной систем управления Zyxel Nebula или встроенным аппаратным решениям Zyxel.
