ipfw and keep-state
Victor Sudakov
Есть набор правил:
00050 divert 8668 ip from any to any via rl0
00220 allow ip from x.x.x.x/27 to y.y.y.y keep-state
00300 deny log logamount 100 ip from x.x.x.x/27 to any out via rl0
00400 deny log logamount 100 ip from any to x.x.x.x/27 in via rl0
65535 allow ip from any to any
Почему может такое происходить, что при попытке установить tcp сессию с
x.x.x.x на y.y.y.y динамическое правило не создаётся и обратные пакеты
режутся 400-м правилом? Это как-то связано с 50-м правилом: если его
убрать, динамическое правило будет создаваться.
Где я торможу? И что можно проделать, кроме явного разрешения обратного
трафика с y.y.y.y ?
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/
Kirill Nuzhdin
> Коллеги,
>
> Есть набор правил:
>
> 00050 divert 8668 ip from any to any via rl0
> 00220 allow ip from x.x.x.x/27 to y.y.y.y keep-state
> 00300 deny log logamount 100 ip from x.x.x.x/27 to any out via rl0
> 00400 deny log logamount 100 ip from any to x.x.x.x/27 in via rl0
> 65535 allow ip from any to any
>
> Почему может такое происходить, что при попытке установить tcp сессию с
> x.x.x.x на y.y.y.y динамическое правило не создаётся и обратные пакеты
> режутся 400-м правилом? Это как-то связано с 50-м правилом: если его
> убрать, динамическое правило будет создаваться.
>
> Где я торможу? И что можно проделать, кроме явного разрешения обратного
> трафика с y.y.y.y ?
а что нат с этими пакетами делает? (x.x.x.x->y.y.y.y)
--
Best regards,
Kirill Nuzhdin
Vadim Guchenko
VS> 00050 divert 8668 ip from any to any via rl0
VS> 00220 allow ip from x.x.x.x/27 to y.y.y.y keep-state
VS> 00300 deny log logamount 100 ip from x.x.x.x/27 to any out via rl0
VS> 00400 deny log logamount 100 ip from any to x.x.x.x/27 in via rl0
VS> 65535 allow ip from any to any
А где check-state?
VS> И что можно проделать, кроме явного разрешения обратного
VS> трафика с y.y.y.y ?
Обратный TCP трафик эффективнее разрешить правилом allow tcp from any to any
established. Динамические правила лучше создавать только для исходящих UDP.
Если сервер с натом является шлюзом для локалки в инет, то смысла для
натовых пакетов создавать динамические правила нет вообще. Сеть за натом
(если там серые адреса) и так защищена. Чтобы правила файрвола стали
простыми и понятными, есть смысл явно разделить обработку входящего и
исходящего трафика. В этом случае на нат будет не один, а два диверта.
--
Best regards, Vadim.
Kirill Nuzhdin
>
> VS> 00050 divert 8668 ip from any to any via rl0
> VS> 00220 allow ip from x.x.x.x/27 to y.y.y.y keep-state
> VS> 00300 deny log logamount 100 ip from x.x.x.x/27 to any out via rl0
> VS> 00400 deny log logamount 100 ip from any to x.x.x.x/27 in via rl0
> VS> 65535 allow ip from any to any
>
> А где check-state?
там же где и первый keep-state
Victor Sudakov
natd настроен транслировать любые RFC1918 адреса в некий публичный
адрес (не в y.y.y.y).
Victor Sudakov
> VS> 00050 divert 8668 ip from any to any via rl0
> VS> 00220 allow ip from x.x.x.x/27 to y.y.y.y keep-state
> VS> 00300 deny log logamount 100 ip from x.x.x.x/27 to any out via rl0
> VS> 00400 deny log logamount 100 ip from any to x.x.x.x/27 in via rl0
> VS> 65535 allow ip from any to any
> А где check-state?
Правило для check-state не обязательно указывать явно. Оно получает тот
же номер, что соответствующее ему keep-state.
Но на самом деле check-state тут совсем не при чём. "ipfw -d list"
показывает, что динамическое правило вообще не создаётся.
> VS> И что можно проделать, кроме явного разрешения обратного
> VS> трафика с y.y.y.y ?
> Обратный TCP трафик эффективнее разрешить правилом allow tcp from any to any
> established. Динамические правила лучше создавать только для исходящих UDP.
Вопрос был не как лучше сделать, а почему не работает данная
конструкция. В ней есть ошибка? Возможно, какой-то неочевидный мне
момент с порядком прохождения пакетов через ipfw?
Насчёт established спорно. Пропускать пакет от кого попало только на
том основании, что на нём есть ACK bit?
Kirill Nuzhdin
очевидно, что
1. правило 50 (именно нат) модифицирует пакеты вида x.x.x.x->y.y.y.y так, что
они перестают попадать под правило from x.x.x.x/27 to y.y.y.y
2. после модификации пакетов, они таки доходят до некоего адресата, ответы
которого попадают под правило 400 from any to x.x.x.x/27 in via rl0
было бы проще ответить на вопрос, если представлять где адреса хххх уууу, из
какой подсети адрес у rl0, как идет интересующий пакет, пришедший на rl0 пакет,
что из хххх и уууу из рфц1918, а что нет
Vadim Guchenko
>> VS> 00050 divert 8668 ip from any to any via rl0
>> VS> 00220 allow ip from x.x.x.x/27 to y.y.y.y keep-state
>> VS> 00300 deny log logamount 100 ip from x.x.x.x/27 to any out via
>> rl0
>> VS> 00400 deny log logamount 100 ip from any to x.x.x.x/27 in via rl0
>> VS> 65535 allow ip from any to any
>> А где check-state?
VS> Правило для check-state не обязательно указывать явно. Оно получает
VS> тот же номер, что соответствующее ему keep-state.
Забыл этот момент. Обычно я явно указываю check-state.
VS> Вопрос был не как лучше сделать, а почему не работает данная
VS> конструкция. В ней есть ошибка? Возможно, какой-то неочевидный мне
VS> момент с порядком прохождения пакетов через ipfw?
Вероятно при попытке установить соединение с хостом y.y.y.y нат заменяет в
исходящем пакете src_ip на некий публичный адрес, не входящий в подсеть
x.x.x.x/27, поэтому правило 220 не срабатывает.
VS> Насчёт established спорно. Пропускать пакет от кого попало только на
VS> том основании, что на нём есть ACK bit?
А чем это хуже ситуации с динамическими правилами?
--
Best regards, Vadim.
Alex Mogilnikov
19 Jul 07 11:11, Victor Sudakov писал All:
VS> 00050 divert 8668 ip from any to any via rl0
VS> 00220 allow ip from x.x.x.x/27 to y.y.y.y keep-state
VS> Почему может такое происходить, что при попытке установить tcp сессию
VS> с x.x.x.x на y.y.y.y динамическое правило не создаётся и обратные
VS> пакеты режутся 400-м правилом? Это как-то связано с 50-м правилом:
VS> если его убрать, динамическое правило будет создаваться.
Потому что порядок операций у тебя несимметричен: в одном направлении
правилом проверяется реальный адрес, а в обратном - транслированный. Или
наоборот, смотря где кто находится. По идее, надо делать два разных
divert-правила для "туда" и для "обратно", чтобы проверка адресов оказалась
между ними.
Всего наилучшего, [Team PCAD 2000]
Алексей М.
... в манах то любой ламмер прочитать сможет (c) Andrew Wingorodov
Vadim Goncharov
On Thu, 19 Jul 2007 08:48:41 +0000 (UTC); Victor Sudakov wrote about 'Re: ipfw and keep-state':
>> Обратный TCP трафик эффективнее разрешить правилом allow tcp from any to any
>> established. Динамические правила лучше создавать только для исходящих UDP.
VS> Вопрос был не как лучше сделать, а почему не работает данная
VS> конструкция. В ней есть ошибка? Возможно, какой-то неочевидный мне
VS> момент с порядком прохождения пакетов через ipfw?
VS> Насчёт established спорно. Пропускать пакет от кого попало только на
VS> том основании, что на нём есть ACK bit?
Ну, допустим, что в обычных условиях так теоретически можно нахакерить.
Но за NAT-то с чего? Так что в этом случае вполне можно.
--
WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_n...@mail.ru
[Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]
Vadim Goncharov
On Thu, 19 Jul 2007 07:11:35 +0000 (UTC); Victor Sudakov wrote about 'ipfw and keep-state':
VS> Есть набор правил:
VS> 00050 divert 8668 ip from any to any via rl0
VS> 00220 allow ip from x.x.x.x/27 to y.y.y.y keep-state
VS> 00300 deny log logamount 100 ip from x.x.x.x/27 to any out via rl0
VS> 00400 deny log logamount 100 ip from any to x.x.x.x/27 in via rl0
VS> 65535 allow ip from any to any
VS> Почему может такое происходить, что при попытке установить tcp сессию с
VS> x.x.x.x на y.y.y.y динамическое правило не создаётся и обратные пакеты
VS> режутся 400-м правилом? Это как-то связано с 50-м правилом: если его
VS> убрать, динамическое правило будет создаваться.
VS> Где я торможу?
В порядке прохождения пакетов через ipfw. В данном рулесете каждый пакет
"наружу" попадет в divert 4 раза, правило проверки стоит уже после
диверта, на прохождении в out через него пойдет пакет с уже
оттранслированным адресом. Следует разделить диверты на входе и выходе
и соответственно расположить динамические правила.
У меня это делается примерно вот так:
ipfw add divert natd ip from $graynet to any out xmit $extiface recv $intiface
ipfw add divert natd ip from any to $ext_nat_address in recv $extiface
Vadim Goncharov
On Thu, 19 Jul 2007 08:48:41 +0000 (UTC); Victor Sudakov wrote about 'Re: ipfw and keep-state':
VS>> 00050 divert 8668 ip from any to any via rl0
VS>> 00220 allow ip from x.x.x.x/27 to y.y.y.y keep-state
VS>> 00300 deny log logamount 100 ip from x.x.x.x/27 to any out via rl0
VS>> 00400 deny log logamount 100 ip from any to x.x.x.x/27 in via rl0
VS>> 65535 allow ip from any to any
>> А где check-state?
VS> Правило для check-state не обязательно указывать явно. Оно получает тот
VS> же номер, что соответствующее ему keep-state.
VS> Но на самом деле check-state тут совсем не при чём. "ipfw -d list"
VS> показывает, что динамическое правило вообще не создаётся.
Хм, только сейчас заметил, что keep-state повешен на всё сразу,
возможно, причина не-создания лежит здесь - точнее, оно создается, но
с дефолтным таймаутом в секунду и успевает исчезнуть раньше, чем
придет ответ / будет просмотрен список правил. Впрочем, я тут могу
ошибаться, сначала в любом случае следует разносить диверты.
Victor Sudakov
> >>> Есть набор правил:
> >>>
> >>> 00050 divert 8668 ip from any to any via rl0
> >>> 00220 allow ip from x.x.x.x/27 to y.y.y.y keep-state
> >>> 00300 deny log logamount 100 ip from x.x.x.x/27 to any out via rl0
> >>> 00400 deny log logamount 100 ip from any to x.x.x.x/27 in via rl0
> >>> 65535 allow ip from any to any
> >>>
> >>> Почему может такое происходить, что при попытке установить tcp сессию с
> >>> x.x.x.x на y.y.y.y динамическое правило не создаётся и обратные пакеты
> >>> режутся 400-м правилом? Это как-то связано с 50-м правилом: если его
> >>> убрать, динамическое правило будет создаваться.
> >>>
> >>> Где я торможу? И что можно проделать, кроме явного разрешения обратного
> >>> трафика с y.y.y.y ?
[dd]
> очевидно, что
> 1. правило 50 (именно нат) модифицирует пакеты вида x.x.x.x->y.y.y.y так, что
> они перестают попадать под правило from x.x.x.x/27 to y.y.y.y
Спасибо, так и оказалось.
Victor Sudakov
> >> VS> 00050 divert 8668 ip from any to any via rl0
> >> VS> 00220 allow ip from x.x.x.x/27 to y.y.y.y keep-state
> >> VS> 00300 deny log logamount 100 ip from x.x.x.x/27 to any out via
> >> rl0
> >> VS> 00400 deny log logamount 100 ip from any to x.x.x.x/27 in via rl0
> >> VS> 65535 allow ip from any to any
[dd]
> Вероятно при попытке установить соединение с хостом y.y.y.y нат заменяет в
> исходящем пакете src_ip на некий публичный адрес, не входящий в подсеть
> x.x.x.x/27, поэтому правило 220 не срабатывает.
Так и есть. А как же теперь написать правило с keep-state, чтобы
учесть NAT?
> VS> Насчёт established спорно. Пропускать пакет от кого попало только на
> VS> том основании, что на нём есть ACK bit?
> А чем это хуже ситуации с динамическими правилами?
Теоретически, может случиться ACK flood и firewall не спасет.
Victor Sudakov
> >> Обратный TCP трафик эффективнее разрешить правилом allow tcp from any to any
> >> established. Динамические правила лучше создавать только для исходящих UDP.
> VS> Вопрос был не как лучше сделать, а почему не работает данная
> VS> конструкция. В ней есть ошибка? Возможно, какой-то неочевидный мне
> VS> момент с порядком прохождения пакетов через ipfw?
> VS> Насчёт established спорно. Пропускать пакет от кого попало только на
> VS> том основании, что на нём есть ACK bit?
> Ну, допустим, что в обычных условиях так теоретически можно нахакерить.
> Но за NAT-то с чего? Так что в этом случае вполне можно.
Пожалуй ты прав, NAT сам по себе stateful, особенно с -deny_incoming.
Victor Sudakov
> VS> Есть набор правил:
> VS> 00050 divert 8668 ip from any to any via rl0
> VS> 00220 allow ip from x.x.x.x/27 to y.y.y.y keep-state
> VS> 00300 deny log logamount 100 ip from x.x.x.x/27 to any out via rl0
> VS> 00400 deny log logamount 100 ip from any to x.x.x.x/27 in via rl0
> VS> 65535 allow ip from any to any
> VS> Почему может такое происходить, что при попытке установить tcp сессию с
> VS> x.x.x.x на y.y.y.y динамическое правило не создаётся и обратные пакеты
> VS> режутся 400-м правилом? Это как-то связано с 50-м правилом: если его
> VS> убрать, динамическое правило будет создаваться.
> VS> Где я торможу?
> В порядке прохождения пакетов через ipfw. В данном рулесете каждый пакет
> "наружу" попадет в divert 4 раза,
То так. Однако простейший пример, который я брал из /etc/rc.firewall.
> правило проверки стоит уже после
> диверта, на прохождении в out через него пойдет пакет с уже
> оттранслированным адресом. Следует разделить диверты на входе и выходе
> и соответственно расположить динамические правила.
> У меня это делается примерно вот так:
> ipfw add divert natd ip from $graynet to any out xmit $extiface recv $intiface
> ipfw add divert natd ip from any to $ext_nat_address in recv $extiface
А где должен стоять keep-state относительно этих двух строчек?
Впрочем, keep-state не обязательно, natd сам отсеет ненужный входящий
трафик. Задача в другом - часть пакетов из приватной сети должна уйти
в ipsec, часть пройти через NAT и далее попасть на разрешённый список
хостов в Интернете, а остальной трафик должен быть запрещён.
Andrew Filonov
VS> 00050 divert 8668 ip from any to any via rl0 00220 allow ip from
VS> x.x.x.x/27 to y.y.y.y keep-state 00300 deny log logamount 100 ip
VS> from x.x.x.x/27 to any out via rl0 00400 deny log logamount 100
VS> ip from any to x.x.x.x/27 in via rl0 65535 allow ip from any to
VS> any
VS> Где я торможу?
Ну от тебя я такого не ожидал.
divert port
Divert packets that match this rule to the divert(4) socket bound
to port port. _The search terminates_.
VS> И что можно проделать, кроме явного разрешения обратного трафика
VS> с y.y.y.y ?
ничего.
--
Andrew E. Filonov
No one's life, liberty, or property are safe
while the legislature is in session.
Victor Sudakov
> VS> 00050 divert 8668 ip from any to any via rl0 00220 allow ip from
> VS> x.x.x.x/27 to y.y.y.y keep-state 00300 deny log logamount 100 ip
> VS> from x.x.x.x/27 to any out via rl0 00400 deny log logamount 100
> VS> ip from any to x.x.x.x/27 in via rl0 65535 allow ip from any to
> VS> any
> VS> Где я торможу?
> Ну от тебя я такого не ожидал.
> divert port
> Divert packets that match this rule to the divert(4) socket bound
> to port port. _The search terminates_.
Ну и что, что terminates?
# Network Address Translation. All packets are passed to natd(8)
# before they encounter your remaining rules. The firewall rules
# will then be run again on each packet after translation by natd
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
# starting at the rule number following the divert rule.
Так что проблема была в другом.
Andrew Filonov
VS> Ну и что, что terminates?
А то, что дальше - идет совсем другой пакет.
--
Andrew E. Filonov
The mountain gets steeper as you get closer.
Victor Sudakov
> VS> Ну и что, что terminates?
> А то, что дальше - идет совсем другой пакет.
Я уже все мозги свернул, пытаясь сделать на ipfw нечто вполне
тривиальное с точки зрения циски. Спасибо, что хоть политики IPSec не
через правила ipfw задаются, а то и они путались бы под ногами (про
плохого танцора можешь не напоминать, сам знаю).
Может лучше ipnat задействовать?
Vadim Goncharov
On Fri, 20 Jul 2007 02:38:17 +0000 (UTC); Victor Sudakov wrote about 'Re: ipfw and keep-state':
>>> Обратный TCP трафик эффективнее разрешить правилом allow tcp from any to any
>>> established. Динамические правила лучше создавать только для исходящих UDP.
VS>> Вопрос был не как лучше сделать, а почему не работает данная
VS>> конструкция. В ней есть ошибка? Возможно, какой-то неочевидный мне
VS>> момент с порядком прохождения пакетов через ipfw?
VS>> Насчёт established спорно. Пропускать пакет от кого попало только на
VS>> том основании, что на нём есть ACK bit?
>> Ну, допустим, что в обычных условиях так теоретически можно нахакерить.
>> Но за NAT-то с чего? Так что в этом случае вполне можно.
VS> Пожалуй ты прав, NAT сам по себе stateful, особенно с -deny_incoming.
Я больше имел в виду то, что серые адреса - unrouteable. Левые пакеты на
машины снаружи просто не могут прилететь (разве что из directly-attached
к роутеру сети, но решается включением antispoof или verrevpath в ipfw).
Vadim Goncharov
On Fri, 20 Jul 2007 02:51:48 +0000 (UTC); Victor Sudakov wrote about 'Re: ipfw and keep-state':
VS> То так. Однако простейший пример, который я брал из /etc/rc.firewall.
На то он и простейший... /* вообще говоря, в одном направлении не
4 раза, а 2, это я с обратным пакетом посчитал - но с разделенными
дивертами все равно в 2 раза меньше попаданий и соответственно
переключений контекста */
>> правило проверки стоит уже после
>> диверта, на прохождении в out через него пойдет пакет с уже
>> оттранслированным адресом. Следует разделить диверты на входе и выходе
>> и соответственно расположить динамические правила.
>> У меня это делается примерно вот так:
>> ipfw add divert natd ip from $graynet to any out xmit $extiface recv $intiface
>> ipfw add divert natd ip from any to $ext_nat_address in recv $extiface
VS> А где должен стоять keep-state относительно этих двух строчек?
VS> Впрочем, keep-state не обязательно, natd сам отсеет ненужный входящий
VS> трафик. Задача в другом - часть пакетов из приватной сети должна уйти
VS> в ipsec, часть пройти через NAT и далее попасть на разрешённый список
VS> хостов в Интернете, а остальной трафик должен быть запрещён.
Расположение зависит от того, что тебе нужно. Поскольку (отвечая
на другое письмо) ipfw, в отличие от той же циски, низкоуровневой
файрвол, в нем все такие вещи делаются руками. То есть нужно нарисовать
схему прохождения пакетов, вспомнить, как к ним применяются правила (в
т.ч. динамические). В виду той же низкоуровневости задачу можно решать
более чем одним способом, например можно сразу в divert рулить пакеты на
те сети, которые разрешены (остальное запрещено) без keep-state - пускай
состояния обруливает natd.
Alex Bakhtin
>> Вероятно при попытке установить соединение с хостом y.y.y.y нат заменяет в
>> исходящем пакете src_ip на некий публичный адрес, не входящий в подсеть
>> x.x.x.x/27, поэтому правило 220 не срабатывает.
VS> Так и есть. А как же теперь написать правило с keep-state, чтобы
VS> учесть NAT?
Используй не allow а skipto. Возможно, в сочетании с навешиванием
тега. У меня оно сделано как-то так. Конфиг не полный и до конца не
доработанный (нет времени), но практически все, что мне нужно -
работает. До выхода релиза семерки трогать ничего не буду, скорее всего.
Два аплинка - через ng0 и ng1. Тег навешивается в целях
connection-oriented полиси роутинга. Естественно, one pass выключено.
add 00050 divert 8768 ip from any to any in via ng0
add 00051 divert 8868 ip from any to any in via fxp0
add 00052 divert 8968 ip from any to any in via ng1
add 00100 check-state
add 10001 skipto 50000 tcp from not table(127) to me dst-port 22
setup keep-state
add 10031 skipto 50000 tag 1000 tcp from me to any setup keep-state out via
ng1
add 10032 skipto 50000 tag 2000 tcp from me to any setup keep-state out via
ng0
add 10033 skipto 50000 tcp from me to any setup keep-state
add 50008 skipto 54000 ip from any to any out via ste0
add 50009 skipto 54000 ip from any to any out via ste3
add 50009 skipto 54000 ip from any to any out via fxp1
add 50010 skipto 55000 ip from any to any tagged 1000
add 50011 skipto 55000 ip from table(20) to any
add 50020 skipto 56000 ip from any to any tagged 2000
add 50021 skipto 56000 ip from table(10) to any
add 50100 skipto 51000 ip from any to any out via ng0
add 50110 skipto 52000 ip from any to any out via fxp0
add 50120 skipto 53000 ip from any to any out via ng1
add 50900 allow ip from any to any in via ste0
add 50901 allow ip from any to any in via ste3
add 50901 allow ip from any to any in via fxp1
add 50996 allow ip from any to any in via ng1
add 50997 allow ip from any to any in via ng0
add 50998 allow ip from any to any in via fxp0
add 50999 skipto 65000 ip from any to any
add 51000 divert 8768 ip from any to any out via ng0
add 51001 allow ip from any to any
add 52010 divert 8868 ip from any to any out via fxp0
add 52011 allow ip from any to any
add 53000 divert 8968 ip from any to any out via ng1
add 53021 allow ip from any to any
add 54000 allow ip from any to any
add 55010 allow ip from any to any in via ng1
add 55020 divert 8968 ip from any to any
add 55030 fwd 192.168.2.2 ip from any to any
add 56010 allow ip from any to any in via ng0
add 56020 divert 8768 ip from any to any
add 56030 fwd 192.168.1.1 ip from any to any
add 64999 skipto 65000 ip from any to any
--
Best regards, Alex Bakhtin, CCIE #8439
AMT Group, Cisco Systems Gold Partner, http://www.amt.ru
Valentin Davydov
> Date: Fri, 20 Jul 2007 07:36:26 +0000 (UTC)
>
> >>> Обратный TCP трафик эффективнее разрешить правилом allow tcp from any to any
> >>> established. Динамические правила лучше создавать только для исходящих UDP.
> VS>> Вопрос был не как лучше сделать, а почему не работает данная
> VS>> конструкция. В ней есть ошибка? Возможно, какой-то неочевидный мне
> VS>> момент с порядком прохождения пакетов через ipfw?
> VS>> Насчёт established спорно. Пропускать пакет от кого попало только на
> VS>> том основании, что на нём есть ACK bit?
> >> Ну, допустим, что в обычных условиях так теоретически можно нахакерить.
> >> Но за NAT-то с чего? Так что в этом случае вполне можно.
> VS> Пожалуй ты прав, NAT сам по себе stateful, особенно с -deny_incoming.
>
>Я больше имел в виду то, что серые адреса - unrouteable. Левые пакеты на
>машины снаружи просто не могут прилететь (разве что из directly-attached
>к роутеру сети, но решается включением antispoof или verrevpath в ipfw).
Попробуй запустить трэйс на серый адрес. У меня с одного из роутеров четыре
живых хопа было видно, каждый следующий дефолт для предыдущего.
Вал. Дав.
Vadim Guchenko
>> VS> Насчёт established спорно. Пропускать пакет от кого попало только
>> А чем это хуже ситуации с динамическими правилами?
Попробую рассмотреть все варианты, связанные с TCP.
1. Предположим, некоторый сервер, имеющий реальный адрес, установил
TCP-соединение с удаленным хостом:
local_ip:local_port <-> remote_ip:remote_port
Если никакого файрвола нет, то сервер будет принимать все приходящие
TCP-пакеты. Однако в обработку, в рамках рассматриваемого соединения,
попадут только те пакеты, которые пришли с remote_ip:remote_port на
local_ip:local_port. Остальные пакеты будут отброшены TCP-стеком (либо
обработаны в рамках других активных соединений). После того, как проверка
адресов и портов прошла успешно, анализируются другие поля в TCP-пакете, в
частности sequence number. Если тупо флудить с различных адресов и портов
TCP-пакетами на local_ip:local_port, это ничего не даст, т.к. все пакеты
будут проигнорированы TCP-стеком. Для получения результата флудить нужно
так, чтобы в src_ip был remote_ip, а в src_port - remote_port. Но даже если
и это будет выполнено, встает вопрос об угадывании sequence number, времени
посылки пакета и т.д.
Предположим где-то на шлюзе настроен ipfw с правилом allow tcp from any to
any established. Т.е. он пропускает через себя все TCP-пакеты, кроме
запросов на установку соединения. Ситуация не меняется. Любые TCP-атаки,
включая флуд, будут прозрачно пропущены через ipfw и обработаны
(проигнорированы) TCP-стеком на локальном сервере.
Предположим на шлюзе настроен ipfw, создающий на каждое исходящее
TCP-соединение динамическое правило. Соответственно, ipfw пропустит внутрь
сети только TCP-пакеты вида:
remote_ip:remote_port -> local_ip:local_port
Разница с предыдущими двумя случаями в том, что простой флуд не дойдет до
целевого сервера, а будет отброшен еще на шлюзе с ipfw. Однако
целенаправленная атака, когда подменяются src_ip и src_port, все равно
пройдет через ipfw и дойдет до сервера назначения.
2. Теперь предположим, что сервер, который установил TCP-соединение с
удаленным хостом, имеет серый адрес и находится за натом. Для простоты будем
считать, что нат не меняет номера портов - только ip-адреса:
local_ip:local_port <-> [local_ip <- nat -> public_ip] <->
remote_ip:remote_port
TCP-пакеты в рамках установленного соединения будут приходить снаружи на нат
в виде:
remote_ip:remote_port -> public_ip:local_port
Только у таких входящих пакетов нат будет заменять public_ip на local_ip и
соответветственно только такие пакеты дойдут до нужного сервера внутри сети
в соответствии с роутингом. Все остальные пакеты, у которых хотя бы один из
четырех элементов будет другим, будут проигнорированы натом (возвращены
после диверта неизмененными). В соответствии с роутингом они осядут на
шлюзе, т.е. до целевого сервера не дойдут. Иными словами, обычный флуд будет
отброшен на шлюзе с натом. Целенаправленная же атака с подмененными src_ip и
src_port опять-таки пройдет через нат.
Выводы. Если имеет место спуфинг и кто-то целенаправленно пытается
вклиниться в TCP-соединение, то ни один из способов не поможет - все они
пропустят пакет до сервера назначения. И уже TCP-стек на сервере назначения
будет решать отбрасывать или принимать полученный пакет. Разница во всех
описанных способах только в том, где будет оседать TCP-флуд с разных
адресов - на целевом сервере или на шлюзе. Сам по себе флуд не представляет
угрозы для безопасности, он может лишь забить сетевые каналы и привести к
отказу в обслуживании. Конкретно TCP-флуд, попадающий под правило
established, к отказу в обслуживании приведет вряд ли, т.к. поддельные
TCP-пакеты будут отбрасываться TCP-стеком еще не доходя до приложения. Далее
можно рассуждать так. Если сервер имеет серый адрес, т.е. на шлюзе есть нат,
то никакого файрвола для пакетов, которые обрабатывает нат, не надо вообще.
Все функции по защите выполняет сам нат. Если же сервер имеет реальный
адрес, то видимо он принимает какие-то входящие соединения извне. А это
значит, что как минимум один порт на ipfw шлюза должен быть открыт для этого
сервера. Т.е. через этот порт можно честно флудить пакетами без всяких
заморочек со спуфингом, и эти пакеты дойдут до сервера назначения и даже
будут приняты приложением, т.е. DOS обеспечен. В этом случае делать
keep-state для TCP смысла нет. Все равно от флуда не спасет. Эффективнее
пропустить весь established TCP-трафик. А если машина не принимает никаких
соединений извне, но все же имеет реальный адрес, наверное это как раз тот
случай, когда реальный адрес берут для того, чтобы иметь полноценный выход в
инет, не ограниченный ни натом, ни файрволом. Т.е. преполагается, что такая
машина готова принимать извне любые пакеты, пришедшие на ее адрес. В том
числе флуд. Таким образом, я не вижу преимуществ использования keep-state
для исходящих TCP-пакетов. А вот для исходящих UDP без keep-state уже никак.
Почему allow tcp from any to any established эффективнее чем allow tcp from
any to any keep-state? Потому что keep-state требует памяти для создания
динамических правил. В случае большого трафика - много памяти. Этой памяти
может внезапно не хватить и часть пакетов потеряется. Кроме того, нужно
время для просмотра таблицы динамических правил.
--
Best regards, Vadim.
Vadim Goncharov
On Fri, 20 Jul 2007 10:00:51 +0000 (UTC); Vadim Guchenko wrote about 'ipfw and keep-state':
VS>> Насчёт established спорно. Пропускать пакет от кого попало только
>>> на том основании, что на нём есть ACK bit?
>>> А чем это хуже ситуации с динамическими правилами?
VS>> Теоретически, может случиться ACK flood и firewall не спасет.
VG> Попробую рассмотреть все варианты, связанные с TCP.
[...]
VG> Почему allow tcp from any to any established эффективнее чем allow tcp from
VG> any to any keep-state? Потому что keep-state требует памяти для создания
VG> динамических правил. В случае большого трафика - много памяти. Этой памяти
VG> может внезапно не хватить и часть пакетов потеряется. Кроме того, нужно
VG> время для просмотра таблицы динамических правил.
Это всё варианты DoS-атак, тут все верно. Возможная дырявость
established заключается в другом - если за шлюзом сеть с реальными
адресами и в ней есть инсайдер, он может организовать обход файрвола,
обойдясь без начального пакета с SYN, так что все подпадут под
established. Но для случая с NATом этот вариант опять-таки нереален.
Vadim Goncharov
On Fri, 20 Jul 2007 08:32:43 +0000 (UTC); Valentin Davydov wrote about 'Re: ipfw and keep-state':
>>>> Обратный TCP трафик эффективнее разрешить правилом allow tcp from any to any
>>>> established. Динамические правила лучше создавать только для исходящих UDP.
VS>>> Вопрос был не как лучше сделать, а почему не работает данная
VS>>> конструкция. В ней есть ошибка? Возможно, какой-то неочевидный мне
VS>>> момент с порядком прохождения пакетов через ipfw?
VS>>> Насчёт established спорно. Пропускать пакет от кого попало только на
VS>>> том основании, что на нём есть ACK bit?
>>> Ну, допустим, что в обычных условиях так теоретически можно нахакерить.
>>> Но за NAT-то с чего? Так что в этом случае вполне можно.
VS>> Пожалуй ты прав, NAT сам по себе stateful, особенно с -deny_incoming.
>>Я больше имел в виду то, что серые адреса - unrouteable. Левые пакеты на
>>машины снаружи просто не могут прилететь (разве что из directly-attached
>>к роутеру сети, но решается включением antispoof или verrevpath в ipfw).
VD> Попробуй запустить трэйс на серый адрес. У меня с одного из роутеров четыре
VD> живых хопа было видно, каждый следующий дефолт для предыдущего.
Кое-где такое бывает, да.
Victor Sudakov
> >> Вероятно при попытке установить соединение с хостом y.y.y.y нат заменяет в
> >> исходящем пакете src_ip на некий публичный адрес, не входящий в подсеть
> >> x.x.x.x/27, поэтому правило 220 не срабатывает.
> VS> Так и есть. А как же теперь написать правило с keep-state, чтобы
> VS> учесть NAT?
> Используй не allow а skipto. Возможно, в сочетании с навешиванием
> тега. У меня оно сделано как-то так. Конфиг не полный и до конца не
> доработанный (нет времени), но практически все, что мне нужно -
> работает. До выхода релиза семерки трогать ничего не буду, скорее всего.
Посмотрел пример. Очень похоже на Basic двадцатилетней давности :(
Такая же неудобочитаемая мешанина из GOTO, в которой очень легко
запутаться и ошибиться. Это упрёк, конечно, не тебе лично, а
дизайнерам ipfw.
> Два аплинка - через ng0 и ng1. Тег навешивается в целях
> connection-oriented полиси роутинга. Естественно, one pass выключено.
Не совсем понял, при чём тут one pass. Он же на dummynet влияет, а
никаких pipe или queue я в твоём примере не нашёл.
Vadim Goncharov
On Mon, 23 Jul 2007 05:05:40 +0000 (UTC); Victor Sudakov wrote about 'Re: ipfw and keep-state':
>>> Вероятно при попытке установить соединение с хостом y.y.y.y нат заменяет в
>>> исходящем пакете src_ip на некий публичный адрес, не входящий в подсеть
>>> x.x.x.x/27, поэтому правило 220 не срабатывает.
VS>> Так и есть. А как же теперь написать правило с keep-state, чтобы
VS>> учесть NAT?
>> Используй не allow а skipto. Возможно, в сочетании с навешиванием
>> тега. У меня оно сделано как-то так. Конфиг не полный и до конца не
>> доработанный (нет времени), но практически все, что мне нужно -
>> работает. До выхода релиза семерки трогать ничего не буду, скорее всего.
VS> Посмотрел пример. Очень похоже на Basic двадцатилетней давности :(
VS> Такая же неудобочитаемая мешанина из GOTO, в которой очень легко
VS> запутаться и ошибиться. Это упрёк, конечно, не тебе лично, а
VS> дизайнерам ipfw.
То, что ipfw низкоуровневой - его плюс (и минус одновременно). Хочешь
простоты - возьми pf, большинство задач он решит красиво и элегантно.
>> Два аплинка - через ng0 и ng1. Тег навешивается в целях
>> connection-oriented полиси роутинга. Естественно, one pass выключено.
VS> Не совсем понял, при чём тут one pass. Он же на dummynet влияет, а
VS> никаких pipe или queue я в твоём примере не нашёл.
Не только, еще и на netgraph/ngtee влияет. Вероятно, был приведен не
весь конфиг либо стоит на всякий случай заранее - "щас допишу".
Vadim Guchenko
VS> Посмотрел пример. Очень похоже на Basic двадцатилетней давности :(
VS> Такая же неудобочитаемая мешанина из GOTO, в которой очень легко
VS> запутаться и ошибиться. Это упрёк, конечно, не тебе лично, а
VS> дизайнерам ipfw.
Исторически так сложилось, что правила файрвола в rc.firewall написаны в плохом и труднопонимаемом стиле: входящие и исходящие пакеты проходят один и тот же набор правил. Многие используют этот скрипт как образец для написания собственного набора правил и
наступают на одни и те же грабли. Как минимум, с натом. На самом деле ipfw очень удобен, если писать список правил как некую программу - с разбиением на мелкие подпрограммы (блоки) и добавлением комментариев. При этом надо руководствоваться рядом
соглашений:
1. Весь трафик первым делом делится на входящий и исходящий. Каждый вид трафика обрабатывается в отдельном блоке. В качестве еще одного блока можно выделить трафик через интерфейс lo0. Слова in и out после первоначального разделения трафика не
используются.
2. Входящий трафик делится на а) трафик, адресованный данному серверу; б) броадкасты; в) мультикасты; г) трафик, идущий транзитом. Каждый из видов трафика обрабатывается в отдельном блоке. Слово me после разделения трафика не используется.
3. Ветвление на блоки происходит по ip-адресам. Имена интерфейсов используются по возможности как можно реже и только тогда, когда без них не обойтись. В частности, при написании правил антиспуфинга. При использовании имен интерфейсов крайне не
рекомендуется использовать слово via. В зависимости от блока (входящий или исходящий трафик) рекомендуется использовать слова xmit или recv. Это повышает читабельность.
4. Все строки с правилами нумеруются (там где это допустимо). Нумерация строго возрастающая. Рекомендуемый шаг между соседними номерами 100.
5. Блок занимает строго фиксированный диапазон номеров строк ipfw. Номер строки, с которой начинается блок, указывается в комментарии в начале этого блока. Переход на блок происходит только на его начало. Переход в середину блока недопустим.
6. Блок всегда заканчивается строкой allow ip from any to any или deny ip from any to any. Исключение составляет ситуация, когда один блок должен выполняться следом за другим. Даже если блок пустой (например, броадкасты или мультикасты не используются),
все равно лучше поместить в него это единственное правило, чем удалять блок целиком. Возможно в будущем туда что-нибудь допишется.
Пример я как-то уже приводил несколько лет назад. Приведу еще раз для трех разных серверов. Макросы, начинающиеся с %, заменятся на блоки ip-адресов. На всех серверах дефолтное 65535 правило: allow ip from any to any.
Правила на центральном роутере/шлюзе в инет:
###############################################################################
###############################################################################
###############################################################################
#!/bin/sh -e
fwcmd="echo"
# Интерфейсы, подключенные к Интернету
xmit_iface_inet="{ xmit fxp1 or xmit fxp2 }"
recv_iface_inet="{ recv fxp1 or recv fxp2 }"
# Ограничение количества ping-пакетов, уходящих на аплинка
$fwcmd pipe 10 config bw 5Kbit/s
###############################################################################
## Разделение трафика в зависимости от направления (нумерация с 100)
###############################################################################
# Трафик через интерфейс lo0
$fwcmd add 100 allow ip from any to any via lo0
# Исходящий трафик
$fwcmd add 200 skipto 30000 ip from any to any out
###############################################################################
## Входящий трафик (нумерация с 500)
###############################################################################
# Съем трафика для статистики
$fwcmd add 500 divert 18000 ip from any to any $recv_iface_inet
# NAT-трансляция входящих пакетов
$fwcmd add 700 divert 8668 ip from any to %ip.nat $recv_iface_inet
##-----------------------------------------------------------------------------
## Антиспуфинг (нумерация с 1000)
##-----------------------------------------------------------------------------
# Интерфейсы Интернета
$fwcmd add 1000 deny log ip from %global.internal to any $recv_iface_inet
##-----------------------------------------------------------------------------
## Разделение трафика в зависимости от получателя пакета (нумерация с 5000)
##-----------------------------------------------------------------------------
# Трафик, адресованный серверу
$fwcmd add 5000 skipto 10000 ip from any to me
# Броадкасты
$fwcmd add 5100 skipto 20000 ip from any to 255.255.255.255
# Мультикасты
$fwcmd add 5200 skipto 25000 ip from any to 224.0.0.0/4
##-----------------------------------------------------------------------------
## Трафик, идущий транзитом (нумерация с 6000)
##-----------------------------------------------------------------------------
# Запрещаем трафик на закрытые адреса магистрали
$fwcmd add 6000 deny log ip from any to %global.backbone.private
# Разрешаем остальной трафик
$fwcmd add 6300 allow ip from any to any
##-----------------------------------------------------------------------------
## Трафик, адресованный серверу (нумерация с 10000)
##-----------------------------------------------------------------------------
# Разрешаем установленные TCP-соединения
$fwcmd add 10000 allow tcp from any to any established
# Разрешаем фрагменты IP-пакетов
$fwcmd add 10100 allow ip from any to any frag
# Разрешаем пакеты, удовлетворяющие динамическим правилам
$fwcmd add 10200 check-state
# Разрешаем OSPF-пакеты
$fwcmd add 10300 allow ospf from %global.backbone to any
# Разрешаем GRE-пакеты
$fwcmd add 10400 allow gre from any to any
##-----------------------------------------------------------------------------
## Службы сервера (нумерация с 12000)
##-----------------------------------------------------------------------------
# SSH
$fwcmd add 12000 deny tcp from %deny.ssh to %ip.ssh 22
$fwcmd add 12100 allow tcp from %allow.ssh to %ip.ssh 22
# BGP
$fwcmd add 12200 deny tcp from %deny.bgp to %ip.bgp 179
$fwcmd add 12300 allow tcp from %allow.bgp to %ip.bgp 179
# SNMP
$fwcmd add 12400 allow udp from %allow.snmp to %ip.snmp 161,1161
##-----------------------------------------------------------------------------
## Завершающие правила для трафика, адресованного серверу (нумерация с 18000)
##-----------------------------------------------------------------------------
# Разрешаем ICMP-пакеты
$fwcmd add 18000 allow icmp from any to any
# Разрешаем работу traceroute
$fwcmd add 18100 unreach port udp from any to any 33434-33584
# Запрещаем соединения на 113 порт (ident)
$fwcmd add 18200 reset tcp from any to any 113
# Запрещаем соединения на 1080 порт (socks check)
$fwcmd add 18300 reset tcp from any to any 1080
# Запрещаем остальной трафик
$fwcmd add 18400 deny log ip from any to any
##-----------------------------------------------------------------------------
## Броадкасты (нумерация с 20000)
##-----------------------------------------------------------------------------
# Разрешаем SNMP trap'ы от ИБП
$fwcmd add 20000 allow udp from %global.backbone to any 162
# Разрешаем NTP-пакеты
$fwcmd add 20100 allow udp from %global.backbone to %global.backbone.broadcast 123
# Запрещаем остальной трафик
$fwcmd add 20200 deny log ip from any to any
##-----------------------------------------------------------------------------
## Мультикасты (нумерация с 25000)
##-----------------------------------------------------------------------------
# Разрешаем OSPF-пакеты
$fwcmd add 25000 allow ospf from %global.backbone to 224.0.0.0/24{5,6}
# Разрешаем общие IGMP и DVMRP-пакеты
$fwcmd add 25100 allow igmp from %global.backbone to 224.0.0.0/24{1,2,4}
$fwcmd add 25200 allow igmp from %ip.link.iskranet-gw to 224.0.0.0/24{1,2}
# Разрешаем трафик TVoIP
$fwcmd add 25300 allow ip from %ip.ext.tvoip to 224.2.153.173
# Запрещаем остальной трафик
$fwcmd add 25400 deny log ip from any to any
###############################################################################
## Исходящий трафик (нумерация с 30000)
###############################################################################
# Запрещаем отправку пакетов, предназначенных для внутрисетевых адресов,
# на шлюз по умолчанию
$fwcmd add 30000 deny ip from any to %global.internal $xmit_iface_inet
# Запрещаем отправку в Интернет пакетов Netbios
$fwcmd add 30100 deny tcp from any to any 135,139,445 $xmit_iface_inet
# Запрещаем отправку пакетов в Интернет для клиентов, которые отключены
# от Интернета
$fwcmd add 30200 skipto 30350 ip from %allow.internet to any $xmit_iface_inet
$fwcmd add 30300 deny ip from any to any $xmit_iface_inet
# Шейпинг ping-пакетов
$fwcmd add 30350 skipto 30400 icmp from %group.ping-shaping to any icmptypes 8 $xmit_iface_inet
$fwcmd add 30351 pipe 10 icmp from any to any icmptypes 8 $xmit_iface_inet
# Съем трафика для статистики
$fwcmd add 30400 divert 18001 ip from any to any $xmit_iface_inet
# NAT-трансляция исходящих пакетов
$fwcmd add 30800 divert 8668 ip from 192.168.0.0/16 to any $xmit_iface_inet
#$fwcmd add 30900 allow ip from %ip.nat to any $xmit_iface_inet
# Направляем пакеты в нужные интерфейсы аплинков в зависимости от их src-адреса
$fwcmd add 31000 fwd %ip.link.krastelecom-gw ip from %ip.link.krastelecom to any $xmit_iface_inet
$fwcmd add 31100 fwd %ip.link.iskranet-gw ip from %ip.link.iskranet to any $xmit_iface_inet
# Динамическое правило для доступа с данного сервера к внешним службам по UDP
$fwcmd add 31200 allow udp from me to any keep-state
##-----------------------------------------------------------------------------
## Аккаунтинг трафика (нумерация с 40000)
##-----------------------------------------------------------------------------
# Трафик Интернета
$fwcmd add 40000 skipto 40200 ip from %global.internal to %group.accounting
$fwcmd add 40100 divert 17000 ip from any to %group.accounting
###############################################################################
###############################################################################
###############################################################################
Правила на сервере доступа:
###############################################################################
###############################################################################
###############################################################################
#!/bin/sh -e
fwcmd="echo"
# Интерфейс, подключенный к клиентскому сегменту
iface_clients=fxp0
# Интерфейсы VPN
iface_vpns=ng*
###############################################################################
## Разделение трафика в зависимости от направления (нумерация с 100)
###############################################################################
# Трафик через интерфейс lo0
$fwcmd add 100 allow ip from any to any via lo0
# Исходящий трафик
$fwcmd add 200 skipto 30000 ip from any to any out
###############################################################################
## Входящий трафик (нумерация с 500)
###############################################################################
# Открываем доступ к DHCP-серверу с незарегистрированных адресов, запрещаем
# с них любой другой трафик
$fwcmd add 500 allow udp from %clients.unreg to %srv.dhcp 67
$fwcmd add 600 allow udp from %clients.unreg to 255.255.255.255 67
$fwcmd add 700 deny ip from %clients.unreg to any
##-----------------------------------------------------------------------------
## Антиспуфинг (нумерация с 1000)
##-----------------------------------------------------------------------------
# Интерфейс клиентов
$fwcmd add 1000 skipto 5000 ip from 0.0.0.0 to any recv $iface_clients
$fwcmd add 1100 skipto 5000 ip from %clients to any recv $iface_clients
$fwcmd add 1200 deny log ip from any to any recv $iface_clients
# Интерфейсы VPN
$fwcmd add 1300 skipto 5000 ip from %clients to any recv $iface_vpns
$fwcmd add 1400 skipto 5000 ip from any to any verrevpath recv $iface_vpns
$fwcmd add 1500 deny log ip from any to any recv $iface_vpns
##-----------------------------------------------------------------------------
## Разделение трафика в зависимости от получателя пакета (нумерация с 5000)
##-----------------------------------------------------------------------------
# Трафик, адресованный серверу
$fwcmd add 5000 skipto 10000 ip from any to me
# Броадкасты
$fwcmd add 5100 skipto 20000 ip from any to 255.255.255.255
$fwcmd add 5200 skipto 20000 ip from any to %global.backbone.broadcast
$fwcmd add 5300 skipto 20000 ip from any to %clients.broadcast
# Мультикасты
$fwcmd add 5400 skipto 25000 ip from any to 224.0.0.0/4
##-----------------------------------------------------------------------------
## Трафик, идущий транзитом (нумерация с 6000)
##-----------------------------------------------------------------------------
# Запрещаем трафик на закрытые адреса магистрали
$fwcmd add 6000 deny log ip from any to %global.backbone.private
# Разрешаем любой трафик, идущий c VPN-адресов клиентов, которым открыт доступ
# к услугам сети, и обратно
$fwcmd add 6100 allow ip from %access.allow to any
$fwcmd add 6200 allow ip from any to %access.allow
# Разрешаем трафик, идущий от клиентов на DNS-резолвер и обратно
$fwcmd add 6300 allow ip from any to %global.srv.resolver
$fwcmd add 6400 allow ip from %global.srv.resolver to any
# Разрешаем трафик, идущий от клиентов на веб-сервер сети и обратно
$fwcmd add 6500 allow ip from any to %global.srv.http
$fwcmd add 6600 allow ip from %global.srv.http to any
# Разрешаем эхо-запросы, идущие на локальные адреса клиентов, и эхо-ответы
# c этих адресов
$fwcmd add 6700 allow icmp from any to %clients icmptypes 8
$fwcmd add 6800 allow icmp from %clients to any icmptypes 0
# Запрещаем остальной трафик
$fwcmd add 6900 deny log ip from any to any
##-----------------------------------------------------------------------------
## Трафик, адресованный серверу (нумерация с 10000)
##-----------------------------------------------------------------------------
# Разрешаем установленные TCP-соединения
$fwcmd add 10000 allow tcp from any to any established
# Разрешаем фрагменты IP-пакетов
$fwcmd add 10100 allow ip from any to any frag
# Разрешаем пакеты, удовлетворяющие динамическим правилам
$fwcmd add 10200 check-state
# Разрешаем OSPF-пакеты
$fwcmd add 10300 allow ospf from %global.backbone to any
# Разрешаем GRE-пакеты
$fwcmd add 10400 allow gre from any to any
##-----------------------------------------------------------------------------
## Службы сервера (нумерация с 12000)
##-----------------------------------------------------------------------------
# SSH
$fwcmd add 12000 allow tcp from %srv.ssh.allow to %srv.ssh 22
# DHCP
$fwcmd add 12100 allow udp from %srv.dhcp.allow to %srv.dhcp 67
# PPTP
$fwcmd add 12200 allow tcp from %srv.pptp.allow to %srv.pptp 1723
# SNMP
$fwcmd add 12300 allow udp from %srv.snmp.allow to %srv.snmp 161,1161
##-----------------------------------------------------------------------------
## Завершающие правила для трафика, адресованного серверу (нумерация с 18000)
##-----------------------------------------------------------------------------
# Разрешаем ICMP-пакеты
$fwcmd add 18000 allow icmp from any to any
# Разрешаем работу traceroute
$fwcmd add 18100 unreach port udp from any to any 33434-33584
# Запрещаем соединения на 80 порт (samba)
$fwcmd add 18200 reset tcp from any to any 80
# Запрещаем соединения на 113 порт (ident)
$fwcmd add 18300 reset tcp from any to any 113
# Запрещаем соединения на 1080 порт (socks check)
$fwcmd add 18400 reset tcp from any to any 1080
# Запрещаем остальной трафик
$fwcmd add 18500 deny log ip from any to any
##-----------------------------------------------------------------------------
## Броадкасты (нумерация с 20000)
##-----------------------------------------------------------------------------
# Разрешаем SNMP trap'ы от ИБП
$fwcmd add 20000 allow udp from %global.backbone to any 162
# Разрешаем NTP-пакеты
$fwcmd add 20100 allow udp from %global.backbone to %global.backbone.broadcast 123
# Разрешаем поиск DHCP-сервера
$fwcmd add 20200 allow udp from %srv.dhcp.allow to any 67
# Запрещаем остальной трафик
$fwcmd add 20300 deny log ip from any to any
##-----------------------------------------------------------------------------
## Мультикасты (нумерация с 25000)
##-----------------------------------------------------------------------------
# Разрешаем OSPF-пакеты
$fwcmd add 25000 allow ospf from %global.backbone to 224.0.0.0/24{5,6}
# Разрешаем общие IGMP и DVMRP-пакеты
$fwcmd add 25100 allow igmp from %global.backbone to 224.0.0.0/24{1,2,4}
$fwcmd add 25200 allow igmp from %clients to 224.0.0.0/24{1,2}
# Разрешаем подписку на группы TVoIP
$fwcmd add 25300 allow igmp from %clients to %global.srv.tvoip.groups
# Разрешаем трафик TVoIP
$fwcmd add 25400 allow ip from %global.srv.tvoip to %global.srv.tvoip.groups
# Запрещаем остальной трафик
$fwcmd add 25500 deny log ip from any to any
###############################################################################
## Исходящий трафик (нумерация с 30000)
###############################################################################
# Динамическое правило для доступа с данного сервера к внешним службам по UDP
$fwcmd add 30000 allow udp from me to any keep-state
###############################################################################
###############################################################################
###############################################################################
Правила на сервере служб:
###############################################################################
###############################################################################
###############################################################################
#!/bin/sh -e
fwcmd="echo"
###############################################################################
## Разделение трафика в зависимости от направления (нумерация с 100)
###############################################################################
# Трафик через интерфейс lo0
$fwcmd add 100 allow ip from any to any via lo0
# Исходящий трафик
$fwcmd add 200 skipto 30000 ip from any to any out
###############################################################################
## Входящий трафик (нумерация с 1000)
###############################################################################
##-----------------------------------------------------------------------------
## Разделение трафика в зависимости от получателя пакета (нумерация с 5000)
##-----------------------------------------------------------------------------
# Трафик, адресованный серверу
$fwcmd add 5000 skipto 10000 ip from any to me
# Броадкасты
$fwcmd add 5100 skipto 20000 ip from any to 255.255.255.255
$fwcmd add 5150 skipto 20000 ip from any to %group.backbone_broadcast
# Мультикасты
$fwcmd add 5200 skipto 25000 ip from any to 224.0.0.0/4
##-----------------------------------------------------------------------------
## Трафик, идущий транзитом (нумерация с 6000)
##-----------------------------------------------------------------------------
# Запрещаем весь трафик
$fwcmd add 6000 deny log ip from any to any
##-----------------------------------------------------------------------------
## Трафик, адресованный серверу (нумерация с 10000)
##-----------------------------------------------------------------------------
# Преобразовываем запросы к DNS-резолверу
$fwcmd add 10000 divert 8669 ip from %allow.resolver_internet to %ip.resolver
# Разрешаем установленные TCP-соединения
$fwcmd add 10100 allow tcp from any to any established
# Разрешаем фрагменты IP-пакетов
$fwcmd add 10200 allow ip from any to any frag
# Разрешаем пакеты, удовлетворяющие динамическим правилам
$fwcmd add 10300 check-state
# Разрешаем OSPF-пакеты
$fwcmd add 10400 allow ospf from %group.backbone to any
##-----------------------------------------------------------------------------
## Службы сервера (нумерация с 12000)
##-----------------------------------------------------------------------------
# SSH
$fwcmd add 12000 deny tcp from %deny.ssh to %ip.ssh 22
$fwcmd add 12100 allow tcp from %allow.ssh to %ip.ssh 22
# DNS-резолвер
$fwcmd add 12200 deny { tcp or udp } from %deny.resolver to %ip.resolver 53
$fwcmd add 12300 allow { tcp or udp } from %allow.resolver to %ip.resolver 53
# DNS-сервер
$fwcmd add 12400 deny { tcp or udp } from %deny.dns to %ip.dns 53
$fwcmd add 12500 allow { tcp or udp } from %allow.dns to %ip.dns 53
# DNS-кэш
$fwcmd add 12600 deny { tcp or udp } from %deny.dnscache to %ip.dnscache 53
$fwcmd add 12700 allow { tcp or udp } from %allow.dnscache to %ip.dnscache 53
# NTP-сервер
$fwcmd add 12800 deny udp from %deny.ntp to %ip.ntp 123
$fwcmd add 12900 allow udp from %allow.ntp to %ip.ntp 123
# IRC
$fwcmd add 13000 deny tcp from %deny.irc to %ip.irc 6667-6669
$fwcmd add 13100 allow tcp from %allow.irc to %ip.irc 6667-6669
$fwcmd add 13200 deny icmp from any to %ip.irc icmptypes 8
# HTTP
$fwcmd add 13700 deny tcp from %deny.http to %ip.http 80,443
$fwcmd add 13800 allow tcp from %allow.http to %ip.http 80,443
# SMTP
$fwcmd add 13900 deny tcp from %deny.smtp to %ip.smtp 25
$fwcmd add 14000 allow tcp from %allow.smtp to %ip.smtp 25
$fwcmd add 14100 deny tcp from %group.internal to %ip.smtp 25
$fwcmd add 14200 allow tcp from any to %ip.smtp 25
# POP
$fwcmd add 14300 deny tcp from %deny.pop to %ip.pop 110
$fwcmd add 14400 allow tcp from %allow.pop to %ip.pop 110
# SNMP
$fwcmd add 14500 allow udp from %allow.snmp to %ip.snmp 161,1161
##-----------------------------------------------------------------------------
## Завершающие правила для трафика, адресованного серверу (нумерация с 18000)
##-----------------------------------------------------------------------------
# Разрешаем ICMP-пакеты
$fwcmd add 18000 allow icmp from any to any
# Разрешаем работу traceroute
$fwcmd add 18100 unreach port udp from any to any 33434-33584
# Запрещаем соединения на 113 порт (ident)
$fwcmd add 18200 reset tcp from any to any 113
# Запрещаем соединения на 1080 порт (socks check)
$fwcmd add 18300 reset tcp from any to any 1080
# Запрещаем остальной трафик
$fwcmd add 18400 deny log ip from any to any
##-----------------------------------------------------------------------------
## Броадкасты (нумерация с 20000)
##-----------------------------------------------------------------------------
# Разрешаем SNMP trap'ы от ИБП
$fwcmd add 20000 allow udp from %group.backbone to any 162
# Запрещаем остальной трафик
$fwcmd add 20100 deny log ip from any to any
##-----------------------------------------------------------------------------
## Мультикасты (нумерация с 25000)
##-----------------------------------------------------------------------------
# Разрешаем OSPF-пакеты
$fwcmd add 25000 allow ospf from %group.backbone to 224.0.0.0/24{5,6}
# Запрещаем остальной трафик
$fwcmd add 25100 deny log ip from any to any
###############################################################################
## Исходящий трафик (нумерация с 30000)
###############################################################################
# Преобразовываем ответы DNS-резолвера
$fwcmd add 30000 divert 8669 ip from %ip.dnscache to %allow.resolver_internet
# Динамическое правило для доступа с данного сервера к внешним службам по UDP
$fwcmd add 30100 allow udp from me to any keep-state
##-----------------------------------------------------------------------------
## Аккаунтинг трафика (нумерация с 40000)
##-----------------------------------------------------------------------------
# Трафик почтового сервера (POP)
$fwcmd add 40000 divert 17000 tcp from %ip.pop to %group.accounting
###############################################################################
###############################################################################
###############################################################################
--
Best regards, Vadim.
Vadim Guchenko
VG> Это всё варианты DoS-атак, тут все верно. Возможная дырявость
VG> established заключается в другом - если за шлюзом сеть с реальными
VG> адресами и в ней есть инсайдер, он может организовать обход файрвола,
VG> обойдясь без начального пакета с SYN, так что все подпадут под
VG> established.
Не понимаю. Можно пример?
--
Best regards, Vadim.
Alex Bakhtin
Привет,
>> >> Вероятно при попытке установить соединение с хостом y.y.y.y нат заменяет в
>> >> исходящем пакете src_ip на некий публичный адрес, не входящий в подсеть
>> >> x.x.x.x/27, поэтому правило 220 не срабатывает.
VS> Так и есть. А как же теперь написать правило с keep-state, чтобы
VS> учесть NAT?
>> Используй не allow а skipto. Возможно, в сочетании с навешиванием
>> тега. У меня оно сделано как-то так. Конфиг не полный и до конца не
>> доработанный (нет времени), но практически все, что мне нужно -
>> работает. До выхода релиза семерки трогать ничего не буду, скорее всего.
VS> Посмотрел пример. Очень похоже на Basic двадцатилетней давности :(
VS> Такая же неудобочитаемая мешанина из GOTO, в которой очень легко
VS> запутаться и ошибиться. Это упрёк, конечно, не тебе лично, а
VS> дизайнерам ipfw.
А что делать? Мне надо было слепить что-то с полиси-роутингом и natом
на 2 канала. Уж что слепилось. Я, честно говоря, думал на предмет несколько
лучше структурировать - но до этого не доходят руки, т.к. оно и так
работает. Может быть, когда-нибудь...
>> Два аплинка - через ng0 и ng1. Тег навешивается в целях
>> connection-oriented полиси роутинга. Естественно, one pass выключено.
VS> Не совсем понял, при чём тут one pass. Он же на dummynet влияет, а
VS> никаких pipe или queue я в твоём примере не нашёл.
Ну, они у меня где-то были. Я, видимо, плохо читал доку и мне
казалось, что это и на divert влияет. Ну, раз не влияет - значит хорошо:)
Victor Sudakov
> >>> Вероятно при попытке установить соединение с хостом y.y.y.y нат заменяет в
> >>> исходящем пакете src_ip на некий публичный адрес, не входящий в подсеть
> >>> x.x.x.x/27, поэтому правило 220 не срабатывает.
> VS>> Так и есть. А как же теперь написать правило с keep-state, чтобы
> VS>> учесть NAT?
> >> Используй не allow а skipto. Возможно, в сочетании с навешиванием
> >> тега. У меня оно сделано как-то так. Конфиг не полный и до конца не
> >> доработанный (нет времени), но практически все, что мне нужно -
> >> работает. До выхода релиза семерки трогать ничего не буду, скорее всего.
> VS> Посмотрел пример. Очень похоже на Basic двадцатилетней давности :(
> VS> Такая же неудобочитаемая мешанина из GOTO, в которой очень легко
> VS> запутаться и ошибиться. Это упрёк, конечно, не тебе лично, а
> VS> дизайнерам ipfw.
> То, что ipfw низкоуровневой - его плюс (и минус одновременно). Хочешь
> простоты - возьми pf, большинство задач он решит красиво и элегантно.
Попробую.
Вообще если бы divert не путался под ногами, то на ipfw можно делать
вполне читабельные конструкции. Особенно если сразу придерживаться
принципа - каждое правило обязательно должно содержать привязку к
интерфейсу и указание на направление трафика (по аналогии с цискиными
"ip access-group").
Хотя, dummynet наверное будет мешать не меньше divert.
Andrew Filonov
VS> Вообще если бы divert не путался под ногами, то на ipfw можно
VS> делать вполне читабельные конструкции. Особенно если сразу
VS> придерживаться принципа - каждое правило обязательно должно
VS> содержать привязку к интерфейсу и указание на направление трафика
VS> (по аналогии с цискиными "ip access-group").
Пользуй pfnat и проблем с divert'ом не будет.
--
Andrew E. Filonov
If you do something right once, someone will ask
you to do it again.
Andrew Alcheyev
Tuesday July 24 2007 at 15:19, Andrew Filonov wrote to Victor Sudakov:
AF> Пользуй pfnat и проблем с divert'ом не будет.
ага, один ftp-proxy у pfnat'а чего стоит.
поскольку с помощью ipfw и netgraph можно реализовать практически всё, а вопрос
читаемости правил кроется в голове их разработчика, то можно сделать вывод, что
критической массе пользователей-девелоперов не нужны фичи и удобства pf(nat) и
сотоварищи.
тем не менее, я уважаю осознанную свободу выбора и слегка удивляюсь отсутствию
iptables во FreeBSD. :-)
С уважением.
Victor Sudakov
> AF> Пользуй pfnat и проблем с divert'ом не будет.
> ага, один ftp-proxy у pfnat'а чего стоит.
Это ты в хорошем смысле или с иронией?
Andrew Alcheyev
Wednesday July 25 2007 at 05:48, Victor Sudakov wrote to Vadim Goncharov:
>> AF>> Пользуй pfnat и проблем с divert'ом не будет.
>> >> ага, один ftp-proxy у pfnat'а чего стоит.
>> VS> Это ты в хорошем смысле или с иронией?
с иронией.
мне нравится синтаксис pf(nat). но вот лучше бы энергию портирования pf, да на
благое дело (нормализация трафика, traffic inspection, NAT экзотических случаев
и т.п.) для ipfw.
>> С иронией, конечно - оно ж на каждый коннект запускается из inetd.
>> И затем такое же копирование ядро<->юзерлэнд.
VS> А что ещё _не_ умеет pfnat по сравнению с libalias?
Я могу ошибаться, но навскидку гугление и поиск по сорцам libalias и pf
показали, что:
CUSEEME, IRC (DCC), PPTP (несколько сессий к одному серверу), NetBIOS/UDP,
RSTP.
Пока же pf выглядит лишь как средство для переманивания openbsd'истов да для
утешения параноиков.
С уважением.
Andrew Filonov
AA> с иронией. мне нравится синтаксис pf(nat). но вот лучше бы
AA> энергию портирования pf, да на благое дело (нормализация трафика,
AA> traffic inspection, NAT экзотических случаев и т.п.) для ipfw.
А вот не надо делать монстрика из ipfw
AA> Я могу ошибаться, но навскидку гугление и поиск по сорцам
AA> libalias и pf показали, что: CUSEEME, IRC (DCC), PPTP (несколько
AA> сессий к одному серверу), NetBIOS/UDP, RSTP.
Только на обычном траффике оно работает в разы быстрее.
AA> Пока же pf выглядит лишь как средство для переманивания
AA> openbsd'истов да для утешения параноиков.
Оно выглядит как работающее решение. Случаи когда оно таки не
работают - не слишком массовы и легко решаются.
--
Andrew E. Filonov
The source for an unattributed quotation will appear
in the most hostile review of your work.
Andrew Alcheyev
Wednesday July 25 2007 at 09:07, Andrew Filonov wrote to Andrew Alcheyev:
AF> А вот не надо делать монстрика из ipfw
оно уже монстрик, да хотя бы по сравнению с FreeBSD 2.2.
и что с этого ? ведь есть же pf, который решает! :-D
AF> Только на обычном траффике оно работает в разы быстрее.
оно = pfnat ? или pf вообще ?
если речь про pfnat, то я бы хотел узнать про методику измерения
производительности и результаты проведения забегов между pfnat и ipfw+ng_nat.
С уважением.
Alexey Kouznetsov
news:slrnfaca30.219...@hostel.avtf.net...
> AF>> Пользуй pfnat и проблем с divert'ом не будет.
> >> ага, один ftp-proxy у pfnat'а чего стоит.
> VS> Это ты в хорошем смысле или с иронией?
> С иронией, конечно - оно ж на каждый коннект запускается из inetd.
> И затем такое же копирование ядро<->юзерлэнд.
На некоторых видах фтп трафика оно у меня просто трапалось. Причем стояло 2
машины как бакап одна другую, так и трапались то одна то вторая. Дебажить
сильно небыло времени, вычислили только что за клиент (там какой-то был
довнлоадер хитрый) В итоге стоит для всего, кроме фтп pfnat а для ftp ipnat
(все на IPnat не подходит, так как нужно его еще и pfsync. а FTP в том виде
как оно реализуется на pf один хрен не синкается.)
Vadim Goncharov
On Wed, 25 Jul 2007 01:48:22 +0000 (UTC); Victor Sudakov wrote about 'Re: ipfw and keep-state':
AF>>> Пользуй pfnat и проблем с divert'ом не будет.
>>> ага, один ftp-proxy у pfnat'а чего стоит.
VS>> Это ты в хорошем смысле или с иронией?
>> С иронией, конечно - оно ж на каждый коннект запускается из inetd.
>> И затем такое же копирование ядро<->юзерлэнд.
VS> А что ещё _не_ умеет pfnat по сравнению с libalias?
Полагаю, любое переписывание данных в payload проходящих пакетов.
Несколько PPTP-сессий из-за ната на один сервер - точно не умеет (для
этого в портах опять же юзерлэндный прокси есть).
Vadim Goncharov
On Wed, 25 Jul 2007 08:12:40 +0000 (UTC); Alexey Kouznetsov wrote about 'Re: ipfw and keep-state':
AF>>> Пользуй pfnat и проблем с divert'ом не будет.
>>> ага, один ftp-proxy у pfnat'а чего стоит.
VS>> Это ты в хорошем смысле или с иронией?
>> С иронией, конечно - оно ж на каждый коннект запускается из inetd.
>> И затем такое же копирование ядро<->юзерлэнд.
AK> На некоторых видах фтп трафика оно у меня просто трапалось. Причем стояло 2
AK> машины как бакап одна другую, так и трапались то одна то вторая. Дебажить
AK> сильно небыло времени, вычислили только что за клиент (там какой-то был
AK> довнлоадер хитрый)
А багрепорт хоть отослали?
AK> В итоге стоит для всего, кроме фтп pfnat а для ftp ipnat
AK> (все на IPnat не подходит, так как нужно его еще и pfsync. а FTP в том виде
AK> как оно реализуется на pf один хрен не синкается.)
А у вас какое применение pfsync ?
Vadim Goncharov
On Wed, 25 Jul 2007 09:26:00 +0400; Andrew Alcheyev wrote about 'ipfw and keep-state':
AF>>> Пользуй pfnat и проблем с divert'ом не будет.
>>> ага, один ftp-proxy у pfnat'а чего стоит.
VS>> Это ты в хорошем смысле или с иронией?
AA> с иронией.
AA> мне нравится синтаксис pf(nat). но вот лучше бы энергию портирования pf, да на
AA> благое дело
AA> (нормализация трафика, traffic inspection,
Что именно требуется?
AA> NAT экзотических случаев и т.п.) для ipfw.
Тот же вопрос.
AA> NetBIOS/UDP, RSTP.
А здесь какие проблемы?
Vadim Goncharov
On Wed, 25 Jul 2007 05:07:35 +0000 (UTC); Andrew Filonov wrote about 'Re: ipfw and keep-state':
AA>> Я могу ошибаться, но навскидку гугление и поиск по сорцам
AA>> libalias и pf показали, что: CUSEEME, IRC (DCC), PPTP (несколько
AA>> сессий к одному серверу), NetBIOS/UDP, RSTP.
AF> Только на обычном траффике оно работает в разы быстрее.
В разы быстрее чего? Как файрвол pf медленне ipfw. Если нат - надо
сравнивать ng_nat либо ipfw nat в 7-ке.
Andrew Filonov
AF> Только на обычном траффике оно работает в разы быстрее.
AA> оно = pfnat ? или pf вообще ?
AA> если речь про pfnat, то я бы хотел узнать про методику измерения
AA> производительности и результаты проведения забегов между pfnat и
AA> ipfw+ng_nat.
"Батюшка или крестик снимите, или трусы наденьте"
Далеко не вся функциональность libalias которая выше приводилась,
ng_nat'ом поддерживается. Также отсутствует функциональность binat и rdr.
И что с чем вы предлагаете сравнивать?
--
Andrew E. Filonov
Capitalism can exist in one of only two states:
welfare or warfare.
Andrew Filonov
AA> Я могу ошибаться, но навскидку гугление и поиск по сорцам
AA> libalias и pf показали, что: CUSEEME, IRC (DCC), PPTP (несколько
AA> сессий к одному серверу), NetBIOS/UDP, RSTP.
AF> Только на обычном траффике оно работает в разы быстрее.
VG> В разы быстрее чего?
natd очевидно. Других способов обеспечить вышеуказанную
функциональность в полном объеме просто нет на данный момент.
VG> Как файрвол pf медленне ipfw. Если нат - надо сравнивать ng_nat
VG> либо ipfw nat в 7-ке.
Когда будет 7ка в STABLE - тогда и будем сравнивать. А до тех пор
способов сравнить pfnat'овский rdr c ng_nat - лично я не вижу.
--
Andrew E. Filonov
Just because you are paranoid
doesn't mean "they" aren't out to get you.
Alexey Kouznetsov
> Hi Alexey Kouznetsov!
> AK> На некоторых видах фтп трафика оно у меня просто трапалось. Причем
> стояло 2
> А багрепорт хоть отослали?
Не имею привычки писать баг репорты вида "ААА все не работает", а для
нормального нужно хотябы корку получить было. На боевой системе небыло
возможности, а на кошках не повторялось. ну не смог я тем же донлоад
менеджером сделать такое же. Может но и от сервера зависит. На тот момент
меня устроило, что ipnat для FTP пошел и не трапается эни море.
AK> В итоге стоит для всего, кроме фтп pfnat а для ftp ipnat
AK> (все на IPnat не подходит, так как нужно его еще и pfsync. а FTP в том
виде
AK> как оно реализуется на pf один хрен не синкается.)
> А у вас какое применение pfsync ?
2 машины под нат каждая дублирует соседнюю: при полегании одной все сессии
переезжают на резервную. Для юзеров более менее прозрачно, фтп отваливается
конечно. Какое у него еще применения может быть ?
/Алексей
Vadim Goncharov
On Thu, 26 Jul 2007 07:36:20 +0000 (UTC); Alexey Kouznetsov wrote about 'Re: ipfw and keep-state':
>> А у вас какое применение pfsync ?
AK> 2 машины под нат каждая дублирует соседнюю: при полегании одной все сессии
AK> переезжают на резервную. Для юзеров более менее прозрачно, фтп отваливается
AK> конечно. Какое у него еще применения может быть ?
Интересно, насколько это востребованная конфигурация. Если б, скажем,
такое когда-нибудь появилось для ipfw.
Vadim Goncharov
On Thu, 26 Jul 2007 05:30:59 +0000 (UTC); Andrew Filonov wrote about 'Re: ipfw and keep-state':
AA>> Я могу ошибаться, но навскидку гугление и поиск по сорцам
AA>> libalias и pf показали, что: CUSEEME, IRC (DCC), PPTP (несколько
AA>> сессий к одному серверу), NetBIOS/UDP, RSTP.
AF>> Только на обычном траффике оно работает в разы быстрее.
VG>> В разы быстрее чего?
AF> natd очевидно. Других способов обеспечить вышеуказанную
AF> функциональность в полном объеме просто нет на данный момент.
VG>> Как файрвол pf медленне ipfw. Если нат - надо сравнивать ng_nat
VG>> либо ipfw nat в 7-ке.
AF> Когда будет 7ка в STABLE - тогда и будем сравнивать. А до тех пор
AF> способов сравнить pfnat'овский rdr c ng_nat - лично я не вижу.
Ага, сначала говорим про обычный трафик, потом передергиваем на
функицонал проброса портов внутрь. Обтекай.
Andrew Filonov
>>> А у вас какое применение pfsync ?
AK> 2 машины под нат каждая дублирует соседнюю: при полегании одной
AK> все сессии переезжают на резервную. Для юзеров более менее
AK> прозрачно, фтп отваливается конечно. Какое у него еще применения
AK> может быть ?
VG> Интересно, насколько это востребованная конфигурация.
Весьма.
--
Andrew E. Filonov
If your condition seems to be getting better, it's
probably your doctor getting sick.
Serge V.Panchenko
19 Jul 07 12:48, Victor Sudakov wrote to "Vadim Guchenko":
VS> Hасчёт established спорно. Пропускать пакет от кого попало только на
VS> том основании, что на нём есть ACK bit?
Hу, да. А что такого? Ох уж эти юные админы в пионерских галстуках... ;-))
уважением, Сережка В. Панченко...
e-mail: svp2...@mail.ru
Пермский ФОРУМ: http://anvil.perm.ru
Victor Sudakov
> VS> Hасчёт established спорно. Пропускать пакет от кого попало только на
> VS> том основании, что на нём есть ACK bit?
> Hу, да. А что такого?
Как минимум на каждый такой левый сегмент твои хосты должны отвечать
TCP ресетом. Можно наверное придумать, как использовать это в
злонамеренных целях, например топологию сети разузнать.
Зачем вообще пускать в сеть пакеты, в которых _заведомо_ ничего не
может быть полезного? Зря что ли делают правила против спуфинга etc?
> Ох уж эти юные админы в пионерских галстуках... ;-))
И не говори. Одни пионеры напридумывали разных stateful inspection,
adaptive security и прочего, а другие пионеры купились.
И только взрослый дядька Serge V.Panchenko смотрит снисходительно на
всю эту возню :)
Andrew Filonov
AA> Я могу ошибаться, но навскидку гугление и поиск по сорцам
AA> libalias и pf показали, что: CUSEEME, IRC (DCC), PPTP (несколько
AA> сессий к одному серверу), NetBIOS/UDP, RSTP.
AF> Только на обычном траффике оно работает в разы быстрее.
VG> В разы быстрее чего?
AF> natd очевидно. Других способов обеспечить вышеуказанную
AF> функциональность в полном объеме просто нет на данный момент.
VG> Как файрвол pf медленне ipfw. Если нат - надо сравнивать ng_nat
VG> либо ipfw nat в 7-ке.
AF> Когда будет 7ка в STABLE - тогда и будем сравнивать. А до тех пор
AF> способов сравнить pfnat'овский rdr c ng_nat - лично я не вижу.
VG> Ага, сначала говорим про обычный трафик, потом передергиваем на
VG> функицонал проброса портов внутрь.
Ты читаешь или где? Обычный - имелось ввиду - не относящийся к
перечисленным протоколам. rdr - вполне себе обычная задачка.
VG> Обтекай.
Хамите парниша.
--
Andrew E. Filonov
It's tough to get reallocated when you're the one
who's redundant.
Andrew Filonov
VS> Как минимум на каждый такой левый сегмент твои хосты должны
VS> отвечать TCP ресетом. Можно наверное придумать, как использовать
VS> это в злонамеренных целях, например топологию сети разузнать.
VS> Зачем вообще пускать в сеть пакеты, в которых _заведомо_ ничего
VS> не может быть полезного? Зря что ли делают правила против
VS> спуфинга etc?
А некоторые еще и ICMP намертво фильтруют.
VS> И не говори. Одни пионеры напридумывали разных stateful
VS> inspection, adaptive security и прочего, а другие пионеры
VS> купились.
очевидно RST-пакет представляется меньшим злом, чем потенциальный DOS
от stateful-подхода.
--
Andrew E. Filonov
Make it possible for programmers to write programs
in english and you will find that programmers cannot
write in english.
Valentin Davydov
> Date: Fri, 27 Jul 2007 05:18:57 +0000 (UTC)
>
> VS> Как минимум на каждый такой левый сегмент твои хосты должны
> VS> отвечать TCP ресетом. Можно наверное придумать, как использовать
> VS> это в злонамеренных целях, например топологию сети разузнать.
>
> VS> Зачем вообще пускать в сеть пакеты, в которых _заведомо_ ничего
> VS> не может быть полезного? Зря что ли делают правила против
> VS> спуфинга etc?
> А некоторые еще и ICMP намертво фильтруют.
>
> VS> И не говори. Одни пионеры напридумывали разных stateful
> VS> inspection, adaptive security и прочего, а другие пионеры
> VS> купились.
> очевидно RST-пакет представляется меньшим злом, чем потенциальный DOS
> от stateful-подхода.
Генерация чего угодно от себя, в частности, tcp RST пакетов - потенциальный
источник DoS, причём в том числе и на чужие сети. Тем более, что сама по себе
генерация RST пакетов ни от каких атак не защищает, как было наглядно показано
недавним скандалом с великим китайским firewallом.
Вал. Дав.
Valentin Davydov
> Date: Fri, 27 Jul 2007 05:08:21 +0000 (UTC)
>
>> VS> Hасчёт established спорно. Пропускать пакет от кого попало только на
>> VS> том основании, что на нём есть ACK bit?
>
>> Hу, да. А что такого?
>
>Как минимум на каждый такой левый сегмент твои хосты должны отвечать
>TCP ресетом.
Зачем? Silently drop его и все дела.
Вал. Дав.
Andrew Alcheyev
Wednesday July 25 2007 at 15:41, Vadim Goncharov wrote to Andrew Alcheyev:
AA>> но вот лучше бы энергию портирования pf, да на благое дело
AA>> (нормализация трафика, traffic inspection,
VG> Что именно требуется?
про нормализацию коротко - scrub. хотя бы fragments reassembly без divert.
неплохо бы иметь и остальные фичи.
от traffic inspection я хочу нормальный фреймворк для обработки
пакетов на уровне ядра самописными приложениями. что-то типа абстрактного
аналога ng_nat/libalias, с нормальной документацией.
до кучи - аналог pfsync. именно из-за него я заинтересовался pf.
конкретно для ipfw - копирование dynamic rules (и в будущем nat table).
идеально - если интегрировать с carp ;-)
AA>> NAT экзотических случаев и т.п.) для ipfw.
VG> Тот же вопрос.
да хотя бы H.323. Про общую актуальность вопроса я в курсе, но когда встала
потребность - был облом. Тем более, что недостаточно простой замены src/dst ip.
AA>> NetBIOS/UDP, RSTP.
VG> А здесь какие проблемы?
А не знаю. Hо видимо они есть, раз сделаны workaround'ы в libalias.
С уважением.
Andrew Alcheyev
Thursday July 26 2007 at 09:25, Andrew Filonov wrote to Andrew Alcheyev:
AF>> Только на обычном траффике оно работает в разы быстрее.
AF> "Батюшка или крестик снимите, или трусы наденьте"
коллега, речь-то ведем об обычном трафике или обычной (сиречь простой)
конфигурации транслятора ? а что такое "обычный" трафик, кстати ?
неужели пара сотен редиректов портов и mapping десятка реальных сетей /C в
серые ипы ?
или вы всё же согласитесь, что речи про "обычный" трафик идти не может, когда
обслуживается что-то большее, чем офис с секретарями и менеджерами и появляется
штатная единица "сисадмин" ?
AF> Далеко не вся функциональность libalias которая выше приводилась,
AF> ng_nat'ом поддерживается. Также отсутствует функциональность binat и
AF> rdr. И что с чем вы предлагаете сравнивать?
предлагаю сравнивать скорость, на "обычном" трафике. поскольку вы не уточнили,
что он представляет из себя - то я вправе полагать его таким трафиком, который
появляется в результате "обычной" конфигурации NATа. да-да, той, которая в
случае NATD идёт из коробки.
что до остального - то всё так, за исключением rdr. есть аналог в ipfw.
при должной сноровке - rdr сейчас может иметь преимущество только в виде ясного
простого синтаксиса и наличия встроенного NAT.
реализовать же фичастость libalias в ng_nat или добавить возможность
redirect'ов блока адресов в libalias - не вижу никаких сложностей.
пока же, позволю себе повториться, видимо нет критической массы
юзеров-девелоперов, которым это надо.
не исключаю, что в том числе из-за наличия ipf/pf.
С уважением.
Victor Sudakov
> VS> Как минимум на каждый такой левый сегмент твои хосты должны
> VS> отвечать TCP ресетом. Можно наверное придумать, как использовать
> VS> это в злонамеренных целях, например топологию сети разузнать.
> VS> Зачем вообще пускать в сеть пакеты, в которых _заведомо_ ничего
> VS> не может быть полезного? Зря что ли делают правила против
> VS> спуфинга etc?
> А некоторые еще и ICMP намертво фильтруют.
Сдуру можно много чего сломать.
Но выборочно фильтровать ICMP (например echo request на свои хосты)
можно и нужно.
> VS> И не говори. Одни пионеры напридумывали разных stateful
> VS> inspection, adaptive security и прочего, а другие пионеры
> VS> купились.
> очевидно RST-пакет представляется меньшим злом, чем потенциальный DOS
> от stateful-подхода.
Пусть возьмут железку помощнее. Или если уж решили экономить на
безопасности сети, пусть не плачут.
Victor Sudakov
> Генерация чего угодно от себя, в частности, tcp RST пакетов - потенциальный
> источник DoS, причём в том числе и на чужие сети. Тем более, что сама по себе
> генерация RST пакетов ни от каких атак не защищает, как было наглядно показано
> недавним скандалом с великим китайским firewallом.
Заинтриговал. Что за история с с великим китайским firewallом?
Victor Sudakov
> >> VS> Hасчёт established спорно. Пропускать пакет от кого попало только на
> >> VS> том основании, что на нём есть ACK bit?
> >
> >> Hу, да. А что такого?
> >
> >Как минимум на каждый такой левый сегмент твои хосты должны отвечать
> >TCP ресетом.
> Зачем? Silently drop его и все дела.
Какие реализации умеют так?
Serge V.Panchenko
27 Jul 07 09:08, Victor Sudakov wrote to Serge V Panchenko:
>> VS> Hасчёт established спорно. Пропускать пакет от кого попало
>> VS> только на том основании, что на нём есть ACK bit?
>> Hу, да. А что такого?
VS> Как минимум на каждый такой левый сегмент твои хосты должны отвечать
VS> TCP ресетом. Можно наверное придумать, как использовать это в
VS> злонамеренных целях, например топологию сети разузнать.
Топологию сети за NAT'ом? ;-)
VS> Зачем вообще пускать в сеть пакеты, в которых _заведомо_ ничего не
VS> может быть полезного? Зря что ли делают правила против спуфинга etc?
Hу, давайте ещё пинги зарежем. От них, ведь, тоже проку мало. И трейсруту по
башке дадим.
>> Ох уж эти юные админы в пионерских галстуках... ;-))
VS> И не говори. Одни пионеры напридумывали разных stateful inspection,
VS> adaptive security и прочего, а другие пионеры купились.
Есть и такая буква. В например, в CISCO 851-ой серии (это у которых 4 соска во
внутренний LAN и пропускная способность 500 кб/сек) тоже есть эти фичи. И
клиент за них плАтит. Только вот, пользует ли? А если и пользует, то какой в
этом смысл? Пять компьютеров обнести железобетонной стеной и наделать в ней
сотню картонных калиток?
С уважением, Сережка В. Панченко...
Andrew Filonov
AF> Только на обычном траффике оно работает в разы быстрее. "Батюшка
AF> или крестик снимите, или трусы наденьте"
AA> коллега, речь-то ведем об обычном трафике или обычной (сиречь
AA> простой) конфигурации транслятора ? а что такое "обычный" трафик,
AA> кстати ?
Который не требует специальной обработки с анализом содержимого
пакетов.
AA> или вы всё же согласитесь, что речи про "обычный" трафик идти не
AA> может, когда обслуживается что-то большее, чем офис с секретарями
AA> и менеджерами и появляется штатная единица "сисадмин" ?
Не соглашусь.
--
Andrew E. Filonov
You may know where the market is going, but you can't
possibly know where it's going after that.
Andrew Filonov
VS> И не говори. Одни пионеры напридумывали разных stateful
VS> inspection, adaptive security и прочего, а другие пионеры
VS> купились.
>> очевидно RST-пакет представляется меньшим злом, чем потенциальный
>> DOS от stateful-подхода.
VS> Пусть возьмут железку помощнее.
Потенциальные возможности TCP перекрывают любые современные железки.
VS> Или если уж решили экономить на безопасности сети, пусть не
VS> плачут.
Плач почему-то исходит от любителей stateful подхода.
--
Andrew E. Filonov
The more general the title of a course, the less
you will learn from it.
Valentin Davydov
> Date: Fri, 27 Jul 2007 08:11:39 +0000 (UTC)
>
>> >> VS> Hасчёт established спорно. Пропускать пакет от кого попало только на
>> >> VS> том основании, что на нём есть ACK bit?
>> >
>> >> Hу, да. А что такого?
>> >
>> >Как минимум на каждый такой левый сегмент твои хосты должны отвечать
>> >TCP ресетом.
>
>> Зачем? Silently drop его и все дела.
>
>Какие реализации умеют так?
Сабжи читаем?
Вал. Дав.
Valentin Davydov
> Date: Fri, 27 Jul 2007 08:10:38 +0000 (UTC)
>
>> VS> Как минимум на каждый такой левый сегмент твои хосты должны
>> VS> отвечать TCP ресетом. Можно наверное придумать, как использовать
>> VS> это в злонамеренных целях, например топологию сети разузнать.
>
>> VS> Зачем вообще пускать в сеть пакеты, в которых _заведомо_ ничего
>> VS> не может быть полезного? Зря что ли делают правила против
>> VS> спуфинга etc?
>> А некоторые еще и ICMP намертво фильтруют.
>
>Сдуру можно много чего сломать.
>
>Но выборочно фильтровать ICMP (например echo request на свои хосты)
>можно и нужно.
Не поможет. Ну, то есть, максимум, чего можно добиться фильтрацией
echo request на свои хосты - затруднить диагностику проблем (типа,
звнит юзер, "у меня интернет не работает", а ты ему даже попинговать
посоветовать не можешь). А зафлудить тебя могут любыми незафильтрованными
пакетами, конкретный тип icmp здесь ни при чём.
>> VS> И не говори. Одни пионеры напридумывали разных stateful
>> VS> inspection, adaptive security и прочего, а другие пионеры
>> VS> купились.
>> очевидно RST-пакет представляется меньшим злом, чем потенциальный DOS
>> от stateful-подхода.
>
>Пусть возьмут железку помощнее.
Это помогает только продавцам железок.
Вал. Дав.
Vadim Guchenko
You wrote to Vadim Guchenko on Sat, 21 Jul 2007 12:15:44 +0000 (UTC):
VG> Это всё варианты DoS-атак, тут все верно. Возможная дырявость
VG> established заключается в другом - если за шлюзом сеть с реальными
VG> адресами и в ней есть инсайдер, он может организовать обход
VG> файрвола, обойдясь без начального пакета с SYN, так что все подпадут
VG> под established. Но для случая с NATом этот вариант опять-таки
нереален.
Ты имеешь в виду, что кто-то внутри защищенной сети посылает на соседнюю
машину с реальным адресом запрос на установку соединения на TCP порт,
который открыт только для внутренней сети и закрыт из интернета, причем в
этом пакете в качестве src_ip и src_port указаны адрес и порт удаленного
атакующего? Поскольку обе машины находятся в одном ethernet-сегменте и их
трафик не проходит через L3 устройство, антиспуфинг сделать некому. Тогда
атакуемый хост, не имея файрвола, честно отошлет этому удаленному атакующему
подтверждение на установку соединения и файрвол на шлюзе это пропустит, если
в нем есть allow tcp from any to any established. Атакующему нужно лишь быть
готовым принять второй пакет и подтвердить его. Согласен. Но разве нат в
этом случае не пропустит пакет наружу и не примет для него ответ? Разве он
смотрит какие там TCP-флаги выставлены на пакете и на этом основании
транслирует его или отбрасывает? То же самое наверное относится и к
keep-state. С одной стороны в sysctl есть различные переменные вида
dyn_ack_lifetime, dyn_syn_lifetime и т.д, с другой стороны эти переменные
могут влиять только на время жизни динамического правила ipfw, но не на
условие его создания. Точно насчет этого я не знаю. В манах не написано, а
исходники я не смотрел. Единственное, что приходит в голову: сделать на
шлюзе не просто allow tcp from any to any keep-state, а с флагом setup. Но
инсайдер с таким же успехом может послать пакет на установку соединения
наружу на адрес и порт атакующего якобы с адреса и порта атакуемого, чтобы
создать динамическое правило в ipfw. С другой стороны, если есть инсайдер,
зачем такие сложности с файрволом? Он и так всю инфу сам может посмотреть и
слить. Или выступить в качестве прокси для удаленного атакующего.
--
Best regards, Vadim.
Vadim Goncharov
On Fri, 27 Jul 2007 08:10:38 +0000 (UTC); Victor Sudakov wrote about 'Re: ipfw and keep-state':
VS> Но выборочно фильтровать ICMP (например echo request на свои хосты)
VS> можно и нужно.
Зачем?
Vadim Goncharov
On Fri, 27 Jul 2007 11:53:00 +0400; Andrew Alcheyev wrote about 'ipfw and keep-state':
AA>>> но вот лучше бы энергию портирования pf, да на благое дело
AA>>> (нормализация трафика, traffic inspection,
VG>> Что именно требуется?
AA> про нормализацию коротко - scrub. хотя бы fragments reassembly без divert.
AA> неплохо бы иметь и остальные фичи.
У них есть реальное применение, кроме сборки? Которую можно дивертом
сделать, да.
AA> от traffic inspection я хочу нормальный фреймворк для обработки
AA> пакетов на уровне ядра самописными приложениями. что-то типа абстрактного
AA> аналога ng_nat/libalias, с нормальной документацией.
Как бы это выглядело? netgraph не устраивает?
Vadim Goncharov
On Fri, 27 Jul 2007 21:05:07 +0000 (UTC); Vadim Guchenko wrote about 'Re: ipfw and keep-state':
VG> Ты имеешь в виду, что кто-то внутри защищенной сети посылает на соседнюю
VG> машину с реальным адресом запрос на установку соединения на TCP порт,
VG> который открыт только для внутренней сети и закрыт из интернета, причем в
VG> этом пакете в качестве src_ip и src_port указаны адрес и порт удаленного
VG> атакующего? Поскольку обе машины находятся в одном ethernet-сегменте и их
VG> трафик не проходит через L3 устройство, антиспуфинг сделать некому. Тогда
VG> атакуемый хост, не имея файрвола, честно отошлет этому удаленному атакующему
VG> подтверждение на установку соединения и файрвол на шлюзе это пропустит, если
VG> в нем есть allow tcp from any to any established. Атакующему нужно лишь быть
VG> готовым принять второй пакет и подтвердить его. Согласен.
Зачем так сложно? хотя можно и так соединения с другими машинами
организовывать, да. См. ниже про инсайдера.
VG> Но разве нат в
VG> этом случае не пропустит пакет наружу и не примет для него ответ? Разве он
Причем тут нат, когда речь о сети с реальными адресами?
VG> смотрит какие там TCP-флаги выставлены на пакете и на этом основании
VG> транслирует его или отбрасывает?
Разумеется, смотрит - man natd /-deny_incoming
VG> То же самое наверное относится и к
VG> keep-state. С одной стороны в sysctl есть различные переменные вида
VG> dyn_ack_lifetime, dyn_syn_lifetime и т.д, с другой стороны эти переменные
VG> могут влиять только на время жизни динамического правила ipfw, но не на
VG> условие его создания. Точно насчет этого я не знаю. В манах не написано, а
VG> исходники я не смотрел.
Учитывает, учитывает. Даже номера последовательностей TCP учитывает.
Правда, состояние все равно будет создано на net.inet.ip.fw.dyn_rst_lifetime
секунд (по умолчанию одна).
VG> Единственное, что приходит в голову: сделать на
VG> шлюзе не просто allow tcp from any to any keep-state, а с флагом setup.
Так обычно и делают.
VG> Но инсайдер с таким же успехом может послать пакет на установку соединения
VG> наружу на адрес и порт атакующего якобы с адреса и порта атакуемого, чтобы
VG> создать динамическое правило в ipfw. С другой стороны, если есть инсайдер,
VG> зачем такие сложности с файрволом? Он и так всю инфу сам может посмотреть и
VG> слить. Или выступить в качестве прокси для удаленного атакующего.
Об этом я и говорил. Инсайдер может принять снаружи от атакующего первый пакет
без SYN и т.п., как-либо модифицировав свой tcp-стек, к примеру - и оно
пройдет через established.
Vadim Guchenko
You wrote to Vadim Guchenko on Sat, 28 Jul 2007 17:20:06 +0000 (UTC):
VG>> Но разве нат в этом случае не пропустит пакет наружу и не примет
VG>> для него ответ? Разве он
VG> Причем тут нат, когда речь о сети с реальными адресами?
Ты в последней фразе написал, что для случая с натом такой вариант не
реален.
VG>> смотрит какие там TCP-флаги выставлены на пакете и на этом
VG>> основании транслирует его или отбрасывает?
VG> Разумеется, смотрит - man natd /-deny_incoming
Причем тут deny_incoming? Я говорю о случае, когда TCP-пакет изнутри сети
идет наружу. Нат должен создать запись в таблице трансляции и пропустить
пакет. И соответственно принять ответный пакет. А смотрит ли он при создании
записи, что TCP пакет на самом деле не первый, а второй в рукопожатии -
вопрос спорный.
VG>> То же самое наверное относится и к keep-state. С одной стороны в
VG>> sysctl есть различные переменные вида dyn_ack_lifetime,
VG>> dyn_syn_lifetime и т.д, с другой стороны эти переменные могут
VG>> влиять только на время жизни динамического правила ipfw, но не на
VG>> условие его создания. Точно насчет этого я не знаю. В манах не
VG>> написано, а исходники я не смотрел.
VG> Учитывает, учитывает. Даже номера последовательностей TCP учитывает.
VG> Правда, состояние все равно будет создано на
VG> net.inet.ip.fw.dyn_rst_lifetime секунд (по умолчанию одна).
А если будет создано, за эту секунду вполне можно успеть начать обмен
пакетами с ACK и состояние будет поддерживаться.
VG>> Но инсайдер с таким же успехом может послать пакет на установку
VG>> соединения наружу на адрес и порт атакующего якобы с адреса и порта
VG>> атакуемого, чтобы создать динамическое правило в ipfw. С другой
VG>> стороны, если есть инсайдер, зачем такие сложности с файрволом? Он
VG>> и так всю инфу сам может посмотреть и слить. Или выступить в
VG>> качестве прокси для удаленного атакующего.
VG> Об этом я и говорил. Инсайдер может принять снаружи от атакующего
VG> первый пакет без SYN и т.п., как-либо модифицировав свой tcp-стек, к
VG> примеру - и оно пройдет через established.
Зачем такие сложности? Инсайдер может сам установить с атакующим исходящее
TCP-соединение, которое пройдет и через нат, и через файрвол с keep-state. И
established тут вообще роли не играет.
--
Best regards, Vadim.
Alex Semenyaka
27 Jul 07 12:23, you wrote to Victor Sudakov:
VS>> И не говори. Одни пионеры напридумывали разных stateful
VS>> inspection, adaptive security и прочего, а другие пионеры
VS>> купились.
>>> очевидно RST-пакет представляется меньшим злом, чем потенциальный
>>> DOS от stateful-подхода.
VS>> Пусть возьмут железку помощнее.
AF> Потенциальные возможности TCP перекрывают любые современные железки.
Hу да. PIX535 закрывает сеть с тысячами хостов, и справляется нормально. А это
- архитектура x86.
Alex
Victor Sudakov
> VS> Но выборочно фильтровать ICMP (например echo request на свои хосты)
> VS> можно и нужно.
> Зачем?
Ты неправильно ставишь вопрос. Надо спрашивать не "почему этот трафик
тут не нужен", а "зачем этот трафик тут нужен"?
Когда речь идёт о защите внутренней сети, мне больше нравится подход
"запрещено всё, что не разрешено".
Victor Sudakov
> >> >> VS> Hасчёт established спорно. Пропускать пакет от кого попало только на
> >> >> VS> том основании, что на нём есть ACK bit?
> >> >
> >> >> Hу, да. А что такого?
> >> >
> >> >Как минимум на каждый такой левый сегмент твои хосты должны отвечать
> >> >TCP ресетом.
> >
> >> Зачем? Silently drop его и все дела.
> >
> >Какие реализации умеют так?
> Сабжи читаем?
Сабжем мне как раз предлагают пропустить в сеть любой TCP сегмент
только на том основании, что на нём есть ACK bit. Что и будет
порождать ресеты от внутренних хостов.
Victor Sudakov
> >> VS> Hасчёт established спорно. Пропускать пакет от кого попало
> >> VS> только на том основании, что на нём есть ACK bit?
> >> Hу, да. А что такого?
> VS> Как минимум на каждый такой левый сегмент твои хосты должны отвечать
> VS> TCP ресетом. Можно наверное придумать, как использовать это в
> VS> злонамеренных целях, например топологию сети разузнать.
> Топологию сети за NAT'ом? ;-)
И за натом тоже, если например нат статический.
А если не статический, он как раз и обеспечит stateful inspection, за
которую я ратую.
> VS> Зачем вообще пускать в сеть пакеты, в которых _заведомо_ ничего не
> VS> может быть полезного? Зря что ли делают правила против спуфинга etc?
> Hу, давайте ещё пинги зарежем. От них, ведь, тоже проку мало. И трейсруту по
> башке дадим.
Совершенно согласен, если речь о внутренней защищаемой сети, например
корпоративной.
> >> Ох уж эти юные админы в пионерских галстуках... ;-))
> VS> И не говори. Одни пионеры напридумывали разных stateful inspection,
> VS> adaptive security и прочего, а другие пионеры купились.
> Есть и такая буква. В например, в CISCO 851-ой серии (это у которых
> 4 соска во внутренний LAN и пропускная способность 500 кб/сек) тоже
> есть эти фичи. И клиент за них плАтит. Только вот, пользует ли? А
Скорее всего да. В простейшей конфигурации с динамическим натом оно
примерно так и будет работать.
> если и пользует, то какой в этом смысл? Пять компьютеров обнести
> железобетонной стеной и наделать в ней сотню картонных калиток?
О калитках прошу поподробнее. Если речь об атаках через браузер и пр.,
то это уже совсем другой вопрос.
Victor Sudakov
> VS> И не говори. Одни пионеры напридумывали разных stateful
> VS> inspection, adaptive security и прочего, а другие пионеры
> VS> купились.
> >> очевидно RST-пакет представляется меньшим злом, чем потенциальный
> >> DOS от stateful-подхода.
> VS> Пусть возьмут железку помощнее.
> Потенциальные возможности TCP перекрывают любые современные железки.
Если некто не может оценить потребности своей сети, он ССЗБ.
> VS> Или если уж решили экономить на безопасности сети, пусть не
> VS> плачут.
> Плач почему-то исходит от любителей stateful подхода.
Отучаемся говорить за всех любителей stateful подхода?
ЗЫ Никто никогда не говорил, что защита бывает нахаляву.
Victor Sudakov
> >
> >> VS> Как минимум на каждый такой левый сегмент твои хосты должны
> >> VS> отвечать TCP ресетом. Можно наверное придумать, как использовать
> >> VS> это в злонамеренных целях, например топологию сети разузнать.
> >
> >> VS> Зачем вообще пускать в сеть пакеты, в которых _заведомо_ ничего
> >> VS> не может быть полезного? Зря что ли делают правила против
> >> VS> спуфинга etc?
> >> А некоторые еще и ICMP намертво фильтруют.
> >
> >Сдуру можно много чего сломать.
> >
> >Но выборочно фильтровать ICMP (например echo request на свои хосты)
> >можно и нужно.
> Не поможет. Ну, то есть, максимум, чего можно добиться фильтрацией
> echo request на свои хосты - затруднить диагностику проблем (типа,
> звнит юзер, "у меня интернет не работает", а ты ему даже попинговать
> посоветовать не можешь).
Внимательно читай. Я не предлагал закрывать ICMP echo request изнутри
наружу.
> А зафлудить тебя могут любыми незафильтрованными
> пакетами, конкретный тип icmp здесь ни при чём.
Именно поэтому никаким таким "любым" пакетам нечего делать во
внутренней сети. Т.е. если некий пакет пропускаешь внутрь, то должен
чётко представлять, зачем.
Andrew Filonov
>> Потенциальные возможности TCP перекрывают любые современные
>> железки.
VS> Если некто не может оценить потребности своей сети, он ССЗБ.
Ну оцени потребности всекитайской сети.
>> Плач почему-то исходит от любителей stateful подхода.
VS> Отучаемся говорить за всех любителей stateful подхода?
Отучаемся передергивать. Где в моих словах ты увидел слово "всех"?
--
Andrew E. Filonov
How long a minute is depends on which side of the
bathroom door you're on.
Victor Sudakov
> >> Потенциальные возможности TCP перекрывают любые современные
> >> железки.
> VS> Если некто не может оценить потребности своей сети, он ССЗБ.
> Ну оцени потребности всекитайской сети.
Если буду работать в Китае в соответствующей организации на
соответствующей должности - обязательно займусь оценкой, и подойду к
вопросу со всей ответственностью.
Хоть и подозреваю, что китайцам stateful firewall на самом деле не
нужен. У них ведь задача не сеть защитить, а умы.
> >> Плач почему-то исходит от любителей stateful подхода.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> VS> Отучаемся говорить за всех любителей stateful подхода?
> Отучаемся передергивать.
Кто бы говорил :)
> Где в моих словах ты увидел слово "всех"?
Я подчеркнул. Если ты готов изменить свою формулировку на нечто вроде
"плач исходит от некоторых любителей stateful подхода", то по такой
формулировке возражений нет. Эти любители решили сэкономить, а теперь
плачут. Вполне закономерный результат.
Andrew Filonov
>> >> Плач почему-то исходит от любителей stateful подхода.
VS> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
VS> Отучаемся говорить за всех любителей stateful подхода?
>> Отучаемся передергивать.
VS> Кто бы говорил :)
>> Где в моих словах ты увидел слово "всех"?
VS> Я подчеркнул.
В подчеркнутом нет вышеуказанного слова.
VS> Если ты готов изменить свою формулировку на нечто вроде "плач
VS> исходит от некоторых любителей stateful подхода",
Моя не понимайт вашего русскаго йазыку. В моем русском языке эти две
фразы эквивалентны.
VS> по такой формулировке возражений нет. Эти любители решили
VS> сэкономить, а теперь плачут. Вполне закономерный результат.
--
Andrew E. Filonov
When the need arises, any tool or object closest to you
becomes a hammer.
Serge V.Panchenko
30 Jul 07 06:37, Victor Sudakov wrote to Vadim Goncharov:
VS> Когда речь идёт о защите внутренней сети, мне больше нравится подход
VS> "запрещено всё, что не разрешено".
Hекоторые воспринимают это как "запрещено всё, что я не понимаю/не знаю".
Serge V.Panchenko
30 Jul 07 06:54, Victor Sudakov wrote to Serge V Panchenko:
>> Есть и такая буква. В например, в CISCO 851-ой серии (это у которых
>> 4 соска во внутренний LAN и пропускная способность 500 кб/сек) тоже
>> есть эти фичи. И клиент за них плАтит. Только вот, пользует ли? А
VS> Скорее всего да. В простейшей конфигурации с динамическим натом оно
VS> примерно так и будет работать.
>> если и пользует, то какой в этом смысл? Пять компьютеров обнести
>> железобетонной стеной и наделать в ней сотню картонных калиток?
VS> О калитках прошу поподробнее. Если речь об атаках через браузер и пр.,
VS> то это уже совсем другой вопрос.
Hе бывает одно без другого. Когда закрывается маленькая сетюшка, почти
бессмысленно наворачивать защиту с логикой - ибо целенаправленная (на данную
сеть) атака если и будет делаться, то совсем не через RST. И кроме атак через
браузер/icq/почту есть ещё и атаки через людей (слово "инсайдер" тут уже
всплыло) - это гораздо эффективнее. IMHO, конечно.
Victor Sudakov
> >> >> Плач почему-то исходит от любителей stateful подхода.
> VS> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> VS> Отучаемся говорить за всех любителей stateful подхода?
> >> Отучаемся передергивать.
> VS> Кто бы говорил :)
> >> Где в моих словах ты увидел слово "всех"?
> VS> Я подчеркнул.
> В подчеркнутом нет вышеуказанного слова.
> VS> Если ты готов изменить свою формулировку на нечто вроде "плач
> VS> исходит от некоторых любителей stateful подхода",
> Моя не понимайт вашего русскаго йазыку. В моем русском языке эти две
> фразы эквивалентны.
Принято. Значит, есть ненулевое количество любителей stateful
подхода, у которых всё работает. ЧТД.
Alex Mogilnikov
30 Jul 07 06:39, Victor Sudakov писал Valentin Davydov:
>> Сабжи читаем?
VS> Сабжем мне как раз предлагают пропустить в сеть любой TCP сегмент
VS> только на том основании, что на нём есть ACK bit. Что и будет
VS> порождать ресеты от внутренних хостов.
По-моему, ты путаешь с established.
Всего наилучшего, [Team PCAD 2000]
Алексей М.
... Если долго думать одни и те же мысли, они становятся грязными.
Victor Sudakov
> >> Сабжи читаем?
> VS> Сабжем мне как раз предлагают пропустить в сеть любой TCP сегмент
> VS> только на том основании, что на нём есть ACK bit. Что и будет
> VS> порождать ресеты от внутренних хостов.
> По-моему, ты путаешь с established.
Мне предлагают использовать established вместо keep-state, я объясняю,
чем это на мой взгляд плохо.
Victor Sudakov
> VS> Когда речь идёт о защите внутренней сети, мне больше нравится подход
> VS> "запрещено всё, что не разрешено".
> Hекоторые воспринимают это как "запрещено всё, что я не понимаю/не знаю".
Можно и так сказать.
Victor Sudakov
> >> Есть и такая буква. В например, в CISCO 851-ой серии (это у которых
> >> 4 соска во внутренний LAN и пропускная способность 500 кб/сек) тоже
> >> есть эти фичи. И клиент за них плАтит. Только вот, пользует ли? А
> VS> Скорее всего да. В простейшей конфигурации с динамическим натом оно
> VS> примерно так и будет работать.
> >> если и пользует, то какой в этом смысл? Пять компьютеров обнести
> >> железобетонной стеной и наделать в ней сотню картонных калиток?
> VS> О калитках прошу поподробнее. Если речь об атаках через браузер и пр.,
> VS> то это уже совсем другой вопрос.
> Hе бывает одно без другого. Когда закрывается маленькая сетюшка,
> почти бессмысленно наворачивать защиту с логикой - ибо
> целенаправленная (на данную сеть) атака если и будет делаться, то
> совсем не через RST.
Боюсь, ты преуменьшаешь опасность. Какова судьба винды, выставленной в
Интернет? IMHO заражение наступает через несколько минут.
Слово "наворачивать" тоже вряд ли уместно. В виденных мной продуктах
stateful inspection в простых случаях не требовал практически никакой
конфигурации.
Помнится, меня в своё время весьма впечатлило, как это сделано в ipf.
Включалось одним словом state.
> И кроме атак через браузер/icq/почту есть ещё и
> атаки через людей (слово "инсайдер" тут уже всплыло) - это гораздо
> эффективнее. IMHO, конечно.
Против разных угроз есть разные методы. Но не стоит пренебрегать одной
из угроз на том основании, что существуют и другие угрозы.
Leizer A. Karabin
Я, собственно, просто так вышел Monday July 30 2007 13:18,
тут слышу - Serge V.Panchenko говорит Victor Sudakov (ну я встрял, конечно):
VS>> Когда речь идёт о защите внутренней сети, мне больше нравится подход
VS>> "запрещено всё, что не разрешено".
SVP> Hекоторые воспринимают это как "запрещено всё, что я не понимаю/не знаю".
Это здравые, годные ребята.
За сим навеки и проч. Leizer [Team Smile'ик - отменить!]
Eugene Grosbein
VS>>> Когда речь идёт о защите внутренней сети, мне больше нравится подход
VS>>> "запрещено всё, что не разрешено".
SVP>> Hекоторые воспринимают это как "запрещено всё, что я не понимаю/не
SVP>> знаю".
LAK> Это здравые, годные ребята.
Которые ломают PMTUD в интернете и удостоились отдельного упоминания
в man vlan как "неадекватные".
Eugene
--
Дьявол в мелочах
Serge V.Panchenko
30 Jul 07 14:50, Victor Sudakov wrote to Serge V Panchenko:
VS> Против разных угроз есть разные методы. Hо не стоит пренебрегать одной
VS> из угроз на том основании, что существуют и другие угрозы.
Hо и не стоит сосредотачивать все усилия на одной угрозе. ;-) По пиву? ;-)
Serge V.Panchenko
30 Jul 07 14:34, Victor Sudakov wrote to Alex Mogilnikov:
>> VS> Сабжем мне как раз предлагают пропустить в сеть любой TCP
>> VS> сегмент только на том основании, что на нём есть ACK bit. Что и
>> VS> будет порождать ресеты от внутренних хостов.
>> По-моему, ты путаешь с established.
VS> Мне предлагают использовать established вместо keep-state, я объясняю,
VS> чем это на мой взгляд плохо.
Hельзя сравнивать keep-state и established напрямую. Для каждого из них есть
своя ниша. Городить защиту с логикой там, где достаточно простой фильтрации -
бесполезная трата времени. Лучше бы обратили внимание на другие аспекты защиты
информации.
Max Khon
26 Jul 07 08:30, you wrote to Vadim Goncharov:
AA>> Я могу ошибаться, но навскидку гугление и поиск по сорцам
AA>> libalias и pf показали, что: CUSEEME, IRC (DCC), PPTP (несколько
AA>> сессий к одному серверу), NetBIOS/UDP, RSTP.
AF>> Только на обычном траффике оно работает в разы быстрее.
VG>> В разы быстрее чего?
AF> natd очевидно. Других способов обеспечить вышеуказанную
AF> функциональность в полном объеме просто нет на данный момент.
ipfilter+ipnat?
VG>> Как файрвол pf медленне ipfw. Если нат - надо сравнивать ng_nat
VG>> либо ipfw nat в 7-ке.
AF> Когда будет 7ка в STABLE - тогда и будем сравнивать. А до тех пор
AF> способов сравнить pfnat'овский rdr c ng_nat - лично я не вижу.
/fjoe
Andrew Filonov
AF> natd очевидно. Других способов обеспечить вышеуказанную
AF> функциональность в полном объеме просто нет на данный момент.
MK> ipfilter+ipnat?
А ipnat'у уже приделали таблицы?
--
Andrew E. Filonov
A man should be greater than some of his parts.
Alex Semenyaka
31 Jul 07 09:53, you wrote to Leizer A Karabin:
VS>>>> Когда речь идёт о защите внутренней сети, мне больше нравится
VS>>>> подход "запрещено всё, что не разрешено".
SVP>>> Hекоторые воспринимают это как "запрещено всё, что я не
SVP>>> понимаю/не знаю".
LAK>> Это здравые, годные ребята.
EG> Которые ломают PMTUD в интернете и удостоились отдельного упоминания
EG> в man vlan как "неадекватные".
Просто не надо до абсурда доводить.
Alex
Eugene Grosbein
VS>>>>> Когда речь идёт о защите внутренней сети, мне больше нравится
VS>>>>> подход "запрещено всё, что не разрешено".
SVP>>>> Hекоторые воспринимают это как "запрещено всё, что я не
SVP>>>> понимаю/не знаю".
LAK>>> Это здравые, годные ребята.
EG>> Которые ломают PMTUD в интернете и удостоились отдельного упоминания
EG>> в man vlan как "неадекватные".
AS> Просто не надо до абсурда доводить.
Так ведь они не прилагают специальных усилий к этому, думается.
Eugene
--
Пробуй, но не смей глотать
Alex Semenyaka
01 Aug 07 00:51, you wrote to me:
VS>>>>>> Когда речь идёт о защите внутренней сети, мне больше нравится
VS>>>>>> подход "запрещено всё, что не разрешено".
SVP>>>>> Hекоторые воспринимают это как "запрещено всё, что я не
SVP>>>>> понимаю/не знаю".
LAK>>>> Это здравые, годные ребята.
EG>>> Которые ломают PMTUD в интернете и удостоились отдельного
EG>>> упоминания в man vlan как "неадекватные".
AS>> Просто не надо до абсурда доводить.
EG> Так ведь они не прилагают специальных усилий к этому, думается.
Мнэ-э-э-э... Объясняю. Минимальная необходимая квалификация - это вообще тот
нулевой уровень, который подразумевается в разговоре. Ипользование обратного
предположения - доведение до абсурда.
С другой стороны, если любой специалист знает отнюдь не всё. И в условиях
enterprise админ (напоминаю, мы предполагаем, что он имеет минимальную
квалификацию) должен закрывать всё, чего не знает.
Для service provider это, чаще всего, неверно - ну так не про это и речь.
Alex
Eugene Grosbein
EG> Минимально необходимая квалификация это вовсе не некий общеизвестный
EG> эталон, они (или набор) на весь мир.
s/они/один/
Eugene
--
Hароду - чтоб не вздумал бунтовать! -
Мы тоже разрешили воровать.
Пусть лучше сам ворует потихоньку,
Чем с воровскою властью враждовать!..
Eugene Grosbein
EG>>>> Которые ломают PMTUD в интернете и удостоились отдельного
EG>>>> упоминания в man vlan как "неадекватные".
AS>>> Просто не надо до абсурда доводить.
EG>> Так ведь они не прилагают специальных усилий к этому, думается.
AS> Мнэ-э-э-э... Объясняю. Минимальная необходимая квалификация - это вообще
AS> тот
AS> нулевой уровень, который подразумевается в разговоре. Ипользование
AS> обратного
AS> предположения - доведение до абсурда.
Минимально необходимая квалификация это вовсе не некий общеизвестный
эталон, они (или набор) на весь мир. В зависимости от местных потребностей
очень сильно варьируется и очень часто отсутствует - это реальность,
а не доведение до абсурда.
AS> С другой стороны, если любой специалист знает отнюдь не всё. И в условиях
AS> enterprise админ (напоминаю, мы предполагаем, что он имеет минимальную
AS> квалификацию)
Весьма смелое предположение ;-) как показывает опыт.
AS> должен закрывать всё, чего не знает.
Вот они и закрывают ICMP.
AS> Для service provider это, чаще всего, неверно - ну так не про это и речь.
Это для всех неверно imho.
Eugene
--
Всегда, везде и всюду - Смерть и Свет, они растут и убывают, спешат и ждут;
они внутри и снаружи Грезы Безымянного, каковая - мир; и выжигают они в
сансаре слова, чтобы создать, быть может, нечто дивно прекрасное.
Leizer A. Karabin
Я, собственно, просто так вышел Wednesday August 01 2007 09:56,
тут слышу - Eugene Grosbein говорит Alex Semenyaka (ну я встрял, конечно):
EG>>>>> Которые ломают PMTUD в интернете и удостоились отдельного
EG>>>>> упоминания в man vlan как "неадекватные".
AS>>>> Просто не надо до абсурда доводить.
EG>>> Так ведь они не прилагают специальных усилий к этому, думается.
AS>> Мнэ-э-э-э... Объясняю. Минимальная необходимая квалификация - это вообще
AS>> тот
AS>> нулевой уровень, который подразумевается в разговоре. Ипользование
AS>> обратного
AS>> предположения - доведение до абсурда.
EG> Минимально необходимая квалификация это вовсе не некий общеизвестный
EG> эталон, они (или набор) на весь мир. В зависимости от местных потребностей
EG> очень сильно варьируется и очень часто отсутствует - это реальность,
EG> а не доведение до абсурда.
AS>> С другой стороны, если любой специалист знает отнюдь не всё. И в
AS>> условиях enterprise админ (напоминаю, мы предполагаем, что он имеет
AS>> минимальную квалификацию)
EG> Весьма смелое предположение ;-) как показывает опыт.
AS>> должен закрывать всё, чего не знает.
EG> Вот они и закрывают ICMP.
AS>> Для service provider это, чаще всего, неверно - ну так не про это и
AS>> речь.
EG> Это для всех неверно imho.
Закрывать всё, чего не понимаешь, - разумно. Hеразумно поручать
корпоративный непровайдерский роутер админу, который не понимает, зачем бывают
icmp-пакеты. А, стало быть, не читал даже man ipwf.
Ilya Kulagin
AS> С другой стороны, если любой специалист знает отнюдь не всё. И в
AS> условиях enterprise админ (напоминаю, мы предполагаем, что он имеет
AS> минимальную квалификацию) должен закрывать всё, чего не знает.
Hу да. Поэтому я для создания vpn-концентратора предпочитаю использовать
openvpn висящий на 443 TCP порту. Мало ли кто чего запретит и через какую
эээ... конфигурацию заставит работать. Были прецеденты...
Пpимитe увеpение в cовеpшеннейшем к Вам почтении.
/Moose
... И пускай уж зима, если будет весна.