Здравствуйте, Michaels1, Вы писали:
M>Как у Вас успехи с LSP? Обещали отписаться 
M>Может, поделитесь опытом? 
TarasCo был прав.
От LSP в конце концов отказались, угрохав кучу времени, сил, денег и нервов.
Если интересно, могу написать более подробно.
Потом продукт все-таки выпустили, взяв за основу самый обыкновенный фильтр TDI.
Программное ядро оказалось значительно проще, хотя тонкостей и недокументированных
особенностей и на этом уровне такое количество, что браться за TDI можно
только тогда, когда предельно хорошо понимаешь работу сетей, протоколов и
вообще когда отдаешь себе отчет в том, что именно делаешь и чего хочешь достичь.
Мне повезло — я попытки с трехсотой нагуглил очень толковые исходники промышленного
уровня (я сейчас не про tdifw), из которых почерпнул чрезвычайно много интересного и
полезного. А еще я месяцами штудировал RFC, писал прототипы, изучал работу браузеров и
веб-серверов. И регулярно пролистывал одни и те же темы на RSDN и WASM, где встречались
хотя бы намеки на TDI, NDIS, LSP и фильтрацию. Фактически, я прочел их все.
Многое в голове прояснилось после этого.
Сейчас в разгаре работа над логическим продолжением первой версии программы, с
учетом приобретенного опыта и знаний. Детали реализации мог бы открыть абсолютно
без сожаления, но не могу, ибо NDA.
Здравствуйте, Аноним, Вы писали:
O>>TarasCo был прав.
O>>От LSP в конце концов отказались, угрохав кучу времени, сил, денег и нервов.
O>>Если интересно, могу написать более подробно.
А>Конечно интересно, я думаю не только мне
LSP — тяжелая штуковина.
И по ней практически отсутствует документация, руководства.
В гугле нарыл несколько примеров, но они все, без исключения,
были глючными, либо работали с ограничениями. Популярный сэмпл от
Comodia вообще завелся только на Vista, а на XP работать отказался.
При этом технология реально используется, вроде бы даже в Dr.Web и
NOD32, хотя за эти данные ручаться не могу.
Плюсы LSP заключаются в том, что фильтрация происходит в user mode, и
для запуска на Vista 64 и выше не требуется цифровая подпись.
Ну а минусы в его сложности и глючности. Лично мне в одиночку осилить
LSP дальше тривиальных примеров не удалось. Масса сложностей и
непонимания посыпалась еще на этапе построения каркаса — а это порядка
двадцати тысяч строк. Цифры, кстати, говорят сами за себя.
Примерно полгода бился, а потом плюнул окончательно.
Благо, заказчики системы отнеслись с пониманием и профинансировали.
И еще. Тут где-то проскакивала информация, что некоторая часть
трафика все-таки идет мимо LSP. Ключевые слова — http.sys.
Теперь я один из тех, кто никому не советует брать LSP за основу
фильтра или security-продукта.
Если копать глубже, есть два других пути для фильтрации
трафика на транспортном и прикладном уровне — это WFP и TDI.
В первом случае, правда, придется забыть про Windows XP, но этот
час уже не так и далек. Думаю, еще годика четыре и вопрос поддержки
приложениями этой версии Windows не будет стоять (так остро).
Во втором случае начинается довольно скользкая территория, где
масса недокументированных нюансов, начиная от корректной установки
драйвера и поддержки PnP/питания до обработки ситуаций с задержкой
IRP и присутствием выше в стеке других фильтров — а всякие антивирусы
тоже любят TDI и, быть может, поэтому Microsoft до сих пор не
смогла до конца удалить эту "нечисть" из системы (см. tdx.sys).
Ну а если копнуть еще глубже, то вопрос технологий второстепенный.
Какой бы способ не выбрать, настоящие сложности встают тогда,
когда нужно работать непосредственно с трафиком.
Предположим, стоит задача — фильтровать HTTP-контент и "запикивать"
или вообще вырезать запрещенные слова. И сразу масса вопросов,
которые предстоит решить.
1. Как определить, что поток данных относится к HTTP ?
Была
такаяАвтор:
Дата: 17.04.06
тема, кстати.
По порту 80 — слишком грубо, HTTP может пойти через другой порт на
каком-нибудь прокси-сервере. Также и через порт 80 может пойти
другой трафик (теоретически). Значит, нужен HTTP-парсер.
И парсер не просто теоретически корректный, а такой, который бы
умел отрабатывать ситуации, не специфицированные в протоколах HTTP,
но встречающиеся в настоящих реализациях.
2. Что делать, если ответ сервера приходит в gzip/compress/deflate ?
"Рубить" Accept-Encoding не вариант, хотя бы потому, что некоторые
серверы могут, опять же вопреки спецификациям, возвращать
компрессированный ответ, руководствуясь заголовком User-Agent
(встречал на практике). Следовательно, нужна либа для декомпресси
"на лету". Но тогда как быть с Content-Length ответа ? Вывод один —
преобразовывать ответ в chunked. Справимся, если соединений будет
пятьсот или шестьсот (это не редкость) ? А если у пользователя
медленное соединение, а нам нужно задержать несколько первых килобайт,
чтобы определить и подправить нужные заголовки ? А если сервер
поддерживает только HTTP/1.0, где Transfer-Encoding вообще не
определен ? А еще есть всякие Content-MD5 и т.д.
В общем, работы немерено, гораздо серъезнее, чем написание
"какого-то" там TDI-фильтра.
3. Больной вопрос — кодировка содержимого. С этим аспектом даже
лучшие браузеры не всегда справляются. Что, если нужно резать
слово "х*й", а кодировка ответа неизвестна ? Подключать еще и
HTML-парсинг, чтобы заглянуть в <META http-equiv> ?
Если у пользователя одна страница в кодировке Windows-1251, а
другая в UTF-8, то и слова-образцы нужно перекодировать для
каждой страницы по своему. Соответственно, даже если иметь
словарную базу на 200-300 слов, то для каждого соединения
придется держать ее перекодированную надлежащим образом копию.
Мрак.
4. Как поступать с шифрованными соединениями ?
Все, что приходит на ум — махинации с подменой сертификата на уровне
TCP, как это делает тот же Fiddler. При этом не факт, что все
браузеры "примут" такой сертификат, если он будет установлен в
корневое хранилище, а не в их собственные и предназначенные для
этого локации.
5. Производительность.
Да, хорошо все это дело гонять на четырехъядерном Intel-е с несколькими
гигами ОЗУ и быстрой сетью. А вот снесите-ка свою поделку на старенький
комп с Celeron-ом или Sempron-ом, где Dial-Up и RAM 256 Mb.
Почувствуй, как говорится, разницу.
6. Совместимость со сторонним ПО.
Тут, откровенно говоря, начинается цирк.
Если взять список из двадцати-тридцати наиболее популярных продуктов
безопасности, то наверняка хотя бы с двумя-тремя из них можно поиметь
проблемы совершенно идиотического характера. Стопроцентного решения
этой проблемы, на мой взгляд, не существует — антивирусы обычно
устанавливают эксклюзивный контроль над системой, и могут делать это в
очень агрессивном ключе.
7. Проблемы с пользователями.
А таковые непременно вылезут, и непременно в уродливой форме.
Я о проблемах, а не о пользователях, конечно.
Если заблаговременно не позаботиться об обратной связи, можно
потом месяцами гонять программу на разных машинах и виртуалках,
но так ничего и не выяснить. Приведу пример — у одного нашего
пользователя программа вызвала падение системы и "синий экран",
а произошло это в самом конце удаления программы.
Собрать ничего не удалось — все модули на тот момент уже были
удалены деинсталлятором, никаких полезных данных на "синем экране"
тоже не было. Ничего подобного не происходило ни до, ни после.
Проблемное место вроде нашли, но определить, оно ли было
причиной падения, уже не удалось.
Короче говоря, разработка продуктов такого уровня — дело далеко не
из простых и за нее, даже имея опыт и знания, нужно сразу торговаться
штук на пятнадцать, как минимум, чтобы комфортно провести два-три
месяца за вдумчивым чтением RFC и отладкой в kernel-mode.
А>Исходники именно TDI драйвера? Не поделитесь?
Вот
здесьАвтор: okman
Дата: 28.06.11
я уже писал, с чего можно начать.
Не смейтесь, это реальный путь, который значительно прибавляет скиллов и
ограждает от попадания в распостраненные, но плохо освещенные ловушки.
Хорошие исходники есть у PCAUSA, Rootkit.com. Человек по имени Thomas F. Divine написал
по теме TDI много интересного. Гуглить обязательно. Некоторые исходники давно уже
платные, но находятся на всяких китайских сайтах. Все, что в WDK хоть каким-то боком
относится к фильтрам, также подлежит прочтению (детальнейшему). И, еще раз
повторю, очень многое по TDI можно узнать здесь, на RSDN, просто задействовав поиск.
Кто хочет, тот, как говорится,
найдетАвтор: x64
Дата: 09.07.11
.
А>Я вот тоже начал писать фильтр, задача похожая на вашу (разве что я максимально перемещаю все в юзермод, чтоб исключить ошибки допущенные по неопытности.
А>Вроде работает. Но как всегда с начинающими бывает, боюсь что упустил какой-то момент, что может привести к краху системы в ситемах с конфигурациями отличными от тех, где мне удалось его протестировать. Иметь именно правильно написанный образец перед глазами очень бы не помешало
Правильно написанных драйверов данного типа не существует.
Все они работают с определенными "предположениями" по отношению к окружающей обстановке.
Триста шестьдесят четыре дня в году драйвер может нормально работать, а на триста
шестьдесят пятый вдруг откажется, ибо кто-то сверху в стеке задержал TDI_CONNECT, или
детектировал подмену данных в TDI_REQUEST_KERNEL, или завернул соединение на
свой локальный прокси-сервер, или отправил IRP напрямую драйверу tcpip.sys.
Тестировать надо будет очень тщательно.
И обязательно читайте комменты и вообще документацию к найденным в сети примерам.
Тут как в договоре — все, что написано маленькими буквами, бывает важнее всего остального.
