[Vadim Smirnov]

In this context above the layer is the driver level abstraction associated with FILE_OBJECT (CNdisApi object) with independent static filters table, packets queue and etc..

Using different layers for each application, both of them cannot intercept the same packet?

They can if packet was not previously dropped by upper (for outgoing packets) or lower (for incoming packets) layers.

Layers architecture allows to share single driver between several different packet filter applications.

[Vadim Smirnov]

Standard driver build supports only one packet filter table and is supposed to be used from one user mode process. You can use multiply CNdisApi instances but setting the new filter table will override the previously loaded one. So you are supposed to collect all required filters into the single table.

However, there is also a multiply layers driver build available to winpkfilter customers which supports multiply packet filter tables (one per filter layer) which can be used from several application as long as they use different layers.

[Vadim Smirnov]

What do you mean “is not working”?

If the table you load into the driver is equivalent to the following:

// 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_REDIRECT;
pFilters->m_StaticFilters[0].m_dwDirectionFlags = PACKET_FLAG_ON_SEND;

// 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_TCP;

pFilters->m_StaticFilters[1].m_Adapter.QuadPart = 0; // applied to all adapters
pFilters->m_StaticFilters[1].m_ValidFields = 0;
pFilters->m_StaticFilters[1].m_FilterAction = FILTER_PACKET_PASS;
pFilters->m_StaticFilters[1].m_dwDirectionFlags = PACKET_FLAG_ON_SEND;

Then it should redirect outgoing TCP packets into the user mode, pass any other outgoing packets (except TCP) over and redirect ALL incoming packets into the user mode.

[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 формате. Поразмыслю на досуге над спецификацией…

[Author]

Posts