Explore

ThreatIQ Overview

⁠
`1. Introduction`⁠
⁠

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 -

Blocking Known Threat IP Traffic using ThreatIQ :: Documentation (aviatrix.com)⁠

⁠

⁠
`1.1 ThreatIQ References`⁠
⁠

· Official Doc:

Blocking Known Threat IP Traffic using ThreatIQ :: Documentation (aviatrix.com)⁠

⁠

· YouTube Overview:

https://www.youtube.com/watch?v=lXBsi8bEJXc⁠

⁠

⁠
`2. ThreatIQ Overview`⁠
⁠

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

⁠

• 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

⁠
`2.1 How does ThreatIQ work`⁠
⁠

The feature relies on Netflow ensure this is configured.

This can now be configured via Copilot (as well as the Controller):

⁠

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)

(

https://rules.emergingthreats.net/blockrules/⁠

)

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

⁠
`3.0` ⁠
ABI Copilot ThreatIQ Alert

This section will detail the threat alert seen on the ABI copilot:

⁠

- Date observed 28th Nov

- The ‘Threat IP’ identified as 77.174.62.158

⁠
`3.1 Details on the Threat Alert`⁠
⁠

⁠

Below is detailed netflow information, note

RIPE⁠

(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:

⁠

Detailed Netflow:

The flow that triggered the alert:

Source Destination

172.17.193.134 (port 56491) -> 77.174.62.158 (port 123) UDP

⁠

⁠
`3.1.2 Threat Summary`⁠
⁠

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.

⁠

PROTECT - Defending Against the Malicious Use of the Tor Network (October 2021).pdf (cyber.gov.au)⁠

⁠

Also this link to find out more about the IP (collaborates ThreatIQ findings):

⁠

AbuseIPDB - IP address abuse reports - Making the Internet safer, one IP at a time⁠

⁠

e.g.

⁠

What is TOR Network?

⁠

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:

⁠

Tor Project | History⁠

⁠

TOR Exit Nodes Geolocated | BigDataCloud⁠

⁠

How to check whether this IP is listed on the Threatdb?

1. Navigate to:

⁠

Proofpoint Emerging Threats Rules⁠

⁠

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

⁠
`4.0 Granular control of blocked IPs`⁠
⁠

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’

⁠

https://docs.aviatrix.com/documentation/latest/network-security/threats-guard.html#add-a-custom-threatiq-ip-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

⁠

⁠
⁠

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.

ThreatIQ Overview

⁠1. Introduction⁠⁠

⁠1.1 ThreatIQ References⁠⁠

⁠2. ThreatIQ Overview⁠⁠

⁠2.1 How does ThreatIQ work⁠⁠

⁠3.0 ⁠ABI Copilot ThreatIQ Alert

⁠3.1 Details on the Threat Alert⁠⁠

⁠3.1.2 Threat Summary⁠⁠

⁠4.0 Granular control of blocked IPs⁠⁠