ѕеред тим ¤к почати впроваджувати заходи по забезпеченню безпеки необх≥дно визначити, що (список об'Їкт≥в ≥ ресурс≥в розпод≥леноњ обчислювальноњ мереж≥), в≥д чого (анал≥з можливих загроз даноњ системи) ≥ ¤к (розробка вимог, визначенн¤ пол≥тики безпеки ≥ виробленн¤ адм≥н≥стративних ≥ програмно-апаратних заход≥в по забезпеченню на практиц≥ розробленоњ пол≥тики безпеки) захищати.
ћабуть, найб≥льш простими ≥ дешевими Ї адм≥н≥стративн≥ методи захисту в≥д ≥нформац≥йних деструктивних вплив≥в, про що ≥ розпов≥датиметьс¤ дал≥.
ѕершою розгл¤дуваною в≥ддаленою атакою була атака, що дозвол¤Ї кракеров≥ за допомогою програмного прослуховуванн¤ каналу передач≥ пов≥домлень у мереж≥ перехоплювати будь-¤ку ≥нформац≥ю, ¤кою обм≥нюютьс¤ користувач≥, ¤кщо по каналу передаютьс¤ т≥льки нешифрован≥ пов≥домленн¤. “акож було показано, що базов≥ прикладн≥ протоколи в≥ддаленого доступу TELNET ≥ FTP не передбачають елементарного криптозахисту переданих по мереж≥ ≥дентиф≥катор≥в (≥мен) ≥ аутентиф≥катор≥в (парол≥в). “ому адм≥н≥страторам мереж можна порекомендувати не використовувати ц≥ базов≥ протоколи дл¤ наданн¤ в≥ддаленого авторизованого доступу до ресурс≥в своњх систем ≥ вважати анал≥з мережевого траф≥ка т≥Їњ пост≥йно присутньою загрозою, котру неможливо усунути, але можна зробити безглуздою, використовуючи ст≥йк≥ криптоалгоритмти захисту IP-потоку.
оротко нагадаЇмо суть ц≥Їњ в≥ддаленоњ атаки, що використовуЇ недол≥ки в механ≥зм≥ в≥ддаленого пошуку на баз≥ протоколу ARP. ” тому випадку, ¤кщо в мережн≥й ќ— в≥дсутн¤ ≥нформац≥¤ про в≥дпов≥дн≥сть IP- ≥ Ethernet-адрес хост≥в усередин≥ одного сегмента IP-мереж≥, даний протокол дозвол¤Ї посилати циркул¤рний ARP-запит на пошук необх≥дноњ Ethernet-адреси, на ¤кий атакуючий може над≥слати хибну в≥дпов≥дь, ≥ надал≥ весь траф≥к на канальному р≥вн≥ ви¤витьс¤ перехопленим атакуючим ≥ пройде через хибний ARP-cepвер. ќчевидно, що дл¤ л≥кв≥дац≥њ даноњ атаки необх≥дно усунути причину њњ можливого зд≥йсненн¤, що пол¤гаЇ у в≥дсутност≥ в ќ— кожного хосту необх≥дноњ ≥нформац≥њ про в≥дпов≥дн≥ IP- ≥ Ethernet-адреси вс≥х ≥нших хост≥в усередин≥ даного сегмента мереж≥. “аким чином, найпрост≥шому р≥шенн¤ ‑ створити мережним адм≥н≥стратором статичну ARP-таблицю у вид≥ файлу (у ќ— UNIX звичайно /etc/ethers), куди внести необх≥дну ≥нформац≥ю про адреси. ƒаний файл встановлюЇтьс¤ на кожен хост усередин≥ сегмента, ≥, отже, у мережн≥й ќ— в≥дпадаЇ необх≥дн≥сть у використанн≥ в≥ддаленого ARP-пошуку. ѕравда, ќ— Windows 95 це не допомагаЇ.
як уже обговорювалос¤, використанн¤ служби DNS у њњ нин≥шньому вид≥ може дозволити кракеров≥ одержати глобальний контроль над з'Їднанн¤ми шл¤хом нав'¤зуванн¤ хибного маршруту через хост кракера ‑ хибний DNS-сервер. «д≥йсненн¤ такоњ в≥ддаленоњ атаки, заснованоњ на потенц≥йних уразливост¤х служби DNS, приведе до катастроф≥чних насл≥дк≥в дл¤ величезного числа користувач≥в Internet ≥ стане причиною масового порушенн¤ ≥нформац≥йноњ безпеки глобальноњ мереж≥. ƒал≥ дл¤ адм≥н≥стратор≥в ≥ користувач≥в мереж≥ ≥ дл¤ адм≥н≥стратор≥в DNS-сервер≥в пропонуютьс¤ можлив≥ адм≥н≥стративн≥ методи запоб≥ганн¤ чи утрудненн¤ даноњ в≥ддаленоњ атаки.
якщо в≥дпов≥дати на запитанн¤ захисту в≥д хибного DNS-сервера коротко, то в≥дпов≥дь формулюЇтьс¤ одним словом: УЌ≥¤кФ. Ќ≥ адм≥н≥стративно, н≥ програмно не можна захиститис¤ в≥д атаки на ≥снуючу верс≥ю служби DNS. ќптимальне р≥шенн¤ з погл¤ду безпеки ‑ узагал≥ в≥дмовитис¤ в≥д використанн¤ служби DNS у захищеному сегмент≥ мереж≥.
ќчевидно, що зовс≥м в≥дмовитис¤ в≥д використанн¤ ≥мен при звертанн≥ до хост≥в буде дуже незручно, тому можна запропонувати наступне компром≥сне р≥шенн¤: використовувати ≥мена, але в≥дмовитис¤ в≥д механ≥зму в≥ддаленого DNS-пошуку. ≤ншими словами це поверненн¤ до схеми, що застосовувалас¤ до по¤ви служби DNS з вид≥леними DNS-серверами. “од≥ на кожн≥й машин≥ ≥снував файл hosts, у ¤кому знаходилас¤ ≥нформац≥¤ про ≥мена ≥ в≥дпов≥дних IP-адресах ус≥х хост≥в у мереж≥. ќчевидно, що на сьогодн≥шн≥й день адм≥н≥стратору в под≥бний файл можна внести ≥нформац≥ю лише про найб≥льш часто в≥дв≥дуван≥ користувачами даного сегмента серверах мереж≥. “ому на практиц≥ виконати дане р≥шенн¤ надзвичайне важко ≥, мабуть, нереально.
ўоб ускладнити зд≥йсненн¤ даноњ в≥ддаленоњ атаки (передача на хост хибноњ DNS-в≥дпов≥д≥ без прийому DNS-запиту), можна запропонувати адм≥н≥страторам використовувати протокол TCP зам≥сть протоколу UDP, що встановлюЇтьс¤ за замовчуванн¤м (хоча з документац≥њ далеко не очевидно, ¤к його зам≥нити).
«агальний невт≥шний висновок такий: у мереж≥ Internet при використанн≥ ≥снуючоњ верс≥њ служби DNS немаЇ прийн¤тного р≥шенн¤ дл¤ захисту в≥д помилкового DNS-сервера (≥ не в≥дмовишс¤, ¤к у випадку з ARP, ≥ використовувати небезпечно).
™диний спос≥б утруднити зд≥йсненн¤ даноњ в≥ддаленоњ атаки ‑ використовувати дл¤ звТ¤зку з хостами ≥ з ≥ншими DNS-серверами т≥льки протокол TCP, але не UDP. јле не сл≥д забувайте ¤к про можливе перехопленн¤ DNS-запиту, так ≥ про математичне прогнозуванн¤ початкового значенн¤ TCP-≥дентиф≥катора ISN (див. параграф Уѕ≥дм≥на одного ≥з суб'Їкт≥в TCP-з'Їднанн¤ в мереж≥ InternetФ).
Ќа завершенн¤ можна порекомендувати дл¤ вс≥Їњ мереж≥ Internet скор≥ше перейти або до б≥льш захищеноњ верс≥њ служби DNS, або прийн¤ти Їдиний стандарт на захищений протокол. «д≥йснити цей перех≥д, незважаючи на вс≥ колосальн≥ витрати, просто необх≥дно, ≥накше Internet ви¤витьс¤ на кол≥нах перед зростаючими усп≥шними спробами порушенн¤ безпеки.
–ан≥ше розгл¤далас¤ в≥ддалена атака суть ¤коњ пол¤гала у передач≥ на хост хибного пов≥домленн¤ ICMP Redirect про зм≥ну вих≥дного маршруту. ÷¤ атака приводила ¤к до перехопленн¤ атакуючим ≥нформац≥њ, так ≥ до порушенн¤ працездатност≥ хосту, що атакуЇтьс¤. ƒл¤ того щоб захиститис¤ в≥д такоњ атаки, необх≥дно або ф≥льтрувати дане пов≥домленн¤ (використовуючи Firewall чи ф≥льтруючий маршрутизатор), не допускаючи його попаданн¤ на к≥нцеву систему, або в≥дпов≥дним чином вибирати мережну ќ—, що про≥гноруЇ це пов≥домленн¤. ќднак, ¤к правило, не ≥снуЇ адм≥н≥стративних способ≥в уплинути на мережну ќ— так, щоб заборонити њй зм≥нювати маршрут ≥ реагувати на дане пов≥домленн¤. ™диний спос≥б (наприклад, у випадку ќ— Linux чи FreeBSD) пол¤гаЇ в т≥м, щоб зм≥нити вих≥дн≥ тексти ≥ перекомп≥лювати ¤дро ќ—. ќчевидно, що такий екзотичний п≥дх≥д можливий т≥льки дл¤ операц≥йних систем, в≥льно розповсюджуваних разом з вих≥дними текстами. ≤ншого способу дов≥датис¤ реакц≥ю використовуваноњ у ќ— на пов≥домленн¤ ICMP Redirect, ¤к послати пов≥домленн¤ ≥ подивитис¤, ¤кий буде результат, на практиц≥ не ≥снуЇ. ≈ксперименти показали, що дане пов≥домленн¤ дозвол¤Ї зм≥нити маршрутизац≥ю на ќ— Windows 95 ≥ Windows NT 4.0. ¬≥дзначимо, що продукти компан≥њ Microsoft не в≥др≥зн¤ютьс¤ особливою захищен≥стю в≥д можливих в≥ддалених атак, властивим IP-мережам. ќтже, небажано використовувати дан≥ ќ— у захищеному сегмент≥ IP-мереж≥. ÷е ≥ буде тим самим адм≥н≥стративним р≥шенн¤м по захисту в≥д под≥бноњ в≥ддаленоњ атаки.
як уже в≥дзначалос¤, прийн¤тних способ≥в захисту в≥д в≥дмови в обслуговуванн≥ дл¤ стандарту 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.
як в≥дзначалос¤ ран≥ше, Їдиним базовим протоколом с≥мейства 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 ≥ т.д. не Ї базовими.
ƒо програмно-апаратних засоб≥в забезпеченн¤ ≥нформац≥йноњ безпеки засоб≥в зв'¤зку в обчислювальних мережах в≥днос¤тьс¤:
Ј програмно-апаратн≥ шифратори мережного траф≥ку;
Ј методика Firewall, реал≥зована на баз≥ програмно-апаратних засоб≥в;
Ј захищен≥ мережн≥ криптопротоколи;
Ј програмн≥ засоби ви¤вленн¤ атак (IDS - Intrusion Detection Systems);
Ј програмн≥ засоби анал≥зу захищеност≥
Ј захищен≥ мережн≥ ќ—.
≤снуЇ величезна к≥льк≥сть л≥тератури, присв¤ченоњ засобам захисту дл¤ використанн¤ в мереж≥ Internet.
÷≥ засоби опишемо по можливост≥ коротко, щоб не повторювати добре в≥дому ус≥м ≥нформац≥ю. ѕри цьому будемо пересл≥дувати наступн≥ ц≥л≥: по-перше, ще раз розв≥¤ти м≥ф про Уабсолютний захистФ, що н≥бито забезпечують системи Firewall; по-друге, пор≥вн¤ти ≥снуюч≥ верс≥њ криптопротокол≥в, застосовуваних у Internet.
” загальному випадку методика Firewall ¤к основний програмно-апаратний зас≥б зд≥йсненн¤ мережноњ пол≥тики безпеки у вид≥леному сегмент≥ IP-мереж≥ реал≥зуЇ наступн≥ основн≥ функц≥њ.
‘≥льтрац≥¤ звичайно в≥дбуваЇтьс¤ на чотирьох р≥вн¤х OSI:
1. анальному (Ethernet).
2. ћережному (IP).
3. “ранспортному (TCP, UDP).
4. ѕрикладному (FTP, TELNET, HTTP, SMTP ≥ т.д.).
‘≥льтрац≥¤ мережного траф≥ка Ї основною функц≥Їю систем Firewall ≥ дозвол¤Ї адм≥н≥стратору безпеки мереж≥ централ≥зовано зд≥йснювати необх≥дну мережеву пол≥тику в вид≥леному сегмент≥ IP-мереж≥, тобото налаштувавши необх≥дним чином Firewall, можна дозволити чи заборонити користувачам ¤к доступ з зовн≥ мереж≥ до служб хост≥в, що знаход¤тьс¤ у захищеному сегмент≥, так ≥ доступ користувач≥в з внутр≥шньоњ мереж≥ до ресурс≥в зовн≥шньоњ мереж≥. ћожна провести аналог≥ю з адм≥н≥страторами локальних ќ—, котр≥ дл¤ реал≥зац≥њ пол≥тики безпеки в ќ— призначають необх≥дним чином в≥дпов≥дн≥ в≥дношенн¤ м≥ж субТЇктами (користувачами) ≥ обТЇктами системи (наприклад, файлами), що дозвол¤Ї розмежувати доступ субТЇкт≥в системи до њњ обТЇкт≥в у в≥дпов≥дност≥ з заданими адм≥н≥стратором правами доступу. “≥ ж м≥ркуванн¤ можна використати у до Firewall-ф≥льтрац≥њ: у ¤кост≥ суб'Їкт≥в взаЇмод≥њ будуть виступати IP-адреси хост≥в користувач≥в, а ¤к об'Їкти, доступ до ¤ких необх≥дно розмежувати, ‑ IP-адреси хост≥в, використовуван≥ транспортн≥ протоколи ≥ служби наданн¤ в≥ддаленого доступу.
9. †http://hosting-database.com
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 абсолютно безглуздо. Ќа даний момент ц≥й методиц≥ (саме ¤к методиц≥) немаЇ альтернативи. ќднак потр≥бно ч≥тко розум≥ти ≥ пам'¤тати њњ основне призначенн¤.
9. †http://hosting-database.com
ƒо програмних метод≥в захисту можна в≥днести насамперед захищен≥ криптопротоколи, з використанн¤м ¤ких з'¤вл¤Їтьс¤ можлив≥сть над≥йного захисту з'Їднанн¤. ƒал≥ мова йтиме про ≥снуюч≥ на сьогодн≥шн≥й день у Internet п≥дходах ≥ основних, уже розроблених, криптопротоколах.
ѕрочитавши попередн≥ розд≥ли читач, мабуть, усв≥домив, що одна з основних причин усп≥ху в≥ддалених атак на розпод≥лен≥ обчислювальн≥ системи пол¤гаЇ у використанн≥ мережних протокол≥в обм≥ну, що не можуть над≥йно ≥дентиф≥кувати в≥ддален≥ об'Їкти, захистити з'Їднанн¤ ≥ передан≥ по ньому дан≥. “ому зовс≥м природно, що в процес≥ функц≥онуванн¤ Internet були створен≥ р≥зн≥ захищен≥ мережн≥ протоколи, що використовують криптограф≥ю ¤к ≥з закритим, так ≥ з в≥дкритим ключем. ласична криптограф≥¤ ≥з симетричними криптоалгоритмами припускаЇ на¤вн≥сть у передавальноњ ≥ приймаючоњ стор≥н симетричних (однакових) ключ≥в дл¤ шифруванн¤ ≥ дешифруванн¤ пов≥домлень. ÷≥ ключ≥ заздалег≥дь повинн≥ бути розпод≥лен≥ м≥ж обмеженим числом абонент≥в, що в криптограф≥њ називаЇтьс¤ стандартною проблемою статичного розпод≥лу ключ≥в. ќчевидно, що застосуванн¤ класичноњ криптограф≥њ ≥з симетричними ключами можливо лише на обмежен≥й множин≥ об'Їкт≥в. ” мереж≥ Internet дл¤ вс≥х њњ користувач≥в вир≥шити проблему статичного розпод≥лу ключ≥в не Ї можливим. ќднак одним з перших захищених протокол≥в обм≥ну в Internet був протокол Kerberos, заснований саме на статичному розпод≥л≥ ключ≥в дл¤ обмеженого числа абонент≥в. “аким же шл¤хом, використовуючи класичну симетричну криптограф≥ю, змушен≥ йти спецслужби, що розробл¤ють своњ захищен≥ криптопротоколи дл¤ Internet. ќтже, щоб дати можлив≥сть захиститис¤ ус≥м користувач≥в мереж≥ Internet, а не обмежен≥й його п≥дмножин≥, необх≥дно використовувати динам≥чно вироблюван≥ в процес≥ створенн¤ в≥ртуального з'Їднанн¤ ключ≥, застосовуючи криптограф≥ю з в≥дкритим ключем. ƒал≥ ми розгл¤немо основн≥ на сьогодн≥ п≥дходи ≥ протоколи, що забезпечують захист з'Їднанн¤.
SKIP-технолог≥Їю (Secure Key Internet Protocol ‑ Internet-протокол ≥з захищеним ключем) називаЇтьс¤ стандарт ≥нкапсул¤ц≥њ IP-пакет≥в, що дозвол¤Ї в ≥снуючому стандарт≥ IPv4 на мережному р≥вн≥ забезпечити захист з'Їднанн¤ ≥ переданих по ньому даних. ÷е дос¤гаЇтьс¤ в такий спос≥б: SKIP-пакет ‑ це звичайний IP-пакет, його поле даних ¤вл¤Ї собою SKIP-заголовок визначеного специф≥кац≥Їю формату ≥ криптограму (зашифрован≥ дан≥). “ака структура SKIP-пакету дозвол¤Ї безперешкодно направл¤ти його будь-¤кий хосту в Internet (м≥жмережева адресац≥¤ в≥дбуваЇтьс¤ по звичайному IP-заголовку в SKIP-пакет≥). ≥нцевий одержувач SKIP-пакету по заздалег≥дь визначеному розроблювачами алгоритму розшифровуЇ криптограму ≥ формуЇ звичайний TCP- чи UDP-пакет, що ≥ передаЇ в≥дпов≥дному звичайному модулю (TCP чи UDP) ¤дра операц≥йноњ системи. ” принцип≥ н≥що не заважаЇ розроблювачу формувати за даною схемою своњ ориг≥нальний заголовок, в≥дм≥нний в≥д SKIP-заголовка.
S-HTTP (Secure HTTP ‑ захищений HTTP) ‑ це захищений HTTP-протокол, розроблений компан≥Їю Enterprise Integration Technologies (EIT) спец≥ально дл¤ Web. ѕротокол S-HTTP дозвол¤Ї забезпечити над≥йний криптозахист т≥льки HTTP-документ≥в Web-сервера ≥ функц≥онуЇ на прикладному р≥вн≥ модел≥ OSI. “ака особлив≥сть цього протоколу робить його абсолютно спец≥ал≥зованим засобом захисту з'Їднанн¤, отже, його застосуванн¤ дл¤ захисту вс≥х ≥нших прикладних протокол≥в (FTP, TELNET, SMTP ≥ ≥н.) неможливе.
SSL (Secure Socket Layer ‑ захищен≥ схован≥ гн≥зда) ‑ розробка компан≥њ Netscape ‑ ун≥версальний протокол захисту з'Їднанн¤, що функц≥онуЇ на сеансовому р≥вн≥ OSI. ¬≥н використовуЇ криптограф≥ю з в≥дкритим ключем ≥ на сьогодн≥шн≥й день, Ї найпопул¤рн≥шим ≥ Їдиним ун≥версальним засобом, що дозвол¤Ї динам≥чно захистити дов≥льне з'Їднанн¤ з застосуванн¤м будь-¤кого прикладного протоколу (DNS, FTP, TELNET, SMTP ≥ т.д.). ÷е зв'¤зано з тим, що SSI на в≥дм≥ну в≥д S-HTTP, функц≥онуЇ на пром≥жному сеансовому р≥вн≥ OSI ‑ м≥ж транспортним (TCP, UDP) ≥ прикладним (FTI TELNET). ѕри цьому процес створенн¤ в≥ртуального SSL-з'Їднанн¤ проходить за схемою ƒ≥фф≥ ≥ ’еллмана, що дозвол¤Ї виробити криптост≥йкий сеансовий ключ, котрий буде використовуватис¤ в подальшому абонентами SSL-з'Їднанн¤ дл¤ шифруванн¤ переданих пов≥домлень.
ѕротокол SSL уже практично оформивс¤ ¤к оф≥ц≥йний стандарт захисту дл¤ HTTP-з'Їднань, тобто дл¤ захисту Web-сервер≥в. …ого реал≥зують на сьогодн≥ ус≥ найпопул¤рн≥ш≥ браузери. «вичайно, дл¤ встановленн¤ SSL-з'Їднанн¤ з Web-сервером ще необх≥дно ≥ на¤вн≥сть Web-сервера, що п≥дтримуЇ SSL (на приклад, SSL-Apache).
«авершуючи розпов≥дь про протокол SSL, не можна не в≥дзначити наступний факт: законами —Ўј донедавна був заборонений експорт криптосистем з довжиною ключа б≥льшою 40 б≥т, а пот≥м 56 б≥т, тому в багатьох верс≥¤х браузер≥в використовуютьс¤ саме 40/56-б≥тн≥ ключ≥. Ќа щаст¤ сьогодн≥ ситуац≥¤ виправилас¤ ≥ останн≥ верс≥њ браузер≥в п≥дтримують ставшу уже стандартну довжину ключ≥в 128 б≥т.
ѕовсюдне застосуванн¤ захищених протокол≥в обм≥ну, особливо SSL 128 б≥т, поставить над≥йний бар'Їр на шл¤ху ус≥л¤ких в≥ддалених атак ≥ серйозно ускладнить житт¤ кракер≥в усього св≥ту. ќднак весь траг≥зм сьогодн≥шньоњ ситуац≥њ з забезпеченн¤м безпеки в Internet пол¤гаЇ в тому, що поки що жоден з ≥снуючих криптопротокол≥в (а њх уже чимало) не оформивс¤ ¤к Їдиний стандарт захисту з'Їднанн¤, що п≥дтримувавс¤ б ус≥ма виробниками мережних ќ—. ѕротокол SSL п≥дходить на цю роль щонайкраще, але його не п≥дтримують ус≥ мережн≥ ќ— ≥ ¤к правило його застосовують лише до найкритичн≥ших застосувань (наприклад, електронна комерц≥¤). “ому були створен≥ спец≥альн≥ прикладн≥ SSL-сум≥сн≥ сервери (DNS, FTP, TELNET, WWW ≥ ≥н.). якщо не домовитис¤ про прийн¤тт¤ Їдиного стандарту на захищений протокол сеансового р≥вн¤, то тод≥ потр≥бно приймати багато стандарт≥в на захист кожноњ окремоњ прикладноњ служби. Ќаприклад, уже розроблений експериментальний протокол Secure DNS. “акож ≥снують експериментальн≥ SSL-сум≥сн≥ Secure FTP- ≥ TELNET-сервери. јле все це без прийн¤тт¤ Їдиного стандарту на захищений протокол не маЇ абсолютно н≥¤кого зм≥сту. ¬ даний час виробники мережних ќ— не можуть домовитис¤ про Їдину позиц≥ю по цьому питанню ≥ тим самим перекладають р≥шенн¤ проблеми безпосередньо на користувач≥в Internet.
copyright © Network Defense