Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 31 replies
  • Subscribers 1 subscriber
  • Views 94953 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

    Short response: count us in - for the very same reasons.

    Christian

    :229
  • 0

    I completely agree.  SSL is a priority for us.

    :236
  • 0

    Some remarks to yesterday's sparse answer:

    In the first place it's Sophos' problem. SUM too, as far is I know, is using http not https. And article 12354 tells you how to configure clients to update directly from Sophos using your license credentials. Sophos must be aware of the security implication - guess they monitor the downloads and can at least detect when a SUM is downloading from a location not related to the customer associated with the credentials.

    As for clients updating via http: We configured static download users to download from our webserver and I have been (inofficially) told that this is understandable and ok given the unavailability of a secure connection - under the assumption that we monitor for excessive download activity. I conjecture the following reasoning: An "unauthorized" client downloading from a customer's site will not incur additional costs for Sophos. Since Sophos does not sell it's solutions to "private end users" there is no business lost (well, perhaps for competitors but ...). A security product is different from an office suite for example - you don't need it for exchanging content (in fact it might prevent it :smileywink:) and you can get quite good ones for free. Isn't it a commendation if someone wants just Sophos and nothing else?

    Nevertheless we'd like to stand on firmer ground here.

    Christian

    :247
  • 0

    why not have just a few (we use one) user account(s) for updating, and then lock these accounts down so they can't do anything else on your network.  Doesn't matter to you if the credentials get compromised

    :248
  • 0

    I host a few solutions for internal clients and in one scenario we did disable interactive logon for the updating account we use, however this account still can access all shares that have Domain User access.  A simple and slow scan for open shares using the harvested credentials could result in some interesting findings without flagging internal detection software.

    It is bad practice all around to send credentials in clear text, this is a plain and simple No-No.

    :250
  • 0

    Accounts for the network share and http access need not (and should not) be the same. So web access is just web access and furthermore restricted to a specific realm - there is nothing else you can do with it.

    Christian

    :252
  • 0

    I'd like to second QC - in past deployments I have created a single IIS (or similar) account for remote updating. All this account can do is read the URL being used for the external web CID.

    I have also advised against using AD or similar authentication for remote users due to their being no HTTPS support at present.

    It is a feature request, and does come up occasionally as a topic of conversation around the Support water cooler - but right now, I'd go with the dedicated, read only, HTTP user authentication.

    You can go one step further of course, and obfuscate this account from the end users in a SAUCONF.XML and using our Obfuscation utility.

    :254
  • 0
    paulcjones wrote:

    You can go one step further of course, and obfuscate this account from the end users in a SAUCONF.XML and using our Obfuscation utility.

    The major concern is not about a user giving away the credentials (and obfuscation wont help as you he monitor the http traffic) but the password travelling in (practically) clear text over "foreign" territory (wire or air).

    Christian

    :255
  • 0
    QC wrote:

    The major concern is not about a user giving away the credentials (and obfuscation wont help as you he monitor the http traffic) but the password travelling in (practically) clear text over "foreign" territory (wire or air).

    Understood - it's the reason I recommend a single, read only HTTP user account for remote updates, not AD accounts or similar. Our remote update doesn't need that kind of access :)

    :257
  • 0

    My school does as Paul recommends... there's a limited access account (well, very limited, it only has access to the sophos console server :P) that gets used for updating. It was probably as much does for ease of deployment as security though I'd imagine.

    :357
Unfiltered HTML