When I send a custom packet using packet builder, the firewall can see it and block it using network rules but there is no way to see it in the applications rules... Like if the app doesn't exist... Any idea why?? Thanks Alex
I'm not sure I understand what you're saying. Are you sending an inbound packet from outside or is it an outbound from your PC?
outbound from my pc using a packet builder... Look 'n' stop sees the packet but doesn't see the application..
What is your packet builder ? How does it send packets exactly ? The application filtering is a TDI filter. If your packet builder doesn't use the TDI interface, then the application filtering will not detect it. Usually, this can only be done by installing some additional protocol drivers, and normally if you enable the protocol detection in the Advanced options, Look 'n' Stop should detect it. Regards, Frederic
Well, I was trying the colasoft packet builder to see if it was any good It must use a driver as you said... I haven't looked... Ad I'm not at home now so... As for TDI... I think I would need to read about the networking stack of windows because I don't need what it is... Do you know good links of books? Thanks Alex
Sorry, I don't have any book or links in hands, you have to search in Microsoft MSDN documentation for more details, or simply use your favorite search engine. Frederic
The application filtering is a TDI filter. If your packet builder doesn't use the TDI interface, then the application filtering will not detect it. Usually, this can only be done by installing some additional protocol drivers, and normally if you enable the protocol detection in the Advanced options, Look 'n' Stop should detect it. I made the test, and look n stop can't detect any kind of other protocol or driver... So this doesn't explain to me how the packet builder bypass this... I would love to have an explanation but the folks at colasoft are just replying with a dumb reply that dosen't explain it at all...
If Look 'n' Stop doesn't detects it by default, you need to use a registry tweak to increase the level of detection. In [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lnsfw] create a "MaxProtocolFrames" DWORD value and set it to 12. If lnsfw doesn't exist, you also need to create it. A reboot is required to have this change taking effect. This is a very advanced option, that's why it's only available through the registry. Frederic
Hi Frederic, On a XP sp3 setup:- I created that key to check results. With a value of 12(hex) outbound UDP DNS was blocked by Protocol, on a value of 12(decimal) a lot of HTTP traffic (legitimate) inbound/outbound was blocked by Protocol. (Not a good result) It does bring up a question. Are you stating that there are certain frames not detected by default that will bypass the firewall? Does the "block all" rule not indeed block all packets/frames not explicitly allowed? - Stem
The firewall will see the packets in question with the NDIS filter. But the app rules and the protocol filter can't...
Hi Stem, Yes, extra protocols could be detected after you modify this option (for instance Wanarp.sys), and you need to allow them in the protocol configuration dialog box, if they are finally legitimate. I would be interested to know which protocol drivers were detected in your case. No this is not what I'm stating. In the option name, "frame" doesn't refer to packets but to the depth of an internal algorithm. In any case, all packets are checked by the ruleset (packet filter). The protocol detection is just an additional check to verify from which protocol (or driver) the packet is sent. Regards, Frederic
Yes, but when a special protocol driver is used (like for PacketBuilder) it is most of the time associated with its own specific application, and at the end detecting the protocol or the application is the same. Blocking the protocol will block any application using that protocol. Frederic
Hi Frederic, Currently L`n`S is filtering an onboard nVidia nforce network controller. AFD.sys NVENETFD.sys OK, thanks. Regards, - Steve