Как проверить маршруты и права в Asterisk

Проверяйте не только пароли SIP, но и контекст, куда попадает каждый входящий канал, доступные ему маршруты и реальные правила набора. Я покажу, как осмотреть загруженный dialplan, найти семь опасных мест и проверить правки без перезапуска Asterisk.

Почему безопасность начинается с контекста

Я начинаю аудит не с поиска «страшных приложений», а с маршрута вызова. Dialplan Asterisk — это набор инструкций обработки вызовов: channel driver помещает канал в заданный контекст, а расширения, приоритеты и переходы определяют дальнейшие действия. Контексты помогают разделять функции и классы обслуживания; включённый через include контекст расширяет набор доступных маршрутов. Поэтому граница между входящим, внутренним и исходящим трафиком должна быть намеренной. Сам по себе dialplan не исполняет произвольную команду от каждого звонка: опасные действия появляются там, где их явно добавили в логику и открыли к ним путь. Я проверяю не только содержимое extensions.conf, но и то, какие контексты назначены каналам и какие include или Goto связывают их между собой. Если нужен разбор такой схемы и смежных настроек, можно заказать аудит информационной безопасности. При чтении схемы я отмечаю источник канала: входящий транк, внутренний телефон или вызов, созданный приложением. Один и тот же номер может законно вести себя по-разному в разных контекстах, поэтому анализ строки расширения без начального контекста даёт неполную картину.

У Asterisk есть два связанных, но разных слоя защиты. Сетевая аутентификация отвечает, кто подключился; dialplan-авторизация — какие функции телефонии доступны этому источнику. Успешная регистрация SIP не должна автоматически означать право звонить на любой номер или пользоваться платным направлением. Для входящего транка назначают отдельный контекст с теми маршрутами, которые нужны именно ему; внутренние телефоны получают собственные разрешения. В документации Asterisk отдельно предупреждают: канал может использовать расширения того контекста, куда он попал, поэтому исходящие платные маршруты нельзя бездумно включать в доступную снаружи часть схемы. Это не означает, что всякая ошибка уже стала взломом: сначала должен существовать достижимый путь от конкретного канала к запрещённому действию. Но именно такие пути и надо искать, пока счёт за связь не стал способом узнать о них. Разница важна и при проверке: регистрация устройства подтверждает учётные данные, но не документирует весь набор доступных ему услуг. Матрица разрешений отдельно показывает, кто может звонить внутри офиса, на городские номера и на международные направления. Так видно, где маршрут действительно нужен, а где его добавили по привычке.

Как проверить загруженный dialplan

В типовой установке основной текстовый файл называется /etc/asterisk/extensions.conf, но путь зависит от каталога конфигурации и способа управления телефонией. FreePBX и другие панели могут генерировать часть конфигурации, а некоторые установки используют базы данных или отдельные механизмы загрузки. Сначала выясните, откуда именно берётся рабочее правило; правка генерируемого файла может исчезнуть при следующем сохранении в панели. Для подключения к работающей консоли используют asterisk -rvvv: эта команда присоединяет удалённую CLI-консоль с уровнем подробности 3. Она не строит полный отчёт о безопасности и не показывает каждую деталь разговора автоматически. Подробность относится к сообщениям консоли; фактический вывод зависит и от настроек Asterisk. Это хороший способ увидеть сообщения загрузки и диагностики, но не замена чтению конфигурации и проверке прав. Сопоставляйте как минимум два представления: конфигурацию, которой управляет администратор, и то, что показывает работающий процесс. Это помогает обнаружить ручную правку, автогенерацию или неожиданный include. Важно проверить связи между правилами и их фактическое состояние, а не полагаться на снимок панели.

В CLI посмотрите конкретный контекст командой dialplan show from-trunk или dialplan show <имя_контекста>. Так вы увидите загруженные расширения и шаблоны для выбранной части плана, а не только файл, который предположительно их породил. Затем проследите цепочки include и Goto до приложений, которые соединяют вызовы с внутренним абонентом, очередью или оператором связи. Для обычного dialplan из extensions.conf изменения загружают командой dialplan reload; документация описывает её как перезагрузку dialplan без остановки работы PBX. После неё проверьте тот же контекст командой dialplan show и выполните согласованные контрольные вызовы. Успешная загрузка означает, что Asterisk прочитал план, а не то, что план разрешает только нужные назначения. Если у вас конфигурацию создаёт панель или другой загрузчик, проверьте результат именно через него и не считайте команду универсальным исправлением. Для каждой группы сделайте два коротких теста: разрешённый звонок должен пройти по ожидаемому пути, запрещённый — остановиться до оператора. Записывайте начальный контекст и совпавшее расширение, иначе повторная проверка превращается в «звонили, вроде работало». Поведение при reload оценивайте отдельно от результата самого вызова.

Семь признаков, которые стоит проверить

Первый признак — входящий канал попадает в контекст, откуда достижимы платные исходящие маршруты. Второй — широкая маска, например _X., совпадает с диапазоном номеров заметно шире утверждённого. В Asterisk шаблон задаётся специальным синтаксисом; один символ звёздочки не следует считать универсальным совпадением. Третий — include или Goto открывает дорогу из контекста транка к маршрутам сотрудников или международной связи, хотя такой переход никто не планировал. Четвёртый — правило использует набранные цифры, Caller ID либо данные из внешней системы для построения следующего назначения, но список допустимых значений не проверяется. Это не автоматически уязвимость, но повод проследить каждый путь и сравнить его с таблицей разрешённых номеров. Маска удобна, пока администратор помнит, сколько именно она разрешает. Особенно внимательно смотрите на близкие шаблоны и порядок выбора совпадения: если назначение набирается из переменной, сравнивайте и исходную строку, и преобразованное значение. Не расширяйте правило, чтобы закрыть пропущенный префикс, пока не перечислили номера, которые оно начнёт принимать. Dialplan выполняет описанные условия, даже если автор имел в виду другое.

Пятый признак — вызов передаёт данные в AGI-скрипт, но неясно, кто может менять этот файл, какие аргументы он принимает и как обрабатывает ввод. AGI связывает dialplan с внешней программой; это рабочий интерфейс, а не доказательство ошибки само по себе. Шестой — никто не настроил или не проверяет журнал событий безопасности. В Asterisk для таких событий есть уровень security в logger.conf, но он не превращает обычный журнал в запись каждого вызова. Седьмой — нет контроля за необычным числом одновременных каналов, длительными или непривычными исходящими вызовами, а установленная ветка Asterisk давно не получает исправлений от поддерживающего её поставщика. Для наблюдения за каналами можно использовать AMI, если он включён и защищён; права менеджера требуют отдельного ограничения. Форумный фрагмент, старая версия или пустой журнал — не приговор. Это три причины проверить конфигурацию, а не объявлять систему взломанной. При проверке скрипта отделяйте факт его вызова от качества реализации: проверьте права на изменение, список доступных действий и обработку входных данных там, где это применимо. В мониторинге сверяйте активные каналы и необычные назначения с обычным графиком звонков компании. Порог зависит от нагрузки; честного универсального числа здесь нет.

Учебный сценарий: путь к дорогому маршруту

Покажу механику на условной модели с названием ООО «Медея-Сервис», которое уже указано в карточке статьи. Это не история реального клиента, не описание подтверждённого инцидента и не статистика АйТи-Фреш. Допустим, у компании есть входящий транк и отдельные внутренние телефоны. Для входящего канала настроили контекст, куда позднее включили общий исходящий контекст. В нём оказалось слишком широкое правило набора. Если конкретный звонок попал в этот контекст и правило направило его на транк оператора связи, у вызывающего канала может появиться возможность совершить нежелательный исходящий вызов. Условия важны: канал должен иметь этот контекст или получить переход в него, а маршрут должен вести к реально подключённому направлению. Без этих условий одна широкая маска не превращает станцию в доступный всему интернету шлюз. «Так исторически сложилось» — не проверка доступа. В аудите рядом с каждой стрелкой я ставлю подтверждение: параметр канала, запись контекста, строку include или совпавшее расширение. Если подтверждения нет, это гипотеза для следующей проверки, а не вывод о взломе.

Чтобы подтвердить или опровергнуть сценарий, я составляю простую цепочку: источник вызова → начальный контекст → доступные через include расширения → совпавший шаблон → приложение Dial и выбранный транк. Отдельно отмечаю, какой класс абонентов должен проходить каждый переход и какие назначения ему разрешены. Затем сравниваю правила с доступными записями вызовов и детализацией оператора: совпадают ли время, направление, длительность и назначение. Если есть только неправильное правило, но нет подходящего входного пути или транка, это ошибка конфигурации с потенциальным риском, а не доказательство состоявшегося мошенничества. Если нашли реальный вызов по неожиданному маршруту, фиксируйте конфигурацию и записи до изменения, чтобы разбор не держался на памяти. Без журналов и тарифа утверждать рост расходов нельзя; здесь уместна проверка маршрута, а не выдуманный итог. Проверьте несколько типов источника, потому что у внутреннего телефона и транка могут быть разные начальные контексты. Не используйте дорогой настоящий номер как тестовый пункт: согласуйте безопасное назначение с ответственными за телефонию и оператором. В карточке проверки укажите ожидаемый результат, а не только набранные цифры.

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

Я свожу контексты к понятной матрице: источник, начальный контекст, разрешённые назначения, запрещённые назначения, владелец правила. Для транка оставляю только необходимые входящие адресаты; исходящий набор доступен тем внутренним контекстам, которым он действительно нужен. Проверяю каждую строку include, а не только название секции: короткая ссылка способна расширить права дальше по цепочке. Широкую маску заменяю конкретными диапазонами или отдельными правилами, которые можно сопоставить с планом нумерации. Для дорогих направлений отдельно задаю разрешённые группы и лимиты на стороне оператора, если тариф и платформа это поддерживают. Пароли SIP, сетевые ограничения и правила диалплана дополняют друг друга, но один механизм не компенсирует другой. Перед применением сохраните текущую рабочую конфигурацию и подготовьте контрольные звонки для каждого класса доступа. Иначе легко убрать риск вместе с нужной связью. Матрица может быть простой: список исходных контекстов и явных групп назначений. На каждой связи укажите бизнес-причину и владельца; тогда при изменении маршрута понятно, кто должен подтвердить новый доступ. В небольшом офисе такой список поместится на одной странице и полезнее фразы «внутренним разрешить всё».

Логирование настраивают в logger.conf; расположение файлов и уровни зависят от конкретной конфигурации, поэтому я не обещаю каждому серверу один и тот же путь вроде /var/log/httpd или одинаковую раскладку Asterisk. Для событий безопасности предусмотрен отдельный уровень. Например, настройка security_log => security направляет такие события в файл с именем security_log; это не журнал всех разговоров и не полный аудит диалплана. Для отслеживания состояния каналов Asterisk предоставляет AMI, который передаёт события и позволяет наблюдать каналы и очереди. Это интерфейс управления, поэтому заведите отдельного пользователя с минимально нужными правами, ограничьте сетевой доступ и не выдавайте право на произвольные CLI-команды без необходимости. Дежурный должен знать, на какие события реагировать: сам факт наличия лог-файла не создаёт мониторинг. Стандартный logger.conf умеет направлять сообщения в файл, системный журнал или консоль; назначения проверяйте по своей конфигурации. Для долговременного учёта обычных звонков нужны подходящие отчёты, а не только security-события. Доступ к AMI не раздавайте тем же группам, которым разрешено набрать обычный номер: это интерфейс управления с более широкими возможностями.

Что делать, если нашли опасный маршрут

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

Исправление начинайте с конкретной причины: уберите лишний include, разведите контексты, сузьте шаблон или измените проверку входных данных в скрипте. Если обнаружена отдельная программная уязвимость, сверяйте её с бюллетенем проекта Asterisk и рекомендациями поставщика вашего дистрибутива; универсальное «обновить немедленно до последней версии» может не соответствовать поддерживаемой ветке и способу установки. Перед загрузкой проверьте изменения на согласованном наборе входящих и исходящих сценариев. После dialplan reload сравните вывод dialplan show с ожидаемой схемой, проверьте журнал и убедитесь, что разрешённые группы работают, а запрещённые назначения закрыты. Затем наблюдайте за каналами и сверяйте новые вызовы с операторской детализацией. У реакции нет универсального таймера в десять или тридцать секунд: скорость зависит от масштаба и доступных ограничений, а выдуманный норматив только мешает. Оставьте короткую запись: причина, изменённые контексты, результат разрешённого и запрещённого теста, место для проверки последующих событий. Так дежурному не придётся заново угадывать устройство маршрутов, а следующий аудит начнётся с фактической схемы.

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