Description
FastNetMon may report an incorrect value in the attack_direction field.
In our environment, an attack was detected because the outgoing flow threshold was exceeded, but the generated report contained:
Attack direction: incoming
The raw traffic statistics clearly indicate that only the outgoing direction exceeded the configured threshold.
Version
FastNetMon Community 1.2.9
Traffic source
NetFlow v9 from MikroTik Traffic Flow.
Configuration
For testing purposes, the flow threshold was intentionally lowered to allow attack detection using a small amount of generated traffic. The low threshold is expected and is not part of a production configuration.
process_incoming_traffic = on
process_outgoing_traffic = on
ban_for_flows = on
threshold_flows = 100
Generated report
Attack direction: incoming
Attack protocol: tcp
Total incoming traffic: 1 mbps
Total outgoing traffic: 1 mbps
Total incoming pps: 245 packets per second
Total outgoing pps: 622 packets per second
Total incoming flows: 78 flows per second
Total outgoing flows: 442 flows per second
Why this appears incorrect
Configured threshold:
Observed values:
Incoming flows: 78 flows/s
Outgoing flows: 442 flows/s
Only the outgoing direction exceeded the configured threshold:
Therefore, the reported direction would be expected to be:
Attack direction: outgoing
instead of:
Attack direction: incoming
Suspected cause
It appears that the threshold check evaluates incoming and outgoing counters together and returns only whether a threshold was exceeded, without preserving which direction actually caused the detection.
As a result, attack_direction may later be populated from another source, a default value, or previously calculated state instead of the direction that exceeded the configured threshold.
Impact
Applications integrating with FastNetMon often rely on:
$fastNetMonData['attack']['attack_direction']
to determine whether an attack is incoming or outgoing.
If this field is incorrect, downstream systems may:
- classify incidents incorrectly,
- trigger incorrect mitigation actions,
- store incorrect forensic information,
- produce misleading reports for SOC/SIEM systems.
Question
Is this expected behavior, or is this a bug?
If it is expected, what is the intended meaning of the attack_direction field?
Description
FastNetMon may report an incorrect value in the
attack_directionfield.In our environment, an attack was detected because the outgoing flow threshold was exceeded, but the generated report contained:
The raw traffic statistics clearly indicate that only the outgoing direction exceeded the configured threshold.
Version
FastNetMon Community 1.2.9
Traffic source
NetFlow v9 from MikroTik Traffic Flow.
Configuration
For testing purposes, the flow threshold was intentionally lowered to allow attack detection using a small amount of generated traffic. The low threshold is expected and is not part of a production configuration.
Generated report
Why this appears incorrect
Configured threshold:
Observed values:
Only the outgoing direction exceeded the configured threshold:
Therefore, the reported direction would be expected to be:
instead of:
Suspected cause
It appears that the threshold check evaluates incoming and outgoing counters together and returns only whether a threshold was exceeded, without preserving which direction actually caused the detection.
As a result,
attack_directionmay later be populated from another source, a default value, or previously calculated state instead of the direction that exceeded the configured threshold.Impact
Applications integrating with FastNetMon often rely on:
to determine whether an attack is incoming or outgoing.
If this field is incorrect, downstream systems may:
Question
Is this expected behavior, or is this a bug?
If it is expected, what is the intended meaning of the
attack_directionfield?