Здравствуйте, TarasCo, Вы писали:

А>>А может переделаная strstr под работу в драйвере быстрее заработает?

TC>Зачем переделывать? Базовые С функции и так реализованы в ядре и более менее быстро.

мойА>>Во первых, не рекомендуется использовать в IM-NDIS драйвере Микрософтом можно конечно и проигнорироать как всегда .
Но почемуто не работает иногда надо разбираться...

А>>Или вобще идея фильтрации по сигнатурам по другому реализуется?

TC>Честно говоря, не очень понятно откуда взялись ТАКИЕ тормоза? На 100МБ сети при полной загрузке пакеты приходят
примерно 1 на 100мкс. Без фильтрации это нагрузка на нормальный процессор врядли превысит 10%
( если трафик не злонамеренный — хитрая фрагментация может хорошо повысить нагрузку ).
Таким образом, можно считать, что у Вас на обработку пакета есть не менее 10 мкс ( при этом не будет существенной нагрузки
на процессор ) — IMHO, этого должно хватить на поиск сигнатуры в буфере длиной около 1КБ любым способом .
Может, у Вас просто отладочная версия драйвера? Попробуйте собрать его с оптимизацией по скорости, я думаю тормоза
значительно уменьшаться. Также, стоит убрать копирование памяти — это съэкономит инструкций 200 .

мойА>>
Версия драйвера действительно отладочная.
А как собрать его с оптимизацией по скорости?
Без NdisMoveMemory(AhB,(PUCHAR)pVA+SIZE_ETHER_HEADER,LenVA-SIZE_ETHER_HEADER);
данные из пакета не собрать в один буфер, наверное . Да и тормозов здесь нет.
Поиск одной сигнатуры то идет быстро, а вот когда их N=100, имеем жуткий тормоз.
Получается ведь в 1500 байтном пакете (берем по максимому) ищем N=100 раз различные сигнатуры.
Тест проводился очень просто, копируется файл avi размером в 2 ГГб. А сигнатуры типа
crack.exe
kill.exe
cmd.exe
и т. п.

Что то мне сдается про идею фильтрации по сигнатурам в IM-драйвере на DISPATCH_LEVEL можно забыть...
Нужен шибко быстрый проц, чтобы буфер в 1500 байт просканировать 1000-10000 раз (прикидочное количество
сигнатур на текущую дату с замахом на недалекое будущее . А может линейный поиск на АСМ-е справится?



TC>IMHO сигнатурный анализ сетевого пакета не сводится к поиску определенной последовательности в нем, на практике
все может быть гораздо быстрее ( например, поиск сигнатуры по конкретному смещению ).

мойА>>По этому вопросу можно конечно долго беседовать как лучше сканировать. Если посмотреть как делают ребята
в SNORT-е, то там и целые строчки ищутся, и по смещению, и повторяющиеся смещения, варианты поиска там поразвитей .
Но только анализ выполняется не в драйвере, а в полученом из драйвера буфере в приложении. Что есть не так накладно
для компа, но и естественно нет фильтрации в реальном режиме. Поздновато как-то блокировать трафик от атакуемого
хоста, если вредные пакеты уже прошли.

А так хочется сделать в IM-драйвере и перехват идет на очень низком уровне, и не так страшно какой протокол там на верху данные получает.


Если рассмотреть вашу идею
...
Кроме того, если говорить про Windows, подобные вещи было бы удобно реализовать не на уровне пакетного фильтра,
а на уровне транспортного драйвера, после сборки ТСР потоков и сортировки UDP датаграмм.
...

Может и подскажите схематически как это сделать, неужели вешать TDI-фильтр на TCP/IP ?