Re: Монитор доступа к разделяемым ресурсам
От: x64 Россия  
Дата: 05.10.10 12:36
Оценка: +1
SA>Вобщем возникла необходимость в написании такого монитора...

Не понял, какие именно ресурсы имеются в виду?
Монитор доступа к разделяемым ресурсам
От: SecurAdmin  
Дата: 29.09.10 09:50
Оценка:
Вобщем возникла необходимость в написании такого монитора (уровень ядра желателен, хотя, если можно обойтись без него, с удовольствием выслушаю предложения). Собственно вопрос как раз в том, что это за драйвер должен быть? Есть предположения, что драйвер-фильтр, тогда сразу ряд вопросов: какой Lower или Upper и к чему его аттачить? Написанием драйверов ранее не занимался, ногами просьба не пинать, копаясь в литературе запутался окончательно, раздупляться буду по мере поступления проблем. Пока это первая проблема, поэтому остальные вопросы пока задавать смысла нет. Если Вам не сложно будет в общих понятиях расписать шаги создания такого монитора, буду премного благодарен. Если есть доступная для понимания литература, буду рад ссылкам.
Re[2]: Монитор доступа к разделяемым ресурсам
От: Аноним  
Дата: 07.10.10 09:55
Оценка:
Здравствуйте, x64, Вы писали:

SA>>Вобщем возникла необходимость в написании такого монитора...


x64>Не понял, какие именно ресурсы имеются в виду?

Shared resources (шары) т.е. по сути нужен низкоуровневый монитор 139 порта (даже не монитор, а некий сигнализатор, т.е. как только кто-то попытался открыть у меня на компе какой-либо расшаренный файл или папку (открылась сессия), драйвер, через IOCTL должен сообщать о факте такого чудовищного вандализма юзермодному приложению, которое в свою очередь само обработает всю эту ситуацию), ну и еще кое-какой незначительный функционал.

Сейчас вроде бы начинает проясняться ситуация — копаю в сторону hook-драйвера (к \\Device\\IPFILTERDRIVER)
Re[3]: Монитор доступа к разделяемым ресурсам
От: x64 Россия  
Дата: 07.10.10 10:23
Оценка:
А>Shared resources (шары)...

Ясно.

А>...по сути нужен низкоуровневый монитор 139 порта


Во-первых, начиная с Windows 2000 используется порт 445 для прямого подключения к SMB-серверу (ну или 139, если включено NetBIOS). Во-вторых, если ты хочешь мониторить любую активность на определённом порту — то это одна задача, но если ты хочешь мониторить доступ к шаренным папкам (и прочим ресурсам), то это уже другая задача. Что именно тебе нужно? Подумай. Потому что если первое, то ты двигаешься в правильном направлении, если второе, то это следует решать по-другому.

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


Это всё проблемы не представляет.

А>...копаю в сторону hook-драйвера...


Неправильно. Если уж писать сетевой фильтр, то только на основе TDI-фильтра. Но тут есть нюанс, что тебе придётся разбирать структуры SMB-протокола, чтобы понять, зачем именно было осуществлено подключение и к какому именно ресурсу был запрошен доступ. Если это не проблема, то вперёд. Более правильным решением данной задачи может стать файловый фильтр с подключением к сетевым файловым системам. Недостаток у этого решения ровно один: он покрывает только такие типы ресурсов, как шаренные папки и тома, остальное же (принтеры, etc.) как фильтровать — мне не известно, в ядре это нереально, насколько знаю. Такие дела.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.