Icmp exfiltration detector#19557
Open
Bruno-Paese wants to merge 22 commits into
Open
Conversation
Feat: Adding LRU logic and limit size of ICMP dest ip history
…icious ICMP packet detection
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Overview
This pull request introduces an analytical mechanism designed to detect ICMP tunneling and potential data exfiltration within the Maltrail framework. I would like to formally acknowledge the significant contributions of @henriqueAmbrosi, whose collaboration and technical expertise were instrumental in the development and implementation of this functionality.
Theoretical Foundation
The proposed solution strictly adheres to Maltrail's fundamental paradigm of maintaining low computational overhead. Consequently, computationally exhaustive methodologies, such as data entropy analysis, were deliberately excluded. Instead, the detection algorithms are founded upon Inter-Packet Arrival Time (IPAT) metrics to establish a reliable baseline for normative network traffic.
Furthermore, to mitigate the statistical distortion caused by transient, high-volume operational events (e.g., ping sweeps or brief connectivity checks), the baseline traffic frequency is calculated utilizing a weighted average predicated on cumulative packet counts. This ensures that persistent flows guide the baseline, while isolated, noisy flows are appropriately attenuated.
Operational Methodology
The integration extends the core
_process_packetroutine within thesensor.pymodule to systematically analyze both ICMPv4 and ICMPv6 protocols. The system employs memory-efficient data structures—specifically period and size accumulators—to monitor historical packet data without storing individual packet timestamps.The network traffic is continuously evaluated against three distinct heuristic criteria:
Payload Volumetric Analysis: Identifies datagrams whose payload size exceeds a dynamically established average or a predefined absolute volumetric threshold.
Frequency Anomaly Detection: Monitors transmission frequencies to identify statistically significant deviations, either targeting a singular destination IP address or localized strictly within a specific source-destination coordinate pair.
Distributed Exfiltration Identification: Detects coordinated architectural anomalies wherein multiple distinct source IP addresses transmit suspicious volumes of ICMP traffic to a centralized destination server.
Empirical Testing Procedures
To empirically validate the implementation, it is required to execute the sensor module with administrative privileges (
sudo ./.venv/bin/python sensor.py) concurrently with the web interface service (./.venv/bin/python server.py) to ensure properpcap-ngpacket capture. Ensure that these processes are actively running before initiating the following test cases.Test Case 1: Baseline Traffic (Negative Control)
Objective: Verify that standard, normative ICMP traffic does not trigger false positive alerts.
Execution:
IPv4:
ping 1.1.1.24IPv6:
ping ipv6.google.com -6Expected Result: The web interface should not display any ICMP exfiltration alerts, as the transmission frequency and payload sizes remain below the calculated heuristic thresholds.
Test Case 2: Frequency Anomaly Validation
Objective: Validate the detection of high-frequency datagram transmissions indicative of potential exfiltration.
Prerequisites: Configure
ICMP_DESTINATION_TRAFFIC_AUTO_DETECT_BASELINE_TOLERANCE = 2andICMP_SRC_DEST_PAIR_EXFILTRATION_DETECTION_TOLERANCE = 2within the Maltrail configuration file to establish stringent thresholds.Execution:
IPv4:
ping 1.1.1.24 -i 0.002IPv6:
ping ipv6.google.com -6 -i 0.002Expected Result: The web interface must generate the alerts:
"ICMPv4 exfiltration by anomalous traffic to destination (suspicious)"and"ICMPv4 exfiltration by src/dst ips pair (suspicious)"(along with their respective ICMPv6 counterparts).Test Case 3: Payload Volumetric Validation
Objective: Validate the detection of abnormally large ICMP payloads.
Execution:
IPv4:
ping 1.1.1.24 -s 1000IPv6:
ping ipv6.google.com -6 -s 1000Expected Result: The web interface must generate the alerts:
"ICMPv4 large package size (suspicious)"and"ICMPv6 large package size (suspicious)". Note that alerts are expected for both Echo Request and Echo Reply datagrams.Test Case 4: Practical ICMP Tunnel Simulation
Objective: Verify the heuristic triggers under realistic data exfiltration conditions utilizing specialized open-source tunneling software (
icmptunnel).Execution:
Server instantiation:
sudo ./icmptunnel -sClient instantiation (on a distinct node):
sudo ./icmptunnel -c <SERVER_IP>Expected Result: Upon tunnel activation, the web interface must concurrently generate multiple alerts, specifically:
"ICMPv4 exfiltration by anomalous traffic to destination (suspicious)","ICMPv4 exfiltration by src/dst ips pair (suspicious)", and"ICMPv4 large package size (suspicious)".Test Fixtures
To facilitate the validation of the distributed exfiltration heuristic (multiple sources to a singular destination), a proprietary Python script leveraging the
scapylibrary has been developed.This testing fixture circumvents the infrastructural complexities associated with configuring Docker containers or Linux network namespaces. By initiating a native operating system raw socket, the script programmatically synthesizes and transmits pre-compiled raw packets. This approach effectively simulates 200 distinct internal hosts executing spoofed ICMP echo requests towards a designated target, allowing for the rigorous testing of distributed anomaly detection.