атака на call-центр
Поводом для написания статьи послужило спам-письмо, поступившее на адрес it@company.com и нижеследующий разговор.
письмо
Бесплатная телефонная справочная.
Бесплатная справочно-адресная информация по организациям и фирмам Москвы. Количество вопросов, заданных за один раз, и время общения не ограничено. Работает круглосуточно.
Поиск информации производится:
- по названию организации;
- по территориальному признаку (адресу вплоть до номера дома, станции метро, району, округу и пр.);
- по видам деятельности, ключевым словам;
- другим критериям.
...
разговор
- Спамеры достали. Всегда на шаг впереди, обучаешь фильтр, включаешь в black-листы, и все равно спам проходит. Ну зачем мне информация по Москве если я живу в другой стране?! - сказал первый админ.
- Ну и что ты можешь сделать? – сказал второй админ.
- Могу DoS устроить.
- Бесполезно: там, скорее всего, бот живет.
- Ты не понял. DoS не хосту, с которого спам отсылается, а корню зла – компании, заплатившей спамерам за рассылку письма.
- Но в письме есть только номер телефона рекламирующей себя фирмы. Объясни.
- Сформулируем упрощенное тех. задание. Необходимо на час вызвать отказ в обслуживании небольшого call-центра, у которого есть один поток E1, 30 операторов, и который расположен в другой стране. Атаку должен осуществить один человек, имеющий доступ в Интернет. Атакующий знает только номер многоканального телефона атакуемого. Можно использовать незаконные методы, но желательно сделать так, чтобы никто не смог доказать, что это сделал именно атакующий. Этических вопросов не поднимаем. Атака должна начаться через 2 часа. Стоимость проведения атаки для атакующего не должна быть выше 10 американских центов. Пойдет?
- Да. Рассказывай.
сеть провайдера VoIP
Согласно тех. заданию, надо сделать так, чтобы все линии потока E1 call-центра были постоянно заняты в течение часа. Для этих целей вполне подходит IP-телефония. Однако использовать легально сеть провайдера VoIP не представляется возможным, так как стоимость атаки не должна превышать 10 центов. Самый естественный выход – взлом, или, точнее, несанкционированное использование оборудования провайдера VoIP. Некоторое время назад я проводил небольшое исследование на предмет того, как работает сеть моего провайдера VoIP, какое оборудование и ПО используется. Схематично VoIP-сеть изображена на рисунке 1.
Рис. 1.
Мы видим, что в центре рисунка стоит сервер. Это SIP Proxy сервер. Программное обеспечение для телефонии, используемое на сервере – SER, аббревиатура от SIP Express Router. SER – бесплатный, open source сервер, написанный на C. Express в его названии значит отнюдь не то, что он написан очень быстро, это означает, что у него очень высокая производительность. Бессмысленно в IP телефонии измерять производительность, как и в обычной телефонии, в количестве одновременных звонков. Производительность измеряется в количестве обработанных звонков в секунду (Calls Per Second). У данного сервера производительность может достигать тысяч звонков в секунду. Кроме того, сервер очень гибкий в плане возможности конфигурирования.
Устройства, работающие с сервером провайдера, я выделил в две логические группы. Слева на рисунке изображены клиенты, на которых провайдер зарабатывает деньги. Эти клиенты подключаются, используя несколько типов IP телефонов и ATA (Analog Terminal Adapter), способных работать с сигнализацией SIP. Справа выделены устройства сопряжения VoIP и PSTN. Часть из них принадлежат провайдеру, часть арендуются на неизвестных мне условиях у других провайдеров. Расположены они, как вы видите, по всему миру.
Качество связи у провайдера очень высокое. Провайдер рекомендует своим клиентам использовать кодек G.711, любое терминирующее в PSTN оборудование провайдера не запрещает его использование. Лично я использую кодек G.729 для экономии своего трафика, практически любое терминирующее оборудование провайдера и его партнеров этого не запрещает.
Одна из причин, заставившая меня проанализировать, как работает сеть моего VoIP-провайдера, заключается в том, что я сам несколько лет назад работал в команде над примерно таким проектом. Наш проект умер по независимым от тех персонала причинам, однако радует тот факт, что два решения совпадают в плане выбора оборудования и ПО примерно на 80%. Это означает, что наш проект был бы работоспособен. Признаться, хотя мы работали над безопасностью, наше решение также было бы подвержено подобной атаке.
атака
Для понимания метода атаки необходимо рассмотреть процесс установления связи по сигнализации SIP. Для этого я использую очень полезную утилиту SIP Scenario. В данном примере производится звонок с программного клиента на Cisco с FXO картами, подключенными к мини-АТС. В качестве SIP Proxy сервера используется SER. В примере опущен процесс аутентификация на SIP-сервере, который присутствует в реальных условиях.
Обратите внимание, что софт-телефон отсылает только один пакет и далее пассивно получает уведомления о процессе установления связи. Один пакет софт-телефона заставил Cisco набрать номер в PSTN, открыть RTP канал и сообщить о том, что абонент поднял трубку. RTP трафик от Cisco начинает поступать сразу после удачного набора номера в PSTN и до момента, когда абонент поднимет трубку передаются гудки. Далее следует фаза разговора. Полезные действия, выполненные SIP Proxy сервером с точки зрения софт-телефона – только в нахождении местоположения Cisco в сети. В принципе, если бы софт-телефон знал, где расположена Cisco, он мог бы напрямую послать пакет на Cisco и соединиться с ним. Связь между SIP UA напрямую, минуя SIP Proxy или B2B UA возможна, более того, в некоторые модели IP телефонов, в частности Grandstream, встроена функция дозвона по IP-адресу вызываемого устройства.
Вся полезная информация для звонка с софт-телефона на Cisco, минуя SIP Proxy, в следующем пакете:
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 192.168.100.28:5060;rport=5060;branch=z9hG4bKFB89C4370AAC4EF2A42DBAE51544860E
From: 106 <sip:106@192.168.100.250>;tag=542367451
To: <sip:5218@192.168.100.250>;tag=EE05E448-E0A
Date: Fri, 01 Dec 2006 14:58:35 GMT
Call-ID: 78EC3705-3897-4375-9BBF-7610422A930D@192.168.100.28
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 13484 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Contact: <sip:5218@192.168.1.8:5060>
Record-Route: <sip:192.168.100.250;ftag=542367451;lr=on>
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 176
v=0
o=CiscoSystemsSIP-GW-UserAgent 7022 3917 IN IP4 192.168.1.8
s=SIP Call
c=IN IP4 192.168.1.8
t=0 0
m=audio 19398 RTP/AVP 0
c=IN IP4 192.168.1.8
a=rtpmap:0 PCMU/8000
Поле Contact: <sip:5218@192.168.1.8:5060> - IP-адрес, порт устройства и номер телефона, каким он должен приходить на устройство. В общем случае набираемый на телефоне номер (поле To: <sip:5218@192.168.100.250>) может не совпадать с тем, который попадает на Cisco, вызывающий абонент набирает его с префиксами, например 8495XXXXXXX. Задача SIP Proxy - преобразовать номер к виду, приемлемому для конкретной конфигурации Cisco, например, убрать 8 и добавить 7, чтобы номер был 7495XXXXXXX.
Если учесть тот факт, что в большинстве случаев SIP-устройства сконфигурированы на транспортировку пакетов сигнализации по протоколу UDP, то метод атаки становится очевидным.
Перейдем от теории к практике, а именно к конкретной задаче завалить звонками call-центр в Москве.
Этап первый – звонок в Москву друзьям через сеть VoIP-провайдера. При этом важно словить все пакеты сигнализации SIP на промежуточном между телефоном и SIP-сервером узле.
Этап второй - с помощью SIP Scenario вычленяем SIP-сигнализацию первого пакета INVITE и записываем в файл.
Этап третий - анализируем SIP-пакеты, полученные при первом звонке, определяем IP-адрес и SIP-порт Cisco, а также правила модификации префикса телефона.
Этап четвертый - в полученном на втором этапе пакете модифицируем поля сигнализации SIP таким образом, чтобы пакет был корректно принят Cisco, меняем префикс для номера вызывающего абонента, IP-адрес вызывающего телефона, номер вызываемого телефона. Для проверки действенности метода в сигнализацию SDP вписываем IP-адрес, идущие пакеты на который мы сможем ловить.
Этап пятый – отсылаем пакет со своего хоста. И... не получаем никакого результата, так как UDP-порт сигнализации SIP закрыт Firewall-ом провайдера VoIP.
Этап шестой – определяем (nslookup’ом) IP-адрес SIP Proxy сервера и с помощью, например, пакетного генератора nemesis, отсылаем такой же пакет, как и на пятом этапе, с той лишь разницей, что Source IP адрес пакета - IP адрес SIP Proxy сервера. Если такой пакет не фильтруется вашим и ни одним из транзитных Интернет-провайдеров между вами и Cisco, то на IP-адрес и порт, прописанные в SDP-сигнализации пакета, пойдет RTP-трафик от атакуемой Cisco. В моем случае, хотя между мной и Москвой пакет проходит, по меньшей мере, через 5 автономных систем, этот этап атаки был успешным. RTP-трафик поступал примерно 15-20 секунд. Это то время, которое требуется на то, чтобы, человек услышал звонок, была поднята трубка, человек понял, что его не слышат, и положил трубку.
Этап седьмой – автоматизация. Заключается в написании простейшего скрипта для генерации множества пакетов. Скрипт можно быстро написать на чем угодно - Perl, Tcl, Python и т. п. Скрипт должен модифицировать эталонный пакет, полученный на пятом этапе и отсылать его, заменяя Source IP на IP адрес SIP Proxy сервера. Согласно тех. заданию, надо постоянно занимать 30 телефонных линий. Примем длительность занятости линии для каждого звонка равной 10 секундам. Тогда очевидно, что скрипту надо постоянно генерировать 3 звонка в секунду – не надо высокой производительности. Тогда, через 10 секунд все 30 линий будут заняты и освобождающиеся на одиннадцатой и последующих секундах линии будут опять заниматься новыми звонками.
Реально атака по этическим соображениям осуществлена не была. Что касается первых шести этапов, то они были продемонстрированы второму админу на оборудовании провайдера за 15 минут. Также, после объяснения алгоритма работы скрипта для седьмого этапа, не вызывало сомнения, что его можно написать в течение часа или полутора. В рамки времени, отведенного на организацию атаки, я вписывался.
Теперь рассмотрим вопрос анонимности атакующего.
Относительно анонимности, я уже упоминал, что от меня до gateway пакеты проходят через, по меньшей мере, 5 автономных систем. Чтобы выяснить откуда пришел пакет с подмененным Source IP-адресом необходимо по цепочке выяснять в обратном порядке путь следовательно пакета. Для этого надо запрашивать вашего верхнего провайдера, затем одного из провайдеров работающего с ним, и так далее. Как показывает практика, такие запросы дропаются провайдерами уже на втором или третьем хопе.
Осталось рассмотреть вопрос длительности атаки. На основании собственного опыта работы осмелюсь утверждать, что с вероятностью не менее 80% администраторы VoIP-провайдера за час не примут меры по прекращению действия атаки. Так уж получилось, что gateway, через который осуществлялся выход в Московский PSTN – Cisco, поэтому буду рассматривать этот вопрос на примере Cisco.
Технически, так как все вызовы из сети IP поступают на один и тот же номер PSTN, подобную атаку прекратить просто. Для этого администраторам надо добавить только несколько строк в конфигурацию своего Cisco. Вот как предлагает делать это на сайте Cisco:
voice translation-rule 1
rule 1 reject /7495345*/
!
voice translation profile call_block_profile
translate calling 1
!
dial-peer voice 111 pots
call-block translation-profile incoming call_block_profile
call-block disconnect-cause incoming invalid_number
Наверняка на другом оборудовании также имеется подобная возможность закрыть какой-то один или группу номеров.
Проблема не в том, как закрыть такую атаку, а в том, чтобы ее выявить. Основная проблема выявления атаки в том, что gateway выполняет свои функции в нормальном режиме. Инициируются звонки из VoIP, происходит вызов в PSTN и нормальное завершение звонка. Не важно, что для всех звонков инициатором завершения является PSTN.
Существует 3 параметра, позволяющие автоматически определить наличие подобной атаки. Первый – количество одновременных звонков на gateway. Второй – ACD (Average Call Duration) среднее время длительности звонка. Третий - ASR (Average Success Rate) отношение количества успешных вызовов к общему количеству вызовов.
Нормальный провайдер будет анализировать эти параметры, однако в том, что у провайдера есть автоматические системы обнаружения атак путем анализа параметров в режиме реального времени, я сомневаюсь.
Приведу пример из собственной практики. Примерно в 1999-2002 годах, когда я работал у Интернет-провайдера, у нас появилась эффективная система определения и противодействия flood DoS-атакам. В общих чертах система работала следующим образом. Интерфейсы маршрутизаторов, через которые к нам извне поступал трафик, специальной программой опрашивались по SNMP с периодичностью 20 секунд. Вычислялась скорость поступления внешнего трафика и производилось сравнение значения полученного на предыдущей итерации с текущим. Если разница превышала некоторый, конфигурируемый минимум, то на консоль дежурного системного администратора выводилось предупреждение. При правильных настройках, flood-атаки выявлялись в 100% случаев, ложных срабатываний было сравнительно мало, около 10 – 15 в сутки. Если администратор предполагал, что началась атака, он запускал специальный скрипт, который, на основании данных, собираемых по протоколу Cisco netflow, выдавал отчет TOP 20 самых активных, по количеству принятых байт и пакетов, потребителях трафика в нашей автономной системе. Так как, обычно, атакующие флудили только на один IP-адрес, то направление атаки вычислялось путем сопоставления значений в статистике TOP 20. С верхними провайдерами у нас была договоренность относительно пресечения подобных атак. Для этого был поднят протокол Internal BGP, поэтому нам было достаточно прописать на своем маршрутизаторе маршрут в null, для атакуемого IP-адреса, и атака до нас не доходила, умирала на уровне верхнего провайдера. Атака блокировалась в среднем через 3 минуты после начала.
Для чего я это рассказываю? Только для того, чтобы сказать, что до появления первой такой атаки у нас такой системы не было, мы просто не предусматривали такой возможности, поэтому несколько раз поплатились за это длительными простоями или ухудшением сервиса. Флудеры просто вынудили нас наладить такой мониторинг. Если бы провайдер VoIP подозревал о возможности подобной описываемой атаки, он бы не дожидался ее появления, а просто исключил бы возможность атаки.
Я не буду больше освещать все возможные тонкости проведения подобной атаки. Моей целью было только доказать, что ее возможно осуществить. Перейду к другому, интересному, на мой взгляд, вопросу – отдаче.
отдача
При выстреле из ружья пуля летит в цель, а в плечо стреляющего ударяет отдача. Если проводить такую аналогию с описываемой атакой, то пуля - звонки, отдача - голосовые RTP-пакеты. Направление отдачи можно легко задавать с помощью параметров SDP-протокола в инициирующем звонок SIP- пакете. С точки зрения атакующего отдача в большинстве случаев полезна. В рассматриваемом примере атакуемый call-центр не указал своего местоположения в Интернете, однако отдачу можно направить на своих недругов. У меня, например, нет недругов, поэтому я бы, на месте атакующих, распорядился отдачей иначе. Я бы распылил отдачу на несколько десятков IP-адресов в Интернете, один и которых – мой. Это дало бы мне возможность проконтролировать эффективность атаки на основании приходящих ко мне RTP-пакетов, и гарантировало бы бездоказательность, того, что атаку проводил именно я. Единственным недостатком отдачи, с точки зрения атакующего, является появление еще одного параметра в виде дополнительного исходящего трафика, косвенно свидетельствующего о не совсем нормальном поведении сети.
Я работаю на текущий день не у провайдера, поэтому об отдаче буду судить со своей “низкой” колокольни. На текущий момент я связан с провайдером с помощью пары SHDSL-модемов, максимум, что можно выжать из моей связи на уровне Ethernet – 2 Мбит/c. На демарке с провайдером у меня стоит Cisco 2621.
Как было показано ранее, звонок инициируется одним пакетом, размер которого примерно 1 Кб. Рассчитаем сначала эффект усиления количества пакетов. Один пакет генерирует 10 секунд передачи пакетов со скоростью 50 пакетов в секунду для кодека G.711. Коэффициент усиления 500 – высокий, но он растянут во времени на 10 секунд. Моя старенькая Cisco 2621 по спецификации способна гарантированно выдерживать 25000 пакетов в секунду. Чтобы вызвать отказ в обслуживании нужно загрузить ее RTP-трафиком, генерируемым 500 одновременными звонками, для этого надо задействовать 20 VoIP gateway’ев, если предположить, что на каждом из них только один поток E1. При этом исходящий трафик атакующего будет примерно пол мегабита в секунду. При расчете я сделал допущение, что каждый шестой пакет не будет инициировать звонок.
Посчитаем генерируемый трафик. Один разговор при использовании G.711 генерирует, если считать и Ethernet-заголовки, 95,2 Кбит/c. Значит 25 звонков гарантировано забьют весь мой канал, достаточно эффекта отдачи от атаки на один gateway, при этом атакующий тратит на атаку примерно 30 Кбит/c. Меня может завалить отдача от атаки на один gateway, это совсем не радует. Теперь перейдем к вопросу о том, кто имеет возможность атаковать.
круг потенциальных атакующих
Надеюсь, из всего вышесказанного очевидно следует, что возможность атаковать есть у того, кто может исследовать сеть VoIP-провайдера, то есть у его клиента. Я знаю о наличии уязвимости у своего провайдера, однако, примерно за час я нашел еще нескольких провайдеров, которые, возможно, также подвержены таким атакам. Алгоритм поиска простой. С помощью поисковой системы находим сайт VoIP-провайдера, работающего по протоколу SIP. Далее ищем, на этом сайте FAQ по настройке оборудования, определяем адрес SIP-сервера и пытаемся аутентифицироваться и зарегистрироваться на нем с помощью soft-телефона. По сигнализации определяем софт SIP-сервера и смотрим, что он из себя представляет. Далее можно заплатить и зарегистрироваться у провайдера VoIP, чтобы исследовать подверженность атаке терминирующих gateway’ев провайдера. Надеюсь я доказал, что серьезный атакующий может при не большом вложении средств исследовать несколько провайдеров и, в конце концов, выйти на подверженного подобной атаке провайдера. Я таких исследований не проводил, поэтому статистику по уровню безопасности провайдеров, к сожалению, представить не могу. Также важно, чтобы пакеты атакующего, отосланные с произвольного IP-адреса, не блокировал ни его, ни один из транзитных Интернет-провайдеров по пути следования до атакуемого PSTN gateway.
варианты использования уязвимости
Я рассмотрел атаку на call-центр как пример использования уязвимости. Очевидно, что возможности использования описываемых методов подобной атакой не ограничиваются. Я не претендую на полный список возможных атак, представлю лишь те, на которые хватило моего воображения. Атака на call-центр или другую организацию. Собственно ее я до сих пор описывал.
Атака на gateway провайдера. Без сомнений, очень легко устроить DoS для gateway провайдера. При этом, даже если у провайдера 4 потока E1 на одном физическом устройстве, атакующему достаточно генерировать 15 пакетов SIP в секунду, осуществляя дозвон на различные номера. Провайдер будет вынужден либо отключить потоки E1, либо закрыть доступ для SIP Proxy сервера, что также является отказом в обслуживании.
Глобальная атака на обычные телефонные сети. Представьте группировку негодяев (хотя кто-то может назвать их Хакерами, с чем я лично не согласен), которые находят множество уязвимых gateway, тщательно все планируют, и затем инициируют атаку на телефонные сети одновременно во многих странах мира. Вы спросите, кому это нужно? А кому нужно атаковать Root DNS-серверы Интернета?
SPIT – Spam Over Internet Telephony. Формально SPIT – дозвон на VoIP-устройства. На сколько я знаю, SPIT не подразумевает дозвон в обычные телефонные сети. Однако данный тип уязвимости дает возможность дешево и анонимно организовать дозвон на номера обычной телефонии. На сегодняшний момент SPIT не очень востребован из-за, того, что IP-телефония не достаточно сильно развита.
Влияние на результаты интерактивного телефонного голосования. Приведу лишь один яркий пример. Хотите подарить (читай, украсть из кармана банка спонсора) дополнительно несколько тысяч рублей телезрителю, задавшему оригинальный вопрос знатокам в прямом эфире игры “Что? Где? Когда?” Не вижу особых сложностей.
Кража VoIP-трафика у провайдера. Этот вопрос представляется мне интересным, поэтому остановлюсь на нем подробнее.
кража VoIP-трафика у провайдера
Сначала, когда я задумался о данной возможности, технически схема мне представлялась следующим образом. Где-то в Интернете стоит сервер, выполняющий функции B2B UA, через который осуществляются звонки. Функции B2B UA заключаются в том, чтобы принять запрос INVITE от клиента, сформировать пакет и отослать его на gateway, имитируя IP-адрес SIP Proxy провайдера, в SDP указав свой адрес для RTP-трафика. Далее, ловить RTP- трафик и определять по пакетам, что в PSTN начался разговор, дабы сообщить об этом вызывающему абоненту по сигнализации SIP и, к тому же - проксировать через себя RTP-трафик. Хотя, теоретически схема должна работать, мне, как не профессиональному программисту написать такой B2B UA – не просто, и откровенно говоря, не интересно. Поэтому я продумывал другие схемы, используя подход специалиста по сетям. После того, как я продумал метод, не более чем за час я имел готовое решение для тестов.
Метод основывается на нюансах работы сигнализации SIP на уровне приложения с транспортным сетевым уровнем. Дело в том, что UDP-пакет с сигнализацией SIP может прийти с любого IP-адреса и порта, однако ответ на этот пакет теоретически может прийти на IP-адрес и порт, прописанные в полях сигнализации SIP. RFC 3261 описывает такие ситуации.
Если это так, то это может помочь успешно обойти firewall, блокирующий только входящие пакеты сигнализации SIP. Во многих случаях для сигнализации SIP организовать firewall, блокирующий исходящие пакеты сигнализации SIP, довольно просто. Очень многие SIP-серверы и UA используют симметричные ответы. Под симметричными ответами подразумевается, что сервер или UA отвечает на SIP-пакеты с того же порта, на котором он слушает запросы. Присмотревшись к использовавшемуся мной в атаке сценарию, я заметил, что в случае с Cisco gateway это не так. У IP-телефона и SER явно указан порт 5060, у Cisco не указан порт, так как их несколько. Слушает она на порту 5060, а отвечает с произвольного порта, в данном случае - 52506.
Симметричный подход необходим для многих схем корректной работы SIP-сигнализации через NAT, однако Cisco в случае с NAT рекомендует использовать SIP ALG NAT, видимо поэтому и считает не важным, с какого порта посылать ответы. ALG означает Application Layer Gateway. Многие не знают об этой технологии, однако технология SIP ALG NAT очень полезна. Суть ее в том, что пакет с сигнализацией SIP анализируется на уровне приложения, помимо изменения IP-адреса самого пакета и создания трансляции в NAT для сигнализации и RTP, изменяются также и IP-адреса в пакете сигнализации SIP и SDP. Это позволяет организовать схему, в которой логику прохождения через NAT не нужно реализовывать дополнительными средствами, то есть использовать STUN-сервер, статические NAT-трансляции или другие технологии. Вообще, ALG не разработан специально для SIP, работает он и для H.323, и вообще не только VoIP-протоколов: HTTP, TFTP, telnet, archie, finger, NTP, NFS, rlogin, rsh, rcp. Впрочем, я отвлекся, кому интересно может почитать об ALG NAT здесь http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801af2b9.shtml.
Я не говорю, что в случае с Cisco организовать блокирующий обратные пакеты SIP firewall сложно, я имею в виду, что простого закрытия исходящих пакетов с порта 5060 не достаточно в данном случае. Админы могут просто не учесть этот факт и допустить ошибку при настройке firewall’а для исходящих SIP-пакетов.
Итак, перейдем к нашей схеме (рис. 2). Она похожа на схему моего VoIP-провайдера. В центре SER SIP Proxy, слева – клиенты, которые будут платить деньги, справа - терминирующие gateways, с которых мы будем воровать VoIP-минуты. Между SER и gateway небольшая “примочка”, функция которой – менять IP-адрес в пакете, следующем на gateway от моего SIP Proxy на IP-адрес SIP Proxy моего VoIP-провайдера.
Рис. 2.
Функции “примочки” схожи с функциями стандартного NAT, поэтому логично, что и работать она будет по тем же принципам. Моим рабочим инструментом в исследовании сетей является FreeBSD, поэтому я использовал методы организации NAT, применяемые в этой операционной системе – divert-сокеты и ipfw. Также я буду использовать замечательный perl-модуль, написанный Stephanie Wehner - Net::Divert.
use Net::Divert;
use NetPacket::IP;
$divobj = Net::Divert->new('localhost',9999);
$divobj->getPackets(\&alterPacket);
sub alterPacket {
my($packet,$fwtag) = @_;
# Decode Packet
$ip_obj = NetPacket::IP->decode($packet);
# Change Source IP address
$ip_obj->{src_ip}= "192.168.50.15";
# Encode Packet
$packet = $ip_obj->encode;
# write it back out
$divobj->putPacket($packet,$fwtag);
}
Плюс такое правило для обработки исходящих с интерфейса fxp0 FreeBSD:
ipfw add 500 divert 9999 all from any to 192.168.3.10 out via fxp0
Все это вместе исполняет функции “примочки” для SIP Proxy, работающго на том же FreeBSD-сервере для схемы, представленной на рисунке 3.
Рис. 3.
Очевидно, что для того, чтобы воровать минуты еще с одного gateway достаточно прописать еще одно правило для ipwf, только указать при этом нужный IP-адрес. Если же необходимо воровать трафик сразу у нескольких провайдеров, надо модифицировать скрипт, привязать его к другому divert- порту и, соответственно, изменять правила для ipfw. Я не использовал стандартный демон natd по причине того, что предполагал, что необходимо будет менять еще некоторые поля сигнализации SIP в исходном пакете, то есть реализовывать функционал, схожий с ALG.
В целом, схема не работоспособна. Тесты с моим Cisco показали, что пакеты сигнализации SIP возвращаются не на адрес и порт, прописанные в сигнализации SIP, а на Source адрес и порт, которые gateway получает, анализируя исходный пакет на транспортном уровне, RFC этого не запрещает. Это справедливо для всех пакетов, кроме пакетов BYE, сигнализирующих об окончании разговора. Это не позволяет вести полноценный billing для клиентов, также не позволяет сообщить клиенту о начале разговора, и, следовательно, не приемлимо в коммерческих целях. Однако позволяет успешно использовать схему для организации SPIT-а.
Поясню. Допустим, некто получил полный контроль над сервером, расположенным у Интернет-провайдера, не блокирующего пакеты с подмененным Source IP-адресом. Он устанавливает на этот хост SIP Proxy, конфигурирует его и “примочку”. После этого с любой бот-машины можно организовать дозвон на произвольный номер в PSTN, дабы счастливый владелец телефонного номера в 3 часа ночи узнал о том, что в продаже появились очень эффективные таблетки от бессонницы. Конечно, есть небольшие технические трудности, в частности, программа на бот-машине должна уметь анализировать RTP- трафик, чтобы понять, когда получатель SPIT-а поднял трубку, однако, думаю, они решаются.
Выяснив, что простой замены Source IP пакета не достаточно, я провел еще несколько веселых часов, исследуя поведение Cisco и перечитывая RFC 3261. Я модифицировал скриптом поля SIP, в частности, поле Via, изменял протокол с UDP на TCP, добавлял параметры sent-by и received. Однако у меня ничего не получилось, такая схема эффективной кражи трафика VoIP-провайдера не заработала. В данном случае отрицательный результат – тоже результат. Самое время перейти к вопросу защиты провайдера.
защита провайдера
Откровенно говоря, общих рекомендации дать не возможно. Защита в любом случае зависит от очень многих факторов.
Можно использовать вместо SIP Proxy (или вместе с ним) Session Border Controller и эффективно скрывать топологию своей сети. Можно использовать дополнительный SIP Proxy сервер, прохождение сигнализации через который будет невидимым для клиентов. Это скроет от клиентов реальный адрес, с которого можно инициировать звонок на PSTN gateway.
Самым очевидным для данного случая решением я вижу использование в качестве транспорта для общения между SIP Proxy и PSTN gateway протокола TCP вместо UDP. Доступ же на UDP-порт сигнализации SIP gateway закрыть от всех IP-адресов. В RFC 3261 на странице 141 сказано буквально следующее “All SIP elements MUST implement UDP and TCP. SIP elements MAY implement other protocols”. RFC 3261 был написан в 2002 году, большинство современных “SIP-элементов” должно поддерживать данный RFC.
выводы
Невозможно судить об уровне защиты сетей VoIP только на примере одного провайдера. Можно лишь сказать, что есть провайдеры, которые могут пострадать от подобных атак. Хотя я не слышал об успешно проведенных подобных атаках, это вовсе не значит, что их никто не проводил до текущего момента, и, тем более, что они не появятся в будущем. Я думаю, провайдерам стоит строить свои сети с учетом возможности подобных атак.
P.S.
Перечитывая все написанное, я прекрасно осознаю, что не осветил всех тонкостей, и сделал ряд грубых, не до конца проверенных, предположений. Однако я хотел написать не пособие по проведению атаки, но просто указать на реальную проблему и на то, сколь серьезными могут быть последствия. Надеюсь, читателю было интересно.
Zelendoplit
письмо
Бесплатная телефонная справочная.
Бесплатная справочно-адресная информация по организациям и фирмам Москвы. Количество вопросов, заданных за один раз, и время общения не ограничено. Работает круглосуточно.
Поиск информации производится:
- по названию организации;
- по территориальному признаку (адресу вплоть до номера дома, станции метро, району, округу и пр.);
- по видам деятельности, ключевым словам;
- другим критериям.
...
разговор
- Спамеры достали. Всегда на шаг впереди, обучаешь фильтр, включаешь в black-листы, и все равно спам проходит. Ну зачем мне информация по Москве если я живу в другой стране?! - сказал первый админ.
- Ну и что ты можешь сделать? – сказал второй админ.
- Могу DoS устроить.
- Бесполезно: там, скорее всего, бот живет.
- Ты не понял. DoS не хосту, с которого спам отсылается, а корню зла – компании, заплатившей спамерам за рассылку письма.
- Но в письме есть только номер телефона рекламирующей себя фирмы. Объясни.
- Сформулируем упрощенное тех. задание. Необходимо на час вызвать отказ в обслуживании небольшого call-центра, у которого есть один поток E1, 30 операторов, и который расположен в другой стране. Атаку должен осуществить один человек, имеющий доступ в Интернет. Атакующий знает только номер многоканального телефона атакуемого. Можно использовать незаконные методы, но желательно сделать так, чтобы никто не смог доказать, что это сделал именно атакующий. Этических вопросов не поднимаем. Атака должна начаться через 2 часа. Стоимость проведения атаки для атакующего не должна быть выше 10 американских центов. Пойдет?
- Да. Рассказывай.
сеть провайдера VoIP
Согласно тех. заданию, надо сделать так, чтобы все линии потока E1 call-центра были постоянно заняты в течение часа. Для этих целей вполне подходит IP-телефония. Однако использовать легально сеть провайдера VoIP не представляется возможным, так как стоимость атаки не должна превышать 10 центов. Самый естественный выход – взлом, или, точнее, несанкционированное использование оборудования провайдера VoIP. Некоторое время назад я проводил небольшое исследование на предмет того, как работает сеть моего провайдера VoIP, какое оборудование и ПО используется. Схематично VoIP-сеть изображена на рисунке 1.
Рис. 1.
Мы видим, что в центре рисунка стоит сервер. Это SIP Proxy сервер. Программное обеспечение для телефонии, используемое на сервере – SER, аббревиатура от SIP Express Router. SER – бесплатный, open source сервер, написанный на C. Express в его названии значит отнюдь не то, что он написан очень быстро, это означает, что у него очень высокая производительность. Бессмысленно в IP телефонии измерять производительность, как и в обычной телефонии, в количестве одновременных звонков. Производительность измеряется в количестве обработанных звонков в секунду (Calls Per Second). У данного сервера производительность может достигать тысяч звонков в секунду. Кроме того, сервер очень гибкий в плане возможности конфигурирования.
Устройства, работающие с сервером провайдера, я выделил в две логические группы. Слева на рисунке изображены клиенты, на которых провайдер зарабатывает деньги. Эти клиенты подключаются, используя несколько типов IP телефонов и ATA (Analog Terminal Adapter), способных работать с сигнализацией SIP. Справа выделены устройства сопряжения VoIP и PSTN. Часть из них принадлежат провайдеру, часть арендуются на неизвестных мне условиях у других провайдеров. Расположены они, как вы видите, по всему миру.
Качество связи у провайдера очень высокое. Провайдер рекомендует своим клиентам использовать кодек G.711, любое терминирующее в PSTN оборудование провайдера не запрещает его использование. Лично я использую кодек G.729 для экономии своего трафика, практически любое терминирующее оборудование провайдера и его партнеров этого не запрещает.
Одна из причин, заставившая меня проанализировать, как работает сеть моего VoIP-провайдера, заключается в том, что я сам несколько лет назад работал в команде над примерно таким проектом. Наш проект умер по независимым от тех персонала причинам, однако радует тот факт, что два решения совпадают в плане выбора оборудования и ПО примерно на 80%. Это означает, что наш проект был бы работоспособен. Признаться, хотя мы работали над безопасностью, наше решение также было бы подвержено подобной атаке.
атака
Для понимания метода атаки необходимо рассмотреть процесс установления связи по сигнализации SIP. Для этого я использую очень полезную утилиту SIP Scenario. В данном примере производится звонок с программного клиента на Cisco с FXO картами, подключенными к мини-АТС. В качестве SIP Proxy сервера используется SER. В примере опущен процесс аутентификация на SIP-сервере, который присутствует в реальных условиях.
Обратите внимание, что софт-телефон отсылает только один пакет и далее пассивно получает уведомления о процессе установления связи. Один пакет софт-телефона заставил Cisco набрать номер в PSTN, открыть RTP канал и сообщить о том, что абонент поднял трубку. RTP трафик от Cisco начинает поступать сразу после удачного набора номера в PSTN и до момента, когда абонент поднимет трубку передаются гудки. Далее следует фаза разговора. Полезные действия, выполненные SIP Proxy сервером с точки зрения софт-телефона – только в нахождении местоположения Cisco в сети. В принципе, если бы софт-телефон знал, где расположена Cisco, он мог бы напрямую послать пакет на Cisco и соединиться с ним. Связь между SIP UA напрямую, минуя SIP Proxy или B2B UA возможна, более того, в некоторые модели IP телефонов, в частности Grandstream, встроена функция дозвона по IP-адресу вызываемого устройства.
Вся полезная информация для звонка с софт-телефона на Cisco, минуя SIP Proxy, в следующем пакете:
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 192.168.100.28:5060;rport=5060;branch=z9hG4bKFB89C4370AAC4EF2A42DBAE51544860E
From: 106 <sip:106@192.168.100.250>;tag=542367451
To: <sip:5218@192.168.100.250>;tag=EE05E448-E0A
Date: Fri, 01 Dec 2006 14:58:35 GMT
Call-ID: 78EC3705-3897-4375-9BBF-7610422A930D@192.168.100.28
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 13484 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Contact: <sip:5218@192.168.1.8:5060>
Record-Route: <sip:192.168.100.250;ftag=542367451;lr=on>
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 176
v=0
o=CiscoSystemsSIP-GW-UserAgent 7022 3917 IN IP4 192.168.1.8
s=SIP Call
c=IN IP4 192.168.1.8
t=0 0
m=audio 19398 RTP/AVP 0
c=IN IP4 192.168.1.8
a=rtpmap:0 PCMU/8000
Поле Contact: <sip:5218@192.168.1.8:5060> - IP-адрес, порт устройства и номер телефона, каким он должен приходить на устройство. В общем случае набираемый на телефоне номер (поле To: <sip:5218@192.168.100.250>) может не совпадать с тем, который попадает на Cisco, вызывающий абонент набирает его с префиксами, например 8495XXXXXXX. Задача SIP Proxy - преобразовать номер к виду, приемлемому для конкретной конфигурации Cisco, например, убрать 8 и добавить 7, чтобы номер был 7495XXXXXXX.
Если учесть тот факт, что в большинстве случаев SIP-устройства сконфигурированы на транспортировку пакетов сигнализации по протоколу UDP, то метод атаки становится очевидным.
Перейдем от теории к практике, а именно к конкретной задаче завалить звонками call-центр в Москве.
Этап первый – звонок в Москву друзьям через сеть VoIP-провайдера. При этом важно словить все пакеты сигнализации SIP на промежуточном между телефоном и SIP-сервером узле.
Этап второй - с помощью SIP Scenario вычленяем SIP-сигнализацию первого пакета INVITE и записываем в файл.
Этап третий - анализируем SIP-пакеты, полученные при первом звонке, определяем IP-адрес и SIP-порт Cisco, а также правила модификации префикса телефона.
Этап четвертый - в полученном на втором этапе пакете модифицируем поля сигнализации SIP таким образом, чтобы пакет был корректно принят Cisco, меняем префикс для номера вызывающего абонента, IP-адрес вызывающего телефона, номер вызываемого телефона. Для проверки действенности метода в сигнализацию SDP вписываем IP-адрес, идущие пакеты на который мы сможем ловить.
Этап пятый – отсылаем пакет со своего хоста. И... не получаем никакого результата, так как UDP-порт сигнализации SIP закрыт Firewall-ом провайдера VoIP.
Этап шестой – определяем (nslookup’ом) IP-адрес SIP Proxy сервера и с помощью, например, пакетного генератора nemesis, отсылаем такой же пакет, как и на пятом этапе, с той лишь разницей, что Source IP адрес пакета - IP адрес SIP Proxy сервера. Если такой пакет не фильтруется вашим и ни одним из транзитных Интернет-провайдеров между вами и Cisco, то на IP-адрес и порт, прописанные в SDP-сигнализации пакета, пойдет RTP-трафик от атакуемой Cisco. В моем случае, хотя между мной и Москвой пакет проходит, по меньшей мере, через 5 автономных систем, этот этап атаки был успешным. RTP-трафик поступал примерно 15-20 секунд. Это то время, которое требуется на то, чтобы, человек услышал звонок, была поднята трубка, человек понял, что его не слышат, и положил трубку.
Этап седьмой – автоматизация. Заключается в написании простейшего скрипта для генерации множества пакетов. Скрипт можно быстро написать на чем угодно - Perl, Tcl, Python и т. п. Скрипт должен модифицировать эталонный пакет, полученный на пятом этапе и отсылать его, заменяя Source IP на IP адрес SIP Proxy сервера. Согласно тех. заданию, надо постоянно занимать 30 телефонных линий. Примем длительность занятости линии для каждого звонка равной 10 секундам. Тогда очевидно, что скрипту надо постоянно генерировать 3 звонка в секунду – не надо высокой производительности. Тогда, через 10 секунд все 30 линий будут заняты и освобождающиеся на одиннадцатой и последующих секундах линии будут опять заниматься новыми звонками.
Реально атака по этическим соображениям осуществлена не была. Что касается первых шести этапов, то они были продемонстрированы второму админу на оборудовании провайдера за 15 минут. Также, после объяснения алгоритма работы скрипта для седьмого этапа, не вызывало сомнения, что его можно написать в течение часа или полутора. В рамки времени, отведенного на организацию атаки, я вписывался.
Теперь рассмотрим вопрос анонимности атакующего.
Относительно анонимности, я уже упоминал, что от меня до gateway пакеты проходят через, по меньшей мере, 5 автономных систем. Чтобы выяснить откуда пришел пакет с подмененным Source IP-адресом необходимо по цепочке выяснять в обратном порядке путь следовательно пакета. Для этого надо запрашивать вашего верхнего провайдера, затем одного из провайдеров работающего с ним, и так далее. Как показывает практика, такие запросы дропаются провайдерами уже на втором или третьем хопе.
Осталось рассмотреть вопрос длительности атаки. На основании собственного опыта работы осмелюсь утверждать, что с вероятностью не менее 80% администраторы VoIP-провайдера за час не примут меры по прекращению действия атаки. Так уж получилось, что gateway, через который осуществлялся выход в Московский PSTN – Cisco, поэтому буду рассматривать этот вопрос на примере Cisco.
Технически, так как все вызовы из сети IP поступают на один и тот же номер PSTN, подобную атаку прекратить просто. Для этого администраторам надо добавить только несколько строк в конфигурацию своего Cisco. Вот как предлагает делать это на сайте Cisco:
voice translation-rule 1
rule 1 reject /7495345*/
!
voice translation profile call_block_profile
translate calling 1
!
dial-peer voice 111 pots
call-block translation-profile incoming call_block_profile
call-block disconnect-cause incoming invalid_number
Наверняка на другом оборудовании также имеется подобная возможность закрыть какой-то один или группу номеров.
Проблема не в том, как закрыть такую атаку, а в том, чтобы ее выявить. Основная проблема выявления атаки в том, что gateway выполняет свои функции в нормальном режиме. Инициируются звонки из VoIP, происходит вызов в PSTN и нормальное завершение звонка. Не важно, что для всех звонков инициатором завершения является PSTN.
Существует 3 параметра, позволяющие автоматически определить наличие подобной атаки. Первый – количество одновременных звонков на gateway. Второй – ACD (Average Call Duration) среднее время длительности звонка. Третий - ASR (Average Success Rate) отношение количества успешных вызовов к общему количеству вызовов.
Нормальный провайдер будет анализировать эти параметры, однако в том, что у провайдера есть автоматические системы обнаружения атак путем анализа параметров в режиме реального времени, я сомневаюсь.
Приведу пример из собственной практики. Примерно в 1999-2002 годах, когда я работал у Интернет-провайдера, у нас появилась эффективная система определения и противодействия flood DoS-атакам. В общих чертах система работала следующим образом. Интерфейсы маршрутизаторов, через которые к нам извне поступал трафик, специальной программой опрашивались по SNMP с периодичностью 20 секунд. Вычислялась скорость поступления внешнего трафика и производилось сравнение значения полученного на предыдущей итерации с текущим. Если разница превышала некоторый, конфигурируемый минимум, то на консоль дежурного системного администратора выводилось предупреждение. При правильных настройках, flood-атаки выявлялись в 100% случаев, ложных срабатываний было сравнительно мало, около 10 – 15 в сутки. Если администратор предполагал, что началась атака, он запускал специальный скрипт, который, на основании данных, собираемых по протоколу Cisco netflow, выдавал отчет TOP 20 самых активных, по количеству принятых байт и пакетов, потребителях трафика в нашей автономной системе. Так как, обычно, атакующие флудили только на один IP-адрес, то направление атаки вычислялось путем сопоставления значений в статистике TOP 20. С верхними провайдерами у нас была договоренность относительно пресечения подобных атак. Для этого был поднят протокол Internal BGP, поэтому нам было достаточно прописать на своем маршрутизаторе маршрут в null, для атакуемого IP-адреса, и атака до нас не доходила, умирала на уровне верхнего провайдера. Атака блокировалась в среднем через 3 минуты после начала.
Для чего я это рассказываю? Только для того, чтобы сказать, что до появления первой такой атаки у нас такой системы не было, мы просто не предусматривали такой возможности, поэтому несколько раз поплатились за это длительными простоями или ухудшением сервиса. Флудеры просто вынудили нас наладить такой мониторинг. Если бы провайдер VoIP подозревал о возможности подобной описываемой атаки, он бы не дожидался ее появления, а просто исключил бы возможность атаки.
Я не буду больше освещать все возможные тонкости проведения подобной атаки. Моей целью было только доказать, что ее возможно осуществить. Перейду к другому, интересному, на мой взгляд, вопросу – отдаче.
отдача
При выстреле из ружья пуля летит в цель, а в плечо стреляющего ударяет отдача. Если проводить такую аналогию с описываемой атакой, то пуля - звонки, отдача - голосовые RTP-пакеты. Направление отдачи можно легко задавать с помощью параметров SDP-протокола в инициирующем звонок SIP- пакете. С точки зрения атакующего отдача в большинстве случаев полезна. В рассматриваемом примере атакуемый call-центр не указал своего местоположения в Интернете, однако отдачу можно направить на своих недругов. У меня, например, нет недругов, поэтому я бы, на месте атакующих, распорядился отдачей иначе. Я бы распылил отдачу на несколько десятков IP-адресов в Интернете, один и которых – мой. Это дало бы мне возможность проконтролировать эффективность атаки на основании приходящих ко мне RTP-пакетов, и гарантировало бы бездоказательность, того, что атаку проводил именно я. Единственным недостатком отдачи, с точки зрения атакующего, является появление еще одного параметра в виде дополнительного исходящего трафика, косвенно свидетельствующего о не совсем нормальном поведении сети.
Я работаю на текущий день не у провайдера, поэтому об отдаче буду судить со своей “низкой” колокольни. На текущий момент я связан с провайдером с помощью пары SHDSL-модемов, максимум, что можно выжать из моей связи на уровне Ethernet – 2 Мбит/c. На демарке с провайдером у меня стоит Cisco 2621.
Как было показано ранее, звонок инициируется одним пакетом, размер которого примерно 1 Кб. Рассчитаем сначала эффект усиления количества пакетов. Один пакет генерирует 10 секунд передачи пакетов со скоростью 50 пакетов в секунду для кодека G.711. Коэффициент усиления 500 – высокий, но он растянут во времени на 10 секунд. Моя старенькая Cisco 2621 по спецификации способна гарантированно выдерживать 25000 пакетов в секунду. Чтобы вызвать отказ в обслуживании нужно загрузить ее RTP-трафиком, генерируемым 500 одновременными звонками, для этого надо задействовать 20 VoIP gateway’ев, если предположить, что на каждом из них только один поток E1. При этом исходящий трафик атакующего будет примерно пол мегабита в секунду. При расчете я сделал допущение, что каждый шестой пакет не будет инициировать звонок.
Посчитаем генерируемый трафик. Один разговор при использовании G.711 генерирует, если считать и Ethernet-заголовки, 95,2 Кбит/c. Значит 25 звонков гарантировано забьют весь мой канал, достаточно эффекта отдачи от атаки на один gateway, при этом атакующий тратит на атаку примерно 30 Кбит/c. Меня может завалить отдача от атаки на один gateway, это совсем не радует. Теперь перейдем к вопросу о том, кто имеет возможность атаковать.
круг потенциальных атакующих
Надеюсь, из всего вышесказанного очевидно следует, что возможность атаковать есть у того, кто может исследовать сеть VoIP-провайдера, то есть у его клиента. Я знаю о наличии уязвимости у своего провайдера, однако, примерно за час я нашел еще нескольких провайдеров, которые, возможно, также подвержены таким атакам. Алгоритм поиска простой. С помощью поисковой системы находим сайт VoIP-провайдера, работающего по протоколу SIP. Далее ищем, на этом сайте FAQ по настройке оборудования, определяем адрес SIP-сервера и пытаемся аутентифицироваться и зарегистрироваться на нем с помощью soft-телефона. По сигнализации определяем софт SIP-сервера и смотрим, что он из себя представляет. Далее можно заплатить и зарегистрироваться у провайдера VoIP, чтобы исследовать подверженность атаке терминирующих gateway’ев провайдера. Надеюсь я доказал, что серьезный атакующий может при не большом вложении средств исследовать несколько провайдеров и, в конце концов, выйти на подверженного подобной атаке провайдера. Я таких исследований не проводил, поэтому статистику по уровню безопасности провайдеров, к сожалению, представить не могу. Также важно, чтобы пакеты атакующего, отосланные с произвольного IP-адреса, не блокировал ни его, ни один из транзитных Интернет-провайдеров по пути следования до атакуемого PSTN gateway.
варианты использования уязвимости
Я рассмотрел атаку на call-центр как пример использования уязвимости. Очевидно, что возможности использования описываемых методов подобной атакой не ограничиваются. Я не претендую на полный список возможных атак, представлю лишь те, на которые хватило моего воображения. Атака на call-центр или другую организацию. Собственно ее я до сих пор описывал.
Атака на gateway провайдера. Без сомнений, очень легко устроить DoS для gateway провайдера. При этом, даже если у провайдера 4 потока E1 на одном физическом устройстве, атакующему достаточно генерировать 15 пакетов SIP в секунду, осуществляя дозвон на различные номера. Провайдер будет вынужден либо отключить потоки E1, либо закрыть доступ для SIP Proxy сервера, что также является отказом в обслуживании.
Глобальная атака на обычные телефонные сети. Представьте группировку негодяев (хотя кто-то может назвать их Хакерами, с чем я лично не согласен), которые находят множество уязвимых gateway, тщательно все планируют, и затем инициируют атаку на телефонные сети одновременно во многих странах мира. Вы спросите, кому это нужно? А кому нужно атаковать Root DNS-серверы Интернета?
SPIT – Spam Over Internet Telephony. Формально SPIT – дозвон на VoIP-устройства. На сколько я знаю, SPIT не подразумевает дозвон в обычные телефонные сети. Однако данный тип уязвимости дает возможность дешево и анонимно организовать дозвон на номера обычной телефонии. На сегодняшний момент SPIT не очень востребован из-за, того, что IP-телефония не достаточно сильно развита.
Влияние на результаты интерактивного телефонного голосования. Приведу лишь один яркий пример. Хотите подарить (читай, украсть из кармана банка спонсора) дополнительно несколько тысяч рублей телезрителю, задавшему оригинальный вопрос знатокам в прямом эфире игры “Что? Где? Когда?” Не вижу особых сложностей.
Кража VoIP-трафика у провайдера. Этот вопрос представляется мне интересным, поэтому остановлюсь на нем подробнее.
кража VoIP-трафика у провайдера
Сначала, когда я задумался о данной возможности, технически схема мне представлялась следующим образом. Где-то в Интернете стоит сервер, выполняющий функции B2B UA, через который осуществляются звонки. Функции B2B UA заключаются в том, чтобы принять запрос INVITE от клиента, сформировать пакет и отослать его на gateway, имитируя IP-адрес SIP Proxy провайдера, в SDP указав свой адрес для RTP-трафика. Далее, ловить RTP- трафик и определять по пакетам, что в PSTN начался разговор, дабы сообщить об этом вызывающему абоненту по сигнализации SIP и, к тому же - проксировать через себя RTP-трафик. Хотя, теоретически схема должна работать, мне, как не профессиональному программисту написать такой B2B UA – не просто, и откровенно говоря, не интересно. Поэтому я продумывал другие схемы, используя подход специалиста по сетям. После того, как я продумал метод, не более чем за час я имел готовое решение для тестов.
Метод основывается на нюансах работы сигнализации SIP на уровне приложения с транспортным сетевым уровнем. Дело в том, что UDP-пакет с сигнализацией SIP может прийти с любого IP-адреса и порта, однако ответ на этот пакет теоретически может прийти на IP-адрес и порт, прописанные в полях сигнализации SIP. RFC 3261 описывает такие ситуации.
Если это так, то это может помочь успешно обойти firewall, блокирующий только входящие пакеты сигнализации SIP. Во многих случаях для сигнализации SIP организовать firewall, блокирующий исходящие пакеты сигнализации SIP, довольно просто. Очень многие SIP-серверы и UA используют симметричные ответы. Под симметричными ответами подразумевается, что сервер или UA отвечает на SIP-пакеты с того же порта, на котором он слушает запросы. Присмотревшись к использовавшемуся мной в атаке сценарию, я заметил, что в случае с Cisco gateway это не так. У IP-телефона и SER явно указан порт 5060, у Cisco не указан порт, так как их несколько. Слушает она на порту 5060, а отвечает с произвольного порта, в данном случае - 52506.
Симметричный подход необходим для многих схем корректной работы SIP-сигнализации через NAT, однако Cisco в случае с NAT рекомендует использовать SIP ALG NAT, видимо поэтому и считает не важным, с какого порта посылать ответы. ALG означает Application Layer Gateway. Многие не знают об этой технологии, однако технология SIP ALG NAT очень полезна. Суть ее в том, что пакет с сигнализацией SIP анализируется на уровне приложения, помимо изменения IP-адреса самого пакета и создания трансляции в NAT для сигнализации и RTP, изменяются также и IP-адреса в пакете сигнализации SIP и SDP. Это позволяет организовать схему, в которой логику прохождения через NAT не нужно реализовывать дополнительными средствами, то есть использовать STUN-сервер, статические NAT-трансляции или другие технологии. Вообще, ALG не разработан специально для SIP, работает он и для H.323, и вообще не только VoIP-протоколов: HTTP, TFTP, telnet, archie, finger, NTP, NFS, rlogin, rsh, rcp. Впрочем, я отвлекся, кому интересно может почитать об ALG NAT здесь http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801af2b9.shtml.
Я не говорю, что в случае с Cisco организовать блокирующий обратные пакеты SIP firewall сложно, я имею в виду, что простого закрытия исходящих пакетов с порта 5060 не достаточно в данном случае. Админы могут просто не учесть этот факт и допустить ошибку при настройке firewall’а для исходящих SIP-пакетов.
Итак, перейдем к нашей схеме (рис. 2). Она похожа на схему моего VoIP-провайдера. В центре SER SIP Proxy, слева – клиенты, которые будут платить деньги, справа - терминирующие gateways, с которых мы будем воровать VoIP-минуты. Между SER и gateway небольшая “примочка”, функция которой – менять IP-адрес в пакете, следующем на gateway от моего SIP Proxy на IP-адрес SIP Proxy моего VoIP-провайдера.
Рис. 2.
Функции “примочки” схожи с функциями стандартного NAT, поэтому логично, что и работать она будет по тем же принципам. Моим рабочим инструментом в исследовании сетей является FreeBSD, поэтому я использовал методы организации NAT, применяемые в этой операционной системе – divert-сокеты и ipfw. Также я буду использовать замечательный perl-модуль, написанный Stephanie Wehner - Net::Divert.
use Net::Divert;
use NetPacket::IP;
$divobj = Net::Divert->new('localhost',9999);
$divobj->getPackets(\&alterPacket);
sub alterPacket {
my($packet,$fwtag) = @_;
# Decode Packet
$ip_obj = NetPacket::IP->decode($packet);
# Change Source IP address
$ip_obj->{src_ip}= "192.168.50.15";
# Encode Packet
$packet = $ip_obj->encode;
# write it back out
$divobj->putPacket($packet,$fwtag);
}
Плюс такое правило для обработки исходящих с интерфейса fxp0 FreeBSD:
ipfw add 500 divert 9999 all from any to 192.168.3.10 out via fxp0
Все это вместе исполняет функции “примочки” для SIP Proxy, работающго на том же FreeBSD-сервере для схемы, представленной на рисунке 3.
Рис. 3.
Очевидно, что для того, чтобы воровать минуты еще с одного gateway достаточно прописать еще одно правило для ipwf, только указать при этом нужный IP-адрес. Если же необходимо воровать трафик сразу у нескольких провайдеров, надо модифицировать скрипт, привязать его к другому divert- порту и, соответственно, изменять правила для ipfw. Я не использовал стандартный демон natd по причине того, что предполагал, что необходимо будет менять еще некоторые поля сигнализации SIP в исходном пакете, то есть реализовывать функционал, схожий с ALG.
В целом, схема не работоспособна. Тесты с моим Cisco показали, что пакеты сигнализации SIP возвращаются не на адрес и порт, прописанные в сигнализации SIP, а на Source адрес и порт, которые gateway получает, анализируя исходный пакет на транспортном уровне, RFC этого не запрещает. Это справедливо для всех пакетов, кроме пакетов BYE, сигнализирующих об окончании разговора. Это не позволяет вести полноценный billing для клиентов, также не позволяет сообщить клиенту о начале разговора, и, следовательно, не приемлимо в коммерческих целях. Однако позволяет успешно использовать схему для организации SPIT-а.
Поясню. Допустим, некто получил полный контроль над сервером, расположенным у Интернет-провайдера, не блокирующего пакеты с подмененным Source IP-адресом. Он устанавливает на этот хост SIP Proxy, конфигурирует его и “примочку”. После этого с любой бот-машины можно организовать дозвон на произвольный номер в PSTN, дабы счастливый владелец телефонного номера в 3 часа ночи узнал о том, что в продаже появились очень эффективные таблетки от бессонницы. Конечно, есть небольшие технические трудности, в частности, программа на бот-машине должна уметь анализировать RTP- трафик, чтобы понять, когда получатель SPIT-а поднял трубку, однако, думаю, они решаются.
Выяснив, что простой замены Source IP пакета не достаточно, я провел еще несколько веселых часов, исследуя поведение Cisco и перечитывая RFC 3261. Я модифицировал скриптом поля SIP, в частности, поле Via, изменял протокол с UDP на TCP, добавлял параметры sent-by и received. Однако у меня ничего не получилось, такая схема эффективной кражи трафика VoIP-провайдера не заработала. В данном случае отрицательный результат – тоже результат. Самое время перейти к вопросу защиты провайдера.
защита провайдера
Откровенно говоря, общих рекомендации дать не возможно. Защита в любом случае зависит от очень многих факторов.
Можно использовать вместо SIP Proxy (или вместе с ним) Session Border Controller и эффективно скрывать топологию своей сети. Можно использовать дополнительный SIP Proxy сервер, прохождение сигнализации через который будет невидимым для клиентов. Это скроет от клиентов реальный адрес, с которого можно инициировать звонок на PSTN gateway.
Самым очевидным для данного случая решением я вижу использование в качестве транспорта для общения между SIP Proxy и PSTN gateway протокола TCP вместо UDP. Доступ же на UDP-порт сигнализации SIP gateway закрыть от всех IP-адресов. В RFC 3261 на странице 141 сказано буквально следующее “All SIP elements MUST implement UDP and TCP. SIP elements MAY implement other protocols”. RFC 3261 был написан в 2002 году, большинство современных “SIP-элементов” должно поддерживать данный RFC.
выводы
Невозможно судить об уровне защиты сетей VoIP только на примере одного провайдера. Можно лишь сказать, что есть провайдеры, которые могут пострадать от подобных атак. Хотя я не слышал об успешно проведенных подобных атаках, это вовсе не значит, что их никто не проводил до текущего момента, и, тем более, что они не появятся в будущем. Я думаю, провайдерам стоит строить свои сети с учетом возможности подобных атак.
P.S.
Перечитывая все написанное, я прекрасно осознаю, что не осветил всех тонкостей, и сделал ряд грубых, не до конца проверенных, предположений. Однако я хотел написать не пособие по проведению атаки, но просто указать на реальную проблему и на то, сколь серьезными могут быть последствия. Надеюсь, читателю было интересно.
Zelendoplit
Сетевые решения. Статья была опубликована в номере 12 за 2006 год в рубрике лабораторная работа
