План
Поняття брандмауера
Чому саме брандмауери?
Проблеми, що виникають із-за брандмауерів
Компоненти брандмауера
Можна знайти рішення ряд проблем з безпекою в Інтернеті, або, принаймні, зробити їх менш небезпечними, якщо використовувати існуючі і добре відомі технології та заходи захисту на рівні хостів. Брандмауер може значно підвищити рівень безпеки мережі організації та зберегти в той же час доступ до всіх ресурсів Інтернеті. Ця глава дає огляд брандмауерів, який включає в себе опис того, як вони усувають небезпеку вразливих місць, описаних у розділі 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] описує іншу компоненту брандмауера, яку інші автори іноді включають в категорію прикладних шлюзів. Шлюз транспортного рівня пропускає через себе TCP-з'єднання, але не робить ніякої фільтрації протоколу. Наприклад, описаний вище приклад прикладного шлюзу TELNET може служити прикладом шлюзу транспортного рівня, тому що після встановлення з'єднання між джерелом і призначенням брандмауер просто передає потік даних між цими двома системами. Іншим прикладом шлюзу транспортного рівня може бути шлюз для NNTP, в якому NNTP-сервер з'єднується з брандмауером, а потім - з внутрішньою системою через брандмауер. Тут брандмауер просто передає потік даних.
Список літератури
[Avol94] Frederick Avolio and Marcus Ranum. A Network Perimeter With Secure Internet Access. In Internet Society Symposium on Network and Distributed System Security, pages 109-119. Internet Society, February 2-4 1994.
[Bel89] Steven M. Bellovin. Security Problems in the TCP / IP Protocol Suite. Computer Communications Review, 9 (2) :32-48, April 1989.
[Cerf93] Vinton Cerf. A National Information Infrastructure. Connexions, June 1993.
[CERT94] Computer Emergency Response Team / Coordination Center. CA-94: 01, Ongoing Network Monitoring Attacks. Available from FIRST.ORG, pub/alerts/cert9401.txt, February 1994.
[Chap92] D. Brent Chapman. Network (In) Security Through IP Packet Filtering. In USENIX Security Symposium III Proceedings, pages 63-76. USENIX Association, September 14-16 1992.
[Ches94] William R. Cheswick and Steven M. Bellovin. Firewalls and Internet Security. Addison-Wesley, Reading, MA, 1994.
[CIAC94a] Computer Incident Advisory Capability. Number e-07, unix sendmail vulnerabilities update. Available from FIRST.ORG, file pub/alerts/e-07.txt, January 1994.
[CIAC94b] Computer Incident Advisory Capability. Number e-09, network monitoring attacks. Available from FIRST.ORG, pub/alerts/e-09.txt, February 1994.
[CIAC94c] Computer Incident Advisory Capability. Number e-14, wuarchive ftpd trojan horse. Available from FIRST.ORG, pub/alerts/e-14.txt, February 1994.
[Com91a] Douglas E. Comer. Internetworking with TCP / IP: Principles, Protocols, and Architecture. Prentice-Hall, Englewood Cliffs, NJ, 1991.