Operating Principles |
Dr.Web MeshD mediates interaction between a host with Dr.Web for UNIX Mail Servers installed and other cloud hosts. Dr.Web MeshD uses the following connection types: •Client (service)—used by Dr.Web MeshD to connect to other cloud hosts that are clients of services provided by the given host.
•Partner (peer to peer)—used by Dr.Web MeshD for interaction with peer (within a service) partner cloud hosts. Usually such horizontal connections are used for scaling and distributing the load when interacting with the cloud, as well as for synchronization of cloud hosts. •Uplink—used by Dr.Web MeshD to connect this host (as a client) to cloud hosts (service providers) (for example, distribution of virus database updates, transmission of files for scanning, and so on). The use of all three types of connections is configured for different cloud services independently from each other. At that, the same host can be configured as a server for processing client requests within a service (for example, providing latest updates) and as a client within another service (for example, remote file scanning). Within cloud, hosts perform authorized interaction via a secure SSH protocol, that is, all sides of interhost communication are always mutually authenticated. For the authentication, host keys are used according to RFC 4251. The client connection from the local component is always considered as trusted. Dr.Web MeshD can either work in the daemon mode or run on requests from other Dr.Web for UNIX Mail Servers components installed on the local host. If Dr.Web MeshD is configured to serve client connections (i.e. the ListenAddress parameter is not empty) and at least one of the services is activated, Dr.Web MeshD starts as a daemon and awaits connections from clients. If Dr.Web MeshD is not set to process client connections (the ListenAddress parameter is empty) and there is no request to this component during the period specified in the IdleTimeLimit parameter, the component exits automatically. The service allows the host to subscribe to updates of virus and other databases, send notifications of the latest updates, upload and share the update files between cloud hosts. The service settings can be configured using the Update* parameters. The standard service usage assumes that Dr.Web MeshD is installed with the enabled feature of obtaining updates on several machines (clients of the service) in the local network of a company. The typical client settings are:
On the host acting as a local server for distributing updates, the following settings are specified:
Here, <server address> in the uplink connection of the client must refer to the <address> and <port> that are used by the server host for managing client connections. When one of the hosts is being updated from the update servers (external to the local cloud—Dr.Web GUS update servers or a centralized protection server), the host sends a notification to all concerned clients (if the host is set as an update exchange server) and sends to the server host a new list of files available for distribution from this host. Upon receiving this notification, client hosts can request downloading updated files from the server, which in turn can request the files from the client to store them locally or to send them to another client that requested these files from the server. The scenario decreases the update delay because clients send requests to Dr.Web GUS at different times, at that the first updated client immediately distributes the latest update files to all concerned cloud hosts. It also decreases the amount of traffic and Dr.Web GUS load.
The service allows to use Dr.Web Scanning Engine for scanning remote files: client hosts send files for scanning to a server host, and server hosts provide a service for scanning files sent by client hosts. Typical client settings are as follows:
The following settings are specified on the host acting as a local scanning server:
Here, <server address> in the uplink connection of the client must refer to the <address> and <port> that are used by the server host for managing client connections. The feature is not used (remote scanning is provided by the Engine service). The service allows to check a URL for belonging to potentially dangerous and non-recommended categories: client hosts send the URL to be checked to the server host. Typical client settings are as follows:
On the local server used for URL check, the following settings are specified:
Here, <server address> in the uplink connection of the client must refer to the <address> and <port> that are used by the server host for managing client connections. |