Hints on using Online Armor FW-a Learning Thread 4

To thread followers,

As you may be reading between the lines here I ask for patience as I"m waiting a week or so to before commenting on Mike's post here.

Experience has taught me that that in the face of too much emotion and lost effort on my part leads to unproductive posts or worse flaming.

I will respond to email queries from Wilder's members. Use the email addy in my profile.

More later

 

FWIW, I cannot assure this thread that any of the hints or advice for OA apply equally to all beta software.

They are intended for OA and no other software. Any generalizations are at the readers own risk.

 

As I indicated a few posts back:

So continuing on to shed light on the use of OA 190 here is a finding for the thread:

As I do, many here probably probably use PerfectDisk 2008 for de-fragmentation and other file management work.

Well OA 190 identifies a trusted Keylogger in PD 2008 see my attached jpg. OA trusts this KL.

So I did a small test and choose to tweak OA and I blocked the PD 2008 KL, as I don't trust any KL and followed my own security policy of block by default and allow by exception.

Without a policy users are deferring to the vendors security policies.

The first result when I tried to do a product update was PD 2008 said you have no www connection (but I did) so that was wrong on the part of PD 2008. See the jpg message I got.

Closing that pop up message, I tried again to do the product update and surprise surprise the update worked so the KL is NOT really required for PD 2008 updates to work. see jpgs

My theory is that the KL for PD 2008 is a thin cover for a KL based on the update need.

OA only saw to this level when deciding to trust this KL. I don't see why a legit SW product like PD 2008 even needs a KL and for sure I don't see why OA trusts it.

Moral, do your own tests on all your updaters see if KL are tagged, and block them all until YOU know they are really really needed.

 

It is easy in OA, to block a "trusted" KL that should not be in the trusted list.

IMO it is not beyond the level of the readers in this thread.

The point is about trust and verify, users can choose to test what OA does and NOT just accept out of the box settings. If OA believes that users should not test these things the block/accept settings for KL should be removed.

One of the main benefits of OA is the white list concept but in this case the KL was white listed ie trusted and in my view and test it is an OA error.

 

Hi Escalader,

What is the impact on PD2008 if the keylogger type behaviour is blocked?


Mike

 

Absolutely zip. All works well the update proceeds and the defrags are successful.

QED

 

Sounds good.

How did you verify that?

 

Because its the OP philosophy, anything is trusted by exception.
Not the first time users (including myself) raised your same question

The important thing is that anyone doing this is aware of the possible consequences, like system or program malfunctions that most of the time are not really visible to the end user.

OP is perfectly aware of it and happy to follow his approach.
So, happy tuning!

Cheers,
Fax

 

Very helpful to understand *why* the back-ups issue can be a dice roll during beta testing. Of course, we should always be aware that things might change (via optimization, in this case), but explaining the "why" does give peace of mind.




//

 

Users need their own security policy. I have mine and it is well known.

Other's have no policy and defer to all the vendors SW they install on THEIR computers even though they may not know this or care.

Other's have a trust all things on THEIR computer and work from that premise. They then rely on the same vendors settings to keep their PC's clean. They know the risks of the trust all approach.

But again this thread is not about policies mine or anybody elses it is a hints/learning thread.

As far as the KL for PD 2008 is concerned OA 190 found it I block it and have not expereinced any lose of function. This was determined by my verification tests. It is for PD to explain why they have a KL at all and for OA to explain why they have a false positive or is it a false negative?

I'm moving on now to some more tests on KL since if there is one FP/FN their might be more. See attached jpg

 

It's okay Pete, Fax doesn't doesn't to speak for me or explain my posts. That is my job alone.

FWIW as you know, I don't agree with the notion that vendors are to be given a pass and that new users are safe out of the box. They should use the provided by OA options to optimize their set up. Otherwise why have options in OA? Examples are many and I will continue to provide the very best help I can to optimize users OA setup.

Remember the computer interface debate? Now due to the efforts of a few, the trust tick is there. In standard mode or advanced. OA IMHO incorrectly defaults it to trust. You may honestly believe it is not important BUT I do and will continue to say this.

So if the newbie or new user does anything they should untick that one setting. But I doubt many moms and pops or true newbies are here anyway. If they are should seek the support over at your TalEmu forum as well.

 

Of course I don't, I have always questioned your approach that adds very little to security as compared to time spent on tuning.

But, this is your thread... so, best of luck

Fax

 

By testing PD 2008. The question I put is how did OA determine that the KL was safe? Did your guys test PD 2008 with and without the KL trusted and untrusted?

My tests don't matter as I'm only a user in a user thread.

What matters is the completness of the vendors tests. If it were me I would ask PD 2008 to justify their KL before slapping a trust lable on it. A digital signature from a trusted vendor is not suffient IMHO. I know you have a check list before a exe is "trusted" but does that mean any KL imbedded in the SW are accepted then by default?

Quicken also has a KL, but OA doesn't trust Quicken due to direct HD access. So my theory for now until you say otherwise Mike is if a exe is trusted by OA like PD 2008 so are any KL riding along with that SW. The reverse is also my theory that if the exe is not whitelisted and untrusted so are any KL riding with it.

If thread readers are surprised that some reputable vendors use KL they shouldn't be.

Enjoy the day!

 

Pete:

Yes, your example and clarifications are good, I like them.

But my technical questions to OA are still unanswered.

If it is easier, just substitute Keylogger Behaviour (or KLB) for KL in my recent posts and you are good to go.

Does OA assume that KLB on whitelisted exe's are safe by default? and the reverse.

These questions are technical not FUD. FUD does not use testing just rumors and fear. I don't believe in rumours or give in to fear.

Work continues

 

Hello Thread readers lurkers and contributors:

I have created a OA feature usage poll at:https://www.wilderssecurity.com/showthread.php?t=231569

It will assist me in targeting future tests and hints on OA optimization.

Thanks

 

Well, it's Australia Day here, so I'll be off for a BBQ and a Beer today

There seems to be a bit of a misconception here about what Trusted Programs are, and how OA is supposed to work. Since I am not personally famililar with Perfect Disk, I'll use Yahoo Messenger as my example.

So - what's OA supposed to do ? Well, it is supposed to help you keep your computer clean, and it's supposed to stop the bad guys from getting data off your computer or phishing out your banking details. There's a bit of this and a bit of that which blends together to try and cover various threat vectors , infection methods, and curious or interesting behaviours that can, or are used by malware.

Our design philosphy with respect to a trusted program, is that a trusted program is just that: trusted. For example, you would no more expect a program like Yahoo Instant Messenger to record your keystrokes any more than you'd check the pockets of a priest before he leaves your home.

So - a trusted program, unmodified, should be allowed whatever access it requires to do it's job. Otherwise - you don't really trust it.

When we look at things like possible keylogger behaviours, we have to be careful. Yahoo IM exhibited a keylogger behaviour, and while this could technically be used to record keystrokes (if they wrote the software to do it) what it actually appeared to be used for is to detect keyboard idle , so it can set you automatically as "away".

I have previously, and seemingly successfully blocked this with no apparent ill effect (save that the idle detection didn't work, something that I am not all to concerned about). However, when you block things like this what you are doing is forcefully causing some kind of error in someone elses code (in this case yahoo).

It then depends on how well Yahoo (or in your case, Perfect Disk) handle this error.

You have no idea why they have the keyboard hook there -(if it was a keyboard hook) - or what it's used for, or how well they have written the error handling if they are unable to obtain such a hook. All you know is that the program exhibits a behaviour that OA knows could, in theory, be used to record keystrokes - and that, if you block it - you do not visuallly notice any negatives.

As for the whitelist - your assumptions about quicken are not correct. It's just that program hasn't yet been looked at an placed on the whitelist. It has nothing to do with what it does.

Our approval logic goes something like this:

This is <company name>. They make extremely well known <productX>. Is this software legitimate software? If so, add it to the trusted list.

Certainly, when we look at unknown or lesser known programs, we take the behavioural characteristics into account - but for things such as Yahoo we trust it. It's not malicious, and it would be commercial suicide for the vendor to do anything silly.

We are not policing whether Winamp, or Office 2007 does certain things. Our whitelisting mechanism is designed to prevent unneeded popups for trusted programs.

I have to run now to avoid spousal aggro - but I can explain in more detail tomorrow if you have questions on this.

mike

 

One of the options in OA 190 is to remove / uninstall the FW engine in the case of "incompatibility". So my next experiment now underway is to assume that and remove the FW engine. That has been completed.

The first thing to check is did the windows xp FW get turned back on it did so that is good.

In theory now, I seem to have a HIPS from OA plus the 2 shields for web and mail. On a quick check, some of the FW settings are still there and I can access the program file options and click run safer but the setting doesn't take. THis is confusing for sure.

More later, I'm now about to install another FW just to see what happens. Maybe if I have another FW OA will let me run browsers safer. We will see.

 

Well that didn't work because the new FW installer disabled ALL of the 3 remaining feature of OA IF I can believe the empty boxes on pop up 1 on configuration. However I was able to change an unknown program to trusted in the edit program function. So this result is contradictory.

What I will do is uninstall OA and see if I can get this done using a different order of install.

I'm back!

Did not have to uninstall OA ! All I had to do was reactivate HIPS features.

I now have OA HIPS and 2 shields working with a completely different FW engine. It is two way and is a bit easier to set up the ip connect rules application by application as it lets me automatically insert the appropriate ip addy's as well as the identifying of the resolved web site so I know I'm on the correct site without having to research each one. But I'm not here to promote this FW at all just to test if the use of a different FW can work. So far I can say it does work. Just be careful not to double up on HIPS function while doing this.

I'm going to see next if run safer from OA fouls up my www connectivity.

 

After adjusting the FW settings to trust for the intel adapter the www connectivity is fine.

I found as well that OA 190 correctly remembered all the following setting upon rebooting:

1) FF, IE7 and explorer were all okay as Run Safer and retain the green boarders to indicate the limited user status provided by OA. So it seems the OA FW engine is not required by the user to exploit that feature.

2) OA correctly remembered that the OA FW engine was not installed

3) Clear the history table worked fine when I used that option

4) However, OA still left it's own FW options re logging etc ticked in the options tab.

5) The clearing of unknown www sites worked on reboot.

Whether these finding would hold for "all" other FW's other than the one I'm using in the hybrid setup is extremely unlikely.

My next test is to try now to reinstall the OA 190 FW with the alternate FW engine in place to see what kind of trouble this causes.


More later


I'm back, well very little real trouble. When I clicked on reinstall OA FW in options, at first all I got was a long boring hourglass. To get rid of that I had to close off Nod32 and SAS.

Then the OA FW came back with all my 190 Rules settings etc, this was good.

BUT here comes the fast ball OA gave no warning about the presence of the "Other FW" and let it continue running in parallel with OA FW engine.

This is NOT good and I suggest to OA that they at least provide a warning message or better "force" user to uninstall the other product.

Next I'm going to see what happens after the following steps:

1) I uninstall Brand x ( the other FW)
2) I attempt to restore my settings saved when I had OA FW engine removed.
3) To be safe I will backup my settings as they are now with OA FW back in it's slot.

More later