[Vadim Smirnov]

We have managed to find a workaround for LHMON problem with F-Secure by hooking TCPIP dispatcher table just before F-Secure driver. The solution is not ideal because any other similar TDI filter may break this balance but this is still better than nothing. The Local Network Monitor was updated on the web site to version 2.2.4.

[Vadim Smirnov]

I don’t think that NeT Firewall may affect MySQL start (firewall works on the packet level and does not directly affect socket creation), probably this is something else. If you suspect NeT Firewall try to remove it and see if MySQL starts. Alternatively you can also select to unload rules on the exit in the options and shutdown the console. Or even just put all interfaces to Low Security and remove all rules. This disables any packet filtering.

However, As I have mentioned NeT Firewall can’t affect MySQL start, it can only block external access to ports used by MySQL.

[Vadim Smirnov]

F-Secure package contains a driver named fsndis5.sys which is TDI filter + NDIS filter + … in one module. TDI filter part is implemented by patching TCPIP.SYS dispatcher table method. Since this driver is loaded before TCPIP.SYS it applies its patch when it detects the first access attempt to DeviceTcp. However, unlike most filter drivers which patch this table only once, fsndis5.sys checks if anyone patches the TCPIP.SYS dispatcher table after him and re-patches it so that fsndis5.sys is always on the top of the stack. But the re-patching implementation is buggy and this bug reveals if another TDI filter driver based on patching dispatcher table is present. An example, when LNM (Local Network Monitor) driver is loaded it gets the fsndis5.sys installed hooks from the TCPIP.SYS dispatcher table, saves them as original handlers and modifies dispatcher table. So far so good, LNM driver gets the request first, processes it, and then passes to fsndis5.sys which after its own processing passes the request to TCPIP.SYS. However, after short amount of time fsndis5.sys detects that handlers in the TCPIP.SYS dispatcher table have changed and patches this table again BUT it saves LNM driver handlers as original (it already has the correct handlers after previous patch, but for some reason prefers to take the incorrect ones). After this any request directed to DeviceTcp first comes to fsndis5.sys, which after processing passes it to LNM driver, which also after processing passes the request to fsndis5.sys which again calls LNM driver and so on until stack overflow.

Same crash scenario can be also reproduced with TDIMon (from Mark Russinovich).

If fsndis5.sys would not take the new modified (LNM driver) handlers from TCPIP.SYS dispatcher table it could just exclude LNM driver from the stack and keep system stable. However, in general the re-patching approach in F-Secure driver is not compatible with any other TDI filter based on patching the dispatcher table.

[Vadim Smirnov]

Once the connection is established you can query the IP it was done from, but NOT before.

[Vadim Smirnov]

TDI_QUERY_INFORMATION allows getting both IP address and port. Refer the structures below in the DDK docs or MSDN.

typedef struct _TA_ADDRESS {

USHORT  AddressLength;

USHORT  AddressType;

UCHAR   Address[1];

} TA_ADDRESS, *PTA_ADDRESS;



typedef struct _TA_ADDRESS_IP {

LONG  TAAddressCount;

struct  _AddrIp {

USHORT          AddressLength;

USHORT          AddressType;

TDI_ADDRESS_IP  Address[1];

} Address [1];

} TA_IP_ADDRESS, *PTA_IP_ADDRESS;



typedef struct _TDI_ADDRESS_IP {

USHORT  sin_port;

ULONG  in_addr;

UCHAR  sin_zero[8];

} TDI_ADDRESS_IP, *PTDI_ADDRESS_IP; 

[Vadim Smirnov]

please,what’is the time for release the new version.

I admit the 3.0.4 release was delayed several times already. However, this was done for the reason. Actually current 3.0.4 beta is already used by some customers and we are trying to take into the account their comments and suggestions. Once this process is completed (I hope it is already but better wait for the latest test reports) the new version will be available for public.

If you are a licensed customer you also can participate in WinpkFilter beta.

[Vadim Smirnov]

Is it possible to get the same functionality (NAT redirect) as IPTables?

It is possible to create NAT solution on top of WinpkFilter. An example, Internet Gateway http://www.ntkernel.com/w&p.php?id=31 is a simple NAT implementation based on WinpkFilter library.

[Vadim Smirnov]

TDI нужен только для контроля приложений, так что в TDI фильтре имеет смысл проверять можно ли приложению работать с сетью или нет (в расширенном варианте можно так же проверять на какой адрес приложение хочет создать соединение), а пакетную фильтрацию по IP/интерфейсу лучше организовывать на NDIS’е.

[Vadim Smirnov]

I believe that storing of packet information in the winpkfilter framework is unlikely as not releasing packet (as in passthru) is not informed back to the framework (like drop indication).

You are right, WinpkFilter does not keep any references to the packet passed to you for the processing. In general your approach to making packet queues is ok.

[Vadim Smirnov]

SendFlagTcpPacketToTcp(Lastpacket,Flag,fromip,toip,from port,toport);

It would also need SEQ and ACK. Basically you can write such a function using the existing API completely in user mode.

by the way,how to get the IFS HOOK like winpktilter(NDIS HOOK)?

Create an IFS filter driver. There is a static IFS filter sample in the IFS kit (or in the latest WDK) names sfilter and dynamic IFS filter driver authored by Mark Russinovich used in Filemon. The source code for the last one was floating over the Internet, not the latest version but still.

[Vadim Smirnov]

hope more fast~~~~~~

It is ready but due to the reasonable amount of changes/extensions still needs more testing.

deny ip in the ring0

Yes, this is possible in 3.0.4

send rst packet by one sub~~~

Adding such a specific API would be an overhead because requires knowledge of current connection status (tracking all TCP sessions just to be able to send RST will affect perfomance), it is not a great problem to form RST packet in your code and then send it using WinpkFilter API if you need such functionality.

[Vadim Smirnov]

Баг? Или я что-то не понял?

Баг – громко сказано, никаких серьезных негативных последствий тут нет. Однако, с точки зрения производительности, ресетить event лучше после вычитывания пакетов из драйвера.

ЗЫ Надо будет поправить, чтобы вопросов не возникало…

[Vadim Smirnov]

Интересно, как именно происходит проверка состояния очереди?
Может есть какой то отдельный поток, который в цикле просматривает состояние очереди, и если она не пуста – сигнализирует в режим юзера?

Когда драйвер перехватывает пакет, он его ставит в очередь и выставляет событие сигнализирующее, что очередь не пуста. User-mode поток ожидающий (WaitForSingleObject/WaitForMultipleObjects) на этом событии пробуждается ото сна и читает пакеты из очереди пока они не закончатся, затем ресетит событие и снова ждет на нем. В общем-то, пример passthru показывает как это делается.

Альтернатива – polling пакетов без использования событий (пробуем читать пакет, если чтение успешно, то вычитываем все пакеты пока не кончаться, если чтение неуспешно – засыпаем на какое-то время, пример packetsniffer), но на мой взгляд этот метод менее эффективен.

[Vadim Smirnov]

Смотря что понимать под loopback пакетами. В контексте WinpkFilter под loopback пакетами понимаются пакеты, которые были посланы на реальный сетевой интерфейс и затем показаны (вызваны receive обработчики) локальным протоколам. Благодарая этому механизму, в частности, могут работать сетевые снифферы реализованные в форме протоколов, как например winpcap. Без этого механизма winpcap не смог бы увидеть пакеты уходящие в сеть от TCP/IP.

Совсем другая история с пакетами отправленными на локальные сетевые интерфейсы (на свой собственный адрес) или на localhost (127.XXX.XXX.XXX). Эти пакеты собсвенно никогда не доходят до NDIS, а обрабатываются внутри TCP/IP стека, так что увидеть их с помощью WinpkFilter не удасться. Они собсвенно и не принимают зачастую привычную форму сетевых пакетов. Однако сами данные перехватить действительно можно анпример при помощи TDI фильтра:

http://www.ntkernel.com/w&p.php?id=24
http://www.ntkernel.com/w&p.php?id=8

[Vadim Smirnov]

But what may happen in case a packet is twisted in a way ? For example wrong packet length or something like that. Can a twisted packet cause BSOD, for example ? (It is rather DPI than SPI I think).

WinpkFilter driver checks validity of buffers supplied by user, but it does not take care about the packet content. So you can send absolutely anything if modules below and above WinpkFilter accept this.

[Author]

Posts