Література

1. Гончаров О.Н. Керівництво для вищого управлінського персоналу. М.: МП "Сувенір".

2. Грачов М.,Суперкадри. М.: Річ.

3.С.Теллин.Интранет і адаптивні інновації.JetINFO, # 21/22,JetInfosystems.

4.Steven L.Telleen. Intranet Organization: Strategies for Managing Change. Copyright (з).ip.com/Intranet.Org/

5.Елисеев У. Ладиженський Р. Введення у Интранет. Системи УправлінняБазами Даних, # 5-6/96.

Тема 6. Засоби фільтрації трафіку

Типи фаєрволів

Міжмережевий екран або мережевий екран – комплекс апаратних чи програмних засобів, здійснює контроль і фільтрацію проходять через нього мережевих пакетів відповідно до заданих правил.

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

Деякі мережеві екрани також дозволяють здійснювати трансляцію адрес – динамічну заміну внутрішньомережевих (сірих) адрес або портів на зовнішні, використовувані за межами ЛОМ.

Брандмауер (нім. Brandmauer) – запозичений з німецької мови термін, який є аналогом англійської firewall в його оригінальному значенні (стіна, яка розділяє суміжні будівлі, оберігаючи від поширення пожежі). Цікаво, що в області комп'ютерних технологій в німецькій мові вживається слово «Firewall».

Файрволл, файрвол, фаєрвол, фаєрвол – утворено транскрипцією англійського терміна firewall.

Рисунок 6.1 – Розташування мережевого екрану у мережі

Мережеві екрани поділяються на різні типи залежно від таких характеристик:

• чи забезпечує екран з'єднання між одним вузлом і мережею або між двома або більше різними мережами;

• на рівні яких мережевих протоколів відбувається контроль потоку даних;

• відслідковуються Чи стану активних сполук чи ні.

Залежно від охоплення контрольованих потоків даних мережеві екрани поділяються на:

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

• персональний мережевий екран - програма, встановлена на комп'ютері користувача і призначена для захисту від несанкціонованого доступу тільки цього комп'ютера.

Вироджений випадок – використання традиційного мережевого екрану сервером, для обмеження доступу до власних ресурсів.

Залежно від рівня, на якому відбувається контроль доступу, існує поділ на мережеві екрани, що працюють на:

• мережевому рівні, коли фільтрація відбувається на основі адрес відправника і одержувача пакетів, номерів портів транспортного рівня моделі OSI та статичних правил, заданих адміністратором;

• сеансовом рівні (також відомі як stateful) – відстежують сеанси між додатками, що не пропускають пакети порушують специфікації TCP/IP, часто використовуваних у зловмисних операціях – скануванні ресурсів, зломи через неправильні реалізації TCP/IP, обрив/уповільнення з'єднань, ін'єкція даних.

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

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

Залежно від відстеження активних сполук мережеві екрани бувають:

• stateless (проста фільтрація), які не відслідковують поточні з'єднання (наприклад, TCP), а фільтрують потік даних виключно на основі статичних правил;

• stateful, stateful packet inspection (SPI) (фільтрація з урахуванням контексту), з відстеженням поточних з'єднань і пропуском тільки таких пакетів, які задовольняють логіці і алгоритмам роботи відповідних протоколів і додатків. Такі типи мережевих екранів дозволяють ефективніше боротися з різними видами DoS-атак і уразливими деяких мережевих протоколів. Крім того, вони забезпечують функціонування таких протоколів, як H.323, SIP, FTP і т. п., які використовують складні схеми передачі даних між адресатами, погано піддаються опису статичними правилами, і, найчастіше, несумісних зі стандартними, stateless мережевими екранами.

Типові можливостей:

• фільтрація доступу до свідомо незахищеним службам;

• перешкоджання отриманню закритої інформації з захищеної підмережі, а також впровадженню в захищену підмережа помилкових даних за допомогою вразливих служб;

• контроль доступу до вузлів мережі;

• може реєструвати всі спроби доступу як ззовні, так і з внутрішньої мережі, що дозволяє вести облік використання доступу до Інтернету окремими вузлами мережі;

• регламентування порядку доступу до мережі;

• сповіщення про підозрілу діяльність, спробах зондування або атаки на вузли мережі або сам екран.

Внаслідок захисних обмежень можуть бути заблоковані деякі необхідні користувачеві служби, такі як Telnet, FTP, SMB, NFS, і так далі. Тому настройка файрволу вимагає участі спеціаліста з мережевої безпеки. В іншому випадку шкода від неправильного конфігурування може перевищити користь.

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

Міжмережевий екран сам по собі не панацея від усіх загроз для мережі. Зокрема, він:

• не захищає вузли мережі від проникнення через «люки» (англ. back doors) або уразливості ПЗ;

• не забезпечує захист від багатьох внутрішніх загроз, в першу чергу - витоку даних;

• не захищає від завантаження користувачами шкідливих програм, в тому числі вірусів.

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

Проект «Золотий щит» (англ. The Golden Shield Project) неофіційна назва – «Великий китайський файрвол» (англ. Great Firewall of China – гра слів, похідне від англ. Great Wall of China – Велика китайська стіна) – система фільтрації вмісту Інтернету в КНР. Розробка проекту була розпочата в 1998 році, а в 2003 році він введений в експлуатацію по всій країні. «Щит» являє собою систему серверів на інтернет-каналі між провайдерами та міжнародними мережами передачі інформації, яка фільтрує інформацію.

Ряд західних компаній виконують вимоги китайської влади про обмеження доступу до інформації. За даними організації «Репортери без кордонів», китайська версія пошукової системи Yahoo! в результатах пошуку не показує певну інформацію.

Сайт Вікіпедії також неодноразово блокувався на території КНР. Причина блокування обумовлена, зокрема, описом подій в Китаї травня-червня 1989 року.

Також системою блокуються сайти низки релігійних і філософських течій, зокрема, трансгуманістіческіх.

Багатофункціональні фільтри трафіку в FreeBSD

В операційній системі FreeBSD існує підтримка одразу трьох мережевих фільтрів (див. рисунок 6.2): IPFW, PF, IPFILTER. Кожен з них має свої переваги і недоліки, але найбільш популярним і багатофункціональним є IPFW.

Рисунок 6.2 – Демон на сторожі FreeBSD

IPFW

IPFIREWALL (IPFW) – являє собою міжмережевий екран, написаний і підтримуваний добровільними учасниками проекту FreeBSD. Він використовує stateless правила, тобто правила без урахування стану, і успадкування техніки кодування правил для отримання того, що називається простою логікою із збереженням стану (stateful).

Приклад найпростішого набору правил IPFW (знаходиться в /etc/rc.firewall та /etc/rc.firewall6) у стандартній установці FreeBSD досить простий і не розрахований на безпосереднє використання без змін. У ньому не використовується фільтрація із збереженням стану, яка дає переваги в багатьох конфігураціях, тому він не може бути взятий за основу для цього розділу.

Синтаксис правил IPFW без збереження стану забезпечує розширені можливості фільтрації, які набагато перевершують рівень знань звичайного користувача брандмауера. IPFW розрахований на професійних користувачів або технічно просунутих любителів, які пред'являють підвищені вимоги до фільтрації пакетів. Щоб використовувати можливості IPFW в повну силу, необхідні поглиблені знання того, як у різних протоколах формуються і використовуються заголовки пакетів. Поглиблене вивчення роботи протоколів виходить за рамки цього розділу Керівництва.

IPFW складається з семи компонентів, головний з яких – процесор правил фільтрації рівня ядра і інтегрований в нього механізм обліку пакетів, а також засоби протоколювання пакетів, правило divert, за допомогою яких викликається функція NAT і інші можливості спеціального призначення, засоби для обмеження швидкості (шейпінгу) трафіку (dummynet), кошти перенаправлення fwd, засоби організації мережевого моста bridge і механізм ipstealth. IPFW підтримує протоколи IPv4 та IPv6.

PF

У липні 2003 програмний міжмережевий екран OpenBSD, відомий як PF, була портована в FreeBSD і став доступний з колекції портів FreeBSD; першим релізом, де PF був інтегрований в основну систему, стала FreeBSD 5.3 в листопаді 2004. PF це повноцінний міжмережевий екран з широким набором можливостей, в якому є опціональна підтримка ALTQ (Alternate Queuing). ALTQ надає управління пропускною здатністю Quality of Service (QoS).

Проект OpenBSD здійснює чудову роботу з підтримки PF FAQ. Цей розділ керівництва фокусується на взаємозв'язку PF і FreeBSD, надаючи лише загальну інформацію щодо його використання. За більш детальною інформацією щодо використання PF зверніться до PF FAQ.

IPFILTER

Автором IPFILTER є Darren Reed. IPFILTER не залежить від операційної системи: це додаток з відкритими вихідними текстами, яке було портовано на операційні системи FreeBSD, NetBSD, OpenBSD, SunOS ™, HP/UX, і Solaris ™. IPFILTER активно розробляється і підтримується, регулярно випускаються оновлені версії.

IPFILTER заснований на міжмережевим екрані і механізмі NAT рівня ядра, які управляються і контролюються утилітами рівня користувача процесів. Правила брандмауера можуть встановлюватися або видалятися утилітою ipf. Правила NAT можуть встановлюватися або видалятися утилітою ipnat. Утиліта ipfstat виводить статистику IPFILTER для ядра. Програма ipmon може заносити дії IPFILTER у файли системних протоколів.

IPF був спочатку написаний з використанням правила «останній збіг застосовується» і лише з правилами без збереження стану. З часом IPF був розширений і включає параметри «quick» і «keep state» (збереження стану), які кардинальним чином змінюють логіку обробки пакетів. Офіційна документація IPF включає традиційні параметри правил з традиційною послідовністю обробки пакетів. Змінені функції включені у вигляді додаткових параметрів, вони необхідні для створення ефективного брандмауера.

Інструкції цього розділу увазі використання параметра «quick» і параметра збереження стану «keep state». Це основа для створення включає брандмауера.

Основи налаштування IPFW і PF

IPFW

IPFW включений в базову установку FreeBSD в вигляді окремого довантажувати модуля. Система динамічно завантажує модуль ядра, коли в rc.conf присутній рядок firewall_enable="YES". Якщо використовувати функціональність NAT не планується, то в цьому випадку додатково компілювати IPFW до складу ядра FreeBSD не потрібно.

Після перезавантаження системи з firewall_enable="YES" у rc.conf на екрані в процесі завантаження відобразиться виділене білим повідомлення:

ipfw2 initialized, divert disabled, rule-based forwarding disabled, default to deny, logging disabled

Завантажуваний модуль скомпільований з можливістю протоколювання інформації про трафік. Для включення протоколювання і установки рівня його деталізації є перемикач, значення якого можна встановити в конфігураційному файлі /etc/sysctl.conf. При додаванні наступних двох рядків протоколювання буде включено при наступному завантаженні системи:

net.inet.ip.fw.verbose=1

net.inet.ip.fw.verbose_limit=5

Також фільтр можна вкомпілювати в ядро, в цьому випадку вищенаведена інструкція втратить смисл. Включення наступних параметрів в ядро FreeBSD не є обов'язковим, якщо додатково не потрібно функціональність NAT. Ці параметри представлені тут у якості довідкової інформації для подальших прикладів.

options IPFIREWALL

Цей параметр включає IPFW до складу ядра.

options IPFIREWALL_VERBOSE

Цей параметр включає протоколювання пакетів, які проходять через IPFW за правилами з ключовим словом log.

options IPFIREWALL_VERBOSE_LIMIT=5

Обмеження числа пакетів, що пройшли через syslogd, окремо для кожного правила. Цей параметр має сенс використовувати в недружньому середовищі, коли необхідно відстежувати активність брандмауера. Це закриває можливість атак «відмова в обслуговуванні» через флуд повідомленнями syslog.

options IPFIREWALL_DEFAULT_TO_ACCEPT

Цей параметр включає для IPFW роздільну політику за замовчуванням. Це зручно на перших етапах налаштування IPFW.

options IPDIVERT

Включення функціональності NAT.

Брандмауер буде блокувати всі вхідні і вихідні пакети, якщо відсутній параметр ядра IPFIREWALL_DEFAULT_TO_ACCEPT або правило, явно дозволяюче ці сполуки.

Параметри /etc/rc.conf включення брандмауера:

firewall_enable="YES"

Для вибору одного зі стандартних режимів роботи брандмауера, що надаються FreeBSD, виберіть найбільш підходящий у файлі /etc/rc.firewall і розмістіть так, як зазначено нижче:

firewall_type="open"

Можливі наступні значення для цього параметра:

• open - пропускати весь трафік.

• client - захищати тільки цю машину.

• simple - захищати всю мережу.

• closed - повністю заборонити IP трафік, за винятком loopback інтерфейсу.

• UNKNOWN - відключити завантаження правил брандмауера.

• filename - абсолютний шлях до файлу, який містить правила брандмауера.

Є два варіанти завантаження власних правил у міжмережевий екран ipfw. Перший спосіб - задати змінну firewall_type у вигляді абсолютного шляху файлу, що містить правила брандмауера без будь-яких параметрів командного рядка для самого ipfw. Нижче наведено простий приклад набору правил, який блокує весь вхідний і вихідний трафік:

add deny in

add deny out

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

#!/bin/sh

ipfw -q flush

ipfw add deny in

ipfw add deny out

Примітка: Якщо змінній firewall_type присвоєно значення client або simple, то правила, розташовані за замовчуванням в /etc/rc.firewall, повинні бути приведені у відповідність з конфігурацією даної машини. Також зауважимо, що для використовуваних прикладів, як значення змінної firewall_script використовується /etc/ipfw.rules.

Включення протоколювання:

firewall_logging="YES"

Єдине, що робить параметр firewall_logging – привласнення логічної одиниці змінної sysctl net.inet.ip.fw.verbose. У rc.conf немає змінної для обмеження протоколювання, але це можна зробити через змінну sysctl вручну або використовуючи файл /etc/sysctl.conf:

net.inet.ip.fw.verbose_limit=5

Команда ipfw – це стандартний механізм для ручного додавання/видалення окремих правил в активній ланцюжку правил брандмауера. Основна проблема при використанні цього методу полягає в тому, що при перезавантаженні операційної системи всі зміни, зроблені за допомогою даної команди, будуть втрачені. Замість цього рекомендується записати всі правила в файл, з якого вони будуть зчитуватися під час завантаження операційної системи, а також для повної заміни поточного набору правил на вміст з файлу.

Тим не менш, команду ipfw зручно використовувати для відображення поточної конфігурації правил на екрані консолі. Обліковий модуль IPFW динамічно створює лічильники для кожного правила, які підраховують кількість пакетів, відповідних умовам спрацьовування правила. У процесі тестування відображення правила зі своїм лічильником є одним із способів перевірки, чи спрацьовує правило при проходженні через нього пакету чи ні.

Вивід повного списку правил:

# ipfw list

Вивід повного списку правил з маркером часу останнього спрацьовування правила:

# ipfw -t list

Наступний приклад виводить облікову інформацію, кількість збіглися пакетів і самі правила. Першим стовпцем йде номер правила, за ним слід число збіглися вихідних пакетів, третій стовпець - число відповідних вхідних пакетів, і потім саме правило.

# ipfw -a list

Вивід динамічних правил разом зі статичними:

# ipfw -d list

Відобразити статичні і динамічні правила, в т.ч. з вичерпаним часом дії:

# ipfw -d -e list

Обнуління лічильників:

# ipfw zero

Обнулити лічильники для правила під номером NUM:

# ipfw zero NUM

Набір правил (ruleset) являє собою групу правил IPFW, які дозволяють або забороняють проходження пакета через міжмережевий екран на підставі значень, що містяться в пакеті. Двонаправлений обмін пакетів між машинами є сесією. Набір правил брандмауера аналізує як пакети, що приходять з глобальної мережі, так і відповідні пакети, що виходять із системи. Кожен TCP/IP сервіс (такий як telnet, www, mail, і т.д.) належить певному протоколу і привілейованого (прослуховуються) порту. Пакети, призначені для конкретного сервісу, передаються з непривілейованого (з високим значенням) порту за адресою призначення на вказаний порт сервісу. Всі ці параметри (тобто порти і адреси) можуть бути використані в якості критеріїв фільтрації при створенні правил, які пропускають або блокують сервіси.

Коли пакет влучає у міжмережевий екран, він порівнюється з кожним правилом, починаючи з першого, рухаючись по безлічі правил верху вниз у порядку збільшення номера правил. Коли пакет збігається з критерієм вибору правила, виконується дія, вказане в правилі, і на цьому пошук правил припиняється. Такий метод пошуку відомий як «виграш першого збігу», тобто після спрацьовування правила залишилися не є видимим. Якщо вміст пакету не відповідає жодному з правил, він примусово потрапляє на вбудоване правило, визначене під номером 65535, яке забороняє і відкидає всі пакети без будь-якого відгуку в бік відправника. Пошук триває після правил count, skipto і tee.

Згадані тут інструкції засновані на використанні правил, що містять параметри із збереженням стану keep state, limit, in, out і via. Це основний механізм для кодування набору правил брандмауера закритого типу.

Розглянемо синтаксис команд IPFW.

Кожне нове правило повинне починатися з префікса add для додавання у внутрішню таблицю.

Кожне правило позначено номером у діапазоні 1 .. 65535.

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

allow|accept|pass|permit

Усі ці дії означають одне і те ж – пакети, що збігаються з правилом, можуть покинути обробку правил брандмауера. На цьому пошук припиняється.

check-state

Перевіряє пакет на відповідність динамічної таблиці правил. Якщо збіг знайдено, виконується дія, що міститься в правилі, яке породило дане динамічне правило, інакше виконується перехід до наступного правила. Правило check-state не має критеріїв фільтрації. За відсутності правила check-state в наборі правил перевірка за динамічної таблиці відбувається на першому правилі keep-state або limit.

deny|drop

Обидва слова означають відкидання пакетів, які співпали з правилом. Пошук припиняється.

Ведення журналів.

log або logamount

Коли пакет збігається з правилом, що містить ключове слово log, інформація про цю подію записується в syslogd з поміткою SECURITY. Запис у журнал відбувається тільки в тому випадку, якщо число спрацьовувань для даного правила не перевищує значення параметра logamount. Якщо значення logamount що не оголошено, то обмеження береться з значення змінної sysctl net.inet.ip.fw.verbose_limit. В обох випадках обнулення значення скасовує обмеження. По досягненню встановленого ліміту запис в журнал може бути повторно включена шляхом скидання лічильника спрацьовувань або лічильника пакетів для цього правила; дивіться опис команди ipfw reset log.

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

Умови відбору.

Ключові слова, представлені в цьому розділі, використовуються для опису атрибутів пакета, за якими перевіряється умова спрацьовування того чи іншого правила. Для збіги використовується наступна послідовність атрибутів загального призначення:

udp|tcp|icmp

Також можуть бути використані імена протоколів, описані в /etc/protocols. Вказане значення позначає протокол для збігу. Це є обов'язковою вимогою.

from src to dst

Ключові слова from і to служать для фільтрації по IP адресах. Обов'язково повинні бути зазначені і джерело, і одержувач. any - це спеціальне ключове слово, яке відповідає будь-якому IP адресою. me - це спеціальне ключове слово, яке відповідає будь-якому з IP адрес, сконфигурированних на інтерфейсі вашої системи FreeBSD, і служить для вказівки комп'ютера, на якому працює міжмережевий екран (тобто цей комп'ютер), як показано на прикладах from me to any, from any to me, from 0.0.0.0/0 to any, from any to 0.0.0.0/0, from 0.0.0.0 to any, from any to 0.0.0.0 і from me to 0.0.0.0. IP адреса вказується у вигляді чотирьох чисел, розділених крапками, або додатково з префіксом мережі (нотація CIDR). Це є обов'язковою вимогою. Для спрощення обчислень, пов'язаних з IP адресами, використовуйте порт net-mgmt/ipcalc.

port number

Для протоколів, що працюють з портами (такі як TCP і UDP), обов'язковою вимогою є зазначення номера порту відповідного сервісу. Замість номера порту можна використовувати ім'я сервісу (з /etc/services).

in|out

Відбір відповідно по вхідних та вихідних пакетів. Присутність одного з цих ключовим слів у правилі обов'язково для формування критерію фільтрації.

via IF

Збігається з пакетами, що проходять через вказаний інтерфейс. Ключове слово via включає обов'язкову перевірку на зазначеному інтерфейсі в загальний процес пошуку збігів.

setup

Це обов'язкова ключове слово визначає початок запиту сесії для TCP пакетів.

keep-state

Це обов'язкова ключове слово. При збігу міжмережевий екран створює динамічне правило, яке за замовчуванням буде збігатися з двонаправленим трафіком між відправником та одержувачем для даної пари IP/порт за вказаною протоколом.

limit {src-addr|src-port|dst-addr|dst-port}

Міжмережевий екран дозволить тільки N з'єднань з однаковим набором параметрів, зазначених у правилі. Можна задавати один або декілька адрес і портів відправника і одержувача. В одному і тому ж правилі використання limit і keep-state не допускається. Параметр limit надає таку ж функцію із збереженням станів, що і keep-state, плюс свої власні.

Параметри для правил із збереженням стану.

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

Параметр check-state служить для вказівки місця в наборі правил IPFW, в якому пакет буде переданий на пошук відповідностей динамічним правилами. У разі збігу пакет пропускається, при цьому створюється нове динамічне правило для наступного пакета, що належить даної двосторонньої сесії. В іншому випадку пакет рухається за звичайними правилами, починаючи з наступної позиції.

Динамічні правила уразливі до атаки SYN-пакетами, які можуть породити гігантську кількість динамічних правил. Для запобігання такого роду атак у FreeBSD передбачений ще один параметр - limit. Цей параметр служить для обмеження кількості одночасно встановлених сесій шляхом перевірки полів відправника і одержувача, залежно від параметра limit, з використанням IP адреси пакета для пошуку відкритих динамічних правил, які представляють собою лічильник кількості збігів для даного IP адреси і цього правила. Якщо ця кількість перевищує значення, вказане в параметрі limit, то такий пакет відкидається.

Протоколювання повідомлень брандмауера.

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

Навіть при включеній функції ведення журналу саме по собі воно проводитися не буде. Адміністратор брандмауера визначає, для яких правил буде включена функція ведення журналу, і додає до цих правил log. Зазвичай в журнал пишуться тільки забороняють правила, такі як правила deny для вхідного ICMP ping. Досить часто кінець списку додають дублююче правило виду «ipfw default deny everything» з приставкою log. Це дозволяє відстежувати всі пакети, що не збігаються ні з одним з правил у вашому наборі.

Будьте вкрай обачними при використанні функції ведення журналу, так як це загрожує невідповідним розростанням файлу журналу, аж до повного заповнення їм місця на жорсткому диску. DoS атаки, спрямовані на переповнення вільного простору жорсткого диска, є одними з найстаріших. Крім заповнення жорсткого диска це неприємно ще й тим, що повідомлення журналу пишуться не тільки в syslogd, але також відображаються на екрані системної консолі, і це незабаром починає сильно дратувати.

Шлях до файлу, в який пишуться повідомлення, задається у файлі /etc/syslog.conf. За замовчанням це файл /var/log/security.

Написання скрипта правил.

Найбільш досвідчені користувачі IPFW створюють скрипт, що містить в собі правила, оформлені таким чином, що вони можуть бути виконані як звичайний sh-скрипт. Основна перевага такого підходу в тому, що правила можна повністю замінити на нові без необхідності в перезавантаженні системи для їх активації. Це вкрай зручно на етапі розробки і тестування набору правил, тому що перезавантажувати весь список правил можна як завгодно часто. Крім того, оскільки це скрипт, то тут можна оголосити деякі часто використовувані значення у вигляді змінної, і використовувати її в безлічі правил, як показано в прикладі нижче.

Синтаксис прикладу, наведеного нижче, сумісний з трьома командними оболонками: sh, csh, tcsh. Для використання значення раніше оголошеної змінної ім'я змінної передує символом $. Під час присвоєння ім'я змінної не має префікса $, що привласнюється значення має бути укладена в "подвійні лапки".

Так виглядає файл з правилами, з якого ви можете почати будувати свій скрипт:

#!/bin/sh

ipfw -q -f flush # Скидання всіх правил.

# Установки за замовчуванням

oif="tun0" # наш інтерфейс

odns="192.0.2.11" # IP DNS сервера провайдера

cmd="ipfw -q add" # префікс для створення правил

ks="keep-state" # просто лінь вводити щоразу

$cmd 00500 check-state

$cmd 00502 deny all from any to any frag

$cmd 00501 deny tcp from any to any established

$cmd 00600 allow tcp from any to any 80 out via $oif setup $ks

$cmd 00610 allow tcp from any to $odns 53 out via $oif setup $ks

$cmd 00611 allow udp from any to $odns 53 out via $oif $ks

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

Якби цей скрипт перебував у файлі /etc/ipfw.rules, то правила можна було б оновити наступною командою:

# sh /etc/ipfw.rules

Ім'я та розташування файлу /etc/ipfw.rules можуть бути якими завгодно.

Такий же результат можна отримати, виконавши вручну наступні команди:

# ipfw -q -f flush

# ipfw -q add check-state

# ipfw -q add deny all from any to any frag

# ipfw -q add deny tcp from any to any established

# ipfw -q add allow tcp from any to any 80 out via tun0 setup keep-state

# ipfw -q add allow tcp from any to 192.0.2.11 53 out via tun0 setup keep-state

# ipfw -q add 00611 allow udp from any to 192.0.2.11 53 out via tun0 keep-state

PF

Щоб завантажити PF як модуль ядра, додайте наступний рядок в /etc/rc.conf:

pf_enable="YES"

Далі, виконайте стартовий скрипт:

# /etc/rc.d/pf start

Врахуйте, модуль PF не завантажили, якщо він не зможе знайти конфігураційний файл з набором правил. Типово розміщення файлу з правилами наступне: /etc/pf.conf. Якщо шлях до файлу відрізняється від вищенаведеного, то внесіть в /etc/rc.conf рядок виду:

pf_rules="/path/to/pf.conf"

Файл з прикладами конфігурацій pf.conf знаходиться у /usr/share/examples/pf/.

Модуль PF можна також завантажити вручну:

# kldload pf.ko

Підтримка ведення логів для PF забезпечується модулем pflog.ko, для завантаження якого додайте наступний рядок в /etc/rc.conf:

pflog_enable="YES"

і запустіть на виконання скрипт:

# /etc/rc.d/pflog start

Якщо вам необхідні інші функціональні можливості PF, то доведеться додати підтримку PF в ядро.

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

Приклад параметрів конфігурації ядра для включення PF знаходиться в /usr/src/sys/conf/NOTES і показаний тут:

device pf

device pflog

device pfsync

device pf включає підтримку брандмауера «Packet Filter».

device pflog включає необов'язкове мережеве псевдопристроїв pflog, яке може використовуватися для протоколювання трафіку через bpf. Демон pflogd може використовуватися для збереження протоколюються інформації на диск.

device pfsync включає необов'язкове мережеве псевдопристроїв pfsync, що використовується для відстеження «змін стану».

Доступні параметри rc.conf.

Для активації PF і pflog під час завантаження в rc.conf повинні бути включені наступні змінні:

pf_enable="YES" # Включити PF (завантажити модуль якщо необхідно)

pf_rules="/etc/pf.conf" # визначення правил для pf

pf_flags="" # додаткові прапори для запуску pfctl

pflog_enable="YES" # запустити pflogd (8)

pflog_logfile="/var/log/pflog" # де pflogd повинен зберігати протокол

pflog_flags="" # додаткові прапори для запуску pflogd

Якщо за міжмережевим екраном знаходиться локальна мережа і необхідно передавати пакети для комп'ютерів цієї мережі, або використовувати NAT, увімкніть також наступний параметр:

gateway_enable="YES" # Включити мережевий шлюз

Створення правил фільтрації.

Пакет PF читає конфігурацію з файлу pf.conf (повний шлях: /etc/pf.conf); пакети відкидаються, пропускаються або модифікуються відповідно до правил і визначеннями з цього файлу. У стандартну поставку FreeBSD входять декілька файлів з прикладами конфігурацій, які знаходяться в каталозі /usr/share/examples/pf/. За вичерпним описом правил PF зверніться до PF FAQ.

Робота з PF.

Для управління PF використовуйте утиліту pfctl. Нижче наведено кілька корисних команд (всі можливі команди та опції наведені на сторінці довідника man pfctl):

pfctl -e Включити PF.

pfctl -d Вимкнути PF.

pfctl -F all -f /etc/pf.conf Скинути всі правила (NAT, правила фільтрації, стану з'єднань, таблиці і т.д.) і завантажити нові з файлу /etc/pf.conf.

pfctl -s [rules|nat|state] Відобразити правила фільтрації, правила NAT або таблицю станів сполук.

pfctl -vnf /etc/pf.conf Перевірити /etc/pf.conf на наявність помилок, але самі набори правил не завантажувати.

28.4.6. Включення ALTQ

ALTQ може бути включений тільки шляхом компілювання ядра FreeBSD з відповідними параметрами. ALTQ підтримується не всіма існуючими драйверами мережевих карт. Щоб переглянути список підтримуваних пристроїв у вашому релізі FreeBSD зверніться до сторінки довідника altq.

Наступні параметри включать ALTQ і додадуть додаткову функціональність.

options ALTQ

options ALTQ_CBQ # Class Bases Queuing (CBQ)

options ALTQ_RED # Random Early Detection (RED)

options ALTQ_RIO # RED In/Out

options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC)

options ALTQ_PRIQ # Priority Queuing (PRIQ)

options ALTQ_NOPCC # Required for SMP build

options ALTQ включає підсистему ALTQ.

options ALTQ_CBQ включає Class Based Queuing (CBQ). CBQ дозволяє розподіляти пропускну здатність сполук за класами або чергах для виставлення пріоритетів трафіку на основі правил фільтрації.

options ALTQ_RED включає Random Early Detection (RED). RED використовується для запобігання перевантаження мережі. RED обчислює довжину черги і порівнює її з мінімальним і максимальним значенням довжини черги. Якщо чергу перевищує максимум, все нові пакети будуть відкинуті. У відповідності зі своєю назвою, RED відкидає пакети з різних сполук у довільному порядку.

options ALTQ_RIO включає Random Early Detection In and Out.

options ALTQ_HFSC включає Hierarchical Fair Service Curve Packet Scheduler. Додаткова інформація про HFSC знаходиться за адресою: http://www-2.cs.cmu.edu/~hzhang/HFSC/main.html.

options ALTQ_PRIQ включає Priority Queuing (PRIQ). PRIQ завжди першим пропускає трафік з черги c більш високим пріоритетом.

options ALTQ_NOPCC включає підтримку SMP для ALTQ. Ця опція необхідна для SMP систем.