RootConf / прямая трансляция

[Лазовский Вадим]

в man ipfw

LOOKUP TABLES
  Lookup tables are useful to handle large sparse address sets, typically
  from a hundred to several thousands of entries.  There may be up to 128
  different lookup tables, numbered 0 to 127.

      ...

  Internally, each table is stored in a Radix tree, the same way as the
  routing table (see route(4)).

Это в том числе к вопросу о скорости фаервола.


Михаил Монашёв пишет:
> Здравствуйте, Алексей.
> 
> АБ> наверное  оффтоп,  но все же: если используется /ets/hosts.allow и
> АБ> если  необходимо  обеспечить  защиту  от  ДОС,  ДДОС,  что  сейчас
> АБ> локально  фаерволом делается на каждом сервере, например, лимитами
> АБ> на  кол-во  коннектов  с  одного  IP  (просто  и  тупо,  но как-то
> АБ> защищает),
> 
> Если  я  не ошибаюсь, то ботнетом количество динамических правил может
> достигнуть  максимума,  который  в  ipfw  вроде  65536. Ну и процессор
> скушает сильно.
> 
> Возможно  правильнее  в  таком  случае было бы на время атаки включать
> скрипт,  который  получал ты на вход лог от ipfw с ip, с которых много
> коннектов  (и прочие подозрительные ip, не понравившиеся Вам по другим
> правилам)  и  вносил  бы  их  в  таблицу. А всё, что идёт с ip из этой
> таблицы   резалось   бы   самым   первым  правилом.  Тогда  количество
> динамических правил возможно меньше раздувалось бы. А поиск по таблице
> в ipfw вроде быстро делается.
> 
> АБ> то   в   этот   функционал   необходимо   выносить   на  отдельную
> АБ> железку-фаервол с функциями инспектирования трафика?
> 
> 
>>>> Идея  метода в том, что роутинг кушает меньше процессора, чем фаервол.
>>>> При  роутинге  используется  то  ли хэш, то ли дерево, и поиск по нему
>>>> быстрый.   А  в  фаерволе  присходит  парсинг  всего  пакета  и  потом
>>>> последовательный   перебор   нескольких   правил,  что  затратнее  про
>>>> процессору.
>>> Там ещё и локи отличаются: для роутинга - shared lock, а для файрволла
>>> exclusive. То есть, дере
>