- 100-е правило разделите на два code 00100 nat 1 ip from 192 168 30 0 24 to not ,
 universite (ok), 20:15 , 02-Май-18 (1)> $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
Для прохождения пинга этих правил достаточно.
- Сумбур, ага, есть немного Ээээ, вот откуда могла возникнуть мысль, что с пакетом, Тыгра (?), 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 лишнее, но с ним нагляднее?
- Большое Вам спасибо Буду разбираться , Evonder (ok), 16:04 , 04-Май-18 (3)
Большое Вам спасибо! Буду разбираться!
- gt оверквотинг удален По поводу keep-state, вот взять например правило для DNS, Evonder (ok), 18:40 , 04-Май-18 (4)
>[оверквотинг удален]
> $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 для интерфейсов инет и лан.
- gt оверквотинг удален Опасность динамики в том, что нужно тщательнее учитывать, Тыгра (?), 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.
- gt оверквотинг удален А можно мне пояснить немного один момент В русских ма, Evonder (ok), 08:18 , 05-Май-18 (6)
>[оверквотинг удален]
>> Вот если убрать правило 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 и уже пляшут от него, разрешено то, что явно разрешено, все остальное запрещено. А согласно листингу свыше, мы разрешаем исходящее вообще все, но получить ответ можно лишь по избранному. Несколько не привычный метод фильтрации для меня.
- И еще, можно пояснить по правилам 3000 Насколько я понимаю 3000 и 3001 запрещают, Evonder (ok), 12:46 , 05-Май-18 (7)
И еще, можно пояснить по правилам 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 Получается что клиент сети, может иниициировать любое соединение с внешним узлом, и фльтрация будет осуществляться лишь на входящих соединениях.
Поскольку в вин системах в основном используют как раньше и говорил запрещено все и вся,то тут как я вижу в основном используется разрешено все и вся, и лишь фильтрами убирается запрещенное. Какой подход более правильнй?
- Попробовал прописать эту схему в лист IPFW, делаю на внутреннем хосте резолв и, Evonder (ok), 22:41 , 05-Май-18 (8)
Попробовал прописать эту схему в лист IPFW, делаю на внутреннем хосте резолв имени, мониторю на внешнем интерфейсе, вижу что пакет из сети попал в нат, прошел с внутреннего на внешний интерфейс, запрос отправился, система получила ответ, но ответ на внутренний интерфейс уже не попал, остался на внешнем, почему так произошло?
- почитайте про открытый и закрытый тип брандмауэра,уверяю вас, будет весьма интер, михалыч (ok), 15:24 , 06-Май-18 (9)
> тут как я вижу в основном используется разрешено все и вся,
> и лишь фильтрами убирается запрещенное.
> Какой подход более правильнй?почитайте про открытый и закрытый тип брандмауэра,
уверяю вас, будет весьма интересно и весьма познавательно http://www.g0l.ru/blog/htmls/BSDA-course/apes01.html
- Я уже разобрался , мне было важно Понять саму схему расстановки правил и зарул, Evonder (ok), 17:27 , 06-Май-18 (10)
>> тут как я вижу в основном используется разрешено все и вся,
>> и лишь фильтрами убирается запрещенное.
>> Какой подход более правильнй?
> почитайте про открытый и закрытый тип брандмауэра,
> уверяю вас, будет весьма интересно и весьма познавательно
> 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. Как же после нат пакет попадает во внешку?
- gt оверквотинг удален все велосипеды давным-давно изобретены, как впрочем и са, михалыч (ok), 19:14 , 07-Май-18 (11)
>[оверквотинг удален]
> Вот такая схема мне очень понятна.
> Только один момент остался немного не ясен, опция 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"
"если установлено ... после выполнения действия, пакет повторно возвращается в брандмауэр
и обрабатывается последующим правилом"
такие дела
- fix, михалыч (ok), 19:15 , 07-Май-18 (12)
- gt оверквотинг удален Да нет, у меня все типично, не типичны после винд ш, Evonder (ok), 22:22 , 07-Май-18 (13)
>[оверквотинг удален]
> Для "клиент" и "простой" примеры ниже должны быть настроены соответствующим образом.
>
> разумеется, если у вас не тривиальный случай, не типичный, а "атипичный )))"
> вам это не подойдёт, но как за основу вполне
> по поводу 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 лет, мне ни разу на форуме не смогли помочь ни с одной проблемой)).
- Ваш подход запретить все исход кроме исключений , конечно, похвальный И понятн, Тыгра (?), 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 как-это-всё-связно-вместе :) Мы делимся, но самые простые вещи всё-же разжёвывать не любим.
С днём связи вас!
|
Свернуть нити
Пометить прочитанным
, (Проблемы с безопасностью / Linux) -Дек-, 00: [⋘ | ☳ | ⋙
| ⚟
] [линейный вид] [смотреть все]
Создать тему
