• Гідрологія і Гідрометрія
• Господарське право
• Економіка будівництва
• Економіка природокористування
• Економічна теорія
• Земельне право
• Історія України
• Кримінально виконавче право
• Медична радіологія
• Методи аналізу
• Міжнародне приватне право
• Міжнародний маркетинг
• Основи екології
• Предмет Політологія
• Соціальне страхування
• Технічні засоби організації дорожнього руху
• Товарознавство продовольчих товарів

Основи налаштування 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 систем.

Читайте також:

1. A) правові і процесуальні основи судово-медичної експертизи
2. R – розрахунковий опір грунту основи, це такий тиск, при якому глибина зон пластичних деформацій (t) рівна 1/4b.
3. Активне управління інвестиційним портфелем - теоретичні основи.
4. Анатомо-фізіологічні основи статевого розвитку.
5. Біологічні основи мислительної діяльності.
6. Біомеханічні основи шинування при пародонтозі.
7. Біохімічні основи розвитку витривалості
8. Біохімічні основи розвитку силових і швидкісних якостей
9. Валютний ринок, основи його функціонування. Основні види валютних операцій
10. Вивчення основи слова і закінчення
11. Вимоги до гірських порід основи гребель
12. Виникнення права на позов і правові основи його реалізації

Переглядів: 808