Radius Server

Универзитет Св. Кирил и Методиј

Факултет за електротехника и информациски

Институт за компјутерска техника и информатика

Семинарска работа по предметотБезжични компјутерски мрежи

RADIUS Server

Ментор:

Доц. д-р Соња Филипоска

Универзитет Св. Кирил и Методиј - Скопје


технологии


Семинарска работа по предметот Безжични компјутерски мрежи

RADIUS Server

р Соња Филипоска Злате Ристовски 131/2007 ИКИ Ивана Костадиновска 248/2007 ИКИ

Скопје, август 2010



Изработиле:

Злате Ристовски 131/2007 ИКИ Ивана Костадиновска 248/2007 ИКИ

2

Содржина

Апстракт ................................................................................................................................................. 4

Вовед ...................................................................................................................................................... 4

Краток преглед на ААА ......................................................................................................................... 5

Автентикација .................................................................................................................................... 6

Авторизација ...................................................................................................................................... 6

Верификација .................................................................................................................................... 6

Главни карактеристики на ААА архитектурата ................................................................................... 6

Авторизациска работна рамка ............................................................................................................. 8

Авторизациски секвенци .................................................................................................................. 8

Роаминг ............................................................................................................................................ 10

Управување со ресурси и сесии ..................................................................................................... 11

Карактеристики на RADIUS ................................................................................................................. 11

Користење на UDP наместо TCP ..................................................................................................... 11

Формати на пакети .......................................................................................................................... 12

Code(код) ...................................................................................................................................... 12

Identifier(идентификатор) ........................................................................................................... 13

Length(должина) .......................................................................................................................... 13

Authenticator(автентикатор) ....................................................................................................... 13

Типови на пакети ............................................................................................................................. 13

Access-Request ............................................................................................................................. 13

Access-Accept ............................................................................................................................... 14

Access-Reject ................................................................................................................................ 14

Access-Challenge ........................................................................................................................... 15

Атрибути и вредности ..................................................................................................................... 15

Атрибути ....................................................................................................................................... 16

Типови на атрибути ................................................................................................................. 16

Вредности .................................................................................................................................... 17

Методи за автентикација................................................................................................................ 17

PAP ................................................................................................................................................ 18

CHAP.............................................................................................................................................. 18

Стандардни RADIUS атрибути......................................................................................................... 18

Верификација на RADIUS (RADIUS Accounting) .................................................................................. 23

3

Клучни точки за верификацијата на RADIUS ................................................................................. 23

Основна операција .......................................................................................................................... 24

Повеќе за Proxying ....................................................................................................................... 24

Формат на верификацискиот пакет ............................................................................................... 25

Code (код) ..................................................................................................................................... 25

Identifier (идентификатор) .......................................................................................................... 25

Length (должина) ......................................................................................................................... 25

Authenticator ................................................................................................................................ 25

Надежност на верификацијата ................................................................................................... 26

Типови на верификациски пакети ................................................................................................. 26

Специфични верификациски атрибути ......................................................................................... 27

Безбедност на RADIUS ......................................................................................................................... 29

Недостатоци ..................................................................................................................................... 29

MD5 и споделена тајна ............................................................................................................... 29

Access-Request пакетот ............................................................................................................... 29

Usher-Password Cipher шема ...................................................................................................... 30

User-Password Shared Secred ...................................................................................................... 30

User-Password атрибут и напади на лозинката ......................................................................... 30

Напади кои користат автентикациско барање ......................................................................... 31

Повторливи автентикациски барања и User-Password атрибутот ...................................... 31

Проширен Автентикациски Протокол (EAP) ................................................................................. 31

Компензација за недостатоците .................................................................................................... 33

Заклучок ............................................................................................................................................... 34

Користена литература ......................................................................................................................... 35

4

Апстракт Во оваа семинарска ќе биде опишан Remote Authentication Dial In User Service (RADIUS) мрежниот протокол кој обезбедува централизирано автентицирачко, авторизациско и верификациско управување на компјутерите кои се поврзуваат и ги користат мрежните сервиси. На почетокот ќе биде даден краток вовед за RADIUS, ќе бидат дадени некои негови главни особини, кои подоцна повторно ќе бидат спомнати. Понатаму ќе се даде опис на ААА, за што служи, од што се состои, каква е ААА архитектурата, што содржи авторизациската работна рамка, какви се секвенци постојат и зошто се користат. На сите овие прашања одговор може да се најде во темата која го опишува ААА. После темата за ААА, следува темата за карактеристиките на RADIUS, во која ќе се даде одговор на прашањето зошто користи UDP, наместо TCP. Ќе се даде форматот на пакетот кој RADIUS го користи, типовите пакети кои се користат, како и кои атрибути може да се користат во овие пакети, на крајот од темата ќе бидат набројани сите стандардни RADIUS атрибути. Како следни теми се темите за верификација на RADIUS и безбедност на RADIUS. Во верификација на RADIUS ќе бидат опишани особините на верификациониот RADIUS, потоа форматот на верификациските пакети, типовите на пакети, а на крај и верификациските RADIUS атрибути. Во безбедноста на RADIUS ќе бидат дадени неговите недостатоци, од какви напади треба да се внимава, како да се заштитат податоците, а на крајот од темата ќе биде опишан и EAP протоколот со кој се зголемува безбедноста. А како за крај во заклучокот ќе се опишат најважните карактеристики на RADIUS, како и тоа кои се следните чекори во развојот на овој протокол.

Вовед RADIUS е клиент/сервер протокол кој работи во апликацискиот слој, со користење на UDP. Remote Access Server(сервер за оддалечен пристап), сервер за виртуелна приватна мрежа со порт-базирана автентикација, како и Network Access Server(NAS) се gateways(премини) кои го контролираат пристапот до мрежата и сите тие имаат RADIUS клиент компонента која комуницира со RADIUS серверот. Како последен дел од воведот се дадени неколку главни особини и карaктеристики на RADIUS: Клиент/Сервер модел

Серверот за мрежен пристап(NAS) како што веќе е спомнато комуницира со RADIUS како клиент. Клиентот е одговорен за испраќање на корисничките информации до именуваните RADIUS сервери како и да го извршат одговорот кој ќе им биде пратен. RADIUS серверите пак, се одговорни за примање на корисничките барања за поврзување, автентицирање на корисникот и после тоа давање на информации за конфигурацијата која е потребна клиентот да ја поседува за успешно да ги користи сервисите. Исто така RADIUS сервер

5

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

Мрежна безбедност

Трансакциите помеѓу RADIUS серверот и клиентот се автентицирани со користење на споделена тајна, која никогаш не се испраќа низ мрежата. Сепак, секоја корисничка лозинка која се праќа помеѓу клиентот и серверот е енкриптирана, се со цел да се елеминира можноста од душкање на необезбедена мрежа и некој да ја дознае корисничката лозинка. Флексибилен автентикациски механизам

RADIUS серверот нуди различни методи за автентикација на корисник. Некои од методите се PPP, PAP или CHAP, дел од овие методи подоцна ќе бидат опишани повеќе.

Краток преглед на ААА Рамката околу која RADIUS е изграден е позната како ААА процес, кој се состои од автентикација, авторизација и верификација(accounting). Иако RADIUS нема ништо специфично со ААА моделот, сепак овој модел се користи за да се опишат повеќето карактеристики на RADIUS. RADIUS е создаден уште пред ААА моделот да биде креиран (развиен), но сепак тој претставува првиот реален протокол кој е базиран на ААА и чиишто ААА функционалности се во широка употреба и прифатени од индустријата. Овој модел служи за управување и прикажување на сите трансакции од почеток до крај. Со одговарање на следниве прашања можат да се опишат функционалностите на ААА:

• Кој си ти?

• Кои сервиси(услуги) ми се дозволени за да ми ги дадеш?

• Што правеше со сервисите додека ги користеше? Најпрвин треба да се погледне зошто ААА архитектурата е подобра стратегија од сите останати стратегии. Пред ААА да биде воведена, посебна опрема е користена за автентикација на корисниците. Без пропишани стандарди, секоја машина посебно си има свој метод за автентикација – некои можеби користат профили, други пак го користат Challenge/Handshake Authentication Protocol (CHAP-протокол за добивање на автентикација преку метод на натпреварување или “поздравување”). Со различните автентикации за секој корисник посебно, се доаѓа до еден голем проблем, а тоа е потребата од постојано зголемување на капацитетот на мрежата со додавање на друга опрема што би довело до ноќен кошмар. За да нема повеќе вакви слични проблеми, од страна на IETF се формира ААА работна група која има за цел да создаде функционална архитектура со која би се избегнало ограничувањето на системот опишано погоре. Очигледно, треба да се даде фокус на децентрализирање на опремата и набљудување на користењето на опремата во хетерогени мрежи. Со почетокот на нудењето на услуги како што се dual-up, ISDN, xDSL, а подоцна и можност за користење на кабелски модем, како и потребата за на еден стандарден начин корисниците да можат да бидат верифицирани, најавени и набљудувани на мрежата, после долга работа е создадена ААА архитектурата.

6

ААА моделот се фокусира на три значајни аспекти од контролата за пристап на корисник: автентикација, авторизација, верификација.

Автентикација

Автентикација е процес на потврда на идентитетот на одредена личност или машина. Најчеста форма на автентикација е користењто на комбинација од ID за најава, и лозинка, при што со познавањето на лозинката се докажува дека корисникот е веродостоен. Како и да е со дистрибуирањето на лозинката овој метод на автентикација станува неефикасен, па така креаторите на страници за е-комерција и останатите Интернет бизнисмени бараат построга и подоверлива автентикација. Дигиталните сертификати е едно од решенијата и во следните пет до десет години дигиталните сертификати како дел од инфрастуктурата на јавен клуч(PKI) ќе биде претпочитан автентикатор на Интернет. Клучниот аспект од автентикацијата е тоа што дозволува два единствени објекти да формираат доверлива врска – се претпоставува дека се валидни корисници. Довербата помеѓу системите дозволува функционалности како што се proxy серверите, каде системот доделува барање на друг систем со поголем приоритет и дозволува ААА имплементации за да се поврзат разновидни мрежи кои подржуваат различни типови на клиенти и сервиси.

Авторизација

Авторизацијата вклучува користење на множество од правила или други шаблони со кои се одлучува што може автентицираниот корисник да прави на системот. Систем администраторот ги дефинира овие правила. Таканаречената “паметна имплементација” на ААА серверите во себе вклучуваат логика со кои ги анализираат барањата и го доделуваат пристапот за тоа што се може клиентите да прават. На пример, конектиран dual-up клиент упатува барање за мултилинк конекција, општиот ААА сервер едноставно ќе го одбие барањето, но паметната имплементација најпрвен ќе го обработи барањето, ќе одреди дали на клиентот му е дозволена само една dial-up конекција и дури тогаш ќе го прифати или ќе го одбие барањето.

Верификација

Верификацијата е последна од ААА моделот, со неа се врши документирање на ресурсите кои корисникот ги користел за време на пристапот. Ова може да го вклучува вкупното траење на системското време или пак вкупната количина на податоци кои корисникот ги испратил/добил за времетраењето на сесијата. Верификацијата во себе вклучува статистика за сесијата, информации кои подоцна се користат за контрола на авторизацијата, фактурурање, користењето на ресурсите, активности за планирање на капацитетот итн.

Главни карактеристики на ААА архитектурата ААА архитектурата посебно ги опишува ААА деловите и нивните комуникации помеѓу себе. ААА имплементацијата може да биде едноставна или комплексна, но тоа зависи од Internet

7

Research Task Force(IRTF) ААА работната група која се обидува да направи што е можно повеќе неутрален модел. Со други зборови ова значи дека ААА моделот е дизајниран да работи во околини со различни кориснички потреби и различен дизајн на мрежата. Постојат неколку клучни атрибути со кои се овозможува ваков модел. Прво, ААА моделот зависи од клиент/сервер интеракцијата, во која клиентскиот систем побарува сервиси или ресурси од серверскиот систем. Во клиент/сервер околините се користи балансиран дизајн затоа што достапноста и времето на одговор се критични. Серверите може да бидат дистрибуирани и децентрализирани од мрежата. Како спротивност на ова е мрежниот модел, peer-to-peer(P2P) мрежа. Со P2P мрежите сите системи ги прикажуваат карактеристиките и на клиент и на сервер системите, при што се јавува доцнење во процесирањето и недостапност. Еден ААА сервер може да биде конфигуриран за обработка на барањето или пак да го предаде на друг ААА сервер, а тој ААА сервер може да го обработи барањето или пак да го предаде на друг сервер. Во суштина, се креира синџир од прокси(proxy), во кој ААА серверите обработуваат барања и од двата клиенти или пак од друг ААА сервер. Проксинг е многу корисна карактеристика во ААА моделот, со него се овозможуваат дистрибуирани мрежни имплементации, во кои дел од ААА опремата може да биде конфигурирана да ги препрати сите барања до машини на други локации. Клиентите со барањата за сервиси и ресурси од ААА сервер може да комуницираат меѓусебно со користење на hop-to-hop или end-to-end трансакција. Во hop-to-hop трансакцијата, клиентот испраќа иницијално барање до ААА уред. Од оваа точка, постои доверлива врска помеѓу клиентот и ААА серверот. ААА серверот одредува дали барањето треба да биде препратено до друг сервер на друга локација, па тогаш тој се однесува како прокси и контактира со друг ААА сервер. Сега доверливата врска е помеѓу серверите, а треба да се напомене дека по природа доверливата врска не е транзитивна. Ова значи дека иницијалниот клиент и вториот ААА сервер немаат доверлива врска. На слика 1 е прикажана независна доверлива врска во hop-to-hop трансакција.

Слика 1: Независна доверлива врска во hop-to-hop трансакција

Сосема различен од hot-to-hop моделот е end-to-end трансакцијата. Клучната разлика е во лажната доверлива врска, таа е помеѓу клиентот кој упатува барање и иницијалниот ААА сервер кој го обработува барањето. Во end-to-end моделот, синџирот од прокси е доста функционален за модел каде што не е неопходно потребен. Овој тип на трансакција е даден на слика 2.

8

Слика 2: Клиент/сервер доверлива врска во end-to-end моделот

Авторизациска работна рамка Авторизациската работна рамка го воведува концептот на корисничка домашна организација – User Home Organization(UHO), кој претставува ентитет кој има директна контрактуална врска со крајниот корисник. Исто така и понудувачот на сервиси – service provider(SP) е вклучен, кој врши одржување на видливите мрежни ресурси. За правилно функционирање, UHO и SP треба да припаѓаат на иста организација, како пример тоа може да биде ISP.

Авторизациски секвенци

Постојат неколку различни методи во кои крајниот корисник, ААА серверот, како и мрежната опрема да можат да комуницираат меѓусебе за време на трансакцијата. Попрецизно, постојат три различни секвенци во кои секоја машина посебно е опфатена. Agent секвенца

Во оваа секвенца, ААА серверот се однесува како човек во средина помеѓу сервисната опрема и крајниот корисник. Крајниот корисник најпрвин го иницијализира контактот со ААА серверот, кој пак го авторизира корисничкото барање и испраќа порака до сервисната опрема известувајќи го за типот на сервисот кој треба да го користи. Сервисната опрема исто така ја известува и ААА машината, при што известувањето поминува и низ крајниот корисник, кој пак дури после известувањето почнува да ја користи мрежата. Оваа секвенца обично се користи во широко појасните апликации каде што е опфатен и квалитетот на сервис. Pull секвенца

Dial-in корисниците често наидуваат на оваа секвенца. Во оваа ситуација крајниот корисник директно се поврзува со сервисната опрема, која пак се поврзува со ААА серверот за тој да одреди кој тип на барање ќе му се додели. Откако ААА серверот ќе ја извести сервисната опрема за својата одлука, сервисната опрема ќе изврши конектирање или исклучување на крајниот корисник со мрежата.

9

Push секвенца

Push секвенцата врши промена на доверливата врска помеѓу сите машини во трансакцијата. Корисникот прво се конектира(поврзува) со ААА серверот, откако барањето до серверот е авторизирано, ААА серверот дистрибуира некој тип на автентикациска потврда (можеби дигитален сертификат) назад до крајниот корисник. Крајниот корисник кај оваа секвенца се однесува како агент помеѓу ААА серверот и сервисната опрема. На следниве слики визуелно е прикажана авторизациската трансакциска секвенца. На слика 3 е прикажана agent секвенцата, во која ААА серверот се однесува како човек во средина помеѓу клиентот и сервисната опрема.

Слика 3: Agent секвенца

На слика 4 е дадена pull секвенцата, во која крајниот корисник директно комуницира со сервисната опрема. Сервисната опрема ја зема авторизацијата од ААА серверот за да знае дали да го поврзе со мрежата.

Слика 4: Pull секвенца

Слика 5 ја прикажува push секвенцата, во која клиентскиот систем зема авторизација од ААА серверот и после тоа комуницира со сервисната опрема.

Слика 5: Push секвенца

10

Роаминг

Кога ААА серверот и сервисната опрема се во сопственост на иста организација и се управуваат од истата таа организација, тогаш не е потребен роаминг. Роамингот се воведува тогаш кога сервисната опрема е сопственост на друга организација, а и раководена од таа организација. Истата комбинација oд авторизациски секвенци – agent, push и pull се можни со роаминг. Сликите 6,7 и 8 ги прикажуваат типичните роаминг авторизациски секвенци.

Слика 6: Роаминг agent секвенца

Слика 7: Роаминг pull секвенца

Слика 8: Роаминг push секвенца

11

Управување со ресурси и сесии

Последниот дел од авторизациската работна рамка се спецификациите за управувањето со ресурси и сесии. Управувањето со ресурси претставува способност за следење на ресурсите кои претходно биле доделени. Посебна програма која би се викала “resource manager” би била способна за добивање и прикажување на информации за ресурсите во реално време. Меѓутоа се јавува проблем кога се користат повеќе ААА сервери чиишто сообраќај целосно не се следи во реално време, па затоа најдобро е опремата да припаѓа на една ентитетска област, односно на еден ААА сервер истовремено. Управувањето со сесии е способност на протоколот или пак на дел од опремата да го извести ААА серверот за промена на условите за работа, односно да изврши промена на моменталната сесија. Оваа сесија може да биде променета, да биде ставена на чекање или пак да биде прекината во зависност од променетите услови кои се наоѓаат во управувачот со ресурси.

Карактеристики на RADIUS RFC спецификациите за RADIUS протоколот пропишуваат дека RADIUS:

• е UDP базиран протокол кој не користи директни конекции

• го користи hop-by-hop безбедносниот модел

• нуди подршка за PAP и CHAP автентикација преку PPP

• користи MD5 хаш секвенца за заштита на лозинките

• обезбедува преку 50 парови атрибут-вредност

• го подржува ААА моделот

Користење на UDP наместо TCP

Прашање кое често се поставува за RADIUS е зошто протоколот користи UDP, а не TCP. UDP е избран за целосно да ги задоволи сите оперативни потреби бидејќи RADIUS има неколку својствени карактеристики кои се и карактеристики на UDP: RADIUS побарува сите неуспешни барања кои се упатени до примарниот автентикациски сервер да бидат пренасочени до секундарниот сервер, а за да се направи ова мора да постои копија од оригиналното барање над транспортниот слој од OSI моделот. Со TCP пак, клиентите и серверите мора да имаат специјални кодови или администраторски дозволи за да ги намалат ефектите од губење на енергија, рестарирање, обилен мрежен сообраќај итн. UDP ги спречува овие ефекти бидејќи дозволува да се отвори една сесија и да остане отворена за цело времетраење на трансакцијата. UDP овозможува RADIUS да опслужува повеќе барања истовремено и секоја сесија да биде исполнета, исто така овозможува и отворена комуникација помеѓу мрежната опрема и клиентот. Единствениот недостаток на UDP е тоа што развивачите мораат да креираат и да управуваат со преиспраќачќите бројачи за ретрансмисија – оваа карактеристика ја има во TCP, но таму бројачите не се креираат посебно како кај UDP.

12

Формати на пакети

RADIUS протоколот користи UDP пакети кои се користат за извршување на преносот помеѓу клиентот и серверот. Протоколот комуницира на порта 1812 и не е истата порта која се наоѓа во оригиналиот RADIUS RFC документ. Оригиналната порта е 1645, но подоцна е извршена промена затоа што се увидело дека би настанало конфликт со “Datametrics” сервисот. RADIUS користи однапред дефинирана структура на пакетот за комуникација која е дадена на слика 9.

Слика 9: Податочна структура на RADIUS пакетот

Податочната структура се состои од пет полиња и тоа: code(код), identifier(идентификатор), length(должина), authenticator(автентикатор) и attributes and values(атрибути и вредности).

Code(код)

Code полето е големо еден бајт и со него се прави разлика во типот на RADIUS пораката која е испратена во пакетот. Пакетите со невалидно code поле се отфрлаат, а валидни кодови за употреба се следните: 1

Access-Request 2

Access-Accept 3

Access-Reject 4

Accounting-Request 5

Accounting-Response 11

Access-Challenge 12

Status-Server(се уште во развој) 13

Status-Client(се уште во развој) 255

13

Reserved(резервиран)

Identifier(идентификатор)

Identifier полето е големо еден бајт и се користи за извршување на threading (слабо поврзување) или пак за автоматско поврзување на иницијалното барање со следниот одговор.

Length(должина)

Length полето е големо 2 бајти и се користи за да се специфицира големината на RADIUS пораката. Вредноста која се наоѓа во ова поле се пресметува со одредување на зафатената големина на code, identifier, length, authenticator и attribute полето. Од ова поле се зема вредноста која ја содржи, секогаш кога RADIUS серверот добива пакет за да го провери податочниот интегритет.

Authenticator(автентикатор)

Authenticator полето обично е големо 16 бајти и во ова поле се врши верификација и проверка на интегритетот на пораката. Ова поле се користи во механизмот за прикривање на лозинката. Постојат два специфични автентикаторски вредности: барање(request) и одговор(response). Автентикаторската вредност барање се користи во authentication-request и accounting-request пакетите. Кај автентикаторската вредност барање, полето е големо 16 бајти и се генерира на случаен начин за да се спречи било каков напад. Со генерирањето случајни вредности се создава лозинка со која нападите и душкањето на мрежите стануваат премногу тешки за имлементација. Автентикаторската вредност одговор се користи во access-accept, access-reject и access-

challenge пакетите. Оваа вредност се пресметува со користење на едностран MD5 хаш, кој се генерира од вредностите во code, identifier, length и request-authenticator полињата од заглавието на пакетот.

Типови на пакети

Има четири типови на RADIUS пакети кои се однесуваат на автентикациските и авторизациските фази од ААА трансакцијата, тоа се: access-request, access-accept, access-reject и access-challenge.

Access-Request

Тип на пакет Одговор(response)

Code(код) 1

Identifier(идентификатор) Еден по барање

Length(должина) Должина на заглавието плус дополнителни податоци за атрибутот

Authenticator(автентикатор) Барање(request)

Податоци за атрибутот 2 или повеќе

Пакетот access-request се користи од страна на корисникот на сервиси кога тој побарува посебен(поединечен) сервис од мрежата. Клиентот го испраќа request пакетот до RADIUS

14

серверот со листа на сервисите кои ги побарува. Значајно за овој пренос е code полето кое се наоѓа во заглавието чија вредност треба да биде сетирана на 1. Payload-от на access-request пакетот треба да го вклучува атрибутот корисничко име кое се користи за идентификација на личноста која сака да добие пристап до мрежните ресурси. Payload-от треба да ја содржи IP адресата или каноничното име на мрежата од која се побаруваат сервисите. Исто така треба да ја содржи и лозинката на корисникот која мора да е CHAP базирана или пак идентификатор, но не и двата типа(лозинка или идентификатор) истовремено. Лозинката мора да биде хаширана со користење на MD5. Структурата на access-request пакетот е дадена на слика 10.

Слика 10: Типичен access-request пакет

Access-Accept

Тип на пакет Одговор

Code(код) 2

Identifier(идентификатор) Идентично со access-request по трансакција

Length(должина) Големината на заглавието плус дополнителни податоци за атрибутот

Authenticator(автентикатор) Одговор


Access-accept пакетите се испраќаат од страна на RADIUS серверот до клиентите за да ги известат дека нивното барање за пристап е одобрено. Ако сите барање во access-request се прифатливи, тогаш RADIUS серверот мора code полето во пакетот со одговор да го постави на 2. Клиентот, по добивањето на accept пакетот, проверува дали се совпаѓа со response пакетот со користење на identifier полето. Пакетите кои не се совпаѓаат се отфрлаат. Access-accept пакетот може да содржи помалку или повеќе информации за атрибутите кои треба да ги вклучи. Најчесто со информациите за атрибутот се опишуваат типовите на сервиси кои треба да бидат автентицирани и авторизирани за да може клиентот да ги користи овие сервиси. Како и да е, ако во пакетот не се вклучени информации за атрибутите, тогаш клиентот претпоставува дека сервисите кои ги побарува се одобрени. На слика 11 е прикажана структурата на access-accept пакетот.

Слика 11: Типичен access-accept пакет

Access-Reject


Code(код) 3

Identifier(идентификатор) Идентично со access-request



15


RADIUS серверот треба да испрати access-reject пакет назад до клиентот ако мора да одбие некои од сервисите кои клиентот ги побарува во access-request пакетот. Access-request пакетот може да биде испратен било кога за цело времетраење на сесијата, што го прави идеален за конекции кои имаат ограничено време на користење. Како и да е, целата опрема не подржува примање на access-request пакетот за време на воспоставување на конекцијата. Payload-oт за овој тип на пакет е ограничен на два специфични атрибути: reply-message и proxy-

state атрибутите, кои можат да се појават повеќе од еднаш во payload-от на пакетот. Структурата на овој пакет е дадена на слика 12.

Слика 12: Типичен access-reject пакет

Access-Challenge


Code(код) 11

Identifier(идентификатор) Идентично со access-request




Ако серверот добие несоодветни информации од корисникот, кој може да побарува повеќе информации или пак сака да употреби лажна автентикација, тогаш серверот може да испрати access-challenge пакет до клиентот. Клиентот пак, по добивањето на овој тип на пакет, ќе мора повторно да испрати access-request пакет кој ќе ги вклучува сите потребни информации. Треба да се забележи дека некои од клиентите не нудат подршка за процес како што е овој. Во тој случај, клиентот, access-challenge пакетот го гледа како access-reject пакет. Слично како и кај access-reject пакетот, постојат два стандардни атрибути кои се вклучени во access-challenge пакетот: state и reply-message атрибутите. Структурата на access-challenge пакетот е прикажана на слика 13.

Слика 13: Типичен access-challenge пакет

Атрибути и вредности

Целата RADIUS трансакција се состои од испраќањето и примањето на паровите атрибут-вредност (AVPs – attribute-value pairs) од и до клиентот и серверот, кои парови всушност ги содржат сите карактеристики на ААА трансакцијата.

16

За да се подобри безбедноста, RADIUS RFC врши ограничување на некои атрибути кои се праќаат со одредени пакети, така на пример, за лозинката да биде подобро заштитена, user-

password атрибутот никогаш не смее да се испраќа во возвратниот пакет (пакетот со одговор) од серверот до клиентот. Атрибутите го запазуваат форматот на полињата во пакетите:

Attribute number (број на атрибут)

Овој број го покажува типот на атрибутот кој се наоѓа во пакетот. Иметот на атрибутот не се наоѓа во пакетот, туку само неговиот број. Генерално, броевите на атрибутите имаат опсег од 1-255, со еден специфичен број кој служи како “gateway” за да можат и производителите да употребуваат свои специфични атрибути. Attribute length (должина на атрибутот)

Ова поле ја дава должината која ја зафаќа атрибут полето, која мора да биде 3 или поголема. Value (вредност)

Ги содржи сите карактеристики на соодветниот атрибут, ова поле мора да биде дадено за секој атрибут дури и тогаш кога неговата вредност е null. Должината на ова поле зависи од природата на самиот атрибут.

Атрибути

Атрибутите ги даваат карактеристиките на типот на сервисот. Тие се пренесуваат заедно со RADIUS пакетот во однапред дефиниран, стандарден формат, кој е прикажан на слика 14.

Слика 14: Стандарден AVP пренос

RADIUS серверот знае доволно за еден атрибут, како на пример, дека не е потребно официјалното име на атрибутот при преносот, дека кодниот број (бројот на атрибутот) е доволен за да заклучи каков тип на информација се пренесува во вредноста.

Типови на атрибути

Со типовите на атрибути се опишува типот на вредноста, дали таа е број, IP адреса, податок итн. Постојат шест типа кои се наведени во RFC: Integer (INT) – целобројна вредност

Вредностите од тип integer содржат цели броеви, кои се читаат така како што доаѓаат. Пример атрибутот idle-timeout може да биде сетиран на целобројната вредност 15. Enumerated (ENUM) – набројана вредност

17

Овој набројан тип се состои од цели броеви, но вредноста е базирана на кориснички-конфигуриран опсег од вредности и знаци. IP Address (IPADDR) – IP адреси

Овој податочен тип е 32-битен број со кој се формира IP адреса од верзија 4. Со проширувањето на RADIUS протоколот се овозможува и користење на IPv6 адреси. Character String (STRING) – низа од карактери

Карактер стрингот се дефинира да биде UTF-8 стринг за да може да се печати. Податокот е конвертиран во низа од карактери која може да е со ограничена или неограничена должина. Date (DATE) – датум

Овој тип е 32-битен недоделен (unsigned) број кој ги прикажува изминатите секунди од 1. 1. 1970 година. Binary (BINARY) – бинарен тип

Особено важни за имплементацијата, бинарните вредности(“0” или “1”) се читаат по нивната номинална вредност.

Вредности

Како што е претходно спомнато, сите атрибути мора да имаат вредности, дури и ако вредноста за атрибутот е null. Вредностите ја прикажуваат информацијата за која секој атрибут е дизајниран да ја пренесе. Тие се носители на “сршта” на информацијата. На следната табела се дадени примери за секој тип на атрибут, должината на типот во бајти и неговата големина.

Тип на атрибут Должина(во бајти) Големина/опсег Примери

Integer(INT) 4 32-бита недоделена 6, 256, 2432

Enumerated(ENUM) 4 32-бита недоделена 3=Callback-Login, 13=Framed-Compression

String(STRING) 1-253 Променлива “Charly”, “206.229.54.2”

IP Address(IPADDR) 4 32-бита 0xFFFFFF, 0x19F8E

Date(DATE) 4 32-бита недоделена 0xC0A80102

Binary(BINARY) 1 1 бит 1

Методи за автентикација

RADIUS нуди подршка за различни протоколи чијашто задача е да извршат безбеден пренос на чувствителниот кориснички податок од и до серверот за автентикација. Најчесто користените протоколи кои се користат за оваа задача се Password Authentication Protocol(PAP) и CHAP. Сепак RADIUS нуди подршка и за останати протоколи кои се специфични за одредени производители кои работат со сопствени креирани атрибути. Во овој дел ќе бидат опишани претходно споменатите протоколи кои најчесто се користат PAP и CHAP.

18

PAP

User-password атрибутот во request пакетот му сигнализира на RADIUS серверот дека PAP протоколот ќе се користи за таа трансакција. Важно е да се забележи дека во овој случај единственото задолжително поле е user-password полето, user-name полето не треба да биде вклучено во request пакетот. Алгоритмот кој се користи за да ја сокрие оригиналната корисничка лозинка се состои од многу елементи. Прво, клиентот го пронаоѓа идентификаторот на оригиналното барање и го доставува до MD5 хаш секвенца. Оригиналната лозинка на клиентот минува низ XOR процес, при што резултатот е комбинација од MD5 и XOR и потоа се запишува во user-password полето. Oткако RADIUS серверот ќе го добие пакетот, тој извршува процедури кои се спротивни од процедурите кај клиентот за да одреди дали треба да ја авторизира конекцијата. Во случај автентикацијата да не успее, тогаш причината на неуспехот би била поради погрешна лозинка.

CHAP

CHAP се базира под мислењето дека лозинката никогаш не треба да биде испратена со некој пакет низ мрежата. CHAP врши динамичка енкрипција на корисничкото ID и лозинка. Потоа корисничката машина ја извршува процедурата за најава за да го добие клучот од корисничката RADIUS опрема кој треба да е најмалку 16 бајти долг. Откако ќе го добие клучот, клиентот врши негово хаширање и го испраќа назад CHAP ID-то и неговото корисничко име. RADIUS серверот откако ќе го добие сето ова, го сместува во chap-password атрибутот и потоа испраќа одговор. За да го автентицира корисникот, RADIUS серверот ја користи вредноста во chap-challenge атрибутот, CHAP ID-то, лозинката за евиденција на соодветниот корисник и сето ова го доставува до MD5 хаш секвенца. Резултатот од хашингот треба да е идентичен со вредноста која се наоѓа во chap-password атрибутот. Ако не е идентичен, серверот мора да го одбие барањето, а ако е, тогаш барањето го одобрува.

Стандардни RADIUS атрибути

Како последен дел од областа за карaктеристики на RADIUS ќе бидат дадени типовите атрибути кои што постојат, како и краток опис на нивните особини со помош на табела: Callback-ID

Број на атрибут 20

Должина 3 или повеќе бајти

Вредност STRING

Дозволен во Access-Accept

Забранет во Access-Request, Access-Reject, Access-Challenge

Учество во пакети Не е задолжително

Максимум итерации 1

19

Callback-Number




Дозволен во Access-Request, Access-Accept

Забранет во Access-Reject, Access-Challenge



Called-Station-ID




Дозволен во Access-Request

Забранет во Access-Accept, Access-Reject, Access-Challenge



Calling-Station-ID








CHAP-Challenge








CHAP-Password


Должина 19




Учество во пакети Задолжително


Class






20


Максимум итерации Неограничено

Filter-ID








Framed-AppleTalk-Link


Должина 6

Вредност INTEGER





Framed-AppleTalk-Network


Должина 6






Framed-AppleTalk-Zone








Framed-Compression


Должина 6

Вредност ENUM





Framed-IP-Address


Должина 6

21

Вредност IPADDR





Framed-IP-Netmask


Должина 6

Вредност IPADDR





Framed-IPX-Network


Должина 6






Framed-MTU


Должина 6






Framed-Protocol


Должина 6

Вредност ENUM





Framed-Route








22

User-Name








User-Password


Должина 18 до 130 бајти



Забранет во Access-Accept, Access-Challenge, Access-Reject

Учество во пакети Задолжително


А останатите RADIUS атрибути ќе бидат само набројани, тоа се:

• Login-LAT-Group

• Login-LAT-Node

• Login-LAT-Port

• Login-LAT-Service

• Login-IP-Host

• Login-Service

• Login-TCP-Port

• NAS-Identifier

• NAS-IP-Address

• NAS-Port

• Nas-Port-Type

• Port-Limit

• Proxy-State

• Reply-Message

• Service-Type

• Session-Timeout

• State

• Terminate-Action

• Vendor-Specific

• Framed-Routing

• Idle-Timeout

23

Верификација на RADIUS (RADIUS Accounting) Интернет провајдерите често управуваат со точки на присуство (постоење) на неколку локации, кои се најверојатно географски дисперзирани. Сите овие точки на присуство бараат да се заштитат од неовластено користење на скапа мрежа на која тие и овозможуваат пристап. Иако првата одбранбена линија може и треба да биде во силна и проширена форма на автентикација (за да го потврди идентитетот на корисникот) и авторизација (за да го обезбеди корисникот со сервиси за кои само тој има право), многу повеќе вредни информации може да се добијат од собраните податоци за активностите на корисниците на мрежата. Кој корисник е најавен? Кога тој го сторил тоа? Какви услови му биле доделени? Податоците стануваат уште покорисни кога тие се собрани за да анализираат група на корисници. Колку е просечното време на повик на еден корисник? Колку податоци корисникот пренесува? Дали јас, како системски администратор, морам да одредам временска граница за една сесија за да ги заштитам ограничените dial-in извори? Дали имам корисници кои ја злоупотребуваат on-demand врската? Сите овие прашања можат да се одговорат со користење на информации од процесот на верификација. RADIUS подржува целосно-опремен верификациски протокол кој ги задоволува сите барања на ААА моделот. Во овој дел ќе се опишат дизајнот, операцијата, пакетите и атрибутите кои се специфични и соодветни за RADIUS верификацијата.

Клучни точки за верификацијата на RADIUS

Дизајнот на верификацијата во RADIUS е заснована на три главни карактеристики: Верификацијата да биде заснована на клиент/сервер моделот.

RADIUS верификациската машина е сервер на RADIUS – клиент врската, која делува како клиент. Клиентот ги испраќа корисните податоци до RADIUS серверот за да бидат обработени. RADIUS серверот потврдува успешен прием на податоците. Исто така е возможно и RADIUS серверот да дејствува како посредник за верификација.

Комуникацијата помеѓу уредите да биде сигурна.

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

РАДИУС верификацијата да биде проширена.

Форматот на верификациските атрибути е сличен на форматот на автентикациските и авторизациските атрибути т.е. голем дел од услугите понудени од имплементациите можат да се дефинираат и квалификуваат со користење на AVPs. AVPs можат да се додадат и модифицираат на постоечката имплементација без да и попречуваат на функцијата која се одвива.

24

Основна операција

Сите комуникации кои се во врска со верификацијата на RADIUS се вршат со Accounting-Request пакетот. Клиентот кој учествува во RADIUS верификацискиот процес ќе произведе т.н. Accounting Start пакет, кој е специфичен вид од пакетот Accounting-Request. Овој пакет содржи информации за услугата која се обезбедува и за корисникот на кој му била пружена истата услуга. Овој пакет се праќа до RADIUS верификацискиот сервер, кој ќе потврди прием на информацијата. Кога клиентот е готов со мрежните сервиси, се испраќа Accounting Stop пакет кој исто така содржи и информации за времето потрошено на услугата, пратената количина, просечната брзина, успешна испорака на услугата и други детали. Потоа верификацискиот пакет го известува клиентот за Accounting Stop пакетот. Ако серверот не може или не ги исполни барањата на пакетот Accounting-Request, тогаш исто така не се испраќа ни потврда за примање на клиентот. Во овој случај, се препорачува клиентот да продолжи да праќа пакети до верификацискиот сервер се додека не добие потврда дека Accounting-Request пакетот е обработен. Всушност, во големите дистрибуирани мрежи, пожелно е клиентот да има повеќе верификациски сервери за да секогаш му биде доделена потребната услуга. Администраторот пак, би имал повеќе верификациски сервери кои би се справиле со различните барања на клиентите – еден сервер за dial-up корисниците, друг за DSL koрисниците, трет за ISDN конекциите.

Повеќе за Proxying

Треба да се земат во предвид следниве процеси:

1. RADIUS-клиент врската го праќа Accounting Start пакет до верификацискиот сервер.

2. Верификацискиот сервер што го прима пакетот исто така и го отвара. Потоа серверот може да го додаде Proxy-State атрибутот и другите следбени детали. Тој ја обновува бараната автентикација и истата ја праќа до оддалечена машина.

3. Оваа оддалечена машина го прима пакетот и го обработува тоа што првиот сервер не

можел да го обработи, ги чува и копира сите Proxy-State атрибути (сосем исти како што изгледаат), и праќа Accounting-Response пакет назад до оригиналниот сервер.

4. Оригиналниот сервер ја прима информацијата, ја расклопува Proxy-State

информацијата, ја конструира и додава Response Authenticator, и го праќа модифицираниот одговор назад до RADIUS-клиент врската.

25

Слика 15 - Proxing процес за верифицирање на RADIUS

Формат на верификацискиот пакет

RADIUS протоколот користи UDP основа за да ги пренесува пакетите помеѓу клиентите, серверите и proxies. Додека оригиналниот RADIUS верификациски RFC (поточно бројот 2139) укажува дека верификациските трансакции треба да земат учество на порта 1646, најновото RFC (2866) ја промени портата на 1813, бидејќи порта 1646 е доделена на sa-msg-port сервисот. Пакетите се поделени на четири различни полиња.

Code (код)

Code полето е 1-битно, и го обележува пренесувањето на RADIUS верификациската информација во овој пакет. Пакетите со полиња на невалиден код се отстрануваат без никакво известување. Валидни кодови се: 4 Accounting-Request 5 Accounting-Response

Identifier (идентификатор)

Identifier полето е големо 1-бајт, и се користи за автоматско поврзување на првичните барања и понатамошните одговори. RADIUS верификациските сервери можат генерално да ги пронајдат пораките кои се дупликати со помош на факторите како IP изворот, изворот на UDP портот, времето искористено помеѓу сомнителните пораки и со помош на identifier полето.

Length (должина)

Length полето е 2-бајтно и се користи за да ја одреди должината на RADIUS верификациската порака. Вредноста во полето е пресметана со анализирање на зафатената големина на полињата code, identifier, length, authenticator и attribute и со пронаоѓање на нивната сума. Полето за должина е означено за да се осигура валидноста на информацијата кога верификацискиот сервер го прима пакетот. Валидните должински вредности се од 20 до 4095.

Authenticator

26

Authenticator полето, често е 16-бајтно, е поле во кое целата содржина на пакетот е проверена и одобрена. Во ова поле, најважниот бајт - вредноста која се користи за валидирање на одговорите од верификацискиот сервер - е пренесен пред сите други. Има два различни вида на автентикација; автентикација на валидно барање (request) и автентикација на валиден одговор (response). Автентификацијата на валидно барање, составена од 16 бајтни MD5 суми, се пресметани користејќи мешавина од code, identifier, length, attribute и споделени тајни(shared secrets), и 16 "zeroed-out" бајти. Вредноста која е вратена од оваа мешавина потоа е сместена во полето за автентификација. Автентификаторот на одговор е пресметан скоро на истиот начин како и автентификаторот на барање. MD5 сумата е произведена со користење на вредности од кодот, идентификаторот, должината, автентификаторот на барање од оригиналното барање, и атрибутите од одговорите; вредностите од оваа сума се сместуваат во authenticator полето. Исто така е важно да се спомене дека некои постари RADIUS и NAS извршувања праќаат неколку верификациски пакети од полето за валидност до сите нули. Додека на RFCs им е забрането ова праќање на вакви пакети, за некои специфични цели RADIUS серверите можат да го прифатат ваквото праќање на пакетите. Надежност на верификацијата Додека спефикациите за RADIUS верификацијата се ветувачки, искуството покажува дека верификациските пакети не се 100% сигурни. На пример, ако клиентот испраќа пакети, но не добива одговор, тој ќе продолжи да праќа исти пакети за ограничено време. Ова резултира на неколку сесии со неконзистетни записи. Ова исто така презентира проблеми со операции кои бараат голема постојаност и точност: фактурирањето(billing) е примарен, но не и единствен пример.

Типови на верификациски пакети

До сега e кажано дека RADIUS служи за пренесување на верификациски податоци. Но исто така треба да се утврди идентитетот и својствата на специфичните пакети. Има два вида на RADIUS пакети кои се релевантни за ААА трансакцијата:

• Accounting-Request

• Accounting-Response

Следниот дел содржи детали за намената, форматот и структурата на овие пакети. Accounting-Request

Тип на пакет барање

Code(код) 4

Identifier(идентификатор) Уникатен за секое барање; уникатен за секое пренесување на модифицирани податоци

Authenticator(автентикатор) барање

Податоци за атрибут 0 или повеќе атрибути

Пакетите Accounting-Request се праќаат од клиентот до серверот. Клиентот може да биде вистински RADIUS клиент или друг RADIUS сервер кој се однесува како прокси. Клиентот го

27

праќа пакетот со код еднаков на 4 (code полето е сетирано на 4). Кога серверот го прима овој пакет, треба да му прати потврден одговор на клиентот дека го примал, освен ако не може да го фати или процесира пакетот. Ако серверот не може да се справи или да го процесира пакетот, тогаш ништо не би можело ни да се пренесе до клиентот. Пакетот Accounting-Request може да ги користи сите атрибути кои се дозволени во Access-

Request или Access-Accept , но не и User-Password, CHAP-Password, Reply-Message, и State атрибутите. Постојат уште неколку предупредувања кои се присутни во пакетот. Еден од NAS-IP-Address и NAS-Identifier атрибутите мора да биде вклучен во пакетот, но не и двата атрибути. RFC предлага разликување на NAS портот или друг вид на порт во пакетот со употреба на NAS-Port или NAS-Port-Type атрибутот, но под услов информацијата да не е преголема за сервисот. Додатно е дека Framed-IP-Address мора да ја прикаже вистинската IP адреса на корисникот. Accounting-Response

Тип на пакет одговор

Code(код) 5

Identifier(идентификатор) Идентичен за соодветно Accounting-Request

Authenticator(автентикатор) одговор

Податоци за атрибут 0 или повеќе атрибути

Пакетите Accounting-Response првенствено се дизајнирани како пакети за потврда, кои ќе бидат пратени од верификацискиот сервер до клиентот, со што даваат до знаење дека барањето од клиентот е примено и се процесира. Ако пакетот е примен и процесиран успешно, RFC укажува дека кодот е еднаков на 5 и со тоа укажува на одговор. Откако распознавачот на пакетот “одговор” ќе се совпадне со соодветното Accounting-Request поле, клиентот лесно може да ги поврзе двата пакети заедно за да може да следи кои барања се завршени, а кои уште не. Пакетите Accounting-Response многу често не содржат никакви атрибути. Како и да е, во случај на прокси трансакција, Proxy-State атрибутот може да биде вклучен во пакетот. Исто така, секој Vendor-Specific атрибут може да биде вклучен во пакетот за верификациски одговор.

Специфични верификациски атрибути

Во последниот дел од оваа област дадени се типовите атрибути кои што постојат, а ќе бидат само наброени:

• Acct-Status-Type

• Acct-Delay-Time

• Acct-Input-Octets

• Acct-Output-Octets

• Acct-Session-ID

• Acct-Authentic

• Acct-Session-Time

• Acct-Input-Packets

• Acct-Output-Packets

• Acct-Terminate-Cause

• Acct-Multi-Session-ID

28

• Acct-Link-Count

29

Безбедност на RADIUS Иако RADIUS протоколот е дизајниран да овозможи сигурност со која само авторизирани корисници ќе можат да ги користат услугите кои се понудени на голема група на луѓе, тој има сигурносни проблеми од кои неколку се доста сериозни. Најголем проблем во сигурноста на RADIUS е неговата широка употреба. RADIUS има поддршка од голем број на продавачи на мрежна опрема, може да се најде во сите интернет-сервис провајдери и соработува со dial-up услугите. Оваа популарност, е сепак меч со две острици. Сигурносните слабости во јадрото на RADIUS протоколот оставa илјадници системи со кои мора да направи компромиси. Исто така, главните промени не можат да бидат направени на јадрениот протокол, затоа што тоа ќе го активира ризикот за нарушување на компатибилноста со илјадниците системи кои го користат RADIUS. Во овој дел, ќе се дискутира за слабостите, ќе се понудат неколку решенија кои ќе го заштитат подобро системот.

Недостатоци

Многумина откриле дека RADIUS има некои основни недостатоци кои му овозможуваат на напаѓачот да го открие идентитетот на трансакцијата. Првенстветно, User-Password заштитата е доста несигурна поради техниките на енкрипцијата и криптографијата. Концептот на вметнување на автентикатор за одговор во RADIUS пакетот е доста добро, но користењето во протоколот е слабо дизајнирано. Access-Request пакетот не е автентициран од ниеден уред на трансакцијата. Случајноста на создавањето на автентицирано барање не е доволно случајна. И како за крај, споделената тајна е примитивен метод на сигурноста на RADIUS на клиент-сервер трансакциите.

MD5 и споделена тајна

Споделената тајна е ранлива поради слабиот MD5 хаш кој го крие автентикациски одговор. Хакерот лесно може да ја нападне споделената тајна со душкање на Access-Request пакетот и неговиот соодветен одговор. Исто така, хакерот, може лесно да ја добие споделената тајна со претходни калкулации на MD5 од кодот, ID, должината, автентицираното барање, и атрибутскиот дел од пакетите и потоа повторно го пресметува хашот.

Access-Request пакетот

Access-Request пакетот нема предефинирана верификација или автентификација. RADIUS серверот ќе направи проверка за да се осигура дека пораката потекнува од IP адреса која припаѓа на некој од клиентите и е во оваа година и ден. Ваквите IP адреси се лесни за наоѓање и користење, и тоа резултира со сериозен проблем во дизајнот на RADIUS протоколот. До сега, како едно од најуспешните решенија е присуството на Message-Authenticator атрибутот во сите Access-Request пораки. Message-Authenticator е MD5 хаш на целосната Access-Request порака, која како клуч ја користи споделената тајна на клиентот. Кога RADIUS серверот е конфигуриран да ги прифаќа само Access-Request пораките со валиден Message-

Authenticator атрибут, RADIUS серверот мора незабележително да ги отстрани оние пакети со невалиден или пропуштен атрибут.

30

Ако имплементација на некој начин го попречува користењето на Message-Authenticator атрибутот, треба да се земе во предвид користењето на некој вид на account-lockout особина, која ќе ги оневозможи автентицирањата после даден број на обиди за автентицирање во одредено време.

Usher-Password Cipher шема

Начинот на кој User-Password атрибутот се користи, во глобала, е познат како stream cipher. Stream cipher е метод за енкрипција кој работи со постoјан проток на влезни информации , кој почесто е поток на битови од обичен текст. Спротивно на него е block cipher, кој е метод за енкрипција кој обработува влезни податоци од фиксни блокови кои се типично 64 до 128 битни. Stream cipher произведува keystream кој се користи во енкрипцијата. Кога се комбинира keystream со потокот од обичен текст користејќи XOR операција, содржината на низата(потокот) е енкриптирана. Генерирањето на keystream може да биде независна од обичен(чист) текст и ciphertext или може да зависи од податоците и нивната енкрипција, и во тој случај stream cipher може да се нарече self-synchronizing (самосинхронизиран). Во User-Password шемата, првите 16 бајти дејствуваат како синхронизиран stream cipher, додека обичниот текст е независен од keystream-от. Како и да е, по првите 16 бајти, keystream-от го вклопува претходниот обичен текст и така станува self-synchronizing. Но сигурносноста на оваа шифра доаѓа во прашање; RADIUS протоколот не разјаснува кои се побарувањата на оваа шифра. MD5 хашовите генерално се криптографски хашови, а не stream ciphers. Затоа можно е да има сигурносен проблем во оваа можна злоупотреба. За жал, за да се заштитат атрибутите и пораките на RADIUS пакетот, треба да се користи IPsec протоколот со ESP (encapsulated security payload) додатоци и алгоритам за енкрипција како што е тројниот енкрипциски стандард (3DES). RFC 3162 го објаснува овој процес подетално.

User-Password Shared Secred

Иако User-Password атрибутот е заштитен со stream cipher, напаѓачите можат да добијат информации од споделената тајна ако го прислушуваат интернет сообраќајот и се обидат да се автентицираат против RADIUS серверот. На пример, напаѓачот може да се обиде да се автентицира, користејќи лозинка која му е позната. Тој тогаш прима и заробува Access-Request пакет и користи комбинација на заштитениот дел од User-Password и лозинката која тој ја користел. Кога пресметувањето е готово, напаѓачот го има резултатот од MD5 (споделена тајна + автентификациско барање) операцијата. Тој веќе го знае автентификациското барање од неговото оригинално барање, и на тој начин може да користи brute-force напад над споделената тајна и да ја открие не користејќи интернет.

User-Password атрибут и напади на лозинката

Напаѓачот може да стигне до секоја граница на автентификација, која е ставена од администраторот на RADIUS серверот поради користењето на stream cipher при заштита на User-Password атрибутот. Еве како тоа работи: хакерот прво се обидува да се автентицира против RADIUS серверот, користејќи познато корисничко име и позната, но веројатно неточна лозинка. Потоа хакерот го зема резултатниот Access-Request пакет и го наоѓа MD5 резултатот од комбинацијата на автентификациско барање + споделена тајна, како што е опишано

31

претходно. Тогаш тој може да користи brute-force напад над лозинката, со избирање на лозинки во пакетот и користејќи ја истата комбинација на автентификациско барање и споделена тајна. Ова само би работело ако лозинката е помала или еднаква на 16 карактери, додека User-Password стане самосинхронизиран на седумнаесетиот карактер и вклучувајќи го претходниот ciphertext во енкрипцијата.

Напади кои користат автентикациско барање

Има повеќе можни методи на напади кои го користат делот за автентикациско барање од RADIUS пакетот. Целосната безбедност во RADIUS е основана на authenticator полиња кои служат како уникатни и можни “распознавачи” (но не ID полето од пакетот) за секој пакет. Како и да е, конечната сигурносна мерка зависи од тоа колку овие автентикатори се измешани т.е. случајно поставени. Повеќето од вродената сигурност се распаѓа кога генераторите на случајни броеви се многу кратки (многу малку броеви во кругот) или кога вредностите се повторливи.

Повторливи автентикациски барања и User-Password атрибутот

Можно е да се произведат милиони автентикациски барања и User-Password атрибути само ако хакерот го надушка жичениот сообраќајот помеѓу RADIUS клиентот и RADIUS серверот за време на трансакцијата. Во тој случај, хакерот би видел ако некоја повторлива вредност се користи за автентикациското барање; ако тоа е така, тој би можел да ја отстрани споделената тајна од првите 16 бајти од лозинката. Со оваа постапка, тој ги добива првите 16 бајти на две комплетно незаштитени лозинки кои се XOR-ирани заедно. Сега, како првична линија е тоа што напаѓачот ги има првите 16 бајти незаштитени. Повеќето од лозинките кои ги користат корисниците, за несреќа, не се толку долги; па и да се со таа должина, хакерот ја има основата за понатамошниот brute-force напад. Напаѓачот не може да добие никаква информација, само ако сите корисници имаат случајно генерирани лозинки со иста должина, што би требало да биде ставено и спроведено од систем-администраторот. За овој напад, на хакерот му се потребни две различни лозинки со доста различни должини. Додека најкратката лозинка има повеќе обложувања, еднаш кога напаѓачот ќе го комплетира својот XOR, тој ќе има неповторувачки карактери од подолгите лозинки и ќе биде изложен да врши минимални обиди. Друг напад може да се случи ако хакерот користи повеќекратно автентицирање со користење на познати лозинки и пресретнувања на Access-Request пакетите. Од овие пакети, хакерот може да го добие автентикациското барање и User-Password атрибутот. Тој тогаш прави XOR на познатата лозинка со заробениот User-Password атрибут и од резултатот, хакерот има валидна “банка” од request-authenticator вредностите и од MD5 вредностите (автентификатор + споделена тајна). Ако тој продолжи да го душка сообраќајот и пронајде вредност на автентикациско барање која поврзува друга вредност од неговата “база”, хакерот може да ги добие првите 16 бајти од User-Password со гледање на MD5 хашот од својата база и да направи XOR со User-Passwodr атрибутот. Исто така, користејќи ја оваа база од автентикациски барања, хакерот исто така може да додаде одредени распознавачи и сервер-одговори кои тој ги добива од душкањето на жицата. Тогаш тој може да се преправа како сервер и да ги замени старите сервер-одговори кога погодниот Access-Request пакет ќе пристигне.

Проширен Автентикациски Протокол (EAP)

EAP е продолжеток на PPP протоколот кој овозможува да се користат голем број на автентикациски протоколи. EAP не е цврсто сврзан со методот на сигурност. Тоа поминува

32

преку размената на автентикациските пораки, дозволувајќи му на автентикацискиот софтвер кој е сместен во серверот, да соработува со својата копија која се наоѓа во клиентот. ЕАР се користи како заменски (replacement) протокол, кој го дозволува првичното преговарање на автентикацискиот протокол (како CHAP и MS-CHAP Verision 1 and 2), а потоа и согласувањето на двата краја на конекцијата, која е специфична EAP-автентикациска шема. Кога овие два елементи ќе се потврдат, EAP дозволува отворено-краен разговор помеѓу RADIUS и неговите клиенти. ЕАР е дизајниран да функционира како автентификациски “plug-in”, со “библиотеки” на двата краеви на РРР конекцијата т.е. на клиентот и на серверот. Секоја автентикациска шема е асоцирана со посебна библиотечна датотека и еднаш кога специфичната библиотека ќе биде сместена на своето место на двата краја, новата шема која е создадена ќе може да биде користена. Всушност, протоколот лесно може да биде функционално проширен од страна на продавачите во секое време, без да биде потребен редизајн на целиот протокол. ЕАР моментално подржува автентикациски шеми како Generic Token Card, OTP, MD5-Challenge и Transport Level Security (TLS) кои ги користи во smart-card апликациите и поддршката за сертификати. Освен поддржувањето од РРР, ЕАР исто така е подржана и во податочниот слој како што е специфирано во IEEE 802. IEEE 802.1x го дефинира EAP користењето во автентицирање на 802 уредите како WiFi влезните точки и Етернет свичовите. Како ЕАР се поврзува со RADIUS? ЕАР го заштитува RADIUS многу повеќе. Користењето на RADIUS со ЕАР не треба да се гледа како на официјална автентикациска шема на ЕАР, туку како движење на ЕАР пораки од секој ЕАР вид со помош на RADIUS – клиент преносникот и RADIUS серверот. ЕАР во RADIUS е поставен на овој начин: серверот за пристап е конфигуриран да користи ЕАР и RADIUS како свој автентикациски провајдер. Кога корисникот на сервисот се обидува да се поврзе, тој го преговара користењето на ЕАР со RADIUS – клиент преносникот. Крајниот корисник тогаш испраќа ЕАР порака на RADIUS клиентот, од каде што RADIUS клиентот ја прифаќа ЕАР пораката како RADIUS порака и ја праќа до RADIUS серверот. Тогаш RADIUS клиентот конструира ЕАР порака од RADIUS пораката и ја праќа назад до корисникот на сервисот / крајниот корисник.

Слика 16 - EAP и RADIUS работат заедно

33

Компензација за недостатоците

Сите од сигурносните работи презентирани досега имаат работни околини. Тоа се следните: Користење на IPsec протоколот со ЕЅР и енкрипциски алгоритам како 3DES

Кога IPsec ја енкриптира целосната RADIUS порака, полињата се отвораат за спогодба, но полињата со автентицирано барање, User-Password, Tunnel-Password i MPPE-Key не можат да се видат. За да се декриптираат овие полиња, напаѓачот најпрво мора да влезе во ESP заштитната порака. Ова ја заштитува целосната RADIUS порака и ја заштитува од “лошите очи”.

Секоја споделена тајна треба да биде долга 22 тастатурни карактери или 32

хексидецимални цифри

Со ова се воведува заштита од недостатоците и незаштитената природа на концептот на споделена тајна.

Користење на различна споделена тајна за секој RADIUS клиент и пар на сервери

Ова е само основна сигурносна мерка, нешто слично како различна лозинка за повеќе веб-страници и компјутерски ресурси.

Користење на Message-Authenticator атрибутот во сите Access-Request пораки. Клиентот

треба да биде сигурен дека знае да го користи и дека може да го конфигура Message-

Authenticator.

Од страна на серверот, Message-Authenticator атрибутот треба да биде присутен и исто така треба да дозволи негова конфигурација.

Користење криптографски-квалитетен генератор на случаен број за да го генерира

автентикациското барање.

Ова го изедначува ограничениот квалитет на имплементацијата на автентикациското барање.

Исто така може да се земе во предвид заштитувањето на врските на крајниот корисник до RADIUS - клиент преносникот со користење на ЕАР и еден од силните енкрипциски видови кои се достапни во својата намена. На пример, може да се користи EAP-TLS, кој е силен ЕАР метод кој побарува размена на сертификати помеѓу клиентот и RADIUS серверот. Употребата на ЕАР пораките наследно побарува валиден Message-Authenticator сертификат, кој ги заштитува пораките кои не можат да бидат заштитени од IPsec. Со ЕАР треба да се има во предвид и користењето на заеднички автентикациски методи. Едноставно е тоа што двата краја од конекцијата ја автентицираат нивната вредност во заедничка автентикација. Обидот за автентикација е одбиен ако автентикацијата и на двата краја (завршетоци) падне. EAP-TLS е заеднички автентикациски метод: RADIUS серверот го валидира корисничкиот сертификат на клиентот, и клиентот го валидира компјутерскиот сертификат на RADIUS серверот.

34

За крај, ако РАР автентикацискиот протоколот не е потребен, треба да се онеспособи на двата краја од клиентот и серверот. РАР треба да се користи само како сигурносна врска кога таа се користи во соединувањето со ОТР и Token Card автентикација, каде лозинката е разумно комплексна и менувана со секоја нејзина употреба. Како и да е, дури и во оваа ситуација имањето на РАР им дозволува на неконфигурираните крајни корисници да преговараат со RADIUS - клиент преносникот и во тој случај тие би можеле потенцијално да пратат незаштитени лозинки. Ако е возможно, треба да се користи ЕАР со ОТР и Token Card автентикациски видови, наместо РАР. Исто така, треба да се оневозможи LAN manager encoding ако се користи MS-CHAP.

Заклучок Како заклучок ќе бидат набројани неколку особини на RADIUS протоколот, кои во текот на целиот опис за RADIUS постојано се спомнувани и се важни да се знаат за правилно да се користи овој протокол:

• RADIUS е оддалечен автентикациски протокол

• RADIUS на еден начин претставува стандард за оддалечените автентикации

• RADIUS има некои безбедносни недостатоци кои сепак можат да се намалат со правилна употреба

• RADIUS е протокол кои може да се користи во комбинација со други протоколи, а исто така подржува и повеќе автентикациски методи, на пример EAP

Денес, се прави обид за модифицирање на RADIUS протоколот. За да не се наследат недостатоците на RADIUS, треба да се поттикне ревизија на протоколот. Иако побезбеден протокол моментално не постои, во блиска иднина се очекува да се издаде Diameter од страна на IETF.

Diameter е планиран заменик на RADIUS. Голем процент од целиот протокол-систем кој е упатен во Diameter е директиран кон одземање на неколку функционални граници воведени од RADIUS протоколот. Ефективно, никаква работа не е направена која асоцира на клиент/сервер сигурноста на протоколот. За да се користи Diameter, неговите корисници мораат да ја поддржат IP сигурноста, и можат да го поддржат TLS. Diameter серверите мора да го поддржат TLS, ама администраторот може да се одлучи да го конфигурира IPSec наместо користењето на TLS. Оперирањето на Diameter протоколот без никаков сигурносен механизам не е препорачливо. Па може да се каже дека IPSec и/или TLS ги извршуваат сите сигурносни аспекти на протоколот. И двата IPSec и TLS се целосно опремени протоколи. Тоа е многу подобро од тоа што RADIUS некогаш го сторил. Меѓутоа, ова укажува дека TLS/IPSec имплементацијта е многу значајна за денешните преносни уреди и би значело дека произведувачите или би продолжиле да користат RADIUS или да го игнорираат Diameter стандардот и ќе преферираат Diameter без TLS или IPSec. Со ова се даде краток опис на развојот на RADIUS во иднина, која е неговата замена што се подготвува и кои се спецификациите на Diametar-от.

35

Користена литература [1] RADIUS by Jonathan Hassell; Publisher: O’Reilly; Data Published: October 2002 [2] RFC 2138 RADIUS http://www.faqs.org/rfcs/rfc2138.html [3] RFC 2865 RADIUS http://www.ietf.org/rfc/rfc2865.txt [4] RFC 2866 RADIUS Accounting http://tools.ietf.org/html/rfc2866 [5] http://en.wikipedia.org/wiki/RADIUS

Documents

Radius Server