Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: NDIS Firewall  (Прочитано 22269 раз)
0 Пользователей и 6 Гостей смотрят эту тему.
tayphoon
Интересующийся

ru
Offline Offline

« : 02-02-2010 16:23 » 

Доброго времени суток! Знаю, что на данном форуме куча информации про NDIS драйвер и, в частности, про Passthru. Но вот есть такой вопрос. Я пишу дипломный проект Файрвол. Не хочется сдавать чужой проект, поэтому взялся за дело сам. Перелопатил ваши статьи да так и не нашел, как драйвер может сообщить о пришедшем пакете и передать его в программу, использующую этот драйвер.
Использовал пример Passthru driver вот с этого сайта: h**p://www.wd-3.com/downloads/PassThru3.zip
Отличный сайт, куча примеров, ну а теперь по порядку. Хочу написать кроссплатформенный файрвол. Низкоуровневую часть под Windows собираюсь реализовывать с помощью NDIS driver. Возможно ли в NDIS драйвере реализовать с помощью механизма событий или callback'ов передачу пакета в программу? Необходимо, чтобы при приходе любого пакета программа узнавала об этом и получала его.

Заранее спасибо)
« Последнее редактирование: 02-02-2010 17:39 от Sel » Записан
Ochkarik
Модератор

ru
Offline Offline
Пол: Мужской

« Ответ #1 : 02-02-2010 17:59 » 

доброго.
по идее NdisInitializeEvent инициализирует Event объявленный как
typedef struct _NDIS_EVENT
{
    KEVENT      Event;
} NDIS_EVENT, *PNDIS_EVENT;

то есть это обычное событие ядра. вроде были методы отобразить его в процесс.. по крайней мере обратно - точно можно при помощи ObReferenceObjectByHandle(). с другой стороны ObReferenceObjectByHandle - это не NDIS функция. для кросплатформенности наверное не стоит ее использовать. да и евенты толго идут...

а насчет callback-ов не знаю...
Записан

RTFM уже хоть раз наконец!  RTFM :[ ну или хотя бы STFW...
tayphoon
Интересующийся

ru
Offline Offline

« Ответ #2 : 05-02-2010 18:39 » 

А есть какой-нибуДь другой способ?
« Последнее редактирование: 05-02-2010 19:27 от Sel » Записан
Ochkarik
Модератор

ru
Offline Offline
Пол: Мужской

« Ответ #3 : 05-02-2010 21:43 » 

штатного увы не соображу. к сожалению я не очень силен в NDIS - а там несколько отдельный набор функций... кросплатформенный.
по идее - альтернатив всего несколько. APC процедуры(Asynchronous Procedure Calls)- не уверен что кроссплатформенно поддержаны в NDIS (но надо проверить - попробуйте поискать аналоги), и, вроде как есть вот такой метод (если я правильно мельком понял):
например http://www.pcausa.com/filters/IPPacketRedirector.pdf
вроде бы это как раз похожая тематика. попробуйте разобраться?) мне показалось что что то разумное в этом подходе есть.


а главное - вы уверены что вам нужны калбэки? это значительно все усложняет, а вопрос зачем - я пока не понял. ведь NDIS сам по себе должен быть кросплатформенный? можно реализовывать все в нем? какой смысл тащить на верхний уровень каждый пакет а потом запихивать обратно? это в любом случае накладные расходы на синхронизацию.
Записан

RTFM уже хоть раз наконец!  RTFM :[ ну или хотя бы STFW...
tayphoon
Интересующийся

ru
Offline Offline

« Ответ #4 : 06-02-2010 14:59 » 

Смысл в том что анализ должен проводится на верхнем уровне, чтобы проанализировать содержимое пакета, на наличие инструкций вредоносных и вирусов


Так что NDIS driver можно и в линукс использовать? А есть литература или пример?
« Последнее редактирование: 10-05-2010 07:42 от RXL » Записан
Ochkarik
Модератор

ru
Offline Offline
Пол: Мужской

« Ответ #5 : 06-02-2010 18:05 » 

http://www.google.ru/search?hl=ru&lr=&rlz=1T4ADBF_ruRU321RU322&newwindow=1&q=porting+NDIS+linux&start=10&sa=N
http://en.wikipedia.org/wiki/NDISwrapper

Записан

RTFM уже хоть раз наконец!  RTFM :[ ну или хотя бы STFW...
resource
Молодой специалист

ru
Offline Offline
Пол: Мужской

« Ответ #6 : 07-02-2010 07:27 » 

То что в твоем понятии кроссплатформенный это значит писать отдельный фаерволл под каждую операционку.

Я тоже недавно решил заморочиться с NDIS файером. Понял следующие вещи.
1. Анализировать на верхнем уровне (я так понял на уровне пользователя) это мягко говоря не лучшая идея. Сеть будет как миниму страшно тупить. В тех же исходниках от pcausa, "фаерволирование" происходит на месте, в самом драйвере.
2. На NDIS неясно какая именно программа шлет пакет, а без этого ни один нормальный фаервол не мыслим. Может ведь и легальный браузер коннектиться на 80 порт по http а может и злодей какой нибудь. Какой смысл в фаерволе если он будет пропускать всё что угодно от кого угодно. Но этот пункт для тебя может быть и не критичным, т.к. твои цели - учебно-тренеровочные.
3. Это самый главный вопрос который встает. Я, например, признаю только один режим "запрещено всё что не разрешено", иначе опять же смысла нет. Так вот как при такой политике фильтровать тот же tcp (с учетом пункта 2)? К примеру, разрешен tcp траффик с твоего компа на определенный удаленный порт. В фаере вижу пакет который желает уйти в большое плавание. Проверяю, вижу что пакет tcp и что он уходит на разрешенный порт - пропускаю. Приходит ответ. И что с ним делать? Откуда я знаю ответ это тому кто спрашивал или вообще "левый" пакет. Да, я могу запомнить порт с которого уходит пакет и смотреть на порт входящего пакета. Но что если та "нормальная" прога вообще уже закрылась, и теперь этот порт заняло что-то зловредное.

в общем я не нашел для себя ответов на эти вопросы. Более того, что касается пункта 2, то мне кажется это вообще невозможно. Майкрософт пишет мол не делайте ничего на tdi, т.к. он якобы уже не поддерживается. Ну по крайней мере и на висте и на 7ке он жив и здоров. Если кому то удалось сделать нормальный файер исключительно на ndis, поделитесь, мне самому очень это интересно
Записан
Ochkarik
Модератор

ru
Offline Offline
Пол: Мужской

« Ответ #7 : 07-02-2010 09:01 » 

resource, у вас есть исходники psausa, и там действительно все реализовано в драйвере?
Удивительно, но мельком проглядывая  инфу на их сайте я так понял, что они то, как раз умудряются пересылать в приложение? или это они брешут?)
да и в соседней ветке это активно утверждали...

Кстати, а чего вдруг все на этот pcausa набросились? или потому что других нет?)

PS кстати я тоже приверженец того, что все надо делать в драйвере, если встает вопрос пакетной обработки и быстродействия.
« Последнее редактирование: 07-02-2010 09:17 от Ochkarik » Записан

RTFM уже хоть раз наконец!  RTFM :[ ну или хотя бы STFW...
resource
Молодой специалист

ru
Offline Offline
Пол: Мужской

« Ответ #8 : 07-02-2010 10:05 » 

Я лично заходил на ndis.com (думаю не я один)) ), а от туда как правило все и попадают на pcausa. Может я и "наврал" немного насчет того что исходники с pcausa, но то что их писали люди с pcausa это чистая правда, равно как и насчет того, что фильтрация происходит в драйвере.  Это возможно не те исходники, что вы ожидали, но тоже интересно посмотреть.
http://www.wd-3.com/archive/ExtendingPassthru2.htm
Записан
Ochkarik
Модератор

ru
Offline Offline
Пол: Мужской

« Ответ #9 : 07-02-2010 12:37 » 

нет счастья на земле...
но тем не менее на сайте несколько другая конфигурация прописана.
есть еще вот такие вещи
1. WinPkFilter
http://www.ntkernel.com/w&p.php?id=7
и тут кажется фильтр встроенныый, правила загружаемые...
2. MicroOLAP's PSSDK
http://www.microolap.com/products/network/pssdk/
правда последнее - всего лишь снифер, а это гораздо проще...
« Последнее редактирование: 07-02-2010 12:42 от Ochkarik » Записан

RTFM уже хоть раз наконец!  RTFM :[ ну или хотя бы STFW...
tayphoon
Интересующийся

ru
Offline Offline

« Ответ #10 : 08-02-2010 19:45 » 

Насчет того что фильтрует сам драйвер, ты прав. а для того чтобы написать нормальный файрвол, нужно много уровней ухватить, ну думаю если без анализа одержимого пакетов то достаточно tdi + ndis. потому что на ndis фиг узнаешь кто пакет просит. Еще вычитал что самый быстродейственный способ это переопределение NDIS API функций, типа и драйвер писать не надо и все те же возможности. Но вот если реализовывать файрвол не просто как пакетный фильтр, как в примерах на выше указанном сайте, то нужно инфу с разных уровней собрать а потом решить что делать с пакетом. Сделать это на уровне драйвером можно но хотелось комплексно решить проблему на уровне приложения. Понимаю что может тормозить адцки) но если подойти к проблеме не напрямую получил пакет и пока решишь что с ним делать а другим способом, например помечать пакеты или буферизировать, в общем я пока фантазирую...


Вот по этому и хочу синхронизировать NDIS driver и прогу, чтоб знать когда пришли пакеты, а дальше уже можно решить как быть


То что в твоем понятии кроссплатформенный это значит писать отдельный фаерволл под каждую операционку.

Я тоже недавно решил заморочиться с NDIS файером. Понял следующие вещи.
1. Анализировать на верхнем уровне (я так понял на уровне пользователя) это мягко говоря не лучшая идея. Сеть будет как миниму страшно тупить. В тех же исходниках от pcausa, "фаерволирование" происходит на месте, в самом драйвере.
2. На NDIS неясно какая именно программа шлет пакет, а без этого ни один нормальный фаервол не мыслим. Может ведь и легальный браузер коннектиться на 80 порт по http а может и злодей какой нибудь. Какой смысл в фаерволе если он будет пропускать всё что угодно от кого угодно. Но этот пункт для тебя может быть и не критичным, т.к. твои цели - учебно-тренеровочные.
3. Это самый главный вопрос который встает. Я, например, признаю только один режим "запрещено всё что не разрешено", иначе опять же смысла нет. Так вот как при такой политике фильтровать тот же tcp (с учетом пункта 2)? К примеру, разрешен tcp траффик с твоего компа на определенный удаленный порт. В фаере вижу пакет который желает уйти в большое плавание. Проверяю, вижу что пакет tcp и что он уходит на разрешенный порт - пропускаю. Приходит ответ. И что с ним делать? Откуда я знаю ответ это тому кто спрашивал или вообще "левый" пакет. Да, я могу запомнить порт с которого уходит пакет и смотреть на порт входящего пакета. Но что если та "нормальная" прога вообще уже закрылась, и теперь этот порт заняло что-то зловредное.

в общем я не нашел для себя ответов на эти вопросы. Более того, что касается пункта 2, то мне кажется это вообще невозможно. Майкрософт пишет мол не делайте ничего на tdi, т.к. он якобы уже не поддерживается. Ну по крайней мере и на висте и на 7ке он жив и здоров. Если кому то удалось сделать нормальный файер исключительно на ndis, поделитесь, мне самому очень это интересно

Комплексный подход! Нужно анализировать на всех уровнях, можешь к примеру пометить пакет, как например делают некоторые пакетный фильтр. Ну это наверное как реализация на уровне драйверов, первый пометил что пор валиден и айпи. А вышестоящий драйвер смотрит что уже делать.

То что в твоем понятии кроссплатформенный это значит писать отдельный фаерволл под каждую операционку.

А кроссплатформенный в моем понимании - программа реализующая анализ содержимого пакетов, интерфейс, в общем все кроме модулей уровня ядра(промежуточные драйвера, модули).
« Последнее редактирование: 10-05-2010 07:41 от RXL » Записан
Ochkarik
Модератор

ru
Offline Offline
Пол: Мужской

« Ответ #11 : 08-02-2010 21:29 » 

вся беда передачи пакетов в ring-3 - время реакции... то есть, не так сложно отправить большой поток, сложно получить быстродействие когда на каждый пакет требуется какая то реакция от приложения.
если можно попытаться свести задачу к потоковой а не пакетной передаче - значительно облегчило бы выполнение)

второе. обычно под кросплатформенностью все таки  портабельность кода с точки зрения использованных функций  на различные ОС...

далее. возвращаясь к тому pcausa, с которого все началось.  на сайте описывают систему из двух виртуальных адаптеров: вопрос - зачем?


во вторых есть пара слов следующего содержания
Цитата
Lower Adapter Interface
A handle opened on the Lower Adapter Interface is easiest to understand.
A write on a lower adapter Win32 handle will call a lower-level miniport driver to transmit a packet on the network. Similarly, a read on a lower adapter handle will fetch an incoming packet from the network.
This PCARedir interface can be thought of as the “net side interface”.
Virtual Adapter Interface
A handle opened on the Virtual Adapter Interface may seem confusing. At first it seems “upside down”.
A write on a virtual adapter Win32 handle will inject a packet “up the stack” where it will eventually enter the TCP/IP transport as if it had been received from the network. Similarly, a read on a virtual adapter handle will fetch an outbound packet being sent by a higher-level protocol.

Redirection Filters
The PCARedir driver includes a separate Redirection Filter on each of the two interfaces.
1 Filter on Virtual Adapter Interface – Packet disposition based on inspection of outbound packets from upper-level protocols. A “send filter”.
2 Filter on Lower Adapter Interface – Packet disposition based on inspection of inbound packets from the network. A “receive filter”

* IP Packet Redirector Logical Block Diagram.JPG (41.61 Кб - загружено 3175 раз.)
« Последнее редактирование: 08-02-2010 21:36 от Ochkarik » Записан

RTFM уже хоть раз наконец!  RTFM :[ ну или хотя бы STFW...
resource
Молодой специалист

ru
Offline Offline
Пол: Мужской

« Ответ #12 : 09-02-2010 02:14 » 

Нда. Признаться, выглядит немного бредово. Картинка конечно красивая, но нарисовать то можно, что угодно. Например, можно было втиснуть обработку пакетов на удаленной машине. Это я не к тому, что картинка врет, а к тому что посмотреть бы как всё это выглядит на уровне исходного кода. В любом случае, странно, что данные из юзермода проходят через Virtual Adapter, затем через TCP/IP transport, потом снова попадают в Virtual Adapter и в конце концов на Miniport Не понял

Добавлено через 4 минуты и 39 секунд:
Цитата: Ochkarik
обычно под кросплатформенностью все таки  портабельность кода с точки зрения использованных функций  на различные ОС...
Я тоже так полагаю
« Последнее редактирование: 09-02-2010 02:18 от resource » Записан
Ochkarik
Модератор

ru
Offline Offline
Пол: Мужской

« Ответ #13 : 09-02-2010 08:46 » 

resource, вот и я не понял пока зачем так сложно... но какой то смысл в этом был?
Записан

RTFM уже хоть раз наконец!  RTFM :[ ну или хотя бы STFW...
resource
Молодой специалист

ru
Offline Offline
Пол: Мужской

« Ответ #14 : 09-02-2010 09:09 » 

Цитата: Ochkarik
но какой то смысл в этом был?
А черт его знает...
Записан
tayphoon
Интересующийся

ru
Offline Offline

« Ответ #15 : 10-02-2010 15:26 » new

Наверное ребята просто перемудрили)


Вообще поковырялся я и пришел к выводу:
1. Для синхронизации программы и драйвера можно использовать события либо механизм APC
2. Для обменом данных лучше использовать разделяемую память
Теперь буду разбираться с этим всем.
« Последнее редактирование: 10-05-2010 07:41 от RXL » Записан
supermaxus
Участник

ru
Offline Offline

« Ответ #16 : 06-11-2010 01:47 » 

Возможно ли в NDIS драйвере реализовать с помощью механизма событий или callback'ов передачу пакета в программу? Необходимо, чтобы при приходе любого пакета программа узнавала об этом и получала его.

Далее все ИМХО.

Из нестандартных решений:

Делать callback из ядра в юзермод - безумие с точки зрения безопасности. Если бы MS такое сделала, то на ушах стоял бы весь инет. В свое время программисты долго муссировали возможность записать код(как последовательность символов) вместо логина в окно winlogon и вызвать таймер с адресом функции на этот код для перехода в ring0. А тут предлагается готовая технология Класс! В любом случае, концепцию шлюзов x86 никто не отменял. И она на уровне CPU запрещает такие дела: прога из юзермода вызывает шлюз, за шлюзом закреплен обработчик для ring0, который не может предоставить управление на ring уровнем выше своего (1,2,3). Иначе бы любой код из юзермода ходил бы пешком в кернел мод.

Про события (APC) - мысль интересная, но насколько я нарыл в ддк - события кернел-мода и юзермода живут отдельно. И как эмулировать объект синхронизации из кернел-мода для юзермода не совсем понятно.

Теоретически можно в драйвер передать адрес памяти из юзермода и писать в эту память при некоторых условиях. При этом, юзермод будет в цикле читать заголовок в начале этой памяти и по нему(например, первый байт = 1) определять наличие полезных данных. Сбрасывая тот же байт в 0 можно сообщать драйверу о возможности следующего обновления данных. При этом, операции чтения/записи между прогой юзермода и драйвером даже синхронизировать не надо, поскольку если выполняется поток кернел-мода, то пока он не завершит свою работу никакой юзермод не получит управление. Однако, это справедливо для однопроцессорных систем:) Думается, что такой метод покажет более лучшую производительность, чем постоянный опрос драйвера запросами IOCTL (здесь нет накладных расходов на переключение в кернелмод и обратно, за исключением первого раза для передачи адреса буфера).
Записан
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines