Hi. I would like to disable all HIPS features so that Outpost works as a simple two-way firewall (prompting on attempted outbound connections). There are a bunch of settings (anti-leak, system guard and application guard) but I´m not sure if all three need to be disabled for the constant prompts on almost all file activity stop. Thanks in advance.
jhr76 Hello Outpost firewall is not the easiest program to do this but.. if I remember correctly... Turn off the functionality under Proactive Protection (anti-leak) 'Web Control' I would not..but you could try it jhr76 by any chance are you running NOD32? I would turn HIPS of on that for sure
I am using NOD32, and Outpost wouldn´t install while it was installed, so I had to uninstall it first and reinstall it after Outpost was installed. So far I haven´t run into any conflicts. I also have HIPS off in NOD32, I find HIPS features to be very obtrussive in general.
Salut, There is not a « HIPS » in Outpost since VISTA, have you seen a HIPS ? no hooks in kernel with patchguard, there is proactivity based on dynamic heuristic ( sand box ). If you want only a firewall, disable only « active protection »
don't be a propaganda victim. there IS indeed a HIPS module in agnitum's OPFW and OSS x86 AND x64. you can turn off/on component control in the advanced settings, but it is there. you can also edit the 'known components' list it produces. current version is 9.2 and is win7, vista, win8.x, win10 compatible. some xp user have trouble with 9.2 & use 9.1 instead.
http://www.outpostfirewall.com/forum/showthread.php?27593-NSA-Backdoors-In-Firewalls/page2 « Originally Posted by PhilGreg Several years ago I posted a question to Agnitum about backdoors. I cannot recall the exact words but in essence I asked if Agnitum would install a backdoor into its firewall if requested to do so by any government. Agnitum's response was 'Yes'. » Where is propaganda ?
Is this not an application modification detection by Outpost's network filter that was triggered from an existing firewall rule? That is how it works for Eset Smart Security. Don't see how this has anything to do with HIPS monitoring?
no,itman, it is from the 'proactive protection' component control module, nothing to do with the network/firewall rules which themselves have nothing to do with whether an application has been modified. the firewall system & low level network rules govern which network protocols can or cannot connect to which sites on which ports. there are however, controls to fine-tune the more generic system/lan networking rules as well as component controls and anti-leak functions to override some of the proactive protection settings on a per-app basis. there is a rules hierarchy, the list is (in part) as follows varying from coarsest to finest control IP Blocklist (blacklist) - highest priority low level rules system firewall rules lan rules application rules it works thru the list top down until it hits a rule that applies, allow or block. you can also set an overall policy from the gui tray icon to block everything, 'block most' where everything that does not have allow rules is blocked, rules 'wizard' mode that prompts you incessantly for your input to create rules where it is not sure, a learning mode that makes up rules for you when you are installing stuff (and should not be used normally) an allow most mode (for weak normal running - it allows anything you have not made rules to block - not recommended) and an allow all mode (use very short term for diagnostics). a hips system ensures that the registry is monitored for changes, applications and components are also monitored for changes and for suspicious activity. outpost (OSS & OPFW) does all of those in the 'proactive protection' components and can be configured in the advanced setting as i noted. it does have a 'heuristics' scanning component to protect against dangerous activity. the anti malware component in OSS also has a real-time heuristic analysis function that can be set to a normal or in-depth setting. as noted earlier, these can in general be overridden by application rules. Outpost has a fairly fine granularity and there are a number of ways of accomplishing the same thing at various levels from generic to more & more specific.
Is it possible you can post what the default registry rules are? That topic came up in another Outpost thread currently active in this forum section. Also could you post a ref. link to details on HIPS functions and rule creation?
https://msdn.microsoft.com/en-us/library/ff556954.aspx « Purpose of Callout Drivers ( in WFP ) A callout driver implements one or more callouts. Callouts extend the capabilities of the Windows Filtering Platform by processing TCP/IP-based network data in ways that are beyond the scope of the simple filtering functionality. Callouts are typically used to do the following tasks: Deep Inspection Perform complex inspection of the network data to determine which data should be blocked, which data should be permitted, and which data should be passed to another filter. An antivirus product, for example, could look for virus signatures. » https://msdn.microsoft.com/en-us/library/ff543874.aspx « Callout Driver A callout driver is a kernel-mode driver that implements one or more callouts. » kernel-mode … not possible for Outpost firewall in 64 bits since Vista. " what the default registry rules are? " The Outpost rule is « ask », like a HIPS ( old unstable thing ), but dynamic heuristic do it with user mode hooks and API.
My testing with behavior blocker dynamic heuristics shows it total ineffective against memory based dll injection; as least using Eset's advanced heuristics. So I stick with HIPS process modification, event interception, and global hooking prevention rules which are effective against memory modification.
" I stick with HIPS process modification, event interception, and global hooking prevention rules " Make a prayer ... and they go back.
It looks to me like parts of this kernel/user mode debate is a replay of events from 2006, nine years old, http://www.outpostfirewall.com/foru...mode-hooks-%96-what%92s-best-for-the-firewall where the document mentioned here several times is referenced. That document also mentions that they use a mix of kernel and user mode hooks. Anyway, What do we know about the current state? How do we find out?
I would imagine its still a mix.Some info about improving kernel drivers here... http://www.agnitum.com/support/kb/article.php?id=1000215 I guess agnitum support would be the ones to contact if you really wanted in depth answer.
It's indeed an old discussion. Back then, security tool providers were afraid that they wouldn't be able to provide the same level as protection, when they couldn't modify the kernel anymore, but that has been addressed a long time ago. If it wasn't, you wouldn't have tools like Zemana, SpyShelter, HMPA and MBAE to name a few, they all offer quite complex protection.
Hopefully this will resolve the hooking issue. Kernel hooking not done by Outpost on Vista+ x64 OS's due to patch guard: http://dl2.agnitum.com/pr/Kernel_mode_hooks_or_user_mode_hooks.pdf Does any AV vendor with a HIPS/Behavior Blocker do x64 w/PatchGuard kernel hooking? None that I am aware of.
itman, unless I'm blind, that .pdf is exactly the 2006 writeup mentioned in the link I wrote in post#19 (Edited post#), all 3 pages of it.
The link you posted in post #20 is just for release changes. You posted a link in #19 which was a Matousec rebuttal posting about kernel vs. user hooks. But it didn't clearly state that Outpost does not hook the x64 OS kernel.
itman, I just edited that it was in post#19, not 20, sorry. Did you read the pdf atachment in the outpost forum post? Yes, their rebuttal post is from 2006, therefore their .pdf linked in that thread is unlikely to be later, and it matches what you wrote in post#22 .