This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Preventing Sophos services from being disabled by domain users

Hi All,

Good to see there is finally a forum to post idea and questions out to end users!

I have a question that I hope someone can answer...

Im looking at rolling out EndPoint 9 to the company and we are going to start using the Sophos Firewall etc.

I wanted to know if there was a way to stop end users disabling or stopping sophos windows services to prevent them from navigating around the device control/firewall etc... 

I realise this is a Windows question more than Sophos and have looked at GPO secuirty settings but cannot get these to work with DENY permissions. It also seems that when I configure any rules in these services in GPO, Sophos AntiVirus service doesnt start up.

Just wondered if there was a way of doing this in Sophos based on the sub estate/roles or anything else...

Thanks!

Dann

:120


This thread was automatically locked due to age.
  • Hello Dann-PLC,

    As you said, this is more a Windows question, and yes, AD is definitely the proper way to achieve this.

    I suppose in your question that your users have local admin rights if they can stop the service, which is definitely not a good practice of safe computing.

    Prior trying to restrict access to windows services, i would recommend investingating if your users really need admin rights on their enterprise desktop/laptop, and must realize that if a user has admin rights on the computer, he has any permission that allow him to break everything on the computer. You can find more information about safe computing on this page : http://www.sophos.com/security/best-practice/10-tips.html

    That said, you can restrict access to the Sophos Endpoint Security & Control installation on the local computer using GPO. The idea is to restrict access to services and files to a Sophos Security group in AD. You also need to enforce access to SophosAdministrators group on the local client.

    In order to allow the service to start, you also need to leave other accounts permissions on the service, such as LocalSystem.

    Laurent.

    :155
  • Thanks for your reply Laurent! :) This could get confusing...! 

    Yeah we dont let users (bar the IT dept) to have local admin but they do have local power user rights (requested by many people across the company). If im right, I still think you can stop and start services as a power user...or is this not the case? (Im going to test this now).

    Interesting that you mention whats possible via Sophos...so using groups in AD and sophos....is there any documentation on this as Im pretty sure thats what Im trying now?! 

    The groups setup in sophos are default apart from me adding in Domain Admins to the sophos admin groups and roles. 

    At the moment if I set the sophos anti virus service to be "automatic" but only for local system, interactive and domain admins (all with full rights) ...it doesnt start on startup even if i login as a domain admin....

    Checked GPO results wizard and there are no errors or permissions problems and its being applied fine. Seems like a GPO/AD issue but just wondered if there was a way you knew of that I could try... (i.e: via AD groups and sophos groups)

    Thanks!

    :166
  • Well, even IT staff shouldn't get permanent admin rights, but should instead have a regular account, and switch to admin mode only when required ... :smileywink:

    Power users don't have the right to interact with the Services, you're safe with that.

    What i mentionned about AD only apply for sensitive profiles who (unfortunately) have true administration privileges on the local machine, and who in this case have the right to start/stop services.

    Prior to explaining how to do that, i must enforce the following :

    This is NOT to be done straight in a production environment since it's a global configuration that - in case of mistake - will apply on all computers within the domain. I strongly recommend testing this on a real test, separate network, separate domain.

    Alternatively, Sophos Professional Services or a trusted Sophos Partner can help in doing the following.

    That said, and once you understand it completely, here is the how-to :

    1. Create a new security group in the domain, manageable by IT Security team only. Alternatively you could use the Domain Admins group which is supposed to be restricted enough.

    2. Open Group Policy Object Editor.

    3. Restrict access to the relevant service(s) to your newly created security group under "Computer Configuration", "Windows Settings", "Security Settings", "System Services".

    4. Restrict access to the relevant filesytem part(s) to your newly created security group under ""Computer Configuration", "Windows Settings", "Security Settings", "File System".

    For 3. and 4., you must leave system parameters unchanged (e.g System Account, Interactive, etc.)

    Regards,

    Laurent.

    :179
  • Hi,

    It is worth remembering the "power" in the "Power Users" security group; the following article highlights just that:
    http://blogs.technet.com/markrussinovich/archive/2006/05/01/the-power-in-power-users.aspx
    So ultimately being a power user without other modifications is essentially giving potential administrative rights to the user. Most probably why this group is only left in for backwards compatibility purposes on Windows Vista and 7.

    That being said it might be interesting to try using Software Restriction Policies (http://technet.microsoft.com/en-us/library/bb457006.aspx) to prevent SAVmain.exe being executed.  I’’’’ve not tried this personally but I see no reason why this approach would not work  A simple path rule might be enough to deter the casual snooper.  Admittedly there is no granularity in this method.

    Thanks

    :203
  • We managed to wrestle the power users rights from both domain users and non-domain "VIP" notebook users (that we were hit by an outbreak of Conficker did help a lot).

    From what you say I gather that you don't have the required backing from your management to enact the policies you deem necessary - and you are trying to "sneak in" a little bit more control. I recommend against it. Such course of action could backfire any moment. You have a job to do and for that you need certain resources - and these include the approval of necessary policies (and the "right" to enforce them).

    If you can convince the users that your actions are for their benefit - fine (management always likes to make decisions which meet no resistance). If not, then you have to convince management - for this you need a "business case" (number of "incidents" on IT-managed vs. partially-user-managed computers for example). If certain applications only (seem to) work for power users try to identify the cause. Show that you care about the users' needs and that you are willing to find workarounds and implement exemptions - while clearly stating the consequences (reduced security, additional effort) and the responsible party (most of the time it's either a sloppy implementation by the vendor or simply "unfit" software and not exactly your fault). This worked for "us" (i.e. the group in IT responsible for the endpoints) - even though most of our colleagues called it mission impossible.

    The bottom line is: When trying to achieve a strategic goal it is better (and easier) to permit specific actions, especially when it's clear that they are exemptions.

    Christian

    :212
  • and incase you actually want to disable them than use the windows services :)

    :19199