Всем привет! В связи с важностью темы и сложностью ее понимания (сам недавно только ее полностью прокачал) публикую выдержку из своей статьи по безопасности Asterisk, по разделу IAX2 каналов.

При входящем IAX2 звонке Asterisk выполняется следующие последовательности проверок.

* Если пристутствует поле username:
o Ищет в файле конфигурации iax.conf (и включённых из него файлов) секцию, имя которой совпадает с username, в которой type=user. Если совпадений не найдено, произойдет закрытие канала.
o В найденной секции проверяется наличие параметров allow/deny, и если IP адрес звонящего совпадает с deny, или не проходит цепочку allow, звонок завершается.
o Проверяется пароль. Если пароли не совпадают, звонок завершается.
o Если во входяшем звонке указан контекст назначения, Asterisk проверяет наличие в настройках пира записи context=требуемый контекст.
o Если контекст не указан, звонок направляется на обработку в первую запись context=, наденную в настройках пира.

* Если в заголовке сообщения нового звонка не содержится поле username, Asterisk выполняет следующее:
o выполняет поиск секции type=user, в которой нет поля secret, и есть атрибуты allow/deny. Если такой пир найден, звонок принимается, и именем username звонящего становится название совпавшей секции.
o Выполняет поиск секции type=user, где нет поля secret, и нет атрибутов allow/deny. Если такая секция найдена, звонок принимается, и именем username звонящего становится название этой секции.
o Если совпадений выше найдено не было, Asterisk ищет секцию type=user, с указанным паролем secret или RSA ключем одновременно с allow/deny фильтром. Если такая секция найдена, и все проверки пройдены, астериск принимает звонок, и устанавливает именем username название секции.
* Выполнеяет поиск секции type=user с установленным паролем secret (или RSA ключем), но без фильтров allow/deny. Если проверка по паролю проходит, звонок принимается, и значение username устанавливается равным названию совпавшей секции.
* Asterisk отвергает звонок.

Какие возможные неожиданные последствия имеет такая схема аутентификации? Можно применять атаку типа brute force (грубой силы), перебирая пароли пользователей, даже не зная их username! При достаточном количестве записей пиров в iax.conf, вероятность подбора пароля к одной из них весьма высока. Как снизить риски такой атаки?

* Включить замедленную реакцию (delayreject=yes в [general] настройках iax.conf). Это позволит замедлить посылку негативного ответа сервера, снижая скорость перебора по словарю. Однако, злоумышленник может предположить о наличии данной опции, и перестроить атаку, не ожидая ответа, полагая, что положительный ответ придет быстро.
* Использовать атрибуты-фильтры allow/deny.
* Создать специальный гостевой экаунт без пароля и сетевых ограничений. Таким образом, алгоритм аутентификации "сработает" до проверки пароля, и атака по словарю уже не имеет смысла, так как принимается звонок с любым паролем. Вот так выглядит гостевой экаунт:
iax.conf
[guest]
type=user
context=guest

extensions.conf
[guest]
exten => _X.,1,Hangup
exten => i,1,Hangup

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

Примечение. type=friend покрывает type=user (включает его).