Zelendoplit специалист по сетям и ОС

zelendoplit@yahoo.com

У меня зазвонил телефон.

-Кто говорит?

-SPIT!

Предисловие.

 Поводом для написания статьи послужило спам письмо, поступившее на адрес  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 http://www.iptel.org/ . 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 http://www.iptel.org/~sipsc/. В данном примере производится звонок с программного клиента на Cisco с FXO картами, подключенными к мини АТС.  В качестве SIP Proxy сервера используется SER. В примере опущен процесс аутентификация на SIP сервере, который присутствует в реальных условиях.

Рисунок 2.

Обратите внимание, что софт телефон отослал только один пакет и далее пассивно получает уведомления о процессе установления связи.  Один пакет софт телефона заставил Cisco набрать номер в PSTN, открыть RTP канал и сообщить о том, что абонент поднял трубку. RTP трафик от Cisco начинает поступать сразу после удачного набора номера в PSTN, в сценарии это пакет PF:5 (Session Progress 183),  и до момента, когда абонент поднимет трубку – пакет PF:7, передаются гудки.  Далее следует фаза разговора.

Полезные действия, выполненные SIP Proxy сервером с точки зрения софт телефона – только в нахождении местоположения Cisco в сети. В принципе, если бы софт телефон знал, где расположен Cisco, он мог бы напрямую послать пакет на Cisco и соединиться с ним. Связь между SIP UA напрямую, минуя SIP Proxy или B2B UA возможна, более того, в некоторые модели IP телефонов, в частности Grandstream, встроена функция дозвона по IP адресу вызываемого устройства.

Вся полезная информация для звонка с софт телефона на Cisco, минуя SIP Proxy в пакете PF:6.

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, etc. Скрипт должен модифицировать эталонный пакет, полученный на пятом этапе и отсылать его, заменяя 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 это не так. Это видно на рисунке 2, у 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, работает он и для h323 и не только 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 пакетов.

Итак, перейдем к нашей схеме. Схема похожа на схему моего VoIP провайдера. В центре SER SIP Proxy, слева - клиенты которые будут платить деньги, справа терминирующее gateway, с которых мы будем воровать VoIP минуты.  Между SER и gateway небольшая “примочка”, функция которой – менять IP адрес в пакете, следующем на gateway от моего SIP Proxy, на IP адрес SIP Proxy моего VoIP провайдера.

Рисунок 3.

 

Функции “примочки” схожи с функциями стандартного 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 сервере для схемы, представленной на рисунке 4.

Рисунок 4.

Очевидно, что для того, чтобы воровать минуты еще с одного 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

Перечитывая все написанное, я прекрасно осознаю, что не осветил всех тонкостей, и сделал ряд грубых, не до конца проверенных, предположений. Однако, я не хотел написать пособие по проведению атаки, но просто указать на реальную проблему и на сколько могут быть серьезными последствия. Надеюсь, читателю было интересно.

Компания SoftKey – это уникальный сервис для покупателей, разработчиков, дилеров и аффилиат–партнеров. Кроме того, это один из лучших Интернет-магазинов ПО в России, Украине, Казахстане, который предлагает покупателям широкий ассортимент, множество способов оплаты, оперативную (часто мгновенную) обработку заказа, отслеживание процесса выполнения заказа в персональном разделе.