[Vadim Smirnov]

Yes, it is possible. As an example you can check the 3rd scenario in filter.cpp:

//**************************************************************************************
// 1. Block all ICMP packets
// Common values
pFilters->m_StaticFilters[0].m_Adapter.QuadPart = 0; // applied to all adapters
pFilters->m_StaticFilters[0].m_ValidFields = NETWORK_LAYER_VALID;
pFilters->m_StaticFilters[0].m_FilterAction = FILTER_PACKET_DROP;
pFilters->m_StaticFilters[0].m_dwDirectionFlags = PACKET_FLAG_ON_SEND | PACKET_FLAG_ON_RECEIVE;

// Network layer filter
pFilters->m_StaticFilters[0].m_NetworkFilter.m_dwUnionSelector = IPV4; 
pFilters->m_StaticFilters[0].m_NetworkFilter.m_IPv4.m_ValidFields = IP_V4_FILTER_PROTOCOL;
pFilters->m_StaticFilters[0].m_NetworkFilter.m_IPv4.m_Protocol = IPPROTO_ICMP;

Please note, that in you code you use incorrect value for m_dwDirectionFlags

[Vadim Smirnov]

I never needed to inject 802.11 frames and thus never researched the subject deep. However, here are several links which could be useful:

https://www.codeproject.com/Articles/28713/802-11-Packet-Injection-for-Windows
https://github.com/Felis-Sapiens/packet11
https://github.com/nmap/npcap/issues/85

I’ve taken a quick look at the packet11 code and from what I can see it is a little bit limited in what it can do, e.g. able to inject only management frames.

[Vadim Smirnov]

Yes, this is what I mean. It is not that big deal to make this type of driver from winpkfilter source code, though worth to mention that the functionality of monitoring driver is limited. If I remember fine you can read packets but not to inject them.

[Vadim Smirnov]

You can try to, but I don’t think that it will work. I think you will need a slightly different WiFi monitoring LWF driver for this. I created one in the past from original winpkfilter, but I don’t remember all the details already…

[Vadim Smirnov]

https://github.com/wiresock/ndisapi/tree/master/examples/legacy/Delphi

[Vadim Smirnov]

На скрине еще одна ошибка в правиле, нельзя указать “tcp, udp”, протокол может быть только один, или “tcp” или “udp”. Обратите внимание, что в дампе правила (в консоли) указан protocol = ip, с таким значением проверяются только raw ip пакеты. Если нужны и tcp и udp, то загрузите два правила.

HEX строку тоже нет смысла пробовать, поддерживаются только обычные строки. Ну и если не работает то прикладывайте правило, вывод консоли и еще желательно wireshark capture.

[Vadim Smirnov]

Вернулся сегодня к этому коду, в предыдущей версии была ошибка в поиске подстроки. Здесь поправил.

[Vadim Smirnov]

Еще очень сырой, но попробуйте.

Для работы требуется последний WinpkFilter. Правила загружаются из файла config.conf, пример одного правила есть в архиве: блокирует TCP пакеты по подстроке ntkernel.com, соответственно не дает зайти на https://www.ntkernel.com, так как имя домена находится в SNI.

Для примера, другое правило, блокирует http://www.ntkernel.com по IP:

 {
    "direction":"forward",
    "interface_name":"{C0420ADB-B1CD-4B01-845F-5BB41EE08687}",
    "source_ip_address":null,
    "destination_ip_address":{"address":"40.122.67.8","mask":"255.255.255.255"}
    "ip_protocol":"tcp",
    "source_port_range":null,
    "destination_port_range":[443,443],
    "string_match":null,
    "action":"drop"
    }

direction: возможные значения input, output, forward
FORWARD имеет несколько иной смысл чем в никсах, здесь он означает что правило будет примененно как к исходящим так и к входящим пакетам.

interface_name: GUID сетевого интерфейса, если null – применяется ко всем доступным сетевым адаптерам.

source_ip_address и destination_ip_address указываются в формате как в примере выше.

ip_protocol: допустимые значения кроме null:

enum class ip_protocol :uint8_t
	{
		/* dummy for IP */
		ip = 0,
		/* control message protocol */
		icmp = 1,
		/* group management protocol */
		igmp = 2,
		/* gateway^2 (deprecated) */
		ggp = 3,
		/* tcp */
		tcp = 6,
		/* pup */
		pup = 12,
		/* user datagram protocol */
		udp = 17,
		/* xns idp */
		idp = 22,
		/* UNOFFICIAL net disk proto */
		nd = 77,
		/* raw IP packet */
		raw = 255
	};

source_port_range и destination_port_range – диапазоны портов, с ними все понятно

string_match: ASCII строка для поиска в пакете

action: допустимые значения accept и drop

[Vadim Smirnov]

Хорошо, спасибо. Я уже частично набросал формат правил навроде упрощенного IPTABLES в JSON формате, чтобы можно было загрузить массив правил из файла. Если будет время, то может закончу до выходных, сам фильтр на готовых правилах сделать несложно.

[Vadim Smirnov]

В правиле ‘76561198923445525’ это ASCII строка в теле пакета?

[Vadim Smirnov]

Я начал потихоньку накидывать прототип, постараюсь сделать что-то несложное, но расширяемое. Как будет что-то рабочее – напишу в этой ветке.

[Vadim Smirnov]

В принципе ничего сложного, надо только подумать как сделать что-то более-менее универсальное и при этом не слишком сложное. Писать парсер для IPTABLES как-то не хочется, наверное проще будет определить собственные правила в JSON формате. Поразмыслю на досуге над спецификацией…

[Vadim Smirnov]

Каждый пакет в стриме содержит строку ID?

Если GUI не принципиален, то наверное могу набросать пример, может еще кому-нибудь будет полезно… ID можно из INI файла подтянуть или в командную строку передать, интерфейс рисовать для такой аппликухи лишняя морока…

[Vadim Smirnov]

В принципе ничего сложного, в этом примере решается почти подобная задача. Я бы еще добавил фильтр для диапазона портов, чтобы не гонять через user space весь трафик.

Нужна помощь с конкретным кодом?

[Vadim Smirnov]

Bill,

I don’t know if there is way to pass Windows host traffic through the WSL2 IPTABLES. I’d say that this could be a subject for serious research.

However, you still have two possibilities:

• Use WinpkFilter to intercept traffic for the desired connections (select by tcp/udp ports using built-in filters), adjust TTL/HOP according the settings, recalculate packets checksum and re-inject these packets back into the network stack.
• Develop a specialized WFP or LWF driver doing the same directly in the Windows kernel.

Second approach is preferred from the performance point of view (passing packets through the user space has its cost), however more expensive in development and support.

[Author]

Posts