Port Scan Detection about theia

[Dhruv-J]

The necessary changes to Theia are changes to the spark operator, and adding CLI commands. Both changes to flow-exporter and flow-aggregator will need to be implemented in Antrea, and a separate issue and design document will need to be outlined within the Antrea repository.

Design Document

Introduction

The bulk of the logic needed to be implemented in Theia is for determining candidates for a port scan attack based on logs of incomplete or attempted connections.

Necessary Fields

The following are fields that will be stored in the logs to describe the incomplete or attempted connections:

• time
• sourceIP
• destinationIP
• destinationPort
• destinationPodName
• destinationPodLabel
• protocol
• HTTP flags

Possible Approaches to Attack Detection

There are several possible approaches to detecting the attacks themselves, with varying complexities and effectiveness.

1. SYN sent to SYN-ACK received ratio

An extremely simple method of testing for a likely attacker is by checking the logs for the ratio of SYNs sent to SYN-ACKs received. A normal IP attempting to communicate would know the port that it's trying to communicate with, and wouldn't continue to send SYN requests without corresponding acknowledgement. A number could be defined, 3 for example, that is the acceptable ratio of SYN to SYN-ACK. This approach is simple and requires little computation with the data but could be accurate for simpler port scan attacks.

2. Time interval and Port

Another simple method of testing for a likely attacker is by checking the logs for batches of connections with similar intervals between attempts with consecutive or commonly used ports being checked in succession. For example, if an attacker attempted to connect to an IP with port range 3000-3500 with 20 ms between each request, the algorithm would know through timestamps and an increasing port number that a port scan attack is likely being carried out. Even for longer intervals for slow port scan attacks, the algorithm could catch the similar intervals between port checks.

3. Dempster Shaffer Portscan Detection

This approach is by far the most complex of the 3. Dempster Shaffer evidence theory attempts to extrapolate information through taking any evidence that could affect an outcome into account. In order to do this, it defines a mass function that outlines probabilities of individual outcomes occurring and the weights of the evidence which caused those outcomes. In our case, traffic features would be used as the evidences, and would be used to evaluate the comprehensive threat. Additionally, Dempster Shaffer also gives a measure of plausibility, which can be used to determine an upper bound for a confidence interval of the result. Populating the mass function itself may require some logic from approaches 1 and 2, but I'll update this document after some more research. Additionally, Dempster Shaffer requires more resources to run, as it potentially has a O(2^n) complexity.

CLI features

• top N potential attackers, rated by confidence of classification
• potential for adding ingress rules blocking attacking IPs

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment, or this will be closed in 90 days