Evaluate direction of flows
to be able to do flow analytics with e. g. akvorado it is recommended to sample ingress and egress on the edge interfaces. This results in twice the flows and fastnetmon being off by factor two. This FR is about taking into account the direction of flows with fastnetmon and only considering ingress flows. For sflow this is allegedly possible by "determin[ing] packet sampling direction by comparing the data source that reported the sample with the ingress/egress port information in the sample. For example, if data source 1 reported a packet sample with ingress port 1 and egress port 3, then it is an ingress packet sample since the data source and the ingress port are the same. " Thanks a lot  https://groups.google.com/g/sflow/c/IxHT3X4wTm0
Flow Spec mode mitigation for total hostgroups
In response to rise of carpet bombing attacks we need to provide flow spec based mitigations on whole prefix.
Option to ignore traffic from some interfaces
In some configurations we may see same traffic more than once. We need some way to explicitly ignore traffic received from some ports / interfaces on switches.
Add per interface traffic dashboard based on Clickhouse metrics
We added capability to export per interface traffic here: https://github.com/FastNetMon/fastnetmon-advanced-releases/releases/tag/v2.0.359
Add a "kill UDP amplification" mode
We could use an advanced setting for UDP amplification attack. I'm imagining this as a kind of setting in which we could enter a list of ports. The idea is to put in a list of ports frequently used for UDP amplification attacks (port 53, 123, etc.), which FastNetMon could block completely in the event of a attack from this source ports. The goal would be that when FastNetMon performs a packet capture & analysis (following the triggering of a threshold), if it finds a packet in the list with a "source port" that matches one present in the setting, it would immediately creates a flowspec rule to drop traffic with this source port. This would probably save a few seconds when an attack is detected (it's common for FastNetMon to try to create 4 or 5 different rules with different packet sizes in the first few seconds, when it would be enough to block all of port 53 or 123).
Add popular amplification vectors as fixed static thresholds
It's really good reference from customer how it can be useful: https://github.com/rganascim/fastnetmon/commit/d28b8e3518c3f13e378fa4c8fd078c72d1787280 Proposed thresholds: NTP DNS LDAP GRE SSDP Chargen Protocol 0