Hi Tom,

Thanks for the reply. CSA does not allow itself to be stopped in anything other than safe mode. Can this be changed at the management console?

I can't explicitly allow Sophos to access the registry key because there is no indication from CSA that it is blocking this access. Therefore I'm not sure what rule or policy is casuing this issue. It is the Sophos logs that are reporting the issue.

We've logged a TAC with Cisco, and their only response so far has been to suggest putting CSA into Test mode (which should effectively disable CSA), and upping the logging by enabling the 'Log deny actions' rule override. Admittedly this seems to be a logical approach, yet neither has had any effect. Despite being in Safe mode, CSA still stops Sophos installing.

Hi Mark,

Yes, you can allow agent interaction via an Agent UI rule applied via policy.

My thought was to allow the Sophos install to access the registry based on what you are seeing in the Sophos install logs.

If you explicitly allow it, it might allow the install (if that's all that is stopping it).

Tom

Hi Tom,

I think I might be getting somewhere. I have nailed down the rule that is blocking the update (256), although it would appear to be something other than a direct Sophos exe that is running into issues. Here it is:

The process 'C:\WINNT\system32\msiexec.exe' (as user NT AUTHORITY\SYSTEM) attempted to modify a Cisco Security Agent resource Cisco Registry Key\Value: \REGISTRY\MACHINE\SOFTWARE\MICROSOFT\WINDOWS NT\CURRENTVERSION\Windows\AppInit_DLLs. The operation was denied.

Research shows this to be a well used Windows installer agent, so there may be a risk of allowing this. However, I suppose I'll have to add the into the rule as an acceptable process for now. I have also defined Sophos within the list of AV software packages that is allowed.

Also, moving hosts directly out of their groups and into a test group allows the update to take place. However, I'd rather try to amend the rule base than negate CSA altogether if I could.

Any thoughts??

Thanks

Mark

Hi Mark,

Sophos must have changed their install package to an MSI wrapper.

I think it's triggering because csauser.dll is listed in the AppInit_DLLs registry key so the agent protection rules kick in.

You could create an explicit allow rule or configure a dynamic rule that triggers when the Sophos install starts.

You'd probably need to include descendants of the Sophos install process then let the registry access take place.

There are existing app classes for msiexec that may work with this.

Tom

If you found away around this in your environment without using test mode could you please post some specifics. We are having the same issue moving from 6.5.10 to 7.0.4 and now it is rearing its head again on a 7.0.5 update (although not on every machine).

We have an environment of nearly 2000 machines so this has been painful.

I have battled with it but since it does not log that it is blocking anything it is very difficult to generate a rule for.

Thank you,

-Landon

I forgot to mention that we are running version 5.1.0.74

Hi Landon,

Do you not get similar messages to what Mark posted?

"The process 'C:\WINNT\system32\msiexec.exe' (as user NT AUTHORITY\SYSTEM) attempted to modify a Cisco Security Agent resource Cisco Registry Key\Value: \REGISTRY\MACHINE\SOFTWARE\MICROSOFT\WINDOWS NT\CURRENTVERSION\Windows\AppInit_DLLs. The operation was denied."

This should give you something to make an exception for.

Tom

No, we do not see anything at all. CSA does not show that it is blocking any activity in any way shape or form on the machines being upgraded.

The local client does not show anything in messages, and there are no events in the MC.

As far as CSA is concerned it does not tell me it is interfering in any way, but it most certainly is since when we put them in test mode the upgrade runs just fine.

We do not want to keep throwing machines in and out of test mode during these upgrades.

Thanks for any help that you can provide,

-Landon

Do you have any rules set not to log? I'm guessing you are running into something similar to what Mark posted since it seems like Sophos changed their install package.

Can you set up a machine for verbose logging with all rules set to log?

You could also try just creating an exception for msiexec to access the registry key mentioned previously.

I have created an exception rule for that registry key and it is being matched when I force an update.

However it will still fail if it is not in test mode.

I have looked through the logs on the local client after an update and it does not show that anything was blocked... it is killing me...

I have a case open with TAC, but they are dragging their feet. If we get it figured out I will post the findings.

Any other advice in the mean time?

Thanks,

-Landon

You did confirm there are no rules set not to log, right?

You could also try broadening the exception or creating a dynamic app class for the install package.

Do you have the license for the analysis package? You might try that if you do.

Tom

I have gone through all of the rules that have matched an action on a machine and verified that they are logging.

I have also applied hot fix 106 now as suggested by Cisco which has not helped.

Sophos has released another engine update now 7.0.6 and this update is failing in our environment also.

Very strange and very frustrating.

Hi Landon,

You created the registry exception for MSIEXEC and it's still failing?

You could try putting the rule(s) into test mode and keep logging enabled. That should allow the install and also give you more information.

If you still have problems, try removing a machine from all groups (except of course) and add it to one group at a time (or create a test group) until you get the failure.

That may help illuminate the cause and allow you to craft a solution.

Tom