GentleSecurity

[VanguardLH]

There is an option to disable notifications. There are policy and attack notifications. If notification is disabled, do just the policy notifications get eliminated but the attack notifications remain?

[geswall]

The attack notification could be disabled in GeSWall Professional Edition, you should try it.

[VanguardLH]

Right now I'm trialing various free security products and am comparing them.

From what I've seen, disabling the notifications only gets rid of the policy alerts. The attack alerts are still shown. That's good because they are more critical; however, as noted in another thread, I see no way to take an action or define a rule at the time an attack alert appears. With other HIPS products, I get the alert and can select Allow or Block (usually with some other options and whether to remember my choice). That generates a rule (if I remember my selection). With attack alerts from GesWall, I just get notification and would have to figure out what to do when separately (and disconnected from the event) defining a rule. Sometimes the logs might help but not if a lot of apps or processes were generating log entries at the same time.

Also, it seems that GesWall is catching a pest a bit too late. After Googling around, I finally found a site that wanted to pretend that I had infections and would attempt to install AntiVirus 2009 (under some other product name but it was the same pest). With GesWall, the download was allowed plus the install program was allowed to run. GesWall didn't kick in until after I selected English for the language of the setup program and when it attempted to create/copy a file into the Windows\system32 directory. To be fair, I had no anti-virus software installed in my test platform. I wanted to see what GesWall would do in case the AV program didn't catch the pest.

So GesWall eventually triggered on the AV2009 pest. However, a HIPS program, like Comodo's Defense+ in their CFP3, catches earlier the pest by alerting on the unknown install program wanting to load. Yet for both GesWall and CFP3 Defense+, they let the pest into the host and alert after it gets loaded. Something like Faronics Anti-Executable wouldn't of even allowed the file to show up on the host (but then you have to maintain a whitelist of allowed programs). In a way, the HIPS program (for the type that watches what tries to load into memory) is also a whitelisting program in that it only lets programs that you've allowed to load but not until you try to run it. Anti-Executable prevents the executable file from ever getting onto the host. Alas, Anti-Executable has no free version so it isn't getting tested by me in my current free security trials (so what I know of it is what I read, not what I experienced).

So back to my original question, the answer is that disabling notification apparently gets rid of only the policy alerts but keeps the attack alerts. That is what I hoped for. Unfortunately, I cannot keep the attack alerts on the screen in the popup window so I can still read them when I can afford to be interrupted to go read them. The maximum delay before they disappear is only 5 seconds. There is no differentiation between policy and attack events in the log so I can't tell which were which to determine how I would define a rule (which is after the event instead of during a pending event).

Alas, although GesWall alerted on the file that the AV2009 installer wanted to put into the Windows\system32 folder ("DENY access to C:\WINDOWS\system32\sysbase32.dll" in the log), and although it prevented that file from copying there, this did NOT prevent the AV2009 from completing its install. When I ran it, GesWall prompted whether to run isolated or not. I said yes, this allowed the pest to run (despite that it apparently blocked some but not all file copying during its install) in an isolated shell but all the windows showed each that was started by the pest were also isolated. The free version of GesWall doesn't let me terminate the isolated processes. Closing all the windows displayed by the pest doesn't eliminate the scan.exe process (that will pop open the windows again). You'll need to kill that process yourself. So while GesWall gave some alerts, it didn't stop the install, didn't give me an option to stop the install, only prevented one file copy which wasn't required for the pest to operate, and required me to use Task Manager to stop the pest from repeatedly misbehaving. Reverting to a snapshot got rid of the pest (and also GesWall).

[geswall]

[geswall]

[geswall]

[geswall]

[VanguardLH]

[VanguardLH]

[geswall]

[geswall]

[VanguardLH]

In the test of the AV2009 malware and GesWall, I let it pretend that it found malware on my host, downloaded it, and ran the install. When I ran the install file, and because GesWall was tracking this file as untrusted, I got a prompt as to whether to run the install in isolated or non-isolated mode. Herein lies the trap: the user might choose to run the install in non-isolated mode. After all, due to the social engineering of duping them into downloading their software in the first place, it might also convince the user that they must not run in isolated mode.

There have been many documented analysis of system emulators, virtual machines, and sandboxes that have been test for security against malware. I don't recall that they claimed the pest punched out of system emulators or VMs but there were some that got outside the sandbox (because they are not as complete as the other 2 methods). Mostly the malware goes dark if it sees it is operating in an environment which can obviates its behavior, like reverting to snapshot to get rid of the pest. In the past, such security-aware malware would go dark so the user might think it was okay and install it in their production environment. However, if it detects it is under a security environment, it might choose to further socially engineer the user by declaring that the product will not function under that environment. It will announce that it cannot run under an emulator, VM, sandbox, and also declare that it must not be ran isolated (if it detects the GesWall environment). So just like the user was duped into downloading their malware, they could also be duped into running the install or the program after install in a non-isolated mode.

GesWall did NOT prevent the infiltration of the AV2009 malware. It prevented one file from getting copied under \Windows\system32 but apparently it isn't critical to the operation of this malware. All the other files were allowed to install. Because the malware was downloaded from an instance of IE that was isolated, and only because I choose to run the downloaded file in isolated mode when prompted by GesWall (a weak spot since it relies on a user choice), its desktop shortcut, Start menu shortcuts, and files had the "G" overlay icon because GesWall was tracking those files (although it requires a manually initiated scan in GesWall to actually get them listed under the Untrusted Files section). So whenever I try to run the pest, GesWall would prompt whether to run in isolated or non-isolated mode (I'd rather see Isolated and Non-Isolated for button labels instead of Yes or No to ensure the user picks the correct mode rather than as an answer to a question). However, if the product runs isolated and detects such, it could issue a prompt to the user that the product will not function in isolated mode and that the user must restart in non-isolated mode. Again, since the user was duped into getting the malware in the first place and since GesWall didn't actually stop the installation, the user might choose to follow that advice and run their program in non-isolated mode. So, again, we're back to the weak link where the user gets a choice.

So the reasons for not having user choices regarding the policy and alert prompts doesn't make sense since the user will still making decisions later. I understand that it may be impossible to get around user ignorance or them overriding the security software; however, I don't see an option mentioned where any untrusted files for an install can be wiped from the host (which would almost require tracking equivalent to Zsoft Uninstaller although perhaps GesWall is as thorough) and force the user to redo the download and install but have to elect to trust it if they really wanted it. That is, they don't get to choose to trust something that was untrusted, and they can only wipe it from their host and start over but have to then trust it. While I might be expert enough to know that I would be very leery of running any untrusted app as trusted, I really don't see this as typical of a normal user. I don't personally know of malware that detects GesWall and then prompts the user to run their software in non-isolated mode, but detection of GesWall is obviously trivial. If they convinced the user to download and/or install their pest, they could probably also convince that user to run it non-isolated. They've been duped once. Duping them again is probably even easier.

From what I've seen GesWall doesn't prevent all pests from getting into the user's host but it can try to control how it operates once there but the user still gets a choice (which maybe they shouldn't have). Does the professional version have an option to force a wipe of an untrusted application from the host (on a per-application level so only a particular untrusted application gets wiped instead of all of them) rather than letting them have a choice of running the app in isolated or non-isolated mode? Since GesWall may not prevent a pest from depositing itself in a host, have a choice of running isolated or non-isolated doesn't seem protective enough except by expert users (who can still make the wrong choice).

[geswall]

[VanguardLH]

[geswall]