Is using Ghostwall + Appdefend enough?

Discussion in 'Other Ghost Security Software' started by dja2k, Oct 5, 2006.

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

    dja2k Registered Member

    Joined:
    Feb 15, 2005
    Posts:
    2,040
    Location:
    South Texas, USA
    Would you trust Ghostwall and Appdefend to control inbound and outbound plus application control? What are your comments and reasons for saying "yes" or "no" ?

    dja2k
     
  2. Hermescomputers

    Hermescomputers Registered Member

    Joined:
    Jan 9, 2006
    Posts:
    1,069
    Location:
    Toronto, Ontario, Canada, eh?
    I do use both in a Win X64 platform. It works. I love the light weight of Ghostwall and its easy configuration. I can customise it to my hearths content. The only concern with it is that Port 0 & 1 are closed but visible until you configure it properly.
    https://www.wilderssecurity.com/showthread.php?t=148627

    As for app defend I realised recently that in its current format it is vulnerable. To a few process termination techniques... Not to worry since a process able to do so must be activated and be installed first to bypass AD.. You should at least see it comming... hopefully.

    The article is here:
    https://www.wilderssecurity.com/showthread.php?t=148725

    However I use VMware to do all my high risk stuff. Makes things a lot safer to recover from hacks or infections and it works.

    https://www.wilderssecurity.com/showthread.php?p=851953#post851953

    My point to this is that if you create a virtual machine. Load App defend and ghostwall, you will be further ahead in securising your environment than enything else you can think of... You keep you primary (Host) OS clean and your (GUest) is the only one exposed... It works!
     
    Last edited: Oct 5, 2006
  3. dja2k

    dja2k Registered Member

    Joined:
    Feb 15, 2005
    Posts:
    2,040
    Location:
    South Texas, USA
    Thanks for the detailed reply. By the way, do you know how Ghostwall compares to inbound protection of Look'n'Stop or maybe CHX-I?

    dja2k
     
  4. Alphalutra1

    Alphalutra1 Registered Member

    Joined:
    Dec 17, 2005
    Posts:
    1,160
    Location:
    127.0.0.0/255.0.0.0
    I think that Ghostwall lacks the SPI found in these products, but if you can configure packet filtering rules well enough, it will give basically the same protection.

    Alphalutra1
     
  5. WSFuser

    WSFuser Registered Member

    Joined:
    Oct 7, 2004
    Posts:
    10,632
    it might be ok, but i prefer having closer integration of rules and application control. at least so the ports only open when u run the particular application.
     
  6. Hermescomputers

    Hermescomputers Registered Member

    Joined:
    Jan 9, 2006
    Posts:
    1,069
    Location:
    Toronto, Ontario, Canada, eh?

    I think CHX-I is more thorough in its filtering (Read Rules) but quite a bit more work to config and maintain. Never tried Look n Stop.
     
  7. Hermescomputers

    Hermescomputers Registered Member

    Joined:
    Jan 9, 2006
    Posts:
    1,069
    Location:
    Toronto, Ontario, Canada, eh?

    I think you get a much better application control out of an app like Appdefend than you would out of most firewalls implementation of it. Besides you are not attempting to control applications but processes. Each and every processes are in turn using sub systems which must also be monitored. I personally like the idea of specialised focus.

    I feel better when I can manage clear and concise modules than an enormous applications suite doing too many things on my behalf and cloaking vital events. It usually ends up createing a false sense of safety under which people tend to delegate mindlessly and leading to exploits.
     
  8. WSFuser

    WSFuser Registered Member

    Joined:
    Oct 7, 2004
    Posts:
    10,632
    maybe, but what i meant is that with a packet filter (like ghostwall), u either have a port open or closed. u cant open a port for a particular process then close the port.
     
  9. Hermescomputers

    Hermescomputers Registered Member

    Joined:
    Jan 9, 2006
    Posts:
    1,069
    Location:
    Toronto, Ontario, Canada, eh?
    True... You do miss on the dynamic automation elements...
    However I do manage my firewall in real time.
    When I need a port open I create a mobile rule for it and move it up into the "Live" area which is above the "Block All Protocols" area.
    Then I move it out of the "Live" area and below the Block All Protocol Area when I'm done... Simple enough I think and it works.
     

    Attached Files:

    Last edited: Oct 6, 2006
  10. dja2k

    dja2k Registered Member

    Joined:
    Feb 15, 2005
    Posts:
    2,040
    Location:
    South Texas, USA
    Amazing! :D

    dja2k
     
    Last edited: Oct 6, 2006
  11. dja2k

    dja2k Registered Member

    Joined:
    Feb 15, 2005
    Posts:
    2,040
    Location:
    South Texas, USA
    By the way, this way of blocking internet access gives you only open or closed ports right, not stealth? Also thanks for the image, helps a lot.

    dja2k
     
    Last edited: Oct 6, 2006
  12. Hermescomputers

    Hermescomputers Registered Member

    Joined:
    Jan 9, 2006
    Posts:
    1,069
    Location:
    Toronto, Ontario, Canada, eh?
    Right... But regardless when you "Open" a port you loose all cloaking for the duration. My guess is that pretty much all such apps do so. Besides During the event you have an applications (Read Process) Listening for traffic on that open port it is effectivelly delegating possible exploit to vulnerabilities inherent to the listening application...

    My guess is it is still fairly difficult to exploit those weaknesses during the short duration the port is actually open. Too many variables in play, also considering the Dynamic IP rotation of my DSL...

    It is certainly more work to manage things this way but it keeps your mind focused on traffic and security related matters. Keeps you sharp!
     
    Last edited: Oct 6, 2006
Thread Status:
Not open for further replies.