3. Порівняльний аналіз основних методів захисту від віддалених атак на інформацію

4.1 Адміністративні методи захисту від віддалених атак у мережі Internet

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

Мабуть, найбільш простими і дешевими є адміністративні методи захисту від інформаційних деструктивних впливів, про що і розповідатиметься далі.

4.2 Захист від аналізу мережевого графіка

Першою розглядуваною віддаленою атакою була атака, що дозволяє хакерові за допомогою програмного прослуховування каналу передачі повідомлень у мережі перехоплювати будь-яку інформацію, якою обмінюються користувачі, якщо по каналу передаються тільки нешифровані повідомлення. Також було показано, що базові прикладні протоколи віддаленого доступу TELNET і FTP не передбачають елементарного криптозахисту переданих по мережі ідентифікаторів (імен) і аутентифікаторів (паролів). Тому адміністраторам мереж можна порекомендувати не використовувати ці базові протоколи для надання віддаленого авторизованого доступу до ресурсів своїх систем і вважати аналіз мережевого трафіка тієї постійно присутньою загрозою, котру неможливо усунути, але можна зробити безглуздою, використовуючи стійкі криптоалгоритмти захисту IP-потоку.

4.3 Захист від хибного ARP-сервера

Коротко нагадаємо суть цієї віддаленої атаки, що використовує недоліки в механізмі віддаленого пошуку на базі протоколу ARP. У тому випадку, якщо в мережній ОС відсутня інформація про відповідність IP- і Ethernet-адрес хостів усередині одного сегмента IP-мережі, даний протокол дозволяє посилати циркулярний ARP-запит на пошук необхідної Ethernet-адреси, на який атакуючий може надіслати хибну відповідь, і надалі весь трафік на канальному рівні виявиться перехопленим атакуючим і пройде через хибний ARP-cepвер. Очевидно, що для ліквідації даної атаки необхідно усунути причину її можливого здійснення, що полягає у відсутності в ОС кожного хосту необхідної інформації про відповідні IP- і Ethernet-адреси всіх інших хостів усередині даного сегмента мережі. Таким чином, найпростішому рішення ‑ створити мережним адміністратором статичну ARP-таблицю у виді файлу (у ОС UNIX звичайно /etc/ethers), куди внести необхідну інформацію про адреси. Даний файл встановлюється на кожен хост усередині сегмента, і, отже, у мережній ОС відпадає необхідність у використанні віддаленого ARP-пошуку. Правда, ОС Windows 7 це не допомагає.

4.4 Захист від хибного DNS-сервера

Як уже обговорювалося, використання служби DNS у її нинішньому виді може дозволити хакерові одержати глобальний контроль над з'єднаннями шляхом нав'язування хибного маршруту через хост кракера ‑ хибний DNS-сервер. Здійснення такої віддаленої атаки, заснованої на потенційних уразливостях служби DNS, приведе до катастрофічних наслідків для величезного числа користувачів Internet і стане причиною масового порушення інформаційної безпеки глобальної мережі. Далі для адміністраторів і користувачів мережі і для адміністраторів DNS-серверів пропонуються можливі адміністративні методи запобігання чи утруднення даної віддаленої атаки.

4.5 Ззахиститися від помилкового DNS-сервера

Якщо відповідати на запитання захисту від хибного DNS-сервера коротко, то відповідь формулюється одним словом: “Ніяк”. Ні адміністративно, ні програмно не можна захиститися від атаки на існуючу версію служби DNS. Оптимальне рішення з погляду безпеки ‑ узагалі відмовитися від використання служби DNS у захищеному сегменті мережі.

Очевидно, що зовсім відмовитися від використання імен при звертанні до хостів буде дуже незручно, тому можна запропонувати наступне компромісне рішення: використовувати імена, але відмовитися від механізму віддаленого DNS-пошуку. Іншими словами це повернення до схеми, що застосовувалася до появи служби DNS з виділеними DNS-серверами. Тоді на кожній машині існував файл hosts, у якому знаходилася інформація про імена і відповідних IP-адресах усіх хостів у мережі. Очевидно, що на сьогоднішній день адміністратору в подібний файл можна внести інформацію лише про найбільш часто відвідувані користувачами даного сегмента серверах мережі. Тому на практиці виконати дане рішення надзвичайне важко і, мабуть, нереально.

Щоб ускладнити здійснення даної віддаленої атаки (передача на хост хибної DNS-відповіді без прийому DNS-запиту), можна запропонувати адміністраторам використовувати протокол TCP замість протоколу UDP, що встановлюється за замовчуванням (хоча з документації далеко не очевидно, як його замінити).

Загальний невтішний висновок такий: у мережі Internet при використанні існуючої версії служби DNS немає прийнятного рішення для захисту від помилкового DNS-сервера (і не відмовишся, як у випадку з ARP, і використовувати небезпечно).

4.6 Як адміністратору DNS-сервера захиститися від помилкового DNS-сервера

Єдиний спосіб утруднити здійснення даної віддаленої атаки ‑ використовувати для зв’язку з хостами і з іншими DNS-серверами тільки протокол TCP, але не UDP. Але не слід забувайте як про можливе перехоплення DNS-запиту, так і про математичне прогнозування початкового значення TCP-ідентифікатора ISN (див. параграф “Підміна одного із суб'єктів TCP-з'єднання в мережі Internet”).

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

4.7 Захист від нав'язування помилкового маршруту

Раніше розглядалася віддалена атака суть якої полягала у передачі на хост хибного повідомлення ICMP Redirect про зміну вихідного маршруту. Ця атака приводила як до перехоплення атакуючим інформації, так і до порушення працездатності хосту, що атакується. Для того щоб захиститися від такої атаки, необхідно або фільтрувати дане повідомлення (використовуючи Firewall чи фільтруючий маршрутизатор), не допускаючи його попадання на кінцеву систему, або відповідним чином вибирати мережну ОС, що проігнорує це повідомлення. Однак, як правило, не існує адміністративних способів уплинути на мережну ОС так, щоб заборонити їй змінювати маршрут і реагувати на дане повідомлення. Єдиний спосіб (наприклад, у випадку ОС Linux чи FreeBSD) полягає в тім, щоб змінити вихідні тексти і перекомпілювати ядро ОС. Очевидно, що такий екзотичний підхід можливий тільки для операційних систем, вільно розповсюджуваних разом з вихідними текстами. Іншого способу довідатися реакцію використовуваної у ОС на повідомлення ICMP Redirect, як послати повідомлення і подивитися, який буде результат, на практиці не існує. Експерименти показали, що дане повідомлення дозволяє змінити маршрутизацію на ОС Windows 95 і Windows NT 4.0. Відзначимо, що продукти компанії Microsoft не відрізняються особливою захищеністю від можливих віддалених атак, властивим IP-мережам. Отже, небажано використовувати дані ОС у захищеному сегменті IP-мережі. Це і буде тим самим адміністративним рішенням по захисту від подібної віддаленої атаки.

4.8 Захист від відмови в обслуговуванні

Як уже відзначалося, прийнятних способів захисту від відмови в обслуговуванні для стандарту IPv4 мережі Internet немає і не може бути. Це зв'язано з тим, що в IPv4 неможливий контроль за маршрутом повідомлень. Таким чином не можна забезпечити надійний контроль за мережними з'єднаннями, тому що в одного суб'єкта мережної взаємодії є можливість зайняти необмежене число каналів зв'язку з віддаленим об'єктом і при цьому залишитися анонімним. Через це будь-який сервер у Internet може бути цілком паралізований за допомогою відповідної віддаленої атаки.

Єдине, що можна запропонувати для підвищення надійності роботи системи, що піддається даній атаці, ‑ використовувати як можна більш потужніші комп'ютери. Чим більше число і частота роботи процесорів, чим більший обсяг оперативної пам'яті, тим більш надійною буде робота мережний ОС, коли на неї буде спрямований шторм хибних запитів на створення з'єднання. Крім того, необхідне використання відповідних обчислювальним потужностям операційних систем із внутрішньою чергою, здатною вмістити велике число запитів на підключення. Адже якщо, наприклад, встановити на суперкомп'ютері операційну систему Windows NT, у якої середня довжина черги для одночасно оброблюваних запитів близько 50, а тайм-аут очищення черги дорівнює 9 секундам, то, незважаючи на всі обчислювальні потужності комп'ютера, ОС буде цілком паралізована атакуючим.

Загальний висновок по протидії даній атаці в існуючому стандарті IPv4 наступний: просто розслабтесь і сподівайтеся на те, що ви ні для кого не представляєте інтересу, чи купіть потужний комп'ютер з відповідною мережною ОС.

Проте у зв’язку з нещодавніми потужними атаками відмови в обслуговувані на найпопулярніші інформаційні ресурси мережі, така порада виявилася, так би мовити, не дуже ефективною. Тому було запропоновано кілька радикальних методів, що полягали у частковому відході від специфікації IPv4 з метою хоча б якось захиститись від таких атак.

Перша ідея полягає у тому, щоб відмовитися від рукостискання при створені віртуального каналу зв’язку. Тобто прийнявши пакет-запит на створення з’єднання хост-сервер формує та відсилає пакет-відповідь, але не записує у свої внутрішні структури у пам’яті жодної інформації про цей запит на створення віртуального каналу. Хост-клієнт, що зробив запит на створення, прийнявши пакет відповідь відсилає останній пакет рукостискання АСК, ISSa+1, ACK(ISSb+l). Лише прийнявши цей пакет хост-сервер, формує необхідні внутрішні структури і створює віртуальний канал. Далі робота ведеться згідно IPv4. Таким чином можна значно зняти навантаження на хост пов’язане з опрацювання першого пакету SYN створення TCP-з’єднання, що зробить його на порядок стійкішим до такої атаки. Проте для ефективного виводу з ладу таких хостів атаку DoS потрібно лише незначно модифікувати – необхідно реалізовувати шторм не SYN пакетами, а АСК, ISSa+1, ACK(ISSb+l) пакетами. Таким чином ця ідея принципово не може захистити хост від атаки відмови в обслуговуванні і крім цього повністю нівелює захист віртуального каналу від підміни суб’єкта з’єднання (хоча це не важливо для загальнодоступних інформаційних порталів).

Ще однією, набагато дієвішою, ідеєю є поєднання попередньої з використанням спеціального способу формування ISSb. Це значення формується не за часозалежною функцією чи як деяке випадкове число, а як шифрування (за симетричним алгоритмом) IP-адреси хоста-клієнта, тобто хоста, що робить запит на створення з’єднання. Прийнявши від цього хоста пакет АСК, ISSa+1, ACK(ISSb+l) хост-сервер розшифровує значення ACK-1=ISSb і звіряє чи воно справді збігається з IP-адресом хоста-клієнта. Якщо так, то формується віртуальний канал і робота продовжується згідно протоколу IPv4. У протилежному випадку пакет відкидається. Таким чином зловмисник не може створити віртуальний канал не приймаючи пакети-відповіді від хоста-сервера (що неможливо якщо він відправляє пакети не від свого імені). Ця методика дозволяє повністю уникнути проблем з міні-штормом будь-якими пакетами, а також з атаками DoS при достатній потужності сервера (мається на увазі, що використовуючи цю методику сервер працює так немовби тайм-аут розриву з’єднання віртуального каналу тотожно дорівнює нулю для хибних пакетів, що дуже суттєво зменшує вимоги до його потужності для протидії атаці при заданій пропускній здатності каналу підключення). При цьому грамотна реалізація цієї ідеї абсолютно не впливає на стійкість ідентифікації і аутентифікації віртуального каналу. Проте і реалізація цього методу абсолютно ніяк не може протидіяти атакам типу DDoS.

4.9 Захист від підміни однієї зі сторін

Як відзначалося раніше, єдиним базовим протоколом сімейства TCP/IP, у якому закладена функція забезпечення безпеки з'єднання і його абонентів, є протокол транспортного рівня ‑ протокол TCP. Що стосується базових протоколів прикладного рівня (FTP, TELNET, r-служба, NFS, HTTP, DNS, SMTP), то жоден з них не передбачає додаткового захисту з'єднання на своєму рівні, і вирішення всіх проблем по забезпеченню безпеки з'єднання залишиться за протоколом більш низького транспортного рівня ‑ TCP. Однак, згадавши про можливі атаки на TCP-з'єднання, розглянутих у розділі “Підміна одного із суб'єктів TCP-з'єднання в мережі Internet”», нескладно зробити висновок: при використанні базових протоколів сімейства TCP/IP забезпечити безпеку з'єднання практично неможливо. Це відбувається через те, що, на жаль, усі базові протоколи мережі Internet сильно застаріли з погляду забезпечення інформаційної безпеки.

Єдине, що можна порекомендувати мережним адміністраторам для захисту тільки від міжсегментних атак на з'єднання, - у якості базового “захищеного” протоколу використовувати протокол TCP і мережні ОС, у яких початкове значення ідентифікатора TCP-з'єднання дійсно генерується випадковим чином (непоганий псевдовипадковий алгоритм генерації використовується в останніх версіях ОС FreeBSD). Підкреслимо, що тут говорилося тільки про базові протоколи сімейства TCP/IP, а всі захищені протоколи типу SSL, S-HTTP, Kerberos і т.д. не є базовими.

4.10 Програмно-апаратні методи захисту від віддалених атак

До програмно-апаратних засобів забезпечення інформаційної безпеки засобів зв'язку в обчислювальних мережах відносяться:

• програмно-апаратні шифратори мережного трафіку;

• методика Firewall, реалізована на базі програмно-апаратних засобів;

• захищені мережні криптопротоколи;

• програмні засоби виявлення атак (IDS - Intrusion Detection Systems);

• програмні засоби аналізу захищеності

• захищені мережні ОС.

Існує величезна кількість літератури, присвяченої засобам захисту для використання в мережі Internet.

Ці засоби опишемо по можливості коротко, щоб не повторювати добре відому усім інформацію. При цьому будемо переслідувати наступні цілі: по-перше, ще раз розвіяти міф про “абсолютний захист”, що нібито забезпечують системи Firewall; по-друге, порівняти існуючі версії криптопротоколів, застосовуваних у Internet.

4.11 Багаторівнева фільтрація мережного трафика

Фільтрація звичайно відбувається на чотирьох рівнях OSI:

1.   Канальному (Ethernet).

2.   Мережному (IP).

3.   Транспортному (TCP, UDP).

4.   Прикладному (FTP, TELNET, HTTP, SMTP і т.д.).

Фільтрація мережного трафіка є основною функцією систем Firewall і дозволяє адміністратору безпеки мережі централізовано здійснювати необхідну мережеву політику в виділеному сегменті IP-мережі, тобото налаштувавши необхідним чином Firewall, можна дозволити чи заборонити користувачам як доступ з зовні мережі до служб хостів, що знаходяться у захищеному сегменті, так і доступ користувачів з внутрішньої мережі до ресурсів зовнішньої мережі. Можна провести аналогію з адміністраторами локальних ОС, котрі для реалізації політики безпеки в ОС призначають необхідним чином відповідні відношення між суб’єктами (користувачами) і об’єктами системи (наприклад, файлами), що дозволяє розмежувати доступ суб’єктів системи до її об’єктів у відповідності з заданими адміністратором правами доступу. Ті ж міркування можна використати у до Firewall-фільтрації: у якості суб'єктів взаємодії будуть виступати IP-адреси хостів користувачів, а як об'єкти, доступ до яких необхідно розмежувати, ‑ IP-адреси хостів, використовувані транспортні протоколи і служби надання віддаленого доступу.

4.12 Proxy-схема з додатковою ідентифікацією й аутентифікацією користувачів на Firewall-хості

Proxy-схема дозволяє, по-перше, при доступі до захищеного Firewall сегменту мережі здійснити на ньому додаткову ідентифікацію й аутентифікацію віддаленого користувача і, по-друге, є основою для створення приватних мереж з віртуальними IP-адресами. Зміст ргоху-схеми полягає в створенні з'єднання з кінцевим адресатом через проміжний proxy-сервер (у перекладі з англ. “proxy” ‑ повноважний) на хості Firewall.

Якщо адміністратор безпеки мережі вважає за доцільне сховати топологію своєї внутрішньої IP-мережі, то йому можна порекомендувати використовувати системи Firewall для створення віртуальних мереж з застосуванням технології NAT (Network Address Translation). Для адресації в зовнішню мережу через Firewall необхідно або використовувати на хості Firewall описані вище ргоху-сервери, або застосовувати тільки спеціальні системи маршрутизації (через які і можлива зовнішня адресація). Це відбувається через те, що використовувана у внутрішній приватній мережі “віртуальна” IP-адреса, непридатна для зовнішньої адресації, тобто адресації до абонентів, що знаходиться за її межами. Тому proxy-сервер повинен здійснювати зв'язок з абонентами з зовнішньої мережі зі своєї справжньої IP-адреси. До речі, ця схема зручна в тому випадку, якщо для створення IP-мережі виділили недостатню кількість IP-адрес: у стандарті IPv4 це відбувається часто , тому для повноцінної IP-мережі з використанням ргоху-схеми досить однієї виділеної IP-адреси для proxy-сервера.

Отже, будь-який пристрій, що реалізує хоча б одну з цих функцій Firewall-методики, і є Firewall-пристроєм. Наприклад, ніщо не заважає використовувати в якості Firewall-хоста комп'ютер зі звичайною ОС FreeBSD чи Linux, у якій відповідним чином потрібно скомпілювати ядро ОС. Firewall такого типу буде забезпечувати тільки багаторівневу фільтрацію IP-трафіка. Інша справа ‑ пропоновані на ринку потужні Firewall-комплекси, створені на базі ЕОМ чи міні-ЕОМ, звичайно реалізують усі функції Firewall-методики і є повнофункціональними системами Firewall.

Але Firewall не є гарантує абсолютного захисту від віддалених атак у Internet. Ця система ‑ не стільки засіб забезпечення безпеки, скільки можливість централізовано здійснювати мережну політику розмежування віддаленого доступу до ресурсів мережі. Так, у тому випадку, якщо, наприклад, до даного хосту заборонений віддалений TELNET-доступ, Firewall однозначно запобіжить можливості такого доступу. Однак більшість віддалених атак мають зовсім інші цілі (безглуздо намагатися одержати визначений вид доступу, якщо він заборонений системою Firewall). Дійсно, задамо собі питання, а які з розглянутих віддалених атак може запобігти Firewall? Аналіз мережевого графіка? Очевидно, що ні! Помилковий ARP-сервер? І так, і ні (для захисту зовсім не обов'язково використовувати Firewall). Помилковий DNS-сервер? Ні, на жаль, Firewall тут не помічник. Нав'язування помилкового маршруту за допомогою протоколу ICMP? Так, цю атаку шляхом фільтрації ICMP-повідомлень Firewall легко відіб'є (хоча досить буде фільтруючого маршрутизатора, наприклад Cisco). Підміна одного із суб'єктів TCP-з'єднання? Відповідь негативна ‑ Firewall тут абсолютно ні при чому. Порушення працездатності хосту шляхом створення спрямованого шторму хибних запитів чи переповнення черги запитів? У цьому випадку застосування Firewall тільки погіршить справу. Зловмиснику досить атакувати тільки один Firewall, а не кілька хостів (це легко пояснюється тим, що зв'язок внутрішніх хостів із зовнішнім світом можливий лише через Firewall), щоб вивести з ладу (відрізати від зовнішнього світу) усі хости усередині захищеного Firewall-системою сегмента.

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