Бележки относно изготвянето на правила за 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), за съжаление функциите за препращане (НАПРЕД) не се поддържат и не можете да правите без рекомпилация.
Поддръжка за демона 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, който съдържа стандартни набори от правила, групирани в раздели "ОТВОРЕН", "ПРОСТО", „ЗАТВОРЕНО“, „НЕИЗВЕСТНО“, можете също да го адаптирате към вашите нужди (въпреки че това не е нашият метод:-)), например, като добавите секцията „ПРАВИЛА“, тогава този ред ще изглежда така:

Няма какво специално да се каже за редовете с 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 по-нататък, което всъщност ще изглежда така: