Дело о неработающей АТС на базе Asterisk PBX

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

Тот факт, что проблема возникла одновременно у нескольких сотрудников, указывал на то, что источником проблемы служила VoIP АТС, которая была реализована в виде FreeBSD + Asterisk.

Залогинившись в консоль Астериска сразу стало ясно, что тут что-то не так: постоянно вываливались сообщения вроде таких:

# tail -n 100000 /var/log/asterisk/messages | grep "Peer '182'"
[Nov  2 10:34:03] NOTICE[824] chansip.c: Peer '182' is now Lagged. (2701ms / 2000ms)
[Nov  2 10:34:13] NOTICE[824] chansip.c: Peer '182' is now Reachable. (695ms / 2000ms)
[Nov  2 10:35:16] NOTICE[824] chansip.c: Peer '182' is now Lagged. (2699ms / 2000ms)
[Nov  2 10:35:41] NOTICE[824] chansip.c: Peer '182' is now Reachable. (623ms / 2000ms)
[Nov  2 10:37:46] NOTICE[824] chansip.c: Peer '182' is now UNREACHABLE!  Last qualify: 1692
[Nov  2 10:37:57] NOTICE[824] chansip.c: Peer '182' is now Reachable. (693ms / 2000ms)

Величина qualify — это временная задержка ответа клиентом на SIP сообщение от сервера, и по умолчанию, если она больше двух секунд, то клиент считается недоступным для вызовов.

Первая мысль была о проблемном l2-свитче, но попинговав VoIP-шлюзы ICMP пакетами стало ясно, что IP, а, следовательно, и все протоколы уровнями ниже IP, в том числе Ethernet, работают хорошо. Но при работе в консоле, ощущалась некоторая «вязкость», похожа на медленный канал или перегруженную операционку. Команда top показала следующую картину:

la=1, т.е. скорее всего какой-то один процесс все время ждет какой-то ресурс.
CPU user~90%, т.е. какой-то процесс съедал все процессорное время.
Плюс ко всему был виден скачущий interrupt.

Стало очевидным, что виноват все-таки демон Asterisk-а. Повысив уровень сообщений, стало видно, что на сервер идет атака брутфорсом, но с такой интенсивностью, что больше похожа на DOS-атаку:

[Nov  2 10:03:33] NOTICE[824] chansip.c:
Registration from '"139"<sip:139@89...*>' failed for '173.203.92.194' - Wrong password
[Nov  2 10:03:33] NOTICE[824] chansip.c:
Registration from '"139" <sip:139@89...>' failed for '173.203.92.194' - Wrong password
[Nov  2 10:03:33] NOTICE[824] chan_sip.c:
Registration from '"137" <sip:137@89...>' failed for '173.203.92.194' - Wrong password
[Nov  2 10:03:33] NOTICE[824] chansip.c:
Registration from '"137" <sip:137@89...*>' failed for '173.203.92.194' - Wrong password
[Nov  2 10:03:33] NOTICE[824] chansip.c:
Registration from '"139" <sip:139@89...>' failed for '173.203.92.194' - Wrong password
[Nov  2 10:03:33] NOTICE[824] chan_sip.c:
Registration from '"139" <sip:139@89...>' failed for '173.203.92.194' - Wrong password
[Nov  2 10:03:33] NOTICE[824] chansip.c:
Registration from '"139" <sip:139@89...*>' failed for '173.203.92.194' - Wrong password
[Nov  2 10:03:33] NOTICE[824] chansip.c:
Registration from '"139" <sip:139@89...>' failed for '173.203.92.194' - Wrong password
[Nov  2 10:03:33] NOTICE[824] chan_sip.c:
Registration from '"139" <sip:139@89...>' failed for '173.203.92.194' - Wrong password

Файрвола на сервере не было, поэтому, чтобы заблокировать атаку была использована команда:

#route add 173.203.92.194/32 192.168.0.200

Нуль-роут — сетевой маршрут в никуда. Wiki: Null_route

Любой пакет, отправленный на адрес 173.203.92.194 попадает в нуль-роутинг.

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

Звонок провайдеру, который заблокировал это направление трафика, решил проблему полностью.

Заключение

Ситуация, увы, типичная — некий американский сервер взломали, посадили туда бота и терроризируют чужие серверы. Атаки такого рода, как правило, проводят по ночам, что бы нагрузка была незаметна администраторами, хотя их хорошо фиксируют наши системы мониторинга.

Какого-то универсального средства против такой DOS-атаки не существует — таких ботов пишет неопытная молодежь, и чуть почуяв, что можно заработать какие-то копейки — без головы бросаются ломать сервер. Вот пример того, зачем подбирают пароль на сервер:

Итак, инцидент был решен, но, как водится, дело надо было довести до конца:

Внедрение Fail2Ban — при высокой частоте неудачных авторизаций удаленный клиент отправляется в нуль-роут. Это сделает этот хост неинтересным для атак брутфорса.
Более «тонкая» настройка мониторинга сервиса.
Сообщение об инциденте (abuse) в Internet Crime Complaint Center, администратору сети (noc) и администратору сервера (webmaster), которого нашел по ns серверам сайтов на этом IP.

Приглашаем подписаться на новые выпуски в социальных сетях: