В статье (http://kes.net.ua/softdev/advanced_firewall.html) рассказано как упростить настройку межсетевого экрана на базе ipfw.
Затронуты темы настройки пайпов и очередей.URL: http://kes.net.ua/softdev/advanced_firewall.html
Новость: http://www.opennet.me/opennews/art.shtml?num=16676
Упростить настройку ipfw очень просто... достаточно всего лишь заменить его pf %)
>Упростить настройку ipfw очень просто... достаточно всего лишь заменить его pf %)сам больше 2х лет использовал pf, пока не столкнулся с проблемой динамического создания и удаления очередей, фильтрации по маске пакета, удобного интерфейса для редактирования правил из скриптов и тд, чего нет в pf.
pf больше подходит для простых правил, поэтому и кажется что он проще...
>>Упростить настройку ipfw очень просто... достаточно всего лишь заменить его pf %)
>
>сам больше 2х лет использовал pf, пока не столкнулся с проблемой динамического
>создания и удаления очередей, фильтрации по маске пакета, удобного интерфейса для
>редактирования правил из скриптов и тд, чего нет в pf.
>pf больше подходит для простых правил, поэтому и кажется что он проще...Фильтрация по маске пакета - это что ?
Удобный интерфейс для редактирования правил из скриптов - что именно не так в pf ?
> Фильтрация по маске пакета - это что ?Это я сканкретизировал часть задачи, которую недавно приходилось решать, - а именно перенаправление пакетов в диверт сокет, с последующим анализм в своей софтине. В общем диверта в pf нет.
> Удобный интерфейс для редактирования правил из скриптов - что именно не так в pf ?
Сможете проще для pf придумать?:
#!/usr/bin/perl
system ("ipfw add ...");или
#!/bin/sh
ipfw add ...
>> Фильтрация по маске пакета - это что ?
>
>Это я сканкретизировал часть задачи, которую недавно приходилось решать, - а именно
>перенаправление пакетов в диверт сокет, с последующим анализм в своей софтине.
>В общем диверта в pf нет.нет
>[оверквотинг удален]
>
>Сможете проще для pf придумать?:
>
>#!/usr/bin/perl
>system ("ipfw add ...");
>
>или
>
>#!/bin/sh
>ipfw add ...Ха!
А что именно нужно сделать-то ? Какая стоит конкретная задача ?В pf есть анхоры
1) модифицируем anchor.conf
2) pfctl -a myanchor -f anchor.confИли же вообще можно ограничится модификацией таблиц
pfctl -t mytable -T add 1.2.3.4
>А что именно нужно сделать-то ? Какая стоит конкретная задача ?
>В pf есть анхоры
>1) модифицируем anchor.conf
>2) pfctl -a myanchor -f anchor.conf
>
>Или же вообще можно ограничится модификацией таблиц
>pfctl -t mytable -T add 1.2.3.4Я и говорю - pf лучше подойдет для простых правил. )))
В том, что вы написали сразу виден недостаток:
1) Для того, чтобы добавлять правила в якорь - необходимо этот якорь создать, а это править файл руками. Если подцеплять все правила от разных пользователей на один (ранее созданный) якорь - со временем невозможно будет разгребсти этот мусор.
2) Ок, а с шейпером как поступить, для него якорей не насоздаешь?
Ну почему для простых-то ?
Хоть в pf, хоть в ipfw написать можно ЛЮБЫЕ правила !
Вопрос в том, где проще будет скрипт для управления.
Но пока неизвестно какую задачу решает скрипт спорить можно бесконечно.
Вот если будет конкретная задача - там можно предметно говорить.
Я не вижу проблем - скрипт можно сделать для ipfw и для pf.1)
Якорь создается один раз в файле pf.conf
Потом все нужные правила добавляются в этот один якорь.
Правила записанные в якорь храним в файле myrule.conf
Правим скриптом файл, потом перегружаем якорь.Можно без якоря - править файл pf.conf
Но скорее все этого не нужно.Я понимаю, что в ipfw подкупает наличие номеров.
Можно вставлять куда угодно что угодно.Насчет мусора - а что если в ipfw добавлять правила, то со временем мусор там не образуется ? Следить надо в любом случаа за тем что добавляется и для чего,
а также процедуру удаления предусмотреть.
Какая конкретная задача решается ?
Или это большой секрет ?2)
С шейпером не знаю как, ибо в pf с ним не работал :)
> Это я сканкретизировал часть задачи, которую недавно приходилось решать, - а именно перенаправление пакетов в диверт сокет, с последующим анализм в своей софтине. В общем диверта в pf нет.Вообще divert был придуман в FreeBSD чтобы как-то сделать natd
И является скорее затычкой, чем полезной вещью: например в частности из-за того что пакеты из kernel-space передаются в user-level-space и обратно.Какой именно анализ выполняется в свой софтине ?
> Какой именно анализ выполняется в свой софтине ?Защита от рассылки спама из клиентских сетей - проверяет, чтобы все smtp подключения были с авторизацией, иначе - дропает.
если не секрет, можно узнать как Вы это делаете?
>если не секрет, можно узнать как Вы это делаете?не секрет: при подключении на 25 порт подключения заварачиваются на divert сокет демона, который в свою очередь сам конектится к данному серваку (информаци об ip извлекается из заголовка пакета), выполняя роль прозрачной прокси. дальше тупо парсится smtp протокол и если до отправки пользователем команды data не была пройдена аутентификация - связь с сервером рвется, а клиенту иметируется сообщение об ошибке.
Я делаю проще и тупее
1) 25 порт наружу запрещен (только mailserver может слать почту на 25-ый порт)
2) А клиенты шлют на smtps или submission
Или еще лучше - через mailserver, который еще и проверит почту
3) В вашем случае клиент не сможет сделать START TLS на 25 порту
Это как-то обрабатывается ?4) Если уже клиент может слать почту с помощью SMTP AUTH на удаленный сервер
то кто ему мешает сделать это через SSL ?5) И потом давать клиенту слать ключ открытым текстом - явно ведет к нарушению security.
У меня postfix настроен так, что фича SMTP AUTH работает ТОЛЬКО если соединение ведется через SSL !
Обычный SMTP не сможет сделать SMTP AUTH.
так сделано у 90% провайдеров. START TLS приравнивается к прохождению аутентификации, а другие порты никак не обрабатываются, метод аутентификации выбирает сам клиент - клиенту, в случае, если у него ноутбук нет необходимости постоянно перепрописывать сервера. за год работы ниодной жалобы от клиентов и на abuse@, - а все потому-что нет спамботов поддерживающих ssl.>5) И потом давать клиенту слать ключ открытым текстом - явно ведет к нарушению security.
>У меня postfix настроен так, что фича SMTP AUTH работает ТОЛЬКО если соединение ведется >через SSL !
>Обычный SMTP не сможет сделать SMTP AUTH.Тут вы, скорее всего, недоконца сами понимаете о чем говорите.
>[оверквотинг удален]
>другие порты никак не обрабатываются, метод аутентификации выбирает сам клиент -
>клиенту, в случае, если у него ноутбук нет необходимости постоянно перепрописывать
>сервера. за год работы ниодной жалобы от клиентов и на abuse@,
>- а все потому-что нет спамботов поддерживающих ssl.
>
>>5) И потом давать клиенту слать ключ открытым текстом - явно ведет к нарушению security.
>>У меня postfix настроен так, что фича SMTP AUTH работает ТОЛЬКО если соединение ведется >через SSL !
>>Обычный SMTP не сможет сделать SMTP AUTH.
>
>Тут вы, скорее всего, недоконца сами понимаете о чем говорите.
>>5) И потом давать клиенту слать ключ открытым текстом - явно ведет к нарушению security.
>>У меня postfix настроен так, что фича SMTP AUTH работает ТОЛЬКО если соединение ведется >через SSL !
>>Обычный SMTP не сможет сделать SMTP AUTH.
>
>Тут вы, скорее всего, недоконца сами понимаете о чем говорите.1) SMTP AUTH шлет пароль открытым текстом. Это опасно.
Насчет этого надеюсь вопросов нет ? :)2) man posfix
# When TLS encryption is optional in the Postfix SMTP server,
# do not announce or accept SASL authentication over unencrypted connections.
#
smtpd_tls_auth_only = yesКлиент подключается к серверу и делает EHLO/HELO.
В ответ получает список фич сервера.
Если соединение ведется без SSL, то сервер не сообщает что есть SMTP AUTH.
Если соединение ведется через SSL, то сервер сообщает что есть SMTP AUTH.И чего я тут не понимаю ? ;)
А что то поумнее сказать? :-)
>А что то поумнее сказать? :-)к вам это тоже относится...
и ко мне относится...
в общем стена там <----
пошли...
в статье анахронизмы вперемешку с откровенными ошибками.>Некоторые могут возразить что мол мы не можем контролировать входящий поток.
>Я отвечу что можем! Наверное Вы просто ребята не читали работу протокола TCP/IP.это вообще шедевр.
>То что можно сделать, так это перенаправлять входящий трафик клиентам по очереди, таким образом разделив канал поровну между ними. Также можно ограничить потребление некоторым клиентом не более K% трафика.
браво. а повесить шейпер исходящего трафика на интерсфейс, смотрящий в сторону клиента никак?
Да и использовать natd - бред.
>в статье анахронизмы вперемешку с откровенными ошибками.
>
>>Некоторые могут возразить что мол мы не можем контролировать входящий поток.
>>Я отвечу что можем! Наверное Вы просто ребята не читали работу протокола TCP/IP.
>
>это вообще шедевр.Криво выражено, но по сути верно. Вешать шейпинг на вход - полностью логически эквивалентно поставить перед входом еще один роутер, на исходе которого к нам шейпить. Да, это никак не повлияет на забитость канала теми пакетами, которые уже пришли (особенно если флуд какой). Но в случае конкнетно tcp, составляющего обычно бОльшую часть трафика - скорость выровняется спустя некоторое время, по подстройке отправителя к скорости возвращаемых ACK'ов.
>>То что можно сделать, так это перенаправлять входящий трафик клиентам по очереди, таким образом разделив канал поровну между ними. Также можно ограничить потребление некоторым клиентом не более K% трафика.
>
>браво. а повесить шейпер исходящего трафика на интерсфейс, смотрящий в сторону клиента
>никак?Это чисто на того клиента. Пример же приводился и для случая, если софтины-клиенты есть и на самом роутере (а почему бы им не взяться, скажем, на домашнем сервере, выполняющем заодно и роль софт-роутера?), для которых исходящего трафика никакого вовсе не будет.
Единственное, что не смог сделать с natd - keep-state правило.
>Единственное, что не смог сделать с natd - keep-state правило.http://nuclight.livejournal.com/124348.html (http://www.opennet.me/opennews/art.shtml?num=16080)
до кучи
http://michurin.com.ru/bsd-ipfw.shtml
рассказ для тех, кто не знает, что такое ipfw, но хочет начать его использовать сразу после прочтения статьи
Блин, режет глаз слово "ложить". И опечатки. И вообще...Вся тема про недостаток ALTQ мягко говоря спорная. Возможно кому то и захочется шейпить входящий трафик, но только в очень экзотических целях. И фраза про разделение входящего канала поровну - технически не грамотная. Можно создать иллюзию придерживая часть трафика, но к каналу это не имеет отношения.
> Возможно кому то и захочется шейпить входящий трафик, но только в очень экзотических
> целях._Шейпить_ входящий трафик _нельзя_. Его можно только _резать_.
Это "альфа" и "омега" всего управления трафиком в TCP/IP-сетях. Распоряжаться можно только _своей_ жо... ой, то есть, управлять можно только _своим_ трафиком. То есть, исходом. На вход повлиять нельзя _никак_. Да хоть весь вход пакетным фильтром в /dev/null сливайте -- да пожалуйста, хоть сто раз. Канал у вас по входу как на полке был, так на полке и останется (это я в вашу сторону "ping -f" пустил :).
Да, можно влиять на вход, шейпя исход: TCP -- протокол с подтверждением приема, PUSH'и не будут идти со скоростью, превышающей скорость ACK'ов. Но это _частный_ случай. UDP так не пошейпить.
И до тех пор, пока такие вот безграмотные статьи будут появляться в Интернете, будут жить системные администраторы класса "набрали по объявлениям".
:-\
>> Возможно кому то и захочется шейпить входящий трафик, но только в очень экзотических
>> целях.
>
> _Шейпить_ входящий трафик _нельзя_. Его можно только _резать_.Под входящим тут имеется в виду не тот трафик, который идет в интерфейс, а тот, который пришел, но еще не передан на обработку. Почему его "_нельзя_" зашейпить? Можно. Только криво это и с трудом можно придумать этому оправдание. О чем и речь.
> Под входящим тут имеется в виду не тот трафик, который идет в
> интерфейс, а тот, который пришел, но еще не передан на обработку.
> Почему его "_нельзя_" зашейпить?Потому что. Его можно только заполисить. Не передать на дальнейшую обработку, если он транзитный. Но _каналам_ твоим от этого ни горячо, ни холодно.
> Можно.
Нельзя.
> Только криво это и с трудом можно придумать этому оправдание. О чем и речь.
Речь о безграмотности автора статьи. :)
>> Возможно кому то и захочется шейпить входящий трафик, но только в очень экзотических
>> целях.
>
> _Шейпить_ входящий трафик _нельзя_. Его можно только _резать_.входящий траффик можно шейпить, если он уже пришел, он еще не отдан далее на обработку
- например в локальную сеть>
>
> Это "альфа" и "омега" всего управления трафиком в
>TCP/IP-сетях. Распоряжаться можно только _своей_ жо... ой, то есть, управлять можно
>только _своим_ трафиком. То есть, исходом. На вход повлиять нельзя _никак_.
>Да хоть весь вход пакетным фильтром в /dev/null сливайте -- да
>пожалуйста, хоть сто раз. Канал у вас по входу как на
>полке был, так на полке и останется (это я в
>вашу сторону "ping -f" пустил :).тем не менее твои входящие ping можно ограничить по скорости
- с какой скоростью они будут попадать на мой интерфейс>[оверквотинг удален]
> Да, можно влиять на вход, шейпя исход: TCP
>-- протокол с подтверждением приема, PUSH'и не будут идти со скоростью,
>превышающей скорость ACK'ов. Но это _частный_ случай. UDP так не пошейпить.
>
>
> И до тех пор, пока такие вот безграмотные
>статьи будут появляться в Интернете, будут жить системные администраторы класса "набрали
>по объявлениям".
>
> :-\ха-ха
> тем не менее твои входящие ping можно ограничить по скорости
> - с какой скоростью они будут попадать на мой интерфейсНет. (C) Фарид Вагапов, если тут еще хоть кто-то помнит, кто это такой.
Я зуб даю с пломбой, что мои пинги будут попадать на твой интерфейс ровно с той скоростью, с которой я их посылаю. Не быстрее, и не медленнее.
Это они в твой TCP/IP-стек могут не попадать. Но _каналу_ от этого легче не станет. Dixi.
>> тем не менее твои входящие ping можно ограничить по скорости
>> - с какой скоростью они будут попадать на мой интерфейс
>
> Нет. (C) Фарид Вагапов, если тут еще хоть
>кто-то помнит, кто это такой.
>
> Я зуб даю с пломбой, что мои пинги
>будут попадать на твой интерфейс ровно с той скоростью, с которой
>я их посылаю. Не быстрее, и не медленнее.Вот зуб не надо.
По дороге между источником ping-ом и firewall многое может случиться
- например их может drop-нуть или задержать проходящий роутер.>
> Это они в твой TCP/IP-стек могут не попадать.
>Но _каналу_ от этого легче не станет. Dixi.Каналу легче не станет, но про канал речи и не было вовсе.
>> Я зуб даю с пломбой, что мои пинги
>> будут попадать на твой интерфейс ровно с той скоростью, с которой
>> я их посылаю. Не быстрее, и не медленнее.
> Вот зуб не надо.
> По дороге между источником ping-ом и firewall многое может случиться
> - например их может drop-нуть или задержать проходящий роутер.Угу, или не справиться мой TCP/IP-стек посылать пакеты с такой скоростью, чтобы выложить _мой_ канал на полку. :)
Разумеется, имелся в виду ping flood с directly-connected router'а.
>тем не менее твои входящие ping можно ограничить по скорости
>- с какой скоростью они будут попадать на мой интерфейс
>Бгы гы
Ограничивать можно только то что УЖЕ пришло.
Ограничивать "скорость попадания на твой интерфейс" можно только на вышестоящем роутере.
Почитал бы ты что-нибудь о защите от DDOS-атак что ли.
>[оверквотинг удален]
> Да, можно влиять на вход, шейпя исход: TCP
>-- протокол с подтверждением приема, PUSH'и не будут идти со скоростью,
>превышающей скорость ACK'ов. Но это _частный_ случай. UDP так не пошейпить.
>
>
> И до тех пор, пока такие вот безграмотные
>статьи будут появляться в Интернете, будут жить системные администраторы класса "набрали
>по объявлениям".
>
> :-\Андрей прав. Все нижепишущие прочтите разницу между Policing и Shaping.
>[оверквотинг удален]
>>превышающей скорость ACK'ов. Но это _частный_ случай. UDP так не пошейпить.
>>
>>
>> И до тех пор, пока такие вот безграмотные
>>статьи будут появляться в Интернете, будут жить системные администраторы класса "набрали
>>по объявлениям".
>>
>> :-\
>
>Андрей прав. Все нижепишущие прочтите разницу между Policing и Shaping.Ну послал, так послал! :) Но раз не указал, куда идти, то иду куда могу и читаю:
"More specifically, traffic shaping is any action on a set of packets (often called a stream or a flow) which imposes additional delay on those packets such that they conform to some predetermined constraint (a contract or traffic profile).""Traffic policing is the distinct but related practice of packet dropping and packet marking."
> управлять можно
>только _своим_ трафиком. То есть, исходом. На вход повлиять нельзя _никак_.
>Под входящим тут имеется в виду не тот трафик, который идет в интерфейс, а тот, который >пришел, но еще не передан на обработку. Почему его "_нельзя_" зашейпить? Можно. Только >криво это и с трудом можно придумать этому оправдание. О чем и речь.Речь идёт о проходящем трафике, который пришел на интерфейс, и в скором времени уйдет через какой-то другой интерфейс.
В 99% случаев говоря "хочу зашейпить вход" кому-то, имеют ввиду "проходящий трафик" мимо роутера.
т.е. зашейпить вход клиенту - это означает зашейпить на выходе из роутера или на входе в роутер.
ipfw может шейпить этот трафик без проблем, а ALTQ только на выходе.ситуация есть LAN 192.168.1.0/24, 192.168.2.0/24 которые доступны через rl1 и rl2 роутера.
На роутере запущен OSPF и трафик к этим сетям динамически уходит через rl1 или через rl2 в зависимости он загрузки каналов или друхих прочих факторов, которые нам не известны.ipfw легко можно зашейпить трафик к этим сетям собирая пакеты на входе в роутер (rl0):
ipfw pipe 1 config bw 512Kbit/s mask dst-ip 0xffffff00
ipfw add 1 pipe 1 all from any to 192.168.1.0/24 in recv rl0
ipfw add 1 pipe 1 all from any to 192.168.2.0/24 in recv rl0И нас не заботит через какой интерфейс/интерфейсы пойдет пакет дальше.
Реализовать в ALTQ такое невозможно, т.к. на rl2 и rl1 это две разные очереди. И они никак!!! с друг другом "общаться" не смогут. Поэтому если трафик к LAN's будет уходить через rl1 со скорость 128Кбит, то мы не как не сможем зашейпить его на rl2 на скорость 384Кбит/с. А так как трафик будет распределятся между двумя каналами каким-то случайным образом, то я вообще не представляю как можно сделать такое с помощью ALTQ.
В догонку:
http://www.nabble.com/altq-td18171872.html#a23453905
тяжко-то как живётся юзверям:
bw 8Kbytes
все это хорошо, только нарезать четко(плавно) каналы не говоря уже о распределении не получается. Если у когото получилось, то скорее всего человек проверял на искуственном тесте и все, а реально не использовал.
>Например если на интерфейсе висит сеть 192.168.0.0/24, то дропаем всё, что не с этой сети:
>ipfw add 11101 deny all from not 192.168.0.0/24 to any in recv rl0Мдя, бывает.
У ipfw уже кучу лет есть ряд полезных фич типа verrevpath, versrcreach, antispoof.
> У ipfw уже кучу лет есть ряд полезных фич типа verrevpath, versrcreach, antispoof.Лучший способ убить border router:
router>en
Password:
router#conf t
router(config)#int <имя внешнего интерфейса>
router(config-if)#ip verify unicast reverse-path:)))
verrevpath -- зло. :)
Аргументы и факты? Cisco давно рекомендует использовать эту фичу и выполняется она в CEF.
В результате дропаются DHCP-запросы которые идут с адреса 0.0.0.0 to 255.255.255.255
Еще можно следить за адресами, куда идут пакеты
Скажем пакеты из локальной сети 192.168.0.0/24 на адреса 10.0.0.0/8 тоже можно drop-ать ( если у вас нет локальной сети 10.0.0.0/8 )