Highlighted
Knowledge Partner
Knowledge Partner
412 views

ArcSight Connectors >7.15 on Windows Servers - File permissions issues

Hi

Strange one here that i didnt originally think was anything to do with the ArcSight software, but now i am not so sure.

Using connector framework 7.15 or 8.0 on Windows 2016 - has anyone come across any strange issues with file permissions? in particular if you configure a connector with ArcMC or RunagentSetup or manually via an update to agent.properties it makes some of the files inaccessible (agent.properties and unobfuscation keys in particular) next time the service is restarted - even though "Administrators" should have full control over the folder / files.
it is resolved by propagating file ownership again either on those files or at the root of the connector.

I have tested with 7.14 Connector and 8.0 connector - installed identical Syslog Connectors and can replicate the issue on 8.0 Connector, but 7.14 works fine.

I am about to raise a support ticket - but has anyone else come accross it and got a good fix before i downgrade our connectors?

0 Likes
12 Replies
Highlighted
Knowledge Partner
Knowledge Partner

hadnt seen that thread - cheers Andreas 

FFS - that is ridiculous behaviour though! will carry on and raise a support ticket

 

0 Likes
Highlighted
Knowledge Partner Knowledge Partner
Knowledge Partner

can you share SD number?

0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

Hi

Still working it through - will try the combination of non admin versus admin install etc

On a first glance i cannot see anything different in the SmartConnector Guide or release notes for 7.15+ that tells me to change how we install this. 

One workaround that has been mentioned is to set a none admin as the owner of the files - however, this doesnt work when the service account runs as (for example) an event log reader account and the ArcMC or runagentsetup uses a user account permission.

0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

An update on this.....

making a service account a member of local admins so far seems stable (running for approx 2 weeks) - but there are still Fatal errors in the agent.log about access to the Obfuscation key every restart - they seem to not cause any issues at the moment.

However, it is not possible for us to make Service Accounts Local Admins for a lot of of our environments - so i dont think that is a long term solution.

MF Support suspect there is a bug following the changes made to address a vulnerability - but havent got a reference or confirmation as yet.

Highlighted
Knowledge Partner Knowledge Partner
Knowledge Partner

Hey @kevquinlan  any news on this?

0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

An Update:

From Microfocus:

"Please find the Dev team's update below for connectors 7.15 and above:

For non-admin users to run the connector, the owner of agent.properties and obfuscationkey file should be changed to corresponding user. Manually adding separated permissions will not work since it will be removed once the connector restarts. So you'll have to specifically set the owner of those files to the user who will run the connector.
In case there are more than 1 user that can have permission to run the connector, these users should be added into the same group, so the owner of agent.properties and obfuscationkey files can be assigned to that new group of users.

If this doesn't work either, please let us know, as per the Dev team a current possible workaround is to downgrade to 7.14."

 

So i suspect that when first installed, the owner of the agent.properties and obfuscation files are set to be the user carrying out the install, therefore, when we then try to change the permissions to add either the Local Admin group (of which the service account is a member) or another specific group or user, that is treated as an additional permission and therefore is removed when the connector runs as the connector permissions are reset to one user or group only (no inheritence).

@MicroFocus- Can i suggest that when changes such as this are made (i.e. how to install a connector or how it operates by default), there is clear information in the documentation to state how it is meant to be configured. there have been several changes in basic functionality of connectors recently that can cause outages or changes to the type of events collected.

Highlighted
Knowledge Partner Knowledge Partner
Knowledge Partner

@kevquinlan thanks for the update on this issue. @dalesio thanks for reading @kevquinlan s post above.

Both: Do you know if SC FW 8.0 is also affected?

 

KR

A

 

0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

Yes - it is functionality rolled out in SC 7.15 and above

The aim of the change seems to be to resolve a vulnerability in the implementation that allows a none privileged user to change critical sensitive files in the SmartConnector software - so i think the aim of the fix is good. 

But i want to see more clarity in the installation guide and release notes when these changes are made and more consideration of real world use cases for the software and every connector type within the software (A DB Connector will have different issues to a syslog connector due to the use of service accounts etc.)

 

0 Likes
Highlighted
Knowledge Partner Knowledge Partner
Knowledge Partner

@kevquinlan 

you will not see this in release notes... i got an answer about the tomcat vulnerability, that was fixed in 7.15, that MF does not want the "hackers to know which versions are affected - hence no comment / writeup somewhere" 

I rather think this is poor practice and making the life of the bad people easier, then harder...

Also the same is valid for not giving a list of all libraries and versions used in each connector version.

@dalesio   and MF you are protecting the wrong side of the game with those actions, form my perspective.

KR

A

 

Highlighted
Super Contributor.
Super Contributor.

Our vulnerability scanner picked up the same Tomcat vulnerability on our SmartConnectors.  Are you aware of any vendor advisory published by Micro Focus on how to remediate/mitigate this vulnerability?  

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.