Juniper flow sources for DDoS detection
Information
| Summary: |
Effect of long duration of Juniper flows in combination with sampling for DDoS detection. |
| Environment: |
Product: DDoS Version: Any Platform: Any |
| Question/Problem Description: |
Why was the attack not detected even threshold was exceeded? |
| Steps to Reproduce: | |
| Error Message: | |
| Defect Number: | |
| Enhancement Number: | |
| Cause: | Long duration of Juniper flows. |
| Resolution: | Juniper devices will generate new flow according to flow active and inactive timeout settings. However, if the monitored session is longer than an active timeout, the session's start time persists and is propagated to the following flow: Long duration of Juniper flows Flowmon Collector will receive data in delay (according to flow received time). PPS/BPS ratio is calculated for each flow received by Collector (ratio/duration), and this value is stored in buffer (floating time window according to anomaly length) for each second. However, most calculation inaccuracies are caused by flows with long duration (e.g. 30 minutes) in combination with used sampling. It means it generates a big lowering of the bitrate if there is a very long flow (iperf traffic). To display bandwidth in a graph, statistics are aggregated in 30s intervals, so from the graph it seems like the threshold was exceeded, however from an anomaly length perspective it was not. We recommend using Flowmon probe as Flowsource for DDoS to bring precise traffic values, without sampling with accurate times and adding adaptive or min rate attack sub-rules for the baseline based on (TCP SYN/ACK). |
| Workaround: | |
| Notes: | Juniper documentation: https://supportportal.juniper.net/sfc/servlet.shepherd/document/download/0693c00000LXcNJAA1?operationContext=S1 Graph processing difference for DDoS and FMC |
Was this article helpful?
0 out of 0 found this helpful