Нотатки про складання правил для IPFW
Нотатки про IPFW
Замість передмови: Питання-"У FreeBSD є 3 різних фаєрвалу, який використовувати?"Відповідь -"Правильно насторінений." тексту обговорюється IPFW як найчастіше використовуваний у FreeBSD фаєрвалл.Як використовувати IPFW?Як відомо існує два способи підключення IPFW: 1. Підключення комп'ютерного модуля ядра при завантаженні системи. 2. Компліація IPFW у ядро системи. Почнемо з останнього - компіляція IPFW в ядро, в MAN-ах цей пункт досить докладно освітлений: Зазвичай використовуються наступні опції в конфізі ядра:
- пакети, що проходять, записуються в лог-файл, при використанні опції log в правилах
-обмеження кількості записів у лог-файл за одним правилом, у правилах IPFW значення можна змінити через опцію logamount
- форвардинг пакетів, дуже корисна опція при налаштуванні прозорого проксі на машині, де одночасно працює IPFW та проксі-сервер (наприклад, SQUID або FROX)
- увімкнення функцій керування трафіком (обмеження ширини каналу, імітація затримок і втрат пакетів), і нарешті для правила за умовчанням, яке є у конфізі IPFW у будь-якому випадку під номером 65535, буде
- якщо включено опцію
- якщо відсутня. Після складання та встановлення нового ядра отримуємо IPFW вбудований в ядро системи. Тепер про підключення модулем, тут все простіше та складніше одночасно. Підключення IPFW як модуля ядра, здійснюється однією командою:
- при цьому завантажується модуль ipfw.ko, який у стандартній поставці має підтримку функцій керування трафіком (DUMMYNET), на жаль, функції форвардингу (FORWARD) не підтримуються і без перекомпіляції тут не обійтися. Підтримка демона NATDв IPFW можна отримати завантаживши аналогічною командою модуль ipdivert.ko
IPFW, завантажений таким чином, містить лише одне правило за умовчанням:
Розглянемо тепер як відбувається підключення IPFW у процесі завантаження операційної системи. Маємо досить типові змінні у файлі /etc/rc.conf
Перший рядок фактично дозволяє виконання стартового скрипта /etc/rc.d/ipfw, який, у свою чергу, виконує вже відому команду
- якщо IPFW вантажиться модулем ядра, потім запускає виконання скрипт з правилами IPFW, вказаний у другому рядку. Зауважимо, що рядок
-Потрібно як для завантаження IPFW у вигляді модуля (інакше запускати доведеться вручну), так і для IPFW компилированном в ядро (інакше не виконається скрипт з правилами з другого рядка, хоча IPFW все одно запуститься з одним правилом за умовчанням). У процесі виконання скрипт /etc/rc.d/ipfw встановить значення системної змінної рівною одиниці (TRUE):
Вона вказує системі використовувати чи IPFW взагалі, тому що якщо змінна дорівнює нулю (FALSE), то IPFW використовуватися не буде, незалежно від того чи підвантажуємо ми модулем IPFW або він скомпільований в ядро, принагідно зазначимо наступне: всі змінні, якими можна керувати через sysctl діють IPFW однаково, незалежно від способу підключення IPFW. Продовжимо рядок:
зазначає розташування нашого скрипта з правилами для IPFW, в принципі її може і не бути, але тоді запуститься на виконання скрипт /etc/rc.firewall, в якому є стандартні набори правил, згруповані в секції "OPEN", "SIMPLE" ,"CLOSED","UNKNOWN", можна також пристосувати його під свої потреби (хоча це і не наш метод :-)), наприклад додавши секцію "RULES", тоді цей рядок набуде вигляду:
защодо рядків з NATD сказати особливо нічого, все аналогічно вже розглянутому з тією різницею, що виконується скрипт /etc/rc.d/natd, і якщо IPFW використовується у вигляді модуля ядра -завантажиться модуль ipdivert.ko, потім скрипт виконає команду виду:
і ще, якщо IP інтерфейс на якому крутиться NATD отриманий від DHCP-сервера, скрипт додасть опцію "-dynamic".Примітка 1.Як таки підключати IPFW? Мабуть, рішення таке: якщо FreeBSD використовується з метою навчання, налагодження і т.д. - простіше підключати модулем, а якщо йдеться вже про "бойове" застосування - краще компіляція в ядро.Як IPFW працює?Загальна схема
Зазвичай коли пишуть таке правило - мають на увазі, що дозволено доступ від хостів внутрішньої мережі до будь-якого хосту (при цьому, часто вважають що йдеться тільки про внутрішню мережу :-) ), але є і ще одна сторона медалі, постараюся її показати. З урахуванням вищеописаних зауважень це правило розпишемо в наступний набір правил:
Отримали такий конфіг IPFW, хоча могли обійтися лише одним рядком
Примітка - Фактично правило №1 не потрібне, т.к. його розширили правилами №6, №9, проте залишимо його, оскільки в реальних умовах треба редагувати саме з №6 по №8, та й саме собою правило №1 не найвдаліше рішення щодо широкомовних запитів.Нехай хост внутрішньої мережі (192.168.0.75) запитує пошту з gmail.com (64.233.183.109:995), для нашого роутера зовнішній IP-195.34.32.55. Забудемо про DNS, відразу до справи - якими бачить IPFW пакети, що проходять: Правила №-№ 1-5 не підходять, а ось №6 якраз у точку:
Так пішов запит на внутрішній інтерфейс (fxp0) роутера, з хоста внутрішньої мережі. Операційна система прийняла його та за таблицею маршрутизації відправила на зовнішнійінтерфейс (fxp1), тут цей пакет став вихідним і знову уперся у фаєрвал:
Тут входить у дію NATD (правило №2) він переписує IP в заголовку пакета, становить таблицю де запам'ятовує що він створив з пакетом і благополучно відпускає подорожувати за правилами IPFW далі, що буде виглядати так:
До речі NATD зберіг ще й початковий порт 1499 року, що буває далеко не завжди. Цей пакет дійде до правила №4, благополучно залишить фаєрвал і помандрує до мережі. Тепер розглянемо як йде відповідь сервера: Відповідний пакет входить у фаєрвал зовні через зовнішній інтерфейс fxp1:
Як видно з якого порту запитали на ту відповідь і отримали. Правила №1, №2 він благополучно пройшов, а у правилі №3 його радісно зустрічає NATD, який перевіряє свою таблицю, знаходить запис і переписує заголовок вже на:
за правилом №8 пакет виходить з IPFW і потрапляє в операційну систему, яка маршрутизує пакет на інтерфейс внутрішньої мережі (fxp0), тут пакет знову упреться у фаєрвал але вже, як вихідний з інтерфейсу внутрішньої мережі fxp0.
У логах IPFW можна буде побачити приблизно таке:
Ну і останнє зауваження щодо IPFW-NATD: Що робити, якщо потрібно щось прикрити в інтернеті для хостів внутрішньої мережі? Відповідь досить очевидна: 1. Попереду правил локальної мережі (рядки 2-3) пишемо свої заборони. Ну і навпаки, якщо потрібно все заборонити, дозволивши тільки щось: наприклад HTTP? 2. Наводимо рядки 2-3 до такого виду:
Вважаю, тема зв'язки IPFW-NATD закрита. Продовжимо дослідження, розберемо ще один випадок IPFW-SQUID, що часто використовується. Спочатку без прозорого проксі. Повернемося до першого варіанту конфігу IPFW і розглянемо, що відбувається.Ось і потрібний шматочок лога:
-вхідний пакет від внутрішнього хоста до роутера з працюючим Squid - правило №1, Squid його обробить і сам відправить до мережі.
-Вихідний пакет від SQUID до віддаленого хоста - правило №4
- вхідна відповідь на інтерфейс зовнішньої мережі - правило № 5, Squid знову ж таки його обробив, і відповів хосту локальної мережі
Припустимо хост внутрішньої мережі з IP 192.168.0.100 запитує http://www.yandex.ru, на вході до фаєрвалу маємо:
-пакет доходить до правила №2, яким переправляється на вхід локального проксі-сервера, далі вже знайома картина самостійної обробки проксі-сервером запиту:
- нарешті відповідь хосту, а тут вже цікаво, оскільки проксі-сервер відповів так:
Як бачимо для хоста внутрішньої мережі, всі махінації з проксі-сервером залишилися не помітні.Знову обмовимося: у прикладі розглянуто лише принцип проходження пакета, реальний лог зовсім не такий однозначний.Щоб закінчити тему зв'язки IPFW-SQUD напишемо зразкові правила для IPFW:
Розставимо крапки над i - об'єднаємо два розморені випадки разом, тим самим створимо такий собі скелет конфігу IPFW для припасування під свої вимоги.
Дякую! Ця замітка про складання правил для IPFW внесла необхідний внесок у справу зміцнення розуміння моїм злегка тугим мозком логіки роботи фаєрволла! наступним буду втовкмачувати в себе необхідне розуміння синтаксису написання правил! зокрема директива "virrevpath" ваще на очі жодного разу не траплялася!
www2, 2007-10-24 о 15:14:13
У документації virrevpath описано як verrevpath. А ще є antispoof.
Помилку виправив, antispoof окремий випадок verrevpath про що MAN себе попереджає
сміття за офтоп)) колупаюсь у мануалі по ipfw, і ось що я там бачу))
BASIC PACKET FILTERING This command adds entry which denies all tcp packets from cracker.evil.org до telnet port of wolf.tambov.su from being for- warded by the host:
ipfw add deny tcp from cracker.evil.org towolf.tambov.sutelnet
alcohollica, 2007-10-25 о 1:26:44
не розкрито тему пропуску трафіку з внутрішньої мережі за протоколом ftp :(
а якщо наступні рядки в rc.conf не потрібні для більшої надійності: tcp_extensions="NO" tcp_drop_synfin="YES" icmp_drop_redirect="YES" icmp_log_redirect="YES"
butcher, 2007-10-25 о 8:36:54
Скрізь втрачено символ долара у конструкціях типу
max, 2007-10-25 о 9:01:41
Чи можна поцікавитися? А навіщо вбивати фрагменти IP? add deny ip from any to any frag
1. Друзі мої. Навіть не знаю як звернутися, давайте всі несуттєві зауваження перенесемо у форум там є гілка називається "Нотатки про IPFW, чи це треба?" переконливо прошу всі зауваження складати туди, зобов'язуюсь відповісти. 2. Коментарі прошу залишати з приводу знайдених помилок. 3. У жодному разі не слід розглядати показані правила IPFW як посібник до дії, це лише скелет який вимагає ґрунтовного доопрацювання, причому не позбавлений помилок.
Дід Піхто, 2007-10-26 о 10:31:18
ну ось і гобліни :)
andrej, 2007-11-09 о 18:17:44
Автор на висоті. Стаття все розставила на свої місця, і тепер виникло бажання перебудувати свій ipfw заново. Прямо таки почуття прозріння і ясність думки :). Раніше слова ipfw і ясність думки я не ризикнув би згадувати разом. Дякую! Продовжуйте-відмінний сайт.
Стаття начебтонепогана, але переглядав навскіс. З того, що хотілося б відзначити 1. Починаючи з 6.2-STABLE, якщо не помиляюся, в man ipfw вживання NAT'а дано через ядерний nat, і, відповідно, конфігурування як ipfw nat xxx config. та потребує наявності в ядрі опції LIBALIAS. 2. natd все ж таки не найвдаліше по продуктивності рішення, я рекомендую ng_nat, як досить простий і швидкий спосіб.
adre, 2007-11-19 о 3:43:17
denzill, 2008-06-05 о 13:01:19
denny у кінцевому конфізі треба виправити на deny
denzill, 2008-06-05 о 13:17:21
індіанець, 2008-09-04 о 16:40:25
про пайпи б ще розписати також ціни б не було
Примітка 4. Кожен маршрутизований IP-пакет потрапляє до фаєрвалу як на вході в операційну систему, так і на виході з неї. Треба уточнити, що це діє, якщо машина не в режимі мосту, а в режимі gateway, інакше пакет проходить за правилами один раз.
Сергій, 2008-09-17 о 15:27:39
Наскільки, я зрозумів ipfw, схема проходу пакета така ->+------>
Дякую за статтю. Нічого подібного ніде більше не бачив. Все дуже зрозуміло і зрозуміло. Просто незамінна на початкових етапах!
Дякую і від мене :) Я став краще розуміти теорію.
Temik, 2008-12-29 о 19:30:33
Ща пивка б, 2008-12-30 о 23:17:23
та власне гуру попрацював на славу
-ЦИТУЮ: #Згадаймо про NATD. 2. add divert natd ip з будь-якого з 3. add divert natd ip from any to in via #. ..cut.. . 7. не зовсім ясно, що робить правило №7 якщо всі пакети, які воно має пропустити, вже перенаправлені в НАТ (правило 2).
lubitel, 2009-02-03 в22:21:24
$ flush -f в в ерсії FreeBSD 6.2-RELEASE-p12
при завантаженні системи давало зупинку з питанням і "ви впевнені? (так/ні)"
змінив на $-f flush, запрацювало нормально
ZooBastik, 2009-07-16 о 18:34:40
>> add allow ip from any to 53 in via >> add allow ip from any 53 to in via
Правила ipfw із зазначенням портів можуть застосовуватись лише до протоколів tcp та udp. Якщо вказати їх у такому вигляді система вкаже на помилку використання обмацюкавшись ворожою мовою. Можна переписати на: add allow tcp,udp from any to 53 in via Хоча для запитів DNS наявність tcp сумнівно, по udp вони ходять.
ZooBastik,по порту 53/tcp DNS теж використовується, наприклад для трансферу зон.
erg, 2009-10-22 о 12:56:06
хотілося б таку саму статтю, але по keep-state і check-state
дякую за статтю
У 2017 налаштування ще актуальні?
10 сайтів/CMS. 2009-04-01, atriumVSFTPD + AD & MySQLНалаштування найбезпечнішого сервера FTP - vsftpd. 2009-03-31, DronPeoplenet + C-motech (3G)Опис підключення до мережі Peoplenet за допомогою 3G модему С-motech CCu-650U на FreeBSD