Forum Replies Created
-
Posts
-
Transparent local proxy? If you can’t intercept application network activity on the TDI level then probably mentioned antiviruses use Layered Service Provider (LSP) to redirect the connection to the local proxy and thus it does reach TDI only from the name of local proxy, not in the context of the calling application. If this is really so you have to create your own LSP and layer it just above AV LSP to get connection first.
The problem is some routers have been configure to block most protocols except TCP taffic.
In this case you may want to tunnel packets inside the SSL stream over TCP. An example, this method is used in http://www.projectloki.com VPN solution.
I do realize that using a common protocol like IPSEC may get me through the router, but it may confuse traffic as well. My encryption solution is disruptive and does not fall into the normal encryption schema.
Why not to use GRE tunneling then? Routers usually pass GRE and even may NAT if you use extended GRE header.
Why do you want to add/change IP options? If you want to add extra encryption related information to the packet there are other possibilities.
First of all I would recommend to use one of the known protocols to tunnel encrypted packets. There are several options and all of them will be successfully processed by routers:
1) IPSEC ESP protocol
2) GRE
3) IP-in-IP
4) IP-in-UDPAs an example you can look at the GRETunnel sample from WinpkFilter samples set. It does not actually encrypt the tunneled packet but it is fairly simple to add encryption. If you need to have an extra information attached to the packet you can also use extended GRE.
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?
