Сигурност във voip мрежите

НБУ

Дипломна работа

Бакалавърски факултет

Калин Диков

[СИГУРНОСТ ВЪВ VOIP МРЕЖИТЕ] Научен ръководител: доц. д-р. Александър Сладкаров

Сигурност във VoIP мрежите

2

Съдържание:

1. УВОД ............................................................................................................................................................... 3 2. Приложение на VoIP ...................................................................................................................................... 3 3. Вектори на атаката ........................................................................................................................................ 4 4. Евентуални заплахи във VoIP ........................................................................................................................ 5 4.1 Типове заплахи......................................................................................................................................... 6 4.2 H.323 базирани атаки ............................................................................................................................32 4.3 Real Time Protocol (RTP) ...........................................................................................................................39 5. МЕХАНИЗМИ ЗА ЗАЩИТА .....................................................................................................................................41 5.1 Механизми за защита на сигнализацията ..........................................................................................41 5.2 Транспортен слой за сигурност - TLS ....................................................................................................46 5.3 Инфограмен (дейтаграмен) транспортен слой за сигурност - DTLS .................................................49 5.4 S/MIME ....................................................................................................................................................50 5.5 Криптиране ............................................................................................................................................52 5.6 IPSec ........................................................................................................................................................52 5.7 Механизми за защита при H.323...........................................................................................................54 5.8 Механизми за защита на MGCP ............................................................................................................60 5.9 МЕХАНИЗМИ ЗА ЗАЩИТА НА МЕДИЯТА ..............................................................................................................60 6. VOIP И МРЕЖОВИ КОНТРОЛИ ЗА СИГУРНОСТ ............................................................................................................67 6.1 Архитектурни съображения .................................................................................................................67 6.2 Сегментация на мрежата ....................................................................................................................68 6.3 Логическо разделяне на гласовия трафик от този на данни .............................................................69 6.4 QoS и ограничаване на трафика (shaping) ............................................................................................69 6.5 Защитни стени ......................................................................................................................................70 6.6 NAT и IP адресиране ................................................................................................................................70 6.7 Контролни списъци за достъп (ACL) .....................................................................................................71 7. Откриване на прониквания при VoIP ...........................................................................................................71 7.1 Системи за улавяне на прониквания - NIDS ..........................................................................................71 7.2 Хост-базирани системи за улавяне на прониквания - HIDS .................................................................75 7.3 Създаване на log файлове ......................................................................................................................75 7.4 Syslog .......................................................................................................................................................75 8. Мрежови топологии .....................................................................................................................................76 9. Заключение ..................................................................................................................................................79


3

1. Увод

Конвергенцията при наземната, безжичната и Интернет комуникация стимулира развитието на нови приложения

и услуги, които доведоха до революция в телекомуникациите. Интерконекцията между PSTN (Public Switched

Telephone Network) и IP (Internet Protocol) мрежите е позната като Мрежа от Ново Поколение (NGN – Next

Generation Network), докато интерконекцията на Интернет с безжичните комуникации е позната като IP

Мултимедийна Подсистема (IMS – IP Multimedia Subsystem). И двете архитектури играят важна роля в

еволюцията от традиционни телекомуникации към мултимедийни комуникации. Също така съществува

терминът „triple play‖, който се отнася до възможността на доставчика на услуги да предложи пренос на глас,

видео и данни като единна услуга. Подобно на „triple play‖, ―quad play‖ означава доставянето на глас, видео,

данни и мобилни комуникации.

IP комуникациите са създадени използвайки IPv4 и IPv6 протоколите с цел да поддържат приложения като

имейл, WWW и телефония. Целият трафик се осъществява по един и същ кабел/канал (наречен pipe). Тъй като

капацитетът в IP базираните мрежи е по-евтин в сравнение с PSTN, IP базираните мрежи се разглеждат като

просто инфраструктура за пренос на пакети, в която сървърите за различните приложения и терминали

поддържат интелигентността на мрежата. Крайните устройства биха могли да бъдат сложни и скъпи, но

инфраструктурата е евтина, в сравнение с традиционните телефонни мрежи.

Фундаментална област на изследване във VoIP комуникациите е Качеството на Услугата (QoS), където някои от

аспектите се отнасят до сигурността (например – лишаването от услуга или Denial of Service, DoS). Поради

природата на пакетната комутация, трафикът понякога може да се състои от много пакети накуп (burst), и

поради тази причина е обект на латенция, закъснение и jitter. IP пакети могат да бъдат изпращани по различни

маршрути и съответно да бъдат получавани в различен ред от този, по който са изпратени. Те могат да бъдат

събрани и сглобени навсякъде, след това пратени наново в различна големина от тази на оригиналните пакети.

Често срещано недоразбиране е, че IP е синоним на Интернет; всъщност това далеч не е така. Не всички IP

мрежи са свързани с глобалната, напротив преобладават частните и наети физически връзки, и по-специално в

критичните инфраструктури и бизнес мрежите, при тях нормално е да нямат или да имат много ограничена

свързаност с Интернет. IP е транспортният протокол, не самата мрежа.

2. Приложение на VoIP

Първият начин за изграждане на VoIP с промишлени или бизнес цели е чрез използването на частни наети

линии или VPN връзки между различни точки, като алтернатива на използването на публичния Интернет, с цел

рутиране на разговори. Това се прави, за да бъдат поне частично избегнати рисковете, свързани с

„враждебността― на Интернет. При тези видове предлагане на услуга, инфраструктурата е изградена и се

поддържа от предприятието или фирмата, или се закупува само услугата, която е инсталирана на друго място -

„hosted― и съответно няма необходимост от свързаност към Интернет или традиционната телефонна мрежа.

Интернет базираното изграждане на VoIP съдържа „интелигентен― софтуерен клиент, който се регистрира в

Интернет базираната услуга, или регистър. При доставчика на услугата, това изисква минимална инвестиция в

инфраструктурни ресурси, сравнено с традиционната телефония и вместо това експлоатира „безплатната―

Интернет свързаност. Първата такава широко разпространена услуга беше Microsoft Messenger, която ползваше

Hotmail като регистър за намиране и идентифициране на клиентите си. Друга популярна услуга е Skype, където

се ползва подходящ собствен протокол и софтуерен клиент за разговори през Интернет, като централният

регистър се управлява от Skype. Примери за комерсиални, но все пак Интернет базирани услуги, изградени

върху истинските отворени стандарти са Vonage, Broadvoice, SunRocket,Hermes phone и Packet8.

Възможно е VoIP да бъде предлаган като затворена комерсиална услуга от традиционният или нов

телекомуникационен оператор, като част от неговия PSTN или като негов заместител. Крайните устройства най-

често са стандартизирани и преконфигурирани, така че да се регистрират единствено към мрежата на

доставчика. За клиентите те се представят като нормални телефонни устройства, които поддържат множество функции в повече, които се осигуряват от VoIP инфраструктурата. Дали се използва Интернет като преносна

среда от телефонните оператори или доставчици е без значение, като изключим сигурността и перспективата за

качество на услугата. Безжичните VoIP терминали и роумингът правят възможна доста безразсъдната употреба

на VoIP. Без значение дали софтуерният клиент е инсталиран на мобилен телефон или лаптоп, Интернет

телефонията позволява на потребителите да ползват услугата навсякъде, където подобен достъп е възможен.

Слабият контрол върху сигурността на места, където конфиденциалност, идентификация и оторизация на

потребителите и устройствата, както и отвореността на инфраструктурата, излагат самата услуга и

потребителите като потенциални мишени на серия от атаки. Безжичните терминали биха могли да бъдат

ограничени до затворена бизнес безжична мрежа, където роуминга е лимитиран чрез достъп единствено до VoIP

инфраструктурата. Целта е да се запази определена мобилност, но да се избегне подобна „отвореност― на

телефонната услуга. По-специален случай при IP телефонията е Sigtran протоколът, който всъщност представлява SS7 по IP, вкарвайки в тунел традиционната PSTN сигнализация за пренос по IP мрежа.


4

За да дефинираме изискванията за сигурност във VoIP, трябва да се съобразим но не и да се ограничим със

следното:

Колко критична е IP телефонията за нашата организация

Каква критична информация може да бъде пренесена от системата или услугата

Какви са механизмите за възстановяване, в случай че се получи грешка в системата

От какви спомагателни технологии зависи услугата

В какви системи и мрежи ще бъдат интегрирани услугите и също така изложени ли са на евентуални

заплахи

Съществува ли зависимост от доставчици на услуги и ако „да‖ те носят ли отговорност за евентуални

щети

Как са разпределени отговорностите вътре в нашата организация

Каква е цената при евентуална загуба на информация и спиране на работата на системата

Какви са последните вътрешни инциденти в сферата на сигурността

Какви са изискванията на местния регулатор

Какви са планираните краткосрочни и дългосрочни промени

3. Вектори на атаката

Всяка една технология притежава пропуски в сигурността, от електронните машини за гласуване до VoIP. Един

от елементите, който често обърква или разсейва материята е възприемането на сложността, приложена при

извършването на евентуална атака. Истината е, че с присъствието на достатъчна мотивация, включвайки в това

число печалбата, славата или дори отмъщението, може да бъде експониран и експлоатиран всеки пропуск в

сигурността. Векторите на атака са подобни на традиционните вектори в мрежовото оборудване. Например, не е нужно да се притежава физически достъп до телефон или PBX кутията. Достъпа, необходим за изпълнение на

VoIP атаки зависи от типа на инсталацията, най-популярните вектори на атаката са изброени в списъка по-долу.

Локална подмрежа, например вътрешна мрежа, където VoIP се използва чрез изключване и/или споделяне на

Ethernet връзка с хардуерен VoIP телефон (обикновено поставен на нечие бюро) - атакуващият може да се

свърже към мрежата за пренос на глас.

Локална мрежа, която ползва безжична технология за връзка с не-проверени (untrusted) потребители, като

кафенета, хотели или конферентни зали - атакуващият може просто да се свърже с безжичната мрежа,

прерутира трафик и засече VoIP разговори.

Публична или мрежа на която се няма доверие, като Интернет, където се ползва VoIP комуникация -

атакуващият, който притежава достъп до публична мрежа може просто да подслуша комуникацията и да

прихване телефонни разговори.

Фигура 3-1.Вектори на VoIP атаката


5

4. Евентуални заплахи във VoIP

Първата версия на IETF черновата изброява следните категории заплахи:

Заплахи чрез прихващане и модифициране

Заплахи чрез прекъсване-на-услугата (Interruption-of-service)

Заплахи чрез злоупотреба-на-услугата (abuse-of-service)

Социални заплахи

Съществуват много различни категоризации и таксономии, както и различните класификации са създадени с

различна цел. Във VOIPSA (Voice Over IP Security Alliance; voipsa.org) заплахите се разглеждат много подробно,

с цел да се даде колкото е възможно повече информация, която може да бъде от огромна помощ за някои

организации. В IETF класификацията на заплахи ги категоризира като се основава на това как спецификациите на протокола могат да бъдат подобрени, с цел да се сведе до минимум въздействието на една атака и затова не

засяга въпроси, свързани с поддържащата инфраструктура, като например платформите на операционните

системи или мрежовите конфигурации.

Заплахите, свързани с VoIP са ограничени в следните категории:

Смущаване и нарушаване на услугата - това е опитът да се попречи на VoIP услуги да работят правилно,

включително и на тяхното управление, обезпечение, достъпа и операции. Атаките в тази категория

могат да засегнат всеки мрежов елемент, който поддържа VoIP услуги, включително и рутери, DNS

сървъри, SIP прокси сървъри, Гранично-Сесийни Контролери, и т.н. Такива атаки могат да бъдат

инициирани или от разстояние, без да се има пряк достъп до целевите мрежови елементи и

манипулирането на VoIP протоколите, или локално, чрез изпращане на вредни инструкции или команди. Атакуващият може да се цели в крайно устройство (напр. VoIP телефон), основен мрежов компонент,

или набор от компоненти като SIP прокси сървъри, които могат да повлияят на потребителите. Тази

категория включва също и атаките чрез „тормоз‖ (създаващи дискомфорт) като SPIT (спам чрез

Интернет телефония).

Подслушване и анализ на трафика – това е събирането на чувствителна информация, небходима за

подготовката на едно нападение. При VoIP (или, по принцип при Интернет мултимедийните

приложения), това означава, че нападателят има възможността да наблюдава необезопасена

сигнализация или потоци медия, които се обменят между потребителите. Тази категория включва

анализ на трафика и може да бъдат пасивна или активна (т.е., да събира, съхранява и анализира, или

декодира в реално време/транслира медийни пакети). Атаката има за цел извличането на словесно или

текстово (например номер на кредитна карта или ПИН) съдържание от един разговор или анализиране съобщенията между страните, за да се установят комуникационни модели, които могат да бъдат

използвани по-късно за извършване на други атаки.

Маскиране (masquerading) и имперсонализация – това е възможността за представяне от името на даден

потребител, устройство, или услуга, за да се получи достъп до определена мрежа, услуга, мрежов

елемент, или информация. Всичко това е обособено като отделна категория, защото атаките чрез

маскиране могат да бъдат ползвани за извършване на измами, неоторизиран достъп до информация, и

дори нарушаване на самата услуга. Специален случай на този вид заплаха е имперсонализацията,

където нападателят може да претендира за или да превземе нечия идентичност в системата. В тази

категория, потенциалните мишени са потребители, устройства или мрежови елементи и атаките могат

да бъдат реализирани чрез манипулиране на сигнализацията или медийните потоци от разстояние или чрез неоторизиран достъп до VoIP компоненти (например, сигнализационни шлюзове, SIP регистъра

или DNS сървърите). Така например, ако даден телекомуникационен оператор използва само ID

информацията от обаждащият се номер за удостоверяване достъпа до гласовите им пощенски кутии, е

възможно атакуващата страна да подслуша и присвои (spoofing) CID информацията, за да получи

достъп до потребителската гласова пощенска кутия. Маскарадните атаки във VoIP мрежите също така

могат да бъдат реализирани чрез манипулиране на протоколите стоящи на по-ниско ниво, които

осигуряват поддръжка на VoIP услугата (като ARP, IP и DNS).

Неоторизиран достъп – това е възможността за достъп до дадена услуга, функционалност, или мрежов

елемент без съответната оторизация. Атаките в тази категория могат да бъдат използвани в помощ на

други атаки – в това число смущение на услугата, подслушване, маскиране и измами, тъй като

нападателят притежава контрол над устройство, ресурс или достъп до мрежата. Разликата между маскирането и неоторизирания достъп е, че нападателят не се нуждае да играе ролята на друг

потребител или мрежов елемент, а по-скоро може да получи пряк достъп, използвайки уязвимост като


6

препълване на буфер, непроменена конфигурация по подразбиране, или лоша сигнализация и лош

контрол на мрежов достъп. Например, хакер с администраторски достъп до SIP прокси сървър може да

наруши VoIP сигнализацията чрез изтриване на файловата система на операционната система, като по

този начин обезсили хоста и услугата. Друг пример е, когато нападателят има достъп до медиен шлюз и

инсталира зловреден софтуер за събиране на пакети медия и в крайна сметка изпълни пасивно

подслушване върху комуникациите на абоната. Неоторизираният достъп може да доведе до заплахи

като подслушване, маскиране и измама.

Измама – това е възможността за злоупотреба с VoIP услуги за лична или парична печалба. Тази

категория нападения е една от най-критичните за далекосъобщителните оператори и доставчици, наред с изискването за непрекъсваемост и наличност на услугата. Измама може да бъде реализирана чрез

манипулиране на сигнализационните съобщения или конфигурацията на VoIP компонентите, в това

число платежната система (billing). Някои сценарии за измама, осъществими в сегашните VoIP

приложения могат да бъдат изпълнявани чрез манипулирането на сигнализационните потоци при

разговор. Очаква се, че ще се появят по-сложни техники за измама когато VoIP стане основната

тенденция в бранша.

Гореизброените категории предоставят точна структура, в която всички настоящи и бъдещи атаки е възможно да

бъдат поставени на съответното им място.

4.1 Типове заплахи

По-долу ще изброя най-основните типове заплахи, срещани до момента при VoIP.

Отказ от услуга (Denial of Service или DoS)

Прекъсването на услугата може да бъде насочено към различни плоскости на VoIP, включително управлението,

контрола или потребителския слой.

DoS атаки могат да бъдат извършени срещу всеки от компонентите, поддържащи VoIP инфраструктурата и

свързаните с нея услуги. Атаките могат да се целят в компоненти от поддържащата инфраструктура; ядрото

VoIP компоненти (включително крайни устройства, сигнализация и медия шлюзове), както и компоненти,

използвани за управление, администрация и обезпечение на VoIP услуги.

Фигура 4.1-1 описва логичното представяне на слоевете, които могат да се превърнат в мишени на нападателя,

по време на подобен род атака.

Фигура 4.1-1. Слоеве – потенциални мишени

DoS атаките могат да бъдат насочени към всеки мрежов елемент с цел нарушаване функционалността на

системата или прилежащите мрежови възможности на съответния компонент.Сред компонентите, които могат

да бъдат атакувани по време на подобен род атака са:

Мрежови компоненти:

Крайни/потребителски устройства

Основни елементи на мрежата (като сигнализационни шлюзове)


7

Поддържаща инфраструктура, стояща в основата (напр. рутъри)

Компоненти на услугата или приложенията:

Сигнализация

Медия

Компоненти на операционната система:

Управление

Платежна система (billing)

Система анти-измама

Система за сигурност

Система за обезпечаване

Очевидно е, че "защитата в дълбочина" е фундаментално изискване при VoIP, тъй като VoIP протоколите трябва

да поддържат модела клиент/сървър, модел при основните елементи на мрежата и модел на крайните

устройства (например, потребителския телефон) и по този начин се разширява полето на действие на атаките от

тип DoS. VoIP се различава от други приложения като електронна поща и уеб сърфиране, тъй като те не се

нуждаят от това да поддържат комуникация в реално време.

Основният ефект от DoS е превръщането на атакуваната услуга или система в безполезна такава. Организациите

могат да симулират DoS атаки за измерване надеждността на своите системи или услуги, както и да се оценят

техните възможности за откриване на евентуално проникване и реакция при инцидент. Основните видове DoS

атаки са базирани на претоварване на системата, а също така и на изпращане на зловредни пакети. Базираните

на натоварване атаки насищат мрежата, системата или услугата с хиляди пакети, пращани с цел понижаване

лентовата скорост на мрежата и в крайна сметка качеството на услугите. При VoIP (и като цяло при Интернет мултимедийните приложения), една товаро-базирана атака се състои от създаване на хиляди паралелни сесии в

бърза последователност като те се организират така че да прекъснат или нарушат дадената услуга (например,

глас или видео). Зловредните пакетно-базирани атаки се състоят от генериране на едно и също деформирано

съобщение, което принуждава услугата-получател, да наруши или прекрати обработката или дори да причини

рестартирането на системата-мишена.

VoIP мрежовите елементи, които могат да се превърнат в мишени по време на Интернет-базирани DoS атаки са

например, VoIP потребителски агент, VoIP прокси, рутер който поддържа VoIP, или SBC (гранично-сесиен

контролер). В мишени също могат да бъдат превърнати конкретни крайни устройства като кабелен модем, сет-

топ бокс (STB) или телефонен адаптер с поддръжка на мултимедийни услуги като глас и видео. В допълнение,

DNS сървъри могат да бъдат атакувани за нарушаване на комуникациите в случаите, когато бива ползван

ENUM, а подобен вид нападение когато сървърът е част от една по-сериозна институция може да бъде катастрофално.

При подготовката за DoS атака, нападателите обикновено първо анализират целевата система. Това включва

сканиране на потенциалните услуги, отворени за атака. След като отворените услуги са вече изброени,

нападателят потвърждава че може да се свърже с услугата чрез изпращане на валидна последователност от

съобщения до целевата система. Тези валидни последователности могат да бъдат използвани за анализ на

наличния набор от функции, които евентуално могат да бъдат ползвани за целта на DoS атаката. Ако SIP

комуникацията е отворена, нападателят може да изпрати валидна SIP последователност от команди, която

„преговаря‖ за извикване параметрите на услугата. Потенциалните мишени могат да бъдат избрани от

различните слоеве на SIP:

Атаки срещу най-ниските слоеве на комуникация могат да ползват IPv4, UDP или TCP връзки

Протоколите за сигурност като TLS или IPSec също могат да бъдат използвани за атака

За атака могат да бъдат ползвани SIP сесиите

Чрез договаряне на медия параметрите в SIP сигнализацията, атакуващата страна може да отвори

връзки през периметъра на защита и да ползва RTP потоци за атака, например чрез серия потоци с едни

и същи идентификационни параметри, „изстреляни‖ срещу дадено устройство-мишена

Целта на DoS атаките може да бъде всичко по пътя на съобщението, включително периметъра на защита, SIP

прокси сървър или потребителски агент (UA). Атаката може да бъда стартирана като

деформирано/модифицирано DoS съобщение или като бомбардиране със DoS съобщения. В първия случай,

един единствен пакет може да доведе устройството до срив, докато при „засипващата― с пакети атака,


8

нападателят стартира редица потоци от съобщения срещу целта. Атаката може да произхожда от един хост или

от много такива паралелно. Тя също може да бъде стартирана от PSTN мрежа, или пък може да бъдат насочена

към такава PSTN мрежа зад VoIP прокси сървър. Целта на атаката може да бъде един единствен хост, или да

бъде насочена към няколко цели едновременно, като резултатът може да се изразява в срив, или пък да

препълни ресурсите на системата (например наличното пространство за съхранение в системата за гласова

поща). Когато атаката е насочена към устройство-посредник, не е задължително нападателят да познава всички

реални крайни устройства, стоящи зад мрежовата инфраструктура.

В жертва на атаката може да се превърне и трето лице, тъй като адресът-източник на произхождащите

съобщения е възможно да бъде подправен. При атаките чрез отразяване (reflection) или усилване (amplification),

хостът до който достигат съобщенията отговаря обратно на атакуващите съобщения, но те всъщност биват изпратени към крайната мишена на атаката. При атаките чрез засипване с пакети, показатели като например

размера на данните и броя на съобщенията са ценна информация за нападателя. За успешната атака от тип

амплификация, дестинацията трябва да отговаря с по-големи пакети, отколкото са изпратени от нападателя, като

по този начин усилва съобщителния поток, необходим за стартиране на flood.

Отказ от услуга чрез деформиран/зловреден пакет

DoS атаката може също така да се състои от индивидуални деформирани пакети. Процесът на произволно или

полу-произволно генериране на деформирани пакети се нарича fuzzing.

Отказът-от-услуга (DoS) може да засегне всяка IP-базирана мрежова услуга. Въздействието на една DoS атака

може да варира от леко влошаване на дадената услуга до пълната й загуба. Съществуват няколко различни

класове DoS атаки. Един вид, при която пакетите могат просто да бъдат бомбардирани върху мрежата-мишена

от множество външни източници се нарича Разпределена атака за Отказ-от-Услуга (DDoS – Distributed Denial of

Service) атака.

Вторият голям клас предпоставки за DоS, се появяват, когато устройствата в рамките на вътрешната мрежа са

засипвани от пакети, така че да се сринат - изваждайки от строя свързани с тях части на инфраструктура. Както

и в DDoS сценария описан по-горе, нарушаването на услугата се появява при изчерпване на ресурсите –

получава се глад за скорост или канал и най-вече липса на процесорен ресурс. Например, някои IP телефони ще

спрат да работят, ако получават непрекъснато UDP пакети по-големи от 65534 байта на порт 5060. Нито

проверките за цялост/интегритет, нито криптирането могат да попречат на тези атаки. DoS или DDoS атаките се

характеризират само с обема на пакети, изпратени към компютъра-жертва; дали тези пакети са подписани от

сървъра, съдържат реални или подправени IP адреси-източници, или са криптирани с фиктивен ключ – нито

едно от тези условия не е свързано с този вид атака.

Защитата срещу DoS атаки е трудна и поради факта че VoIP е просто още една IP мрежова услуга, тя е също

толкова чувствителна към DoS атаки както всяка друга IP услуга по мрежата. Освен това, DoS атаките са особено ефективни срещу услуги в реално време като VoIP, тъй като те са най-чувствителни към

неблагоприятното моментно състояние на мрежата. Вирусите и червеите са включени в тази категория, тъй като

те често причиняват DoS или DDoS поради увеличения мрежов трафик който генерират, като част от усилията

си да се възпроизвеждат, плодят и разпространяват.

Удостоверяване

При SIP се използва дайджест (digest) автентификация за валидиране на потребителите, което представлява

процедура/метод тип запитване и отговор. Този удостоверяващ процес е базиран в голямата си част на HTTP

дайджест(сложна) автентификацията, с малки промени.

Когато потребителският агент изпраща SIP REGISTER или INVITE до сървър, изискващ удостоверяване,

автоматичните съобщения които биват върнати обратно от сървъра са 401 или 407, които означават че е

необходима автентификация. Вътре в 401 или 407 отговора се съдържа запитване за паролата (nonce – случаен

стринг). Конкретно, потребителският агент трябва да включи следните параметри в своя отговор:

Username – потребителското име (напр. Ivan)

Realm – ползваният по време на сесията домейн (напр. iptelco.bg)

Password – паролата, ползвана от UA (напр., HackniMe)

Method - SIP метода, ползван по време на сесията (INVITE или REGISTER)

URI – Единният Рерурсен Идентификатор (Uniform Resource Identifier) на UA, като SIP:192.168.2.102

Challenge (nonce) – уникалната заявка/запитване за парола, изпратена от сървъра под формата на 401 или

407 съобщение

Cnonce - клиентско „nonce‖, не е задължителен параметър, освен ако сървърът не изпраща информация за

качество на услугата (QoS), обикновено липса конкретна стойност

Nonce Count (nc) – броят пъти на изпратена от клиента стойност за nonce, не е задължителен параметър и

обикновено липсва конкретна стойност


9

Следните стъпки описват процеса на удостоверяване на SIP UA към SIP сървър, ползвайки дайджест схема:

1. Потребителският агент изпраща заявка за комуникация (чрез REGISTER, INVITE или друг SIP метод).

2. Сървърът (SIP Регистър или Прокси) отговаря или с 401 или с 407 отговор - „неоторизирано―,

съдържащ полето „nonce‖, приканващо към процес на удостоверяване.

SIP потребителският агент изпълнява три действия, с цел изпращане на правилният MD5 отговор

обратно, който ще удостовери че вярната парола е притежавана от него. Първата стъпка е създаване на

низ от символи - hash, съдържащ потребителското име, областта на действие (realm) и парола,

следвайки синтаксиса показан по-долу:

MD5 (Username : Realm : Password)

3. Като втора стъпка, потребителският агент създава втори MD5 hash, състоящ се от SIP метода, който е

използван в конкретния случай, като REGISTER например, и URI-то, напр. SIP:192.168.2.102, следвайки

синтаксиса по-долу:

MD5 (Method : URI)

4. Като последна стъпка, потребителският агент създава MD5 hash, който бива ползван като последен

отговор. Този низ комбинира първият MD5 hash в стъпка 3, „nonce‖ пратен от сървъра в 401/407 съобщението, броят на изпратените nonce (ако е необходимо да бъде пратен такъв), cnonce (ако трябва

да бъде върнат като отговор), както и втория MD5 hash от стъпка 4, както следва:

MD5 (MD5-step-3 : nonce : nc : cnonce : MD5-step-4)

Полетата nc и cnonce не са задължителни, така че всъщност уравнението би изглеждало така:

MD5 (MD5-step-3 : nonce : MD5-step-4)

5. Клиентът изпраща крайният MD5 низ, създаден в стъпка 5 към сървъра, като стойност на своя отговор.

6. Сървърът, от своя страна, изпълнява същата процедура както потребителя в стъпки 3, 4 и 5 и ако

отговорът на потребителския агент съвпада със стойността на MD5 hash-а получен от него,той може да

потвърди че паролата е вярна и съответно че потребителят е удостоверен.

Основавайки се на тази информация и в съответствие със стъпки от 1 до 6, изчисленият краен отговор от

потребителския агент би трябвало да бъде:

1. MD5 (Ivan:iptelco.bg:HackniMe)

= 49be40838a87b1cb0731e35c41c06e04

2. MD5 (REGISTER:sip:192.168.2.102)

= 92102b6a8c0f764eeb1f97cbe6e67f21

3. MD5

(49be40838a87b1cb0731e35c41c06e04:350c0fec:92102b6a8c0f764eeb1f97cbe6e67f21)

= 717c51dadcad97100d8e36201ff11147 (Крайна стойност за отговора)

Откриване/изброяване на потребителските имена (enumeration)

Изброяването на потребителските имена включва събирането на информация за валидни сметки (акаунти),

регистрирани във VoIP мрежата чрез използване на съобщения за грешка от SIP прокси сървъри и Регистри, или

чрез подслушване на трафика (sniffing). Както при всяко едно друго нападение над сигурността, изтичането на

информация често представлява първите 80% от целия процес. Колкото повече информация е събрана за целта

на нападението, толкова по-вероятно е един атакуващ да успее в своето начинание. Ето защо, откриването на

потребителите често е първата стъпка в процеса на една атака.

Откриване на потребителски имена чрез употребата на съобщения за грешка

При SIP, имената могат да бъдат изброени чрез съобщения за грешка, изпратени от Прокси сървъра или

Регистъра. Ако един UA изпраща REGISTER или INVITE заявка, включвайки валидно потребителско име,

сървърът връща обратно отговор 401, в противен случай връщаното съобщение е 403. Атакуващият може просто да приложи процес на брут-форс (brute-force, груба сила), изпращайки стотици REGISTER пакети с различни

стойности за потребителско име. Зад всяко запитване, на което се получава отговор със стойност 401, той ще

знае че стои валидно потребителско име.


10

Откриване на SIP потребителски имена чрез подслушване на мрежата (sniffing)

Когато се изисква удостоверяване между UA и SIP сървър, клиентът изпраща URI към сървъра. То преминава по

мрежата в чист текстов вид, освен ако не се ползва някакъв вид криптировка на транспорта, като TLS например.

Следователно, URI от типа на SIP:User@hostname:port просто може да бъде подслушано от нападател по

мрежата. Използването на потребителски имена в прост текстов вид (cleartext) оказва повече натиск върху

сигурността на клиентската парола, защото потребителското име се раздава свободно и след като е прихванато

може директно да се приложи атака от типа brute-force. Освен това, тъй като в предприятията и учрежденията

често се използват потребителски имена или вътрешни номера като пароли, ако хакер може лесно да се добере

до потребителско име или номер, потребителския агент също така лесно може да бъде компрометиран.

Фигурата долу показва пример на „подслушано‖ потребителско име по мрежата, с помощта на Wireshark.

Фигура 4.1-2. SIP потребителско име в Wireshark

Извличане на SIP пароли

След като вече разгледах колко лесно е да се открие потребителско име на SIP UА, нека разгледам и процеса за

добиване на паролата. Удостоверяващият процес при SIP ползва дайджест метод и този модел подсигурява, че

паролата не се изпраща по мрежата в прост текстов вид; и все пак този модел не ни имунизира срещу офлайн

речникова атака например.

SIP потребителският агент използва следните уравнения за създаването на MD5 стойност като отговор, ползвана

за удостоверяване на крайната точка в сървър (позициите в курсив пътуват по мрежата в просто текстов

формат). Речниковата атака се състои от изпробване на речник от думи срещу даден хеш алгоритъм до

извеждане на правилната парола. Офлайн версията на речниковата атаката се осъществява от система която не е

задължително свързана с мрежата, като например лаптопа на нападателя:

MD5_1 = MD5 (Username:Realm:Password)

MD5_2 = MD5 (Method:URI)

Response MD5 Value = MD5 (MD5_1:Nonce:MD5_2)

С цел да се изпълни офлайн речникова атака е необходимо първо да се подслуша потребителското име, зоната

му на действие (realm), URI, nonce (идващо от сървъра), както и MD5 хеш-а пратен като отговор по мрежата

(чрез ползване на атака от тип човек-по-средата „MITM‖ в цялата подмрежа), като всяка стойност е на

разположение в прост текстов вид. След като е събрана изброената информация, атакуващият избира списък с

пароли и замества всяка една в по-горното уравнение, наред с всички останали елементи, които са били

прихванати. Когато бъдат изпълнение тези условия, нападателят вече ще притежава цялата информация

необходима за извършване на офлайн речникова атака. Нещо повече, тъй като SIP потребителските агенти често ползват прости пароли, като четири цифрения вътрешен номер на абоната например, времето необходимо за

завършване на атаката може да бъде сведено до минимално.

Събиране на информация с цел атака над SIP автентификация

Информацията, необходима за изпълнение на офлайн речникова атака, достъпна до пасивен нападател, може да

бъде получена от точно два пакета по мрежата – заявката за изпращане на парола от SIP сървъра и пакета-

отговор, пратен от потребителския агент. Първият, изпратен от SIP сървъра съдържа запитването и зоната на

действие в чист текстов формат. Пакетът от потребителския агент съдържа потребителското име, метод и URI

също в прост текстов вид.

След като нападателят е подслушал и взел всички необходими стойности за получаване на паролата, той започва

изпробване на дума от речника, чрез комбинирането й с познатото вече потребителско име и realm, за създаване

на MD5 хеш стойност. След това се взима ползвания метод и откраднатото URI, за създаване на втората MD5 стойност. След като са генерирани първите два хеш-а, вниманието се концентрира върху първият MD5,

стойността на „nonce‖ и втората стойност за MD5 с цел създаване на крайната MD5 стойност, която ще бъде

ползвана за отговор. Ако полученият хеш съвпада с този който вече имаме от оригиналният клиент, означава че


11

брут-форс атаката е успяла, а ако е различен процесът бива повторен чрез използване на следващата дума от

речника.

Пример

Нека приложа съответен пример в подкрепа на горните твърдения. Да предположим че притежаваме

откраднатият от мрежата пакет, необходим за започване на атаката. От този пакет може да бъде извлечена

следната информация:

Challenge (nonce): 350c0fec

Realm: iptеlco.bg

От втория пакет-отговор, може да се извлече следното:

Username: Ivan

Method: REGISTER

URI: SIP:192.168.2.102

MD5 Response Hash Value: 717c51dadcad97100d8e36201ff11147

Ползвайки уравнението за дайджест автентификация, споменато по-рано, калкулациите ни биха изглеждали по

следния начин (с удебелен шрифт са стойностите, взети по мрежата):

Setup Equation 1 MD5-1: MD5 (Ivan:iptеlco.bg:Password)

Setup Equation 2 MD5-2: MD5 (REGISTER:sip:192.168.2.102)

Final Equation 3 717c51dadcad97100d8e36201ff11147: (MD5-1:350c0fec

:MD5-2)

Уравнение 1 е неизвестно, тъй като паролата не се изпраща по мрежата в прост текстов вид. Уравнение 2 е

напълно известно, тъй като метода и URI са в текстов формат. MD5 хеш стойността от второто уравнение е

92102b6a8c0f764eeb1f97cbe6e67f21.

Уравнение 3 е комбинацията от MD5 хеш стойността на у-е 1, стойността на nonce от SIP сървъра и MD5 хеш

стойността от у-е 2. Тъй като притежаваме nonce от мрежата, MD5 хеш-а в у-е 2 може да бъде генериран,

единствената неизвестна в случая е стойността на MD5 хеш-а от у-е 1 и тя се подлага на brute-force.

За осъществяване на речниковата атака, следните две процедури трябва да бъдат изпълнени, първата от която

изисква нападателят да вземе у-е 1 и да вкара думи от речника, в полето за парола:

MD5-1 : MD5 (Ivan:iptelco.bg:Password )

f3ef32953eb0a515ee00916978a04eac : MD5 (Ivan:iptelco.bg:Hello )

44032ae134b07cee2e519f6518532bea : MD5 (Ivan:iptelco.bg:My )

08e07c4feffe79e208a68315e9050fe4 : MD5 (Ivan:iptelco.bg:Voice )

b7e9d8301b12a8c30f8cab6ed32bd0b6 : MD5 (Ivan:iptelco.bg:Is )

44032ae134b07cee2e519f6518532bea : MD5 (Ivan:iptelco.bg:My )

56a88ae72cff2c503841006d63a5ee98 : MD5 (Ivan:iptelco.bg:Passport )

7b925e7f71e32e0e8301898da182c944 : MD5 (Ivan:iptelco.bg:Verify )

a5d8761336f52fc74922753989f579c4 : MD5 (Ivan:iptelco.bg:Me )

49be40838a87b1cb0731e35c41c06e04 : MD5 (Ivan:iptelco.bg:HackniMe )

Въз основа на тези MD5 хеш стойности от уравнение 1, MD5 хеш от у-е 2

(92102b6a8c0f764eeb1f97cbe6e67f21), както и временната (nonce) стойност от уравнението 3

(350c0fec), нападателя вече може да изпълни втората процедура, която подлага на brute-force у-е 3 показано

по-рано. Поставят се различни стойности на MD5_1, генерирани от всяка уникална парола, но се запазват

стойностите на MD5_2 и nonce:

MD5 = (MD5-1:72fbe97f:MD5-2)

bba91fc34976257bb5aa47aeca831e8e =

(f3ef32953eb0a515ee00916978a04eac:350c0fec:92102b6a8c0f764eeb1f97cbe6e67f21)

01d0e5f7c084cbf9e028758280ffc587 =

(44032ae134b07cee2e519f6518532bea:350c0fec:92102b6a8c0f764eeb1f97cbe6e67f21)

5619e7d8716de9c970e4f24301b2d88e =


12

(08e07c4feffe79e208a68315e9050fe4:350c0fec:92102b6a8c0f764eeb1f97cbe6e67f21)

8672c6c38c335ef8c80e7ae45b5122f8 =

(b7e9d8301b12a8c30f8cab6ed32bd0b6:350c0fec:92102b6a8c0f764eeb1f97cbe6e67f21)

01d0e5f7c084cbf9e028758280ffc587 =

(44032ae134b07cee2e519f6518532bea:350c0fec:92102b6a8c0f764eeb1f97cbe6e67f21)

913408579b0beb3b6a70e7cc2b8688f9 =

(56a88ae72cff2c503841006d63a5ee98:350c0fec:92102b6a8c0f764eeb1f97cbe6e67f21)

b8178e3e6643f9ff7fc8db2027524494 =

(7b925e7f71e32e0e8301898da182c944:350c0fec:92102b6a8c0f764eeb1f97cbe6e67f21)

c4ee4ed95758d5e6f6603c26665f4632 =

(a5d8761336f52fc74922753989f579c4:350c0fec:92102b6a8c0f764eeb1f97cbe6e67f21)

717c51dadcad97100d8e36201ff11147 =

(49be40838a87b1cb0731e35c41c06e04:350c0fec:92102b6a8c0f764eeb1f97cbe6e67f21)

Последният опит в примера горе калкулира MD5 стойност 717c51dadcad97100d8e36201ff11147, която

отговаря на взетата по мрежата. Това автоматически означава, че думата от речника HackniMe отговаря на

паролата.

Отказ от услуга чрез BYE съобщение

Подобно на H.323 и IAX сигнализацията, SIP протоколът е също много уязвим откъм атаки от тип Отказ от

Услуга (DoS). Първата DoS атака която ще разгледам, е прост spoofing чрез съобщение BYE от един

потребителски агент към друг такъв. Подобно съобщение се изпраща от един потребител до друг, за да се

посочи че потребителят желае да прекрати разговора и по този начин края на сесията. При нормални

обстоятелства, потребителският агент ще изпрати съобщението след като разговорът е приключил. Въпреки

това, нападател може да прекрати даден разговор като „подметне― подобна команда докато разговорът все още е

в хода си.

Преди да се осъществи тази атака, атакуващата страна трябва да събере няколко елемента от вече

съществуващия разговор (като INVITE съобщение или подобно), и по-конкретно стойностите на Caller-ID и

съответните маркери (tag). След като нападателя е прихванал споменатите обекти по мрежата, той е способен

да създаде собствено съобщение BYE, подправяйки полето From с адреса на едната страна участваща в

разговора и прибавяйки в To адреса на жертвата. Когато полетата From, To, Caller-ID и стойностите на tag

(маркерите) са правилни за съответния разговор, атакуващата страна може да изпрати пакет и разговорът ще

бъде незабавно прекратен (всички стойности на горепосочените параметри се изпращат в прост текстов вид по

мрежата).

SIP Прокси сървърът отговаря със съобщение „200 OK“ към потребителят, показвайки по този начин че spoof

съобщението BYE е обработено успешно и разговорът е прекъснат. Лог-ът от разговора е показан по-долу:

SIP/2.0 200 OK

Via: SIP/2.0/TCP

192.168.5.122; branch=;received=192.168.5.122

From: "iSEC" <sip:[email protected]>;tag=ff761a48

To: "iSEC" <sip:[email protected]>;tag=as3a9bd758

Call-ID: 845b1f52dd197838MThmMDVhZWRkYZIxMmI1MjNiNDA4MThmYTJiODdiMzM

CSeq: 2 BYE

User-Agent: Asterisk PBX

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY

Content-Length: 0

Подобна атака от тип Отказ от Услуга (DoS) може да се осъществи по метода SIP CANCEL, използвайки същите

стъпки като показаните по-горе. Вместо прекратяване на повикване което е в ход, което е възможно чрез BYE

съобщение, метода CANCEL може да бъде ползван за изпълнение на SIP DoS атака върху SIP потребителски

агенти в момент, когато се опитват да започнат разговор помежду си. Следователно, BYE атаката може да се

използва по време на разговор, a CANCEL преди разговорът да е започнал.

Отказ от услуга чрез REGISTER

Подобно на атаката чрез осуетяване на регистрация, един нападател може да осъществи DoS чрез асоцииране на

легитимен потребителски агент към несъществуващ IP адрес. В момента, когато разговорите се пренасочат към

недостъпният IP адрес, няма да има отговор и разговорът би се разпаднал.


13

С цел да изпълни подобен вид атака чрез REGISTER, нападателят може да подаде регистрационна заявка и

промени полето Contact, като добави фалшив или несъществуващ IP адрес. Например, ако нападателят Райна

се опита да проведе DoS атака върху потребителя Соня, тя трябва да промени полето Contact, което

притежава IP адреса 192.168.5.122, с фалшиво напр. 118.118.8.118. В такъв случай Райна би подменила

REGISTER заявката с такава, съдържаща фалшив IP адрес, вместо този на Соня, както е показано на Фигура 4.1-

3.

Фигура 4.1-3. Подправяне на поле Contact в SIP съобщения

Отказ от услуга чрез Un-register

Следващата атака от тип Отказ от Услуга (DoS), която ще разгледам включва де-регистрацията на SIP

потребителски агент. Де-регистрирането дава възможност да се отстрани SIP агент от Прокси или Регистър

сървър. Тъй като де-регистрацията не е стандартизирана в SIP RFC, тази функция на потребителските агенти се

поддържа само от някои устройства.

Проблемът с де-регистрационния метод е, че обикновено не се изисква удостоверяване за премахване на

потребителски агент от Прокси или Регистър. Следователно, ако SIP потребителски агент е легитимно

регистриран, атакуващият може просто да опита премахване регистрацията на потребителя.

С цел де-регистрация на UA, се ползва метода REGISTER, но вместо поставяне на стандартната стойност за

изтичане срока на връзката (обикновено 3600 или 7200), при изпращане на пакета нападателят полага нулева

стойност. Легитимният потребителски агент може да опита пре-регистрация, но нападателят пък от своя страна

може просто да изпрати нов UDP пакет и незабавно да го де-регистрира отново.

Тъй като атаката включва само един UDP пакет, нападателят може да изпълнява процеса веднъж на всеки

няколко минути за неопределен период от време. Този вид атака може да бъде ползвана заедно с атаката чрез

предотвратяване на регистрация, разгледана по-рано.

SIP “Fuzzing”

Това е процеса, когато се подава случайна информация към протокол или приложение, с цел да се причини

грешка в работата му. Ако се получи такъв срив в програмата, могат да се появят проблеми в сигурността на

местата, където се е появила грешката. SIP протоколът може да бъде подложен на „fuzzing―, за да се тества устойчивостта на SIP изпълнението на даден производител. Например, ако протоколът не е в състояние да се

защити срещу обичайните fuzzing техники, може да бъде засегната наличността на VoIP мрежата.

Проектът PROTOS (http://www.ee.oulu.fi/research/ouspg/protos/testing/c07/sip/index.html/) притежава fuzzing

инструмент, който може да бъде ползван за тестване на VoIP мрежа под SIP:

Както е показано на Фигура 4.1-4, програмата ще тества всички случаи един по един. Ако възникне грешка в SIP

сървъра, тя може да открие евентуален проблем в сигурността, свързан с нея. Това не е нито бърз, нито лесен

начин за откриване на пропуски в сигурността, но е първата стъпка от цяла поредица, които е нужно да бъдат

предприети.

http://www.ee.oulu.fi/research/ouspg/protos/testing/c07/sip/index.html/#_blank


14

Фигура 4.1-4. Пример за Fuzzing

SIP заливане със съобщения (flooding)

Една от най-добре познатите DoS атаки във VoIP е унищожаването на ресурси чрез заливане/засипване със

съобщения. Атакуващата страна генерира хиляди от тях и ги изпраща по мрежата към устройство или услуга -

мишени, за да ги превърне в неработещи.

Атаката може да причини безкрайно звънене на отсрещният телефон и по този начин да блокира телефонната

комуникация. Като допълнение, SIP проксито заделя ресурс за поддръжка на всички заявки INVITE, които е

получило и е препратило към дестинацията. Подобна техника може да бъде ползвана при SPIТ атаките.

Производителността на една система е важен фактор при flooding атаките. Когато се подсигурява системата

срещу подобен род атаки, тя се изпробва срещу генератори на натоварване и тестери за производителност.

Координираната DoS атака (DDoS) е частен случай на засипването с пакети. VoIP мрежите могат да бъдат както

източник, така и мишена на DDoS атаки. При тях голямо количество хостове биват компрометирани и

контролирани от нападател и биват ползвани за стартиране на концентрирана атака срещу дадена услуга.

Обикновено такива програми за атака са интегрирани с вируси и червеи, с цел заразяване на неподозиращи

жертви като по този начин ги присъединяват към атаката. Такава мрежа от компрометирани хостове често пъти

се нарича BOTNET, тъй като се състои от автономни софтуерни роботи, или „бот―-ове. Примерна атака във VoIP

би включвала това всички телефони да се опитват да наберат една и съща мишена едновременно.

SIP атака „сигнализационен капан“ (signaling loop)

В близко бъдеще се очаква да се появят нови видове DoS атаки, чиято цел ще бъде сигнализационните

съобщения във VoIP инфраструктурата да развалят или прекъснат дадена услуга. Пример за подобна атака,

която може да има катастрофален ефект върху една VoIP мрежа е проблемът с Максималния-Брой-Препращания

(Max-Forwards), който е бил открит по време на конференция относно SIP преди време. Атаката изисква

необходимото условие да бъде създаден чифт от еднакви акаунти в два различни Прокси/Регистър сървъра,

които не следят за появата на цикъл (loop). Фигура 4.1-5 описва двете стъпки при атаката.

http://tools.ietf.org/html/draft-lawrence-maxforward-problems-00

http://tools.ietf.org/html/draft-lawrence-maxforward-problems-00#_blank


15

Фигура 4.1-5. SIP DoS атака signaling loop

Като първа стъпка, потребителят се регистрира в двата домейна едновременно, one.com и two.com, ползвайки

двата акаунта user1 и user2. Нужно е да се отбележи, че по време на всяка регистрация, контактният header

притежава две стойности, едната сочеща към първия акаунт и другата към втория акаунт, в един и същ домейн.

Това биват легитимни регистрационни заявки, които се обработват успешно от съответните SIP

Прокси/Регистър. При стъпка 2, единият Прокси/Регистър получава INVITE заявка (в разгледания случай

one.com), който на свой ред разклонява и изпраща две INVITE заявки към домейна two.com, за потребители

user1 и user2. В момента, когато тези INVITE заявки са получени от SIP Прокси/Регистъра в домейн two.com,

четири такива заявки биват разклонени към Прокси/Регистъра в домейн one.com. Когато тези заявки се получат

в one.com, осем ще бъдат клонирани и така докато Max-Forwards header-а се занули. RFC 3261 дефинира, че

стойността по подразбиране на Max-Forwards параметъра трябва да бъде 70, което означава че биха били

достигнати 270 броя заявки по мрежата. Допълнително ще бъдат генерирани друг набор от съобщения от сървърите (напр.408, CANCEL). Този вид атака парализира VoIP мрежата за минути, като съществуват няколко

решения, които биха облекчили подобна атака. Едното е да се изключи разклоняванетo или да се намали

стойността на Max-Forwards параметъра, което е приложимо в малки, затворени SIP мрежи, но не е при големи

доставчици, където е съществува и е необходим пиъринг. Друго решение е да се включи функцията за откриване

на подобни цикли (loop detection), което пък може да се отрази върху производителността на прокситата.

SPIT (Spam Over Internet Telephony)

Такава атака е тази, при която група абонати извършват обаждания към някой, който не може да предотврати

приемането им. Вкарването им в черен списък или изключване звука на телефонния апарат в повечето случаи е

подходящо решение, когато броят на обаждащите се е достатъчно малък.

В PSTN съществува СПАМ под формата на нежелани разговори. Повечето от тях идват предимно от теле-

маркетингови компании, макар в България все още да не сме се сблъскали с този проблем. Въпреки това, те са

естествено ограничени, тъй като спам по PSTN е сравнително скъпо удоволствие, особено по отношение на

комуникационния канал. Спам по Интернет телефония (SPIT) представлява провеждането на нежелани


16

разговори през VoIP мрежите, и той е по-специална разновидност на добре познатия ни проблем при имейл

услугата. Когато услугата е безплатна или на ниска стойност и когато могат да останат анонимни, хората са

изкушени от изпращането на търговски или политически послания през съответната форма на комуникация.

Проста атака в случая би било създаването на скрипт, който инициира разговори към широк кръг номера или IP

адреси и изпраща записана реч. При имейл версията на спама има простички решения, тъй като цялото

съобщение може да бъде статично анализирано и сравнено с типичните модели и съществуващи черни списъци,

без значително забавяне при изпращането на съобщението. Спам съобщение, което отговаря на съответните

филтри няма да бъде изпратено, докато при SPIT има особен проблем по отношение на механизмите за

превенция, тъй като съдържанието не е известно в момента на позвъняването. Въвеждането на черни и бели

списъци (позволявайки само проверените потребители или домейни) са потенциално решение на проблема. Има предложения от някои анализатори за приложение на ескалиращи на техники на няколко нива. Друго

потенциално решение е преправяне на телефонния секретар, така че всъщност всеки разговор бива поеман от

него и чрез натискане на определен бутон, разговорът се пренасочва. Малко по-сложен скрипт включва гласово

разпознаване на отговор на даден въпрос, например „Моля, кажете кое е обратното на черно?―.

Маркиране на разговорите като високо-приоритетни (тези разговори, които бихте желали да приемете дори по

време на бизнес среща например) са отделна категория в този вид атака. Ако всеки може да определи

обаждането си като спешно, или еквивалента на на най-високия приоритет, контролът върху това кой може да се

обади се губи автоматически. Възможна атака тук е да се промени приоритета на повикването на ниво протокол,

така че разговорът да прескочи определените филтри.

Друга категория SPIT атака е свързана с лошата обработка на броудкаст и мултикаст съобщения. Един от

методит за атака е изпращане на сигнални (INVITE) съобщения по броудкаст. Това ще накара всеки телефон в

броудкаст мрежата да звъни непрекъснато и ако източника на обаждането е всъщност подправен номер, резултатът би бил че всеки от прозвъняните номера биха върнали обаждането върху мишената. Освен SIP

INVITE съобщение, могат да се ползват множество други по описания начин.

Друго подобно броудкаст базирано нападение, този път в частта на медията, е изпращането на развалени,

невалидни медийни (RTP) съобщения до броудкаст адрес, вкарвайки ги в потоците на медията на водените

разговори, създавайки шум или DoS в легитимните разговори. Понякога номерирането на последователността,

различните кодеци, и неверните адреси на източника/порт, защитават срещу този вид атака, но за съжаление

повечето реализации на VoIP ги игнорират или ползват стойности лесни за отгатване.

Неоторизиран достъп

Неоторизираният достъп е една от традиционните атаки, свързани с физическата и логическа сигурност. Трите

основни метода за получаване на неоторизиран достъп са както следва:

Имперсонализация

Атаки от тип човек-по-средата

Пълно компрометиране

Имперсонализиращите атаки включват открадване или отгатване на оторизационните ключове, като

комбинацията потребителско име/парола и ползването им от името на даден потребител.

При атаките от тип човек-по-средата, истинският потребител извършва удостоверяването, но нападателят вижда

обмена на съобщения и дори може да превземе активната, след удостоверяване сесия.

При пълното компрометиране атакуващият притежава пълен контрол върху системата и може да стартира

всякакви услуги, команди и процеси от името на потребител. Пример за подобен род нападение е атака от

изпълнена от червей, при която червеят е стартиран в компютъра на жертвата, имперсонализирайки го при

извършване на нови комуникационни сесии.

В контекста на VoIP комуникациите, неоторизираният достъп може да възникне в следните области:

VoIP услугите. Един нападател може да използва уязвимости в сигнализацията на услугата, за да получи

неоторизиран достъп до VoIP мрежата.

VoIP инфраструктурата. Нападател може да използва уязвимостта да получи достъп до VoIP мрежови

елементи.

VoIP мрежови елементи, като например сигнализация и медия шлюзове, софтсуичи, проксита,

регистъри, SBC, DNS, NTP сървъри и др.

VoIP крайни устройства.

Поддържаща инфраструктура.


17

Мрежови, транспортни елементи като маршрутизатори и суичове.

Управленски и административни системи. Нападател може да получи достъп до управленски или

административни интерфейси и да изпълни задачи чрез прескачане на контроли за достъп или да се

възползва от липсата на такива.

Системи за обезпечаване/оперативна поддръжка.

Злонамерен потребител може да използва уязвимост (или комбинация от такива), за да получи неоторизиран

достъп до услуги, данни, или контролери (привилегировани или непривилегировани) на дадена система или

мрежа и да извършва разнообразни атаки. Лошите контроли на сигурността увеличават вероятността и

въздействието на този вид заплаха.

Броят на необходими компоненти и протоколи, нужни за осигуряване поддръжка на VoIP създават сложна среда, в която възникват няколко възможности за получаване на неоторизиран достъп. Опити за неоторизиран достъп

може да се появят срещу всеки от софтуерните компоненти, които управляват, администрират или поддържат

VoIP инфраструктурата и включват използването на следното:

Настройките на конфигурацията по подразбиране (например, неуспех да се премахнат ненужните

потребителски профили, наръчници, библиотеки, компилатори)

Пароли на акаунти по подразбиране

Неограничен достъп до интерфейси за управление

Неограничен достъп до услуги (напр. TFTP, FTP, Telnet, RPC)

Липсата на адекватни контроли за оторизация (например, файлове и директорийни разрешения,

изпълнение на програми)

Въпреки, че неоторизирания достъп обикновено е свързан с ресурсите на операционната система, той също може да бъде извършван от слоя на приложенията (сигнализацията и медията). Един нападател може да се

опита да получи достъп до VoIP мрежа чрез използване на слаби сигнализационни съобщителни контроли.

Например, хакер може да се опита да проведе разговор през VoIP мрежата чрез използване на слаба

автентификация, ползвана при сигнализационните съобщения. В случай на VoIP измама през 2006 г.,

извършителите са били в състояние да генерират повече от $1 млн. чрез прерутиране на VoIP трафик през

различни доставчици, получавайки неоторизиран достъп до VoIP инфраструктурата и променяйки таблицата на

маршрутите така че да приема измамническия трафик.

Способността за получаване на неоторизиран достъп до мрежови елементи или услуги и приложения, може да

бъде ползвана като лост за други атаки, включително нарушаване на услугата, SPIT, подслушване и измама. При

разработването и внедряването на VoIP мрежи трябва да се обърне внимание на следните контроли, с цел

предотвратяване на неоторизиран достъп.

Приложенски контроли

Регистрация в дадена услуга на потребител и устройство

Удостоверяване и интегритет на сигнализационното съобщение

Удостоверяване и интегритет на медия съобщението

Задължително лог-ване и одит на компоненти, които генерират, обработват, видоизменят или

прекратяват VoIP разговори

Мрежови контроли

Задължителни контроли върху мрежови устройства за достъп, включително проверка на MAC адреси и

802.1x автентификация по порт

Сегментиране на мрежата. Въвеждане на VLAN, за да се изолират различните VoIP компоненти

Задължителни VLAN ACL-и (листи за достъп), с цел да се предотврати оторизирано преминаване на

трафика през VoIP VLAN-ите

Въвеждане инспекция на пълното състояние на сигнализационните и медийни потоци чрез VoIP

защитни стени или SBC.

Управление

Правилното прилагане на контролите за достъп до мрежата върху управленските интерфейси за да се

ограничи достъпа от отдалечени оторизирани източници


18

Задължително правилна оторизация и ролеви-базирани контроли на достъп върху управленските

функции

Задължително лог-ване и одит на потребителски акаунти и процеси, които изпълняват управленски или

административни функции върху VoIP мрежови елементи

Плащания

Задължителни контроли за запазване целостта на платежните записи

Задължителни контроли за запазване конфиденциалността на платежните записи

Задължителни контроли за удостоверяване и оторизация, за да се попречи на неоторизирания достъп до

платежни записи

Задължително лог-ване и одит на потребителски акаунти и процеси които модифицират CDR записи (CDR – Customer Detail Records)

Обезпечение

Задължителни контроли за правилен мрежов достъп, за да се ограничи свързаността от разстояние до

системите за обезпечаване на неоторизирани източници

Задължителни контроли за удостоверяване и оторизация, за да се предотврати неоторизиран достъп до

функционалността на системата за обезпечаване на неоторизирани лица

Задължително лог-ване и одит на потребителски акаунти и процеси, които стартират, модифицират или

изтриват поръчки на услуги

Този уводен списък от контроли осигурява основата за засилване на сигурността на една VoIP мрежа в

критичните области, в които може да се появи неоторизиран достъп. По-късно ще разгледам по-подробно

мрежовите контроли за сигурност, както и механизмите за защита, които могат да бъдат предприети, за

предотвратяване на неоторизиран достъп до мрежови елементи, услуги и приложения, и свързаните с тях данни.

Важно е да се разбере, че неоторизирания достъп може да възникне в слоя на приложенията (VoIP услугите)

чрез манипулиране или spoofing на сигнализационни и медия съобщения, в транспорта и мрежовите слоеве,

чрез манипулиране на пакети или на ниво операционна система, чрез възползване от софтуерна уязвимост или

конфигурация по подразбиране.

SIP речникова атака при автентификация

Един от методите за придобиване на неоторизиран достъп до VoIP услуга е чрез отгатване пълномощията на

абонат чрез brute-force или речникова атака. Във VoIP приложения, които ползват SIP, за отгатване на пароли

може да бъде ползвана REGISTER заявка. Такава атака изпраща множество заявки REGISTER, ползвайки

комбинация от потребителски имена и пароли от речников файл. Когато атакуващата страна идентифицира

паролата, тя може да се регистрира като съответния потребител и да се отнеме регистрацията от истинския

такъв. Нужно е да отбележим, че традиционно най-добрите практики за сигурност препоръчват заключване на акаунта или време за изчакване/пауза, за да се предотврати удостоверяване чрез груба-сила (brute-force) или

речникова атака. Това може да не е осъществимо при VoIP, защото абонатите няма да могат да провеждат

телефонни разговори. Един от подходите може да бъде да се забави процеса на удостоверяване между

потребителя и SIP Регистъра. Например, ако първото искане за влизане в системата се провали, SIP Регистъра

трябва да изчака две минути, преди да отговори на следващото, а ако второто искане не успее, трябва да се

изчака четири минути, след това 16 и т.н. Възможно е и уведомяване на реалният потребител по имейл, SMS и

други канали.

Атака от тип човек-по-средата (MITM)

В допълнение към офлайн речниковата атака, SIP също е уязвим към атака от типа човек-по-средата, както е

показано на Фигура 4.1-6. Тази атака ползва „заразяване‖ на ARP кеш таблицата или DNS spoofing техники, с

цел да позволи на атакуващия да се вмъкне между SIP сървъра и легитимния SIP потребителски агент. След като

нападателят маршрутизира трафик между двете легитимни лица, той може да изпълни атака от тип човек-по-средата и да се удостовери в SIP сървъра, без да знае валидно потребителско име и парола.

По време на този вид атака, нападателят извършва мониторинг, следене на мрежата, за да идентифицира кога

SIP потребителските агенти изпращат заявки за удостоверяване към SIP сървъра. Когато постъпи искането за

такова удостоверяване, той пресреща пакетите и по този начин им пречи да достигнат реалния сървър (стъпка

1), след това изпраща своя собствена заявка за автентификация към SIP сървъра (втора стъпка),

ползвайки за удостоверяване метода на запитване/отговор, SIP сървъра изпраща „nonce‖ към атакуващата страна

(стъпка 3). Атакуващият го получава и след това го препраща към легитимния потребителски агент, опитващ се


19

първоначално да бъде удостоверен (стъпка 4). След това, легитимният агент праща на нападателя валидна

стойност на MD5 хеш, която е генерирал от истинската парола и пратеното от сървъра „nonce‖ (стъпка 5),

мислейки че атакуващият е реалния сървър. След като нападателят вече притежава валидния MD5 низ, той го

изпраща на свой ред към SIP сървъра и успешно се автентифицира (стъпка 6).

Фигура 4.1-6. Атака от тип MITM при SIP удостоверяване

Подслушване

Защитата и поверителността са ключови аспекти на сигурността, а в някои случаи са основни нейни цели при

изграждането на VoIP мрежите. Защитата на мрежата в някои приложения може да бъде продиктувана от

законодателството; телекомуникациите традиционно имат строги изисквания за защита на личната тайна.

Шифроването е един от фундаменталните компоненти при осигуряването на поверителност и защита на

личните данни в мултимедийните съобщения, включвайки в това число и VoIP, заедно с процеса по договаряне

на ключове.

Изхождайки от нашите основни цели, подслушването би включвало следното:

Трафик анализ (в слоя на връзката, мрежата и транспорта)

Подслушване на сигнализацията

Подслушване на медията

Анализ на трафика (в слоя на връзката, мрежата и транспорта) е възможен винаги, дори без наличието на криптиране. Той може да разкрие информация относно моделите на потребителските обаждания, поведение и

навици, което помага за профилиране на мишената. Като допълнение, ако за криптиране се ползва главен ключ

(master), той може да бъде ползван от анализатора на трафика за отключване на записите и виждане

съдържанието на криптираната комуникация. Преглеждайки VoIP пакет с помощта на анализатор на мрежи,

може да се види целия многослоен стек на протокола, заедно с техническата информация свързана с

комуникацията.

Подслушване на комуникацията може да стане по няколко различни начина. Един хакер може да се възползва от

уязвимостта, която съществува в протоколите или софтуерните реализации на различни VoIP компоненти, за да

проникне в комуникацията между страните в разговора. Въз основа на исторически данни от атаки на IP-

базирани мрежи, съдим че е възможно да се улови комуникацията (сигнализация и медия) между потребители,

които пребивават в PSTN и съответно в IP-базирани мрежи. При подобни сценарии, хакер с достъп до IP мрежа (т.е. корпоративната мрежа) притежава възможността да осъщяствява мониторинг и да прихване

сигнализационни и медийни съобщения между две неподозиращи това страни. Подобна атака е по-лесно да се

изпълни в IP-базирани мрежи, поради лекотата на достъп. Някой може да каже, че суич-базираните IP мрежи

предотвратяват подслушване още в IP слоя, като не броудкаст-ват всички рамки до всеки по мрежовия сегмент.

Това е вярно, само ако атака като ARP заразяване (poisoning) не е преминала успешно или мрежов елемент не е

бил компрометиран чрез инсталиране на снифър по мрежата.

Подслушване с Wireshark

Wireshark (по-ранните версии са познати като Ethereal) е добре известен безплатен анализатор на трафик и

притежава множество мощни функции, включвайки анализ на пакетните потоци на SIP, H.323 и RTP. Когато

трафика е вече прихванат, програмата предлага възможността да филтрира и избира автоматично VoIP

разговори.


20

Фигура 4.1-7. Прихващане на мрежов трафик с помощта на Wireshark

Падащото меню на статистиките осигурява възможност за филтриране на трафика, свързан с Voice over IP.

Софтуерът анализира прихванатия трафик и показва наличните VoIP разговори, а когато потоците са вече

сглобени, потребителят може да избере кой точно да декодира от тях, маркирайки го в списъка. След като е

готов с избора, потребителят може да натисне бутона Player, за да продължи с повторното сглабяне и декодиране. Накрая, потребителят може да преслуша аудио записа от RTP потоците - поотделно или в

комбинация (напр. халф-дуплекс или пълен дуплекс).

Подслушване с Cain & Abel

Друг инструмент, който може да се ползва за улавяне на VoIP трафик е Cain & Abel. Инструментът използва ARP

заразяване (poisoning) за започване на атака от типа човек-по-средата и за прехвърляне на SIP и RTP трафик към

нищо неподозиращите крайни точки .


21

Фигура 4.1-8. Атака чрез заразяване на ARP кеша

ARP заразяване (poisoning), известно също като ARP spoofing се използва и за пренасочване на трафика по

мрежата през хоста на нападателя, така че той да действа като човек-по-средата или да се предизвика DoS чрез

отхвърляне на всички Ethernet рамки. Това нападение може да се упражни само между хостовете в LAN. По

време на една атака от типа човек-по-средата, нападателят може да подслуша комуникациите между две или

повече крайни точки и да събере чувствителна информация, като например пълномощия на акаунти

(потребителски идентификатори и пароли) и потоци медия (напр. глас и видео трафик).

Протоколът за адресна резолюция (ARP) се използва за асоциацииране на MAC адреса на хоста с даден IP

адрес. ARP spoofing атаката работи на принципа на подмяна на подобна асоциация между MAC и IP адрес,

който е бил кеширан от ARP таблицата на хоста (ARP кеш). Например, ако един нападател иска да прихване

трафик между хостове 192.168.1.2 и 192.168.1.5, той ще изпрати ARP броудкаст към LAN мрежата, уведомявайки (advertising) по този начин че новият MAC адрес на 192.168.1.5 е 00:0B: 95:09:68:05 . Нищо

неподозиращият хост кешира тази асоциация и го използва за да предаване на Ethernet рамките в бъдеще време.

Подобни spoofed пакети ще бъдат генерирани и от името на атакуваната жертва (192.168.1.2), с цел да бъде

рутиран през хоста на нападателя (192.168.1.9), така че нападателят ще направи spoof на ARP пакети и за двата

хоста, за да зарази техните кеш таблици и да събере трафик и в двете посоки.

Когато приложението засече VoIP разговор (SIP), то стартира прихващането на трафик. Разговорът може да се

визуализира чрез избиране на опцията VoIP, в долната част на интерфейса. На този етап, може да се маркира

желания разговор, както и да се избере с десен клик падащо меню, което предоставя опцията за прослушване.

За възпроизвеждане се използва инсталираната на компютъра програма по подразбиране.

Подслушване чрез VLAN прескачане (hopping)

В предишният раздел разгледах подслушане чрез атаки от типа човек-по-средата, ползвайки ARP заразяване,

като обикновено тази атака се извършва срещу хостове от една и съща локална мрежа. Този раздел разглежда как се изпълнява ARP заразяване чрез VLAN hopping, и в крайна сметка се осъществява подслушване на

комуникациите между потребители в различни локални мрежи, в мрежа с няколко суича.

Традиционно се е мислело, че ARP заразяването е атака, ефективна само срешу хостове стоящи в един и същ

LAN. В момента съществуват две публично-известни VLAN hopping атаки: измамване на суича (switch spoofing)

и двойно маркиране (double-tagging). Атаките са ефективни, когато мрежовият суич притежава неправилно

конфигуриран трънкинг порт. По време на суича spoofing, нападателят конфигурира неговата система, така че

да рекламира ISL или 802.1q и DTP сигнализация, като по този начин я маскира като суич с трънк порт, който е

член на всички VLAN мишени. При двойното маркиране, изпратените Ethernet рамки носят маркер с два 802.1q

хедъра. Когато мрежовият суич получи рамката, той отстранява първия маркер и я препраща с оставащия втори

маркер до всички суич и трънк портове. Ето защо рамката може да се размножава от междинни суичове,

основавайки се на VLAN ID-то, което е показано в останалия 802.1q хедър. Двойното маркиране работи дори, когато порт трънкинга е изключен.

С цел защита на VoIP комуникациите от атаки, прилагащи тази слабост на системата, биха могли да се подсилят

защитните механизми на сигнализационните и медийни потоци, описани по-рано. Допълнителна защита срещу


22

VLAN hopping би могла да бъде следното:

Спиране на всички неизползвани суич портове.

Спиране на Динамичния Трънкинг Протокол (DTP – Dynamic Trunking Protocol). При опорни суич-до-

суич връзки се конфигурира изрично trunking-а.

Слагане на персонални VLAN идентификатори на всички трънк портове.

Публично достъпен инструмент, който може да бъде ползван за демонстрация на VLAN прескачане е Yesirnia.

Този инструмент може да осъществява атаки върху няколко протокола, които се ползват от суичове за мрежово

управление, вкл. DTP, STP (Spanning Tree Protocol), VTP (VLAN Trunking Protocol), ISL (Inter-switch Link

Protocol), 802.1x, 802.1q, HSRP (Hot Standby Router Protocol), DHCP (Dynamic Host Configuration Protocol) и CDP

(Cisco Discovery Protocol).

Подслушване в реално време чрез манипулация на MGCP

В много от корпоративните и VoIP мрежите на доставчиците, MGCP протоколът обикновено се използва между

повикващия агент (или call manager в Cisco терминологията) за създаване, променяне и прекратяване на

повиквания-макар и в някои приложения да се използва между крайните устройства и сигнализационния или

медиен шлюз (напр. АТА – Аналоговите Телефонни Адаптери). Фигура 4.1-9 описва употребата на протокола в

рамките на една корпоративна VoIP мрежа.

Фигура 4.1-9. MGCP интеграция във VoIP мрежите

Други протоколи като SIP, H.323, или Cisco SCCP, „Skinny‖, може да се използват между крайните устройства и

повикващият агент (или „мениджър на повикванията―) за да инициират, редактират както и да прекратяват

сесии. Важно е да се разбере, че ако не се приложат правилните контроли за защита на сигнализационните и

медия шлюзове, един нападател може да манипулира връзки ползвайки MGCP протокола за извършване на

атаки, включително преждевременно прекратяване, отклоняване на разговори и подслушване.

Един хакер може да изпрати MGCP сигнализационни съобщения към PSTN шлюз за да промени състоянието на

съществуващо повикване и да принуди PSTN шлюза да отклони RTP трафика към хоста на нападателя или дори

конферентен разговор без знанието на самите участници, и по същество да извърши подслушане.

По-долу е показана последователността, според която нападател изпраща MGCP сигнализационни съобщения към PSTN шлюз, за да пренасочи RTP трафик към неговия хост. Следните пет съобщения/стъпки се прилагат по

време на атаката:

1. Нападателят изпраща заявка за получаване на списък с всички активни разговори.

2. Шлюзът отговаря със списък на активни връзки (разговори).

3. Атакуващият прави запитване за специфична връзка, с цел да получи съответните детайли за нея.

4. Шлюзът праща информацията в отговор.

5. Атакуващият изпраща модифицираща връзката заявка, за да промени състоянието й, и пренасочи

трафика към своя хост.


23

Фигура 4.1-10. Подслушване в реално време чрез манипулиране на MGCP шлюза

Началната стъпка за осъществяване на тази атака е идентифицирането на съществуващите връзки в PSTN

шлюза. Въпреки че MGCP протокола е текстово базиран, той не е толкова интуитивен както SIP. Следното

съобщение кара MGCP шлюза да изброи всички налични крайни точки:

AUEP 1500 *@mgcp.gateway MGCP 0.1

Съобщението AUEP (Audit End-Point) включва транзакция (1500) и подканва да се направи одит на крайните

точки. В посоченият случай, съобщението ползва астериск (*) като маска за изваждане на всички крайни точки

на разположение в хоста – мишена (mgcp.gateway).

Отговорът от шлюза включва всички крайни точки (портове), които са налични в момента, а където има крайна

точка е много вероятно да съществува и връзка. Долното е актуален списък от шлюз, който изброява 15 налични

крайни точки:

200 1500

Z: S0/SU1/DS1-0/[email protected]















Следващата стъпка по време на атаката е да се „разпита‖ крайната точка и да се определи дали тя поддържа

разговор в момента или в момента е бездействаща (idle). Това се прави чрез следното AUEP съобщение:

AUEP 1000 S0/SU1/DS1-0/[email protected] MGCP 0.1

F: R,D,S,X,N,I,T,O,ES

В това съобщение крайната точка е посочена като S0/SU1/DS1-0/1, и хедъра F: идентифицира заявената

информация, която трябва да бъде върната:

200 1000

I: 2EDA

N: [email protected]:2427

X: 1

R: D/[0-9ABCD*#](N)

S:

O:

T:

ES:

Отговорът съдържа идентификатора ID I: 2EDA, който е нужен да се интегрира специфичната връзка и

идентифицира хоста, асоцииран с разговора към който MGCP изпраща RTP трафик.


24

Съобщението AUXC (Audit Connection) се изпраща до шлюза, за да се одитира определена връзка (в този случай

S0/SU1/DS1-0/[email protected]) с идентификатор за връзка 2EDA и идентифицира каква допълнителна

информация да бъде използвана за завършване на задачата. Полученият отговор от MGCP шлюза представлява

следното:

200 1

C: D000000002000594000000F50000001d

N: [email protected]:2427

L: p:20, a:PCMU, s:off, t:b8

M: sendrecv

P: PS=9817, OS=1570720, PR=9817, OR=1570720, PL=0, JI=60, LA=0

v=0

c=IN IP4 10.6.255.25

m=audio 18688 RTP/AVP 0 100

a=rtpmap:100 X-NSE/8000

a=fmtp:100 192-194

Отговорът съдържа доста ценна информация, като агентът на разговори (CA - Call Agent), с който шлюзът

комуникира ([email protected]:2427), показвайки в N: ―Notified entity - уведомения обект― и режима в M: ―изпраща

или получава― (sendrecv). SDP частта от съобщението съдържа IP адреса на телефона (10.6.255.25) и порта

(18688) към който бива изпращан RTP трафика. Това позволява на един нападател да извършва мониторинг

върху моделите от разговорите на даден потребител, след като автоматизира споменатите стъпки като част от

процеса. Фигура 4.1-11 изобразява този метод.

Фигура 4.1-11. Препредаване на RTP трафик през хоста на нападателя

Следващата стъпка е да се модифицира съществуващата връзка чрез изпращане на MDCX (Modify Connection)

съобщение до гейта. Прихващащата MDCX заявка представлява следното съобщение:

MDCX 1553 S0/SU1/DS1-0/[email protected] MGCP 0.1

C: D000000002003e0e000000F580001f6d

I: 2EDA

X: 16

L: p:20, a:PCMU, s:off, t:b8

M: sendrecv

R: D/[0-9ABCD*#]

Q: process, loop

v=0

o=- 1334 0 IN EPN S0/SU1/DS1-0/[email protected] s=Cisco SDP 0

t=0 0

m=audio 17994 RTP/AVP 0

c=IN IP4 10.6.158.178

Тази заявка инструктира MGCP шлюза да промени съществуващата връзка в съответния канал (S0/SU1/DS1-0/1)

и да започне да изпраща RTP пакети към хоста на нападателя на адрес 10.6.158.178 и порт 17794. Когато MGCP

шлюза изпълнява тази модификация, участващите страни губят входящите или изходящите потоци. Така че,

нападателят трябва да идентифицира и модифицира както входящите така и изходящите RTP потоци преди

изпълняване на атаката, за да подслуша разговора без да се появи съмнение. В случай, когато хакер проникне в

конферентен мост, той може да наруши RTP потока на някой участник, но да е в състояние да слуша останалата

част от страните. Участникът, който е бил прекъснат може да се включи отново в конференцията, веднага след

като осъзнае, че е "отпаднал".

В този случай, нападателя инструктира MGCP гейта да започне пренасочване на RTP трафика към своя хост, и

mailto:S0/SU1/DS1-0/[email protected]


25

на свой ред препраща трафика към телефона на нищо неподозиращия потребител. За да се пренасочи RTP

трафика към легитимния потребителски телефон, той може да използва инструмент като RAT (Robust Audio

Tool), който позволява приемане и предаване на RTP потоци. Чрез ползване на RAT, нападателят може да

създаде порт за приемане на RTP поток и да препрати трафика към отдалечен адрес и порт (в разглеждания

случай – жертва). Атаката е независима от операционната система или RTP инструментите за пренасочване,

които се ползват, тъй като в случая е нужна манипулация на сигнализацията на MGCP шлюза за пренасочване на

RTP потоците. Могат да бъдат ползвани и други инструменти, с възможности за получаване и препращане на

RTP пакети.

Маскиране (masquerading)

Тук ще разгледаме маскирането и опишем техниките, които могат да бъдат приложени на множество нива от протоколния стек. Маскарадните атаки са познати още от древни времена, типичен пример е Троянската война,

която е била спечелена благодарение на агент – Троянския кон. В частност, гръцката армия ползва устройство за

маскиране на проникването си в Троя.

Частен случай на маскарадинга е имперсонализацията на абоната, като при него един хакер маскира своята

самоличност чрез използване на вече прихванати пълномощия или получен достъп до устройство, свързано с

абоната. Друг пример е, когато нападателят притежава логически контрол върху устройството като се възползва

от уязвимост, която му позволява да получи неоторизиран достъп от разстояние и да генерира различни атаки

(инжектиране на съобщения в мрежата или сондира за други уязвимости). При всички сценарии нападателят

замаскира истинската си идентичност, като използва различни методи. В този пример се ползва SIP протокол, с

цел да се докаже това нападение. Нападението не е специфично от страна на ползвания протокол и може да бъде

извършено в мрежи, които ползват други сигнализационни протоколи, като H.323 например.

Нападателят може да имперсонализира устройство като телефон, сигнализационен шлюз, медиен шлюз, DNS сървър, SIP регистър, PSAP или softswitch, да играе роля на компонент или мрежа, в зависимост от това кой

компонент е имперсонализиран и да извърши нападения, които имат за цел да съберат и манипулират трафик.

Например, даден хакер може да се представи за DNS сървър, който осигурява транслацията на SIP URL-и и

пренасочи входящи повиквания към желания хост, т.е. към нападателя.

Въпреки че могат да се ползват традиционни методи, за извършване на една маскарадна атака (което означава

MAC адрес или IP клониране и spoofing на IP пакети), методите свързани с VoIP се стремят да манипулират

сигнализационните съобщения за извършване на дадено нападение. В този случай, нападателят има достъп до

VoIP мрежата и притежава познанието и способността да моделира сигнализационните съобщения, с помощта

на които се представя за потребител или устройство.

Подправяне на телефонната номерация (caller id spoofing)

Манипулиране на телефонната номерация във VoIP може да бъде извършено чрез променяне на съобщенията в ползвания сигнализационен протокол (напр. SIP INVITE). В специализираната литература са дискутирани

различни методи, включително манипулация на VoIP гейта (напр. Asterisk PBX) или ръчно създаване на измамна

INVITE заявка, ползвайки инструмент като SIVuS. Макар че, има няколко начина за конфигурация на Asterisk

PBX така че да ползва фалшив CID, най-лесният начин е ползването на командата SetCallerID(2015551212) в

extensions.conf файла, като номера 2015551212 е този, който трябва да бъде фалшифициран. Въпреки че

процедурата е лесна, тя изисква ръчна редакция на промяната, а също така и рестарт на Asterisk за всяко ново

обаждане.

Манипулиране на обаждащото се ID също е осъществимо при връзките на VoIP мрежовите доставчици с

корпоративни клиенти. Обикновено, VoIP доставчиците рутират VoIP трафика от корпоративните клиенти чрез

създаване на конфигурация от тип точка-до-точка или с други думи статична, между гейта на доставчика и този

на клиента (например SBC, SIP прокси, H.323 gatekeeper). При този сценарий, VoIP доставчикът поема целия

VoIP трафик, без да има възможност да провери ID информацията на обаждащият се от корпоративната мрежа - източник. Следователно, един злонамерен потребител, който пребивава в корпоративната мрежа може да

манипулира ID информацията на обаждането през мрежата на доставчика на услугата.

Атака чрез манипулация на повикващото ID може да бъде стартирана срещу системи, които използват тази ID

информация за идентифициране на потребителите. Например, някои мобилни телефонни компании ползват

обаждащия се ID за удостоверяване на абонатите до гласовите им пощенски кутии. Ако ID-то на обаждането

съвпадне с това на пощенската кутия, системата няма да поиска парола за достъп, защото се предполага, че

повикването е с произход от потребителския клетъчен телефон.

В момента, някои компании предлагат подобна услуга за ползване на произволен ID (напр. SpoofTel, NuFone и

VoicePulse, за актуална информация, моля потърсете в Интернет).

www.spooftel.com/; www.nufone.net/; www.voicepulse.com/features/basic/CallerID.aspx;

http://www.spooftel.com/#_blank

http://www.nufone.net/#_blank

http://www.voicepulse.com/features/basic/CallerID.aspx#_blank


26

“Отвличане“ на регистрация (presence hijacking)

Отвличането на потребителско присъствие може да има неблагоприятни последици в някои сфери, като

например здравеопазването или военните. Следователно, може да се окуражи дефинирането на подходящи

изисквания за сигурност по време на фазата на проектиране на VoIP мрежата и да се планират съответни

контроли за сигурност, както и ответни мерки за свеждане до минимум въздействието от такива атаки.

Пример, демонстриращ механиката на присъственото отвличане е представен в следващите параграфи. Фигура

4.1-12 показва валидно съобщение за регистрация, показващо наличността на потребителя и неговия IP адрес,

за изпращане на входящи заявки (INVITE). Това показва на VoIP мрежата, че потребителското устройство е в

състояние да приема повиквания.

Фигура 4.1-12. SIP Register съобщение

Заявката REGISTER съдържа Contact хедър, който показва IP адреса на потребителското устройство (софтуерен

или хардуерен телефон). Когато едно прокси получава заявка за обработване на входящо повикване (INVITE),

то изпълнява търсене за идентифициране на IP адреса на респективното потребителско устройство и препраща

заявката. В този пример, потребителят с номер 201-853-0102 може да бъде достигнат на IP адрес 192.168.10.5.

Проксито препраща INVITE заявката към това IP, може да се види също че анонсирания порт е 5061, който по

принцип е резервиран за SIPS, и в посочения пример е в разрез с RFC 3261.

За допълнителна информация, посетете

www.vopsecurity.org/Security_Issues_with_SOHO_VoIP_Gateways-052005.pdf

Фигура 4.1-13 изобразява преправена версия на заявката REGISTER, която бива изпратена от нападателя. По

време на тази заявка, всички хедъри и параметри на съобщението остават същите, с изключение на параметрите

в хедъра Contact. Информацията, която е променена в случая е IP адреса (192.168.1.3), който сочи към

устройството на нападателя вместо към реалния IP адрес. Заявката REGISTER бива пратена на SIP Регистъра с

адрес 192.168.1.2. Ползваният инструмент е SIVuS.

http://www.vopsecurity.org/Security_Issues_with_SOHO_VoIP_Gateways-052005.pdf#_blank


27

Фигура 4.1-13. Подправена REGISTER заявка

Отвличащата атака работи както следва:

1. Спиране на легитимната потребителска регистрация. Това може да бъде направено като се изпълнят

следните стъпки:

Изпълняване на DoS атака срещу потребителското устройство, с цел да бъде предотвратена пре-

регистрация.

Де-регистриране на потребителя чрез изпращане на фалшиво (spoof) съобщение за същия потребител,

задавайки стойност 0 за изтичане на връзката в хедъра (Expires: 0). Това показва, че потребителят желае

да прекъсне своето присъствие в съответния регистър.

Генериране на заявки от тип REGISTER в по-кратка времева рамка (напр. всеки 15 секунди), за да се

преодолее заявката за регистрация на легитимния потребител. Обикновено, телефоните са

конфигурирани за опресняване на своята регистрация на всеки 60 секунди.

2. Изпращане на заявка REGISTER с включен IP адреса на нападателя, вместо този на легитимния

потребител.

Фигурата долу демонстрира захождането към атаката. Следните стъпки са налице по време на разгледания

сценарии:

0. DoS атака.

1. Регистрация на потребител.

2. Обаждащ се: стартиране на заявка за започване на сесия.

3. Прокси сървър: търсене на домейна и намиране на пътя.

4. Прокси сървър: търсене на потребителя, сървърът вече получава IP адреса на нападателя.

5. Прокси сървър: свързване с потребителя.

6. Търсената страна отговаря.

7. Проксито препраща отговора на обаждащата се страна. Връзката бива осъществена и медията бива рутирана между двата телефона.


28

Фигура 4.1-14. Пример за „отвличане“ на регистрация

Атаката е възможна поради следните причини:

Изпълняването на този пример налага удостоверяване на съобщенията, с цел да се оспорят заявките за

регистрация (или INVITE съобщенията да контролират произхода на обажданията).

Сигнализационните съобщения се изпращат в чист вид, което позволява на нападателите да ги събират,

модифицират и възпроизвеждат по тяхно желание.

Досегашните версии на SIP не поддържат интегритет на съдържанието на съобщенията и по този начин

атаките чрез модификация и възпроизвеждане не биват откривани автоматично.

За да се защитят срещу тази атака, VoIP системите трябва да заверяват REGISTER заявките и също така да

използват SIPS (SIP по TLS). Един от важните параметри в механизмите за SIP удостоверяване е „nonce‖, който е случаен низ от символи, използван във връзка с потребителското ID, тайната парола, зоната на действие и URI,

за генериране на MD5 дайджест за удостоверяване. Нападателят трябва да знае тайната парола и случайно

генерираното „nonce‖, за успешно удостоверяване в SIP проксито. Ето защо, като се използва SIPS се осигурява

друго ниво на защита от някой, опитващ се да промени съдържанието на сигнализационното съобщение.

В някои реализации на VoIP, тази атака може да бъде успешна, дори ако отдалеченият SIP прокси сървър

изисква удостоверяване на потребителската регистрация, тъй като SIP сървърът не може да провери всяка

заявка, а само първоначалната. В други случаи, SIP сървърът, погрешно, може да използва повторно кеширана

удостоверяваща информация в исканията за REGISTER, и тъй като те се изпращат в прост текстов вид, те могат

да бъдат прихванати, модифицирани и възпроизведени наново (напр. като се използва същото „nonce‖ и по този

начин се генерира същия дайджест). Това нападение може да се стартира срещу корпоративни или частни

потребители. Например домашна мрежа, която използва лошо конфигуриран безжичен достъп без криптиране,

може да бъде компрометирана от нападател, който след това може да пресрещне и подправи искането за регистрация. Нападателят може да изпълни различни видове атаки, включително неправомерни повиквания или

пренасочване на комуникациите. В една корпоративна среда, един хакер може да пренасочи дадени разговори

към неоторизирани лица (например, обаждания от акционери могат да бъдат отклонени към агент, който не е

упълномощен да обработва търговски сделки за тези клиенти). Тази атака може да бъде подтисната чрез

използване на SIPS и автентифициране на SIP заявките и отговорите (което може да включва защита на

интегритета), чрез използване на нови псевдо-случайни стойности във всяко съобщение. Всъщност, употребата

на SIPS и удостоверяването на отговорите може да подтисне много от свързаните с това атаки, включително

подслушване и имперсонализация на съобщение или потребител.

Подправяне на ARP (arp spoofing)

ARP е фундаментален Ethernet протокол. Може би поради тази причина, манипулацията на ARP пакети е мощен

и често срещан механизъм за атака върху VoIP мрежите. Повечето мрежови администратори предполагат, че разполагането на напълно комутируема мрежа на работните места пречи на способността на мрежовите

потребители да подслушват мрежов трафик и потенциално да уловят чувствителна информация, предавана по

мрежата. За съжаление, съществуват няколко техники и инструменти, които позволяват на всеки потребител да

подслуша трафика по комутируемата мрежа, тъй като ARP няма никакво обезпечение за удостоверяване на

заявките и техните отговори. Освен това, тъй като ARP е протокол без възможност за показване на моментното


29

състояние, повечето операционни системи (Solaris е изключение от правилото) актуализират своя кеш при

получаване на ARP отговор, независимо от това дали са изпратили действителна заявка.

Сред тези техники, ARP пренасочване, ARP spoofing, ARP отвличане и ARP заразяване на кеша са методи за

нарушаване нормалната работа на ARP. Споменатите термини често биват смесвани един с друг или обърквани.

Аз считам ARP заразяването на кеша и ARP spoofing-а за процес от един и същ вид. Ползвайки свободно

достъпни инструменти като ettercap, Cain и dsniff, едно лошо IP устройство може да излъже едно нормално

такова чрез изпращане на непоискани ARP отговори към хоста-мишена. Фалшивият ARP отговор съдържа

хардуерния адрес на нормалното устройство и IP адреса на злонамереното устройство. Това заразява ARP кеша

на хоста.

Пример, У-во Х е атакуващият компютър. Когато „А‖ броудкаства ARP запитване за IP адреса на „Б‖, У-во Х (нападателят), отговаря на запитването, твърдейки че IP адреса (10.1.1.2) принадлежи на MAC адреса на У-вото

Х, BA:DB:AD:BA:DB:AD. Предполагаемите пакети, пратени от „А‖ до „Б‖, вместо това ще бъдат изпратени до

У-вото Х. „А‖ погрешно ще счете, че MAC адресът на У-вото Х, отговаря на IP адреса на „Б‖ и ще насочи целия

трафик, предназначен за този IP адрес към MAC адреса на У-во Х. Фактически, У-во Х може да зарази ARP

кеша на „А‖ без да чака ARP запитване, тъй като на всички Windows базирани системи, статичните ARP записи

биват пренаписани при всеки ARP отговор, без да има значение от това дали изобщо е изпратено някакво

запитване.

ARP кешът на „А‖ изглежда така:

Интернет адрес Физически адрес

10.1.1.1 AA:BB:CC:DD:EE:FF int0

10.1.1.2 BA:DB:AD:BA:DB:AD int0

Тези стойности ще останат такива докато не изтече валидността им или докато не се появят нови, които да ги

заместят.

ARP пренасочването може да работи в две посоки, така че натрапник може да се напъха по средата на разговор

между две IP устройства в една комутируема мрежа. Това е може би най-коварната атака, свързана с ARP. Чрез рутиране на пакети към устройствата, които всъщност трябва наистина да ги получат, появата на нападател

(познат като човек по средата – MITM) може спокойно да остане незабелязана за известно време. Нападателят

може също да прерутира пакетите към /dev/null (т.е. до никъде), като това вече превръща атаката в DoS.

ARP кеша на „Б‖:

Интернет адрес Физически адрес

10.1.1.1 BA:DB:AD:BA:DB:AD int0

10.1.1.2 AA:BB:CC:DD:EE:00 int0

Тъй като целият трафик между изпращача и получателя в момента минава през устройството на нападателя, за

него вече е елементарно да подслуша трафика, ползвайки свободни за тази цел инструменти като Wireshark или

tcpdump. Всякa некриптирана информация (включително електронни писма, потребителски имена и пароли,

както и уеб трафик), може да бъдат прегледана и прихваната.

Отново свободно достъпни инструменти като vomit и rtpsniff, както и платени инструменти като VoipCrack,

позволяват прихващането и декодирането на целия VoIP трафик. Записаното съдържание може да включва реч, сигнализация и платежна информация, мултимедия и PIN номера. Чрез тази техника гласовите разговори,

преминаващи по вътрешната IP мрежа могат да бъдат прихванати и записани.

Съществуват няколко разновидности на посочените по-горе техники. Вместо да имитира хост, нападателят може

да емулира шлюз. Това дава възможност на атакуващия да прихване множество пакетни потоци. Въпреки това,

повечето ARP пренасочващи техники разчитат на това да останат невидими. Нападателят, в тези сценарии, се

надява да остане неразкрит от потребителите които са имперсонализирани. Представянето като портал/гейт,

може да доведе до алармиране на потребителите за присъствието на нападателя, поради непредвидени

проблеми в мрежата, тъй като често суичовете реагират по неочакван начин, когато нападателите манипулират

ARP процеси. Една непредвидена (в повечето случаи) последователност от тези атаки, в частност когато

суичовете са много натоварени, е че таблицата на адресиращата-съдържанието памет (CAM – Content-

Addressable Memory) – таблица с ограничен размер записи за търсене на IP адрес по MAC, се оказва нарушена.

Това довежда до препращане на unicast пакети, от страна на суича, до много портове по непредсказуем начин. Това трябва да се има предвид, когато се ползват подобни техники за тестване на производствени мрежи.


30

С цел да се ограничат вредите от ARP манипулация, администраторите трябва да приложат софтуерни

инструменти за следене на MAC адресните карти. Подобен безплатен инструмент е Arpwatch. На мрежово ниво,

MAC/IP адресното картотекиране може да се кодира статично в суича. В новите Cisco Catalyst 6500 суичове е на

лице Динамична ARP инспекция (DAI – Dynamic ARP inspection). DAI е част от функционалността на

Системата за Интегрирана Сигурност на Cisco (CIS) и е предназначена за предотвратяване на няколко spoofing

атаки от втори и трети слой, включително ARP пренасочващи атаки. DAI и CIS са достъпни само на комутатори

Catalyst, ползващи оригиналния режим на работа (Cisco IOS).

Потенциалният риск от декодиране на прихванат VoIP трафик може да бъде елиминиран чрез прилагане на

криптиране. Пример за това е функцията за шифроване на медията при Avaya. При използване на медийна

кодировка, VoIP разговорите между две крайни точки биват шифровани ползвайки AES криптировка. В средите където се изисква изключително ниво на сигурност, организациите трябва да се уверят че медийното

шифроване е включено за всички набори IP кодеци в употреба.

Следват допълнитени примери на прихващане или отвличане на разговор или сигнализация. Този клас заплахи,

въпреки че са по-трудни за изпълнение от DoS, могат да доведат до значителни загуби или промяна на

информацията и като цяло DoS атаките са по-незначителни от тях. Прихващащите и отвличащите атаки от своя

страна, са почти винаги активни атаки свързани с кражба на услуга, информация или пари като крайна цел.

Представяне за Call Manager и пренасочване на всички разговори

Друга вид атака във VoIP е въплъщение в даден мрежов елемент, като например мениджър на разговори. Той

бива разположен между VoIP телефон и гласов шлюз и управлява всички входящи и изходящи повиквания на

мрежата. Мениджърът на разговорите е отговорен за свързването с потребителския VoIP телефон и

разпределянето на ресурсите (гласовите канали) на гласовия шлюз, за поддържане на входящи и изходящи

повиквания. Цялата комуникация между мениджъра на разговори и гласовия шлюз се осъществяват с помощта на MGCP.

Фигура 4.1-15. Конфигурация при мениджър на повиквания и PSTN

Един нападател може да се възползва от "пренасочващия" пакет в MGCP, за да заиграе ролята на мениджър на

повикванията и да инструктира MGCP да маршрутизира входящите повиквания към „лош― такъв мениджър на

повиквания. RFC 3991, "Media Gateway Control Protocol (MGCP) Пренасочване и Нулиране на пакет," дефинира

набор от сигнализационни съобщения, които позволяват на разговорния агент да пренасочи група крайни точки,

без това да повлияе на крайната точка или състоянието на връзката. Тези сигнализационни съобщения позволяват на разговорния агент (CA) да подаде нов NotifiedEntity или NotifiedEntityList за събиране на

крайните точки, определени от маската "all of". Това е полезно, ако нов разговорен агент поеме работата на

предишния и пожелае от този момент нататък да пренасочи крайната точка(и) да изпращат съобщения до него.

В същото време, тази "функция" може да бъде използвана от хакер, който да инструктира гласов шлюз да

пренасочи сигнализационния трафик към нов мениджър на разговори. Следното съобщение демонстрира тази

атака:

EPCF 1200 *@gw1.dostav4ik.bg MGCP 1.0

RED/N: [email protected]

EPCF (End Point Configuration – конфигурация на крайното устройство) съобщението бива изпратено към

гласовия шлюз на порт 2427. То съдържа астериск (*) пред името на домейна като маска, за инструктиране на

шлюза да приложи промяната към всички възможни крайни точки. Хедърът RED/N посочва къде трябва да бъде

изпратен трафика (в този случай [email protected]). Следващото съобщение е друг вариант и посочва

резервен мениджър на разговори:

EPCF 1200 *@gw1.dostav4ik.bg MGCP 1.0

RED/NL: [email protected], [email protected]


31

Тъй като MGCP не предоставя какъвто и да било контрол над сигурността, един от подходите за защита срещу

подобна атака е да се ограничат връзките към MGCP порта (2427) от източници, които не са доверени. С други

думи, трябва да бъде направено конфигуриране от типа точка-до-точка, между мениджъра на повикванията и

гласовия шлюз, с цел размяна на сигнализационни MGCP съобщения. Друг подход е да се конфигурира IPSec

между мениджъра на повикванията и гласовия шлюз, разбира се ако такава функция се поддържа и от двата.

Компрометиране на IP телефонната конфигурация

Повечето хардуерни телефони получават важни файлове, като стартиращи „изображения― (boot image) или

конфигурационни файлове, по мрежата. Различни VoIP устройства, включително и тези от Cisco и Avaya, често

трансферират тези файлове, използвайки TFTP протокол, но някои също така може да ползват и HTTP. Така или

иначе един нападател може да получи копия от тези файлове доста лесно. И двата TFTP и HTTP протокола са тесктово базирани в чист вид, и те често се ползват без удостоверение. Нападател, който е получил подобни

файлове, има достъп до настройките на телефона, оперативните функции и опциите.

За да се сдобие с такъв файл, нападателят единствено се нуждае от IP адреса на TFTP сървъра, както и името на

boot image-а или конфигурационния файл, като за тази цел да речем при един Cisco телефон, може просто да се

провери дисплея на самия телефон. В меню „Опции― на телефона може да бъдат намерени редица ценни неща,

като например адрес на TFTP сървър или такъв на Cisco мениджър на повиквания.

В мрежа на Avaya, нападателят може да започне подслушване на UDP порт 69 и да идентифицира TFTP сървър

(Тъй като Avaya телефоните теглят TFTP информацията след рестартиране, нападателят може просто да

рестартира телефона докато подслушва по мрежата). След като нападателя узнае адреса на TFTP сървъра, той

може просто да вземете желания файл, ползвайки подходящата TFTP или HTTP GET команда.

Например, 46xxsettings.txt е конфигурационния файл на всеки хардуерен телефон марка Avaya. Чрез

изпълнение на TFTP GET ползвайки това файлово име, атакуващ може лесно и бързо да изтегли

конфигурационен файл. Тъй като повечето телефони изтеглят актуален кофигурационен файл всеки път, след

като са рестартирани, нападателят може да бъде доста сигурен във факта че ще се сдобие с най-актуалната

версия. За да се изтегли конфигурационен файл на телефон е нужно да се изпълнят следните стъпки:

1. Свързване към VoIP мрежата

2. Локализация на TFTP сървъра, ползван за качване на конфигурационните файлове в хардуерните

телефони

3. Локализация на TFTP сървъра, чрез подслушване на мрежата за връзки към неговия IP адрес. По този

начин се разбира името и пътя на тегления файл. Приемаме че адресът на сървъра е 172.16.1.88.

4. Изпълнява се командата по-долу, в command prompt на Windows:

tftp 172.16.1.88 GET 46xxsettings.txt

Когато един хардуерен телефон рестартира, той често сваля стартиращо изображение (boot image) и

конфигурационен файл по мрежата. Тези файлове съдържат информация за настройките на телефона,

включително и функционалните свойства и възможности. Както бе обсъдено в предишния раздел, boot image-а и конфигурационния файл биват прехвърлени от мрежата на хардуерния телефон по протоколи в чист текстов

вид. Използването подобни протоколи предоставя на хакерите възможността за въвеждане на собствени

злонамерени файлове в средата.

Нападател, който желае да принуди хардуерен телефон да зареди зловреден конфигурационен файл може да

изпълни проста атака от тип човек-по-средата. Чрез фокусиране на атаката върху слой 2 на OSI модела,

нападателят може да пренасочи всички TFTP/HTTP заявки далеч от истинския сървър, към машина под негов

контрол. След като пренасочването е било създадено, нападателят може да вкара злонамерен boot image и

конфигурационен файл в телефона. Тези файлове биват инсталирани в телефона по време на процеса на

зареждане. В резултат на липсата на криптографски защити, става невъзможно за хардуерния телефон да

провери идентичността на изпращащия ги сървър.

a01d01b2_3.bin за Avaya хардуерни телефони

46xxsettings.txt за Avaya хардуерни телефони

След като файловете са заредени в телефона, нападателят е в състояние да контролира него и всичките му

възможности от разстояние. За него са атрактивни само някои от функциите. На практика, повечето от

настройките в типичните хардуерни телефони са от малко или без значение за нападателите.

Конфигурационните файлове обикновено включват информация като набирането на какъв код избира външна

линия, а също и настройките за бързо набиране. Въпреки това, промяна в пренасочването на обажданията, SIP


32

времената на изчакване за пре-регистрация, както и записването на разговорите позволяват да се прихване

гласовата информация от самия й източник, понякога дори когато телефона не се използва.

Например, много хардуерни телефони позволяват на потребителите да използват телефона като записващо

устройство, без да има телефонен разговор или вдигане на слушалката. Това означава, че чрез правилния

конфигурационен зловреден файл, телефонът може да се настрои да записва звук от микрофона на говорителя.

За да проведе атака, нападател трябва да следва изброените стъпки:

5. Свързване към VoIP мрежата

1. Локализация на TFTP или HTTP сървъра, ползван за зареждане на boot изображения и

конфигурационни файлове в хардуерните телефони

2. Стартиране на собствен TFTP сървър и подсигуряване, че зловредните 46xxsettings.txt and a01d01b2_3.bin се съдържат в основната директория на TFTP сървъра

3. Изключване на атакуващата машина от мрежата, след това се променя IP адреса с този на TFTP сървъра

4. Машината се включва обратно в мрежата и се игнорират всякакви грешки за IP адресен конфликт

5. Ползвайки Cain & Abel в атакуващата машина, се изпълнява атака от тип човек-по-средата,

пренасочвайки целия трафик, предназначен до реалния TFTP сървър към машината на нападателя,

която притежава различен MAC адрес, но същото IP

Представяне за SIP Прокси и Регистър сървър

Възможни са много spoofing атаки срещу SIP VoIP системите, включително възможността някой да се представи

за SIP прокси и SIP Регистър сървър. По време на SIP INVITE заявка, SIP клиентът изпраща до SIP прокси

сървъра или регистъра пакет INVITE. Преди легитимния сървър да отговори, нападателят може да изпрати

подправен отговор, който да изглежда че е като от истинския домейн, но който да притежава различен IP адрес,

като по този начин пренасочи потребителския агент към SIP Прокси или Регистър, контролиран от нападателя.

Например, ако SIP потребителски агент се опита да се свърже със stargate-bg.org на адрес 91.196.124.78,

нападателят може да подправи отговор от Stargate-BG с контакт адрес на 91.196.124.150, което е SIP

Прокси/Регистър контролиран от нападателя. Когато легитимният потребителски агент пожелае да извърши

обаждане към потребители на Stargate-BG, нападателят може да прехвърли разговори към всеки SIP клиент, по

свое усмотрение. При този сценарий, атакуващият може да пренасочи разговори към клиент който контролира,

както и към легитимният клиент на разговора, позволявайки на атакуващият да слуша всички разговори към или

от целта им. Spoof пакетът от атакуващият би изглеждал по подобен начин на този по-долу (IP адреса на

нападателя е споменат в реда Contact).

SIP/2.0 302 Moved Temporarily

To: <sip:[email protected]>

From: <sip:[email protected]>;tag=1108

Call-Id: [email protected]

CSeq: 1 INVITE

Contact: <sip:[email protected]>

4.2 H.323 базирани атаки

H.323 крайните точки използват Допускащ до Регистрация Статус на H.225 (RAS - Registration Admission Status)

за много операции свързани със сигурността, включително идентификационни и регистрационни функции. RAS

услугите позволяват на крайни точки, gatekeeper-и и шлюзове да поддържат връзка една с друга, за да се гарантира, че всяко устройство е регистрирано и напълно функциониращо. Операции като свързаност по време

на регистрация, промени в скоростта на канала, активен/не-активен статус и де-регистрации между крайна

точка-gatekeeper, всички те възникват с помощта на RAS.

От гледна точка на сигурността, RAS държи ключовите компоненти на H.323 мрежите. Например, когато H.323

крайна точка е свързана към мрежата, тя трябва да използва функцията на RAS за регистрация, ако иска да

комуникира във VoIP средата. Ако крайната точка не е в състояние да се регистрира или не може да се

регистрира чрез RAS, тя просто не съществува. RAS също така държи автентификацията при H.323. След като

крайната точка е регистрирана, нейното потребителско име и парола се потвърждава от/до gatekeeper-а. След

като регистрацията и удостоверяването са възникнали чрез RAS в H.323 VoIP мрежата, крайните точки може да

започнат да изпращат или получават телефонни обаждания. Преди RAS услугите да са се осъществили, нищо не

може да се случи.

H.225 регистрационният удостоверяващ процес защитава паролата срещу общите подслушващи атаки, тъй като

той не изпраща паролата по мрежата в прост, текстов формат. За съжаление, H.225 е все още уязвим към много

атаки върху сигурността. Атаките, които ще бъдат обсъдени са:


33

Изброяване на потребителите (H.323 ID)

Извличане на H.323 пароли (офлайн речникова атака)

Атака чрез повторение (replay) върху H.225 автентификация

Измама (spoofing) на H.323 крайна точка (E.164 псевдоним)

Изброяване на E.164 псевдонимите

E.164 атаки чрез прескачане (hopping)

Отказ от услуга по NTP

Отказ от услуга по UDP (H.225 отказ на регистрация)

Отказ от услуга чрез H.225 nonStandardMessage

Отказ от услуга чрез пакети „Host Unreachable―

Пренасочване на H.323 gatekeeper-и

H.323 GK (от GateKeeper) също могат да бъдат пренасочени доста просто, в зависимост от конкретното VoIP

изпълнение. Ако H.323 крайната точка не притежава статично зададен gatekeeper, тя търси такъв чрез

изпращане на запитване за gatekeeper (GRQ – Gatekeeper Request) по мрежата до 224.0.1.41 на порт 1718. Всяка

една H.323 крайна точка използва този адрес за намиране на gatekeeper-и в локалната мрежа. Трикът на

нападателя тук е първи да отговори на пакета и по този начин да каже на H.323 точката да се регистрира в

gatekeeper-а под негов контрол. Пакета за потвърждение от gatekeeper-а (GCF – Gatekeeper Confirmation),

изпратен от нападателя, може да накара „насила― H.323 крайни точки да маршрутизират всичките си разговори,

както и в прост текстов вид, така и криптирани, през зловреден посредник. Като алтернатива, за да се гарантира

че разговорът е завършен по правилен начин, злонамереният gatekeeper може да посочи легитимния gatekeeper в

мрежата. След като агентът на крайната H.323 точка получи GCF пакета, крайната точка ще започне да общува с GK на нападателя, като по този начин позволи на атакуващия да контролира гласовия комуникационен път.

224.0.1.41 е резервиран Клас D мултикаст адрес за откриване на GK

В много случаи се ползва статично зададен IP адрес за gatekeeper, но въпреки това пренасочващата атака не

може да бъде избегната. Дори когато крайната точка не изпрати пакет за откриване към 224.0.1.41, нападател все

още е способен да опресни информацията в крайната точка свързана с GK, със зловредна такава. За да извърши

тази атака, нападателят може да направи мониторинг на мрежата и да изчаква моментът, когато крайната точка

бъде рестартирана или просто да изпълни рестарт на крайната точка с помощта на DoS атака.

Когато крайна точка стартира процес на зареждане, тя търси своя статично въведен gatekeeper адрес. По това

време един хакер може да замени статичния запис с подправен GCF отговор, съдържащ неговата информация за

GK. Както и в предишната ситуация, GCF пакета изпратен от нападателя ще накара H.323 крайната точка насила

да актуализира своята gatekeeper информация. Така, докато се ползва статично въведен адрес, информацията бива подменена ако е получен GCF пакет с нова информация. След като е получена новата информация, данните

в GCF пакета ще бъдат използвани от крайната точка. Следва да се отбележи, че GCF пакетите на нападателя

трябва да достигнат крайните точки преди да пристигне легитимния GCF пакет от истинския GK, което

означава че времето и близостта са ключови изисквания, за да се развие успешно подобна атака.

Откриване на потребителските имена (H.323 ID)

Когато се изисква удостоверяване между gatekeeper и H.323 крайна точка, крайната точка ще изпрати своето

потребителско име и парола към устройството за удостоверяване. За да се улови използваното в H.323

потребителско име, може просто да се подслуша мрежата и да се улови в прост текстов вид. Една комутируема

мрежа осигурява малка защита, тъй като хакер може да изпълни атака от тип човек-по-средата и да прихване

всички H.225 потребителски имена в рамките на локалната подмрежа.

След като са получени потребителските имена са възможни няколко вида атаки, включително ползването на

брут-форс. Като снифър за прихващане на потребителското име може да бъде ползван Wireshark, функцията в него е отбелязана като H.323 ID под H.225.0 RAS секцията от пакетното трасиране/проследяване.


34

Фигура 4.2-1. H.225 потребителско име в прост текстов вид

Извличане на H.323 пароли

В процесa на удостоверяване H.323 крайните точки ползват H.225, а паролата е кодирана с ASN.1, заедно с

потребителското име (H.323 ID) и щампата за време (създадена от датата и часа в момента, отброени в секунди

от 1 януари, 1970), и така се създава ASN.1-кодиран буфер. Кодираният буфер след това се използва за създаване

на MD5 хеш (означен като cryptoEPPwdHash). Както бе споменато по-рано, този модел гарантира, че паролата не

е изпратена по мрежата в прост текстов формат; моделът обаче не е застрахован срещу офлайн речникови и

брут-форс атаки.

За създаване на MD5 паролата в крайната точка, се ползва следния алгоритъм/уравнение:

MD5(ASN.1 Encoded: H.323 ID + Парола + timestamp) = Hash

Този метод е уязвим към офлайн речникова атака. Два от трите параметъра, необходими за да се извърши

офлайн атаката могат да се вземат чрез подслушване на мрежата от нападател, извършващ да речем атака от

типа човек-по-средата. По-нататък, тъй като H.323 крайните точки често използват прости пароли, като

например четирицифрения вътрешен номер на хардуерния или софтуерен телефон, времето необходимо за

получаване на паролата е минимално.

С цел да се извърши офлайн речникова атака, нападателят се нуждае да подслуша потребителското име,

щампата за време, и полученият MD5 хеш от мрежата, всички от които преминават по мрежата в прост текстов

вид. На Фигура 4.2-2 може да се забележи, че H.323-ID реда съдържа потребителското име (USER), реда

timestamp съдържа Nov 7, 2006 10:32:45.00000000 и реда хеш притежава резултата на MD5 низа:

1C8451595D9AC7B983350D268DB7F36E.

Фигура 4.2-2. Прихващане на информация от H.323 удостоверяващ пакет

На този етап потребителят може да вземе речников списък с пароли и да постави всяка една в уравнението,

заедно с всички останали елементи, които са били прихванати:

MD5(ASN.1-encoded: H.323-ID + password + timestamp) = hash

При брут-форс атаката, нападателят взема парола от речниковия файл, заедно с потребителското име (H.323 ID),


35

щампата за време и тогава ASN.1 кодира всяка стойност индивидуално. След това ASN.1-кодирания буфер се

„разбърква―, ползвайки MD5 hashing функцията. Ако стойността на MD5 хеша на нападателя е същата като

MD5 хеш-а, заловен по мрежата, значи паролата е позната, ако ли не се продължава със заместването на нова

парола. Процеса може да бъде изобразен изключително просто, като за целта избираме уравнението 5 + X = 8.

На мястото на X може да бъдат замествани различни числа, докато се получи верния резултат.

За разлика от онлайн брут-форс атаката, където нападателя може да има само ограничен брой опити преди да

бъде блокиран или забелязан в мрежата, офлайн версията може да бъде прилагана неопределено време докато

паролата бъде налучкана. Освен това, тъй като повечето H.323 телефони ползват лесни за отгатване пароли, това

упражнение най-вероятно няма да отнеме прекалено много време.

Следната демонстрация описва тази пасивна речникова атака върху H.225 автентификация. Първата колона представлява подслушаното потребителско име, втората е параметъра ползващ голям списък с речникови думи,

третата – подслушаната щампа на времето и четвъртата – резултата за MD5 хеш. След като генерираната наново

стойност за MD5 отговори на взетата по мрежата (удебелен шрифт в последния ред), нападателят разбира че е

отгатнал правилната H.323 парола.

Sniffed (Captured) Entities over the network:

- Username: USER

- Timestamp: 1162895565

- MD5 Hash: 1c8451595d9ac7b983350d268db7f36e

MD5 (ASN.1 Encoded: Username + Password + Timestamp ) = Hash

USER + test + 1162895565 + =! 1C8451595D9AC7B983350D268DB7F36E

USER + Ivan + 1162895565 + =! 1C8451595D9AC7B983350D268DB7F36E

USER + Raina + 1162895565 + =! 1C8451595D9AC7B983350D268DB7F36E

USER + 1108 + 1162895565 + =! 1C8451595D9AC7B983350D268DB7F36E

USER + 1117 + 1162895565 + =! 1C8451595D9AC7B983350D268DB7F36E

USER + isec + 1162895565 + =! 1C8451595D9AC7B983350D268DB7F36E

USER + PASS + 1162895565 + = 1C8451595D9AC7B983350D268DB7F36E

H.323 атака чрез повторение (replay)

H.225 удостоверяването е уязвимо също и към атака чрез повторение, като тя се осъществява когато хеш със

същата стойност, еквивалентна на този от паролата, може да бъде препратен от различен от оригиналния източник, който успешно да се автентифицира. Например, ако устройство приема само MD5 хеша от пароли

като удостоверение, нападател може просто да повтори някой от хешовете, прихванати по мрежата. Когато

нападателят няма идея каква е паролата, той просто повтаря вече готовия хеш и бива удостоверен. Поради тази

причина, повечето MD5 хешове биват третирани чрез прибавяне на случайни стойности. При H.323, това е

щампата за време, но това от своя страна пък довежда до други проблеми.

С цел да се предотврати изпробването на всяка дума от речника в MD5 хеша, H.323 ползва щампата за време

(която е уникална за всяка заявка за удостоверение), потребителското име (H.323-ID) и паролата. В такъв

случай, ако паролата е „iSEC‖ например, тя ще бъде комбинирана с потребителското име и съответната щампа

за време, с цел създаване на уникална MD5 стойност за всяка заявка за удостоверяване.

Ако крайната точка и GK използват различни щампи за време от NTP сървъра, хеша създаден от H.323 точката ще бъде невалиден. Така например, ако крайната точка получи клеймото Oct 2, 2008 6:34.00 и gatekeeper-а

получи клеймото Oct 2, 2008 6:34:01, MD5 стойностите ще бъдат различни и gatekeeper-а ще отхвърли

удостоверяването.

Може да си направим извода, че управлението на клеймото от множество NTP устройства със стотици H.323

крайни точки и GK, може да се окаже обременяваща задача, ако щампата закъснее дори с .01 секунди. Ето защо,

H.323 GK-ите позволяват MD5 хеш, който е бил създаден от по-старо клеймо за време (обикновено в рамките на

30 до 60 минути), за успешно удостоверяване. Докато това помага значително за оперативните цели (в противен

случай не би могло да H.323 крайните точки да се удостоверяват постоянно), се позволява на атакуващия да

изпълнява атака чрез повторение. Дори когато са налични уникални щампи за време, потребителски имена и

пароли, с цел създаване на MD5 хеш, е позволено да се използва повторно стария MD5 хеш в рамките на 30 или

60 минутен интервал.

Да се изпълни такава атака е доста лесно - злонамерения потребител просто прихваща MD5 хеша от крайното устройство към gatekeeper-a и повтаря обратно стойността към GK, като това удостоверява клиента на

нападателя.

Следната информация в 16-ичен вид е пример за пакет, съдържащ пълна H.225 регистрационна заявка.

Информацията в курсив на първият ред е всъщност IP адреса на GK (c0 a8 74 79 означава 192.168.116.28, в


36

hex), втората стойност в курсив е потребителското име (00 55 00 53 00 45 00 52 00 00 означава USER

в hex) и последната е прихванатия по мрежата MD5 хеш.

0e 80 08 be 06 00 08 91 4a 00 05 80 01 00 c0 a8 - IP адрес

74 49 06 b8 01 00 c0 a8 74 49 06 b7 22 c0 82 01

01 00 07 00 00 00 00 00 00 00 00 01 34 39 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 02 40 0c

00 44 00 49 00 47 00 53 00 2d 00 69 00 53 00 45

00 43 00 2d 00 74 00 73 00 74 05 00 49 83 58 69

c3 76 82 01 01 00 07 54 61 6e 64 62 65 72 67 01

34 39 2c 2b 10 30 2e 01 04 04 00 55 00 53 00 45 – Потребителското име (т.е.

USER)

00 52 00 00 c0 45 50 d1 4c 08 2a 86 48 86 f7 0d

02 05 00 80 80 1c 84 51 59 5d 9a c7 b9 83 35 0d - MD5 Хеш

26 8d b7 f3 6e 01 00 01 00 01 00 01 00 05 18 01

00 00 12 6d 01 50 20 df 89 03 59 6f 45 19 9f 27

73 c0 a5 92 74 af 00 00 50 20 df 89 03 59 6f 45

19 9f 27 73 c0 a5 92 74 af 00 46 3c 61 73 73 65

6e 74 3e 3c 61 73 73 65 6e 74 5f 74 79 70 65 3e

63 6c 69 65 6e 74 3c 2f 61 73 73 65 6e 74 5f 74

79 70 65 3e 3c 76 65 72 73 69 6f 6e 3e 31 3c 2f

76 65 72 73 69 6f 6e 3e 3c 2f 61 73 73 65 6e 74

3e

След като се създаде новата H.225 регистрационна заявка, тя бива изпратена по мрежата в 16-ичен вид и

съответно бива удостоверена от страна на GK.

Подмяна на крайни устройства при H.323 (Е.164 псевдоними)

На по-високо ниво, E.164 псевдонимите означават телефонния номерационен план, ползван за адресни и

телефонни номера при H.323 крайни точки, той често се ползва като идентификатор за H.323 крайните точки по

мрежата. Подмяната на E.164 псевдонимите е подобна на други видове атаки върху обекти, на които се има

доверие, като MAC адресите в Ethernet картите например, имената на иницииращите нод-ове (Initiator Node

Names) в iSCSI крайни точки и WWN при оптично-каналните HBA. Ако се ползва MAC адрес за филтриране

достъпа до безжична точка за достъп например, всеки нападател може да ползва etherchange за промяна на своя

MAC, който може да бъде намерен на адрес http://ntsecurity.nu, и така да прескочи ограниченията на достъпа.

Една злонамерена крайна точка може да промени своя E.164 псевдоним и да се регистрира в GK с подменена

идентичност. В зависимост от политиката на gatekeeper-а, нападателят може да трябва да извърши DoS атака

срещу устройството, чиято идентичност се ползва. Ако политиката на GK е настроена за запис отгоре(rewrite)

на всяка нова крайна точка с E.164 псевдоним, вече присъстващ в базата данни (псевдоним дупликат), ще бъде разрешен презапис върху вече съществуващата регистрация; в този случай не е необходима DoS атака. Ако

политиката е настроена обаче да отхвърли всяка нова точка с дублиращ се E.164 псевдоним, регистрацията ще

бъде отхвърлена, така че ако цели присъединяване към мрежата с откраднат псевдоним, нападателят ще трябва

да изпълни DoS атака върху легитимната крайна точка. Освен това, когато истинската крайна точка опита да се

регистрира в мрежата, след като е била „изблъскана― по този груб начин, то вероятно вече тя ще бъде

отхвърлена, тъй като там има крайна точка с нейния E.164 псевдоним. Различните политики, които са

приложени, влияят върху изхода от този вид атака.

Преди нападателят да подмени идентичността си във VoIP мрежата, той се нуждае да открие E.164 псевдонима,

както е описано в следващия параграф. Освен това, тъй като E.164 псевдонима е параметъра, използван за

адресиране и свързване с абонат, той бива широко разпространен във VoIP средите (подобно на телефонен

номер в телефонния указател). Телефонния справочник на компанията притежава пълното име и E.164 псевдоним на даден потребител (често VoIP фирмените телефонни директории са напълно достъпни, без да се

изисква идентификация). Тази информация може да бъде използвана от нападател, за да се представи за

практически всеки потребител на една такава VoIP мрежа.

Откриване на Е.164 псевдоними

Съществуват няколко начина за откриване на E.164 псевдоними, водещи до присвояване самоличността на

H.323 крайна точка. Най-лесният от тях е просто да се подслуша информацията по мрежата. По време на

разговор, една точка набира друга, ползвайки своя E.164 псевдоним. Информацията за дестинацията на

крайната точка преминава в прост текстов вид; така нападател може просто да подслуша връзката и да види

Е.164 псевдонима. Ако за целта се ползва Wireshark, мястото където може да бъде намерен псевдонима е в реда

dialedDigits, която показва набрания номер. Позицията на реда dialedDigits в H.323 пакета с ползване на

http://ntsecurity.nu/


37

Wireshark е показан по-долу:

H.225.0 RAS

gatekeeperRequest

endpointAlias

Item 1

Item: dialedDigits

dialedDigits

Може да не е възможно да се извърши атака от типа човек-по-средата, и по този начин нападателя да бъде принуден да намери по-добър начин за откриване на E.164 информацията. Следващият метод, който е по-добър

избор в момент когато подслушването не е възможно, е да се подложи информацията от gatekeeper-а на брут-

форс. Когато дадена крайна точка се опита да се регистрира в gatekeeper, използвайки неоторизиран E.164

псевдоним, съобщението което бива върнато обратно е securityDenial. В случай, че крайно устройство се опита

да се регистрира с E.164 псевдоним, който е бил вече регистриран, GK ще изпрати duplicateAlias. Това

съобщение сигнализира, че изпробваната Е.164 информация е легитимна и дори регистрирана, и разбира се че в

момента се ползва от друго устройство. Това поведение на GK, позволява на нападател да открие E.164

псевдонимите в даден GK, като изброи цифрите от 1 до 999999999 например и запази тези когато отговора е бил

duplicateAlias.

Фигурите по-долу изобразяват този процес. Вторият ред (rejectReason) на Фигура 4.2-3 показва съобщение за

грешка, в случай че нападател се опита да се регистрира с Е.164 псевдоним, който не е оторизиран (securityDenial). Вторият ред на Фигура 4.2-4 показва съобщение за грешка (rejectReason), когато нападател се

опита да се регистрира с оторизиран псевдоним, който е регистриран в момента в системата (duplicateAlias).

Разликата в съобщенията показва на нападателя, че във втория случай се ползва валиден E.164 псевдоним.

Фигура 4.2-3. Грешка при отхвърляне на регистрация, при неоторизиран E.164 псевдоним

Фигура 4.2-4. Откриване на E.164 псевдоним чрез съобщение за грешка duplicateAlias

Атаки чрез „прескачане“ при E.164 (hopping)

Hopping атаките позволяват неоторизирани потребители да „прескачат‖ между различните ограничения на

сигурността, позволявайки им да избягат от всеки вид изолация пусната в действие. С други думи, hopping

атаките позволяват неоторизирани потребители да имат достъп до оторизирани зони или непривилегировани

потребители да навлизат в зони, които трябва да бъдат достъпни само за привилегированите потребители. От Cisco суичовете е известно, че са възможни атаки при които нападателите са в състояние да прескочат между

VLAN-овете, използвайки специфични VLAN маркери (тагове), и да получат достъп до някои мрежи, които по

принцип трябва да са ограничени.

E.164 атаките чрез прескачане са продължение на атаките чрез подправяне, описани по-горе. Често, GK

използват E.164 псевдонимите като обекти с цел сигурност (позволявайки само статично зададени E.164

псевдоними да се регистрират или да правят специфични видове повиквания). Следователно, E.164

псевдонимите се задават с различни зони на действие при H.323 крайните точки. Например, на една група от

псевдоними може да бъде позволено да се обажда навсякъде, включително и да прави международни

повиквания в най-скъпата част от денонощието; друга група може да бъде ограничена да води само национални;

на трета група може да бъде позволено да се обажда само на вътрешни номера и последната група може да бъде


38

позволено да се обажда само на "700" и „800― номера. Преправянето на Е.164 псевдонимите срива целия модел

за подсигуряване на идентичността в една H.323 VoIP мрежа.

DoS през NTP

След като вече знаем защо не може да се има доверие на удостоверяването (регистрацията) и оторизацията в

H.323, нека изместим фокуса към атаките от тип „отказ от услуга― при H.323 протокола.

DoS при включена автентификация

Първата DоS атака която ще разгледам, се случва при активирана автентификация на H.323 крайните точки.

Както беше показано по-горе, H.323 удостоверяването използва клеймото (щампата за време) от NTP сървър за

създаване на MD5 хеш. Въпреки това, един хакер може да си гарантира, че H.323 крайните точки няма да могат

да се регистрират в мрежата, като актуализира H.323 устройства с невярна щампа за време. Това е възможно, тъй като NTP използва UDP за транспорт, който е ненадежден протокол (всеки един хакер може да подправи

NTP пакет).

Например, хакер може да използва фалшив NTP сървър и да изпрати времеви щампи до H.323 крайни точки,

които не са същите ползвани от gatekeeper-а. Освен това, един нападател може да изпрати времеви щампи до

самия GK, които се различават от ползваните от крайните точки. Тъй като повечето H.323 крайни точки и

gatekeeper-и не изискват удостоверяване на щампите за време, те просто ще ги приемат от нападателя.

В най-добрия случай, някои крайни точки и GK биха приели времеви клейма само от определени IP адреси, но

нападателите могат просто да променят своите адреси и след това да изпратят злонамерената щампа до

крайната точка. Следователно, разполагайки с невярната информация за точно време, MD5 хеш стойностите

между GK сървъра и H.323 крайните точки ще се разминат, предотвратявайки по този начин удостоверяване на

заявките от VoIP телефоните.

DoS по UDP (отказ от регистрация при H.225)

Следващата атака от тип отказ от услуга включва отказ на H.225 регистрационни пакети и както подсказва

името, отказът от услуга при регистрация служи за да се отхвърли регистрацията на съществуваща H.323

крайна точка. Проблемът е, че не се изисква удостоверяване за да се отхвърли насилствено H.323 крайна точка

от мрежата. Следователно, ако има H.323 крайна точка която легитимно се е регистрирала в GK, нападател може

просто да изпрати към нея един UDP пакет за отхвърляне на регистрацията и тя ще бъде незабавно свалена от

H.323 мрежата. Легитимната крайна точка ще се опита да се пре-регистрира, но нападателят може просто да

изпрати друг UDP пакет.

Тъй като атаката включва само един UDP пакет, нападателят може да изпраща отхвърлящи регистрацията

пакети веднъж на всеки няколко минути, за да се предотврати регистрацията на легитимната крайна точка в GK

(предотвратявайки по този начин получаването и изпращането на телефонни обаждания за неопределено

време).

DoS чрез пакети от тип „хоста не е достъпен“ (host unreachable)

Следващата атака от тип отказ от услуга включва съществуващ телефонен разговор между две крайни H.323

точки. Когато две крайни H.323 точки са установили телефонен разговор, много пакети прелитат из цялата

мрежа. Един от многото се използва, за да се гарантира че двете крайни точки са все още там.

Например, когато човек говори по телефона най-често казва „Ало― в началото или когато се появи тишина

отсреща, за да се увери че линията не е прекъснала. Същата идея се прилага и при VoIP.

При тази атака, нападателят постоянно изпраща ICMP пакет „Host Unreachable‖ (хоста не е достъпен), по време

на разговор между две точки. В днешните разработки на VoIP, получателят на ICMP пакета ще счете че другата

страна е разпаднала разговора и би прекъснал комуникацията.

Забележка: Преди време е било забелязано че някои хардуерни телефони са податливи на този вид атака, всички

производители са били уведомени, като съответно са зашитили своите разработки.

DoS чрез H.225 nonStandartMessage

Последният вариант на атака чрез отказ от услуга възниква чрез H.225 nonStandardMessage пакети. Както

подсказва и самото име, нестандартен H.225 пакет бива пратен от крайна точка до мишената, която не е в

състояние да го интерпретира правилно. Нестандартните съобщения, често се използват за извършване на

действия в зависимост от конкретния производител. В случаите, когато с пакетите се злоупотребява,

неправилната им употреба може да доведе VoIP устройство до срив. Както и при предишната атака, нападателят


39

може неколкократно да изпраща дадения пакет до H.323 крайната точка в мрежата. В зависимост от

изпълнението на производителя, пакетите ще доведат или до претоварване, или до блокиране на системата. Това

блокиране, от своя страна, отваря крайната точка за много от нападенията обсъдени по-рано (като заместваща

атака или присвояване на идентичността), тъй като атаката отстранява крайната точка от мрежата в

продължение на две или три минути.

Забележка: Преди време е било забелязано че някои хардуерни телефони са податливи на този вид атака, всички

производители са били уведомени, като съответно са зашитили своите разработки.

За да се тества, податливо ли е дадено устройство на атака чрез H.225 nonStandardMessage, е нужно да се изпълнят стъпките по-долу:

1. Стартира се Nemesis от BackTrack Live CD.

2. От http://www.isecpartners.com/tools.html/ се сваля iSEC.nonStandardMessage.DOS; това ще бъде входния

файл в Nemesis, необходим за стартиране на атаката.

3. След като файла е свален, се стартира командата в подточка b а информацията от подточка a се

променя, съгласно параметрите на локалната мрежа:

a. Мрежова информация

a. IP: 172.16.1.103

b. MAC: 00:05:4E:4A:E0:E1

c. IP на мишена (H.323 крайна точка): 172.16.1.140

d. MAC на мишена (H.323 крайна точка): 02:34:4F:3B:A0:D3

b. Примерен синтаксис

nemesis udp -x 1719 -y 1719 -S 172.16.1.103 -D 172.16.1.140 -H

00:05:4E:4A:E0:E1-M 02:34:4F:3B:A0:D3 -P iSEC.nonStandardMessage.DOS

4. Командата се стартира последователно много пъти или се създава скрипт за непрекъснатата й

повтаряемост.

Следващите два реда представляват информацията в 16-ичен вид, като за редактирането й се ползва HEX

редактор.

5c 09 81 40 82 01 01 00 04 03 00 00 04 04 00 00

00 00

4.3 Real Time Protocol (RTP)

RTP е UDP протокол, който може да бъда използван динамично на портове от 1024 до 65535. Въпреки че, е

възможно да бъде ползван на всеки един UDP порт по-голям от 1024, много производители на VoIP

корпоративни решения (като Cisco и Avaya) предоставят възможност за статична конфигурация на портовете. В допълнение, съществува тенденция много софтуерни телефони да ползват специфични диапазони за RTP/RTCP

връзки, вместо да избират портовете произволно.

Основните елементи на един RTP пакет не са по-различни от тези при другите протоколи. RTP пакетите

съдържат номерация на последователността, клеймо за време, полезен товар (payload), SRRC (източник на

синхронизация), CSRC (спомагателен източник), както е показано по-долу.

Номерация на последователността: Това е стойността, която поддържа състоянието между две VoIP крайни

точки. Тя се увеличава с единица, всеки път когато RTP пакет бъде изпратен от H.323 точка.

Клеймо (щампа) за време: Съдържа информацията за време на RTP връзката. Нужно е да се отбележи, че

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

със 160 във всеки пакет.

Източник на синхронизация: Това е източника за пакетна синхронизация по време на един RTP поток.

Спомагателен източник: Поддържа източника на синхронизация по време на RTP поток.

Секция B от RTP RFC, "Съображения за сигурност", изброява многото притеснения относно сигурността,

свързани с протокола. Първото изречение в раздел 9 от RFC също така посочва, че на сигурността се очаква да

бъде обърнато внимание на по-ниски нива, като IPSec например.

http://www.isecpartners.com/tools.html/#_blank


40

Въпреки това, повечето VoIP системи в момента не поддържат IPSec на по-ниски нива за защита на разговорите,

тъй като употребата на протоколи за криптиране на ниско-ниво може да намалят драстично производителността

на VoIP системата. Тези факти, както и многото други описани в RFC, подсказват слабите места в сигурността,

свързани с RTP протокола.

Възможни атаки при RTP

Атаките върху сигурността при VoIP обикновено се фокусират върху прихващането на медия (аудио), което

включва RTP. Липсата на криптиране и/или конфиденциалност позволява няколко типа атаки от неоторизирани

потребители, вкл. анонимни, неоторизирани.

Забележка: Въпреки че, Secure RTP (SRTP), описан няколко раздела по-долу, осигурява необходимата сигурност

при комуникация на медията, повечето корпоративни мрежи не поддържат SRTP заради производителността и/или проблеми с работата му.

RTP е уязвим откъм много типове атаки, вкл. традиционните като подмяна, отвличане, отказ от услуга,

манипулация на трафика, така и по-новите като подслушване и инжекция на глас. Ние ще се фокусираме върху

най-опасните и тежки атаки в RTP, включвайки:

Пасивно подслушване

Активно подслушване

Отказ от услуга

Подслушване на разговори при RTP

RTP е протокол в чист бинарен вид, което означава че може да бъде подслушан по мрежата като други подобни

протоколи, като напр. Telnet, FTP и HTTP. Разликата е, че един RTP поток се съдържа от множество аудио

пакети, като всеки един съдържа „парченце― от целия разговор, затова ако някой иска да запише цял разговор трябва да запише всички „парченца―.

Един лесен начин е ползването на инструмент като Cain&Abel или Wireshark, като и двата позволяват

прихващане на последователност от RTP пакети, сглабянето им в правилен ред и запис на RTP потока във вид на

аудио файл. По този начин, всеки пасивно подслушващ нападател може просто да посочи, кликне и подслуша

почти всяка VoIP комуникация.

Ползвайки атака от тип човек-по-средата, нападателят може да бъде сигурен в успеха на подслушването, тъй

като по този начин той принуждава мишените да изпращат пакетите си през локалната подмрежа на нападателя.

С цел например да прихване RTP пакети от даден доставчик на VoIP, да ги подреди и декодира в .wav файлове, и

всичко това по време на атака от тип човек-по-средата, един нападател може да ползва познатия вече

инструмент Cain&Abel.

Фигура 4.3-1. Прихваната и записана VoIP комуникация през RTP пакети

Инжекция на глас

Този вид атака позволява на злонамерен потребител да „инжектира― аудио в съществуващи VoIP телефонни

разговори. Например, нападател може да инжектира аудио файл, който казва „Продавай на 118―, в разговор

между двама брокери на борсата, обсъждащи стокова информация.

За да стане тази атака реалност между две VoIP крайни точки, трябва да бъдат ползвани RTP пакети които

копират оригиналните клейма за време, последователност и SSRC информация. Напр. в дадена RTP сесия,


41

клеймото за време обикновено стартира с 0 и се увеличава с дължината на съдържанието на кодека (т.е. 160ms),

последователността стартира от 0 и се увеличава с 1 и SSRC обикновено представлява статична стойност за

сесията и функция за време. Всичките тези стойности са или статични или могат да бъдат отгатнати.

Възможността за отгатване е доста вероятна, тъй като всяка от тези стойности преминава по мрежата в прост,

текстов вид.

Фигура 4.3-2. RTP инжекция

SSRC номера на нападателя е същият като на своята мишена, но последователността и щампата за време са в

синхрон с легитимната сесия (увеличаващи се по правилен начин).

За да се инжектира аудио във VoIP мрежите които ползват RTP, нападателят трябва да ползва RTPInject,

инструмент който автоматизира стъпките, необходими за вкарване на пакети в съществуващ аудио поток. Той

автоматично променя щампата за време, последователността и стойността на SSRC.

5. Механизми за защита

В следващите няколко страници ще разгледам предвидените механизми за защита при сигнализацията и преноса на VoIP.

5.1 Механизми за защита на сигнализацията

Един от основните пропуски във VoIP сигурността е защитата на сигнализационните съобщения, разменяни

между участниците и компонентите. Тези съобщения се ползват за осъществяване на комуникацията, а също

така и за размяна и управление на криптографски ключове за защита на медийните потоци. Сигнализационните

съобщения може да преминават през мрежи със съмнителна политика и качество на сигурността, което на свой

ред създава предпоставки за атака. Правилната защита на сигнализационните съобщения играе важна роля в

отбраната срещу евентуални заплахи и атаки, вкл. неоторизиран достъп до равнината за защита, измами,

подслушване, отклоняване на разговори и др. Следователно е много важно да се разбере важността от дефинирането на набор от фундаментални цели на сигурността за защита на сигнализационните съобщения.

Тези цели включват автентичност, цялост и конфиденциалност на съобщенията.

Сфера на предизвикателство за доставчици на услуги и трафик и собственици на корпоративни мрежи е

поддържането на протоколи за защита на VoIP и мултимедийни комуникации от страна на производителите на

устройства. Например, включването на SRTP и TLS в граничните сесийни контролери почти не съществува.

Механизми за защита на SIP

Няколко протокола могат да бъдат ползвани за осигуряване на интегритет и конфиденциалност на SIP

сигнализацията (RFC 3261) срещу значителен брой атаки. Такива са IPSec, S/MIME, TLS и напоследък DTLS,

като те се радват на различен успех при различните производители на устройства. Два фундаментални

показателя, които трябва да се имат предвид при въвеждането на протоколите за сигурност са лекотата на

въвеждане и мащабируемостта на действие. Например, TLS е предпочитан от редица производители пред S/MIME, защото е често срещан при приложенията и изисква минимални промени в софтуера или фърмуера. И

двата протокола обаче, притежават своите предимства и недостатъци.

Обикновено, когато SIP устройство като хардуерен телефон, е свързано към мрежа то минава през процеса на

получаване на IP адрес по DHCP, получаване на конфигурационен файл по TFTP (или друг подобен механизъм)


42

и анонсиране на своето присъствие за получаване на разговори, регистрирайки се в SIP регистър. IP адреса на

SIP регистъра може да бъде открит по три начина. Първият е чрез получаване на конфигурационен файл (напр.

изтеглен по TFTP), вторият е чрез ползване на хост частта от адреса на записа (напр. sip:[email protected]) и

третият е чрез мултикаст (напр. sip.mcat.net или 224.0.1.75). Регистрационният процес е критичен в SIP откъм

сигурност, следователно е силно препоръчително SIP регистрациите да бъдат удостоверявани, за да се избегнат

атаки от тип „отвличане на регистрация―. В допълнение, заявки за иницииране на разговори (INVITE) също

трябва да се удостоверяват, за да се осигури ниво на защита срещу провеждане на неоторизирани разговори и

DoS или SPIT атаки.

Удостоверяване (автентификация) по SIP

SIP ползва HTTP дайджест удостоверяване на съобщенията и обикновено SIP акредитацията е със сила в определена зона на действие (realm) или домейн. Един домейн може да управлява акредитациите на своите

потребители, но не може да ги делегира до други домейни, освен ако не е дефинирано между-домейново

доверено взаимоотношение.

Фигура 5-1. Удостоверяване на SIP регистрация и начало на разговор

Фигура 5-1 демонстрира удостоверяване на регистрация на устройство, иницииране на разговор и прекратяване

на разговора. Обезпечаващи съобщения като „180 Ringing‖ са пропуснати за краткост.

При стъпка 1, SIP телефонът се регистрира към локалния регистър (домейн A). По време на регистрацията (под-

стъпки 1-5), регистъра отправя призив за автентификация, чрез изпращане на отговор „401 Unauthorized‖ (също

се изпраща „nonce‖) (стъпка 1.2 в отговор на REGISTER заявката от стъпка 1.1). Устройството изпраща нова

заявка REGISTER (стъпка 1.4), която включва MD5 дайджеста. Ако удостоверяването е успешно, регистъра опреснява вътрешните си записи и отговаря със съобщение ОК. Форматът на съобщенията и механизма на

приканването към автентификация е един и същ за всички SIP методи.

При стъпка 2, потребителят стартира повикване към друг потребител в домейн B. При тази стъпка локалното

SIP прокси (домейн A) изпълнява удостоверяване преди да пристъпи към разговора, изпращайки „ 407 Proxy

Authentication Required― (стъпка 2.2) съобщение в отговор на първоначалния INVITE (стъпка 2.1). Следва

демонстрация на разменяните съобщения между потребителски агент (UA) и прокси.

Първоначалната заявка INVITE се изпраща без всякаква удостоверяваща информация:

INVITE sip:[email protected]:5060 SIP/2.0

Via: SIP/2.0/UDP 192.168.1.3:5060;branch=z9hG4bK-5ef661a9

From: ivan<sip:[email protected]:5060>;tag=aed516f97e1da529o0

To: <sip:[email protected]:5060>


43

Call-ID: [email protected]

CSeq: 101 INVITE

Max-Forwards: 70

Contact: ivan<sip:[email protected]:5060>

Expires: 240

User-Agent: 001217E57E31 Linksys/RT31P2-3.1.6(LI)

Content-Length: 313

Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER

Content-Type: application/sdp

Локалното SIP прокси (домейн А) подканва потребителското устройство да предостави правилна акредитация:

SIP/2.0 407 Proxy Authentication Required


From: ivan<sip:[email protected]:5060>;tag=aed516f97e1da529o0;



CSeq: 101 INVITE

Proxy-Authenticate: Digest realm="domain-a.com",

domain="sip:domain-a.com", nonce="969467834", algorithm=MD5

Max-Forwards: 15

Content-Length: 0

407 Proxy Authentication Required

Отговорът на локалното SIP прокси съдържа „Proxy-Authenticate‖ хедър, който включва realm,

domain, nonce и digest алгоритъм, които да бъдат ползвани за генериране на MD5 отговор:



SIP телефонът потвърждава съобщението от SIP проксито, чрез изпращане на ACK:

ACK sip:[email protected]:5060 SIP/2.0





CSeq: 101 ACK

Max-Forwards: 70



Content-Length: 0

SIP телефонът изпраща нова заявка INVITE, която включва акредитациите на потребителя в хедъра „Proxy-Authorization‖. Като допълнение, Cseq е увеличено от 101 на 102, за да покаже че това INVITE съобщение

принадлежи на нов диалог:

INVITE sip:[email protected]:5060 SIP/2.0

Via: SIP/2.0/UDP 192.168.1.3:5060;branch=z9hG4bK-d04dcaa1




CSeq: 102 INVITE

Max-Forwards: 70

Proxy-Authorization: Digest username="ivan",realm="domain-

a.com", nonce="969467834",uri="sip:petar@domain-

b.com:5060",algorithm=MD5,response="72f370515acd0b878bce1e9e788

99ad2"


Expires: 240


Content-Length: 313

Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER


Когато отсрещния потребител вдигне слушалката, неговият телефон изпраща отговор OK:

SIP/2.0 200 OK


44

Via: SIP/2.0/UDP domain-a.com:5060;branch=z9hG4bK-f7bb35c3

Via: SIP/2.0/UDP 192.168.1.3:5060;branch=z9hG4bK-d04dcaa1

From: petar<sip:[email protected]:5060>;tag=aed516f97e1da529o0;

To: <sip:[email protected]:5060>;tag=2027561073


CSeq: 102 INVITE

Contact: <sip:[email protected]:5060>

Max-Forwards: 15


Content-Length: 217

В тази стъпка, телефонът инициатор завършва сесията чрез изпращането на ACK, която съдържа

оторизационната информация:

ACK sip: [email protected]:5060 SIP/2.0

Via: SIP/2.0/UDP 192.168.1.3:5060;branch=z9hG4bK-6ee04695

From: ivan<sip:[email protected];5060>;tag=aed516f97e1da529o0



CSeq: 102 ACK

Max-Forwards: 70


a.com",nonce="969467834",uri="sip:petar@domain-

b.com:5060",algorithm=MD5,response="28909c2f5b3f682b2d8bc6a36ab

a572c"



Content-Length: 0

Забележка: в RFC документа не се указват начини за посрещане на ACK, защото той не се нуждае от отговор. С

други думи, ако SIP прокси получи ACK, той не трябва да отговаря със съобщение „407 Proxy Authentication

Required―.

Когато разговорът между двата потребителя е приключил и те затворят, се генерира BYE съобщение. В дадения

пример, BYE заявката се изпраща от Алис и бива удостоверена от локалното прокси (домейн А).

BYE sip:[email protected]:5060 SIP/2.0

Via: SIP/2.0/UDP 192.168.1.3:5060;branch=z9hG4bK-304dbcd




CSeq: 103 BYE

Max-Forwards: 70



b.com:5060",algorithm=MD5,response="96645bfe26e2a5b64803041948b

ba38d"


Content-Length: 0

В примера, локалното SIP прокси в домейн А изисква потребителското устройство да автентифицира заявката

BYE, като отговаря със съобщение „407 Proxy Authentication Required―:

SIP/2.0 407 Proxy Authentication Required

Via: SIP/2.0/UDP 192.168.1.3:5060;branch=z9hG4bK-304dbcd




CSeq: 103 BYE



Max-Forwards: 15

Content-Length: 0

Потребителският SIP телефон генерира съобщението BYE и включва подходящата удостоверяваща

информация:

BYE sip:[email protected]:5060 SIP/2.0

SIP/2.0/UDP 192.168.1.3:5060;branch=z9hG4bK-1be1b199




CSeq: 104 BYE

Max-Forwards: 70

Proxy-Authorization: Digest username="petar",realm="domain-



45

b.com:5060",algorithm=MD5,response="f17f737430b236c73121ecf6a10

31518"


Content-Length: 0

Накрая, острещният потребителски телефон отговаря със съобщение OK и сесията се прекратява:

SIP/2.0 200 OK

Via: SIP/2.0/UDP 192.168.1.3:5060;branch=z9hG4bK-1be1b199




CSeq: 104 BYE

Max-Forwards: 15

Content-Length: 0

SIP системите може да изискват удостоверяване на различни нива, което може да доведе до недостатъчно ниво

на защита. Например, система може да удостоверява само заявки за REGISTER, без да изисква удостоверяване

на INVITE. В друг случай може да се изисква удостоверяване на REGISTER и INVITE, но не и на BYE или

CANCEL заявки. Тези непълноти представляват възможности за атака на системата, като неоторизирано

иницииране или прекратяване на разговори.

С цел защита срещу атаки чрез повторение или маскарадинг, трябва да се ползва удостоверяване при всички

видове съобщения предназначени за създаване, редактиране или прекратяване на сесия. Такива съобщения са

INVITE, BYE, ACK и REFER. SIP RFC 3261 отбелязва, че CANCEL метода не би трябвало да бъде

удостоверяван от прокситата, тъй като той не може да бъде пратен наново. Оставено е на SIP проксито което

получава заявката CANCEL да провери дали тя пристига от източник, за който има вече асоциирана SIP сесия. Тази директива предполага, че съществува вече транспорт или мрежов слой за сигурност, като IPSec или TLS.

Тази предпоставка от своя страна създава възможност за злоупотреба в SIP системите, ползващи UDP като

транспорт и които не разполагат с IPSec. Ако нападател събере свойствата на един SIP диалог (напр. чрез

подслушване се събира информация като callerID, Cseq, branchID и tag), той може да маскира злонамерен

CANCEL и да прекрати създаване на разговор. В момента повечето продукти поддържат удостоверение на

INVITE и REGISTER методите, но не поддържат на BYE или CANCEL. Също така в IETF има дискусии върху

идеята за защита на финалните и обезпечителните отговори (напр. 183, 180), пращани по UDP с помощта на

криптографски механизми, така че да се запази целостта на съобщението.

Механизма, ползван за генериране на дайджест при SIP съобщенията се прилага при всички видове съобщения

(напр. REGISTER, INVITE и т.н.) и е описан във Фигура 5-2.

Фигура 5-2. Процесът на генериране на SIP отговор на заявка за поискване на удостоверяване

По-долу е описана целта на всяка една от стойностите:

nonce_value— Определен от сървъра стринг, генериран уникално всеки път когато е направена заявка

nc_value (nonce count)— Брой пъти в 16-ичен вид на заявките, които клиента е пратил с nonce. Напр.,

ако клиент е направил първата заявка в отговор на дадена nonce стойност, тя е "nc=00000001". Броят на nonce се изисква, когато се ползва qpop

cnonce_value— Това е цитиран обратно стринг, който се предоставя от клиента и бива ползван и от

клиента и от сървъра, за да се избегнат атаките в прост текстов формат, както и да предостави взаимно

удостоверяване и ниво на защита на съобщителна цялост


46

qpop_value— Показва качеството на защита. В момента са дефинирани две стойности (RFC 2617).

Стойността „auth‖, която показва удостоверяване и стойността „auth-int‖, която показва удостоверяване

със защита на цялостта(интегритет)

A1— MD5 низа от стойностите на потребителското име, realm, парола, nonce и cnonce:

username_value - Потребителското име в определената зона (realm)

realm_value - Стринг, съдържащ името на хоста който извършва автентификацията и асоциирания

домейн (напр. sipserver.domain.com)

passwd - Паролата, асоциирана с потребителското име

nonce_value – вижте описанието по-горе

cnonce_value - вижте описанието по-горе

A2— MD5 низа от метода, стойност на URI и тялото:

Method - SIP метода показан в съответното SIP съобщение

digest_uri_value - URI-то от Request-URI от Request-Line; повторено тук, защото е позволено на

прокситата да променят Request-Line по време на предаването

Резултатът е стринг от 32 HEX символа, пазен в полето Response на Proxy-Authorization хедъра, както е

показано по-долу:

Proxy-Authorization: Digest

username="petar",realm="domain-


b.com:5060",algorithm=MD5,response="f17f737430b236c73121ecf6a1031518"

Въпреки че, SIP съобщенията осигуряват определено ниво на защита за INVITE и REGISTER съобщенията

разменяни между SIP участниците, те не защитават други SIP методи като CANCEL, BYE и обезпечаващи или финализиращи отговори (напр. 486 Busy Here). От тази слабост може да се възползва нападател, за да промени

отговорите и да осъществи атака. Един от начините на защита е да се криптират сигнализационните съобщения,

ползвайки протокол за сигурност като TLS, S/MIME или IPSec или да се удостоверяват SIP отговорите.

Друго притесненително нещо е SIP удостоверяването между различните домейни, които е възможно да

поддържат различни политики на управление или изобщо да нямат такива. Отговорът, на който е нужно да се

отговори е „Как по правилен начин да се удостовери потребител от домейн А до домейн C, през домейн B?‖.

Слаби места, които трябва да бъдат избегнати при осъществяване на идентификация по SIP

Въпреки че, SIP механизма чрез изискване на автентификация предлага защита от атаки чрез повторение, някои

SIP системи притежават слабости и може да позволят на някой да повтори SIP съобщения и успешно да

преодолее контролите за сигурност. За да се избегнат някои от клопките, трябва да бъдат спазени следните

препоръки:

Генериране на „nonce‖ стрингове, ползвайки псевдо-случайни криптографски функции

Поддръжка на изискване за удостоверяване при съобщения които инициират, модифицират или

прекратяват сесии

Избягване на кеширането или използването наново на потребителски удостоверяващи акредитации

Използване на мрежови или транспортни протоколи за сигурност, за да се предпазят сигнализационните

съобщения (напр. IPSec, TLS, DTLS или S/MIME)

5.2 Транспортен слой за сигурност - TLS

Един от приетите от индустрията протоколи за поддръжка на конфиденциалност на транспортния слой е TLS.

Версия 1.1 на протокола е дефинирана в RFC 4346 и тя осигурява възможността да се изпълни обща

автентификация (клиент и сървър), конфиденциалност и цялост (интегритет). Протоколът е съставен от две

части: TLS Записващ Протокол (TLS Record Protocol) и TLS Договарящ Протокол (TLS Handshake Protocol).

TLS Record протокола цели да поддържа сигурна връзка между две крайни точки (напр. клиент и сървър). Договорката на криптографските свойства (напр. шифри, криптиращи ключове) за съответната връзка се

изпълнява от TLS Handshake протокола, който е капсулиран вътре в TLS Record.

TLS Handshake протокола се ползва за обща клиент/сървър автентификация и за договаряне на криптографски


47

свойства (напр. криптиращи алгоритми и ключове) касаещи респективната сесия. TLS ―ръкостискането― трябва

да бъде напълно завършено преди да се изпрати някаква информация. Протоколът е проектиран, така че да бъде

ползван по надежден транспорт като TCP или SCTP. Това създава пречка пред системи, ползващи UDP като свой

транспорт. В RFC 4347 "Datagram Transport Layer Security" IETF е разгледал решението на този проблем, както е

описано по-долу.

SIP и TLS

SIP RFC-то препоръчва ползването на TLS, за да осигури необходимата защита срещу атаки като подслушване,

подправяне на съобщенията, повторение на съобщенията и т.н. Когато потребителите желаят да проведат

разговор и да запазят определено ниво на конфиденциалност, те могат да ползват SIPS URI (сигурен SIP или SIP

по TLS), за да си гарантират че се ползва сигурен, криптиран транспорт за защита на сигнализационните съобщения между двата потребителя.

Фигура 5.2-1 Пример за употреба на SIPS

Съобщението в SIPS е подобно на SIP (некриптираният вариант) и то бива транспортирано върху UDP, TCP или

STCP. Най-ярките различия са както следва:

Синтаксисът на URI адреса е дефиниран като sips: [email protected].

Транспортът е TLS, вместо UDP или TCP.

SIPS порта е 5061, вместо 5060.

Когато се ползва SIPS, всички SIP съобщения се транспортират по TLS, което осигурява адекватно ниво на

защита срещу атаки като подслушване, повторение и манипулация на съобщенията. Като добавка, TLS

осигурява общо удостоверяване, ползвайки сертификати с цел защита срещу атаки от тип „човек-по-средата―.

Устройството може да удостовери себе си в мрежата, но то също може да удостовери автентичността на SIP

проксито (или регистъра). Препоръчителния набор от шифри за ползване със SIPS e AES, ползващ 128-битов

ключ в CBC (Cipher Block Chaining – Верижката на Шифровия Блок) режим и кода за удостоверение на

съобщението е SHA-1 (с цел предоставяне на интегритет).

Друга ключова полза при употребата на SIPS е възможността за размяна на криптиращи ключове, за шифроване


48

на медийните потоци чрез SRTP (Secure Real Time Protocol). Например, Sdescriptions може да бъде ползван

вътре в SIPS INVITE съобщение за размяна на главния ключ между два участника. Криптиращият ключ е

поддържан от SDP частта от SIPS INVITE съобщението, в a=crypto атрибута. Фигура 5.2-2 предоставя пример за

това.

Фигура 5.2-2. SIPS съобщение съдържащо SDescriptions crypto атрибут

Въпреки че, TLS предоставя конфиденциалност между две крайни точки (взаимоотношение клиент/сървър), той

не поддържа директна конфиденциалност от точка до точка между два отделни потребителя, които са свързани

през междинни SIP проксита. Нужно е да се изгради специална TLS връзка за всеки сегмент. Фигура 5.2-3

илюстрира това взаимоотношение.

Фигура 5.2-3. Защита на SIP съобщение посредством TLS при всеки хоп

Въпреки че, TLS предоставя адекватна защита на SIP съобщенията, той има й своите ограничения. Всяко

междинно прокси се нуждае да направи разбор на SIP хедърите за да го пренасочи по правилния начин, което

означава че съобщението бива разкодирано и TLS(SSL) връзката се прекъсва през всеки „скок― (hop) между

отделните проксита. Ситуацията се усложнява и ако отделните проксита притежават различни политики на

сигурност, например по-слаби и по-силни. Това може да доведе до:

Опитът за осъществяване на разговор може да бъде неуспешен, в зависимост от това каква политика на

сигурност е приложена.

Връзката може да бъде осъществена с по-слаба защита от страна на наборите шифри, от дефинираните

в политиката на потребителя.

Връзката може да бъде осъществена без защита между двете проксита в отделния мрежов сегмент.

Връзката може да бъде осъществена без никаква защита.

Какъвто и да е изхода, крайният потребител най-вероятно няма да бъде уведомен и ще бъде заблуден за нивото


49

на конфиденциалност. Например, ако се проведе международен разговор, не може да бъде гарантирано че

всички междинни доставчици на услуги ще бъдат в състояние да поддържат SIPS, дали поради технологични

или регулаторни ограничения е без значение. Тази липса на поддръжка на конфиденциалност би разкрила

ключовете за криптиране, които се ползват при SRTP, ако договарянето им е установено през SIP, не през SIPS.

От друга страна, потоците медия не се нуждаят да преминават през междинни компоненти, както става при SIP,

освен ако специално не е указано да става така. Вместо това се установява директна peer-to-peer връзка и за тях

конфиденциалността се постига чрез SRTP.

Предимства и недостатъци при ползване на TLS

TLS осигурява няколко свойства за защита на SIP сигнализационните съобщения и може да бъде ползван като

механизъм за обмен на RTP ключове. В същото време са налице и някои ограничения, които трябва да бъдат взети предвид за да бъде ефикасен в конкретната среда.

Предимства

- Поддръжка на обща автентификация чрез сертификати

- Осигурява конфиденциалност и интегритет на съобщенията, което може да предпази срещу

атаки като подслушване, подправяне на съобщенията и повторение

- Повсеместното присъствие на SSL осигурява по-лесна адаптация и по-лесното му въвеждане

- Може да защити договарянето на криптографски ключове

- Доказан протокол, широко разпространен в Интернет приложенията (уеб, имейл, VPN)

- Ниско въздействие върху производителността, в сравнение с други протоколи за сигурност като

IPSec

Недостатъци

- Изисква PKI инфраструктурата да приложи обща автентификация в SSL слоя

- Не осигурява директна конфиденциалност от точка до точка. Изисква прекъсването и

създаването на нова сесия при всеки hop (напр. между SIP проксита или гранично сесийни

контролери)

- Може да бъде ползван при TCP и SCTP но не и при UDP, което се отразява при системи

ползващи UDP. Много от корпоративните мрежи и тези на доставчиците са изцяло UDP базирани

- Допуска DoS атаки като TCP бомбардиране със съобщения и RST (прекъсване на връзката,

reset). Една TCP flood атака тук цели консумацията на системни ресурси (напр. CPU цикли),

изпълнявайки RSA декриптиране. Също така, нападател може да генерира маскирани RST пакети

или TLS записи, за да прекъсне преждевременно дадена връзка

5.3 Инфограмен (дейтаграмен) транспортен слой за сигурност - DTLS

Дефиниран в RFC 4347, DTLS протокола за сигурност е разработен с цел да посрещне нуждите от осигуряване на еквивалентна на TLS защита към протоколите на ниво приложение, но е ориентиран към тези от

приложенията, ползващи UDP като транспорт, като SIP например. Той е подобен на TLS в много отношения,

включително ограниченията за създаване на нови сесии между различните hop-ове. Фундаментална разлика

между TLS и DTLS е, че DTLS предоставя механизъм за справяне с ненадеждността свързана с UDP, като

например вероятността от загуба на пакети и тяхното подреждане в различен ред. Ако подобна загуба на пакет

се случи по време на TLS Handshake, връзката пропада.

Друго ограничение на TLS е, че той ползва MAC (код за удостоверение на съобщение, Message Authentication

Code) за всеки запис с цел защита срещу повторение и объркване на реда на пакетите. MAC се генерира с

помощта на номерацията за последователност в записите, които съществуват за всеки запис. Следователно, ако

се загуби пакет, той прави откриването на повторение безполезно.

DTLS е проектиран да преодолее ограниченията на TLS, чрез осигуряване на следното:

Надеждност по време на DTLS договарянето (избягва се загуба на пакети и разбъркване на реда)

Откриване на пакетно повторение

За да компенсира условията при загубата на пакети, DTLS предоставя таймер за рестрансмисия. Когато

клиентът изпрати съобщение ClientHello, то стартира таймера и изчаква съобщение HelloVerifyResponse от

сървъра. Сървърът също поддържа такъв таймер. Ако таймера на клиента изтече, то тогава той приема че или

ClientHello или HelloVerifyResponse е бил загубен и изпраща съобщението ClientHello наново. Фигура 5.3-1


50

описва сценария при загуба на пакет и повторното му изпращане.

Фигура 5.3-1. Загуба на DTLS пакет и повторното му изпращане

От друга страна, сървърът няма да изпрати наново HelloVerifyResponse съобщението, преди да получи

повторното клиентско ClientHello.

За откриване на повторения, DTLS протоколът препоръчва ползването на таблица със записи на това което е изпратено от клиента и сървъра респективно. Например, при ползване на таблица с 32 записа това би

означавало, че ще бъдат обработени последните 32 записа. Всичко до преди 32-рия запис ще бъде изоставено и

всичко над него ще бъде проверено.

Въпреки че, изборът за големина на таблицата-получател зависи единствено от настройката на системата, RFC

4347 ограничава поддръжката до минимална стойност от 32 записа. Това е така, защото повторението на пакети

не винаги е злонамерено и може да се случи поради грешки в маршрутизацията.

Друг атрибут на DTLS е употребата на техниката „stateless cookies‖, за защита от DoS атаки. По време на

първоначалната размяна на съобщения (напр. ClientHello и HelloVerifyRequest), сървърът включва cookie по

време на своя отговор, за да провери че заявката произлиза от отсрещния клиент, а не от някой който се

представя за него. Легитимният клиент трябва да калкулира друг cookie, базиран на информацията получена от

сървъра и генерира ново ClientHello съобщение, което включва клиентския cookie. Калкулирането става с помощта на MD5 върху стойността на secret, клиентския IP адрес и клиентските параметри, получени в

ClientHello съобщението. Този механизъм помага да се смекчи ефекта от DoS атаки чрез отражение, където

нападателят ползва подправени IP адреси, за да бомбардира жертвата с отговори от сървъра.

Силни и слаби страни на DTLS

DTLS протоколът спомага за смекчаване на някои от пропуските, асоциирани с мултимедийните приложения,

като напр. ранна медия и разклонение на потока, докато доставя защита за сигнализационни и медия

съобщения. Следният списък подчертава неговите силни страни и ограничения, които трябва да се имат

предвид по време на въвеждането му в употреба или оценяването на ефективността му в специфичните среди:

Силни страни

По-лесен за въвеждане, в сравнение със S/MIME и IPSec

Унаследява доказани свойства на сигурността от TLS

Осигурява механизми за компенсиране на ограниченията на TLS, относно надеждността на handshake и

откриването на повторения

Защита към DoS атаки, благодарение на stateless cookies

Ограничения

Изисква установяването на нова крипто-сесия, между преходните hop-ове, подобно на TLS

PKI инфраструктурата трябва да изиска обща автентификация

Не осигурява директна конфиденциалност от край до край, изисква прекъсването и създаването на нова

сесия при всеки hop (напр. между SIP проксита или SBC)

5.4 S/MIME

Дефинирани в RFC 3851, Сигурните/Многоцелни Интернет Пощенски Разширения (Secure/Multipurpose Internet

Mail Extensions), могат да осигурят конфиденциалност от край до край, интегритет и удостоверяване на


51

приложенски протоколи като SMTP и SIP. MIME дефинира набор от механизми за кодиране и представяне на

сложни съобщителни формати като прикрепени мултимедийни файлове (напр. графики или аудио и видео

клипове) и лингвистични символи (напр. гръцки, китайски) вътре в други протоколи като SMTP или SIP. Всяко

S/MIME съобщение е базирано на MIME, но то също така обединява PKCS стандартите, за да посрещне целите

на сигурността (напр. PKCS#7 стандарт за криптографски синтаксис на съобщения, обхванат в RFC 3852). Тази

комбинация (MIME и S/MIME) осигурява изключително ниво на гъвкавост при поддръжката на размяна на

сложни съобщения, наред с конфиденциалност, цялост и автентичност. В същото време, възможността да

осигури такава „зърнеста― защита, добавя високо ниво на сложност при въвеждането им.

S/MIME и SIP

S/MIME може да бъде ползван за защита на хедърите на едно SIP съобщение, с изключение на хедъра „Via‖, и да донесе конфиденциалност от край до край, интегритет и автентификация между различните участници. За

разлика от TLS и DTLS, S/MIME осигурява гъвкавостта и нуждата от по-модулна защита на информацията в

хедърите на SIP съобщенията. Както е описано в предишните пасажи, TLS и DTLS осигуряват адекватна защита

на SIP съобщенията, но те съдържат цялото съобщение вътре в своята структура. S/MIME позволява избираемо

да бъдат защитени порции от SIP съобщението, той може да бъде ползван както по TCP, така и по UDP, което

преодолява ограниченията срещани при ползване на IPSec, TLS и DTLS, и също така създава защита от крайна

точка до крайна точка. Фигурата долу изобразява SIP съобщение с криптирана SDP част, ползващо S/MIME.

Фигура 5.4-1. Защита на SIP съдържанието чрез S/MIME

В посочения пример, SIP съобщението остава същото, с изключение на SDP частта, която бива криптирана. Това

позволява на крайните потребители да защитят информацията за своята сесия, като ползваните за пращане и

получаване на медия UDP портове например, криптиращи ключове (напр. ползвайки SRTP), и допълнителни

показатели относно обсега на сесията (напр. тема, участници, URL-и, други ресурси и т.н.).

Външната част от SIP съобщението съдържа информация (напр. From, To, Contact, Via), която може да бъде

използвана от междинни точки за рутиране на съобщението до крайната цел. Външният From хедър съдържа информация, която осигурява анонимност на истинския изпращач на съобщението. В допълнение, Contact

хедъра на външната порция съдържа само домейна на изпращача, но не и точното местонахождение, което е

показано във вътрешната част, която пък е криптирана.

Реципиентът декриптира S/MIME съобщението и ползва стойността от вътрешния From като индекс, за

намиране и проверяване на идентичността на инициатора, като изпраща заявка до органа, удостоверяващ

сертификата на потребителя, ползвайки публичния ключ на изпращача. Целостта на съобщението може да бъде

проверена чрез инспекция на добавения подпис. Очевидно е, че за да обработят успешно SIP съобщения с

S/MIME обекти в тях, крайните устройства като хардуерни телефони например, трябва да поддържат S/MIME.

За съжаление, много голяма част от тях не поддържат S/MIME, с изключение на някои академични разработки

на софтуерни телефони. Като допълнение към всичко това се изисква и PKI инфраструктура, за да се поддържат

функциите на S/MIME, изискващи употребата на сертификати (напр. подписване, проверка, удостоверяване и

т.н.).

Възможността за селективна защита на SIP съобщенията преодолява проблема на прокситата с анализиране и в

някои случаи модифициране на SIP хедърите с цел рутиране, което води до прекъсване на криптираната


52

комуникация при TLS, DTLS или IPSec. Това води до пълнота в конфиденциалността от край до край.

SIP системите, ползващи S/MIME би трябвало да поддържат 3DES като криптиращ алгоритъм и SHA1, като

алгоритъм за цифровия подпис, като това е минимално изискване. В RFC 3853, IETF обсъжда употребата на

AES със S/MIME при SIP системи. AES алгоритъмът е доста по-ефективен в криптографските калкулации, и той

е бил проектиран така че да намали консумацията на ресурси, което е идеално за мобилни устройства.

Следователно е препоръчително въвеждането на AES с минимална поддръжка на 128 битови ключове. В секция

23 на RFC 3261 се разглеждат детайли, относно това как се въвеждат различни механизми на защита при

S/MIME и SIP.

Предимства и недостатъци на S/MIME

S/MIME протоколът осигурява много високо ниво на защита на сигнализационните съобщения, но неговата сложност би била значителен фактор и би ограничила въвеждането му в много VoIP среди. Следният списък

изброява накратко силните и слабите му страни:


Независим откъм транспорта и може да бъде ползван с UDP и TCP

Осигурява голяма гъвкавост в начина, по който защитава отделни порции от SIP съобщенията

Осигурява конфиденциалност от край до край, както и интегритет и автентификация


Изисква повече усилия при въвеждане, поради сложността си и инфраструктурните си изисквания

(напр. PKI), в сравнение с други протоколи като TLS и DTLS.

Не е широко разпространен. Може би бъдещите разработки при мрежовите протоколи ще позволят по-

лесната му интеграция в сегашните инфраструктури

Мащабността му е под въпрос, тъй като изисква PKI инфраструктура

5.5 Криптиране

Криптирането на VoIP трафика се осъществява на две части – в сигнализационния и в медийния слой. Тъй като

удостоверенията се извършват в сигнализационния, а аудио пакетите се предават в медийния слой, ако например

се криптира сигнализацията, медията може да остане незащитена и обратно. При всички случаи може да се

ползват следните методи за криптиране на VoIP мрежите:

IPSec: Може да бъде ползван в шлюзове, работещи в режим от точка до точка с цел защита на VoIP трафика по

Интернет или публични или недоверени мрежи. В често случаи не се ползва между крайните точки, поради

липсата на поддръжка от страна на VoIP клиентите.

SRTP: Може да бъде ползван наред с AES (Advanced Encryption Standart) за защита на медийния слой по време

на VoIP разговори.

Забележка: В често случай, когато се ползва SRTP, ключът бива пратен по мрежата в прост, текстов вид по SIP или H.323. Много важно условие е да се ползва SSL, за да се постигне пълна защита.

SSL: VoIP протоколите могат да бъдат „опаковани― със SSL (SIPS) или Stunnel (H.323) с цел защита на

сигнализацията.

5.6 IPSec

IPSec е доказан и широко разпространен протокол за сигурност, той осигурява защита на приложения ползващи

както TCP, така и UDP като свой транспорт. Той може да бъде ползван в тунелен или транспортен режим за

защита на своя товар. Тъй като той може да се приложи навсякъде, тук ще се фокусирам основно върху

аспектите от употребата му в SIP. IPSec осигурява конфиденциалност, интегритет и удостоверение на

сигнализационните и медия съобщения, чрез създаване на защитени тунели между крайните точки. Фигура 5.6-

1 демонстрира употребата му в една SIP среда.


53

Фигура 5.6-1. Защита на SIP чрез IPSec

Създаването на трите различни IPSec тунела може да отнеме средно ~2.7 секунди за всяка IPSec връзка

(приблизително 5 до 6 секунди за целия IPSec тунел). Изследване, проведено от Telcordia Technologies е

демонстрирало че създаване на разговор отнема ~20 секунди (от едната до другата страна и обратно). Това е напълно неприемливо, тъй като стандарта в комуникационната индустрия предвижда време от порядъка на не

повече от 250ms. В нормалния случай, пътят на медията (RTP) се създава директно между двете крайни точки

и отнема средно ~10 милисекунди, което е незначително. Този пример демонстрира, че употребата на IPSec не е

възможна при динамично разпределени сесии, тъй като времето необходимо за преминаването на

сигнализационните съобщения през междинните hop-ове е далеч по-голямо от средното време, което

потребителят би изтърпял за самото създаване на разговора.

Ако пък съществуват вече изградени IPSec асоциации, почти няма закъснение при рутирането на

сигнализационните съобщения, което показва че VoIP по IPSec VPN е напълно осъществим сценарий. В някои

случаи, IPSec тунелите трябва да бъдат създадени наново и разпадат поради мрежови, софтуерни или хардуерни

грешки, неактивност или договаряне на ключове, което може да се отрази и на разговорите. Най-общо обаче,

IPSec е в състояние да защити адекватно VoIP трафика между мрежите, в които има вече изградени IPSec

тунели. Обикновено, IPSec тунелите между отдалечени точки остават стабилни тъй като постоянно преминава трафик по тях и те не биват разпадани поради неактивност. Това не е така при VoIP телефоните, които ползват

IPSec за защита на сигнализационните и медия съобщения. За да се реши този проблем, точките изпращат чести

регистрационни съобщения до своя локален регистър, с цел да се поддържа непрекъснато IPSec тунела.

Предимства и недостатъци на IPSec

IPSec е ефективен в предоставянето на удостоверяване и конфиденциалност на съобщенията, носещи

сигнализация и медия. В същото време, съществуват ограничения които оказват влияние върху

производителността на мултимедийните комуникации. Следният списък ги обобщава:


Доказан протокол за сигурност, широко разпространен

Работи в мрежовия слой, така че поддържа UDP, TCP, SIP и RTP

Осигурява стрингова защита срещу различни видове атаки, като подслушване, маскарадинг, DoS и други

Осигурява конфиденциалност, интегритет, автентификация


Изисква повече усилия за въвеждането му в употреба, както има и инфраструктурни изисквания (напр.

PKI), в сравнение с други протоколи като TLS или DTLS

Изисква PKI инфраструктурата да поддържа автентификация на крайни устройства, интегритет и

конфиденциалност, но не непременно защита на VoIP елементите (напр. VPN връзка между мениджъра

на повикванията и гласовите шлюзове).


54

Междинните компоненти трябва да бъдат доверени

Не се вписва добре при приложения като конферентни връзки

5.7 Механизми за защита при H.323

H.323 са серия от препоръки на ITU, от които H.225.0, H.245 и H.235.x са най-приложими тук от техническа

гледна точка. Препоръка H.225 съдържа две под-части, едната от които дискутира RAS (регистрация, допускане

и статус), а другата сигнализацията на разговора. Сигнализацията се ползва между H.323 крайни точки за

създаване и прекратяване на връзки и е подобна на ITU Q.931 препоръката. RAS препоръката се ползва от GK за

управление на крайни точки в неговата зона, като крайните точки трябва да ползват RAS за регистрация в

съответния GK и да придобият достъп до мрежови ресурси и услуги. Едно архитектурно различие между RAS и

сигнализацията е, че RAS се транспортира по UDP, докато сигнализацията както по UDP, така и по TCP. Поради тази причина са приложими различни видове атаки, носещи различна успеваемост. H.245 спецификацията е

контролен протокол, ползван между две или повече крайни точки за управление на потоци медия между

участниците в една сесия. Неговата основна цел е договарянето на параметрите на медията между крайни

точки, като RTP IP адрес, портове, кодеци (напр. G.729, G.711) и т.н. Всеки от трите протокола, H.225, RAS и

H.245 се ползват за създаване, модифициране и терминиране на сесии.

H.235 препоръката дискутира услуги за защита като удостоверяване и поверителност (криптиране на

информацията) при H.323 системи, които ползват H.245 и H.225.0, за създаване на конференции от точка до

точка или от точка до много точки. Последната версия на H.235 (v4) отделя препоръките за сигурност в H.235.1

до H.235.9 различни секции. По-ранните версии описват контроли за сигурност като Aнекси от A до F.

Таблицата долу предоставя списък на всяка препоръка и съответната й цел.

Таблица 5.7-1 H.235 препоръки за защита

Препоръка Описание

H.235.0 Рамка за сигурност за H сериите (H.323 и други H.245 базирани) мултимедийни

системи

H.235.1 Основен профил за сигурност

H.235.2 Профил за сигурност на подписа

H.235.3 Хибриден профил за сигурност

H.235.4 Директна и избираема защита за рутиране на повиквания

H.235.5 Рамка за защитено удостоверение в RAS, чрез използване на слаби, незащитени

пароли

H.235.6 Профил за гласово криптиране с вградено управление на H.235/H.245 ключове

H.235.7 MIKEY + SRTP профил за сигурност

H.235.8 Обмен на ключове при Secure RTP, ползвайки обезопасени сигнализационни

канали

H.235.9 Поддръжка на защита при H.323 шлюзове

Типичното създаване на разговор при H.235 отнема между 300 и 400ms, в зависимост от системата (H.323

хардуерен или софтуерен телефон).

H.235.0 рамка за сигурност

Защитата на сигнализацията се постига чрез ползването на TLS (RFC 2246/3546) или IPSec (RFC 2401 в режим

ESP). IPSec обаче може да не е напълно подходящ метод за удостоверяване на потребители в средата на един

доставчик на VoIP услуги, където може да се наложи употребата на милиони сертификати, там TLS би се вписал

по-добре. В същото това време, пак в зависимост от средата, могат да бъдат въведени H.235 профилите от 1 до

9. Профилите биват договорени по време на обмена на H.323 сигнализационни съобщения (напр. RRQ

съобщение до GK) и те се съдържат в обектните идентификатори.

При H.235 се извършва удостоверяване в три определени случая:

По време на първоначалното повикване


55

В процеса на защита на H.245 канала

По време на обмен на сертификати за H.245 канала

Както бе споменато по-рано, удостоверяването може да бъде част от сигурността на мрежовия или транспортен

протокол, но също така може да бъде въведено и при H.323 приложенията или услуги, с цел допълнителна

защита. Препоръките обсъждат следните опции за едностранна или обща автентификация, при провеждане или

създаване на разговори:

Удостоверяването, базирано на сертификати се основава на механизъм за обмен на сертификати, с цел

автентификация на потребителя в мрежата (не само на устройството). Не се посочва механизъм за

проверка да информацията, като той е оставен на този който въвежда системата в употреба.

Удостоверяване чрез споделена тайна, може да бъде приложено ползвайки H.225.0 сигнализационни съобщения. Този вид автентификация може да бъде създадена, чрез употребата на обмена на ключове на

Diffie-Hellman, за да криптира и размени споделената парола.

Удостоверяване, ползвайки свойствата на отделен протокол за сигурност като TLS или IKE.

Контролът на повикванията, H.245, също би трябвало да се зашити с договорения алгоритъм на криптиране, с

цел да се защити информацията за сесията. Първоначалното договаряне на криптографски алгоритми и

дистрибуция на ключовия материал се извършва през H.245, чрез съобщенията OpenLogicalChannel или

OpenLogicalChannelAck. По-нататък, договарянето на нови ключове може да бъде извършено със следните

H.245 команди:

EncryptionUpdateCommand се ползва от главната точка (master) за дистрибуция на сесиен ключ

EncryptionUpdateRequest се ползва от подчинената точка (slave) за поискване на нов сесиен ключ

EncryptionUpdate се ползва от главната точка (master) за дистрибуция на нов сесиен ключ

EncryptionUpdateAck е отговора на подчинената за потвърждение на новия ключ

Дистрибуцията на ключовия материал се защитава от H.245 канала, като той оперира в режим на частен канал

или чрез защитата на ключовия материал ползвайки сертификати.

H.235.1 основен профил за сигурност

Този профил за сигурност осигурява поддръжка за удостоверяване и интегритет на H.245, H.225.0 RAS и

сигнализационните съобщения на повикването. Интегритета се създава чрез разбъркване (hashing) на всички

полета в съобщението. Препоръката предоставя също и опция за въвеждане на удостоверение без наличие на

интегритет. Това би било подходящо в случаи, когато сигнализацията преминава през NAT (Network Address

Translation) устройство, което води до загуба на валидността на оригиналното съобщение (тъй като NAT го

пренаписва). Искането за удостоверение се обработва с HMAC-SHA1-96 за постигане на 20 байтова, хеширана

(разбъркана) парола. Удостоверяването между крайната точка и GK е базирана на определен ключ, който може да бъде различен от ползвания за защита на сигнализацията, в някои случаи дори се изисква ключовете да бъдат

различни. В препоръката са дискутирани три начина, по които може да се извърши автентификация на H.225

сигнализационните съобщения:

Маршрутизиран през GK (Gatekeeper routed) — Оторизационните ключове за ползване от крайните

точки, преминават през съответните GK.

Директен — Оторизационният ключ за ползване от крайните устройства се предава директно между

крайните точки.

Смесен — Всяка точка маршрутизира ключа през съответния GK.

H.225 (RAS и сигнализационните) съобщения получават удостоверяващата и криптираща акредитация, от

сърцевината на по-обхватна структура, наричаща се cryptoTokens, а H.235.1 препоръката предоставя

допълнителна информация за това как точно се предават полетата в H.225 съобщенията.

H.235.2 профил за сигурност на подписа

Това е препоръка за профил, който не е задължителен и който въвежда цифрови подписи при H.225.0

сигнализационните съобщения, чрез ползването на SHA1 и MD5 като алгоритъм за разбъркване (hashing). Тази

препоръка предоставя по-добра мащабируемост и по-добра възможност за управление, в сравнение с H.235.1,

защото в среди с много терминали може да бъде ползвана асиметрична автентификация. В същото време този

механизъм може да бъде ползван за обмен на тайния ключ за криптиране на RTP трафика (глас и видео).

Препоръката определя процедури за следното:


56

Цифрови подписи, ползващи публични/частни чифтове ключове

Конференции между няколко точки

Удостоверение от край до край

Само автентификация

Оперирането със сертификати

Изброените процедури могат да бъдат ползвани за защита на H.225 (RAS частта и информацията на

сигнализацията) и H.245 съобщения.

H.235.3 хибриден профил за сигурност

Той ползва комбинация от препоръки от H.235.1 и H.235.2 с цел изграждане на мащабируем профил, базиран на

PKI сертификати. H.235.3 взема силните страни от споменатите два профила, и е създаден за поддържане на големи корпоративни VoIP системи.

Този профил указва употребата на GK-рутиран модел, при който всички съобщения се маршрутизират през

локалния gatekeeper, вместо да бъдат изпращани директно към крайните точки. За прилагането на мобилност на

потребителите и приложенията, чувствителни откъм време, се ползва метода за сигнализация за бърза връзка

(fast-connect). По-нататък, той поддържа тунелизация на H.245 контролните съобщения на разговора вътре в

H.225.0 сигнализационните съобщения, което осигурява вградена защита.

Процедурите, описани в H.235.3 включва следното:

Hop-by-hop защита (комбинирайки H.235.1 клауза 7 и процедура II от H.235.2 клауза 7)

При няколко паралелни разговора между два участника (напр. конферентен разговор, или връзка между

два GK), се поддържа употребата на един ключ, който да се грижи за криптирането на всички потоци

Обновяване на ключ, с цел поддържането на периодично опресняване

Тъй като всички тези процедури за криптиране натоварват неимоверно много процесора е дефиниран отделен

процесор за сигурност (GKSP – Gate Keeper Security Processor).

H.235.4 режисирано и избираемо рутиране за защитени повиквания

Този профил се опитва да осигури гъвкава алтернатива на GK-рутирания модел, когато се търси подобрение на

производителността и мащабируемостта, в случаите когато се обработват няколко паралелни канала. Фигура

5.7-1 изобразява тази конфигурация.

Фигура 5.7-1. H.235 защитено рутиране на разговор от точка до точка

Посочената конфигурация приема, че крайните точки комуникират по незащитена мрежа. Всяка от крайните точки е изградила взаимоотношение на доверие със своя GK през RAS сигнализация, а понякога и двата GK

също изграждат доверено взаимоотношение помежду си по RAS. Това взаимоотношение позволява на двете

крайни точки да договорят споделен ключ по незащитена мрежа, за да предпазят сигнализационните съобщения

и потоците медия. Това е подходящо в средите, където се изисква директно установяване на разговора между

крайните точки, и GK се концентрира върху управлението на регистрациите, допускането, адресната резолюция

и контрол на скоростта. Препоръката предлага следните процедури за избраното маршрутизиране на разговора:

Корпоративна среда (DRC1)

Интердомейн среда I (DRC2)

Интердомейн среда II (DRC3)


57

В допълнение, препоръката предлага следните процедури за деривация на ключове:

PRF базирана процедура за деривация

FIPS 140 базирана процедура за деривация

И двете процедури дефинират как да се извлече информацията за ключа от споделената тайна, както и други

параметри в директен и избираем рутиращ сценарий.

H.235.5 рамка за защитено удостоверение в RAS, чрез използване на слаби, незащитени пароли

Препоръка H.235.5 ни запознава с рамка чрез която крайна точка и нейния GK, или между два GK, може да се

ползват RAS съобщения за да преговорят набор от силни, споделени пароли помежду си, а след това да ги

използват за криптиране и удостоверяване на избрани части от последващия RAS и сигнализационните

съобщения. Този метод се прилага единствено към GK-рутиран режим, не към директно рутирана сигнализация.

В рамката биват дискутирани два профила:

Специфичен профил за защита (SP1), който се ползва за конструиране на еквивалент на споделената

тайна в 80 битов произволен номер (вж. NIST SP 800-57)

Подобрен профил за сигурност (SP2), който е базиран на SP1, но сред останалите препоръки той

предлага подобрения за защита срещу речникови и атаки чрез повторение

SP2 въвежда употребата на последователна сигнализационна номерация на повикванията, за защита срещу

атаки чрез повторение и отражение. Защитата срещу речникови атаки се постига, чрез генерирането на нов

ключ който ползва оригиналната парола и pointID на крайната точка като добавка:

K = Trunc(SHA1(user_password || end pointID), 16)

Trunc(SHA1,16) скъсява резултатния стринг на SHA1 до 16 октета.

H.235.6 профил за гласово криптиране с вградено управление на H.235/H.245 ключове

Този профил за гласово криптиране се ползва в съгласие с H.235.0 основният профил за сигурност, с цел да

предостави конфиденциалност на потоците медия. Криптиращият профил бива разменян между крайните точки

като част от договарянето на терминалните свойства. Той може да ползва множество криптиращи алгоритми, включително AES, RC2, DES или 3DES, ползвайки OFD (Output Feed Back mode, ISO/IEC 10116). Договарянето

на криптиращите алгоритми става през H.245, където всеки алгоритъм може да бъде приложен върху

специфичен кодек и заедно да формират определено свойство на крайната точка.

За поддръжката на мобилни и чувствителни към закъснение приложения (напр. видео, игри и глас), се въвежда

употребата на сигурност при fast-connect. Препоръката, също така дискутира криптирането на DTMF (Dual Tone

Multi Frequency). При H.323 DTMF тоновете могат да бъдат пренасяни в сигнализационните съобщения или

RTP, докато в SIP или MGCP системите те се пренасят вътре в RTP канала. При H.323 системите, където DTMF

тоновете се пренасят в RTP (чрез rtpPayloadIndication), е препоръчително RTP товара да бъде криптиран, защото

декодирането на DTMF от некриптирания трафик е елементарна задача.

За обмен на ключове между H.323 участници, препоръката предлага следните два транспортни механизма:

Опростен транспорт на ключа - осигурява на крайните точки по-ранна версия на H.323 (версия 1 и 2),

посредством полето KeySyncMaterial

Подобрен транспорт на ключа - за елиминиране на слабите места срещани при опростения метод се

въвежда ECNRYPTED операция

Методът за бърз старт се ползва за договарянето на възможностите за сигурност между крайните точки и

създаване на споделена тайна (Diffie-Hellman) при старта на разговора. Ключът по Diffie-Hellman след това се

ползва като главен за дистрибуция ключ за сигурност за криптиране на медия (RTP) сесиите.

Представя се механизъм за подтискане на DoS атаки срещу потоци медия (антиспам), при който получателят

удостоверява RTP пакетите, ползвайки удостоверяващия код на съобщението през определени полета от RTP

пакета. Този механизъм се прилага и при системи, където медия потоците са криптирани и такива при които не

са. Ако не са, получаващата страна калкулира MAC на RTP хедъра (вкл. номерацията на последователността и

клеймото), чрез използване на договарящия алгоритъм (в полето antiSpamAlgorithm).


58

Фигура 5.7-2. Пример за H.235.6 RTP удостоверяване при anti-spam защита

Ако RTP пакета е криптиран, антиспам механизмът трябва да провери автентичността на пакета преди да

започне декодиране на товара. Въпреки че, RTP хедъра не е криптиран, хедърите на аудио и видео кодеците би

трябвало да бъдат криптирани.

H.235.7 използване на MIKEY протокола за управление на ключове при Secure RTP, вътре в H.235

Препоръката дискутира следните два профила за сигурност:

Симетрична ключово-базирана инфраструктура за сигурност, поддържаща няколко gatekeeper-а

Асиметрична ключово-базирана инфраструктура за сигурност (PKI), поддържаща няколко gatekeeper-а

Фигура 5.7-3 е логическо изображение за употребата на MIKEY вътре в H.323 среда.

Фигура 8.7.8-1. Употреба на MIKEY в H.323

MIKEY съобщенията се пренасят вътре в H.245 договарящите сигнализационни съобщения до крайните точки,

видими за междинните GK. Договарящите съобщения включват TerminalCapabilitySet, RequestMode,

OpenLogicalChannel и MiscellaneousCommand.

MIKEY протокола може да бъде приложен на сесийно ниво вътре в H.323 (за няколко медия потоци) и медийно

ниво (определен логически канал).

Като допълнение, профилът осигурява възможността за преговаряне на ключов материал чрез употребата на

симетрични и асиметрични техники. В случая, когато се ползват предварително споделени ключове, за да се

поддържа MIKEY се въвежда H.235.1 основата между hop-овете.

H.235.8 обмен на ключове при Secure RTP, ползвайки обезопасени сигнализационни канали

Профилът се фокусира върху уникаст комуникациите и ITU планира да въведе допълнителни опции за

мултикаст в бъдеще време. Полето SrtpCryptoCapability се ползва за анонсиране на SRTP възможностите на

H.323 терминала и може да бъде използан по време на договарящата фаза. Посоченото подполе, се намира вътре

в полето genericH235SecurityCapability, под секция encryptionAuthenticationAndIntegrity на H.245 съобщението.

В SrtpCryptoCapability се съдържа подполе SrtpCryptoInfo, указващо крипто комплекта и сесийните параметри

за съответната мултимедийна сесия.

Ключовият материал за ползване в SRTP се разменя през SRTP крипто параметъра SrtpKeyParameters, който е

подполе на SrtpKeys и се предава чрез H.245 OpenLogicalChannel съобщението. Авторите на H.235.8 са

проектирали SRTP крипто параметъра, така че да може да създаде SRTP криптографските параметри в едно

единствено или в единствена двупосочна размяна на съобщения. По този начин се елиминира договарящата


59

фаза.

Криптографията по подразбиране в H.235.8 е AES в броячен режим и ползва дължина от 128 бита.

Удостоверяващия алгоритъм по подразбиране е SHA1, с дължина от 80 или 32 бита. В допълнение бива

поддържан AES f8 със 128 битов ключ, а също така и SHA1 с 80 битова дължина при UMTS (Universal Mobile

Telecommunications System).

H.323 притежава същите проблеми с ранната медия и разклоняването на сигнализационни заявки като SIP.

Проблемът с ранната медия (early media) се състои в това, че след като първоначалната заявка се изпрати към

отсрещния терминал, терминалът изпращач може да получи медия (ранна) от повиквания терминал преди да е

получен реален отговор (напр. поради клипване или закъснение), и съобщението-отговор се състои в това какви

крипто параметри се поддържат от отсрещния терминал. Следователно, терминалът източник на повикването трябва да може да обработи подобен сценарии, защото той не знае кой точно ключ ползва отговарящия

терминал за криптиране на медията и в този случай, стандартът препоръчва ползването на механизъм като

H.460.11 забавени процедури за осъществяване на разговор.

H.235.9 поддръжка на защита при H.323 шлюзове

ITU въвежда препоръка H.235.9, която описва начините да се избегнат споменатите проблеми разрешавайки на

защитният шлюз да манипулира сигнализацията и медия съобщенията, когато е необходимо.

Защитният шлюз трябва да изгради взаимоотношение на доверие с локалния GK който получава, обработва,

модифицира и препраща сигнализационните и медия съобщения. Тази връзка се изгражда, когато шлюзът се

регистрира в локалния GK и тя позволява на шлюза да придобие достъп до удостоверяващия ключ, договорен

между GK и крайната точка, желаеща да изпрати съобщения. Имайки достъп до ключа, шлюзът може да

манипулира публична информация (напр. транспортни адреси) в сигнализационните съобщения и да регенерира

удостоверяващата информация на съобщението преди да го препрати към дестинацията.

Възможността за модифициране на свойствата на протоколите за сигурност (напр. TLS, IPSec) е уязвима откъм

атаки за понижаване на сигурността. Например, ако крайна точка е способна да поддържа защита на медия

съобщенията ползвайки различни механизми (напр. DES, AES и изкл. подобна опция) и параметри (дължина на

ключа 64, 128, 192, 256), шлюз за сигурност контролиран от нападател може да опита понижаване нивото на

сигурност до „изключена опция на криптиране―, с цел достъп до RTP трафика. Препоръчително е локалната

политика за сигурност да бъде настроена изрично да ползва дадено ниво на сигурност, без възможност за

отклонение по време на договарянето и в никакъв случай избиране на по-слаб механизъм.

В допълнение, притежаването на достъп до договорения ключ между крайното устройство и GK предоставя

възможност за атака. В шлюзовете за сигурност трябва да бъдат приложени пароли и да се следват процедурите

за удостоверяване, водещи до обща автентификация между GK и регистриращият се GW, трябва да се следват

препоръките дефинирани в H.235.1, H.235.2, H.235.3, и H.235.5.

Предимства и недостатъци на H.235

Следният списък предоставя обобщение на силните и слабите страни, които трябва да се имат предвид, когато

се проектира VoIP мрежа или се тества дадена VoIP система:


Може да достави сигурност от край до край, в зависимост от комбинацията на препоръките за

сигурност (профили), които се ползват

Може да поддържа сигурност при мултикаст и уникаст

Може да предостави защита срещу различни видове атаки, ползвайки комбинации от H.235 профили,

включително DoS атаки, атаки човек-по-средата, атаки с повторение, подмяна, отвличане на връзката и

подслушване


Не е достатъчно мащабируем при Интернет комуникации

По-високо ниво на сложност при въвеждане от SIP

H.235 не е често срещан, а ако е наличен, съвместимостта между различните производители е под

въпрос


60

5.8 Механизми за защита на MGCP

MGCP (Media Gateway Control Protocol, RFC 3435) се ползва от PSTN шлюзовете за създаване на разговори

между IP мрежи или между IP мрежи и PSTN. В някои случаи, PSTN шлюзът може бъде разделен на

сигнализационен и медиен шлюз. Тук, аз ще считам че той е комбиниран в един компонент и ще го наричам

PSTN шлюз. Фигура 5.8-1 изобразява позицията на PSTN шлюза в мрежата.

Фигура 5.8-1. Позициониране на PSTN шлюз в една конвергентна мрежа

MGCP протоколът не предоставя никакви контроли за сигурност, но той препоръчва ползването на протокол

като IPSec за постигане на необходимата защита. Отвореността на MGCP позволява да бъдат проведени

различни видове атаки срещу шлюза в мрежата.

Препоръки за защита срещу MGCP атаки

Следният списък представлява препоръки, които са ефективни за защита срещу атаки по MGCP:

Указване на мрежовите ACL с цел да се ограничи достъпа до MGCP портове от неоторизирани

източници. Това защитава срещу злонамерени опити да се манипулират съществуващи сесии.

Дефиниране на взаимоотношения от точка до точка между мениджърите на повиквания (или агенти на

повиквания) и PSTN шлюзовете за обмен на MGCP съобщения.

Ако PSTN шлюза поддържа IPSec, задължително тази опция се включва и се криптира трафика между

мениджърите на повиквания и PSTN шлюзовете.

Предимства и недостатъци на MGCP


Мащабируем за корпоративни и мрежи на доставчици

От гледна точка на защитата, няма никакви силни страни освен препоръката в самия стандарт да се

ползва IPSec


Не предоставя удостоверяване, интегритет или конфиденциалност за защита на съобщенията

Ползва UDP транспорт и следователно няколко вида атаки са актуални (напр. маскиране на съобщения)

5.9 Механизми за защита на медията

Стандартният протокол за обмен на медия е RTP (Real Time Protocol), който е дефиниран в RFC 3550. Въпреки че, IPSec е възможно да бъде ползван за защита на RTP, неговите лимитации изискват по-мащабируемо и

гъвкаво решение, което преодолява проблема с преминаването през NAT, динамичното разпределение на

сесиите и необходимостта от PKI. Това е довело до създаването на SRTP (Secure Real Time Protocol). Употребата

на SRTP изисква механизъм за обмен на криптографски ключове преди изпращането на някаква медия.

SRTP

SRTP (Secure Real Time Protocol) е профил на RTP (RTP, IETF RFC 3550) с цел да осигури конфиденциалност,

интегритет и удостоверяване на потоците медия и е дефиниран в IETF RFC 3711. Въпреки че, съществуват

няколко сигнализационни протокола (напр. SIP, H.323, Skinny) и няколко механизма за обмен на ключове (напр.

MIKEY, SDESCRIPTIONS, ZRTP), SRTP е считан за един от стандартните механизми за защита на медия в

реално време (глас и данни) в мултимедийни приложения. Като допълнение към защитата на RTP пакетите, той

осигурява защита на RTCP (Real Time Transport Control Protocol) съобщения. RTCP съобщенията се изпращат


61

отделно от RTP, като се ползват и отделни портове за двата протокола. Следователно и RTP, и RTCP се нуждаят

от защита по време на мултимедийната сесия.

Проектантите на SRTP са се фокусирали върху разработването на протокол, който осигурява адекватна защита

на потоците медия, но също така управлява ключови свойства за поддръжка на жични и безжични мрежи, при

които може да съществуват ограничения откъм прилежащия транспорт или скоростта на канала. Някои от

подчертаните възможности на SRTP са както следва:

Възможността за обединяване на нови криптографски функции

Поддръжка на ниска скорост и високо натоварване

Консервативен в големината на ползвания код. Това е полезно при устройства с ограничена памет (напр.

мобилни телефони)

Независимост на прилежащия транспорт, вкл. мрежови и физически слоеве

Даденото приложение, което ползва SRTP трябва да конвертира RTP пакетите в SRTP преди да ги изпрати по

мрежата. Същия процес се ползва по обратния път - декриптиране на SRTP пакетите и превръщането им в RTP.

След като приложението улови мултимедията от входа на устройството, то кодира сигнала ползвайки

договорения или кодиращия по подразбиране стандарт (напр. G.711, G.729, H.261, H.264) и създава полезния

товар на RTP пакета. След това, RTP пакета бива криптиран чрез договорения алгоритъм. Алгоритъмът по

подразбиране при SRTP е AES (Advanced Encryption Standart), ползвайки 128 битова дължина на ключа. Този

режим, заедно с нулевия режим, е задължителен затова разработките да бъдат считани за съвместими с IETF

RFC (вж. RFC 3711 за допълнителни изисквания). SRTP също така препоръчва употребата на AES във f8 режим

за криптиране на информацията при UMTS (Universal Mobile Telecommunications System). Този режим ползва

същата големина на сесийния ключ. Употребата на AES в SRTP позволява обработката на пакети дори ако те бъдат получени в разбъркан ред, което е желана функция при приложения в реално време.

Механизмът за удостоверяване по подразбиране е SHA-1 със 160 битова дължина на ключа. Кодът за

удостоверяване на съобщението (MAC) се създава чрез направата на разбъркан ред от символи (хеш) от цялото

RTP съобщение, включително RTP хедърите и криптирания товар, и поставяне на получената стойност в

маркера (tag) ―автентификация―, както е показано на фигурата долу.

Фигура 5.9-1. Формат на SRTP пакет

SRTP съобщението наподобява по формат RTP, с изключение на това че са въведени два допълнителни хедъра:

MKI и маркера „Authentication―. MKI (Master Key Identifier) се ползва от механизма за управление на ключа

(напр. MIKEY), и присъствието му не е задължително, според описаното в SRTP стандарта (RFC 3711).

Хедърите на съобщението целенасочено не се криптират (напр. номерация на последователността, SSRC) за да

могат да бъдат компресирани и да си взаимодействат с приложения или междинни мрежови елементи, които

може да не се изисква да поддържат SRTP, но пък да трябва да обработват RTP хедърите (напр. разплащателната

система). Това ограничение позволява на нападател да извършва анализ на трафика, чрез събирането на

информация от RTP хедъри и разширения, наред с информацията от транспорта в по-долните слоеве (IP, UDP).

Фигура 5.9-2 изобразява пример за приложение, ползващо SDescriptions за изпращане на криптографски ключ при употреба на SRTP. Ключът бива изпратен в SDP порцията на SIP съобщението. SDP медия атрибута ―crypto‖

дефинира типа алгоритъм, режима на криптиране и дължината на ключа (AES_CM_128), наред с дайджест

алгоритъма и неговата дължина (SHA1_32).


62

Фигура 5.9-2. Договаряне на обмен на ключ, посредством SDescriptions в SIP

Методът „inline‖ показва че актуалната ключова информация е приложена в полето key-info. Синтаксисът на

хедъра е дефиниран както следва:

a=crypto:<tag> <crypto-suite> <key-params> [<session-params>]

<crypto-suite> идентифицира криптировката и алгоритмите за удостоверяване (в този случай, AES в броячен

режим ползвайки 128 битова дължина на ключа и SHA-1).

Следващият атрибут е <key-params>, където

key-params = <key-method> ":" <key-info>

В посочения пример <key-method> е вътре

<key-info> = UlrbLlfNTNw3blKHQVLGze6oHsyFdjGj3NheKoYx

Друг механизъм за обмен на криптографски ключове е чрез употребата на MIKEY, като Фигура 5.9-3 показва SIP INVITE заявка, която анонсира че се ползва MIKEY вътре в SDP порцията на съобщението.

Фигура 5.9-3. Употреба на MIKEY в SIP при договаряне на ключ

Атрибутът key-mgmt в SDP показва, че трябва да бъде ползван MIKEY за криптиране на медията по време на

тази сесия.


63

След като ключовете са договорени, приложението криптира RTP товара и изпраща SRTP пакетите към

отсрещната страна.

Фигура 5.9-4. Съдържание на SRTP пакет

Всички хедъри в RTP пакетите се изпращат в чист текстов формат, с изключение на полезния товар, който бива

криптиран. Тъй като SRTP ползва AES по подразбиране, това му осигурява защита срещу DoS атаки, които

целят да развалят криптираното съдържание на медията. Обикновено, шифрите при потоци данни, които

разчитат на предишни блокове за декриптиране на следващите ги (верига шифрови блокове) могат да бъдат

атакувани чрез разваляне на информацията на даден блок, като по този начин се предотвратява възможността за успешно сглабяне наново и възпроизвеждане на оригиналното съдържание. AES не страда от това ограничение,

защото може да декриптира всеки блок без да изисква познание за предишните.

Препоръчва се ползването на SRTP със SHA-1 и дължина на ключа 160 бита (и по този начин генерирането на

80 битов удостоверяващ маркер /tag/) за интегритет и удостоверяване на съобщенията, с цел защита срещу

възможни атаки. При някои сценарии (напр. при безжични комуникации) се препоръчва ползването на къс

удостоверяващ маркер (напр. 32 битова дължина) или дори нулевата дължина (без удостоверяване) също е

опция.

Деривация на ключове

SRTP стандарта изисква ползването на вграден алгоритъм за деривация и генериране на сесийни ключове.

Способността да се „добиват― ключове през SRTP вместо ползването на външен механизъм намалява

допълнителните изчислителни цикли за установяване на даден ключ. Обикновено, всеки участник в една сесия поддържа набор от криптографска информация за всеки SRTP поток, която се нарича криптографски контекст.

За всеки криптографски контекст има поне едно криптиране, един salt и един удостоверяващ ключ за SRTP и

SRTCP респективно. Следователно, SRTP ключовия дериватен алгоритъм може да поиска само един главен

ключ и една стойност на salt, за деривация на необходимите сесийни ключове. Дериватният алгоритъм може да

се ползва респективно за получаване на сесийни ключове. Честотата на деривация се базира на стойността на

key_derivation_rate, която е предефинирана. Това представлява опреснителен механизъм за ключа, за защита

срещу крипто-анализ (което в противен случай може да бъде възможно ако се ползва главен /master/ ключ). Един

нападател например може да събере големи количества сесийна информация и да се опита да извърши крипто-

анализ. Ако се ползва един и същи ключ за цялата информация, в момента в който бъде открит цялата

информация ще бъде разкрита, а ако се ползват много такива, евентуален крипто-анализ би разкрил само

информацията свързана с респективния ключ (не цялата сесия). Това е приложимо при по-малки групи потребители и уникаст сесии, но при големи мултикаст с много участници би натоварило прекалено много

ресурсите на системата, поради генерирането на стотици сесийни ключове.

Проблеми при „ранна медия“ (early media)

В някои случаи, медия бива изпратена към отсрещната страна преди обмена на сигнализационните съобщения

да е завършил и да се установи сесията. Това се нарича „ранна медия― (early media), и това е необходимо

условие в конвергентни среди (напр. VoIP/PSTN). Например, когато VoIP потребител се обажда на номер, който

е част от конвергентна среда (напр. VoIP/PSTN разговор), може да бъде необходимо PSTN шлюза да осигури

прогресиране на сигнала чрез изпращане на тонове или оповестяване вътре в самия канал, преди разговорът да

се осъществи. Това е едно предизвикателство за това как може да бъде защитена медията. Напоследък, в IETF

съществуват дискусии за употребата на MIKEY с поддръжка на EKT (Encrypted Key Transport), с цел решаване

на споменатия проблем.


64

SRTCP

Подобно на SRTP, форматът на SRTCP пакета притежава удостоверяващия маркер /tag/ и MKI хедъри, но също и

два допълнителни хедъра: SRTCP index и encrypt-flag. Чувствителната информация, която трябва да бъде

защитена в едно RTCP съобщение съдържа неговия източник и неговото съдържание. Следователно, тези

хедъри са криптирани. Маркерите authentication, SRTCP index и encrypt-flag в хедърите са задължителни за

SRTCP. В по-голямата си част, обработката на SRTCP пакети е подобна на SRTP пакетите, вкл. употребата на

криптографски алгоритми и дължина на ключовете.

SRTP предимства

Осигурява конфиденциалност, интегритет и автентификация на полезния товар на съобщението (медия

съдържанието)

Осигурява защита срещу атаки чрез повторение за RTP и RTCP

Поддръжката на AES позволява получаването и обработката на разбъркани (в неправилен ред) пакети

Минимизира изчислителната и ресурсна консумация при генериране на криптографски ключове чрез

механизъм за външно управление на ключовете и ползване на вроден алгоритъм за деривацията им

Алгоритъма за деривация на ключове помага за защитата срещу определени крипто-анализиращи атаки

SRTP недостатъци

Липсата на криптиране при RTP хедърите позволявана на анализаторите на трафик да събират

информация от RTP хедърите и техните разширения

Не могат да поддържат интегритет и автентификация на съобщението от край до край, тъй като потока

медия се праща от IP мрежа до SS7 мрежа (PSTN)

Опресняването на ключовете влияе на консумацията на ресурси по време на обработка в големи мултикаст групи. Това не е желателно при мобилни устройства с ограничени изчислителни ресурси

SRTP описания на защитата (SRTP Security Descriptions)

SRTP Security Descriptions не се счита за протокол за управление на ключове, като MIKEY например, но

по-скоро е механизъм за договаряне на криптографски ключове сред потребители в уникаст сесии,

ползващи SRTP транспорт (напр. RTP/SAVP или RTP/SAVPF). Този механизъм не поддържа потоци

мултикаст медия или мулти-точкови уникаст такива.

За предаване на ключовия материал се ползва полето crypto вътре в SDP.

Форматът на crypto атрибута е както следва:

a=crypto:<tag> <crypto-suite> <key-params> [<session-params>]

Полето tag е десетично число и се ползва като част от модела на запитване/отговор за различаване на крипто

атрибутите, избрани от участниците, за всеки един поток медия в една сесия.

Полето crypto-suite е идентификатор, който описва криптиращия и удостоверяващия алгоритъм (напр.

AES_CM_128_HMAC_SHA1_80).

Полето key-params осигурява един или повече набора от ключов материал за крипто комплекта и съдържа метод, в този случай inline, където се показва че актуалния ключов материал (главен ключ и salt) е публикуван в

самото поле key-info. Допълнителната информация включва асоциираната политика на главния ключ, като

неговата продължителност на живот и употреба на MKI (главен ключов идентификатор). MKI се употребява да

асоциира SRTP пакети с главен ключ в мултимедийната сесия. Основавайки се на IETF Security Descriptions

стандарта, всеки ключ следва този формат:

"inline:" <key||salt> ["|" lifetime] ["|" MKI ":" length]

Синтаксисът на ключа е в следната последователност:

key||salt е свързания главен ключ и salt, кодирани в base64 формат

lifetime показва таймаута на главния ключ

MKI:length: показва MKI и дължината на MKI полето в SRTP пакетите

Сесийните параметри [<session-params>], които могат да бъдат включени при запитване/отговор са както следва


65

(според дефиницията в RFC препоръката):

KDR— честотата на деривация на ключа при SRTP е честота, която PRF прилага в главния ключ

UNENCRYPTED_SRTP— SRTP съобщенията не са криптирани

UNENCRYPTED_SRTCP— SRTCP съобщенията не са криптирани

UNAUTHENTICATED_SRTP— SRTP съобщенията не са удостоверени

FEC_ORDER— реда на предадената корекция за грешки (FEC – Forward Error Correction), отнасяща се

до SRTP услугата

FEC_KEY— главен ключ за FEC, когато FEC потока е пратен до различен адрес/порт

WSH— подсказка за размера на прозореца, който се ползва за защита срещу атаки чрез повторение

Extensions— могат да бъдат дефинирани параметри за разширения

Описанията на защитата е дефинирана вътре в SDP, който обикновено е капсулиран в протоколи като SIP или

MGCP. Следователно се очаква, че транспорта лежащ отдолу (напр. TLS, IPSec) ще осигури удостоверение и

конфиденциалност за защита на ключовия материал от атаки като подслушване, повторение и модификация на

съобщението.

ZRTP

ZRTP е друг протокол за договаряне на ключове, който може да бъде поддържащ за SRTP. Фундаменталната

разлика между ZRTP и други съществуващи механизми за обмен на ключове е че криптографските ключове се

договарят през потока медия (RTP) по същия UDP порт, вместо да се ползва сигнализационния път, тъй като

това се прави чрез MIKEY или SDescriptions. Следователно, договарянето се извършва директно между пиърите

без да се изисква употребата на междинни точки, като SIP проксита, за да се препредаде ключовия материал.

Ако това е необходимо обаче, дизайна на ZRTP дава възможност за обмен на ключов материал през сигнализационните съобщения. Основно протоколът ползва краткотрайни DH (Diffie-Hellman) ключове за

създаването на споделена тайна между пиърите, но той не изисква PKI, което прави протокола атрактивна

алтернатива за организации, които не обслужват такава инфраструктура. По време на създаването на този

документ, ZRTP е все още маркиран като чернова, но се очаква ратифицирането му като RFC от IETF, защото

вече е приложен на места от производителите.

ZRTP договаряне на ключове

Договарянето на ключове при ZRTP се изпълнява, ползвайки пътя на медията (RTP) и тук съществуват два

режима на работа: Diffie-Hellman и предварително-договорена споделена тайна(shared secret). Когато се ползва

Diffie-Hellman режим, процеса на договаряне се изпълнява в пет стъпки, за да се анонсира поддръжката на

ZRTP между пиърите и да се инициира, управлява и прекрати обмена на ключа, както е показано по-долу на

фигурата.


66

Фигура 5.9-5. ZRTP договаряне на ключ, ползвайки Diffie-Hellman режим

При предоговорения споделен режим, крайните точки избягват DH калкулацията, защото се приема че

споделената тайна е известна от предишната сесия, но съобщенията DHPart1 и DHPart2 все още се разменят за

установяване на кои точно споделени ключове трябва да бъдат ползвани. Вместо DH стойности (hvi и pvr),

крайните точки ползват „nonce‖ наред със запазените тайни ключове за доставяне на ключовия материал.

ZRTP и човек-по-средата (MITM)

Тъй като DH е уязвим към атака от тип човек-по-средата, ZRTP дизайна осигурява SAS (Къс Удостоверяващ

Ключ, Short Authentication String). SAS бива ползван от участниците за да определи дали техния обмен на ключове е бил компрометиран. Легитимните страни анонсират SAS стринга една към друга, след като

първоначалното договаряне е вече приключено, като задават също и V флаг (SAS проверен). Ако опцията за

задаване на SAS флаг не е налична е възможно да се извърши атака от тип човек-по-средата.

ZRTP DoS

Основен метод за атакуване на протоколи за обмен на ключове е чрез извършване на DoS чрез консумация на

ресурси и изтощение по този начин на системата. При ZRTP, един нападател може да изпрати фалшиви Hello

съобщения до крайните точки и по този начин да ги накара да отделят ресурси, като евентуално да предизвика

влошаване на връзката или да прекрати операцията. Тази атака има изискването обмена на сигнализационни

съобщения да предхождат предоговарянето на ZRTP. Сигнализационните съобщения може да бъдат по-лесна

мишена за атака, вместо да се изчаква докато крайните точки не инициират обмен на RTP медия и започнат

експлоатация на ZRTP.

ZRTP DTMF оповестяване

Въпреки че, ZRTP е направен да защитава RTP потока, сегашната версия на Zfone се проваля в защитата на

DTMF тонове. RFC 2833 дефинира формата на полезния товар за изпращане на DTMF тонове в RTP. Много

съвременни автоматично-отговарящи системи ползват DTMF тонове с цел навигация в менюто. Например,

когато потребител набере своята банка или друг вид система, той бива подканени да вкара своя номер на акаунт,

ЕГН или друга идентифицираща информация. Възможно е нападател да прихване един такъв разговор между

крайни точки и да получи номера на кредитни карти, дати на раждане, ПИН, ЕГН и друга конфиденциална

информация.


67

Фигура 5.9-6. ZRTP и DTMF незащитеността: примерен пакет

Един от подходите за премахване на тази уязвимост е да се вгради съответната опция в дизайна на ZRTP, така че

да разшири своята защита и върху DTMF тонове (напр. криптиране на RTP полезния товар).

6. VoIP и мрежови контроли за сигурност

Тази глава дискутира мрежовите контроли за сигурност, които могат да бъдат ползвани за защита на VoIP

инсталацията. Мрежовите контроли за сигурност са само едно от измеренията в усилието да се защитят VoIP

мрежите.

Процесът на защита трябва да бъде създаден, така че да включва контроли адресиращи следното:

Идентифициране на приложимите заплахи

Идентифициране на пътищата на една атака и минимизиране възможността за такава

Минимизиране въздействието от една атака, ако се случи

Овладяване и подтискане на успешна атака в кратки срокове

Следователно, защитата във VoIP или всяка мрежа която предлага Интернет мултимедийни приложения изисква

вземането на същите мерки. Нужно е да се разработят и наложат политики за сигурност, стандарти и процедури, с цел поддържане на еднороден подход към управление на информационната сигурност.

Тази глава се фокусира върху архитектурните съображения, механизмите които могат да бъдат използвани за

поддръжка на удостоверяване, оторизация и отчетност (напр. Диаметър /Diameter/), както и компонентите които

могат да бъдат ползвани за осигуряване на контроли и защита срещу атаки (напр. SBC).

6.1 Архитектурни съображения

Фундаментален елемент от защитената VoIP инсталация е добре дефинираната архитектура. Тя трябва да

обединява изисквания за надеждност, достъпност, конфиденциалност, оторизация и интегритет.

За да поддържа тези основни точки, трябва да се въведе приоритет в типовете информация, които се обменят

през VoIP мрежата (тайна, конфиденциална, публична). По-нататък, трябва да се посочат изискванията за

защита, които трябва да поддържа инфраструктурата, за да посрещне останалите предизвикателства

(конфиденциалност, оторизация и интегритет). Разработването на изисквания за сигурност би помогнало да се построи стабилна и мащабируема архитектура, която обединява сигурност и наличност на услугите, наред с

QoS. Най-общо казано, съображенията за сигурност в една VoIP архитектура биха включвали правилна мрежова

сегментация, мрежово управление извън системата и частно адресиране.


68

6.2 Сегментация на мрежата

В корпоративните мрежи и тези на доставчиците, мрежовата сегментация осигурява възможност за

рационализиране и контрол на трафика между компонентите. Фигура 6.2-1 описва конфигурация на една

сегментирана корпоративна VoIP мрежа.

Фигура 6.2-1. Сегментация на архитектурата на корпоративна мрежа

В тази примерна архитектура всички критични компоненти са логически изолирани. Филтрирането на трафик

може да бъде наложено от поддържащите мрежови елементи, като маршутизатори и суичове или употребата на

VoIP защитни стени или гранично сесийни контролери (SBC).

Например, повикващите агенти, PSTN шлюзовете, сървърите за гласова поща, сървъра за унифицирана

пощенска услуга, имейл сървъра, VoIP хардуерните и софтуерни телефони, всички те са отделени в техните

обособени VLAN (виртуални LAN), като сигнализацията и трафика на медия между различните VLAN са ограничени. Ако от маршрутизаторите или суичовете е наложено филтриране на трафика, типичен избор е

употребата на контролни списъци за достъп (ACL).

Тъй като, сигнализацията на трафика може да бъде SIP, H.323, MGCP или друг протокол като Skinny, може да

бъде наложена допълнителна филтрация за ограничаване типа на сигнализация, която може да тече между

VLAN мрежите. Таблица 6.2-1 разглежда пример на ACL, който позволява SIP сигнализация между VoIP

телефоните и VLAN мрежата на агента на повикванията.

Таблица 6.2-1 Примерно ACL филтриране на сигнализационен трафик

Източник Дестинация Транспорт Порт

CA VLAN (Call Agent) VoIP телефонен VLAN UDP 5060

VoIP телефонен VLAN CA VLAN UDP 5060

Таблица 6.2-3 показва друг пример на ACL, позволяващ MGCP сигнализация между агента на повикванията и VLAN мрежата на гласовия шлюз.


69

Таблица 6.2-2 Примерно ACL филтриране на сигнализационен трафик

Източник Дестинация Транспорт Порт

CA VLAN (Call Agent) VLAN на гласов шлюз UDP 2427

VLAN на гласов шлюз CA VLAN UDP 2727

В допълнение, CA може да има възможността да наложи контроли за приемане и изпращане на повиквания (вкл.

удостоверяване и оторизация), базирани на потребителските акредитации, профил (напр. мениджмънта,

складове, продажби) и политика (напр. недопускане на международни разговори или такива до вътрешни или

външни номера).

Трафика на медия е позволен между определени VLAN мрежи, като PSTN шлюзовия VLAN, този на VoIP

телефоните и този на сървъра за гласова поща. Медия портовете биват договаряни динамично между крайните

точки, затова ползването на ACL за ограничаване на RTP трафика изисква дефинирането на определен диапазон от UDP портове, които да бъдат разрешени между крайните точки. Обикновено, портове между 16,384 и 32,767

се ползват за аудио, а такива между 49,152 и 65,535 се ползват за видео. Даден производител може да ползва

различен диапазон, но трябва да е възможно да се идентифицират ниската и високата им граница, с цел

въвеждане на съответни ACL.

Фигура 6.2-2 описва пример за ACL филтриране между VoIP компоненти в определени VLAN мрежи.

Позволяват се само потоци медия и сигнализация между съответните VLAN, като по този начин атака

произхождаща от друга точка в мрежата срещу сигнализационен порт на гласов шлюз например, няма да може

да се осъществи.

Фигура 6.2-2. Пример за ACL филтриране между отделни VoIP компоненти

6.3 Логическо разделяне на гласовия трафик от този на данни

Пакетизираният глас не е различим от останалата пакетна информация в слоеве 2 и 3, и по този начин е обект на

същите мрежови рискове и рискове за сигурността, които засягат мрежите пренасящи само данни. Основната

мотивираща идея за логическо разделение на глас и данни е очакването, че мрежови събития (т.е. урагани от

броудкаст съобщения и задръствания на трафика, червеи и DoS атаки) в едната мрежа, няма да окажат влияние

върху другата.

Логически се разделя трафика на данни и глас; планира се създаването на поне 2 VLAN мрежи, като VoIP

системните компоненти се поставят на отделения за тази цел VLAN с включени 802.1p/q QoS и приоритетно

VLAN маркиране; ограничава се физическия и терминален достъп до суич конзолите само до оторизирания за

това персонал.

6.4 QoS и ограничаване на трафика (shaping)

Когато в мрежата се въведе гласова услуга, въпросът за качество на услугата и нейният приоритет става от

критично значение.

Някои от мерките за сигурност при VoIP може да намалят производителността на мрежовата свързаност в


70

точката където не е приложен QoS. Повечето от закъсненията, причинени от въвеждането на защита, идват от

генерирането на ключове и обмен на съобщения по време на автентификацията и обмена на ключове.

Например, AES криптировката, без да има хардуерно ускорение, отнема около 50 микросекунди, но

генерирането на ключа и неговия процес на обмен може да трае 500ms, което е неприемливо за приложение

работещо в реално време. Най-общо пък при IPSec това отнема някъде между 2 и 10 секунди. TLS постига по-

добра производителност, но той също се нуждае от около 1.5 секунди за формиране на сигурна връзка.

6.5 Защитни стени

Защитните стени осигуряват физическа и логическа граница между вътрешната и външна страна на една мрежа.

Първите защитни стени са били просто шлюзове между две мрежи без функции за IP пренасочване. Повечето

пък модерни такива притежават общи набори от характеристики: точка между две или повече мрежи, откъдето трябва да премине целия трафик; може да бъде конфигурирана да позволява или отказва IP трафик (или друг

протокол); осигурява одитираща функция; осигурява NAT функция; операционната й система е подсилена;

често служи като VPN крайна точка; трафикът се прекъсва ако е в „затворено― състояние – това означава, че ако

защитната стена се срине по една или друга причина, няма да бъде препратен никакъв трафик между

интерфейсите.

Таблица 6.5-1 представя непълен списък на основни портове и услуги, свързани с VoIP.

Таблица 6.5-1 Основни VoIP портове и услуги

Услуга Порт

Skinny TCP 2000-2002

TFTP UDP 69

MGCP UDP 2427

Backhaul (MGCP) TCP 2428

Tapi/Jtapi TCP 2748

HTTP TCP 8080/80

SSL TCP 443

SCCP TCP 3224

Transport traffic 16384-32767

SNMP UDP 161

SNMP trap UDP 162

DNS UDP 53

NTP UDP 123

LDAP TCP 389

H.323RAS TCP 1719

H.323 H.225 TCP 1720

H.323 H.245 TCP 11000-11999

H.323 Gatekeeper Discovery UDP 1718

SIP TCP 5060

SIP/TLS TCP 5061

Все още няма лесно решение за защитена обработка на повикванията, които произхождат външно. Защитните

стени с пакетно филтриране и инспекция на състоянието на пакетите могат да създадат „малък отвор― през

който повикванията отвън да преминават навътре. Особено с случая на SIP базираните решения обаче,

преведения частен IP адрес пречи на входящите разговори да достигнат правилния реципиент, освен ако не се

ползва STUN протокола, специално създаден за преодоляване на NAT.

За да се избегнат проблемите, свързани със защитните стени, се препоръчва употребата на VPN или друг вид

капсулиране на VoIP трафика.

6.6 NAT и IP адресиране

Мрежовото адресно транслиране (NAT) е метод за пренаписване на адресът-източник и/или дестинацията на IP

пакетите, когато те преминават през едно NAT устройство. Тези устройства следят, записват и променят IP


71

адреса-източник, адреса-дестинация, както и полето за проверка (checksum) вътре в IP хедърите. Те също така

модифицират чексумата на TCP и UDP пакетите, тъй като те се изчисляват върху псевдо-хедър, чиято концепция

съдържа IP адресите на източника и дестинацията, а при TCP полетата се ползва за дължина на полетата. NAT

осигурява функция за сигурност чрез разделяне на вътрешните хостове от публично рутираните в Интернет.

NAT ще продължи да бъде основната пречка за преминаването към VoIP, докато Ipv6 не навлезе широко в

употреба. Криптирането през NAT устройства е особено проблематично, тъй като и H.323 и SIP поставят

рутиращата и сигнализационна информацията от 3ти слой вътре в полезния товар на IP инфограмата.

6.7 Контролни списъци за достъп (ACL)

Мрежовите контроли за достъп (ACL) са подобни на таблици структури, които обикновено съдържат следните

колони – референтен номер идентифициращ ACL, правило (обикновено permit или deny) и модел на информацията, който може да съдържа източника и/или дестинацията, портовете на източника или

дестинацията, маски, булеви операции. ACL заедно с VLAN, QoS и защитните стени са мощни инструменти за

разделяне на VoIP от останалия трафик.

7. Откриване на прониквания при VoIP

Съществуват два вида системи за откриване на прониквания IDS (Intrusion Detection Systems) – базирани на

сигнатура и базирани на аномалия в системата. Сигнатурно-базираните IDS идентифицират злонамерена

активност чрез инспектиране на индивидуални пакети и сравнявайки го с модели образци на познати сигнатури.

Базираните на аномалия идентифицират атаки, чрез анализиране на общи потоци мрежови трафик и

изпълнявайки сравнение с образци на предефинирани трафични характеристики (напр. дали активността е в

рамките на нормални или анормални параметри). И двата типа системи притежават силни и слаби страни, но и

двата типа са ефективни когато бъдат правилно приложени.

VoIP комуникациите ползват комбинация от протоколи за препредаване на комуникационни съобщения, и те на своя ръка могат да ползват динамично разпределени портове. Също така може да бъдат ползвани различни

маршрути и това довежда до различни предизвикателства при съшествуващите IDS системи. Въпреки че, те са

способни да засекат някои от свързаните с VoIP атаки, с досегашните техники те все още не могат да открият

атаки като отвличане на повиквания и сесии, манипулиране на потока на разговор или манипулация на медията.

Например, Snort IDS ползва сигнатурно-базирани техники за откриване на злонамерена активност, свързана със

SIP сигнализацията, като правилата включват откриване на атаки като SIP сигнализационно бомбардиране със

съобщения, сканиране на портове, засипване със SYN заявки и други.

IDS все още са безсилни срещу следните заплахи:

DoS; чрез изтощение на ресурсите на дадено приложение (напр. атаки срещу сигнализацията или

протоколи управляващи ключовете)

Маскарадинг на сигнализационни и медия съобщения

Засичане на деформирани съобщения

Атаки, манипулиращи потока разговор

Контрол на достъпа и оторизационни атаки (напр. атаки чрез повторение на автентификация, атаки

нарушаващи функционалността на приложението, атаки свалящи нивото на сигурност)

Измами

Корелацията на събитията е техника, която може да бъде ползвана във VoIP за обобщаване на събития от

няколко агента, които пребивават във VoIP мрежовите елементи, вкл. телефони, SIP проксита, шлюзове и SBC.

Техниката чрез корелация на събития се основава на характеристиките на мрежата и транспортния слой, което е

недостатъчно, а вместо това трябва да бъдат разработени корелационни техники които да обединят

характеристики от протоколите, ползвани в мултимедийните приложения. Друг подход е базиран процеси за

инспектиране състоянието на протокола, така че когато то бъде променено той бива инспектиран.

Въпреки че настоящите техники са обещаващи, в бъдеще време трябва да се обърне по-сериозно значение на

материята и да се доразвият с цел покриване на споменатите слаби моменти.

7.1 Системи за улавяне на прониквания - NIDS

NIDS са проектирани така че да известяват администраторите, когато бъде засечен злонамерен или нелигитимен

трафик. Злонамерения трафик може да се състои от червей или код, базиран на дупка в системата, докато

нелигитимния се съдържа от трафик, който се отклонява от установената политика за сигурност, като сърфиране

в порно сайтове или връзки от тип пиър до пиър например. Мрежово-базираните IDS може да извършват


72

мониторинг на голяма мрежа с помощта само на няколко добре ситуирани нодове или устройства. Те са често

срещани в съвременните мрежови компютърни среди, тъй като няма значение колко добре са въведени

контролите за сигурност - просто е непрактично да се поддържа защита срещу всички познати и потенциални

заплахи за мрежовите системи и приложения. Във VoIP средите NIDS осигурява допълнително ниво на защита.

NIDS засича подозрителна активност по три начина: първият - общността за защита поддържа изключително

голяма база данни от специфични сигнатури на атаки. Тези сигнатури са програмирани в NIDS сензора и биват

опреснявани редовно. Примери за такива сигнатури са Code Red, NIMDA, DoS атаки, препълване на буфер, ASP

и CGI уязвимости. Вторият - NIDS сензорите съдържат препроцесори, които непрекъснато наблюдават мрежата

за анормално поведение. Въпреки че, не са толкова специфични като сигнатурите от атаки, засичането на

аномалии е все още високо ефективно при сканиране на портове, дистрибутирани мрежови проби, нови форми на препълване на буфер и атаки от тип отказ от услуга. Третият - всички NIDS елементи могат да прилагат и

откриват отклонения от политиката на защита, вкл. откриване на неоторизирани мрежови услуги, приложения

ползващи нетрадиционни портове и активност причинена от „задни вратички― (backdoor) или троянски коне.

Базираните на сигнатури NIDS биват по същество мрежови снифъри, комбинирани с база данни от сигнатури на

атаки. Една от най-трудните задачи, когато се конфигурират за първи път е „финната― настройка, като трябва да

се знае че ако са включени прекалено много алармиращи опции смисленият анализ на информацията няма да

бъде възможен.

Компоненти

Повечето NIDS са конфигурирани в клиент (сензор) - сървър (конзола за управление) конфигурация. Много

сензори обикновено докладват до една или няколко конзоли за управление. Сензорите могат да бъдат специално

предназначени за тази цел устройства, могат да работят като приложения на даден хост, наред с други

инсталирани приложения или могат да работят независимо, във виртуална подсистема като VMWare или Xen. В случай, че сензорът не се намира в отделно устройство, то тогава операционната система на компютърния хост

трябва да бъде подсилена.

Тъй като NIDS не се намират на пътя на данните (обикновено една мрежова карта се ползва като сензор и втора

се ползва за управление на трафика), сензорния Ethernet интерфейс трябва да бъде конфигуриран по няколко

начина, като такъв който само получава без да изпраща данни. Хардуерните изисквания за сензорите не са

особено строги, тъй като приложението на сензора инспектира пакети, и след като намери сигнатурата от даден

образец, изпраща допълнителния информационен поток към конзолата за управление за обработка и

визуализация.

Понятието сигнатура се отнася до набор от условия, които трябва да бъдат срещнати, и когато това се случи се

стартира дадено събитие. Типичните модерни сензори съдържат база данни от 1000 до 2000 записа. Често,

сензорите инспектират трафика основавайки се на микс от сигнатури и образци. Последните се базират на търсенето на фиксирана последователност от байтове в един единствен пакет. По-сложен метод се явяват

образците с определено състояние и той е полезен, когато сигнатурата за нападение обхване повече от един

пакет. Подобно на антивирусните програми, сигнатурно базираните IDS изискват непрекъснат достъп за

обновяване на сигнатурите на нови атаки.

Фигура 7.1-1 е проста илюстрация на основната логика, заложена в NIDS управленските станции за

разрешаване на събитие, докладвано от отдалечен сензор. Логиката „Match IDS Rule‖ обикновено се прилага в

самия сензор, а когато се срещне дадено правило (напр. пакет идващ отвън навътре,който съдържа неверни SIP

прерутиращи хедъри) информацията се препраща към конзолата за управление, където бива приоритизирана,

записана в лог файл и визуализирана.


73

Фигура 7.1-1. Блок схема - логика на NIDS

Типове

NIDS обикновено биват класифицирани по методите за откриване на атаки които ползват – или сигнатурно

базирани или откриващи аномалии в мрежата. Въпреки това последните поколения NIDS ползват микс от тези

техники. Сигнатурите на атаки обикновено съдържат една или повече от една от изброените характеристики:

IP адрес на източника и дестинацията, или спектър от адреси

TCP/UDP портове на източника и дестинацията и ICMP тип/код

Флагове и опции на IP хедърите

Флагове и опции на TCP хедърите

Дефиниция за търсене на данните от полезния товар (hex или ASCII)

Стартираща точка за търсене на полезния товар (offset) и дълбочина на търсенето

Анализът на пакетните хедъри може да бъде направен по „икономичен― начин, тъй като полетата в хедъра се намират на определени места и това е изискване на протоколните стандарти. За разлика от тях, съдържанието на

полезния товар не е подредено по никакъв начин и поради тази причина търсене на няколко стринга в неговото

съдържание вътре в потока данни, може да се окаже доста „не-икономична― задача. Допълнително усложняване

на задачата добавя и факта, че тези търсения трябва да бъдат извършени с висока скорост.

NIDS базиращи се на откриване на аномалии, се основават на предположението, че нормалния трафик може да

бъде дефиниран и че образци от атаки или неправилна употреба на системата определено ще се различават от

„нормалния― трафик. Евристично-базираните сигнатури, от друга страна, ползват определен тип алгоритмична

логика, върху която да обусловят решенията си за включване на алармира. Евристиката е изкуството и науката

да откриваш – самата дума идва от гръцки (в оригинал „Еврика―) и означава „Аз намерих―. Евристиката

определя техника за решаване на проблем, при която най-правилното решение се избира на последователни

етапи в дадена програма, за да се употреби на по-късни етапи в същата. Евристиката подхожда към опростяване или обучено предположение, с цел намаляване или ограничаване на самото търсене на решение. Тя може да

представлява единствено алгоритмично решение на проблем или задача, но за разлика от алгоритъм тук не се

гарантират оптималните или дори възможните решения.Тези алгоритми често са статистическа оценка на типа

трафик, който е инспектиран. Пример за евристична сигнатура е такава, която се ползва за откриване на

сканиране на портове. Тя дефинира определен праг на външните проби срещу единични портове или

определена комбинация от такива. По-късно тя може да бъде ограничена чрез определяне на типа пакети (напр.

само SYN). От тези данни може да бъдат научени интересни тенденции и е възможно да се засекат настоящи

атаки, основавайки се на тези алгоритми, но трябва да се има предвид че най-често информацията която

осигуряват този вид системи е не-специфична и изисква сериозна човешка намеса преди да бъде взето решение

за вземане на мерки. Чрез очертаване на нормално поведение, базираните на аномалии NIDS са способни да

открият кога поведението на посочената мрежа се отклонява от нормата. Това свойство теоретически им

придава капацитет да откриват нови, непознати атаки за които все още не съществуват сигнатури. Основният проблем с този тип анализ е че нормалният мрежов трафик е труден или дори невъзможен за дефиниране.


74

Важни особености на NIDS

Поддръжка

Повечето NIDS системи поддържат централизирана инсталация, конфигурация и осъвременяване, тъй като в

повечето корпоративни мрежи администратора не е в състояние физически да достигне всеки сензор. Също

така, повечето производители поддържат автоматично опресняване на сигнатури и софтуерни осъвременявания.

Дистрибуцията и редактирането на библиотеки със сигнатури би трябвало да е възможно както за всеки сензор

поотделно, така и за цели групи, така че да не е небходимо дадена промяна да бъде прилагана сензор по сензор.

Комуникацията между различни компоненти на IDS (сензори и конзола за управление) трябва да бъде

криптирана, а NIDS Ethernet интерфейсите трябва да бъдат невидими, като трансмисията на данни от тях е

забранена, освен в по-специални случаи когато изрично се налага.

Известяване

Конзолата за управление трябва да може да се конфигурира, така че да поддържа известяване чрез различни

механизми, включвайки SNMP, имейл, SMS и пейджър, syslog съобщения, IM както и конзолно известяване.

Създаване на лог файлове

Всички известявания, хедър информация и данни за полезен товар трябва да се съхраняват автоматично в

централна база данни със събития, на която се прави периодически резервно копие по SCP или друг сигурен

начин.

Разширяемост

NIDS трябва да поддържа проста интеграция на допълнителни инструменти за оценка на уязвимостта като

Nmap или Nessus и би трябвало да има корелация на данните от други IDS (напр. NIDS или HIDS).

Отговор на атаки

Някои NIDS са способни да отговарят активно на атаки или на неправилна употреба чрез намеса в потока съобщения, предизвикали сигнала. Това обикновено се постига с насочени TCP нулирания (resets) и евентуално

изтриване на връзката или чрез динамична промяна на правилата на защитната стена или контролните списъци

за достъп (ACL), така че да се блокира връзката. Тези активно отговарящи NIDS често биват наричани IPS

(Intrusion Prevention Systems).

Повечето администратори не активират тези функции, поради съществуващ риск от блокиране на нормалния

трафик. Ако да речем те са пуснати в действие при система свързана директно с Интернет, има риск нападател

който е достатъчно наясно с това което върши, да извърши spoof атака към рутър отговарящ за връзката на IDS,

резултата би бил блокиране на рутъра и прекъсване на свързаността на компанията с Интернет.

Ограничения

Базираните на сигнатури NIDS трябва постоянно да опресняват базата си данни от сигнатури, тъй като те биха

пропуснали атаки, за които не притежават такава сигнатура, ако пък дефинициите са твърде специфични могат да пропуснат различни разновидности на атаките (най-често срещаната техника за създаване на нови атаки е

като се модифицират стари такива). Базираните на сигнатури NIDS може също да доведат до значими проблеми

с производителността при системи, където са се появили няколко сигнатури на атаки едновременно, като това

пък допълнително да доведе до инспекция на системата и излишна загуба на време.

Honeypots и Honeynets

Honeypot е компютърна система, защитена от Интернет с помощта на маршрутизатор или защитна стена, която

е прозрачна за нападателя. Тя бива маскирана като нормална, незащитена система, като все още записва всяко

действие предприето срещу нея и всяка операция, която се извършва на нея. Целта на един honeypot оператор е

да примами нападател и да го въвлече в проникване в системата, като се надява да научи всички детайли на

атаката. Honeynet са мрежи, които съдържат поне един honeypot. Обикновено, honeynet представляват виртуална

мрежа, изпълнена с виртуални услуги и приложения, която в очите на нападателя изглежда като истинска.

За разлика от NIDS и HIDS, където основния нюанс са изградените правила и критерии за алармиране, при honeypot и honeynet няма такива. Такива мрежи обикновено се разполагат в свободното IP пространство във

вътрешната мрежа на една организация, като при такава конфигурация всичко което удари honey-мрежата е или

атака или предшественик на такава, тъй като това IP пространство се предполага че не се ползва. По този начин

те могат да осигурят ранно известяване за вирус или червей в мрежата.


75

7.2 Хост-базирани системи за улавяне на прониквания - HIDS

Хост-базираните системи за откриване на прониквания (HIDS) са приложения, които боравят с информация

събрана от индивидуални компютърни системи. Това предимство позволява на HIDS да анализира активноста

на хоста, който наблюдава много детайлно, като често е в състояние да открие кои процеси и/или потребители

са свързани със злонамерените действия.

Много HIDS следват модела Tripwire, който работи с MD5 хешове на критични системни файлове. Това е един

от моделите на хост-базираните системи, недостатък е че за проникване се разбира единствено след като бъде

променено нещо по файловата система, т.е. след като проникването е извършено. Повечето HIDS софтуери,

както и Tripwire, създават „цифров инвентар― от файлове и техните атрибути в познато състояние, като този

инвентар се ползва за основа на мониторинг за евентуална промяна в една система. „Инвентарът― обикновено е файл, съдържащ MD5 чексума за индивидуални файлове или директории и той трябва да се съхранява на

защитена медия, поддържаща само четене, без право на писане отгоре.

Една минус при HIDS е, че достатъчно умен нападател може да извърши DoS атака която да го засегне, тъй като

тези системи не се занимават с превенцията им и са уязвими откъм такъв тип атаки. HIDS системите

консумират процесорно време, място на твърди дискове, памет и други ресурси, а тези които работят в клиент-

сървър среда - и мрежов трафик.

7.3 Създаване на log файлове

Системната лог информация е златна мина за ценна информация, но търсенето в нея е като да се намери „игла в

купа сено―. Носещите щампа на време лог файлове, генерирани от сървъри, шлюзове, защитни стени, проксита,

рутъри и суичове често носят безценна информация относно сигурността, но администраторите обикновено са

претрупани с друга работа и анализирането им остава настрана. Ключът към успешен анализ на лог файлове е

ползването на подходящите за средата инструменти, които автоматично правят разбор, визуализират и създават доклади от тях. Много организации ползват MRTG (Multi Router Traffic Grapher—

http://people.ee.ethz.ch/~oetiker/webtools/mrtg/) или RRDTool (http://oss.oetiker.ch/rrdtool/) за визуализиране на

SNMP мрежовата информация от маршрутизатори и суичове.

7.4 Syslog

В най-простия си вид, syslog протоколът осигурява транспорт за да позволи на дадена машина да изпрати

известяващи съобщения за събития по IP мрежи до съответните syslog сървъри. Syslog е доста странен

протокол, от гледна точка на това, че е бил вече приет в доста платформи преди да бъде ратифициран от IEEE в

RFC3164, където само е описано действието му.

Съобщенията ползват UDP/514 за транспорт, увеличавайки вероятността от загуба на пакети без да се уведомява

за това, улеснявайки значително фалшифицирането на пакети с цел вкарването им в лог файла или просто за да

залее със съобщения сървъра. Syslog не поддържа криптиране, така че съобщенията се изпращат в прост, текстов формат и могат да бъдат прихванати. В момента има чернова на препоръка, предлагаща механизъм

който да прибави удостоверяване на източника, интегритет на съобщението, защита срещу повторение,

последователност на съобщенията и откриване на липсващи syslog съобщения, но това не се прилага широко.

Някои от популярните заместващи syslogd аналози (вкл. syslog-ng) могат да ползват TCP за по-надеждна

доставка, някои добавят чексума и/или криптографска сигнатура към всяко събитие.

Syslog е широко разпространен сред UNIX платформите, но рядко в MS Windows. Най-известното приложение

под Windows е Kiwi Syslog (www.kiwisyslog.com).

Syslog съобщенията (ASCII базирани) могат да бъдат изпратени в локални лог файлове, локалната конзола,

отдалечен syslog сървър или отдалечен syslog relay. Syslog събира съобщенията и по подразбиране ги записва

във /var/log, а конфигурационния файл за програмата и подсистемата която събира събитията се намира в

/etc/syslog.conf. Нивата на приоритет и важност на съобщенията са както следва:

0 Emergency: системата е неизползваема 1 Alert: трябва да бъдат взети незабавни мерки

2 Critical: критични условия

3 Error: условия на грешка

4 Warning: условия изискващи внимание

5 Notice: номални условия на работа, промени от значение

6 Informational: информационни съобщения

7 Debug: съобщения на ниво debug /всичко което се случва/

В една VoIP среда, IP телефоните и сървърите са в състояние да генерират syslog съобщения, като тези

съобщения би трябвало да се изпращат до централизиран сървър, където им се прави разбор и се генерират

http://people.ee.ethz.ch/~oetiker/webtools/mrtg/

http://oss.oetiker.ch/rrdtool/

http://www.kiwisyslog.com/


76

доклади поне веднъж дневно. Тези лог файлове често са много ценен и пренебрегван източник за откриване на

прониквания и съобщения за производителността на системата.

8. Мрежови топологии

Гъвкавостта, предлагана от протоколите за осигуряване на мултимедийни услуги по IP, позволяват на много

компании да предложат VoIP услуга. Въпреки че, това сваля цените тъй като се предлага по-голям избор на

клиентите, не всички поддържат еднакви стандарти за сигурност и качество. Типичните архитектури на

доставчиците на услуги в днешно време са следните:

Телеком от конвергентен тип— досегашен телекомуникационен доставчик, който поддържа и осигурява

услуги по PSTN и VoIP инфраструктури (напр. Mtel, BTC и т.н.)

ISP базиран доставчик на услуга (ISP-VSP)— Интернет доставчик, който предлага VoIP услуга на настоящите си клиенти (Cores Networks, Евроком кабел и т.н.)

Интернет базиран доставчик на гласови услуги (I-VSP)— VoIP доставчик, който предлага

телекомуникационни услуги по VoIP, но не поддържа никаква PSTN инфраструктура или пък предлага

достъп до Интернет на своите клиенти (Hermes phone, inphonex.com, Vonage и т.н.)

Всяка архитектура притежава своите предимства и недостатъци и те са разгледани по-долу в документа.

Телеком от конвергентен тип

Конвергентният телеком поддържа TDM инфраструктура, която е взаимосвързана с VoIP инфраструктурата. В

някои случаи, TDM и IP мрежите могат да бъдат взаимосвързани с клетъчна мрежа. Интерконекцията между

тези мрежи (IP и клетъчна) е във фокуса на IMS архитектурата и 3GPP инициативата, целяща да осигури нови

услуги и персонализирана услуга на потребителите.

В тази среда телекомите предлагат традиционни PSTN и VoIP услуги на бизнеса и частните абонати, през точки

на присъствие (POP – Points Of Presence), в даден географски регион. Корпоративните клиенти могат да направят интерконект с VoIP мрежата през Интернет или IP VPN мрежа (ползвайки MPLS). Свързването на

частни или корпоративни абонати към мрежата по Интернет изисква VoIP шлюз или компонент на

корпоративната мрежа, който да работи като такъв (напр. MGCP или SIP базиран маршрутизатор, IP-PBX, SIP

прокси, H.323 GK). Физическата връзка може да се осъществи по DSL модем или друга медия (напр. T1-OC3,

E1, в случай на корпоративен клиент), която поддържа висока скорост на обмен. Въпреки че, свързването по

Интернет е по-ефективният вариант откъм цена, съществува известен риск от атаки произхождащи от

глобалната мрежа.

Интерконекцията по IP VPN осигурява качество на услугата (QoS) и по-високо ниво на защита, в сравнение с

Интернет-базираната свързаност, тъй като VPN мрежата се контролира от телекомуникационния доставчик.

Компании, които предлагат VoIP услуги от разстояние по Интернет не могат да предложат пълното качество на

услугата, тъй като контролът на транспорта не е в техния резон.

Като допълнение към рутирането на обаждания между TDM и IP, тази архитектура предлага възможност за

обмен на VoIP трафик с други телекоми, ползвайки статично IP рутиране (напр. VoIP до VoIP). В IETF има опити

(работната група SPEERMINT) за установяване на правила за динамичен пиъринг между различни VoIP

доставчици.

Основните компоненти, които улесняват конвергенцията в тази архитектура са сигнализационните и медия

шлюзове, защото те изпълняват транслация на съобщенията между IP и SS7/C7 (сигнализационни и медия

кодеци). Управлението на сигнализацията на разговорите, които преминават по VoIP мрежата и координираното

разпределение на ресурсите в сигнализационните и медия шлюзове се извършва от софт-суич (softswitch).

Евентуални DoS атаки до споменатите компоненти биха повлияли драстично върху услугата, ето защо

доставчиците ползват различни контроли за сигурност като SBC (гранични сесийни контролери), срещу атаки

произхождащи от външни мрежи.

Произходът на една атака тук, може да бъде от външен интерконект или от удобна вътрешна точка,

предварително компрометирана или ползвана зловредно от вътрешен оператор (служител, търговец). Едно от

критичните места е управленската мрежа, която ако бъде засегната, това може да има опустошително влияние

върху работата на VoIP доставчика. Следователно, управленските мрежи трябва да бъдат изолирани от другите

мрежи и трафикът между мрежата за управление и мрежата на продукта трябва да бъде наблюдаван по

съответния начин. Типично недоглеждане, което излага на рискове сигурността е липсата на адекватни

контроли за сигурност при свързване с други VoIP доставчици (пиъри). Напоследък станаха известни някои

случаи на VoIP измами, при които нападателите са ползвали основни методи за атака за компрометиране на VoIP

доставчик и корпоративни мрежи, с цел рутиране на разговори междуконтинентално, резултата от което е загуба

изразяваща се в милиони долари в рамките на няколко месеца. Една от ползваните техники е била брут-форс


77

атака на пиъринг кодове за достъп, като в някои случаи ползваният код се е състоял само от три цифри.

ISP базиран доставчик на гласови услуги

Доставчиците на Интернет са добре позиционирани откъм предлагане на VoIP услуги до потребителите си на

конкурентни цени. Кабелните и Интернет LAN доставчици могат да предложат цялостна услуга

(Интернет/телевизия/глас), като доста от компаниите предлагат вече услугата и на корпоративни, както и частни

абонати. При тази архитектура, IP мрежата е свързана към TDM чрез същите мрежови елементи като конвергентния

телеком. Доставчикът може да защити ключовата VoIP инфраструктура от евентуални атаки, чрез въвеждане на

комбинация от контроли за сигурност, като SBC за управление на трафика, налагайки регистрацията на

устройства и потребители наред с удостоверяване и интегритет на сигнализационните съобщения. В случаите, когато Интернет доставчика не разполага с TDM инфраструктура, той може да рутира разговори до PSTN през

регионалния телеком. Съществува тенденцията големите доставчици да поддържат PoP – точки на присъствие в

различни географски райони, и по този начин могат да рутират разговори в своя IP гръбнак, от една точка до

друга на минимална цена или в често случаи безплатно. По този начин се гарантира и безпрецедентно качество

на услугата, тъй като каналите между точките на присъствие са високоскоростни и гарантирани. В същото

време има реална опасност за атаки от външната мрежа.

Хубав пример за ISP-VSP са кабелните доставчици, като те ползват PacketCable архитектура за своите VoIP

потребители (PacketCable е базиран на DOCSIS [Data-Over-Cable Service Interface Specifications] PacketLabs

публикация 1.1.), като тя дефинира IP-базирана архитектура за доставка на услуги като VoIP, видеоконференции,

интерактивни игри и т.н., и се основава на 6-то издание на IMS, разработено от 3GPP (3rd Generation Partnership

Project). Двата компонента дефинирани като гранични точки между IP и PSTN са сигнализационните и медия

шлюзове. Тези два компонента са сърцето на една конвергентна мрежа и трябва да бъдат приложени правилните механизми за тяхната защита, с цел минимизиране ефекта от евентуални атаки.

Интернет базиран доставчик на гласови услуги

Топологията на Интернет базиран VSP поддържа подобни ключови компоненти като предишните архитектури.

Фундаменталните разлики са липсата на възможност на доставчиците да предложат качество на услугата и

адекватна защита до своите потребители, тъй като те ползват VoIP мрежата през своите респективни Интернет

доставчици. Пример за подобен доставчик е Vonage.

При тази архитектура потребителите се свързват към Интернет чрез съответният им доставчик, а изпълняват

повиквания и получават разговори през мрежата на своя VoIP доставчик. Разговори към PSTN биват рутирани

до локалния доставчик-търговец на разговори (LEC – Local Exchange Carrier) през сигнализационния и медия

шлюз.

Регистрацията на потребителя в системата се поддържа непрекъснато, докато има Интернет свързаност, а когато тя прекъсне по една или друга причина, прекъсва и телефонната услуга.

Сигурност при различните видове доставчици

VoIP архитектурите от клас оператор поддържат определен набор от операционни и архитектурни изисквания,

тъй като основната цел е печалба чрез поддържане на непрекъснато увеличаване броя на абонатите, като се

предлагат конкурентни услуги и функции, непрекъснато достъпни, с високо качество и сигурност. За защита

срещу познати типове атаки се ползва рамка за сигурност на няколко нива.

Една от основните сфери, на която е наблегнато в тази рамката е потребителския достъп. За защита срещу

различни видове атаки и минимизиране тяхното въздействие, трябва да се наложат правилни контроли за

достъп, за автентификация, оторизация, интегритет и конфиденциалност на сигнализационните и медийни

потоци, обменяни между потребителските устройства (напр. телефони, PBX). Контролите за строг достъп до

системата минимизират възможността за изпълнение на DoS атаки и измама с услугата от страна на

неоторизирани лица, но в същото време съвсем реален изглежда сценарият при който легитимен потребител се опитва да измами услугата, стартира евентуална атака целяща засягане на услугата, както и се опита да проведе

други видове атаки. Този вид заплаха (от вътрешен оторизиран човек), се управлява чрез установяване на строги

контроли за управление на сигурността, вкл. дефинирането на политики, процедури и стандарти и налагането

на технически контрол за адекватна мрежова и приложенска сигурност, одит и логване на събития.

В днешно време, VoIP доставчиците налагат контрол за сигурност в следните сфери:

Удостоверяване на потребителското устройство

Удостоверяване на потребителите

Защита от DoS атака


78

Удостоверяването на потребителското устройство се фокусира върху удостоверяване на самото устройство

ползвано от потребителя, но не и на самия потребител. Това е различно от удостоверяването на потребителя към

мрежата или на потребителя към устройството и след това устройството към мрежата. Това означава, че и други

потребители които не могат да бъдат идентифицирани е възможно да ползват устройството за провеждане на

разговори. Методите за автентификация на устройството зависят от наличните хардуерни контроли, както и от

сигнализационните протоколи които се ползват. Хардуерните контроли могат да включват удостоверяване по

MAC адрес, чрез сертификат или комбинация от двете, или чрез друг набор от характеристики на устройството

(напр. сериен номер). Ако се ползва SIP като сигнализация, методът на удостоверяване е SIP дайджест с парола.

В зависимост от конфигурацията може да се ползва удостоверяване при всяка заявка REGISTER/INVITE или

пък устройството да опреснява регистрацията си през определен период от време. IP адресът и портовете на устройството присъстват по време на заявката за регистрация. Подобни на тези процедури се ползват и при

употребата на H.323, като там в частност се ползва RRQ.

Удостоверяването на потребители в мрежата на един VoIP доставчик се опитва да свърже даден потребител със

съответстващия му акаунт в системата. Процесът е подобен на удостоверяването на дадено устройство, но в

този случай потребителят предефинира парола, която се ползва от сигнализацията. Този метод позволява на

потребителя да ползва услугата от всяка една точка на света и от всеки софтуерен или хардуерен телефон,

поддържащ съответната сигнализация.

DoS атаките представляват една от най-съществените сфери на притеснение при VoIP доставчиците, тъй като те

влияят директно върху качеството на услугата. Този вид атаки могат да бъдат стартирани срещу потребителски

устройства или VoIP компоненти с цел разрушаване на услугата. В допълнение може да бъдат проведени атаки

от типа на SPIT. За борба с тези атаки, доставчиците ползват филтриране на трафика чрез SBC елементи, като в

зависимост от архитектурата някои методи може да са ефективни, а някои не.

Въпреки че, мерките които се вземат в днешно време от доставчиците осигуряват защита срещу някои атаки,

има възможност да се направят доста подобрения в цялостното състояние на сигурността. Фигура 8-1 показва

пример на зонално разделение, с цел налагане на защита в цялата инфраструктура.

Фигура 8-1. Пример за слоева NGN (Next Generation Network) зашита

В посочения пример, граничният контролен елемент (BCE – Border Control Element) е разделителния компонент

между зоните, делящи различните компоненти на инфраструктурата. Предлаганата от BCE функционалност е


79

зависима от типа на защитата, изисквана когато се преминава между зоните. Например, BCE което контролира

зона 3 може да наложи контрол (напр. ограничение на скоростта, инспекция на съобщенията) в мрежовия слой

(IP) за филтриране на трафика от недоверени мрежи. Контроли на приложенския слой може да бъдат също

наложени от BCE в зони 0 и 1, за защита срещу атаки към сигнализацията и потоците медия. Следният списък

описва взаимоотношенията между BCE и зоните:

BCE зона 3— налага управление на трафика и филтриране в мрежовия слой, защитава срещу атаки

произхождащи от Интернет. Между зони 2 и 3 съществува логическа сегрегация между доверените

мрежи, които взаимодействат с компоненти, лежащи в по-вътрешни зони. Тези доверени мрежи се

състоят от потребители, партньори, търговци или пиъри, и сегрегацията осигурява допълнителен слой

на защита от атаки, които могат да засегнат някой от участниците в доверения слой.

BCE зона 2— налага управление и филтрация на трафика в транспортния и приложенския слой и

защитава срещу атаки, произлизащи от доверени мрежи, които може да бъдат компрометирани или от

потребители, които имат злонамерени действия. Компонентите, които присъстват в зона 2 обикновено

осигуряват услуги за конфигурация на устройствата. Следователно, за елиминиране на атаките е нужно

да се изолират съответните компоненти (напр. DNS, TFTP, BOOTP, DHCP).

BCE зона 1— защитава компоненти като приложенски сървъри, NFS (ползван за съхранение на

платежна информация), сървъри за удостоверение (напр. Diameter), сървъри директории (напр. LDAP)

или платежни сървъри, от атаки произхождащи от зона 2 или 0. Въпреки че хост и мрежово-базираните

сензори за откриване на прониквания (HIDS и NIDS) могат да бъдат приложени в действие, даденият

пример описва NIDS между зона 1 и 2 като минимална мярка за търсене на злонамерен трафик от

външна мрежа. BCE в зона 1 може да бъде ползван за прекъсване на SSL или SRTP потоци данни, за

налагане на инспекция върху сигнализацията или медията и посрещане на дефинираните в закона изисквания за следене.

BCE зона 0— защитава ключовите компоненти, които поддържат мултимедийните услуги (напр. глас,

конференции и т.н.) Компонентите на тази зона трябва да продължат обмен на сигнализация и медия,

дори ако са засегнати компонентите на платежната система и други такива. Те трябва да бъдат

изолирани от останалата инфраструктура и трябва да бъдат въведен строг контрол за ограничение на

трафика от страна на BCE, защитаващ зона 0. Между зона 0 и 1 трябва да бъде въведена възможност за

откриване на проникване в приложенията (AP-IDS , application intrusion detection), като тя може да бъде

вградена в BCE системата.

Друга фундаментална сфера, която трябва да бъде адресирана е дефиницията и разработката на изисквания за

сигурност в критични зони свързани с VoIP мрежите, вкл. следното:

Дизайн и архитектура

Въвеждане в експлоатация

Операции

Управление и администрация

Сертификация на продукти

Договорености с други доставчици на услуги

9. Заключение

Както беше описано в някои от главите, корпоративните VoIP мрежи са под непрекъснатия риск от различни

видове атаки, а повечето системни инсталации не притежават правилните контроли за защита срещу настоящи и

бъдещи заплахи. Някои организации се отнасят по-съзнателно към въпроса за сигурността от други и поемат

необходимите предпазни мерки, за да се уверят че техните VoIP системи осигуряват подходящата сигурност и са

в състояние да минимизират въздействието от евентуални атаки.

Стандартът IEEE 802.1x осигурява протокол, който помага на организациите да наложат удостоверяване на

устройство в една корпоративна мрежа. Механизмът е ефективен за предотвратяване на неоторизиран достъп до

мрежата от неоторизирани хостове, и по този начин е способен да ограничи векторите на атака, които могат да

бъдат упражнени върху VoIP мрежата и поддържащите я компоненти. Въпреки че, 802.1x е ефективен

механизъм, той е скъп за прилагане. Вместо това, някои компании предпочитат да въведат контрол на достъп на

нодовете, чрез налагане на механизми като MAC адрес автентификация.

Удостоверяване на потребителите е друго нещо, което често се пропуска при корпоративните VoIP инсталации и

по този начин се позволява достъп до VoIP услуги и приложения на потребители, без да притежават съответното

разрешение за това. В зависимост от VoIP системата е напълно изпълнимо прилагането на удостоверяване на


80

потребителите във VoIP приложения, вкл. удостоверяване на сигнализационни и медия съобщения. В

предходните глави бе подробно обяснен процеса на защита на сигнализацията и медията, вкл. тяхното

удостоверяване.

Конфиденциалност на сигнализацията и медията е друга важна сфера, за която има тенденция организациите да

си затварят очите, поради цената, поддръжката от страна на производителя или сложността, свързана с

въвеждането на свързани с това контроли. За да се преодолеят тези пречки, се препоръчва дефинирането на

изисквания за сигурност, представени като разширение на описанието на VoIP мрежовата архитектура, и да се

дискутира това как да бъдат защитени сигнализацията и медия съобщенията.

Създаването на лог файлове и одит е важна и чувствителна сфера, свързана с VoIP сигурността. Записването на анормални или събития свързани със сигурността, позволява на фирмите да извършват подходящите

разследващи анализи в случай на инцидент. Всеки VoIP ключов мрежов елемент и асоциираните с него

компоненти, вкл. сигнализационни/медия шлюзове, повикващи агенти, сървъри за гласова поща, имейл сървъри

и т.н. трябва да поддържат лог файлове със събития, включвайки кой, кога, как и какво (напр. кой е ползвал

мрежовия елемент, кога е бил ползван, как и какво точно е било достъпно). Платежните и обезпечаващи системи

се нуждаят от допълнително внимание откъм записване на действията и одит.

VoIP е част от критичната инфраструктура и всяка една организация трябва да разбере необходимостта от

своевременната защита на всички системи, свързани с неговото правилно функциониране.


81

Съкращения и терминология

3DES Криптиращ алгоритъм, който обработва всеки блок информация три пъти, ползвайки уникален ключ всеки от пътите. Много

по-труден за разбиване от DES.

3GPP 3rd Generation Partnership Project. Участниците работят в посока установяване на стандарти и технически параметри на

мобилни системи от трето поколение.

AES Advanced Encryption Standart. Криптиращ стандарт, създаден с цел да замени DES, дефинира алгоритъм за деривация на

симетричен или частен ключ.

ACL Access Control List, списък с потребители и групи потребители и респективните им права в системата.

ACK от "ACKnowledge", символ, изпращан обратно от получателя към изпращача за потвърждение получаването на сигнал,

информация или пакет.

ARP Address Resolution Protocol. Протокол от ниско ниво, част от TCP/IP, който свързва IP адреси със съответстващите им Ethernet

такива.

ASCII American Standart Code for Information Interchange. Метод за кодиране на символи и предаването им в цифров вид (двоичен код),

така че да могат да бъдат предавани към други електронни у-ва. Дефинира общо 128 букви, цифри и пунктуационни знаци.

ASP Active Server Pages

ASN.1 Abstract Syntax Notation One. Мрежов "буквар", включващ правила и символи за описание и дефиниране на протоколи и

програмни езици.

Backdoor Недокументиран начин за достъп до една защитена система, мрежа или мрежов компонент.

BCE Border Control Element

BOOTP Bootstrap Protocol. TCP/IP протокол, позволяващ на дадено у-во да открие информацията необходима му за стартиране по

мрежата, като IP адрес например.

BOTNET Мрежа от инфектирани с троянски кон компютри, и по този начин контролирана от хакери.

CA Call Agent. Клиентска точка при MGCP.

CAM Content-Addressable Memory

CBC Cipher Block Chaining. Техника, най-вече ползвана при DES криптиращия алгоритъм, при която едно просто текстово

съобщение се разцепва на последователни блокове, първият от които се криптира с даден шифър, и с получения

шифрован текстов блок се криптира втория, като това се повтаря при всеки следващ.

CDR Call Detail Record. Запис, генериран при клиентски трафик, който се ползва след това от платежната система.

CGI Common Gateway Interface. Интерфейс за стартиране на клиентски скриптове на сървър. Най -често ползван език при него е Perl,

но също така е възможно да се ползват C++, Java, VBScript.

CID Caller ID

CIS Contact Image Sensor

IOS Cisco Internetwork Operating System. Операционна система при Cisco маршрутизаторите.

CSRC spomagatelen source sync

ChecksumСума на група битове информация, ползвана при проверка за грешки.

DAI Dynamic ARP Inspection

DHCP Dynamic Host Configuration Protocol. Протокол за динамично раздаване на IP адреси в мрежата.

DDoS Distributed Denial of Service. Координирана атака от тип отказ на услуга.

DoS Denial of Service

DH Diffie-Hellman. Техника за обмен на криптиращи ключове по време на предаването на информация. Не изисква наличието на

трета страна, която да се ползва за оторизиращ орган.

DOCSIS Data-Over-Cable Service Interface Specifications на PacketLabs

DSL Digital Subscriber Line. Най-общо наименование за цифрови наети линии, предлагани от телекомите на техните абонати по

медни чифтове.

DTLS Datagram Transport Layer Security. TLS по UDP.

DTMF Dual Tone Multi-Frequency.

DNS Domain Name Service

E.164 Препоръка на ITU-T за глобална телефонна номерация, съдържаща 16 цифри.

ENUM Стандарт, предложен от IETF, целящ свързване на всички телефонни номера към IP адреси, посредством DNS.

FTP File Transfer Protocol

Fuzzing Жаргонен термин за грубо тестване на системата, изпращайки към нея зловредни или проблематични пакети

GCF Gatekeeper Confirmation


82

GK GateKeeper. При H.323 това е точката, която извършва регистрация на медия шлюзовете и крайните точки и транслира

номера в IP адреси, извършва обезпечаване и т.н.

GKSP Gate Keeper Security Processor

GRQ Gatekeeper Request

H.323 Стандарт на ITU-T, под шапката на който се крият набор от стандарти, дефиниращи комуникацията в реално време в

пакетно-базирани мрежи

HBA Host Bus Adapter. Отговаря за връзката между микропроцесора и диск контролера.

HIDS Host-based Intrusion-Detection System. Работи, чрез откриване на атаки към хоста, на който е инсталиран.

HTTP HyperText Transfer Protocol

IAX Inter-Asterisk Exchange. Протокол за връзка на Asterisk PBX-и помежду си.

ICMP Internet Control Message Protocol. Протокол в 3-ти слой, ползван за изпращане на контролни мрежови съобщения.

IDS Intrusion Detection Service

IETF Internet Engineering Task Force. Формирана през 1986г. Организация, работеща изцяло на доброволен принцип, състояща

се от работни групи, създаващи стандартите за работа на Internet. Работните групи първо създават чернова на дадена

препоръка (RFC - Request For Comment), като се очаква одобрението или неодобрението на заинтересованите страни, и едва

след това тя бива публикувана като официална такава.

IP Internet Protocol

IPSec Набор от мерки за сигурност в IP, което включва и наличен протокол за създаване на виртуален тунел.

IKE Internet Key Exchange. Механизъм в IPSec, отговарящ за създаване на сигурни връзки между две точки в IP базиран VPN.

IMS IP Multimedia Subsystem, стандартизирана NGN архитектура базирана на 3GPP вариант на SIP

iSCSI Internet Small Computer Systems Interface. Наложил се вече протокол, за трансфер на големи блокове данни между

различните хостове при SAN(Storage Area Network) и NAS (Network Attached Storage) в IP базирани инфраструктури.

ITU International Telecommunication Union. Огранизация, създадена 1934г., базирана в Женева - най-важният

телекомуникационен орган в целия свят, отговарящ за създаване на нови стандарти, като формално той няма юридическото право

за създаване на такива, но ако неговите членове приемат даден стандарт, той автоматично се превръща в световен такъв. Състои

се от три основни сектора: ITU-R (Радиокомуникационен), ITU-T (Телекомуникационен Стандартизиращ), ITU-D

(Телекомуникационен Разработващ). ITU-T е иззел сферата на действие на CCITT (Comite Consultatif Internationale de

Telegraphique et Telephonique) - до 1982г. най-влиятелният орган за стандартизиране при телекомуникациите.

Jitter Измененията на латенцията или закъснението.

LEC Local Exchange Carrier. Локален, най-често пъти подлежащ на лицензиране, телефонен оператор.

MAC Media Access Control. Уникален идентификатор на всяко мрежово устройство.

MD5 Message Digest version 5 Algorithm. Описан в RFC1321, това е алгоритъм който взима входящо съобщение от всякаква

дължина и създава негов 128 битов "отпечатък".

MGCP Media Gateway Control Protocol. Протокол за контрол на VoIP обаждания, извършван от външен елемент, познат като

медия-шлюзови контролер (MGC), софтсуич или CA.

MITM Man In The Middle.

MIKEY Mode of Key Distribution in Multimedia Internet Keyring. Описва няколко сценария и решения за дистрибуция на ключове

при SIP и RTSP.

NAT Network Address Translation. Интернет стандарт, който позволява една локална мрежа да ползва набор от вътрешни IP

адреси за локален трафик и друг набор от външни (реални) за Интернет трафик.

NGN Next Generation Network, по-скоро маркетингов термин, свързан с VoIP мрежите.

NIDS Network Intrusion Detection Systems. Система, която извършва мониторинг върху трафика по мрежата, търсейки подозрителна

активност.

NTP Network Time Protocol. Ползван за сверяване на часа на дадено мрежово у-во.

Packet burstВ такъв режим на работа, сървърът изпраща множество пакети наведнъж към клиента, като потвърждение за тяхното

получаване се очаква едва след това.

PBX Private Branch eXchange. Фирмена или корпоративна телефонна централа.

POP Point Of Presence. Точка за достъп на една телефонна компания или доставчик на услуга.

PSTN Public Switched Telephone Network. Абревиатура на ITU-T, отнасяща се до традиционната телефонна мрежа.

PIN Personal Identification Number.

PKCS#7 Public Key Cryptographic Standart #7. Ползва се за подписване или криптиране на съобщения в PKI инфраструктура.

PKI Public Key Infrastructure. Набор от хардуер, софтуер, политика и процедури за създаване, управление, дистрибуция,

ползване и съхраняване на цифрови сертификати.

PSAP Public Safety Answering Point. Най-близката точка, от която се отговаря на едно спешно повикване (напр. до тел. 112).


83

QoS Quality of Service

Quad play Маркетингов термин, комбиниращ една Triple play услуга (високоскоростен Интернет достъп, телевизия и телефон) и безжична

услуга.

RAS Registration, Admissions and Status. Изпълняващ споменатите функции при H.323.

RAT Robust Audio Tool

RC2 Rivest Cipher

RFC Reguest For Comment. Документи, съдържащи спецификации на различни IETF приети или все още разработвани стандарти.

RPC Remote Procedure Call. Протокол, управляващ метода по който дадено приложение активира процеси в друг нод/система и

получава съответния резултат.

RRQ Receive Request

RTP Realtime Transport Protocol. Стандарт на IETF за пакетна трансмисия на мултимедия в реално време по IP.

SBC Session Border Controller. У-во във VoIP мрежите, което упражнява контрол върху сингализацията и най-често също върху

потоците медия при създаване и провеждане на интерактивна мултимедийна комуникация. Обикновено бива ситуирано между

мрежите на два доставчика в пиърингова мрежова структура, или между мрежата за клиентски достъп и опорната мрежа на

доставчика. Осигурява сигурност, качество на услугата, статистика и може да изпълнява регулаторна роля.

SDP Session Description Protocol. Описан в RFC2327, ползва се за описание на мултимедийните сесии в IP базираните мрежи.

Ползва се в SIP.

SHA-1 Secure Hash Algorithm 1. Алгоритъм, който взима съобщение с дължина до 264 бита и го сбива в 160 битово.

SIP Session Initiation Protocol. Най-важният стандарт за установяване на телефонни разговори, мултимедийни конференции,

кратки съобщения и други типове комуникация по Интернет.

SPIT Spam over Internet Telephony

SS7 Signalling System 7. Най-често мрежа със скорост 64kbit, пренасяща пакетни съобщения относно провеждащите се

разговори в дадена мрежа, с цел контрол на връзката.

STB Set-Top Box. У-во за връзка с кабелната телевизия, като спецификациите могат да бъдат много различни при различните

производители. Модерните STB могат да притежават интерфейс за IP мрежова свързаност, както и имат уникален

идентификационен номер, който позволява на доставчика да спира или пуска дадена услуга.

SCCP Signalling Connection Control Part или Skinny. Част от SS7 протокола, предлага допълнителна функционалност за рутиране и

управление при трансфер на съобщения, несвързани със самия разговор.

SIPS SIP Secure

S/MIME Secure/Multipurpose Internet Mail Extensions

Spoofing Кражба на идентичност в мрежата.

Solaris Операционна система на SUN/Oracle.

SNMP Simple Network Management Protocol. Най-разпространеният метод за управление и получаване на информация от мрежови

устройства. Работи в приложенския слой от OSI модела.

SSL Secure Sockets Layer. Криптира и подсигурява връзките във WWW, като осигурява удостоверяване, криптиране и интегритет

на съобщенията.

STUN Simple Traversal of UDP through NAT. Протокол, позволяващ на у-вата зад NAT да рутират пакети.

SYN SYNchronous. При TCP - единичен бит, сред общо 6 контролни бита в TCP хедъра. Ползва се за синхронизация на

последователността и номерация на TCP пакетите.

Syslog System log. Файл, в който се записва всичко случващо се в операторската конзола на едно PC.

TCP Transport Control Protocol. Протокол за транспорт от край-до-край в 4-ти слой на OSI модела.

TLS Transport Layer Security. Стандартен протокол за сигурност, описан в RFC2246 на IETF.

Triple play Маркетингов термин, означаващ глас, данни и видео по един мултимедиен канал.

TDM Time Division Multiplex. Технология за трансмисия на определен брой различни информационни, гласови и/или видео

сигнали едновременно по една комуникационна медия, като сигналите се разбиват и изпращат на поредни части.

Telnet Програма, позволяваща връзка до други компютри по Интернет.

TFTP Trivial File Transfer Protocol. Опростен вариант на FTP, който не поддържа пароли или защита на файловете.

UA User Agent. Крайна точка, действаща от името на потребител.

UDP User Datagram Protocol. Част от TCP/IP, позволява предаването на инфорграми (datagram-и), без получаване на обратно

потвърждение на тяхното получаване.

URI Uniform Resource Identifier. Идентификатор, указващ чрез име, място или друга характеристика даден ресурс в Интернет.

URL Uniform Resource Locator. Съкращение, означаващо адрес в мрежата, водещ до определен файл или уеб страница по HTTP

протокола.

VLAN Virtual Local Area Network. Логическо групиране на потребители, без значение на тяхното физическо местоположение в


84

мрежата.

VoIP Voice over IP

VPN Virtual Private Network. Виртуална мрежа, изградена от отдалечени точки, създаваща впечатление и служеща като локална

мрежа.

VSP Voice Service Provider

WWN World Wide Name. Уникален идентификатор при оптично-каналните, ATA или SCSI устройствата.

ZRTP Z Real Time Protocol. Протокол за договаряне на ключове и криптиране на VoIP разговор, ползващ Diffie-Hellman за обмен на

ключове и SRTP за транспорт на медията. Разработен от Фил Цимерман.


85

Източници:

Hacking VoIP, 1st Edition, автор Himanshu Dwivedi

Practical VoIP Security, автори Larry Chaffin; Jan Kanclirz, Jr.; Thomas Porter; Choon Shim; Andy Zmolek

Securing VoIP Networks: Threats, Vulnerabilities, and Countermeasures, автори Peter Thermos; Ari Takanen

Voice over IP Security Alliance, http://voipsa.org

RTP, A Transport Protocol for Real-Time Applications, http://www.faqs.org/rfcs/rfc1889.html

Gibson Research Corporation: Arp Cache Poisoning, http://www.grc.com/nat/arp.htm

S. Niccolini. VoIP Security Threats, http://tools.ietf.org/id/draft-niccolini-speermint-voipthreats-00.txt

S. Lawrence, Problems with Max-Forwards Processing (and Potential Solutions) IETF Draft, http://tools.ietf.org/html/draft-

lawrence-maxforward-problems-00

D. Shin and C. Shim, "Voice SPAM Control with Gray Leveling," Proceeding of 2nd VoIP Security Workshop

Fraud Analysis in IP and Next-Generation Networks. The International Engineering Consortium,

http://www.iec.org/online/tutorials/fraud_analysis/

S. Kent and R. Atkinson. Security Architecture for the Internet Protocol (IPSec). RFC 2401

M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Norrman. "The Secure Real-time Transport Protocol (SRTP)," IETF RFC 3711

F. Andreasen, M. Baugher, D. Wing. Session Description Protocol Security Descriptions for Media Streams, IETF draft draft -ietf-mmusic-

sdescriptions-12.txt

J. Bilien, et al. Secure VoIP: Call Establishment and Media Protection. Royal Institute of Technology (KTH). Stockholm, Sweden

J. Arkko, et. al. MIKEY: Multimedia Internet KEYing. IETF RFC 3830

Cisco TLS Implementation Steps, TLS imlementation

Avaya TLS Implementation Steps, http://support.avaya.com/elmodocs2/sip/S6200SesSip.pdf

Asterisk SRTP Implementation Steps, http://www.voip-info.org/wiki/view/Asterisk+SRTP

libSRTP, an open source library for SRTP, http://srtp.sourceforge.net/srtp.html

PacketCable, Security technical Report, [PKT-TR-SEC-V01-060406]

PacketCable Architecture Framework Technical Report [PKT-TR-ARCH- ARCHFRM-V01-060406]

Symantec SecurityFocus, http://www.securityfocus.com/archive/1

MITRE CVE database, http://cve.mitre.org

BackTrack 4, http://www.remote-exploit.org Newton’s Telecom Dictionary

http://voipsa.org/

http://www.faqs.org/rfcs/rfc1889.html

http://www.grc.com/nat/arp.htm

http://tools.ietf.org/id/draft-niccolini-speermint-voipthreats-00.txt





http://www.cisco.com/en/US/docs/ios/12_3/vvf_c/cisco_ios_sip_high_availability_application_guide/hachap2.html#wp1136622

http://support.avaya.com/elmodocs2/sip/S6200SesSip.pdf

http://www.voip-info.org/wiki/view/Asterisk+SRTP

http://srtp.sourceforge.net/srtp.html

http://www.securityfocus.com/archive/1

http://cve.mitre.org/

http://www.remote-exploit.org/

Сигурност във voip мрежите

Documents