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: The eG Enterprise architecture requires the agents to “poll” the manager for information such as what tests the agent should run, how frequently it should run, etc. The agent itself does not listen on any specific port for requests. This minimizes the security risk to the systems on which the agents are deployed.
  • 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 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 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.