Eduroam - Подготовка инфраструктуры

OS: "Linux Debian 9", "Linux Ubuntu Server 18 LTS".
Apps: "Freeradius v3".

Здесь рассматривается первая (подготовительная) часть решения задачи развёртывания совместимой с международным сервисом "Eduroam" инфраструктуры предоставления доступа в интернет через беспроводную WiFi-сеть.

Последовательность действий такова:

1. Подготовка системного окружения (отдельная инструкция).
2. Установка и предварительная настройка сервера аутентификации "Freeradius".
3. Настройка связи контроллеров точек доступа или непосредственно таковых с сервисом "Freeradius".

Установка сервера аутентификации "Freeradius".

Мы развёртываем сервис с аутентификацией через аккаунты хранимые в LDAP, потому требуется установка только одного дополнительного модуля:

# aptitude install freeradius freeradius-utils freeradius-ldap

По умолчанию сервис "freeradius" деактивирован, как ни странно - исправляем это:

# systemctl enable freeradius.service

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

"./proxy.conf" - распределение запросов между сервисами обработчиками;
"./clients.conf" - перечень клиентских точек (WiFi-точки, коммутаторы);
"./mods-enabled/*" - параметры подключаемых модулей;
"./policy.d/*" - описание политик обработки запросов;
"./sites-enabled/*" - специфичные конфигурации, перекрывающие все предыдущие.

Снижая вероятность путаницы в логике работы деактивируем модули, нам ненужные:

# rm /etc/freeradius/3.0/mods-enabled/chap
# rm /etc/freeradius/3.0/mods-enabled/detail
# rm /etc/freeradius/3.0/mods-enabled/detail.log
# rm /etc/freeradius/3.0/mods-enabled/digest
# rm /etc/freeradius/3.0/mods-enabled/exec
# rm /etc/freeradius/3.0/mods-enabled/ntlm_auth
# rm /etc/freeradius/3.0/mods-enabled/passwd
# rm /etc/freeradius/3.0/mods-enabled/replicate
# rm /etc/freeradius/3.0/mods-enabled/soh
# rm /etc/freeradius/3.0/mods-enabled/unix
# rm /etc/freeradius/3.0/mods-enabled/unpack

Каждый раз после внесения изменений в конфигурацию следует проверять корректность таковых с точки зрения "Freeradius":

# freeradius -C -X

Остановка, запуск и проверка состояния сервиса осуществляется типовыми командами:

# systemctl stop freeradius.service
# systemctl start freeradius.service
# systemctl status freeradius.service

Запуск в отладочном режиме, с богатейшим сопутствующим выхлопом, осуществляется с опцией "-X":

# freeradius -X

Наладка подключения и практика использования "дебагера".

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

Активируем конфигурацию для подключения отладчика через локальный файловый сокет:

# ln -s /etc/freeradius/3.0/sites-available/control-socket /etc/freeradius/3.0/sites-enabled/control-socket

Приводим конфигурацию точки входа к следующему виду:

# vi /etc/freeradius/3.0/sites-available/control-socket

....
listen {
  type = control
  socket = ${run_dir}/${name}.sock
  mode = rw
}
....

Проверяем корректность конфигурации и применяем таковую:

# freeradius -C -X && systemctl restart freeradius

Теперь в любой момент можно получить детали обработки текущих запросов:

# raddebug -t0

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

# raddebug -t0 -u username@example.net

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

# raddebug -t0 | tee -a /var/log/freeradius/raddebug.log

Добавление специфичных атрибутов "Freeradius".

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

# vi /etc/freeradius/3.0/dictionary

....
ATTRIBUTE  Linelog-Key     3000  string
ATTRIBUTE  LDAP-User-Name  3000  string
ATTRIBUTE  Inner-User-Name 3000  string

Настройка журналирования процедуры аутентификации.

Упоминаемый во всех простых инструкциях модуль журналирования "detail" мне не нравится форматом хранения данных. Я почти сразу отказался от него в пользу модуля "linelog".

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

# vi /etc/freeradius/3.0/mods-available/linelog

linelog {
  # Указываем месторасположение файла журнала
  filename = ${logdir}/linelog/linelog.log
  permissions = 0600
  ....

  # Подставляем в качестве ключа для анализа свою переменную
  reference = "messages.%{session-state:Linelog-Key}"

  # Описываем сочетание вызываемого события и строки данных, сохраняемую при этом в журнал событий
  messages {
    default = "%T: unknown packet type %{Packet-Type}"
    #
    recv-request = "%T: Action = Recv-Request, User-Name = %{User-Name}, Calling-Station-Id = %{Calling-Station-Id}, Src-AP-IP-Address = %{Packet-Src-IP-Address}, Src-AP-Name = %{client:shortname}, Operator-Name = %{Operator-Name}"
    #
    send-accept = "%T: Action = Send-Accept, User-Name = %{%{session-state:Inner-User-Name}:-%{User-Name}}
, Calling-Station-Id = %{Calling-Station-Id}, Src-AP-IP-Address = %{Packet-Src-IP-Address}, Src-AP-Name = %{client:shortname}, Operator-Name = %{Operator-Name}"
    send-reject = "%T: Action = Send-Reject, User-Name = %{%{session-state:Inner-User-Name}:-%{User-Name}}
, Calling-Station-Id = %{Calling-Station-Id}, Src-AP-IP-Address = %{Packet-Src-IP-Address}, Src-AP-Name = %{client:shortname}, Operator-Name = %{Operator-Name}"
    #
    # ( %{pairs:proxy-request:} )
    send-proxy-request = "%T: Proxy Action = Send-Proxy-Request, User-Name = %{User-Name}, Calling-Station-Id = %{Calling-Station-Id}, Src-AP-IP-Address = %{Packet-Src-IP-Address}, Src-AP-Name = %{client:shortname}, Operator-Name = %{Operator-Name}"
    recv-proxy-request = "%T: Proxy Action = %{proxy-reply:Response-Packet-Type}, User-Name = %{User-Name}, Calling-Station-Id = %{Calling-Station-Id}, Src-AP-IP-Address = %{Packet-Src-IP-Address}, Src-AP-Name = %{client:shortname}, Operator-Name = %{Operator-Name}"
  }
}

# Деактивируем блок конфигурации неиспользуемого функционала учёта состояния сессий
#linelog log_accounting {
  #....
#}

Заранее создаём директорию, в которой будут сохранятся журналы событий аутентификации:

# mkdir -p /var/log/freeradius/linelog
# chown -R freerad:freerad /var/log/freeradius/linelog
# chmod -R o-rwx /var/log/freeradius/linelog

Проверяем и применяем изменения в конфигурации:

# freeradius -C -X && systemctl restart freeradius

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

# vi /etc/logrotate.d/freeradius-linelog

/var/log/freeradius/linelog/linelog.log {
  monthly
  size 100M
  rotate 7
  missingok
  notifempty
  compress
  delaycompress
  dateext
  dateformat .%Y-%m-%d
  extension .log
  copytruncate
  su root freerad
}

Конечно же, проверяем синтаксис конфигурационного файла подсистемы ротации "Logrotate":

# logrotate -d /etc/logrotate.d/freeradius-linelog

На будущее, пример простейшей выборки (посредством "Bash") из журнала событий сведений об успешно аутентифицированных в недавнее время пользователях:

# tail -n5000 /var/log/freeradius/linelog/linelog.log | grep 'Send-Accept' | awk -F ',' '{print $2}' | awk 'match($0, /User-Name = .+/) {print substr($0, RSTART, RLENGTH);}' | awk -F '=' '{print $2}' | tr -d '[:blank:]' | sort | uniq

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

# cat /var/log/freeradius/linelog/linelog.log | grep -e "^$(date +'%Y-%m-%d')" | grep 'Send-Reject' | awk -F ',' '{print $2}' | awk 'match($0, /User-Name = .+/) {print substr($0, RSTART, RLENGTH);}' | awk -F '=' '{print $2}' | tr -d '[:blank:]' | grep '@' | sort | uniq

Меры безопасности для модуля журналирования "detail".

Если для журналирования событий аутентификации используется модуль "detail" с подсекциями вроде "auth_log", то обязательно (!!!) во избежание утечки учётных данных запрещаем сохранять атрибут содержащий пароль в журналах событий:

# vi /etc/freeradius/3.0/modules-enabled/detail

detail {
  ....
  suppress {
    User-Password
  }
}

# vi /etc/freeradius/3.0/modules-enabled/detail.log

detail auth_log {
  ....
  suppress {
    User-Password
  }
}

Настройка приёма запросов от клиентских устройств.

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

# vi /etc/freeradius/3.0/clients.conf

....
# Разрешаем приём запросов на аутентификацию от клиентов беспроводной точки доступа
client standalone-wifi-ap {

  # IP-адрес в качестве логин и последующий пароль для аутентификации точки доступа
  ipaddr = 12.34.56.7
  secret = connectionPassword

  # Требуем от клиентского шлюза подписания тела "Access-Request" контрольной суммой HMAC-MD5
  require_message_authenticator = yes

  # Указываем блок конфигурации, которым должны обрабатываться запросы от этой точки доступа
  virtual_server = outer-example-eduroam
}
....

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

# vi /etc/freeradius/3.0/clients.conf

....
# # Блок описания связки с Wireless Controllers: begin

# Wireless Controller: wc1.example.net
client wc1_wifi_clients {
  ipaddr = 12.34.56.72
  secret = connectionPassword
  require_message_authenticator = yes
  virtual_server = outer-example-eduroam
}
....
# Wireless Controller: wc4.example.net
client wc4_wifi_clients {
  ipaddr = 12.34.56.76
  secret = connectionPassword
  require_message_authenticator = yes
  virtual_server = outer-example-eduroam
}

# # Блок описания связки с Wireless Controllers: end
....

Настройка отправки запросов серверу аутентификации.

Для работы WiFi-точки доступа в спарке с RADIUS-сервером главное, чтобы она поддерживала способ аутентификации посредством стека протоколов "802.1x". У разных производителей параметры в названиях параметров настроек и блоков таковых замечательный разнобой, как то: WPA-EAP, "WPA2 Enterprise", "dot1x", "AAA Radius" и тому подобное.

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

Пример простейшей настройки аутентификации клиентов посредством radius-сервера для домашнего уровня устройства вроде "TP-Link":

Wireless Security:
  Security: WPA2-AES
  WPA-Authentication: EAP
  RADIUS Server IP: 10.20.30.41
  RADIUS Server Port: 1812
  RADIUS Server Secret: connectionPassword

Пример настройки аутентификации клиентов посредством radius-сервера для контроллеров "Cisco 4400 Series" и "Cisco Virtual Wireless Controller":

Security -> RADIUS -> Authentication:
  Call Station ID Type: System MAC Address
  Servers:
    Server Address: 10.20.30.41
    Server Secret: connectionPassword
    Key Wrap: false
    Port Number: 1812
    Server Status: Enabled
    Support for RFC-3576
    Server Timeout: 2 seconds
    Network User: false
    Managment: false
    IPSec: false

WLANs -> Eduroam -> Security -> Layer2:
  Layer 2 Security: WPA+WPA2
  WPA Policy: false
  WPA2 Policy: enable
  WPA2 Encryption: AES
  Auth Key Mgmt: 802.1X

WLANs -> Eduroam -> Security -> AAA Servers:
  Radius Server Overwrite Interface: Enabled
  Authentication Servers: Enabled
    Server 1: 10.20.30.41
    Server 2: 10.20.40.51

Пример настройки аутентификации клиентов посредством radius-сервера для контроллера "Cisco 5700 Series Wireless Controller":

Configuration -> AAA -> RADIUS - > Servers:
  Server Name: eg.example.net
  Server IP Address: 10.20.30.41
  Shared Secret: connectionPassword
  Auth Port: 1812
  Server Timeout: 2 secs
  Retry Count: 2
  Support for RFC-3576

Configuration -> AAA -> Server Groups -> Radius:
  Name: Eduroam-Radius-Group
  Assigned Servers:
    eg.example.net
    eg2.example.net

Configuration -> AAA -> Method Lists -> General:
  Dot1x System Auth Control: true

Configuration -> AAA -> Method Lists -> Authentication:
  Method List Name: Eduroam-Metod-Auth
  Type: dot1x
  Assigned Server Groups: Eduroam-Radius-Group

Configuration -> Wireless -> WLANs -> Eduroam -> Security -> Layer2:
  Layer 2 Security: WPA+WPA2
  WPA Policy: false
  WPA2 Policy: true
  WPA2 Encryption: AES
  Auth Key Mgmt: 802.1x

Configuration -> Wireless -> WLANs -> Eduroam -> Security -> AAA Server:
  Authentication Method: Eduroam-Metod-Auth

Configuration -> Wireless -> Access Points -> Radios -> AP Groups:
  Groupname:
    WLANs:
      WLAN SSID: Eduroam
      Interface/Interface Group: ....

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

Подготовка инфраструктуры ( Первая часть решения задачи развёртывания сервиса "Eduroam" - настройка совместимой инфраструктуры. )

Заметки и комментарии к публикации: