Agent settings

Hostnames

Does not apply to Deep Security as a Service

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. (Deep Security Manager always identifies computers by using a unique fingerprint, not their IP addresses or hostnames.)

Update the "Hostname" entry if an IP is not used as a hostname and a change in hostname is detected on the computer after Agent/Appliance-initiated communication or discovery: Updates the hostname displayed in the computer's "Hostname" property field if a hostname change is detected. (Deep Security Manager always identifies computers by using a unique fingerprint, not their IP addresses or hostnames.)

Agent-Initiated Activation

The standard method of installing and activating an Agent on a computer is to install the Agent on a computer and then to use the Deep Security Manager to "activate the Agent". This activation sends a unique encrypted fingerprint from the Manager to the Agent and the Agent will now refuse any instructions that are not identified as coming from the Manager by that fingerprint.

There may be circumstances, however, where it is desirable for the activation to be initiated by the Agent rather than by the Manager. (Large, distributed installations, for example.) In this case the Manager must be configured to allow Agents to communicate with it and initiate activation. Use the Agent-Initiated Activation panel to set restrictions on which computers can initiate their own Agent activations.

Agent-initiated activation is performed from the command-line. The following are the Agent's activation-related command-line options:

Usage: dsa_control [-a <str>] [-g <str>] [-c <str>] [-r] Notes
-a <str> Activate Agent with Manager at specified URL. URL format must be "dsm://hostname:port/" "hostname" is the Manager's domain name (such as dsm.example.com), IP4 address, or IPv6 address. "port" is the Manager's listening port for heartbeats.
-g <str> Agent URL in the format "https://ip:port/" "port" is the agent's listening port for heartbeats.
-c <str> Certificate file. Default is "ds_agent.crt". dsa_control will use the correct certificate automatically. There is no need to use this option unless you have multiple Agents installed in different directories, or you are trying to control an Agent on another computer.
-r Reset Agent configuration

You can instruct Deep Security Manager to send a default Policy to self-activating Agents which do not already have a Policy assigned to them. Use the Policy to assign (if Policy not assigned by activation script) option to select a Policy.

If you allow Agent-Initiated Activated Activation, there are several further options you can configure:

Specify on which computers you will 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.

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:

  • 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.
For more information on Agent-Initiated Activation, see Command-Line Utilities and Use a deployment script.

Data Privacy

Does not apply to Deep Security as a Service

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

Does not apply to Deep Security as a Service

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.