“the term leaks implies ways to spoof the firewall into believing that any sort of inbound or outbound transmission is one thing, when it is in fact something else masquerading as the former”
is this the correct definition?
if not what is it?
thank you
Melih
If to run a leak test or in some real conditions a unusual connexion is asked to the firewall, there’s no more masquerading, the leaker trying to “identify” as no other then himself.
I would add any attempt by malware to trick the computer user into allowing a firewall leak.
does it have to be something else?
why not leak=firewall not being aware!
Melih
Let us take, another time, the exemple of some leak tests, and let us suppose these tests are indeed a real leak threat:
if the firewall warns and the user allows despite this warning, the one not being aware is not the firewall, but the user, and i believe this kind of situation to happen quite often.
Here is the definition from Firewallleaktester.com
“A leaktest will try to bypass your firewall stealthly without attacking it, it’s purpose is to hijack a trusted communication flow to go out undetected.”
on the basis of the above statement is this correct?
“the term leaks implies ways to spoof the firewall into believing that any sort of inbound or outbound transmission is one thing, when it is in fact something else masquerading as the former”
??
Can you pls give us your opinion, whether it is or it is not correct.
thank you
Melih
My first language is not english but I think both statements say exactly the same but with different words.
The definition is good but not perfect.
For instance, if a firewall asks the user to make the decision to allow or block, a “spoof” may succeed based strictly on poor human interaction.
Even with great advice (like Comodo’s) regarding options, many “less informed” folks may still go wrong.
MN
but do any of the leaktesting applications get caught by the firewall and ask the question (when they bypass the firewall that is)?
Melih
May i may an analogy,to me a leak test is a bit the air in a car tyre!
You know where the valve is and if you want to let air out YOU open the valve.This is being controlled by you and you how much air is going out.But if a nail where to get in the tyre or something opened the valve without your knowledge or permission then air would be released and make the car dangerous to the driver.
Therefore to me a leak is caused by either a rogue point(the nail) or something allowing info through the right place(the valve) but doing it without the users knowledge but saying the user says its ok.
The same goes for inbound.
Nice 1 Matty :-*
Sorry had to dash out:To me leaktesting should really envelope all aspects concerning unwanted data flow,like program A making a connection via program B, or program A making a connection by masquerading as program B.
Anything that tries to trick the firewall/HIPS into making an unauthorised connection is IMO a leak.
If a firewall were to allow the leak without question, and assuming a user has no other means of being informed, then both user and firewall would be totally oblivious to the success of the “spoof.”
So whether a choice is given or a bad choice is made by the user, it is still the user that is deceived. In the case of no choices being given, it could either be a poor choice of firewall, or a careless set-up of a good firewall that is the culprit.
In the strictest technical sense of the word, i think the definition given is incomplete.
There are many ways for leak tests to work, “masquerading” is just one way.
I disagree also with the guy who thinks that users who make mistakes and click allow are falling prey to leak tests.
Leak tests if they work bypass firewalls giving no chance what so ever regardless of user knowledge/response to block it.
It is true however that many users might ignroe a warning that malware x is trying to access the process space of explorer.exe or that "program x is trying to start iexplore.exe) , but that is really not the fault of the firewall.
A firewall that fails will only note (assuming it is not whitelisted) that iexplore.exe is starting…
I think a technically true test of “leaking” for a firewall will not involve user interaction. Obviously if the user gets an alert that application xyz is trying to access the internet, the user has the option to deny or allow (and, the rogue app/leaktest is not very sneaky).
So a more accurate test would be if the “leak” can bypass the firewall rules without any user interaction required. Or, be stopped by the firewall rules w/o any user interaction.
IMO, the current leaktests commonly deployed to “test” firewalls seem to all require user interaction when they try to do their stuff. Taking a realistic approach, is malware really going to be that simple to block? I hardly think so.
If we’re looking at a firewall (and not a HIPS), there’s probably no way for a dedicated firewall to simply silently block these types of things because they’re going to be the result of a system hijack anyway, deeply rooted, and exploiting known system processes/vulnerabilities to escape to the outer world. The only thing it could be defaulted for is to build a safelist of all known processes/applications and all possible legit combinations of the same (to avoid the hijacking issue), all legit IP protocols (of all levels) for said legit apps & combinations of apps, along with a blacklist of known bad IPs (with the ability to identify other values for the IP, such as hex, etc). Then the FW (again, no HIPS), would allow the known safe, disallow (silently - no user interaction) the unknown, block bad IPs for outbound, and so on. Does that sound crazy? While the NIST lists could help to identify known applications, combinations of apps seems impossible. Not to mention, when you get some off-the-wall application/process that’s not known to the FW (but is to the user), it would be blocked silently (remember, no user interaction for a “true” leaktest), which is just insane.
So… user interaction is the only way to realistically run these tests, and that (as we all know) will always be flawed based on the dependence on users’ choices. No matter how informative the prompt, there are always going to be wrong choices. That’s just the way it is, IMO.
I still think the only accurate leaktest cannot depend on user interaction (ie, the human element), but that there is no way this can be legitimately accomplished (remember HAL? 
).
LM
Although a firewall is an essential component of any solid “layered-security” strategy, it is clearly not the only effective “layer” that can stop “leaks.” If it was, it would not ask us any questions, nor would we need to consider any additional “layers” of protection.
It appears that the trend in firewall design is toward combining many of these additional “layers” into one package, but then is it still just a firewall? or a “suite” package that includes the basic firewall as its focus?
MN
That pretty much depends on what the word “effective” is…
If that word means: 100% security… then i agree, there is no 100% security…
if that word means: it prevents current known threat… then i must disagree and say that CFP v3 does a pretty good job
If that word means: because it prevent any authorised events and asks the user hence the user might make a mistake by answering it wrong (then I can tell you that this will be resolved shortly)…
If you wish, i have a layered security article in my blog you can read and contribute at www.melih.com ( http://www.melih.com/2007/12/04/layered-security-why-this-is-the-only-way-forward/ )
thanks
Melih
I think this is it, hijacking trusted processes.
A leak-test program is only successful when computer security is not.
Is the intended purpose of a leak-test program to slip past computer security?
If YES, it needs to bypass every operative component that might have otherwise prevented it, including the user. Leak-tests could include “social engineering” techniques adapted toward more closely mimicking interactive cyberspace.
If NO, as in pure firewall testing, then all components that are not being tested should be inoperative, including the user. Anything short of an administrator controlled environment may produce a false sense of security.
MN
Good point, MNcom ~ Especially about the social engineering side of it; I had not considered that. I also like the idea of an inoperative user…
LM