Agent settings

Deep Security Agent-related settings are located on Administration > System Settings > Agents. They include the following.

Hostnames

Update the "Hostname" entry if an IP is used as a hostname and a change in IP is detected on the computer after Agent/Appliance-initiated communication or discovery: Updates the IP address displayed in the computer's "Hostname" property field if an IP change is detected.

Agent-initiated activation (AIA)

In addition to activating new agents on Deep Security Manager (such as via a cloud connector or manually adding a new computer on Computers), but you can also (or instead) allow agents to automatically activate themselves. See also Activate and protect agents using agent-initiated activation and communication.

Allow Agent-Initiated Activation: Allow agents to connect to the manager to activate themselves. Then select which computers are allowed to perform agent-initiated activation.

• For Any Computers: Any computer, whether it is already listed on Computers or not.

  To prevent unauthorized agent activations, don't enable this option if your network allows connections to Deep Security Manager from untrusted networks such as the Internet. To similarly protect Deep Security Agent from unauthorized managers, only allow agent activation with your authenticated manager.
• For Existing Computers: Only computers already listed on Computers.
• For Computers on the following IP List: Only computers whose IP address has a match on the specified IP list.

Also configure initiation behavior:

• Policy to assign (if Policy not assigned by activation script): Security policy to assign to the computer during activation. This setting only applies if no policy is specified in the agent's activation script or an AIA event-based task.
• Allow Agent to specify hostname: Allow the agent to specify its hostname by providing it to Deep Security Manager during activation.

• If a computer with the same name already exists: How to handle the activation attempt if the new computer is trying to use the same agent GUID or certificate as an existing computer:

  • Do not allow activation: Don't activate the computer.
  • Activate a new Computer with the same name: Using a new name, create a new computer object and activate the computer.
  • Re-activate the existing Computer: Keeping the same name, reuse the existing computer object and activate the computer.

  This setting only applies to physical computers, Azure virtual machiness (VMs), Google Cloud Platform (GCP) VMs, or VMware VMs. (AWS provides a unique instance ID that Deep Security Manager uses to differentiate all AWS instances, so this setting is ignored for those computers.)

• Reactivate cloned Agents: Reactivate clones as new computers; assign the the policy selected in Policy to assign (if Policy not assigned by activation script). This can be useful when re-imaging computer hard disks, or deploying new VM instances or AMI, using a "golden image" that has an already-activated Deep Security Agent. It ensures that each computer has a unique agent GUID, despite being deployed by copying the same software image.

  Clones are detected after the initial activation, during their first heartbeat. If the same agent GUID is being used on different computers, the manager detects the clones and reactivates those computers.

  If you disable this option, clones will not be automatically reactivated. You'll need to activate them either manually through the manager or via an activation script.

  This setting only applies to AWS instances, Azure virtual machines (VMs), Google Cloud Platform (GCP) VMs, or VMware VMs that you added via Computers > Add Account.

• Reactivate unknown Agents: Reactivate deleted (but previously activated) computers as new computers if they connect again; do not assign the original computer's assigned policies or rules. This setting is useful together with inactive agent cleanup: any accidentally removed computers can automatically re-activate. See also Automate offline computer removal with inactive agent cleanup.

  Previously known agents are detected after the initial activation, during their next heartbeat. If a heartbeat has an agent GUID (indicating prior activation) but its computer is not currently listed on Computers, the manager reactivates the computer.

  Previous event messages will still link to the old computer object, not this new one.

• Agent activation token: Optional. Agent activation secret. If specified, agents must provide the same value when activating.

  If Deep Security Manager is multi-tenant, this setting applies only to the primary tenant.

  To configure this, you can use the token parameter in the agent activation script such as:

  /opt/ds_agent/dsa_control -a dsm://172.16.0.5:4120/ "token:secret"

Agent Upgrade

Automatically upgrade agents on activation: During activation, upgrade Deep Security Agent to the latest software version that's compatible with Deep Security Manager. Linux computers only. See also Automatically upgrade agents on activation.

Inactive Agent Cleanup

If you have many offline computers (that is, they are not communicating with Deep Security Manager), and they don't need to manage them anymore, you can automatically remove them from Computers via inactive agent cleanup. This setting is useful together with reactivating currently unknown agents. See also Automate offline computer removal with inactive agent cleanup.

Delete Agents that have been inactive for: How much time a computer must be inactive in order to be removed.

Data Privacy

Allow packet data capture on encrypted traffic (SSL): Allow packet capture to be enabled on Intrusion Prevention (IPS) rules that apply to SSL/TLS encrypted traffic. Compliance and other policies about sensitive data might not allow this, or might require that you store downloaded packet captures in an encrypted, secure location to avoid compromising security. This setting can be useful for advanced network troubleshooting.

Agentless vCloud Protection

Allow Appliance protection of vCloud VMs: Allow virtual machines in VMware vCloud to be protected by Deep Security Virtual Appliance instead of (or in addition to) Deep Security Agent. If Deep Security Manager is multi-tenant, tenants configure the security policies of those VMs.