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

Между другото, 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, 24.10.2007 г. в 15:14:13

Документацията за virrevpath е описана като verrevpath. И тогава има противопоказание.

Поправена е грешката, antispoof е специален случай на verrevpath, за който MAN всъщност предупреждава

котило за офтопа)) Аз се мушкам в ръководството за ipfw и това виждам там))

ОСНОВНО ФИЛТРИРАНЕ НА ПАКЕТИТЕ
Тази команда добавя запис, който отказва всички tcp пакети от
cracker.evil.org до telnet пристанището на wolf.tambov.su от да бъде за-
пазена от домакина:

ipfw добави отказ от tcp от cracker.evil.org към wolf.tambov.su telnet

alcohollica, 2007-10-25 в 1:26:44

темата за предаване на трафик от вътрешната мрежа чрез протокол ftp не е разкрита:(

Не са ли необходими следните редове в rc.conf за по-голяма надеждност:
tcp_extensions = "НЕ"
tcp_drop_synfin = "ДА"
icmp_drop_redirect = "ДА"
icmp_log_redirect = "ДА"

месар, 25.10.2007 г. в 8:36:54 ч

Символът на долара се губи навсякъде в конструкции като

макс, 25.10.2007 г. в 9:01:41

Може да бъдете любопитни?
Защо да убиваме IP фрагменти?
добавете отричане на ip от който и да е към всеки фрагмент

1. Моите приятели.
Дори не знам как да кандидатствам, нека преместим всички несъществени коментари във форума, има клон, наречен "Бележки за IPFW, необходимо ли е?" Моля ви да добавите всичките си коментари там, ангажирам се да отговоря.
2. Моля, оставете коментари за откритите грешки.
3. В никакъв случай показаните правила на IPFW не трябва да се разглеждат като ръководство за действие, това е само скелет, който изисква задълбочена ревизия и не е лишен от грешки.

Дед Пихто, 26.10.2007 г. в 10:31:18

ами ето гоблините:)

Андрей, 09.11.2007 г. в 18:17:44

Авторът е на върха. Статията постави всичко на мястото си и сега има желание да възстановите вашия ipfw наново. Наистина чувствам проницателност и яснота на мисълта:). По-рано не бих се осмелил да спомена думите ipfw и яснотата на мисълта заедно. Благодаря! Продължете - страхотен сайт .

Изглежда, че статията не е лоша, но я сканирах косо. От това, което бих искал да отбележа
1. Започвайки от 6.2-STABLE, ако не се лъжа, в man ipfw използването на NAT се дава чрез ядрената nat и съответно конфигурацията е като ipfw nat xxx config. и изискване на опцията LIBALIAS в ядрото.
2.natd все още не е най-успешното решение по отношение на производителността, препоръчвам ng_nat, като доста прост и бърз начин.

адре, 19.11.2007 в 3:43:17

denzill, 05.06.2008 г. в 13:01:19

denny във финалната конфигурация трябва да бъде фиксирано да отрича

denzill, 05.06.2008 г. в 13:17:21

Индийски, 2008-09-04 в 16:40:25

Бих искал също да опиша тръбите
нямаше да има цена

Забележка 4.
Всеки маршрутизиран IP пакет влиза в защитната стена както на входа на операционната система, така и на изхода от нея.
Трябва да се изясни, че това работи, ако машината не е в мостов режим, а в шлюзов режим, в противен случай пакетът преминава през правилата веднъж.

Сергей, 17.09.2008 в 15:27:39

Доколкото разбирам ipfw, схемата за преминаване на пакети е следната
-> | + ----- || ->

Благодаря ви много за статията. Никога другаде не съм виждал подобно нещо. Всичко е много разбираемо и разбираемо. Просто незаменим в началните етапи!

Благодаря и от мен:) Започнах да разбирам по-добре теорията.

Темик, 2008-12-29 в 19:30:33

Бирата ще бъде, 30 декември 2008 г. в 23:17:23

да, всъщност гуруто свърши чудесна работа

-ЦИТАТА:
# Нека си спомним за NATD.
2. добавете пренасочване на natd ip от към всеки изход чрез
3.add пренасочване на natd ip от който и да е към през
#.
.разрез.
.
7. добавете позволете ip от до всяко излизане през
--
не е напълно ясно какво прави правило # 7, ако всички пакети, които трябва да предаде, вече са пренасочени към NAT (правило 2).

lubitel, 2009-02-03 в 22:21:24

$ flush -f
във FreeBSD версия 6.2-RELEASE-p12

когато системата се стартира, тя спира с въпрос и "сигурен ли си (да/не)"

променен на $ -f флъш, работи добре

ZooBastik, 2009-07-16 в 18:34:40

>> добавете позволи на ip от който и да е до 53 в чрез
>> добавете позволи на ip от всякакви 53 към през

Правилата, специфични за портовете ipfw, могат да се прилагат само към протоколите tcp и udp. Ако ги посочите в този формуляр, системата ще покаже грешка при използване чрез опаковане на враждебен език. Може да бъде пренаписан на:
добавете allow tcp, udp от който и да е до 53 в чрез
Въпреки че tcp е съмнителен за DNS заявки, те използват udp.

ZooBastik, чрез порт 53/tcp се използва и DNS, например за трансфер на зона.

erg, 22.10.2009 в 12:56:06

Бих искал точно същата статия, но за keep-state и check-state

много благодаря за статията

През 2017 г. настройките все още са актуални?

10 сайта/CMS. 2009-04-01, атриум
VSFTPD + AD && MySQL
Конфигурирането на най-сигурния FTP сървър е vsftpd. 2009-03-31, Дрон
Peoplenet + C-motech (3G)
Описание на свързване към мрежата Peoplenet чрез 3G модем C-motech CCu-650U на FreeBSD