Я фрилансер, и основная моя специализация — решения IP телефонии на основе Asterisk.
На днях ко мне обратился один из моих довольно давних клиентов, у которого в прошлом году я внедрял телефонию для call-центра интернет-магазина. Там я ставил и настраивал только и исключительно Asterisk с сопутствующими пакетами, установкой же собственно сервера и ОС (Ubuntu), как и поддержкой системы после внедрения, занимался местный сисадмин, а ко мне изредка обращались с разовыми нетривиальными задачами, требующими квалификации большей, чем простая правка контекстов в диалплане. В этот раз им потребовалось изменить логику работы CDR в части статистики принятых вызовов по очередям.
Договорившись о стоимости и сроках, я приступил к работе. Каково же было мое удивление, когда после включения логирования незавершенных звонков в CDR пошел поток записей а-ля «UNKNOWN UNKNOWN» со статусом «FAILED»! Причем попытки дозвона были направлены на несколько литовских номеров в коде +370.
Поскольку мысль о подключении извне к самому asterisk была после проверки отброшена сразу (все рекомендации по безопасности были выполнены еще на этапе внедрения, стоял fail2ban, а sip-аккаунты имели жесткое ограничение по ip), и при этом AMI был отключен, то оставался один вариант — call-файлы. Так и оказалось. Уточнил у клиента: они не использовали эту технологию и тем более не звонили в Литву. Мораль? Правильно, банальный взлом.
При удалении call-файлов они через какое-то время появлялись снова. В cron вполне ожидаемо ничего лишнего не нашлось. Почесав в затылке, я запустил циклично lsof – но он не смог отловить в outgoing ничего интересного. Тогда после короткого гугления в бой пошла тяжелая артиллерия – inotify_tools. Картина вырисовалась любопытная: нечто постоянно генерило пресловутые файлы по несколько штук в секунду. Из чего я сделал вывод, что имею дело не с запускающейся по расписанию задачей, а с процессом или демоном.
Дальше – проще: через top и ps довольно быстро был отловлен подозрительный процесс, называвшийся «backup» и лежавший в /var/tmp/bkb.d. Им оказался простейший скрипт, постоянно копировавший в /var/spool/asterisk/outgoing лежавшие там же десяток call-файлов, содержавшие инициирование международного вызова на различные литовские номера. При этом, что самое интересное, звонки (точнее, попытки дозвона) производились через несуществующий транк, а call-файлы не содержали указания на соединение после дозвона с кем-то еще.
Выпилив зловреда и сделав требуемые модификации логики CDR, я сообщил клиенту ориентировочное время взлома и ожидаемо получил отдельную материальную благодарность за обнаружение этого факта. Что он будет с этим делать дальше – не знаю, задачи поиска дыры, через которую стал возможен взлом, передо мной не стояло. Хотя наружу там торчали только SIP, SSH и закрытая http-авторизацией вебморда статистики (разумеется, апач, как и астериск, запускались не из-под рута), так что выбор невелик.
Возможно, было более простое и быстрое решение поиска зловреда — но я все же не считаю себя linux админом широкого профиля, и применил то, что пришло в голову и нагуглилось по ходу дела. Однако мне до сих пор непонятно, кто, как и, главное, зачем устроил такой бессмысленный хак.
Автор: Vengant
