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

[Лазовский Вадим <lvm@xxxxxxxxx>]

в 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. То есть, дере