Безопасность IAX2

Безопасность IAX2

Сегодня поговорим об IAX2 – протоколе Asterisk и о том как безопасно его использовать в решениях VoIP.

1. Введение

В протокол IAX2 были внесены изменения, чтобы снизить атаки типа “Denial of Service – отказ в обслуживании”. Это изменение называется проверкой токена вызова. Это изменение влияет на обмен сообщениями и не поддерживает обратную связь для старых клиентов, подключающихся к обновленному серверу. Поэтому ряд опций были предоставлены для того, чтобы отключить валидацию токена вызова, если это необходимо для совместимости.
В дополнение к проверке токенов, Asterisk теперь также может ограничить количество подключений, разрешенных для каждого IP-адреса, чтобы запретить одному хосту запрещать другим хостам успешные соединения. Эти параметры называются лимитами одновременных вызовов (call limits).

2. Руководство пользователя

2.1. Конфигурация

2.1.1. Быстрый старт

Мы настоятельно рекомендуем администраторам использовать улучшения безопасности IAX2 там, где это возможно. Однако, чтобы полностью обойти улучшения безопасности и работать с Asterisk так же, как и раньше, в разделе [general] файла iax.conf можно указать следующие параметры:

[general]
…
calltokenoptional = 0.0.0.0/0.0.0.0
maxcallnumbers = 16382
…

2.1.2. Контролируемые сети

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

2.1.2.1. Полное обновление

Если все конечные точки IAX2 были обновлены, никаких изменений в конфигурации не требуется.

2.1.2.2. Частичное обновление

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

2.1.3. Общественные сети

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

2.1.3.1. Полное обновление

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

[general]
; По умолчанию ограничивайте использование номера звонка на низкое число.
maxcallnumbers = 16
...
[callnumberlimits]
; Это ограничение на IP-адрес для адресов, которые попадают в указанный диапазон.
; /<маска> = <предел>
192.168.1.0/255.255.255.0 = 1024
...
[PeerA]
; Поскольку мы не будем знавать IP-адрес динамического партнера до тех пор, пока
; они регистрируются, ограничение максимального количества вызовов может быть установлено в
; динамический профиль конфигурации.
type= peer
host = dynamic
maxcallnumbers = 1024
...
2.1.3.2. Частичное обновление

Если были обновлены только некоторые конечные точки IAX2 или состояние конечной точки IAX2 неизвестно, тогда проверка маркера вызова должна быть отключена для обеспечения совместимости. Чтобы уменьшить потенциал влияния отключения проверки токена вызова, его следует отключать только для определенного партнера или пользователя по мере необходимости. Используя опцию auto, проверка токена звонка будет изменена на требуемый, как только мы определим, что он поддерживает его.

[FriendA]
requirecalltoken = auto
...

Обратите внимание, что есть случаи, когда auto нельзя использовать. Например, если несколько одноранговых узлов используют одни и те же данные аутентификации, и они не все обновлены для поддержки проверки токена вызова, то те, которые его не поддерживают, будут заблокированы. Как только обновленный клиент успешно завершит аутентифицированную настройку вызова с использованием проверки токена вызова, с этого момента потребуется использование Asterisk. В этом случае было бы лучше установить для параметра requirecalltoken значение no.

2.1.3.3. Гостевой доступ

Гостевой доступ через IAX2 требует особого внимания. Учитывая количество существующих конечных точек IAX2, которые не поддерживают валидацию токенов, большинство систем, которые разрешают гостевой доступ, должны делать это, не требуя проверки токена вызова.

[guest]
; Обратите внимание, что здесь указано имя «гость». Когда код
; пытается определить, требуется ли проверка токена вызова,
; будет искать пользователя по имени пользователя, указанному в
; запросе. Приглашения могут быть отправлены без имени пользователя. В
; в этом случае мы будем искать определенного пользователя, называемого «гость», чтобы
; определить, требуется ли проверка токена или нет.
type = user
requirecalltoken = no
…

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

[general]
maxcallnumbers_nonvalidated = 2048

2.2. Команды консоли CLI

2.2.1. IAX2 показывает использование номеров вызовов

Usage: iax2 show callnumber usage [IP address]
Show current IP addresses which are consuming IAX2 call
numbers.

2.2.2. iax2 show peer

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

3. Модификация протокола

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

3.1. Обзор

В протоколе IAX2 используется номер вызова для связи сообщений, с которыми они связаны.
Доступное количество номеров вызовов является конечным, как определено протоколом. Из-за этого важно, чтобы злоумышленники не использовали номера вызовов. Чтобы достичь этого, было сделано усовершенствование протокола IAX2, которое называется проверкой токена вызова.
Проверка токена вызова гарантирует, что соединение IAX2 не будет получено с поддельного IP-адреса.
В дополнение к использованию проверки токена вызова, Asterisk также ограничит количество одновременных звонков данным удаленным IP-адресом. Эти ограничения имеют значения по умолчанию, которые обычно не нужно изменять, но могут быть изменены для конкретной функциональности.
Сочетание проверки токена вызова и ограничений номера вызова используется для смягчения атаки на отказ в обслуживании для использования всех доступных номеров вызовов IAX2. Альтернативным подходом к обеспечению безопасности IAX2 было бы использование уровня безопасности поверх IAX2, такого как DTLS [RFC4347] или IPsec [RFC4301].

3.2. Проверка токена вызова

Эта модификация добавляет новый тип кадра IAX2 и определяется новый информационный элемент.

Frame Type: CALLTOKEN 0x28 (40)
IE: CALLTOKEN 0x36 (54)

Когда запрос отправляется первоначально, он ДОЛЖЕН включать IE CALLTOKEN с полезной нагрузкой zerolength, чтобы указать, что этот клиент поддерживает обмен CALLTOKEN. Когда сервер получает этот запрос, он ДОЛЖЕН отвечать на сообщение IAX2 CALLTOKEN. Сообщение CALLTOKEN ДОЛЖНО отправляется с номером вызова источника “0”, поскольку номер вызова еще не будет выделен для этого вызова.
Для обратной совместимости с клиентами, которые не поддерживают проверку токена, реализации сервера МОГУТ обрабатывать запросы, которые не указывают на поддержку CALLTOKEN в их первоначальном запросе. Однако это НЕ ДОЛЖНО быть поведением по умолчанию, поскольку оно отказывается от преимуществ безопасности, полученных при проверке CALLTOKEN.
После того как клиент отправит запрос с пустым IE CALLTOKEN, он ДОЛЖЕН быть готов получить ответ CALLTOKEN или получить ответ, который будет указан в случае действительного CALLTOKEN. Это то, как клиент должен вести себя для взаимодействия с реализациями сервера IAX2, которые еще не поддерживают проверку CALLTOKEN.
Когда клиент IAX2 получает ответ CALLTOKEN, он ДОЛЖЕН отправить свой первоначальный запрос еще раз.
Этот запрос ДОЛЖЕН включать IE CALLTOKEN с копией значения CALLTOKEN IE, полученного в ответ CALLTOKEN. Значение IE является непрозрачным значением. Клиенты ДОЛЖНЫ иметь возможность принимать полезную нагрузку CALLTOKEN любой длины, вплоть до максимальной длины, разрешенной в IE IAX2.
Значение полезной нагрузки в IE CALLTOKEN является детальностью реализации. Разработчику остается решить, насколько он утончен. Однако он ДОЛЖЕН быть полным, чтобы при отправке CALLTOKEN IE его можно было использовать для проверки того, что исходный IP-адрес и номер порта не были подделаны.
Если сервер получает запрос с недопустимым значением IE CALLTOKEN, он ДОЛЖЕН оставить его и не отвечать на запрос.

3.3. Пример обмена сообщениями

3.3.1. Настройка вызова

 Client            Server
--------         --------
----------- NEW ----------->
(with empty CALLTOKEN IE)
<-------- CALLTOKEN --------
(client must ignore source call number from this message)
-------- NEW -------->
(with received token)
<-------- AUTHREQ --------
...
continue as normal …

3.3.2. Настройка вызова, клиент не поддерживает CALLTOKEN

 Client            Server
--------         --------
----------- NEW ----------->
(with no CALLTOKEN IE)
<---------- REJECT ---------
(sent without allocating a call number)
----------- ACK ----------->

3.3.3. Call Setup, клиент поддерживает CALLTOKEN

 Client            Server
--------         --------
----------- NEW ----------->
(with empty CALLTOKEN IE)
<----------- AUTHREQ ----------- (sent without allocating a call number) ... continue as normal …

3.3.4. Вызовите программу установки с клиента, который отправляет недействительный токен

Client            Server
--------         --------
----------- NEW ----------->
(with invalid CALLTOKEN IE)
... dropped …

4. Внедрение Asterisk

В этом разделе приведены некоторые дополнительные сведения об осуществлении этих изменений в Asterisk.

4.1. CALLTOKEN IE

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

  • Временная метка (основанная на эпохе)
  • SHA1-хэш удаленного IP-адреса и порта, метка времени, а также некоторые случайные данные генерируемые при запуске Asterisk.

Когда принимается CALLTOKEN IE, его действительность будет определяться путем пересчета хэша SHA1. Если это действительный токен, отметка времени проверяется, чтобы определить, истек ли токен. Тайм-аут токена будет жестко закодирован через 10 секунд. Если сервер определяет, что токен истек, он будет рассматривать его как недопустимый токен и не отвечать на запрос. Используя этот метод, нам не нужно выделять дополнительную память для диалога. Однако, с кодированием IE CALLTOKEN токен считается действительным для Asterisk каждый раз, когда клиент отправил его, пока мы не рассмотрим его истекший токен. Используя опцию «maxcallnumbers», эта проблема решается. Это означает, что злоумышленник сократит число своих вызовов, поскольку ему нужно будет получить только один токен за период ожидания, а не токен за запрос.