Я фрилансер, и моя основная специализация — решения IP-телефонии на базе Asterisk. На днях со мной обратился один из моих довольно давних клиентов, для которого в прошлом году я реализовал телефонию колл-центра интернет-магазина.
Там я установил и настроил только и исключительно Asterisk с сопутствующими пакетами; Установкой сервера и ОС (Ubuntu), а также поддержкой системы после внедрения занимался локальный сисадмин, и ко мне время от времени обращались с разовыми нетривиальными задачами, требующими чего-то большего, чем простая квалификация редактирования контекстов в диалплан.
На этот раз им нужно было изменить логику CDR с точки зрения статистики поступивших звонков по очереди.
Согласовав стоимость и сроки, я приступил к работе.
Каково же было мое удивление, когда после включения протоколирования незавершенных звонков в CDR начался поток записей а-ля «НЕИЗВЕСТНО НЕИЗВЕСТНО» со статусом «FAILED»! Более того, попытки дозвона были направлены на несколько литовских номеров с кодом +370. Так как сама идея подключения извне к астериску была сразу отброшена после проверки (все рекомендации по безопасности были соблюдены на этапе реализации, был фаил2бан, а у SIP-аккаунтов был жёсткий лимит по IP), а AMI был отключен, остался только остался один вариант - вызвать файлы.
Так и получилось.
Я уточнил у клиента: они не использовали эту технологию и уж точно не звонили в Литву.
Мораль? Правильно, банальный хак.
Когда файлы звонков удалялись, через некоторое время они снова появлялись.
Как и ожидалось, ничего лишнего в cron не обнаружено.
Почесывая затылок, я циклически запускал lsof — но в исходящем он не смог поймать ничего интересного.
Затем, после недолгого гугления, в бой пошла тяжелая артиллерия — inotify_tools. Картина получилась интересная: что-нибудь Он постоянно генерировал пресловутые файлы, по несколько в секунду.
Из чего я сделал вывод, что имею дело не с запланированным заданием, а с процессом или демоном.
Дальше проще: с помощью top и ps был быстро пойман подозрительный процесс под названием «backup» и расположенный в /var/tmp/bkb.d. Это оказался простой скрипт, который постоянно копировал в /var/spool/asterisk/outgoing десяток располагавшихся там файлов вызовов и содержал инициацию международного звонка на различные литовские номера.
При этом, что самое интересное, звонки (точнее, попытки дозвона) совершались через несуществующий транк, а файлы звонков не содержали никаких указаний на соединение после дозвона с кем-то другим.
Вырезав вредоносное ПО и внеся необходимые изменения в логику CDR, я сообщил клиенту предполагаемое время взлома и, как и ожидалось, получил особую финансовую благодарность за обнаружение этого факта.
Я не знаю, что он с этим сделает дальше; Передо мной не стояла задача найти дыру, через которую стал возможен взлом.
Хотя там торчали только SIP, SSH и закрытая http авторизацией веб-морда статистики (конечно, Apache, как и Asterisk, не запускался от root), поэтому выбор был невелик.
Возможно, существовало более простое и быстрое решение для поиска вредоносного ПО — но я все же не считаю себя универсальным Linux-администратором и пользовался тем, что приходило в голову, и попутно гуглил.
Однако я до сих пор не понимаю, кто, как и, главное, почему осуществили такой бессмысленный взлом.
Теги: #asterisk #voip #voip #информационная безопасность #asterisk
-
Как Работает Программа Disk Speedup
19 Oct, 24 -
Гренландия
19 Oct, 24 -
Пожиратели Батарей
19 Oct, 24 -
Облегченная Криптография Интернета Вещей
19 Oct, 24
