Forum Replies Created
-
AuthorPosts
-
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?
August 5, 2008 at 7:54 am in reply to: WinpkFilter Driver v3.0.4 Incompatability Issue On Vista #6662NDIS 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.
August 3, 2008 at 12:21 pm in reply to: New event to be signaled on network interfaces configuration #6661How 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.
We are not aware about any problems with wireless adapters and WinpkFilter. However, please ensure that you are using the latest version of WinpkFilter.
Driver conflict with some other network software is possible and most usual problem of misbehave, details depend from what other third party low level network software you have installed on those systems.
I’d recommend to sign both CAT file and driver image.
INetCfg provides programming interface for network components management.
You can uncheck WinpkFilter Service checkbox in the connection properties to disable it (by default the service is not hidden, but in can be hidden in the custom builds).
pIPHeader.DestIp := htonl(NewDestIP.S_addr);
Don’t do this, you already have IP address in the correct byte order.
I had not sad that this is easy, but there is no other way to track the module which actually called the system service.
Luckily for the actual winsock calls the stack is easy to restore (number and types of parameters are known) up to the calling module.
Ну это то как раз очень даже понятно, адрес/порт источника/назначения зависят от направления пакета. Можно было бы сделать более сложные правила (в том числе двунаправленные), но чем проще тем быстрее работает, да и в любом случае сложное правило можно записать как композицию простых.
Ну как-то вот так:
//**************************************************************************************
// 1. Outgoing HTTP requests filter: PASS OUT TCP packets with destination IP 64.251.25.36 PORT 80 (http://www.ntkernel.com)
// Common values
pFilters->m_StaticFilters[0].m_Adapter.QuadPart = 0; // applied to all adapters
pFilters->m_StaticFilters[0].m_ValidFields = NETWORK_LAYER_VALID | TRANSPORT_LAYER_VALID;
pFilters->m_StaticFilters[0].m_FilterAction = FILTER_PACKET_PASS;
pFilters->m_StaticFilters[0].m_dwDirectionFlags = PACKET_FLAG_ON_SEND;
// Network layer filter
in_addr address;
in_addr mask;
// IP address 64.251.25.36
address.S_un.S_un_b.s_b1 = 64;
address.S_un.S_un_b.s_b2 = 251;
address.S_un.S_un_b.s_b3 = 25;
address.S_un.S_un_b.s_b4 = 36;
// Network mask 255.255.255.255
mask.S_un.S_un_b.s_b1 = 255;
mask.S_un.S_un_b.s_b2 = 255;
mask.S_un.S_un_b.s_b3 = 255;
mask.S_un.S_un_b.s_b4 = 255;
pFilters->m_StaticFilters[0].m_NetworkFilter.m_dwUnionSelector = IPV4;
pFilters->m_StaticFilters[0].m_NetworkFilter.m_IPv4.m_ValidFields = IP_V4_FILTER_PROTOCOL | IP_V4_FILTER_DEST_ADDRESS;
pFilters->m_StaticFilters[0].m_NetworkFilter.m_IPv4.m_DestAddress.m_AddressType = IP_SUBNET_V4_TYPE;
pFilters->m_StaticFilters[0].m_NetworkFilter.m_IPv4.m_DestAddress.m_IpSubnet.m_Ip = address.S_un.S_addr; // IP address
pFilters->m_StaticFilters[0].m_NetworkFilter.m_IPv4.m_DestAddress.m_IpSubnet.m_IpMask = mask.S_un.S_addr; // network mask
pFilters->m_StaticFilters[0].m_NetworkFilter.m_IPv4.m_Protocol = IPPROTO_TCP;
// Transport layer filter
pFilters->m_StaticFilters[0].m_TransportFilter.m_dwUnionSelector = TCPUDP;
pFilters->m_StaticFilters[0].m_TransportFilter.m_TcpUdp.m_ValidFields = TCPUDP_DEST_PORT;
pFilters->m_StaticFilters[0].m_TransportFilter.m_TcpUdp.m_DestPort.m_StartRange = 80; // HTTP
pFilters->m_StaticFilters[0].m_TransportFilter.m_TcpUdp.m_DestPort.m_EndRange = 80;
//******************************************************************************************
// 2. Incoming HTTP responses filter: PASS IN TCP packets with source IP 64.251.25.36 PORT 80 (http://www.ntkernel.com)
// Common values
pFilters->m_StaticFilters[1].m_Adapter.QuadPart = 0; // applied to all adapters
pFilters->m_StaticFilters[1].m_ValidFields = NETWORK_LAYER_VALID | TRANSPORT_LAYER_VALID;
pFilters->m_StaticFilters[1].m_FilterAction = FILTER_PACKET_PASS;
pFilters->m_StaticFilters[1].m_dwDirectionFlags = PACKET_FLAG_ON_RECEIVE;
pFilters->m_StaticFilters[1].m_NetworkFilter.m_dwUnionSelector = IPV4;
pFilters->m_StaticFilters[1].m_NetworkFilter.m_IPv4.m_ValidFields = IP_V4_FILTER_PROTOCOL | IP_V4_FILTER_SRC_ADDRESS;
pFilters->m_StaticFilters[1].m_NetworkFilter.m_IPv4.m_SrcAddress.m_AddressType = IP_SUBNET_V4_TYPE;
pFilters->m_StaticFilters[1].m_NetworkFilter.m_IPv4.m_SrcAddress.m_IpSubnet.m_Ip = address.S_un.S_addr; // IP address
pFilters->m_StaticFilters[1].m_NetworkFilter.m_IPv4.m_SrcAddress.m_IpSubnet.m_IpMask = mask.S_un.S_addr; // network mask
pFilters->m_StaticFilters[1].m_NetworkFilter.m_IPv4.m_Protocol = IPPROTO_TCP;
// Transport layer filter
pFilters->m_StaticFilters[1].m_TransportFilter.m_dwUnionSelector = TCPUDP;
pFilters->m_StaticFilters[1].m_TransportFilter.m_TcpUdp.m_ValidFields = TCPUDP_SRC_PORT;
pFilters->m_StaticFilters[1].m_TransportFilter.m_TcpUdp.m_SourcePort.m_StartRange = 80; // HTTP
pFilters->m_StaticFilters[1].m_TransportFilter.m_TcpUdp.m_SourcePort.m_EndRange = 80;
//***************************************************************************************
// 3. Drop all packets (skipped by previous filters) without processing in user mode
// Common values
pFilters->m_StaticFilters[2].m_Adapter.QuadPart = 0; // applied to all adapters
pFilters->m_StaticFilters[2].m_ValidFields = 0;
pFilters->m_StaticFilters[2].m_FilterAction = FILTER_PACKET_DROP;
pFilters->m_StaticFilters[2].m_dwDirectionFlags = PACKET_FLAG_ON_RECEIVE | PACKET_FLAG_ON_SEND;
Правда, при таком наборе фильтров, к ntkernel.com можно будет достучаться только по адресу http://64.251.25.36, потому что DNS пакеты буду блокироваться. Для того чтобы работала DNS нужно добавить правило разрешающее DNS пакеты. Роутер добавлять необязательно (если конечно он выполняет роль DNS сервера, то можно разрешить к нему полный доступ, и заморачиваться специфическими DNS правилами).
The task is very similar to what debugger does when it shows you the call stack. You can try to search for open source debugging tools. Also debugging relative books should be helpful. Personally I like this one http://www.amazon.com/Advanced-Debugging-Addison-Wesley-Microsoft-Technology/dp/0321374460
-
AuthorPosts
