Security Aspects of the eG Agent Architecture

The noteworthy aspects of the eG agent architecture are as follows:

  • No listening ports open on the agents: In the eG Enterprise architecture, the eG agents normally do not listen on external TCP ports. Communications with the eG manager are initiated by the agents, so the agent does not have to listen for any commands from the manager. Instructions such as what tests the agent should run, how frequently it should run, etc., are provided to the agents by the eG manager when the agents connect to them. External-facing TCP ports opened on customer systems can often entry points for attackers. Hence, by not listening to external TCP ports, the eG agent minimizes security risk to the systems it is deployed on.

    Note that there may be a few situations in which the eG agents have to listen to external TCP ports:

    • A remote agent is configured to receive NetFlow records from network devices. In this case, the eG agent NetFlow service needs to receive and analyze NetFlow records.

    • An external agent monitoring network devices may receive SNMP traps from these devices. A separate eG Trap Receiver service may need to receive SNMP traps.

    • A remote agent monitoring a Microsoft Office 365 tenant may use Webhooks to receive notifications. A separate Webhook service is configured to receive such notifications.

  • 100% web-based communication with the eG manager: IT infrastructures typically include multiple demilitarized zones. From a security perspective, most IT infrastructure operators view SNMP and other proprietary protocols suspiciously. On the other hand, HTTP/HTTPS traffic is not viewed as a serious security threat. Consequently, the agent uses HTTP/HTTPS for all communications with the manager. HTTPS support is particularly useful for remote monitoring across multiple locations, wherein the manager may be in a central location, and the agents at remote locations use the public Internet to communicate with the manager.
  • Unidirectional communication only - from the agent to the manager: All HTTP/HTTPS communications in the eG Enterprise architecture originate from the agent. Consequently, any firewalls between the eG agent and the manager need to allow HTTP/HTTPS connections to be initiated in one direction only - i.e., from the eG agent to the manager. The manager never attempts to communicate directly to the agents.
  • Support for private networks, proxied networks, NATed environments: Since the eG manager never initiates communication with the eG agents directly, the eG Enterprise system supports even private networks that may not be directly accessible from the eG manager system. For example, the network being managed could be behind a Network Address Translator (NAT) and the server being managed may have a private IP address. Since the eG architecture allows secure web-based communication, there is no explicit need to set up VPNs just for the purpose of monitoring. The use of web protocols for communication also implies that the agents can be communicating through a web proxy to the management console. This functionality may be useful for networks wherein the administrator may prefer to have only one central server directly accessible to the public Internet.
  • Authenticated communication: The manager/agent communication protocol has authentication built-in. When it receives a request from an agent, the manager validates the agent based on the IP address of the host from which it is communicating. This authentication mechanism ensures that only eG agents can communicate with the manager. Furthermore, the manager checks the list of managed servers to make sure that the agent connecting to it happens to be from one of these servers.
  • Encrypted communication: The manager/agent communication can be encrypted using industry standard SSL technology. Encryption prevents any third- party from snooping and decoding the data transmitted between the manager and agents.

  • Support for communication through web proxy servers: In some IT environments, administrators may require that all communications out of their network be passed through a central server. Because eG Enterprise uses web protocols for communication, the agents can be configured to communicate to the manager through a web proxy. These communications can be secured through standard web authentication mechanisms.

  • Failover capabilities: If the agent to manager communication link goes down, data is temporarily stored on the agent system for a pre-defined period of time. When the network link comes back up, the agent uploads the stored data back to the eG manager for storage and analysis. This ensures that the eG agent architecture is robust to sporadic network failures.

  • Secure execution of Signed PowerShell scripts:eG agents monitoring Windows servers and applications run several proprietary PowerShell scripts for auto-discovery and performance monitoring. To ensure security, by default, the eG agents run PowerShell scripts that are digitally signed by eG Innovations. If any change is made to the scripts by an attacker, the execution of the script will fail.

    For troubleshooting purposes, an administrator/eG support person may want to modify the script and test the output. For such cases, the eG agent also includes unsigned version of the scripts. Whether the eG agent executes signed or unsigned scripts is determined by a flag UsedSignedPSScripts in the <EG_MANAGER_INSTALL_DIR> /manager/config folder of the eG manager (on Unix, EG_MANAGER_INSTALL_DIR is /opt/egurkha). If the value is true, only signed scripts are executed. If the value is false, unsigned scripts are executed.

    When executing a PowerShell script, the eG agent sets the Powershell execution policy to RemoteSigned. PowerShell's execution policy is a safety feature that controls the conditions under which PowerShell loads configuration files and runs scripts. This feature helps prevent the execution of malicious scripts. Since the execution policy is set to RemoteSigned, the eG agent will not execute unsigned scripts downloaded from the Internet.

  • Secure folder permissions: By default, the eG agent is installed in the “Program Files” folder of a Microsoft Windows operating system. Installing programs in the "Program Files" folder of a Windows OS helps prevent unauthorized or accidental modification of the eG agent’s files by restricting access to these files. By default, the "Program Files" folder is protected by the OS and only users with administrator-level permissions can make changes to the files within this folder. Standard users will not be able to make changes to the eG agent’s files, and this helps prevent accidental deletion or modification of the files. Additionally, this also prevents unauthorized access by malicious software or users who may try to modify the eG agent’s files for malicious purposes.

    Care has been taken to ensure that even if the eG agent is installed in a different folder, the eG agent folder’s permission has been configured during agent installation to prevent standard users from making modifications to the folder or its contents.

  • Secure upgrade process: eG agents are auto-upgradable. They download the upgrade packages from the management server and upgrade themselves. To safeguard against the upgrade process being manipulated by third parties, the agent now compares the checksum of each and every file being extracted during the upgrade with the expected value. Only if all files extracted are valid does the upgrade process continue. This checksum validation process ensures that unexpected corruption or manipulation of files in the upgrade process is detected and prevents any malicious files from being installed on the agent systems.