oleshii
Участник
Offline
|
|
« : 26-11-2012 05:26 » |
|
Всем привет, глубокоуважаемые Гуру свободной мысли ! Наверное, больше вопрос адресован к товарищу x64, но если вдруг кто то натолкнет на что либо умное, буду бесконечно благодарен. Итак, как гласит тема, вопрос о прехвате TDI в Windows 8. Знаю, что сие пообещали "выкарлить" из 8-ки, но не "выкарлили" наши друзья из Ms, которые "снабжают" нас работой. Тем не менее, почти весь функционал TDI сохранился. Фильтр не ловит SMB трафик. Знаю, что прошли изменения протокола, и SMB 2.2 переименовали в SMB 3.0 = поплыли структуры. Знаю, что раньше это "ходило" по TDI_SEND и IOCTL_TDI_QUERY_DIRECT_SEND_HANDLER = по сему возвращался указатель на функцию TCPIP. Теперь посылка этого IOCTL вызывает STATUS_NOT_IMPLEMENTED. Может, кто то может сказать, где теперь "ползает" SMB ? Заранее благодарен Олег Н.
|
|
|
Записан
|
|
|
|
izl3sa
Интересующийся
Offline
|
|
« Ответ #1 : 27-11-2012 05:03 » |
|
насколько знаю в вин8 например метро приложения уже не перехватываются через TDI + там есть интерфейс для сокетов юзермодный (+ новый кернел модный WSK), скорее через него теперь весь SMB траффик идет. Переходите уже на WPF callout drivers, а TDI оставьте только на XP ибо они проще, надежнее и быстрее (в смысле не даунгрейдят общесистемный перфоманс). Тем более они очень просты =)
|
|
|
Записан
|
|
|
|
oleshii
Участник
Offline
|
|
« Ответ #2 : 27-11-2012 11:42 » |
|
izl3sa, Спасибо. Насчет WSK - в курсе, он появился с Vista начиная. WFP (по моим прочтениям, они не всеобъемлющи) платформа полу-UI, работающая при отключенном firewall. Вызовы SOCKET интерфейса по любому пойдут в ядро, а точнее - в экспорты драйвера netio.sys System networking perfomanse downgrade тянется еще начиная с самых первых NT-ядер, поскольку сеть в NT "прибивали" гвоздями из-за маркетинговой ошибки Билла Г. В общем - спасибо всем за внимание, разобрался сам. Где "ползает" SMB так и не понял, но задача решена. Кому интересно - могу чуток рассказать об особенностях TDI в 8-ке.
|
|
|
Записан
|
|
|
|
izl3sa
Интересующийся
Offline
|
|
« Ответ #3 : 28-11-2012 05:27 » |
|
>> WFP (по моим прочтениям, они не всеобъемлющи) платформа полу-UI, работающая при отключенном firewall. вы что-то не то читали, там весь трафик виден будет, в callout драйвере и причем здесь UI вообще?
|
|
|
Записан
|
|
|
|
oleshii
Участник
Offline
|
|
« Ответ #4 : 28-11-2012 11:50 » |
|
izl3sa, Может быть и недочитал - спорить не стану. Но ВЕСЬ инет полон рекомендаций на тему о том, что "работающая при отключенном firewall" Меня это НИКАК не устраивает. Nobody from end users will turn off the Windows Firewall according of concrete product needings. Весь траффик также виден и в NDIS, но в него мне лезть не хочется по иным причинам. Цель - не разобраться как и что (в данном случае). Цель - сделать ASAP с минимальным изменением project code base. Своей цели я достиг.
|
|
|
Записан
|
|
|
|
izl3sa
Интересующийся
Offline
|
|
« Ответ #5 : 29-11-2012 06:49 » |
|
>> Но ВЕСЬ инет полон рекомендаций на тему о том, что "работающая при отключенном firewall" бред =) всего интернета не нужно, есть osr ) коллауты и вообще WPF делали как раз для фильтрации трафика и фаерволов в частности у меня в частности все работает в независимости от фаерволов и тд, что в принципе ясно следует из того, что каллауты связываются в цепочку.
>> есь траффик также виден и в NDIS там не виден конкретный контекст, от которого пришел запрос, понятно же, что это не катит если нам нужно к примеру приложение, которое реквестит.
>> Цель - сделать ASAP с минимальным изменением project code base. Своей цели я достиг. не понятно, что если просто заказ на конкретную доработку то смысла большого нет, но в 2014 году хр умрет окончательно, и в силу того,что часть трафика в TDI не видна на последних системах то полный переход на wpf видится мне довольно разумным шагом.
|
|
|
Записан
|
|
|
|
oleshii
Участник
Offline
|
|
« Ответ #6 : 30-11-2012 06:35 » |
|
izl3sa, >> коллауты и вообще WPF делали как раз для фильтрации трафика и фаерволов в частности >> у меня в частности все работает в независимости от фаерволов и тд, что в принципе ясно следует из того, что каллауты связываются в цепочку. Может быть, с этим спорить не стану. Может быть, это БЫЛО на ранних стадиях WFP. Таким образом, решение - не всеобъемлющее, меня это не устраивает.
>> виден и в NDIS там не виден конкретный контекст, от которого пришел запрос, понятно же, что это не катит если нам нужно к примеру приложение, PsGetCurrentProcess, ZwQuerySystemInformation, IoGetRequestorIrp - об ЭТОМ слышали ?
>> не понятно, что если просто заказ на конкретную доработку то смысла большого нет А с какой целью интересуетесь ? И вообще - какова цель беседы ? Обменяться знаниями ? Этого нет. Поспорить о том, кто круче ? Разрешите самоустраниться, в этом участвовать желание отсутствует. Если Вас это греет и цепляет, считайте, что Вы, Бог с Вами.
|
|
« Последнее редактирование: 30-11-2012 06:38 от oleshii »
|
Записан
|
|
|
|
oleshii
Участник
Offline
|
|
« Ответ #7 : 28-03-2013 07:55 » |
|
Итого, пришлось таки переползать на wfp. Впечатления: 1) wfp for kernel - интерфейс к kernel mode firewall 2) user data - process packet requestor реализована из рук вон плохо, а точнее - никак, хотя ВСЕ интерфейсы для этого есть Говоря точнее, вместо process requestor пакета в FWPS_INCOMING_VALUES кладутся данные из current process Таким образом, request originator скрыт 3) задача фильтрации LAN, а именно - на per user основе без серьезных kernel hacks не решается НИКАК 4) проблема routing не решается НИКАК (оно и понятно - вопросы индейцев не волнуют шерифа !) 5) MS примеры написаны НАСТОЛЬКО криво, что ДАЖЕ в демонстрационных условиях валятся в BSOD Что в общем то тоже понятно - если в них текст комментариев идет с грамматическими ошибками (индусы, млин !) В итоге: wfp - весьма СВОЕОБРАЗНАЯ платформа, которая в "чистом" виде весьма и весьма малопригодна для решения интересующих большинство людей задач. Решение возможно, но в большинстве случаев - на основе mixed technologies, in concrete - NDIS, security, session objects tracking, and etc
|
|
|
Записан
|
|
|
|
|