Forum Replies Created
-
AuthorPosts
-
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.
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.
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.
Once the connection is established you can query the IP it was done from, but NOT before.
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;November 21, 2007 at 5:16 pm in reply to: what’s the time to release new version for winpkfilter #6482please,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.
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.
TDI нужен только для контроля приложений, так что в TDI фильтре имеет смысл проверять можно ли приложению работать с сетью или нет (в расширенном варианте можно так же проверять на какой адрес приложение хочет создать соединение), а пакетную фильтрацию по IP/интерфейсу лучше организовывать на NDIS’е.
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.
November 9, 2007 at 3:09 pm in reply to: what’s the time to release new version for winpkfilter #6479SendFlagTcpPacketToTcp(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.
November 9, 2007 at 12:18 pm in reply to: what’s the time to release new version for winpkfilter #6477hope 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.
Баг? Или я что-то не понял?
Баг – громко сказано, никаких серьезных негативных последствий тут нет. Однако, с точки зрения производительности, ресетить event лучше после вычитывания пакетов из драйвера.
ЗЫ Надо будет поправить, чтобы вопросов не возникало…
Интересно, как именно происходит проверка состояния очереди?
Может есть какой то отдельный поток, который в цикле просматривает состояние очереди, и если она не пуста – сигнализирует в режим юзера?Когда драйвер перехватывает пакет, он его ставит в очередь и выставляет событие сигнализирующее, что очередь не пуста. User-mode поток ожидающий (WaitForSingleObject/WaitForMultipleObjects) на этом событии пробуждается ото сна и читает пакеты из очереди пока они не закончатся, затем ресетит событие и снова ждет на нем. В общем-то, пример passthru показывает как это делается.
Альтернатива – polling пакетов без использования событий (пробуем читать пакет, если чтение успешно, то вычитываем все пакеты пока не кончаться, если чтение неуспешно – засыпаем на какое-то время, пример packetsniffer), но на мой взгляд этот метод менее эффективен.
Смотря что понимать под 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=8But 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.
-
AuthorPosts