Most UpGuard users take advantage of the ability to scan devices using an agentless approach. This approach is easy to set up and maintain, but is not always feasible for some of the more elaborate network topologies and environments that the target nodes may live in. Thus, it is sometimes necessary to use the agent instead, both for connectivity reasons and to take advantage of some of the innate properties of such a setup. This post will outline some of the common scenarios where agents are most sensible, and how you can set up the rest of your environment to work best with that setup.
The different types of UpGuard connectivity
UpGuard is capable of scanning nodes through two different connectivity methods: agent-based and agentless. While the output of these two methods is exactly the same, they differ in how they handle connecting to the node:
- Nodes are scanned by an agent, with one agent being associated with one node
- The agent must be installed on the target node directly
- The agent initiates a connection to the associated appliance over HTTPS on port 443
- The agent runs continuously, but only initiates a scan if a job has been queued on the appliance
- Nodes are scanned by a connection manager, with one connection manager being associated with many nodes
- The connection manager is installed on a central server, with the appropriate level of connectivity to it’s target nodes
- The connection manager initiates a connection to it’s target nodes over a protocol and port appropriate to the target device
- The connection manager only opens these connections when a scan is requested
- Appliances ship with a built-in Connection Manager that handles all non-Windows based node types.
More often than not, users will opt to utilize the agentless approach; it provides all of the normal scanning functionality, without the need to manage the installation and maintenance of a fleet of agents. However, this approach does come with one drawback: The connection manager must be able to reach the target node at the time of scan. While this is no problem for standard server-based installations, there are a number of scenarios where this is untenable, and the agent-based approach becomes the better option.
How your environment affects connectivity
If the assets being scanned are network-topologically static and stable, then you will almost always opt for a connection manager-based approach. However, there are numerous instances where this is not the case:
- Laptop-heavy environments, where users may readily move between networks or shut the laptop down
- Environments outside of your direct control, or without direct connectivity to your internal networks, such as a client’s network when acting as an MSP
- DMZ and similar networks, such as guest networks in hotel lobbies or coffee shops
- Special purpose machines whose network connectivity cannot be assured, such as on sea-going vessels, or rovers exploring Mars.
In such cases, the agent becomes the far better choice than the connection manager to when it comes to achieving consistent results when scanning. Because the agent connects directly to the appliance, and does so on a regular basis, it will most often be able to reach the appliance at scan time, especially when utilized with a hosted appliance. Despite this, there are still instances where the agent may not be able to connect in an appropriate window surrounding the scan, and it can be helpful to alter the way scans are scheduled to align with this.
Manipulating scans schedules to ensure connectivity
Nodes within UpGuard are, by default, scanned once a day as part of scheduled environment scans. This is suitable for servers, but rarely works for more mobile or other more specialized devices, and as such it can often be necessary to change the way that UpGuard handles scans. What this change should look like will depend on the type of environment you have.
Client devices (workstations, kiosks, etc.) most often suffer from either being in a DMZ-like network, being frequently turned off, or both, but otherwise reamin in the same place within the network. When it comes to scanning these regularly and successfully, the simplest option can often be to simply increase the frequency with which the scheduled scans run. 12 or even 6 hour intervals will often be sufficient to ensure that the node is online for at least one of the scheduled windows each day.
Devices that may be moved present similar challenges to stationary clients, as
well as the added problems associated with moving between networks. To achieve success in this scenario,
it (somewhat counterintuitively) serves to disable environment scans for the target nodes completely,
and opt to have the endpoint indicate when scanning should be performed. This can be as simple as a
curl command associated with a
cron job, or as elaborate as having another system confirm connectivity
and indicate that the node is available on its behalf. In either case, the benefit to this approach is
two-fold: there will be no perceived scan failures due to scheduled jobs simply executing at the wrong time
(reducing false alerts) and the average success rate of scans will be greatly increased.
As we can see, while there is additional setup involved, agents can be used to great effect to overcome problems with connectivity that would be infeasible to work around when scanning via connection managers. In addition, the agent provides avenues for scan scheduling that are simply not available to connection manager-based setups, which helps to reduce the number of false alarms and ensures that you are only being alerted to things of legitimate importance.
Note: You can find example code for initiating scans and more over at our public content repo.