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

Architecture question

Hello,

This is my first post to the forums.  Please forgive me if I'm failing to observe an established convention.  I've looked around the documentation and forums and have been unable to find an answer to my bigger question although I think I've run across answers to some of the subcomponents. 


I'm running SEC 5.2.0.644 on Windows Server 2008 R2 Standard.  Licensed product is Sophos Endpoint Protection - Advanced.  This is working properly.  The server is a member of our AD domain but is not a DC.  It's located on our internal network. 

Since we do not allow any outside traffic inbound into our internal network, external clients can't update using that server, and are using the Sophos severs for updates.  Since we have an increasing number of external clients, we'd like to provide updates to these clients from our own servers, which would also allow us to to deploy the home client for some of our users who would like to use it.

It seems to me that the easiest way to do this securely would be to set up a second server in a dedicated DMZ, and then have our existing SEC server push product and definition updates to the second server.  I'd also like to have the existing SEC server pull client status information from the second server, rather than having the second server push it to the existing server.  From there, we could allow inbound traffic from clients into the DMZ and then to the second server.  I can't have the DMZ server be a member of the existing internal AD domain.


Am I on the right track here?  If so, is there an existing article or post on how to put this together to work in that fashion?  Or is there a better way to do this?  I would rather avoid putting my existing SEC server in the DMZ.

Thanks for any guidance.

Elisan

:45333


This thread was automatically locked due to age.
  • HI,

    The options I see for remote clients are:

    1. "Sophos Cloud" licence for remote clients.

    Pro - no setup, easy to get management of remote clients, no infrastructure work. Can create an eval account (30 days) and deploy to a client in less that 5 minutes as a test. https://secure2.sophos.com/en-us/products/free-trials/sophos-cloud.aspx

    Con - no control over packages and seperate reports to your existing SEC infrastructure.  I think this is worth a mention as it's so easy and removes the burden from your infrastructure.

    2. Install a SUM on your DMZ computer and have it pull updates from either Sophos directly or from your current management server.  If you install a webserver on your existing management server it can pull over HTTP otherwise UNC.

    3. Have the existing management server's SUM push a CID to the DMZ server to create a CID.

    For management of 2 or 3, it would make sense to make the DMZ computer a message relay.  I.e. the CID is a message relay CID.  http://www.sophos.com/en-us/support/knowledgebase/50832.aspx.  Remote clients would need acess to ports 8192/8194 for RMS and 80 for updating if you make a web cid available from it.

    The hostname_in_ior switch mentioned in the article allows the (RouterNT.exe) IOR (port 8192) to host a FQDN inside it, so if you need to port forward to 8192/8194, the IOR string in 8192 will contain an external routable address you define rather than the internal IP of the DMZ computer.  The local client would need to resolve this address to be itself and remote clients would need to be able to also resolve it externally.

    If the sum+relay config is something you wish to do, then I would give Support a quick call to explain your requirements as it can be tricky if you've not done it before and it will save time.

    Regards,

    Jak

    :45339
  • jak,


    Thank for you for the fast, thoughtful, and helpful guidance.

    Offhand it looks like option 3 would be the best choice for my environment, at least assuming I can get it working.  I will pursue that for now at least and see how deep the water is.  Fortunately I'm not under time pressure.  Thanks for the link to the article and the suggestion of getting tech support involved early in the process.

    Elisan

    :45393