IPFW порядок составления, прохождения правил с NAT. Пинги., universite, 20:15 , 02-Май-18 (1)
IPFW порядок составления, прохождения правил с NAT. Пинги., Тыгра, 22:11 , 03-Май-18 (2)
>Извините за сумбур, пытаюсь все переварить.
Сумбур, ага, есть немного.
>И еще один момент, подскажите по правилу прохождения цепочки правил 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/shlan='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 лишнее, но с ним нагляднее?
Ответить | Сообщить модератору

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

IPFW порядок составления, прохождения правил с NAT. Пинги., Тыгра, 01:09 , 05-Май-18 (5)
>[оверквотинг удален]
>  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.
Ответить | Сообщить модератору

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)
>>[оверквотинг удален]
Ваш подход "запретить все исход кроме исключений", конечно, похвальный. И понятно непонимание. ИМХО, большинство примеров - по построению пограничного маршрутизатора. И поскольку обычно строят его в гражданской конторе, смысла нет настолько жёстко контролировать исходящий трафик, не с гостайной работаем.
На самой системе, отправляющей данные, как-то можно ограничить потоки данных от разных программ, но если на маршрутизатор пришёл пакет с запросом на 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 как-это-всё-связно-вместе :) Мы делимся, но самые простые вещи всё-же разжёвывать не любим.

С днём связи вас!
Ответить | Сообщить модератору