Purpose
This guide explains how to configure the Arbor Networks APS (Availability Protection System) Response integration in Logsign USO, so that Incidents and Alarms can automatically, or an analyst can manually, manage cloud-signaling requests, query blocked hosts, configure GRE tunnels, and manage country/host/domain/URL blacklists and whitelists (both globally and per protection group) directly from a Logsign Incident. This is a DDoS-mitigation-oriented Response integration, configured under Settings > Integrations > Responses > +Device.
This is a different product from Arbor Edge Defense (AED). Arbor Networks APS and AED are separate NETSCOUT/Arbor products with different APIs; do not assume configuration or methods from one apply to the other.
Known issues. Three methods in this integration currently do not work as their names describe; see the callouts on create-protection-group, add-hosts-to-outbound-whitelist, blocked-host-query, and whitelist-a-host below, and the Notes and Limits section for the full explanation. A code fix has been proposed to Logsign engineering; until it ships, avoid relying on these four methods in production automation.
Prerequisites
- An Arbor Networks APS appliance with its API reachable from the Logsign server.
- A client certificate for API authentication (Arbor APS uses certificate-based auth for its API, not a username/password).
- Use least privilege. If your APS deployment supports scoped API certificates/roles, restrict this integration's certificate to the specific blacklist/whitelist/protection-group management functions it needs.
Step 1: Obtain an API Certificate from Arbor APS
- Log in to the Arbor APS management console with an administrator account.
- Generate or export an API client certificate for Logsign to use, following your Arbor APS version's certificate-based API authentication process (the exact console navigation path was not independently verified during this research).
- Note the APS appliance's hostname.
Step 2: Configure the Integration in Logsign USO
In Logsign USO, go to Settings > Integrations > Responses, search for Arbor Networks APS, click Configure then +Device, and fill in:
| Field | Required | Description |
|---|---|---|
| Device Name | Yes | Free-text label identifying this Arbor APS device in Logsign. |
| Hostname | Yes | Hostname of your Arbor APS appliance. |
| Certificate Content | Yes | The API client certificate from Step 1. Stored encrypted at rest. |
Click Create to save the device.
Available Methods
Some methods listed below reference field names your account may see differently in the Logsign UI, since a small number of this integration's manifest entries have an internal naming inconsistency between the field labeled as required and its actual property name (for example a method may expect a host_address value even where the field is referenced elsewhere as "hostAddress"). If a specific field does not appear to accept input as expected, try the alternate naming style before assuming a connection problem.
Cloud signaling
- get-active-cloud-signaling — fetches active cloud-signaling entries, with filters for prefixes, request type, mitigation timestamp, and search/sort/paging.
- add-prefixes-to-cloud-signaling — adds prefixes to cloud signaling. Arg: prefixes (required).
Blocked host queries and GRE
- blocked-host-query — queries blocked hosts by time range, with optional filters for source addresses, direction, and attack category. Args required: start time, end time. Known issue: a code bug currently makes this method read the start-time value twice instead of reading start time and end time separately, so the end-time boundary you provide is silently ignored and has no effect on the query.
- configure-gre-tunnels — configures GRE tunnels. Args: subnet_bit_length, local_ip, gre_remote_ips.
Outbound blacklist/whitelist
- add-countries-to-outbound-blacklist — blacklists a country for outbound traffic. Args: country_code (required), annotation.
- add-hosts-to-outbound-blacklist — blacklists a host for outbound traffic. Arg: host address (required).
- add-hosts-to-outbound-whitelist — intended to whitelist a host for outbound traffic, arg: host address (required). Known issue: due to a code bug, calling this method currently runs the create-protection-group logic instead (see below) and does not whitelist a host. Do not use until this is fixed.
Protection groups
- create-protection-group — intended to create a protection group. Args required: name, prefixes, server_type; optional: description, active, protection_level. Known issue: due to a code bug, calling this method currently runs the add-hosts-to-outbound-whitelist logic instead (it reads a host address and adds it to the outbound whitelist) and does not create a protection group. Do not use until this is fixed.
- blacklist-a-country / blacklist-a-domain / blacklist-a-host — blacklists an entry within a specific protection group. Args required: the entry value (country_code, domain, or host) plus pgid.
- whitelist-a-host — whitelists a host. The manifest only shows host as an input, but the integration internally also needs a protection group ID (pgid) that is not exposed as a field. Known issue: because this value cannot currently be supplied, every call resolves to protection group 0 regardless of which group you intended.
Global blacklist/whitelist
- blacklist-a-url — globally blacklists a URL. Arg: url (required).
- add-countries-to-blacklist / add-domains-to-blacklist / add-hosts-to-blacklist / add-urls-to-blacklist — globally blacklists a country/domain/host/URL. Required entry value, plus optional cid, pgid, annotation.
- add-hosts-to-whitelist — globally whitelists a host. Arg: host (required), plus optional cid, pgid, annotation.
Troubleshooting
| Symptom | Likely cause | What to check |
|---|---|---|
| 401/403 error | Wrong, expired, or revoked Certificate Content. | Re-generate the API client certificate in Arbor APS and update the Certificate Content field. |
| A method's required field does not seem to accept the expected input | See the naming-inconsistency note above; some methods have a mismatch between the field name shown as required and its actual property key. | Try both the camelCase and snake_case variants of the field name if the first attempt is rejected, and report the specific method to Logsign support so the manifest can be corrected. |
| create-protection-group whitelists a host instead of creating a group, or add-hosts-to-outbound-whitelist creates a protection group instead of whitelisting a host | Known code issue: these two methods' underlying logic is swapped. | Avoid both methods until Logsign engineering ships the fix; see Notes and Limits. |
| blocked-host-query results don't respect the end time you supplied | Known code issue: the end-time value is currently not read. | Treat results as "from start time onward" rather than a bounded range until this is fixed. |
Notes and Limits
- This is a large, DDoS-mitigation-focused integration with 18 methods spanning cloud signaling, blocked-host queries, GRE tunnel configuration, and blacklist/whitelist management at both global and per-protection-group scope; review Arbor APS's own documentation for how these concepts (protection groups, cloud signaling, CID/PGID scoping) relate to your deployment before using this integration in production automation.
- Known issues (code fix proposed to Logsign engineering, not yet shipped):
- create-protection-group and add-hosts-to-outbound-whitelist currently run each other's logic: calling create-protection-group whitelists a host, and calling add-hosts-to-outbound-whitelist creates a protection group. Avoid both until this is fixed.
- blocked-host-query ignores the end time you supply and only applies the start time, so results are not bounded the way the method's arguments suggest.
- whitelist-a-host needs an internal protection group ID that has no corresponding input field, so it always targets protection group 0 rather than a group you can choose.
- The exact console navigation path for generating an API client certificate was not independently verified against a live Arbor APS appliance during this research (not independently verified); the field names and method behavior above are taken directly from Logsign's integration code.