Сервер AIX RADIUS: Часть 1


Данная статья является первой из двух статей о сервере AIX® Remote Authentication Dial-In User Service (RADIUS). В этой статье Дениз Дженти рассмотрит протоколы аутентификации и учета, а также на примере модема расскажет о потоках передачи пакетов в RADIUS.

Введение

Сервер AIX® Remote Authentication Dial-In User Service (RADIUS, служба удаленной аутентификации пользователей при коммутируемом подключении) реализует протоколы клиент-сервер, определенные комитетом Internet Engineering Task Force (IETF). Данные протоколы позволяют удаленным клиентам получать доступ к центральному серверу для входа в сеть. Сам RADIUS описан в стандартах RFC 2865 и RFC 2866. Сервер RADIUS производит аутентификацию пользователей, авторизует их запросы к сервисам и записывает учетные данные. Первая реализация сервера RADIUS была включена в AIX 5L версии 5.3.0.10.

Обычными клиентами в RADIUS-среде являются терминальный сервер, устройство локальной сети, выполняющее аутентификацию или беспроводная точка доступа.

Сервер AIX RADIUS состоит из трех служб:

  1. Аутентификация.
  2. Авторизация.
  3. Регистрация событий (учет).

Эти три службы работают вместе с UNIX-аутентификацией, локальной базой данных пользователей или каталога, использующего протокол Lightweight Directory Access Protocol (LDAP) для предоставления информации об аутентификации. Демон сервера аутентификации RADIUS обеспечивает безопасность и аутентификацию пользователей для удаленных подключений к сети. Также этот демон выполняет функции авторизации, а именно определяет, какие службы доступны для использования и (в некоторых конфигурациях) как выполняется сетевой доступ. Демон сервера регистрации событий RADIUS отслеживает, когда и как долго удаленные соединения подключены к сети, как показано на рисунке 1.

Рисунок 1. Обзор процессов сервера RADIUS
  figure1.gif

    Основные процессы сервера AIX RADIUS: мониторинг; аутентификация;  регистрация событий.

Основные означает, что при нормальном функционировании сервера RADIUS эти демоны всегда загружены. Процессы выполняются под действующим идентификатором пользователя "radiusd" и не имеют постоянных полномочий пользователя root. Остановить и запустить процессы можно при помощи основных команд SRC: startsrc -s radiusd; stopsrc -s radius. Посмотреть, загружены ли процессы, можно при помощи команд ps -ef | grep radiusd.

  Процесс мониторинга

Процесс мониторинга – это управляющий процесс, который запускает или перезапускает все другие процессы, ассоциированные с RADIUS-сервером. При запуске процесс мониторинга читает и обрабатывает все конфигурационные файлы (например, radiusd.conf, client, proxy, dictionary, default.policy). Для регистрации информации процесс инициирует связь с демоном syslog. Службы в сервере RADIUS – это процессы, которые обеспечивают сетевые сервисы. Сервер RADIUS может запускать и управлять с помощью двух служб:

  • аутентификация RADIUS;
  • регистрация событий RADIUS-сервером.

Процесс мониторинга может запустить от 1 до N экземпляров каждой службы. Каждый экземпляр службы прослушивает уникальный сетевой порт. По умолчанию для аутентификации используется порт 1812. Порт для учета – 1813. Определить дополнительные порты можно в главном конфигурационном файле RADIUS – radiusd.conf. Каждый порт, перечисленный в файле radiusd.conf, запускает сервис, который прослушивает этот порт.

Экземпляры служб могут быть одинакового или различного типов. Например, процесс мониторинга может запустить три экземпляра службы аутентификации и два экземпляра службы регистрации событий.

Запомните, что все экземпляры служб должны работать на различных портах. Как показано на рисунке 2, сервер аутентификации может иметь три выполняющихся экземпляра на портах 1812, 6666, и 7779. Конфигурационный файл radiusd.conf содержит описания номеров портов.

Рисунок 2. Процессы службы аутентификации
  figure2.gif

 

После того как все службы были запущены, процесс мониторинга наблюдает за процессами запущенных служб. Если процесс службы аварийно завершил свою работу, процесс мониторинга зарегистрирует это событие и перезапустит службу.

Примечание. При частом обновлении сервера RADIUS возможно уменьшение числа служб.

  Процесс аутентификации

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

  • предоставить доступ;
  • отказать в доступе;
  • отказать в доступе и потребовать дополнительной информации;
  • проверить политику авторизации;
  • передать информацию об авторизации.

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

Порядок аутентификации

  Рисунок 3. Удаленная аутентификация RADIUS: пример для модема 

figure3.gif

Модем получает запрос (см. пункт 1 на рисунке 3) и оповещает об этом терминальный сервер. Терминальный сервер запрашивает у вызывающего абонента имя пользователя и пароль. Когда терминальный сервер принимает имя пользователя и пароль, он собирает аутентифицирующий UDP-пакет (UDP Authentication packet). Терминальный сервер является клиентом RADIUS-сервера. Аутентифицирующий пакет (Access-Request, запрос доступа) содержит имя пользователя, скрытый пароль и другую информацию, которая описывает модемное соединение и терминальный сервер, который отправил этот пакет.

Затем аутентифицирующий пакет (Authentication packet) отсылается процессу аутентификации RADIUS-сервера (см. пункт 2 на рисунке 3), и терминальный сервер ожидает ответа. В случае, если в течение заранее определенного промежутка времени (например, три секунды) процесс аутентификации не отвечает, терминальный сервер повторно посылает аутентифицирующий пакет. Терминальный сервер будет пересылать аутентифицирующий пакет до тех пор, пока не получит пакет, подтверждающий прием данных (отклонение запроса, запрос дополнительной информации или подтверждение запроса), или до тех пор, пока не исчерпает количество возможных попыток (например, 23). В этот момент он перестанет посылать запросы аутентификации и сбросит вызов, или попытается передать запросы аутентификации другому процессу аутентификации, если такой определен.

Когда процесс аутентификации принимает запрос на аутентификацию, он делает запрос к пользовательской базе данных. В зависимости от того как системный администратор настроил RADIUS-сервер, возможны три варианта размещения пользовательской базы данных: база данных пользователей в локальной UNIX-системе, определенная для RADIUS локальная база данных или каталог LDAP (см. пункт 3 на рисунке 3). Итак, процесс извлекает информацию о пользователе, запрашивающем аутентификацию. Для успешной аутентификации необходимо выполнение следующих трех условий:

  1. Пользовательский идентификатор должен присутствовать в базе данных.
  2. Пароль в аутентифицирующем пакете должен соответствовать паролю, найденному в базе данных или LDAP-каталоге.
  3. Должна быть проверена политика авторизации. Эта политика является опцией, поэтому ее нужно сконфигурировать. Если политика сконфигурирована, пара имя/значение (attribute-value) из пакета должна соответствовать значениям из базы данных.

Когда все действия по аутентификации успешно завершатся, терминальному серверу возвращается пакет разрешения (Acceptance packet, Аccess-Accept). В зависимости от конфигурации модему может быть присвоен IP-адрес и предоставлен доступ в частную сеть (см. пункт 4 на рисунке 3).

Если аутентификация не была пройдена, терминальному серверу (см. пункт 4 на рисунке 3) посылается уведомление об отказе в доступе (Access-Reject); в свою очередь терминальный сервер уведомляет о том, что не удалось провести аутентификацию пользователя. Далее клиент может отказаться или повторить попытки аутентификации, или попробовать аутентифицироваться под новым именем пользователя и паролем.

Описание пакета аутентификации

Ниже представлен пример пакета аутентификации, который был получен процессом аутентификации.
Эти данные записываются в syslog, на 9-м уровне отладки. Информация представлена в шестнадцатеричном и текстовом формате.

Sep 20 10:03:18 server1 radiusd[1773678]: [2]:Incoming Packet:
Sep 20 10:03:18 server1 radiusd[1773678]: [2]: 
Code = 1, Id = 253, Length = 90
Sep 20 10:03:18 server1 radiusd[1773678]: [2]:   
Type =   1, Length =   8, Value = 0x67656E747937
Sep 20 10:03:18 server1 radiusd[1773678]: [2]:   
Type =   2, Length =  18, Value = 0x********************************
Sep 20 10:03:18 server1 radiusd[1773678]: [2]:   
Type =   4, Length =   6, Value = 0x0A0A0A09
Sep 20 10:03:18 server1 radiusd[1773678]: [2]:   
Type =   5, Length =   6, Value = 0x00000002
Sep 20 10:03:18 server1 radiusd[1773678]: [2]:   
Type =   6, Length =   6, Value = 0x00000001
Sep 20 10:03:18 server1 radiusd[1773678]: [2]:   
Type =   7, Length =   6, Value = 0x00000001
Sep 20 10:03:18 server1 radiusd[1773678]: [2]:   
Type =  30, Length =  10, Value = 0x3132332D34353637
Sep 20 10:03:18 server1 radiusd[1773678]: [2]:   
Type =  31, Length =  10, Value = 0x3736352D34333231
Sep 20 10:03:18 server1 radiusd[1773678]: [2]:Starting parse_packet()
Sep 20 10:03:18 server1 radiusd[1773678]: [2]:
Code 1, ID = 253, Port = 44224 Host = 10.10.10.9
Sep 20 10:03:18 server1 radiusd[1773678]: [2]:User-Name = "user_id"
Sep 20 10:03:18 server1 radiusd[1773678]: [2]:NAS-IP-Address = 10.10.10.9
Sep 20 10:03:18 server1 radiusd[1773678]: [2]:NAS-Port = 2
Sep 20 10:03:18 server1 radiusd[1773678]: [2]:Service-Type = Login-User
Sep 20 10:03:18 server1 radiusd[1773678]: [2]:Framed-Protocol = PPP
Sep 20 10:03:18 server1 radiusd[1773678]: [2]:Called-Station-Id = "123-4567"
Sep 20 10:03:18 server1 radiusd[1773678]: [2]:Calling-Station-Id = "765-4321"
Sep 20 10:03:18 server1 radiusd[1773678]: [2]:Leaving parse_packet()

Информация из аутентифицирующего пакета, запрос доступа, как видно из отладочной
информации RADIUS-сервера, состоит из следующих частей:
Sep 20 10:03:18 server1 radiusd[1773678]
Основная информация syslog: день, время, имя сервера и идентификатор radius-процесса.
[2]
Номер пакета с момента запуска демона.
Incoming packet:
Сообщение, которое означает начало обработки пакета.
Code = 1, Id = 253, Length = 90
Код запроса доступа и длина пакета.
Type = 1, Length = 8, Value = 0x67656E747937
Запускает обработку пар имя/значение, представленных в 16-й системе счисления.
Этот пример содержит 8 пар имя/значение.
Starting parse_packet()
Запись сообщения, которое означает начало обработки пакета – то же самое сообщение, что и в Incoming packet,
только в текстовом удобочитаемом формате.
Собрать информацию, описанную выше, можно тогда, когда сервер RADIUS работает в отладочном режиме (уровень 9).
Пары имя/значение являются параметрами RADIUS- сервера, которые были переданы ему аппаратным сервером доступа.

  Описание заголовка пакета аутентификации 

code Тип RADIUS-пакета. Все запросы аутентификации имеют код "1".
ID Порядковый номер пакета, который определяется терминальным сервером. Пакеты, посланные до текущего пакета, имеют меньшие значения идентификатора (ID), в то время как пакеты, посланные после текущего пакета, имеют большие значения ID. Как только ID достигает значения 256, то сбрасывается в "1". Это может быть полезно при установлении последовательности получения пакетов. Кроме того, когда идентификаторы пакетов приходят не по порядку, это означает наличие задержки при передаче данных через сеть или другие проблемы.
Length Длина всего пакета в байтах.
Host IP-адрес хоста, который отправил пакет, в шестнадцатеричной системе счисления. Каждая пара шестнадцатеричных чисел означает одну из четырех частей IP-адреса.

Описание пар имя/значение пакета аутентификации

Username Type = 1 Имя пользователя для сетевой аутентификации.
Password Type = 2 Скрытый пароль пользователя.
NAS-IP-Address Type = 4 IP-адрес терминального сервера, запрашивающего аутентификацию.
NAS-Port Type = 5 S-port, к которому обращается пользователь (например, модем).
Service-Type Type = 6 Тип службы, которую запрашивает пользователь. Большинство пользователей могут быть либо Framed-Users, либо сетевыми пользователями.
Framed-Protocol Type = 7 Атрибут Framed-Protocol позволяет указать протокол, используемый для передачи данных между клиентом и сетью. Данная пара имя/значение доступна только тогда, когда свойство User-Service-Type установлено в Framed-Users.
Called-Station-ID Type = 30 Номер телефона, у которого клиент запрашивал доступ в сеть. Это поле заполняется только в том случае, если необходимая информация доступна терминальному серверу.
Calling-Station-ID Type = 31 Номер телефона, с которого клиент запрашивал доступ в сеть. Это поле заполняется только в том случае, если терминальный сервер владеет необходимой информацией.

   Процесс регистрации сообщений

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

  1. Начать соединение (start accounting message, start-сообщение).
  2. Прекратить соединение (stop accounting message, stop-сообщение).

Сценарий начала регистрации сообщений

Рисунок 4. Сообщение RADIUS-сервера о начале учета 

figure4.gif

Следующий пример подходит для пользователей, определенных в LDAP-каталоге. Пользователи, определенные в LDAP, имеют особенность, которая позволяет регистрировать информацию о событиях внутри процессоров. Если пользователь определен в локальной базе данных или является UNIX-пользователем, "внутрипроцессная" информация (или RADIUS Active objectclass) не обновляется.

Определение пользователей в LDAP позволяет использовать дополнительную возможность: ограничение числа попыток входа в систему. Если LDAP-пользователь создан с заданным параметром maximum allowed login times ("максимально возможное число попыток входов в систему"), тогда по пакетам, уведомляющим о начале и конце учета, можно определить момент, когда пользователь прошел аутентификацию. Если пользователь исчерпал все попытки входа в систему (maximum allowed login times), то он больше не сможет аутентифицироваться.

start-сообщение ("Start Accounting message") создается в момент получения терминальным сервером подтверждения об успешно пройденной аутентификации (см. пункт 5 на рисунке 4). По получении подтверждения об аутентификации терминальный сервер создает пакет Start Accounting (Начать соединение, start-пакет) (см. раздел Описание Accounting Start пакета). start-пакет содержит параметр "Acct-Session-ID", значение которого идентично значению такого же параметра в пакете Stop Accounting (Закончить соединение, Stop-пакет). Acct-Session-ID помогает находить соответствующие пары сообщений Start Accounting и Stop Accounting, которые были зарегистрированы.

start-пакет содержит информацию о терминальном сервере и типе соединения. Также пакет содержит данные о времени, которое прошло с момента получения подтверждения об аутентификации. Время начала соединения для пользователя вычисляется следующим образом: надо вычесть Acct-Delay-Time из текущего времени системы (см. раздел Подробное описание Acct-Delay-Time).

Когда сервер регистрации сообщений RADIUS получает сообщение о регистрации событий (Accounting packet) (см. пункты 6 и 7 на рисунке 4):

  1. Проверяется LDAP-поле active objectclass на наличие пользователя с заданными параметрами (например, имя пользователя и модификатор, указывающий что пользователь еще не вошел в систему).
  2. Если пользователь был найден, процесс регистрации событий обновляет текущий active objectclass, добавляя к объекту Acct-Session-ID и время начала соединения. Счетчик входов в систему также увеличивается.
  3. Данные о начале соединения записываются в файл /var/radius/data/accounting.

Все пакеты подтверждаются. Если действия, описанные выше, не будут успешно выполнены, в журнал будут записаны ошибки. Чтобы не нарушать порядок сообщений учета (Accounting packets), также регистрируются и ошибочные пакеты.

Терминальный сервер прекращает передавать start-пакеты либо когда получает подтверждение от RADIUS-сервера, либо когда превышает число возможных попыток отослать сообщение. Терминальный сервер пересылает start-пакеты через определенный интервал времени (например, 0, 2 минуты, 4 минуты, 8 минут, и так далее) до тех пор, пока не получит подтверждение или превысит допустимое число попыток отправить этот пакет (см. пункт 8 на рисунке 4).

  Подробное описание параметра Acct-Delay-Time

  Атрибут Acct-Delay-Time не отражает задержек в передаче данных по сети. Он отражает задержки из-за невыполненных доставок предыдущих пакетов. Собственно, это говорит о наличии проблем с передачей данных по сети или о том, что была какая-то ошибка в процессе аутентификации (он был недоступен по какой-то причине).

Когда клиент получает доступ к сети, высылается start-пакет (Acct-Delay-Time = 0). Если за определенный период времени не было получено корректного подтверждения, отсылается другой пакет, который содержит новую задержку (Acct-Delay-Time = 120). Прежде чем терминальный сервер завершит свое выполнение, эти попытки будут продолжаться (как и в случае с аутентифицирующим пакетом) определенное количество раз. Так же как и в случае с аутентифицирующим пакетом, будет предпринята попытка доставить stat-пакет другому процессу регистрации событий, если таковой определен.

  Описание Accounting Start-пакета

Ниже приведен пример ситуации, когда сервер регистрации событий RADIUS получает Accounting Start-пакет.

Oct 1 15:47:43 server1 radiusd[540746]: [1]:Code 4, ID = 54, Port = 49475

 Host = 10.10.10.9 Oct  1 15:47:43 server1 radiusd[540746]: [1]:Acct-Status-Type = Start Oct  1 15:47:43 server1 radiusd[540746]: [1]:Acct-Session-Id = "000004F5" Oct  1 15:47:43 server1 radiusd[540746]: [1]:User-Name = "user_id" Oct  1 15:47:43 server1 radiusd[540746]: [1]:NAS-IP-Address = 10.10.10.9 Oct  1 15:47:43 server1 radiusd[540746]: [1]:NAS-Port = 12 Oct  1 15:47:43 server1 radiusd[540746]: [1]:Acct-Authentic = RADIUS Oct  1 15:47:43 server1 radiusd[540746]: [1]:Service-Type = Framed-User Oct  1 15:47:43 server1 radiusd[540746]: [1]:Framed-Protocol = PPP Oct  1 15:47:43 server1 radiusd[540746]: [1]:Framed-IP-Address = 10.10.10.10 Oct  1 15:47:43 server1 radiusd[540746]: [1]:Acct-Delay-Time = 1 

Информация в Accounting Start-пакете, как показано на отладочном выводе сервера RADIUS, состоит из следующих частей:

  • Заголовок (первая строка).
  • Пары имя/значение.

И Accounting Start-пакет, и пакет аутентификации содержат некоторые общие пары имя/значение. Для дополнительного удобства пакеты содержат и общие, и уникальные элементы.

Информация, приведенная выше, может быть собрана, если RADIUS-сервер работает на 9-м уровне отладки. Вторая статья этого цикла предоставит описание того, как работает RADIUS-сервер при отладке.

Заголовок Accounting Start-пакета

   

Code Тип RADIUS-пакета. Все запросы, связанные с регистрацией событий, имеют код "4".
ID Порядковый номер пакета, который определяется терминальным сервером. Пакеты, посланные до текущего пакета, имеют меньшие значения идентификатора (ID), в то время как пакеты, посланные после текущего пакета, имеют большие значения ID. Номер ID откатывается к "1" как только ID достигает значения 256. Это может быть полезно при установлении последовательности получения пакетов. Кроме того, когда идентификаторы пакетов приходят не по порядку, это означает наличие задержки при передаче данных через сеть, либо другие проблемы.
Length Длина всего пакета в байтах.
Host IP-адрес хоста, который отправил пакет, в шестнадцатеричной системе счисления. Каждая пара шестнадцатеричных чисел означает одну из четырех частей IP-адреса.

 

Описание пар имя/значени Accounting Start-пакета 

 

Acct-Status-Type Type = 40 Определяет тип пакета регистрации событий (начало или конец соединения). В данном примере используется start-пакет.
Acct-Session-ID Type = 44 Шестнадцатеричное число из восьми цифр, генерируемое передающим терминальным сервером. Терминальный сервер гарантирует, что это число будет уникальным (для него самого) с момента его последней перезагрузки. Пакет об окончании соединения для текущей учетной сессии содержит идентификатор Acct-Session-ID, по которому легко найти сообщения о начале/завершении соединений.
User-Name Type = 1 Имя пользователя, вводимое для сетевой аутентификации.
NAS-IP-Address Type = 4 IP-адрес терминального сервера, который запрашивает аутентификацию.
NAS-Port Type = 5 S-port, к которому обращается пользователь (например, модем).
Acct-Authentic Type = 45 Определяет, каким методом аутентифицируются пользователи. Всегда должно быть RADIUS.
Service-Type Type = 6 Тип службы, которую запрашивает пользователь. Большинство пользователей могут быть либо Framed-Users, либо сетевыми пользователями.
Framed-Protocol Type = 7 Атрибут Framed-Protocol позволяет указать протокол, используемый для передачи данных между клиентом и сетью. Данная пара имя/значение доступна только тогда, когда свойство User-Service-Type установлено в Framed-Users.
Framed-IP-Address Type = 8 IP-адрес, которые используют клиенты когда подсоединяются к сети. Эта пара появляется только тогда, когда свойство User-Service-Type имеет значение Framed-Users.
Acct-Delay-Time Type = 41 Задержка по времени, которая имела место с момента посылки пакета и приходом подтверждения аутентификации. Вычитание Acct-Delay-Time из текущего системного времени должно дать примерное время, когда пользователь получил доступ к сети (см. раздел Подробное описание Acct-Delay-Time).

 

Сценарий остановки регистрации сообщений

Рисунок 5. Сообщение об остановке регистрации сообщений RADIUS-сервером

  figure5.gif

Процесс создания пакета об остановке регистрации сообщений (Stop Accounting-пакет) начинается в момент, когда удаленное устройство завершает или сбрасывает соединение. После этого терминальный сервер генерирует Stop-пакет (см. пункт 9 на рисунке 5 и Описание Stop Accounting-пакета).

Stop Accounting-пакет содержит тот же Acct-Session-Id, что и Start Accounting-пакет. Как и Start Accounting -пакет, Stop Accounting-пакет может отсылать пару имя/значение Acct-Delay-Time. Acct-Delay-Time для Stop Accounting-пакета – это количество времени, прошедшего с того момента, как настоящий пакет был послан и клиент завершил соединение. Более подробная информация о Acct-Delay-Time может быть найдена в разделе Подробное описание Acct-Delay-Time.

Когда сервер регистрации событий RADIUS принимает Stop Accounting-пакет (см. пункты 10 и 11 на рисунке 5):

  1. Выполняется поиск LDAP- поля active objectclass соответствующего пользователя. Поиск основан на Session-Id, User-Name и флаге входа в систему.
  2. Если была найдена соответствующая запись, запись удаляется. Objectclass должен отражать то, что клиент завершил соединение.
  3. Данные из Stop Accounting-пакета записываются в /var/radius/data/accounting.

Число секунд, в течение которых пользователь был в сети, отсылаются в параметре Acct-Session-Time.

Как и в случае со Start Accounting-пакетом, все полученные пакеты подтверждаются, чтобы исключить повторные запросы терминального сервера и минимизировать сетевой трафик и вычислительные нагрузки. Если шаги выше не были успешно выполнены, все ошибки записываются в syslog.

Терминальный сервер прекращает передавать Stop Accounting-пакеты, когда получает подтверждение от RADIUS-сервера, или когда исчерпывает все попытки передать этот пакет. Терминальный сервер пересылает Stop Accounting-пакеты через заранее определенные интервалы времени (например, 0, 2 минуты, 4 минуты, 8 минут, и так далее) до тех пор, пока ему не придет подтверждение или он не превысит число возможных попыток отправки пакета (см. пункт 12 на рисунке 5). Если определен прокси, доставка Stop Accounting-пакета может быть выполнена на альтернативный сервер регистрации сообщений RADIUS.

Описание Stop Accounting-пакета

Ниже приведен пример, когда сервер регистрации событий RADIUS получает Stop Accounting-пакет.

Oct 1 15:50:17 server1 radiusd[540746]: [2]:Code 4, ID = 67, Port = 49475

 Host = 10.10.10.9 Oct  1 15:50:17 server1 radiusd[540746]: [2]:Acct-Status-Type = Stop Oct  1 15:50:17 server1 radiusd[540746]: [2]:Acct-Session-Id = "000004F5" Oct  1 15:50:17 server1 radiusd[540746]: [2]:User-Name = "user_id" Oct  1 15:50:17 server1 radiusd[540746]: [2]:NAS-IP-Address = 10.10.10.9 Oct  1 15:50:17 server1 radiusd[540746]: [2]:NAS-Port = 12 Oct  1 15:50:17 server1 radiusd[540746]: [2]:Service-Type = Framed-User Oct  1 15:50:17 server1 radiusd[540746]: [2]:Framed-Protocol = PPP Oct  1 15:50:17 server1 radiusd[540746]: [2]:Framed-IP-Address = 10.10.10.10 Oct  1 15:50:17 server1 radiusd[540746]: [2]:Acct-Input-Octets = 100 Oct  1 15:50:17 server1 radiusd[540746]: [2]:Acct-Output-Octets = 200 Oct  1 15:50:17 server1 radiusd[540746]: [2]:Acct-Session-Time = 7200 Oct  1 15:50:17 server1 radiusd[540746]: [2]:Acct-Terminate-Cause = User-Request 

Данные в Stop Accounting-пакете, как видно из информации, выводимой RADIUS-сервером на 9-м уровне отладки, состоят из следующих частей:

  1. Header information (first line)
  2. Последовательность пар имя/значение.

Stop Accounting-пакет и пакет аутентификации имеют некоторые общие пары имя/значение, однако для удобства у них есть и уникальные пары имя/значение. Относительно рассматриваемого примера заметим, что был отправлен атрибут Acct-Session-Time со значением 7200; это означает, что пользователь user_id был в системе в течение 7200 секунд.

Описание пар имя/значение Accounting Stop-пакета 

Acct-Status-Type Type = 40 Определяет тип пакета регистрации событий (Начало или конец соединения). В данном примере используется Stop Accounting-пакет.
Acct-Session-Id Type = 44 Шестнадцатеричное число из восьми цифр, генерируемое передающим терминальным сервером. Терминальный сервер гарантирует, что это число будет уникальным (для него самого) с момента его последней перезагрузки. Stop Accounting-пакет для текущей учетной сессии содержит Acct-Session-ID. Благодаря этому легко искать сообщения о начале/завершении соединений.
User-Name Type = 1 Имя пользователя, вводимое для сетевой аутентификации.
NAS-IP-Address Type = 4 IP-адрес терминального сервера, который запрашивает аутентификацию.
NAS-Port Type = 5 S-port, к которому обращается пользователь (например, модем).
Acct-Session-Time Type = 46 Примерное время, в течение которого клиент был в сети. Определяется терминальным сервером.
Acct-Authentic Type = 45 Определяет, каким методом аутентифицируются пользователи. Всегда должно быть RADIUS.
Service-Type Type = 6 Тип службы, которую запрашивает пользователь. Большинство пользователей могут быть либо Framed-Users, либо сетевыми пользователями.
Framed-Protocol Type = 7 Атрибут Framed-Protocol позволяет указать протокол, используемый для передачи данных между клиентом и сетью. Данная пара имя/значение доступна только тогда, когда свойство User-Service-Type установлено в Framed-Users.
Framed-IP-Address Type = 8 IP-адрес, которые используют клиенты когда подсоединяются к сети. Эта пара появляется только тогда, когда свойство User-Service-Type имеет значение Framed-Users.
Acct-Input-Octets Type = 42 Как много октетов было получено с этого порта.
Acct-Output-Octets Type = 42 Число октетов, отправленных через порт.
Acct-Terminate-Cause Type = 49 Причина, по которой была прекращена сессия.

Учетные данные записываются в файл журнала /var/radius/data/accounting. Формат данных параметр=значение; время в виде текстовой строки и день выводятся в начале сводки информации, а временная метка выводится в конце. Временная метка представляет собой число секунд с 1970 года.

Можно написать сценарии, чтобы создавать отчеты различных типов, например: учетные данные об активности за месяц, активности определенного пользователя или IP-адреса.

По материалам www.ibm.com/developerworks

Оставьте комментарий