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

При резком росте счета начните с выгрузки детализации у оператора и сверки ее с CDR Asterisk: так вы увидите направления, время и внутренние каналы, если эти данные записывались. Затем сопоставьте события с логами и конфигурацией. Ни один файл сам по себе не доказывает взлом; ниже — порядок проверки и безопасной локализации.

С чего начать, если счет за звонки резко вырос

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

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

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

Какие данные хранит Asterisk и где их искать

В Asterisk есть разные источники, и смешивать их не стоит. Обычный журнал настраивается в logger.conf: там задаются назначения сообщений и уровни журналирования. Путь /var/log/asterisk/full распространен, но может отличаться или вообще не использоваться в конкретной установке. Поэтому проверьте конфигурацию и фактические файлы до команд поиска. Наличие файла full не означает, что туда записываются все нужные события. Объем и содержание зависят от конфигурации, загруженных модулей, ротации журналов и сборки Asterisk.

Для событий безопасности предусмотрен отдельный механизм журналирования. В документации Asterisk описан уровень security и пример назначения security_log => security в logger.conf; наличие соответствующих событий зависит от подключенных компонентов и конфигурации. Если этот журнал раньше не был включен, задним числом он записи не создаст. Отдельно полезно проверить системный журнал и централизованный сбор, если они настроены. Я не включаю подробную отладку наугад на загруженной АТС: сначала оцениваю объем диска и влияние, потом ограничиваю время сбора и проверяю ротацию.

CDR — журнал сведений о вызовах, а не полный протокол каждого действия. Доступные поля обычно помогают сопоставить источник, назначение, канал, время начала и завершения, длительность и итог, но фактический набор зависит от backend и сценария звонка. Модули CDR могут хранить данные в CSV или реляционной базе; хранение должно быть настроено и проверено. Сложные переводы и ветвления могут отражаться не одной строкой. Если нужна подробная хронология действий с каналами, у Asterisk есть CEL; она дает более детальные события, но также требует заранее настроенного хранения.

В конфигурации сначала смотрю на logger.conf, CDR/CEL backend и правила ротации, затем — на диалплан и параметры внутренних учетных записей. Не выкладывайте конфиги в тикет или публичный чат целиком: там могут оказаться секреты, номера и сетевые адреса. Для внешней консультации подготовьте копию с замаскированными значениями. В статье о защите Asterisk от атак отдельно разобраны меры, которые снижают вероятность повторного инцидента; сейчас же важнее собрать имеющиеся данные без потери контекста.

• Проверьте, куда пишет logger.conf и какие уровни включены.
• Уточните backend CDR и период хранения.
• Проверьте, включались ли security-журнал и CEL до инцидента.

Как сопоставить CDR, журналы и события

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

Проверить состояние CDR можно из консоли Asterisk командой cdr show status. Для PJSIP список настроенных конечных точек показывает pjsip show endpoints. Это диагностические команды: первая не гарантирует, что нужный backend записывал данные весь спорный период, вторая не устанавливает, кто инициировал конкретный разговор. Команды выполните с правами доступа к CLI, принятыми в вашей установке; если консоль недоступна, попросите ответственного администратора выгрузить результат. В детализации звонков сначала найдите повторяющиеся неизвестные направления, одинаковые необычные интервалы и каналы, которых нет в рабочем расписании.

Если журнал доступен по стандартному для вашей установки пути, посмотреть последние записи можно так: tail -n 200 /var/log/asterisk/full. Следить за новыми строками можно через tail -f /var/log/asterisk/full, но это не поиск по истории и не заменяет сохранение файла. Команды предполагают, что путь действительно верен и у вас есть права чтения. Ищите записи около времени спорного вызова и сверяйте их с CDR; имена сообщений зависят от версии, канального драйвера и уровня логирования. Ключ -f не «включает аудит»: он лишь показывает новые строки выбранного файла.

Ошибки авторизации — повод для проверки, не доказательство успешного доступа. В PJSIP ответ 401 сам по себе тоже не доказывает, что известная учетная запись была атакована: документация объясняет, что Asterisk может отвечать так и для неизвестной конечной точки, чтобы не раскрывать ее наличие. Смотрите на последовательность запросов, адрес источника в локальных журналах, состояние конечной точки, успешные регистрации и соответствующие исходящие вызовы. Для более детального обмена PJSIP отладочное логирование включают только на короткий диагностический интервал и затем отключают: оно может содержать чувствительные данные и быстро увеличивать объем журналов.

Проверяйте также изменения конфигурации и учетных записей за тот же период. Сравните резервную копию конфигурации с текущими файлами, историю административных действий и список активных внутренних номеров. Если система управления телефонией ведет собственный аудит, сохраните и его. Не утверждайте, что «IP из лога и есть мошенник»: это может быть адрес оператора, NAT-шлюза или легитимного клиента, а запись могла быть сформирована прокси. Сначала подтвердите источник по сетевой схеме и данным провайдера. Для подробной настройки endpoint и их сопоставления пригодится руководство по PJSIP в Asterisk.

• Сверьте часовой пояс и интервал событий.
• Сопоставьте назначение, канал, время и длительность.
• Отдельно пометьте пробелы в логах и расхождения источников.

Разбор условного случая «Радуга-Сервис»

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

Предположим, CDR показывает вызовы через внутренний канал, который команда считает давно неиспользуемым. Это делает учетную запись кандидатом на проверку, но еще не подтверждает, что бывший сотрудник или внешний человек звонил с нее. Я сверяю имя endpoint, его auth и AOR в используемом драйвере, дату отключения сотрудника, текущий диалплан и запись о последнем изменении конфигурации. Для старой chan_sip и res_pjsip синтаксис разный; нельзя механически вписать один и тот же параметр в sip.conf и pjsip.conf. Сначала определите драйвер, затем действуйте по документации своей версии.

Если текущие вызовы действительно идут через эту учетную запись, вместе с владельцем телефонии временно запрещаем ей исходящие направления или отключаем ее в системе управления, сохраняя копию конфигурации и время изменения. Одновременно меняем связанный секрет и проверяем, не использовали ли его повторно в другом месте. Удаление endpoint вслепую может оборвать легитимную работу или стереть контекст расследования. Если атака идет через транк или ошибочный маршрут, блокировка одного внутреннего номера ничего не исправит — сверяем точку входа и правила исходящей маршрутизации до объявления инцидента закрытым.

Затем проверяем похожие учетные записи, гостевой или анонимный доступ, неиспользуемые направления и права контекстов. Ищем правила, которые выпускают наружу звонки шире, чем нужно сотрудникам. Настраиваем лимиты у оператора и мониторинг расходов, если провайдер это поддерживает. Итог формулируем предметно: какие звонки подтвердились, какие данные отсутствовали, что ограничили, что изменили и кто проверит работу после изменения. Пароль вроде admin/admin — не средство экономии времени, а открытую дверь проще заменить до тревоги.

• Сохранить исходную детализацию и копии журналов.
• Подтвердить endpoint и маршрут по конфигурации.
• Ограничить подтвержденный источник и проверить соседние правила.

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

После локализации я устраняю установленную причину, а не «обновляю всё подряд». Удаляю неиспользуемые учетные записи после согласования, задаю уникальные длинные секреты для оставшихся и ограничиваю исходящие направления по рабочей необходимости. Для транка с провайдером применяю поддерживаемый им способ идентификации и список разрешенных адресов, если он доступен. Входящие SIP-соединения и медиатрафик требуют разных правил; номера портов и диапазон RTP определяются транспортом и настройками конкретной АТС. Порт 5060 часто используется для SIP, но объявлять его обязательным и открытым всему интернету нельзя.

Проверьте фактические слушающие адреса и правила межсетевого экрана с учетом конфигурации, а не по универсальному списку из статьи. В документации Asterisk отмечено, что пример конфигурации make samples может открыть порты для VoIP; это не означает, что любая установленная система открыта одинаково. Ограничивайте доступ источниками, которым он действительно нужен, и проверяйте, что звонки через разрешенные транки продолжают работать. Для сценариев с внешней публикацией оцените шифрование сигнализации и медиапотока, но не путайте шифрование с контролем того, кому разрешен исходящий вызов.

Зафиксируйте до и после: результат cdr show status, список endpoint, примененные ограничения, тестовый входящий и исходящий звонок, а также получение нового события журналирования. Убедитесь, что CDR записывается в ожидаемый backend и файлы не исчезают после ротации. Настройте уведомление на признаки, которые можно надежно измерить: резкий рост расходов, новые направления или превышение согласованного лимита. Порог выберите с владельцем телефонии по обычной нагрузке, а не из чужого шаблона. Если CDR или security-журнал отсутствовали до инцидента, включите их и проверьте контрольным вызовом — но не обещайте, что это восстановит старые события.

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

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

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