12. Network & Policy » 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. Different Responses can be configured for each IP, subnet, traffic threshold, or anomaly type.
To add a new Response, go to Configuration » Network & Policy » [+] and click [Response].
The top bar permits renaming and deleting the Response, as well as showing a list with the IP classes configured to use it.
12.1. Response Actions¶
When invoked by a Sensor or Filter, the Response runs the actions it contains. These are built-in modules that provide the means to execute commands, send notifications, send BGP routing updates, write logs, etc.
There are two types of actions:
Anomaly Actions are executed by Sensor for each traffic anomaly. To execute such an action immediately upon the detection of an anomaly or while an anomaly is being detected, add it to the When an anomaly is detected… panel. To execute an action when the anomaly expires, add it to the When an anomaly expires… panel
Filtering Rule Actions are executed for each filtering rule identified by Filter. To execute such action immediately upon the identification of a filtering rule or while a filtering rule is being identified, add it to the When a filtering rule is detected.. panel. To execute an action when the filtering rule expires, add it to the When a filtering rule expires… panel
To add an action, click the [+] button from the title bar of the relevant panel from the left-hand side of the window. To view, edit, delete or rename an action, select the action’s name. To enable or disable an action, click the small on/off switch button displayed next to it.
Each action configuration panel contains some action-specific fields. The following fields are present in all actions:
● Action Name – Short description of the action● Priority – Select the order of execution relative to the other actions defined within the same panel. Lower numerical values correspond to increased priority● Periodicity – Actions can be executed once per anomaly/filtering rule, 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 automatically without end-user intervention or manually by an Operator or Administrator that clicks the lightning icon from Reports » Tools » Anomalies● Preconditions Policy – When the first option is selected, the action is executed only when all preconditions (defined below) are evaluated as true. When the second option is selected, the action is executed if at least one precondition is evaluated as true. The action is executed without restrictions when the list of preconditions is empty● Record Action – When checked, the name of the action is recorded and displayed in anomaly reports● Preconditions – May contain rules that, when evaluated as false, will deny the action’s execution. Each precondition is composed of a conditional parameter, a comparison function, and a user-defined value. Conditional parameters are linked to internal variables whose values are constantly updated by Sensors and Filters. Appendix 4 - Conditional Parameters & Dynamic Parameters lists and describes each conditional parameter
Dynamic parameters are 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 4 - Conditional Parameters & Dynamic Parameters.
12.1.1. Announce the destination IP address in a BGP routing update¶
Use this action to announce the anomaly’s prefix in a BGP routing update. To prevent uplink network congestion, set up D/RTBH by following Appendix 3 from the User Guide. Add a severity-related Precondition (e.g. Peak Link Severity) to avoid blackholing during weak attacks.
12.1.2. Capture a sample of malicious packets¶
Use this action to capture a packet sample with the anomaly’s traffic. Capturing packets is possible only for anomalies detected by Packet Sensor. Limit the size of the packet dump or use the second Sampling Type option.
12.1.3. Detect filtering rules and mitigate the attack with Wanguard Filter¶
Use this action to activate a Wanguard Filter instance that detects which filtering rules can mitigate the attack. You can define a Precondition to activate the Filter only when the attack is strong enough. Wanguard Filter stops automatically when the anomaly expires.
12.1.4. Execute a command or script¶
Use this action if you want to extend the software’s capabilities with custom scripts or commands. You can pass the dynamic parameters listed on Appendix 4 as arguments to the command. Use “sudo” to elevate privileges if the command or script needs root privileges.
12.1.5. Modify anomaly parameter¶
Use this action to change the anomaly status based on custom preconditions, set a custom anomaly description or comments, or change the expiration time.
12.1.6. Send a custom email notification¶
Use this action to send informative emails during anomalies. Customize the sender in Configuration » General Settings » Outgoing Email. Emails are delivered by the MTA (Postfix, Qmail, Sendmail) running on the Console server.
12.1.7. Send a custom Syslog message¶
Use this action to send a custom Syslog message. Use Syslog for central log collection, compliance, and reporting to a SIEM. Syslog messages are delivered to the Syslog service running on the Console server.
12.1.8. Send a custom SNMP trap¶
Use this action to send a custom SNMP trap to a management station. SNMP traps are sent using the snmptrap command executed on the Console server.
12.1.9. Send a visual or audio notification to logged-in Console users¶
Use this action to notify all logged-in Console users that an anomaly has been detected. Permit user accounts to receive notifications in Configuration » General Settings » User Management. Upload custom audio notification files in /opt/andrisoft/webroot/mp3.
12.1.10. Participate in A.T.L.A.S. with anomaly statistics¶
Members of A.T.L.A.S. are provided with a globally-scoped view into malicious activities. Enterprise support customers benefit from a Global NOC supervision and managed security services.
12.1.11. Generate an anomaly report and send it by email¶
Use this action to generate a full anomaly report—after the anomaly has finished—and then send it by email to relevant recipients.
12.1.12. Announce a BGP routing update with Flowspec or S/RTBH¶
Use this action to mitigate attacks with Flowspec or S/RTBH. Deploy BGP Flowspec to mitigate attacks by dropping the malicious traffic on the edge router. Filtering rules compatible with Flowspec are listed in Configuration » General Settings » Anomaly Mitigation.
12.1.13. Apply the filtering rule on a third-party inline device¶
Use this action when using a custom script that pushes the filtering rules to an inline third-party device. Install custom ACLs on existing inline appliances such as routers, IPSes, firewalls and load balancers. Helper wrapper scripts not included.
12.1.14. Delete the filtering rule on a third-party inline device¶
Use this action when using a custom script to delete the filtering rules applied on an inline third-party device.
12.1.15. Capture a sample of packets matched by the filtering rule¶
Use this action to capture a packet sample of the traffic that matches the filtering rule. The capturing process stops automatically when the filtering rule expires. Limit the size of the packet dump or use the second Sampling Type option.
12.1.16. Modify filtering rule parameter¶
Use this action to modify the CIDR mask of the attacker or victim, whitelist or stop the filtering rule. You can change the CIDR mask for Flowspec to mitigate carpet-bombing attacks more efficiently. Set the priority of the action to Highest, to modify the parameters before other actions are executed.
12.2. Extending the Built-in Preconditions and Actions¶
If you need to improve the logic in which actions are allowed to run, add the precondition named Custom Script Return Value. With it, you can implement your own custom precondition, or you can mix logical disjunction and logical conjunction in any way you wish. Just set the Comparison field to “equal to”, and in the Value field enter the path to a custom script that accepts dynamic parameters (full list on Appendix 4 - Conditional Parameters & Dynamic Parameters) as arguments.
If you want to extend the number of actions, add the Response action named Execute a command or script with dynamic parameters as arguments. You can pass useful information collected from Wanguard as arguments to your script. Make sure that the script can be run as the “andrisoft” user, and that your script does not require any input from the terminal during execution. You can check if the permissions of the “andrisoft” user are sufficient by executing the script from the CLI with the “sudo -u andrisoft /path/to/your/script.sh” command. It is recommended to output the script’s output to a temporary file, in order to catch any errors, by appending ” > /tmp/script_output.txt 2>&1” to the command. That way you can verify the script’s output in /tmp/script_output.txt.
To access data not related to the current anomaly or filtering rule, or to automate the actions available on Reports » Tools, call the REST API from within your script.
As an example, the script shown below will write the anomaly number ({anomaly} as 1st argument), attacked IP ({ip} as 2nd argument), detecting Sensor ({sensor} as 3rd argument), and current kbps/s value ({latest_anomaly_bps_kilo} as 4th argument) to a temporary file when the decoder that detected the anomaly is either NTP or SNMP.
#!/bin/sh
DECODER=$1
if [ "$DECODER" = "NTP" ] || [ "$DECODER" = "SNMP" ];
then
exit 0;
else
exit 1;
fi
#!/bin/sh
echo "Anomaly: $1, IP: $2, Sensor: $3, Kbits/s: $4" > /tmp/test.txt
Note
When writing a script, make sure that it can be accessed and executed by the system account named “andrisoft”. You can check if there are permission-related issues by executing the script manually with “sudo -u andrisoft /path/to/script”. Dynamic parameters should be passed within single or double-quotes.
12.3. Using the REST API¶
The REST API’s calls are fully documented at www.andrisoft.com/wanguard-api-ui. To be able to use the REST API, make sure that you have the package wanrestapi installed on your Console. Then go to General Settings » User Management and enable REST API Access for one of your users. Open http://<console_ip>/wanguard-api-ui and authenticate with the user’s credentials by clicking the [Authorize] button from the top-right part of the web page.
The API calls are ordered in a way that resembles the navigation structure of Wanguard Console. If you click on any resource, you will see what parameters it accepts, you can test the call to see the results, and you can also copy/paste the exact command needed to call the method from any scripting language or from the CLI. Each REST API call uses one of the following HTTP methods:
#!/bin/sh
curl -X GET --header 'Accept: application/json' --header 'Authorization: Basic XXXXXXX==' 'https://console/wanguard-api/v1/anomalies?status=Active'
#!/usr/bin/php
<?php
error_reporting(E_ALL);
$wgUser = 'api_user';
$wgPass = 'api_pass';
$wgUrl = 'https://wanguard_console/wanguard-api/v1/bgp_announcements_actions';
$payload = json_encode([ 'batch_action' => "Clear" ]);
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $wgUrl);
curl_setopt($ch, CURLOPT_TIMEOUT, 30);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_HTTPAUTH, CURLAUTH_ANY);
curl_setopt($ch, CURLOPT_USERPWD, "$wgUser:$wgPass");
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 0);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0);
curl_setopt($ch, CURLOPT_POSTFIELDS, $payload);
curl_setopt($ch, CURLOPT_HTTPHEADER, ['Content-Type:application/json']);
$result = curl_exec($ch);
if (curl_errno($ch)) {
echo sprintf("Error: %s\n", curl_error($ch));
} else {
echo $result;
}
curl_close($ch);
?>