Jetico and ProcessGuard or GSS - and other questions

Discussion in 'other firewalls' started by Kuffi, Sep 18, 2006.

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

    Kuffi Registered Member

    Sep 15, 2006
    I have a few questions questions about the Jetico PFW.

    1.) When I have all those hooking and memory modifying checks enabled in Jetico, would I still need ProcessGuard or GSS?

    2.) If I have Jetico hooking/memory etc. checks enabled, and also use PG or GSS, will I experience a worse performance? Would it be better to disable those Jetico features and just use PG/GSS instead?

    3.) Does Jetico prevent, that some other program modifies the application rule files or other config files?

    4.) Is Jetico just so good, for example against leaktests, because of this hooking/process modify checks? If so, what other improvements would I gain when using Jetico instead of Sygate PFW Pro with PG/GSS (which also block hooks/...) ?

    5.) Sygate Pro should be good because of (among other things) "Driver level protection" and "Block all traffic while service is not loaded"...
    Is this Driver Level Protection needed to improve the security?
    Does Jetico also use this way?
    Is Jetico also able to block traffic, even if Win isn't loaded completely yet?

    Thanks for answering my questions; I hope they aren't too silly :)

  2. tony62

    tony62 Registered Member

    Aug 26, 2005
    if you have an application, such as GSS as i do, then Jetico's Process attack table can be safely disabled: Root-Process Attack Table-Accept. I feel that there would be too much overlap, since GSS already covers all areas that the Proceess Attack Table does.
    GSS and Jetico(I'm still using v1) are extremely light on resources and combined provide excellent protection from all leaktests, present and possibly future.
  3. Kuffi

    Kuffi Registered Member

    Sep 15, 2006
    Perhaps anyone else, for the other questions? :)
  4. Nail

    Nail Registered Member

    Mar 27, 2005
    JPF does not protect Registry, so ProcessGuard would be helpful.

    You can disable JPF proces attack layer. Anyway, performance degradation would be minimal because these events are rare enough.

    JPF v2 beta locks its configuration.

    JPF gives user full control over firewall configuration. You can view/analyze/modify every bit.

    It can protect your TCP/IP stack from inbound attacks at early boot stages.
    JPF does not have it yet.
  5. tlu

    tlu Guest

    For an excellent protection of the registry you should rather chose GSS (with Regdefend).
  6. Alphalutra1

    Alphalutra1 Registered Member

    Dec 17, 2005
    Process guard doesn't defend the registry, so Regdefend is definately the way to go for registry protection.

  7. cthorpe

    cthorpe Registered Member

    Jun 30, 2006
    I use Jetico (v1) and SSM, so I can't speak directly to the questions about PG but SSM is similar to PG in many ways. Jetico seems to catch items in the process attack table before SSM catches them, but SSM catches quite a few more types of things than Jetioc does. I would assume that PG catches more as well, so you could disable the process attack table in Jetico. I haven't noticed any difference in computer speed on my 866 PIII with 512mb ram when I have both Jetico's process attack table and SSM running. The only slowdown comes when an event occurs that triggers those protections as I get an alert from Jetico that I have to click through and then an alert from SSM. I see it as more of a "Are you sure you want to allow that?" than a problem, however.

    As for protecting before logging into the system, Jetico v1 can't do that unless you use a program to run it as a service. I currently use NTWrapper to install Jetico as a service, so it is running as soon as Windows is up.

Similar Threads
  1. bellgamin
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.