> вот тут да -- 5 тупле в пролете. и не на 5 тупле ориентироваться, мне кажется можно вообще не завязываться напрямую на IP. > я предлагаю фрэймворк. т.е. когда действительно то, что получится может никак не быть предусмотренно проектировщиком файрвола.
Это, конечно, интересно, но здесь громадная проблема - производительность. Когда там 5-tuple и FSM того же TCP сразу захаркожены на Си - производительность приличная. Как только мы вводим этот уровень абстракции - она сразу падает, возможно весьма значительно. Тут вон производительность pf и libalias даже на одном ядре сравнивали - заметно отличается, при том что оба на сях. Потому что куча всякого роляет типа кэшей процессора и др. (там RB-дерево vs хэш).
А ведь у людей есть потребность гонять в определенных условиях даже вообще без динамики - на 10 Гбит например. Про тот же иптаблес рапортовали, в нем отключение может резко поднять производительность (а ведь никаких абстракций). Тоже такие потребности учесть надо.
> нет, алгоритмическая -- плохое слово. алгоритм не оптимизируется, он относительно стандартный. паралельное -- тоже плохое слово, согласен.
Алгоритмическая значит - оптимизируется заменой алгоритма с тупого на умный.
> не понимаю, какая декомпиляция. и мне не видно чего бы тут "операции" были сущестенно мельче.
А ты в tcpdump -d хотя б погляди, на какой-нибудь аналог правила ipfw. Да, некоторые опкоды оттранслируются один в один. Но другие - разъедутся в десятки. Декомпиляция - возможность из опкодов собрать обратно исходник для операции листинга (ipfw show, iptables -L), так, чтобы исходник не хранить - мало ли его кто потёр или изменил или он там нечитаем (случаи разные бывают, по идее в файрвол должно быть можно вкурить по выводу листинга из ядра, на что Корчмарь и ругался, что у ipfw это сложнее).
> потому что выживает всегда самое кривое! вот хоть архитектуру PC взять. да кто их знает, не понравились мантэйнеру дистрибутива, не получили юзербазы и потеряли интерфейс. или слишком сложное сделали. или синтаксис правил фильтрации неудобный получился.
Было б оно совсем кривое, оно б не выжило. Да и у нас проблема выжить, и если это мало кто осилит - значит не годится. К тому же не забывай про правило 80/20 и что оно пока делается в одиночку, и даже мной отнюдь не всё время даже без работы (на халтурках подрабатывать приходится) - если сильно уж навернуть, можно ниасилить.
> я понял, но смысл именно в том, что не было исполнения виртуальной машиной. т.е. что бы делалось одно-несколько деревьев по которым делался бы анализ. да, потом, некторые операции будут выполняться, в этом смысле наверное виртуальная машина и bpf. но в этом смысле и ipfw сейчас -- bpf.
Кхе. А ты думаешь это реально? Я что-то не встречал алгоритмов перевода из псевдокода инструкций в дерево. Рассматривавшийся пример hipac - он по фиксированному набору чисел делает, никакого произвольного набора полей, а тем более строк или даже регэксопв для SIP, там и близко нет. Такая тема тянет на докторскую, пожалуй =) Сочинить такое своё я пожалуй точно ниасилю.
> backreferences пожалуй не нужен. вот что точно нужно -- эффективное определение какая альтернатива сработала (в pcre после срабатывания (GET|PUT|POST) надо еще отдельный анализ устраивать кто из трех сработал. ну и аналогично, если мы пять правил в одно через "или" объеденили -- как узнать какое сработало? в pcre неудобно.
> нет, по крайне мере не совсем. я предлагаю на псевдоязыке описывать только протокол. а правила фильтрации -- боле-менее обычным образом, но описание на псевдоязыке дают возможность в правилах фильтрации использовать параметры описанных протоколов.
> попробую. в воскресенье на поезде ехать -- как раз буду бумагу чирикать. это, вероятно, будет чем-то похоже на описание MIBов
Вот без примеров непонятно, что ты имеешь в виду. То есть, для конструктивного продолжения нужно на чем-то предметном обсуждать, а не в общем. Ну как, воскресенье прошло, начеркал?..
no subject
> я предлагаю фрэймворк. т.е. когда действительно то, что получится может никак не быть предусмотренно проектировщиком файрвола.
Это, конечно, интересно, но здесь громадная проблема - производительность. Когда там 5-tuple и FSM того же TCP сразу захаркожены на Си - производительность приличная. Как только мы вводим этот уровень абстракции - она сразу падает, возможно весьма значительно. Тут вон производительность pf и libalias даже на одном ядре сравнивали - заметно отличается, при том что оба на сях. Потому что куча всякого роляет типа кэшей процессора и др. (там RB-дерево vs хэш).
А ведь у людей есть потребность гонять в определенных условиях даже вообще без динамики - на 10 Гбит например. Про тот же иптаблес рапортовали, в нем отключение может резко поднять производительность (а ведь никаких абстракций). Тоже такие потребности учесть надо.
> нет, алгоритмическая -- плохое слово. алгоритм не оптимизируется, он относительно стандартный. паралельное -- тоже плохое слово, согласен.
Алгоритмическая значит - оптимизируется заменой алгоритма с тупого на умный.
> не понимаю, какая декомпиляция. и мне не видно чего бы тут "операции" были сущестенно мельче.
А ты в tcpdump -d хотя б погляди, на какой-нибудь аналог правила ipfw. Да, некоторые опкоды оттранслируются один в один. Но другие - разъедутся в десятки. Декомпиляция - возможность из опкодов собрать обратно исходник для операции листинга (ipfw show, iptables -L), так, чтобы исходник не хранить - мало ли его кто потёр или изменил или он там нечитаем (случаи разные бывают, по идее в файрвол должно быть можно вкурить по выводу листинга из ядра, на что Корчмарь и ругался, что у ipfw это сложнее).
> потому что выживает всегда самое кривое! вот хоть архитектуру PC взять. да кто их знает, не понравились мантэйнеру дистрибутива, не получили юзербазы и потеряли интерфейс. или слишком сложное сделали. или синтаксис правил фильтрации неудобный получился.
Было б оно совсем кривое, оно б не выжило. Да и у нас проблема выжить, и если это мало кто осилит - значит не годится. К тому же не забывай про правило 80/20 и что оно пока делается в одиночку, и даже мной отнюдь не всё время даже без работы (на халтурках подрабатывать приходится) - если сильно уж навернуть, можно ниасилить.
> я понял, но смысл именно в том, что не было исполнения виртуальной машиной. т.е. что бы делалось одно-несколько деревьев по которым делался бы анализ. да, потом, некторые операции будут выполняться, в этом смысле наверное виртуальная машина и bpf. но в этом смысле и ipfw сейчас -- bpf.
Кхе. А ты думаешь это реально? Я что-то не встречал алгоритмов перевода из псевдокода инструкций в дерево. Рассматривавшийся пример hipac - он по фиксированному набору чисел делает, никакого произвольного набора полей, а тем более строк или даже регэксопв для SIP, там и близко нет. Такая тема тянет на докторскую, пожалуй =) Сочинить такое своё я пожалуй точно ниасилю.
> backreferences пожалуй не нужен. вот что точно нужно -- эффективное определение какая альтернатива сработала (в pcre после срабатывания (GET|PUT|POST) надо еще отдельный анализ устраивать кто из трех сработал. ну и аналогично, если мы пять правил в одно через "или" объеденили -- как узнать какое сработало? в pcre неудобно.
> нет, по крайне мере не совсем. я предлагаю на псевдоязыке описывать только протокол. а правила фильтрации -- боле-менее обычным образом, но описание на псевдоязыке дают возможность в правилах фильтрации использовать параметры описанных протоколов.
> попробую. в воскресенье на поезде ехать -- как раз буду бумагу чирикать. это, вероятно, будет чем-то похоже на описание MIBов
Вот без примеров непонятно, что ты имеешь в виду. То есть, для конструктивного продолжения нужно на чем-то предметном обсуждать, а не в общем. Ну как, воскресенье прошло, начеркал?..