For Stem,Wat0114,Diver(and others)-what firewall do you recommend me?

It would be down to your own choice, but also on what level of protection you want. I dont want to get too involved with a discussion on HIPs, as this is the wrong forum. But briefly, with possibilities.
SSM (System Safety Monitor) This is good protection, but does lack in the area of folder(file) protection(access rights) and dll control.
PS (ProSecurity) Good protection, that does give the added benifit of folder(file) protection(access rights) and dll control. But be aware that the program does need time to "learn", you would also need to leave the "dll" control in learning for a while (or you will get a popup for every dll loaded into an application)
NG (Neova Guard) Although still a "beta", gives all-round good protection. It does by default place all system(signed) applications into a trusted group, so can save a lot of popups.

This is down to what description of "most secure". You put forward that you expect a firewall to block kernel level drivers, I do not.

 

Thanks to you Wat0114 and everyone else here for the time and patience.
Cheers!

 

There is a big difference (for me) between a "conflict" and an "overlap" of protection.

Let me try to explain.

The main "conflicts" I see between security software is down to the installation of low level system hooks(or system redirects). These are the entries you can see if you run an application such as "Ice sword"(check the SSDT Table). When security application both attempt to hook into the same function, then problems/conflict (or at best- unpredictable results) can (and usually do) happen.

Such as (what I would class as) an "overlap" of protection, I would see as where 2 security applications are installed, but the installation method/protection is different(where as one security application will low level hook the system and the other does not). This usually leads to no actual low level conflicts, but can give the user a popup from both applications for the same (or similar) event.

Now, looking at Jetico2, I now see no low level system hooking. So I would expect to see no low level conflicts in this area. Of course, I do still need to spend time checking this (and my spare time is very short at the moment) to see if other possible problems would show in testing with Jetico2 and an HIPS.

 

The way I see it, Jetico 2 would need not much more than a basic anti-executable and perhaps registry protection application to supplement it. It is, of course, possible to go with a full blown HIPS and disable most or all the supplemental application protective options in J2 such as Checksum, Process attack & Indirect access filters. A setup like this should probably satisfy all but the most extreme paranoid.

 

Jetico2 is based on internet and applications directly related. It will not protect from internal possible compromise. Only if you where to manually add all applications for protection to the "Indirect access" would (possibly?) internal compromise be added. This is not what users will do,... users may simply see one of their applications attempting indirect access for the first time, this may seem acceptable, but this app may (possibly) be compromised.

 

The Process Attack filter seems to protect on some application activities that are not necessarily network related, but I do see that a full HIPS application will provide better coverage than J2's basic HIPS functionality. The "Indirect access" filter kind of bugs me the way it works in J2. It is possible to create rules based on individual Indirect access types but then, as I'm led to believe, the selection Indirect Relativeness apparently renders those other individual selections (inject dll, create remote thread, write to other's memory ,inter-process call & parent process) completely redundant!

Anyways, it is the firewall functionality with regards to ip/application filtering that matters most to me, and J2 seems to perform this with aplomb

 

After some further consideration, I have completely misunderstood this Indeed, Network and IP filtering will always occur before Indirect access, Process Attack & Checksum filtering takes place in J2.

 

Hello wat0114,

Re: Jetico2
The "process attack" is now working again in this latest build (I have missed installing a couple of builds). Earlier builds only gave me alerts to the "indirect access", but now I am seeing alerts from the "process attack" (such as "direct memory access", "hidden window") but it does appear to be buggy, as it is missing certain events such as global hook.

 

Interesting. I have numerous applications in my Process Attack filter and only Ad munch.exe indicates an allowed "Install global hook" entry. It certainly does seem to be buggy, because I can't believe that only one app could have triggered this. This is something I had not noticed because most of my efforts have been concentrated on fine-tuning the XML config file.

 

That means we don't need new rules for the updated programs?

 

Even with Hash checking enabled you don't need new rules for updated programs, only the need to answer the alerts on programs that have changed due to updates/new versions, since this will possibly cause the checksum to change.