Как стать автором
Обновить

Комментарии 15

все очень просто — тот кто ломал в литве держит эти номера за которые ему платят процент от полученных звонков. а клиенту приходит счет на мегабаксы потому что звонки там очень недешевые
Кстати, да, хорошая идея. Я-то сталкивался в основном с брутфорсом SIP аккаунтов со стороны кубинских телефонистов.
Хотя все равно странно. Ломать таким экзотическим способом, к тому же не добившись результата.
А вот нефиг на продакшне держать pbx_spool.so, впрочем как и 0.0.0.0:5038 с юзерами без permit/deny…
Про pbx_spool вы правы. Наступил один раз на грабли, буду теперь и это отключать где не используется :) Но где вы увидели 5038, да еще и с юзерами без permit/deny? Я же писал — AMI отключен, а лишние порты снаружи закрыты.
Про 5038 это было дополнение к вопросу о безопасности :)
У меня просто AMI везде используется, но обычно или забинден на 127.0.0.1 или закрыт фаерволом с жесткими ацл-ями. Да к тому же и over ssl (на 5039)…
Логично.
Если интересно продолжение истории — сегодня им кто-то снес все конфиги астериска. Тупо всю директорию /etc/asterisk, ага. Хорошо хоть бэкап был. После совместного скуривания логов auth выяснилось, что взлом был произведен не извне, а изнутри локальной сети. Причем весьма оригинально — заданием пароля и шелла для аккаунта nobody и внесением его в sudoers. Но изначально это было сделано из-под рута, так что пароль утек стопроцентно.
Да, печалька печальная. В принципе, не удивлен, ибо просто так ничего с +x не валяется в /var/tmp/. На моей практике было пару случаев подобно Вашим, только не с астериском,
Один раз был весьма оригинальный pwn:
Обратился ко мне старый заказчик с вопросом посмотреть на Windows 2003 сервер, говорит что работает отлично, вот только незадача: периодически заканчивается свободное место, типа я туда ничего не лью, однако 250Г заполняется каждый день, уже устал чистить…
Ну зашел туда, ничего в процессах не видно (и стандартными средствами и нестандартными), расхода места тоже не видно.
Потом зашел фаром через RPC с другой машины и о#%2*л: процесс лист забит какими-то процессами непонятного происхождения. И, почему-то, у всех хоумдир C:\RECYCLER\левый-[UUID]\что-то там. Естественно, что по прямому пути там ничего не было.
Зашел через \\?\c:\ — а там… порно-рассадник с блекджеком и французскими девушками (в прямом смысле).
Порно-ФТП, с отдельными юзерами, с полным списком фильмов, тщательно отсортированным по жанрам, интересам, размерам и тд…
С акцесс-листами и списком IP-ов. Ну и классика жанра — все это управлялось через IRC.

Все мои попытки вычистить эту гадость, зафаерволиться и прочее — не помогли. Как только фаерволил одно — появлялись какие-то открытые порты (фаервол правился тоже), я уже туда втулил wipfw, так же, правила правились и прочее. Пришлось забакапить все и переустановить…
Да, интересный случай. Я бы попробовал отключить его от прямого инета, подключить через отдельный фаерволл и смотреть уже на нем, куда это гуано ломится. Дальше закрыть, хоть бы и блоком подсетей, канал управления — и не торопясь чистить остальное. Но все это при наличии времени и возможности таких экспериментов, а на боевом продакшн сервере действительно дешевле переустановить — риск рецидива меньше и время недоступности, пожалуй, тоже.
Когда сервер находится в облаке в датасервере в США — там как-бы, проблематично его отключить :-)
К тому же, это был лоу-кост, без ip-kvm, пишешь тикет на установку ОС-и, тебе его устанавливают, прописывают ИП-ы и емейлят логин/пароль на RDP. Кстати, меня очень удивило, что их саппорт сказал: Извините, Ваш сервер заражен и мы его переустановили.
На вопрос о бакапе (я-то его сделал перед тикетом о просьбе проанализировать что не так на сервере) они ответили — нам сказали посмотреть на сервер, если там вирусы — формат винта и установка, про бакапы ничего не говорили.
Лоу-кост такой лоу-кост…

Был похожий случай в моей практике, 50$ (слава богу лежала минимальная сумма) со счета SIPNET улетело на звонки в Египет и Литву. После этого Asterisk переместился за внешний файрволл и наружу торчит исключительно SIP на IP адреса провайдеров. После принятых мер проблем более не испытывали.
Кстати у многих SIP операторов в FAQ висят статьи каким образом можно избежать подобных эксцессов, за что им отдельное спасибо.
А как у Вас бегает RTP через NAT? Через Symmetric NAT или Вы проксируете это через что-то, типа Kamailio+RTPProxy?
Используется iptables с модулем conntrack_sip
Абсолютно обычная ситуация. Взлом систем IP-телефонии у хакеров уже давно стал большой или даже основной статьей доходов.
Сканируют и ищут все что угодно отвечающее на SIP или похожее на VoIP софт/железо и дальше стадартные подборы/переборы.
Главная задача — дозвон на pay to call направления (а их кстати в мире очень много и есть даже в странах СНГ).

Так что любая работа с голосом должна быть крайне осторожна с точки зрения безопасности.
(ограничения по IP или направлений звонков спасают достаточно редко)
Необычен сам способ. Впрочем, в данном случае это была внутренняя утечка, а не взлом извне.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации