Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 4 replies
  • Subscribers 1 subscriber
  • Views 4717 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

Managing Endpoint with Enterprise Console outside the network?

IAA

This question may have a very quick answer - but is it possible to use Sophos Enterprise Console to manage computers running Sophos Endpoint that AREN'T on the same network?

The scenario I have is that I'm trying to remotely administer Sophos Endpoint on roughly 60 computers at over a dozen independant sites. Ideally I'd like to be able to monitor any alerts on these machines and apply policy changes from a centralised console to save the need to log in to each site and adjust standalone settings on 60 different machines.

I've been running Enterprise Console with a smaller group of about a dozen computers without issue, but this is the first time I've looked into using the console to manage computers outside the same network as the server.

Any assistance as to how to go about this or whether it is possible or not would be greatly appreciated.

:5603


This thread was automatically locked due to age.
  • 0

    Hello IAA,

    the very quick answer is: If the computers can connect to the management server's ports 8192-8194 (directly or through a message relay) you can manage them. For "fast reaction" a connection in the opposite direction (to the clients' ports 8192-8194) is needed (again this can be through a relay).

    The funny colored part is the minimum requirement (of course RMS has to be correctly installed). You'll find more than some posts about message relays and 8194 in this forum. Please read them (and also check if the links therein are still valid :smileywink). BTW: For only a handful of clients the message relay doesn't have to be a server.

    If reading doesn't help on (or adds confusion) please just ask

    Christian

    :5610
  • 0

    Hi,

    It sure is, the interface for the clients talking to the "management server" is the routernt.exe process.  By default, when this starts, it listens on all interfaces (0.0.0.0 will show in a "netstat -ano" output) on TCP ports 8192-8194.  So if you have 5 network cards on the server, they will all be listening on 8192-8194.  Note the clients need to be able to reach 8192 and 8194, the server needs to be able to connect to 8194 of the clients (for fastest downstream message delivery).  8193 isn't actually used and if 8194 on the client isn't accessible by the server router as long as the client router can connect to the server, it will poll for messages, by default every 15 minutes, which will make downstream delivery slower but it will still work if the endpoint is prevent incoming connections (think XP firewall).

    The parent address string is really what defines what the clients use to access the parent router.  It is essentially determined at the install of the management server when it lays down the mrinit.conf file in the Enterprise Console directory.  This is the source file from which all others are created.  If the server has a static IP, the IP address is inserted first, followed by the FQDN and then the NETBIOS name.  If the management server is DHCP, it just contains the FQDN and NETBIOS.

    So I would check in a CID that the remote network is going to be using, the mrinit.conf file and specifically the parent address value, is this address going to be resolvable by the clients on the other network?

    There is also the option to add message relays, please see: 
    http://www.sophos.com/support/knowledgebase/article/14635.html

    but either way, one machine on each network will need to be able to address the management server.

    As for protecting machines on another network from SEC, SEC uses the NETBIOS name, so if you have multiple domains, you will need to include each in the DNS suffix list on the management server.  Also remember that the deployment account needs to be able to log on to the management server machine.

    I hope this info is helpful.

    Thanks,

    Jak

    :5612
  • 0

    I'm not 100% sure if I described the scenario I'm in correctly. I'm trying to rollout an antivirus solution for a dozen companies that have no affiliation with eachother. We provide and maintain ownership of the equipment we install, but it is installed into the customer's existing network on a VLAN and receives internet access through their domain. The internet access varies between unrestricted, blacklists and whitelists, but we can have their various IT departments ensure we can communicate with whatever destinations we require.

    What I'd ideally like to do is use Enterprise Console to manage policies and alerts from computers that have no way of communication with this console server other than through the internet. There is no option to use a VPN and there will potentially be duplicate PC Names and IP addresses from some of the computers in the various networks.

    After some research, I thought that NAC might be a potential solution for this scenario but I haven't been able to obtain a trial yet. Does anyone have any experience with this scenario of using Enterprise Console to manage PCs that connect to it solely via the internet?

    :5641
  • 0

    Hi,

    I can see a couple of approaches that will work, one being far simpler than the other but doesn't provide you with the same level of control as the more complex solution. 

    Method 1

    If there is only a few clients to be managed at each site:

    1. Install SEC + SUM at your site to create the distribution points/CIDs.
    2. Define all the various policies of each type you require for the various companies in SEC, E.g. CompanyAAV, CompanyBAV, etc..
    3. Use ExportConfig and ConfidCID to export these configurations to the XML files you can then place in the various distribution points/CIDs that have been created.  I'm not sure if you will have the same policies at each site. Either way this will work, you just might need to share out more distribution points centrally with a CID for each company/Config.
    4. You can then share these update locations out centrally with Apache/IIS, etc..
    5. The policies can use SMTP/SNMP to alert to viruses,at each site, that could hopefully be forwarded securely to the central site.

    This would be simple to setup for a few machines at each site updating from a central location the downside would be the ease of appending to policies, inability to send clean-up tasks, without reconfiguring maybe the SAV policy but for a basic level of protection could be fine.  

    For a large number of machines at each site, it could require a lot of bandwidth if all the clients were going to a remote location for updates.  Maybe install a SUM at each site and perform the same steps there or maybe a caching proxy could be configured at each site.  So once a file is grabbed from a remote location, it is cached by the proxy for subsequent requests.

    Method 2

    Firstly: Regarding machines appearing in SEC possibly having duplicate names.  This isn't so much of an issue, as long as they have different domain/workgroup names.  If they have the same domain name and work group name, you can use command line parameters with setup to override the computer name/domain name and description to ensure SEC sees them as unique entries.  See: http://www.sophos.com/support/knowledgebase/article/12570.html

    As for central management.  I would suggest a message relay would need to be installed at each site.  Essentially a machine that all local machines at the site report to before forwarding messages to the central site.  I would also suggest this machine maybe has a SUM on to provide updates to the site also. As it is likely to be a server.  SUM could update either from a parent SUM at your site, or directly from Sophos at each site.  If each site updated from Sophos, I would suggest making the SUM at the central site the authoritative SUM (http://www.sophos.com/support/knowledgebase/article/57638.html), and ensure that that SUM is subscribed to all the same packages as all the various site SUMs are subscribed to.  If not, machines will potentially show as unknown with respect to their update status.

    In order for the message relay on the site to be able to communicate with your central site, it would need to be able to make a TCP connection to 8192 and 8194.  Plus, if the child SUMs at each site were to update from the central site rather than Sophos, I would suggest sharing out the warehouse using a web server.  In which case port 80, or whatever you host the webserver on would also need to be permitted.  Ideally you would open up port 8194 on the child relay server for fast downstream messages from SEC, but I fear that machines is going to behind a router/NAT in which case, it might have to fall back to polling the central site for messages which should work fine.  The message relay at each site could always be tweaked to have a more aggressive polling time (getterinterval) to speed up downstream message take up by the sites. 

    The hardest part in this sort of configuration relates to where the SEC server, or could be a message relay at the central site sits in the network.  Does it sit right on the edge or behind some device which will port forward, ports 8192 and 8194?  If you're port forwarding to the SEC server or another relay at the central site, you will need to "override the IOR" on that machine so the IOR contains an externally routable address.  This article explains how to do this: http://www.sophos.com/support/knowledgebase/article/50832.html

    Essentially the remote sites should be able to connect to the central site using a FQDN, this FQDN will be in the child relays parent address.  If port forwarding at the central site is in use, you will have to override the IOR on the router the child relays will be connecting to, to contain that FQDN.  Plus the local Management Agent service, on that machine, will also need to be able to resolve that FQDN to be that same machine.

    Quite a lot to process I know but once setup, each site should be able to communicate with the central site.

    You may like to call Support to go over this plan and have them help you configure the management server/relay at the central site and one of the "site" relays and ensure it is communicating before moving on to managing clients at each site.

    Good luck, 

    Jak

    :5646
Unfiltered HTML