Введення
в брандмауери
План
Поняття брандмауера
Чому саме брандмауери?
Проблеми, що виникають із-за брандмауерів
Компоненти брандмауера
Можна знайти вирішення ряд проблем з безпекою в Інтернеті, або, принаймні, зробити їх менш небезпечними, якщо використовувати існуючі і добре
відомі технології та заходи захисту на рівні хостів. Брандмауер може значно підвищити рівень безпеки мережі організації та зберегти в той же
час доступ до всіх ресурсів Інтернеті. Цей розділ дає огляд брандмауерів, який включає в себе опис того, як вони усувають небезпеку
вразливих місць, описаних у розділі 1, від чого не захищають брандмауери та компоненти, що становлять брандмауер. Ця глава особливу увагу звертає на
використання посиленою аутентифікації і важливість політики безпеки при визначенні того, як брандмауер буде реалізовувати схему захисту.
Рисунок 2.1 Приклад брандмауера з маршрутизатором і прикладним шлюзом
Поняття брандмауера
Напевно, найкраще почати з опису того, що НЕ є брандмауером: брандмауер - це не просто маршрутизатор, хост чи група систем, які
забезпечують безпеку в мережі. Скоріше, брандмауер - це підхід до безпеки; він допомагає реалізувати політику безпеки, яка визначає
дозволені служби і типи доступу до них, і є реалізацією цієї політики в термінах мережевої конфігурації, кількох хостів і маршрутизаторів, та інших
заходів захисту, таких як посилена аутентифікація замість статичних паролів. Основна мета системи брандмауера - управління доступом К або З що захищається
мережі. Він реалізує політику мережевого доступу, змушуючи проходити всі з'єднання з мережею через брандмауер, де вони можуть бути проаналізовані та
вирішені або відкинуті.
Система брандмауера може бути маршрутизатором, персональним комп'ютером, хостом, або групою хостів, створеної спеціально для захисту мережі або підмережі від
неправильного використання протоколів і служб хостами, що знаходяться поза цією підмережі. Зазвичай система брандмауера створюється на основі маршрутизаторів
верхнього рівня, звичайно на тих, які з'єднують мережу з Інтернетом, хоча може бути створена і на інших маршрутизаторах, для захисту тільки частини хостів або
підмереж.
Проблеми, що виникають із-за брандмауерів
Крім описаних вище переваг використання брандмауерів, має місце ряд недоліків при їх використанні і ряд проблем, від яких брандмауер не
можуть захистити. Брандмауер не є панацеєю від всіх проблем безпеки, пов'язаних з Інтернетом.
2.3.1 Обмеження в доступі до потрібних службам
Найбільш очевидним недоліком брандмауера є те, що він може блокувати ряд служб, які використовують користувачі, такі як TELNET, FTP,
X Windows, NFS та ін Тим не менше, ці недоліки не властиві тільки брандмауерів; мережевий доступ також може обмежуватися при захисті на рівні
хостів відповідно до політики безпеки. Добре продумана політика безпеки, в якій знайдено баланс між вимогами безпеки і
потребами користувачів, може сильно допомогти при вирішенні проблем з-за обмежень у доступі до послуг.
Деякі мережі можуть мати топологію, яка не дозволяє застосувати брандмауер, або використовувати служби, такі як NFS, таким чином, що
використання брандмауера потребують серйозних обмежень при роботі в мережі. Наприклад, у мережі може вимагатися використання NFS і NIS через основні
маршрутизатори. У такій ситуації вартість встановлення брандмауера потрібно порівняти із шкодою, якої зазнає організація від атаки, що використовує вразливі місця,
захищаються брандмауером, тобто провести аналіз ризику, а потім прийняти рішення на підставі його результатів. Можуть виявитися більш доречними інші рішення,
такі як Керберос, але ці рішення також мають свої недоліки. [NIST94c] містить додаткову інформацію про Керберос та інших потенційних рішеннях.
2.3.2 Велика кількість залишаються уразливих місць
По-друге, брандмауери не захищають від чорних входів (люків) у мережі. Наприклад, якщо можна здійснити необмежений доступ по модему в мережу, захищену
брандмауером, атакуючі можуть ефективно обійти брандмауер [Iiaf91]. Зараз швидкості модемів достатні для того, щоб зробити можливим використання
SLIP (Serial Line IP) і PPP (Point-to-Point Protocol); SLIP або PPP-з'єднання всередині захищеної мережі по суті є ще одним з'єднанням з мережею і
потенційним вразливим місцем. Для чого потрібний брандмауер, якщо дозволено необмежений доступ по модему?
2.3.3 Погана захист від атак своїх співробітників
Брандмауери зазвичай не забезпечують захисту від внутрішніх загроз. Хоча брандмауер може захищати від отримання сторонніми особами критичних даних,
він не захищає від копіювання своїми співробітниками даних на стрічку або дискету і винесення її за межі мережі. Тому, було б помилкою думати, що наявність
брандмауера захищає від атак зсередини або атак, для захисту від яких потрібен не брандмауер. Напевно, не варто вкладати значні ресурси в брандмауер,
якщо є інші способи вкрасти дані.
2.3.4 Інші проблеми
З брандмауером також пов'язана низка інших проблем:
WWW, gopher - нові
інформаційні сервера й клієнти, такі як WWW, gopher, WAIS та ряд інших
не розраховані на спільну роботу з брандмауером, і з-за їх новизни
взагалі досить ризиковані. Є потенційна можливість атак з
допомогою спеціальних передачі даних, при яких дані, в опрацюванні
клієнтом, можуть містити команди клієнта, ці команди можуть примушувати
клієнта змінити параметри засобів управління доступом або модифіковані
важливі файли, пов'язані із захистом машини клієнта.
MBONE - групові
передачі за допомогою IP (MBONE), що містять мова і зображення,
інкапсулюються в інших пакетах; брандмауери зазвичай пропускають ці
пакети, не перевіряючи їх вміст. Передачі типу MBONE представляють
потенційну загрозу, якщо пакети містять команди, що змінюють параметри
роботи засобів захисту та дозволяють зловмисникам одержати доступ.
Віруси - брандмауер не
захищають від користувачів, які завантажили програми для ПЕОМ, заражені
вірусами, з інтернетівських архівів або передачі таких програм як
додатків до листа. Тому що ці програми можуть бути закодовані або
стиснуті великим числом способів, брандмауер не може сканувати такі
програми на предмет виявлення сигнатур вірусів. Проблема вірусів буде
залишатися і повинна бути вирішена за допомогою інших антивірусних засобів захисту.
Пропускна здатність --
брандмауери є потенційно вузьким місцем, тому що всі з'єднання
повинні проходити через брандмауер і, в деяких випадках, вивчатися
брандмауером. Тим не менш, сьогодні це не є проблемою, тому що
брандмауери можуть обробляти дані зі швидкостями 1.5 Мбіт/с, а
більшість мереж, підключених до Інтернету, мають підключення з
швидкістю меншою або рівною цієї.
" Всі яйця в одному кошику " - система брандмауера
концентрує безпеку в одному місці, а не розподіляє її серед
групи систем. Компрометація брандмауера може бути жахливою для погано
захищених систем в підмережі. Цьому тези можна протиставити
контраргумент, що при збільшенні підмережі зростають шанси того, що в ній
з'являться вразливі місця в безпеці.
Незважаючи на ці недоліки NIST рекомендує, щоб організації захищали свої ресурси за допомогою брандмауерів та інших засобів безпеки.
Компоненти брандмауера
Основними компонентами брандмауера є:
політика мережевого доступу
механізми посиленою аутентифікації
фільтрація пакетів
прикладні шлюзи
Наступні розділи описують більш детально кожну з цих компонентів.
2.4.1 Політика мережевого доступу
Є два види політики мережевого доступу, які впливають на проектування, встановлення та використання системи брандмауера. Політика
верхнього рівня є проблемною концептуальної політикою, яка визначає, доступ до яких сервісів буде вирішена або явно заборонений з
мережі, що захищається, як ці сервіси будуть використовуватися, і за яких умов буде робитися виняток і політика не буде дотримуватися. Політика нижнього
рівня описує, як брандмауер повинен насправді обмежувати доступ і фільтрувати сервіси, які вказані в політиці верхнього рівня. Наступні
розділи коротко описують ці політики.
Політика доступу до сервісів
Політика доступу до сервісів має фокусуватися на проблемах використання Інтернету, описаних вище, і, судячи з усього, на всьому доступ до мережі ззовні (то
є політика доступу по модемів, з'єднань SLIP та PPP). Ця політика має бути уточненням загальної політики організації щодо захисту інформаційних
ресурсів в організації. Щоб брандмауер успішно захищав їх, політика доступу до сервісів повинна бути реалістичною і узгоджуватися з зацікавленими особами
перед установкою брандмауера. Реалістична політика - це така політика, в якій знайдено баланс між захистом мережі від відомих ризиків, але в той же час
забезпечений доступ користувачів до мережевих ресурсів. Якщо система брандмауера забороняє або обмежує використання деяких сервісів, то у політиці
повинна бути явно описана суворість, з якою це робиться, щоб запобігти зміні параметрів засобів управління доступом сьогохвилинним чином. Тільки
підтримувана керівництвом реалістична політика може забезпечити це.
Брандмауер може реалізовувати ряд політик доступу до сервісів, але типова політика може забороняти доступ до мережі з Інтернету, і вирішувати тільки доступ
до Інтернету з мережі. Інший типової політикою може бути дозвіл деякого доступу з Інтернету, але тільки до обраних систем, таким як інформаційні
сервера і поштові сервера. Брандмауери часто реалізують політик доступу до сервісів, які дозволяють користувачам мережі працювати з Інтернету за
деякими обраними хостами, але цей доступ надається, тільки якщо він поєднується з посиленою аутентифікації.
Політика проекту брандмауера
Вона специфічна для конкретного брандмауера. Вона визначає правила, що використовуються для реалізації політики доступу до сервісів. Не можна розробляти
цю політику, не розуміючи такі питання, як можливості та обмеження брандмауера, і загрози і узявімие місця, пов'язані з TCP/IP. Як правило,
реалізується одна з двох базових політик проекту:
дозволити доступ для сервісу, якщо він явно не заборонений
заборонити доступ для сервісу, якщо він явно не дозволений
Брандмауер, який реалізує перший політику, пропускає всі сервіси в мережу за замовчуванням, нслі тільки цей сервіс не був явно вказаний в політиці управління
доступом як заборонений. Брандмауер, який реалізує другий політику, за замовчуванням забороняє всі сервіси, але пропускає ті, котрі зазначені в списку
дозволених сервісів. Друга політика йде класичної моделі доступу, яка використовується в усіх галузях інформаційної безпеки.
Перша політика менш бажана, тому що вона надає більше способів обійти брандмауер, наприклад, користувачі можуть одержати доступ до нових
сервісів, що не забороняються політикою (або навіть не зазначених в політиці), або запустити заборонені сервіси на нестандартних портах TCP/UDP, які не
заборонені політикою. Певні сервіси, такі як X Windows, FTP, ARCHIE і RPC, складно фільтрувати [Chap92], [Ches94], і для них краще підходить брандмауер,
реалізує першу політику. Друга політика суворіше і безпечніше, але її важче реалізувати і вона може вплинути на роботу користувачів в тому відношенні, що
ряд сервісів, такі, як описані вище, можуть виявитися заблокованими або використання їх буде обмежено.
Взаємозв'язок між концептуальною політикою доступу до сервісів і відповідної їй другою частиною описана вище. Цей взаємозв'язок існує через
того, що реалізація політики доступу до сервісів сильно залежить від можливостей і обмежень системи брандмауера, а також уразливих місць, що є в
дозволених інтернетівських сервісах. Наприклад, може виявитися необхідним заборонити сервіси, дозволені політикою доступу до сервісів, якщо вразливі
місця в них не можуть ефективно контролюватися політикою нижнього рівня і, якщо безпеку мережі найважливіше. З іншого боку, організація, яка
сильно залежить від цих сервісів при вирішенні своїх завдань, може прийняти це більш високий ризик і дозволити доступ до цих сервісів. Цей взаємозв'язок приводить
до того, що формулювання обох політик стає ітеративним процесом.
Політика доступу до сервісів - найважливіший компонент з чотирьох, описаних вище. Решта три компоненти використовуються для реалізації політики. (І, як
зазначалося вище, політика доступу до сервісів повинна відображати загальну політику безпеки організації). Ефективність системи брандмауера при захисті мережі
залежить від типу реалізації його, від правильності процедур роботи з ним, і від політики доступу до сервісів.
2.4.2 Посилена аутентифікація
Розділи 1.3,
1.3.1
і 1.3.2
описували інциденти в Інтернеті, що відбулися почасти через уразливості традиційних паролів. Вже багато років користувачам рекомендується вибирати такі
паролі, які було б важко вгадати і не повідомляти їх нікому. Проте, навіть якщо користувач слід цієї поради (а багато хто і цього не роблять), то
той факт, що зловмисники можуть спостерігати за каналами в Інтернеті і перехоплювати що передаються в них паролі, робить традиційні паролі
застарілими.
Розроблено ряд заходів посиленої аутентифікації, таких як смарт-картки, біометричні механізми, і програмні механізми, для захисту від вразливості
звичайних паролів. Хоча вони й відрізняються один від одного, всі вони однакові в тому відношенні, що паролі, що генеруються пристроєм посиленою аутентифікації, не
можуть бути повторно використані атакуючим, який перехоплює трафік з'єднання. Тому що проблема з паролями в Інтернеті є постійною,
брандмауер для з'єднання з Інтернетом, який не має коштів посиленою аутентифікації або не використовує їх, має сенсу.
Ряд найбільш популярних пристроїв посиленою аутентифікації, що використовуються сьогодні, називаються системами з одноразовими паролями. Смарт-карта,
наприклад, генерує відповідь, який хост використовує замість традиційного пароля. Так як смарт-карта працює разом з програмою або обладнанням
на хості, що генеруються відповіді унікальні для кожного встановлення сеансу. Результатом є одноразовий пароль, який, якщо перехоплюється, не
може бути використаний зловмисником для встановлення сеансу з хостом під виглядом користувача. [NIST94a] і [NIST91a] більш детально описують пристрої
посиленою аутентифікації та засоби захисту на їх основі.
Рисунок 2.2 Використання посиленою аутентифікації в брандмауері для попередньої аутентифікації
трафіку TELNET, FTP
Оскільки брандмауери можуть централізувати управління доступом в мережі, вони є логічним місцем для установки програм або пристроїв посиленою
аутентифікації. Хоча заходи посиленої аутентифікації можуть використовуватися на кожному хості, більш практичним є їх розміщення на брандмауері. Малюнок
2.2 показує, що в мережі без брандмауера, що використовує заходи посиленої аутентифікації, неаутентіфіцірованний трафік таких додатків як TELNET або
FTP, може безпосередньо проходити до систем в мережі. Якщо хости не використовують заходів посиленої аутентифікації, зловмисник може спробувати зламати паролі або
перехоплювати мережевий трафік з метою знайти в ньому сеанси, в ході яких передаються паролі. Рисунок 2.2 також має мережа з брандмауером,
використовують посилену аутентифікацію, при якій сеанси TELNET або FTP, що встановлюються з боку Інтернету з системами мережі, повинні проходити
перевірку за допомогою посиленої аутентифікації перед початком роботи. Самі системи мережі можуть продовжувати вимагати статичні паролі перед доступом до себе, але
ці паролі не можна буде використовувати, навіть якщо їх перехопити, тому що заходи посиленої аутентифікації та інші компоненти брандмауера не дозволять
зловмисникові проникнути або обійти брандмауер.
Частини 2.4.4
і 3
містять додаткову інформацію про використання заходів посиленої аутентифікації з брандмауерами. Смотяри [NIST94b] для отримання більш детальної
інформації про використання заходів посиленої аутентифікації на хостах.
2.4.3 Фільтрація пакетів
Фільтрація IP-пакетів зазвичай виконується за допомогою маршрутизатора з фільтрацією пакетів, що здійснює її, коли пакети передаються між
інтерфейсами маршрутизатора. Фільтруючий маршрутизатор звичайно може фільтрувати IP-пакети на основі групи полів з наступних полів пакету:
IP-адреса відправника
IP-адреса одержувача
TCP/UDP-порт відправника
TCP/UDP-порт одержувача
Не всі фільтруючі маршрутизатори зараз фільтрують через TCP/UDP-порту відправника, але багато виробників почали включати таку можливість.
Деякі маршрутизатори перевіряють, з якого мережного інтерфейсу маршрутизатора прийшов пакет, і потім використовують цю інформацію як додатковий критерій
фільтрації. Деякі версії Unix мають можливість фільтрації пакетів, але далеко не всі.
Фільтрація може бути використана різним чином для блокування з'єднань від або до окремих хостів або мереж, і для блокування з'єднань до
різних портів. Організації може знадобитися блокувати з'єднання від специфічних адрес, таких як хости або мережі, які вважаються ворожими
або ненадійними. Або ж організація може захотіти блокувати з'єднання від всіх адрес, зовнішніх по відношенню до організації (з невеликими винятками,
такими як SMTP для отримання пошти).
Додавання фільтрації по портах TCP і UDP до фільтрації по IP-адресами дає більшу гнучкість. Нагадаємо главу 1, в якій говорилося, що сервера, такі
як демон TELNET, пов'язані зазвичай з конкретними портами, такими як порт 23 для TELNET. Якщо брандмауер може блокувати з'єднання TCP або UDP до або від
певних портів, то можна реалізувати політику, при якій певні види сполук можуть бути здійснені тільки з конкретними хостами, але не з
іншими. Наприклад, організація може захотіти блокувати всі вхідні з'єднання для всіх хостів, окрім декількох систем, що входять до складу
брандмауера. Для цих систем можуть бути дозволені тільки певні сервіси, такі як SMTP для однієї системи, і TELNET або FTP для іншої. При фільтрації
по портах TCP і UDP ця політика може бути легко реалізована маршрутизатором з фільтрацією пакетів або хостом з можливістю фільтрації пакетів.
Рисунок 2.3 Приклад фільтрації пакетів для TELNET і SMTP
Для прикладу розглянемо політику, в якій вирішуються тільки певні з'єднання з мережею з адресою 123.4 .*.* З'єднання TELNET дозволяються тільки з
одним хостом, 123.4.5.6, який може бути прикладним TELNET-шлюзом мережі, а SMTP-з'єднання дозволяються тільки з двома хостами, 123.4.5.7 та 123.4.5.8,
які можуть бути двома поштовими шлюзами мережі. NNTP (Network News Transfer Protocol) дозволяється тільки від взаємодіє з мережею сервера новин,
129.6.48.254, і тільки з NNTP-сервером мережі, 123.4.5.9, а протокол NTP (мережевого часу) дозволений для всіх хостів. Всі інші сервіси та пакети блокуються.
Приклад набору правил наведено нижче:
Тип
Адреса відправника
Адреса одержувача
Порт джерела
Порт одержувача
Дія
tcp
*
123.4.5.6
> 1023
23
дозволити
tcp
*
123.4.5.7
> 1023
25
дозволити
tcp
*
123.4.5.8
> 1023
25
дозволити
tcp
129.6.48.254
123.4.5.9
> 1023
119
дозволити
udp
*
123.4 .*.*
> 1023
123
дозволити
*
*
*
*
*
заборонити
Перше правило дозволяє пропускати пакети TCP з Інтернету від будь-якого джерела, які мають порт відправника більше ніж 1023, до адреси 123.4.5.6, якщо
з'єднання встановлюється з портом 23. Порт 23 - це порт, пов'язаний з сервером TELNETa, а всі клієнти TELNETа повинні використовувати непривілейованих
порти більше, ніж 1024. Друге і третє правило працюють аналогічно, крім того, що вирішуються адреси призначення 123.4.5.7 та 123.4.5.8 і порт 25 - SMTP.
Четверте правило пропускає пакети до NNTP-сервера мережі, але тільки від адреси 129.6.48.254 до адреси 123.4.5.9 з портом призначення 119 (129.6.48.254 --
єдиний NNTP-сервер, від якого мережа отримує новини, тому доступ до мережі відносно NNTP обмежений тільки цією системою). П'яте правило дозволяє
трафік NTP, який використовує UDP, а не TCP, від будь-якого джерела до будь-якої системи в мережі. Нарешті, шосте правило блокує всі інші пакети - якщо
цього правила не було б, маршрутизатор міг блокувати, а міг і не блокувати інші тіи пакетів. Це дуже простий приклад фільтрації пакетів. Справжні
правила дозволяють здійснити більш складну фільтрацію і є більш гнучкими.
Які протоколи фільтрувати
Рішення про те, які протоколи або групи портів фільтрувати, залежить від політики мережевого доступу, тобто від того, які системи повинні мати доступ до
Інтернету і які типи доступу дозволені. Описані нижче сервіси потенційно уразливі до атак і зазвичай блокуються на брандмауері при вході в мережу або
вихід з неї [Chap92], [Garf92].
Tftp, порт 69,
спрощений FTP, який використовується для завантаження ОС на бездискових робочих
станціях, термінальних серверах і маршрутизаторах, може також бути
використаний для читання будь-якого файлу в системі при його неправильної
установці.
X Windows, Open Windows ,
порти 6000 +, порт 2000, може використовуватися для перехоплення зображення
вікон X-вікон, а також символів.
RPC , порт 111, служби
виклику віддалених процедур, включаючи NIS і NFS, які можуть використовуватися
для крадіжки системної інформації, включаючи паролі, а також читання та запису
файлів
rlogin, rsh, rexec,
порти 513, 514, 512, служби, які можуть при їх неправильної
конфігурації призвести до несанкціонованого доступу в систему
Ряд інших засобів також зазвичай фільтрується або їх використання дозволяється тільки для тих систем, яким вони дійсно потрібні. У цей список входять:
TELNET , порт 23, часто
дозволяється тільки для окремих систем
FTP , порти 20 і 21,
аналогічно TELNET його використання дозволено лише для окремих систем
SMTP, порт 25, часто
дозволяється тільки для центрального поштового сервера
RIP , порт 520, протокол
передачі інформації про маршрутизації пакетів, може бути фальсифікований
для перенаправлення пакетів
DNS , порт 53
UUCP, порт 540,
UNIX-to-UNIX CoPy, при неправильній конфігурації може бути використаний
для отримання несанкціонованого доступу
NNTP, порт 119, протокол
передачі мережних новин, для доступу і читання мережних новин
Gopher, http , порти 70 і
80,
· Хоча деякі з цих служб, такі як TELNET і FTP, є небезпечними по своїй суті, повне блокування доступу до
іншим може виявитися неприйнятною для багатьох організацій. Проте, не всі системи вимагають доступу до всіх служб. Наприклад, дозвіл доступу по
TELNET і FTP з Інтернету тільки до тих системах, яким потрібен цей вид доступу, може поліпшити безпеку, не завдаючи незручностей користувачам.
Такі служби, як NNTP, на перший погляд не представляють особливої небезпеки, але розв'язання цих служб тільки для тих систем, яким вони потрібні, допоможе створити
більш упорядковану мережеве середовище і зменшить ймовірність їх використання атакуючими через ще невідомих вразливих місць.
Проблеми з маршрутизаторами з фільтрацією пакетів
Маршрутизатори з фільтрацією пакетів мають ряд недоліків, описаних в [Chap92]. Правила фільтрації пакетів складно формулюються і звичайно немає коштів
для тестування їх коректності (крім як ручне тестування). У деяких маршрутизаторів немає коштів протоколювання, тому якщо правила фільтрації
пакетів все-таки дозволять небезпечним пакетам пройти маршрутизатора, такі пакети не зможуть бути виявлені до виявлення проникнення.
Часто потрібно зробити виключення з правил, щоб вирішити певні види доступу, які зазвичай блокуються. Але виключення з правил фільтрації
іноді можуть зробити правила фільтрації такими складними, що вони стануть неконтрольованими. Наприклад, досить просто написати правило для
блокування всіх вхідних з'єднань до порту 23 (серверу TELNETa). Якщо ж робляться виключення, тобто якщо з деякими системами мережі дозволяється мати
прямі з'єднання по TELNET, то має бути додано правило для кожної такої системи. Іноді додавання певних правил може ускладнити всю схему
фільтрації. Як було вже сказано, тестування складного набору правил на їх коректність може виявитися дуже важким.
Деякі маршрутизатори з фільтрацією пакетів не фільтрують по порту TCP/UDP відправника, що може зробити набір правил фільтрації дуже складним і створити
"дірки" у схемі фільтрації. [Chap92] описує подібні проблеми з мережами, в яких були дозволені вхідні та вихідні SMTP-з'єднання.
Згідно з пунктом 1.2.5, TCP-з'єднання мають порт відправника і одержувача порт. Якщо система ініціює SMTP-з'єднання з сервером, портом джерела буде
випадково обраний порт з номером більше 1024, а портом одержувача буде буде порт з номером 25, порт, який слухає сервер SMTP. Сервер повертатиме
пакети з номером порту відправника 25, і номером порту одержувача, рівним випадково вибраному клієнтом номером порту. Якщо в мережі дозволені вхідні та
вихідні SMTP-з'єднання, то маршрутизатор повинен дозволяти з'єднання з портами відправника та одержувача, великими 1023, в обох напрямках. Якщо
маршрутизатор може фільтрувати по порту відправника, він може блокувати всі пакети, що входять в мережу організації, у яких порт одержувача більше 1023, а
порт відправника не дорівнює 25. Якщо він не може фільтрувати пакети по порту відправника, маршрутизатор повинен дозволити з'єднання, які використовують
порти відправника і одержувача більше 1024. Користувачі іноді можуть спеціально запустити сервера на портах, великих 1023, і обходити таким чином
політику фільтрації (тобто зазвичай сервер telnet в системі слухає порт 23, але може бути налаштований так, що буде слухати замість цього порт 9876, і
користувачі в Інтернеті зможуть організувати telnet-сеанс з цим сервером навіть, якщо маршрутизатор блокує з'єднання з портом призначення 23).
Іншою проблемою є те, що ряд служб RPC дуже важко заблокувати через те, що сервера для цих служб слухають порти, випадково обрані в
процесі завантаження системи. Служба, відома під назвою portmapper відображає початкові виклики служб RPC в призначені ним номери служб, але її
еквіваленту не існує для маршрутизатора з фільтрацією пакетів. Так як маршрутизатора не можна повідомити, з яким портом працює служба, не можна
повністю заблокувати ці служби, хіба що заблокувати повністю всі пакети UDP (RPC-служби в-основному використовують UDP). Блокування всіх пакетів
UDP призведе до блокування низки інших корисних служб, таких як DNS. Тому блокування RPC призводить до дилеми.
Маршрутизатори з фільтрацією пакетів з більш ніж двома інтерфейсами іноді не мають можливостей з фільтрації пакетів в залежності від того, з якого
інтерфейсу прийняті пакети, і куди повинні бути спрямовані. Фільтрація вхідних і вихідних пакетів спрощує правила фільтрації пакетів і дозволяє
маршрутизатора легко визначити, який IP-адреса справжній, а який - фальшивий. Маршрутизатори без такої можливості ускладнюють реалізацію стратегій
фільтрації.
Крім того, маршрутизатори з фільтрацією пакетів можуть реалізовувати обидві концептуальні стратегії, описані у пункті 2.4.1.
Набір правил, який менш гнучким, тобто не фільтрує по порту відправника або за типом інтерфейсу (вхідний або вихідний), зменшує можливості
маршрутизатора по втіленню в життя другого і більш сильної політики, за якої забороняються всі сервіси, крім тих, що явно дозволені. Наприклад,
проблематичні служби, такі, як ті, які базуються на RPC, стає ще важче фільтрувати з менш гнучким набором правил; відсутність фільтрації по
порту відправника змушує дозволяти з'єднання з портами, великими 1023. При менш гнучкому наборі правил маршрутизатор має менше можливостей по
реалізації сильної політики, і тому зазвичай використовують перші політику - вирішувати всі кошти, окрім тих, що явно заборонені.
Читачам рекомендується прочитати [Chap92], в якому дано більш детально опис фільтрації пакетів та пов'язаних з нею проблем. Хоча фільтрація пакетів
дуже важлива, потрібно знати існуючі проблеми та шляхи їх вирішення.
2.4.4 Прикладні шлюзи
Щоб захиститися від ряд уразливих місць, пов'язаних з маршрутизаторами з фільтрацією пакетів, в брандмауерах потрібно використовувати прикладні програми для
перенаправлення, та фільтрації сполук з такими службами, як TELNET і FTP. Таке додаток називається проксі-службою, а хост, на якому працює
проксі-служба - прикладним шлюзом. Прикладні шлюзи та маршрутизатори з фільтрацією пакетів можуть бути об'єднані для досягнення більш високої
безпеки і гнучкості, ніж була б досягнуто, якщо б вони використовувалися окремо.
Наприклад, розглянемо мережу, в якій блокуються вхідні з'єднання TELNET і FTP за допомогою маршрутизатора з фільтрацією пакетів. Цей маршрутизатор
дозволяє пропускати пакети TELNET або FTP тільки до однієї машини, прикладному шлюзу TELNET/FTP. Користувач, який хоче з'єднатися зовні з системою в
мережі, повинен спочатку з'єднатися з прикладним шлюзом, а потім вже з потрібним хостом:
спочатку користувач встановлює telnet-з'єднання з прикладним
шлюзом і вводить ім'я внутрішнього хоста
шлюз перевіряє IP-адресу користувача і дозволяє або забороняє
з'єднання у відповідності з тим чи іншим критерієм доступу
може знадобитися аутентифікація користувача (можливо за допомогою
одноразових паролів)
проксі-сервер може створювати telnet-з'єднання між шлюзом та внутрішнім
хостом
проксі-сервер передає дані між цими двома з'єднаннями
прикладної шлюз протоколює з'єднання
Рисунок 2.4 Віртуальні з'єднання, реалізовані за допомогою прикладного шлюзу і проксі-засобів
Цей приклад демонструє кілька переваг використання проксі-служб. По-перше, проксі-служби дозволяють тільки ті служби, для яких є проксі.
Іншими словами, якщо прикладної шлюз містить проксі для FTP та TELNET, то в захищається підмережі будуть дозволені тільки FTP та TELNET, а інші служби будуть
повністю блоковані. Для деяких організацій такий вид безпеки важливий, тому що гарантує, що тільки ті служби, які вважаються безпечними, будуть
пропускатися через брандмауер. Цей підхід також оберігає від можливості розробки нових небезпечних служб без повідомлення адміністраторів
брандмауера.
Іншою перевагою використання проксі-служб є те, що може бути здійснена фільтрація протоколів. Наприклад, деякі брандмауери, можуть
фільтрувати ftp-з'єднання і забороняти використання команди FTP put, що було б корисно для отримання гарантій того, що користувачі не можуть, наприклад,
писати на анонімний FTP-сервер.
Прикладні шлюзи мають ряд серйозних переваг у порівнянні зі звичайним режимом, при якому прикладної трафік пропускається безпосередньо до внутрішніх
хостів. Вони включають в себе:
приховування інформації , при
якому імена внутрішніх систем необов'язково будуть відомі зовнішнім
систем за допомогою DNS, так як прикладної шлюз може бути єдиним
хостом, чиє ім'я має бути відомо зовнішнім системам.
надійна аутентифікація та протоколювання , при якому прикладної трафік може бути
попередньо аутентифікований до того, як він досягне внутрішніх
хостів, і може бути запротокольовано більш ефективно, ніж стандартні
засоби протоколювання хоста.
оптимальне співвідношення між ціною та ефективністю через те, що додаткові програми або
обладнання для аутентифікації або протоколювання потрібно встановлювати
тільки на прикладному шлюзі.
прості правила фільтрації, так як правила на маршрутизаторі з фільтрацією пакетів будуть
менш складними, ніж вони були б, якщо б маршрутизатор сам фільтрував
прикладної трафік і відправляв його великій кількості внутрішніх систем.
Маршрутизатор повинен тільки пропускати прикладної трафік до прикладного
шлюзу і блокувати весь інший трафік.
Недолік прикладного шлюзу полягає в тому, що при використанні клієнт-серверних протоколів, таких як TELNET, потрібно двухшаговая проціди?? ра
для входження всередину або виходу назовні. Деякі прикладні шлюзи вимагають модифікованих клієнтів, що може розглядатися або як недолік, або
як перевагу, в залежності від того, чи роблять модифіковані клієнти більш легким використанням брандмауера. Прикладної шлюз TELNET необов'язково
вимагає модифікованого клієнта TELNET, проте він вимагає іншої логіки дій від користувача: користувач повинен встановити з'єднання (але не
сеанс) з брандмауером, а не безпосередньо встановити сеанс з хостом. Але модифікований клієнт TELNET робить брандмауер прозорим, дозволяючи
користувачеві вказати кінцеву систему (а не брандмауер) в команді TELNET. Брандмауер є як би дорогою до кінцевої системі і тому перехоплює
з'єднання, а потім виконує додаткові кроки, такі як запит одноразового пароля. Користувачу не потрібно в цьому випадку нічого робити, але на
кожній системі повинен бути встановлений модифікований клієнт.
Крім TELNET, звичайно прикладні шлюзи використовуються для FTP і електронної пошти, а також X Windows і ряду інших служб. Деякі прикладні шлюзи FTP
мають можливості блокування команд get і put для деяких хостів. Наприклад, зовнішній користувач, який встановив FTP-сеанс (через прикладної шлюз FTP) з
внутрішньою системою, такий, як анонімний FTP-сервер, може спробувати скопіювати файли на сервер. Прикладної шлюз може фільтрувати FTP-протокол і
блокувати всі команди put для анонімного FTP-сервера; це дозволить гарантувати, що ніхто не зможе завантажити на сервер чого-небудь, і дасть
більші гарантії, ніж проста упевненість в тому, що права доступу до файлів на анонімному FTP-сервер встановлені коректно (деякі організації ввели
політики, в яких забороняються команди get і put для певних директорій; наявність брандмауера, фільтруючого FTP-команди, було б особливо корисно в цій
ситуації. Деякі місця заборонили команди get для зовнішніх хостів, щоб користувачі не могли вважати інформацію або програми із зовнішніх хостів. У
інших же мережах заборонена команда put для зовнішніх хостів, щоб користувачі не могли зберегти локальну інформацію на зовнішніх FTP-серверах. Але типовим
є варіант. Коли забороняються вхідні команди put, щоб зовнішні користувачі не могли писати на FTP-сервера в мережі)
Прикладної шлюз для електронної пошти служить для централізованого збору електронної пошти та розповсюдження її по внутрішнім хостам і користувачам.
Для зовнішніх користувачів всі внутрішні користувачі будуть мати адресу виду користувач @ почтовий_хост,
де поштову хост - ім'я шлюзу для пошти. Шлюз повинен приймати пошту від зовнішніх користувачів, а потім переправляти її на інші внутрішні системи.
Користувачі, що посилають електронні листи з внутрішніх систем, можуть надсилати їх безпосередньо з внутрішніх систем, або, якщо внутрішні імена систем не відомі
зовні мережі, лист має бути надіслано на прикладної шлюз, який потім переправить його до хоста призначення. Деякі поштові шлюзи використовують більше
безпечну версію програми sendmail для прийому пошти.
Шлюзи транспортного рівня
[Ches94]
