Что проверить в Asterisk, если звонки пропали при SIP-сканировании

Сам факт SIP-сканирования не доказывает, что он уронил Asterisk: OPTIONS бывает штатной проверкой доступности, а обрывы вызывают и ошибки NAT, и потеря регистрации, и перегрузка сервера. Я покажу, какие признаки собрать в CLI, что проверить в pjsip.conf и на firewall, и как отличить гипотезу об атаке от установленной причины.

Почему SIP-сканирование совпадает с обрывами звонков

Когда после жалобы на связь я вижу обращения к SIP-порту, сначала проверяю, действительно ли это тот транспорт и тот адрес, где слушает Asterisk. 5060 — распространённый порт SIP, но конфигурация может использовать другой порт, UDP или TCP; сам номер ничего не говорит о причине сбоя. Если АТС доступна из интернета, случайные запросы будут приходить даже без целевой атаки. Моя задача — установить, что сервер получил, что он ответил и что в это время происходило со звонками. Для компаний, которым нужна помощь с такой проверкой и сопровождением АТС, важно начать с данных, а не с обещания «закрыть всё одним правилом».

Особенно аккуратно я отношусь к OPTIONS. В PJSIP этот метод может быть штатной проверкой доступности контакта: параметр qualify_frequency задаёт интервал таких проверок. Поэтому один OPTIONS, как и несколько повторов, сами по себе не доказывают сканирование или попытку взлома. Я сопоставляю адрес источника, частоту, заголовки, ответы Asterisk и время жалобы. Повторные неудачные REGISTER и OPTIONS с неизвестного источника — разные события, их нельзя складывать в одну корзину. Если звонок оборвался, причина может оказаться в регистрации, NAT, маршруте RTP, диалплане или загрузке системы; совпадение по времени помогает выбрать проверку, но не заменяет её. Для первичной развилки я записываю отдельно: не регистрируется телефон, не устанавливается вызов или пропадает только звук. Это три разных симптома. Если endpoint остаётся доступен, а сбой есть лишь на исходящем направлении, сканирование не объясняет проблему без дополнительных признаков.

Какие команды включить для диагностики PJSIP

В Asterisk CLI я включаю трассировку командой pjsip set logger on. Она показывает SIP-сообщения в консоли; это не команда «записать всё в отдельный файл». Для общей детализации можно поднять уровни core set verbose 4 и core set debug 4, если в конкретной сборке и текущей задаче этого достаточно. В документации Asterisk эти уровни задаются отдельно от протокольной трассы. Сначала фиксирую точное время жалобы, затем включаю логирование на короткий интервал и воспроизвожу проблему. Когда данных достаточно, выполняю pjsip set logger off и возвращаю прежние уровни. Трасса может содержать номера, адреса и служебные заголовки, поэтому перед отправкой её нужно очистить от чувствительных данных. Важна и сторона запроса: Asterisk сам может отправлять OPTIONS удалённому контакту для проверки доступности, а входящий OPTIONS приходит от клиента к АТС. В трассе видны направление и адреса, поэтому не смешивайте штатное наблюдение за транком с внешним запросом к серверу.

После трассы проверяю состояние объектов через pjsip show endpoints и pjsip show endpoint <имя-endpoint>: видны endpoint, привязанные к нему параметры аутентификации, AoR и транспорт. В журнале ищу не просто большое число строк, а последовательность: пришёл ли REGISTER или INVITE, какой ответ вернулся, был ли запрос сопоставлен с endpoint и дошёл ли вызов до диалплана. Ошибки регистрации, тайм-ауты и успешный SIP-ответ указывают на разные участки цепочки. Если звонок устанавливается, но нет звука, это уже отдельная проверка медиапотока и NAT. Такой разбор полезнее, чем считать строки и объявлять каждую запись атакой; для более широкого списка причин пригодится разбор пяти причин падения Asterisk.

• `pjsip set logger on` — начать SIP-трассу.
• `pjsip show endpoints` — проверить объекты PJSIP.
• `pjsip set logger off` — завершить сбор трассы.

Что проверять в pjsip.conf и какие лимиты доступны

В обычной установке конфигурация PJSIP находится в /etc/asterisk/pjsip.conf, хотя пакет, контейнер или способ установки могут изменить расположение. Важно не искать одну магическую строку «защитить SIP»: endpoint, auth, aor и transport — разные объекты с разными задачами. Для входящего транка по IP секция identify с параметром match связывает адрес источника с endpoint. Это помогает Asterisk понять, к какому объекту относится запрос; такая привязка не является сетевым фаерволом и не ограничивает сама по себе частоту пакетов. Аутентификация тоже не заменяет проверку диалплана: даже корректно опознанному endpoint нельзя автоматически давать доступ к любым исходящим направлениям. До поиска бюллетеня я фиксирую выпуск командой core show version и выясняю, откуда установлен пакет. Одинаково выглядящие номера в разных ветках не всегда означают один набор исправлений. Так проще проверить применимость сообщения об уязвимости, не обновляя систему наугад.

Для неизвестных запросов PJSIP предоставляет параметры unidentified_request_count и unidentified_request_period в глобальной секции конфигурации. Когда число запросов, не сопоставленных с endpoint, от одного IP за заданный период достигает порога, Asterisk создаёт событие безопасности. Это не универсальный лимит всех SIP-запросов и не автоматический бан адреса. Значения нужно сверять с документацией своей ветки и поведением легитимных устройств, иначе можно получить шумные события и пропустить полезный сигнал. Секция identify определяет, к какому endpoint отнести входящий запрос; она не указывает адрес назначения исходящего вызова. Для этого endpoint должен ссылаться на AoR с актуальным контактом. Если AoR не загружен или не привязан, Asterisk не найдёт адрес телефона — даже если внешних запросов нет. Объект можно проверить командой pjsip show aor <имя-AoR>. А если поверх событий безопасности подключаете Fail2Ban для Asterisk, сначала проверьте, какие именно записи ловит правило и не блокирует ли оно легитимный транк.

• Сверить endpoint, auth, AoR и transport.
• Проверить, что `identify` сопоставляет ожидаемый источник.
• Отделить событие безопасности от сетевой блокировки.

Как обновлять Asterisk без ложного чувства защиты

Номер исправленного выпуска относится к конкретной ветке и бюллетеню, поэтому один набор цифр не отвечает на вопрос, какая версия нужна сегодня. Я сначала узнаю точный выпуск Asterisk командой core show version, затем нахожу соответствующее уведомление проекта и проверяю, относится ли оно к установленному модулю и сборке. Номер версии без ветки и описания дефекта мало что говорит: исправление одной проблемы ничего не доказывает насчёт другой. Состояние поддержки меняется, поэтому проверяйте уведомления именно для установленной ветки. Если Asterisk поставлен из репозитория дистрибутива, сверяйте описание пакета и его журнал изменений. Не всякий ответ 401 означает неверный пароль: при SIP digest-аутентификации сервер может сначала запросить учётные данные, после чего клиент повторит запрос. Смотрите, последовал ли повтор и чем завершилась попытка. Отдельно отметьте адрес, метод и время; сам код без последовательности не отвечает, кто и почему не дозвонился.

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

• Сверить выпуск с бюллетенем Asterisk и поставщика ОС.
• Проверить доступность исправлений для активной ветки.
• После обновления повторить контрольные звонки.

Что закрывает firewall и как проверить результат

Правила firewall настраиваю по реальной схеме: откуда подключаются телефоны и транки, какой транспорт слушает Asterisk и где проходит медиатрафик. Если провайдер использует известные адреса, входящий SIP можно ограничить ими и внутренними сетями. Если сотрудники подключаются из меняющихся сетей, правило «разрешить только один IP» оборвёт им связь — сначала проектируют доступ, потом фильтруют. Не надо без проверки блокировать порт 5060 целиком или объявлять его единственным нужным портом: фактический SIP-порт задаётся транспортом, а медиа использует отдельные настройки. Для внешнего доступа рассматривают отдельную точку фильтрации и ограничения частоты, но конкретная схема зависит от оборудования, провайдера и того, какие абоненты должны звонить. В секции identify проверяйте type=identify, имя endpoint и формат match: официальная документация требует IP-адрес, а не DNS-имя. Если запрос не сопоставляется, проверьте маску и выбранный модуль идентификации. Иначе ожидаемый транк может выглядеть для Asterisk так же, как неизвестный источник.

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

• Разрешать только нужные источники и транспорты.
• Проверить медиапоток отдельно от SIP-сигнализации.
• Повторить тестовые звонки после каждого изменения.

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