Работаем с приемром из DDK, IM driver PASSTHRU.
Как собирать, проходящий через него IP-пакет до кучи, в один буфер поместить пакет
таким, каким он должен быть, чтоб потом проанализировать все его содержимое?

Здравствуйте, Аноним, Вы писали:

А>Работаем с приемром из DDK, IM driver PASSTHRU.
А>Как собирать, проходящий через него IP-пакет до кучи, в один буфер поместить пакет
А>таким, каким он должен быть, чтоб потом проанализировать все его содержимое?

Для анализа полного пакета придётся для начала его дефрагментировать, т.к. он может быть фрагментирован.

RTFM: NdisQueryPacket, NdisQueryBufferSafe, NdisGetNextBuffer
Если что то непонятно, задавайте конкретный вопрос. Если что то не работает: приводите симптомы, код — будем разбираться

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

TC>RTFM: NdisQueryPacket, NdisQueryBufferSafe, NdisGetNextBuffer
TC>Если что то непонятно, задавайте конкретный вопрос. Если что то не работает: приводите симптомы, код — будем разбираться

С чтением даных при отсылке пакетов в сеть вроде получилось удачно внедрится в
PtSendComplete, однако в примерах нарытых в сети модифицируют всегда MPSendPacket.
Как будет правильней, "читать" пакеты в PtSendComplete или MPSendPacket?
Может при чтении не критично? Просто вслед за чтением вдруг сразу хочется еще и
модифицировать пакеты, тогда сразу и работают с MPSendPacket, с заделом на будущее так сказать.

А вот с "чтением" пакетов при получении их из сети возникили трудности.
Подглядывание DbgView-ром показывает, что отрабатывают функции
PtReceive
PtReceiveComplete
Насколько я понимаю то, что вызывается PtReceive или PtReceivePacket зависит от того
как напрограмили драйвер самой сетевой карты. И получается мне попалась сетевуха не очень
умная. Так вот, в PtReceive вызов NdisGetReceivedPacket почти всегда возвращает NULL.
И получается для получения пакета необходимо вызвать NdisTransferData.
Как правильно отработать с этой функцией, какие данные ей подсовывать
и как отработать в случае если NdisTransferData вернет "неудачу" или PENDING?
Требуется получить весь проходящий пакет.

Странно, что в passthru описана функция PtTransferDataComplete которая как бы в связке с
NdisTransferData и работает. Однако нет ничего подобного PtTransferData и вообще вызова
NdisTransferData в секции protocol.c и получается что PtTransferDataComplete
никто никогда не вызовет? Зачем тогда лишнии строки?

А>Странно, что в passthru описана функция PtTransferDataComplete которая как бы в связке с
А>NdisTransferData и работает. Однако нет ничего подобного PtTransferData и вообще вызова
А>NdisTransferData в секции protocol.c и получается что PtTransferDataComplete
А>никто никогда не вызовет? Зачем тогда лишнии строки?

Вы внимательно на код посмотрите? Функция NdisTransferData вызывается из MPTransferData. Это же тупой драйвер, он просто пропускает мимо себя все. И использовать его в качестве полноценного фильтра довольно сложно. В данном случае логика такая:

1. Нижележащий минипорт сообщает о наличии данных — NdisMEthIndicateReceive
2. Вызывается функция PtReceive. Из нее нотификация идет наверех — NdisMEthIndicateReceive
3. Вышележащий протокол вызывает NdisTransferData
4. Вызывается функция MPTransferData

Таким образом, passthrou нельзя малой кровью превратить даже в мониторящий фильтр. Если Вам нужно просматривать содержимое пакетов полностью, Вам лучше полностью переписать логику приема пакетов.

TC>Вы внимательно на код посмотрите? Функция NdisTransferData вызывается из MPTransferData.
Видел я это, но я рассмтриваю в данном случае protocol.c Ну да лано, раз не уточнил...
Прикол в том что MPTransferData тоже не вызывается. Потому так уверено и написал.

TC>Таким образом, passthrou нельзя малой кровью превратить даже в мониторящий фильтр. Если Вам нужно просматривать содержимое пакетов полностью, Вам лучше полностью переписать логику приема пакетов.

От этих слов опять начинается философия в голове, по вопросу, может перейти всетаки
на НДИС-ХУКИНГ, Комерческие продукты используют это, авторитеты тоже хвалят, как
метод позволяющей более крутую в безопасности вещь писать, да и производительность
лучше якобы чем у IMD.

Попробовал получить пакет так

этот вызов сидит в passthru.c
NdisAllocateBufferPool(&Status, &buffer_pool, 100);

ниже следующее сидит в protocol.c

PktLen2=HeaderBufferSize + PacketSize;
NdisAllocateMemoryWithTag(pVA2,PktLen2,'TAG3');

NdisAllocateBuffer(&Status,&buffer2,buffer_pool,pVA2,PktLen2);

NdisAllocatePacket(&Status,&pPacket2,pAdapt->RecvPacketPoolHandle);

NdisChainBufferAtFront(pPacket2,buffer2);

NdisTransferData(&Status,pAdapt->BindingHandle,MacReceiveContext,0,PacketSize,pPacket2,&BytesTransfered);

Получаем BSOD IRQL_NOT_LESS_OR_EQUAL
D1(0,2,1,xxxxxxx);

Хееелп!!!

ф. ProtocolTransferDataComplete вызвалась?

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

TC>ф. ProtocolTransferDataComplete вызвалась?

Нет.

А>Получаем BSOD IRQL_NOT_LESS_OR_EQUAL
А>D1(0,2,1,xxxxxxx);

Это обращение по 0 адресу. Скорее всего, неверно создан пакет. Из вашего кода не ясно, проверяете ли Вы создание буферов, выделения памяти и.т.п.

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


А>>Получаем BSOD IRQL_NOT_LESS_OR_EQUAL
А>>D1(0,2,1,xxxxxxx);

TC>Это обращение по 0 адресу. Скорее всего, неверно создан пакет. Из вашего кода не ясно, проверяете ли Вы создание буферов, выделения памяти и.т.п.

Заработало!
было
NdisAllocateMemoryWithTag(pVA2,PktLen2,'TAG3');
а надо
NdisAllocateMemoryWithTag(&pVA2,PktLen2,'TAG3');
так.. мелкая пакость

Теперь получилась вот такая PtReceive

NDIS_STATUS
PtReceive(
    IN  NDIS_HANDLE         ProtocolBindingContext,
    IN  NDIS_HANDLE         MacReceiveContext,
    IN  PVOID               HeaderBuffer,
    IN  UINT                HeaderBufferSize,
    IN  PVOID               LookAheadBuffer,
    IN  UINT                LookAheadBufferSize,
    IN  UINT                PacketSize
    )

{
    PADAPT            pAdapt = (PADAPT)ProtocolBindingContext;
    PNDIS_PACKET      MyPacket, Packet = NULL;
    NDIS_STATUS       Status = NDIS_STATUS_SUCCESS;

    NDIS_STATUS       Status2 = NDIS_STATUS_SUCCESS;
    PNDIS_PACKET      pPacket2;
    PVOID             pVA2=NULL;

    PNDIS_BUFFER buffer;
    PNDIS_BUFFER buffer2=NULL;
    UINT         bufcnt;
    UINT         TotalPktLen;
    UINT         PktLen2;
    UINT         BytesTransfered;

if ((!pAdapt->MiniportHandle) || (pAdapt->MPDeviceState > NdisDeviceStateD0))
{
   Status = NDIS_STATUS_FAILURE;
}
else do
{
 
Packet = NdisGetReceivedPacket(pAdapt->BindingHandle, MacReceiveContext);

if (Packet != NULL)
{
//код в этом месте пока не рассматриваем, интересует как раз таки случай Packet == NULL)
}

else

{
//-----------------------------------------my code NdisTransferData--------------------------------------------------
// The miniport below us uses the old-style (not packet)
// receive indication. Fall through.
//

if (PacketSize == LookAheadBufferSize)
{
//пока не рассматриваем
}
else
{

PktLen2=HeaderBufferSize + PacketSize;

Status2=NdisAllocateMemoryWithTag(&pVA2,PktLen2,'TAG3');

if (Status2==NDIS_STATUS_SUCCESS)//1
{

    NdisAllocateBuffer(&Status,&buffer2,buffer_pool,pVA2,PktLen2);

    if (Status==NDIS_STATUS_SUCCESS)//2
    {
        NdisAllocatePacket(&Status,&pPacket2,pAdapt->RecvPacketPoolHandle);

        if (Status==NDIS_STATUS_SUCCESS)//3
         {

        NdisChainBufferAtFront(pPacket2,buffer2);

        NdisTransferData(&Status,pAdapt->BindingHandle,MacReceiveContext,0,PacketSize,pPacket2,&BytesTransfered);

        if (Status == NDIS_STATUS_SUCCESS)
        {

            NdisQueryPacket(pPacket2,NULL,&bufcnt,NULL,&TotalPktLen);
            KdPrint(("PtReceive bufcnt %d\n",bufcnt));
            KdPrint(("PtReceive TotalPktLen %d\n",TotalPktLen));
        }
        
        NdisFreeBuffer(buffer2);
        NdisFreePacket(pPacket2);


}//if (Status==NDIS_STATUS_SUCCESS)//3
else
{
NdisFreeBuffer(buffer2);
}

}//if (Status==NDIS_STATUS_SUCCESS)//2


    NdisFreeMemory(pVA2,PktLen2,0);


}//if (Status==NDIS_STATUS_SUCCESS)//1
if (Status == NDIS_STATUS_PENDING)
{
Status = NDIS_STATUS_SUCCESS;
}

}

//-----------------------------------------end of my code NdisTransferData----------------------------------------------
}

        if (Packet != NULL)
        {
            PtFlushReceiveQueue(pAdapt);
        }
        if ((pAdapt->MiniportHandle == NULL)
                || (pAdapt->MPDeviceState > NdisDeviceStateD0))
        {
            break;
        }
        
        pAdapt->IndicateRcvComplete = TRUE;
        switch (pAdapt->Medium)
        {
            case NdisMedium802_3:
            case NdisMediumWan:
                NdisMEthIndicateReceive(pAdapt->MiniportHandle,
                                             MacReceiveContext,
                                             HeaderBuffer,
                                             HeaderBufferSize,
                                             LookAheadBuffer,
                                             LookAheadBufferSize,
                                             PacketSize);
                break;

            case NdisMedium802_5:
                NdisMTrIndicateReceive(pAdapt->MiniportHandle,
                                            MacReceiveContext,
                                            HeaderBuffer,
                                            HeaderBufferSize,
                                            LookAheadBuffer,
                                            LookAheadBufferSize,
                                            PacketSize);
                break;

            case NdisMediumFddi:
                NdisMFddiIndicateReceive(pAdapt->MiniportHandle,
                                              MacReceiveContext,
                                              HeaderBuffer,
                                              HeaderBufferSize,
                                              LookAheadBuffer,
                                              LookAheadBufferSize,
                                              PacketSize);
                break;

            default:
                ASSERT(FALSE);
                break;
        }

    } while(FALSE);

    return Status;
}

На участке:
NdisTransferData(&Status,pAdapt->BindingHandle,MacReceiveContext,0,PacketSize,pPacket2,&BytesTransfered);

if (Status == NDIS_STATUS_SUCCESS)
{

NdisQueryPacket(pPacket2,NULL,&bufcnt,NULL,&TotalPktLen);
KdPrint(("PtReceive bufcnt %d\n",bufcnt));
KdPrint(("PtReceive TotalPktLen %d\n",TotalPktLen));
}
вызывать ли ProtocolTransferDataComplete? и когда, при Status == NDIS_STATUS_SUCCESS или Status == NDIS_STATUS_PENDING?
А что делать при NDIS_STATUS_FAILURE?

Интересно отметить теперь при отрабатывании NdisTransferData стала отрабатывать MPTransferData.

А>Теперь получилась вот такая PtReceive
А>Packet = NdisGetReceivedPacket(pAdapt->BindingHandle, MacReceiveContext);

Функция NdisGetReceivedPacket() является устаревшей для Windows Vista.

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

А>>Теперь получилась вот такая PtReceive
А>>Packet = NdisGetReceivedPacket(pAdapt->BindingHandle, MacReceiveContext);

U>Функция NdisGetReceivedPacket() является устаревшей для Windows Vista.

Все пишу под Win2003server. А эту Висту пока суем как можно дальше.
Устарела NdisGetReceivedPacket? Возмем современную!

А как думает сообщество драйверистов ,
как можно реализовать IDS-ы (SNORT, ISA-server, и т. д.)
если объем сигнатур вырастит в сотни, гиги, и т. д. байтов?
Как так быстро осуществить поиск на соответствие инфы из пойманых пакетов
в большом количестве сигнатур, чтобы машина не висла? Будем внедрять технологии Гугла?
А когда они не станут справляться?

А>как можно реализовать IDS-ы (SNORT, ISA-server, и т. д.)
А>если объем сигнатур вырастит в сотни, гиги, и т. д. байтов?

Я думаю, системы IDS основаные на сигнатурном анализе пакетов несколько устарели. IMHO всякие пакетные фильтры должны заниматься своим делом — фильтровать пакеты. При этом они могут обнаруживать некоторые "криминальные" ситуации — сканирование портов, махинации с МАС и ip адресами, аномально фрагментированный трафик, флуд и.т.п. Все эти атаки не нуждаются в сигнатурном анализе, тут нужна эвристика. Сигнатурный поиск интересен для защиты уязвимых служб ( типа RPC ), но вроде как не видно тенденции к увеличению количества эксплоитов и врядли объем баз достигнет больших объемов. Кроме того, тут можно точно сказать, когда сигнатура больше не нужна — как только на машине появится обновленая версия уязвимого модуля. Кроме того, если говорить про Windows, подобные вещи было бы удобно реализовать не на уровне пакетного фильтра, а на уровне транспортного драйвера, после сборки ТСР потоков и сортировки UDP датаграмм. В этом месте требования к производительности уже не такие большие ( т.е мы можем втормозить какое то соединение, при том что остальные нормально работают ). Защищать пользовательские приложения ( в первую очередь веб броузеры ) с помощью сигнатурного анализа трафика IMHO не разумно. Невозможно поддерживать актуальную и хоть сколько то надежную базу.

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


А>>как можно реализовать IDS-ы (SNORT, ISA-server, и т. д.)
А>>если объем сигнатур вырастит в сотни, гиги, и т. д. байтов?

TC>Я думаю, системы IDS основаные на сигнатурном анализе пакетов несколько устарели. ...

Написал таки простейший IDS . С возможность дропить пакеты если сигнатура в них попалась.
Так вот... При количесве сигнатур =3 проц загружается на 90%
производительность сети под 90%, ну а 100 сигнатур, висит так хорошо все , загрузка проца 100%,
производительность сети 10% (судя по таскменеджеру).
Вопрос, как можно быстро искать сигнатуру в пакете (причем на IRQL=2)? Мож кто подскажет что нить из быстрых
алгоритмов поиска или какие хитрые возможности работы с процессором там, с его кешем первого уровня , и тд и тп...?
На данный момен происходит следущее (за основу взят passthru из DDK, WIN2003ES_ EN, SP2):

В функция PtReceive, PtReceivePacket и PtSendComplete
(PtReceive можно не рассматривать, на данный момент стоит сетевая карта, пакеты из которой попадают в PtReceivePacket)
из Packet собирается PUCHAR массив AhB примерно так:
...
PNDIS_PACKET Packet
PUCHAR AhB
...

NdisQueryPacket(Packet,NULL,&bufcnt,&buffer,&TotalPktLen);
NdisQueryBufferSafe(buffer,&pVA,&LenVA,Priority);
NdisMoveMemory(AhB,(PUCHAR)pVA+SIZE_ETHER_HEADER,LenVA-SIZE_ETHER_HEADER);
NdisGetNextBuffer(buffer,&buffer);
...

затем в AhB ищатся в цикле сигнатуры по следующему алгоритму:
сравнивается каждый символ из AhB с первым символом i-ой сигнатуры, (которая есть переменая типа PUCHAR signature).
если символы совпадают, тогда сравниваем следующий символ из AhB после совпавшего,
со вторым символом из текущей сигнатуры и т. д. если до конца сигнатуры символы оказались неравны, прерываем
поиск, если все символы совпали, кричим match=ок.

Если поиск отключаем, то все работает на ура как-будто passthru отсутствует
включаем поиск сигнатур, машина подвисает, о мегабайтах сигнатур вопрос можно и не ставить, тут бы с 10 кб заработало.

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

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

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

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

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

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

Здравствуйте, 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 ?

Вспомнил про эту тему http://www.rsdn.ru/forum/message/1850969.flat.aspx#1850969

Автор:
Дата: 17.04.06

Наконецто нашлось время и я ее нашел и пароль восстановил

<--
От: Maxim S. Shatskih mvp
Дата: 24.04.06 17:23
Оценка: 2 (1)

Один толковый специалист (нашего с вами уровня) пишет файрволльный фильтр на основе PASSTHRU с набором правил,
взятым из BSDшной ipfw, и _со stateful inspection_ — это вот то самое, фильтр реально обрывал коннект при скачивании с
сайта страницы, в которой было одно из запретных слов — вот такая задача,...
-->

Архитектурно практически моя задачка . Хотелось бы узнать результаты работы такого фильтра
с большим количеством запретных слов (100-1000) в 100Мбит сети , загрузка проца и сети (без матчинга)/(с матчингом).
Не будет ли любезен Максим включится в диалог подсказать пару моментов, особенно про матчер или
подсказка уже есть ...kwset.c в GNU grep... Дайте еще , только не говорите про 6000 бакариков пожалуйста
(<--
Re[5]: Написание NDIS-клиента Оценить
От: Andrew.W Worobow http://worobow.spaces.live.com
Дата: 06.02.07 18:25
Оценка: 7 (2) -2

...и того — цена твоего вопроса $6000...
-->)
Вот зато сейчас не въеду в такую вещь, поймали мы пакет допустим в PtReceivePacket,
прошел он через маленький такой TCP/IP-стек , попал в матчер, матчер сказал "все гуд", дальше что с NDIS_PACKET-ом?
А если и это наверное делается, надо получить данные из нескольких пакетов, собрать все до кучи,
только теперь в матчер, он говорит "гуд", как данные загнать в виндовый TCP/IP-стек чтобы броузер получил свои данные?
Ведь насколько я понимаю PtReceivePacket говорит NDIS-у не пускать NDIS_PACKET-ы дальше, пока матчер не скажет "гуд".

А>Получается ведь в 1500 байтном пакете (берем по максимому) ищем N=100 раз различные сигнатуры.
А>Тест проводился очень просто, копируется файл avi размером в 2 ГГб. А сигнатуры типа
А>crack.exe
А>kill.exe
А>cmd.exe
А>и т. п.

раз тормоза проявляются при большом кол-ве сигнатур, то нужно обратить внимание на не эффективный алгоритм анализа. Тут два основных момента:
1. допустим мы ищем сигнатуру по смещению N. Проанализировав 1 символ, пусть это будет 'd', можно сразу отложить анализ всех сигнатур, которые начинаются не с 'd' — это может на порядок увеличить скорость работы
2. при поиске длинных сигнатур можно использовать более эффективные методики сравнения. Хотя бы сравнивать одновременно с начала и с хвоста. Так для сигнатуры crack.exe — нет смысла перебирать всю строку, если в конце стоит не 'e'. Насколько мне известно, есть еще более эффективные методики сравнения.

Итого — представление сигнатур в виде списка не эффективно, нужно этот список превратить в какой нибудь индексированный массив. Для дальнейшего увеличение производительности нужно сделать какую нибудь машину состояний — т.е искать не по одной сигнатуре, а сразу по всем ( или по группам ). Тут можно посмотреть в сторону машин разбора регулярных выражений. Короче, с NDIS фильтром все нормально — Вам дальше в "алгоритмы".