The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

[FreeBSD] порядок размещения правил для IPFW (freebsd cronyx firewall ipfw)


<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>
Ключевые слова: freebsd, cronyx, firewall, ipfw,  (найти похожие документы)
From: proff <prozoroff@mail.ru> Subject: [FreeBSD] порядок размещения правил для IPFW http://www.opennet.dev//openforum/vsluhforumID1/26143.html Возможно будет полезно "укращающим" IPFW. ;-) Сегодня получил письмо следующего содержания: Наткнулся тут на форуме на твой конфиг rc.firewall, и возникли вопросы: >Тут есть одно и очень простое правило: располагать правила для IPFW в следующем порядке: >1. сначала идут инструкции deny и reject (если есть) >2. потом divert >3. потом allow на внутреннюю сетку(и) >4. потом allow все остальное >5. потом deny все, что осталось. Разве divert не должен идти самым первым правилом ipfw? По идее, сколько я юзал ipfw и нат, divert, потом (если есть) fwd, а потом уже deny/reject, allow и deny на остальное... Сначала ответил отправителю по почте, но ответ не дошел и письмо вернулось. По этому ответ размещаю здесь. Примечания: 1. "сверхопытнейшим" сисадминам с нереализованным до конца творческим потенциалом читать сие не рекомендуется, чтобы не испортился сон; 2. я не считаю эту стратегию "абсолютно" правильной, но "достаточно хорошей" для домашней сетки назвать-таки отваживаюсь. ----------- По существу: divert совершенно не обязательно распологать первым правилом. Даже более того, обычно, распологать его там вредно. Дело в том, что не все пакеты, которые попадают на внешний интерфейс твоего роутера предназначены для внутренней сети, следовательно, необходимо отправлять в divert-socket, т.е. на растерзание natd, только те пакеты, которые внутренней сети предназначены. Соответственно, пакеты, не предназначенные для внутренней сети отправлять в divert-socket смысла не имеет. По этому, получается, что первым правилом распологать divert вредно. В схеме 1. сначала идут инструкции deny и reject (если есть) 2. потом divert 3. потом allow на внутреннюю сетку(и) 4. потом allow все остальное 5. потом deny все, что осталось. предложена упрощенная стратегия написания правил IPFW. На самом деле, эффективнее, с точки зрения моего представления о безопасности, распологать правила так: 1. сначала идут инструкции deny и reject (если есть), чтобы погасить вредный трафик 2. потом count для внешнего трафика, если интересна полная статистика 3. потом forward, если нужен 4. потом allow на сервисы, доступные извне 5. потом divert 6. потом count для трафика в разрезе внутренних хостов, если интересна такая статистика 7. потом allow на внутреннюю сетку(и), либо хосты, если ты параноик, как я;) 8. потом allow для разрешенных с роутера соединений 9. потом log deny все, что осталось в разрезе всего, что интересно. ответил на твой вопрос? в заключении хочу добавить, что FreeBSD -- конструктор Lego, по этому как бы ты не собрал -- работать будет, остается только вопрос -- на сколько хорошо и надежно...

<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>

Обсуждение [ Линейный режим | Показать все | RSS ]
  • 1.1, togkskbr (?), 10:11, 19/03/2003 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    предлогаемая схема, я пологаю, для ядра с опцией разрешающей все пакеты?
     
  • 1.2, vi (?), 04:48, 20/03/2003 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > 1. сначала идут инструкции deny и reject (если
    > есть), чтобы погасить вредный трафик
    > 2. потом count для внешнего трафика, если
    > интересна полная статистика

    отброшенные пунктом 1 входящие пакеты все равно засчитаются тебе в траффик твоим ISP -- твоему серверу-то их то передали (важно если за траффик платишь) ... поэтому если хочешь видеть реально полную статистику, то count надо первым ставить... а так на втором месте будет считаться только "полезный" траффик...

    ps. про подсчеты трафика киской и т.д не напоминайте -- не о том речь

     
     
  • 2.9, proff (?), 15:14, 16/03/2004 [^] [^^] [^^^] [ответить]  
  • +/
    Точно подмечено: ПОЛЕЗНЫЙ трафик. Очипятался я там, есть такое дело ;-)
    Но с другой стороны, считывать счетчики можно не только с правил count, но и с других правил (allow, deny, ...). Так что полет фантазии для подсчета трафика только count-том не ограничен ;-)
     

  • 1.4, Василий (?), 13:55, 06/11/2003 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Попадает ли пакет, который обработан правилом с divert обратно в файрвол?
     
     
  • 2.5, McLone (?), 07:06, 11/11/2003 [^] [^^] [^^^] [ответить]  
  • +/
    Это тебе не ipf/ipnat... тут используется древнейшая технология файерволостроения "first match" так что пакеты НЕ МОГУТ проходить правило более 1-го раза - попал пакет в правило и ушёл из файервола (кроме skipto number ИМХО). Если хочется поизголяться с НАТа - man 5 ipf (http://www.obfuscation.org/ipf/ тоже рулез) там "last match", а ipfw/natd/dummynet - это как бы... хм... быстрое решение, когда лень вникать. А ipf/ipnat тоже встроены... Опять же ИМХО получается что "скрипач не нужен".
     
     
  • 3.6, Basil (?), 15:34, 03/12/2003 [^] [^^] [^^^] [ответить]  
  • +/
    Ничего подобного. RTFM.
    Пакеты могут быть "reinjected into firewall" в том случае, если правила неверно написаны. I.e., если в правиле на входящий пакет не поставлена опция проверять только входящие, то проверке он подвергнется входя в интерфейс и выходя из него.

    Divert packets that match this rule to the divert(4) socket bound              to port port.  <b>The search terminates.</b> RTFM. Полезно, по себе знаю.


     
  • 3.11, Serrj (?), 13:15, 30/03/2005 [^] [^^] [^^^] [ответить]  
  • +/
    natd(8) : "..After translation by natd, packets re-enter the firewall at the rule number following the rule number that caused the diversion (not the next rule if there are several at the same number)..."
     

  • 1.7, Александр Моря (?), 15:49, 13/12/2003 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    RTFM то конечно классно но не суть))) Поскольку Divert packets that match this rule to the divert(4) socket bound to port port.  <b>The search terminates.</b> это есть общий случай... а вот при попадании пакета в natd этот пакет так сказать реинжектится)) в файрвол и проходит  правила с номерами, превышающими номер правила ната(в который он попал)Вот так вот))) а вы RTFM...
     
  • 1.8, Dmitry Grigorovich (?), 13:13, 12/03/2004 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Почему никто даже не предлагает использовать ipfw skipto в правилах ?
    Таким образом можно сделать структуру правил нелинейной, в виде бинарного дерева
    Это позволит уменьшить кол-во обрабатываемых команд

    Что же касается порядка размещения правил,
    то с точки зрения скорости обработки правил,
    внутренний канал как правило быстрее работает чем внешний
    поэтому IMHO стоит сначала разрешить пакеты для внутренней сети
    а потом уже обрабатывать уже пакет их внешней сети
    и во внешнюю сеть

     
  • 1.10, KES (?), 18:07, 22/09/2004 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Интересно, а как должен выгледеть файр волл, если net.link.ether.bridge=1
    net.link.ether.bridge_ipfw=1
    и с политикой 65535 deny ip from any to any
    Физическая структура такая:
    Есть сеть: 192.168.0.0/16
    Эта сеть разделена физически на две части:
    192.168.0.0/24 i 192.168.1.0/24
    У каждой подсети есть свой сервачок, который раздает и-нет (natd) и считает трафик.
     
  • 1.12, XoRe (??), 08:42, 30/07/2005 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Я хочу рассмотреть ситуацию, когда локальная сеть имеет выход в интернет через ш... большой текст свёрнут, показать
     
  • 1.14, TazMan (?), 00:35, 28/12/2005 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    а не подскажет ли кто как быть с pipe ? его куда в этом порядке вставлять ? in и out /// хотелось бы действующий firewall.rules посмотреть ...
     

    игнорирование участников | лог модерирования

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру