Application filtering problem

[Thomas M]

Using Win98SE2, webwasher and LnS 2.04p2

Since Opera announced a security hole in their browser software, I decided to give the fixed and latest version 7.02 a chance next to my beloved version 6.05. Which means that now I have installed both versions on the same harddrive, but in separate subdirectories.
Ok, after starting the new Opera7 LnS came up asking for permission to let opera.exe (version7) on the web. I allowed it, so far so good!

BUT I use a specific rule in the Internet filtering of LnS to only allow 3 apps connecting via port 80/443. These apps are Netscape.exe, Mozilla.exe and OPERA.EXE (version 6 !!)
However, now I am able to surf via port 80 using the new OPERA.EXE (version 7), which is located in a different subdirectory :o

This reminds me that there are little apps out trying to hide by using the same file name as the standard browser file name... and trying to leak out contacting their "script creator".... >:(

Any ideas on this one ???

Thomas :)

[Andreas1]

Hi Thomas,
have you checked your "special rule" to include two Opera.exe's? There should be an additional one available to include there.
If LnS stumbles on this, you can try and rename one of the opera.exe's and see if it still works and you get hold of both versions in LnS application filtering and in the "specify apps on which to activate the rule" dialogue.
Just an idea, don't know if it works.
Andreas

[bluenose]

Hi,

This is due to a weak checksumming. Other firewalls are using MD5, SHA1
or other hash algorithms as used in encryption. Furthermore one will
notice, that LnS doesn't show the exact version and build number of
the application, as other firewalls do.
This needs serious rework!
Another serious issue is the correct detection of the connection state
at any time for the proper functioning of the stateful packet inspection.
Especially dial-up users will notice after some time that this is not
the case. It would be too long to descripe here when this happens.
I can only advise to regularily compare the connection states with
netstat!
Possibly this effects also the internet filter and give a clue as to
unexplainable results with online-scans.

bluenose

[Thomas M]

{QUOTE-> {QUOTE-> quoting: Thomas M link=board=13;
However, now I am able to surf via port 80 using the new OPERA.EXE (version 7), which is located in a different subdirectory :o
Thomas :)
<-QUOTE}

Just to make things clear: Whenever I deactivate my port80/443 rule, none of my apps ( Netscape/Mozilla/Opera.exe(6)/Opera.exe(7) ) can connect via port 80/443 ! This confirms that my rule is specific for port 80/443. However, just one included Opera.exe covers both different files located at different subdirs on my HDD :(

Here is my port 80/443 rule:

----------------------------------------
[Rule0]
Statut=1
Valide=1
Direction=3
Filtrage=1
Avertir=0
Continuer=0
AlerteDlg=0
Name=TCP : Allow HTTP(S) Port 80 & 443
Description=This rule allows your PC to connect to otherÿþcomputers on the TCP port 80 & 443.
EthernetType=1
IPProtocol=1
EthernetAdd_PC_Criteria=0
EthernetAdd_PC0=0
EthernetAdd_PC1=0
EthernetAdd_PC2=0
EthernetAdd_PC3=0
EthernetAdd_PC4=0
EthernetAdd_PC5=0
EthernetAdd_Net_Criteria=0
EthernetAdd_Net0=0
EthernetAdd_Net1=0
EthernetAdd_Net2=0
EthernetAdd_Net3=0
EthernetAdd_Net4=0
EthernetAdd_Net5=0
IPAdd_PC_Criteria=7
IPAdd_PC_Bas0=212
IPAdd_PC_Bas1=204
IPAdd_PC_Bas2=29
IPAdd_PC_Bas3=6
IPAdd_PC_Haut0=212
IPAdd_PC_Haut1=204
IPAdd_PC_Haut2=29
IPAdd_PC_Haut3=6
IPAdd_Net_Criteria=0
IPAdd_Net_Bas0=0
IPAdd_Net_Bas1=0
IPAdd_Net_Bas2=0
IPAdd_Net_Bas3=0
IPAdd_Net_Haut0=0
IPAdd_Net_Haut1=0
IPAdd_Net_Haut2=0
IPAdd_Net_Haut3=0
IPFragmentOffset=0
IPFragmentFlags=0
TcpUdpPort_PC_Criteria=3
TcpUdpPort_PC_Bas=1024
TcpUdpPort_PC_Haut=5000
TcpUdpPort_Net_Criteria=5
TcpUdpPort_Net_Bas=80
TcpUdpPort_Net_Haut=443
IcmpCode_PC_Criteria=0
IcmpCode_PC=0
IcmpType_PC_Criteria=0
IcmpType_PC=0
BlockTCPServer=0
TCPFlagsVal=0
TCPFlagsMask=0
App0=MOZILLA.EXE
App1=NETSCAPE.EXE
App2=OPERA.EXE

[Nb rules]
Nb=1
----------------------------------------

I think this is convincing evidence for a leak problem in LnS...

Thomas :)

[bluenose]

Hi Thomas,

as I said, poor checksumming. Simply speaking, the Applications are not
protected to prevent masquerading by a strong signature generated by
a strong hash algorithm. So Opera 1 and Opera 2...etc. are seen by
LnS as one and the same application.

bluenose

[Frederic]

{QUOTE-> quoting: bluenose link=board=13;threadid=7579;start=0#49981 date=1046339520]
as I said, poor checksumming. Simply speaking, the Applications are not
protected to prevent masquerading by a strong signature generated by
a strong hash algorithm. So Opera 1 and Opera 2...etc. are seen by
LnS as one and the same application.
<-QUOTE}

Thomas said the following:
{QUOTE->
Ok, after starting the new Opera7 LnS came up asking for permission to let opera.exe (version7) on the web. I allowed it, so far so good!
<-QUOTE}

So the issue is not a "masquerading"/"strong signature" issue.
Actually Look 'n' Stop did detect the new Opera.

Frederic

[Andreas1]

{QUOTE-> quoting: Thomas M link=board=13;threadid=7579;start=0#49965 date=1046328605]
[...]
IcmpType_PC=0
BlockTCPServer=0
TCPFlagsVal=0
TCPFlagsMask=0
App0=MOZILLA.EXE
App1=NETSCAPE.EXE
App2=OPERA.EXE

[Nb rules]
Nb=1
<-QUOTE}

Let's assume that LnS has no checksumming problem (some words about the algorithm used would help to convince everyone of this, tho) - then there would be two entries in LnS's application database named "Opera.exe" and each would have a different signature checksum. But could the problem be caused by the fact that there's nothing in that rule i quote above that tells LnS which of those two "opera.exe"s is the one that we mean...?
If this is the case, then the renaming trick should help and maybe a future version could get an additional field in the rule description that indexes the listed applications less ambiguously.

Thoughts about this?
Andreas

[Frederic]

Actually, the application names in the Internet Filtering don't refer directly to the exe on the harddisk but to the applications already allowed in the Application Filtering.

So an Internet filtering rule is activated only after the Application Filtering has allowed first the application to cionnect.

I'm not sure it is useful to have two instances of the same application allowed in the Application filtering and one allowing some Internet rules and the other allowing different Internet rules.
I confirm it is not possible to do so with the current version of Look 'n' Stop.

If you think there is a security issue there, please explain.

Frederic.

[Ph33r]

As Frederic mentioned that Look ‘n’ Stop refers not to the executable on the HDD but the Executable which had been Authorized to Application Filtering Layer. Therefore this is a good example why people shouldn’t state Informatics of situations where they know very little of, invalid informatics might I add.

For an Example use the most recently Updated “MooLive.exe” v1.5.1.1058 and MooLive v1.5.1.1052 which you can download from http://www.moosoft.com/updates now if you hadn’t already executed MooLive.exe from The Cleaner’s directory do-so now and you’ll see Look ‘n’ Stop Application Filtering Layer bringing up Alert dialog to Authorize or DENY. Now Execute the MooLive.exe v1.5.1.1052 which you downloaded from the site manually and you’ll see it bringing up Look ‘n’ Stop Application Filtering Layer Alert.

Now replace the MooLive.exe found in either directory with something else spamming as MooLive.exe and execute, you’ll see it show the Look ‘n’ Stop Application Filtering Alert with the following;

Look ‘n’ Stop : Application Filtering
--------------------------------------------
C:\*\MooLive.exe

The application signature has changed. Do you want to authorize it again ?


|Authorize| | Block|
-----------------------------------------------

Now where do you see a flaw in Look 'n' Stop's Application Filtering Layer? 8)

[Andreas1]

Hi Frederic,
while i also don't think this to be a very grave issue, here's the way i see it:

1. a couple of applications connect to the internet, provided they are allowed to do so (which LnS checks by strong (?) checksums and their pathname).
2. The TCP/IP stack wants to initiate/receive a communication for which there is a rule and this rule has certain applications specified which enable the rule when they're running. So
3. LnS checks the names of all running apps if they match one of the names specified in the rule. Yes - the rule is activated, no - it isn't.

so far so good (i am not sure about step 3. Does the list of allowed apps come in again at this point?).
The problem (if it is one) surfaces when there is an application running which has a name that is specified in the rule, but which isn't the one that was supposed to activate the rule. That was a different one, only with the same name (so i suppose).
Then you'd have a rule active although it shouldn't be, since none of the applications you have specified to activate it are running - just one with the same name.

The multi-version Opera.exe is one example, other examples could be files called "update.exe" or "guard.exe" - i think that there are many (net-relevant) small apps with these names and that would increase the chances of inadvertently activating certain rules. (Imagine a scenario where you'd like certain IPs blocked/allowed just when a certain update.exe of a certain "mother program" is active.)
If finally you consider this to be worth fixing/improving, toute l'affaire could be prevented if the application parameters in the internet rules would provide not (only) the app's name, but (addidtionally) a pointer into the list of allowed applications to the exact entry, where also Path and Checksum are available. I know that this would probably mean a lot of work in the interface and checking (step 3 above) logic, but "conceptually" it's not a big thing.

But maybe Thomas, Bluenose or someone else also wants to voice their opinion on this.

Bottomline: No "serious" security issue, just a more or less theoretical trap to (maybe) avoid.

CU,
Andreas

[Ph33r]

Now in reference to the “Rule-Base Application Filtering” (Rule Applies only when Running and/or Connecting with *.exe) Feature, just keep in mind it doesn’t matter what rule with Authorized Application is specified, when in use anything other-than those Applications you specified can access the outside resources if using the following ports as the rule authorizes.

For an Example, you authorized Internet Explorer, and Opera and you create a rule to specify Internet Explorer, and u execute Internet Explorer and then use Opera you see Opera is capable of accessing the Outside through the current Internet Explorer Rule session. :'(

[Ph33r]

The issue exists with Applications being capable of taking advantage of “Rule-Base Application Filtering” Feature, when a rule which has this feature currently in use another Application whether or not it uses the same name is capable of accessing the outside resources depending if it uses the ports which a rule authorizes for a specified Application which currently in session. My Opinion is this Feature requires major improvement, until it does it’s pointless to even use. :'(

[Frederic]

{QUOTE-> quoting: Andreas(W) link=board=13;threadid=7579;start=0#50056 date=1046385153]
Hi Frederic,
while i also don't think this to be a very grave issue, here's the way i see it:

1. a couple of applications connect to the internet, provided they are allowed to do so (which LnS checks by strong (?) checksums and their pathname).
2. The TCP/IP stack wants to initiate/receive a communication for which there is a rule and this rule has certain applications specified which enable the rule when they're running. So
3. LnS checks the names of all running apps if they match one of the names specified in the rule. Yes - the rule is activated, no - it isn't.

so far so good (i am not sure about step 3. Does the list of allowed apps come in again at this point?).
The problem (if it is one) surfaces when there is an application running which has a name that is specified in the rule, but which isn't the one that was supposed to activate the rule. That was a different one, only with the same name (so i suppose).
Then you'd have a rule active although it shouldn't be, since none of the applications you have specified to activate it are running - just one with the same name.

The multi-version Opera.exe is one example, other examples could be files called "update.exe" or "guard.exe" - i think that there are many (net-relevant) small apps with these names and that would increase the chances of inadvertently activating certain rules. (Imagine a scenario where you'd like certain IPs blocked/allowed just when a certain update.exe of a certain "mother program" is active.)
If finally you consider this to be worth fixing/improving, toute l'affaire could be prevented if the application parameters in the internet rules would provide not (only) the app's name, but (addidtionally) a pointer into the list of allowed applications to the exact entry, where also Path and Checksum are available. I know that this would probably mean a lot of work in the interface and checking (step 3 above) logic, but "conceptually" it's not a big thing.

But maybe Thomas, Bluenose or someone else also wants to voice their opinion on this.

Bottomline: No "serious" security issue, just a more or less theoretical trap to (maybe) avoid.

CU,
Andreas
<-QUOTE}

Ok, I understand and I agree with that.

But the case you explained is different from the one exposed by Thomas:

{QUOTE->
BUT I use a specific rule in the Internet filtering of LnS to only allow 3 apps connecting via port 80/443. These apps are Netscape.exe, Mozilla.exe and OPERA.EXE (version 6 !!)
However, now I am able to surf via port 80 using the new OPERA.EXE (version 7), which is located in a different subdirectory

This reminds me that there are little apps out trying to hide by using the same file name as the standard browser file name... and trying to leak out contacting their "script creator"....
<-QUOTE}
It is not possible to have a troyan application just using OPERA.EXE as filename to activate some internet rules, because the application (with the full pathname) should be allowed first by the application filtering.
This was only my point. And there is nothing about checksumming involved in that.

Frederic.

[Thomas M]

{QUOTE-> {QUOTE-> Frederic wrote:
<-QUOTE}
It is not possible to have a troyan application just using OPERA.EXE as filename to activate some internet rules, because the application (with the full pathname) should be allowed first by the application filtering.
This was only my point.
Frederic.
<-QUOTE}

Yes, this makes sense to me! Thanks Frederic!

On the other hand I just tried to repeat the experiment suggested by "Ph33r": I have an application rule to block all activity from IExplore.exe. So I changed this application rule from block to allow IExplore.exe. And now my Internet Explorer perfectly connects to the web via my unchanged port 80 internet filtering rule! BUT again, as defined in this rule I only want Mozilla. Opera and Netscape to use port 80!!

So basically each of the "allowed" applications in my application list can connect to the web through all ports, which I allow through my Internet filtering rules. And this special button in the "rule editing window" of each Internet filtering rule called "application" could be removed, it has no meaning at the moment ??? It is not possible at the moment to block a specific port for an allowed application, when this port is allowed by any other app.

Please Frederic tell me, that I am wrong :o

Thomas

[Andreas1]

{QUOTE-> quoting: Thomas M link=board=13;threadid=7579;start=0#50110 date=1046421023]

So basically each of the "allowed" applications in my application list can connect to the web through all ports, which I allow through my Internet filtering rules. And this special button in the "rule editing window" of each Internet filtering rule called "application" could be removed, it has no meaning at the moment ??? It is not possible at the moment to block a specific port for an allowed application, when this port is allowed by any other app.

Please Frederic tell me, that I am wrong :o

Thomas
<-QUOTE}

I'm afraid you're (almost) right. Frederic may of course still confirm or deny this. I say "almost" because yet the button has a function, just not the one you're used to by other fw's like Tiny/Kerio/ZAP/etc.: While you cannot so-to-say limit the rules which apply to a certain app (like: let Opera use the port-80-rule, but not the port-443-rule when) (or maybe you can or maybe in some constellations only), the actual function of this is - like it says - to activate a rule only when a certain app is running. Take that stupid ident service as an example: Normally you're not running any servers so you drop all incoming connection attempts. OTOH, irc, smtp and maybe some other common services get back to you on port 113 before they continue and you get more or less serious problems if you continue to drop these requests. So you can add a rule that allows incoming connections on port 113 (the OS's tcpip stack will reject them anyway if there's no server app listening there on your comp.), but in order not to have that open all the time (and spoil your "stealth" status) you can specify that you want this rule valid only when your irc/mailclient are launched...

AFAIU, Frederic's argument about the issue you're talking of, was "either you trust an app or you don't. Opera could still tunnel its https traffic thru port 80" (in the example above), but i think he's keeping it on the todo-list for a future version.

HTH,
Andreas

[lurker1]

Hi everybody,

I like to bring something to the attention of the group which, when I
read bluenose's comments, sounded familiar to me.
Similar to Thomas's reasons for upgrading opera, I had to upgrade from
ie6 to ie6 sp1 for the last cummulative security update to accept the
the ie version. So I replaced ie6 with ie6 sp1.

Neither ie6 sp1 nor oe6 sp1 have been detected by LnS as a new app.
This is definitely a checksum problem.

I wonder what would have happened, when Thomas had replaced opera 6
with opera 7 in the same directory.
Another thing I took note of was bluenose's mentioning of identifying
applications as "iexplore version-number built-number" instead of
just directoryname/iexplore.exe.

I don't really bother about these issues, because I am using another
firewall (only tried LnS :-}).

Just wanted to let you know. :-)

[Ph33r]

I could of swore I had seen Frederic mentioned while back that Look ‘n’ Stop uses MD5, and MD5 is much more then matching up Location and filenames…etc

Most likely since newer version of the Application is an Update of the current it contains the same "fingerprint" therefore not triggering any Alarms. And even though the idea of matching files by version Informatics sounds beautiful it’s really quite of pointless since it’s impossible for another program to spam another programs "fingerprint".

Unless you can replace Opera’s Executable with a Trojan Executable or any type of malicious or non-malicious Executables and execute without Look ‘n’ Stop Alerting you shouldn’t be questioning Look ‘n’ Stop’s capabilities. ;)

[bluenose]

Hi Ph33r,

hold it...hold it. You should do some more reading about fingerprinting!
If only a SINGLE bit is changed, the MD5 fingerprint changes.
It is true that basically the functuality of a file may be the same,
however if only ONE bit of the file is changed, the fingerprint is
different. It's up to you now to figure out how many bits are changed
if the file contains different versions- and built-numbers! Or none
at all!

MANY!!!

[Andreas1]

Lurker and Bluenose,
i don't want to argue about LnS checksumming, just get some info together that might help explain why LnS could have missed the update(s) (if it did miss them). After all, this is not going to be resolved (either way) unless we get a bit more technical.

Can you confirm that those upgrades (ie6 sp1) change the exe file and not just some dll or other resources? (on several occasions i was alerted by LnS after i updated such an exe, only i can't exactly recall what was the app and the upgrade.)

And: do we all agree that MD5 is sufficient if it's used? If something else (crc-?? or maybe even sha-??) is used, we should know it, and then we can discuss about whether it is appropriate or not.

Cheers,
Andreas

[Ph33r]

Actually I do believe bluenose is a bit right…
In Look ‘n’ Stop’s earlier versions it appeared to function quite well, but now it seems not to detect “Updated” Executables that contains the same KB’s in filesize. And using MooLive.exe for an Example updating or downgrading the current MooLive.exe doesn’t trigger any Alarms now… Maybe there’s a conflict within the Look ‘n’ Stop Application that needs to be repaired… :o

[Thomas M]

Folks,

my LnS detected the new version of opera.exe (version 7) in the application filtering. So this thread here is not about LnS missing anything in the application filtering. At least not for this Opera.exe file.

What really depresses me is that I misunderstood the entire concept of this firewall! If I can not block specific ports for an allowed application makes me thinking to switch to another product (please note that I just wrote "makes me thinking"!! Please help me to find out that the concept of LnS is convincing...)

Thomas :)

[Andreas1]

{QUOTE-> quoting: Thomas M link=board=13;threadid=7579;start=15#50157 date=1046455024]
What really depresses me is that I misunderstood the entire concept of this firewall! If I can not block specific ports for an allowed application makes me thinking to switch to another product (please note that I just wrote "makes me thinking"!! Please help me to find out that the concept of LnS is convincing...)
<-QUOTE}

I for one have not much to add here: this (the other way) is a functionality that has been asked for a couple of times and Frederic is aware of it, i think he has it on the todo-list for a later version.
Other than this, i have only recently switched to LnS from Kerio. On the one hand, the numerous other options that LnS offers (like filtering on flags, logflood protection and a couple of others) made me not wanting to wait any longer just for that function you've mentioned (and which i'd like to see in LnS too).
On the other hand, i'm in linux most of the time now and so maybe i am more easily willing to run LnS in my win98 sessions.
Finally, that specific function is - as Frederic is IMHO right in insisting - needed primarily if you don't trust your apps (spyware, cracked versions or something like these), and over the past year i've virtually eliminated those apps that i don't trust completely. (I'll admit tho, that there are also some occasions where another motivation for using such a function arises, but i can cope with these).

HTH,
Andreas

[tosbsas]

I don't understand anything about the tech - stuff but in my case IE 6sp1 (if I remeber right) was found and Opera 7 too, as there where many other changed apps - all found

Ruben

[Frederic]

Yes, there is currently no option in Look 'n' Stop to allow specific port for a specific application.
Our motivation is that you should trust an application globally. Otherwise what you will do is: open one port and block others, and then nothing will prevent the application (if it is a malicious one) to use the only port you allowed to perform malicious operations.

The application selection feature in the Internet filtering doesn't replace at all the port selection at application level.
The purpose of the feature is only to block the maximum of ports when there is no need to open them.

2.03 and previous versions didn't include this feature, and this didn't prevent Look 'n' Stop to offer a high level of security.
So this new 2.04 feature is just a plus to have more cases where packets can be blocked in the packet filter.
This is useful for all applications that open sockets in server mode (Irc with the ident, FTP, Web Servers...) and this is useful for people that would like to use applications like NetMeeting (that uses a lot of ports) but don't want to let many ports open as soon as the application is no longer connected.

Anwyay, the port selection at application level is something that we will introduce in a future version (I know I've already said that before, but we think the other features we introduced are more interesting).

Frederic

[Ph33r]

To be accurate this Feature had been extremely Requested Feature since the start of the old Look ‘n’ Stop Forum on Becky’s. Customers and their Time and Efforts put forth into creating threads requiring this Feature and explaining why it’s necessary to them. And I can absolutely ensure Frederic that I’ve known quite a number of people switching to another Software Firewall because of this particular Feature we are currently discussing. As Andreas(W) said this Look ‘n’ Stop contains much Features that other Software Firewalls “still” doesn’t have implemented yet. And that’s why I’m using this reliable, Firewall which runs smoothly and speedy and giving me absolutely nearly nothing much to want. But don’t tell me this Feature isn’t absolutely beneficial Feature, with all my Kn0wledge I can ensure you this will prevent all my issues with Spywares, and others peoples issues like Trojan Infections. And like it or not it’s nearly impossible for the Average Joe to download programs that doesn’t contain Spywares, many very popular beautiful programs many people uses contains Spywares and Look ‘n’ Stop isn’t capable of functioning in this field to protect users against Trusted Applications unauthorized Outbounds.

Back in the old days of ConSeal PC Firewall, I use to specify what Applications can access what port or ports, mIRC specified to use port 6667tcp, Internet Explorer specified to use port 80tcp, Outlook Express specified to use ports 25, 110, mIRC specified to Authorize 113tcp inbounds… and I specify Source Port/IP and Destination Port/IP and so forth, and nothing other-than the selected Application was capable of intercepting the packets.

Look ‘n’ Stop’s Feature you cannot authorize or DENY with specified Application without haven major conflicts with other Applications connecting. You Block Internet Explorer or Opera only then execute the denied Application and attempt to connect to a webpage and try opening Non-specified browser and surf, you’ll find it very difficult to make Connection even though you specified the rule to only apply to Internet Explorer or Opera browser rather then other-than which had not been selected.

Now try Authorizing only Internet Explorer or Opera and Execute & surf, while executing Non-selected browser, again the Other Applications capable of using the same rule to gain Access to the Internet Resources even though we didn’t specify the use of this here Non-Selected browser.

[Ph33r]

Quite shocked to see such an issue here, when ConSeal PC Firewall had this Feature “Apply only when running *.exe” it worked beautifully. And this was years, and years and years back, I’m quite sure it shouldn’t be too complicate for Frederic to implement this Feature with ease considering Today’s programming enhancements.

I don’t see why we have to Trust an Application globally, that’s non-sense. Trusting mIRC globally with its Socket Features is non-sense. If this Feature “Rule-base Application Filtering” wasn’t taking advantage of we could prevent bad mIRC script from making secrete unauthorized Connections, and this is just an example doesn’t necessary mean this is specific to mIRC because it’s not… Note: I used this Example because it doesn’t refer to mIRC containing Spyware or Trojan Infections by Default.

Now let’s use Explorer.exe which relates to privacy issues, Explorer.exe is on all Microsoft Windows Machines by Default of Installation, it’s very important part since its Windows Shell. I don’t trust this file Explorer.exe but I still require using it unless I want to find a shell replacement. I would like to be-capable of using Explorer.exe surfing capabilities, but I have to block it at Application Filtering Level, if I had this here Feature I could specific a rule to resolve all my issues regarding Explorer.exe.

Now there’s many popular Freeware which contains Spywares like WebFerret, KaZaa, and not so Freeware like GetRight and so forth. Do I want to Trust these Applications Authorization on Global Scale? No. What Advise giving? Trust it on global scale or don’t use… Easy as that….

Regards,

[Thomas M]

Thank you Frederic, Ph33r, Andreas(W), bluenose, lurker1 and tosbsas for your input on this topic :)

Very much appreciated your comments and now I see much clearer about the current features of LnS! I still believe it is a very good firewall, this is why I am using it! - But here I put my name on the wish list for better control of application port filtering ! Priority level: HIGH !!!

Thanks again,
Thomas :)

[Ph33r]

Look ‘n’ Stop isn’t capable of doing comparison besides the Signatures, and so Opera 7 update contained the same Signature as Opera 6 of that I done a thorough check on… And thus is why no Look ‘n’ Stop Alerts shown up after updating… Perhaps implementing Build, Version and so forth comparisons isn’t such a bad idea… I don’t believe though for this to be a security issue, just and problem of detecting Updated Applications Executables…


{QUOTE-> Hi Ph33r,

hold it...hold it. You should do some more reading about fingerprinting!
If only a SINGLE bit is changed, the MD5 fingerprint changes.
It is true that basically the functuality of a file may be the same,
however if only ONE bit of the file is changed, the fingerprint is
different. It's up to you now to figure out how many bits are changed
if the file contains different versions- and built-numbers! Or none
at all!

MANY!!! <-QUOTE}

Care to explain bluenose how Opera 7 Update contained the same Signature as Opera 6, or MooSoft Live Update v1.5 - build 1058 containing the same Signature that of MooSoft Live Update v1.5 - build 1052 by Look 'n' Stop? Maybe Look ‘n’ Stop isn’t using MD5 after all?!? I really don't know this part, i'm starting to Question what Look 'n' Stop uses...

[manuangi]

{QUOTE-> quoting: Ph33r link=board=13;threadid=7579;start=15#50201 date=1046471052]
I don’t see why we have to Trust an Application globally, that’s non-sense. Trusting mIRC globally with its Socket Features is non-sense. If this Feature “Rule-base Application Filtering” wasn’t taking advantage of we could prevent bad mIRC script from making secrete unauthorized Connections, and this is just an example doesn’t necessary mean this is specific to mIRC because it’s not… Note: I used this Example because it doesn’t refer to mIRC containing Spyware or Trojan Infections by Default.

Now let’s use Explorer.exe which relates to privacy issues, Explorer.exe is on all Microsoft Windows Machines by Default of Installation, it’s very important part since its Windows Shell. I don’t trust this file Explorer.exe but I still require using it unless I want to find a shell replacement. I would like to be-capable of using Explorer.exe surfing capabilities, but I have to block it at Application Filtering Level, if I had this here Feature I could specific a rule to resolve all my issues regarding Explorer.exe.

Now there’s many popular Freeware which contains Spywares like WebFerret, KaZaa, and not so Freeware like GetRight and so forth. Do I want to Trust these Applications Authorization on Global Scale? No. What Advise giving? Trust it on global scale or don’t use… Easy as that….

Regards,

<-QUOTE}

What an interesting discussion, thanks to this my knowledge about how things go, in LnS world, can hope for a higher rating! :)

I COMPLETELY AGREE with the quoted Ph33s's post, I too can't find any good reason to fully & always trust any, however good, software trying to reach the outer planes! :o

Many other fws have this feature...I remember using Outpost & its rule maker...you could always specify a "and when PORT NUMBER is XXXX" (or the like, I can't remember it perfectly).

LnS rules, really! Anyway it's true I'd really like to be able to specify what ports the apps I allow to get out may use!!
HIGH PRIORITY, Frederic!

I have been surfing this forum for a while now, I read many posts of yours...I'm sure, as most of us as well, that it would be so easy for you to implement that feature!

[Andreas1]

{QUOTE-> quoting: manuangi link=board=13;threadid=7579;start=15#50543 date=1046638260]
I have been surfing this forum for a while now, I read many posts of yours...I'm sure, as most of us as well, that it would be so easy for you to implement that feature!
<-QUOTE}

Let me say first that i also think that feature to be of high priority. But then, i don't know if this can be done soooo easily. As i understand it (but actually i don't have much insight in this and am rather speculating), restricting apps to certain ports would require a completely different parsing of communications at a completely different place than does restricting the whole OS to certain ports etc. So i imagine this does mean quite some work. Maybe for some v3.0...
Cheers,
Andreas

[MickeyTheMan]

I personally don't understand all the hype about ports !
Once you trust an app, much more enphasis should be put IMO on restricting it to ip's, rather than trying to focus on ports only.
For example, emailers use ports 25 & 110. As long as you restrict your client to mail servers ip's only, then no other app could try to piggyback on it as only the authorized ip's and these 2 ports are allowed.
Not much sense to me either to authorize a blank authorization to port 80 to your browser ! As a true paranoid, each ip to port 80 has it's rule on this sys. Mind you i mainly surf to BB's and few very reputable sites, so that there was not that many rules to create. But you can't get tighter rules than that.
Atewlier's firewall tester didn't have much chance to succeed even before Frederic came up with it's new driver.

Fianlly, do yourself a favour a disable the rule tcp- authorize most common internet services and replace by appropriate rules for each client.

[Ph33r]

I personally don’t know why you find it so difficult to see the importance of this Feature, haven more efficient capabilities of securing your System to the near Maximum, restricting at an Application Level and not a Global Level, Specifying rule for Applications to only have capabilities of sending/receiving only to/from the specified source/destination port or ports.

{QUOTE-> I personally don't understand all the hype about ports !
Once you trust an app, much more enphasis should be put IMO on restricting it to ip's, rather than trying to focus on ports only. <-QUOTE}

I’m going to be brief here; you must not do a whole lot of Exploring. There’s great deal of popular clients that offers Multi server Features which people don’t take for granted and p2p Transfer capabilities. Not everything is simple like a simple ol E-mail Client…

{QUOTE-> For example, emailers use ports 25 & 110. As long as you restrict your client to mail servers ip's only, then no other app could try to piggyback on it as only the authorized ip's and these 2 ports are allowed. <-QUOTE}

This is bigger then you or I, I can’t see how you cannot see the benefits of this.
But it doesn’t matter if you don’t applaud this Feature, and it doesn’t matter that I do, the secret word is Majority, they do…

{QUOTE-> Not much sense to me either to authorize a blank authorization to port 80 to your browser ! As a true paranoid, each ip to port 80 has it's rule on this sys. Mind you i mainly surf to BB's and few very reputable sites, so that there was not that many rules to create. But you can't get tighter rules than that. <-QUOTE}

Not everyone revolves around your way of things, what you or I consider worse others may consider better.

{QUOTE-> Atewlier's firewall tester didn't have much chance to succeed even before Frederic came up with its new driver. <-QUOTE}

[MickeyTheMan]

There is nothing worse than a false sense of security. I'm not intertested in features that will provide just that and i understand Frederic's relunctance to implement that feature because of it.
P2P ? I use it on occasion, but rules are made on the fly as needed and disabled or even deleted right after usage.
Majority ?..............They choose ZA ! Popularity does not mean security conscious or awareness

And just answer me this question, please :
Is the rule TCP - authorize most common internet services active or disabled on your sys ? If it's active, then it's pointless to pursue any discussions with you on this subject.

[Ph33r]

Firstly it’s no worse implementing “Application Filtering” Feature into Software Firewalls; you’ve even said on many occasions that “Application Filtering” Feature gives false sense of security. However you choose to use a Software Firewall with that Feature, giving option you could use Look ‘n’ Stop Lite version but you don’t.

But once again this isn’t about you or I, this is about the majority which had spoke in the past and in the present and will in the future which over weights your judgement on this.

I personally get the instinct impression you only against this Feature with a hidden agenda whether it’s to score points with Frederic and/or to show how reluctant you can be in front of the public…

{QUOTE-> There is nothing worse than a false sense of security. I'm not intertested in features that will provide just that and i understand Frederic's relunctance to implement that feature because of it. <-QUOTE}

Whether or not rules can be made on the fly and be Disabled and Deleted for you doesn’t matter, what matters is this Feature is more efficient which offers great enhancements in relations to Security and when it comes down to it, that’s all what matters… If you aren’t capable of seeing how beneficial this Feature is then step aside and don’t attempt to spoil it for the rest of us who been working so hard to get Frederic to implement this in from day #1.

{QUOTE-> P2P ? I use it on occasion, but rules are made on the fly as needed and disabled or even deleted right after usage. <-QUOTE}

ZA was extremely popular type of Software Firewall, but like it or not it went under quite awhile ago, more people on Rule-based Software Firewalls then what they are on ZA type Software Firewalls.

Besides I was in reference to Majority who was into Rule-base Software Firewalls, next time I’ll try to be quite so more detailed…

{QUOTE-> Majority ?..............They choose ZA ! Popularity does not mean security conscious or awareness <-QUOTE}

Whether or not I use “TCP : Authorize most common Internet services” or something like has no bases, this is a Feature which will benefit widely, not only for paranoid rule-set styles but all rule-set styles. I’ll admit this Feature will be extremely beneficial in enhancing security for those who uses “TCP : Authorize most common Internet services” or something like, people who don’t have time spending making rules after rules per connection made by per client day after day after day… Copying and pasting, copying and pasting, configure, re-connecting… You may have time, but I’m sure not all has time to-do all that and so forth…

{QUOTE-> And just answer me this question, please :
Is the rule TCP - authorize most common internet services active or disabled on your sys ? If it's active, then it's pointless to pursue any discussions with you on this subject. <-QUOTE}

[Ph33r]

Here is my Idea of implementing “Rule-base Application Filtering (Rule Applies only when running/and-or/connecting with *.exe)” Feature

#1. Only Authorized Client Applications will only be available for selection.
#2. Adding Feature to select only 1 (starting point) Client Application in a List of Authorized Client Applications in “Rule Editing” dialog.
#3. Rule with selected Authorized Client Application only applies to that of which had been selected and nothing more.
#4. And of course Allowing/Denying Capabilities.
#5. Possibly even “From” section to indicate what Application trigger the Rule (But I suppose using “Rule Description:” this might not be necessary Feature unless others find it a useful Feature…

Now this is just my thoughts on the matter, I’m sure if anyone else has any other suggestions to add they will… ;)

[V]

Mickey, what if trusted site "x" is hosting a forum for security software that you use and the IP/rule used to update said software is also the one that connects to site "x" forum? What if a trojan was installed with your new update? Could happen!! ;)


__________________

Paranoia is complete awareness

[MickeyTheMan]

{QUOTE-> quoting: V link=board=13;threadid=7579;start=30#50664 date=1046714074]
Mickey, what if trusted site "x" is hosting a forum for security software that you use and the IP/rule used to update said software is also the one that connects to site "x" forum? What if a trojan was installed with your new update? Could happen!! ;)


__________________

Paranoia is complete awareness
<-QUOTE}
This is behond any rule making or app filering abilities and has to deal with anti-trojan capabilities.

However, for the feature that is requested in this topic, it is of utmost importance those asking for it realize the importance of the rule TCP - authorize most common internet services and that it is very much related to that request.
Wether the feature is implemented or not, this rule does not make any sense whatsoever and should never be active .
If there is a rule that should be disabled as soon as you install LNS, this is the one !

[V]

The issue isn't so simple as merits of Anti Trojan versus App Filtering there's a whole range of protection possible from adding the requested features..I previously given example how to easily bypass your IP/Port to IP/Port total security model. With requested features included in Application Filtering we would be protected from "in-the-wild" exploits that are well beyond the reach of A/T databases.

I would rather have an A/F that protects against every imaginable way of information leakage, than totally trust after-the-fact signatures and leave the door wide open for any "new" exploit to leak out. Improved Application Filtering can only benefit all.

__________________

Paranoia is complete awareness

[Ph33r]

Well Said! ;)

[AN(t)ON]

Hi,

I have had LnS installed for some time but discontinued using it because
of irregularities which various contributers of this topic discribed in
one or the other way.
The first thing can described as what other FW makers call:
Strong enforced application privileges. This has in my opinion something
todo with a strong hash in both directions and other identifications.

If the allowed applications appear in the rule only as:

netscape.exe
mozilla.exe
opera.exe

instead of:

netscape nnnn.nnnn.nnnn
mozilla nnnn.nnnn.nnnn
opera nnnn.nnnn.nnnn
opera xxxx.xxxx.xxxx

then there is something not quite fake-save. :-)

It happened also to me, that IE sp1 was NOT identified as a new
application.

Another very important security layer is Stateful Packet Inspection.
Not only to check if the packets belong to the established connection
but also ,I guess, to the privileged application.

It happened to me, that when DL Express was allowed the first time
to enter the net, not one of the many connections a download manager
establishes by natur was detected, which leaves me to believe that at
that time the security-layer of SPI was totally deactivated.

Occasionally I noticed also that after a disconnect after mail-fetching
by OE, the connections-states remained as connected. As I read, SPI is
done by caching the connection states for comparison. If something goes
wrong there, the SPI cannot work properly anymore.

[Ph33r]

Nothing wrong with more Informatics, I’m open for that Enhancement. However, I don’t agree it’s an Enhancement of Security. I’m pretty sure Frederic had at one point mentioned that Look ‘n’ Stop uses MD5, has anyone ever heard of MD5 being unreliable? Anyone here thinks they have the capabilities of making a replica MD5 Signature of something else?

Only reason Internet Explorer SP1 Executable wasn’t detected because it had the same Signature. Appears to me people would have to not Trust Applications own sources Upgrades…

In any event I don’t believe one who attempts to go all through the work of masquerading an Application to leave out the current Version and Build and so forth Informatics.
++

{QUOTE-> Another very important security layer is Stateful Packet Inspection.
Not only to check if the packets belong to the established connection
but also ,I guess, to the privileged application. <-QUOTE}
Absolutely, I’ve suggested ages ago to implement that Feature. Any Software Firewall with Stateful Packet Inspection Feature should also cover Trusted Applications Connections.

{QUOTE-> It happened to me, that when DL Express was allowed the first time
to enter the net, not one of the many connections a download manager
establishes by natur was detected, which leaves me to believe that at
that time the security-layer of SPI was totally deactivated. <-QUOTE}
TCP Stateful Packet Inspection Feature in Look ‘n’ Stop isn’t Enabled by Default of Installation…

- Fixed unmatched quote tags that was causing page format problems - LWM

[AN(t)ON]

Hi Ph33r,

what you are saying is to the normal person not quite clear and confuses,
and also based on assumptions.

I happen to use here a not very known but feature-rich legacy version
of PGP and can by the snip of my fingers calculate the file hash
of MD5, SHA1, SHA2 and RIPEMD160. Which I of course did for IE and IESP1.

They ARE different; if LnS would use a decent one-way hash, it would
have detected IE SP1.

And as to SPI: IT WAS ENABLED!

rgds

[Ph33r]

AN(t)ON I’m no normal person, I’m mentally insane person…
I can see crystal clear, Look ‘n’ Stop sees the same Signature of MooSoft Live Update v1.5 - build 1052 as MooSoft Live Update v1.5 - build 1058 (""=dword:41b3040d), same as Signature of Opera 6.* as Opera 7.* Signature when I done comparison.

As for SPI Feature, it’s still needs improvements. When Firstly Enabling it you must re-execute all your Client Applications, or if you Disable Internet Filtering Layer…

[Ph33r]

I suppose only one way to clear this up for once-and-for-all, is wait for Frederic to confirm what he’s using. ;)

[AN(t)ON]

Hi Ph33r,

take it easy...:-)

What you have seen "crystal-clear", is proof enough, that LnS has NOT
seen everything crystal-clear.:-)

In other words, or in the words of "bluenose"... poor checksumming.:-)

If a strong hash would have been used, also LnS would have seen the
applications not so "foggy" through its goggles. :-)

rgds

[Frederic]

{QUOTE-> quoting: AN(t)ON link=board=13;threadid=7579;start=30#50774 date=1046788353]If the allowed applications appear in the rule only as:

netscape.exe
mozilla.exe
opera.exe

instead of:

netscape nnnn.nnnn.nnnn
mozilla nnnn.nnnn.nnnn
opera nnnn.nnnn.nnnn
opera xxxx.xxxx.xxxx

then there is something not quite fake-save. :-)
<-QUOTE}

I already mentioned that the applications selected in the Internet filtering have to be allowed first in the Application filtering.
So there is nothing bad here.

I agree this relies on the Application Filtering checksums.

Ok, I've understood that everyone is saying that the checksum used by LnS is not as strong as expected.

Frederic.

[AN(t)ON]

Hi,

just a short final from my side...

Possibly some of the readers of this forum are asking themselves:

Strong checksum...one-way hash? All good enough to check file-integrity?

NO! Checksums like XORing, CRC etc. are all re-calculatable or breakable.

A one-way hash like MD5, SHA1/2, Tandem Davies-Meyer etc. are as of
today considered as irreversable. That's why they are also used for
signing documents and files using PKI Structure (PGP) to check integrity.
And of course in firewalls. ;-)

rgds