Share
Explore

ThreatIQ Overview

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 -

What does it offer:
• Multi-Cloud native network security to dynamically identify, alerts on, and automatically remediate (Block threats option under ThreatIQ) potential threats to known malicious destinations

image.png

• 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

The feature relies on Netflow ensure this is configured.
This can now be configured via Copilot (as well as the Controller):
image.png
Distributed Inspection & Notification
• Aviatrix gateways across Multi-Cloud environment send real-time Netflow data to CoPilot
• CoPilot analyzes the data on all public destinations against well-known threat DB (every 60mins)
In general these files:
- 3coresec.rules
- emerging-botcc.rule
- emerging-compromised.rule
- emerging-tor.rules
- emerging-ciarmy.rules
• CoPilot alerts and provides visibility on any potential threats in the environment
• ThreatIQ can be configured to alert (email)

Distributed Enforcement
• CoPilot informs Aviatrix Controller to push firewall policies to all the Aviatrix gateways in the data path
(copilot instructs the controller to program DROP rules in the Aviatrix gateways where the threat Ips were observed)
• Firewall policies automatically get updated with the current status of the threat
• Blocking threats with firewall policy is optional but recommended


ABI Copilot ThreatIQ Alert

This section will detail the threat alert seen on the ABI copilot:
image.png
- Date observed 28th Nov
- The ‘Threat IP’ identified as 77.174.62.158


image.png

Below is detailed netflow information, note
(Internet IP registrar) has details of which entity/organization the IP/IP block is registered with.
(Via cli running ‘whois 77.174.62.158’ will provide pretty much the same information)
RIPE details:

image.png
Detailed Netflow:
The flow that triggered the alert:
Source Destination
172.17.193.134 (port 56491) -> 77.174.62.158 (port 123) UDP
image.png

Reasons for the alert and what it triggered against.
image.png
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.
Also this link to find out more about the IP (collaborates ThreatIQ findings):
e.g.

image.png


What is TOR Network?
tor.jpg
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.

Information on TOR:
How to check whether this IP is listed on the Threatdb?
1. Navigate to:
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 :
image.png
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:
image.png


Expanded view of the firewall rule on ‘eu-hub-weu-prod-avxtransit-gw’
image.png
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’
For the specific case of the threat alert flow :
172.17.193.134 (port 56491) -> 77.174.62.158 (port 123) UDP
1. Determine if this flow is warranted
a. What is the flow, is it needed?
b. Is there another option that avoids ‘TOR’ listed IPs?

4.1 Example of Controller updating Aviatrix Gateway with IPSET rule

From the controller logs ~/etc/localgateway/<aviatrix gateway name>-security-policy.dat file.
IPSET rule being added for 77.174.62.158/32
Action to DROP from any traffic to the matched IP
image.png

Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.