Comments 6
Писал флуд-детектор на NDIS 5.1 и 6.0. Получилась дипломная работа.
Интересно, а можно подробнее? что он из себя представлял и что именно делал?
Думаю вы знакомы с примером Passthru Intermediate Driver из DDK.
Есть функция PtReceivePacket, которая обрабатывает входящие NDIS-пакеты. Идея заключалась в защите от syn-flood'а. Через клиентское приложение устанавливались параметры — максимально допустимое кол-во SYN реквестов с одного IP и если этот порог был превышен, то все пакеты с этого IP дропались. Защита разумеется не от реальных атак. Но это было небольшой частью моего стажировочного задания при приеме на работу, поэтому я и использовал его как дипломную работу.
Есть функция PtReceivePacket, которая обрабатывает входящие NDIS-пакеты. Идея заключалась в защите от syn-flood'а. Через клиентское приложение устанавливались параметры — максимально допустимое кол-во SYN реквестов с одного IP и если этот порог был превышен, то все пакеты с этого IP дропались. Защита разумеется не от реальных атак. Но это было небольшой частью моего стажировочного задания при приеме на работу, поэтому я и использовал его как дипломную работу.
После прочтения статьи пришёл к выводу, что tap-win32 построен как промежуточный. Правильная догадка или я заблуждаюсь?
Интересно было бы почитать про tspip.sys. Например, меня интересует механизм, как ОС выделяет порт для исходящего соединения и как контролирует уже выделеные порты.
Sign up to leave a comment.
Краткий обзор драйверов спецификации NDIS