Forum Replies Created
-
Posts
-
WinpkFilter hooking driver does not work with IPv6 and IPsec?
WinpkFilter hooking driver intercepts only TCPIP.SYS (IPv4) and ignores other protocols (it can be changed if needed). As soon as IPv6 is available only since Wndows XP I don’t see a problem to use NDIS IM driver instead NDIS hooking one for Windows XP and higher.
As for IPSec, as I have already told that depends from implementation, if WinpkFilter is above IPSec you will capture unencrypted packets and you will capture encrypted ones otherwise.
WinpkFilter NDIS IM driver is suitable for filtering IPv6. As for IPSec, it is actually depends from the particular implementation (WinpkFilter driver can be installed below or above IPsec driver).
i mean “IP header compression”–> RFC 2507(ftp://ftp.isi.edu/in-notes/rfc2507.txt)
If here you mean to use Windows built-in IP header compression for dial-up links then I think it is implemented below the WinpkFilter (inside of NDISWAN.SYS), so it should not interfere with the changes you do to the packet and its IP header.
What do you actually mean under “IP header compression”? RFC 2507(ftp://ftp.isi.edu/in-notes/rfc2507.txt)? Or some sort of your custom protocol compression?
For the majority of Internet users it is enough to use one the Stealth modes to be fully protected from external attacks. TCP stateful inspection is mostly important for server systems.
You can modify the packet directly without making a copy. However, don’t forget to recalculate checksums before reinjecting the modified packet. Also, if you change TCP data length you have to change TCP header SEQ value.
NDIS_PACKET_TYPE_DIRECTED limits packets received to only packets having the destination MAC address equal to local system MAC address. You have also to allow broadcast packets to let the system function normally:
NDIS_PACKET_TYPE.NDIS_PACKET_TYPE_DIRECTED | NDIS_PACKET_TYPE.NDIS_PACKET_TYPE_BROADCAST
I have performed some experiments with wireless network adapter on Windows XP SP3 having Norton Internet Security installed. I can confirm that after installation of WinpkFilter NDIS IM driver wireless connectivity is lost. But it is restored after reboot. Sometimes network stack can’t be rebound dynamically and after installation of NDIS IM driver you may have to reboot. This probably the case your users have met with WinpkFilter (both reported cases had Symantec software installed).
We have received few complains on WinpkFilter conflict with KIS 2008/2009, however we were not able to reproduce (it looks it happens only on small amount of systems) and thus can’t understand and fix this problem so far.
It looks that the “lock up” you have expirienced depends from hardware configuration (installed hardware drivers) or some third software component in addition to KIS and WinpkFilter. Could you please post or e-mail to support(at)ntkernel.com the details of the software/hardware configuration?
NDIS IM driver is a standard Windows driver and by design it has a less chance of the software conflict with other third-party applications than NDIS hooking driver. Your case looks like a software conflict.
Install Kaspersky Internet Security 7.0.0.125 d.f
We have tested the suggested configuration with Kaspersky Internet Security 7.0.1.325 (the latest one available from the official web site) and have not figured out any problems. May be the problem was specific to 7.0.0.125 and fixed in the current version.
Could you try to reproduce it after updating KIS to 7.0.1.325?
Could you try to completely uninstall Symantec software and check if problem with WinpkFilter disappear? This would help to identify the problem.
You still have not replied if you are using the latest WinpkFilter or ealier builds.
Try to e-mail us the list of installed drivers/softwares, this may sched some light.
How can I detect network interface’s status changes? And also enable/disable interface with winpk framework? Is there any details for delphi or c++?
http://www.ntkernel.com/wpfk-help/setadapterlistchangeevent.htm
As a second question, can I extract tcp packets from the SSL stream with winpk?
If this is about HTTPS then by port number 443. If another port used you can try to identify the connection, an example, by SSL certificate sent by server.
