Как ограничить ущерб от взлома Asterisk

Защитить Asterisk от телефонного фрода можно только несколькими ограничениями сразу: закрыть лишний сетевой доступ, разделить права на направления, задать пределы вызовов и настроить оповещения. Ни один фильтр не спасёт от украденного пароля сам по себе. Разбираю пять практических мер для небольшого офиса.

Как украденный пароль превращает АТС в международный шлюз

Качество связи — только одна часть наблюдения за АТС. Теперь речь о событиях, которые бьют не по качеству, а по кошельку: события, которые бьют не по качеству, а по кошельку. Схема проста: злоумышленник получает данные SIP-учётки, регистрируется на АТС и пытается набрать направления с высокой стоимостью. Расходы возникают на стороне оператора, который обслуживает ваш транк. Источником утечки может быть слабый пароль, телефон или конфигурационный файл — угадывать единственный путь проникновения бессмысленно. Если вы держите АТС на своём сервере под присмотром, этот сценарий нужно закрывать в первую очередь, раньше любых красивых IVR.

Такие инциденты могут происходить ночью или в выходные, когда за журналами никто не следит. Но привязка фрода к расписанию — не закон природы: ориентируйтесь на собственные журналы и условия оператора. Размер ущерба зависит от тарифов, числа доступных каналов, скорости обнаружения и ограничений у провайдера; универсальной суммы тут нет. И списание по состоявшемуся вызову нельзя заранее объявлять безусловно неоспоримым: разбор зависит от договора, журналов и обстоятельств. Рассчитывать надо на предотвращение и быстрое ограничение расходов.

Защита от фрода — не одна галочка. Fail2ban может уменьшить шум от перебора, но не поможет, если пароль уже украден. Поэтому я строю несколько рубежей: кто может обращаться к SIP, куда может звонить конкретный номер, сколько вызовов разрешено, кто получает сигнал о подозрительной активности и кто управляет самой АТС. Каждый рубеж решает свою задачу; вместе они ограничивают вероятность инцидента и возможный ущерб.

Слой 1: fail2ban и ACL против перебора регистраций

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

При разборе ошибок и атак на PJSIP полезно сначала проверить саму регистрацию и источник SIP-запроса (типичные проблемы PJSIP). В PJSIP можно применять ACL к входящему SIP-трафику: параметры acl и contact_acl ссылаются на правила для адреса источника и адреса в SIP Contact. Не путайте эти проверки с проверкой пароля: конкретное поведение регистрации зависит от конфигурации и способа подключения телефона. Для внутренних номеров задайте длинные уникальные пароли. События безопасности Asterisk настраиваются отдельно: модуль журнала безопасности и уровень security в logger.conf позволяют записывать такие события, если модуль загружен и логирование настроено.

Fail2ban с подходящим фильтром может разбирать журналы и временно блокировать адреса после серии неудачных попыток. Не рассчитывайте на то, что любая установленная версия уже содержит готовый фильтр, подходящий к вашему формату журналов: проверьте фильтр, jail, путь к файлу и действие firewall. После настройки проверьте результат на контролируемом тестовом адресе командой fail2ban-client status ИМЯ_JAIL. Jail, который читает не тот файл или блокирует не тот трафик, существует только в конфиге.

• SIP-доступ разрешён только необходимым источникам
• ACL PJSIP сверены с реальной схемой регистрации
• У номеров длинные уникальные пароли
• Журнал security настроен, jail проверен на тесте

Слой 2: направления и права в dialplan

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

Для типового офиса можно задать несколько профилей: складским телефонам оставить местные и мобильные направления, менеджерам добавить междугородние, а международные открыть только тем, кому они действительно нужны. Это пример политики, а не универсальное распределение по должностям. Перед изменением проверьте шаблоны набора и тестовые вызовы: dialplan должен отказать запрещённому номеру до передачи вызова оператору. Дополнительный PIN в Authenticate() — лишь ещё одна проверка; он не заменяет сильные пароли и ограниченный контекст.

Отдельно проверьте, какие контексты достаются гостевым и служебным учёткам: факсу, домофону, тестовому номеру, который завели при запуске и забыли. Их тоже нужно включать в ревизию: забытая учётка может сохранить права, которые давно не нужны. Широкий шаблон вроде _X. в исходящем контексте требует особой проверки. Если вызов отклоняется неожиданно, полезно отличить ошибку маршрута от ответа SIP 403 (разбор SIP 403 в Asterisk). Такой шаблон он может разрешить больше направлений, чем планировалось. Ревизию контекстов я делаю после каждой крупной правки dialplan, а не раз в год: шаблон, добавленный ради одного теста, имеет свойство оставаться навсегда. Служебная учётка должна уметь ровно то, ради чего её завели.

• Местные и мобильные — всем
• Междугородние — по должности
• Международные — поимённо и через Authenticate с PIN
• Служебные учётки — минимальный контекст, без исходящих наружу

Слой 3: лимиты каналов и длительности

Даже разрешённое направление может стать проблемой, если одновременно идут многочисленные долгие вызовы. Для учёта каналов в dialplan есть GROUP() и GROUP_COUNT(): канал относят к группе, затем считают каналы этой группы и при достижении выбранного порога отказывают в новом вызове. Нужно аккуратно выбрать, когда помечать канал и какую категорию считать; неверная группировка даст неверный лимит. Так можно ограничивать число каналов на транк или для конкретной категории вызовов, но сам механизм не задаёт финансовый потолок.

У приложения Dial есть опция L(x[:y][:z]): она ограничивает длительность разговора; значения задаются в миллисекундах, а дополнительные параметры позволяют настроить предупреждение и время до завершения. Проверьте синтаксис для своей версии и протестируйте завершение вызова: лимит длительности не заменяет контроль стоимости тарифа. Например, для международного направления можно установить разумный предел длительности и отдельно ограничить число одновременных каналов — значения выбирают по рабочему сценарию, а не по красивой круглой цифре.

Попросите оператора проверить доступные именно на вашем тарифе ограничения: запрет направлений, лимит расходов, ограничение числа каналов или уведомления о балансе. Набор функций и скорость применения правил различаются. Внешний лимит особенно полезен, потому что он находится вне dialplan, но не называйте его единственной защитой: при компрометации учётной записи оператора или неверно выбранном пороге он не решит все проблемы. Сначала выясните, какое ограничение реально включено, как оно срабатывает и кто получит уведомление.

Слой 4: оповещения о необычных вызовах

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

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

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

Слой 5: учётные записи и доступ к панели управления

Веб-панель АТС, AMI и ARI требуют отдельной защиты. Для AMI документация задаёт настройки в manager.conf; ACL и ограниченные права учётной записи помогают сузить доступ, но интерфейс управления не следует выставлять без необходимости в общедоступную сеть. Сначала ограничьте сетевой доступ межсетевым экраном, затем настройте отдельные учётки и минимальные полномочия. У ARI собственная конфигурация и механизмы доступа — не переносите настройки AMI на другой интерфейс по аналогии.

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

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

• Панель, AMI и ARI — только из офиса или VPN
• Персональные учётки администраторов, без общего пароля
• Ревизия номеров раз в квартал против списка сотрудников
• Пароли веб-интерфейсов телефонов и закрытый автопровижининг

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