Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 31 replies
  • Subscribers 1 subscriber
  • Views 94937 views
  • Users 0 members are here
Options
Suggested
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

Sophos Endpoint Updates over https

faygate

For the past 3 or 4 years we have posed the question to Sophos as to why we cannot update our clients out in the field using a web CID over https. So far this has failed to materialise, which I found bizarre for a company that deals with security. We are a large University and to ensure we our students and staff are protected from viruses and malware, they are allowed to install Sophos on their computers. Now as we like to ensure that we adhere to our licence our users must update Sophos using their University credentials.

As our University credentials are being used to grant access to more and more sensitive systems, this is becoming a real security issue and we are not happy about this credentials being passed over effectively in plain text! Of course we'd have the overhead of the encryption on our webservers, but I'm happy to take that hit and the servers can handle it.

Does anyway else have this requirement for updates via https? I can't believe we are the only ones.

My understanding is that this is now being discussed as a feature request, but it would be good to have some more people on board. Please post your comments below.

Regards, Richard

:226


This thread was automatically locked due to age.
  • 0

    Hi all

    This discussion makes me wonder......

    In my position as CISSP i´ve heard a lot of rumors regarding to security and https instead of http.

    Most of these rumors are true, some are completly out of sentence...

    To bring some light in:

    1.)  First of all "https" is primary used to encrypt the whole transport process to ensure the context is not readable for others.

    As sophos updates are checksummed it is not possible to manipulate the files for the update process in a way that impacts the endpoint

    So there is no advantage to encrypt the whole transport process as long as the files are save against manipulation.

    2.) Using user accounts, who have local login rights, against a webserver for updating produce a risk to be hacked.

          Therfore the use of "https" is more secure to hide user accounts from being sniffed.

    This is wrong! Every traffic over ssl like https resolve in more or less curious people who want to look at.

    E.g: look at http://www.youtube.com/watch?v=XtaAuhQWvcg for a tiny https attack using backtrack to "man in the middle" an https stream.

    Looking at this, brings back to mind that in an https stream an password encrytion does not really exist, its simply base64 encoded.

    As a result a user acount is not really more secure using https than with http and using NTLM authentication!

    Additional to the above:

    The overhead for the encrypt / decrypt process on a webserver is rising exponential and slows down the  update server himself aswell as the endpoiints in summary.

    As Sophos AutoUpdate process support NTLM authentication against a webserver what might deliver an more adequate encryption for user passwords than https does......

    However, from a security aspect it makes most sence to decouple an update user from an existing user who has local login rights. 

    :569
  • 0
    To update remote clients use a web CID for HTTP updating remote systems.

    Ok everyone if you need to control reporting from remote computers use this below and call support if this is too confusing :)
    Using Sophos message relays in a public WAN

    This article provides examples and guidelines for situations in which there are multiple endpoint clients that never access the corporate network, either physically or via a VPN, but still need to be managed by Sophos Enterprise Console.

    Background
    Sophos message relays are used to consolidate the policy and reporting data flowing between the Enterprise Console and client computers. They are also used to facilitate firewall rules, traffic management, and bandwidth. This article assumes the reader is familiar with Sophos message relays and their role within the Enterprise Console management structure.
    For more information, or to set up a message relay, refer to the knowledgebase article Enterprise Console: configuring message relay computers

    Sophos message relays are typically used to manage internal clients. These clients are usually on the corporate network, or a VPN, and have regular frequent network access to internal message relays, or the Enterprise Console directly.  If temporarily unavailable, messages to and from a client are cached on its message relay and the client respectively, until communication is re-established.

    Introduction

    The following scenarios provide guidelines for situations in which there are multiple endpoint clients that for various reasons never access the corporate network, either physically or via VPN, but still need to be managed by the Enterprise Console.

    In these cases, it is possible for computers which never access the local network to be configured to communicate with the Sophos Management Console via a message relay located in a DMZ, rather than directly to the console or to an internal message relay. This improves accessibility and management of roaming laptops by providing a location which they should always be able to reach while on, or off, the corporate network.

    The following cases give examples of hosting a service that is traditionally an internal network-facing role, on the internet. Although steps have been taken in order to prevent unauthorized systems from communicating with a message relay, it is beyond the scope of this article to give recommendations on hosting internet facing services, and securing Microsoft Windows servers for use in a DMZ.  

    Steps should be taken to ensure that only legitimate traffic is allowed between clients and a message relay, as well as a message relay and the Enterprise Console, which may be on the internal corporate network.

    Communication between clients, message relays and the Enterprise Console takes place via Sophos RMS on TCP ports 8192, 8193, and 8194.
    For more information, refer to the knowledgebase article Sophos Anti-Virus for Windows: access to computers with firewalls.

    Clients should be configured to communicate with a specific message relay upon installation. This is done by modifying the mrinit.conf file as described in the knowledgebase article Enterprise Console: configuring message relay computers, and more specifically in the following scenarios.
    Note that these scenarios will result in one-way RMS communication, and while they will not cause any loss of functionality, they may slightly delay the delivery of policies and other endpoint instructions.

    Scenario 1: Message relay in a DMZ, using a public routable IP

    In this scenario, clients on the Remote Private Network have no VPN access to the ‘‘‘‘Private Corporate Network’’’’, and clients cannot communicate directly with the Management Server.

    In such a scenario, a customer can configure all clients (or just remote clients) to use a message relay located in the DMZ, in order to facilitate communication with a console located on a corporate LAN.
    Since RMS communicates on TCP ports 8192, 8193 and 8194, bidirectional traffic on these ports should be allowed between the message relay and the Management Server (including specific port forwarding, in the case of NAT) as well as inbound from the Internet to the message relay.
    The Enterprise Console Management server and the message relay should be able to resolve each other via DNS.
    In the above scenario, all clients that will use the message relay will need to be installed with an mrinit.conf file which includes the following:

    "MRParentAddress"="192.168.0.3 ,[CONSOLE-FQDN],[CONSOLE-HOSTNAME]"
    "ParentRouterAddress"="2.2.2.3,[MR-FQDN],[MR-HOSTNAME]"

    This tells the client to use the router 2.2.2.3 as a message relay.

    Scenario 2: Message relay in a DMZ, using a private non-routable IP

    Should the DMZ use RFC 1928 IP addresses (192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8) a modification must be made to the message relay which changes the IOR message it provides the client.
    A split DNS zone is also required, which resolves DNS names differently internally than externally.


    Normally, when a client connects to a message relay or the console on port 8192, it will receive back an IOR string, containing the Message Relay’’’’s locally configured IP address. (In this case, 172.16.2.3)
    Since the message relay’’’’s IP in this case is non-routable, a change is required so that the IP provided in the IOR is either routable, or is an FQDN.

    In the above case, the message relay is named MR.domain.com, replace it with the FQDN for the message relay you will be using.

    In our example, internally within the organization, MR.domain.com resolves to 172.16.2.3, an address that is routable between the Corporate Private Network and the DMZ.
    Externally, MR.domain.com should resolve to 1.1.1.1, an address that is routable on the internet, and must have TCP ports 8192, 8193, and 8194 forwarded to 172.16.2.3.

    How to change the message relay to make it return an FQDN in the IOR string:
    This procedure must be performed on the message relay

    WARNING:  Make a backup of the registry (or the necessary keys below) before changing the data values.

    Replace all example values, with values that reflect your organization.

    • To immediately affect the service:
    1.  
      1. Modify the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Sophos Message Router\ImagePath
        to the following (all one line):

        "C:\Program Files\Sophos\Remote Management System\RouterNT.exe" -service -name Router -ORBDottedDecimalAddresses 0 -ORBListenEndpoints iiop://:8193/ssl_port=8194&hostname_in_ior=MR.domain.com
      2. Restart the Message Router service on the message relay.
    • To make the change persistent when an RMS update/reinstall occurs:

    Modify the key HKEY_LOCAL_MACHINE\SOFTWARE\Sophos\Messaging System\Router\ServiceArgs
    to the following (all one line):

    -ORBDottedDecimalAddresses 0 -ORBListenEndpoints iiop://:8193/ssl_port=8194&hostname_in_ior=MR.domain.com

    Additional configuration and information for this scenario

    • All clients using the external message relay need to be installed using an mrinit.conf file which includes the following:

    "MRParentAddress"="192.168.0.3 ,[Console-FQDN],[Console-HOSTNAME]"
    "ParentRouterAddress"="MR.domain.com”

    This tells the clients to use MR.domain.com as a relay.

    • TCP Ports 8192, 8193, and 8194 should be port-forwarded from the external IP: 1.1.1.1 to the message relay IP: 172.16.2.3

    Internal communication on these ports between the 192.168.0.x and 172.16.2.x networks should also be allowed through the firewall, and be routable.

    • The Enterprise Console management server and the message relay should be able to resolve each other via DNS to their actual IP addresses, not the external IP addresses.
    • In this example, the message relay needs to resolve CONSOLE-FQDN.domain.com to 192.168.0.3, and both the Enterprise Console Management Server and the message relay need to resolve MR.domain.com to 172.16.2.3.
    Network Flow Walkthrough

    Assuming all clients (internal and external) have been configured to use one message relay:

    Walkthrough – Internal clients:

    1. Upon install an internal (192.168.0.x) client will read mrinit.conf, know that its message relay is MR.domain.com, and resolve it (from the Internal DNS server) to 172.16.2.3
    2. It will then connect to the message relay on 172.16.2.3:8192, and receive an IOR.
      The IOR will contain the next IP and port to communicate on, and since the Registry keys were changed above to provide an FQDN instead of an IP, the IOR will contain MR.domain.com, and 8194 as the port.
    3. The Client will then connect to MR.domain.com (172.16.2.3) on port 8194, and will have RMS messages passing through the message relay, to the console and back.

    Walkthrough – External clients:

    1. Upon install an external (192.168.1.x) client will read mrinit.conf, know that its message relay is MR.domain.com, and resolve it (from the External DNS server) to 1.1.1.1.
    2. It will then connect to the message relay on 1.1.1.1:8192, get port forwarded to 172.16.2.3:8192, and receive an IOR.  The IOR will contain the next IP and port to communicate on, and since the Registry keys were changed above to provide an FQDN instead of an IP, the IOR will contain MR.domain.com, and 8194 as the port.
    3. The Client will then connect to MR.domain.com (1.1.1.1) on 8194, get port forwarded to 172.16.2.3:8194, and will have RMS messages passing through the message relay, to the console and back.

    If you need more information or guidance, then please contact technical support.

    • Article ID: 50832
    • Created: 23 Dec 2008
    • Last updated: 13 May 2009

    <script type="text/javascript"></script> <script src="http://www.sophos.com/js/signon.js" type="text/javascript"></script>

    :580
  • 0

    Okay I realise I'm resurrecting an ancient thread here, but I also find it surprising that there's no support for https updating.  I'm aware of the over head using https (and don't really care about it to be honest), and setting up a separate account for updating only doesn't really fit in here.  We have a lot of temporary staff, and using AD accounts ensures that when people leave the organisation they can't keep using our Sophos licence.  With a stand-alone account former employees would probably still keep using it, and since the username and password would no longer be 'personal' to our users, there's more chance they'd start distributing the credentials to their friends and family.


    AD authentication helps keep our licencing in check, but having these details sent over a standard http connection still causes concern, especially given all the resources that can be accessed externally with an active account.

    :2890
  • 0

    Hi,

    using AD-accounts creates new risks like DOS-attacks on legit accounts, therefore I personally wouldn't use this approach.

    Even if the update service were to use SSL, any attacker would be able to bomb the server with https-Requests with "Administrator" or "JSmith" as a user-account, and would in time disable the account. In my opinion, the risks from such behaviour do far outweigh the risks from the pattern-distribution to retired employees.

    This attack vector works equally over http and https.

    Best regards,

    Detlev

    :3000
  • 0
    DetlevRackow wrote:
    ...

    Even if the update service were to use SSL, any attacker would be able to bomb the server with https-Requests with "Administrator" or "JSmith" as a user-account, and would in time disable the account.

    That's actually a very good and perfectly valid point.  However, the same risk is also present with any AD authenticating system available publicly over the web, such as OWA (correct me if I'm wrong here, but I've seen a few accounts get locked out when the user has tried to log into OWA with a forgotten password).  At least with OWA the connection is secure so there's less risk of the password being compromised.

    Out of curiosity, what would the official Sophos response be if I did assign a generic username and password (non-AD) to the download location and we ended up exceeding our licence for home users who didn't uninstall the software or distributed the credentials without our knowledge?

    Thanks

    :3032
  • 0

    Right, and this is one of the two reasons why security consultants advocate authorization via token or smartcard for users to gain access over the internet.

    Regarding the question of licensing: You should clarify this with your Sophos-salesperson. When we started to offer patternupdates to our personnel over the internet, I sent our concept to our contact at Sophos and had him acknowledge that our measures were sufficient.

    Best regards,

    Detlev

    :3038
  • 0

    We've been looking at supporting https in Sophos development for a long time (we do regularly get requests for it). From a software development point of view, adding support for https would obviously be easy, which is why people are often surprised that we don't offer it.

    The main reason we don't currently provide this is the difficulty of providing a sufficiently 'brilliantly simple' way of configuring https that won't be error-prone and risk breaking updates. We are very careful about infrastructure changes that could cause updating failure on a large scale, as it can compromise endpoint protection and can be hard to recover from such a situation.

    The difficulty and risk in using https is in the management of the certificates used by the https server.

    There are three main ways that this can be done:

    1) Get a certificate from one of the usual trusted CAs (e.g. Verisign). This is an additional cost and process. More dangerously, these need to be renewed frequently, and forgetting to do so would then break updating of the endpoints for an entire site.

    There is also a potential failure case where endpoints don't have a sufficiently up-to-date lists of CA certificates. This could also break updating.

    2) Use a site specific certificate (e.g. a self-signed one).

    This adds the additional complexity of having to get the appropriate public certificates onto the endpoint. This could be tricky to set up, and again is another potential failure point.

    This also can cause problems with some proxies that check certificates.

    We are currently considering ways this could be made easier.

    3) Don't check the certificate validity.

    Sadly, a lot of https clients side-step the certificate management issue and take this approach. However, with such a set-up it's easy to perform a man-in-the-middle attack, so the https adds little security benefit. As a security company we couldn't really recommend this.

    For those of you who want to use https, it would be helpful if you could tell us how you would want to configure your servers, so we could look at supporting the particular use cases.

    :3058
  • 0

    John covered the three possible setups that could be used for updating over https.

    An additional point about 1) is that while Windows and Mac have central CA root certificate stores, that isn't true for other platforms we support, so the products would have to ship their own databases of CA root certs, with all the cost and complexity that would entail.

    :3059
  • 0

    Thanks for the replies John and Douglas - I'm aware there's no ideal solution to this that solves all problems, but from my point of view solution 1) (using a certificate from a trusted CA) would be the best option.  This would only cost us approx £483 for three years which doesn't really make that much difference when added to the cost of our Sophos licensing for the same time frame.  Also, the vast majority of our users are on Windows machines with a few Mac users, so I'm not too worried about clients not having up-to-date lists of CA certificates.

    The main concern is passwords being sent in clear text, and if buying a certificate resolves that issue then so be it.  As mentioned above I'm keen to keep our licences restricted to people who are actually entitled to them, and AD authentication seems the best option for that.  Maybe not the best solution for other people posting here, but in my case it's the best.

    Thanks

    :3067
  • 0

    Thanks, John, for your detailed explanation.

    Re-reading your post I think there are two distinct cases

    A) fetching updates from Sophos

    B) fetching updates from your site's server(s)

    A) does not use HTTP authentication (neither from SUM nor from AutoUpdate). Guess it requires some effort to extract the license so that someone could actually use someone else's license details to download software and updates from Sophos. The problem is, though, that if a client is configured for updating from Sophos it can continue to do so even if its owner is no longer eligible (but that has nothing to do with HTTPS).

    B) does use HTTP authentication. If basic authentication is used (or tried by the client for whatever reason - I have seen it during tests where the webserver only accepted NTLM) then the credentials are practically in plain text.

    Now I think that if a site makes sensitive data accessible "over the web" it's very likely that it uses https and that it already has one or more certificates for this purpose - and that an error will easily be detected because something else besides AutoUpdate will fail. So if https were an option I (and probably others) could use it immediately.

    BTW: anyone using an authenticating proxy to connect to an internal web-CID? This would be another challenge ...

    Christian

    :3127
Unfiltered HTML