Block All traffic before init tweak not working on Win 7 x64

I noticed that if I logged in quickly after boot (so hard disk is having to work hard loading lots of things), apps were able to connect out without being prompted by LnS (due to LnS not having initialised at that stage). After letting the system settle and LnS init properly, I was prompted.

So, by default, LnS Allows all traffic until it has initialised properly, which is a little worrying.

After searching the forum, I came across a registry tweak which supposedly blocks all traffic until LnS has initialised fully - See here. Unfortunately, this doesn't appear to work on Win 7 x64 SP1.

Has anyone verified this tweak works on Win 7 x64 ?

Been a happy LnS user for a long time but this, along with a similar issue with LnS not blocking for short period on resume from hibernate, has made me think I might need to switch to a different firewall (I have a couple of ideas).

 

What reason do you have to think that it doesn't work on Win7 x64?

 

I'm still running a slowish HDD and if I log in quickly (ie. so the HDD is thrashing a bit having to load lots of things at once), and use a Check for Updates feature of an app that doesn't have a rule created, the Update check is successful WITHOUT LnS prompting. If I let the system settle down a bit and finish loading everything, and retry the Check for Updates in the same app, LnS prompts.

LnS hangs a bit when first starting with a "(Not responding)" in the taskbar button until it manages to load the Rule-set. So it would seem that until the rule-set is loaded, LnS is allowing ALL traffic WITHOUT prompting.

Windows firewall does not suffer from this problem (ie. traffic is blocked unless a rule exists).

 

Your guess to why Look 'n' Stop hangs briefly on a startup is just assumption. Look 'n' Stop GUI does much more than simply load up a set of instructions for packet filtering.

I would even bet that the Look 'n' Stop Application filtering list is what might make things noticeable since it has to draw from all those listed applications and load those associated icons up for the first time this Windows session.

Regarding Updaters. I've seen countless popular software updaters under certain conditions ... like running when no Internet exists and it returns successful OR NO error message.


Running w/ Windows 7 x64 I decided to now make sure things still working with this tweak applied. The test I performed was a easy one. I simply had Look 'n' Stop GUI not load with Windows. I rebooted and without Look 'n' Stop being started, I perform various networking related tasks and all failed .. up until I finally manually started Look 'n' Stop GUI.

 

I understand it does more than just load rules, but it's after this point when LnS starts to filter. My problem is more to do with the App filtering, rather than Packet filtering (although I haven't tested to see if PAcket filtering is also not being performed.)

The LnS GUI is just a visual clue as to when App filtering seems to take place, but it's not really relevant to the testing as the LnS drivers will be using the rule-sets directly, and my thinking is that until the App filtering driver has finished it's initialisation (including loading the rule-set), the driver either isn't active (and so isn't filtering the App at this point - hence no prompt is shown), or it is active but Allows everything until it finishes initialisation.

The update is defnitely happening as it is downloading a changelog, rather than just a YES/NO answer.

Your test does not simulate the conditions I mentioned, whereby the hard disk is thrashing, and so is slow loading various things.

 

For starters.. Anything allowed via Application Filtering don't get a free pass via Packet Filter.

The drivers gets loaded on start-up but doesn't handle directly the decision to block or accept .. with exception to the packet filter tweak which uses its own hard-coded master deny rule into the driver and gets overruled once the Look 'n' Stop GUI loads up and communicates with the driver.

Application filtering don't automatically allow, but it just simply don't see until the layer is properly initialized. It's almost like you expect a software product to function even before having installed it fully.

When the Look 'n' Stop GUI initializes the Application filtering layer, It obviously won't catch anything happening during the very moment it's starting.

 

Ah, so the tweak only applies to the packet filter.

As both app filtering and packet filtering are done at driver level, the drivers are up and running quite early in the boot cycle, and they don't have to rely on the LnS GUI to perform actions (ie. they only need the GUI when user input is needed). It's a serious flaw of LnS that the app filtering driver allows all connections until the GUI has finished initialising, as it potentially allows malware to connect (and transmit/receive data) while this is happening.

It would be far better if LnS either paused connections until the LnS GUI was up and running and then prompt for a user decision, or intially just blocked all connections.

If the packet filter does indeed block all traffic initially (I'll test this soon), then a workaround would be to create+enable a rule to block ALL traffic. This rule then has to be disabled after loggind in and re-enabled when logging out/rebooting/shutting down, which is a pain (and not very practical).

If Frederic is still around, PLEASE can you fix this fatal flaw in LnS ?