Как парализовать работу SMG1016 - практическое руководство
Добавлено: 21 фев 2012 22:19
Есть SMG-1016 прошивка последняя доступная с сайта (сейчас SMG-1016 вообще убрали).
Стоит на глобальном ip. Лицензий для регистратора нет. Как абонентский вынос для отдачи клиентам потоков E1.
С утра сегодня перестало работать. В логе основная ошибка - нет доступного канала. Перезагрузка не помогала. В консоле вывод команды top
Сняли всю нагрузку. Перезагрузили. Не помогло. Ступор и паника...
Объяснение простое - товарисчи хакеры из китая и германии (география по ip) производили подбор логина пароля для sip регистрации. Регистраций было сравнительно НЕ много - около 15 - 20 в секунду.
Вот таким образом можно парализовать работу сего довольно неплохого шлюза... Сейчас ситуацию решили, но осадок остался...
теперь вопросы к разработчикам.
1. все таки когда будет еще с год назад обещанный iptables? неужели сложно модуль для ядра собрать!?
2. почему на такую сравнительно безобидную ситуацию ПО реагирует, по сути, зависанием? Причем по tcpdump`у видно что звонок пришел, инициатор не дождался ответа а спустя 500!!! секунд шлюз начинает отвечать? Вот в качестве примера диаграмма звонка:
[первые цифры перед INVITE CANCEL это время в секундах от начала дампа]
или никак нельзя предположить что при таких задержках в обработке пакета отвечать уже нет смысла?
3 будут ли разработчики заниматься ЭТИМ? собирать стенд, эмулировать хак атаку? А проинформируют потом нас, простых пользователей, о том что проблема есть, решается, решена? или ограничатся сборкой модуля iptables и будь что будет?
Версия ПО: V.2.0.10. L. Build: Sep 5 2011 17:20:16
Версия SIP-адаптера: 2.4.57
Стоит на глобальном ip. Лицензий для регистратора нет. Как абонентский вынос для отдачи клиентам потоков E1.
С утра сегодня перестало работать. В логе основная ошибка - нет доступного канала. Перезагрузка не помогала. В консоле вывод команды top
Mem: 364580K used, 148912K free, 0K shrd, 2052K buff, 51452K cached
CPU: 97.4% usr 0.0% sys 0.0% nic 0.0% idle 0.0% io 0.0% irq 2.5% sirq
Load average: 1.19 0.99 0.49 2/72 1081
PID PPID USER STAT VSZ %MEM CPU %CPU COMMAND
980 1 root R 101m 20.2 0 94.8 /usr/lib/erlang/erts-5.7.3/bin/bea
997 985 root S 257m 51.2 0 5.1 /root/smg/mgapp
1000 979 root S 58448 11.3 0 0.0 /root/smg/cfgmngr
981 1 root S 53760 10.4 0 0.0 /root/smg/msgcore
983 1 root S 38088 7.4 0 0.0 /root/smg/webspp
985 1 root S 21912 4.2 0 0.0 /root/smg/mgapp
Сняли всю нагрузку. Перезагрузили. Не помогло. Ступор и паника...
Объяснение простое - товарисчи хакеры из китая и германии (география по ip) производили подбор логина пароля для sip регистрации. Регистраций было сравнительно НЕ много - около 15 - 20 в секунду.
Вот таким образом можно парализовать работу сего довольно неплохого шлюза... Сейчас ситуацию решили, но осадок остался...
теперь вопросы к разработчикам.
1. все таки когда будет еще с год назад обещанный iptables? неужели сложно модуль для ядра собрать!?
2. почему на такую сравнительно безобидную ситуацию ПО реагирует, по сути, зависанием? Причем по tcpdump`у видно что звонок пришел, инициатор не дождался ответа а спустя 500!!! секунд шлюз начинает отвечать? Вот в качестве примера диаграмма звонка:
109,673 INVITE SDP (g729 g711U g711A
(5060) ------------------> (5060)
110,171 INVITE SDP (g729 g711U g711A
(5060) ------------------> (5060)
110,171 INVITE SDP (g729 g711U g711A
(5060) ------------------> (5060)
112,201 INVITE SDP (g729 g711U g711A
(5060) ------------------> (5060)
114,231 INVITE SDP (g729 g711U g711A
(5060) ------------------> (5060)
120,322 INVITE SDP (g729 g711U g711A
(5060) ------------------> (5060)
123,044 CANCEL SIP Request
(5060) ------------------> (5060)
123,545 CANCEL SIP Request
(5060) ------------------> (5060)
124,558 CANCEL SIP Request
(5060) ------------------> (5060)
125,570 CANCEL SIP Request
(5060) ------------------> (5060)
128,610 CANCEL SIP Request
(5060) ------------------> (5060)
129,624 CANCEL SIP Request
(5060) ------------------> (5060)
132,663 CANCEL SIP Request
(5060) ------------------> (5060)
659,301 100 Trying SIP Status
(5060) <------------------ (5060)
672,692 100 Trying SIP Status
(5060) <------------------ (5060)
694,229 100 Trying SIP Status
(5060) <------------------ (5060)
[первые цифры перед INVITE CANCEL это время в секундах от начала дампа]
или никак нельзя предположить что при таких задержках в обработке пакета отвечать уже нет смысла?
3 будут ли разработчики заниматься ЭТИМ? собирать стенд, эмулировать хак атаку? А проинформируют потом нас, простых пользователей, о том что проблема есть, решается, решена? или ограничатся сборкой модуля iptables и будь что будет?