Application filtering faulty

From the premise of when the application is active, it allows everything in the rule without considering what is really listening.

I made a browser rule, a rule I only want my browser to use, and not my html enabled mail client. Well the block all at the end stopped the replies from the sites when it was outbound only so I had to make it both directions since LnS wasn't smart enough to see that it was a connection started by my computer, and when I did that the entire range of tcp 1024-5000 was allowed when the program was running! I tired it without the block all active, and I've had Stateful Inspection enabled. The stateful inspection is doesn't work all the time, and seems to require that you get bombed with packets before thinking about working. If you want proof, I did the simple scan from grc.com, and ports 1024+ all showed closed, or open when it was enabled.

So when I start my browser, if I get a tcp probe in the rage of 1024-5000, it will be allowed to send a closed, or open repsonse just beause its running. The stateful inspection is not doing its job.

With Kerio Personal Firewall, I have a simple rule:
Outbound TCP
Local ports:1024-5000
Remote ports: Any
Remote Address: Any
Application: Browser.exe

I'm not required to make it bi-directional since my firewall knows that my computer started the connection, and with Kerio's ability of blocking inbound tcp/udp packets to non-listening ports its not an issue even if I did make the rule bi-directional. If nothing is listening, its blocked, and it works better than LnS's so-called stateful inspection. Even the ancient AtGuard didn't require that you made the browser rule with the application as part of the rule bi-directional, and it saw that your computer started the connection so it didn't question the nature of the packets.

The test I ran were with only LnS installed, and it was the only firewall enabled. The premise of the application filtering, and the unreliable stateful inspection are a problem. I'm aware that the ability to make rules by application is very new for this product, but it still needs work with more than just the application filtering. To the core, this firewall is still mainly a packet filter with a little bit of application filtering, but unless they fix the way they handle the application filtering with the stateful inspection it will not be as effective as other firewalls already out for years.

 

You in reference to Rule-base Application Filtering Feature..........

 

Did you read the entire thing? I just posted it less than a minute ago..

I'm referring to the application filtering in the rules, where you can pick the application to apply to the rule.

 

Look ‘n’ Stop doesn’t contain “Rule-base Application Filtering” yet, remember it’ll be coming out in the next soon-to-be v2.05. What you are currently seeing in Look ‘n’ Stop is not even a beginning of “Rule-base Application Filtering”.

And the Stateful Packet Inspection Feature does work properly like it should… You just need a better understanding

 

I downloaded the Pro demo, and it has the application filtering in the rules.

BTW, I do understand how stateful inspection works, and you should not have to use tcp/udp block all rules when you have stateful inspection.

 

Heh, i know... Trust me that's not i would call "Rule-base Application Filtering".

Visit http://spyblocker-software.com/IPB/index.php?showtopic=103 (very old, old, old topic)

 

Thanks for confirming, the packet filter on LnS is great, and I like how it can detect programs starting internet programs. However I'm too paranoid about making my programs use certain addresses, and ports so the current build it doesn't work very well for me.

Oh well, I'll just watch out for the newest version, and see what they have improved.

 

Multi-Layers;

#1. Application Filtering
#2. Internet Filtering
#3. Stateful Packet Inspection

If you understood how Stateful Packet Inspection works you wouldn’t be complaining.

 

Just from googling around I'm finding information supporting my theories

http://www.firewall-software.com/firewall_tech/stateful_packet_inspection.html

 

#2. Internet Filtering
#3. Stateful Packet Inspection

Internet Filtering comes 1st, all that is allowed then goes through Stateful Packet Inspection. If there is a malicious packet attempting to spoof, it’ll be seen and Alerted by SPI Feature…

 

Correct, it was missing packets that should have been blocked by the stateful inspection. The applications didn't request it, they were not effected by the rules, and the packets were allowed to send back a closed response.

Anyway, for some reason it didn't work properly, but I will have to test out LnS again when the true application based rules have become a feature.

 

Hey BlitzenZeus

You are misinterpreting it all; and you can’t expect the Software Firewall to function properly when you are crippling it by making improper modifications to its rule-set.

You don’t understand just how crucial rule like “Block : All other packets” is; You must not expect when deactivating or making modifications to a rule such like this one that everything will function properly. In Reference to this particular rule, this rule plays a very important role. This rule does not just apply to TCP, UDP Protocols but ALL IP & Non-IP or Other IP Protocols.

Now Look ‘n’ Stop doesn’t have Rule-base Application Filtering and you can’t expect a Dialog to appear on un-configured App Traffic coming with Options like Authorize, Deny and so forth, and clicking Authorize for an example and it’ll automatically apply for both directions (Inbounds & Outbounds) for TCP Connections…

This is how it works;

"PC >> Internet" = Packets Locally and sent
“Internet >> PC” = Packets remotely being sent
"Internet >> PC & PC >> Internet" = Packets Locally and sent, & Packets remotely being sent.

Now in Addition; if you want to make a rule for TCP Connections you use “Internet >> PC & PC >> Internet” selection, if you want this rule to apply only to Locally started Connections you place this rule BELOW “TCP : Block incoming connections” rule, another crucial rule you must learn. And if you want this rule to apply to remotely started Connections (assuming you hosting some type of server locally) then you place this rule ABOVE “TCP : Block incoming connections” rule.

Now in reference to Server Applications; you can make a rule which applies only to a specific Server Application since only one application can listen to a TCP port at once, however making a rule for a specific Clients Applications Outgoing then that will apply at a global scale to any Application that’s been authorized to the Application Filtering List, regardless whether it’s the only App that’s been Added to the "The rule is activated as soon as one of the following applications connects to internet:" list. This Feature is not “Rule-base Application Filtering”, the soon-to-be next release v2.05 will contain “Rule-base Application Filtering” which Applies “only” when running or connecting with…

As for the Stateful Packet Inspection; I don’t see a single thing wrong with it, it’s working just how Frederic coded. It’s working as a 3rd Layer Protection;

Application Filtering Layer
Internet Filtering Layer
Stateful Packet Inspection Layer

Now there must be misinterpretation on my behalf because I know you cannot be telling me while SPI Feature is Enabled that any Servers being ran Locally, behind the SPI Firewall it’ll be completely useless?

And I definitely know Look ‘n’ Stop’s TCP SPI Feature is working; as I try to Spoof an Active Connection to the slightest Detail expectation to the purposely mismatch and Look ‘n’ Stop’s TCP SPI Triggers, so obviously the monitoring algorithm must be working.