The OpenNET Project / Index page

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

Заметки о составлении IPFW правил

24.10.2007 16:30

Олег Воробьёв опубликовал статью с рассказом о принципе построения правил пакетного фильтра IPFW.

  1. Главная ссылка к новости (http://www.lissyara.su/?id=153...)
Лицензия: CC-BY
Тип: яз. русский / Практикум
Ключевые слова: ipfw, firewall, freebsd
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (27) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 17:10, 24/10/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    В правиле 4 не должно ли быть deny?
     
  • 1.2, sunTechnic (?), 17:26, 24/10/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Во Фре есть очень полезная фича: переименование сетевых интерфейсов, так, например, {iif} и {oif} лучше сразу писать типа internal, external.

    Делается это в /etc/rc.conf так:
    ifconfig_em0_name="internal"
    ifconfig_em1_name="external"

    Это удобно тем, что вне зависимости какого производителя у вас карточка и на какую вы её в случае чего замените, вам потребуется поменять всего лишь обозначение в /etc/rc.conf, а не отлавливать все скрипты на предмет изменения названия интерфейса.

    Плюс размещение в файле строчек типа:
    ${fwcmd} add allow ip from any to ${MyLan} in via {oif}
    не очень удобно в плане дальнейшего модифицирования файрволла на ходу без перезагрузки всех правил, гораздо удобнее всё-таки писать /sbin/ipfw вместо {fwcmd} (благо его не часто переносят):
    /sbin/ipfw table 1 add 10.10.10.0/24
    /sbin/ipfw add allow ip from any to table(1) in via external

    Таким образом можно после редактирования файлика сразу исполнить эту строчку и тем самым добавить в файрволл новое правило.

    Всё ИМХО, основанное на продолжительном опыте эксплуатации фри в качестве роутера.

     
     
  • 2.3, B.O.B.A.H. (??), 20:06, 24/10/2007 [^] [^^] [^^^] [ответить]  
  • +/
    а почему народ не любит стандартный
    /etc/rc.firewall
    и старается писать свои правила?
     
     
  • 3.13, Дмитрий Ю. Карпов (?), 11:19, 25/10/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Например, в /etc/rc.firewall адреса внутренней сетИ заданы внутри скрипта, а их надо задавать в /etc/rc.conf - этого уже достаточно, чтобы делать свой набор правил.

    А вот подгружать правила из текстового файла тоже не очень хорошо, т.к. конструкция с проверкой необходимости natd очень разумна, и $natd_interface берётя из /etc/rc.conf.

     
  • 2.11, JJF (?), 09:16, 25/10/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >Во Фре есть очень полезная фича: переименование сетевых интерфейсов

    Это таки хорошая фича, да, но есть одно но (не знаю, пофиксили ли это в 7 ветке, но на 6.2 этот баг все еще есть) - NETGRAPH очень странно работает с переименованными интерфейсами. Например, у меня mpd категорически отказывается подключаться по pppoe через переименованный интерфейс. Погуглил - оказалось, таки да. Судя по всему, валится ng_ether, который собран с ядром. По идее, его нужно подгружать уже после переименования интерфейса, тогда может быть все и будет нормально, но пока руки не дошли проверить. Кто-то уже боролся?

     
     
  • 3.14, sunTechnic (?), 12:31, 25/10/2007 [^] [^^] [^^^] [ответить]  
  • +/
    там тонкость: ng_ether надо грузить модулем после переименования интерфейсов
     
     
  • 4.22, JJF (?), 11:51, 26/10/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Так я об этом же и говорю.
    Но все равно это своеобразный косяк, с которым еще попританцовывать надо. Может быть кому-то и пригодится, потому как в нете не сильно много об этой проблеме написано.
     

  • 1.4, Аноним (4), 20:32, 24/10/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Замечание к статье.
    В /etc/rc.conf в firewall_type="" можно указать просто имя файла, из которого стандартный rc.firewall и считает правила, и в самом rc.firewall ничего править не нужно.
     
  • 1.5, belkin (?), 20:35, 24/10/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    В очередной раз можно сказать "читайте man" (man ipfw) - лучший источник знаний.

    1. Правила загружать правильней не скриптом, который для добавления каждого правила вызывает ipfw, а из текстового файла: /sbin/ipfw /etc/ipfwrules.txt.
    2. Для сложных случаев с переменными пользуемся препроцессором:
    /sbin/ipfw -p /usr/bin/m4 /etc/ipfwrules.m4 .

     
     
  • 2.6, sk (??), 20:44, 24/10/2007 [^] [^^] [^^^] [ответить]  
  • +/
    а если маленькая ошибочка в этом текстовом файле?
    по умолчанию таки в виде скрипта все сделано. Разработчики кто по вашему тогда? идиоты чтоль? ;)
     
     
  • 3.7, belkin (?), 21:14, 24/10/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >а если маленькая ошибочка в этом текстовом файле?
    >по умолчанию таки в виде скрипта все сделано. Разработчики кто по вашему
    >тогда? идиоты чтоль? ;)

    Разработчики чего ? Скрипта rc.firewall ?
    А если ошибочка в скрипте - тогда что делать ?

    Читаем man ipfw и узнаём о ipfw -n . Позволяет проверить правила без реальной загрузки.

     
  • 3.8, SunTech (?), 22:16, 24/10/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Для этого есть set, сначала правила загружаются в неактивный, потом проверяются, потом он делается активным. Есть пример в examples
     
     
  • 4.9, Просто человек (?), 03:27, 25/10/2007 [^] [^^] [^^^] [ответить]  
  • +/
    ммм....у меня к ночи мозги клинят или я непойму....откуда в правилах 7 и 8 айпишники внутренней сетки появяться на внешнем интерфейсе?


     
  • 2.24, northbear (??), 18:48, 26/10/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >2. Для сложных случаев с переменными пользуемся препроцессором:
    >/sbin/ipfw -p /usr/bin/m4 /etc/ipfwrules.m4 .

    Только не m4... в прочем если вы используете sendmail и в ручную пишите sendmail.cf, то m4 вам понравится.

     

  • 1.10, nuclight (?), 06:41, 25/10/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Автор, как всегда, в своем репертуаре... Экспериментально устанавливал, что происходит с пакетом после divert, тогда как это есть в мане, даже в двух - и divert(4), и natd(8)/
     
     
  • 2.12, Аноним (-), 10:49, 25/10/2007 [^] [^^] [^^^] [ответить]  
  • +/
    дык маньяк он и с маном маньяк и без мана
     
  • 2.25, cat (??), 10:17, 27/10/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >Автор, как всегда, в своем репертуаре...

    Мы не знакомы, это моя первая статья чтобы говорить о моём репертуаре.

    Очень рад что заставил лишний раз перечитать  MAN.

     

  • 1.15, Аноним (15), 13:52, 25/10/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Да ладно вам автору респект - я сам часто методом научного тыка все пытаюсь выявить а уж если совсе бяд -вот тогда мана. Да я уверен что 70% админов сами с усами...народ у нас такой...
     
  • 1.16, Осторожный (?), 18:17, 25/10/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Не в тему.
    Если уж начали изучать firewall-ы на FreeBSD то
    лучше СРАЗУ изучайте pf !
    После него на ipfw,iptables смотреть даже не будете :)
    Вот только с документацией и примерами не густо но есть хорошие статьи про pf для OpenBSD ( со списком отличий в FreeBSD )
     
     
  • 2.17, belkin (?), 21:54, 25/10/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >Не в тему.
    >Если уж начали изучать firewall-ы на FreeBSD то
    >лучше СРАЗУ изучайте pf !
    >После него на ipfw,iptables смотреть даже не будете :)
    >Вот только с документацией и примерами не густо но есть хорошие статьи
    >про pf для OpenBSD ( со списком отличий в FreeBSD )
    >

    Не всё так как кажется.
    1. Он не умеет на FreeBSD блокировать в ядре IP до запуска себя. Приходится это делать скриптами запуска.
    2. В ipfw удобно добавляются, удаляются отдельные правила или наборы.
    3. IPFW+Dummynet - удобная вещь для справедливого деления канала между пользователями.

    Ну и ещё всякое разное.

     
     
  • 3.19, Serg (??), 04:22, 26/10/2007 [^] [^^] [^^^] [ответить]  
  • +/
    > 1. Он не умеет на FreeBSD блокировать в ядре IP до запуска себя. Приходится это делать скриптами запуска.

    Ничего не понял, как это скриптами запуска? А при старте ядра загрузить модуль религия не дает?

    > 2. В ipfw удобно добавляются, удаляются отдельные правила или наборы.

    Аналогично и в pf

    > 3. IPFW+Dummynet - удобная вещь для справедливого деления канала между пользователями.

    PF замечательно умеет делить канал как вашей душе угодно.

    Ничего не имею против IPFW, но прежде чем говорить что какая-то из служб что-то не умеет все же стоит документацию хотя бы глянуть.

    Оба фильтра замечательно выполняют свои функции, и могут полностью заменить друг друга.
    Тут дело вкуса, и кто к чему привык/лучше знает.

     
     
  • 4.20, raistlin (??), 09:38, 26/10/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Уважаемый серг, а какая-нить альтернатива natd есть в OpenBSD? Я согласен что, ПФ Опенка гораздо приятнее ipfw, но вот када нада извраты с натд...
     
     
  • 5.26, cadmi (?), 09:11, 28/10/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >Уважаемый серг, а какая-нить альтернатива natd есть в OpenBSD? Я согласен что,
    >ПФ Опенка гораздо приятнее ipfw, но вот када нада извраты с
    >натд...

    там слава богу нет этого угребищного natd, там nat в ядре и сделан прямыми руками, в отличие от возни с divert и левой программой, которая поднимается отдельно.

     
  • 4.21, belkin (?), 10:39, 26/10/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >> 1. Он не умеет на FreeBSD блокировать в ядре IP до запуска себя. Приходится это делать скриптами запуска.
    >
    >Ничего не понял, как это скриптами запуска? А при старте ядра загрузить
    >модуль религия не дает?

    Если PF по каким-либо причинам не загрузится, то будет дыра. Без IPFW в таких случаях будет Deny All.

    >> 2. В ipfw удобно добавляются, удаляются отдельные правила или наборы.
    >
    >Аналогично и в pf

    "Удобно".

    >
    >> 3. IPFW+Dummynet - удобная вещь для справедливого деления канала между пользователями.
    >
    >PF замечательно умеет делить канал как вашей душе угодно.

    pipe 1 config bw 10Mbit/s
    pipe 2 config bw 10Mbit/s
    pipe 3 config bw 768Kbit/s mask dst-ip 0xFFFFFFFF
    queue 1 config pipe 1 mask src-ip 0xFFFFFFFF
    queue 2 config pipe 2 mask dst-ip 0xFFFFFFFF
    add pipe 3 all from 192.168.15.1 to any src-port 3128 out
    add queue 1 all from any to any out xmit vlan0
    add queue 2 all from 192.168.15.1 to any out

    Для каждого клиентского IP-адреса по маске динамически создаёт по одной очереди в каждом направлении и справедливо распределяет пропускную способность между ними не требуя указания пропускной способности канала Internet. Сделайте подобное на FreeBSD с помощью PF.

    >Ничего не имею против IPFW, но прежде чем говорить что какая-то из
    >служб что-то не умеет все же стоит документацию хотя бы глянуть.

    Это вы товарищу Осторожный скажите. Я ему хотел сказать, что если он не знает недостатки PF значит он его плохо знает.

    >Оба фильтра замечательно выполняют свои функции, и могут полностью заменить друг друга.

    Отличия есть и потому использую оба в разных ситуациях.

    >Тут дело вкуса, и кто к чему привык/лучше знает.

    Не согласен. Знать надо оба три :-) (ipfw,pf,ipf) чтобы выбрать и использовать лучшее или более подходящее к конкретной ситуации.

     

  • 1.23, DaemonBSD (?), 13:28, 26/10/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    По поводу natd и всяких извратов в несколько сетей во FreeBSD - http://www.it-ramenskoe.ru/freebsd_1.html
     
     
  • 2.27, sdm (??), 14:03, 31/10/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >По поводу natd и всяких извратов в несколько сетей во FreeBSD - http://www.it->ramenskoe.ru/freebsd_1.html

    ну чего вы лажу всякую тут продвигаете!

     
     
  • 3.28, DaemonBSD (?), 10:51, 05/11/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Эта "лажа" как раз и работает без всяких проблем.
    А если у Вас есть Ваша "не лажа" - будьте добры поделиться с остальными (В чем я сильно сомневаюсь ...)
     

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



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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