The goal of this document is to provide details on the ThreatIQ feature in Copilot, a high-level summary of its workflow and how to handle an alert, using an example from an alert that was observed on the ABI Copilot on 28th Nov.
Configuration and setup details will not be delved into as this is well documented in the official Aviatrix documentation -
• Multi-Cloud native network security to dynamically identify, alerts on, and automatically remediate (Block threats option under ThreatIQ) potential threats to known malicious destinations
• Distributed threat visibility and control built into the network data-plane at every hop
• Identify potential data exfiltration and compromised host
• No data-plane performance impact
• Complementary security solution with full multi-cloud support
Reasons for the alert and what it triggered against.
Key points:
- ‘reference’ the specific Threat Db file the IP was listed in
- ‘msg’ ET TOR Known for Relay…
- ‘signature_severity’ is INFORMATIONAL
Questions that come to mind on the above?
Why was this IP considered a threat?
This could have been flagged by KPN (ISP) itself, believe it or not. Hops/nodes are pulled into TOR networks regularly as relays. If a node is suspected to be a relay (compared to an exit) node, then it will still be categorized as TOR even if it's just been included in the network and not directly culpable.
Threat actors usually leverage anonymization techniques and technologies to circumvent detection.
This document pretty much conveys that information and the reasons for identifying traffic emanating from the TOR network, recommending caution on allowing such traffic to access customers’ Internet exposed services.
Tor, short for The Onion Router, is free and open-source software for enabling anonymous communication.
It directs Internet traffic via a free, worldwide, volunteer overlay network that consists of more than seven thousand relays.
2. In this specific case, the reason for the alert was ‘TOR relay’ so check/parse the ‘emerging-tor.rules’ file, entry is still seen :
How does Aviatrix ThreatIQ handle this?
If the ‘block traffic’ option is enabled in ThreatIQ, then the Controller sets a firewall rule on the specific Aviatrix gateways (in this specific case ‘eur-hub-weu-prod-avxtransit-gw’).
Screenshot below summarizes this:
Expanded view of the firewall rule on ‘eu-hub-weu-prod-avxtransit-gw’
What happens if this IP is no longer listed as a ‘threat’?
ThreatIQ will automatically detect this when it parses the updated ‘Threat DB’; the controller will remove the firewall rule that was inserted on the affect Aviatrix gateways
If it is determined that the flow in this case should be allowed, you have the option to ‘disable blocking’ via the controller (note this removes any deny rules that were set for previous threat alerts) and make use of the ‘custom threatIQ’ to many the ‘IP deny list’