[Vadim Smirnov]

1. What happen to the packets, which are received while I am reading from the queue? And if they are added to the queue, what happens to them when I purge the queue?

These packets are added to the queue until free intermediate buffers are avalaible, after this new packets are dropped. If you call FlushAdapterPacketQueue then all queued packets for the given adapter are deleted from the queue and associated resources are released.

2. I have posted my code also. Can somebody point out if there is anything I am doing wrong. I required I can post the fill source code?

Hmm, I would advise to remove all “printf” output from the packet processing code because it has a serious perfomance impact. Also, if your system is loadad with something else during packet processing I would recommend to increase packet processing code priority. If all above won’t improve the situation then I recommend to profile whole your application with one of the profilers available on the market (COmpuware TrueTime an example). If achieved perfomance is not enough yet, then the only thing to do is moving all your code into the kernel (direct integration into the WinpkFilter drivers).

3. Is it possible to achive what I mentioned in the scenario using winpkfilter at all? Or is there some other way I can achive this using winpkfilter or some other tool/library ?

Yes, everything described can be realized using WinpkFilter. Your scenario is not unique. I’ve been working about similar solutions before. Btw, since you process only outgoing packet in the code you have provided, then what flooding do you mean? Do you run some sort of local traffic generator (UDP sender or something)? If yes, then please take into account that this application also decrease overall perfomance of your filter, because it also neeeds processor time.

4. Am I doing too much processing while reading from the queue? I tested it on a pc which was doing lot of netbios flooding. It was stopping that, but it was not sending the valid packets to my gateway (ping to gateway).

I don’t think the code below does too much processing.

Hope it helps…

[Vadim Smirnov]

TDI filter (filter driver for the MSTCP devices DeviceTcp, DeviceUdp, DeviceIp, DeviceRawIp, DeviceMULTICAST) detects the network operation running in the context of calling thread/process. The same is true for the LSP DLL (another weaker approach for application level firewalls).

[Vadim Smirnov]

An example, it can be done like in the code below (I’m sorry C code only)

TCP_AdapterList		AdList;

CNdisApi			api;

ETH_REQUEST			Request;

INTERMEDIATE_BUFFER PacketBuffer;

HANDLE				hEvent[32];

DWORD				dwAdapterCount;



int InitHandles()

{

api.GetTcpipBoundAdaptersInfo ( &AdList );



ADAPTER_MODE Mode;



Mode.dwFlags = MSTCP_FLAG_SENT_TUNNEL|MSTCP_FLAG_RECV_TUNNEL;



dwAdapterCount	=	AdList.m_nAdapterCount ;



// Create notification events

for(int nCount = 0; nCount < dwAdapterCount; nCount++)

{

hEvent[nCount] = CreateEvent(NULL, TRUE, FALSE, NULL);



Mode.hAdapterHandle = (HANDLE)AdList.m_nAdapterHandle[nCount];



// Set event for helper driver

if ((!hEvent[nCount])||(!api.SetPacketEvent((HANDLE)AdList.m_nAdapterHandle[nCount], hEvent[nCount])))

{

printf ("Failed to create notification event or set it for driver.n");

return 0;

}



api.SetAdapterMode(&Mode);

}



return 1;

}



void ReleaseHandles()

{

// This function releases packets in the adapter queue and stops listening the interface

ADAPTER_MODE Mode;



for(int nCount = 0; nCount < dwAdapterCount; nCount++)

{

Mode.dwFlags = 0;

Mode.hAdapterHandle = (HANDLE)AdList.m_nAdapterHandle[nCount];



// Set NULL event to release previously set event object

api.SetPacketEvent(AdList.m_nAdapterHandle[nCount], NULL);



// Close Event

if (hEvent[nCount])

CloseHandle ( hEvent[nCount+1] );



// Set default adapter mode

api.SetAdapterMode(&Mode);



// Empty adapter packets queue

api.FlushAdapterPacketQueue (AdList.m_nAdapterHandle[nCount]);

}



}



int main(int argc, char* argv[])

{

ether_header*			pEthHeader = NULL;

iphdr*				pIpHeader = NULL;

DWORD				dwEvent;



.............



if(!api.IsDriverLoaded())

{

printf ("Driver not installed on this system of failed to load.n");

return 0;

}



InitHandles();



atexit (ReleaseHandles);





while (TRUE)

{

dwEvent = WaitForMultipleObjects (dwAdapterCount, hEvent, FALSE, INFINITE );



ResetEvent(hEvent[dwEvent]);



// Initialize Request

ZeroMemory ( &Request, sizeof(ETH_REQUEST) );

ZeroMemory ( &PacketBuffer, sizeof(INTERMEDIATE_BUFFER) );

Request.EthPacket.Buffer = &PacketBuffer;

Request.hAdapterHandle = (HANDLE)AdList.m_nAdapterHandle[dwEvent-1];





while(api.ReadPacket(&Request))

{



pEthHeader = (ether_header*)PacketBuffer.m_IBuffer;

pIpHeader = (iphdr*)(PacketBuffer.m_IBuffer + ETHER_HEADER_LENGTH);



if (PacketBuffer.m_dwDeviceFlags == PACKET_FLAG_ON_SEND)

{

// Place packet on the network interface

api.SendPacketToAdapter(&Request);

}

else

{

// Indicate packet to MSTCP

api.SendPacketToMstcp(&Request);

}







}



}



return 0;

}

[Vadim Smirnov]

I have always used system wide dll inject, but is there really any reason to do it when you have such privilleges on the machine? I see that things can be done easier by hijacking APIs in Kernel-Mode. (i’m still a n00b in that matter)

It’s a great luck for us that the majority of malware authors are not familier with kernel mode programming. Otherwise, numerous kernel-mode trojans… Terrific… 😯

AV companies prognose such a future, but I always hope for the better 🙄 😉

[Vadim Smirnov]

With WinpkFilter you can capture packets from any amount of adapters (using dedicated for each with WaitForSingleObject, or using single thread for all adapters with WaitForMultiplyObjects).

Another question is how to determine wich adapters are of your interest (connected to the Internet). There is no universal way to do it. If default Internet connection can be determined as the default route (0.0.0.0 mask 0.0.0.0) then other Internet connections look similar to LAN connections.

[Vadim Smirnov]

You can do about anything if the malware includes kernel-mode component. The majority of users are usually logged on as user with Administrator rights which has the priviledge to install and load drivers. So there is no actual problem for the malware to install such a component (it can be even the primary component of the malware).

Since such kernel-mode component can bypass firewall by many different ways, such as:

1) Execution in the context of priviledged process (even simply create thread in the context of System process),.
2) Blocking/cheating firewall components.
3) Using it’s own protocol module and working with network directly.
4) Working with TCPIP.SYS devices directly bypassing any possible upper level TDI filters.
5) and so on…

[Vadim Smirnov]

I am very curious how does popular personal firewall like ZoneAlarm work. When they discover outgoing packets, how do they know what program is sending them?

Usually they utilize NDIS level filter and TDI one.

Do all such firewalls work similarily?

From the general point of view the answer is YES, but concrete realization and set of features can be very different.

I was thinking if any malware application could fake returned command line so the firewall would think it’s the other process. Is it possible?

Yes, this is possible.

[Vadim Smirnov]

Hmm, it is difficult to say what actually happens because I don’t know how you’ve created the code for the DLL. The original sample (console application) had not such problems, so probably it is somehow relative to moving the code into the DLL…

[Vadim Smirnov]

Uninstall process should remove all NeT Firewall components; however I don’t exclude the collision. Please check the registry key below, if it exists then just remove it and reboot (this is kernel component registry key). If it is not then probably your problems are caused by something else.

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesipfrwl

Hope it helps…

P.S. I would be gratefull if you could explain the problems you’d expirienced with NeT Firewall.

[Vadim Smirnov]

Hi,

I have it running on the web server (Windows Server 2003 Web Edition) for about 3 months (up to this day) without reboot. So probably it should fit your requirements…

[Vadim Smirnov]

Etherbridge is an expiremental driver and it was not updated for a long time. In some configurations it works, but in others don’t. In your case driver looks to overload system with packets duplications…

[Vadim Smirnov]

There is no proof and easy way to get full process path. This topic was discussed (in russian) in Windows Internals forum. Two ways were proposed (first is easier but second is more reliable):

I)
ZwQueryInformationProcess ( NtCurrentProcess(), ProcessBasicInformation, &ProcInfo, sizeof(ProcInfo), 0);

ProcInfo.PebBaseAddress->ProcessParameters->ApplicationName

II)
1. Get EPROCESS using IoGetCurrentProcess().
2. For NT 4.0 and 5.0 get SectionHandle using ObReferenceObjectByHandle() get SectionObject; for NT 5.1 just get SectionObject from EPROCESS.
3. From SectionObject get SegmentObject.
4. From SegmentObject get ControlArea.
5. From ControlArea get FilePointer (FileObjec pointert).
6. Using ObQueryNameString() get full path for the process.

[Vadim Smirnov]

This value is filled using KeQuerySystemTime (equal to user-mode NtQuerySystemTime). Here is the short description:

“System time is a count of 100-nanosecond intervals since January 1, 1601. System time is typically updated approximately every ten milliseconds. This value is computed for the GMT time zone.” (Windows DDK help)

In order to convert the m_SystemTime to SYSTEMTIME structure do the following:

1) Copy m_SystemTime to FILETIME structure (don’t use simple typecast, because alignment can be different).
2) Call FileTimeToSystemTime.

[Vadim Smirnov]

If you control DeviceTcp, DeviceUdp, DeviceIp, DeviceRawIp and DeviceMULTICAST then you have complete control over application’s (IE, ICQ, Outlook and etc…) access to the MS TCP/IP network stack. Under control I mean ability to block any network activity (create socket, listen port, connect remote host and et…). Is that your question?

But this does not mean that you control all network activity of the system, because it may have another network protocols installed (IPv6 an example). But even without installing additional protocols, control over TDI is not the same as control over network. If you try to block the network with your TDI filter then MS TCP/IP still continue packet routing, it still replies ICMP ping, network file and folder sharing still works and etc… This is because mentioned network activities never reach TDI level.

I hope I’ve answered your question…

[Vadim Smirnov]

I don’t understand what actually you mean under “control control the network of the system”. Please clarify if you need the correct answer…

[Author]

Posts