> setup не спасает от SYN-флуда, он вообще никаким раком на него не влияет.Сам setup нет. Вкупе с limit да.
Смотрим мой пост 5 выше.
Цитата из него:Ещё совместно с флагом setup удобно использовать limit ограничивая количество подключений к хосту или порту.
> думайте что пишите.
Я думаю, в отличии от вас.
> limit {src-addr | src-port | dst-addr | dst-port} спасает в таких случаях
См. выше, опять же пост 5. Это уже было.
Вы в очередной раз показали свою невнимательность.
> Ну так просвятите...
"просвятить"? Святым хотите стать? Это не здесь.
Это вам в семинарию надо.
Если же вы хотите просветиться, то как же вас просвещать, если вы очевидное отрицаете?
Я понимаю, почему вы отрицаете. Это психологическая защита. Нежелание признавать свою неправоту.
Хуже упорства может быть только тупое и глупое упорство.
> SYN-флуд и setup - это бред, вы уж извините.
По вашему получается, что SYN-флуд это бред?!
Так флагом setup и можно выделить эти SYN-пакеты, понимаете?
И соответственно, принять меры защиты от чрезмерного затопления этими пакетами.
Или вы действительно считаете, что разработчики в man ipfw пишут бред?
Однако..
Смотрим ваш старт:
Есть ли какой-нибудь смысл использовать keep-state вместе с setup? Если да, то приведите наглядные примеры.
Ответ:
Да, смысл есть. Наглядные примеры приведены в man ipfw
Когда на форумах частенько отсылают к страницам справочного руководства и документации,
то поверьте, в этом есть смысл. И железная логика.
Ибо пересказ документации прочитанной другим человеком - это не ваше понимание и толкование, а понимание и интерпретация того человека.
Вы сами должны. Понимаете? Сами! И никто за вас, никто вам свои мозги не вложит.
Открываем man ipfw:
STATEFUL FIREWALL
Stateful operation is a way for the firewall to dynamically create rules
for specific flows when packets that match a given pattern are detected.
Support for stateful operation comes through the check-state, keep-state
and limit options of rules.
Dynamic rules are created when a packet matches a keep-state or limit
rule, causing the creation of a dynamic rule which will match all and
only packets with a given protocol between a src-ip/src-port
dst-ip/dst-port pair of addresses (src and dst are used here only to
denote the initial match addresses, but they are completely equivalent
afterwards). Dynamic rules will be checked at the first check-state,
keep-state or limit occurrence, and the action performed upon a match
will be the same as in the parent rule.
Note that no additional attributes other than protocol and IP addresses
and ports are checked on dynamic rules.
The typical use of dynamic rules is to keep a closed firewall configura-
tion, but let the first TCP SYN packet from the inside network install a
dynamic rule for the flow so that packets belonging to that session will
be allowed through the firewall:
ipfw add check-state
ipfw add allow tcp from my-subnet to any setup keep-state
ipfw add deny tcp from any to any
A similar approach can be used for UDP, where an UDP packet coming from
the inside will install a dynamic rule to let the response through the
firewall:
ipfw add check-state
ipfw add allow udp from my-subnet to any keep-state
ipfw add deny udp from any to any
Dynamic rules expire after some time, which depends on the status of the
flow and the setting of some sysctl variables. See Section SYSCTL
VARIABLES for more details. For TCP sessions, dynamic rules can be
instructed to periodically send keepalive packets to refresh the state of
the rule when it is about to expire.
See Section EXAMPLES for more examples on how to use dynamic rules.
EXAMPLES
DYNAMIC RULES
In order to protect a site from flood attacks involving fake TCP packets,
it is safer to use dynamic rules:
ipfw add check-state
ipfw add deny tcp from any to any established
ipfw add allow tcp from my-net to any setup keep-state
This will let the firewall install dynamic rules only for those connec-
tion which start with a regular SYN packet coming from the inside of our
network. Dynamic rules are checked when encountering the first
check-state or keep-state rule. A check-state rule should usually be
placed near the beginning of the ruleset to minimize the amount of work
scanning the ruleset. Your mileage may vary.
To limit the number of connections a user can open you can use the fol-
lowing type of rules:
ipfw add allow tcp from my-net/24 to any setup limit src-addr 10
ipfw add allow tcp from any to me setup limit src-addr 4
The former (assuming it runs on a gateway) will allow each host on a /24
network to open at most 10 TCP connections. The latter can be placed on
a server to make sure that a single client does not use more than 4
simultaneous connections.
BEWARE: stateful rules can be subject to denial-of-service attacks by a
SYN-flood which opens a huge number of dynamic rules. The effects of
such attacks can be partially limited by acting on a set of sysctl(8)
variables which control the operation of the firewall.
Мой вольный перевод:
БРАНДМАУЭР С УЧЁТОМ СОСТОЯНИЯ СОЕДИНЕНИЯ Деятельностью учёта состояния соединени для брандмауэра является динамически создаваемые правила
для определенных потоков при обнаружении пакетов соответствующих данному образцу.
Поддержка фильтрации с учётом состояния соединения проходит через опции правил:
проверки состояния, учёта состояния и ограничения.
Динамические правила создаются, когда пакет соответствует правилу учёта состояния или ограничения,
это вызывает создание динамического правила, которое будет соответствовать всем пакетам только с данным
протоколом между парой адресов: IP-адресом источника/портом источника и IP-адресом назначения/портом назначения
(источник и назначение здесь используются для того, чтобы обозначить начальные соответствующие адреса,
далее они полностью совпадают). Динамические правила будут проверяться вначале проверкой состояния,
учётом состояния или событием ограничения и выполняемое действие на соответствующем правиле будет таким же,
как и в родительском.
Обратите внимание, что никакие другие дополнительные атрибуты кроме протокола,
IP-адреса и порта на динамических правилах не проверяются.
Типичное использование динамических правил сохраняет конфигурацию "закрытый брандмауэр",
но пусть первый TCP SYN пакет из внутренней сети установит динамическое правило для потока так,
что пакеты, принадлежащие этой сессии будут разрешены через брандмауэр:
ipfw add check-state
ipfw add allow tcp from my-subnet to any setup keep-state
ipfw add deny tcp from any to any
Аналогичный подход может быть использован для UDP, где UDP пакет, исходящий из внутренней сети,
установит динамическое правило, позволяющее прохождение ответа через брандмауэр:
ipfw add check-state
ipfw add allow udp from my-subnet to any keep-state
ipfw add deny udp from any to any
Динамические правила устаревают через некоторое время, которое зависит от состояния потока данных и
настройки некоторых sysctl переменных. Смотрите раздел переменные SYSCTL для более подробной информации.
Для TCP сессий, динамическим правилам может быть поручено периодически посылать пакеты проверки,
чтобы обновить состояние правила, когда срок его действия истекает.
Смотрите в разделе ПРИМЕРЫ дополнительные примеры того, как использовать динамические правила.
ПРИМЕРЫ
ДИНАМИЧЕСКИЕ ПРАВИЛА
В целях защиты сайта от атак, использующих поддельные пакеты TCP,
безопаснее использовать динамические правила:
ipfw add check-state
ipfw add deny tcp from any to any established
ipfw add allow tcp from my-net to any setup keep-state
Это позволит установить брандмауэру динамические правила только для тех соединений,
которые начинаются с правильного SYN пакета, исходящего из внутренней сети.
Динамические правила проверяются первым правилом проверки состояния или сохранения состояния.
Правило проверки состояния обычно должно помещаться в начале набора правил для минимизации
работы по просмотру набора правил.
Чтобы ограничить число соединений, которые пользователь может открыть,
можно использовать следующие типы правил:
ipfw add allow tcp from my-net/24 to any setup limit src-addr 10
ipfw add allow tcp from any to me setup limit src-addr 4
Первое (в предположении выполнения на шлюзе), позволит каждому
компьютеру в сети /24 открывать не более 10 TCP подключений.
Последнее, размещённое на сервере, гарантирует, что ни один из клиентов
не использует больше, чем 4 одновременных подключения.
ОСТЕРЕГАЙТЕСЬ: динамические правила могут привести к отказу в обслуживании атаками SYN-flood,
которые открывает огромное количество динамических правил. Последствия таких атак могут быть
частично ограничены действующим набором переменных sysctl(8), которые контролируют работу брандмауэра.
Будете продолжать бессмысленно упорствовать дальше?
Вариант для распечатки
