Что известно о шифровальщиках и защите Asterisk

Проверенные первоисточники не подтверждают описанную связку Medusa, Asterisk и BlackSuit. Это не доказывает, что такой инцидент невозможен; это значит, что выдавать его за установленный факт нельзя. Я разбираю, что известно об этих именах, где у АТС реальные точки риска и что проверить в первую очередь.

Medusa и BlackSuit — это одна атака?

Слово Medusa здесь требует уточнения. В первичной документации Foofus так называется модульный инструмент для проверки удалённых учётных записей на сетевых сервисах. Отдельно существует семейство вымогателей BlackSuit, о котором выпустили совместное предупреждение CISA и FBI. Это названия разных сущностей: инструмент для проверки паролей сам по себе не является участником группы BlackSuit. Документация инструмента перечисляет поддерживаемые модули; я не нашёл в ней подтверждения, что именно эта программа перебирает SIP или Asterisk Manager Interface (AMI). Значит, утверждение о таком конкретном способе атаки требует отдельного источника, которого в исходном тексте нет.

В предупреждении CISA и FBI описаны наблюдавшиеся при BlackSuit тактики и меры защиты. В рассмотренном документе Asterisk, AMI и SIP не названы как отдельный путь проникновения. Это ограниченный вывод по конкретному публичному материалу, а не заявление, что ни одна АТС никогда не подвергалась атаке. Без образца, журналов, заметки о выкупе и результатов расследования назвать именно BlackSuit нельзя. Тем более нельзя дорисовывать маршрут «подбор пароля — root — шифрование» только потому, что он звучит убедительно.

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

Что известно о кейсе «Тополь-Сервис»

В качестве условного примера оставляю только компанию, названную в исходном поле company: «Тополь-Сервис». Представим, что сотрудники утром обнаружили: входящие звонки не доходят, а часть настроек АТС изменилась. Это модель ситуации для разбора, а не подтверждённый отчёт об инциденте. В материалах нет журналов, заключения расследования или документов, по которым можно установить время атаки, конкретную версию Asterisk, имя вредоносной программы, сумму ущерба и срок восстановления. Поэтому я удалил такие подробности из фактического повествования, а не стал выдавать их за историю клиента.

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

Если посторонний получил доступ к управлению АТС или к серверу, последствия зависят от конкретных полномочий. Он может менять маршруты, инициировать нежелательные звонки, читать доступные ему данные или нарушить работу служб. Шифрование файлов возможно только там, куда вредоносная программа добралась и куда у неё есть права записи; это не означает, что вся система непременно зашифрована. Нельзя заранее утверждать и обратное — что данные целы. Сначала фиксируют признаки, затем проверяют каждый слой. Так выглядит разбор, а не сюжет с заранее назначенным злодеем.

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

Если нужен разбор конкретной конфигурации, мы можем проверить АТС, доступы и резервные копии по этому плану.

• «Тополь-Сервис» — условный пример из статьи
• Причину сбоя устанавливают по журналам и настройкам
• Права SIP-учётной записи не равны root-доступу
• Семейство вымогателя нельзя определить по одному симптому

Где у Asterisk настоящая поверхность риска

AMI — интерфейс управления Asterisk. Официальная документация указывает TCP-порт 5038 по умолчанию, если AMI включён в manager.conf. Через интерфейс можно управлять PBX и выполнять команды Asterisk; набор действий зависит от выданных пользователю прав. В частности, разрешение command позволяет запускать команды CLI. Поэтому вопрос не сводится к тому, открыт ли порт: нужно выяснить, включён ли интерфейс, с каких адресов к нему можно подключиться, какие учётные записи существуют и какие разрешения у каждой. Если AMI не нужен, его не следует оставлять доступным «на всякий случай».

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

Неверно обещать, что одна строка в dialplan сама по себе всегда даёт выполнение shell-команды. Команда может быть доступна только при определённых приложениях, разрешениях, контексте и внешних условиях; запуск от root также зависит от способа установки и настроек службы. Подтверждённая уязвимость в конкретном модуле — отдельный риск со своими затронутыми версиями и исправлением. Для неё нужно читать бюллетень разработчика, а не собирать в один сценарий любые старые CVE. Номера CVE из исходного текста я убрал: один не удалось подтвердить в NVD или у разработчика, второй не нашёлся в проверенных первичных базах и бюллетенях.

Для звонков с шифрованием у Asterisk есть два разных слоя. TLS защищает сигнализацию между совместимыми узлами, а SRTP — медиапоток с голосом. Это полезно для конфиденциальности передачи, но шифрование не отберёт лишние права у учётной записи и не остановит перебор пароля. Защита канала и защита доступа решают разные задачи; пункт «включить TLS/SRTP» не закрывает весь список рисков.

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

Как укрепить АТС без мифических настроек

Начните с установленной версии и статуса её поддержки. У проекта Asterisk несколько серий релизов с разными сроками сопровождения; после окончания жизненного цикла серия перестаёт получать исправления. Сверяйте версию не с советом из старой статьи, а с официальной таблицей релизов и бюллетенями безопасности. Пакет Linux-дистрибутива иногда получает исправление без смены видимой старшей версии, поэтому проверяйте ещё и информацию сопровождающего дистрибутив. Универсальный совет «поставьте 18.x» или «оставьте 22.10.0 — это безопасно» без даты и конкретного бюллетеня бесполезен.

Вот конкретный пример того, почему патч нельзя отрывать от описания проблемы. В бюллетене AST-2022-003 разработчик описал возможную SQL-инъекцию в модуле func_odbc и перечислил исправленные версии 16.25.2, 18.11.2 и 19.3.2. Это сведения о том конкретном дефекте, а не заявление, что перечисленные старые версии подходят для установки сегодня. В официальной таблице статусов есть сроки поддержки каждой ветки; текущий пакет и активные бюллетени нужно проверять на дату работ. Я сохраняю такую привязку «дефект — затронутая ветка — исправление», иначе точный номер релиза создаёт ложное чувство безопасности.

Для AMI сначала определите, нужен ли он вообще. Если нужен, ограничьте подключения административной сетью и списком доверенных адресов, используйте отдельную учётную запись для каждого интеграционного сервиса и оставляйте только нужные разрешения. Убирайте неиспользуемые manager-пользователи и не выдавайте command без ясной причины. Настройка ACL и сетевого фильтра должна соответствовать фактической схеме: адрес SIP-провайдера, телефоны и сервер интеграции — разные источники трафика. Не копируйте чужую bindaddr вслепую: допустимый адрес зависит от того, откуда именно должен принимать соединения ваш сервер. Для аудита я отдельно перечисляю, кому действительно нужны AMI и SIP, и сверяю это с правилами на внешнем межсетевом экране и самом сервере. Если список доверенных адресов ведут только на одном из этих уровней, второй может оставить лишний доступ. Схему адресов и назначений фиксирую рядом с владельцем сервиса: после смены оператора, телефонов или интеграции правила нужно пересмотреть, иначе старое исключение проживёт дольше причины, по которой его добавили.

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

TLS и SRTP включайте с учётом поддержки на телефонах, шлюзах и у оператора, а затем проверьте согласование соединения и сертификатов. TLS шифрует сигнализацию, SRTP — голосовой трафик; отсутствие поддержки на одном из концов может помешать вызову или оставить часть соединения без ожидаемой защиты. Отдельно настройте резервное копирование конфигурации, голосовых сообщений и нужных данных интеграций. Храните копии так, чтобы компрометация самой АТС не давала возможности удалить их теми же учётными данными. Регулярно проверяйте восстановление на отдельной среде — слово «успешно» в журнале задания ещё не доказывает, что систему можно поднять.

Логи нужны для ответа на конкретные вопросы: кто подключался к AMI, какие аккаунты SIP не прошли аутентификацию, когда меняли dialplan и откуда появились необычные исходящие вызовы. Сохраняйте журналы не только на самом сервере и назначьте человека, который разбирает уведомления. Фильтр, который шлёт сотню сообщений без приоритета, быстро становится декорацией. Я предпочитаю несколько понятных сигналов — массовые ошибки регистрации, неожиданные изменения конфигурации, всплеск международных вызовов — и заранее описанные действия для каждого из них.

• Сверить ветку Asterisk и бюллетени безопасности
• Ограничить AMI и сократить его права
• Проверить SIP-секреты и разрешённые направления
• Настроить и проверить резервное восстановление
• Контролировать события входа и изменения конфигурации

Что делать при подозрении на компрометацию

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

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

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

Для компании «Тополь-Сервис» в нашем условном примере такой порядок дал бы понятный план: сохранить журналы, остановить нежелательные вызовы, определить охват, восстановить чистую АТС и проверить маршруты. Но без конкретных артефактов я не приписываю этому сценарию BlackSuit, Medusa или выдуманный срок простоя. Если нужен прикладной разбор, можно сопоставить его с проверкой журналов Asterisk и отдельно установить причину сбоя. Название вредоносной программы — итог расследования, а не его стартовая гипотеза.

Моя короткая памятка для ответственного за связь: запишите, что изменилось и когда; ограничьте подозрительную активность; сохраните журналы; смените секреты с чистого устройства; восстановите только из проверенной копии; проверьте звонки и оставьте мониторинг включённым. Если есть сомнение, что злоумышленник получил доступ к Linux, рассматривайте систему как недоверенную до проверки и не возвращайте её в сеть только потому, что телефоны снова зазвонили.

• Остановить подозрительные исходящие вызовы
• Сохранить журналы и зафиксировать изменения
• Сменить доступы и проверить AMI
• Восстановить систему из проверенной копии
• Проверить тестовые вызовы и наблюдение

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