forum.opennet.ru - "IPFW порядок составления, прохождения правил с NAT. Пинги." (14)

"IPFW порядок составления, прохождения правил с NAT. Пинги."

Форум Информационная безопасность (BSD ipfw, ipf, ip-filter / FreeBSD)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"IPFW порядок составления, прохождения правил с NAT. Пинги."	+/–
Сообщение от Evonder (ok) on 02-Май-18, 11:47
Добрый день.Начинаю изучать FreeBSD. Пытаюсь разобраться с принципами работы NAT, изучал схему прохождения пакета по стеку ipfw, если для самой машины все более менее ясно, то вот то, как работают правила для NAT я никак понять не могу. Вводные данные: ------------------ rc.conf ifconfig_re0="inet 192.168.30.254 netmask 255.255.255.0" #Локальная сеть ifconfig_re1="DHCP" #Интернет от провайдера работает только при получении настроек по DHCP" #Интернет firewall_enable="YES" firewall_script="/etc/rules.fw" firewall_nat_enable="YES" gateway_enable="YES" ----------------- /etc/sysctl.conf net.inet.ip.fw.one_pass=1 ----------------- rules.fw fwcmd="ipfw -q add" ipfw -q -f flush $fwcmd 00001 allow all from any to any via re0 ipfw nat 1 config log if re1 reset same_ports deny_in $fwcmd 00100 nat 1 ip from any to any via re1 ----------------------------------------------------------- предположим я хочу пропинговать сервер гугла 8.8.8.8 c хоста из внутренней подсети. Пакет с машины поступает на интерфейс re0 и получает тег in и reciv re0, после чего попадает в подсистему ipfw на вход в IN где пакет пробегает по правилам, проходит ее согласно правилу 00001 (пакет имеет тег reciv re0) после чего попадает в функцию Forward где происходят некие действия и после этого пакет направляется на выход OUT ipfw, где пакету теряет тег IN, получает OUT и тег xmit re1 после чего направляется по правилам IPFW. Пройдя по правилам и дойдя до 00100 пакет будет перенаправлен в модуль NAT где с ним совершатся необходимые действия и он снова вернется в out ipfw, где из-за опции net.inet.ip.fw.one_pass=1 он будет пропущен на "выход" без прохождения цепочки выходных правил. Это я так понимаю процесс прохождения пакета по IPFW если где-то не ошибся. А теперь вопросы по тому, что именно мне не понятно. Если я хочу сделать правило пинг для самого гейта, то 2 правила вида: $fwcmd 00001 pass udp from me to any 53 out via re1 $fwcmd 00001 pass udp from any 53 to me icmptype 0 in via re1 Дают мне необходимый результат, насколько я понимаю, данные правила должны располагаться выше по порядку чем правило NAT, и тогда пакеты не будут заруливаться на нат. Но как быть с правилами пинг с внутреннего хоста на внешний? Насколько я понимаю, все правила отрабатывают до попадания пакета в в функцию NAT, поскольку после преобразования пакета с подменой адреса источника пакет из-за параметра net.inet.ip.fw.one_pass=1 проходит цепочку out ipfw "насквозь" словно pass all. Как тогда должно выглядеть правило для ping с внутренних узлов на внешку? Дописать такое правило: $fwcmd 00002 allow icmp from 192.168.30.10 to any out via re1 setup keep-state И еще один момент, подскажите по правилу прохождения цепочки правил IPFW, продолжается ли прохождение в случае: 1) для пакета найдено блокирующее правило 2) для пакета найдено разрешающее правило Извините за сумбур, пытаюсь все переварить. Большое спасибо всем, кто откликнется. Попробовал прописать вот это правило: $fwcmd 00002 allow icmp from 192.168.30.10 to any out via re1 setup keep-state Смотрю внешний интерфейс tcpdump -ni re1 icmp и идут вот такие ответы: 10:57:04.752135 IP 192.168.30.10 > 8.8.8.8: ICMP echo request, id 1, seq 568, length 40 Непонятно почему ip внутренний, а не самого шлюза, т.е. нат получается не работает, и ответы не приходят.
Ответить \| Правка \| Cообщить модератору

Оглавление

IPFW порядок составления, прохождения правил с NAT. Пинги., universite, 20:15 , 02-Май-18, (1)
IPFW порядок составления, прохождения правил с NAT. Пинги., Тыгра, 22:11 , 03-Май-18, (2)

IPFW порядок составления, прохождения правил с NAT. Пинги., Evonder, 16:04 , 04-Май-18, (3)
IPFW порядок составления, прохождения правил с NAT. Пинги., Evonder, 18:40 , 04-Май-18, (4)

IPFW порядок составления, прохождения правил с NAT. Пинги., Тыгра, 01:09 , 05-Май-18, (5)

IPFW порядок составления, прохождения правил с NAT. Пинги., Evonder, 08:18 , 05-Май-18, (6)

IPFW порядок составления, прохождения правил с NAT. Пинги., Evonder, 12:46 , 05-Май-18, (7)

IPFW порядок составления, прохождения правил с NAT. Пинги., Evonder, 22:41 , 05-Май-18, (8)
IPFW порядок составления, прохождения правил с NAT. Пинги., михалыч, 15:24 , 06-Май-18, (9)

IPFW порядок составления, прохождения правил с NAT. Пинги., Evonder, 17:27 , 06-Май-18, (10)

IPFW порядок составления, прохождения правил с NAT. Пинги., михалыч, 19:14 , 07-Май-18, (11)

IPFW порядок составления, прохождения правил с NAT. Пинги., михалыч, 19:15 , 07-Май-18, (12)
IPFW порядок составления, прохождения правил с NAT. Пинги., Evonder, 22:22 , 07-Май-18, (13)

IPFW порядок составления, прохождения правил с NAT. Пинги., Тыгра, 01:22 , 08-Май-18, (14)

Сообщения по теме [Сортировка по времени | RSS]

1. "IPFW порядок составления, прохождения правил с NAT. Пинги." +/–

Сообщение от universite (ok) on 02-Май-18, 20:15

> $fwcmd 00001 allow all from any to any via re0
> ipfw nat 1 config log if re1 reset same_ports deny_in
> $fwcmd 00100  nat 1 ip from any to any via re1
100-е правило разделите на два.

00100 nat 1 ip from 192.168.30.0/24 to not 192.168.30.0/24 out via re1
00101 nat 1 ip from any to me in via re1
Для прохождения пинга этих правил достаточно.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "IPFW порядок составления, прохождения правил с NAT. Пинги." +/–

Сообщение от Тыгра on 03-Май-18, 22:11

>Извините за сумбур, пытаюсь все переварить.
Сумбур, ага, есть немного.
>И еще один момент, подскажите по правилу прохождения цепочки правил IPFW, продолжается ли >прохождение в случае:
>1) для пакета найдено блокирующее правило
>2) для пакета найдено разрешающее правило
Ээээ, вот откуда могла возникнуть мысль, что с пакетом после этого ещё что то нужно делать?
Конечно, обработка на командах allow, deny(drop), unreach, fwd завершается. nat, netgraph, ngtee - в зависимости от one_pass. skipto, call, count - всегда продолжается. reass - продолжается, если пакет не фрагментирован, иначе откладывает пакет до поступления всех частей, когда придут - собирает его в кучу и продолжается
man ipfw вроде бы об этом хорошо говорит.
>$fwcmd 00002 allow icmp from 192.168.30.10 to any out via re1 setup keep-state
1. icmp и setup? серьёэно?
2. allow = "всё, пропуск верный, беги по коридору". До NAT-а этот пакет не дойдёт, уйдёт в канал. Потому tcpdump и показывает такое - правило с NAT обойдено.
3. keep-state коварен. Избегайте, если структура правил не проектировалась для его использования. А в данном случае - вообще не нужен.
Ещё мелочи - via и указанное направление out - бессмысленная трата тактов, ибо внутри ipfw "via re1" = "(out xmit re1) or (in recv re1)"
также from any to me - красиво, понятно, но это me - долго, так как перебирает все интерфейсы и их адреса. Как концепция - самое то. Но потом - выпиливать в угоду скорости.
А в чём сакральный смысл one_pass=1 ?
Как раз без него, ИМХО, лучше.
Да, добавится ещё правило, типа
$fwcmd 00110 allow ip from any to any via re1
А вообще рекомендую сразу разделять потоки на группы правил, например:

#!/bin/sh
lan='re0'
inet='re1'
ipfw nat 1 config log if $inet reset same_ports deny_in
$fwcmd 10 reass all from any to any //
# separate IN and OUT
$fwcmd 100 skipto 1000 all from any to any in
$fwcmd 110 skipto 2000 all from any to any out
# IN. Seperate interfaces
$fwcmd 1000 skipto 3000 all from any to any recv $inet
$fwcmd 1010 skipto 4000 all from any to any recv $lan
$fwcmd 1997 allow all from any to any recv lo
$fwcmd 1998 deny all fron any to 127.0.0.0/8 // protection
$fwcmd 1999 deny all from any to any
# OUT.  Seperate interfaces
$fwcmd 2000 skipto 5000 all from any to any xmit $inet
$fwcmd 2010 skipto 6000 all from any to any xmit $lan
$fwcmd 2997 allow all from any to any xmit lo
$fwcmd 2998 allow all from 127.0.0.0/8 to any // protection
$fwcmd 2999 deny all from any to any
# inet in
# icmp for router
# filter some of them
$fwcmd 3000 deny icmp from any to me icmptypes 5 // strange
$fwcmd 3001 deny log icmp from any to me icmptypes 9,10,13,15,17 // danger
$fwcmd 3002 allow icmp from any to me icmptypes 8 // usual in ping, NO NAT
$fwcmd 3100 nat 1 all from any to any // inet in
# place for filters to me
$fwcmd 3110 allow tcp from any to me dst-port 80 // my web, also setup NAT rule
$fwcmd 3130 deny tcp from any to me dst-port 1-1023
$fwcmd 3140 deny udp from any to me dst-port 1-1023
$fwcmd 3500 allow all from any to me // inet in to this gate
# place for filters to LAN clients
$fwcmd 3999 allow all from any to any // inet in transit
# lan in
$fwcmd 4000 allow all from any to any // lan in
# inet out
$fwcmd 5000 nat 1 all from any to any // inet out
$fwcmd 5010 allow all from any to any // inet out
$ lan out
$fwcmd 6000 allow all from any to any // lan out

Это пример без keep-state. Этот keep-state в такой структуре можно применять очень ограниченно.
Если нужно тотально, то структура правил должна быть совсем другой.
Вопрос на понимание - какое правило 100 или 110 лишнее, но с ним нагляднее?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "IPFW порядок составления, прохождения правил с NAT. Пинги." +/–

Сообщение от Evonder (ok) on 04-Май-18, 16:04

  Большое Вам спасибо! Буду разбираться!

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "IPFW порядок составления, прохождения правил с NAT. Пинги." +/–

Сообщение от Evonder (ok) on 04-Май-18, 18:40

>[оверквотинг удален]
> $fwcmd 5000 nat 1 all from any to any // inet out
> $fwcmd 5010 allow all from any to any // inet out
> $ lan out
> $fwcmd 6000 allow all from any to any // lan out
>
> Это пример без keep-state. Этот keep-state в такой структуре можно применять очень
> ограниченно.
> Если нужно тотально, то структура правил должна быть совсем другой.
> Вопрос на понимание - какое правило 100 или 110 лишнее, но с
> ним нагляднее?
По поводу keep-state, вот взять например правило для DNS
fwcmd 00300 allow  udp  from me  to X.X.X.X 53 out via re1 keep-state  #ДНС ЗАПРОС К СЕРВЕРУ ПРОВАЙДЕРА
  В чем тут опасность создания динамического правила? Отправил запрос к днс, и на основе его автоматом создалось разрешающее правило для входящего ответа, а если не использовал бы, тогда пришлось бы дописывать вторую строчку с разрешением для входящего ответа.
   $fwcmd 00110 allow ip from any to any via re1
   Не могу понять смысла этого правила, ведь оно по сути разрешает все на отправку и вход по внешнему интерфейсу.
----------------
По поводу правил 100 и 110
  Могу ошибаться, но "лишнее" тут 100, поскольку оно разрешает весь входящий поток по всем интерфейсам и всего лишь делает skipto на дальнейшие правила которые разбивают поток по интерфейсам лан и инет.
  Вот если убрать правило 110, то весь исходящий траф будет порезан правилом 1999, который для правила 1000 режет все пакеты которые не имели тега recv для интерфейсов инет и лан.



Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

5. "IPFW порядок составления, прохождения правил с NAT. Пинги." +/–

Сообщение от Тыгра on 05-Май-18, 01:09

>[оверквотинг удален]
>  fwcmd 00300 allow  udp  from me  to X.X.X.X
> 53 out via re1 keep-state  #ДНС ЗАПРОС К СЕРВЕРУ ПРОВАЙДЕРА
>   В чем тут опасность создания динамического правила? Отправил запрос к
> днс, и на основе его автоматом создалось разрешающее правило для входящего
> ответа, а если не использовал бы, тогда пришлось бы дописывать вторую
> строчку с разрешением для входящего ответа.
>    $fwcmd 00110 allow ip from any to any via
> re1
>    Не могу понять смысла этого правила, ведь оно по
> сути разрешает все на отправку и вход по внешнему интерфейсу.
Опасность динамики в том, что нужно тщательнее учитывать порядок прохождения пакетов в правилах. Как говорит ман, keep-state (и все правила с limit) одновременно является и check-state, в сложных конфигурациях (с несколькими интерфейсами или правилами, создаваемыми скриптами) можно огрести по полной, когда пакет, для которого есть динамическое правило, проверяется не там, и не отрабатывает какой-то нужный запрет или (что чаще) NAT.
Но динамика очень хороша, когда NAT не нужен или не используется deny_in. И очень нужна при внедрении IPv6 (так как там NAT почти не нужен, а фаерволить всё равно нужно).
Когда есть NAT с его deny_in, он делает всю работу по отбрасыванию ненужных входящих, действуя по правилу "всех выпускать, впускать только уже вышедших". Если deny_in нет, динамические правила предпочтительны, вы правы.
> ----------------
> По поводу правил 100 и 110
>   Могу ошибаться, но "лишнее" тут 100, поскольку оно разрешает весь
> входящий поток по всем интерфейсам и всего лишь делает skipto на
> дальнейшие правила которые разбивают поток по интерфейсам лан и инет.
>   Вот если убрать правило 110, то весь исходящий траф будет
> порезан правилом 1999, который для правила 1000 режет все пакеты которые
> не имели тега recv для интерфейсов инет и лан.
Да, верно, но только потому, что нет других правил между 110 и 1000. Если бы были - о то оба нужны.
Напоминание по поводу NAT: для маршрутизатора в NAT нужно заворачивать весь трафик - входящий, понятно, и так весь, но ошибочно делают NAT только исходящего трафика других компов, а исходящий самого шлюза не делают, и потом удивляются разным глюкам.
ipfw - это как ассемблер, too easy to shoot the leg.

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "IPFW порядок составления, прохождения правил с NAT. Пинги." +/–

Сообщение от Evonder (ok) on 05-Май-18, 08:18

>[оверквотинг удален]
>>   Вот если убрать правило 110, то весь исходящий траф будет
>> порезан правилом 1999, который для правила 1000 режет все пакеты которые
>> не имели тега recv для интерфейсов инет и лан.
> Да, верно, но только потому, что нет других правил между 110 и
> 1000. Если бы были - о то оба нужны.
> Напоминание по поводу NAT: для маршрутизатора в NAT нужно заворачивать весь трафик
> - входящий, понятно, и так весь, но ошибочно делают NAT только
> исходящего трафика других компов, а исходящий самого шлюза не делают, и
> потом удивляются разным глюкам.
> ipfw - это как ассемблер, too easy to shoot the leg.
  А можно мне пояснить немного один момент. В русских мануалах по ipfw где разбирают схему прохождения пакета структура такая, что пакет дойдя до правила заворачивания в nat и пройдя процедуру маскирования (например для исходящих) вновь возвращается в скажем так в функцию ip_out и снова пробегает по цепочке правил для исходящих пакетов. Но опция
# lan in
$fwcmd 4000 allow all from any to any // lan in
# inet out
$fwcmd 5000 nat 1 all from any to any // inet out
$fwcmd 5010 allow all from any to any // inet out
$ lan out
$fwcmd 6000 allow all from any to any // lan out
   Правильно ли я понимаю, что  правило 4000 на которое сбрасывает keepto с правила 1010 отфильтровавшее весь вошедший локальный трафик его же и полностью разрешает, после чего весь этот трафик заворачивает в нат правилом 5000, после использования которого снова проходит по всей цепочке ipfw для out, но благодаря опции one_pass он эту цепочку минует и сразу попадает на выход.  Вот не могу понять, если опция не выставлена, что помешает пакету при повторном прохождении цепочки снова не попасть в правило которое заворачивает исходящие пакеты в NAT, и не получить петлю.
    Правило 5010 разрешает весь маскированный трафик на выход. И вот тут насколько я понимаю и появляется смысл отсутствия keep-state. По сути мы выпускаем на out все, без какой либо фильтрации, но благодаря отсутствию keep-state, все равно весь входящий трафик мы режем на правилах ин, и даже если скажем кто-то из юзеров попытается сделать что-то не хорошее, то в плане исх трафика он сможет отправить любой запрос, но вот ответ от нежелательных источников будет порезан на входе, и получится что-то типа черной дыры, он вроде кричит, а ответа не приходит. А если бы я использовал Keep-state для исходящих правил, и где-то ошибся, то выпустив по правило все разрешено, я по сути мог бы получить "дыру", пользователь сделал какое-то не хорошее дейсвие, о котором я мог не подумать, и это действие подпало бы под keep-state и не подверглось бы фильтрации на входящих.
    --------------
upd
   Правильно ли я понимаю, что по логике, в вышеприведенном листинге правил фильтрация по сути осуществляется на входе?
  Просто в вин я привык что прописываем умолчальное правило deny all from all to all и уже пляшут от него, разрешено то, что явно разрешено, все остальное запрещено. А согласно листингу свыше, мы разрешаем исходящее вообще все, но получить ответ можно лишь по избранному. Несколько не привычный метод фильтрации для меня.

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

7. "IPFW порядок составления, прохождения правил с NAT. Пинги." +/–

Сообщение от Evonder (ok) on 05-Май-18, 12:46

И еще, можно пояснить по правилам 3000.
Насколько я понимаю 3000 и 3001 запрещают системе отвечать на icmp запросы по подозрительным пингам, разхрешая только простое эхо, и только затем все остальные пакеты заруливаются на входящий нат и идут по правилам IPFW.  Видел примеры, где все IN пакеты по внешнему интерфейсу (кроме стандартных запрещающих правил для подсетей) заруливаются на нат первым же правилом. Насколько это принципиально и безопасно?
Получается, что есть фильтрация входящих до nat и после nat.
   Правила 3010-40 запрещают вход на служебные порты роутера, разрешая только доступ на веб сервер на роутере, и после этих правил по сути все разрешено на роутер на вход.
$fwcmd 3999 allow all from any to any // inet in transit
  Это правило разрешает весь трафик с инета в локалку после прохождения nat.
а эти правила разрешают свободный выход в сеть.
$fwcmd 5000 nat 1 all from any to any // inet out
$fwcmd 5010 allow all from any to any // inet out
Получается что клиент сети, может иниициировать любое соединение с внешним узлом, и фльтрация будет осуществляться лишь на входящих соединениях.
  Поскольку в вин системах в основном используют как раньше и говорил запрещено все и вся,то тут как я вижу в основном используется разрешено все и вся, и лишь фильтрами убирается запрещенное. Какой подход более правильнй?

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

8. "IPFW порядок составления, прохождения правил с NAT. Пинги." +/–

Сообщение от Evonder (ok) on 05-Май-18, 22:41

  Попробовал прописать эту схему в лист IPFW, делаю на внутреннем хосте резолв имени, мониторю на внешнем интерфейсе, вижу что пакет из сети попал в нат, прошел с внутреннего на внешний интерфейс, запрос отправился, система получила ответ, но ответ на внутренний интерфейс уже не попал, остался на внешнем, почему так произошло?

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

9. "IPFW порядок составления, прохождения правил с NAT. Пинги." +/–

Сообщение от михалыч (ok) on 06-Май-18, 15:24

> тут как я вижу в основном используется разрешено все и вся,
> и лишь фильтрами убирается запрещенное.
> Какой подход более правильнй?
почитайте про открытый и закрытый тип брандмауэра,
уверяю вас, будет весьма интересно и весьма познавательно
http://www.g0l.ru/blog/htmls/BSDA-course/apes01.html

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

10. "IPFW порядок составления, прохождения правил с NAT. Пинги." +/–

Сообщение от Evonder (ok) on 06-Май-18, 17:27

>> тут как я вижу в основном используется разрешено все и вся,
>> и лишь фильтрами убирается запрещенное.
>> Какой подход более правильнй?
> почитайте про открытый и закрытый тип брандмауэра,
> уверяю вас, будет весьма интересно и весьма познавательно
> http://www.g0l.ru/blog/htmls/BSDA-course/apes01.html
  Я уже разобрался), мне было важно Понять саму схему расстановки правил и заруливания пакетов в nat.

   базово выбрал для себя такую схему
   первыми идут правила pass from any to any на lo0 и Lan
потом
1) заворачиваю в нат все входящие пакеты с in recv $inet
2) разрешающие правила на выход вида
   add 10 skipto 1000 udp from x.x.x.x to x.x.x.x 53 xmit $inet
3) Блокирующее правило для всего прочего трафика
   add 20 deny all from any to any
4) заворачиваю в нат все исходящие пакеты
   add 1000 nat 1 all from any to any OUT
  Вот такая схема мне очень понятна.
   Только один момент остался немного не ясен, опция one-pass
  Если она выключена, то пакет после маскирования в нат снова попадает на цепочку ipfw и каким образом при
повторном прохождении этой цепочки он снова не попадает в правило что все заруливается в nat, а если не попадает, то какое правило после нат выпускает наружу его.  Вот в моей цепочке правида pass all from any to any нет в конце, между тем все рабоает очень корректно, по умолчанию сам ipfw правилом 65355 ставит all deny. Как же после нат пакет попадает во внешку?

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

11. "IPFW порядок составления, прохождения правил с NAT. Пинги." +/–

Сообщение от михалыч (ok) on 07-Май-18, 19:14

>[оверквотинг удален]
>   Вот такая схема мне очень понятна.
>    Только один момент остался немного не ясен, опция one-pass
>   Если она выключена, то пакет после маскирования в нат снова
> попадает на цепочку ipfw и каким образом при
> повторном прохождении этой цепочки он снова не попадает в правило что все
> заруливается в nat, а если не попадает, то какое правило после
> нат выпускает наружу его.  Вот в моей цепочке правида pass
> all from any to any нет в конце, между тем все
> рабоает очень корректно, по умолчанию сам ipfw правилом 65355 ставит all
> deny. Как же после нат пакет попадает во внешку?
все велосипеды давным-давно изобретены, как впрочем и само колесо
но практически каждый начинающий "гонщик" начинает со своего "самоката" )))
ну в смысле - есть готовые несложные примеры ipfw правил
самые типичные и распространённые смотрим в /etc/rc.firewall

Определите тип брандмауэра в /etc/rc.conf. Допустимые значения:
open - открытый, разрешает входящий трафик любому хосту
client - клиент, будет защищать именно эту машину
simple - простой, будет защищать всю сеть
closed - закрытый, полностью отключает IP-сервисы, кроме интерфейса lo0
workstation - защищает только эту машину с помощью учёта состояния соединений. Смотрите ниже используемые переменные для rc.conf
UNKNOWN - неизвестный, полностью отключает загрузку правил брандмауэра
filename - загружает правила из указанного файла (требуется полный путь)
Для "клиент" и "простой" примеры ниже должны быть настроены соответствующим образом.
разумеется, если у вас не тривиальный случай, не типичный, а "атипичный )))"
вам это не подойдёт, но как за основу вполне
по поводу one_pass
опять же обратимся к первоисточнику
info ipfw | grep -A4 "net.inet.ip.fw.one_pass: 1"
"если установлено ... после выполнения действия, пакет повторно возвращается в брандмауэр
и обрабатывается последующим правилом"

такие дела

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

12. "IPFW порядок составления, прохождения правил с NAT. Пинги." +/–

Сообщение от михалыч (ok) on 07-Май-18, 19:15

fix

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

13. "IPFW порядок составления, прохождения правил с NAT. Пинги." +/–

Сообщение от Evonder (ok) on 07-Май-18, 22:22

>[оверквотинг удален]
> Для "клиент" и "простой" примеры ниже должны быть настроены соответствующим образом.
>
> разумеется, если у вас не тривиальный случай, не типичный, а "атипичный )))"
> вам это не подойдёт, но как за основу вполне
> по поводу one_pass
> опять же обратимся к первоисточнику
> info ipfw | grep -A4 "net.inet.ip.fw.one_pass: 1"
>
"если установлено ... после выполнения действия, пакет повторно возвращается в брандмауэр
> и обрабатывается последующим правилом"

> такие дела
     Да нет, у меня все типично, не типичны после винд шлюзов логика работы шлюзов на базе ipfw.
Например мне не привычно, что в большинстве примеров весь исходящий трафик по умолчанию открыт, я хотел
запретить все исход кроме исключений. Решить эту задачу помогает функция skipto которая позволяет "перепрыгнуть" разрешенным правилам через deny all from any to any. В виндовых шлюзах такой логики работы никогда не встречал, поэтому очень для меня не привычно. Опять таки заруливание в нат всего входящего трафика отдельным правилом, правило deny_in в свойствах нат, которое отрубает все входящие пакеты не имеющие записей в динамических таблицах. По поводу:
"если установлено ... после выполнения действия, пакет повторно возвращается в брандмауэр
и обрабатывается последующим правилом"
   Изучать ipfw начал по мануалам с лисяры форума бсд, там не было такой конкретизации, там было однозначно сказано, что при отключенной функции one_pass после прохождения NAT пакет снова возвращается в функцию (например ip_in) и пробегает по всей цепочке правил. Именно это у меня и вызвало непонимание того, каким образом пакет избежит попадания снова в правило заруливающее в NAT образовав таким образом петлю.С Вашим пояснением все логически становится ясно, что пакет продолжает идти по цепочке уже после этого правила. Но кстати на этом моменте вообще никто не акцентировал внимания, хотя я кучу "примеров и мануалов" просмотрел.
   Большое Вам спасибо, все таки как я понял, в бсд в отличие от вин многое приходится искать самому по манам, народ не очень охотно делится. Хотя за весь мой опыт работы с вин за более чем 10 лет, мне ни разу на форуме не смогли помочь ни с одной проблемой)).

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

14. "IPFW порядок составления, прохождения правил с NAT. Пинги." +/–

Сообщение от Тыгра on 08-Май-18, 01:22

>>[оверквотинг удален]
Ваш подход "запретить все исход кроме исключений", конечно, похвальный. И понятно непонимание. ИМХО, большинство примеров - по построению пограничного маршрутизатора. И поскольку обычно строят его в гражданской конторе, смысла нет настолько жёстко контролировать исходящий трафик, не с гостайной работаем.
На самой системе, отправляющей данные, как-то можно ограничить потоки данных от разных программ, но если на маршрутизатор пришёл пакет с запросом на 80 порт - всё равно его нужно отправлять. И 53 нужно отправлять. И 443. Вот, собственно, даже этого хватит, чтобы вынести любую информацию с внутренней сети. (первые пол-года, когда домашний ПК подключили к выделенке на постоянку, под рукой всегда жил скрипт, удаляющий дефолтный маршрут. Перестраховка от вирусов такая - типа - замечу левую активность - отрублю. Теперь прошло.) Ну а кроме того, есть протоколы, которым нужны целые диапазоны (FTP, например, skype тот же), и заниматься мазохизмом, настраивая маршрутизатор для всего этого счасться, желающих среди админов-сетевиков очень мало.
Лисяра как источник информации - очень неоднозначен. Как начальная точка - неплохо, но в основе - всё равно нужно читать man-ы.
Поясню по NAT и фильтрам.
Мне кажется, вы в уме никак не делите трафик самого шлюза и его транзитный трафик. И ещё ICMP тут радует.
>icmp запросы по подозрительным пингам
ICMP - управляющий протокол, ping - только два из его кодов. Там нет "подозрительных" пингов. Есть echo request, echo reply, есть другие коды. В моём примере отфильтрованы коды, ведущие к проблемам с безопасностью.
Вы можете отфильтровать echo request и reply, но это снижает качество диагностики сетевых проблем. И кроме того, echo request никогда не придёт извне с получателем - внутренним адресом (тем, который за NAT-ом), только с адресом самого шлюза. Вот собственно поэтому его обычно в NAT и не передают - смысла нет. Вместо ната его либо разрешили, либо запретили.
С echo reply уже другая ситуация - он может придти на запрос из внутренней сети, его уже надо NAT-ить.
Ещё NAT-у приходится отслеживать входящий ICMP типа destanation unreacable, так как клиент вообще то просил соединение по другому протоколу, а ему прибежал оттуда облом в виде ICMP. А в таблице NAT-а нет потока на ICMP, есть на другой протокол. Вот в NAT-е и необходимо дополнительно обрабатывать все ICMP, кроме запроса входящего эха, чтобы своему клиенту их оттранслировать, иначе тормозааааа.

>Опять таки заруливание в нат всего входящего трафика отдельным правилом, правило deny_in в свойствах нат, которое отрубает все входящие пакеты не имеющие записей в динамических таблицах.
Не во всех случаях deny_in нужен. Просто он один из вариантов. Например, один мой маршрутизатор работал одним интерфейсом на белую, а на другим - на серую подсети. Вот там deny_in был совсем не нужен. Поэтому у меня в условном 3500 было
$fwcmd 3500 deny all from any to me // inet in to this gate

>в бсд в отличие от вин многое приходится искать самому по манам, народ не очень охотно делится.
Вот тут сложно. Маны предполагают размышления и более глубокое понимание предмета, GUI-интерфейс частенько этому не способствует. По прочтении манов у каждого рождается своё видение процесса, и, чего уж тут скрывать, частенько маны тоже пишутся в стиле "у нас есть молоток, гвозди, сварка и пассатижи. А вот так выглядит синхрофазотрон". Надо сказать,  man ipfw тоже не идеален, но большинство моментов всё же описано отлично. Вот только чтобы понимать его, нужно ещё man ip,  man icmp, man osi, man как-это-всё-связно-вместе :) Мы делимся, но самые простые вещи всё-же разжёвывать не любим.

С днём связи вас!

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "IPFW порядок составления, прохождения правил с NAT. Пинги."	+/–
Сообщение от universite (ok) on 02-Май-18, 20:15
> $fwcmd 00001 allow all from any to any via re0 > ipfw nat 1 config log if re1 reset same_ports deny_in > $fwcmd 00100 nat 1 ip from any to any via re1 100-е правило разделите на два. 00100 nat 1 ip from 192.168.30.0/24 to not 192.168.30.0/24 out via re1 00101 nat 1 ip from any to me in via re1 Для прохождения пинга этих правил достаточно.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору

2. "IPFW порядок составления, прохождения правил с NAT. Пинги."	+/–
Сообщение от Тыгра on 03-Май-18, 22:11
>Извините за сумбур, пытаюсь все переварить. Сумбур, ага, есть немного. >И еще один момент, подскажите по правилу прохождения цепочки правил IPFW, продолжается ли >прохождение в случае: >1) для пакета найдено блокирующее правило >2) для пакета найдено разрешающее правило Ээээ, вот откуда могла возникнуть мысль, что с пакетом после этого ещё что то нужно делать? Конечно, обработка на командах allow, deny(drop), unreach, fwd завершается. nat, netgraph, ngtee - в зависимости от one_pass. skipto, call, count - всегда продолжается. reass - продолжается, если пакет не фрагментирован, иначе откладывает пакет до поступления всех частей, когда придут - собирает его в кучу и продолжается man ipfw вроде бы об этом хорошо говорит. >$fwcmd 00002 allow icmp from 192.168.30.10 to any out via re1 setup keep-state 1. icmp и setup? серьёэно? 2. allow = "всё, пропуск верный, беги по коридору". До NAT-а этот пакет не дойдёт, уйдёт в канал. Потому tcpdump и показывает такое - правило с NAT обойдено. 3. keep-state коварен. Избегайте, если структура правил не проектировалась для его использования. А в данном случае - вообще не нужен. Ещё мелочи - via и указанное направление out - бессмысленная трата тактов, ибо внутри ipfw "via re1" = "(out xmit re1) or (in recv re1)" также from any to me - красиво, понятно, но это me - долго, так как перебирает все интерфейсы и их адреса. Как концепция - самое то. Но потом - выпиливать в угоду скорости. А в чём сакральный смысл one_pass=1 ? Как раз без него, ИМХО, лучше. Да, добавится ещё правило, типа $fwcmd 00110 allow ip from any to any via re1 А вообще рекомендую сразу разделять потоки на группы правил, например: #!/bin/sh lan='re0' inet='re1' ipfw nat 1 config log if $inet reset same_ports deny_in $fwcmd 10 reass all from any to any // # separate IN and OUT $fwcmd 100 skipto 1000 all from any to any in $fwcmd 110 skipto 2000 all from any to any out # IN. Seperate interfaces $fwcmd 1000 skipto 3000 all from any to any recv $inet $fwcmd 1010 skipto 4000 all from any to any recv $lan $fwcmd 1997 allow all from any to any recv lo $fwcmd 1998 deny all fron any to 127.0.0.0/8 // protection $fwcmd 1999 deny all from any to any # OUT. Seperate interfaces $fwcmd 2000 skipto 5000 all from any to any xmit $inet $fwcmd 2010 skipto 6000 all from any to any xmit $lan $fwcmd 2997 allow all from any to any xmit lo $fwcmd 2998 allow all from 127.0.0.0/8 to any // protection $fwcmd 2999 deny all from any to any # inet in # icmp for router # filter some of them $fwcmd 3000 deny icmp from any to me icmptypes 5 // strange $fwcmd 3001 deny log icmp from any to me icmptypes 9,10,13,15,17 // danger $fwcmd 3002 allow icmp from any to me icmptypes 8 // usual in ping, NO NAT $fwcmd 3100 nat 1 all from any to any // inet in # place for filters to me $fwcmd 3110 allow tcp from any to me dst-port 80 // my web, also setup NAT rule $fwcmd 3130 deny tcp from any to me dst-port 1-1023 $fwcmd 3140 deny udp from any to me dst-port 1-1023 $fwcmd 3500 allow all from any to me // inet in to this gate # place for filters to LAN clients $fwcmd 3999 allow all from any to any // inet in transit # lan in $fwcmd 4000 allow all from any to any // lan in # inet out $fwcmd 5000 nat 1 all from any to any // inet out $fwcmd 5010 allow all from any to any // inet out $ lan out $fwcmd 6000 allow all from any to any // lan out Это пример без keep-state. Этот keep-state в такой структуре можно применять очень ограниченно. Если нужно тотально, то структура правил должна быть совсем другой. Вопрос на понимание - какое правило 100 или 110 лишнее, но с ним нагляднее?
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	3. "IPFW порядок составления, прохождения правил с NAT. Пинги."	+/–
	Сообщение от Evonder (ok) on 04-Май-18, 16:04
	Большое Вам спасибо! Буду разбираться!
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	4. "IPFW порядок составления, прохождения правил с NAT. Пинги."	+/–
	Сообщение от Evonder (ok) on 04-Май-18, 18:40
	>[оверквотинг удален] > $fwcmd 5000 nat 1 all from any to any // inet out > $fwcmd 5010 allow all from any to any // inet out > $ lan out > $fwcmd 6000 allow all from any to any // lan out > > Это пример без keep-state. Этот keep-state в такой структуре можно применять очень > ограниченно. > Если нужно тотально, то структура правил должна быть совсем другой. > Вопрос на понимание - какое правило 100 или 110 лишнее, но с > ним нагляднее? По поводу keep-state, вот взять например правило для DNS fwcmd 00300 allow udp from me to X.X.X.X 53 out via re1 keep-state #ДНС ЗАПРОС К СЕРВЕРУ ПРОВАЙДЕРА В чем тут опасность создания динамического правила? Отправил запрос к днс, и на основе его автоматом создалось разрешающее правило для входящего ответа, а если не использовал бы, тогда пришлось бы дописывать вторую строчку с разрешением для входящего ответа. $fwcmd 00110 allow ip from any to any via re1 Не могу понять смысла этого правила, ведь оно по сути разрешает все на отправку и вход по внешнему интерфейсу. ---------------- По поводу правил 100 и 110 Могу ошибаться, но "лишнее" тут 100, поскольку оно разрешает весь входящий поток по всем интерфейсам и всего лишь делает skipto на дальнейшие правила которые разбивают поток по интерфейсам лан и инет. Вот если убрать правило 110, то весь исходящий траф будет порезан правилом 1999, который для правила 1000 режет все пакеты которые не имели тега recv для интерфейсов инет и лан.
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	5. "IPFW порядок составления, прохождения правил с NAT. Пинги."	+/–
	Сообщение от Тыгра on 05-Май-18, 01:09
	>[оверквотинг удален] > fwcmd 00300 allow udp from me to X.X.X.X > 53 out via re1 keep-state #ДНС ЗАПРОС К СЕРВЕРУ ПРОВАЙДЕРА > В чем тут опасность создания динамического правила? Отправил запрос к > днс, и на основе его автоматом создалось разрешающее правило для входящего > ответа, а если не использовал бы, тогда пришлось бы дописывать вторую > строчку с разрешением для входящего ответа. > $fwcmd 00110 allow ip from any to any via > re1 > Не могу понять смысла этого правила, ведь оно по > сути разрешает все на отправку и вход по внешнему интерфейсу. Опасность динамики в том, что нужно тщательнее учитывать порядок прохождения пакетов в правилах. Как говорит ман, keep-state (и все правила с limit) одновременно является и check-state, в сложных конфигурациях (с несколькими интерфейсами или правилами, создаваемыми скриптами) можно огрести по полной, когда пакет, для которого есть динамическое правило, проверяется не там, и не отрабатывает какой-то нужный запрет или (что чаще) NAT. Но динамика очень хороша, когда NAT не нужен или не используется deny_in. И очень нужна при внедрении IPv6 (так как там NAT почти не нужен, а фаерволить всё равно нужно). Когда есть NAT с его deny_in, он делает всю работу по отбрасыванию ненужных входящих, действуя по правилу "всех выпускать, впускать только уже вышедших". Если deny_in нет, динамические правила предпочтительны, вы правы. > ---------------- > По поводу правил 100 и 110 > Могу ошибаться, но "лишнее" тут 100, поскольку оно разрешает весь > входящий поток по всем интерфейсам и всего лишь делает skipto на > дальнейшие правила которые разбивают поток по интерфейсам лан и инет. > Вот если убрать правило 110, то весь исходящий траф будет > порезан правилом 1999, который для правила 1000 режет все пакеты которые > не имели тега recv для интерфейсов инет и лан. Да, верно, но только потому, что нет других правил между 110 и 1000. Если бы были - о то оба нужны. Напоминание по поводу NAT: для маршрутизатора в NAT нужно заворачивать весь трафик - входящий, понятно, и так весь, но ошибочно делают NAT только исходящего трафика других компов, а исходящий самого шлюза не делают, и потом удивляются разным глюкам. ipfw - это как ассемблер, too easy to shoot the leg.
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	6. "IPFW порядок составления, прохождения правил с NAT. Пинги."	+/–
	Сообщение от Evonder (ok) on 05-Май-18, 08:18
	>[оверквотинг удален] >> Вот если убрать правило 110, то весь исходящий траф будет >> порезан правилом 1999, который для правила 1000 режет все пакеты которые >> не имели тега recv для интерфейсов инет и лан. > Да, верно, но только потому, что нет других правил между 110 и > 1000. Если бы были - о то оба нужны. > Напоминание по поводу NAT: для маршрутизатора в NAT нужно заворачивать весь трафик > - входящий, понятно, и так весь, но ошибочно делают NAT только > исходящего трафика других компов, а исходящий самого шлюза не делают, и > потом удивляются разным глюкам. > ipfw - это как ассемблер, too easy to shoot the leg. А можно мне пояснить немного один момент. В русских мануалах по ipfw где разбирают схему прохождения пакета структура такая, что пакет дойдя до правила заворачивания в nat и пройдя процедуру маскирования (например для исходящих) вновь возвращается в скажем так в функцию ip_out и снова пробегает по цепочке правил для исходящих пакетов. Но опция # lan in $fwcmd 4000 allow all from any to any // lan in # inet out $fwcmd 5000 nat 1 all from any to any // inet out $fwcmd 5010 allow all from any to any // inet out $ lan out $fwcmd 6000 allow all from any to any // lan out Правильно ли я понимаю, что правило 4000 на которое сбрасывает keepto с правила 1010 отфильтровавшее весь вошедший локальный трафик его же и полностью разрешает, после чего весь этот трафик заворачивает в нат правилом 5000, после использования которого снова проходит по всей цепочке ipfw для out, но благодаря опции one_pass он эту цепочку минует и сразу попадает на выход. Вот не могу понять, если опция не выставлена, что помешает пакету при повторном прохождении цепочки снова не попасть в правило которое заворачивает исходящие пакеты в NAT, и не получить петлю. Правило 5010 разрешает весь маскированный трафик на выход. И вот тут насколько я понимаю и появляется смысл отсутствия keep-state. По сути мы выпускаем на out все, без какой либо фильтрации, но благодаря отсутствию keep-state, все равно весь входящий трафик мы режем на правилах ин, и даже если скажем кто-то из юзеров попытается сделать что-то не хорошее, то в плане исх трафика он сможет отправить любой запрос, но вот ответ от нежелательных источников будет порезан на входе, и получится что-то типа черной дыры, он вроде кричит, а ответа не приходит. А если бы я использовал Keep-state для исходящих правил, и где-то ошибся, то выпустив по правило все разрешено, я по сути мог бы получить "дыру", пользователь сделал какое-то не хорошее дейсвие, о котором я мог не подумать, и это действие подпало бы под keep-state и не подверглось бы фильтрации на входящих. -------------- upd Правильно ли я понимаю, что по логике, в вышеприведенном листинге правил фильтрация по сути осуществляется на входе? Просто в вин я привык что прописываем умолчальное правило deny all from all to all и уже пляшут от него, разрешено то, что явно разрешено, все остальное запрещено. А согласно листингу свыше, мы разрешаем исходящее вообще все, но получить ответ можно лишь по избранному. Несколько не привычный метод фильтрации для меня.
	Ответить \| Правка \| ^ к родителю #5 \| Наверх \| Cообщить модератору


	7. "IPFW порядок составления, прохождения правил с NAT. Пинги."	+/–
	Сообщение от Evonder (ok) on 05-Май-18, 12:46
	И еще, можно пояснить по правилам 3000. Насколько я понимаю 3000 и 3001 запрещают системе отвечать на icmp запросы по подозрительным пингам, разхрешая только простое эхо, и только затем все остальные пакеты заруливаются на входящий нат и идут по правилам IPFW. Видел примеры, где все IN пакеты по внешнему интерфейсу (кроме стандартных запрещающих правил для подсетей) заруливаются на нат первым же правилом. Насколько это принципиально и безопасно? Получается, что есть фильтрация входящих до nat и после nat. Правила 3010-40 запрещают вход на служебные порты роутера, разрешая только доступ на веб сервер на роутере, и после этих правил по сути все разрешено на роутер на вход. $fwcmd 3999 allow all from any to any // inet in transit Это правило разрешает весь трафик с инета в локалку после прохождения nat. а эти правила разрешают свободный выход в сеть. $fwcmd 5000 nat 1 all from any to any // inet out $fwcmd 5010 allow all from any to any // inet out Получается что клиент сети, может иниициировать любое соединение с внешним узлом, и фльтрация будет осуществляться лишь на входящих соединениях. Поскольку в вин системах в основном используют как раньше и говорил запрещено все и вся,то тут как я вижу в основном используется разрешено все и вся, и лишь фильтрами убирается запрещенное. Какой подход более правильнй?
	Ответить \| Правка \| ^ к родителю #6 \| Наверх \| Cообщить модератору


	8. "IPFW порядок составления, прохождения правил с NAT. Пинги."	+/–
	Сообщение от Evonder (ok) on 05-Май-18, 22:41
	Попробовал прописать эту схему в лист IPFW, делаю на внутреннем хосте резолв имени, мониторю на внешнем интерфейсе, вижу что пакет из сети попал в нат, прошел с внутреннего на внешний интерфейс, запрос отправился, система получила ответ, но ответ на внутренний интерфейс уже не попал, остался на внешнем, почему так произошло?
	Ответить \| Правка \| ^ к родителю #7 \| Наверх \| Cообщить модератору


	9. "IPFW порядок составления, прохождения правил с NAT. Пинги."	+/–
	Сообщение от михалыч (ok) on 06-Май-18, 15:24
	> тут как я вижу в основном используется разрешено все и вся, > и лишь фильтрами убирается запрещенное. > Какой подход более правильнй? почитайте про открытый и закрытый тип брандмауэра, уверяю вас, будет весьма интересно и весьма познавательно http://www.g0l.ru/blog/htmls/BSDA-course/apes01.html
	Ответить \| Правка \| ^ к родителю #7 \| Наверх \| Cообщить модератору


	10. "IPFW порядок составления, прохождения правил с NAT. Пинги."	+/–
	Сообщение от Evonder (ok) on 06-Май-18, 17:27
	>> тут как я вижу в основном используется разрешено все и вся, >> и лишь фильтрами убирается запрещенное. >> Какой подход более правильнй? > почитайте про открытый и закрытый тип брандмауэра, > уверяю вас, будет весьма интересно и весьма познавательно > http://www.g0l.ru/blog/htmls/BSDA-course/apes01.html Я уже разобрался), мне было важно Понять саму схему расстановки правил и заруливания пакетов в nat. базово выбрал для себя такую схему первыми идут правила pass from any to any на lo0 и Lan потом 1) заворачиваю в нат все входящие пакеты с in recv $inet 2) разрешающие правила на выход вида add 10 skipto 1000 udp from x.x.x.x to x.x.x.x 53 xmit $inet 3) Блокирующее правило для всего прочего трафика add 20 deny all from any to any 4) заворачиваю в нат все исходящие пакеты add 1000 nat 1 all from any to any OUT Вот такая схема мне очень понятна. Только один момент остался немного не ясен, опция one-pass Если она выключена, то пакет после маскирования в нат снова попадает на цепочку ipfw и каким образом при повторном прохождении этой цепочки он снова не попадает в правило что все заруливается в nat, а если не попадает, то какое правило после нат выпускает наружу его. Вот в моей цепочке правида pass all from any to any нет в конце, между тем все рабоает очень корректно, по умолчанию сам ipfw правилом 65355 ставит all deny. Как же после нат пакет попадает во внешку?
	Ответить \| Правка \| ^ к родителю #9 \| Наверх \| Cообщить модератору


	11. "IPFW порядок составления, прохождения правил с NAT. Пинги."	+/–
	Сообщение от михалыч (ok) on 07-Май-18, 19:14
	>[оверквотинг удален] > Вот такая схема мне очень понятна. > Только один момент остался немного не ясен, опция one-pass > Если она выключена, то пакет после маскирования в нат снова > попадает на цепочку ipfw и каким образом при > повторном прохождении этой цепочки он снова не попадает в правило что все > заруливается в nat, а если не попадает, то какое правило после > нат выпускает наружу его. Вот в моей цепочке правида pass > all from any to any нет в конце, между тем все > рабоает очень корректно, по умолчанию сам ipfw правилом 65355 ставит all > deny. Как же после нат пакет попадает во внешку? все велосипеды давным-давно изобретены, как впрочем и само колесо но практически каждый начинающий "гонщик" начинает со своего "самоката" ))) ну в смысле - есть готовые несложные примеры ipfw правил самые типичные и распространённые смотрим в /etc/rc.firewall Определите тип брандмауэра в /etc/rc.conf. Допустимые значения: open - открытый, разрешает входящий трафик любому хосту client - клиент, будет защищать именно эту машину simple - простой, будет защищать всю сеть closed - закрытый, полностью отключает IP-сервисы, кроме интерфейса lo0 workstation - защищает только эту машину с помощью учёта состояния соединений. Смотрите ниже используемые переменные для rc.conf UNKNOWN - неизвестный, полностью отключает загрузку правил брандмауэра filename - загружает правила из указанного файла (требуется полный путь) Для "клиент" и "простой" примеры ниже должны быть настроены соответствующим образом. разумеется, если у вас не тривиальный случай, не типичный, а "атипичный )))" вам это не подойдёт, но как за основу вполне по поводу one_pass опять же обратимся к первоисточнику info ipfw \| grep -A4 "net.inet.ip.fw.one_pass: 1" "если установлено ... после выполнения действия, пакет повторно возвращается в брандмауэр и обрабатывается последующим правилом" такие дела
	Ответить \| Правка \| ^ к родителю #10 \| Наверх \| Cообщить модератору


	12. "IPFW порядок составления, прохождения правил с NAT. Пинги."	+/–
	Сообщение от михалыч (ok) on 07-Май-18, 19:15
	fix
	Ответить \| Правка \| ^ к родителю #11 \| Наверх \| Cообщить модератору


	13. "IPFW порядок составления, прохождения правил с NAT. Пинги."	+/–
	Сообщение от Evonder (ok) on 07-Май-18, 22:22
	>[оверквотинг удален] > Для "клиент" и "простой" примеры ниже должны быть настроены соответствующим образом. > > разумеется, если у вас не тривиальный случай, не типичный, а "атипичный )))" > вам это не подойдёт, но как за основу вполне > по поводу one_pass > опять же обратимся к первоисточнику > info ipfw \| grep -A4 "net.inet.ip.fw.one_pass: 1" > "если установлено ... после выполнения действия, пакет повторно возвращается в брандмауэр > и обрабатывается последующим правилом" > такие дела Да нет, у меня все типично, не типичны после винд шлюзов логика работы шлюзов на базе ipfw. Например мне не привычно, что в большинстве примеров весь исходящий трафик по умолчанию открыт, я хотел запретить все исход кроме исключений. Решить эту задачу помогает функция skipto которая позволяет "перепрыгнуть" разрешенным правилам через deny all from any to any. В виндовых шлюзах такой логики работы никогда не встречал, поэтому очень для меня не привычно. Опять таки заруливание в нат всего входящего трафика отдельным правилом, правило deny_in в свойствах нат, которое отрубает все входящие пакеты не имеющие записей в динамических таблицах. По поводу: "если установлено ... после выполнения действия, пакет повторно возвращается в брандмауэр и обрабатывается последующим правилом" Изучать ipfw начал по мануалам с лисяры форума бсд, там не было такой конкретизации, там было однозначно сказано, что при отключенной функции one_pass после прохождения NAT пакет снова возвращается в функцию (например ip_in) и пробегает по всей цепочке правил. Именно это у меня и вызвало непонимание того, каким образом пакет избежит попадания снова в правило заруливающее в NAT образовав таким образом петлю.С Вашим пояснением все логически становится ясно, что пакет продолжает идти по цепочке уже после этого правила. Но кстати на этом моменте вообще никто не акцентировал внимания, хотя я кучу "примеров и мануалов" просмотрел. Большое Вам спасибо, все таки как я понял, в бсд в отличие от вин многое приходится искать самому по манам, народ не очень охотно делится. Хотя за весь мой опыт работы с вин за более чем 10 лет, мне ни разу на форуме не смогли помочь ни с одной проблемой)).
	Ответить \| Правка \| ^ к родителю #11 \| Наверх \| Cообщить модератору


	14. "IPFW порядок составления, прохождения правил с NAT. Пинги."	+/–
	Сообщение от Тыгра on 08-Май-18, 01:22
	>>[оверквотинг удален] Ваш подход "запретить все исход кроме исключений", конечно, похвальный. И понятно непонимание. ИМХО, большинство примеров - по построению пограничного маршрутизатора. И поскольку обычно строят его в гражданской конторе, смысла нет настолько жёстко контролировать исходящий трафик, не с гостайной работаем. На самой системе, отправляющей данные, как-то можно ограничить потоки данных от разных программ, но если на маршрутизатор пришёл пакет с запросом на 80 порт - всё равно его нужно отправлять. И 53 нужно отправлять. И 443. Вот, собственно, даже этого хватит, чтобы вынести любую информацию с внутренней сети. (первые пол-года, когда домашний ПК подключили к выделенке на постоянку, под рукой всегда жил скрипт, удаляющий дефолтный маршрут. Перестраховка от вирусов такая - типа - замечу левую активность - отрублю. Теперь прошло.) Ну а кроме того, есть протоколы, которым нужны целые диапазоны (FTP, например, skype тот же), и заниматься мазохизмом, настраивая маршрутизатор для всего этого счасться, желающих среди админов-сетевиков очень мало. Лисяра как источник информации - очень неоднозначен. Как начальная точка - неплохо, но в основе - всё равно нужно читать man-ы. Поясню по NAT и фильтрам. Мне кажется, вы в уме никак не делите трафик самого шлюза и его транзитный трафик. И ещё ICMP тут радует. >icmp запросы по подозрительным пингам ICMP - управляющий протокол, ping - только два из его кодов. Там нет "подозрительных" пингов. Есть echo request, echo reply, есть другие коды. В моём примере отфильтрованы коды, ведущие к проблемам с безопасностью. Вы можете отфильтровать echo request и reply, но это снижает качество диагностики сетевых проблем. И кроме того, echo request никогда не придёт извне с получателем - внутренним адресом (тем, который за NAT-ом), только с адресом самого шлюза. Вот собственно поэтому его обычно в NAT и не передают - смысла нет. Вместо ната его либо разрешили, либо запретили. С echo reply уже другая ситуация - он может придти на запрос из внутренней сети, его уже надо NAT-ить. Ещё NAT-у приходится отслеживать входящий ICMP типа destanation unreacable, так как клиент вообще то просил соединение по другому протоколу, а ему прибежал оттуда облом в виде ICMP. А в таблице NAT-а нет потока на ICMP, есть на другой протокол. Вот в NAT-е и необходимо дополнительно обрабатывать все ICMP, кроме запроса входящего эха, чтобы своему клиенту их оттранслировать, иначе тормозааааа. >Опять таки заруливание в нат всего входящего трафика отдельным правилом, правило deny_in в свойствах нат, которое отрубает все входящие пакеты не имеющие записей в динамических таблицах. Не во всех случаях deny_in нужен. Просто он один из вариантов. Например, один мой маршрутизатор работал одним интерфейсом на белую, а на другим - на серую подсети. Вот там deny_in был совсем не нужен. Поэтому у меня в условном 3500 было $fwcmd 3500 deny all from any to me // inet in to this gate >в бсд в отличие от вин многое приходится искать самому по манам, народ не очень охотно делится. Вот тут сложно. Маны предполагают размышления и более глубокое понимание предмета, GUI-интерфейс частенько этому не способствует. По прочтении манов у каждого рождается своё видение процесса, и, чего уж тут скрывать, частенько маны тоже пишутся в стиле "у нас есть молоток, гвозди, сварка и пассатижи. А вот так выглядит синхрофазотрон". Надо сказать, man ipfw тоже не идеален, но большинство моментов всё же описано отлично. Вот только чтобы понимать его, нужно ещё man ip, man icmp, man osi, man как-это-всё-связно-вместе :) Мы делимся, но самые простые вещи всё-же разжёвывать не любим. С днём связи вас!
	Ответить \| Правка \| ^ к родителю #13 \| Наверх \| Cообщить модератору