Leaktests: Should they be considered in selecting a Firewall?

Discussion in 'other firewalls' started by Rmus, Aug 28, 2005.

Thread Status:
Not open for further replies.
  1. WSFuser

    WSFuser Registered Member

    Joined:
    Oct 7, 2004
    Posts:
    10,639
    i agree with toploader, the problem is that siganture based scanners need the definition to detect the malware and the develepor of such scanner has control over whats included in the database. then theres HIPS which rely on sandboxing, behavior blocking, or heuristics. however it has a high level of flase positives (if u install it before everything else) and generally requires a fair amount of user interaction and configuration. if u have layers of programs, the chances of malware getting through are very slim and finding malware that does get through are very more slim. it is the (or it should be) resposibility of every computer user to decide what amount of security is sufficient as no antimalware can ever be perfect. Its the price u pay to keep a well maintained and secure computer.
     
  2. Paranoid2000

    Paranoid2000 Registered Member

    Joined:
    May 2, 2004
    Posts:
    2,839
    Location:
    North West, United Kingdom
    Most firewalls will detect obvious attempts to use Internet Explorer (e.g. trying to access a website via a "hidden window" that doesn't appear onscreen) and many will detect more subtle hijack attempts (e.g. DLL injection). However legitimate software may use these techniques also to add new functions to applications (e.g. a mouse driver may need to inject its DLL into every running application to provide new button functions) so it then becomes a question of knowing what software on your system needs to do this.

    This also applies to "process monitoring/control" software like Process Guard/PrevX/System Safety Monitor. However it is usually quite easy to pick up the legitimate items (since they will most likely refer to files in the Program Files folder of the application/utility in question) while most malware will try to hide itself in the \Windows or \Windows\System32 folders.
     
  3. ----

    ---- Guest

    yes, they try to be too clever to fool the noobs. But if I were targetting you and the people on this board, i would do it differently of course, hiding in plain sight.
     
  4. StevieO

    StevieO Guest

    Hmm,

    Hiding in plain sight, looks like we are into the rootkit department now.

    But i guess that would be one, sure big leak past all of our stuff, and out through the FW !


    StevieO
     
  5. HandsOff

    HandsOff Registered Member

    Joined:
    Sep 16, 2003
    Posts:
    1,946
    Location:
    Bay Area, California
    I hope this is not too far afield but by the general consensus, if I am sensing it correctly, most of you are concerned with some evil individual hacking into your system armed with homespun trojan's, rootkits, designer viruses, and whatnot.

    Probably alot of you are professionals, and protect networks, so this is understandalbe. Anyway, for me, the struggling home computer user, the enemy is a little less vague, and is constantly present. It is the software that I download, or purchase and then install myself. And the O/S of course.

    The good firewall, just like almost all good security programs tells you things you would not otherwise know. I don't expect it to know good from bad. I think suspicious, or superfluous should be identifiable. And I expect it to communicate. And I expect it to block everything outbound if necessary, until I, the nominal boss of the computer, have said yes or no. I don't understand how dangerous leaks can not appear suspicious, but I know some firewalls are much better at following instructions, communicating, and suspending activity, indefinitely if necessary. I don't know which one's are the best, because I don't see as much discussion on those points (lately).

    If every notification from your firewall is stupid and irrelevent. If you have no idea how to monitor connections, or review past activity. If you have people or ip ranges, or applications that you would like to block, but you don't know IF, let alone how to use the firewall to put those restrictions in place, then I say, with all humility, your firewall sucks! I don't care how great its leaktest report card is. It is an ignorant, atonomous piece of junk that hunkers on while you tell yourself, 'I think my spaceship knows which way to go'.

    I still say, leave leaktests, and other threat assesment and product developement to the professionals. And quite frankly, I have no way to assess the risk that they present, in the first place. But I am not responsible for network security, so I have a different objective than those who are.

    (w/ regard to P2000's comment on malware and where they are found. Don't get me wrong, he makes a good point, but...)

    I am a little surprised if other people's windows systems directories are not littered with bits and pieces from a very large percentage of the applications that run on their machines - like mine is. I would like to say that their dangerous presence is at least lessened a good deal by thorough documentation included in the files self-contained summary (see below)
    ...only, I don't think I have EVER seen one even partially filled out. It seems worse with drivers, because each and every one appears to be written by ... well anyway...just wanted to say that.


    -HandsOff
     

    Attached Files:

  6. ----

    ---- Guest

    No, I don't mean rootkits. I mean give up trying cute tricks of pretending to be a system file, they don't work with experienced users. It's a dead give away.


    Rootkits don't hide in plain sight anyway.

    Well since most of us here are home users, running zero services and servers, someone hacking through is not really too big a possibility.

    Er no. That's DSLR

    Exactly. And I'm concerned that other than AV and AT, there is nothing else to protect the homeuser from malware bundled in. All the HIPS hype going around either don't address this danger at all, or at best do it very ineffectively (Go study up programming on the meaining of global hooks and you still have a 50% chance of guessing wrong).

    Or you suck. :) Seriously I thought all this knowledge was assumed to be present before you start messing with leak tests. It's not that important if you fail or pass the leak test, what is important is that you know why exactly you pass ot fail! And that involves at least some knowledge of how the leak test is working.

    Not too hard for hobbyist really though.

    Another rules of the thumb, something that has a extremely randomised name or a name that is almost but not quite the same as an existing system file is almost always malware. If you know which directories they usually reside you are even better off.

    It may be littered with stuff, but they almost never connect outwards through your firewall.
     
  7. ghost16825

    ghost16825 Registered Member

    Joined:
    Feb 1, 2005
    Posts:
    84
    Some fair points there, ---/Guest.

    Errr, I disagree, I think. I favor full control by the user only, rather than any automated decisions. Obviously this cannot occur due to differing levels of user knowledge. So failing this, I think the most important characteristic is full transparency with regard to automated decisions. Additionally, full mapping of firewall behaviour should be explained in detail in the help file documentation. You may note that many so called easy-to-use GUI firewalls completely fail on this point.

    Ah, here's the point. You cannot have better control over the firewall without better user knowledge and with it more input from you. Consequently, most firewalls make decisions for you. Often they create a 'generic' rule which can be made a lot tighter.

    Guest/--- raised a good point on leaktests. But this kind of reasoning is valid for any type of security threat. Only after finding out how exploitation of a vulnerability occurs should we choose a countermeasure to counter this threat. Sadly, many infosec vendors are keen to push solutions to their customers which may been unsuitable for the types of threats they face.
     
  8. StevieO

    StevieO Guest

    Quoting Guest ---- "Rootkits don't hide in plain sight anyway."

    I was thinking in terms of the ones that Don't try to hide whilst being scanned etc, so in that way i would call them, hiding in plain sight.

    Quoting Guest ---- "(Go study up programming on the meaining of global hooks and you still have a 50% chance of guessing wrong)"

    Global hooks are RK territory, and 50% chance of guessing wrong, is a 50% chance of guessing right !

    Quoting Guest ---- "It's not that important if you fail or pass the leak test, what is important is that you know why exactly you pass ot fail! And that involves at least some knowledge of how the leak test is working."

    I think it does matter if you pass or fail. Why would anyone want a system that fails, if they can engineer one with the right Apps and system settings etc that can pass. I agree that understanding why you might fail or pass is powerful knowledge worth having.


    StevieO
     
    Last edited by a moderator: Sep 10, 2005
  9. ----

    ---- Guest

    Yes, but that's not the point I'm making. I'm talking about P2000's point about exes trying to mimic known system files.


    Global hooks are NOT "rk" territory. How did you get that idea??

    This sounds very good, until you realise the cost of guessing wrong. Besides, if any security procedure has exactly 50% chance of being right, you are no better off than in the original situtation without it. You might as well flip a coin and randomly terminate processes without using it.


    You miss the point.

    That is because leak tests are proof of concepts. So you need to understand what is the source of vulnerability they are exploiting.

    Trival example,some tests work only if you have IE not because it works only against IE, but because it's a file most people have.

    But if you don't use IE and the test fails doesn't mean the same technique cannot be used against another trusted app. It's simple for it to modified to have a list of trusted apps to look for, eg all browsers.

    Or perhaps your firewall 'cheats' by automatically disallowing the tool from starting based on the hash etc.

    It's a point made on the leaktester sites with varying degrees of complexity.

    You can trivally pass a lot of tests,and you feel safer, but if you don't really close the hole that it is exploiting, this is just a false sense of security.

    Clear, Stevie O?










    StevieO[/QUOTE]
     
  10. StevieO

    StevieO Guest

    Guest ----

    "I'm talking about P2000's point about exes trying to mimic known system files"

    Ok.

    I got the Global hooks ARE territory idea from various places, including these two !

    . . .


    Hooks are mechanisms that allow processes to intercept data intended for other processes, such as messages, keyboard strokes, mouse movements and so on. To do this, the process wanting to apply the hook calls the SetWindowsHookEx function in user32.dll, which in turn loads the DLL into all other processes that use the user32.dll file (which is most, but not all of the processes on your system). This allows for extra functionality, but also can be abused by malicious software such as trojans.


    The Firehole leaktest uses a global hook (by calling the SetWindowsHookEx function in user32.dll) to load its DLL into all other processes that use the user32.dll file, such as Internet Explorer.


    Looking at the main Process Guard window we can see that Internet Explorer is protected by Process Guard, and that the Firehole program was prevented from creating a global hook:

    http://diamondcs.com.au/processguard/index.php?page=attack-hooks

    . . .

    Analysis of a win32 Userland Rootkit

    Setting a global hook to take over userland:

    To be efficient, the rootkit must run under all visible applications that may reveal unwanted presence. Performing an injection try for each running process when the rootkit loads is not a good idea since it won't affect processes that would be run later. A perfect way to achieve this is to set a system wide hook, using SetWindowsHookEx for WH_CBT events. Therefore, the rootkit's dll will be injected into all running graphical processes, as soon, as they appear on screen. Unfortunately, the WH_CBT concerns only processes using user32.dll, therefore it won't affect some console programs. This is the case of windows cmd, netstat, and so on. Thereby, the rootkit must also affect processes so that it will be notified and injected when a process creation is about to be done. This is achieved by hooking the CreateProcessW function into all injected processes. This way, the rootkit will be running inside any newly created process. The CreateProcessW replacement and the system hook are complementary methods.

    http://www.securiteam.com/securityreviews/5FP0E0AGAC.html

    . . .

    If a proof of concept actually works, then it's not a POC anymore, and can be used against systems !

    "You can trivally pass a lot of tests,and you feel safer, but if you don't really close the hole that it is exploiting, this is just a false sense of security."

    Agreed.


    Clear thanks, you too ?


    StevieO
     
  11. HandsOff

    HandsOff Registered Member

    Joined:
    Sep 16, 2003
    Posts:
    1,946
    Location:
    Bay Area, California
    Ghost and Guest-

    I may have to modify some of my ideas in light of your comments, however, in other cases I think I was misunderstood.

    "And I'm concerned that other than AV and AT, there is nothing else to protect the homeuser from malware bundled in. All the HIPS hype going around either don't address this danger at all, or at best do it very ineffectively"
    - interesting. It is sad that people are conned into buying a machine with "restore" disks. This is a personal opinion, but I think it is an abuse of consumers with the net effect of coercing/manipulating many users to reinstall things that they do not need, or want, or understand. And then there is the issue of what is on those disks.

    "Seriously I thought all this knowledge was assumed to be present before you start messing with leak tests."
    -I guess I made an assumption too. I guess my interpretation of the theme of this thread *Leaktests: Should they be considered in selecting a Firewall* is narrower than how others may consider it.
    my thinking: they man on the street (even less knowledgeable than my self, in many cases) wants to choose a firewall. Should he look for one on the basis of its performance in leaktests? I think we agree the answer is no. You say:"Seriously I thought all this knowledge was assumed to be present before you start messing with leak tests."
    I am trying to say: Some firewalls are easier for people to use. If you don't understand the things I mentioned, then don't worry about leaktests. Select a program that works well for you.


    "It may be littered with stuff, but they almost never connect outwards through your firewall."

    I'm not sure I agree with this one. I recently scanned my programs to see which ones have the capability of connecting to the internet. There were over 400. I hope you are right that they connect from their own little plots of land on the hard drive but this would be an assumption, especially considering that they may be doing so through Microsoft dlls or the brower, e-mail client, who knows what else. Now i mean 400+ are capable of connecting...if not restricted by, the firewall ect...I think that a very strong function of the firewall is to monitor this and provide you away to go through and just take that ability away in most cases. Of the 400, probably 30 might need to have that access. That is why I hit the ceiling with regard to the subject of why i consider my programs to be the real enemy. For the record the balance of those programs have never had access (at least if they are truly blocked)

    "Another rules of the thumb, something that has a extremely randomised name or a name that is almost but not quite the same as an existing system file is almost always malware. "
    -This is a good point, however, I always wonder why can't something have a name that is reasonably discriptive about origin, task, maker, or ANY system that does not. I think we don't aim high enough with our expectations. I'd love to see a windows where virtually all processes could be clearly understood by their names, there properties, their location. I know some people will say that we can't control this, and that may be.

    -"Originally Posted by Handsoff
    The good firewall, just like almost all good security programs tells you things you would not otherwise know.
    -Errr, I disagree, I think. I favor full control by the user only, rather than any automated decisions. Obviously this cannot occur due to differing levels of user knowledge.
    -I did not mean that automation was good. Monitoring and providing you information that is not available easily through other means. In other words to justify its existence I have to have more direct control over program activity. But your point about user knowledge is true. Though I would point out that a lot less knowledge would be essential if the programs did their jobs better. I hate it when I look at menu's and settings that are cryptic.


    -Originally Posted by Handsoff
    ...until I, the nominal boss of the computer, have said yes or no.
    -Ah, here's the point. You cannot have better control over the firewall without better user knowledge and with it more input from you. Consequently, most firewalls make decisions for you. Often they create a 'generic' rule which can be made a lot tighter.
    -Yes here is the point. I do not deny that there are people who know computers, and Operating Systems inside and out. These people will be able to secure their computers better than the rest of us, and possibly without even having a third party firewall installed. As interesting as this may be, I choose to limit my firewall selection criteria to ones that will provide reasonably good results that allow me to skip:
    Step 1: Completely master computer.


    Now on to my real point: Thanks for the information people! I have been made aware of some things. I know I need to make some changes before I can say I have met my goals in securing my computer. I still am deciding what next, but I found ideas here that will help. I have always looked for the easy solution. I know I have to master some areas of knowledge, but for every answer, I get two more questions.


    -HandsOff
     
  12. ekerazha

    ekerazha Registered Member

    Joined:
    Jul 22, 2004
    Posts:
    28
    I agree with kareldjag.

    A firewall is a firewall. As I've already said in another thread:

    "a firewall should open/close ports for incoming/outgoing tcp/udp(/igmp) traffic from/to another host. That's all. Only this.".

    However, "if you admit "application firewalling" capabilities then you cannot separate them from "proactive actions" capabilities".

    So there's an illogic categorization, because:

    Firewall != "Application Firewall"

    and

    Application Firewall = Network Firewalling + "System Firewalling"

    The actual situation seems to be "Firewall = Firewall + Network Firewalling" and this is an obsolete and wrong approach IMHO :)

    The ideal solution is

    Security Suite = Firewall + Application Firewall ;)
     
  13. gkweb

    gkweb Expert Firewall Tester

    Joined:
    Aug 29, 2003
    Posts:
    1,932
    Location:
    FRANCE, Rouen (76)
    Hello,

    I didn't read all of the posts, I just quickly jump to the end of the thread to post what I am saying on my website's FAQ :
    http://www.firewallleaktester.com/faq.htm#04

    Leaktests results are merely an information that a firewall cannot do everything and protect against everything.
    That does not mean that you have to uninstall your firewall if it has a poor leaktest score, it is just information.

    The solution is not necessarely to switch of firewall, but "simply" to add extra layers of protection, to catch threats that your firewall cannot handle.

    Regards,
    gkweb.
     
  14. ekerazha

    ekerazha Registered Member

    Joined:
    Jul 22, 2004
    Posts:
    28
    This is a wrong approach imo.

    A firewall should be a firewall not an "application handler" or a "leaktest handler". It doesn't have to "catch threats". What you are "testing" (outgoing application-traffic catchers, leaktests catchers etc.) are sandbox-like features, not firewall features.

    "a firewall should open/close ports for incoming/outgoing tcp/udp(/igmp) traffic from/to another host. That's all. Only this."
    Think to a "hardware firewall".

    Firewall != Application Firewall
     
  15. gkweb

    gkweb Expert Firewall Tester

    Joined:
    Aug 29, 2003
    Posts:
    1,932
    Location:
    FRANCE, Rouen (76)
    Hello,

    I do not understand where we disagree ?
    When I say that you have to add security layers to catch threats that you firewall cannot handle, I do not say either it is their job or not to do so.
    It is simply a fact that no matter what they do, they can be bypassed by one way or another, and that you should take measures to ensure a good security level.

    Some firewall vendors claim to secure your computer against all inbound and outbound threats, my website shows it's not the case. Weither it should be to the personal firewall to do something is another question, the first thing created was the application filtering by the firewall vendors, not the leaktests.

    Also, do not forget "network bypass" leaktests such as MBtest or Outbound, which try to pass under the firewall network hook, by using other network library such as WinpCap. Only the packet filtering is stressed with these ones, but still some firewall fail.

    Regards,
    gkweb.
     
  16. kareldjag

    kareldjag Registered Member

    Joined:
    Nov 13, 2004
    Posts:
    622
    Location:
    PARIS AND ITS SUBURBS
    Hi,

    Ekerazha: i've quickly discussed with GkWeb about the same question.
    The most important for me is still packet filtring.
    For leaktests behaviours (dll injection, API hooking etc), this more the role and the function of an HIPS/behavioural blocker/application firewall.
    And most of all, we have to consider that testing packet filtring abilities requires a "know-how" that beginners and classical users don't have:
    an example based on the diploma thesis of Candid Wuest can be found on these pages:

    http://reader.li.ru/article//fido7.ru.internet.security/571

    On the other hand, more the user has products which can catch the malware, more he has chances to detect and block this malware.

    If we consider a line defense with only an antivirus and a firewall without advanced application control, then the attacker can easily bypassed this line defense: i know undetected (by AVs) trojans and keyloggers which can do this.
    Now if we use a firewall with advanced application control abilities like Jetico, the user has more chance to detect this malware.

    Moreover, since a firewall does its job (packet filtring), then Firewallleaktester is good site which can help a potential consumer to choose a firewall.

    Regards
     
  17. ekerazha

    ekerazha Registered Member

    Joined:
    Jul 22, 2004
    Posts:
    28
    They are not "bypassed". That is the normal job of a firewall. A firewall doesn't have to handle application-specific traffic. They have global rules. Application-specific traffic should be handled by "application firewalling" programs, that is a different thing.

    Yes... because they have added "application firewalling" capabilities. So you are not testing a "firewall" but an "application firewall". This is why the distinction between "leaktests blocked by proactive systems" and "not-proactive systems" you did is not very coherent imo... it's always an "application firewalling" thing.

    Of course. As I've already said (maybe in another thread) I'm talking about "some" leaktests, not all of them. "Outbound"-like situations should be definitely handled.
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.