netfilter sdk что это
Netfilter sdk что это
Implementing many kinds of network filtering applications is easier with NetFilter SDK and ProtocolFilters:
— Parental control
— Traffic shapers/monitors
— Ad blocking
— Filtering email spam
— Redirecting TCP/UDP to local or remote proxy
— Decoding and filtering TCP connections protected with SSL
— Parsing SSL, HTTP, POP3, SMTP, FTP, ICQ, XMPP, NNTP and other protocols
— Other software that requires filtering TCP/UDP
It is possible to use the components from C/C++/Delphi/.NET code
NetFilter SDK
for Windows
NetFilter SDK is a framework for transparent filtering the data packets transmitted via network on Windows. This is a high performance proxy-less solution, compatible with antiviruses/firewalls/other network filters. Also it includes server side components, allowing to filter TCP/UDP on a gateway.
System requirements:
Windows XP/2003/2008/2012/Vista/7/8/10, x86/x64.
ProtocolFilters
ProtocolFilters is a library that classifies data packets provided on input, detects high-level protocols and allows filtering the classified objects. It is designed to work with NetFilter SDK API, but also can be used for parsing and filtering the network packets obtained from other sources.
System requirements:
Windows XP/2003/2008/2012/Vista/7/8/10, x86/x64.
Linux, Mac OS
NetFilter SDK
for Linux and Mac OS
The solution allows filtering TCP connections and allow/block UDP datagrams in user mode applications. It is possible to filter the specified subset of connections/datagrams, restricted by filtering rules. The outgoing TCP connections can be redirected to different address.
System requirements:
Linux, Mac OS
October 21, 2021
NetFilter SDK 2
build 1.6.2.0 [changelog]
ProtocolFilters
build 1.2.6.9 [changelog]
June 3, 2021
NetFilter SDK
for Linux and Mac OS
build 1.0.2.1 [changelog]
filecheck .ru
Вот так, вы сможете исправить ошибки, связанные с netfilter2.sys
Информация о файле netfilter2.sys
Важно: Некоторые вредоносные программы маскируют себя как netfilter2.sys. Таким образом, вы должны проверить файл netfilter2.sys на вашем ПК, чтобы убедиться, что это угроза. Мы рекомендуем Security Task Manager для проверки безопасности вашего компьютера.
Комментарий пользователя
Лучшие практики для исправления проблем с netfilter2
Если у вас актуальные проблемы, попробуйте вспомнить, что вы делали в последнее время, или последнюю программу, которую вы устанавливали перед тем, как появилась впервые проблема. Используйте команду resmon, чтобы определить процесс, который вызывает проблемы. Даже если у вас серьезные проблемы с компьютером, прежде чем переустанавливать Windows, лучше попробуйте восстановить целостность установки ОС или для Windows 8 и более поздних версий Windows выполнить команду DISM.exe /Online /Cleanup-image /Restorehealth. Это позволит восстановить операционную систему без потери данных.
netfilter2 сканер
Security Task Manager показывает все запущенные сервисы Windows, включая внедренные скрытые приложения (например, мониторинг клавиатуры или браузера, авто вход). Уникальный рейтинг надежности указывает на вероятность того, что процесс потенциально может быть вредоносной программой-шпионом, кейлоггером или трояном.
Бесплатный aнтивирус находит и удаляет неактивные программы-шпионы, рекламу, трояны, кейлоггеры, вредоносные и следящие программы с вашего жесткого диска. Идеальное дополнение к Security Task Manager.
Reimage бесплатное сканирование, очистка, восстановление и оптимизация вашей системы.
Microsoft призналась в подписании вредоносного драйвера «Netfilter»
Новая атака на цель поставок: Microsoft подписала руткит
Аналитик из компании G Data Картсен Хан (Karsten Hahn) впервые обнаружил необычное поведение и присоединился к сообществу Infosec с целью совместного отслеживания и анализа вредоносной активности драйвера, подписанного Microsoft.
Данный инцидент вновь обращает наше внимание на безопасность цепи поставок. В этом случае атака оказалась успешной из-за уязвимости в процедуре подписания кода Microsoft.
Эксперт по безопасности G Data заявил:
Драйвер «Netfilter» является руткитом, подписанным Microsoft. На прошлой неделе защитные системы G Data зафиксировали опасное поведение, которое казалось ложным срабатыванием. На самом деле, драйвер «Netfilter», с подписью Microsoft несет реальную угрозу.
При детальном анализе оказалось, что драйвер общается с командными серверами (С2) с китайскими IP-адресами. Своей находкой специалист G Data сразу же поделился с Microsoft. Хан пояснил:
Еще со времен Windows VIsta любой код, запускаемый в режиме ядра, нужно тестировать и подписывать до публичного выпуска, чтобы обеспечить стабильную работу операционной системы.
Драйверы без сертификата Microsoft не могут быть установлены по умолчанию.
Анализ командных серверов, выявил, что первый URL-адрес C2 возвращает набор нескольких маршрутов, разделенных символом «|».
При переходе по URL-адресу становятся доступно больше маршрутов разного назначения:
Маршрут /v предоставляет путь к вредоносному драйверу Netfilter по маршруту /d3.
Исследователю G Data понадобилось некоторое время, чтобы проанализировать драйвер и убедиться в его вредоносной природе.
В отдельной публикации блога исследователь приводит результаты анализа драйвера, его функции самостоятельного обновления и указывает индикаторы компрометации.
Образец поддерживает процедуру самостоятельно обновления, которая отправляет собственный хеш MD5 на сервер через hxxp://110.42.4.180:2081/v?v=6&m=,
Пример запроса выглядит следующим образом:
Эксперт G Data добавил:
Затем сервер либо возвращает адрес с новейшей версией образца, например hxxp://110.42.4.180:2081/d6, либо статус ОК, если используется актуальная версия образца.
В ходе своего анализа Хан присоединился к другим исследователям вредоносных программ: к Иоганну Айденбасу (Johann Aydinbas), к Такахиро Харуяма (Takahiro Haruyama) и к Флориану Роту (Florian Roth).
Рот смог собрать список образцов в электронной таблице и предоставил в инструмент YARA правила для обнаружения угрозы в вашей сетевой среде.
Любопытный факт, что один из командных серверов с IP-адресом 110.42.4.180 связывается с доменом, который согласно WHOIS, принадлежит компании Ningbo Zhuo Zhi Innovation Network Technology Co., Ltd.
Microsoft признается в подписи вредоносного драйвера
Microsoft продолжает расследовать данный инцидент и пока нет доказательств того, что использовались украденные сертификаты подписания кода. Компания сообщает:
Microsoft расследует инцидент безопасности, связанный с распространением вредоносных драйверов в игровых средах.
Злоумышленники представили драйверы для сертификации через программу совместимости оборудования Windows. Драйверы были разработаны третьей стороной.
Мы заблокировали аккаунт и проанализировали представленные материалы на предмет дополнительных признаков вредоносных программ.
Согласно Microsoft, в качестве целей киберпреступников интересовал игровой сектор в Китае, и нет никаких признаков ущерба в корпоративных средах.
Бинарные файлы с полученной обманным путем подписью могут использоваться для проведения крупномасштабных атак на цепь поставок. Например, в атаке Stucernet, нацеленную на ядерные объекты Ирана, использовались вредоносные файлы, подписанные сертификатами Realtek и Jmicron.
Этот конкретный инцидент раскрыл уязвимости процедур подписания кодов, которые активно эксплуатируются злоумышленникам для получения надежного сертификата без его компрометации
Client side components
NetFilter SDK is a framework for transparent filtering the data packets transmitted via network. This is a high performance proxy-less solution, compatible with all antiviruses/firewalls/other network filters. It allows filtering the transmitted packets without redirecting connections to proxy. The SDK suits for developing the content filters, basic application level firewalls, traffic analyzers/shapers, other software that requires viewing and modifying TCP/UDP traffic on Windows.
SDK consists of kernel mode and user mode parts. TDI and WFP level kernel drivers are used to filter the transmitted packets. The drivers have a simple user level API, which can be used from C/C++/.NET/Delphi code. TDI level driver suits for Windows 7 and lower, WFP level driver works on Windows 7 and higher.
System requirements:
Windows XP/2003/2008/2012/Vista/7/8/10, x86/x64.
Limitations:
The driver must be signed with a code signing digital certificate to work properly on 64-bit operating systems starting from Windows Vista. More details are provided here.
Server side components
nfsrvfilter is a server side driver, allowing to control access and filter IP traffic on a gateway host. TCP connections and UDP packets directed to other hosts via gateway with installed driver can be filtered by redirecting them to local proxy using network address translation. When the filtering is enabled for TCP and UDP, the solution works as a transparent proxy for the filtered traffic.
Limitations:
The driver must be signed with a code signing digital certificate. More details are provided here.
Учимся писать модуль ядра (Netfilter) или Прозрачный прокси для HTTPS
Эта статья нацелена на читателей, которые начинают или только хотят начать заниматься программированием модулей ядра Linux и сетевых приложений. А также может помочь разобраться с прозрачным проксированием HTTPS трафика.
Постановка задачи
Как и все начинающие в области IT захотелось покопаться немножко в ядре. Тут и область для экспериментов появилась сама собой. Если заглянуть в гугл, то можно заметить, что, если с прозрачным прокси-сервером для HTTP проблем ни у кого не возникает, то в случае с HTTPS некоторые уверены в том, что прозрачного прокси для протокола HTTPS нет. И его никогда не будет. Все это и послужило появлению этой статьи.
Для начала рассмотрим некоторые аспекты работы прокси-сервера, которые нам понадобятся. Когда браузер напрямую обращается к HTTP серверу, то он создает следующий типовой запрос:
Когда в настройках браузера указываем прокси сервер, то браузер начинает соединяться с прокси-сервером, и отсылает ему запрос с полным адресом:
Если прокси сервер получит запрос с неполным адресом, как в первом случае, то он может не знать, кому предназначен этот запрос и возвратит ошибку.
Скажу в двух словах про HTTPS. Браузер устанавливает tcp соединение и, используя протокол SSL: обменивается сертификатами и передает зашифрованный трафик HTTP. Так как протокол SSL как раз направлен на то, чтобы никто не смог посередине прочитать передаваемые данные, то прокси-сервер не может, как в случае HTTP, выяснить с кем следует установить соединение. Для передачи данных по HTTPS через прокси-сервер браузер должен сообщить прокси-серверу с кем он хочет соединиться, используя HTTP метод CONNECT:
На что прокси-сервер должен ответить, что соединение успешно установлено:
В результате браузер получает как бы прямое tcp соединение через прокси-сервер, в котором он может передавать абсолютно любые данные. А прокси-сервер занимается только точной перекладкой данных из tcp соединения, установленного с браузером, в tcp соединение, установленное с указанным хостом в методе CONNECT, и, соответственно, обратной перекладкой.
Когда используется прозрачное проксирование, т.е. браузер даже не подозревает о существование прокси-сервера, то соответственно браузер и не будет так красиво подготавливать свои данные. И прокси-серверу придется самому подумать об этом.
Схематично взглянем на прозрачный прокси для HTTP: 
Здесь конечно есть неточности, например, прокси, получая пакет на свой порт 3128, не передает его дальше гуглу, а создает новое соединение с гуглом, но, в общем, схема взаимодействий примерно такова. В данной схеме видно, что NAT начинает направлять пакеты прокси-серверу, которые предназначены не для него, и ему требуется узнать кому их все-таки отсылать. В случае с HTTP трафиком некоторые прокси-сервера неправомерно начинают пользоваться информацией из поля HOST заголовка HTTP запроса, нарушая спецификацию. Чаще всего конечно в HOST содержится именно то имя хоста, которому и адресован запрос, но, в общем случае, HOST может содержать что угодно. Для HTTPS такое решение и вовсе не подходит. Чтобы узнать, кому адресован пакет, сразу напрашивается решение, в котором прокси-сервер заглянул бы в NAT и посмотрел, кому все-таки были предназначены данные и тогда проблем бы ни каких не было. Вот собственно, чем и займемся.
В сам iptables, к сожалению, не полезем, но все равно будут хорошо понятны основные принципы его работы. Схематично это будет выглядеть следующим образом:
Для намеченных целей, будет достаточно написать крохотный модуль ядра (Module Shifter) и реализовать небольшую программную прослойку (Shifter) в пользовательском пространстве для взаимодействия с нашим модулем, которая и будет подготавливать данные для прокси-сервера.
Клиент – серверное приложение (Shifter)
Напишем маленькое клиент-серверное приложение, которое я назвал Shifter. Shifter будет висеть на своем порту и, когда кто-нибудь установит tcp соединение с ним, то он создаст tcp соединение с прокси-сервером и пошлет ему метод CONNECT (HTTP), а далее будет заниматься только точной передачей данных между этими двумя соединениями. В случае если клиент или прокси закроет соединение с ним, то он закроет эту пару сокетов.
Для отправки метода CONNECT нужен ip адрес удаленного узла, с которым на самом деле хотел установить соединение клиент. Чтобы получить эту информацию Shifter будет связываться с модулем ядра (Module Shifter) используя библиотеку Netlink. Об этом будет рассказано в последней части этой статьи.
Данным приложением мы подготовим прокси-сервер к приему данных (HTTPS) от клиента, который ничего не знает о прокси-сервере. Так как имеется много ресурсов, где подробно написано про сокеты, здесь лишь приведу ссылку на часть исходного кода Shifter’а с подробными комментариями.
Kernel module Shifter
Теперь у нас имеется вся информация, чтобы написать каркас своего первого модуля:
Расскажу еще немного о том, как это все скомпилировать и запустить. Скажу сразу, что у меня установлена Ubuntu 11.10 (x86) Kernel 3.0.
В системе имеется каталог /lib/modules/[версия ядра]/ в нем находятся модули для соответствующей версии ядра. Также там имеется build – это символическая ссылка на заголовки библиотек ядра (kernel-headers), которые находятся в каталоге /usr/src/linux-headers-[версия ядра]/. Если у вас еще нет kernel-headers, то их нужно скачать (sudo apt-get install linux-headers-[версия ядра]). Чтобы узнать версию текущего ядра, в котором Вы работаете, можно выполнить команду uname –r. Если будете использовать библиотеку с версией отличной от версии текущего ядра, то такой скомпилированный модуль может замечательно работать, а может в лучшем случае не запуститься. Это все зависит от того, какие произошли изменения в ядре, и какие Вы используете в модуле функции.
Для компиляции модуля напишем Makefile. Создадим две цели: all (сборка модуля) и clean (очистка проекта), для их написания воспользуемся уже написанными для нас целями: modules и clean в Makefile из kernel-headers.
Библиотека Netfilter
С теорией разобрались, теперь продолжим писать модуль. При загрузке модуля в ядро нужно зарегистрировать функцию, назовем ее Hook_Func, которая будет просматривать все входящие пакеты, а при завершении эту функцию надо разрегистрировать, иначе ядро будет пытаться вызывать несуществующую функцию.
Теперь все что нам осталось — это написать саму функцию Hook_Func. Она должна иметь следующий прототип:
sk_buff – это буфер для работы с пакетами. Как только приходит пакет или появляется необходимость его отправить, создается sk_buff, куда и помещается пакет, а также сопутствующая информация, откуда, куда, для чего… На протяжении всего путешествия пакета в сетевом стеке используется sk_buff. Как только пакет отправлен, или данные переданы пользователю, структура уничтожается, тем самым освобождая память.
В этом месте я хотел бы обратиться к читателю. Мне осталось не совсем понятным, кто именно должен устанавливать указатель transport_header в структуре sk_buff, т.к. в точках NF_INET_PRE_ROUTING и NF_INET_LOCAL_IN (с любыми приоритетами) мне не удалось с помощью skb_transport_header получить структуру на tcp заголовок, хотя в остальных точках это работало прекрасно. Пришлось вручную указывать смещение для transport_header от указателя sk_buff->data, воспользовавшись void skb_set_transport_header(skb, offset).
Упомянутый указатель sk_buff->data — это указатель на содержимое пакета, т.е. указывает на область памяти после Ethernet протокола, например, сразу на структуру IP заголовка, а после нее может следовать структура TCP заголовка или Ваш собственный протокол.
Так как везде используются указатели на данные в самом пакете, то можно не только читать различные поля, но и изменять их. Однако нужно помнить, что при изменении, например, IP адреса отправителя или получателя следует еще пересчитать контрольную сумму в заголовке IP пакета.
И так, наша функция будет сохранять IP адрес назначения только тогда, когда она увидит IP-TCP пакет, идущий на порт 443 (HTTPS) и содержащий флаг SYN, который говорит, что клиент хочет установить TCP соединение для протокола HTTPS. И удалять, когда появляются пакеты содержащие флаги FIN или RST, которые сообщают что tcp соединение разорвано и больше этот IP адрес нам не нужен.
Здесь есть две функции AddTable и DelTable, которые должны сохранять и удалять IP адрес получателя из памяти, для каждого IP и порта отправителя. Это нужно для того, чтобы клиент-сервер Shifter смог связаться с модулем Shifter и воспользовавшись функцией ReadTable, узнать по IP и порту клиента с каким IP адресом на самом деле хотел он связаться. Я не стал сильно раздумывать над типом данных для сохранения IP и воспользовался обычным статическим массивом с использованием элементарной хэш-функции. Хэш-функция (KeyHash) получает на входе ip и порт отправителя и возвращает индекс массива, где хранится ip адрес назначения. Она написана с учетом того, что клиент находится за натом и имеет подсеть с маской 255.255.255.0, поэтому я использую только последний байт ip отправителя, и еще этот байт накладывается 3 битами на два байта порта. В результате мне удалось сжать массив до размера 0x1FFFFF (
8 Мб). Конечно, нужно учитывать, что теперь после загрузки в ядро этот модуль будет занимать не меньше 8 Мб памяти, а это может оказаться слишком много для каких-нибудь встраиваемых систем. И еще не забываем про коллизию 🙂 Но для моего демонстрационного примера все это окупается простотой и, вдобавок, DelTable вообще осталась пустой.
На этом эта длинная часть статьи закончена и осталось только связать клиент-сервер Shifter c модулем ядра Shifter.
Взаимодействие с модулем ядра из пользовательского пространства (Netlink)
Теперь наша цель создать по одному сокету в Shifter и в модуле Shifter и соединить их между собой. Протокол обмена между модулем и сервером Shifter будет простым. Shifter будет отсылать 4 байта IP клиента и 2 байта Порт клиента, а модуль будет отвечать 4 байтами IP назначением, взятым из своей таблицы. Для этого воспользуемся библиотекой Netlink.
Хочу обратить внимание, что заголовок для пользовательских приложений /usr/include/linux/netlink.h и для модулей ядра /usr/src/linux-headers-[версия ядра]/include/linux/netlink.h имеет множество различий.
Netlink in user space
struct nlmsghdr – заголовок сообщения netlink и сразу за структурой в памяти расположены отправляемые/принимаемые данные, для доступа к ним используйте NLMSG_DATA(struct nlmsghdr *) макрос.
struct iovec — находится в msghdr, в ней будет содержаться указатель на структуру nlmsghdr.
struct msghdr – содержит указатель на адрес (sockaddr_nl) и данные (iovec)
Рассмотрим некоторые макросы Netlink:
Округляет размер сообщения netlink до ближайшего большего значения, выровненного по границе.
Принимает в качестве параметра размер поля данных и возвращает выровненное по границе значение размера для записи в поле nlmsg_len заголовка nlmsghdr.
Возвращает размер памяти (в байтах), который займет структура nlmsghdr плюс данные указанной длины len (в байтах) в пакете netlink.
Возвращает указатель на данные, связанные с переданным заголовком nlmsghdr.
Возвращает следующую часть сообщения, состоящего из множества частей. Макрос принимает следующий заголовок nlmsghdr в сообщении, состоящем из множества частей. Вызывающее приложение должно проверить наличие в текущем заголовке nlmsghdr флага NLMSG_DONE – функция не возвращает значение NULL при завершении обработки сообщения. Второй параметр задает размер оставшейся части буфера сообщения. Макрос уменьшает это значение на размер заголовка сообщения.
Возвращает значение TRUE (1), если сообщение не было усечено и его разборка прошла успешно.
Возвращает размер данных, связанных с заголовком nlmsghdr.
Netlink Kernel Space
Чтобы закрыть netlink сокет и удалить «регистрацию функции» воспользуйтесь:
Заключение
В заключение скажу, чтобы перенаправить пакеты на прокси-сервер, достаточно на шлюзе добавить правило в iptables: