Настройка WPA2 Enterprise c RADIUS

Настройка WPA2 Enterprise c RADIUS Сертификаты

Ad freeradius google authenticator. установка с нуля для cisco anyconnect и не только

Итак, у нас встала задача включить двухфакторную аутентификацию для Cisco AnyconnectVPN и некоторых других пакетов. Общими у всех задач есть одно – они умеют аутентифицироваться в Radius.

Существует большое количество платных решений (например Cisco DUO), но – платное не значит лучше и зачем платить больше?

Да, критики скажут — это очередная статья как натянуть сову на глобус или как подружить FreeRadius, MS Acitve Directory и Google Authenticator. Но есть нюансы, которые я хочу показать.

Во-первых. Мне нужно несколько типов аутентификации. Я это реализую нестандартными настройками FreeRadius и получу на трех разных портах одного сервера три типа аутентификации:

  1. ADlogin, ADPasswordGoogleAuth (логин из AD, паролем выступает склееная фраза из пароля в AD и цифр от GoogleAuth )
  2. ADlogin, ADPassword (стандартный вариант логина и пароля от AD, по сути чисто технический вариант, но нужен для Anyconnect)
  3. ADLogin, GoogleAuth ( логин из AD, пароль цифры GoogleAuth. Так сказать GoogleAuthenticator в чистом виде)

Во-вторых.

Используя модуль shellinabox предоставляем возможность клиенту создать себе GoogleAuth токен самостоятельно, при этом не понижая уровня безопасности системы. Возможно не самое красивое решение – но 100% работающее.

И в-третьих. Мне так и не удалось победить проблему: когда истекает время жизни пароля в AD, FreeRadius перестает считать его валидным и пробрасывает дальше ошибку. Т.е перестает предлагать сменить пароль в такой ситуации. Решение shellinabox позволяет решить эту проблему, предлагая пользователю в такой ситуации зайти на URL shellinabox.

Все проверено на Centos7, но без особых изменений зайдет на любом RedHat дистрибутиве и с непринципиальными модификациями на Ubuntu и FreeBSD. Другие дистрибуты не проверял, но общий смысл обязан сохранится.

1) Включаем NTP – если не включено. Можно заменить любой аналогичной службой, важно чтобы время было синхронизировано корректно.

a) Установка

#yum install ntp

b) Включение на старте и сразу запуск

#systemctl enable –now ntpd

c) Проверка

#ntpq –p

2)

Включаем 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/sudoadmin

g) Выключаем root для ssh, разрешаем ssh только членам группы

GroupLinuxAdmins@my.domen

.

Редактируем /etc/ssh/sshd_config, изменив или добавив строки ниже. ВАЖНО! Тут и дальше имена групп нужно использовать только в нижнем регистре.

PermitRootLogin no
AllowGroups  grouplinuxadmins

И перезапускаем sshd

#systemctl restart sshd

3)

Установка FreeRadius

a) Собственно установка

#yum -y install freeradius freeradius-utils
#ln -s /etc/raddb/mods-available/pam /etc/raddb/mods-enabled/pam

b) Редактируем

/etc/raddb/sites-enabled/default

:

Находим в разделе authenticate строку вида

# pam

и убираем комментарий в начале строки ( символ # )

c) Редактируем

/etc/raddb/sites-enabled/users

:

добавляем строку

DEFAULT Auth-Type := PAM

d) Собственно базовый радиус установлен. Только для

localhost

но уже можем проверять.

Парольное слово в Radius для localhost по умолчанию: testing123

# radtest userVPN ‘password_for_userVPN’ localhost 0 testing123

Правильный ответ будет если в конце ответа

Received Access-Accept

При неправильном пароле (тоже стоит обязательно проверить).

В конце ответа будет

Received Access-Reject

и дальше

(0)	-: Expected Access-Accept got Access-Reject

e) Добавляем систему, которой можно обращаться к 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 radiusd

g) Radius установлен. Если при установке FreeRadius что-то идет не так, очень полезная возможность консольной работы с FreeRadius. Для этого стопаем службу и запускаем Radius в консольном режиме с debug

#systemctl stop radius
#radiusd -Xx

4)

Ставим 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-authenticator

5) Модифицируем 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/radius21812

d) Редактируем /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 shellinabox

b) В принципе этого достаточно. Но некоторые любят красоту ;). Тогда дополнительно ставим еще 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_profile

d) Создаем

/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.sh

f) Можно файлы типа .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_config

b) Редактируем /usr/lib/systemd/system/sshd_web.service заменяя строку

ExecStart=/usr/sbin/sshd -D $OPTIONS

на

ExecStart=/usr/sbin/sshd -D -f /etc/ssh/sshd_web_config $OPTIONS

c) Редактируем

/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=8443

f) Перезапускаем после всех изменений.

#systemctl daemon-reload
#systemctl enable –now sshd_web
#systemctl enable –now shellinabox

Если ставили nginx то

#systemctl enable –now nginx

g) Открываем порты 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 --reload

8)

Тестируем весь конструктор.

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 как второй фактор.

Настройка WPA2 Enterprise c RADIUS

Настройка WPA2 Enterprise c RADIUS

Настройка WPA2 Enterprise c RADIUS

Настройка WPA2 Enterprise c RADIUS

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, есть ли возможность использовать системные сертификаты и есть ли там вообще такое хранилище.

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

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

WiFi Enterprise. FreeRadius   FreeIPA   Ubiquiti

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

Non-samsung


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

WiFi Enterprise. FreeRadius   FreeIPA   Ubiquiti

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

Samsung

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

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

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

WiFi Enterprise. FreeRadius   FreeIPA   Ubiquiti

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

WiFi Enterprise. FreeRadius   FreeIPA   Ubiquiti

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

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

WiFi Enterprise. FreeRadius   FreeIPA   Ubiquiti

сертификат — указываем тот, который устанавливалианонимный пользователь — 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 по домену. Поэтому приходится вручную закидывать наш сертификат в хранилище доверенных сертификатов. Здесь можно использовать как самоподписанный так и от центра сертификации. Я буду использовать второй.

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

WiFi Enterprise. FreeRadius   FreeIPA   Ubiquiti

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

WiFi Enterprise. FreeRadius   FreeIPA   Ubiquiti

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

WiFi Enterprise. FreeRadius   FreeIPA   Ubiquiti

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

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

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

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

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

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

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

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

Клиент для проверки подключения

В качестве платформы для проверки клиентского подключения — наиболее наглядно данный процесс отображается на последних версиях Mac OS X.

Контроллер ubiquiti

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

WiFi Enterprise. FreeRadius   FreeIPA   Ubiquiti

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

WiFi Enterprise. FreeRadius   FreeIPA   Ubiquiti

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

WiFi Enterprise. FreeRadius   FreeIPA   Ubiquiti

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

Конфигурация сервера 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.

Про сертификаты:  Математический конкурс-игра «Кенгуру» (old)

Сами методы:

  • 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.

Настройка WPA2 Enterprise c RADIUS
Рисунок 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.

Оцените статью
Мой сертификат
Добавить комментарий