The OpenNET Project / Index page

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

03.05.2007 15:55  Руководство по пакетному фильтру pf

В учебнике BSD дописан раздел посвящённый пакетному фильтру OpenBSD. Данный раздел не является только переводом документации с официального сайта. Текст переработан и дополнен из других источников, снабжён собственными примерами.

В качестве примера на интеграцию пакетного фильтра с прочим программным окружением, показано как при помощи PF, syslog, python и SQLite осуществить защиту от bruteforce атак на SSH.

  1. Главная ссылка к новости (http://house.hcn-strela.ru/BSD...)
Автор новости: Евгений Миньковский
Тип: яз. русский / Практикум
Ключевые слова: pf, firewall
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение Ajax/Линейный | Раскрыть все сообщения | RSS
 
  • 1.1, glyph (?), 16:37, 03/05/2007 [ответить] [показать ветку] [···]    [к модератору]
  • +/
    Сообщения об опечатках высланы с помощью "Орфус".
     
     
  • 2.6, Евгений Миньковский (?), 18:24, 03/05/2007 [^] [ответить]    [к модератору]
  • +/
    Спасибо. Исправления появятся в следующем релизе.
     
  • 1.2, zedis (?), 17:31, 03/05/2007 [ответить] [показать ветку] [···]    [к модератору]
  • +/
    >pass in on fxp0 proto tcp from any to any port ssh flags S/SA
    >Приведённое правило пропускает весь TCP трафик c установленным флагом SYN, при >этом изучаются флаги SYN и ACK. Пакет с флагами SYN и ECE будет пропущен данным >правилом, а пакет в котором выставлены флаги SYN и ACK или просто ACK не будет >пропущен.

    Что за бред собачий сам это проверял с помощью hping'a - пакетного генератора.
    Правило flags S/SA указывает на то что пропускаем все пакеты с флагами S и/или SA но не как не запрещаем, а вот пакет с флагами SYN и ECE точно не попадёт под это правило. автор ошибся грубо.

     
     
  • 2.4, eugene (??), 18:10, 03/05/2007 [^] [ответить]     [к модератору]
  • +/
    Это Вы грубо ошиблись, автор совершенно прав Комбинация S SA обозначает что про... весь текст скрыт [показать]
     
  • 2.5, Евгений Миньковский (?), 18:22, 03/05/2007 [^] [ответить]     [к модератору]  
  • +/
    Вот выдержка из man pf conf 5 flags a b 124 b This rule on... весь текст скрыт [показать]
     
     
  • 3.41, Unknown user (?), 14:34, 04/05/2007 [^] [ответить]     [к модератору]  
  • +/
    драматически изменилось Не надо так писать Не надо засорять русский язык, эт... весь текст скрыт [показать]
     
  • 1.3, Alter (??), 17:59, 03/05/2007 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Очень хотелось бы в PDF'е весь документ увидеть.
     
     
  • 2.7, Евгений Миньковский (?), 18:30, 03/05/2007 [^] [ответить]     [к модератору]  
  • +/
    Это отвлечёт меня не менее чем на месяц от написания текста Текст, для меня пре... весь текст скрыт [показать]
     
     
  • 3.11, автор (?), 20:02, 03/05/2007 [^] [ответить]    [к модератору]  
  • +/
    гм, вы вручную html верстаете? docbook не подходит? там напрягаться осбо не надо, хочешь хтмл, хочешь пдф, хочешь еще что...
     
     
  • 4.12, Евгений Миньковский (?), 20:55, 03/05/2007 [^] [ответить]     [к модератору]  
  • +/
    Это вам только кажется, что в dobook так всё просто Надо вбухать в его руссифик... весь текст скрыт [показать]
     
     
  • 5.22, nobody (??), 09:59, 04/05/2007 [^] [ответить]    [к модератору]  
  • +/
    русификация занимает от силы 5 мин (xml версия docbook'а), проверено на собственном опыте
     
     
  • 6.26, Евгений Миньковский (?), 10:19, 04/05/2007 [^] [ответить]    [к модератору]  
  • +/
    Хорошо, давайте спишемся через мыло. Помогите мне и будет всем PDF. Моё мыло приведено на первой странице моей писанины: http://house.hcn-strela.ru/BSDCert/BSDA-course/index.html на самом верху.
     
  • 2.43, Дмитрий Ю. Карпов (?), 16:00, 04/05/2007 [^] [ответить]    [к модератору]  
  • +/
    Есть стандартный формат - HTML. Можете преобразовывать его во что угодно.
     
  • 1.8, x0r (?), 18:54, 03/05/2007 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    орфографическая ошибка на "главной"?!

    -- организовать сертификационный экзамен по черырём ->вериям<- систем BSD

     
  • 1.9, s_dog (??), 19:33, 03/05/2007 [ответить] [показать ветку] [···]    [к модератору]  
  • +/

    [url://Sgibnev-CARP-2006]
        2006. Сгибнев Михаил. hping2. http://www.opennet.ru/base/net/carp_freebsd.txt.html .

    Должно быть что то, типа:
    [url://Sgibnev-CARP-2006]
        2006. Сгибнев Михаил. CARP(4) Руководство по интерфейсам ядра FreeBSD .
    http://www.opennet.ru/base/net/carp_freebsd.txt.html .

     
     
  • 2.13, Евгений Миньковский (?), 21:00, 03/05/2007 [^] [ответить]    [к модератору]  
  • +/
    Спасибо. Будет исправлено в следующем релизе.
     
  • 1.10, Charon (??), 19:37, 03/05/2007 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    а мне в целом понравилось, хотя чувствуется некоторая незаконченность.
     
  • 1.14, Дохтур (?), 23:58, 03/05/2007 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    не освещены вопросы:
    1)"покраски" трафика (DSCP/IP Precedence)
    2)пропуска через NAT pptp/sip-клиентов.
    3)hfsc, управление задеркой и джиттером

    (это то что после беглого просмотра заметил).

     
  • 1.15, zulin (??), 01:20, 04/05/2007 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    ого. вот это труд. спасибо, очень кстати
     
  • 1.16, Аноним (-), 01:26, 04/05/2007 [ответить] [показать ветку] [···]     [к модератору]  
  • +/
    2 Евгений Миньковский Хочу добавить, что непосредственно в самом учебнике основн... весь текст скрыт [показать]
     
     
  • 2.25, Евгений Миньковский (?), 10:14, 04/05/2007 [^] [ответить]     [к модератору]  
  • +/
    Боюсь, что это неизбежно к тому моменту, когда я всё допишу, BSD уже выкинут ... весь текст скрыт [показать]
     
  • 1.17, Аноним (-), 01:32, 04/05/2007 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Автору Огромное спасибо!
     
     
  • 2.18, vehn (?), 05:30, 04/05/2007 [^] [ответить]    [к модератору]  
  • +/
    да-да, за работу мегареспект, спасибо огромное
     
     
  • 3.19, dimus (??), 07:51, 04/05/2007 [^] [ответить]     [к модератору]  
  • +/
    Очень полезная работа Надеюсь, что у автора все получится Желаю ему удачи А е... весь текст скрыт [показать]
     
     
  • 4.20, northbear (??), 08:40, 04/05/2007 [^] [ответить]     [к модератору]  
  • +/
    Это утверждение касается порядка фильтрации трафика на одном интерфейсе В твоем... весь текст скрыт [показать]
     
     
  • 5.21, GreenX (??), 09:45, 04/05/2007 [^] [ответить]    [к модератору]  
  • +/
    По этому вопросу есть не плохая иллюстрация.
    http://homepage.mac.com/quension/pf/flow.png
     
     
  • 6.23, dimus (??), 10:00, 04/05/2007 [^] [ответить]    [к модератору]  
  • +/
    Спасибо за иллюстрацию и за разъяснения. Вообще, было бы здорово чтобы этот вопрос более подробно освещался в руководстве. Надеюсь, что автор примет это к сведению.
     
  • 5.27, mutronix (?), 10:48, 04/05/2007 [^] [ответить]     [к модератору]  
  • +/
    Интересно, а почему фильтрация пакета происходит в таком порядке Не лучше ли бы... весь текст скрыт [показать]
     
     
  • 6.42, northbear (??), 15:56, 04/05/2007 [^] [ответить]     [к модератору]  
  • +/
    А какая разница Тогда бы точно так же возникали обратные вопросы Мне например... весь текст скрыт [показать]
     
  • 4.24, Евгений Миньковский (?), 10:07, 04/05/2007 [^] [ответить]     [к модератору]  
  • +/
    Было бы странно, если бы это было невозможно ext_if rl0 int_if rl1 nat on ... весь текст скрыт [показать]
     
  • 1.28, muhlik (??), 10:57, 04/05/2007 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Уважаемые господа, я вот сижу на BSD + ipfw, на Linux + iptables, на Windows + ISA. Мне несколько раз приходила мысль перетащить ipfw на pf, но вот что меня смущает... я как начну представлять логику работы, сразу встает вопрос, в чем преимущество пакетного фильтра у которого выигрывает последнее правило? Я что-то никак не уловлю здесь "правильной" философии, ведь если использовать политику "все запрещено кроме разрешенного", то каждый пакет будет проходить все правила... не влияет ли это на скорость обработки... в ipfw я самые часто срабатываемые правила перемещаю наверх и получается что в большинстве случаев у меня пакет обрабатывается всего несколькими правилами...
    Я понимаю что есть "quick"... но что ж применять ко всем правилам его?


     
     
  • 2.29, dimus (??), 11:36, 04/05/2007 [^] [ответить]    [к модератору]  
  • +/
    Лично мне тоже кажется, что такой порядок проверки не самый лучший. Однако, если верить тестам, при больших нагрузках pf показывает себя лучше, чем ipfw, идя примерно наравне с iptables.
     
  • 2.30, Евгений Миньковский (?), 11:47, 04/05/2007 [^] [ответить]    [к модератору]  
  • +/
    Да, вы правы, такой порядок обработки правил снижает производительность брандмауера, хотя и весьма незначительно. Производительность пакетного фильтра всё равно выше, чем у ipfw (лично не проверял, пересказываю чужое мнение), повидимому за счёт более грамотного проектирования.

    Да, можно применять quick ко всем правилам. Неуклюже выглядит, согласен.

    Можно при засасывании правил пременять команду
    pfctl -oo -f /etc/myrules
    При этом, теоретически, правило quick расставится само и логика будет примерно как у iptables (который и сам обладает рядом недостатков, хотя и не в этом месте).

    Наконец, не грех было бы задаться вопросом так ли вам нужна оптимизация? Дональд Кнут говорил: "преждевременная оптимизация - корень всех бед". Маловероятно, что ваш брандмауер работает на 486-й машине. В самом ли деле ваша полоса пропускания страдает от производительности брандмауера? Может быть, если у вас всё работает, то уже пора оставить всё как есть? :)

     
     
  • 3.31, Евгений Миньковский (?), 11:51, 04/05/2007 [^] [ответить]    [к модератору]  
  • +/
    Да, и ещё: все пакеты всё равно сразу направляются в state-table (в отличие от iptables, где об этом надо ещё позаботиться). Поэтому основная масса пакетов вообще не пойдёт на правила фильтрации. Видимо это обстоятельство переводит данный диспут из разряда практического в разряд академического.
     
     
  • 4.33, dimus (??), 12:04, 04/05/2007 [^] [ответить]    [к модератору]  
  • +/
    При объемах среднего офиса оптимизация шибко не требуется. А вот когда через роутер проходит нехилая часть сети класса Б (естественно, разбитой на подсети), то тут уже начинаешь задумываться...
     
     
  • 5.34, Andrew Kolchoogin (?), 12:24, 04/05/2007 [^] [ответить]    [к модератору]  
  • +/
    > А вот когда через роутер проходит нехилая часть сети класса Б (естественно,
    > разбитой на подсети), то тут уже начинаешь задумываться...
    Которой всей срочно нужно в Интернет через единственную гигабитную кишку, вставленную во второй Ethernet-контроллер этого же роутера?

    Как-то это мне напоминает сферического коня в вакууме. А если через роутер проходит внутрисетевой траффик, то не лучше ли спроектировать сеть так, чтобы в ядре был L3-свитч помощнее?

    Просто как ни оптимизируй программное обеспечение ЭВМ общего назначения, со специализированными ЭВМ с ASIC'ами на борту они всё равно соперничать не смогут, увы.

     
     
  • 6.37, Дохтур (?), 13:32, 04/05/2007 [^] [ответить]    [к модератору]  
  • +/
    >Которой всей срочно нужно в Интернет через единственную гигабитную кишку, вставленную во второй Ethernet-контроллер этого же роутера?

    а зачем тогда этот роутер нужен, если есть гигабитная кошка? :)
    И имхо, на машине с каким-нибудь athlon64 и nic-ми на pcie и гигабит можно зароутить.

     
     
  • 7.39, Andrew Kolchoogin (?), 14:13, 04/05/2007 [^] [ответить]    [к модератору]  
  • +/
    Я не про Cisco. :) Кишка -- это, в смысле, гигабитный канал. ;)
     
  • 4.35, Дохтур (?), 13:22, 04/05/2007 [^] [ответить]    [к модератору]  
  • +/
    >все пакеты всё равно сразу направляются в state-table (в отличие от iptables, где об этом надо ещё позаботиться).

    генерировать стейты по каждому чиху - имхо, дурной тон. И кстати, заботится как раз не надо.
    Ручками заботиться надо именно в том случае, если через nat идёт протокол, нуждающийся в хелпере(вроде того же ftp).

     
  • 3.36, Дохтур (?), 13:28, 04/05/2007 [^] [ответить]    [к модератору]  
  • +/
    >Производительность пакетного фильтра всё равно выше, чем у ipfw (лично не проверял,
    пересказываю чужое мнение), повидимому за счёт более грамотного проектирования.

    категорически неверное высказывание.
    советую посмотреть сюда: http://www.tancsa.com/blast.html

    Гораздо интереснее вот что: умеет ли pf/ipfw на smp-системе раскидывать нагрузку по камням (матчить на разных процессорах)?

     
     
  • 4.49, nuclight (?), 21:15, 04/05/2007 [^] [ответить]    [к модератору]  
  • +/
    >Категорически неверное высказывание. советую посмотреть сюда: http://www.tancsa.com/blast.html

    Угу, ipfw быстрее. Я списался с автором теста, узнать, какие он использовал правила, дабы не было обвинений в намеренном использовании "медленных" фич. Всё было корректно, ответ был таков:

    They were just a bunch of random rules that would not match (e.g

    ipfw add 10 deny log ip from 10.0.0.3 to any
    ipfw add 20 deny log ip from any to 10.0.0.4
    ipfw add 30 deny log tcp from 172.3.3.3 to 10.0.99.4 port 24

    i.e. they were "worst case scenario" rules, and all would need to be evaluated and none would match.

    I plan to re-test in a month or so.

    >Гораздо интереснее вот что: умеет ли pf/ipfw на smp-системе раскидывать нагрузку по камням (матчить на разных процессорах)?

    Насколько мне известно, ipfw умеет работать на разных процессорах, во всяком случае, к параллельной работе он подготовлен. Другое дело, что сейчас это реализовано захватом лока на весь ruleset сразу, соответственно, толку с этого распараллеливания очень мало. Думаю, что в pf дело обстоит не лучше, поскольку в OpenBSD, откуда он пришел, с использованием SMP все плохо.

     
  • 2.45, northbear (??), 16:16, 04/05/2007 [^] [ответить]    [к модератору]  
  • +/
    >Уважаемые господа, я вот сижу на BSD + ipfw, на Linux +
    >iptables, на Windows + ISA. Мне несколько раз приходила мысль перетащить
    >ipfw на pf, но вот что меня смущает... я как начну
    >представлять логику работы, сразу встает вопрос, в чем преимущество пакетного фильтра
    >у которого выигрывает последнее правило? Я что-то никак не уловлю здесь
    >"правильной" философии, ведь если использовать политику "все запрещено кроме разрешенного", то
    >каждый пакет будет проходить все правила... не влияет ли это на
    >скорость обработки... в ipfw я самые часто срабатываемые правила перемещаю наверх
    >и получается что в большинстве случаев у меня пакет обрабатывается всего
    >несколькими правилами...
    >Я понимаю что есть "quick"... но что ж применять ко всем правилам
    >его?

    Да, мне тоже было по началу тяжеловато после ipfw. Но, когда я свел три страницы правил ipfw в пол страницы правил pf, я это оценил.
    Просто в pf по началу многие действуя по старой привычке  все сначала все запрещают, а потом а потом начинают разрешать и это превращается в черт знает что.

    А, для начала, более правильный подход, сначала все разрешить, а потом отрезать то, что не нужно. наверняка не нужно. Причем нет необходимости писать громоздкие правила. Пишешь кучу мелких с конкретным  критерием привязанным к конкретному типу трафика. И quick используешь конкретно для тех правил, которые дальше точно нет смысла смотреть.

     
     
  • 3.51, Евгений Миньковский (?), 09:26, 05/05/2007 [^] [ответить]    [к модератору]  
  • +/
    Ох уж вы и насоветуете: сначала всё разрешить. Этож надо!

    Значит так: сначала читаем документацию с примерами.
    Затем, критически относимся к чужим советам в форуме (это всё советы злобных кракеров, которые будут вас ломать:)!)

     
  • 3.52, Осторожный (?), 10:09, 07/05/2007 [^] [ответить]    [к модератору]  
  • +/
    >Да, мне тоже было по началу тяжеловато после ipfw. Но, когда я
    >свел три страницы правил ipfw в пол страницы правил pf, я
    >это оценил.
    >Просто в pf по началу многие действуя по старой привычке  все
    >сначала все запрещают, а потом а потом начинают разрешать и это
    >превращается в черт знает что.
    >
    >А, для начала, более правильный подход, сначала все разрешить, а потом отрезать
    >то, что не нужно. наверняка не нужно. Причем нет необходимости писать
    >громоздкие правила. Пишешь кучу мелких с конкретным  критерием привязанным к
    >конкретному типу трафика. И quick используешь конкретно для тех правил, которые
    >дальше точно нет смысла смотреть.

    Правильный подход - это когда первое правило

    block all

    а дальше разрешаем что нужно

    А firewall который работает по принципу - запрещать что не нужно - это дуршлаг называется а не firewall :)

     
  • 1.32, Andrew Kolchoogin (?), 12:02, 04/05/2007 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    > Наконец, не грех было бы задаться вопросом так ли вам нужна оптимизация?
    > Дональд Кнут говорил: "преждевременная оптимизация - корень всех бед".
    > Маловероятно, что ваш брандмауер работает на 486-й машине. В самом ли деле
    > ваша полоса пропускания страдает от производительности брандмауера?
    > Может быть, если у вас всё работает, то уже пора оставить всё как есть? :)
    Золотые слова! Автору респект!

    А вот про FTP информация неполная. Не хочу вмешиваться в стиль изложения автора, но на порт ftp/ftpsesame рекомендую обратить внимание.

    Беглый просмотр доки показал, что функциональность этого порта смержена в OpenBSD'шный ftp-proxy. Для FreeBSD рекомендуется использовать этот порт вместо проксирования, особенно, когда по тем или иным причинам не хочется NAT'ить FTP-траффик (или проксировать его).

     
  • 1.38, proks (?), 13:55, 04/05/2007 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Возможно ли при помощи PF nat-ить на "внутреннем" интерфейсе, на котором установлен еще и маршрутизируемый ip ?
     
     
  • 2.40, Andrew Kolchoogin (?), 14:15, 04/05/2007 [^] [ответить]    [к модератору]  
  • +/
    > Возможно ли при помощи PF nat-ить на "внутреннем" интерфейсе, на котором установлен
    > еще и маршрутизируемый ip ?
    Насколько я понимаю, нет. Можно использовать LoopBack, на манер Cisco'вских маршрутизаторов.
     
  • 2.44, northbear (??), 16:04, 04/05/2007 [^] [ответить]    [к модератору]  
  • +/
    >Возможно ли при помощи PF nat-ить на "внутреннем" интерфейсе, на котором установлен
    >еще и маршрутизируемый ip ?

    А нельзя ли поподробней. Что такое "маршрутизируемый ip"?

     
     
  • 3.46, Andrew Kolchoogin (?), 17:22, 04/05/2007 [^] [ответить]    [к модератору]  
  • +/
    Видимо, не перечисленный в RFC1918 :)
     
     
  • 4.47, proks (?), 17:53, 04/05/2007 [^] [ответить]    [к модератору]  
  • +/
    Имел ввиду приватные

    3. Private Address Space

       The Internet Assigned Numbers Authority (IANA) has reserved the
       following three blocks of the IP address space for private internets:

         10.0.0.0        -   10.255.255.255  (10/8 prefix)
         172.16.0.0      -   172.31.255.255  (172.16/12 prefix)
         192.168.0.0     -   192.168.255.255 (192.168/16 prefix)

     
  • 4.48, proks (?), 17:56, 04/05/2007 [^] [ответить]    [к модератору]  
  • +/
    Именно так
     
     
  • 5.50, northbear (??), 21:16, 04/05/2007 [^] [ответить]    [к модератору]  
  • +/
    В таком случае, можно. Не вижу в чем тут может быть сложность.
     

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


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