Agent settings

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.

The Deep Security Manager always identifies computers by using a unique fingerprint, not their IP addresses or hostnames.

Agent-Initiated Activation

For more information on Agent-Initiated Activation, see Command-Line Utilities and Use a deployment script.

Allow Agent-Initiated Activation

  • For Any Computers: Any computers, whether they are already listed on the Deep Security Manager's Computers page or not.
  • For Existing Computers: Only computers already listed on the Computers page.
  • For Computers on the following IP List: Only computers whose IP address has a match on the specified IP List.

Policy to assign (if Policy not assigned by activation script): The security policy to assign to the computer if no policy has been specified in the activation script.

If an event-based task exists which assigns policies to computers where activation is agent-initiated, the policy specified in the event-based task will override the policy assigned here or in the activation script.

Allow Agent to specify hostname: Select this option to allow the agent to specify the hostname by providing it to the Deep Security Manager during the agent activation process.

If a computer with the same name already exists: If a computer, VMware virtual machine, AWS instance, or Azure VM with the same Agent GUID or certificate is already listed on the Computers page, you can configure the Deep Security Manager to take the following actions:

  • Do Not Allow Activation: The computer object will not be activated.
  • Activate a new Computer with the same name: The Deep Security Manager will create a new computer object with a new name.
  • Re-Activate the existing Computer: The existing computer object will be re-activated.

Reactivate cloned Agents: When a new computer (computer, VMware virtual machine, AWS instance, or Azure VM) that is running an already activated Deep Security Agent sends a heartbeat to the Deep Security Manager, the Deep Security Manager will recognize it as a clone and reactivate it as a new computer. No policies or rules that may have been in place on the original computer will be assigned to the new one. It will be just a like a newly activated computer.

Reactivate unknown Agents:This setting allows previously activated computers (computers, VMware virtual machines, AWS instances, or Azure VMs) that have been removed from their cloud environment and deleted from the Deep Security Manager to be reactivated if they are added back to the inventory of computers. Deep Security Manager will recognize a valid certificate on the computer and allow it to be reactivated. No policies or rules that may have been in place on the original computer will be assigned to the new one. It will be just a like a newly activated computer.

Agent activation secret: When a value is specified here, the same value must be provided when agents activate themselves in the Deep Security Manager. You can provide this agent activation secret in the tenantPassword parameter in the agent activation script. For example, the script for agent-initiated activation on a Linux machine might look like this:

/opt/ds_agent/dsa_control -a dsm://172.31.2.247:4120/ "tenantPassword:secret"

In a multi-tenant environment, the Agent activation secret setting applies only to the primary tenant.

Data Privacy

Allow packet data capture on encrypted traffic (SSL): The Intrusion Prevention module allows you to record the packet data that triggers Intrusion Prevention Rules. This setting lets you turn on data capture when Intrusion Prevention rules are being applied to encrypted traffic.

Agentless vCloud Protection

Allow Appliance protection of vCloud VMs: Allow virtual machines in a vCloud environment to be protected by a Deep Security Virtual Appliance and let the security of those virtual machines be managed by tenants in a multi-tenancy Deep Security environment.