Response¶

Responses provide a powerful way to automate and extend the system’s reaction to the anomalies detected by Sensor, and to the filtering rules identified by Filter.

To add a new Response, go to Configuration » Network & Policy » [+] and select [Response].

[List Prefixes] generates a list with IP classes configured to use the selected Response.

When invoked by a Sensor or Filter, the Response runs the actions it contains. These “actions” are built-in modules that provide means to execute commands, send notifications and BGP routing updates, write logs, etc.

There are two types of actions:

● Anomaly Actions – These are executed by Sensor for each traffic anomaly immediately after detection, while it is still detected, or when it expires

● Filtering Rule Actions – These are executed by Filter for each filtering rule immediately after detection, while it is still detected, and when it expires. Filtering rules expose malicious packets that share some common OSI layer 3-7 fields (attacker IPs, TCP/UDP ports, packet lengths, protocols, TTLs, content, etc.)

To add an action, click the [+] button on the title bar of the relevant panel from the left side of the window. To view, edit, delete or rename an action, select the action name.

To enable or disable an action, click the small on/off switch button displayed next to the action name.

Each action configuration panel contains action-specific fields. The following fields are always present:

● Action Name – Short description of the action

● Action Priority – Select the order of execution relative to the other actions defined in the same panel. Lower numerical values correspond to increased priority

● Periodicity – Actions can be executed once or periodically. The frequency of execution is 5 seconds for Packet Sensor, Packet Filter, Sensor Cluster and Filter Cluster, or 5-60 seconds for Flow Sensor, depending upon its Granularity parameter

● Execution – Actions can be executed either automatically without end-user intervention, or manually by an operator or administrator that clicks the lightning icon in Reports » Tools » Anomalies » Active Anomalies » Actions

● Record Action – When enabled, the name of the action is recorded and displayed in anomaly reports

● Preconditions – Preconditions are rules that can deny execution of actions. An action is executed only when each precondition is evaluated as true, or when the list of preconditions is empty.

Each precondition is composed from a conditional parameter (listed in Appendix 5), a comparison function, and a user-defined value. Conditional parameters are linked to internal variables whose values are constantly updated by Sensors and Filters.

Tip: To combine conditional parameters in complex ways (e.g. mix logical disjunction and logical conjunction), write a custom script that uses the conditional parameter named “Custom Script Return Value” together with dynamic parameters passed as arguments

Dynamic parameters are parameters (variables) defined within curly brackets “{ and }”, used as parameters or script arguments for most Response actions. Almost every conditional parameter has a corresponding dynamic parameter. All dynamic parameters are listed in Appendix 5.

11.1. Extending the Built-in Actions¶

By adding the Response action named “Execute a command or script with dynamic parameters as arguments” you can easily extend the number of actions executed during attacks and during the detection of filtering rules.

Most data about about the anomaly / filtering rule can be passed to your script as arguments (the full list is listed in Appendix 5). As an example, when the script shown below is called with: /path/to/script/test.sh “{anomaly}” “{ip}” “{sensor}” “{latest_anomaly_bps_kilo}”, the anomaly number, attacked IP, detecting Sensor, and current kbps/s value will be written to a temporary file.

#!/bin/sh
echo "Anomaly: $1, IP: $2, Sensor: $3, Kbits/s: $4" > /tmp/test.txt

To access data not related to the current anomaly / filtering rule, or to automate the actions from Reports » Tools, call the REST API from within your script. The REST API is documented at http://<console_ip>/wanguard-api-ui or www.andrisoft.com/wanguard-api-ui.

All scripts/commands are executed on the detecting Sensor’s server for anomalies and/or on the detecting Filter’s server for filtering rules. When using a custom script, make sure that it can be accessed and executed by the system account named “andrisoft” (e.g. by moving it to /opt/andrisoft/bin). You can check if there are permission-related issues by executing the script manually with “sudo -u andrisoft /path/to/script”. Also, it’s best to write dynamic parameters within single or double quotes.

11.2. Extending the Built-in Preconditions¶

By adding the Precondition named “Custom Script Return Value” you can easily improve the logic which permits an Action to run. Set the Comparison column to “equal” and the Value to a custom script which accepts dynamic parameters as arguments (full list on Appendix 5).

For example, the script shown below (called as “/path/to/script/test.sh {decoder}”) will allow the Action to run only when the decoder is NTP or SNMP:

#!/bin/sh

DECODER=$1

if [ "$DECODER" == "NTP" ] || [ "$DECODER" == "SNMP" ];
then
 exit 0;
else
 exit 1;
fi