Что проверить в Asterisk перед открытием SIP-доступа

До подключения Asterisk к внешней сети я проверяю пять вещей: версию, доступность SIP-порта, правила аутентификации, права процесса и журналы. Это не докажет, что АТС неуязвима, зато быстро покажет, куда смотреть первым делом и что закрыть до подробного аудита.

Что входит в короткий аудит Asterisk

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

У Asterisk есть два отдельных слоя защиты: сетевой — шифрование и аутентификация — и защита диалплана, то есть проверка, кому разрешено пользоваться услугами АТС. Хороший пароль не исправит слишком широкий контекст вызовов; закрытый порт сам по себе не ограничит пользователя, которому уже выдали доступ. Я прохожу эти проверки по очереди и фиксирую, что подтверждено настройками, а что пока только предполагается. «Звонки идут» — это проверка связи, не аудит безопасности.

Чтобы результатом проверки был план действий, а не тревожная фраза «АТС небезопасна», я записываю для каждой находки четыре вещи: что именно увидел, почему это важно, какое изменение предлагаю и как проверим, что оно не сломало звонки. Например: «SIP доступен от любого источника; оставить доступ оператору и офисным адресам; после изменения проверить входящий и исходящий сценарии». Такой формат помогает руководителю выбрать, что исправлять сразу, а что планировать на окно обслуживания. В коротком обзоре я отделяю подтверждённую настройку от предположения и не называю каждую открытую службу уязвимостью. Если проверки делаются перед подключением новой АТС к сети, первым блокирующим условием для меня остаётся неизвестный источник доступа. Я также помечаю, где заканчивается быстрый просмотр: если нет доступа к маршрутизатору, биллингу или конфигурации панели, это не «чисто», а непроверенный участок. Владельцу АТС проще принять решение, когда ограничения доступа названы прямо и не спрятаны в длинном техническом отчёте.

Как сверить версию Asterisk с advisory

Сначала выясняю версию именно того экземпляра, который обслуживает звонки. Для локальной установки команда asterisk -V показывает версию установленного исполняемого файла. На сервере с несколькими сборками или контейнерами проверьте нужную среду: запуск команды на хосте не обязательно покажет версию процесса внутри контейнера. Не запускайте случайный образ с тегом latest только ради диагностики: он может измениться после публикации инструкции и не совпадать с рабочей АТС.

Затем сравниваю результат с конкретным предупреждением проекта Asterisk, а не с агрегатором, который сваливает в один список разные ветки и последствия. Например, CVE-2025-57767 затрагивает релизы веток 20, 21 и 22 до исправлений 20.15.2, 21.10.2 и 22.5.2 соответственно. Причина — некорректный SIP-заголовок Authorization; описанное последствие — сбой Asterisk, а не автоматический захват сервера. Для условного примера ООО «Калина» возьмём Asterisk 20.15.1: этот релиз попадает в диапазон advisory, а исправление для ветки — 20.15.2. Это учебный сценарий, не отчёт о реальном клиенте. Общие принципы и другие случаи собраны в обзоре уязвимостей Asterisk.

Advisory нужно читать целиком: в нём важны не только затронутая версия и номер исправления, но и предварительные условия, затронутый модуль и последствие. Для CVE-2025-57767 речь идёт о специально сформированном SIP-запросе и сбое процесса; это серьёзная проблема доступности, но по описанию не кража учётных данных и не запуск команд в системе. Исправление подбирают по той же ветке, что установлена у вас, а не по самой большой цифре в соседнем выпуске. После установки я проверяю версию ещё раз и отдельно делаю звонки по основным маршрутам. Если пакет получен из репозитория дистрибутива или поставки АТС, сверяю его бюллетень и способ обновления: заменять бинарник вручную поверх управляемого пакета — плохой способ сохранить поддержку и возможность отката. Если установленный выпуск уже не поддерживается проектом или поставщиком, одного патча может быть мало: сначала нужен план перехода на поддерживаемую ветку с проверкой совместимости модулей и телефонов. Я не предлагаю обновление в рабочее время наугад и не называю ветку безопасной только потому, что она новее. Фиксирую источник пакета и дату проверки advisory.

Какие SIP-порты доступны снаружи

Номера портов сами по себе не доказывают, что сервер открыт всему интернету. Для SIP стандартно используются 5060 для UDP/TCP и 5061 для TLS, но Asterisk может слушать другие адреса и порты, а межсетевой экран — пропускать только конкретные источники. Поэтому я проверяю реальные правила на периметре и фактический транспорт АТС: кому нужен доступ — внутренним телефонам, провайдеру, удалённым сотрудникам — и с каких адресов он должен приходить. Порты веб-интерфейса здесь не приписываю Asterisk: веб-панель, если она есть, может быть отдельным компонентом.

Есть и частая путаница в настройке PJSIP: параметр allow задаёт разрешённые медиакодеки, а не список IP-подсетей. Для IP-фильтрации в настройках PJSIP служат ACL и правила permit/deny; на внешнем периметре ограничения задаются межсетевым экраном. Проверяйте оба слоя и не вставляйте пример подсети из чужой статьи в рабочую конфигурацию. Если телефонные регистрации доступны снаружи, отдельная мера — защита от SIP-перебора; практические варианты разобраны в статье про Fail2ban для Asterisk.

Составьте простую карту источников: какие телефоны регистрируются локально, какие подключения идут через удалённый доступ, а какие адреса принадлежат провайдеру. Сверьте её с правилами межсетевого экрана и активными транспортами, а затем проверьте доступ с внешней сети тем способом, которым пользуется провайдер. Внутренняя проверка списка правил не всегда показывает итоговое поведение маршрутизатора, NAT или облачного фильтра. При этом не закрывайте адреса вслепую: у оператора могут быть несколько узлов, а телефоны сотрудников — работать из разных сетей. Запросите актуальные параметры у поставщика связи и оставьте документированное исключение только для нужных подключений. Если схема меняется, сохраните старые правила и время проверки, чтобы вернуть связь при несовместимости. В той же карте отдельно отмечаю панель управления, если она установлена: её адрес, способы входа и круг пользователей — отдельный вопрос, который нельзя решить закрытием SIP-транспорта. Панель не должна становиться неучтённым исключением в периметре. Перед изменением правил я уточняю, какие регистрации ожидаются в рабочем графике и кто подтвердит, что телефоны вернулись в сеть.

Могут ли учётные записи звонить куда угодно

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

Отдельно проверяю контекст диалплана для каждого endpoint и входящего транка. В документации Asterisk прямо советуют не давать контекстам входящих каналов доступ к исходящим платным направлениям, если такой доступ там не нужен. Это важнее охоты за абстрактными «дырками»: можно закрыть весь SIP снаружи, но оставить внутреннему подключению маршрут, который оно не должно выполнять. В условном примере ООО «Калина» после обновления я отдельно проверяю два сценария: обычный звонок между внутренними номерами и разрешённый исходящий вызов; результат записываю как критерий приёмки, а не как доказательство полной неуязвимости.

Для каждого endpoint и транка я выписываю ожидаемый набор действий: регистрация, внутренний звонок, исходящий городской вызов, перевод на коллегу и, если используется, международное направление. Затем сопоставляю действия с его контекстом и шаблонами набора. Тест должен включать как разрешённый, так и запрещённый маршрут: если телефон звонит куда надо, это ещё не доказывает, что он не может набрать лишнее. Административные функции, переадресация и исходящие правила тоже входят в проверку, когда они доступны из данного контекста. При изменении диалплана я заранее фиксирую ожидаемые номера, ответственных и окно проверки. Так можно найти избыточное разрешение без хаотичного перебора маршрутов и без остановки всей телефонии. Проверяю и список учётных записей: действующие устройства, временные тестовые подключения, старые сотрудники, неиспользуемые шлюзы. Отключать запись без владельца нельзя, но оставлять её навсегда «на всякий случай» тоже не решение. У каждой активной записи должны быть назначение, ответственный и понятное основание для исходящих вызовов. Неиспользуемые доступы сначала подтверждаю у владельца, потом отключаю согласованно.

Под каким пользователем работает Asterisk

Процесс Asterisk не следует запускать от root: документация проекта прямо предупреждает, что это увеличивает последствия ошибок конфигурации. Для запуска от отдельного пользователя и группы есть параметры -U и -G, но их нельзя механически дописать в unit-файл: выбранной учётной записи нужны права на каталоги, сокет, базу и журналы, которые использует конкретная установка. Сначала проверьте фактические параметры службы и владельцев этих каталогов, затем меняйте запуск в согласованное окно и тестируйте звонки.

Права на конфигурацию тоже оцениваю по назначению, а не по универсальному числу из чужого чек-листа. Режим 777 на конфигурационном файле даёт всем локальным пользователям запись и чтение — это повод разобраться немедленно. Но приказ назначить одинаковые права и одного владельца всем файлам может сломать обновление или работу панели управления: разные пакеты и сборки назначают права по-разному. Нужный итог проще сформулировать точно: посторонний локальный пользователь не должен менять SIP-учётные записи и маршруты, а сервис должен читать только то, что ему действительно нужно.

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

Как проверить журналы и тестовые вызовы

В Asterisk состав и направления журналов настраиваются в logger.conf; каталоги установки и логов могут быть изменены в asterisk.conf. Поэтому путь /var/log/asterisk/full встречается часто, но не является обещанием, что у любой АТС он включён и содержит нужные события. Я выясняю, какие файлы, консоль или syslog получает конкретная установка, включены ли полезные уровни сообщений, есть ли ротация и кто может читать записи. Не храните журналы только на диске, который заполнится первым же сбоем, и не включайте избыточную отладку без причины.

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

У каждого сигнала должен быть понятный владелец и действие: кто смотрит ошибку регистрации, кому приходит сообщение о необычном исходящем вызове, где сверяется счёт и сколько хранятся журналы. Сам факт, что запись где-то создаётся, ещё не означает, что кто-то её увидит вовремя. Я проверяю доставку уведомления отдельным тестом и убеждаюсь, что после ротации файл не исчезает из системы сбора. Доступ к журналам ограничивают по роли: там могут быть номера, адреса устройств и служебные данные. В конце проверки оставляю короткую инструкцию: какие события отслеживаются, кто реагирует, где найти журнал и как выполнить контрольный звонок. Если мониторинг ещё не настроен, честно отмечаю это как следующий шаг, не обещая, что одна настройка логирования сама остановит атаку. Для сопоставления событий полезно заранее знать часовой пояс системы и оператора, иначе отметки из двух источников легко сравнить неправильно. Проверяю, что команда знает, кто получает уведомление вне рабочего времени, и что уведомление содержит достаточно данных для первой реакции, но не рассылает секреты и лишние персональные сведения. Это отдельный процесс сопровождения, а не флажок в интерфейсе.

Частые вопросы