Forum Replies Created
-
Posts
-
>Q. Has the Net Firewall been thoroughly tested on W2K Advanced Server?
Yes, it was. However, I should note that even thorough testing can’t cover all possible hardware/software configurations. It was even specially tested during 12 hours under heavy network load (using WAPT) trying to reproduce the problem you had. Regretfully with no result.
>Q. Is Net Firewall still in beta, and if so is the development of the application being aggressively pursued, or is it >considered a “stable version”? I am running version 2.2.1, which has the updated password protection.
It is stable and I have it running constantly on the few my own systems without having any problems like you described.
>Q. I am running F-Prot Anti Virus, a virus scanning agent, that I have been able to successfully employ as the agent >engine for Imail Server 8.1, has the software been tested running with F-Prot, although this is a not a packet filtering >application, and should not effect Net Firewall.
It’s hardly possible to test any product with all software available worldwide. One question, had you ever install other firewalls? If yes, are you sure that they were completely uninstalled? Some of firewalls forget or fail to remove their kernel components what can be followed by a certain conflicts.
>Q. The only other means of Internet security I employ is TCP/IP filtering, does this have any effect on the stability or >is it a possibility that employing TCP/IP filtering can create this problem?
NeT Firewall has not any known problems with MS native TCP/IP filtering, so it’s not an issue.
We are still trying to reproduce the problem you have, if you can provide more details about your system (hardware/software configuration, HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServices export and etc..) we would appreciate it.
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…
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).
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;
}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 🙄 😉
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.
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…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.
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…
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.
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…
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…
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.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.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…
