"Wanna" ransomware outbreak. Please see this Sophos article sophos.com/kb/126733 for advice on how to protect your organization. Immediate action recommended.
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.
Applies to the following Sophos product(s) and version(s) Enterprise Console
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.
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 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.
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 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:
This tells the client to use the router 22.214.171.124 as a message relay.
Should the DMZ use RFC 1918 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 126.96.36.199, an address that is routable on the internet, and must have TCP ports 8192 and 8194 forwarded to 172.16.2.3.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Sophos Message Router\ImagePat
"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
-ORBDottedDecimalAddresses 0 -ORBListenEndpoints iiop://:8193/ssl_port=8194&hostname_in_ior=MR.domain.com
Assuming all clients (internal and external) have been configured to use one message relay:
Every comment submitted here is read (by a human) but we do not reply to specific technical questions. If you need technical support please post a question to our community. Alternatively for licensed products open a support ticket.