# FastNetMon DDoS Detection Tool > FastNetMon Official Site > Generated by All in One SEO Pro v5.0.3, this is an llms-full.txt file, used by LLMs to index the site. ## Posts ### [What Is a DDoS Scrubber? How DDoS Traffic Scrubbing Works](https://fastnetmon.com/2026/10/19/what-is-a-ddos-scrubber-how-ddos-traffic-scrubbing-works/) **Published:** October 19, 2026 **Author:** FastNetMon **Content:** A **DDoS scrubber** is a network security system designed to identify and remove malicious traffic during a [DDoS attack](https://fastnetmon.com/2026/09/21/ddos-explained-what-is-a-distributed-denial-of-service-attack/) while allowing legitimate traffic to reach its destination. During a DDoS attack, large volumes of unwanted traffic can overwhelm a website, server or network connection, making services unavailable to legitimate users. A DDoS scrubber helps prevent this disruption by inspecting incoming traffic, filtering malicious packets and forwarding permitted traffic. DDoS scrubbing is widely used by Internet Service Providers (ISPs), hosting providers, data centres and enterprises to protect their networks against network and transport-layer attacks. Depending on the network architecture, scrubbing can take place locally using dedicated hardware or software, often called a "scrubber" or "inline scrubber" or through an external DDoS scrubbing provider, often called "cloud-based scrubbing centre". ## How Does a DDoS Scrubber Work? A DDoS scrubber acts as a traffic-cleaning system positioned in the path of incoming network traffic. Its purpose is to distinguish traffic that should be allowed through from traffic that should be blocked or restricted. Although the exact process varies by solution, DDoS scrubbing generally involves four stages. ### 1. Traffic Reaches the Scrubbing System Traffic is directed through a DDoS scrubber, either because the scrubbing system is permanently deployed in the network path or because traffic has been redirected following an attack. In an inline deployment, the scrubber continuously processes traffic passing through the network. In a cloud-based deployment, routing changes can redirect traffic for an affected network prefix to an external scrubbing centre. ### 2. Traffic Is Inspected and Analysed The scrubbing system examines incoming packets and applies its configured detection and filtering policies. Depending on the solution, this may involve analysing: - Source and destination IP addresses - Network protocols, such as TCP, UDP and ICMP - Source and destination ports - Packet sizes and packet rates - Traffic patterns and known attack characteristics - Protocol behaviour and connection state, where supported Some systems apply predefined filtering rules, while others also use traffic analysis and anomaly detection to identify suspicious behaviour. The depth of inspection depends on the capabilities of the scrubbing technology. ### 3. Malicious Traffic Is Filtered When traffic matches the system's mitigation rules, the scrubber can drop or rate-limit the relevant packets. For example, a scrubber might block packets matching a known UDP amplification attack pattern while allowing other traffic to continue. Filtering methods may include packet filtering, protocol-specific mitigation, rate limiting and, where supported, more advanced traffic inspection. A scrubber does not necessarily identify every malicious packet correctly. Effective protection depends on the filtering rules, detection methods, configuration and attack characteristics. ### 4. Legitimate Traffic Is Forwarded Once filtering rules have been applied, traffic that is permitted by the scrubbing system is forwarded towards the protected network or service. For an inline scrubber, this typically means forwarding permitted packets along the local network path. For an external scrubbing provider, the permitted traffic may be returned to the customer's infrastructure using a GRE tunnel, an IPsec tunnel or another configured connectivity method. The goal is to maintain availability for legitimate users while reducing the amount of malicious traffic reaching the protected infrastructure. ## What Types of DDoS Attacks Can a Scrubber Mitigate? DDoS scrubbers are particularly important for defending against [network and transport-layer attacks](https://fastnetmon.com/2025/09/23/understanding-layer-3-and-layer-4-ddos-attacks/) that generate large volumes of unwanted packets. Common examples include: | **Attack type** | **How it works** | **How scrubbing can help** | |---|---|---| | **UDP flood** | Overwhelms a target with large volumes of UDP packets | Filters or rate-limits traffic matching attack characteristics | | **TCP SYN flood** | Sends large numbers of TCP connection requests to exhaust connection-handling resources | Applies SYN flood mitigation techniques, depending on the system | | **ICMP flood** | Overloads a target with excessive ICMP traffic | Filters or rate-limits unwanted ICMP packets | | **Reflection and amplification attacks** | Uses third-party services to generate large traffic volumes towards a victim | Identifies and filters reflected traffic using protocol and packet characteristics | | **Other packet floods** | Overwhelms network links or processing equipment with large packet rates | Applies filtering rules to reduce malicious packet volume | Some scrubbing providers also offer application-layer DDoS protection, including mitigation of HTTP floods. However, application-layer protection is not a universal capability of all DDoS scrubbers. It may require additional proxy infrastructure, specialised inspection features or separate security services. The available mitigation techniques depend on the scrubbing solution and its configuration. ## Inline DDoS Scrubbing vs Cloud-Based DDoS Scrubbing DDoS scrubbing can be implemented using different network architectures. Two common approaches are inline scrubbing and external scrubbing centres. ### Inline DDoS Scrubbing With **inline DDoS scrubbing**, a filtering system is deployed directly in the network traffic path. Incoming packets pass through the scrubber, which applies filtering rules and forwards permitted traffic to its destination. Inline scrubbing can be implemented using specialised network appliances or software-based packet-processing systems running on commodity hardware. This approach gives network operators direct control over their filtering infrastructure and can allow unwanted traffic to be dropped within their own network. However, inline scrubbing has an important limitation: the malicious traffic must reach the filtering system before it can be removed. If a DDoS attack saturates the upstream internet connection before reaching the inline scrubber, the protected network may still experience disruption. For this reason, local inline scrubbing is often combined with upstream filtering or external mitigation capacity. ### Cloud-Based DDoS Scrubbing Centres A **DDoS scrubbing centre** is an external facility or service that filters traffic before forwarding permitted traffic to the protected network. Scrubbing providers typically operate dedicated infrastructure with substantial network connectivity and mitigation capacity. When traffic is directed to a scrubbing centre, malicious packets can be discarded within the provider's infrastructure rather than consuming bandwidth on the customer's network connection. Clean traffic is then returned to the protected network through the configured connectivity path. Cloud scrubbing is particularly useful when attacks exceed the bandwidth or mitigation capacity available locally. External scrubbing can operate in two ways: - **Always-on scrubbing:** Protected traffic continuously passes through the scrubbing provider. - **On-demand scrubbing:** Traffic is diverted to the provider when an attack is detected and returned to normal routing when diversion is no longer required. On-demand protection requires reliable attack detection, routing automation and an established clean-traffic return path. For a more detailed explanation, read our guide to [DDoS Scrubbing Centre Automation](https://fastnetmon.com/2025/08/06/ddos-scrubbing-centre-automation-explained/). ### Comparing Inline and External DDoS Scrubbing | **Feature** | **Inline DDoS scrubber** | **External scrubbing centre** | |---|---|---| | **Deployment** | Within the operator's network traffic path | At an external mitigation provider | | **Traffic filtering** | Performed locally | Performed within the provider's infrastructure | | **Network capacity** | Limited by local connectivity and processing resources | Depends on the provider's available mitigation capacity | | **Traffic redirection** | Usually not required when permanently inline | May require BGP diversion or provider-specific routing | | **Infrastructure control** | Managed by the network operator | Shared between the operator and scrubbing provider | | **Typical use case** | Local packet filtering and network protection | Large-scale attacks requiring external mitigation capacity | Neither approach is universally better. The appropriate architecture depends on network capacity, attack types, operational requirements and the level of control the organisation needs. ## What Is a Line-Rate DDoS Scrubber? A **line-rate DDoS scrubber** is a system designed to inspect and filter traffic at the full supported speed of its network interfaces under specified operating conditions. For example, a scrubber connected to a 100 Gbps Ethernet interface may be described as line-rate capable if it can sustain packet filtering at that speed under the relevant test conditions. Line-rate performance matters because filtering equipment must be capable of keeping up with incoming network traffic, particularly during high-volume DDoS attacks. However, an advertised 100 Gbps or 400 Gbps interface does not automatically mean that the system can process every traffic pattern at that speed. Actual filtering performance depends on several factors, including packet size, packet rate, filtering complexity, hardware resources and software architecture. Two important measurements are: - **Gbps (gigabits per second):** The amount of traffic processed per second. - **Mpps (million packets per second):** The number of individual packets processed per second. A system may handle large packets at full Ethernet line rate but struggle with small packets that require much higher packet-processing rates. This makes packet-per-second performance particularly important when evaluating DDoS scrubbers and line-rate DDoS filters. ## How FastNetMon Supports DDoS Scrubbing FastNetMon provides real-time DDoS detection and automated mitigation capabilities for ISPs, hosting providers and data centres. Its technology supports different DDoS protection architectures, including **automated diversion to external scrubbing centres** and **high-performance inline packet filtering**. With [FastNetMon's scrubbing centre diversion automation](https://fastnetmon.com/2025/08/06/ddos-scrubbing-centre-automation-explained/), network operators can automatically redirect traffic to external scrubbing providers when attacks are detected. Meanwhile, [FastACL](https://fastnetmon.com/2026/09/25/introducing-fastacl-community-open-source-ddos-scrubbing/), FastNetMon's open-source packet filtering engine built on FD.io VPP, enables high-performance inline DDoS filtering directly within the operator's own network infrastructure. Together, these technologies give network operators flexible options for detecting and mitigating DDoS attacks using local filtering, external scrubbing services or a combination of both. ### Automated Diversion to External Scrubbing Centres FastNetMon can detect DDoS attacks and automatically activate traffic diversion to supported external scrubbing providers. Depending on the integration, this can involve BGP announcements or provider API calls. Once the diversion is active, the external scrubbing centre filters incoming traffic and returns legitimate traffic to the protected network. When the attack subsides, FastNetMon can trigger withdrawal of the diversion and restoration of normal routing. This allows network operators to use external scrubbing capacity when required rather than permanently routing all protected traffic through a scrubbing centre. Learn more about [FastNetMon's automated DDoS scrubbing centre diversion](https://fastnetmon.com/ddos-scrubbing-centre-diversion/). ### Inline DDoS Filtering with FastACL FastNetMon's ecosystem also includes **FastACL Community**, an open-source packet filtering engine built on FD.io VPP. FastACL operates inline, applying packet-filtering rules to incoming traffic and forwarding permitted packets. It can be combined with FastNetMon's detection capabilities to create a software-based DDoS mitigation architecture in which FastNetMon identifies attacks and FastACL enforces filtering rules. This offers an alternative to relying exclusively on dedicated hardware appliances or external scrubbing providers for local traffic filtering. FastACL's performance depends on the hardware, traffic profile and filtering configuration. Its published performance tests provide specific throughput and packet-rate measurements rather than a universal guarantee of line-rate processing under all conditions. Learn more about [FastACL Community and open-source DDoS scrubbing](https://fastnetmon.com/2026/09/25/introducing-fastacl-community-open-source-ddos-scrubbing/). ## What Should You Consider When Choosing a DDoS Scrubber? Choosing a DDoS scrubbing solution involves more than comparing advertised bandwidth capacities. Network operators should evaluate several practical factors. **Mitigation capacity:** Can the solution handle the expected attack volume without overwhelming the filtering infrastructure or available connectivity? **Packet-processing performance:** Can the scrubber handle high packets-per-second rates, including attacks composed of small packets? **Detection and filtering capabilities:** Which attack types can the solution identify and mitigate, and how are filtering policies configured? **Network integration:** Can the solution work with the organisation's existing routers, BGP configuration and network architecture? **Deployment model:** Is local inline filtering sufficient, or is external scrubbing capacity needed to handle attacks that exceed upstream bandwidth? **Automation:** Can attack detection, mitigation activation and recovery operate automatically, or do they require manual intervention? **Operational visibility:** Does the solution provide useful information about detected attacks, applied mitigation actions and traffic behaviour? A suitable DDoS protection architecture may combine several mitigation techniques rather than rely on a single filtering system. ## Conclusion A DDoS scrubber protects networks by inspecting incoming traffic, removing packets that match malicious traffic patterns and forwarding permitted traffic towards its destination. Scrubbing can be performed locally through inline filtering systems or externally through dedicated scrubbing centres. Inline scrubbing offers direct control over traffic filtering, while external scrubbing providers can provide additional capacity when attacks exceed the bandwidth available to the protected network. For ISPs, hosting providers, data centres and large enterprise networks, the most effective approach often combines reliable attack detection with appropriate filtering and mitigation infrastructure. **FastNetMon helps automate DDoS detection and mitigation**, including traffic diversion to external scrubbing providers. FastACL extends the ecosystem with an open-source inline packet-filtering engine for building software-based DDoS mitigation systems. Together, these technologies give network operators different options for designing DDoS protection around their existing infrastructure and operational requirements. [Explore FastNetMon's DDoS detection and mitigation solutions](https://fastnetmon.com/) to learn more about protecting high-capacity networks. **Categories:** FastNetMon Blog **Tags:** Network Security Insights --- ### [DDoS Scrubbing Centre Automation Explained: How On-Demand Traffic Diversion Works](https://fastnetmon.com/2026/10/01/ddos-scrubbing-centre-automation-explained/) **Published:** October 1, 2026 **Author:** FastNetMon **Content:** DDoS scrubbing centre automation is the process of automatically redirecting network traffic to a scrubbing provider when a [DDoS attack](https://fastnetmon.com/2026/09/21/ddos-explained-what-is-a-distributed-denial-of-service-attack/) is detected. Instead of routing traffic through a scrubbing centre permanently, on-demand diversion activates protection when needed, helping network operators maintain efficient routing during normal operation. **FastNetMon automates** [**DDoS scrubbing centre diversion**](https://fastnetmon.com/ddos-scrubbing-centre-diversion/) by detecting attacks in real time and triggering routing changes or integrations with scrubbing providers. The scrubbing centre then filters malicious traffic and forwards legitimate traffic back to the protected network. For Internet Service Providers (ISPs), hosting companies, data centres and other network operators, this approach combines automated threat detection with the mitigation capacity of dedicated scrubbing infrastructure. In this article, we'll explain how DDoS scrubbing centres work, how automated diversion operates, and how FastNetMon helps organisations respond to attacks without permanently routing their traffic through an external scrubbing provider. ## What Is a DDoS Scrubbing Centre? A **DDoS scrubbing centre** is a dedicated network facility or cloud-based service designed to protect networks against DDoS attacks by separating malicious traffic from legitimate traffic. During a DDoS attack, an attacker attempts to overwhelm a target network, server or application with excessive traffic. Large volumetric attacks can consume available bandwidth, overwhelm network equipment or disrupt services for legitimate users. A scrubbing centre provides an additional layer of protection by receiving traffic destined for the protected network, identifying malicious packets and dropping them before they reach the customer's infrastructure. Depending on the provider and its mitigation capabilities, DDoS scrubbing centres may use several techniques to identify and filter malicious traffic, including: - **Packet filtering:** Dropping traffic based on characteristics such as source or destination IP addresses, protocols, ports and known attack patterns. - **Protocol-based mitigation:** Identifying and blocking traffic associated with network and transport-layer attacks, including UDP floods, TCP SYN floods and reflection or amplification attacks. - **Traffic analysis and anomaly detection:** Analysing traffic patterns and packet rates to identify suspicious activity and determine which mitigation rules to apply. - **Rate limiting:** Restricting traffic that matches specific conditions to prevent excessive traffic from overwhelming protected infrastructure. Some scrubbing providers also offer application-layer DDoS protection, such as mitigation of HTTP floods, through additional services or specialised inspection capabilities. The exact techniques available depend on the scrubbing provider, its infrastructure and the protection services enabled. Once malicious traffic has been removed, the scrubbing centre forwards legitimate traffic to the protected destination. Scrubbing providers often operate high-capacity, geographically distributed infrastructure designed to absorb attacks that could otherwise exceed the bandwidth available to an individual organisation. However, using a scrubbing centre does not necessarily mean that all network traffic must pass through it permanently. ## External DDoS Scrubbing vs Inline DDoS Scrubbing While external scrubbing centres provide additional mitigation capacity by redirecting traffic to a dedicated provider, **inline DDoS scrubbing** offers another approach to protecting networks against malicious traffic. With inline scrubbing, a filtering system is deployed directly in the network's traffic path. Instead of sending traffic to an external provider, the system inspects incoming packets, drops traffic matching malicious patterns, and forwards permitted traffic towards its destination. Both approaches have different advantages: - **External scrubbing centre diversion:** Redirects traffic to a specialised provider with additional mitigation capacity. This is particularly useful when an attack exceeds the bandwidth available to the protected network. - **Inline DDoS scrubbing:** Filters traffic within the network infrastructure, allowing operators to apply mitigation policies locally without necessarily relying on an external scrubbing provider. FastNetMon supports these approaches through different technologies. For external scrubbing, FastNetMon detects DDoS attacks and automates traffic diversion using BGP announcements or supported provider integrations. For inline filtering, **FastACL Community** is an open-source packet filtering engine built on FD.io VPP. It applies filtering rules directly to packets passing through the system, dropping identified attack traffic while forwarding permitted traffic. Combined with FastNetMon's detection capabilities, FastACL provides a foundation for building a high-performance, software-based DDoS scrubbing system on commodity hardware Learn more about [FastACL Community and its inline DDoS filtering capabilities](https://fastnetmon.com/2026/09/25/introducing-fastacl-community-open-source-ddos-scrubbing/). ## What Is DDoS Scrubbing Centre Diversion? **DDoS scrubbing centre diversion** is the process of redirecting traffic for selected IP prefixes through a scrubbing provider so malicious traffic can be filtered before reaching the protected network. There are two common deployment models. ### Always-On DDoS Scrubbing With always-on scrubbing, protected traffic continuously passes through the scrubbing provider, regardless of whether an attack is occurring. This means the scrubbing infrastructure is already in the traffic path when an attack begins. There is no need to wait for an additional routing change to activate the scrubbing path. Always-on scrubbing can be useful for organisations that require continuous inspection or want to avoid the delay associated with activating on-demand traffic diversion. However, the model also introduces considerations around routing, infrastructure dependencies and cost. Depending on the scrubbing provider's network and location, routing traffic through an external service may introduce additional latency or complexity. Commercial pricing also varies between providers and service agreements. ### On-Demand DDoS Scrubbing With on-demand scrubbing, network traffic follows its normal routing path until an attack is detected. When an attack occurs, traffic for the affected IP prefix is redirected to a scrubbing centre. The provider filters malicious packets and forwards legitimate traffic to the protected network. Once the attack has ended and the configured mitigation conditions have been satisfied, traffic diversion can be withdrawn, allowing traffic to return to its normal path. This approach is particularly relevant to ISPs, hosting providers and data centres that want to use external scrubbing capacity during attacks without continuously diverting their traffic. The main challenge is ensuring that attacks are detected quickly and that traffic diversion can be activated reliably. This is where FastNetMon comes in. ## How FastNetMon Automates DDoS Scrubbing Centre Diversion FastNetMon is a DDoS detection and mitigation solution that monitors network traffic and can automatically trigger mitigation actions when attacks are identified. When integrated with a scrubbing provider, FastNetMon acts as the detection and automation component of an on-demand DDoS protection architecture. Rather than performing the cloud scrubbing itself, FastNetMon identifies the attack and initiates the configured diversion process. The scrubbing provider is responsible for filtering the redirected traffic. ![](https://fastnetmon.com/wp-content/uploads/2025/08/Diagram-of-FastNetMon-Scrubbing-Centre-Diversion-1024x538.png)*FastNetMon automated DDoS scrubbing centre diversion architecture. FastNetMon analyses network telemetry, detects DDoS attacks and triggers traffic diversion through BGP or a scrubbing provider integration. The scrubbing centre filters malicious traffic and returns legitimate traffic to the protected network. Once mitigation ends, normal routing is restored.* The process involves four main stages. ### 1. Real-Time DDoS Attack Detection FastNetMon continuously analyses network traffic using telemetry sources such as NetFlow, sFlow and IPFIX. It monitors traffic characteristics including bandwidth consumption, packet rates and flow rates, helping network operators identify unusual patterns that may indicate a DDoS attack. For example, if a server normally receives a moderate volume of UDP traffic but suddenly experiences a substantial increase in packets per second, FastNetMon can evaluate that traffic against its configured detection criteria. When the traffic exceeds the relevant thresholds or matches configured attack detection conditions, FastNetMon can trigger a mitigation action. This automation reduces the need for network engineers to identify an attack manually and then make emergency routing changes. Detection speed depends on factors such as the telemetry source, export intervals, sampling configuration, attack characteristics and detection settings. ### 2. Automatic Traffic Diversion Once an attack is detected, FastNetMon can initiate traffic diversion using the mitigation method supported by the network and scrubbing provider. Common approaches include: **BGP Unicast announcements** FastNetMon can announce the affected network prefix with the appropriate routing attributes or BGP communities. Depending on the upstream routing policies and scrubbing provider's configuration, these announcements can trigger the diversion of inbound traffic to the provider's scrubbing infrastructure. **Scrubbing provider API integrations** FastNetMon can also integrate with supported scrubbing providers through their APIs. When an attack is detected, FastNetMon can trigger the configured integration to request diversion or activate protection for the affected prefix. Once mitigation is no longer required, the integration can remove that request. For example, FastNetMon Advanced supports integrations with DDoS protection providers including [Gcore](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-integration-with-gcore-global-ddos-protection-scrubbing-centre/) and [Cloudflare Magic Transit](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-integration-with-cloudflare-magic-transit-scrubbing-centre/). ### 3. DDoS Traffic Scrubbing and Clean Traffic Return After diversion has been activated and the relevant routing changes have taken effect, inbound traffic for the diverted prefix reaches the scrubbing provider. The scrubbing centre inspects the traffic and applies its mitigation policies. Malicious traffic is discarded or otherwise mitigated, while legitimate traffic is forwarded towards the protected network. The clean traffic is commonly returned through a preconfigured GRE tunnel, an IPsec tunnel or another connectivity method supported by the provider. It is important to distinguish between the two directions of traffic: - **Inbound diversion:** BGP routing changes or provider-specific routing mechanisms direct incoming traffic towards the scrubbing centre. - **Clean traffic return:** The scrubbing provider forwards filtered traffic back to the protected network over the configured return path. FastNetMon controls the automated activation of diversion through the configured integration. It does not itself establish or operate the scrubbing provider's traffic-cleaning infrastructure. ### 4. Automatic Withdrawal and Routing Restoration Once the attack has subsided and the configured mitigation conditions have been met, FastNetMon can automatically deactivate the diversion. Depending on the integration, this may involve withdrawing a BGP announcement or sending an API request to the scrubbing provider. The network then returns to its normal routing state as the relevant routing changes propagate. This automated recovery process helps reduce the operational work associated with manually enabling and disabling external DDoS protection. ## Always-On vs On-Demand DDoS Scrubbing Both always-on and on-demand scrubbing can provide effective DDoS protection. The best choice depends on the organisation's traffic patterns, performance requirements and risk tolerance. | **Feature** | **Always-On Scrubbing** | **On-Demand Scrubbing with FastNetMon** | |---|---|---| | **Traffic routing** | Protected traffic continuously passes through the scrubbing provider | Traffic is diverted when configured attack conditions are met | | **Attack detection** | Provider protection is already in the traffic path | FastNetMon detects attacks and triggers diversion | | **Activation delay** | No additional diversion activation required | Depends on detection, provider activation and routing convergence | | **Normal-state latency** | Depends on scrubbing provider location and network routing | Traffic normally avoids an external scrubbing detour | | **Attack mitigation capacity** | Depends on the scrubbing provider | Depends on the selected scrubbing provider | | **Operational costs** | Determined by the provider's commercial model | May reduce usage-based costs, depending on the agreement | | **Traffic inspection** | Protected traffic passes through the scrubbing system continuously | Traffic for diverted prefixes passes through the scrubbing system during mitigation | | **Routing complexity** | Scrubbing path must remain operational continuously | Diversion activation, withdrawal and clean-traffic return must be configured and tested | | **Primary advantage** | Protection infrastructure is already in the traffic path | Normal traffic routing is preserved when diversion is not required | Always-on scrubbing can be a strong choice for organisations that prioritise continuous inspection or cannot tolerate the time needed to activate traffic diversion. On-demand scrubbing is attractive for network operators that want to maintain normal routing most of the time while retaining access to external mitigation capacity during attacks. FastNetMon helps automate the second approach by reducing the manual steps involved in identifying attacks, activating diversion and restoring normal routing. ## Benefits of Automating DDoS Scrubbing Centre Diversion For network operators with an appropriate routing architecture, automated on-demand scrubbing offers several practical advantages. ### Faster Operational Response Manually identifying a DDoS attack, contacting a scrubbing provider and changing network routing can consume valuable time. FastNetMon automates detection and the configured mitigation trigger, reducing dependence on manual intervention. The total time required for protection to become effective still depends on provider activation and routing convergence. ### Normal Routing During Non-Attack Periods Traffic does not need to pass through an external scrubbing provider continuously. During normal network operation, protected traffic can follow the organisation's established routing paths, avoiding an unnecessary diversion through the scrubbing infrastructure. ### Access to Additional Mitigation Capacity Large DDoS attacks can exceed the capacity of an individual hosting provider or ISP connection. Automated diversion allows network operators to use an external scrubbing provider's mitigation infrastructure when an attack requires additional protection. The available mitigation capacity depends on the selected provider and service agreement. ### More Targeted Traffic Diversion Rather than permanently redirecting all network traffic, on-demand scrubbing can be activated for selected affected prefixes. This helps reduce unnecessary use of external scrubbing infrastructure, although other legitimate services within the diverted prefix may also be routed through the provider. ### Potential Cost Efficiency For organisations whose scrubbing provider offers a suitable pricing model, on-demand diversion may reduce traffic-based operating costs compared with continuous scrubbing. However, savings depend on the provider's contract, reserved capacity, subscription fees and traffic-based charges. ### Reduced Manual Network Operations FastNetMon can automate the mitigation lifecycle, from attack detection and diversion activation through to withdrawal and routing restoration. This reduces the number of manual routing changes required during an incident and allows network engineers to focus on investigating attacks and maintaining service availability. ## Automate DDoS Scrubbing Centre Diversion with FastNetMon DDoS scrubbing centres provide valuable protection against large-scale attacks, but the effectiveness of an on-demand deployment depends on how quickly and reliably traffic can be redirected. **FastNetMon connects real-time DDoS detection with automated mitigation actions**, helping ISPs, hosting providers and data centres activate scrubbing centre protection when required. By combining traffic analysis with BGP-based diversion and supported scrubbing provider integrations, FastNetMon enables network operators to: - Detect abnormal traffic patterns and DDoS attacks in real time. - Trigger diversion for affected network prefixes. - Integrate with external DDoS scrubbing services. - Restore normal routing automatically when mitigation is no longer required. - Maintain visibility and operational control over the mitigation workflow. The result is a flexible approach to DDoS defence that combines FastNetMon's detection and automation capabilities with the filtering capacity of dedicated scrubbing infrastructure. To learn more, explore [FastNetMon's BGP traffic diversion capabilities](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-and-bgp-traffic-diversion/) or discover how FastNetMon integrates with [supported DDoS scrubbing providers](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-and-ddos-scrubbing-centers-integration/). **Looking to automate DDoS scrubbing centre diversion in your network?** [Contact the FastNetMon team](https://fastnetmon.com/contact-us/) to discuss your network architecture, mitigation requirements and available integration options. **Categories:** FastNetMon Blog **Tags:** core product, Scrubbing --- ### [NVIDIA and Cisco Introduce USFP Optics for 12.8 Tbps AI Networking](https://fastnetmon.com/2026/10/13/nvidia-and-cisco-introduce-usfp-optics-for-12-8-tbps-ai-networking/) **Published:** October 13, 2026 **Author:** FastNetMon **Content:** NVIDIA and Cisco have announced Ultra-Dense Small Form Factor Pluggable (USFP), a new optical transceiver form factor designed for next-generation AI factories and high-performance Ethernet networks. Supporting 400 Gb/s per electrical lane, USFP promises four times higher bandwidth density and approximately 1.3x greater power efficiency compared with today's 200 Gb/s-per-lane pluggable optics. Announced on October 12, 2026, at the Open Compute Project (OCP) Global Summit, USFP aims to address growing bandwidth, power, and scalability challenges in AI data centers, GPU clusters, and large-scale Ethernet fabrics. ## USFP: 400 Gb/s per Lane and Up to 12.8 Tbps The first planned USFP transceivers will integrate **16 full-duplex lanes operating at 400 Gb/s each**, delivering 6.4 Tbps of bandwidth per direction in an OSFP-sized footprint. Future 32-lane configurations could increase this capacity to 12.8 Tbps. Key technical features include: - **4x higher bandwidth density** compared with existing 200 Gb/s-per-lane pluggable modules. - **Approximately 1.3x improved power efficiency**, helping reduce networking power consumption. - **Up to 100 W power dissipation** without a dedicated embedded cooling circuit. - **New two-dimensional connector design** with two-step insertion for improved signal integrity and reduced contact wear. - **Support for switches and SuperNICs**, enabling higher-density connectivity for 1.6 Tbps endpoints. - **Pluggable, field-replaceable architecture**, preserving operational flexibility in data center networks. ## Scaling Data Center Networks Beyond Today's Limits As GPU clusters and AI workloads grow, network operators must increase Ethernet fabric bandwidth without continuously adding switches, optical links, and network tiers. USFP could help data center operators build higher-capacity spine-leaf networks, connect more AI accelerators per switch, and improve infrastructure utilization while reducing latency and power requirements. For network engineers, this development also highlights the growing importance of high-speed network monitoring, traffic visibility, congestion management, and network performance troubleshooting. As Ethernet fabrics scale toward multi-terabit connectivity, maintaining visibility into network traffic and detecting anomalies will remain essential for reliable AI infrastructure operations. ## NVIDIA and Cisco Build an Open USFP Ecosystem NVIDIA and Cisco are working with **TE Connectivity and Amphenol** on USFP connectors, cages, and optical modules. The companies also plan to establish an open industry specification through a community-led multi-source project, encouraging broader adoption of high-density pluggable optics. The initiative complements NVIDIA Spectrum-X Ethernet networking and Cisco Silicon One-based Ethernet platforms, targeting hyperscale data centers, cloud providers, neoclouds, and enterprise AI infrastructure. ## What Comes Next? USFP is still a planned technology, and its commercial availability and broader vendor adoption remain to be seen. However, its proposed combination of **400 Gb/s-per-lane signaling, 6.4 Tbps initial capacity, and a roadmap to 12.8 Tbps** represents a significant development for next-generation Ethernet switching and AI factory networking. For network operators, the challenge will be ensuring that network observability, operational reliability, and traffic management evolve alongside these rapidly increasing bandwidth capabilities. **Sources:** - [NVIDIA Official Press Release — October 12, 2026](https://nvidianews.nvidia.com/news/nvidia-and-cisco-introduce-new-pluggable-optics-form-factor-to-scale-ai-factories) - [Cisco Technical Blog — October 12, 2026](https://blogs.cisco.com/news/cisco-and-nvidia-announce-usfp-expanding-the-path-to-ai-connectivity) **Categories:** FastNetMon Blog --- ### [Faster Packet Filtering on BlueField-3 Arm Cores with VPP’s Native RDMA Driver](https://fastnetmon.com/2026/10/14/faster-packet-filtering-on-bluefield-3-arm-cores-with-vpps-native-rdma-driver/) **Published:** October 14, 2026 **Author:** FastNetMon **Content:** ![Portrait of a man with short dark hair and light stubble, wearing a dark gray T-shirt, facing the camera (circular crop).](https://fastnetmon.com/wp-content/uploads/2026/06/Denys-Haryachyy-FastNetMon-Guest-Blog.png) *This post is a repost of a [technical blog originally published by Denys Haryachyy](https://haryachyy.wordpress.com/2026/10/02/faster-packet-filtering-on-bluefield-3-arm-cores-with-vpps-native-rdma-driver/), shared here with permission as part of ongoing research and engineering work around FastNetMon’s inline traffic processing capabilities*. In the [first post on the BlueField-3](https://haryachyy.wordpress.com/2026/10/01/packet-filtering-with-vpp-on-bluefield-3-arm-cores-and-100g-nics/) I ran an FD.io VPP data plane with an ACL filter plugin on the DPU’s sixteen Arm cores, with DPDK driving its two 100G uplinks. VPP has a second way to drive the same mlx5 NIC: its native RDMA driver, which uses mlx5 Direct Verbs and no DPDK at all. This post puts the two side by side on the same cores, with the same filter and the same traffic. On 64-byte packets the RDMA driver drops **86.0 Mpps against 58.7 Mpps with DPDK (+46.5%)**, and it filters at **100G line rate from 128-byte frames** instead of from 256 bytes. ## What Changed Since the First Post | | First post | This post | |---|---|---| | DOCA / BF-bundle | 2.9.1 (DOCA 24.11) | 3.4.0 (bf-release 4.15.0) | | Arm kernel | 5.15.0-1057-bluefield | 5.15.0-1093-bluefield | | mlx5 driver (OFED) | 24.10 | 26.04 | | NIC firmware | 32.43.2408 | 32.49.1014 | | VPP | 25.10 | 26.10-rc1 | | NIC driver in VPP | DPDK | RDMA (Direct Verbs) | The cores, the filter, the traffic and the twelve VPP workers are the same as in the first post. For a fair comparison I re-ran the DPDK driver on exactly this setup, so the two columns in the results below differ only in the NIC driver. Every number is the median of three 15-second trials on one 100G ingress port with a drop rule matching the flood; the trials agreed within 1%. ## Two Receive Paths into VPP [![DPDK and RDMA receive paths into the VPP ACL filter](https://haryachyy.wordpress.com/wp-content/uploads/2026/10/vpp-bluefield3-dpdk-vs-rdma-receive-path.png)](https://haryachyy.wordpress.com/wp-content/uploads/2026/10/vpp-bluefield3-dpdk-vs-rdma-receive-path.png)Both drivers hand packets to the same VPP graph; only the receive path differsBoth drivers sit on the same bifurcated mlx5 device: the uplinks stay on the kernel’s `mlx5_core` and user space gets its own receive and transmit queues ([DPDK mlx5 guide: bifurcated driver](https://doc.dpdk.org/guides/nics/mlx5.html#bifurcated-driver)). With DPDK, the mlx5 poll-mode driver fills DPDK `rte_mbuf` descriptors and `dpdk-input` turns them into VPP buffers. VPP’s RDMA plugin uses mlx5 Direct Verbs instead: the queue rings are mapped into VPP, and `rdma-input` reads the NIC’s completion entries and builds VPP buffers from them directly, with no DPDK layer in between ([VPP docs: RDMA (ibverb) driver](https://s3-docs.fd.io/vpp/26.06/developer/devicedrivers/rdma.html), [mlx5dv(7)](https://man7.org/linux/man-pages/man7/mlx5dv.7.html)). ## The DMA-Ordering Fix on Arm In Direct Verbs mode the CPU and the NIC hand ring entries to each other through completion-entry owner bits, doorbell records in host memory and a write to the NIC’s doorbell register. On x86, compiler barriers are enough for the DMA memory, plus a store fence before the doorbell write; Arm’s weaker memory model can reorder these accesses, so compiler barriers are not enough there ([Linux kernel: memory barriers](https://docs.kernel.org/core-api/wrappers/memory-barriers.html)). The change [“rdma: enforce mlx5 DV DMA ordering”](https://github.com/FDio/vpp/commit/34b80e5e0c177b1a06a5d19966b5eba150a68e2c) adds `dmb oshld` after each ownership check and `dmb oshst` before each publication to the device on AArch64, and leaves x86 with compiler barriers only. It first ships in VPP 26.10-rc1, which is why this test runs on that release. > On Arm, run VPP’s RDMA driver in Direct Verbs mode only on a release that contains the DMA-ordering fix: VPP 26.10-rc1 or later. ## Starting VPP with the RDMA Driver The start-up configuration loses its `dpdk` section; the DPDK plugin is disabled and the RDMA plugin enabled, and everything else from the first post stays as it was: ``` plugins { plugin dpdk_plugin.so { disable } plugin rdma_plugin.so { enable } plugin acl_filter_plugin.so { enable } } ``` The interfaces are created in the start-up script, before the same cross-connect and filter set-up as in the first post. Giving them the Linux names keeps the rest of the configuration unchanged: ``` create interface rdma host-if p0 name p0 num-rx-queues 12 rx-queue-size 4096 tx-queue-size 4096 mode dv create interface rdma host-if p1 name p1 num-rx-queues 12 rx-queue-size 4096 tx-queue-size 4096 mode dv ``` `host-if` is the kernel network device, which stays up after the uplinks leave the OVS bridges. One RX queue per worker spreads the flood across all twelve cores, as with DPDK. The rate comes from VPP’s interface counter, which matched the filter node’s and `rdma-input`’s packet counts within timing slack, and the NIC-side loss from the port’s `rx_packets_phy` counter. VPP 26.10-rc1 comes from FD.io’s arm64 packages and the plugin is built out of tree against them, as described in the first post ([FD.io 26.10 package repository](https://packagecloud.io/fdio/2610)). ## Results [![Drop rate per frame size, DPDK versus RDMA, BlueField-3 Arm cores](https://haryachyy.wordpress.com/wp-content/uploads/2026/10/vpp-bluefield3-dpdk-vs-rdma-drop-rate.png)](https://haryachyy.wordpress.com/wp-content/uploads/2026/10/vpp-bluefield3-dpdk-vs-rdma-drop-rate.png)Drop rate per frame size on one 100G port, VPP 26.10-rc1, DOCA 3.4.0 | Frame | DPDK | RDMA | Change | |---|---|---|---| | 64 B | 58.7 Mpps · 41 Gbps · 58.6% dropped in the NIC | 86.0 Mpps · 61 Gbps · 39.4% dropped in the NIC | +46.5% | | 128 B | 50.2 Mpps · 61 Gbps · 39.0% dropped in the NIC | 82.2 Mpps · 100 Gbps (line rate) | +63.7% | | 256 B | 44.2 Mpps · 99 Gbps (line rate) | 44.3 Mpps · 99 Gbps (line rate) | — | | 512 B | 23.3 Mpps (line rate) | 23.3 Mpps (line rate) | — | | 1024 B | 11.9 Mpps (line rate) | 11.9 Mpps (line rate) | — | | 1500 B | 8.2 Mpps (line rate) | 8.2 Mpps (line rate) | — | | IMIX | 32.9 Mpps (line rate) | 32.9 Mpps (line rate) | — | Where the cores have headroom, both drivers run at line rate. Where they do not, the RDMA driver moves the limit: 64-byte traffic gains 27 Mpps, and 128-byte traffic goes from 61% to 100% of line rate. ## Where the Cycles Go [![Arm core cycles per 64-byte packet, DPDK versus RDMA](https://haryachyy.wordpress.com/wp-content/uploads/2026/10/vpp-bluefield3-dpdk-vs-rdma-cycle-budget.png)](https://haryachyy.wordpress.com/wp-content/uploads/2026/10/vpp-bluefield3-dpdk-vs-rdma-cycle-budget.png)Per-packet cycle budget at 64 B with all twelve workers saturatedAt 64 bytes all twelve workers are saturated, so the measured rate fixes the budget per packet: 12 cores × 2.13 GHz divided by the rate gives 435 core cycles per packet with DPDK and 297 with RDMA. The filter node costs the same in both, about 100 cycles (15.4 and 16.3 ticks of the 330 MHz Arm timer). The difference is all in receiving, buffer handling and graph dispatch: 336 cycles with DPDK, 192 with RDMA. On frames of 256 bytes and more, the filter node’s own figure rises to 19–24 ticks with the RDMA driver against 15–17 with DPDK, but at those sizes both drivers run at line rate with cycles to spare. ## Summary On the BlueField-3 Arm cores the NIC driver underneath VPP decides the small-packet rate. With VPP 26.10-rc1, DOCA 3.4.0 and twelve workers, VPP’s native RDMA driver in Direct Verbs mode drops 86.0 Mpps of 64-byte packets, 46.5% more than DPDK’s 58.7 Mpps, and filters at 100G line rate from 128-byte frames. Both drivers run at line rate from 256 bytes and on IMIX. On Arm the RDMA driver needs the DMA-ordering fix that first ships in VPP 26.10. ## References - [First post: Packet Filtering with VPP on BlueField-3 Arm Cores and 100G NICs](https://haryachyy.wordpress.com/2026/10/01/packet-filtering-with-vpp-on-bluefield-3-arm-cores-and-100g-nics/) - [VPP commit 34b80e5e0: rdma: enforce mlx5 DV DMA ordering](https://github.com/FDio/vpp/commit/34b80e5e0c177b1a06a5d19966b5eba150a68e2c) - [VPP docs: RDMA (ibverb) device driver](https://s3-docs.fd.io/vpp/26.06/developer/devicedrivers/rdma.html) - [VPP source: rdma-input node (src/plugins/rdma/input.c)](https://github.com/FDio/vpp/blob/master/src/plugins/rdma/input.c) - [VPP source: dpdk-input node (src/plugins/dpdk/device/node.c)](https://github.com/FDio/vpp/blob/master/src/plugins/dpdk/device/node.c) - [mlx5dv(7): mlx5 Direct Verbs](https://man7.org/linux/man-pages/man7/mlx5dv.7.html) - [DPDK mlx5 guide: bifurcated driver](https://doc.dpdk.org/guides/nics/mlx5.html#bifurcated-driver) - [Linux kernel: memory barriers](https://docs.kernel.org/core-api/wrappers/memory-barriers.html) - [FD.io VPP 26.10 packages, including arm64](https://packagecloud.io/fdio/2610) **Categories:** FastNetMon Blog, Featured --- ### [MDNOG 1 - Event Recap](https://fastnetmon.com/2026/07/14/see-you-at-mdnog/) **Published:** July 14, 2026 **Author:** FastNetMon **Content:** Last week, FastNetMon joined the Moldovan network operator community in Chișinău for **MDNOG 1**, held on October 8–9 at Digital Park. And what a start for a brand-new NOG! With **360 people registered** for the very first edition, MDNOG made quite an impression. For a smaller national networking community, that is an impressive turnout and a clear sign of the enthusiasm for bringing Moldova's network engineers and operators together. Representing FastNetMon was **Virgil Truica**, who presented on the latest DDoS trends, attack records and practical mitigation strategies. We've attended plenty of established NOG meetings over the years, but there's something particularly exciting about seeing a new one get off the ground. MDNOG 1 had the technical programme, the community spirit and, perhaps most importantly, the energy of people genuinely excited to build something together. ## DDoS attacks in 2026: New records and practical mitigation On Thursday morning, Virgil presented **“DDoS Attacks in 2026: Emerging Trends, New Records and Practical Mitigation.”** With DDoS attacks continuing to evolve in scale and complexity, the presentation focused on the latest developments in the threat landscape and the practical challenges of protecting networks against increasingly demanding attacks. For network operators, understanding how attack patterns are changing is only part of the challenge. Detecting malicious traffic quickly, maintaining visibility into what is happening across the network, and responding effectively without disrupting legitimate users are just as important. These are topics we work with every day at FastNetMon, and it was great to have the opportunity to share our perspective with the Moldovan operator community. If you missed Virgil's session, or would like to revisit the presentation, you can watch the recording below. ## Two days of networking The MDNOG programme was impressively comprehensive for a first edition, covering everything from BGP security and routing engineering to DDoS mitigation, optical networking, data centre infrastructure and peering. Thursday opened with **Oleksiy Semenyaka from RIPE NCC** discussing the next layer of BGP security beyond ROAs, including ASPA and BGP Roles. Oleg Andronic from Noction followed with a practical look at inbound BGP traffic engineering. Network resilience and DDoS were particularly prominent throughout the first day. Alongside Virgil's presentation, Olena Lutsenko from RETN discussed keeping networks operational during disruptions, while Chase Clowser from Recorded Future explored how modern DDoS botnets are using public cryptocurrency blockchains for command-and-control infrastructure. The afternoon continued with further DDoS discussions from Nokia and Corero, as well as sessions on DWDM networks, fibre infrastructure and regional interconnection. Vladimir Filatov from Trabia also shared an update on **KIVIX, the Chișinău Internet Exchange**, while Eric Andrei Băleanu from InterLAN discussed strengthening connectivity between Moldova and the Romanian Internet ecosystem. Friday shifted the focus towards data centre networking, automation, telemetry and peering. Sessions covered EVPN-VXLAN, data centre interconnect, AI-driven networking, and practical applications of telemetry and BGP Monitoring Protocol (BMP). The programme also included community-focused presentations from RoNIX and PeeringDB, before an afternoon panel explored the practical and regulatory challenges operators face when receiving requests to block online resources. It was a good reminder of just how many different technologies, operational challenges and policy questions come together in the day-to-day work of running the Internet. ## A fantastic start for Moldova's networking community Beyond the technical programme, what stood out most was the atmosphere. Over300 registered attendees for a first-ever national NOG is no small achievement. The event brought together local operators, engineers, hosting providers, infrastructure companies and international networking organisations. For a community hosting its first major NOG conference, the organisation was excellent. The programme ran across two full days, with plenty of opportunities to meet people between sessions and continue discussions during the social events at Digital Park and Mojito Terrace. It was particularly encouraging to see such a strong local community coming together around a vendor-neutral, technical event. NOGs work best when engineers have the opportunity to exchange knowledge openly, learn from one another and build connections that continue long after the conference ends. Judging by the enthusiasm around MDNOG 1, Moldova has a very promising new meeting point for its Internet community. ## A big thank you to the MDNOG team! A special thank you goes to **Andrian Visnevschi from ITcare and Vladimir Filatov from Trabia**, the founders behind MDNOG, as well as **Sven Wiese** and the wider organising team. We know how much work goes into organising a network operator meeting, especially when starting something entirely new. Bringing together speakers, sponsors, international organisations and hundreds of attendees for a first edition is a substantial undertaking, and the team deserves real credit for making it happen so successfully. Thank you also to the programme committee, volunteers, sponsors and everyone who contributed their time and expertise to the event. And, of course, thanks to everyone who attended Virgil's presentation, came over to say hello, or spent time discussing DDoS protection, traffic visibility, routing and network operations with us. We're genuinely happy to have been part of the very first MDNOG, and we hope this is just the beginning of a long-running tradition for Moldova's network operator community. **Here's to MDNOG 2 — and many more years of engineers bringing the Internet community together!** **Event:** MDNOG 1 **Date:** October 8–9, 2026 **Location:** Digital Park, Mihai Viteazul 15A, Chișinău, Moldova See the [official MDNOG website](https://mdnog.md/index.html#top) for more information. **Categories:** Events --- ### [FastNetMon Advanced 2.0.385](https://fastnetmon.com/2026/10/12/fastnetmon-advanced-2-0-385/) **Published:** October 12, 2026 **Author:** FastNetMon **Content:** **Release date:** 12 October, 2026 **Version:** 2.0.385 FastNetMon Advanced 2.0.385 introduces enhanced FlowSpec traffic filtering statistics, improved BGP announcement capabilities, and TLS support for ClickHouse connections. This release also expands flow dump data and Prometheus metrics, upgrades scrubbing services, and addresses multiple stability issues related to traffic monitoring and data export. Changes: - Added TLS support for ClickHouse connections in `traffic_db` - Added attack detection logic for IPv6 traffic - Added `flow_duration`, `flow_start`, and `flow_end` fields to the JSON output of flow dumps - Added per-IP counters to track traffic filtered by FlowSpec rules, accessible using `sudo fcli show flowspec_host_drop_counters_v4 1.2.3.4` - Added bandwidth calculation for traffic filtered by individual FlowSpec rules, accessible using `sudo fcli show flowspec_drop_counters_v4 UUID` - Implemented flow tracking for IPv6 traffic - Upgraded scrubbing services to a newer version - Added support for mirror next-hop configuration for IPv4 and IPv6 whole-subnet BGP announcements, using options such as `gobgp_announce_whole_subnet_mirror_next_hop_ipv4` and `gobgp_announce_whole_subnet_mirror_peer_name_ipv4` - Fixed a potential crash caused by an incorrect code definition in remote host counters - Fixed a bug that could cause the ClickHouse exporter to crash when a database table is corrupted in FastNetMon or `traffic_db` - Added version and license information to the Prometheus metrics endpoint [FastNetMon Advanced documentation](https://fastnetmon.com/docs-fnm-advanced/) [View this release on GitHub](https://github.com/FastNetMon/fastnetmon-advanced-releases/releases/tag/v2.0.385) **Categories:** Releases **Tags:** release --- ### [IPv6 DDoS Attacks and Mitigation with FastNetMon](https://fastnetmon.com/2026/10/08/ipv6-ddos-attacks-and-mitigation-with-fastnetmon/) **Published:** October 8, 2026 **Author:** FastNetMon **Content:** IPv6 is now a standard part of many service provider, hosting, data centre and enterprise networks. As more services become reachable over IPv6, network operators also need to make sure that their DDoS monitoring covers IPv6 traffic properly. IPv6 DDoS attacks are no longer unusual or small-scale. Recent industry telemetry has recorded IPv6 attacks exceeding 1 Tbps, while the amount of IPv6 traffic requiring active DDoS mitigation has also increased significantly. For operators running dual-stack or IPv6 networks, IPv6 visibility and mitigation therefore need to be part of the production DDoS strategy, not an additional capability added later. At a basic level, DDoS attacks do not become fundamentally different because the destination uses IPv6. A UDP flood is still a UDP flood. A TCP SYN flood can target an IPv6 service in much the same way as an IPv4 service. High packet-rate attacks can put pressure on routers, firewalls and servers regardless of which IP version carries the traffic. There are, however, some differences in IPv6 that monitoring and mitigation systems need to account for. ## What does an IPv6 DDoS attack look like? Most common network-layer DDoS attacks have direct IPv6 equivalents. For example, an attacker can direct a large UDP flood towards an IPv6 address such as: ``` 2001:db8:100::1234 ``` The objective is the same as with IPv4: consume available bandwidth or overwhelm the packet-processing capacity of equipment or services. The same applies to TCP attacks. Large numbers of TCP SYN packets can be sent towards an IPv6 service, while very high packet rates can affect routers, firewalls, load balancers and servers. ICMP also exists in IPv6 as ICMPv6. It deserves some additional care because ICMPv6 is used for important IPv6 functions, including Neighbor Discovery and error signalling. Blocking all ICMPv6 traffic indiscriminately is therefore generally not a good mitigation strategy. For DDoS detection, the core measurements remain familiar: - bits per second; - packets per second; - flows per second where the telemetry source provides them; - TCP, UDP and ICMP traffic; - TCP SYN traffic. The important requirement is that these measurements are collected and analysed for IPv6 as well as IPv4. ## What is different about IPv6? The most obvious difference is the size of the address space. IPv6 uses 128-bit addresses, and operators routinely work with prefixes such as `/48`, `/56` and `/64`. A monitoring system therefore needs to handle IPv6 networks efficiently and correctly determine which traffic belongs to the monitored network. IPv6 packet handling also differs in some areas. Optional information can be carried in IPv6 extension headers between the IPv6 header and an upper-layer protocol such as TCP or UDP. Fragmentation also works differently: routers do not fragment IPv6 packets in transit; fragmentation is performed by the source using an IPv6 Fragment header. For most operators these details are not something they need to think about during every DDoS incident, but they do matter to the software receiving and interpreting network traffic. There is also a simpler operational issue: visibility. A network may have mature IPv4 DDoS monitoring but much less visibility into its IPv6 traffic. Enabling IPv6 on routers and services does not automatically mean the existing monitoring stack is collecting and analysing it. ## Monitoring IPv6 traffic with FastNetMon FastNetMon Advanced can process IPv4 and IPv6 traffic in the same deployment. Operators configure the IPv4 and IPv6 prefixes that belong to their network. FastNetMon uses this information to classify traffic direction and maintain counters for monitored networks and hosts. IPv6 traffic can be supplied using telemetry that supports IPv6, including NetFlow v9, IPFIX and sFlow, as well as mirrored packet traffic. For NetFlow deployments, the export format matters. IPv6 flow information requires an IPv6-capable export format such as NetFlow v9 or IPFIX. FastNetMon provides dedicated IPv6 counters that make it straightforward to confirm that IPv6 traffic is being received and classified correctly: ``` sudo fcli show total_traffic_counters_v6 sudo fcli show network_counters_v6 sudo fcli show host_counters_v6 ``` Traffic for an individual IPv6 host can also be checked with: ``` sudo fcli show single_host_counters_v6 2001:db8:100::1234 ``` FastNetMon also provides IPv6 support in `fastnetmon_client`: ``` sudo fastnetmon_client -ipv6 ``` This is useful during deployment because operators can verify IPv6 visibility before enabling any automated attack actions. In addition to CLI tools, [FastNetMon LiveView](https://fastnetmon.com/fastnetmon-liveview/) provides a visual view of current IPv4 and IPv6 traffic, which is useful for confirming visibility during deployment and for day-to-day operations: ![](https://fastnetmon.com/wp-content/uploads/2026/10/IPv6-DDoS-FastNetMon-LiveView-1024x538.png) ## Detecting IPv6 DDoS attacks FastNetMon uses traffic counters and configurable thresholds to detect abnormal traffic towards monitored hosts. Available threshold types include overall packets per second and bandwidth, as well as protocol-specific thresholds for TCP, UDP, ICMP and TCP SYN traffic. For example, an operator can configure an alert or attack action when an IPv6 host exceeds an expected UDP packet rate or overall bandwidth threshold. FastNetMon hostgroups can also contain IPv6 prefixes. This allows different groups of networks or customers to use different thresholds rather than applying a single DDoS threshold across the entire network. That can be useful in environments where customer servers, infrastructure services and high-bandwidth systems have very different normal traffic profiles. From an operational point of view, IPv6 therefore does not require a separate detection platform or a completely different detection model. IPv4 and IPv6 traffic can be monitored using the same FastNetMon deployment and the same types of traffic thresholds. ## Mitigating IPv6 DDoS attacks FastNetMon currently supports automatic IPv6 attack mitigation in blackhole mode. When an IPv6 host is detected as being under attack and the relevant attack actions are enabled, FastNetMon can announce the attacked host as an IPv6 `/128` over BGP. Operators can configure the BGP community and next hop used for these IPv6 announcements. FastNetMon also supports IPv6-specific AS path configuration. This allows the announcement to integrate with the operator's BGP blackhole policy, for example using an RTBH community understood by upstream or internal routers. IPv6 blocking must be enabled explicitly: ``` sudo fcli set main enable_ban_ipv6 enable sudo fcli commit ``` [FastNetMon Advanced 2.0.381](https://fastnetmon.com/2026/07/13/fastnetmon-advanced-2-0-381/), released in July 2026, also added support for manually announcing IPv6 BGP FlowSpec rules. It is important to distinguish this from automatic IPv6 FlowSpec mitigation. FastNetMon can originate manually defined IPv6 FlowSpec announcements, but the detection logic that automatically generates selective IPv6 FlowSpec rules from an attack is not currently implemented. Automatic IPv6 attack mitigation therefore remains based on blocking the attacked host rather than automatically constructing a selective FlowSpec filter. ## IPv4 and IPv6 in the same FastNetMon deployment For dual-stack networks, IPv6 does not require a separate FastNetMon installation. IPv4 and IPv6 prefixes can be monitored by the same system, using the same traffic sources and operational tooling. Operators can inspect IPv6 traffic counters, configure thresholds for IPv6 hosts and prefixes, detect attacks and automatically trigger IPv6 BGP blackhole announcements. The main requirement is to make sure IPv6 is included throughout the monitoring path: the network equipment needs to export IPv6 traffic information, the relevant IPv6 prefixes need to be configured in FastNetMon, and IPv6 mitigation needs to be configured if automatic blocking is required. For configuration details and the latest information on supported IPv6 functionality, see the [FastNetMon Advanced IPv6 support documentation](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-ipv6-support/). **Categories:** FastNetMon Blog, Featured **Tags:** IPv6, Network Security Insights --- ### [Inside Today's Botnets - Changing Supply Chain Behind the Terabit Scale Attacks](https://fastnetmon.com/2026/10/02/inside-todays-botnets-changing-supply-chain-behind-the-terabit-scale-attacks/) **Published:** October 2, 2026 **Author:** Outi Maria Pietilanaho **Content:** ![](https://fastnetmon.com/wp-content/uploads/2026/10/outi_wordpress.png) This article is based on the presentation **“Tracking Today’s Botnets — Threat Intel & Lessons to Defend Against DDoS”**, presented by FastNetMon’s Outi Maria Pietilanaho at [NOG.HR Meetup 7 in Zagreb in September 2026](https://fastnetmon.com/2026/09/10/nog-hr-meetup-7-event-page/). The talk focused on what recent DDoS data tells us about the infrastructure behind the attacks: where the capacity is coming from, how botnets are being built, and how the ecosystem is responding to disruption. ## From Denial of Service to the 1 Tbps DDoS era Denial of service is almost as old as the public Internet. The 1988 Morris worm was not a modern DDoS botnet, but its runaway propagation demonstrated how quickly distributed systems could exhaust shared resources. By the end of the 1990s, coordinated DDoS tooling had appeared: compromised machines were organised behind handlers and instructed to flood a target together. Researchers were already documenting hundreds of systems participating in coordinated attacks around the turn of the millennium. For most network operators, though, the more relevant history is much more recent. A few hundred gigabits per second once qualified as an exceptional DDoS event. The emergence of Mirai moved that ceiling around 2015 by showing what could happen when hundreds of thousands of cheap IoT devices were recruited at Internet scale. The original Mirai research tracked the botnet to a peak of roughly 600,000 infections, built largely through Internet-wide scanning and weak or default credentials. Then the numbers began moving in a completely different pace. In October 2024, Cloudflare reported a **5.6 Tbps UDP attack,** generated by a Mirai variant. It lasted only 80 seconds and involved more than 13,000 IoT sources. And then, 2025 came, with almost absurd attack volume growth. [7.3 Tbps](https://fastnetmon.com/2025/06/23/internet-under-fire-analysis-of-the-record-breaking-7-3-tbps-ddos-attack/). [11.5 Tbps](https://fastnetmon.com/2025/09/03/cloudflare-mitigates-record-breaking-11-5-tbps-ddos-attack/). [22.2 Tbps](https://fastnetmon.com/2025/09/23/a-new-world-record-ddos-attack-22-2-tbps/). [29.7 Tbps](https://fastnetmon.com/2025/12/04/new-record-breaking-ddos-29-7-tbps-aisuru-attack-marks-new-high-in-hyper-volumetric-threats/). By Q3 2026, the infamous Aisuru botnet was routinely producing attacks above 1 Tbps and 1 Bpps, and by the end of the year, the public bandwidth record had reached [**31.4 Tbps**.](https://fastnetmon.com/2026/02/01/aisuru-botnet-sets-a-new-ddos-record-at-31-4-tbps/) And to be frank, the most telling number may not be the record at all. In the first half of 2026, Cloudflare reported to have mitigated **935 network-layer DDoS attacks above 1 Tbps**. Between Q1 and Q2, the number of such attacks increased 519%. We have, effectively, entered the **1 Tbps era**. Terabit traffic is no longer interesting only because somebody broke a record. It has become a repeatable, common attack class, and this is the development where we should pay attention to, not necessarily the peak volumes and headlines. ![](https://fastnetmon.com/wp-content/uploads/2026/10/State-of-DDoS-1024x530.png)Pie chart illustrating the exponential growth in DDoS attack volumes. List of reported attacks is not exhaustive. But traffic does not appear from nowhere. If attack capacity has increased by this much, there must be an underlying increase in available infrastructure. This is what we are looking into next. ## How many bots in a net? For years, a large DDoS botnet generally meant tens or hundreds of thousands of sources. Mirai has been notorious precisely because it could reach hundreds of thousands of vulnerable devices. Through 2022, 2023 and 2024, the largest observed botnet populations were still broadly in that spectrum of several hundreds of thousands of compromised devices. Then, in 2025, things changed. Qrator first detected one very large bot population in March 2025 at **1.33 million devices**. [By Q1 2026, it had grown to **13.5 million**](https://qrator.net/blog/details/Q1-2026-DDoS-bad-bots-and-BGP-incidents-statistics-and-overview/). Those figures need some caution. A source IP, an active attacking endpoint and an infected physical device are not necessarily the same thing. DHCP churn, NAT, CGNAT and rotating residential addresses make botnet measurement inherently messy. Different vendors also have different visibility. But the exact census is less important than the order-of-magnitude change. Within a short period, researchers went from discussing populations in the hundreds of thousands to populations in the millions. ![](https://fastnetmon.com/wp-content/uploads/2026/10/Development-of-botcount-in-botnets-1024x538.png)Estimate number of bots in the largest botnets according to mainstream threat intelligence. For the purpose of illustrating scale - exact bot count in a botnet is complicated to achieve. The basic mechanism behind IoT botnets was not mysterious. Mirai had already shown how effectively the Internet itself could serve as a recruitment pool. Its bots scanned addresses looking for reachable devices, attempted known credentials, infected successful targets and then repeated the process. Later families added CVEs, new device classes and better persistence, but the underlying model remained recognisable: **find something exposed on the Internet, compromise it, and add it to the botnet.** That model survived for surprisingly long. And from a threat-intelligence perspective, it had a useful characteristic: the source often explained itself. If a particular IP address appeared in DDoS telemetry, researchers could scan it and frequently find a router, camera, DVR or exposed service that plausibly explained the infection. That was roughly the picture Nokia Deepfield says it saw through 2024. Its DDoS source intelligence often mapped neatly onto identifiable vulnerable devices or services. Then, in 2025, things stopped making sense in the way we were used to. But, before getting to the *why*, it is useful to look at the entire machinery. ## How does a DDoS botnet work? A DDoS botnet can be simplified into five stages: **recruit, control, attack, impact, persist**. ![](https://fastnetmon.com/wp-content/uploads/2026/10/How-does-a-Botnet-work-1024x523.png)First, the operator needs devices. That is recruitment: exploiting them, stealing them, renting access to them, or otherwise bringing them under control. Those devices then need a command path. C2 tells them what to attack, which vector to use, when to start and when to stop. Modern operators may rotate infrastructure, distribute tasks across different bot populations and change vectors during a campaign. At launch, the botnet converts that control into traffic: UDP floods, TCP floods, application requests or combinations of several vectors. The impact depends on where the target runs out of resources. Sometimes it is bandwidth. Sometimes packet processing. Sometimes connection state or the application itself. And after the attack stops, the useful bots normally remain. The operator can reuse them tomorrow. Each part of this chain matters, but the recent step-change in botnet scale makes one stage particularly interesting: ***The bot recruitment.*** And particularly, how did the pool of recruitable infrastructure suddenly become so much larger? ## What changed in the botnet recruitment? The old model is easy to draw. ![](https://fastnetmon.com/wp-content/uploads/2026/10/Legacy-bot-recruitment-model-1024x520.png)An operator scans the Internet. A router answers. A camera exposes an old service. A DVR has default credentials. A CPE device runs a vulnerable firmware version. Exploit the vulnerability, install the bot, enroll it into C2. Repeat. Around 2025, we started seeing attack sources that did not fit that model. Volumetric DDoS was arriving from ordinary-looking residential IP addresses. Researchers looked at those addresses and could not find the expected vulnerable Internet-facing device. No obvious camera, router or exposed service explained why that subscriber was suddenly generating attack traffic. The common feature was **[residential proxy infrastructure](https://www.nokia.com/blog/one-year-later-the-residential-proxy-botnet-problem-got-bigger-not-smaller/)**. Residential proxy networks themselves are not new. They provide a customer with traffic egress through a real consumer connection rather than a data-centre address. There are legitimate reasons to buy that service, and many dubious ones. Crucially, though, buying residential proxy service does not normally mean buying the device itself. Proxy access is not root access. What botnet operators discovered was that some proxy implementations could provide a route further into the endpoint: An attacker could buy access through the proxy network and, because of weaknesses in how the proxy software handled local destinations, reach an Android Debug Bridge service on the underlying device. The endpoint might be safely hidden behind NAT or CGNAT from the public Internet, yet reachable from inside the proxy overlay. From there, the attacker could gain control and install malware. The recruitment path had changed from: **scan the Internet → find device → compromise device** to something closer to: **buy proxy access → reach device through the proxy network → exploit locally reachable service → install bot** That is a profound difference for both attackers and defenders. The public IP no longer needs to expose the vulnerability. Internet-wide scanning may tell you very little about how the endpoint was compromised. ![](https://fastnetmon.com/wp-content/uploads/2026/10/New-model-residential-proxies-1024x517.png)This also changes the size of the pool. Some researchers have described the conventional active DDoS population it had been tracking as roughly **one million bots**. The residential proxy ecosystem represented an [estimated **100–200 million devices**](https://www.nokia.com/ip-networks/deepfield/genome-shield/anatomy-of-a-botnet-ddos-attack/). It is useful to make the distinction though: those are not 100–200 million infected bots. They are **potentially reachable endpoints**. But that is exactly why the number is important. Attackers no longer need every device in that pool to be compromised. They need a repeatable path into a critical mass of exploitable devices. When the available pool grows by two orders of magnitude, even a low conversion rate can create a *very* large botnet. ## From building the botnet to buying the supply This is where the change becomes economic rather than purely technical. The traditional botmaster had to discover its own inventory. Scanning, exploitation and recruitment were part of building the botnet. Residential proxy networks introduce an intermediary. Deepfield described operators buying proxy access and using it to reach vulnerable devices. In the channels researchers were observing, acquiring access paths towards [roughly **100,000 devices could reportedly cost only $10–15**](https://www.nokia.com/blog/one-year-later-the-residential-proxy-botnet-problem-got-bigger-not-smaller/). That does not mean $15 buys 100,000 infected bots. It buys access from which some portion of those devices may become exploitable. But the effect on botnet resilience is obvious. If defenders eliminate 100,000 bots and replacing them requires the operator to rediscover 100,000 vulnerable hosts across the public Internet, the disruption has a real rebuilding cost. If the operator can go back to an access market, buy another population and repeat the compromise process for a very nominal price, replacement becomes much easier. ![](https://fastnetmon.com/wp-content/uploads/2026/10/changed-model-of-botnet-operations-1024x506.png)Next interesting observation is that DDoS is only one way to monetise these devices. There are several instances where Kimwolf has been observed to use compromised endpoints both for volumetric DDoS and proxying. The botnet could enter through one proxy service, install another proxy component and sell the residential connection again. The same infrastructure was also associated with credential abuse, while other families added LAN scanning that could support reconnaissance or lateral movement. So there is a broader economy competing for these endpoints. A compromised Android box can be DDoS capacity, a residential exit node, credential-abuse infrastructure and a foothold inside a private network. The market incentive does not disappear when one DDoS service does. And once the access route became understood, other operators piled in. Currently, we can observe several botnet operators competing for the same devices, building methodologies for eliminating competing bots and moats for being eliminated. A botnet war happening inside a device while the owner is clueless of anything illegitimate happening. ![](https://fastnetmon.com/wp-content/uploads/2026/10/Botnets-competing-of-the-same-infrastructure-1024x523.png) ## What about take-downs? None of this means law-enforcement disruption has stopped working. [In March 2026, US authorities joined simultaneous actions](https://fastnetmon.com/2026/03/20/aisuru-and-kimwolf-disrupted-but-the-botnet-cycle-continues/) in Canada and Germany against infrastructure used by **Aisuru, KimWolf, JackSkid** and others. Domains, servers and other infrastructure were targeted; the four botnets collectively controlled millions of devices. A [wider PowerOFF action](https://fastnetmon.com/2026/04/16/europol-backed-operation-poweroff-targets-ddos-for-hire-ecosystem-contacts-75000-users/) the following month targeted the DDoS-for-hire market itself: authorities in 21 countries acted against more than 75,000 identified users, took down 53 domains and executed 25 search warrants. The impact is visible, and had tangible impacts. Qrator's largest observed botnet population fell from **[13.5 million in Q1 2026 to 2.09 million in Q2](https://qrator.net/blog/details/Q2-2026-DDoS-bad-bots-and-BGP-incidents-statistics-and-overview/)**. Nokia Deepfield's research team says the disruption of Kimwolf's original DDoS C2 worked: that operation is no longer active at its previous scale. But the replacement ecosystem remained. That forces takedowns to look beyond a single C2 server. Which dependency is actually difficult for the operator to replace? The hosting? The command path? The proxy provider? The access broker? The vulnerable software? The operator themselves? Attackers are simultaneously trying to make those dependencies less obvious. Qrator found [**Aeternum** storing C2 instructions in smart contracts on Polygon.](https://qrator.net/blog/details/Exploring-Aeternum-C2/) Soon afterwards it documented **[Void](https://qrator.net/blog/details/Void-Botnet-uses-Ethereum-smart-contracts-for-seizure-resistant-C2/)**, an unrelated Rust botnet using Ethereum smart contracts for the same basic purpose: infected hosts retrieve commands through public blockchain RPC infrastructure rather than depending entirely on a conventional domain and server. The DDoS packets do not travel through Ethereum. The blockchain is being used to make a small but critical part of the control plane harder to locate and seize. And the barrier to building this infrastructure may be falling as well. Palo Alto Networks' Unit 42 recently analysed **[TuxBot v3](https://fastnetmon.com/2026/07/16/new-iot-botnet-reveals-how-llms-are-changing-malware-development/)**, a multi-architecture IoT botnet framework whose developer relied heavily on an LLM to generate code, port exploits and build parts of the C2. The result was imperfect — Unit 42 found broken components, hallucinated cryptography and even AI safety warnings left in the source — but the core scanning, credential brute-forcing, persistence, C2 and DDoS functions worked. The framework compiled for 17 architectures and included automated testing infrastructure. It would be too strong to say that LLMs have made sophisticated botnet engineering trivial. TuxBot itself demonstrates the opposite: generated code still failed in revealing ways. What it does show is that one developer can assemble a surprisingly ambitious framework with much more machine assistance than was available a few years ago. That lowers the engineering barrier for the next generation of operators, even if it does not eliminate it. For defenders, this means the landscape is moving at several layers at once: recruitment is becoming commoditised, C2 is becoming more seizure-resistant, and tooling is becoming easier to assemble. ## We're all part of the problem - and solution too! There is one final change that matters directly to operators. DDoS has traditionally been discussed from the receiving side: detect the traffic, divert it, scrub it, filter it. Residential botnets make the other end of the attack increasingly difficult to ignore. We are already seeing large concentrations of compromised residential devices creating **availability problems inside the originating ISP itself**, particularly in Latin America. The impact can propagate into aggregation, ingress and transit infrastructure even when that network is not the attack target. And as we discussed, the problem is very tangible when with millions of available devices, a botnet operator does not even need to activate the entire population. This makes outbound DDoS visibility a network-engineering issue, not merely an abuse-desk concern. Access networks have a direct incentive to identify abnormal outbound floods, compromised subscriber populations and botnet C2 traffic before it consumes their own capacity or reaches somebody else's. It also makes DDoS defense increasingly collective. Target networks, access ISPs, transit providers, mitigation networks, device vendors, proxy operators, researchers and law enforcement all see different pieces of the same system. There is no single filter that fixes the current botnet problem. There is no takedown that permanently removes the economic incentive. And there is no reason to expect the recent growth in capacity to reverse on its own. What we have seen over the past 12–18 months is an abrupt expansion of both botnet capacity and botnet supply. The important development is not simply that attacks reached 30 Tbps. It is that the infrastructure behind them became easier to source, easier to replace and valuable for more than DDoS alone. The answer will have to evolve in the same way: better source-side visibility, faster automated mitigation, intelligence sharing, device remediation, pressure on abusive access markets and coordinated law-enforcement action against the parts of the value chain that are genuinely difficult for attackers to rebuild. There is no silver bullet here. But network operators have always been unusually good at solving problems that cross organisational boundaries. Today’s botnet ecosystem gives the community another one. **Categories:** FastNetMon Blog --- ### [Packet Filtering with VPP on BlueField-3 Arm Cores and 100G NICs](https://fastnetmon.com/2026/10/05/packet-filtering-with-vpp-on-bluefield-3-arm-cores-and-100g-nics/) **Published:** October 5, 2026 **Author:** FastNetMon **Content:** ![Portrait of a man with short dark hair and light stubble, wearing a dark gray T-shirt, facing the camera (circular crop).](https://fastnetmon.com/wp-content/uploads/2026/06/Denys-Haryachyy-FastNetMon-Guest-Blog.png) *This post is a repost of a [technical blog originally published by Denys Haryachyy](https://haryachyy.wordpress.com/2026/10/01/packet-filtering-with-vpp-on-bluefield-3-arm-cores-and-100g-nics/), shared here with permission as part of ongoing research and engineering work around FastNetMon’s inline traffic processing capabilities*. The NVIDIA BlueField-3 DPU carries sixteen Arm Cortex-A78AE cores right next to its ConnectX-7 network engine. I wanted to know how much an FD.io VPP data plane can filter when it runs on those Arm cores instead of the x86 host, so I built VPP with an ACL filter plugin for arm64, started it on the BlueField-3 in DPU mode and drove it with 2×100G of traffic. This post walks through every step of getting VPP up on the DPU — the card mode, the uplinks, hugepages, the container, the startup configuration — and then shows how fast it filters. In short: on a 100G port the Arm cores filter at line rate from 256-byte frames upward and on IMIX, while 64-byte floods top out at about 59 Mpps (42 Gbps, 41% of line rate) and 128-byte frames at 52 Mpps (64%). ## Our Test Setup The DPU sits in an AMD EPYC 9534 server. A separate Ryzen 9950X box runs TRex and is cabled to the two BlueField-3 uplinks with 100G DACs, no switch in between. | Component | Details | |---|---| | DPU | NVIDIA BlueField-3, integrated ConnectX-7, 2×100G uplinks | | Arm CPU | 16× Cortex-A78AE at 2.13 GHz, 512 KB L2 per core, 16 MB shared L3, 30 GB DDR5 | | DPU software | BlueField bundle 2.9.1 (DOCA 24.11), Ubuntu 22.04, kernel 5.15.0-1057-bluefield | | VPP | 25.10 built from source for arm64, DPDK mlx5 driver, in a Docker container on the Arm | | Generator | TRex 3.06 on a Ryzen 9 9950X with two ConnectX-5 Ex cards | [![VPP on the BlueField-3 Arm cores between the two uplinks](https://haryachyy.wordpress.com/wp-content/uploads/2026/10/vpp-bluefield3-dpu-datapath.png)](https://haryachyy.wordpress.com/wp-content/uploads/2026/10/vpp-bluefield3-dpu-datapath.png)VPP owns both uplinks on the Arm side; management stays on oob\_net0## Step 1 — Put the Card in DPU Mode A BlueField-3 runs either as a plain NIC, where the x86 host owns the ports, or in DPU mode, where the embedded Arm system owns the uplinks and the host only sees representor-backed functions. The mode is the firmware parameter `INTERNAL_CPU_MODEL`: `EMBEDDED_CPU(1)` is DPU mode, `SEPARATED_HOST(0)` hands the ports to the host. The Arm OS ships `mlxconfig`, so I read and set the mode from the DPU itself, which keeps the host free of any Mellanox tools ([NVIDIA: BlueField modes of operation](https://networking-docs.nvidia.com/doca/archive/3-5-0/bluefield-modes-of-operation)). ``` sudo mlxconfig -d 03:00.0 -e q INTERNAL_CPU_MODEL sudo mlxconfig -d 03:00.0 -y s INTERNAL_CPU_MODEL=1 sync ``` The query prints three columns — default, current and next boot — so it shows a pending change before it takes effect. The new value is applied only by a **cold power cycle of the whole server**: I power the chassis off through the BMC, wait for it to report off, power it on again and then check that the current column shows the new mode. A firmware reset or a warm reboot of the host leaves the old mode in place. > The DPU mode switch takes effect only after a cold power cycle of the host server, and that power cut also hits the Arm. Run sync on both sides first: files written to the Arm moments before the cut can come back empty. ## Step 2 — Release the Uplinks From OVS In DPU mode the Arm boots with Open vSwitch bridging each uplink to its host function: `ovsbr1` joins `p0` with `pf0hpf`, and `ovsbr2` joins `p1` with `pf1hpf` ([NVIDIA: virtual switch on the DPU](https://networking-docs.nvidia.com/bsp/4.5.6/virtual-switch-on-dpu)). DPDK needs the uplinks to itself, so I detach them from the bridges. The SSH session survives, because DPU management runs over the separate out-of-band port `oob_net0`, not over the uplinks. ``` sudo ovs-vsctl del-port ovsbr1 p0 sudo ovs-vsctl del-port ovsbr2 p1 # when finished, give the wire back to the host sudo ovs-vsctl add-port ovsbr1 p0 sudo ovs-vsctl add-port ovsbr2 p1 ``` ## Step 3 — Hugepages The BlueField OS mounts only a 2 MB hugetlbfs at `/dev/hugepages`; there is no 1 GB mount, so the whole VPP setup uses 2 MB pages. 4,096 of them (8 GB) hold the 4 GB main heap and a one-million-buffer pool comfortably. ``` echo 4096 | sudo tee /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages ``` ## Step 4 — Run VPP in a Container Nothing is compiled on the DPU. I build VPP 25.10 from the upstream source with `make pkg-deb` on a native arm64 GitHub Actions runner, inside an Ubuntu 24.04 container, and build the ACL filter plugin out of tree against those packages on the same runner. The resulting arm64 `.deb` files — `vpp`, `libvppinfra`, `vpp-plugin-core`, `vpp-plugin-dpdk`, `vpp-crypto-engines` and the plugin — are all the DPU needs. The BlueField OS ships Docker, so VPP runs in a container on the Arm cores. I build the image on the DPU itself: Ubuntu 24.04 plus those packages, `ibverbs-providers` and `libnuma1`. The DPDK mlx5 driver talks to the NIC through rdma-core’s mlx5 provider and the `/dev/infiniband` verbs devices. mlx5 is a bifurcated driver, so the uplinks stay bound to the kernel `mlx5_core` driver — no vfio or igb\_uio binding is needed ([DPDK mlx5 guide: bifurcated driver](https://doc.dpdk.org/guides/nics/mlx5.html#bifurcated-driver)). ``` docker run -d --name vpp --privileged --network host \ -v /dev/hugepages:/dev/hugepages \ -v /dev/infiniband:/dev/infiniband \ -v /run/vpp:/run/vpp \ -v $PWD/startup.conf:/etc/vpp/startup.conf \ vpp-arm64 vpp -c /etc/vpp/startup.conf ``` The container needs `--privileged` and the host network so DPDK can open the PCI devices and the verbs interface, plus the hugepage mount and `/run/vpp` for the CLI and API sockets. ## Alternative — FD.io Packages and an Out-of-Tree Plugin VPP itself does not have to be compiled at all. FD.io publishes arm64 builds for Ubuntu 22.04 — the release the BlueField OS runs — and 24.04, and their DPDK plugin already contains the mlx5 driver. On top of them only the plugin is built, out of tree, against the `vpp-dev` headers and CMake helpers ([FD.io 25.10 repository setup](https://packagecloud.io/fdio/2510/install)). The plugin is compiled against VPP’s internal headers, so I pin the exact package version and hold it, and rebuild the plugin whenever VPP moves. ``` curl -s https://packagecloud.io/install/repositories/fdio/2510/script.deb.sh | sudo bash V=25.10.0-23~g744d3c715 sudo apt-get install -y vpp=$V vpp-plugin-core=$V vpp-plugin-dpdk=$V \ vpp-dev=$V libvppinfra=$V libvppinfra-dev=$V \ build-essential cmake ninja-build python3-ply sudo apt-mark hold vpp vpp-plugin-core vpp-plugin-dpdk vpp-dev libvppinfra libvppinfra-dev ``` The plugin’s CMake project needs only two calls: `find_package(VPP)` loads the helpers that `vpp-dev` installs, and `add_vpp_plugin` generates the API code with `vppapigen` and compiles the data-plane node once per CPU variant ([VPP sample plugin](https://github.com/FDio/vpp/tree/stable/2510/src/examples/sample-plugin)). `vppapigen` imports PLY, which is why `python3-ply` is in the list above. ``` cmake_minimum_required(VERSION 3.16) project(acl-filter-plugin C) find_package(VPP REQUIRED) add_vpp_plugin(acl_filter SOURCES acl_filter.c acl_filter_api.c acl_filter_node.c MULTIARCH_SOURCES acl_filter_node.c API_FILES acl_filter.api ) ``` The packaged helpers install plugins under `lib/vpp_plugins` unless told otherwise, while the Debian VPP loads them from the multiarch directory. `VPP_LIBRARY_DIR` — not CMake’s usual `CMAKE_INSTALL_LIBDIR` — points the install at the right place: ``` cmake -S . -B build -G Ninja -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_INSTALL_PREFIX=/usr -DVPP_LIBRARY_DIR=lib/$(gcc -print-multiarch) cmake --build build sudo cmake --install build # /usr/lib/aarch64-linux-gnu/vpp_plugins/ ``` I ran this end to end in an arm64 Ubuntu 22.04 container under QEMU on an x86 laptop: the packages installed, the plugin built and installed in about seven minutes of emulated time, VPP listed it with its own version string, and a drop rule matched and dropped all 1,000 UDP packets the packet generator sent through it. The image that results is a drop-in for the container in Step 4. What this route gives up is CPU tuning. The packages are compiled for a generic `-march=armv8-a+crc` baseline plus a fixed set of node variants, and the plugin’s data-plane node inherits that same list from the packaged `cpu.cmake` ([VPP cpu.cmake: aarch64 variants](https://github.com/FDio/vpp/blob/stable/2510/src/cmake/cpu.cmake)). None of them targets the Cortex-A78AE, so on the BlueField VPP runs the baseline code everywhere — the plugin’s node shows `default` as its only active variant. Flags such as `-mcpu=cortex-a78ae`, which DPDK recommends for the BlueField-3, cannot be applied here: VPP and its bundled DPDK arrive prebuilt, and adding them to the plugin alone would still leave the RX path, buffer handling and graph dispatch on the generic build. Tuning needs VPP and DPDK built from source. | | FD.io packages + out-of-tree plugin | VPP built from source | |---|---|---| | Build time | minutes | about 47 minutes per VPP version on a GitHub arm64 runner | | Version control | pinned FD.io build, held in apt | any tag, any patch set | ## Step 5 — The Startup Configuration The uplinks are addressed by PCI address and renamed to `p0` and `p1` so the VPP interface names match the Linux ones. Each port gets as many RX queues as there are workers, and RSS hashes IPv4 and IPv6 so source-address variety spreads across all of them ([VPP startup.conf: the dpdk section](https://s3-docs.fd.io/vpp/25.10/configuration/reference.html#the-dpdk-section)). ``` unix { cli-listen /run/vpp/cli.sock startup-config /etc/vpp/setup.vpp nodaemon } memory { main-heap-size 4G main-heap-page-size 2M } dpdk { no-multi-seg no-tx-checksum-offload dev 0000:03:00.0 { name p0 num-rx-queues 12 num-tx-queues 12 num-rx-desc 4096 num-tx-desc 4096 rss { ipv4 ipv6 } } dev 0000:03:00.1 { name p1 num-rx-queues 12 num-tx-queues 12 num-rx-desc 4096 num-tx-desc 4096 rss { ipv4 ipv6 } } } cpu { main-core 0 corelist-workers 1-12 } buffers { buffers-per-numa 1048576 } plugins { plugin acl_filter_plugin.so { enable } } ``` Twelve workers on cores 1–12 is the best split I measured: core 0 runs the VPP main thread, and cores 13–15 stay with Linux, OVS and sshd. Fourteen workers filtered less than twelve, because the extra workers compete for the same 16 MB L3 rather than adding throughput. [![BlueField-3 Arm core layout for VPP](https://haryachyy.wordpress.com/wp-content/uploads/2026/10/vpp-bluefield3-arm-core-layout.png)](https://haryachyy.wordpress.com/wp-content/uploads/2026/10/vpp-bluefield3-arm-core-layout.png)Core layout: main thread on core 0, twelve workers on cores 1–12, three cores left to the OS## Step 6 — Wire the Ports and the Filter The startup script brings both uplinks up, cross-connects them at layer 2 in both directions and enables the ACL filter on each port, so every packet arriving on one uplink is classified and, unless a rule drops it, leaves on the other. An L2 cross-connect puts the ports in promiscuous mode, so the generator’s destination MAC does not matter. For a routed setup, address traffic to the uplink MACs of `p0` and `p1` — the host-side functions carry different MACs. To measure, I read the NIC’s own `rx_good_packets` and `rx_missed_errors` counters from `show hardware-interfaces` at the start and end of a 15-second window. `rx_missed_errors` rising means the Arm cores are saturated and the good-packet rate is the ceiling; when it stays at zero the DPU keeps up with the wire. ## How Fast It Filters Each point below is a 15-second sample with a drop rule matching the flood, one 100G port in and twelve workers, against the 100G line rate for that frame size. [![Drop rate per frame size on the BlueField-3 Arm cores](https://haryachyy.wordpress.com/wp-content/uploads/2026/10/vpp-bluefield3-drop-rate-by-frame-size.png)](https://haryachyy.wordpress.com/wp-content/uploads/2026/10/vpp-bluefield3-drop-rate-by-frame-size.png)Drop rate per frame size, one 100G ingress port | Frame | Drop, 1 port | Forward, 1 port | Drop, 2 ports | Forward, 2 ports | |---|---|---|---|---| | 64 B | 60 Mpps · 42 Gbps | 50 Mpps · 35 Gbps | 59 Mpps · 42 Gbps | 66 Mpps · 46 Gbps | | IMIX | 33.8 Mpps · ~100 Gbps (line rate) | 33.8 Mpps · ~100 Gbps (line rate) | 44 Mpps · 133 Gbps | 39 Mpps · 118 Gbps | | 1500 B | 8.1 Mpps · ~100 Gbps (line rate) | 8.1 Mpps · ~100 Gbps (line rate) | 16 Mpps · ~200 Gbps (line rate) | 15 Mpps · 183 Gbps | The 64-byte limit is shared by all twelve workers: flooding both uplinks reaches the same ~60 Mpps in aggregate, while large frames scale to both ports at line rate. ## Two Ports: Pin RX Queues per Port With both uplinks loaded, VPP’s default placement spreads every port’s queues across every worker, so each worker polls both ports and the two flows of buffers thrash the same caches. For two-port runs I configure six RX queues per port and pin them with `set interface rx-placement`: queues of `p0` to the first six workers, queues of `p1` to the other six ([VPP CLI: set interface rx-placement](https://s3-docs.fd.io/vpp/25.10/cli-reference/clis/clicmd_src_vnet.html#set-interface-rx-placement)). That restores the full 59 Mpps aggregate. [![64-byte drop rate with one port, two ports default placement and two ports dedicated placement](https://haryachyy.wordpress.com/wp-content/uploads/2026/10/vpp-bluefield3-rx-placement.png)](https://haryachyy.wordpress.com/wp-content/uploads/2026/10/vpp-bluefield3-rx-placement.png)64-byte drop rate: dedicated per-port placement recovers the full rate## Working Set: Flows Matter, Rule Count Does Not The table can be large: I loaded 983,045 rules and the per-packet cost stayed the same as with 10,000. What moves the rate is how many different rules the traffic touches at once. The BlueField-3 holds its peak up to about a hundred simultaneous flows and then declines steadily as the working set outgrows the 512 KB L2 and 16 MB L3. [![64-byte drop rate versus simultaneous active flows](https://haryachyy.wordpress.com/wp-content/uploads/2026/10/vpp-bluefield3-working-set.png)](https://haryachyy.wordpress.com/wp-content/uploads/2026/10/vpp-bluefield3-working-set.png)64-byte drop rate versus simultaneous active flows, 983,045 rules installed | Change | Per-packet cost | Effect | |---|---|---| | 10,000 → 983,000 rules (one match shape) | 29.1 → 29.1 ticks | none — hash lookup, untouched rules never reach the cache | | +5 port-range rules (2 match shapes) | 29.1 → 47.7 ticks | +64% — one more hash table probed per packet | | 1,000 → 10,000 active flows | 29.1 → 56.6 ticks | ×2 — the working set leaves the cache | ## Reading Cycle Counters on Arm The clock column of `show runtime` counts ticks of the Arm generic timer, which runs at 330 MHz on the BlueField-3, not CPU cycles. The A78AE cores run at 2.13 GHz (measured with `perf stat`), so one VPP tick is about 6.5 core cycles. The 29 ticks per packet above are therefore roughly 190 core cycles, and only the converted figure compares with the TSC-based clocks VPP reports on x86. ## Summary VPP runs on the BlueField-3 Arm cores in a Docker container, from arm64 packages built natively in CI. The card goes into DPU mode through `mlxconfig` on the Arm and a cold power cycle; the uplinks come out of the OVS bridges while management stays on `oob_net0`; VPP uses 2 MB hugepages and the bifurcated mlx5 driver from a privileged container; twelve workers with one RSS queue each give the best rate. On that setup the DPU filters at 100G line rate for frames of 256 bytes and larger and for IMIX; smaller frames are CPU-bound, at about 59 Mpps (42 Gbps) for 64 bytes and 52 Mpps (64 Gbps) for 128 bytes. With both uplinks loaded, 1500-byte frames reach about 200 Gbps. The filter keeps its per-packet cost flat from ten thousand to nearly a million rules. ## References - [NVIDIA DOCA: BlueField modes of operation and INTERNAL\_CPU\_MODEL](https://networking-docs.nvidia.com/doca/archive/3-5-0/bluefield-modes-of-operation) - [NVIDIA BlueField BSP: virtual switch (OVS) on the DPU](https://networking-docs.nvidia.com/bsp/4.5.6/virtual-switch-on-dpu) - [DPDK: NVIDIA BlueField board support package guide](https://doc.dpdk.org/guides/platform/bluefield.html) - [DPDK mlx5 driver: bifurcated driver model](https://doc.dpdk.org/guides/nics/mlx5.html#bifurcated-driver) - [NVIDIA NICs performance report with DPDK 25.03 (BlueField-3 Arm results)](https://fast.dpdk.org/doc/perf/DPDK_25_03_NVIDIA_NIC_performance_report.pdf) - [VPP 25.10 startup.conf reference: the dpdk section](https://s3-docs.fd.io/vpp/25.10/configuration/reference.html#the-dpdk-section) - [VPP 25.10 CLI: set interface rx-placement](https://s3-docs.fd.io/vpp/25.10/cli-reference/clis/clicmd_src_vnet.html#set-interface-rx-placement) - [FD.io VPP 25.10 packages, including arm64](https://packagecloud.io/fdio/2510) - [VPP sample plugin: out-of-tree plugin layout](https://github.com/FDio/vpp/tree/stable/2510/src/examples/sample-plugin) - [VPP cpu.cmake: aarch64 multiarch variants and baseline flags](https://github.com/FDio/vpp/blob/stable/2510/src/cmake/cpu.cmake) - [VPP docs: multiarch node function variants](https://s3-docs.fd.io/vpp/25.10/developer/corearchitecture/multiarch/nodefns.html) - [FD.io wiki: VPP on AArch64](https://github.com/FDio/vpp/wiki/VPP-AArch64) - [Kashyap et al., Understanding the Idiosyncrasies of Emerging BlueField DPUs (ICS 2025)](https://hpcrl.github.io/ICS2025-webpage/program/Proceedings_ICS25/ics25-40.pdf) - [Schrötter et al., XenoFlow: How Fast Can a SmartNIC-Based DNS Load Balancer Run? (BlueField-3)](https://arxiv.org/abs/2509.21656) - [BlueField DPU setup notes for non-DGX servers (j3soon)](https://github.com/j3soon/bluefield-dpu-setup-notes) - [Red Hat: offloading network functions to BlueField-2 DPUs](https://www.redhat.com/en/blog/optimizing-server-utilization-datacenters-offloading-network-functions-nvidia-bluefield-2-dpus) - [Arm Dataplane Stack: VPP reference solutions on Arm Neoverse](https://dataplane-stack.docs.arm.com/en/nw-ds-2024.03.29/overview.html) **Categories:** FastNetMon Blog, Featured --- ### [RONOG 11 – Event Recap](https://fastnetmon.com/2026/09/30/ronog-11-event-page/) **Published:** September 30, 2026 **Author:** FastNetMon **Content:** FastNetMon was pleased to join **RONOG 11** in Bucharest, bringing together the Romanian network operator community for a full day of technical talks, discussions and networking. Our Bucharest-based colleague **Virgil Truică** joined network operators, engineers, infrastructure providers and security professionals from Romania and further afield at the Radisson Blu Hotel. RONOG has grown into an important meeting point for the networking community in the region, and once again the agenda reflected the breadth of challenges facing operators today — from DDoS and BGP to AI infrastructure, optical networking, peering and automation. ## A morning of DDoS, infrastructure and network security The opening plenary covered several topics particularly close to us at FastNetMon. Alexandru Tolgyi from ZET.net presented **“Stopping DDoS at the Door,”** while Massimiliano Stucchi from Team Cymru introduced a collection of **no-cost community network tools**. The morning also included sessions on open data, EVPN and infrastructure architecture. After the first networking break, **Virgil chaired the late-morning plenary**, guiding a varied session that moved from the impact of AI on the technical workforce and digital infrastructure to some very familiar territory for anyone following the current DDoS landscape. Chase Clowser from Recorded Future presented research into **modern DDoS botnets using publicly available cryptocurrency blockchains as command-and-control infrastructure** — another example of how the infrastructure and techniques behind DDoS attacks continue to evolve. The session then moved into optical networking, with Thomas Weible from Flexoptix looking at flexible DWDM network design for 1.6T, before Olena Lutsenko from RETN discussed where traffic is heading next and the infrastructure required to support growing AI workloads in Romania. It made for an interesting mix of security, infrastructure and capacity planning — different subjects on the surface, but all closely connected when it comes to building networks that can continue to perform reliably as traffic patterns and threats change. ## From optical networks to BGP and peering The afternoon kept the technical variety going. Sessions covered **continuous optical monitoring, the changing value of IP addresses, AI infrastructure and connectivity in Central and Eastern Europe, and the practical considerations behind 400G optical networking**. One presentation we particularly enjoyed seeing on the agenda came from Ștefan Alexandru Cezar Mincu of the Networking & Cybersecurity Club at “Alexandru Ioan Cuza” High School, sharing how a networking club developed into hands-on Internet experience. It was great to see the next generation of network engineers represented alongside experienced operators and industry speakers. The closing plenary brought things back to some of the fundamentals of operating the Internet. Livio Morina from PeeringDB discussed building an effective network profile, Andrian Visnevschi from IT Care looked at the state of **BGP policy automation**, and Gianluca Sironi from Naquadria gave attendees a closer look at **Internet traffic in Romania**. That breadth is a big part of what makes network operator group meetings worthwhile. You can start the day discussing DDoS mitigation and EVPN, move through optical infrastructure and AI traffic, and finish with BGP and peering — while hearing directly from people working with these technologies in production. ## Thank you, RONOG A big thank you to the **RONOG team and InterLAN**, as well as the programme committee, speakers, sponsors and everyone else who helped make RONOG 11 happen. The official programme continued beyond the talks with an evening networking party, giving the community more time to catch up after a packed day of sessions. And, of course, thank you to everyone who caught up with Virgil during the event and shared their experiences and challenges. The conversations around DDoS detection and mitigation, network security, traffic visibility and day-to-day network operations are always one of the most valuable parts of these meetings. It was great to see familiar faces, make new connections and once again be part of **Romania’s network operator community**. **Until the next RONOG — we hope our network paths cross again soon!** **Event:** RONOG 11 **Date:** September 29, 2026 **Location:** Radisson Blu Hotel, Bucharest, Romaniafaces and making new connections. **Event:** RONOG 11 **Date:** September 29, 2026 **Location:** Radisson Blu Bucharest Hotel, Calea Victoriei 63-81, Bucharest 010065, Romania See our [social media](https://lnkd.in/p/e7ja67vK) for event photos! **Categories:** Events --- ### [Network Engineering Community News: September 2026](https://fastnetmon.com/2026/09/29/network-engineering-community-news-september-2026/) **Published:** September 29, 2026 **Author:** FastNetMon **Content:** ⚡️ Network Engineering Community News - from FastNetMon September at FastNetMon brings new open-source launches, FastNetMon Advanced 2.0.384, community updates from events, and a closer look at LiveView. Happy reading! | \| \| \| \| \| \|:-:\| \| \|:-:\| \| \|:--\| \| \| \| ![]() \| \| \|:--\| \| \|:--\| \| \| \| \| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| ### Product Updates \| \|:--\| \| \| \| \| \|:--\| \| \|:-:\| \| \|:--\| \| \| \| ## Expanding Our Open-Source Stack, Plus a New Advanced Release \| \| September brought several important updates across the FastNetMon ecosystem. We launched [**FastACL Community**](https://fastnetmon.com/2026/09/25/introducing-fastacl-community-open-source-ddos-scrubbing/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) and [**Netom**](https://fastnetmon.com/2026/09/24/introducing-netom-an-open-source-bgp-bmp-monitoring-engine-built-for-scale/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter), expanding our open-source stack into high-performance DDoS scrubbing and large-scale BGP/BMP monitoring. We also released [**FastNetMon Advanced 2.0.384**](https://fastnetmon.com/2026/09/16/fastnetmon-advanced-2-0-384/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter), with new psample traffic collection, multi-endpoint flow forwarding, expanded Prometheus monitoring, and more. \| \| \|:--\| \| \|:--\| \| \|:-:\| \| \| \| \| \| \|:-:\| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| ### **Deprecation notice** \| \|:--\| \| \| \| \| \|:--\| \| \|:-:\| \| \|:--\| \| \| \| Debian 11 (Bullseye) reached its FastNetMon Advanced deprecation date on **September 15, 2026**. [Version 2.0.383](https://fastnetmon.com/releases/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) was the final release supporting Debian 11, so users still running Bullseye should plan their migration to a supported operating system. For more info see our [Release Lifecycle](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-release-lifecycle/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter). \| \| \|:--\| \| \|:--\| \| \|:-:\| \| \| \| \| \| \|:-:\| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| ### FastACL Community \| \|:--\| \| \| \| \| \|:--\| \| \|:-:\| \| \|:--\| \| \| \| [![](https://eoolnbw.stripocdn.email/content/guids/CABINET_996c860aa178f7fedfae229d01d4e9aaa104c3a3417a0d1025c5c54ea32f38a0/images/fastacl_diagram.png)](https://fastnetmon.com/2026/09/25/introducing-fastacl-community-open-source-ddos-scrubbing/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| \| ## Open-Source DDoS Scrubbing at 400 Gbps \| \| **Big news this month: we launched FastACL Community**, our open-source inline DDoS mitigation engine built on FD.io VPP. We designed it for extreme packet-processing performance on commodity hardware, reaching 270 Mpps with 64-byte packets and full 400 Gbps throughput in our testing. DDoS scrubbing at this performance level is still unusual. With FastACL Community, we decided to build it — and make it available to everyone. For a more hands-on perspective, we also shared **[“We are under attack! (of a DDoS)”](https://fastnetmon.com/2026/09/15/we-are-under-attack-of-a-ddos/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter)**, a community story from Peter-Paul Kurstjens about building his own DDoS detection and mitigation setup around VPP. \| \| \|:--\| \| \|:--\| \| \| \| [FastACL on GitHub](https://github.com/FastNetMon/FastACL-Community?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| \| \|:-:\| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| ### Introducing Netom \| \|:--\| \| \| \| \| \|:--\| \| \|:-:\| \| \|:--\| \| \| \| [![](https://eoolnbw.stripocdn.email/content/guids/CABINET_996c860aa178f7fedfae229d01d4e9aaa104c3a3417a0d1025c5c54ea32f38a0/images/introducing_netom_bgpbmp_monitoring_at_scale.jpg)](https://fastnetmon.com/2026/09/24/introducing-netom-an-open-source-bgp-bmp-monitoring-engine-built-for-scale/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| \| ## Open Source BGP Monitoring Built for Scale \| \| [**Netom**](https://fastnetmon.com/2026/09/24/introducing-netom-an-open-source-bgp-bmp-monitoring-engine-built-for-scale/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) is our new open-source BGP/BMP monitoring engine for operators working at serious routing scale. It ingests **BGP, BMP, and MRT data**, keeps routing state in memory, exposes it through CLI and HTTP API, and can retain history in ClickHouse. The first release builds on work we [demonstrated at NANOG 97](https://fastnetmon.com/2026/06/08/see-you-at-nanog-97/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter), including monitoring 300 million prefixes across 2,800 BGP sessions. Want to see Netom taken for a spin in the wild?[ Exergy ∞ Connect has already been putting it through its paces ](https://lnkd.in/p/egKAzHDd?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter)(Kudos to Jeroen van Bemmel). \| \| \|:--\| \| \|:--\| \| \| \| [Netom on GitHub](https://github.com/FastNetMon/netom?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| \| \|:-:\| \| \|:--\| \| \| \| ### Team News \| \| \| \| \| \|:--\| \| \|:-:\| \| \|:--\| \| \| \| [![](https://eoolnbw.stripocdn.email/content/guids/CABINET_996c860aa178f7fedfae229d01d4e9aaa104c3a3417a0d1025c5c54ea32f38a0/images/teamannouncementdenysharyachyy.png)](https://fastnetmon.com/2026/09/14/welcome-denys-haryachyy-to-the-fastnetmon-team/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| \| ## Denys Haryachyy joins FastNetMon \| \| We’re pleased to welcome [**Denys Haryachyy**](https://www.linkedin.com/in/haryachyy/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) as our new **Senior SDN Software Engineer**. Denys brings more than 20 years of experience in high-performance networking, SDN, and data plane development, with deep expertise in **VPP, DPDK, C, and AF\_XDP**. At FastNetMon, he is helping us expand our high-performance DDoS mitigation capabilities, including the work on the VPP-based filtering technology behind **FastACL**. We’re excited to have him on the team as we continue building the next generation of DDoS protection. \| \| \|:--\| \| \|:--\| \| \|:-:\| \| \| \| \| \| \|:-:\| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| ## A Look Inside FastNetMon LiveView \| \|:--\| \| \| \| \| \|:--\| \| [![](https://eoolnbw.stripocdn.email/content/guids/CABINET_996c860aa178f7fedfae229d01d4e9aaa104c3a3417a0d1025c5c54ea32f38a0/images/watch_liveview_walkthrough.jpg)](https://youtu.be/lORwFniXxJs?si=zOI9OMb5cfAtLYoG&utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| \| Haven’t tried **FastNetMon in the web interface** yet? LiveView makes it easier to monitor traffic, investigate attacks, and manage your setup from one place. Watch the walkthrough or [**try it for yourself!**](https://fastnetmon.com/how-to-get-fastnetmon-liveview/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| \| [LiveView Walkthrough](https://youtu.be/lORwFniXxJs?si=zOI9OMb5cfAtLYoG&utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| \| \|:--\| \| \| ## Recent NOG Meetups \| \|:--\| \| \| \| \| \|:--\| \| [![](https://eoolnbw.stripocdn.email/content/guids/CABINET_fcab01b1dcdf56ac2f4e39c61ae0e616d7f1b58e49e87a9909cfb1a330a572cb/images/copy_of_nonog_event.png)](https://fastnetmon.com/2026/07/16/snonog-8-nix-2026-event-page/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| \| We enjoyed visiting the Nordic networking community in Oslo, where [Pavel Odintsov presented FastNetMon Community Edition](https://fastnetmon.com/2026/09/09/snonog-8-nix-2026-event-page/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter). \| \| \| \| \| \|:--\| \| [![](https://eoolnbw.stripocdn.email/content/guids/CABINET_fcab01b1dcdf56ac2f4e39c61ae0e616d7f1b58e49e87a9909cfb1a330a572cb/images/copy_of_fastnetmon_is_attending_hrnog_meeting_7.png)](https://fastnetmon.com/2026/07/15/nog-hr-meetup-7-event-page/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| \| Great to spend time with the Croatian network operator community in Zagreb, where [Outi Maria Pietilänaho spoke about today’s botnets and DDoS landscape.](https://fastnetmon.com/2026/09/10/nog-hr-meetup-7-event-page/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| \| \|:--\| \| \|:--\| \| \|:-:\| \| \| \| \| \| \|:-:\| \| \|:-:\| \| \|:--\| \| \| \| \| \| \|:-:\| \| \|:--\| \| \| \| \| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| [![Logo](https://eoolnbw.stripocdn.email/content/guids/CABINET_25fbf50d6f886b897f2305af06c298676dd346c8a5de49097728110845f22b79/images/fastnetmon_logo_darkmode_enabled.png "Logo")](https://fastnetmon.com/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| \|:--\| \| Comprehensive solution for DDoS Security \| \| \|:--\| \| \| \| [![CUSTOM_ICON](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff9e4351fbcb955078ba327c189f28d8b8b57377a196b7d7db50a5853c7a6dd1/images/github_logo_icon.png "CUSTOM_ICON")](https://github.com/FastNetMon/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| [![IN](https://eoolnbw.stripocdn.email/content/assets/img/social-icons/logo-black/linkedin-logo-black.png "LinkedIn")](https://www.linkedin.com/company/fastnetmon?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| [![RDT](https://eoolnbw.stripocdn.email/content/assets/img/social-icons/logo-black/reddit-logo-black.png "Reddit")](https://www.reddit.com/r/fastnetmon/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| [![Yt](https://eoolnbw.stripocdn.email/content/assets/img/social-icons/logo-black/youtube-logo-black.png "Youtube")](https://www.youtube.com/@FastNetMon?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| [![BSKY](https://eoolnbw.stripocdn.email/content/assets/img/social-icons/logo-black/bluesky-logo-black.png "BlueSky")](https://bsky.app/profile/fastnetmon.bsky.social?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| [![IG](https://eoolnbw.stripocdn.email/content/assets/img/social-icons/logo-black/instagram-logo-black.png "Instagram")](https://www.instagram.com/fastnetmon?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| [![TT](https://eoolnbw.stripocdn.email/content/assets/img/social-icons/logo-black/tiktok-logo-black.png "TikTok")](https://www.tiktok.com/@fastnetmon?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| [![XCOM](https://eoolnbw.stripocdn.email/content/assets/img/social-icons/logo-black/x-logo-black.png "X")](https://x.com/fastnetmon?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| [![FB](https://eoolnbw.stripocdn.email/content/assets/img/social-icons/logo-black/facebook-logo-black.png "Facebook")](https://www.facebook.com/fastnetmon?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| \|:-:\|:-:\|:-:\|:-:\|:-:\|:-:\|:-:\|:-:\|:-:\| \| \|--:\| \| [Newsletter Archive](https://fastnetmon.com/newsletter/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| [Blog](https://fastnetmon.com/blog/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| \| \|:--\| \| \|:--\| \| \|:-:\| \| \| \| \| \| \|:-:\| \| \|:-:\| \| \|:--\| \| \|:-:\| | |---| **Categories:** Newsletter --- ### [Introducing Netom: an open-source BGP/BMP monitoring engine built for scale](https://fastnetmon.com/2026/09/24/introducing-netom-an-open-source-bgp-bmp-monitoring-engine-built-for-scale/) **Published:** September 24, 2026 **Author:** FastNetMon **Content:** We’re excited to announce the first release of **Netom**, an open-source BGP and BMP monitoring engine developed and maintained by FastNetMon. Netom is built for network operators who need to collect, inspect, and redistribute large volumes of routing information. It brings BGP, BMP, and MRT data into an in-memory RIB and makes that data accessible through a CLI and HTTP API—providing a programmable foundation for routing observability, analysis, and automation. This first release incorporates the scalability work we [**presented at NANOG 97**](https://fastnetmon.com/2026/06/08/see-you-at-nanog-97/), where we demonstrated monitoring **[300 million prefixes across 2,800 BGP sessions](https://youtu.be/m992J25_eBY)**. ### Built for production routing environments Netom goes beyond simply receiving BGP updates. The first release includes: - **BGP, BMP, and MRT ingestion** with an in-memory RIB that can be inspected through the CLI and HTTP API. - **BMP restreaming**, including connections to active TCP/TLS BMP feeds and the ability to provide downstream consumers with an initial RIB dump followed by live updates. - **Detailed routing visibility**, including ADD-PATH and FlowSpec data and inspection of best-path decisions. - **Streaming route exports** for integrating routing information with other network and observability systems. - **ClickHouse observation history**, enabling routing data to be retained and analyzed beyond the current state of the RIB. The architecture is intended for environments where conventional routing collectors can become difficult to operate as the number of sessions, prefixes, and updates grows. ### Open source and built on Rotonda Netom is a fork of **[Rotonda](https://nlnetlabs.nl/projects/rotonda/about/)**, the routing information platform originally developed by NLnet Labs. We’re grateful for the work of the Rotonda team and are building on that foundation with a focus on the requirements we encounter in large-scale production networks. Netom is open source under the **Mozilla Public License 2.0**, so operators can deploy it themselves, inspect the implementation, integrate it into their tooling, and contribute improvements upstream. This is only the first release. We see Netom becoming a useful building block for engineers who need high-performance access to routing state without treating the routing collector as a black box. **Documentation:** <https://netom.io/> **Source code:** <https://github.com/FastNetMon/netom> **Categories:** FastNetMon Blog, Featured, Press & Newsroom --- ### [We are under attack! (of a DDoS)](https://fastnetmon.com/2026/09/15/we-are-under-attack-of-a-ddos/) **Published:** September 15, 2026 **Author:** FastNetMon **Content:** ![](https://fastnetmon.com/wp-content/uploads/2026/09/Peter-Paul-Kurstjens.png) *This article is republished with the kind permission of **Peter-Paul Kurstjens**. We are sharing it to showcase a real-world implementation of FastNetMon’s inline traffic filtering solution, currently under the working name [FastACL](https://fastnetmon.com/2026/09/25/introducing-fastacl-community-open-source-ddos-scrubbing/).* *A big thank you to Peter-Paul for the interesting work and for sharing his experience with the community.* You can find the original LinkedIn article [here](https://www.linkedin.com/pulse/we-under-attack-ddos-peter-paul-kurstjens-ak44e/). I'm writing this article because lately my network, AS200132, has been having some hiccups. Not because the software is unstable, but because of attacks from the outside — infamously known as [DDoS attacks](https://fastnetmon.com/2026/09/21/ddos-explained-what-is-a-distributed-denial-of-service-attack/). - For reference — attacks involved multiple hundreds of Gbps... more than I can absorb. I don't understand, and will never understand, why people resort to this kind of thing. My network is purely intended to help others — you know, supporting, helping. It's a bit like attacking a school: a place where people experiment, learn, and grow. You shouldn't do that either. Despite everything, I had to take some measures to protect my network from downtime, which set me out to build an anti-DDoS engine. ## Principles There are various mitigation options and detection mechanisms for DDoS attacks. I'll restrict this article to how I built my DDoS shield, named Sentry-Flow (SF), which makes use of flow data. As a sneak preview, here's a screenshot of the app. ![Article content](https://media.licdn.com/dms/image/v2/D4E12AQExVqVrKlAIdw/article-inline_image-shrink_1500_2232/B4EaCcJ7_gJcAg-/0/1789326246343?e=1790812800&v=beta&t=ta_YMwSHZfqVdTkQ6ZRh4UzAKq7xJe_lJfArJapLjGk)For people not interested in reading but but clicking: [https://sentryflow-demo.netone.nl](https://sentryflow-demo.netone.nl/) is a demo/mockup of the suite in production. And now how i got there ... I love the following two pictures from [Pavel Odintsov](https://www.linkedin.com/in/podintsov/) of [FastNetMon](https://www.linkedin.com/company/fastnetmon/) , which explain what's traveling in a "flow" — in this case, IPv4 and IPv6 packets. ![Article content](https://media.licdn.com/dms/image/v2/D4E12AQH5yMqj9JBnFQ/article-inline_image-shrink_1000_1488/B4EaCcD2T7JQAI-/0/1789324649946?e=1790812800&v=beta&t=izE13hG7P51pqKIi8Lo2NgDZIjAM9XiBV2yjzHLy5uw)IIPV4![Article content](https://media.licdn.com/dms/image/v2/D4E12AQGzyxlQKBV1gw/article-inline_image-shrink_1500_2232/B4EaCcD6q8KoAU-/0/1789324667828?e=1790812800&v=beta&t=RDVPUHs_itYej0mAP6XHHMjXuFO1EIVLtnf-9GMSD1I)IPV6This is also what i want to use for my anti-DDoS / mitigation / detection engine. I want to decode flows based on their content to initiate remediation actions where needed, eg looking inside the packets to determine if traffic is clean or malicious. ## Building A little epilogue is in order here. I could have downloaded an open-source suite or bought a commercial product, but since everything is paid out of my personal account, that's a tough call. There are some very good open-source products out there — check out the folks at [FastNetMon](http://fastnetmon.com) , they have a nice suite. For me, I'm using some specific automation tooling and setup, and I decided to set up a "date" with [Claude.ai](http://claude.ai/) to build a suite of my own. *Basic components*: Bird routing, VPP dataplane, RHEL 9 + 10 servers, Arista + Mikrotik networking. *Note*: I'm not a developer, so yes — I've vibe-coded this. But there's vibe coding, and there's vibe coding. I put everything into the context/harness of Claude, based on the principles we preach at [Red Hat](https://www.linkedin.com/company/red-hat/) when it comes to proper software building: testing, linting, SBOMs, hashing, CVE scanning, cleaning, and so on. For reference, when the GitLab runners build the Sentry-Flow application, each build runs nearly 81 "tests" to validate the app and each individual function, poller, trigger, job, etc. ``` find . -type d -print0 | while IFS= read -r -d '' d; do printf "%8d %s\n" "$(find "$d" -type f | wc -l)" "$d" done | sort -nr 81 .TESTS 64 ./backend 17 ./worker ``` ![Article content](https://media.licdn.com/dms/image/v2/D4E12AQFHBa-0q90crA/article-inline_image-shrink_1500_2232/B4EaCcPQQWIwAU-/0/1789327639885?e=1790812800&v=beta&t=akvBh2j9d2MXkLuO3OikUpYxLEICKUlPbgrcqPh9zJ8)GIT PIPELINEWhat did I need to build Sentry-Flow? - Flow data - Detection - Baselining - Actions / test area - Generic management I'll explain further what I used for each of these and how the various capabilities look in Sentry-Flow itself. ### Flow data There are basically two ways for me to get flow data — either by using the sFlow plugin from [FD.io](http://fd.io/) Vector Packet Processing on the routers themselves (I have three), or by using an sFlow exporter on a switch. Since my routers are mainly connected to one switch (either DWDM/L2 or via dedicated port channels), and since I couldn't get the VPP plugin working, I decided to put an exporter on the Arista 7280 switch I have. I won't go into the config here. Data is then exported to an application called Akvorado — a really nice suite that gathers flow data and presents it with various queryable options: destination ASN, source ASN, addresses, IPv4/IPv6, geographic information, and much more. See below a screenshot from their website, and check out <https://demo.akvorado.net/> as well. ![Article content](https://media.licdn.com/dms/image/v2/D4E12AQEnJb7dIHGLUA/article-inline_image-shrink_1500_2232/B4EaCcHlSXH8AU-/0/1789325628907?e=1790812800&v=beta&t=f5YuZwNeSwz4WyWLKdFVIEz1VxosYoQGZl5PXTA3OlI)SAMPLE AKVORADO### Detection Now we have proper data — awesome! But we need to make sense of it. After some searching, I found this article by [Vincent Bernat](https://www.linkedin.com/in/vincentbernat/) : <https://vincent.bernat.ch/en/blog/2023-akvorado-ddos-flowspec>, which was a great source of inspiration. He describes a few patterns and queries we can run against the ClickHouse database behind Akvorado. I fed all of this into Claude and used it as the basis for the baselines. Building on his work, Sentry-Flow ships with some pre-defined patterns and also lets you build your own. You can adjust the various weight factors of a pattern from within the app too. This is probably the part — patterns and weight factors — that will need the most rework and tweaking going forward. ![Article content](https://media.licdn.com/dms/image/v2/D4E12AQHbl5NndXQF9A/article-inline_image-shrink_1500_2232/B4EaCcIy54G4AQ-/0/1789325946952?e=1790812800&v=beta&t=DpR0lPFAUMUcUo9R1dlq-srzdf7sp1MiH3Dma97uRL8)![Article content](https://media.licdn.com/dms/image/v2/D4E12AQEE0EJCwUUTYg/article-inline_image-shrink_1500_2232/B4EaCcI0pcG8AY-/0/1789325953867?e=1790812800&v=beta&t=hYOl_WHz9E2xDy9qK_nCaBuZR8LZdUmsibu9oExAcXc)### Baselining Next up: monitoring. Before you can take action, you need to determine what's "normal" and what isn't. For this, Sentry-Flow has a baseline function that determines, based on historical Akvorado data, whether traffic is behaving as expected. The system adapts automatically via jobs in the backend containers, adjusting its expectations over time. It's also possible to manually adjust the time profile of the traffic — some downstreams and upstreams are day- or night-heavy, and that's a parameter I can tune. ![Article content](https://media.licdn.com/dms/image/v2/D4E12AQH-a50TjkKx9A/article-inline_image-shrink_1500_2232/B4EaCcJiQaKYAQ-/0/1789326140847?e=1790812800&v=beta&t=JpJcBlVFwnFafXKFgB6bM4oe_MV-h6M2z7RhDHcrotc)BASELINE TRAFFIC NETONE / AS200132![Article content](https://media.licdn.com/dms/image/v2/D4E12AQHBiSIfl3zUIQ/article-inline_image-shrink_1500_2232/B4EaCcJntbHoAQ-/0/1789326163178?e=1790812800&v=beta&t=eEqq1BRpXZ81H30Btu1xhTSzW8tiRevWmWtK8bqcCWc)PATTERN ADJUSTMENTS FOR TRANSIT### Actions Now the most tricky part — if something is detected (see the dashboard at the beginning of the article), what am I going to do? After some investigation, there are basically three options available to me: 1. **Blackholing** I can blackhole a target or destination — either via a route to 0.0.0.0 or via a BGP community (666). 2. **ACLs** I can apply Access Control Lists on the dataplane, in this case VPP. 3. **BGP FlowSpec** I can use BGP FlowSpec, with fine-grained options to tweak incoming and outgoing traffic based on patterns. I've decided to implement all three options into Sentry-Flow. For each remediation — and depending on the capabilities of each router, which are tested when it's added to the app — the relevant remediation options become available. This means you can have a mix of routers with more or less capability, and Sentry-Flow adapts to what each one supports. For reference: Sentry-Flow currently only works against Bird 2.19+ and VPP. VPP only supports FlowSpec via a special plugin from [FastNetMon](http://fastnetmon.com) , developed by a team led by [Denys Haryachyy](https://www.linkedin.com/in/haryachyy/) , on VPP 25.10 or VPP 26.06. Also, for each of the three remediation types, there's a "staged" variant and a "realtime" variant: realtime takes action immediately without making it permanent, while staged writes the change to the config files. *(The FastNetMon plugin isn't generally available yet — contact* [Pavel Odintsov](https://www.linkedin.com/in/podintsov/) *if you want to test it too.)* The staged option is directly linked to my Git repo, where my automation tooling lives. I use [Netwerkvereniging Coloclue](https://www.linkedin.com/company/coloclue/) KEES automation toolchain (though with heavy modifications). In my private repo, Sentry-Flow opens a PR/MR — for example, a blackhole in static-routes.conf — and merges it after my approval. For VPP, Sentry-Flow can edit the daemon's bootstrap file or execute the plugin commands directly, restricted to only those specific commands and nothing else. A mitigation then looks like this — a sample detection with all the available actions. They light up green when I pick one 🙂 I particularly like the console output, where I can see exactly what's being executed. ![Article content](https://media.licdn.com/dms/image/v2/D4E12AQGCeP6SNEl0gA/article-inline_image-shrink_1000_1488/B4EaCcMVbKKgAI-/0/1789326874704?e=1790812800&v=beta&t=uVWfLknUNKFiqOcIt-SMczS_t_6moZ8XtMVydvgd7QA)Once a mitigation is applied, it shows up in the "Active Mitigations" tab, where I can see everything currently applied — realtime or staged — and withdraw it if needed. I also like the manual mitigation option here, including the ability to set a timer for automatic withdrawal. A similar pane called "Test Area" lets me test freely using RFC 5737 (203.0.113.0/24, 198.51.100.0/24, 192.0.2.0/24) and RFC 3849 IPv6 ranges — so I can experiment without breaking anything... I think 🙂 ![Article content](https://media.licdn.com/dms/image/v2/D4E12AQEK_VNVnEJiNA/article-inline_image-shrink_1500_2232/B4EaCcNWHzKUAU-/0/1789327139639?e=1790812800&v=beta&t=kAJEmbfbvwGcPdIdF3K3raX8yAYnhMDSYKpopjX7Icw)### Generic management To conclude - an engine is nothing without proper infrastructure management around it. So i have builtin the following features as well - Configurable options for Akvorado — either polling via ClickHouse or a realtime Kafka bus query ![Article content](https://media.licdn.com/dms/image/v2/D4E12AQGGSqYx85U0aw/article-inline_image-shrink_1500_2232/B4EaCcQaECGoAQ-/0/1789327942302?e=1790812800&v=beta&t=dKbm5fjD1PzXO9SD0amfGqu8e7zQV3jlYxtYYcZBG4E) - Adding/removing routers with proper connectivity and capability checks. In the router's edit pane, you can also select, based on a query to VPP, which interfaces the ACLs should apply to — either ACL or FastACL ![Article content](https://media.licdn.com/dms/image/v2/D4E12AQEmbcJp4aC-KQ/article-inline_image-shrink_1500_2232/B4EaCcRPS6G4AQ-/0/1789328160172?e=1790812800&v=beta&t=yTadNrXZvSpGPrThMA-DGv9b3pCX2sTX9bRgnKalfQc)![Article content](https://media.licdn.com/dms/image/v2/D4E12AQGMTvdz0tOwsA/article-inline_image-shrink_1000_1488/B4EaCcRhDkIQAI-/0/1789328232910?e=1790812800&v=beta&t=78cM0d2OlzB_I55VZGi1pD8Omv_HVuhxIJegl5FBPYU) - A notification system for detections, issues, and lost connectivity to Akvorado, with configurable alerts based on my needs. Notifications go out via SMTP or Matrix - Branding: I can adjust the logo, colors, and text body colors, and Sentry-Flow has a dark/light mode - User management: both local and LDAP-based, with built-in 2FA. Keycloak/SAML/OAuth is on the roadmap. Also includes session timers, avatars, username changes, and a full RBAC system with admin, operator, and read-only roles - Configurable parameters for my Akvorado instance, GitLab/Forgejo/Gitea, ports, timeouts, etc. - Retention jobs for the detection log - SBOM generation with each build, plus calendar versioning (2026.9.X) of the appe Lastly, a backup system for all settings, exported with proper keys and hashing. Note: all data is encrypted on initial launch of Sentry-Flow, so if you lose the original keys, the settings can't be imported into a new system. ### Roadmap The following items are on the roadmap/backlog: - A DDoS simulator for the various patterns, to really test that the system works - More options around BGP FlowSpec - Making it scalable — more workers, backend, Kubernetes support - Making it open source 🙂 — not sure yet, mainly because I don't want to compete with other great initiatives, but I'm definitely considering it ## One more thing .... Please — reading this doesn't mean you should start testing whether my network crashes, times out, or triggers Sentry-Flow. I unfortunately had to build this to protect myself and my downstreams. Let's keep the internet safe and working properly, and treat everyone the way you'd want to be treated. Cheers! Peter-Paul **Categories:** FastNetMon Blog, Featured --- ### [See you at RITE 2026!](https://fastnetmon.com/2026/07/13/rite-2026-event-page/) **Published:** July 13, 2026 **Author:** FastNetMon **Content:** **RITE 2026 – Romanian Internet Technologies Event** is an annual meeting of Romania's Internet and telecommunications community, bringing together ISPs, network operators, technology providers and Internet infrastructure professionals to exchange knowledge and discuss the technologies and challenges shaping today's Internet. The 2026 edition focuses on “The Trustworthy Internet: Resilience, Identity and Intelligent Infrastructure.” FastNetMon will be attending RITE 2026 on October 27, 2026, at the Sheraton Hotel in Bucharest, Romania, and we're looking forward to connecting with the Romanian networking community. **Virgil Truica, Head of Sales at FastNetMon, will present “DDoS Botnets Today.”** His session will explore how modern DDoS botnets are evolving, the attack patterns network operators are seeing today, and the challenges of detecting and mitigating large-scale attacks. With Internet resilience and security at the centre of this year's discussions, RITE is a great opportunity to exchange practical experience around DDoS protection and the challenges facing today's networks. If you're attending RITE 2026 in Bucharest, book a meeting with the FastNetMon team, join Virgil's presentation, and come talk to us about DDoS detection and mitigation, network traffic visibility and network security. **Event:** RITE 2026 – Romanian Internet Technologies Event **Date:** October 27, 2026 **Location:** Sheraton Hotel, Platinum Grand Ballroom, Bucharest, Romania **FastNetMon speaker:** Virgil Truică, Head of Sales **Presentation:** DDoS Botnets Today See the [official RITE 2026 website](https://rite.org.ro/en/) for registration, the agenda, and the latest event information. **Categories:** Upcoming Events --- ### [Introducing FastACL Community: Open-Source DDoS Scrubbing](https://fastnetmon.com/2026/09/25/introducing-fastacl-community-open-source-ddos-scrubbing/) **Published:** September 25, 2026 **Author:** FastNetMon **Content:** For more than a decade, [FastNetMon Community](https://github.com/pavel-odintsov/fastnetmon) has given network operators an open-source option for high-performance DDoS detection. Today, we’re extending that approach from **detecting attacks to filtering them**. **We are proud to announce FastACL Community**, an open-source packet filtering engine for FD.io VPP, built to deliver DDoS filtering at exceptionally high packet rates and throughput. **Performance has been a core focus from the start. In our testing on a single AMD EPYC 7742-based platform, FastACL achieved 270 Mpps with 64-byte packets and full 400 Gbps throughput (2 × 200 GbE) with medium-sized packets.** FastACL runs inline, enforcing filtering rules to drop identified attack traffic while forwarding permitted traffic. Combined with FastNetMon—or another detection and orchestration system—FastACL provides the filtering data plane for building an open-source DDoS mitigation pipeline on commodity hardware. > We believe FastACL Community is the **world’s first open-source DDoS scrubbing data plane built for commodity hardware.** ## From detection to scrubbing FastNetMon Community already provides the detection side of the equation: analysing network traffic, identifying attacks in real time, and triggering external mitigation actions such as BGP announcements. FastACL Community brings that same open-source approach to the **mitigation data plane**. The concept is simple: ![](https://fastnetmon.com/wp-content/uploads/2026/09/FastACL-diagram-edited-1024x477.png)**FastACL Community DDoS mitigation workflow:** FastNetMon or another detection engine identifies a DDoS attack and provides filtering rules to FastACL. FastACL applies the rules inline, drops identified attack traffic, and forwards permitted traffic through the network.--- Under the hood, FastACL is implemented as a native FD.io VPP plugin and is designed for high-volume inline packet processing on commodity servers. Our development has focused on scaling both packet-processing performance and filtering capacity, **from hundreds of millions of packets per second and hundreds of gigabits of traffic to configurations with up to one million active filtering rules.** ## FlowSpec-style filtering for IPv4 and IPv6 FastACL Community implements all **12 matching components defined by the RFC 8955/8956 BGP FlowSpec model**, for both IPv4 and IPv6. This includes filtering based on source and destination prefixes, protocols, ports and port ranges, ICMP fields, TCP flags, packet length, DSCP, and fragmentation flags. It also provides **permit and drop actions, per-rule and aggregate counters, packet sampling, and both CLI and binary API control**. In other words, FastACL provides the high-performance filtering engine while leaving operators in control of how attacks are detected and how mitigation policies are generated. ## Building an open DDoS mitigation stack For us, FastACL Community represents an important next step for the FastNetMon open-source ecosystem. FastNetMon Community made it possible to build high-performance DDoS detection without relying entirely on proprietary systems. With FastACL Community, we’re bringing that philosophy to the system that actually processes and filters attack traffic. FastACL Community is released under the **Apache License 2.0** and is available now on GitHub. **GitHub:**[ https://github.com/FastNetMon/FastACL-Community](https://github.com/FastNetMon/FastACL-Community) **Categories:** FastNetMon Blog, Featured, Press & Newsroom **Tags:** product update --- ### [DDoS News: FBI Disrupts NightmareStresser DDoS-for-Hire Service in Operation PowerOFF](https://fastnetmon.com/2026/09/22/ddos-news-fbi-disrupts-nightmarestresser-ddos-for-hire-service-in-operation-poweroff/) **Published:** September 22, 2026 **Author:** FastNetMon **Content:** The FBI has seized internet domains associated with **NightmareStresser**, a long-running [DDoS-for-hire service](https://fastnetmon.com/2025/04/10/ddos-booters-and-ip-stressers-explained-by-experts/) accused of enabling hundreds of thousands of actual or attempted attacks worldwide. The action is part of **Operation PowerOFF**, an international law-enforcement effort targeting criminal DDoS-for-hire services. [According to the U.S. Department of Justice](https://www.justice.gov/usao-ak/pr/fbi-seizes-ddos-hire-domains-part-continuing-district-alaska-crackdown-booter-and), NightmareStresser was used to launch **hundreds of thousands of actual or attempted [DDoS attacks](https://fastnetmon.com/2026/09/21/ddos-explained-what-is-a-distributed-denial-of-service-attack/) against victims worldwide since 2022**. The seizure is another win in the effort to make commercial DDoS services harder to operate and access. However, the DOJ announcement specifically confirms the seizure of NightmareStresser's **internet domains**. It does not announce arrests or the seizure of the underlying attack infrastructure. ## NightmareStresser disruption at a glance - **Service:** NightmareStresser - **Type:** DDoS-for-hire / booter / stresser - **Action:** Internet domains seized - **Agencies:** FBI and Royal Canadian Mounted Police - **Operation:** Operation PowerOFF - **Reported activity:** Hundreds of thousands of actual or attempted DDoS attacks since 2022 - **Arrests announced:** None - **Attack infrastructure seized:** Not announced ## What is NightmareStresser? **NightmareStresser is a DDoS-for-hire service, also known as a booter or stresser, that allowed customers to purchase access to DDoS attack capabilities.** Services like this lower the barrier to launching a DDoS attack. A customer does not need to build a [botnet](https://fastnetmon.com/2025/06/18/anatomy-of-a-botnet/) or operate attack infrastructure directly. Instead, the service provides an interface through which attacks can be purchased and launched. The DOJ says booter services continue to proliferate because they provide a low barrier to entry for cybercriminal activity. NightmareStresser appears to have operated at significant scale. Beyond the hundreds of thousands of actual or attempted attacks cited by the DOJ, some independent sources estimate that the service approached **one million registered users by 2025** and was capable of generating **thousands of attacks per hour**. Earlier independent research also cited more than **566,000 registered users and 52 dedicated servers in 2023**. These additional figures are estimates reported by third-party cybersecurity sources rather than numbers confirmed in the DOJ's latest announcement. ## What did the FBI actually seize? The DOJ announced the **court-authorized seizure of internet domains associated with NightmareStresser**. Reporting identifies the affected domains as: - `nightmare-stresser[.]com` - `nightmarestresser[.]org` The domains now display FBI seizure notices. Removing established domains disrupts access to a DDoS-for-hire service and forces its operators to rebuild the connection with their customers. It can also create additional costs, operational friction and investigative opportunities. However, a **domain seizure is not the same as dismantling the underlying DDoS infrastructure**. A simplified DDoS-for-hire service might look like this: ![](https://fastnetmon.com/wp-content/uploads/2026/09/Diagram-How-a-DDoS-for-Hire-Service-Works-1024x576.png)Seizing the domain disrupts an important part of that chain. The DOJ announcement does not state that NightmareStresser's backend servers, databases, payment infrastructure or systems used to generate attack traffic were seized. No arrests were announced as part of this specific action. ## What is Operation PowerOFF? **Operation PowerOFF is an ongoing international law-enforcement effort targeting DDoS-for-hire infrastructure, operators and users.** The NightmareStresser seizure was conducted by the FBI Anchorage Field Office in coordination with the **Royal Canadian Mounted Police**. According to the DOJ, previous investigations involving prosecutors and investigators in Anchorage and Los Angeles over the past eight years have resulted in **12 defendants being charged** for facilitating DDoS-for-hire services and the seizure of **more than 100 associated domains**. This sustained pressure matters. Even when an individual action does not eliminate all of a service's infrastructure, repeated domain seizures, investigations, infrastructure disruption and arrests make DDoS-for-hire platforms more difficult and risky to operate. ## Could NightmareStresser return? It is too early to know whether NightmareStresser will permanently disappear. If its operators retain the underlying infrastructure, they could potentially attempt to move the service to new domains. Independent reporting indicates that a domain associated with NightmareStresser was included in an earlier U.S. enforcement action in **2022**, after which the service continued operating. But rebuilding isn't without cost. Operators need to establish new domains and communication channels, reconnect with customers and potentially expose additional infrastructure in the process. The latest action should therefore be viewed as part of a broader strategy of **increasing the cost, friction and risk of operating DDoS-for-hire services**. **Categories:** FastNetMon Blog **Tags:** DDoS News --- ### [DDoS Explained: What Is a Distributed Denial of Service Attack?](https://fastnetmon.com/2026/09/21/ddos-explained-what-is-a-distributed-denial-of-service-attack/) **Published:** September 21, 2026 **Author:** FastNetMon **Content:** A **DDoS (Distributed Denial of Service) attack** is a cyberattack that attempts to make a website, server, network, or online service unavailable by overwhelming it with traffic or requests from many sources at the same time. Unlike attacks designed to gain unauthorised access or steal data, a DDoS attack primarily targets **availability**. The goal is to consume enough bandwidth, network capacity, or computing resources that legitimate users can no longer access the targeted service normally. In simple terms, a DDoS attack is like creating an artificial traffic jam around an online service: the service may still be running, but legitimate users cannot reliably reach it. ## DDoS explained in 30 seconds A typical DDoS attack works like this: 1. **An attacker controls or coordinates many Internet-connected devices.** 2. **Those devices send traffic or requests toward the same target.** 3. **The attack consumes bandwidth or infrastructure resources.** 4. **Legitimate traffic has to compete with the attack traffic.** 5. **The targeted service becomes slow, unstable, or unavailable.** The word **distributed** is important. Instead of the attack coming from a single source, traffic can originate from thousands of devices, IP addresses, and networks at once. This makes DDoS attacks more difficult to stop with simple source-based blocking. Watch this video and learn what a DDoS attack is, how they work and how to defend against one. ## How does a DDoS attack work? Many DDoS attacks use a **[botnet](https://fastnetmon.com/2025/06/18/anatomy-of-a-botnet/)** — a collection of compromised computers, servers, routers, IoT devices, or other Internet-connected systems that an attacker can remotely control. The owners of these devices may not know that their systems are participating in an attack. When the attack begins, the compromised devices simultaneously generate traffic toward the target. Depending on the attack technique, the objective may be to: - Saturate the target's Internet bandwidth - Overwhelm routers, firewalls, or load balancers - Exhaust connection tables or other infrastructure resources - Consume server CPU or memory - Overload a website, API, or application with requests Some DDoS attacks also use **reflection and amplification**, where third-party Internet services are abused to send large amounts of traffic toward the victim. Regardless of the technique, the objective is the same: **consume resources needed by legitimate users until the service becomes degraded or unavailable.** ![](https://fastnetmon.com/wp-content/uploads/2026/09/how-does-a-ddos-attack-works-diagram-1024x576.png)Diagram explaining how a DDoS attack works: compromised devices generate distributed attack traffic that overwhelms the target, causing slowdowns, errors or outages for legitimate users.## DoS vs. DDoS: what's the difference? The main [difference between DoS and DDoS](https://fastnetmon.com/2025/04/16/ddos-dos-rdos-explained/) is the number and distribution of systems generating the attack. | DoS attack | DDoS attack | |---|---| | Denial of Service | Distributed Denial of Service | | Usually originates from one or relatively few sources | Originates from many distributed sources | | Often easier to identify and block | Usually harder to block using source-based filtering | | Limited by the resources of the attacking system | Can combine the resources of many devices | A **DoS attack** attempts to deny access to a service. A **DDoS attack** does the same thing using distributed sources. ## What are the main types of DDoS attacks? DDoS attacks are commonly divided into **three broad categories: volumetric attacks, protocol attacks, and application-layer attacks**. ### 1. Volumetric attacks A volumetric DDoS attack attempts to consume the available bandwidth between a target and the Internet. Common examples include: - UDP floods - ICMP floods - DNS amplification attacks - NTP amplification attacks These attacks are often measured in **bits per second (bps)**, such as Gbps or Tbps. ### 2. Protocol attacks Protocol attacks target network protocols or the infrastructure responsible for processing connections. Instead of relying only on bandwidth, they may attempt to exhaust resources such as connection tables or packet-processing capacity. A **TCP SYN flood** is a common example. These attacks are often associated with high **packets-per-second (pps)** or connection rates. ### 3. Application-layer attacks Application-layer attacks target applications and services, typically at **Layer 7 of the OSI model**. For example, an attacker may generate large numbers of HTTP requests toward a website or API. Individual requests may appear legitimate while collectively consuming substantial application or backend resources. An **HTTP flood** is a common example of an application-layer DDoS attack. These three categories are a good starting point to understand the types of DDoS attacks, but if you want to dig deeper, here is a [full taxonomy of DDoS attacks](https://fastnetmon.com/2025/07/25/classification-of-ddos-attacks-every-modern-ddos-attack-vector-explained/). ## What does a DDoS attack look like in real network traffic? In real network traffic, a DDoS attack often appears as a **sudden and significant deviation from the network's normal traffic baseline**. The example below, captured using **FastNetMon LiveView**, shows how a DDoS attack can appear in network traffic. ![](https://fastnetmon.com/wp-content/uploads/2026/09/What-does-a-DDoS-attack-look-like.png)*Example of DDoS attack traffic illustrated in FastNetMon LiveView, showing a sudden increase above the normal traffic baseline.* Before the attack begins, network traffic remains within its expected range. When the attack starts, traffic rises sharply as packets are directed toward the target. Network operators typically examine several metrics: - **Bits per second (bps):** the amount of bandwidth being consumed - **Packets per second (pps):** the number of packets the network must process each second - **Flows per second (fps):** the rate at which network flows are observed - **Source and destination addresses:** where traffic originates and which systems are targeted - **Protocols and ports:** what types of network traffic are involved A large traffic spike does **not automatically mean DDoS**. Legitimate events can also cause sudden increases in traffic. The important question is whether the traffic represents an abnormal change from the network's expected behavior. This is why understanding the **normal traffic baseline** is important for accurate DDoS detection. ## How can you tell if you're under a DDoS attack? Common indicators of a possible DDoS attack include: - Sudden, unexpected increases in network traffic - Abnormally high packet rates - Large numbers of connections or requests - Significant deviations from normal traffic patterns - Unusual protocols, ports, sources, or destinations - Increased network latency - Packet loss - Websites or APIs becoming slow - Connection timeouts - Complete service outages No single symptom proves that a DDoS attack is taking place. Detection requires **traffic visibility and context** so abnormal activity can be distinguished from legitimate traffic spikes. ## How are DDoS attacks detected and mitigated? DDoS detection starts with monitoring network traffic and identifying behavior that differs significantly from what is expected. Network operators typically collect traffic telemetry using technologies such as: - **NetFlow** - **IPFIX** - **sFlow** - **Packet data** - **Network and routing telemetry** DDoS detection software such as **FastNetMon** analyses this traffic in real time, looking for abnormal traffic volumes, packet rates, and other patterns that may indicate an attack. Once an attack is detected, the next step is **mitigation**: taking action to stop or limit the malicious traffic while minimising the impact on legitimate users. Common DDoS mitigation techniques include: - **[BGP FlowSpec](https://fastnetmon.com/2025/02/10/bgp-flow-spec-for-ddos-mitigation/)** to apply targeted filtering rules - [**BGP Blackhole / RTBH** ](https://fastnetmon.com/2026/01/06/bgp-blackhole-automation-for-ddos-mitigation/)to discard traffic destined for an attacked host or network - **[Traffic redirection](https://fastnetmon.com/2025/08/06/ddos-scrubbing-centre-automation-explained/)** to an external DDoS scrubbing center - **Rate limiting and traffic filtering** - **Firewall or access-control rules** Network operators can also use software such as **FastNetMon to automate the response**. For example, when an attack crosses operator-defined thresholds, FastNetMon can trigger BGP FlowSpec filtering, announce an RTBH route, or redirect traffic toward an external mitigation system. This automation reduces the time between **detecting an attack and beginning mitigation**, which is particularly important during fast-growing volumetric DDoS attacks. Detection and mitigation therefore perform different jobs: **detection identifies and characterizes the attack; mitigation takes action against the malicious traffic.** ## Frequently asked questions about DDoS attacks ### What does DDoS stand for? **DDoS stands for Distributed Denial of Service.** It describes an attack that uses multiple distributed sources to overwhelm a network, server, application, or online service and make it unavailable to legitimate users. ### What is a DDoS attack in simple terms? A DDoS attack overwhelms an online service with traffic or requests from many sources at once. The resulting overload can prevent legitimate users from accessing the service. ### What are the three main types of DDoS attacks? The three broad categories are: 1. **Volumetric attacks** — consume network bandwidth 2. **Protocol attacks** — exhaust network or infrastructure resources 3. **Application-layer attacks** — overwhelm applications or services with requests Real-world attacks can combine techniques from more than one category. ### Does a DDoS attack steal data? A DDoS attack does **not inherently steal data**. Its primary objective is to disrupt the availability of a service. However, organizations should still investigate DDoS incidents carefully rather than assume that denial of service is the only malicious activity taking place. ### Can a firewall stop a DDoS attack? A firewall can help mitigate some DDoS attacks, but **a firewall alone cannot provide complete DDoS protection**. If an attack saturates the Internet connection before traffic reaches the firewall, filtering the traffic at the firewall cannot restore the lost bandwidth. Firewalls can also become targets themselves when attacks exhaust connection tables or processing resources. ### Can DDoS attacks be prevented? It is generally not possible to prevent attackers from sending malicious traffic toward an Internet-facing service. Instead, DDoS protection focuses on **detecting attacks quickly, filtering or absorbing malicious traffic, and maintaining availability for legitimate users.** **Categories:** FastNetMon Blog **Tags:** basics, Network Security Insights --- ### [Why do DDoS attacks happen? Top motivations behind DDoS cybercrime](https://fastnetmon.com/2025/08/27/why-do-ddos-attacks-happen-top-motivations-behind-ddos-cybercrime/) **Published:** August 27, 2025 **Author:** FastNetMon **Content:** We often talk about [how DDoS attacks happen](https://fastnetmon.com/2025/08/27/why-do-ddos-attacks-happen-top-motivations-behind-ddos-cybercrime/) — via botnets, traffic floods, vectors — but rarely do we ask the more human question: why? The truth is, behind every DDoS attack is a motive. Sometimes it's financial. Sometimes it’s political. And sometimes it’s just personal. Here’s a closer look at the most common reasons these attacks occur. ### **According to industry reports** Several industry reports indicate growth in both the number and volume of DDoS attacks, underscoring the expanding scale of the threat. In many cases, however, the attacker is unknown, not publicly reported, or the victim chooses not to disclose details for security reasons. Data on the specific motivations behind attacks is limited, but one recent industry report\* was able to analyse self-reported causes from the victims: - 63% said ‘competitor’ was the culprit (common in gaming, gambling, crypto sectors) - 21% attributed the attack to state-level or state-sponsored actors - 5% each blamed disgruntled customers - 5% reported a self-caused bug (e.g. accidental self-inflicted DDoS) - 5% said they were a victim of an RDDoS attack (extortionist demanding a ransom) ### **Major motivations behind DDoS explained** #### **1. Competitive sabotage** In industries like[ gaming](https://fastnetmon.com/2025/06/05/ddos-attack-targets-byond-game-engine-in-push-to-open-source-it/), crypto services, or[ online betting](https://fastnetmon.com/2025/04/30/record-size-ddos-batters-betting-site-during-a-major-nhl-event/), rivals or insiders launch DDoS at the worst time possible — during product launches, tournaments, or promotional events. This tactic targets availability, reputation, and revenue, and is reported in over 60% of identifiable cases. FastNetMon has documented similar patterns in its coverage of[ infrastructure-targeted incidents](https://fastnetmon.com/2025/06/23/internet-under-fire-analysis-of-the-record-breaking-7-3-tbps-ddos-attack/) that disrupted trust in emerging platforms. #### **2. Extortion (Ransom DDoS, “RDDoS”)** Attackers increasingly pair threats with demands: pay us or face larger, prolonged disruption later. Industry reports note a significant rise in ransom-style threats. These campaigns often follow successful test floods that reveal defensive gaps and are most effective against organisations under time pressure. #### **3. Geopolitical or ideological campaigns** State-linked groups or activists often deploy DDoS as a digital protest tool — to disrupt[ critical infrastructure](https://fastnetmon.com/2025/07/29/svf-botnet-campaign-targets-linux-ssh-servers-using-discord-based-c2/),[ media outlets](https://fastnetmon.com/2025/07/23/hungarian-police-arrest-alleged-ddos-attacker-targeting-ipi-and-independent-media/), or financial services in specific countries. Industry analysis found that 21% of identified cases were tied to political operations or[ state-sponsored cyber activity](https://fastnetmon.com/2025/05/19/ddos-in-geopolitics-when-network-traffic-becomes-a-digital-weapon/). FastNetMon’s recent reporting on the[ Monero-aligned Qubics takeover attempt](https://fastnetmon.com/2025/08/05/ddos-or-drama-qubics-monero-takeover-attempt-sparks-controversy/) illustrates how such campaigns may mix ideology with spectacle, aiming to destabilise or provoke rather than generate direct profit. #### **4. Hacktivism or protest** Motivated by ideology or protest, hacktivist groups like[ NoName(057)16](https://fastnetmon.com/2025/05/08/50-dutch-public-services-flooded-by-noname05716-in-one-week-as-a-punishment/) launch DDoS campaigns against government agencies, universities, or corporations they oppose. These campaigns may be publicly claimed or shrouded in anonymity, making attribution difficult, but their goal is primarily disruption rather than technical outcome. #### **5. Personal vendettas or trolling** In gaming communities and small-scale environments, DDoS is still used as a revenge tool. A disgruntled player might knock a server offline to reset leaderboards or force resignation. These attacks are seldom publicised or traced, with industry reports classifying many as ‘disgruntled user’ cases (~5%). #### **6. Diversion tactics** Malicious actors sometimes launch noisy floods to distract defenders while executing more subtle operations like malware deployment or data theft. These diversion attacks may not reach high volumes and often go unreported, but when investigated, they reveal coordinated campaigns using fake DDoS alarms as cover for real compromise. ### **Understanding attacker motivation: the key to effective defence** Understanding *why* a DDoS attack occurs is as important as knowing *how* it happens. Motivation directly influences the attack’s timing, intensity, and persistence, which in turn determines how organisations should respond. Competitor-driven attacks and ransom-style threats demand rapid detection and strong forensic readiness to minimise business impact. Politically motivated or hacktivist campaigns require a layered defence approach, combining technical mitigation with strategic communication and public response planning. Even low-profile attacks, such as personal vendettas, can cause disruption if left unchecked, making anomaly detection and reputation monitoring essential. By analysing attacker motives, security teams can anticipate patterns, prioritise resources, and tailor defences to specific threats. DDoS has never been a homogeneous problem — it is a spectrum of challenges shaped by human intent. Adapting defences to these motivations is the most effective way to stay one step ahead. --- # **About FastNetMon** FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit <https://fastnetmon.com> --- - Data source: Cloudflare’s 2025 Q2 [DDoS threat report](https://blog.cloudflare.com/ddos-threat-report-for-2025-q2/) **Categories:** FastNetMon Blog **Tags:** basics, Network Security Insights --- ### [Understanding Layer 3 and Layer 4 DDoS attacks](https://fastnetmon.com/2025/09/23/understanding-layer-3-and-layer-4-ddos-attacks/) **Published:** September 23, 2025 **Author:** FastNetMon **Content:** ## What L3 and L4 DDoS attacks are, how they work, and what defenders need to know [DDoS attacks ](https://fastnetmon.com/2026/09/21/ddos-explained-what-is-a-distributed-denial-of-service-attack/)at Layers 3 and 4 (the Network and Transport layers) are some of the most common and disruptive seen on the public internet. While often lumped together, they behave differently, and defending against them requires understanding how they work. Here’s a breakdown of both layers, common attack types, and tips for mitigation based on real-world experience. ### What is a Layer 3 DDoS attack? Layer 3 (Network Layer) handles IP routing and delivery between networks. Attacks at this layer typically aim to overwhelm routing infrastructure or links, making services unreachable. **Common Layer 3 attack types:** - **ICMP floods**: Attackers send high volumes of ICMP (ping) packets to consume bandwidth or exhaust CPU resources on routers and firewalls. - **IP fragmentation attacks**: Send malformed or overlapping IP fragments to confuse reassembly logic in devices, causing drops or crashes. - **Smurf attacks** (less common today): Exploit broadcast addresses to amplify ICMP traffic via spoofed source IPs. **The impact:** - Saturated links - Router CPU exhaustion - Dropped connections and full outages ### What is a Layer 4 DDoS attack? Layer 4 (Transport Layer) deals with protocols like TCP and UDP that enable communication between devices. Layer 4 DDoS attacks typically exploit open ports or connection states to drain server or firewall resources. **Common Layer 4 attack types:** - **UDP floods**: High-rate, stateless floods targeting common ports (e.g. DNS/53, NTP/123). Easy to spoof and amplify. - **TCP SYN floods**: Exploit the TCP handshake by sending floods of SYN packets and never completing the connection. Servers wait and exhaust available sessions. - **TCP RST/ACK floods**: Abuse legitimate TCP response mechanisms to clog state tables or confuse session tracking logic. **The impact:** - Exhausted port listeners or connection queues - High CPU on stateful firewalls - Service latency, resets, or full failure ### How L3 and L4 compare to L7 Layer 7 (Application Layer) DDoS attacks target specific applications (like HTTP, DNS, or APIs) with the goal of exhausting resources with what appears to be legitimate traffic. While L7 attacks are more targeted, L3 and L4 floods are often more volumetric, and are the types of attacks that most often trigger automatic blackholing, BGP-based filtering, or upstream rate-limiting. FastNetMon focuses on detecting and mitigating Layer 3 and Layer 4 attacks in real time -long before they reach the application layer. ### Detection & mitigation: what works Layer 3 and 4 attacks often require mitigation within seconds to avoid full service degradation. Some effective strategies include: **RTBH (Remote Triggered Black Hole)** - Used for fast, coarse null-routing of attacked IPs - Great for link protection during volumetric floods **BGP Flow Spec** - Enables granular, rule-based filtering on routers - Useful for filtering based on specific protocol, port, and packet fields (e.g. UDP/53 floods) **Traffic Analysis & Thresholding** - Monitoring NetFlow/sFlow/IPFIX lets you catch anomalies in volume, source diversity, and protocol usage - Smart thresholding reduces false positives and triggers appropriate mitigation in real time ### Key Differences: Layer 3 vs Layer 4 | Feature | Layer 3 Attacks | Layer 4 Attacks | |---|---|---| | Protocols Used | ICMP, IP fragments | TCP, UDP | | Attack Goal | Overwhelm network/routing | Exhaust transport/session layers | | Detection Signals | Packet rate, ICMP spikes | Port targeting, TCP flag spikes | | Typical Mitigation | RTBH, Flowspec (IP-based) | Flowspec (port-based), state handling | | Spoofing Feasibility | High | High (esp. UDP floods) | | Impact Radius | Network-wide | Targeted but infrastructure-heavy | Layer 3 and Layer 4 DDoS attacks remain the bread and butter of volumetric threats today. While not as complex as application-layer attacks, they’re faster, harder to spot without flow visibility, and can take entire services offline in under a minute. If you're running edge infrastructure, hosting services, or operating a transit network, real-time detection and automated mitigation for L3/L4 threats isn't optional; it’s operational hygiene. --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit <https://fastnetmon.com> **Categories:** FastNetMon Blog **Tags:** basics, Network Security Insights --- ### [DDoS booters and IP stressers explained by experts](https://fastnetmon.com/2025/04/10/ddos-booters-and-ip-stressers-explained-by-experts/) **Published:** April 10, 2025 **Author:** FastNetMon **Content:** ## "DDoS for hire" - how anyone can pay to take down a website You don’t need to be a hacker to launch a cyberattack anymore. These days anyone with £20 and a few minutes can [rent a tool](https://fastnetmon.com/2025/04/30/most-infamous-ddos-booter-services-and-user-consequences/) online and knock a website offline. These services are called DDoS booters, and while they may sound like gaming slang, the impact they cause is very real. **What’s a DDoS attack?** [A DDoS (Distributed-Denial-of-Service) attack](https://fastnetmon.com/2026/09/21/ddos-explained-what-is-a-distributed-denial-of-service-attack/) floods a website or service with so much junk traffic that it slows to a crawl or crashes completely. It’s like hundreds of people ringing your doorbell non-stop, and you can’t hear the real visitor. These attacks are often launched using botnets—hijacked devices like routers, cameras, or poorly secured servers. The result? A flood of traffic the target never asked for. **What are Booters and IP Stressers?** IP stresser is a legitimate service used to test how well a system handles heavy traffic. An IT team or a network engineer might run one against their own network to check for weak spots. You can think of it as a stress test for your own environment - using IP stressers is a common practice in cybersecurity. A booter, on the other hand, is the illegal version of a stresser, designed to attack someone else’s system. While the functionalities of booter services are very similar to those of stressers, the aim is very different: booters are used as DDoS-for-hire. These days, booter services are [easy to find](https://fastnetmon.com/2025/04/30/most-infamous-ddos-booter-services-and-user-consequences/), they are slickly packaged like any legitimate digital service, and they are incredibly cheap. Some offer subscription plans, tutorials, and even live support. **Who’s using booters?** Booters are used mostly by low-skill cyber offenders, often called ‘script kiddies,’ people with limited knowledge but access to ready-made attack tools. More experienced attackers may use booters too, sometimes as a distraction while launching more targeted hacks. Booters often disguise their origin using proxy servers and spoofed IP addresses, making it hard to trace the attacker. Payments are made through crypto or temporary accounts, further muddying the trail. **What types of attacks are launched with booters?** Booters can carry out a wide range of DDoS attacks, including: - Volumetric floods that jam bandwidth - Application-layer attacks that target login or search functions - Reflection and amplification tricks that bounce data off third-party servers - IoT-based attacks powered by hacked smart devices **Is using a DDoS booter service illegal?** Yes. Using or offering a DDoS booter is illegal in most countries. Authorities like the FBI and Europol regularly take these sites down, but they keep reappearing. Launching a DDoS attack is a crime, regardless of how it is conducted or who is running the booter service. **How to defend against attacks conducted with booter services?** 1. Monitor traffic for anomalies 2. Use up-to-date hardware and software 3. Enable rate limiting 4. Work with a DDoS defence provider like FastNetMon 5. Never pay a ransom; it only encourages more attacks Booters lower the barrier to cybercrime, making DDoS attacks as easy as buying a streaming subscription. We must understand how they work so we can defend against them. ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit <https://fastnetmon.com> **Categories:** FastNetMon Blog **Tags:** basics --- ### [Botnets explained: What is a botnet and how do they work?](https://fastnetmon.com/2025/06/18/anatomy-of-a-botnet/) **Published:** June 18, 2025 **Author:** FastNetMon **Content:** # Botnet Explained: What Is a Botnet and How Does It Work? A **botnet is a network of Internet-connected devices that have been compromised and can be remotely controlled as a group**. Each infected device is called a **bot**, while the person or group controlling the network is commonly known as a **botmaster**, **bot herder,** or **Botnet Operator**. Botnets can include computers, servers, routers, cameras, and other Internet of Things (IoT) devices. Attackers use them to perform coordinated activities at scale, including **[DDoS attacks](https://fastnetmon.com/2026/09/21/ddos-explained-what-is-a-distributed-denial-of-service-attack/), spam campaigns, credential attacks, malware distribution, and other malicious activity**. In a Distributed Denial of Service (DDoS) attack, a botnet can instruct thousands of compromised devices to send traffic toward the same target simultaneously, potentially overwhelming the target's network or infrastructure. ## Botnet explained in 30 seconds A botnet typically works in five stages: 1. **Infection:** An attacker compromises Internet-connected devices using malware, weak credentials, software vulnerabilities, or other security weaknesses. 2. **Connection:** The infected devices connect to the botnet's command-and-control infrastructure or other bots in the network. 3. **Control:** The botmaster sends instructions to compromised devices. 4. **Execution:** The bots perform coordinated activities such as generating DDoS traffic, sending spam, or scanning for vulnerable systems. 5. **Expansion:** Some botnets continuously search for and infect additional devices, allowing the network to grow. The power of a botnet comes from **scale and distribution**. An attacker can coordinate large numbers of devices across different networks and geographical locations as if they were a single system. ## How does a botnet work? A botnet consists of compromised devices that can receive and execute instructions from an attacker. The exact architecture varies, but botnets generally require a way for the attacker to communicate with the infected devices. This is known as **command and control (C2 or C&C)**. Two common botnet architectures are: - **Centralized command and control:** Bots communicate with one or more central servers controlled by the botmaster. This makes the botnet relatively straightforward to operate, but disrupting the C2 infrastructure can interfere with the botnet. - **Peer-to-peer (P2P):** Bots communicate with each other rather than relying entirely on a central server. This decentralized design can make the botnet more difficult to disrupt. Once connected, infected devices wait for instructions and may continue to function normally from the owner's perspective. ![](https://fastnetmon.com/wp-content/uploads/2025/06/How-does-a-botnet-work-Diagram-of-Botnet-Ingrastructure-1024x683.png)*Example of botnet infrastructure showing how a botmaster can coordinate compromised devices and use them to generate traffic toward a target.*The owner of a compromised router, camera, server, or computer may therefore have no obvious indication that their device is participating in a botnet. ## How do devices become part of a botnet? Attackers build botnets by compromising large numbers of Internet-connected devices. Common infection methods include: - **Default or weak passwords** - **Unpatched software vulnerabilities** - **Outdated device firmware** - **Malware and malicious downloads** - **Phishing and social engineering** - **Exposed Internet-facing services** - **Automated scanning for vulnerable devices** IoT devices such as routers and Internet-connected cameras are particularly attractive targets because they are widely deployed and may operate for years without firmware updates or security maintenance. Some botnet malware also attempts to spread automatically. After compromising one device, it can scan the Internet for other vulnerable systems and attempt to infect them. This allows a botnet to grow with relatively little manual involvement from its operator. ## What are botnets used for? Botnets can perform many types of malicious activity at scale. Common uses include: - **DDoS attacks:** Flooding networks, websites, or online services with traffic - **Spam and phishing:** Sending large volumes of malicious email or messages - **Credential attacks:** Automating login attempts against online accounts - **Malware distribution:** Delivering additional malicious software - **Click and advertising fraud:** Generating artificial clicks or traffic - **Cryptocurrency mining:** Using compromised computing resources to mine cryptocurrency - **Proxying malicious traffic:** Routing an attacker's activity through compromised devices - **Network scanning:** Searching the Internet for additional vulnerable systems Not every botnet is therefore a **DDoS botnet**. DDoS is one of several ways attackers can use a network of compromised devices. ## How are botnets used in DDoS attacks? Botnets are particularly effective for **Distributed Denial of Service attacks** because they allow an attacker to generate traffic from many sources simultaneously. During a botnet-powered DDoS attack: 1. The botmaster sends an attack command to the botnet. 2. Large numbers of compromised devices begin sending traffic or requests toward the target. 3. The combined traffic consumes network bandwidth or infrastructure resources. 4. Legitimate users have to compete with the attack traffic. 5. The targeted service may become slow, unstable, or completely unavailable. Depending on the botnet and attack technique, bots may generate large numbers of **TCP packets, UDP packets, or application-layer requests**. Because attack traffic is distributed across many devices, networks, and locations, blocking a single source IP address does little to stop the overall attack. This distributed structure is what makes botnets particularly useful for large-scale DDoS attacks. ## What are some examples of botnets? Several botnets have become well known because of their scale or their use in DDoS attacks. Examples include: - **Mirai** - **Mēris** - **Reaper** - **Aquabot** - **AIRASHI** **Mirai** is one of the best-known examples of an IoT botnet. It spread by compromising Internet-connected devices using common or default credentials, demonstrating how large numbers of poorly secured devices could be coordinated for powerful DDoS attacks. Botnet families and variants continue to change, but many rely on the same underlying opportunity: **large numbers of vulnerable Internet-connected devices that attackers can compromise and remotely control.** ## Why are botnets difficult to stop? Botnets can be difficult to eliminate because their infrastructure is distributed across many devices and networks. Several factors contribute to their persistence: - Large numbers of vulnerable devices remain connected to the Internet. - Compromised devices may continue working normally, so owners do not realize they are infected. - Botnet malware can automatically scan for new victims. - Peer-to-peer architectures can reduce reliance on centralized infrastructure. - Botnet source code can be copied, modified, and reused. - Attackers can rebuild infrastructure after a disruption. - Botnets can be rented or sold to other attackers. This means taking down one command-and-control server or group of bots does not necessarily eliminate the underlying malware or prevent new variants from appearing. ## How can botnets be detected and stopped? Defending against botnets requires action at both the **device and network level**. For device owners, basic security measures can reduce the likelihood of infection: - Change default usernames and passwords. - Install software and firmware updates. - Disable unnecessary Internet-facing services. - Use network segmentation where appropriate. - Remove or replace devices that no longer receive security updates. At the network level, operators can monitor traffic for signs of compromised devices or coordinated attacks. Potential indicators include: - Connections to known malicious infrastructure - Unusual DNS activity - Unexpected outbound connections - Abnormal scanning behavior - Sudden increases in packets or traffic - Large numbers of devices exhibiting similar traffic patterns During a botnet-powered DDoS attack, network operators can use DDoS detection systems such as **FastNetMon** to analyze traffic in real time and identify abnormal traffic patterns. Once an attack is detected, mitigation can be automated using techniques such as **BGP FlowSpec, BGP blackholing (RTBH), or traffic redirection to a DDoS scrubbing center**. ## Frequently asked questions about botnets ### What does botnet mean? The word **botnet** combines the words **bot** and **network**. It describes a network of compromised devices that can be remotely controlled and coordinated. ### What is a bot in a botnet? A **bot** is an individual device that has been compromised and added to a botnet. Bots may include computers, servers, routers, cameras, and other Internet-connected devices. Compromised devices in a botnet are also sometimes called **zombies**. ### What is a botmaster? A **botmaster**, also called a **bot herder**, is the person or group that controls a botnet and issues instructions to its compromised devices. ### Are all botnets used for DDoS attacks? No. **DDoS is only one use for a botnet.** Botnets can also be used for spam, phishing, credential attacks, malware distribution, advertising fraud, cryptocurrency mining, proxying malicious traffic, and other automated activities. ### What is a DDoS botnet? A **DDoS botnet** is a network of compromised devices used to generate a Distributed Denial of Service attack. The botmaster instructs many bots to send traffic or requests toward the same target simultaneously. The combined traffic can overwhelm the target's bandwidth, network infrastructure, or application resources. ### Can a device be part of a botnet without its owner knowing? Yes. Botnet malware often attempts to operate without disrupting the device's normal functions. A compromised router, camera, server, or computer may therefore continue working normally while communicating with botnet infrastructure or participating in malicious activity in the background. **Categories:** FastNetMon Blog **Tags:** Botnets --- ### [FastNetMon Advanced 2.0.384](https://fastnetmon.com/2026/09/16/fastnetmon-advanced-2-0-384/) **Published:** September 16, 2026 **Author:** FastNetMon **Content:** **Release date:** 16 September, 2026 **Version:** 2.0.384 FastNetMon Advanced 2.0.384 introduces a new Linux psample traffic collection plugin, multi-endpoint flow forwarding, enhanced BGP configuration for hostgroup announcements, and additional Prometheus monitoring capabilities. This release also improves web callback handling, expands API functionality, simplifies ASN database updates, and includes multiple packaging, CLI, and reliability fixes. Changes: - Improved Debian and Ubuntu packages by adding installed size and homepage metadata, correcting license information, and fixing the package maintainer email - Added a new plugin capable of reading traffic from the Linux psample facility - Deprecated Debian 11 - Added HTTP 200 and 201 as successful response codes for web callback queries - Added Prometheus metrics to track successful and failed web callback calls: `fastnetmon_web_callback_calls_total` and `fastnetmon_web_callback_calls_failed` - Fixed the path used by `sudo fcli show asn_networks xxx` to use `/var/lib/fastnetmon` instead of the legacy `/var/cache/fastnetmon` location - Marked `Slack_notifications_url` and `Telegram_notifications_bot_token` as sensitive fields - Added more detailed diagnostics when a TCP connection for the flow forwarder cannot be established - Added support for sending traffic to multiple endpoints using the `flow_forwarder` capability - Refactored packet forwarding logic into a dedicated function to avoid code duplication - Fixed missing `fastnetmon_host_traffic_flows` section in the Prometheus endpoint - Added support for controlling AS\_PATH for total hostgroup announcements using global `gobgp_as_path_hostgroup_networks_ipv4` and `gobgp_as_path_hostgroup_networks_ipv6` configuration options - Added per-hostgroup `bgp_as_path_hostgroup_networks_ipv4` and `bgp_as_path_hostgroup_networks_ipv6` configuration options to control AS\_PATH for total hostgroup announcements - Added support for the `include_all_fields` flag for the `/api/v2/fields/main` endpoint to expose hidden fields - Added web callback notifications for total hostgroups - Added logic to download the ASN database directly from FastNetMon without relying on `fill_dictionaries` - Added logic to create `/var/lib/fastnetmon` for Red Hat family distributions - Upgraded `fcli` to address a bug that limited query size to 5000 bytes [FastNetMon Advanced documentation](https://fastnetmon.com/docs-fnm-advanced/) [View this release on GitHub](https://github.com/FastNetMon/fastnetmon-advanced-releases/releases/tag/v2.0.384) **Categories:** Releases --- ### [Welcome Denys Haryachyy to the FastNetMon Team](https://fastnetmon.com/2026/09/14/welcome-denys-haryachyy-to-the-fastnetmon-team/) **Published:** September 14, 2026 **Author:** FastNetMon **Content:** We’re pleased to welcome **Denys Haryachyy** to FastNetMon as our **Senior SDN Software Engineer**. Denys brings more than 20 years of experience in high-performance networking, software-defined networking, and data plane development, with deep expertise in **VPP, DPDK, C, and AF\_XDP**. Throughout his career, Denys has worked on demanding networking challenges where packet-processing performance, scalability, and reliability are critical. His previous work includes significant contributions at VyOS Networks and 46 Labs, where he worked on integrating VPP as a high-performance data plane and extending its capabilities for advanced L2 and L3 networking. ### Building the next generation of DDoS mitigation at FastNetMon At FastNetMon, Denys is helping us expand our capabilities in high-performance, programmable DDoS mitigation. One of his key areas of focus is a new VPP-based inline DDoS mitigation project, currently operating under the working name **FastACL**. The project is designed to provide high-performance packet filtering directly in the data plane, complementing FastNetMon’s existing DDoS detection and traffic analysis capabilities. The system uses **VPP and DPDK** to implement FlowSpec-style traffic filtering at up to **100 Gbps line rate**, with dual-stack IPv4/IPv6 support and a flexible matching engine covering all 12 traffic-matching components defined by **RFC 8955 and RFC 8956**. Denys is also working on integration with VPP policers, multi-worker processing, the VPP binary API, and CLI tooling — all with the goal of building a scalable mitigation platform capable of handling modern high-volume attacks while giving network operators precise control over how unwanted traffic is filtered. ### From detection to mitigation FastNetMon has long focused on giving network operators the ability to detect DDoS attacks quickly and understand exactly what is happening on their networks. As attack volumes and network capacities continue to grow, efficient mitigation at the data plane becomes increasingly important. Our work on VPP-based inline filtering is part of that evolution. Denys’ extensive experience with VPP, DPDK, SDN, NFV, and high-performance packet processing makes him a great addition to the team as we continue developing these capabilities. We’re very pleased to have Denys at FastNetMon and look forward to building the next generation of DDoS protection together. **Welcome to FastNetMon, Denys**! **Categories:** FastNetMon, FastNetMon Blog, Featured, Press & Newsroom --- ### [NOG.HR Meetup 7 - Event Recap](https://fastnetmon.com/2026/09/10/nog-hr-meetup-7-event-page/) **Published:** September 10, 2026 **Author:** FastNetMon **Content:** Last week, FastNetMon joined the Croatian network operator community in Zagreb for **NOG.HR Meetup 7**, held on September 10 at Algebra Campus. Representing FastNetMon was **Outi Maria Pietilänaho**, who held her very first NOG presentation, sharing insights about the latest developments in the DDoS botnet ecosystem, and current DDoS climate. It was our pleasure to be part of yet another network operator gathering focused on practical knowledge sharing and a great environment to exchange ideas. ## Tracking today’s botnets Outi’s presentation focused on the changing DDoS threat landscape and, in particular, what current botnet activity can tell network operators about the underlying ecosystem and attacks they need to prepare for. The session explored **history and recent DDoS developments, changes in the botnet landscape, and how this influences the network security environment** - connecting what we see in attack data with underlying capacity upgrades the offenders are building today. For those who could not join us in Zagreb, you can find Outi’s slides below. [![](https://fastnetmon.com/wp-content/uploads/2026/09/DDoS-Botnets-HR.NOG-Outi-Pietilanaho-FastnetMon-Presentation-cover-1024x578.png)](https://fastnetmon.com/wp-content/uploads/2026/09/NOG.HR-presentation-10.9.2026-Outi-Pietilanaho-FastNetMon.pdf)As always, the presentation itself was only part of the experience. NOG meetings give us a valuable opportunity to speak directly with operators about what they are seeing in their own environments, from DDoS attacks and botnet activity to traffic visibility, routing security and mitigation strategies. ## From SRv6 to DNS, automation and 5G NOG.HR Meetup 7 covered a wide range of operational networking topics. The day started with an extended **SRv6 tutorial from Oleksiy Semenyaka of RIPE NCC**, giving attendees a deeper technical look at Segment Routing over IPv6 before the main afternoon programme began. Network automation and observability featured prominently after lunch. Robert Petračić from Deutsche Telekom Cloud Services discussed **automating network connectivity with host-based routing**, while Luca Deri of ntop and Vasja Križmančič of Karsolink explored **AS-level network visibility, LLMs and intelligent monitoring**. Ulrich Wisser from ICANN turned the discussion towards one of the Internet’s most fundamental services with a session on **keeping the DNS reliable**. The later sessions moved across several other areas of network operations, including the transition towards **5G Standalone**, discovering vulnerabilities in enterprise software and devices, and automated network speed testing using TR-069 and TR-369. Overall, the day was very interesting, and the conversations continued to late into the night with a nice dinner among some of the participants. ## Thank you, Zagreb A big thank you to the **NOG.HR organisers**, speakers, sponsors and everyone involved in making Meetup 7 possible. We would also like to thank everyone who attended Outi’s presentation, came over to say hello, asked questions, or shared their own experiences with DDoS attacks and network security. Events like NOG.HR are particularly valuable because they bring together the people working directly on Internet infrastructure. They create a space where operators can share what works, discuss what does not, compare experiences and learn from challenges encountered in other networks. Thank you to the Croatian network operator community for having us in Zagreb. We enjoyed being part of NOG.HR Meetup 7 and look forward to crossing paths again — at the next NOG, another networking event, or somewhere out there on the Internet! **Categories:** Events --- ### [NONOG-8 / NIX-2026 - Event Recap](https://fastnetmon.com/2026/09/09/snonog-8-nix-2026-event-page/) **Published:** September 9, 2026 **Author:** FastNetMon **Content:** Last week, FastNetMon joined the Nordic network operator community in Oslo for **[NONOG-8 / NIX-2026](https://nonog.net/events/nonog-8-nix-2026)**, held on September 9 at Oslo Handelsstands Forening. Representing FastNetMon was our founder, **Pavel Odintsov**, who spent the day catching up with network engineers, operators and friends from across the region — and took to the stage to talk about **FastNetMon Community Edition** and open-source DDoS detection. NONOG is exactly the kind of event we enjoy attending. It brings together people who are actually building and operating networks, and the conversations tend to stay firmly grounded in the practical realities of keeping Internet infrastructure running. ## FastNetMon Community: open source DDoS detection Just before lunch, Pavel presented **“FastNetMon Community: open source tool for DDoS Detection.”** The FastNetMon Community project has been at the centre of our story from the beginning, so it is always good to have an opportunity to get back to the open-source side of what we do and discuss it directly with network operators. The presentation looked at FastNetMon Community and how it can be used for DDoS detection, with a focus on the practical requirements of detecting attacks in real networks. For anyone who could not make it to Oslo, you can also watch Pavel's presentation below. As usual, some of the most useful discussions happened after the presentation. We had a chance to talk about DDoS detection and mitigation, network telemetry, BGP, traffic visibility and the operational challenges engineers are dealing with in production. ## A very operational agenda The rest of the NONOG programme covered a broad range of topics, but there was a clear focus on technologies and problems that matter to network operators today. The morning included updates from **NIX and the regional Internet exchange community**, followed by Luca Deri from ntop discussing **AS/IXP traffic observability**. Patrik Fältström from Netnod then looked at **infrastructure resilience in an increasingly adversarial environment**, before Pavel closed the morning programme with his FastNetMon Community presentation. Routing security was another important theme. After lunch, Per Thorsheim discussed Norway's adoption of **RPKI ROAs and ASPA**, while later sessions moved across network automation, optical infrastructure and open-access networks. The day finished on another topic close to us: **BGP**. Donatas Abraitis presented *“A Dietary Plan for BGP (FRRouting)”*, rounding out a programme that had moved from Internet exchanges and observability through resilience, routing security and automation to the protocols underneath it all. That mix is one of the things we appreciate about NOG meetings. The agenda can move across very different layers of Internet infrastructure, but the common thread is usually the same: engineers sharing what they have learned from operating real networks. ## An unusual day in Oslo This particular NONOG also took place on a significant and sombre day for Norway. September 9 was the day of the **state funeral of His Majesty King Harald V** at Oslo Cathedral. With the ceremonial procession passing through central Oslo, including along Karl Johans gate, the city around the conference was understandably very different from a normal Wednesday. We would like to respectfully acknowledge the significance of the day for our Norwegian hosts and the wider community. ## Thank you, Oslo A big thank you to the **NONOG and NIX organisers**, the event sponsors, speakers and everyone who made the meeting possible. And, as always, thank you to everyone who came over to say hello to Pavel, joined the discussions around the presentation, or simply spent some time talking networks with us during the day. Network operator groups remain some of our favourite events because they are built around knowledge sharing rather than sales pitches. They give engineers space to compare notes, discuss what is actually happening in production, and learn from people solving similar problems elsewhere. It was great to spend the day with the Nordic networking community, and we hope to see many of you again soon — at another NOG, another conference, or somewhere on the Internet! **Categories:** Events **Tags:** events --- ### [See you at DENOG 18!](https://fastnetmon.com/2026/07/12/see-you-at-denog-18/) **Published:** July 12, 2026 **Author:** FastNetMon **Content:** FastNetMon will be attending **DENOG 18** on **November 15–17, 2026**, in **Essen, Germany**, and we're looking forward to connecting with the German network operator community. Members of the **FastNetMon team** will be there. If you're working on **DDoS detection and mitigation, traffic visibility, routing or network security**, we'd be happy to hear about the challenges you're facing and share our experience. DENOG brings together **network engineers, operators, ISPs, data centres and infrastructure providers** to exchange practical knowledge and discuss the technologies and operational challenges behind today's Internet. If you're heading to Essen, **book a meeting with the FastNetMon team** and let's find some time to talk. DENOG 18 takes place at **Haus der Technik**, right next to Essen Central Station. We're looking forward to catching up with the community and making new connections. **Event:** DENOG 18 **Date:** November 15–17, 2026 **Location:** Haus der Technik (HDT), Hollestrasse 1, 45127 Essen, Germany See the [official DENOG 18 website](https://www.denog.de/de/meetings/denog18/) for registration, the program, and the latest event information. **Categories:** Upcoming Events --- ### [See you at NANOG 89](https://fastnetmon.com/2026/07/13/nanog-89-event-page/) **Published:** July 13, 2026 **Author:** FastNetMon **Content:** FastNetMon will be attending **NANOG 98** on **October 19–21, 2026**, in **Miami, Florida**, and we're looking forward to three days with the network operator community. Several members of the **FastNetMon team** will be there, so it's a great opportunity to meet us in person. If you're working on **DDoS detection and mitigation, traffic visibility, routing or network security**, we'd be happy to hear about the challenges you're seeing in your network and share our experience. NANOG is one of the key meeting points for network engineers, operators, ISPs, cloud providers, and infrastructure vendors. It brings the community together to exchange practical knowledge and discuss the technologies and operational challenges shaping today's Internet. If you're heading to Miami, **book a meeting with the FastNetMon team** and let's find some time to talk during the event. NANOG 98 takes place at the InterContinental Miami in downtown Miami. We're looking forward to catching up with familiar faces, meeting new people, and having some great conversations. **Event:** NANOG 98 **Date:** October 19–21, 2026 **Location:** InterContinental Miami, 100 Chopin Plaza, Miami, FL 33131, USA See the [official NANOG 98 website](https://nanog.org/events/nanog-98/) for registration and the latest event information. **Categories:** Featured, Upcoming Events --- ### [Network Engineering Community News: August 2026](https://fastnetmon.com/2026/08/27/network-engineering-community-news-august-2026/) **Published:** August 27, 2026 **Author:** FastNetMon **Content:** ⚡️ Network Engineering Community News - from FastNetMon Welcome to the August edition of Network Engineering Community News! This month, we’re covering key FastNetMon product updates, the recent launch of Netomics, DDoS simulation at 100GbE, the latest botnet research, and a look back at the history of the first transatlantic cable. Plus, find out where you can meet the FastNetMon team at upcoming events. | \| \| \| \| \| \|:-:\| \| \|:-:\| \| \|:--\| \| \| \| \| \| \|:--\| \| \|:--\| \| \|:-:\| \| \| \| \| Welcome to the August edition of Network Engineering Community News! This month, we’re covering key FastNetMon product updates, the recent launch of Netomics, DDoS simulation at 100GbE, the latest botnet research, and a look back at the history of the first transatlantic cable. Plus, find out where you can meet the FastNetMon team at upcoming events. \| \|:--\| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| \| \|:-:\| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| ### Product Updates \| \|:--\| \| \| \| \| \|:--\| \| \|:-:\| \| \|:--\| \| \| \| ## What's New? \| \| On the product side, we’ve released [**FastNetMon Advanced 2.0.383**](https://fastnetmon.com/2026/08/06/fastnetmon-advanced-2-0-383/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter), a **mandatory upgrade for all FastNetMon Advanced customers using online licensing** following a CA certificate rotation in our licensing infrastructure. Customers need to upgrade to ensure continued automatic license renewal, and Ubuntu and Debian users should also check that they are using the current [FastNetMon APT repository](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-apt-repositories/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter). Additionally, we’ve made **FastNetMon Community easier to install through the** [**Ubuntu Snap Store**](https://fastnetmon.com/2026/08/04/fastnetmon-community-is-now-available-on-the-ubuntu-snap-store/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) and introduced a new tool called [**sFlowgen**](https://fastnetmon.com/2026/08/11/introducing-sflowgen-lightweight-sflow-traffic-generator/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter), a lightweight sFlow traffic generator for generating realistic traffic samples and simplifying DDoS testing. \| \| \|:--\| \| \|:--\| \| \|:-:\| \| \| \| \| \| \|:-:\| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| ### From the Lab \| \|:--\| \| \| \| \| \|:--\| \| \|:-:\| \| \|:--\| \| \| \| [![](https://eoolnbw.stripocdn.email/content/guids/CABINET_fcab01b1dcdf56ac2f4e39c61ae0e616d7f1b58e49e87a9909cfb1a330a572cb/images/concept4_OY2.png)](https://fastnetmon.com/2026/08/10/simulating-ddos-attacks-at-100gbe-line-rate-with-trex/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| \| ## Simulating DDoS Attacks at 100GbE Line Rate with TRex \| \| How can you realistically simulate DDoS traffic at high packet rates? We explore how **TRex stateless mode** can generate DDoS traffic at **100GbE line rate**, covering UDP, SYN, ACK, ICMP and fragment floods, along with carpet-bombing and multi-vector scenarios. The article by Denys Haryachyy, walks through the setup and practical examples for generating high-volume attack traffic in a controlled environment. \| \| \|:--\| \| \|:--\| \| \| \| [Read the article](https://fastnetmon.com/2026/08/10/simulating-ddos-attacks-at-100gbe-line-rate-with-trex/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| \| \|:-:\| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| ### Introducing Netomics \| \|:--\| \| \| \| \| \|:--\| \| \|:-:\| \| \|:--\| \| \| \| [![](https://eoolnbw.stripocdn.email/content/guids/CABINET_fcab01b1dcdf56ac2f4e39c61ae0e616d7f1b58e49e87a9909cfb1a330a572cb/images/netomics_by_fastnetmon_4.png)](https://linuxsecurity.com/news/network-security/routing-security-hijacks-and-leaks?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| \| ## About Route Leaks, BGP Hijacks - and Netomics \| \| BGP hijacks and route leaks remain a serious operational risk, and detecting them quickly requires more than simply watching routing updates. A recent LinuxSecurity article looks at how RPKI, routing history, ownership data, and real-time BGP visibility can help operators identify suspicious announcements — and explores how **Netomics, our new self-hosted routing intelligence platform**, brings that context together while keeping routing data within your own infrastructure. \| \| \|:--\| \| \|:--\| \| \| \| [Read the article](https://linuxsecurity.com/news/network-security/routing-security-hijacks-and-leaks?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| \| \|:-:\| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| ## Worth Reading \| \|:--\| \| \| \| \| \|:--\| \| ### DDoS News: Inside The New Linux Botnet \| \| [![](https://eoolnbw.stripocdn.email/content/guids/CABINET_fcab01b1dcdf56ac2f4e39c61ae0e616d7f1b58e49e87a9909cfb1a330a572cb/images/ddos_news_new_linux_botnet_evooo1bot_emerged_BkI.png)](https://fastnetmon.com/2026/08/19/ddos-news-evooo1bot-linux-botnet-hijacks-routers-and-firewalls/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| \| A closer look at **Evooo1Bot**, a new Linux botnet targeting routers, firewalls, cameras, and other edge devices — combining DDoS capabilities with proxy relaying, credential sniffing, and automated exploitation. \| \| [Read the News](https://fastnetmon.com/2026/08/19/ddos-news-evooo1bot-linux-botnet-hijacks-routers-and-firewalls/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| \| \| \| \| \|:--\| \| ### Internet History: How Victorian Engineers Wired an Ocean \| \| [![](https://eoolnbw.stripocdn.email/content/guids/CABINET_fcab01b1dcdf56ac2f4e39c61ae0e616d7f1b58e49e87a9909cfb1a330a572cb/images/the_first_transatlantic_cable_article.png)](https://fastnetmon.com/2026/08/11/the-first-transatlantic-cable-how-victorian-engineers-wired-an-ocean/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| \| A trip back to the **first transatlantic telegraph cable** and the remarkable engineering challenges involved in connecting Europe and North America across the Atlantic. \| \| [Read Article](https://fastnetmon.com/2026/08/11/the-first-transatlantic-cable-how-victorian-engineers-wired-an-ocean/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| \| \|:--\| \| \| ## Upcoming Events \| \|:--\| \| \| \| \| \|:--\| \| ### Pavel speaking at NONOG 8 \| \| [![](https://eoolnbw.stripocdn.email/content/guids/CABINET_fcab01b1dcdf56ac2f4e39c61ae0e616d7f1b58e49e87a9909cfb1a330a572cb/images/copy_of_nonog_event.png)](https://fastnetmon.com/2026/07/16/snonog-8-nix-2026-event-page/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| \| We're heading to Oslo soon! Join Pavel Odintsov’s [session on FastNetMon Community Edition](https://fastnetmon.com/2026/07/16/snonog-8-nix-2026-event-page/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) and catch up with the Nordic network operator community on September 9th. \| \| \| \| \| \|:--\| \| ### Outi joining NOG.HR \| \| [![](https://eoolnbw.stripocdn.email/content/guids/CABINET_fcab01b1dcdf56ac2f4e39c61ae0e616d7f1b58e49e87a9909cfb1a330a572cb/images/copy_of_fastnetmon_is_attending_hrnog_meeting_7.png)](https://fastnetmon.com/2026/07/15/nog-hr-meetup-7-event-page/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| \| in Zagreb? NOG.HR Meetup 7 is on September 10th — join [Outi Maria Pietilanaho’s session on today’s botnets, threat intelligence, and DDoS defence](https://fastnetmon.com/2026/07/15/nog-hr-meetup-7-event-page/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter). \| \| \| \| \| \|:--\| \| ### Meet the team in Miami at NANOG 98 \| \| [![](https://eoolnbw.stripocdn.email/content/guids/CABINET_fcab01b1dcdf56ac2f4e39c61ae0e616d7f1b58e49e87a9909cfb1a330a572cb/images/fastnetmon_is_attending_nanog_98.png)](https://fastnetmon.com/2026/08/25/nanog-89-event-page/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| \| FastNetMon is heading to [**NANOG 98 in Miami**](https://fastnetmon.com/2026/08/25/nanog-89-event-page/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter)**,** October 19–21 — catch up with our team to talk DDoS, network visibility, and the challenges you're seeing in your network. \| \| \|:--\| \| \|:--\| \| \|:-:\| \| \| \| \| \| \|:-:\| \| \|:-:\| \| \|:--\| \| \| \| \| \| \|:-:\| \| \|:--\| \| \| \| \| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| [![Logo](https://eoolnbw.stripocdn.email/content/guids/CABINET_25fbf50d6f886b897f2305af06c298676dd346c8a5de49097728110845f22b79/images/fastnetmon_logo_darkmode_enabled.png "Logo")](https://fastnetmon.com/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| \|:--\| \| Comprehensive solution for DDoS Security \| \| \|:--\| \| \| \| [![CUSTOM_ICON](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff9e4351fbcb955078ba327c189f28d8b8b57377a196b7d7db50a5853c7a6dd1/images/github_logo_icon.png "CUSTOM_ICON")](https://github.com/FastNetMon/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| [![IN](https://eoolnbw.stripocdn.email/content/assets/img/social-icons/logo-black/linkedin-logo-black.png "LinkedIn")](https://www.linkedin.com/company/fastnetmon?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| [![RDT](https://eoolnbw.stripocdn.email/content/assets/img/social-icons/logo-black/reddit-logo-black.png "Reddit")](https://www.reddit.com/r/fastnetmon/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| [![Yt](https://eoolnbw.stripocdn.email/content/assets/img/social-icons/logo-black/youtube-logo-black.png "Youtube")](https://www.youtube.com/@FastNetMon?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| [![BSKY](https://eoolnbw.stripocdn.email/content/assets/img/social-icons/logo-black/bluesky-logo-black.png "BlueSky")](https://bsky.app/profile/fastnetmon.bsky.social?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| [![IG](https://eoolnbw.stripocdn.email/content/assets/img/social-icons/logo-black/instagram-logo-black.png "Instagram")](https://www.instagram.com/fastnetmon?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| [![TT](https://eoolnbw.stripocdn.email/content/assets/img/social-icons/logo-black/tiktok-logo-black.png "TikTok")](https://www.tiktok.com/@fastnetmon?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| [![XCOM](https://eoolnbw.stripocdn.email/content/assets/img/social-icons/logo-black/x-logo-black.png "X")](https://x.com/fastnetmon?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| [![FB](https://eoolnbw.stripocdn.email/content/assets/img/social-icons/logo-black/facebook-logo-black.png "Facebook")](https://www.facebook.com/fastnetmon?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| \|:-:\|:-:\|:-:\|:-:\|:-:\|:-:\|:-:\|:-:\|:-:\| \| \|--:\| \| [Newsletter Archive](https://fastnetmon.com/newsletter/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| [Blog](https://fastnetmon.com/blog/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| \| \|:--\| \| \|:--\| \| \|:-:\| \| \| \| \| \| \|:-:\| \| \|:-:\| \| \|:--\| \| \|:-:\| | |---| **Categories:** Newsletter --- ### [DDoS News: Evooo1Bot Linux Botnet Hijacks Routers and Firewalls](https://fastnetmon.com/2026/08/19/ddos-news-evooo1bot-linux-botnet-hijacks-routers-and-firewalls/) **Published:** August 19, 2026 **Author:** FastNetMon **Content:** A newly observed Linux botnet dubbed **Evooo1Bot** is targeting internet-facing edge devices, including enterprise firewalls, SOHO routers, IP cameras, and industrial RTUs. FortiGuard Labs reports that the malware reuses the DDoS engine from the publicly leaked Mirai source code while adding capabilities including encrypted command-and-control (C2) communications, SOCKS5 proxy relaying, credential sniffing, SSH brute-force scanning, persistence, and automated vulnerability exploitation. Fortinet telemetry indicates that Evooo1Bot has been actively targeting internet-facing devices since July 2026. For network operations teams, the key takeaway is a shift in operational risk: compromised edge devices are no longer just participating in [outbound DDoS attacks](https://fastnetmon.com/2025/09/24/outbound-ddos-the-attack-you-might-be-unknowingly-hosting/). They can also be converted into proxy nodes capable of relaying arbitrary TCP traffic, concealing an attacker's origin and potentially providing access to internal networks through an already compromised device. ## **Vulnerability Delivery and Execution Pipeline** FortiGuard IPS telemetry observed active exploitation attempts against vulnerabilities affecting Alcatel OmniPCX, NETGEAR and Tenda routers, Mitsubishi Electric RTUs, Telesquare devices, and D-Link routers. Across the captured exploitation traffic, payload callbacks pointed to the same loader URL at **`91.92.40[.]118/wget.sh`**. Separately, Evooo1Bot contains an integrated HTTP exploit module covering additional targets, including Hikvision IP cameras, Zyxel firewalls, TP-Link routers, Atlassian Confluence, D-Link NAS devices, WSO2 products, PHP-CGI, and Kubernetes ingress-nginx. Fortinet notes that some exploit entries contain implementation errors and are non-exploitable as shipped. When an observed exploit succeeds, it retrieves the **`wget.sh`** loader. The script identifies the host's CPU architecture and downloads one of 12 binary variants, attempting **`wget`**, **BusyBox `wget`**, **`curl`**, and **`tftp`** in that order. The binary is written to a temporary path, made executable, and launched, after which Bash history is cleared. To complicate static analysis, Evooo1Bot protects more than 60 static string blocks using multiple layers of encryption and obfuscation. AES and ChaCha20 keys are not stored directly in the binary; instead, each key is represented by two 32-byte constants embedded in **`.data`** and reconstructed at runtime using XOR. A separate XOR decoding procedure protects a subset of strings in **`.rodata`**. Fortinet identifies AES-256-CTR, ChaCha20, and XOR-based key derivation among the techniques used. Before establishing C2 communications, the malware searches for analysis tools such as **`gdb`**, **`tcpdump`**, and **`wireshark`**, along with fingerprints associated with virtualized, sandboxed, or isolated environments such as **QEMU**, **VMware**, **VirtualBox**, **gVisor**, and **Kata Containers**. Once these checks pass, it connects to its C2 server over TCP port 443, which Fortinet says was selected to blend in with expected HTTPS traffic at the network perimeter. ## **Functional Components: DDoS, SOCKS5 Relays, and Sniffing** Evooo1Bot exposes a broader modular remote-administration framework that includes persistence, self-update, control, file transfer, interactive shell, sniffing, SOCKS relaying, SSH scanning, DDoS, and CVE exploitation. Among these capabilities, three are particularly relevant to network operators. ### **1. Disruption Engine (16 DDoS Vectors)** The bot's DDoS engine is structurally consistent with the publicly leaked Mirai source code and supports **16 flood methods**. These include generic and high-packet-rate UDP floods, TCP SYN and ACK floods, GRE-encapsulated IP and Ethernet floods, fragmented TCP floods, TCP attacks using different flag combinations, a DNS flood, Valve Source Engine query amplification, and other specialized attack variants. Evooo1Bot also includes an HTTP flood variant. Operators can specify the HTTP method, headers, and expected values while customizing fields including **User-Agent** and **Content-Length**, extending the bot's attack capabilities beyond network- and transport-layer flooding. ### **2. SOCKS5 Proxy Relaying** The malware can turn an infected device into a SOCKS5 proxy in two modes. In direct mode, it opens a SOCKS5 listener on the infected host using TCP port **1080** by default. It first attempts to establish a dual-stack IPv6 listener and falls back to IPv4 if that fails. In reverse mode, Evooo1Bot establishes an encrypted outbound connection to an operator-specified relay server rather than exposing a local listening port. When instructed to create a proxy session, the bot opens a second encrypted connection to the relay and passes it to its SOCKS5 proxy routine. This allows multiple proxy sessions to operate while maintaining a persistent control channel. The result is particularly significant for defenders: an infected edge device can relay arbitrary TCP traffic using the victim's public IP address. Fortinet warns that this functionality could be used to disguise malicious traffic, bypass geographic restrictions, access internal networks through an already compromised system, or form part of a distributed proxy infrastructure. ### **3. Credential Sniffing, SSH Scanning, and Persistence** Evooo1Bot's sniffer reads **`/proc/net/tcp`**, intercepts cleartext **HTTP Basic Authorization** and **Cookie** headers, and writes captured information to **`/tmp/.sniff.log`**. A built-in SSH scanner uses an embedded dictionary containing **more than 150 credential entries**. In addition to common IoT default credentials, the list contains service-account names such as **`jenkins`**, **`postgres`**, **`oracle`**, **`nagios`**, and **`deploy`**, extending its potential targets beyond consumer IoT devices into enterprise and operational-technology environments. The scanner also performs checks intended to identify and avoid SSH honeypots before delivering its persistence payload. Persistence is established through several mechanisms simultaneously. These include a systemd service using the description **`Apache HTTPD Cache Manager`**, a SysV init script, a cron entry that attempts to retrieve the malware script every five minutes, **`/etc/profile.d/`** injection, and modification of **`/etc/rc.local`**. To resist termination, Evooo1Bot writes to **`/proc/self/oom_score_adj`** to reduce its priority as a target for the Linux OOM killer. It also keeps **`/dev/watchdog`** open, which Fortinet says is intended to prevent a device reboot from interrupting the malware's operation. ## **Primary Indicators of Compromise** | **Indicator** | **Value** | **Description** | |---|---|---| | **Loader / IOC IP** | **`91.92.40[.]118`** | **IP associated with the observed `wget.sh` loader and listed by Fortinet as an IOC** | | **Loader URL** | **`91.92.40[.]118/wget.sh`** | **Loader observed in exploitation payload callbacks** | | **ELF Sample 1** | **`f13cb360768363d3424e2192c7805b8c8015eb8706dbbbcdead6aed8cf390109`** | **SHA-256 binary hash** | | **ELF Sample 2** | **`4c0886349e9d348569fffe1b7a31e474d514508bf0cd6f1e5dd99c2a73525e4d`** | **SHA-256 binary hash** | Fortinet lists **`91.92.40[.]118`** and both SHA-256 hashes as indicators of compromise associated with Evooo1Bot. For operators, the combination of DDoS functionality, vulnerability exploitation, persistent remote administration, credential interception, SSH scanning, and SOCKS5 proxying makes Evooo1Bot more capable than a conventional Mirai-derived DDoS bot. In particular, the reverse proxy functionality means a compromised router, firewall, camera, or other edge device can serve not only as a source of attack traffic but also as infrastructure for concealing and relaying subsequent malicious activity. Read the full research from FortiGuard Labs [here](https://www.fortinet.com/blog/threat-research/multi-functional-linux-botnet-evooo1bot). **Categories:** FastNetMon Blog --- ### [The First Transatlantic Cable: How Victorian Engineers Wired an Ocean](https://fastnetmon.com/2026/08/11/the-first-transatlantic-cable-how-victorian-engineers-wired-an-ocean/) **Published:** August 11, 2026 **Author:** FastNetMon **Content:** > *Occasionally on the FastNetMon blog, we venture into the history of communications infrastructure and the engineering stories that helped shape the Internet we know today. This time, it’s the remarkable story of how Victorian engineers attempted to wire an ocean—and what happened when their first transatlantic connection lasted only a few weeks.* On August 16, 1858, Queen Victoria sent a message to U.S. President James Buchanan. The message itself was conventional diplomatic fare, expressing goodwill between Britain and the United States. What was extraordinary was the route it took. Instead of travelling aboard a ship, the message crossed the Atlantic as electrical signals through roughly 3,200 kilometres of cable connecting Ireland and Newfoundland. Victoria's 98-word message took almost 16 hours to transmit. That sounds painfully slow today, but a steamship carrying the same information could take around ten days to cross the Atlantic. For the first time, information could travel between Europe and North America without a person, letter or ship making the journey. It was a profound change in what distance meant, and the public response reflected it. The project has since been described as the Victorian equivalent of the Apollo mission. There was, however, a rather serious problem with this technological triumph. Within a few weeks, the cable had stopped working. The story of the first transatlantic cable is therefore not simply one of Victorian ingenuity. It is also a remarkably familiar engineering story: an ambitious idea pushed beyond the limits of existing technology, competing theories about how to make it work, repeated deployment failures, difficult debugging, questionable design decisions and enormous financial pressure. Most importantly, it is a story about learning from failure. ## Connecting two continents Electrical telegraphy was already well established by the 1850s. Telegraph networks had spread across land, while shorter submarine cables had demonstrated that electrical signals could also be transmitted underwater. A cable between Britain and France had been laid as early as 1850. Crossing the Atlantic was an entirely different proposition. The distance between Ireland and Newfoundland was thousands of kilometres, with parts of the route crossing ocean around two miles deep. A cable would have to be manufactured in unprecedented quantities, carried across the Atlantic, lowered onto an ocean floor nobody could directly observe, and remain electrically functional after deployment. The driving force behind the project was an American businessman named **Cyrus W. Field**. Having made his fortune in the paper industry, Field became interested in telegraphy and eventually turned his attention to connecting North America with Europe. In 1856, he joined English submarine-telegraph specialists John Watkins Brett and Charles Tilston Bright to form the **Atlantic Telegraph Company**. It was a serious commercial undertaking. The company raised around £350,000 in private capital, much of it from British business communities, while both the British and U.S. governments provided financial support and ships. The ambition was enormous, but so were the unresolved engineering questions. Nobody had ever built a communications link of this length. ## Designing a cable for an ocean The basic construction of the cable would be recognisable to a modern communications engineer. At the centre was the conductor: seven strands of copper wire twisted together. Around this were three layers of **gutta-percha**, a natural latex derived from tree sap that provided electrical insulation. Tarred hemp and an outer wrapping of iron wire provided additional protection and mechanical strength. The completed cable was approximately five-eighths of an inch in diameter and weighed more than a ton per nautical mile. Producing enough of it was itself a major industrial undertaking; no single manufacturer could deliver the required quantity within the available time, so the order had to be divided. More significantly, engineers disagreed about what the cable's electrical characteristics should be. Edward Orange Wildman Whitehouse, an electrician working for the Atlantic Telegraph Company, supported a relatively thin conducting core. William Thomson, the physicist who would later become Lord Kelvin, argued in favour of a substantially larger conductor made from extremely pure copper. Charles Bright, the project's chief engineer, agreed with Thomson. The difference between the proposals was substantial. The copper core that was ultimately manufactured weighed about **107 pounds per nautical mile**. Thomson and Bright had proposed a core weighing approximately **392 pounds per nautical mile**. The lighter design was adopted. Even at that weight, transporting the completed cable created another practical problem: no ship could carry all of it. The load therefore had to be divided between two naval vessels, **HMS** ***Agamemnon***, a British warship launched in 1852, and the American ***Niagara***. The plan now depended on getting thousands of kilometres of cable from those ships to the seabed without losing it along the way. ## The first attempt The first major expedition began from Ireland on August 5, 1857. The initial plan was to start at the Irish coast and gradually pay the cable out from *Niagara* while sailing west across the Atlantic. Problems appeared almost immediately. Less than five miles from shore, the heavily reinforced shore section of the cable became caught in the machinery and broke. The expedition managed to retrieve it, splice it back together and continue. That early failure demonstrated how difficult the physical act of laying the cable would be. The cable could not simply be dropped over the stern. Its release had to be carefully controlled while accounting for the speed of the ship, ocean currents, waves and the increasing weight of cable suspended between the vessel and the seabed. Machinery controlled the rate at which cable was paid out, with brakes requiring continual adjustment. In calm weather this was manageable. The North Atlantic was not reliably calm. At around 3:45 a.m. on August 11, *Niagara* moved into the trough of a wave. As the ship rose again, tension on the cable increased. The brakes should have been released to compensate, but they were not. The cable broke and disappeared into water so deep that it could not be recovered. The expedition was abandoned for the year. ## A second attempt — and several more failures The winter provided an opportunity to improve the system. Engineer William Everett redesigned the paying-out machinery, paying particular attention to its braking mechanism and safety features, while the crews practised the procedures they would need at sea. Thomson was also working on the electrical problem. He developed his **mirror galvanometer**, a highly sensitive instrument capable of detecting extremely faint electrical currents. This would become important because sending a signal through thousands of kilometres of submarine cable was not simply a matter of applying enough voltage at one end and expecting a clean pulse to appear at the other. When the ships returned in 1858, they adopted a different deployment strategy. Instead of starting at Ireland, *Agamemnon* and *Niagara* would sail to the middle of the Atlantic carrying half the cable each. There the crews would splice the two halves together before the ships sailed in opposite directions, *Agamemnon* towards Ireland and *Niagara* towards Newfoundland. Before they could even begin, a six-day storm battered the cable-laden ships. *Agamemnon*, carrying around 1,500 tons of cable, rolled violently enough that 45 men were injured, and the vessel was pushed approximately 200 miles off course. Eventually, on June 25, the two ships met and joined their cables. They began sailing apart, initially communicating with each other through the new connection. Two days later, the electrical connection failed. Both ships returned to the rendezvous point, abandoned the cable already laid and started again. The next attempt ended with another broken cable. For Cyrus Field, the engineering problem was now accompanied by an equally difficult financial one. After repeated expensive failures, he had to convince the Atlantic Telegraph Company's directors to fund yet another attempt. Somehow, he did. ## The Atlantic comes online The ships left again on July 17, 1858. On July 29 they met in the Atlantic and spliced the cable once more. The connection was lowered into water approximately **1,500 fathoms, or 2.7 kilometres, deep**, and the ships headed towards opposite sides of the ocean. This time, nothing broke. *Niagara* reached Newfoundland on August 4. *Agamemnon* reached Ireland the following day. A continuous electrical connection now stretched across the Atlantic. Testing began, and on August 16 Queen Victoria and President Buchanan exchanged formal messages over the new line. After years of investment, failed expeditions and cables disappearing into the ocean, the Atlantic Telegraph was finally operating. The reaction was enormous. Newspapers had followed the project closely, and the public had become fascinated both by the expedition and by telegraphy itself. New York marked the achievement with a parade and fireworks; the celebrations became sufficiently enthusiastic that fireworks accidentally set fire to the dome of City Hall. In Britain, shares in the Atlantic Telegraph Company more than doubled, while Charles Bright was knighted for his role in the project. The commercial response was equally enthusiastic. *Niagara* returned with hundreds of kilometres of surplus cable, which **Tiffany & Co. bought and turned into souvenirs**. Sections about ten centimetres long were fitted with brass ends and sold to the public. Other manufacturers produced cable-themed pendants, earrings, charms, letter openers, candlesticks and decorations. For a brief period, pieces of communications infrastructure had become fashionable consumer products. Unfortunately, the actual communications infrastructure was already deteriorating. ## Why did the first cable fail? The 1858 cable never performed particularly well. Signals were weak, transmission was extremely slow, and the quality of the connection deteriorated rapidly. Here the earlier disagreement between Whitehouse and Thomson became important. Whitehouse believed that stronger voltages were needed to push signals across the enormous distance and reportedly used voltages as high as **2,000 volts**. Thomson's approach was almost the reverse: rather than forcing increasingly powerful signals through the cable, his mirror galvanometer was designed to detect the extremely weak signals that arrived. Within a few weeks of opening, the cable stopped functioning. Whitehouse received much of the blame. An official investigation criticised his use of high voltages, and for many years the straightforward explanation was that excessive voltage had damaged the cable's insulation. Later research complicated that story. In 1985, historian and engineer Donard de Cogan published an analysis of surviving cable and found evidence of poor manufacturing. The copper conductor was not always centred inside its gutta-percha insulation and in places came dangerously close to the outer metal armour. The insulation itself showed significant deterioration. Problems with impurities and the way the cable had been stored during the winter of 1857–58 may also have contributed. The failure therefore appears less like a single catastrophic mistake and more like a system in which several weaknesses interacted: cable design, material quality, manufacturing, storage and the electrical techniques used to operate it. That is perhaps one of the most recognisable aspects of the story to a modern engineer. Complex infrastructure often fails not because one component is obviously defective, but because several tolerable problems line up in exactly the wrong way. ## A useful failure The first Atlantic cable had a remarkably short operational life, but calling it simply a failure misses what it accomplished. A total of **732 messages** were transmitted before the connection died. Some demonstrated immediately why rapid transatlantic communication mattered. In one notable case, the British government had troops in Canada that were expected to travel to India. After learning that circumstances there had changed, the government used the cable to order two regiments to remain in Canada. The decision reportedly saved the British Treasury between **£50,000 and £60,000**—a substantial portion of its investment in the cable. More importantly, the experiment had answered the largest question. Electrical communication across the Atlantic was possible. Engineers no longer had to prove the concept; they had to make it reliable. That distinction would shape what happened next. ## From experiment to infrastructure Field remained determined to build another cable, although many of the original investors were understandably less enthusiastic. In the years following the 1858 failure, submarine telegraph engineering continued to improve. Cables laid elsewhere used better insulation and thicker copper conductors, providing valuable practical experience. By 1865, Field was ready to try the Atlantic again. This time the project had access to the **SS** ***Great Eastern***, then the largest ship in the world. Its enormous size solved one of the original expedition's fundamental logistical problems: *Great Eastern* could carry the entire transatlantic cable itself. The 1865 expedition came remarkably close to success. About 600 miles from Newfoundland, however, the cable snapped and disappeared into deep water. Field returned the following year. In 1866, after almost a decade of failures, redesigns and expeditions, a new transatlantic cable was successfully completed and entered commercial service on July 28. A month later, the expedition recovered the cable lost in 1865 from the ocean floor, repaired it and placed that connection into service as well. Europe and North America now had two working telegraph links. The experiment had become infrastructure. ## The network beneath the ocean It is easy to treat the transatlantic telegraph as a distant ancestor of today's Internet: an ingenious Victorian technology that was eventually replaced by something fundamentally different. In reality, there is a surprisingly direct line between the problem those engineers faced and the global communications infrastructure we depend on today. The technology has obviously changed. Copper conductors have been replaced by optical fibre, telegraph pulses by digital traffic, and messages that once required hours of transmission now represent an insignificant amount of data. Modern submarine cables can carry enormous volumes of traffic between continents. But the physical problem never disappeared. Oceans still have to be crossed. Cable routes must be surveyed. Thousands of kilometres of cable must be manufactured to exacting standards, transported and deployed. The cable must survive the installation process and then operate reliably in an environment where physical access is exceptionally difficult. Signal quality, materials, manufacturing defects and redundancy all remain engineering concerns. This is what makes the first transatlantic cable such an interesting technology story more than 160 years later. Its creators did not arrive at the correct design in a single moment of inspiration. They disagreed about the physics, built machinery that failed, lost enormous lengths of cable in the Atlantic, discovered weaknesses in their materials and exhausted the patience of their investors. Yet the failures produced information. Machinery was redesigned. Electrical instruments improved. Cable construction changed. Deployment techniques evolved. Each unsuccessful expedition narrowed the set of problems that still had to be solved. The cable of 1858 survived for only a few weeks, but it demonstrated something far more important than the reliability of one particular piece of copper and gutta-percha. It showed that continents could be connected by communications infrastructure laid across the ocean floor. The cables became better. The signals became faster. The network expanded. More than a century and a half later, we are still using the same basic idea. **Categories:** FastNetMon Blog --- ### [Introducing sFlowgen: Lightweight sFlow Traffic Generator](https://fastnetmon.com/2026/08/11/introducing-sflowgen-lightweight-sflow-traffic-generator/) **Published:** August 11, 2026 **Author:** FastNetMon **Content:** Testing DDoS mitigation can be surprisingly difficult. You may want to see how your monitoring system reacts to a 10 or 15 Gbps attack, but generating that much real traffic requires suitable hardware and network capacity — and is not always practical or desirable in a test environment. To make this kind of testing easier, FastNetMon has released **[sflowgen](https://github.com/FastNetMon/sflowgen/)**, a lightweight, open-source tool for DDoS testing. Instead of generating gigabits of real network traffic, sflowgen generates the **sFlow telemetry that represents it**. You can create normal background traffic, introduce a simulated DDoS attack, and send the resulting sFlow v5 data directly to FastNetMon. For example, you can configure a network carrying a few gigabits of everyday traffic, add a UDP flood targeting a particular host, and watch how FastNetMon responds as the attack gradually increases to 15 Gbps. The generator itself does not need to put 15 Gbps of traffic onto the network. This gives network engineers a lightweight and controlled way to test DDoS detection, tune thresholds, validate monitoring configurations and demonstrate FastNetMon without setting up a full-scale traffic-generation environment. FastNetMon has released sflowgen as an **open-source Go tool** for exactly these kinds of testing, demonstration, dashboard and attack-detection validation scenarios. ## Key Features - **Two Operating Modes:** - **Ambient Mode:** Continuously generates background traffic across one or more IPv4 and IPv6 networks. Zipf-distributed base weights create stable but non-uniform top talkers, while correlated AR(1) noise allows individual host rates to move smoothly over time without causing large swings in the overall network rate. - **Attack Mode:** Generates synthetic telemetry representing targeted DDoS traffic associated with a single victim address. It can represent TCP, UDP, ICMP and ICMPv6 floods, with configurable smooth ramp-up, peak hold and ramp-down phases. - **Configurable Traffic Profiles:** Define protocol ratios, packet sizes using a bounded normal distribution, incoming and outgoing traffic proportions, and TCP SYN, ACK or SYN-ACK flags for attack profiles. - **Deterministic Test Runs:** Configurable random seeds make it possible to create deterministic, reproducible traffic-generation runs. - **IPv4 and IPv6 Support:** Both ambient and attack scenarios can generate synthetic headers representing IPv4 or IPv6 traffic. - **Concurrent Ambient and Attack Traffic:** Ambient traffic and an attack simulation can run as separate processes against the same sFlow collector. Different sub\_agent\_id values distinguish the two streams. - **Runtime Statistics:** sflowgen reports both the traffic rate requested by its model and the traffic volume represented by the emitted sFlow samples, making it easier to verify that a test is behaving as expected. ## How It Works Because sFlow represents network traffic through statistical sampling, sflowgen does not need to generate true line-rate application bandwidth to test high-volume detection scenarios. Instead, it generates sFlow FlowSample records containing RawPacketFlow data with synthetic Ethernet, IP and transport-layer headers. Each sample also carries an original frame length and is associated with a configurable sampling rate. FastNetMon can use this information to estimate the amount of network traffic represented by the samples. For the generator, the approximate represented traffic per sample is: **frame length × sampling rate × 8** This means a relatively small stream of sFlow telemetry can represent a much larger volume of network traffic. For example, an engineer can configure an attack profile with a **15 Gbps peak rate** and specify the victim address, protocol, packet-size distribution and attack duration. FastNetMon then receives telemetry representing that traffic pattern without sflowgen having to transmit 15 Gbps of real application traffic. This separation between **generated telemetry** and **represented traffic** is what makes sflowgen useful for lightweight DDoS testing. ## Simulating Background Traffic DDoS detection is often easier to test when an attack does not appear against an otherwise empty network. The ambient mode is designed to create a changing baseline of background traffic. Each configured network receives an average traffic rate that can be divided between incoming and outgoing traffic. Individual hosts receive stable base weights, optional Zipf-based rank bias and smoothly changing AR(1) noise. This produces non-uniform top talkers whose rates vary over time while keeping the total network rate comparatively stable. Incoming and outgoing traffic for the same internal host also use the same changing host weight. This creates correlated, request/response-like behaviour without attempting to model actual application sessions. An attack process can then run alongside this baseline, allowing teams to observe how detection behaves as synthetic attack traffic ramps up above normal background activity. ## What sflowgen Is — and Isn't sflowgen is a **telemetry generator, not a packet or application traffic generator**. It does not generate application payloads, maintain stateful TCP or UDP sessions, or reproduce complete request/response conversations. Incoming and outgoing ambient traffic can be correlated by host, but individual flows are not matched by five-tuple. It also does not currently model features such as VLAN tagging, fragmentation, tunnelled traffic, counter samples, PCAP replay or BGP metadata. Instead, the tool is deliberately focused on generating controlled sampled-header telemetry that a collector such as FastNetMon can use for traffic estimation and attack-detection testing. That makes it particularly useful when the goal is to test **DDoS detection logic and traffic visibility**, rather than the forwarding capacity of routers, switches, NICs or mitigation appliances. Because the telemetry is synthetic, it is still important to check that a test profile produces the behaviour you expect. Review the configuration and validate the resulting telemetry before using sflowgen in shared or production-like environments. ## License & Availability sflowgen is open source and released under the **Apache License 2.0**. The project requires **Go 1.22 or newer** and a reachable sFlow collector. To get started and explore more, visit the **[sflowgen GitHub repository](https://github.com/FastNetMon/sflowgen/tree/main)**. **Categories:** FastNetMon Blog, Featured, Press & Newsroom --- ### [Simulating DDoS Attacks at 100GbE Line Rate with TRex](https://fastnetmon.com/2026/08/10/simulating-ddos-attacks-at-100gbe-line-rate-with-trex/) **Published:** August 10, 2026 **Author:** FastNetMon **Content:** ![Portrait of a man with short dark hair and light stubble, wearing a dark gray T-shirt, facing the camera (circular crop).](https://fastnetmon.com/wp-content/uploads/2026/06/Denys-Haryachyy-FastNetMon-Guest-Blog.png) *This post is a repost of a [technical blog originally published by Denys Haryachyy](https://haryachyy.wordpress.com/2026/08/06/simulate-ddos-attacks-trex-100gbe-line-rate/), shared here with permission as part of ongoing research and engineering work around FastNetMon’s inline traffic processing capabilities*. > **TL;DR.** TRex’s **stateless mode** can simulate every common volumetric DDoS class at full **100 GbE line rate (142 Mpps)**, and they are all one generator template with a different header. This post takes each attack type in turn — **what it is in the real world, how much of today’s traffic it is, and how to generate it in TRex**. The shared trick is TRex’s **Field Engine**, which rewrites the source IP per packet to mimic the spoofed sources of a real botnet. To test a DDoS-mitigation device I need attack traffic that looks like the real thing: **high volume** and **spoofed, varied sources**. TRex’s stateless mode gives me both — line-rate packet generation plus per-packet field rewriting — without modelling real TCP state. Each attack below is a real-world flood class paired with the exact snippet that generates it. ## The Common Base: Spoofed Source IPs Every flood below shares one thing: the source IP is randomised per packet to mimic a botnet of spoofed sources. That is a Field Engine program attached to the stream, and I reuse the exact same `vm` for all of them: ``` # Random (spoofed) source IP across a /16, with a fixed checksum vm = STLScVmRaw([ STLVmFlowVar(name="src", min_value="10.1.0.1", max_value="10.1.255.254", size=4, op="random"), STLVmWrFlowVar(fv_name="src", pkt_offset="IP.src"), STLVmFixIpv4(offset="IP"), # recompute IPv4 checksum ]) ``` Two reasons this matters. Spoofed sources **defeat per-source rate limits** — no single IP stands out — and random sources **spread across every RX queue** of the target via RSS, so the attack hits all of the victim’s cores, not just one. Use `op="random"`, not `inc`: random gives the full product of the address range as unique flows. ## The Attacks at a Glance Before the snippets, here is roughly how much of real network-layer DDoS each class accounts for — because it decides which ones are worth simulating first. These are Cloudflare’s 2025 Q2 per-vector shares; the ranking reshuffles every quarter, but the shortlist does not. ![Share of network-layer DDoS attacks by vector](https://haryachyy.wordpress.com/wp-content/uploads/2026/08/ddos-f2.png)DNS floods (UDP) and TCP SYN floods are the two that matter most by attack count. Coloured by transport — UDP-carried vectors are about half of all attacks.## UDP Flood — and Its Reflection Variant **The attack.** UDP has no handshake, so there is nothing to slow a flood down and no state to validate a spoofed source. Direct UDP floods are about **13%** of network-layer attacks, but the bigger story is reflection: **DNS floods alone are 33%**, the single largest vector. In a reflection attack the attacker spoofs the victim’s address as the source of a small query to an open server, and the much larger reply is delivered to the victim — free bandwidth, and the attacker never touches the target. ![How a reflection and amplification attack works](https://haryachyy.wordpress.com/wp-content/uploads/2026/08/ddos-f3.png)The multipliers are the bandwidth amplification factors from US-CERT TA14-017A (memcached measured up to 51,000× in 2018). The attacker spends 1 Gbps and the victim receives tens to thousands of times more. | protocol | port | amplification | still common? | |---|---|---|---| | memcached | 11211 | up to 51,000× | mostly filtered since 2018 | | NTP (monlist) | 123 | 557× | yes | | DNS | 53 | 28–54× | **yes — #1 vector** | | CLDAP | 389 | ~56× | yes | | SSDP | 1900 | 31× | yes | Reflection has one convenient property for a defender: it arrives with a well-known source PORT, so a single match catches it. **In TRex.** The direct flood is the base packet with a UDP header; the reflection variant is a reply-shaped packet — source port 53, large payload — aimed straight at the target: ``` victim = "198.51.100.1" # Direct UDP flood — connectionless, no handshake to slow it down udp = Ether()/IP(dst=victim)/UDP(sport=1025, dport=53) # Reflection variant — the packet LOOKS like a DNS reply arriving at the # victim: source PORT 53, large payload. In the wild the attacker spoofs the # victim as the source and an open resolver sends this; in the lab I just # emit the reply-shaped packet straight at the target. refl = (Ether()/IP(dst=victim)/UDP(sport=53, dport=1025) / (b"\x00" * 1400)) ``` ## TCP SYN Flood **The attack.** The second-largest vector at **~27%**. Each SYN asks the target to allocate half-open connection state; at 142 Mpps the listen backlog and the conntrack table are the pressure point long before bandwidth is. ![SYN flood fills the connection backlog](https://haryachyy.wordpress.com/wp-content/uploads/2026/08/sec-syn.png)Each SYN allocates half-open state; the backlog fills before bandwidth does.**In TRex.** Same base, swap the header for a TCP SYN: ``` # TCP SYN flood — half-open connections exhaust the listen backlog syn = Ether()/IP(dst=victim)/TCP(sport=1025, dport=80, flags="S") ``` ## TCP ACK Flood **The attack.** An ACK with no prior SYN. A naive “drop non-SYN” rule will not catch it, and a stateful firewall still has to look up — and fail to find — a connection for every single packet. It is how attackers probe whether a filter is stateless or stateful. ![ACK flood forces a connection lookup that always misses](https://haryachyy.wordpress.com/wp-content/uploads/2026/08/sec-ack.png)An ACK with no prior SYN forces a conntrack lookup per packet that can never match.**In TRex.** One flag changes: ``` # TCP ACK flood — an ACK with no prior SYN; slips past "drop non-SYN" rules ack = Ether()/IP(dst=victim)/TCP(sport=1025, dport=80, flags="A") ``` ## ICMP Echo Flood **The attack.** The classic ping flood — pure volumetric pressure with no protocol subtlety. Its realism comes entirely from the spoofed-source spread, which is why the shared `vm` is doing all the work here. ![ICMP flood spreads across every RX queue](https://haryachyy.wordpress.com/wp-content/uploads/2026/08/sec-icmp.png)Pure packet-rate pressure; the spoofed-source spread lights up every core at once.**In TRex.** Swap in an ICMP echo header: ``` # ICMP echo flood — the classic ping flood icmp = Ether()/IP(dst=victim)/ICMP(type=8, code=0) ``` ## IP Fragment Flood **The attack.** Send only the *first* fragment (`MF=1`) of an oversized datagram, so the target holds reassembly buffers waiting for a remainder that never arrives. The sharp edge for a filter is that a non-first fragment carries **no L4 ports at all**, so every rule that matches on ports is blind to it — a gap worth testing deliberately. ![Fragment flood pins reassembly buffers and has no L4 ports](https://haryachyy.wordpress.com/wp-content/uploads/2026/08/sec-frag.png)The first fragment is held waiting for a rest that never arrives, and it carries no ports to match on.**In TRex.** Emit only the first fragment: ``` # IP-fragment flood — first fragment only (MF=1), forces the target to # hold reassembly state for a datagram whose rest never arrives. Note there # is no L4 port here, so any rule that matches on ports cannot classify it. frag = Ether()/IP(dst=victim, flags="MF", frag=0)/UDP(dport=53) ``` ## Carpet Bombing: Spread the Same Traffic Thinner **The attack.** Not a new protocol — a targeting change. Send the same total volume, but spread it across an entire prefix instead of one host. No per-destination threshold trips, because no single host looks abnormal, and detection that works per-host misses it entirely. It has grown over 110% in recent tracking. ![Carpet bombing spreads an attack across a whole prefix](https://haryachyy.wordpress.com/wp-content/uploads/2026/08/ddos-f4.png)Same total volume in both cases. On the left one host is obviously under attack; on the right 65,536 of them are, and none looks unusual on its own.**In TRex.** Add a second Field Engine variable that walks the destination across the protected range — `inc` here, not `random`, so every address is hit evenly: ``` # Carpet bomb — same flood, but the DESTINATION walks a whole /16 so no # single host looks abnormal. Add a second Field Engine variable for dst. carpet_vm = STLScVmRaw([ STLVmFlowVar(name="src", min_value="10.1.0.1", max_value="10.1.255.254", size=4, op="random"), STLVmWrFlowVar(fv_name="src", pkt_offset="IP.src"), STLVmFlowVar(name="dst", min_value="198.51.100.1", max_value="198.51.100.254", size=4, op="inc", step=1), STLVmWrFlowVar(fv_name="dst", pkt_offset="IP.dst"), STLVmFixIpv4(offset="IP"), ]) ``` ## Multi-Vector: All at Once **The attack.** Real incidents rarely use one vector — attackers combine them precisely because defences tend to be vector-specific. The subtle part is the accounting. If I budget five vectors by equal *bandwidth*, they do not carry equal *packets*: the small-frame vectors dominate the packet rate, which is what actually costs a filter CPU. ![Bandwidth share versus packet share in a multi-vector flood](https://haryachyy.wordpress.com/wp-content/uploads/2026/08/ddos-f5.png)Equal fifths of the bandwidth become 29 / 29 / 29 / 9 / 3 percent of the packets. Always budget a mixed profile by bandwidth, or you oversubscribe the link the moment frame sizes differ.**In TRex.** Build one stream per vector, with the pps of each derived from its frame size so the sum is exactly line rate: ``` # Multi-vector — several classes at once, budgeted by BANDWIDTH so each # gets an equal share of the 100G line (equal pps would oversubscribe the # moment frame sizes differ). pps = share_of_line / frame_bits. line_bps = 100e9 def pps_for(frame_bytes, vectors): return (line_bps / vectors) / ((frame_bytes + 24) * 8) streams = [] for pkt, size in [(udp, 64), (syn, 64), (icmp, 64), (frag, 256), (refl, 1500)]: streams.append(STLStream(packet=STLPktBuilder(pkt=pkt, vm=vm), mode=STLTXCont(pps=pps_for(size, 5)))) ``` ## Driving It at Line Rate Whichever attack I picked, the last step is the same — wrap the packet and its `vm` in a stream and start at 100%: ![The TRex stream pipeline from packet to line rate](https://haryachyy.wordpress.com/wp-content/uploads/2026/08/sec-drive.png)One stream template: swap the header on the left, the line-rate figure on the right stays put. ``` s = STLStream(packet=STLPktBuilder(pkt=syn, vm=vm), mode=STLTXCont(pps=25_000_000)) c.add_streams([s], ports=[0]) c.start(ports=[0], mult="100%", force=True) ``` Three such streams to different victim prefixes saturate a 100 GbE link at **142 Mpps** of 64-byte frames. (Getting to that line rate — cores, hugepages, and the frame-size math — is its own topic.) ## What You Will Actually See One last piece of perspective, because it changes what you optimise for. The attacks that make the news are nothing like the attacks that happen. The overwhelming majority of real network-layer DDoS is small and brief: ![Most DDoS attacks are small and short](https://haryachyy.wordpress.com/wp-content/uploads/2026/08/ddos-f6.png)94% of network-layer attacks stay under 500 Mbps and 89% end within ten minutes — but the tail reaches 31.4 Tbps.So mitigation has to be automatic (ten minutes is not enough time for a human to react), but capacity cannot be planned off the median (the same infrastructure has to survive the rare hyper-volumetric one). Both numbers matter, and a line-rate generator is how you test against each end of that range. ## Summary 1. TRex **stateless mode** simulates every common volumetric DDoS class at **100 GbE line rate (142 Mpps)**. 2. **UDP/reflection, SYN, ACK, ICMP, and fragment** floods are one template with a swapped header; the realism is **spoofed source IPs** via `STLVmFlowVar(op="random")` + `STLVmFixIpv4`. 3. By attack count, **DNS floods (33%) and SYN floods (27%)** lead; UDP-carried vectors are about half, driven by **reflection/amplification** up to 51,000×. 4. **Carpet bombing** is a targeting change (walk the destination prefix); **multi-vector** must be budgeted by **bandwidth**, because that is not the same as packet rate. 5. Each class stresses a different resource — backlog, conntrack, reassembly buffers, or raw packet rate — so a real test suite needs all of them. ## References - [Cisco TRex documentation](https://trex-tgn.cisco.com/trex/doc/) — the generator and its stateless mode. - [TRex Stateless Python API](https://trex-tgn.cisco.com/trex/doc/cp_stl_docs/) — `STLStream`, `STLTXCont`, and the Field Engine (`STLVm*`). - [Cloudflare DDoS threat report, 2025 Q2](https://blog.cloudflare.com/ddos-threat-report-for-2025-q2/) — the per-vector percentage shares and size/duration data. - [US-CERT TA14-017A](https://www.cisa.gov/news-events/alerts/2014/01/17/udp-based-amplification-attacks) — the canonical amplification-factor table. - [RFC 4987 — TCP SYN Flooding](https://www.rfc-editor.org/rfc/rfc4987) and [MITRE ATT&CK T1498](https://attack.mitre.org/techniques/T1498/) — the attack descriptions. - [RFC 9411](https://www.rfc-editor.org/rfc/rfc9411) — benchmarking methodology for network-security-device performance. - [NETSCOUT ASERT: Carpet-Bombing](https://www.netscout.com/blog/asert/carpet-bombing) — how prefix-wide attacks evade per-host detection, and their growth. - [360 Netlab: Memcache DDoS](https://blog.netlab.360.com/memcache-ddos-a-little-bit-more-en/) — measurement of the 51,000× memcached amplification factor. - [Cloudflare DDoS threat report, 2025 Q4](https://blog.cloudflare.com/ddos-threat-report-2025-q4/) — the 31.4 Tbps record and the full-year totals. **Categories:** FastNetMon Blog --- ### [Learning TRex: Generating 100GbE Line-Rate Traffic on a Mellanox ConnectX-5](https://fastnetmon.com/2026/08/10/learning-trex-generating-100gbe-line-rate-traffic-on-a-mellanox-connectx-5/) **Published:** August 10, 2026 **Author:** FastNetMon **Content:** ![Portrait of a man with short dark hair and light stubble, wearing a dark gray T-shirt, facing the camera (circular crop).](https://fastnetmon.com/wp-content/uploads/2026/06/Denys-Haryachyy-FastNetMon-Guest-Blog.png) *This post is a repost of a [technical blog originally published by Denys Haryachyy](https://haryachyy.wordpress.com/2026/06/26/generate-100gbe-line-rate-traffic-trex-connectx-5/), shared here with permission as part of ongoing research and engineering work around FastNetMon’s inline traffic processing capabilities*. > **TL;DR.** Cisco **TRex 3.06** pushes full 100GbE line rate — **142 Mpps, 100.01 Gbps L1, `tx_util` 100 %** — from one desktop **Ryzen 7 5800X** and a single **ConnectX-5 Ex** (PCIe Gen4). The rate is set by hardware, not tuning: **14 worker cores**, **800×2 MB hugepages**, and stateless streams with randomized source IPs. Why 142 and not 148.8 Mpps? A 64-byte Scapy frame is **68 bytes on the wire**, so `100e9 ÷ (88×8) = 142 Mpps`. A traffic generator earns its keep by saturating the wire, so your measurements blame the device under test, not the test rig. Here’s how to get there with TRex 3.06 on a ConnectX-5. ![TRex 3.06 generating 100GbE line rate (142 Mpps) from one Ryzen 7 5800X with a Mellanox ConnectX-5 Ex.](https://haryachyy.wordpress.com/wp-content/uploads/2026/06/generate-100gbe-line-rate-traffic-trex-connectx-5-fig1-7.png)Figure 1: TRex 3.06 generating 100GbE line rate (142 Mpps) from one Ryzen 7 5800X with a ConnectX-5 Ex.## The Hardware | Component | Value | |---|---| | CPU | AMD Ryzen 7 5800X — 8 cores / 16 threads | | NIC | Mellanox ConnectX-5 Ex, 100 GbE, PCIe Gen4 x16 | | OS | Ubuntu 24.04, TRex in a privileged container | | TRex | v3.06 | TRex is CPU-bound, so cores are the ceiling. Core 0 runs the master and latency threads; the remaining 14 threads are data cores that fill the NIC queues. A PCIe **Gen4** NIC matters — on Gen3 the bus caps you before the cores do. ![TRex thread layout: core 0 master, core 8 latency, 14 worker threads (1-7, 9-15) filling the NIC queues.](https://haryachyy.wordpress.com/wp-content/uploads/2026/06/trex-14-core-thread-layout-ryzen-5800x.png)Figure 2: The 14-core TRex layout — one master, one latency thread, 14 workers driving the NIC queues.## Why 142 Mpps Is Line Rate (Not 148.8) The textbook 100 GbE figure is **148.8 Mpps** (a 64-byte *wire* frame: 64 + 20 bytes preamble/IFG = 84 = 672 bits). But Scapy’s `Ether` excludes the 4-byte FCS the NIC appends, so a 64-byte Scapy frame is **68 bytes on the wire**: ![A 64-byte Scapy frame is 68 bytes on the wire (it carries the FCS) - so 100GbE line rate is 142 Mpps, not 148.8.](https://haryachyy.wordpress.com/wp-content/uploads/2026/06/generate-100gbe-line-rate-traffic-trex-connectx-5-fig2-6.png)Figure 3: A 64-byte Scapy frame is 68 bytes on the wire — so line rate is 142 Mpps, not 148.8. ``` 68 B frame (64 Scapy + 4 FCS) + 8 preamble + 12 IFG = 88 B = 704 bits100e9 / 704 = 142.0 Mpps <- line rate for these frames ``` TRex confirms it: **142.06 Mpps, 100.01 Gbps L1, `tx_util` 100 %**. To hit the literal 148.8 Mpps, build a 60-byte Scapy frame so the wire frame is exactly 64 bytes. ## TRex Configuration **`/etc/trex_cfg.yaml`** — two ports and the 14-core layout: ``` - port_limit : 2 version : 2 interfaces : ["0000:26:00.0", "0000:26:00.1"] port_info : - ip : "10.0.1.1" - ip : "10.0.2.2" platform : master_thread_id : 0 latency_thread_id : 8 dual_if : - socket : 0 threads : [1,2,3,4,5,6,7,9,10,11,12,13,14,15] ``` The ConnectX-5 uses the `mlx5` bifurcated driver — no `vfio` unbind, the kernel and TRex share the port. Flush the kernel IP off the data-plane port, then launch: ``` ip addr flush dev enp38s0f0np0 # port 0echo 800 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages./t-rex-64 -i --iom 0 --no-ofed-check -c 14 ``` ## Streams: Where Line Rate Comes From A single fixed 5-tuple pins to one queue (~10–15 Mpps). To spread across all 14 cores, vary the source IP *randomly* per packet: ``` vm = STLScVmRaw([ # random source IP - spreads RSS across all RX queues STLVmFlowVar(name="src", min_value="10.1.0.1", max_value="10.1.15.254", size=4, op="random"), STLVmWrFlowVar(fv_name="src", pkt_offset="IP.src"), STLVmFixIpv4(offset="IP"), # fix checksum after the rewrite])stream = STLStream(packet=STLPktBuilder(pkt=pkt, vm=vm), mode=STLTXCont(pps=25_000_000)) ``` Two gotchas. First, use `op="random"`, not `op="inc"`: incrementing every FlowVar in lockstep walks the values down a diagonal, so the unique-flow count collapses to the *largest single range* instead of the product of the ranges. ![op=inc makes flows walk a diagonal (few unique flows); op=random fills the grid (many unique flows).](https://haryachyy.wordpress.com/wp-content/uploads/2026/06/trex-flowvar-inc-vs-random-flow-grid.png)Figure 4: `op="inc"` collapses flows onto a diagonal; `op="random"` fills the grid.Second, rewriting `IP.src` invalidates the IPv4 header checksum, so `STLVmFixIpv4` must recompute it — otherwise a checksum-validating receiver drops every frame. (UDP checksums are optional in IPv4, so `UDP(chksum=0)` saves a FlowVar.) ## Spreading Across the RX Queues Random source IPs aren’t just convenient — they spread the load evenly across every RX queue. The receiver steers each packet by hashing its source IP, so a stream of random sources lands on all 32 queues to within **0.1 %** of each other. Every poll worker stays busy, and no single core caps the receiver. ![Random source IPs spread evenly across all 32 RX queues, CoV 0.1 percent, every queue active.](https://haryachyy.wordpress.com/wp-content/uploads/2026/06/trex-random-src-even-rss-spread-32-queues.png)Figure 5: Random source IPs spread the load flat across all 32 RX queues (measured: CoV 0.1%, no idle queue).## The Result ``` Port 0 tx_pps 142.06 Mpps tx_bps_L1 100.01 Gbps tx_util 100.06 % ``` Full 100 GbE line rate, sustained, from one desktop Ryzen and one ConnectX-5. `tx_util` 100 % means there are no idle bit-times left on the wire. ## Summary 1. **Hardware sets the ceiling** — Gen4 ConnectX-5 + **14 cores** dedicated to TRex. 2. **Target 142 Mpps**, not 148.8 (68-byte wire frames). Trust `tx_util`. 3. **TRex:** `trex_cfg.yaml` with 14 threads, `-c 14`, 800×2 MB hugepages. 4. **Streams:** randomized source IPs + `STLVmFixIpv4` — they spread RSS evenly across every RX queue (measured 0.1% CoV). ## References - [Cisco TRex documentation](https://trex-tgn.cisco.com/trex/doc/) — full manual, including the stateless mode used here. - [TRex Stateless Python API](https://trex-tgn.cisco.com/trex/doc/cp_stl_docs/) — `STLClient`, `STLStream`, and the Field Engine (`STLVm*`). - [DPDK mlx5 poll-mode driver](https://doc.dpdk.org/guides/nics/mlx5.html) — the ConnectX-5 PMD and its devargs. - [Microsoft — RSS Hashing Functions](https://learn.microsoft.com/en-us/windows-hardware/drivers/network/rss-hashing-functions) — how receive-side scaling maps flows to queues. **Categories:** FastNetMon Blog **Tags:** Network Security Insights --- ### [Tuning a VPP Data Plane to 100GbE Line Rate: Cycle Budget, NIC Rings, and RSS](https://fastnetmon.com/2026/08/17/tuning-a-vpp-data-plane-to-100gbe-line-rate-cycle-budget-nic-rings-and-rss/) **Published:** August 17, 2026 **Author:** FastNetMon **Content:** ![Portrait of a man with short dark hair and light stubble, wearing a dark gray T-shirt, facing the camera (circular crop).](https://fastnetmon.com/wp-content/uploads/2026/06/Denys-Haryachyy-FastNetMon-Guest-Blog.png) *This post is a repost of [technical blog originally published by Denys Haryachyy](https://haryachyy.wordpress.com/2026/06/23/tuning-a-vpp-data-plane-to-100gbe-line-rate-cycle-budget-nic-rings-and-rss/), shared here with permission as part of ongoing research and engineering work around FastNetMon’s inline traffic processing capabilities*. > **TL;DR.** A **VPP** software data plane drops packets at full **100GbE line rate (~140 Mpps)** on one server — but staying there is a systems problem, not an algorithm one. Two things decide it, neither about the classifier: the **per-packet cycle budget** (~346 cyc/pkt spent of a 597 budget on a 3.26 GHz core, dominated by **VPP node-graph overhead**, not rule-matching); and the **NIC RX ring** — the real ceiling. More workers help only by adding **queues**, so RSS spreads the load and no single ring overflows. The drop path reaches line rate once enough queues spread the load — **26 workers already hold 142 Mpps**. Dropping at 100GbE line rate is a systems problem as much as an algorithm one. A previously published article — [Learning VPP: Filtering Packets at 100GbE Line Rate](https://haryachyy.wordpress.com/2026/06/17/vpp-packet-filtering-100gbe-line-rate/) — covered the *classifier*, the tuple-space search that makes rule-matching effectively free no matter how many rules you load. This is its companion: once matching is cheap, where do the cycles actually go, and why does the NIC — not the CPU — set the ceiling. ## The Test Platform Every number below comes from a two-machine 100GbE lab wired back-to-back: a VPP/FastACL device under test, and a TRex traffic generator that both sources and sinks the load. | Role | CPU | NIC | |---|---|---| | Device under test (VPP + FastACL) | AMD EPYC 7742 (64C/128T, ~3.26 GHz) | Mellanox ConnectX-5 Ex 100GbE, dual-port | | Traffic generator + sink (TRex) | AMD Ryzen 5800X (8C/16T, 14 data cores) | Mellanox ConnectX-5 Ex 100GbE, dual-port | The DUT runs a **release** VPP with **26 workers**, 8192-entry RX rings, and the ConnectX-5 in `CQE_COMPRESSION=AGGRESSIVE` firmware mode. The card negotiates a full **PCIe 4.0 x16 link (252 Gb/s)** — far above the ~95 Gb/s of L1 bandwidth that 64-byte frames at 142 Mpps actually carry — so the bus is never the limit; the NIC RX ring is. TRex sources up to **142 Mpps of 64-byte frames**, full 100GbE line rate. ## The Budget: 597 Cycles per Packet Start from the wire. At **141.9 Mpps** spread over **26 workers**, each worker sees ~5.5 Mpps. On a 3.26 GHz core that is a hard budget of **597 cycles per packet** — receive, classify, drop, and recycle the buffer, all of it. Everything below is about staying under that line. ## Where the Cycles Go If rule-matching is fixed and small (the classifier is O(number of distinct masks), not O(rules)), what spends the 346 cycles? VPP’s node graph. Profiling the drop path on the low-cardinality (frag-flood) profile: [![Figure 1: The per-packet cost (346 cycles) against the 597-cycle budget at 141.9 Mpps over 26 workers. The filter node is just an O(1) cache lookup — ~74% of the cost is VPP node-graph overhead, not rule-matching.](https://haryachyy.wordpress.com/wp-content/uploads/2026/06/vpp-cycle-budget-26workers-fig2.png)](https://haryachyy.wordpress.com/wp-content/uploads/2026/06/vpp-cycle-budget-26workers-fig2.png)Figure 1: The per-packet cost (346 cycles) against the 597-cycle budget at 141.9 Mpps over 26 workers. The filter node is just an O(1) cache lookup — ~74% of the cost is VPP node-graph overhead, not rule-matching. | Node | cyc/pkt | Share | |---|---|---| | `dpdk-input` | 193 | 56 % | | filter node (TSS bihash lookup) | 74 | 21 % | | `ethernet-input` | 39 | 11 % | | `ip4-input` | 23 | 7 % | | `error-drop` + `drop` | 17 | 5 % | | **Total** | **346** | of a **597** budget | The filter node is the classifier lookup — a small, fixed number of per-mask bihash probes regardless of how many rules are loaded. The dominant cost is **VPP graph overhead** — `dpdk-input` + `ethernet-input` + `ip4-input` are ~74% of the pipeline. Further wins come from *bypassing nodes* (a combined L3-drop node), not from faster matching. The lookup itself rises only modestly on high-cardinality floods — every packet carries a fresh 5-tuple, so each pays a full bihash probe (~80 cyc) instead of hitting a warm bucket — but it stays bounded by the mask count, never the rule count. ## Always Build Release VPP The single biggest performance cliff has nothing to do with the algorithm. A **debug** VPP build enables `vlib_buffer_validate_alloc_free` on every buffer: | Build | Drop throughput | |---|---| | debug | **0.56 Mpps** | | release | **35+ Mpps** | Same code, ~60× difference. If your numbers look impossibly bad, check the build first (`show version`; a giveaway is `vlib_buffer_validate` in `show errors`). ## Why More Workers Doesn’t Mean More Throughput The per-worker ceiling is **3.26 GHz ÷ 346 cyc = 9.4 Mpps**, so 26 workers is **245 Mpps theoretical** — comfortably above the NIC’s 142. CPU is *not* the limit. The limit is how fast workers drain the **NIC RX ring**, which depends on RSS spread and queue count: | Workers | Mpps (random-src) | Why | |---|---|---| | 8 | 34 | RSS/RETA imbalance — flows clump on a few queues | | 16 | 88 | each queue gets 8.9 Mpps > drain rate → RX ring overflow | | **26** | **142** | each queue 5.4 Mpps < drain rate → line rate | | 32 | 142 | each queue 4.4 Mpps; half the cores on this 64-core box — same line rate, extra headroom | Adding workers helps only because it adds **queues**: more queues means less traffic per queue, so no single RX ring overflows. With too few queues — say 8 — the NIC’s 128-entry redirection table and a Toeplitz hash over random source IPs clump flows onto a few queues while others sit idle. The number that matters isn’t 32 but “enough queues that per-queue load stays under the drain rate”: **26 workers already hold full line-rate drop (142 Mpps)**, and 32 is just margin. ## Summary 1. At 100 GbE the budget is **597 cyc/pkt** (26 workers, 3.26 GHz); ~**346** are spent, dominated by **VPP node-graph overhead**, not rule-matching. 2. **Build release.** A debug VPP build collapses drop throughput ~60× (0.56 vs 35+ Mpps) — check this before anything else. 3. The ceiling is the **NIC RX ring**, not the CPU. More workers help only by adding **queues** so RSS spreads the load; the drop path reaches line rate once per-queue load drops under the drain rate — **26 workers already hold 142 Mpps**, and 32 (half the cores on this 64-core box) leaves headroom. 4. Per-worker headroom is **9.4 Mpps**, so the CPU could theoretically do 245 Mpps — the NIC’s 142 gets there first. ## References - [Learning VPP: Filtering Packets at 100GbE Line Rate](https://haryachyy.wordpress.com/2026/06/17/vpp-packet-filtering-100gbe-line-rate/) — the companion article on the TSS classifier that keeps rule-matching off the hot path. - [FD.io VPP documentation](https://s3-docs.fd.io/vpp/26.06/) — the Vector Packet Processor and its node-graph data plane. - [DPDK mlx5 poll-mode driver](https://doc.dpdk.org/guides/nics/mlx5.html) — RSS, the redirection (RETA) table, and RX descriptors on the ConnectX-5. **Categories:** FastNetMon Blog, Featured **Tags:** Network Security Insights --- ### [Action Required: Upgrade to FastNetMon Advanced v2.0.383](https://fastnetmon.com/2026/08/06/action-required-upgrade-to-fastnetmon-advanced-v2-0-383/) **Published:** August 6, 2026 **Author:** FastNetMon **Content:** **IMPORTANT:** **Action is required for all customers using online licensing.** We have released **[FastNetMon Advanced v2.0.383](http://fastnetmon.com/2026/08/05/fastnetmon-advanced-2-0-383/)** as part of a CA certificate rotation for our online licensing infrastructure. **All customers using online licensing are REQUIRED to upgrade to FastNetMon Advanced v2.0.383 no later than August 14, 2026.** After August 14, 2026, older FastNetMon versions will no longer be able to renew their licenses automatically because they cannot validate the updated CA certificate presented by the licensing service. Please follow our official upgrade [guide](http://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-upgrade-procedure/). ## Important note for Ubuntu and Debian users We recently introduced new release-specific APT repositories and signing keys. If your system is still configured to use the legacy FastNetMon APT repository, please migrate to the current repository before upgrading. See FastNetMon Advanced APT repositories [here](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-apt-repositories/). ## Additional information for older Linux distributions Customers running older Linux distributions should review the [FastNetMon Advanced release lifecycle documentation](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-release-lifecycle/) before proceeding with the upgrade. If you have any questions or encounter any issues during the upgrade, please contact [FastNetMon Support](https://support.fastnetmon.com/hc/en-gb/requests/new). **Categories:** FastNetMon Blog --- ### [FastNetMon Advanced 2.0.383](https://fastnetmon.com/2026/08/06/fastnetmon-advanced-2-0-383/) **Published:** August 6, 2026 **Author:** FastNetMon **Content:** **Release date:** 5 August, 2026 **Version:** 2.0.383 FastNetMon Advanced 2.0.383 is a **mandatory update** for customers using online licensing. This release includes a new CA certificate required for communication with the FastNetMon licensing service as part of our infrastructure update. **All customers using online licensing must upgrade to FastNetMon Advanced v2.0.383 no later than August 14, 2026, to ensure uninterrupted automatic license renewals.** In addition to the licensing changes, the release delivers several improvements across traffic analytics, system reliability, database handling, and LiveView. Full list of changes: - Switched to new CA for licensing server. Mandatory upgrade required for all customers - Moved ASN database files to /var/lib/fastnetmon to prevent their removal in cache folder - Now we return only top 10 items for sudo fcli show hostgroup\_counters\_total - Now we return only top 10 items for sudo fcli show interface\_counters - Added pre-calculation of traffic for Clickhouse to find out top IP Fragments talkers, TCP SYN talkers, ICMP talkers, TCP talkers - Upgrade LiveView to latest version - Added safe version of function db.has\_collection which catches exceptions we discovered as part of auth using algorithm SCRAM-SHA-256 [FastNetMon Advanced documentation](https://fastnetmon.com/docs-fnm-advanced/) [View this release on GitHub](https://github.com/FastNetMon/fastnetmon-advanced-releases/releases/tag/v2.0.383) **Categories:** Releases **Tags:** release --- ### [FastNetMon Community is Now Available on the Ubuntu Snap Store](https://fastnetmon.com/2026/08/04/fastnetmon-community-is-now-available-on-the-ubuntu-snap-store/) **Published:** August 4, 2026 **Author:** FastNetMon **Content:** We're pleased to announce that **FastNetMon Community** is now available as an official package on the **Ubuntu Snap Store**. FastNetMon Community is a high-performance DDoS detection sensor that monitors network traffic using **NetFlow, IPFIX, sFlow, PCAP, and port-mirrored traffic**. It detects traffic anomalies based on configurable thresholds and can automatically notify operators, execute custom scripts, or trigger BGP announcements for automated mitigation. The new Snap package makes it easy to install and keep FastNetMon Community up to date across Ubuntu releases using the standard Snap ecosystem, and it complements our existing installation methods. You can find the package on the Ubuntu Snap Store: <https://snapcraft.io/fastnetmon-community> See FastNetMon Community Edition on GitHub: <https://github.com/pavel-odintsov/fastnetmon> *FastNetMon Community Edition is intended for **small-scale deployments, home labs, and test environments**. For a detailed comparison with FastNetMon Advanced, see the [documentation for edition comparison](https://fastnetmon.com/compare-community-and-advanced/).* **Categories:** FastNetMon Blog, Featured, Press & Newsroom --- ### [VyOS and FastNetMon announce an integration](https://fastnetmon.com/2020/06/30/vyos-and-fastnetmon-integration/) **Published:** June 30, 2020 **Author:** FastNetMon **Content:** **Barcelona, Spain & London, UK — July 01, 2020 -** Sentrium established a partnership with FastNetMon to provide official support for those customers who are interested not only in a reliable router but also in protection against various DDoS attacks. This collaboration will help bring both companies in a position to give more value to current customers and attract new ones. The advantage of such cooperation is the opportunity for customers to get a powerful customizable platform for network devices with the ability to detect and filter out only malicious traffic flowing into or from the customer’s network. VyOS is known as a fully open-source network OS that runs on a wide range of hardware, virtual machines, and cloud providers and offers features for any networks, small and large. > *We are highly entertained when it comes to collaboration with FastNetMon. This partnership is very exciting for both organizations. It combines the solutions which, through defined development and testing methodologies, will satisfy the needs of even the most demanding customers. We believe that the best way to reach and support more small, mid-sized, and enterprise businesses and their clients is via this integration*. > > Yuriy Andamasov, Community and Business Coordinator of VyOS Project > *We are really happy to start our cooperation with VyOS project and offer smooth integration between our products for benefits of the customers. Routing platform configuration for reliable and fast DDoS detection is very challenging task and we’re going to rely on proven and solid platform provided by VyOS team to address this challenge*. > > Pavel Odintsov, Project Founder While the main development of the joint integration of both products are in the process, learn more about using use FastNetMon Advanced with VyOS routing on the links: - [FastNetMon VyOS Netflow configuration](https://fastnetmon.com/fastnetmon-vyos-netflow-configuration/) - [FastNetMon VyOS sFlow v5 configuration](https://fastnetmon.com/fastnetmon-vyos-sflow-v5-configuration/) **About VyOS** VyOS project started in 2013 as a fork of Vyatta Core when the open-source Vyatta version was discontinued. Now VyOS is a fully open-source network OS that provides a wide range of features for any network, from small business to Internet service provider. It runs on commodity x86 hardware from desktop router boards to large servers, as well as virtualized in all popular hypervisors and multiple cloud hosting platforms including VMware, KVM, Xen, Amazon EC2, Microsoft Azure, Google Cloud Platform and more. Its aim is to provide the reliability and user experience of traditional hardware routers, without getting tied to any specified hardware or software vendor. Unified command-line interface and HTTP API for all functions, built-in configuration versioning and archiving, and reversible image upgrades allow network admins to make configuration changes easily. **About FastNetMon** FastNetMon was started as an open-source project for DDoS detection. From the first days of the project, we were heavily committed to the open-source community. FastNetMon protects more than nine thousand customers from DDoS. It can detect all most popular volumetric attack types and immediately block them with BGP blackhole or BGP flow spec rules (in Advanced Edition only). Solid support for all top network vendors provides easy and fast set up on a network. FastNetMon is a very high-performance DDoS detector built on top of multiple packet capture engines: NetFlow, IPFIX, sFlow, and SPAN/port mirror. Instant attack detection (from 2 sec), unlimited scalability (tested up to 2.5 Tbits and 3 millions of flow/s) and rich traffic reports provide reliable protection of your network. ## Media Contacts **VyOS:** Nataliia Korobchenko PR manager <https://sentrium.io>, <https://vyos.io> e-mail: nataliia.korobchenko@sentrium.io phone: +8170-4292-5389 **FastNetMon:** Ekaterina Fateeva Marketing manager <https://fastnetmon.com> e-mail: kate@fastnetmon.com **Categories:** FastNetMon Blog, Partner Highlights **Tags:** integration, partnership, Press Releases --- ### [FastNetMon integration with Radware DefenseFlow](https://fastnetmon.com/2017/02/17/fastnetmon-integration-with-radware-defenseflow/) **Published:** February 17, 2017 **Author:** FastNetMon **Content:** FastNetMon was built with interoperability in mind. Every day we are working hard on protocols and their corner cases. Modern Internet consist of hundreds of protocols and thousands of brands. It’s very complicated to support them all without cooperation. And we are pleased to share result of our cooperation with one of top vendors on cybersecurity services market, Radware. As part of this project Radware’s security experts implemented complete integration of FastNetMon with Radware’s leading network detection and cyber control application, DefenseFlow! This integration introduces significant benefits for customers of both products. We are looking forward and happy to see new companies who want to add integration with our DDoS detection toolkit to make the Internet a safer place! You can find more details [here](https://support.radware.com/app/answers/answer_view/a_id/1011363/~/integration-guidelines-for-fastnetmon-and-defenseflow). **Categories:** FastNetMon Blog, Partner Highlights, Press & Newsroom **Tags:** integration, partnership --- ### [FastNetMon and IP Infusion introduce automated DDoS protection with OcNOS + FastNetMon](https://fastnetmon.com/2026/03/16/fastnetmon-and-ip-infusion-collaborate-on-automated-ddos-protection-with-ocnos/) **Published:** March 16, 2026 **Author:** FastNetMon **Content:** [FastNetMon](http://fastnetmon.com/) and [IP Infusion](https://www.ipinfusion.com/) are collaborating to deliver an open, standards-based DDoS protection solution built on IP Infusion’s OcNOS network operating system and the FastNetMon traffic analysis and mitigation platform. The joint solution combines real-time traffic detection with automated mitigation, enabling operators to detect and stop attacks in seconds using native routing protocols within a disaggregated network architecture. ## **The solution: OcNOS and FastNetMon** The integration brings together two complementary components: - **OcNOS**, a carrier-grade network operating system designed for whitebox routing platforms - **FastNetMon**, a high-performance traffic analysis and automated mitigation platform Together, they form a closed-loop defense system that detects traffic anomalies through real-time telemetry and automatically applies mitigation policies directly at the network edge. ![](https://fastnetmon.com/wp-content/uploads/2026/03/OcNOS-and-FastNetMon-Solution-scaled-1-1024x396.jpg)Unlike traditional inline mitigation appliances, the architecture operates out-of-band, allowing networks to stop attacks without rerouting traffic or introducing additional latency. More details about the solution are available on the IP Infusion solution overview page: <https://www.ipinfusion.com/ocnos-ddos-protection/> ## **How the solution works** OcNOS routers export high-performance sFlow and IPFIX telemetry generated at line rate by hardware ASICs. FastNetMon continuously analyses this telemetry, correlating traffic patterns and identifying anomalies that indicate an attack. When malicious traffic is detected, FastNetMon automatically distributes mitigation rules using standard BGP mechanisms. Depending on the scenario, networks can apply: - **BGP Flow Spec** for precise filtering of malicious traffic flows while keeping legitimate traffic operational - **Remote Triggered Black Hole (RTBH)** routing for immediate protection against large volumetric floods Mitigation rules are withdrawn automatically once the attack subsides, restoring normal traffic flow without manual intervention. ![](https://fastnetmon.com/wp-content/uploads/2026/03/FastNetMon-Solution-with-OcNOS-2-scaled-1-1024x405.webp)A detailed technical overview is available in the joint solution brief: <https://media.ipinfusion.com/Solution-Brief/03-26-Affordable-Automated-DDoS-for-Modern-Networks-with-OcNOS-and-FastNetMon.pdf> ## **Disaggregated architecture advantages** The solution follows a disaggregated networking model in which detection and enforcement scale independently. Operators can expand mitigation capacity by adding routers or increase analytical capacity by scaling software instances, avoiding hardware replacement cycles common in legacy security appliances. By relying entirely on open standards, including BGP Flow Spec, RTBH, sFlow, and IPFIX, the architecture integrates cleanly into multi-vendor environments while reducing operational complexity and vendor lock-in. ## **Architecture benefits in practice** By combining FastNetMon’s detection intelligence with OcNOS routing capabilities, the collaboration provides a practical path toward automated, scalable DDoS defence suitable for service providers, data centres, and large enterprise networks. The solution demonstrates how disaggregated networking and open standards can deliver fast mitigation, operational simplicity, and long-term architectural flexibility compared to legacy security models. **Categories:** FastNetMon Blog, Featured, Partner Highlights, Press & Newsroom --- ### [Network Engineering Community News: July 2026](https://fastnetmon.com/2026/07/30/network-engineering-community-news-july-2026/) **Published:** July 30, 2026 **Author:** FastNetMon **Content:** ⚡️ Network Engineering Community News - from FastNetMon Big news this month: we've launched Netomics, a new self-hosted routing intelligence platform for network operators. We've also shipped a ton of new features, launched our own podcast, rounded up the latest DDoS news, and published two in-depth engineering articles. We hope you enjoy this month's edition! | \| \| \| \| \| \|:-:\| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| Welcome to this edition of Network Engineering Community News! The big news this month is the launch of Netomics, our new self-hosted routing intelligence platform for network operators. We've also shipped new FastNetMon features, launched our FastNetMon Sessions podcast, rounded up the latest DDoS news, and published two in-depth engineering articles. We hope you enjoy this month's edition! \| \|:--\| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| \| \|:-:\| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| ### Introducing Netomics \| \|:--\| \| \| \| \| \|:--\| \| \|:-:\| \| \|:--\| \| \| \| [![](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff9e4351fbcb955078ba327c189f28d8b8b57377a196b7d7db50a5853c7a6dd1/images/netomics_by_fastnetmon_user_interfaces.png)](https://fastnetmon.com/2026/07/06/introducing-netomics-a-self-hosted-routing-intelligence-platform-for-network-operations/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| \| ## Meet Netomics: Self-Hosted Routing Intelligence for Network Operations \| \| We're excited to introduce [**Netomics**](https://netomics.com/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter), a self-hosted routing intelligence platform built for network operators. By bringing together live BGP data, routing history, RPKI validation, IRR and WHOIS data, Netomics eliminates the need to jump between multiple tools during routing investigations. Read more how Netomics helps you gain real-time routing context, while keeping all routing intelligence inside your own infrastructure. \| \| \|:--\| \| \|:--\| \| \| \| [Full announcement](https://fastnetmon.com/2026/07/06/introducing-netomics-a-self-hosted-routing-intelligence-platform-for-network-operations/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| \| \|:-:\| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| ### Product Updates \| \|:--\| \| \| \| \| \|:--\| \| \|:-:\| \| \|:--\| \| \| \| ## What's New? \| \| We've shipped a number of updates across both FastNetMon Advanced and Community Edition. FastNetMon Advanced [**now supports HTTP and HTTPS proxies**](https://fastnetmon.com/2026/07/20/fastnetmon-now-supports-http-and-https-proxies/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter), making deployments behind corporate firewalls and in tightly controlled enterprise environments much easier. Recent releases **[2.0.381](https://fastnetmon.com/2026/07/13/fastnetmon-advanced-2-0-381/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter)** and [**2.0.382**](https://fastnetmon.com/2026/07/20/fastnetmon-advanced-2-0-382/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) also deliver significant improvements to BGP FlowSpec, platform stability, and security. For Community users, we've expanded package availability with **[updated Fedora builds and new EPEL packages for RHEL, AlmaLinux, and Rocky Linux](https://fastnetmon.com/2026/07/06/fastnetmon-community-expands-fedora-and-epel-support/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter)**, simplifying installation and maintenance across Enterprise Linux distributions. \| \| \|:--\| \| \|:--\| \| \|:-:\| \| \| \| \| \| \|:-:\| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| ## Worth Reading \| \|:--\| \| \| \| \| \|:--\| \| ### Learning Mellanox ConnectX-5 \| \| [![](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff9e4351fbcb955078ba327c189f28d8b8b57377a196b7d7db50a5853c7a6dd1/images/concept5.png)](https://fastnetmon.com/2026/07/22/learning-mellanox-connectx-5-cqe-compression-tuning/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| \| A practical guide to tuning Mellanox ConnectX-5 NICs for higher packet rates, including the CQE compression setting that enables 100GbE line-rate packet processing. \| \| [Read Article](https://fastnetmon.com/2026/07/22/learning-mellanox-connectx-5-cqe-compression-tuning/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| \| \| \| \| \|:--\| \| ### Learning VPP: Filtering Packets at 100GbE Line Rate \| \| [![](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff9e4351fbcb955078ba327c189f28d8b8b57377a196b7d7db50a5853c7a6dd1/images/concept4.png)](https://fastnetmon.com/2026/07/02/learning-vpp-filtering-packets-at-100gbe-line-rate/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| \| In this guest post, Denys Haryachyy explains the design behind a high-performance VPP classifier built for DDoS mitigation. \| \| [Read Article](https://fastnetmon.com/2026/07/02/learning-vpp-filtering-packets-at-100gbe-line-rate/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| \| \|:--\| \| \| ## DDoS News \| \|:--\| \| \| \| \| \|:--\| \| ### From Script Kiddies to "Prompt Kiddies" \| \| [![](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff9e4351fbcb955078ba327c189f28d8b8b57377a196b7d7db50a5853c7a6dd1/images/new_llm_built_iot_botnet_tuxbot_v3_evolution_1.png)](https://fastnetmon.com/2026/07/16/new-iot-botnet-reveals-how-llms-are-changing-malware-development/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| \| A newly discovered IoT DDoS botnet appears to have been built with the help of an LLM, providing one of the first real-world examples of AI-assisted malware development. \| \| [Read Story](https://fastnetmon.com/2026/07/16/new-iot-botnet-reveals-how-llms-are-changing-malware-development/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| \| \| \| \| \|:--\| \| ### RustDuck Botnet Targets Internet-Exposed Devices \| \| [![](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff9e4351fbcb955078ba327c189f28d8b8b57377a196b7d7db50a5853c7a6dd1/images/new_rustduck_botnet_ddos_news_fastnetmon_1.png)](https://fastnetmon.com/2026/07/02/new-rustduck-botnet-targets-internet-exposed-devices-and-servers/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| \| A new Rust-based botnet is actively targeting routers, IP cameras, Android TV boxes, and exposed servers \| \| [Read Story](https://fastnetmon.com/2026/07/02/new-rustduck-botnet-targets-internet-exposed-devices-and-servers/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| \| \|:--\| \| \|:--\| \| \|:-:\| \| \| \| \| \| \|:-:\| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| ### Podcast Launch \| \|:--\| \| \| \| \| \|:--\| \| \|:-:\| \| \|:--\| \| \| \| [![](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff9e4351fbcb955078ba327c189f28d8b8b57377a196b7d7db50a5853c7a6dd1/images/podcast_e1.png)](https://youtu.be/Nd83ykfji-I?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| \| ## Introducing FastNetMon Sessions \| \| We're excited to launch **FastNetMon Sessions**, a new podcast featuring 15–20-minute conversations with experts in networks, security, and DDoS defence. We'll be chatting with researchers, operators, and engineers about the work and the ideas shaping the industry. In our first episode, we sit down with Shyam Krishna Khadka to discuss his research into the DDoS scrubbing ecosystem. We hope you enjoy it—and stay tuned, as we've got plenty more conversations coming soon! \| \| \|:--\| \| \|:--\| \| \| \| [See on YouTube](https://youtu.be/Nd83ykfji-I?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| \| \|:-:\| \| \|:-:\| \| \|:--\| \| \| \| \| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| [![Logo](https://eoolnbw.stripocdn.email/content/guids/CABINET_25fbf50d6f886b897f2305af06c298676dd346c8a5de49097728110845f22b79/images/fastnetmon_logo_darkmode_enabled.png "Logo")](https://fastnetmon.com/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| \|:--\| \| Comprehensive solution for DDoS Security \| \| \|:--\| \| \| \| [![CUSTOM_ICON](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff9e4351fbcb955078ba327c189f28d8b8b57377a196b7d7db50a5853c7a6dd1/images/github_logo_icon.png "CUSTOM_ICON")](https://github.com/FastNetMon/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| [![IN](https://eoolnbw.stripocdn.email/content/assets/img/social-icons/logo-black/linkedin-logo-black.png "LinkedIn")](https://www.linkedin.com/company/fastnetmon?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| [![RDT](https://eoolnbw.stripocdn.email/content/assets/img/social-icons/logo-black/reddit-logo-black.png "Reddit")](https://www.reddit.com/r/fastnetmon/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| [![Yt](https://eoolnbw.stripocdn.email/content/assets/img/social-icons/logo-black/youtube-logo-black.png "Youtube")](https://www.youtube.com/@FastNetMon?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| [![BSKY](https://eoolnbw.stripocdn.email/content/assets/img/social-icons/logo-black/bluesky-logo-black.png "BlueSky")](https://bsky.app/profile/fastnetmon.bsky.social?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| [![IG](https://eoolnbw.stripocdn.email/content/assets/img/social-icons/logo-black/instagram-logo-black.png "Instagram")](https://www.instagram.com/fastnetmon?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| [![TT](https://eoolnbw.stripocdn.email/content/assets/img/social-icons/logo-black/tiktok-logo-black.png "TikTok")](https://www.tiktok.com/@fastnetmon?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| [![XCOM](https://eoolnbw.stripocdn.email/content/assets/img/social-icons/logo-black/x-logo-black.png "X")](https://x.com/fastnetmon?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| [![FB](https://eoolnbw.stripocdn.email/content/assets/img/social-icons/logo-black/facebook-logo-black.png "Facebook")](https://www.facebook.com/fastnetmon?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| \|:-:\|:-:\|:-:\|:-:\|:-:\|:-:\|:-:\|:-:\|:-:\| \| \|--:\| \| [Newsletter Archive](https://fastnetmon.com/newsletter/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| [Blog](https://fastnetmon.com/blog/?utm_campaign=NL_Jul_26&utm_medium=email&utm_source=newsletter) \| \| \|:--\| \| \|:--\| \| \|:-:\| \| \| \| \| \| \|:-:\| \| \|:-:\| \| \|:--\| \| \|:-:\| | |---| **Categories:** Newsletter **Tags:** Newsletter --- ### [Network Engineering Community News: June 2026](https://fastnetmon.com/2026/06/30/network-engineering-community-news-june-2026/) **Published:** June 30, 2026 **Author:** FastNetMon **Content:** ⚡️ Network Engineering Community News - from FastNetMon We’ve given the newsletter a bit of a fresh coat of paint, but the goal is the same: keeping you in the loop on what we’re building, sharing interesting DDoS and NetSec updates, and staying connected with the community. Let us know what you think! | \| \| \| \| \| \|:-:\| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| In this edition of Network Engineering Community News, we take you inside our lab for a sneak peek at our new VPP-based inline filtering engine, share Pavel Odintsov's latest NANOG presentation on large-scale BGP monitoring, explore real-world DDoS defence through a customer case study, dive into two in-depth technical articles, and more. Happy reading! \| \|:--\| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| \| \|:-:\| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| ### Lab sneak peek \| \|:--\| \| \| \| \| \|:--\| \| \|:-:\| \| \|:--\| \| \| \| [![](https://eoolnbw.stripocdn.email/content/guids/CABINET_3da2357449f580d634c71eea21148f4b514b09290534a03fe66330ead8eb2f86/images/fastnetmon_product_development_sneak_peek_inline_filtering_solution_in_the_tests_1.png)](https://fastnetmon.com/2026/06/11/sneak-peek-building-a-high-performance-vpp-based-inline-filter-at-fastnetmon/?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| \| ## Building a high-performance inline DDoS filter \| \| FastNetMon is expanding beyond DDoS detection. In this lab sneak peek, we share early results from our in-house VPP-based inline filtering engine, which achieved near-line-rate 100G performance while processing one million filtering rules. See the lab results and learn more about the roadmap \| \| \|:--\| \| \|:--\| \| \| \| [Peek inside the lab](https://fastnetmon.com/2026/06/11/sneak-peek-building-a-high-performance-vpp-based-inline-filter-at-fastnetmon/?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| \| \|:-:\| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| ### From NANOG 97 \| \|:--\| \| \| \| \| \|:--\| \| \|:-:\| \| \|:--\| \| \| \| [![](https://eoolnbw.stripocdn.email/content/guids/CABINET_3da2357449f580d634c71eea21148f4b514b09290534a03fe66330ead8eb2f86/images/nanog97_monitoring_2800_bgp_sessions_using_bmp_protocol_1.png)](https://youtu.be/m992J25_eBY?si=J3AnoMmt3pLn1WfV&utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| \| ## Monitoring 2,800 BGP sessions with BMP \| \| Watch Pavel Odintsov's NANOG 97 presentation on monitoring thousands of BGP sessions using BMP at production scale. If you're interested in BGP monitoring, watch this space — we'll have more to share very soon! \| \| \|:--\| \| \|:--\| \| \| \| [Watch the recording](https://youtu.be/m992J25_eBY?si=J3AnoMmt3pLn1WfV&utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| \| \|:-:\| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| ### Case study \| \|:--\| \| \| \| \| \|:--\| \| \|:-:\| \| \|:--\| \| \| \| [![](https://eoolnbw.stripocdn.email/content/guids/CABINET_3da2357449f580d634c71eea21148f4b514b09290534a03fe66330ead8eb2f86/images/fastnetmon_case_study_joy_services_rtbh_automation_bgp_blackhole_newsletter.png)](https://fastnetmon.com/2026/06/15/case-joy-services-automated-ddos-detection-and-hardware-accelerated-mitigation/?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| \| ## How Joy Services built an automated DDoS defence workflow with FastNetMon \| \| Discover how Joy Services built an automated DDoS defence workflow with FastNetMon, detecting attacks in seconds, automating RTBH mitigation, and gaining visibility into both inbound and outbound attack traffic to keep its cloud network resilient. \| \| \|:--\| \| \|:--\| \| \| \| [Read the case study](https://fastnetmon.com/2026/06/15/case-joy-services-automated-ddos-detection-and-hardware-accelerated-mitigation/?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| \| \|:-:\| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| ### Worth reading \| \|:--\| \| \| \| \| \|:--\| \| \|:-:\| \| \|:--\| \| \| \| [![](https://eoolnbw.stripocdn.email/content/guids/CABINET_3da2357449f580d634c71eea21148f4b514b09290534a03fe66330ead8eb2f86/images/guest_post_by_denys_haryachyy_dpdk_vpp_expert_fastnetmon_newsletter.png)](https://fastnetmon.com/2026/06/17/learning-dpdk-eliminating-nic-receive-drops-at-100gbe/?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| \| ## Guest post: Eliminating NIC Receive Drops at 100GbE \| \| In this guest post, Denys Haryachyy explores why DPDK-based systems can still experience NIC receive drops at 100GbE, even when CPU headroom is available. The article breaks down how interrupt handling, kernel activity, and core scheduling impact RX ring stability, and shows how IRQ affinity tuning and full core isolation can reduce rx\_missed errors by several orders of magnitude under extreme load. \| \| \|:--\| \| \|:--\| \| \| \| [Read now](https://fastnetmon.com/2026/06/17/learning-dpdk-eliminating-nic-receive-drops-at-100gbe/?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| \| \|:-:\| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| ## More from our blog \| \|:--\| \| \| \| \| \|:--\| \| ### What's up with the residential proxy DDoS botnets? \| \| Residential DDoS botnets didn’t disappear after major takedowns. They fragmented, rebounded, and are now quietly larger and more pervasive than ever. \| \| [Read More](https://fastnetmon.com/2026/06/24/the-current-reality-of-residential-ddos-botnets/?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| \| \| \| \| \|:--\| \| ### Ultra Ethernet and 1.6T Standard explained \| \| Ultra Ethernet and 1.6T Ethernet are reshaping data centre design for AI workloads, combining extreme link speeds with smarter traffic handling for large-scale GPU communication and congestion-sensitive clusters. \| \| [Read More](https://fastnetmon.com/2026/06/25/understanding-ultra-ethernet-and-the-1-6t-ethernet-standard/?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| \| \|:--\| \| \| ## Past & upcoming events \| \|:--\| \| \| \| \| \|:--\| \| ### [N](https://viewstripo.email?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter)ext week: NetUK3 \| \| FastNetMon will attend the third NetUK conference. Looking forward to meeting you there! \| \| \| ![](https://eoolnbw.stripocdn.email/content/guids/CABINET_fc06604b104f1c3dbccc791ad6081b55ac13a56d1ba6194593c1d6dc86f4e973/images/nouncalendar5453585.png "06-07/07/2026") 06-07/07/2026 \| \| \|---\| \| \| ![](https://eoolnbw.stripocdn.email/content/guids/CABINET_fc06604b104f1c3dbccc791ad6081b55ac13a56d1ba6194593c1d6dc86f4e973/images/nounlocation5453587.png "London, UK") London, UK \| \| \|---\| \| [More info](https://fastnetmon.com/2026/05/28/netuk3-event-page/?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| \| \| \| \| \|:--\| \| ### Event recap: NANOG 97 \| \| We had a great time in Bellevue, Washington. See the highlight shorts, catch the vibes, and read what stood out. \| \| [NANOG 97 recap](https://fastnetmon.com/2026/06/08/see-you-at-nanog-97/?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| \| \|:--\| \| \|:--\| \| \|:-:\| \| \| \| \| \| \|:-:\| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| [![Logo](https://eoolnbw.stripocdn.email/content/guids/CABINET_25fbf50d6f886b897f2305af06c298676dd346c8a5de49097728110845f22b79/images/fastnetmon_logo_darkmode_enabled.png "Logo")](https://fastnetmon.com/?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| \|:--\| \| Comprehensive solution for DDoS Security \| \| \|:--\| \| \| \| [![CUSTOM_ICON](https://eoolnbw.stripocdn.email/content/guids/CABINET_7e6a8564089fadc148855032a7b90d72f142d3fa863d4d48fa42755254638276/images/github_logo_icon.png "CUSTOM_ICON")](https://github.com/FastNetMon/?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| [![IN](https://eoolnbw.stripocdn.email/content/assets/img/social-icons/logo-black/linkedin-logo-black.png "LinkedIn")](https://www.linkedin.com/company/fastnetmon?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| [![RDT](https://eoolnbw.stripocdn.email/content/assets/img/social-icons/logo-black/reddit-logo-black.png "Reddit")](https://www.reddit.com/r/fastnetmon/?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| [![Yt](https://eoolnbw.stripocdn.email/content/assets/img/social-icons/logo-black/youtube-logo-black.png "Youtube")](https://www.youtube.com/@FastNetMon?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| [![BSKY](https://eoolnbw.stripocdn.email/content/assets/img/social-icons/logo-black/bluesky-logo-black.png "BlueSky")](https://bsky.app/profile/fastnetmon.bsky.social?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| [![IG](https://eoolnbw.stripocdn.email/content/assets/img/social-icons/logo-black/instagram-logo-black.png "Instagram")](https://www.instagram.com/fastnetmon?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| [![TT](https://eoolnbw.stripocdn.email/content/assets/img/social-icons/logo-black/tiktok-logo-black.png "TikTok")](https://www.tiktok.com/@fastnetmon?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| [![XCOM](https://eoolnbw.stripocdn.email/content/assets/img/social-icons/logo-black/x-logo-black.png "X")](https://x.com/fastnetmon?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| [![FB](https://eoolnbw.stripocdn.email/content/assets/img/social-icons/logo-black/facebook-logo-black.png "Facebook")](https://www.facebook.com/fastnetmon?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| \|:-:\|:-:\|:-:\|:-:\|:-:\|:-:\|:-:\|:-:\|:-:\| \| \|--:\| \| [Newsletter Archive](https://fastnetmon.com/newsletter/?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| [Blog](https://fastnetmon.com/blog/?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| \| \|:--\| \| \|:--\| \| \|:-:\| \| \| \| \| \| \|:-:\| \| \|:-:\| \| \|:--\| \| \|:-:\| | |---| **Categories:** Newsletter --- ### [Network Engineering Community News: May 2026](https://fastnetmon.com/2026/05/31/network-engineering-community-news-may-2026/) **Published:** May 31, 2026 **Author:** FastNetMon **Content:** ⚡️ Network Engineering Community News - from FastNetMon We’ve given the newsletter a bit of a fresh coat of paint, but the goal is the same: keeping you in the loop on what we’re building, sharing interesting DDoS and NetSec updates, and staying connected with the community. Let us know what you think! | \| \| \| \| \| \|:-:\| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| In this edition of Network Engineering Community News, we’ve given the newsletter a bit of a fresh coat of paint, but the goal is the same: keeping you in the loop on what we’re building, sharing interesting DDoS and NetSec updates, and staying connected with the community. Let us know what you think! \| \|:--\| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| \| \|:-:\| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| ## Security Advisory: immediate upgrade recommended \| \|:--\| \| \| \| \| \|:--\| \| **Latest FastNetMon release 2.0.380 includes important security fixes addressing multiple vulnerabilities** affecting BGP, Flow Spec, Netflow v9, IPFIX, and packet parsing components. Due to the nature of these issues, **we strongly recommend that all FastNetMon users upgrade to the latest version immediately.** Full details are available in the security advisory and release notes. \| \| [Release notes](https://fastnetmon.com/2026/05/27/fastnetmon-advanced-2-0-380/?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| \| \|:-:\| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| ### Happening now \| \|:--\| \| \| \| \| \|:--\| \| \|:-:\| \| \|:--\| \| \| \| [![](https://eoolnbw.stripocdn.email/content/guids/CABINET_7e6a8564089fadc148855032a7b90d72f142d3fa863d4d48fa42755254638276/images/nanog97.jpg)](https://fastnetmon.com/2026/04/06/see-you-at-nanog-97/?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| \| \| June 1-3, 2026 | Bellevue, WA \| \| \|---\| \| ## Live from NANOG 97! \| \| Greetings from NANOG 97 in Bellevue, WA! We’re already on-site and looking forward to connecting with the community. Pavel Odintsov will be speaking in the Wednesday session on *Monitoring 2,800 BGP Sessions using BMP protocol --* get the details, book a meeting, and follow the updates on our event page. \| \| \|:--\| \| \|:--\| \| \| \| [NANOG 97 Event page](https://fastnetmon.com/2026/04/06/see-you-at-nanog-97/?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| \| \|:-:\| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| ### Worth reading \| \|:--\| \| \| \| \| \|:--\| \| \|:-:\| \| \|:--\| \| \| \| [![](https://eoolnbw.stripocdn.email/content/guids/CABINET_7e6a8564089fadc148855032a7b90d72f142d3fa863d4d48fa42755254638276/images/mapt_newsletter.png)](https://fastnetmon.com/2026/05/06/map-t-in-2026-stateless-ipv4-over-ipv6-translation-and-what-operators-actually-debate-in-production-networks/?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| \| \| FastNetMon Blog \| [May 6 2026](https://fastnetmon.com/2026/05/06/map-t-in-2026-stateless-ipv4-over-ipv6-translation-and-what-operators-actually-debate-in-production-networks/?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| \| \|---\| \| ## MAP-T in 2026: What operators debate in production networks \| \| IPv6 adoption keeps growing, but IPv4 is still deeply embedded in production networks. MAP-T is one of the transition mechanisms helping operators bridge that gap by carrying IPv4 over an IPv6-only core using stateless translation. This article looks at how it works in practice and, more importantly, what operators are currently debating when it comes to real world deployments. \| \| \|:--\| \| \|:--\| \| \| \| [Read now](https://fastnetmon.com/2026/05/06/map-t-in-2026-stateless-ipv4-over-ipv6-translation-and-what-operators-actually-debate-in-production-networks/?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| \| \| \|:-:\|---\| \| \| Share \| \|--:\| \| \|:--\| \| \| \| [![IN](https://eoolnbw.stripocdn.email/content/assets/img/social-icons/logo-black/linkedin-logo-black.png "LinkedIn")](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Ffastnetmon.com%2F2026%2F05%2F06%2Fmap-t-in-2026-stateless-ipv4-over-ipv6-translation-and-what-operators-actually-debate-in-production-networks%2F&utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| [![RDT](https://eoolnbw.stripocdn.email/content/assets/img/social-icons/logo-black/reddit-logo-black.png "Reddit")](https://www.reddit.com/submit?url=https%3A%2F%2Ffastnetmon.com%2F2026%2F05%2F06%2Fmap-t-in-2026-stateless-ipv4-over-ipv6-translation-and-what-operators-actually-debate-in-production-networks%2F&title=MAP-T&utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| [![XCOM](https://eoolnbw.stripocdn.email/content/assets/img/social-icons/logo-black/x-logo-black.png "X")](https://twitter.com/intent/tweet?url=https%3A%2F%2Ffastnetmon.com%2F2026%2F05%2F06%2Fmap-t-in-2026-stateless-ipv4-over-ipv6-translation-and-what-operators-actually-debate-in-production-networks%2F&text=MAP-T+in+2026%3A+What+operators+debate+in+production+networks&hashtags=%23MAP-T+%23MAPT+%23FastNetMon&utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| \|:-:\|:-:\|:-:\| \| \|--:\| \| \|:--\| \| \|:--\| \| \|:-:\| \| \| \| \| \| \|:-:\| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| ## What we’ve been up to \| \|:--\| \| \| \| \| \|:--\| \| \|:-:\| \| \|:--\| \| \| \| \| May was a busy month for the FastNetMon team, with events from Taipei to Europe to Washington. It was a great month of connecting with the networking and telecom community -- read the highlights below! \| \| \|:-:\| \| \|---\| \| \|:--\| \| \|:-:\| \| \| \| \| \| \|:-:\| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| [![](https://eoolnbw.stripocdn.email/content/guids/CABINET_7e6a8564089fadc148855032a7b90d72f142d3fa863d4d48fa42755254638276/images/virgil_at_itw.png)](https://fastnetmon.com/2026/05/22/see-you-at-itw-2026/?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| \|:-:\| \| \| Washington DC \| May 18–21, 2026 \| \| \|---\| \| ### ITW 2026 \| \| ITW delivered as always --Washington was all about back-to-back meetings, reconnecting with partners, clients, and new conversations. \| \| [Read our recap](https://fastnetmon.com/2026/05/22/see-you-at-itw-2026/?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| \| \|:--\| \| \| [![](https://eoolnbw.stripocdn.email/content/guids/CABINET_7e6a8564089fadc148855032a7b90d72f142d3fa863d4d48fa42755254638276/images/outi_at_ripe.png)](https://fastnetmon.com/2026/05/22/see-you-at-ripe-92/?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| \|:-:\| \| \| Edinburgh, Scotland \| [18–22 May 2026](https://viewstripo.email?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| \| \|---\| \| ### RIPE 92 \| \| RIPE week in beautiful Edinburgh in summary: routing security talks, operator discussions, coffees, pubs, and plenty of catching up with the community. \| \| [Read our recap](https://fastnetmon.com/2026/05/22/see-you-at-ripe-92/?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| \| \|:--\| \| \|:--\| \| \| \| [![](https://eoolnbw.stripocdn.email/content/guids/CABINET_7e6a8564089fadc148855032a7b90d72f142d3fa863d4d48fa42755254638276/images/pavel_at_twnog.png)](https://fastnetmon.com/2026/05/16/see-you-at-taiwan-internet-week-twnog-7/?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| \| \| Taiwan, Taipei \| 12–15 May 2026 \| \| \|---\| \| ### TWNOG \| \| A busy week in Taipei with Pavel joining a Taiwan Internet Week panel on NIS2 resilience and presenting at TWNOG 7 about the realities of terabit-scale DDoS detection. \| \| [Read our recap](https://fastnetmon.com/2026/05/16/see-you-at-taiwan-internet-week-twnog-7/?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| \| \|:--\| \| \| [![](https://eoolnbw.stripocdn.email/content/guids/CABINET_7e6a8564089fadc148855032a7b90d72f142d3fa863d4d48fa42755254638276/images/image.jpeg)](https://fastnetmon.com/2026/05/11/see-you-at-datacenter-world-2026/?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| \|:-:\| \| \| Bucharest, Romania \| May 7th 2026 \| \| \|---\| \| ### Datacenter Forum 2026 \| \| Virgil spent a great day in Bucharest talking with data centre and cloud teams about AI infrastructure, scaling challenges, and, of course, the latest in DDoS protection. \| \| [Read our Rrecap](https://fastnetmon.com/2026/05/11/see-you-at-datacenter-world-2026/?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| \| \|:--\| \| \|:--\| \| \|:-:\| \| \| \| \| \| \|:-:\| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| ## DDoS News \| \|:--\| \| \| \| \| \|:--\| \| ### KimWolf DDoS botnet operator arrested \| \| \| May 25, 2026 \| \| \|---\| \| Canadian authorities have arrested a 23-year-old man suspected of operating the KimWolf IoT DDoS-for-hire botnet. \| \| [Read More](https://fastnetmon.com/2026/05/25/kimwolf-ddos-botnet-operator-arrested/?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| \| \| \| \| \|:--\| \| ### Ubuntu and Canonical services disrupted by a DDoS attack \| \| \| May 4, 2026 \| \| \|---\| \| Ubuntu users experienced widespread service disruptions after a sustained DDoS attack. \| \| [Read More](https://fastnetmon.com/2026/05/04/ubuntu-and-canonical-services-disrupted-by-ddos-attack/?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| \| \|:--\| \| \| ## See you at these upcoming events! \| \|:--\| \| \| \| \| \|:--\| \| ### [THIS](https://viewstripo.email?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) WEEK: NANOG 97 \| \| The team is already at Bellevue, and happy to meet! Also don't miss out Pavel's talk about monitoring 2800 BGP sessions. \| \| \| ![10.03.23](https://eoolnbw.stripocdn.email/content/guids/CABINET_fc06604b104f1c3dbccc791ad6081b55ac13a56d1ba6194593c1d6dc86f4e973/images/nouncalendar5453585.png "01-03/06/2026")01-03/06/2026 \| \| \|---\| \| \| ![4375 Cinder Bank, Climax](https://eoolnbw.stripocdn.email/content/guids/CABINET_fc06604b104f1c3dbccc791ad6081b55ac13a56d1ba6194593c1d6dc86f4e973/images/nounlocation5453587.png "Bellevue, WA")Bellevue, WA \| \| \|---\| \| [More info](https://fastnetmon.com/2026/04/06/see-you-at-nanog-97/?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| \| \| \| \| \|:--\| \| ### NetUK3 \| \| FastNetMon will be joining NetUK's third conference in July. If you're in London, let's catch up! \| \| \| ![10.03.23](https://eoolnbw.stripocdn.email/content/guids/CABINET_fc06604b104f1c3dbccc791ad6081b55ac13a56d1ba6194593c1d6dc86f4e973/images/nouncalendar5453585.png "06-07/07/2026")06-07/07/2026 \| \| \|---\| \| \| ![4375 Cinder Bank, Climax](https://eoolnbw.stripocdn.email/content/guids/CABINET_fc06604b104f1c3dbccc791ad6081b55ac13a56d1ba6194593c1d6dc86f4e973/images/nounlocation5453587.png "The Brewery, London")The Brewery, London \| \| \|---\| \| [More info](https://fastnetmon.com/2026/05/28/netuk3-event-page/?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| \| \|:--\| \| \|:--\| \| \|:-:\| \| \| \| \| \| \|:-:\| \| \|:-:\| \| \|:--\| \| \| \| \| \| \|:-:\| \| \|:--\| \| \|:-:\| \| \| \| \| [![Logo](https://eoolnbw.stripocdn.email/content/guids/CABINET_25fbf50d6f886b897f2305af06c298676dd346c8a5de49097728110845f22b79/images/fastnetmon_logo_darkmode_enabled.png "Logo")](https://fastnetmon.com/?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| \|:--\| \| Comprehensive solution for DDoS Security \| \| \|:--\| \| \| \| [![CUSTOM_ICON](https://eoolnbw.stripocdn.email/content/guids/CABINET_7e6a8564089fadc148855032a7b90d72f142d3fa863d4d48fa42755254638276/images/github_logo_icon.png "CUSTOM_ICON")](https://github.com/FastNetMon/?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| [![IN](https://eoolnbw.stripocdn.email/content/assets/img/social-icons/logo-black/linkedin-logo-black.png "LinkedIn")](https://www.linkedin.com/company/fastnetmon?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| [![RDT](https://eoolnbw.stripocdn.email/content/assets/img/social-icons/logo-black/reddit-logo-black.png "Reddit")](https://www.reddit.com/r/fastnetmon/?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| [![Yt](https://eoolnbw.stripocdn.email/content/assets/img/social-icons/logo-black/youtube-logo-black.png "Youtube")](https://www.youtube.com/@FastNetMon?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| [![BSKY](https://eoolnbw.stripocdn.email/content/assets/img/social-icons/logo-black/bluesky-logo-black.png "BlueSky")](https://bsky.app/profile/fastnetmon.bsky.social?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| [![IG](https://eoolnbw.stripocdn.email/content/assets/img/social-icons/logo-black/instagram-logo-black.png "Instagram")](https://www.instagram.com/fastnetmon?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| [![TT](https://eoolnbw.stripocdn.email/content/assets/img/social-icons/logo-black/tiktok-logo-black.png "TikTok")](https://www.tiktok.com/@fastnetmon?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| [![XCOM](https://eoolnbw.stripocdn.email/content/assets/img/social-icons/logo-black/x-logo-black.png "X")](https://x.com/fastnetmon?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| [![FB](https://eoolnbw.stripocdn.email/content/assets/img/social-icons/logo-black/facebook-logo-black.png "Facebook")](https://www.facebook.com/fastnetmon?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| \|:-:\|:-:\|:-:\|:-:\|:-:\|:-:\|:-:\|:-:\|:-:\| \| \|--:\| \| [Newsletter Archive](https://fastnetmon.com/newsletter/?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| [Blog](https://fastnetmon.com/blog/?utm_campaign=NL_March_26&utm_medium=email&utm_source=newsletter) \| \| \|:--\| \| \|:--\| \| \|:-:\| \| \| \| \| \| \|:-:\| \| \|:-:\| \| \|:--\| \| \|:-:\| | |---| **Categories:** Newsletter **Tags:** Newsletter --- ### [Learning VPP: Inside TupleMerge, the ACL Plugin’s Classifier](https://fastnetmon.com/2026/09/07/learning-vpp-inside-tuplemerge-the-acl-plugins-classifier/) **Published:** September 7, 2026 **Author:** FastNetMon **Content:** ![Portrait of a man with short dark hair and light stubble, wearing a dark gray T-shirt, facing the camera (circular crop).](https://fastnetmon.com/wp-content/uploads/2026/06/Denys-Haryachyy-FastNetMon-Guest-Blog.png) *This post is a repost of a [technical blog originally published by Denys Haryachyy](https://haryachyy.wordpress.com/2026/07/13/learning-vpp-inside-tuplemerge-the-acl-plugins-classifier/), shared here with permission as part of ongoing research and engineering work around FastNetMon’s inline traffic processing capabilities*. > **TL;DR.** **TupleMerge**, the classifier inside VPP’s ACL plugin, is tuple-space search plus one liberty: a rule may live in a table *coarser* than its own mask. Insert = *join or relax*; buckets past 39 candidates *split*; lookup = one probe per merged partition into a single shared bihash, plus an exact re-verify of every candidate. Worst case per packet: **P probes + 39·P exact checks**. The [previous post](https://haryachyy.wordpress.com/2026/06/17/vpp-packet-filtering-100gbe-line-rate/) compared plain TSS and TupleMerge at the trade-off level. This one opens the hood: how the merge happens, rule by rule, in `hash_lookup.c`, and what a lookup costs. TupleMerge is on by default (`use_tuple_merge = 1`). ## The Machinery Three structures. **Partitions** are the merged tables, one mask each, kept sorted by their best rule’s position. **One shared [bihash\_48\_8](https://haryachyy.wordpress.com/2026/06/16/vpp-bihash-lock-free-hash-table/)** holds every partition’s entries — a partition id in 16 spare key bits keeps them apart. **`colliding_rules`** is the list on each hash entry, where the relaxed-away bits are re-checked. ![TupleMerge data structures: partitions ordered by best rule position feed one shared bihash_48_8 keyed by the masked 5-tuple plus a partition id; a hit yields a colliding_rules list of at most 39 candidates, each re-verified against its full mask.](https://haryachyy.wordpress.com/wp-content/uploads/2026/07/vpp-tuplemerge-machinery.png)Figure 1: The whole engine — few partitions, one shared hash, and a bounded candidate list per bucket doing the exact work the coarse key skipped.## Two Rulesets to Follow Two rulesets run through the rest of the post. **Ruleset A** — a slice of a general ACL: four rules, four mask shapes. **Ruleset B** — the canonical DDoS filter ([CISA’s source-port list](https://www.cisa.gov/news-events/alerts/2014/01/17/udp-based-amplification-attacks)): five reflection rules of one shape, dropping UDP from the amplification ports. ``` Ruleset A — general ACL (4 shapes) #1 dst 203.0.113.0/24 #2 dst 203.0.113.64/26 #3 dst 192.0.2.9/32 #4 src 198.51.100.0/24 dport 443 Ruleset B — reflection filter (1 shape) drop udp → dst 203.0.113.45/32 #1 src-port 53 (DNS) #2 src-port 123 (NTP) #3 src-port 1900 (SSDP) #4 src-port 11211 (memcached) #5 src-port 19 (CharGen) ``` ## Insert: Join, Relax, or Split Merging happens per rule, at insert. A rule **joins** any partition whose mask is a subset of its own (key truncated to the table mask; full mask kept for verify). If none fits, the plugin creates one with a **relaxed** mask. Relax compares the two address prefix lengths and, when they differ by more than 4 bits, drops the *less specific* address together with its port (source address → source port, dest → dest port); protocol and other exact-match fields are never touched. It then shortens the surviving prefix (`/32 → /26`, and so on), reverting the step entirely if the coarser mask would stop matching the rule. If a bucket’s chain exceeds `TM_SPLIT_THRESHOLD` (default 39, tunable — the paper’s collision limit *c*), `split_partition()` carves a finer mask. ![Animation comparing insert for two rulesets. Ruleset A: rule 1 relaxes dst /24 to /20 and creates partition P_dst, rules 2 and 3 join it (buckets 203.0.112.0 and 192.0.0.0), rule 4 constrains src so it starts partition P_src; four shapes become two partitions. Ruleset B: five UDP reflection rules — the relax heuristic drops the source port from the key, so all five collide into one bucket.](https://haryachyy.wordpress.com/wp-content/uploads/2026/07/vpp-tuplemerge-insert-cmp-v2.gif)Animation: the same relax heuristic, opposite outcomes — Ruleset A merges to two partitions, Ruleset B collapses into one 5-deep bucket.**Ruleset A merges:** `#1` relaxes to `dst /20` (P\_dst), `#2` and `#3` join it — `#1`/`#2` share bucket `203.0.112.0` (their `203.0.113.x` dst masked to `/20`), `#3` lands in `192.0.0.0`; `#4` constrains src, so it starts P\_src — four shapes, **two partitions**. **Ruleset B collapses:** with `dst /32` far more specific than the unconstrained source, relax drops the source port (and shortens dst to `/26`), so all five rules share one key and pile into a **single 5-deep bucket**. The difference is *what* relax drops: in A the weaker address is always empty (`#1`’s source, `#4`’s destination), so nothing that separates rules is lost; in B the port dropped with the empty source is the *source port* — the one field telling the five rules apart. Same heuristic, opposite outcome. ## Lookup: Probes, Verifies, and One Early Exit The per-packet loop (`multi_acl_match_get_applied_ace_index`) walks the sorted partitions: for each, six ANDs build the masked key, one bihash probe, then an exact re-check of every candidate. ![Animation comparing lookup for the two rulesets. Ruleset A: the packet probes partition P_dst, verifies the two rules sharing its bucket, sets best position 1, then skips partition P_src by the priority early-exit — one probe, two verifies. Ruleset B: the packet's single probe hits the five-deep collided bucket and verifies all five rules by source port to find the one match — one probe, five verifies.](https://haryachyy.wordpress.com/wp-content/uploads/2026/07/vpp-tuplemerge-lookup-cmp-v2.gif)Animation: one packet, two rulesets — A breaks early after one probe and two verifies; B pays a five-way verify in its single collided bucket.Two rules govern the walk. A hit can’t end the loop — priorities are scattered across partitions, so only the priority sort can break early. And the coarse key can only *over*-match (a wrong rule the verify rejects), never hide a real one — a match is never lost. In **Ruleset A** the packet probes P\_dst, verifies two rules, and the sort breaks before P\_src: one probe, two verifies. In **Ruleset B** one probe hits the 5-deep bucket and pays a five-way verify. ## The Verdict: When TupleMerge Wins, When It Loses The scoreboard falls out of the partition counts, against the plain-TSS baseline of one exact table per shape. ![Two panels. Top: four rules of four different mask shapes — plain TSS builds 4 tables and pays 4 probes per packet, TupleMerge merges to 2 partitions and pays 1 to 2 probes plus at most 2 verifies, so TupleMerge wins. Bottom: a reflection drop filter that drops UDP to victim 203.0.113.45/32 from amplification source ports 53, 123, 1900, 11211 and 19 — one mask shape: plain TSS uses 1 table and 1 probe with no verify, while TupleMerge's relax heuristic drops the source port from the key, collapsing all five rules into one bucket for 1 probe plus 5 verifies with a 48-byte key, so plain TSS wins.](https://haryachyy.wordpress.com/wp-content/uploads/2026/07/vpp-tuplemerge-ddos-vs-tss.png)Figure 2: The same trade-off from both sides — TupleMerge wins when many shapes merge, and loses on a uniform reflection filter where plain TSS is already at a single probe.**Ruleset A — TupleMerge wins:** four shapes cost TSS four tables → four probes; TupleMerge’s two partitions cost one or two probes and ≤2 verifies, and the gap grows with every added shape. **Ruleset B — plain TSS wins:** one shape is one exact table → one probe, no verify (its floor); TupleMerge’s collision costs one probe plus a five-way verify, on a 48-byte key. Three costs bound the loss: the 39 cap holds only while `split_partition()` can find a separating mask; the 48-byte key is heavier than an exact per-shape key; and a miss that false-hits a full bucket still pays the whole verify list — worst case **P probes + 39·P checks**. Rule of thumb: many shapes that merge → TupleMerge wins; already one or a few shapes (a reflection filter) → plain TSS wins. ## Summary 1. TupleMerge = TSS + one liberty: a rule may live in a partition coarser than its mask; the relaxed-away bits are re-checked on every hit. 2. Insert = join or relax (pre-coarsened so later rules pile in); a bucket past 39 candidates splits. 3. Lookup, per partition: 6 ANDs + 1 probe + up to 39 verifies; only the priority sort breaks early. Worst case = P probes + 39·P checks. 4. Many shapes that merge into few partitions → TupleMerge wins; already one or a few shapes (a reflection filter) → plain TSS wins. ## References - [Daly et al. — TupleMerge: Fast Software Packet Processing for Online Packet Classification (IEEE/ACM ToN 2019)](https://nonsns.github.io/paper/rossi19ton.pdf) - [Srinivasan, Suri & Varghese — Packet Classification using Tuple Space Search (SIGCOMM ’99)](https://dl.acm.org/doi/10.1145/316194.316216) - [VPP `acl/hash_lookup.c`](https://github.com/FDio/vpp/blob/master/src/plugins/acl/hash_lookup.c) - [VPP `acl/public_inlines.h`](https://github.com/FDio/vpp/blob/master/src/plugins/acl/public_inlines.h) - [Learning VPP: Filtering Packets at 100GbE Line Rate](https://haryachyy.wordpress.com/2026/06/17/vpp-packet-filtering-100gbe-line-rate/) - [Learning VPP: Inside bihash, the Lock-Free Hash Table](https://haryachyy.wordpress.com/2026/06/16/vpp-bihash-lock-free-hash-table/) - [CISA — UDP-Based Amplification Attacks (Alert TA14-017A)](https://www.cisa.gov/news-events/alerts/2014/01/17/udp-based-amplification-attacks) - [APNIC — DDoS defences in the terabit era: SSDP, memcached](https://blog.apnic.net/2018/12/05/ddos-defences-in-the-terabit-era-ssdp-memcached/) **Categories:** FastNetMon Blog, Featured **Tags:** Network Security Insights --- ### [Hardware-in-the-Loop CI: Line-Rate VPP Testing over Tailscale](https://fastnetmon.com/2026/08/28/hardware-in-the-loop-ci-line-rate-vpp-testing-over-tailscale/) **Published:** August 28, 2026 **Author:** FastNetMon **Content:** ![Portrait of a man with short dark hair and light stubble, wearing a dark gray T-shirt, facing the camera (circular crop).](https://fastnetmon.com/wp-content/uploads/2026/06/Denys-Haryachyy-FastNetMon-Guest-Blog.png) *This post is a repost of [a technical blog originally published by Denys Haryachyy](https://haryachyy.wordpress.com/2026/06/29/hardware-in-the-loop-ci-line-rate-vpp-testing-over-tailscale/), shared here with permission as part of ongoing research and engineering work around FastNetMon’s inline traffic processing capabilities*. > **TL;DR.** Testing a data plane at **100GbE line rate** needs real NICs running **VPP** — which no cloud CI runner has. So an ephemeral **GitHub Actions** runner joins a private two-machine lab over **Tailscale**, deploys its code to a scratch tree, pulls a fresh base image, brings up a **VPP** device under test (auto-recovering a wedged NIC via IPMI), drives a **TRex** generator through a profile sweep, and gates the merge on per-profile line-rate floors — verified on both sides of the wire. Jobs queue on the single lab, and every run tears itself down. Unit tests don’t tell you whether your **VPP** forwarding plane still does 100GbE line rate after a refactor. For that you need real hardware in the loop — reached from CI, benchmarked on every push, and cleaned up after. ![Cloud runner driving a private line-rate lab over Tailscale.](https://haryachyy.wordpress.com/wp-content/uploads/2026/06/ci-architecture-logos-2.png)Figure 1: A cloud runner reaches a private two-machine lab over Tailscale, drives the TRex generator and the VPP DUT, and recovers a wedged NIC out-of-band via IPMI.## The Problem A cloud runner is a VM with a virtual NIC. It can’t run **VPP** on a physical 100GbE adapter, generate ~142 Mpps, or measure what a real DUT forwards. That hardware lives in a private lab with no public address — so the question is **how a cloud runner safely drives hardware it can’t see.** ## One Lab, One Job at a Time A physical lab serves one test at a time — two jobs can’t share one NIC pair. A GitHub Actions `concurrency` group with `cancel-in-progress: false` serializes them: a second push waits its turn instead of colliding on the wire, and is never dropped. ![CI jobs queueing on a single shared hardware lab via a concurrency group.](https://haryachyy.wordpress.com/wp-content/uploads/2026/06/ci-queued-jobs-concurrency-2.png)Figure 2: The lab is a single shared resource, so jobs queue through a concurrency group rather than fighting over the NIC.## The Run, End to End Every run follows the same arc — and every stage cleans up after itself: ![CI run lifecycle stages.](https://haryachyy.wordpress.com/wp-content/uploads/2026/06/hw-ci-run-lifecycle-bringup-bench-teardown.png)Figure 3: Join the tailnet, deploy, guarded bring-up, bench, assert floors, teardown.## Tailscale Auth: Keys and ACLs The lab has no public IP. The runner joins its Tailscale mesh per job, and the control is all in the auth: - **Ephemeral, tagged, single-use key** (a CI secret): the node is pre-authorized, tagged `tag:ci`, and removed automatically when the job ends. - **An ACL that scopes it:** `tag:ci` may reach `tag:lab` on SSH and nothing else — a leaked key still can’t roam. - **No inbound exposure:** the runner dials out; the lab stays dark to the public internet. ![Tailscale auth-key and ACL control for the CI runner.](https://haryachyy.wordpress.com/wp-content/uploads/2026/06/ci-tailscale-auth-logos-2.png)Figure 4: A tagged, single-use key admits the runner; an ACL confines it to SSH on the lab; the node expires with the job. ``` "acls": [ // the ephemeral CI node may only SSH the lab machines { "action": "accept", "src": ["tag:ci"], "dst": ["tag:lab:22"] }] ``` ## Isolation A shared lab is also a development lab, so CI must touch nothing it didn’t bring: - **Scratch checkout:** the runner rsyncs to a dedicated scratch tree, not the dev checkout, and the container mounts that — so it runs exactly the code under test. - **Fresh base image every run,** pulled from the registry — never a stale local cache (the bug that once slipped a debug build into a perf test). ## Guarded Bring-Up Bringing a 100GbE NIC up under VPP can hard-lock the host. A watcher tells a transient miss from a real wedge; on a wedge it power-cycles the box over **IPMI** — out of band, independent of the hung OS — and retries, instead of hanging the job. ![Guarded bring-up flowchart with IPMI wedge recovery.](https://haryachyy.wordpress.com/wp-content/uploads/2026/06/ci-guarded-bringup-ipmi-recovery.png)Figure 5: A wedged NIC is power-cycled out-of-band via IPMI, not waited out.## Verifying Line Rate Line rate is verified on **both** sides of the wire, not assumed: - **Generator:** `tx_util = 100 %` means no idle bit-times — it really is offering line rate (~142 Mpps at 64 B). - **DUT:** per-worker vectors ÷ time = Mpps processed; `rx_missed ≈ 0` proves the NIC kept up. - **Gate:** each profile’s floor sits a few percent below its ceiling — catches regressions without tripping on jitter. ![Line rate verified on both the generator and the DUT.](https://haryachyy.wordpress.com/wp-content/uploads/2026/06/ci-line-rate-verify-logos-2.png)Figure 6: Read line rate off both ends — `tx_util` and the DUT rate with `rx_missed ≈ 0` — against a floor. ``` # generator (TRex) # DUT data plane, over the sample windowtx_pps 142.0 Mpps show runtime -> sum(Vectors)/seconds = Mppstx_util 100.0 % rx_missed_errors 0 # nothing dropped before software ``` ## Self-Cleaning Teardown On success, failure, or cancel, the run stops the containers *gracefully* (a hard kill is what wedges the firmware), then removes the containers, every lab image, and the scratch checkout from both hosts. The lab is left exactly as CI found it — powered on, idle, holding none of CI’s code or images. ## The Workflow ``` name: hw-line-rateon: { push: { branches: ['**'] } }concurrency: # one job on the lab at a time group: hw-lab cancel-in-progress: falsejobs: line-rate: runs-on: ubuntu-latest # an ordinary cloud runner steps: - uses: actions/checkout@v4 - uses: tailscale/github-action@v3 with: { authkey: ${{ secrets.TS_AUTHKEY }} } # ephemeral, tag:ci - name: Deploy + base + guarded bring-up run: | for h in "$GEN_HOST" "$DUT_HOST"; do rsync -az --delete ./ "ci@$h:~/ci-scratch/"; done ssh ci@$DUT_HOST 'ENSURE_BASE_FORCE=1 ./labs/hw/ensure-base-image.sh' ./labs/hw/bringup-guarded.sh --watch-secs 600 - name: Bench + assert line-rate floors run: ./labs/hw/bench.sh && ./labs/hw/assert-floors.sh - name: Tear down — leave no trace if: always() run: ./labs/hw/teardown.sh ``` ## Summary 1. Real line-rate testing needs real hardware; a cloud runner orchestrates it, doesn’t host it. 2. **Tailscale** admits the ephemeral runner with a tagged single-use key + an ACL — no public exposure. 3. Serialize jobs on the single lab; isolate CI’s code; pull a fresh base every run. 4. Guard the NIC bring-up; recover wedges out-of-band via **IPMI**. 5. Verify line rate on both sides, gate on floors, and tear everything down. ## References - [Tailscale — GitHub Action](https://tailscale.com/kb/1276/tailscale-github-action) - [Tailscale — Access Controls (ACLs)](https://tailscale.com/kb/1018/acls) - [GitHub Actions — Concurrency](https://docs.github.com/actions/using-jobs/using-concurrency) - [Cisco TRex](https://trex-tgn.cisco.com/) - [FD.io VPP](https://fd.io/) - [ipmitool](https://github.com/ipmitool/ipmitool) — out-of-band BMC control **Categories:** FastNetMon Blog, Featured **Tags:** Network Security Insights --- ### [Learning VPP: Inside bihash, the Lock-Free Hash Table](https://fastnetmon.com/2026/07/31/learning-vpp-inside-bihash-the-lock-free-hash-table/) **Published:** July 31, 2026 **Author:** FastNetMon **Content:** ![Portrait of a man with short dark hair and light stubble, wearing a dark gray T-shirt, facing the camera (circular crop).](https://fastnetmon.com/wp-content/uploads/2026/06/Denys-Haryachyy-FastNetMon-Guest-Blog.png) *This post is a repost of a [technical blog originally published by Denys Haryachyy](http://haryachyy.wordpress.com/2026/06/16/vpp-bihash-lock-free-hash-table/), shared here with permission as part of ongoing research and engineering work around FastNetMon’s inline traffic processing capabilities*. > **TL;DR — everything that matters, in one paragraph.** **`bihash`** (the *bounded-index extensible hash*, `clib_bihash` in VPP) is the hash table behind almost every VPP table — FIB, L2, NAT sessions, ACL flow caches. Its defining property is **lock-free lookups**: a reader **never takes a lock**, so millions of packets per second can probe it concurrently with no contention. The layout is a fixed **bucket array** (`2^log2` buckets); each bucket points to a **page** of a few **key-value pairs (KVPs)** that a lookup scans linearly. Collisions are handled by **growing the page** (4 → 8 → 16 KVPs) — that’s the “extensible” part. Writers take a **per-bucket spinlock**, build the new page, and **atomically swap** the bucket pointer; readers detect an in-flight change via a generation counter and simply **retry**. The name encodes the sizes: **`bihash_48_8`** is a 48-byte key and an 8-byte value. Size it with one number — `log2` of the bucket count — and pre-allocate the memory pool up front. At line rate you can’t afford a mutex on a lookup. A hash table that 140 million packets a second hammer concurrently needs reads that never block and never bounce a cache line between cores. That’s what bihash is for. [![Figure 1: bihash structure — a key is hashed and masked to a slot in the fixed bucket array; each non-empty bucket points to a page of K key-value pairs scanned linearly to the value. Keys A and B collide and share one bucket's page.](https://haryachyy.wordpress.com/wp-content/uploads/2026/06/bihash-fig1-3.png)](https://haryachyy.wordpress.com/wp-content/uploads/2026/06/bihash-fig1-3.png)Figure 1: bihash structure (separate chaining) — a key is hashed and masked (`hash & (nbuckets-1)`) to a slot in the fixed bucket array; each non-empty bucket points to a page of K key-value pairs scanned linearly to the value. Keys A and B collide → they share one bucket’s page.## The Structure: Buckets, Pages, KVPs A bihash is three layers (Figure 1): 1. **Bucket array** — a flat array of `2^log2_nbuckets` buckets, fixed at init. Hashing the key picks one bucket. 2. **Bucket** — a single machine word holding the **offset** to a page plus `log2_pages` (how big that page is). Empty buckets are zero. 3. **Page of KVPs** — an array of `BIHASH_KVP_PER_PAGE` **key-value pairs**. A lookup reads the bucket, finds its page, and **linearly scans** the KVPs comparing keys. With a few entries per page, that scan is effectively O(1) and stays in one or two cache lines. The KVP sizes are baked into the type name: **`bihash_48_8`** stores a 48-byte key and an 8-byte value (so a packet’s full tuple as the key, a result/index as the value). VPP ships `bihash_8_8`, `_16_8`, `_24_8`, `_48_8`, and more — you pick the smallest key that holds your data. ## Lock-Free Lookups — the Key Trick This is the part worth understanding. A lookup does **no locking at all**: [![Figure 2: The lock-free reader — read the bucket (one atomic word), scan its page, and return the value; the only retry is if the bucket changed mid-scan. No lock is taken.](https://haryachyy.wordpress.com/wp-content/uploads/2026/06/bihash-reader-2.png)](https://haryachyy.wordpress.com/wp-content/uploads/2026/06/bihash-reader-2.png)Figure 2: The lock-free **reader** — read the bucket (one atomic word), scan its page, return the value. It takes *no lock*; the only retry is if the bucket changed mid-scan.[![Figure 3: The writer — serialize on a per-bucket spinlock, build a new page, atomic-swap the bucket word, then unlock. Readers never block on it.](https://haryachyy.wordpress.com/wp-content/uploads/2026/06/bihash-writer-1.png)](https://haryachyy.wordpress.com/wp-content/uploads/2026/06/bihash-writer-1.png)Figure 3: The **writer** — serialize on a per-bucket spinlock, build a fresh page, **atomic-swap** the bucket word, then unlock. Readers never block behind it.The bucket is a single word, read atomically. A writer never mutates a live page in place — it **builds a fresh page**, then **atomically overwrites the bucket word** to point at it. So a reader either sees the old bucket (and the old, still-valid page) or the new one — never a torn state. To catch the rare case where the bucket changes *during* a scan, each bucket carries a small **generation/`change` counter**; if it moved, the reader re-reads the bucket and scans again. Writers serialize on a **per-bucket spinlock**, so two inserts to the same bucket don’t race — but they never block readers. The payoff: lookups scale linearly with cores. No shared lock, no cache-line ping-pong on a mutex, no reader ever parked behind a writer. ## Extensible: Collisions Grow the Bucket When two keys hash to the same bucket and its page is full, bihash doesn’t chain or probe elsewhere — it **doubles the page**. A 4-KVP page becomes an 8-KVP page (a bigger `log2_pages`), the entries are copied in, and the bucket is swapped to the new page. Lookups still scan one contiguous page; they’re just slightly longer. This keeps the common case (a near-empty bucket) at a single short scan while gracefully absorbing hot buckets — hence *extensible*. If a bucket would grow past the configured maximum, the insert fails rather than degrading unboundedly — a signal that the table is undersized for the working set. ## Sizing It A bihash is configured with essentially **one knob**: `log2` of the bucket count (plus a memory budget for the pages). More buckets means fewer collisions and shorter scans, at the cost of memory you allocate **up front** from a dedicated heap — bihash never calls `malloc` on the data path. A practical rule: size the bucket count so the expected entries land **roughly one per bucket**. For a flow cache holding a worker’s working set of, say, 512 K flows, `log2 = 19` (≈ 512 K buckets) keeps almost every lookup a single-entry scan. Oversizing wastes memory; undersizing turns lookups into longer page scans and risks insert failures on hot buckets. ## Using bihash: API Notes A few practical rules from the VPP documentation for when you actually wire one up: - **Pick a template by key/value size.** Include e.g. `vppinfra/bihash_8_8.h` (VPP ships 8/16/20/24/40/48-byte keys, `u8 *` vector keys, and 8-byte values) and declare the table with `BVT(clib_bihash)` or the explicit `clib_bihash_8_8_t`. A standalone app also includes `bihash_template.c`. - **Init and size it.** `clib_bihash_init_8_8(h, "name", nbuckets, memory_size)`. Choose `nbuckets ≈ expected_records / BIHASH_KVP_PER_PAGE`; the table owns a separate arena, so it’s fine to be generous to absorb collisions. - **Add / update / delete.** Set `kv.key` and `kv.value`, then `clib_bihash_add_del_8_8(h, &kv, is_add)` (`1` = add, `0` = delete). To *update* a value, just re-add the pair. - **Lookups take no lock.** `clib_bihash_search_8_8(h, &search_kv, &return_kv)` returns `< 0` on a miss. On the packet hot path use `clib_bihash_search_inline_with_hash` and **prefetch ahead**: compute the hash early, then call `clib_bihash_prefetch_bucket` and `clib_bihash_prefetch_data` a few packets in advance to hide memory latency. - **Iterate with `clib_bihash_foreach_key_value_pair`.** It is **OK to delete** entries during a walk, but **not OK to add** — an insert can rehash the current bucket, so entries get skipped or revisited. The iterator does *not* take the writer lock; take it yourself if your use case needs one. - **The hash function matters.** A slow or poorly-distributed hash costs both throughput and space efficiency; a CPU CRC32 intrinsic is a good default. ## Summary 1. **bihash** is VPP’s lock-free hash — the backbone of FIB, L2, NAT, and flow caches. 2. Layout: **bucket array → page → linear scan of a few KVPs** (≈ O(1)). 3. **Reads take no lock**; writers build a new page and **atomically swap** the bucket, readers retry on a generation change. 4. Collisions **grow the page** (extensible), not a probe chain. 5. The name = sizes (**`bihash_48_8`** = 48 B key, 8 B value); size with `log2` buckets, pre-allocated. ## References - [VPP `bihash` — bounded-index extensible hash](https://fd.io/docs/vpp/master/developer/corearchitecture/bihash.html) — the authoritative description and API. - [FD.io VPP source — `vppinfra/bihash_template.h`](https://github.com/FDio/vpp/blob/master/src/vppinfra/bihash_template.h) — the templated implementation. - [FD.io VPP documentation](https://fd.io/docs/vpp/master/) — the Vector Packet Processor and its data structures. - The Linux kernel’s **`rhashtable`** is the same idea in another codebase — a resizable, RCU-protected hash table with **lock-free reads** and per-bucket locks for writers. See LWN’s [“Relativistic hash tables, part 1: Algorithms”](https://lwn.net/Articles/612021/) and the practical [“The rhashtable documentation I wanted to read”](https://lwn.net/Articles/751374/); source in [`lib/rhashtable.c`](https://github.com/torvalds/linux/blob/master/lib/rhashtable.c). - [“Resizable, Scalable, Concurrent Hash Tables via Relativistic Programming”](https://www.usenix.org/conference/usenixatc11/resizable-scalable-concurrent-hash-tables-relativistic-programming) (Triplett, McKenney & Walpole, USENIX ATC 2011) — the paper behind RCU/relativistic hash tables and lock-free resizing. - Bucket hashing with **separate chaining** is a textbook algorithm — see [Sedgewick & Wayne, *Algorithms* §3.4 “Hash Tables”](https://algs4.cs.princeton.edu/34hash/), CLRS *Introduction to Algorithms* ch. 11, and the [Wikipedia “Hash table”](https://en.wikipedia.org/wiki/Hash_table) article (the bucket-array-plus-chains figure this post’s Figure 1 follows). - Video: [MIT 6.006 — “Hashing with Chaining” (Erik Demaine)](https://www.youtube.com/watch?v=0M_kIqhwbFo), a clear lecture on the bucket-array-plus-chains model. **Categories:** FastNetMon Blog **Tags:** Network Security Insights --- ### [Learning VPP: Filtering Packets at 100GbE Line Rate](https://fastnetmon.com/2026/07/02/learning-vpp-filtering-packets-at-100gbe-line-rate/) **Published:** July 2, 2026 **Author:** FastNetMon **Content:** ![Portrait of a man with short dark hair and light stubble, wearing a dark gray T-shirt, facing the camera (circular crop).](https://fastnetmon.com/wp-content/uploads/2026/06/Denys-Haryachyy-FastNetMon-Guest-Blog.png) *This post is a repost of [technical blog originally published by Denys Haryachyy,](https://haryachyy.wordpress.com/2026/06/17/vpp-packet-filtering-100gbe-line-rate/) shared here with permission as part of ongoing research and engineering work around FastNetMon’s inline traffic processing capabilities*. > **TL;DR.** A **VPP** software data plane classifies and drops packets using a **tuple-space search (TSS)**: rules are grouped by mask shape into per-mask `bihash` tables, and each packet probes one table per distinct mask. Matching cost is **O(number of distinct masks), independent of how many rules you load**. VPP’s in-tree **ACL plugin** solves the same problem with the **TupleMerge** variant (one shared `bihash`, relaxed and merged masks); our filter uses **plain TSS** (one small exact-mask hash per shape). Same idea, opposite trade-offs. Dropping a packet sounds free, but the CPU still has to receive it, classify it, decide, and free the buffer. This article is about the *classifier* that makes the rule-matching step effectively free — no matter how many rules you load. [![Figure 1: Tuple-space search — each packet probes one bihash per distinct mask shape (O(#masks)), so matching cost is independent of the rule count.](https://haryachyy.wordpress.com/wp-content/uploads/2026/06/vpp-filtering-tss-fig1.png)](https://haryachyy.wordpress.com/wp-content/uploads/2026/06/vpp-filtering-tss-fig1.png)Figure 1: Tuple-space search — each packet probes one bihash per distinct mask shape (O(#masks)), so matching cost is independent of the rule count.## Tuple-Space Search: One Hash per Mask Shape Tuple-space search (Figure 1) avoids walking the rule list at all. A rule’s *mask shape* is the combination of fields it constrains — source/destination prefix lengths, protocol, port ranges. Rules that share a mask shape can be matched by a single exact-match hash lookup on the masked packet fields. So TSS: - **Groups rules by mask shape** into a handful of per-mask hash tables — each one a VPP `clib_bihash_24_8` (a bounded-index, lock-free hash), keyed on the packet’s 7-tuple fields masked to that shape. - **Probes one table per distinct mask** for each packet. The cost is the number of *distinct masks* (a small constant — real-world ACLs have tens of mask shapes even with millions of rules), **not the number of rules**. The first table that returns a hit gives the action; if no table matches, the packet passes. IPv6 rules use the same TSS with a wider key — a per-mask `clib_bihash_40_8` (40-byte key: dst + src IPv6 + protocol). Both the IPv4 and IPv6 paths are **pure TSS**; only the key width differs (24 B vs 40 B). The consequence is the headline of this whole article: **classification cost scales with the number of distinct mask shapes, not with how many rules you load.** Load 100 rules or 1M; if they collapse into the same handful of masks, the per-packet cost is identical. [![Figure 2: A worked tuple-space-search example. Three rules collapse into three mask shapes, each with its own bihash; a packet is masked once per shape and probed in parallel. Mask B hits rule R2 → DROP. Cost is one probe per mask, independent of how many rules each table holds.](https://haryachyy.wordpress.com/wp-content/uploads/2026/06/tss-mask.png)](https://haryachyy.wordpress.com/wp-content/uploads/2026/06/tss-mask.png)Figure 2: A worked tuple-space-search example. Three rules collapse into three mask shapes, each with its own `bihash`. The packet (dst 192.168.1.55, src 8.8.8.8) is masked once per shape — dst/8, dst/24, dst/24+src/16 — and each masked key probes its table. Mask B hits rule R2 → **DROP**. The cost is exactly three probes (one per mask), no matter how many rules each table holds.## VPP’s Own ACL Plugin: TSS, but TupleMerge VPP already ships a tuple-space search — in the in-tree **ACL plugin** — and it’s worth comparing, because it makes the opposite set of trade-offs. Both group rules by mask shape and probe hash tables instead of scanning a rule list. But the ACL plugin uses the **TupleMerge** variant (Daly & Torng, ICCCN 2017) and folds every table into a single shared hash, where our filter stays plain TSS with one small hash per mask. [![Figure 3: VPP's ACL plugin packs every per-mask table into one shared bihash_48_8 keyed by the 5-tuple plus a mask-type index, where each hit is a candidate to re-verify; our filter keeps one small bihash_24_8 per mask shape with the rule index inline in the value.](https://haryachyy.wordpress.com/wp-content/uploads/2026/06/tss-compare-1.png)](https://haryachyy.wordpress.com/wp-content/uploads/2026/06/tss-compare-1.png)Figure 3: Two takes on TSS. VPP’s ACL plugin (left) merges masks into one shared `bihash_48_8`, keyed by the full 5-tuple plus a mask-type index, so every hit is a candidate to re-verify. Our filter (right) keeps one small `bihash_24_8` per mask shape with the rule index stored inline.**VPP’s ACL plugin.** TupleMerge *relaxes and merges* compatible masks into fewer tables, so a rule can land in a table whose mask omits some of the bits it actually constrains. That bounds the table count — it splits a table once it collects more than **39 colliding rules** — but it means a hash hit is only a *candidate*: the matched rule is **re-verified** (port ranges and the relaxed-away bits) before it counts. Every logical table lives in one shared `clib_bihash_48_8`; the 48-byte key is the full 5-tuple plus a `mask_type_index` and a lookup-context index, so a single physical table holds every per-mask table and every interface’s context at once. To honor ACE order it probes *every* mask type and keeps the lowest applied-entry index — it can’t stop at the first hit. [![Figure 4: The same three rules and packet under TupleMerge. Relaxing masks merges the rules into fewer mask-types in one shared bihash, so the packet takes fewer probes (2 vs 3 in Figure 2) — but a hash hit is only a candidate: rule R2 is re-verified against the relaxed-away bits before it counts.](https://haryachyy.wordpress.com/wp-content/uploads/2026/06/tuplemerge-mask-2.png)](https://haryachyy.wordpress.com/wp-content/uploads/2026/06/tuplemerge-mask-2.png)Figure 4: The same three rules and packet as Figure 2, now under **TupleMerge**. Relaxing masks merges them into fewer mask-types in one shared `bihash`, so the packet takes **fewer probes (2 vs 3)** — but because bits were relaxed away, a hit is only a *candidate*: the matched rule (R2) is **re-verified** against the omitted bits before it counts. In plain TSS (Figure 2) the exact-mask hit needs no such re-check.**Our filter.** Ours is plain TSS: one `clib_bihash_24_8` per distinct mask shape, no merging and no relaxation. The 24-byte key is just the masked destination and source IPv4 plus protocol, and the value is the **rule index inlined directly** — a collision chain appears only when two rules share a masked key. Because masks are exact, the address-and-protocol match from the hash is **authoritative**; we only re-check the fields that aren’t in the key (ports, DSCP, fragment flags, length). Like VPP we probe every tuple and keep the lowest rule order, but a sorted collision chain lets us prune as soon as we pass the best match. IPv6 rules use a separate set of per-mask `clib_bihash_40_8` tables — a 40-byte key holding the full source and destination IPv6 addresses plus protocol — so IPv6 is the same TSS, just a wider key. | | VPP ACL plugin | our filter | |---|---|---| | **Algorithm** | TupleMerge (TSS + mask relax/merge) | Plain TSS (one table per mask) | | **Hash table** | one shared `clib_bihash_48_8` | one `bihash_24_8` (IPv4) / `bihash_40_8` (IPv6) per mask | | **Key** | 48 B: 5-tuple + `mask_type_index` + `lc_index` | 24 B (IPv4) / 40 B (IPv6): masked dst + src + proto | | **Value** | applied-entry index → ACE | rule index inline, or collision-chain index | | **Hash hit** | candidate — re-verify relaxed bits + ports | addr+proto exact; re-verify ports/DSCP/frag only | | **Table count** | bounded (merge + split at 39 collisions) | one per distinct mask shape | | **Priority** | scan all tables, keep lowest ACE index | probe all tuples, keep lowest rule order | | **IPv6** | same 48 B key (`is_ip6` bit) | separate per-mask `bihash_40_8` (TSS) | ## Why Plain TSS for a DDoS Filter TupleMerge is the right tool for a *general-purpose* ACL — thousands of rules across hundreds of distinct mask shapes, where the number of tables would otherwise explode. A DDoS drop filter is the opposite workload, and that flips the trade-offs: - **Few, fixed mask shapes — nothing to merge.** Mitigation rules are coarse and uniform (drop by victim prefix, by protocol, by amplification port), so they collapse into a handful of shapes. TupleMerge’s table-bounding machinery buys nothing when there are only a couple of shapes to begin with. - **You match constantly, so re-verification is the wrong cost.** Under a flood the filter *matches* (drops) most packets, so re-verifying every hit (Figure 4) is paid on nearly every dropped packet. Plain TSS uses exact masks, so an address-and-protocol hit is **authoritative** — only the fields not in the key (ports, DSCP, fragment) need a cheap recheck. - **No table mutation under load.** TupleMerge splits and re-homes tables as rules collide; a mitigation system adds and removes rules *live* as attacks are detected, so a simple insert into the right exact-mask hash — no relaxation, no splitting — means predictable behaviour and fast rule churn exactly when you are under attack. - **The mask shapes are yours, not the attacker’s.** TSS classifiers can be attacked by inducing many distinct tuples; in a purpose-built filter the shapes are fixed by your rule set, not by traffic, so the probe count is bounded *by design* and there is no explosion to tame. Load an arbitrary ACL with hundreds of distinct masks and the trade inverts — TupleMerge’s bounded table count would win. But that is not the DDoS case: here the shapes are few and fixed, so plain TSS keeps authoritative exact-mask hits, a smaller key, and a simple lock-free insert path — the same algorithm with the general-purpose tax removed. ## Cost vs. Number of Mask Shapes (Measured) Since the cost driver is the number of *distinct mask shapes*, not the rule count, we measured it directly: load ~1M rules across N distinct shapes (one hot shape the flood matches → dropped, plus N−1 cold ones) and sample the classifier’s cyc/pkt and DUT throughput under an RSS-optimal line-rate flood, with each per-mask `bihash` sized to `tss-bihash-buckets = 1048576` (2^20 buckets, ≈ 1 entry/bucket for ~1M rules; AMD EPYC 7742, 32 workers): A *mask shape* is the set of fields a rule constrains, with their prefix lengths — one shape = one tuple = one probe. The sweep mints N distinct shapes; a few of the ones it uses: - `udp, dst-port 8000–8255` — the hot shape the flood matches → **dropped** - `dst /24` — a subnet (the bulk: ~1M cold rules all share this one shape) - `dst /32` — a single host - `dst /24 + udp` - `dst /24 + udp + dst-port` - `dst /24 + src /24` - `dst /24 + src /32 + udp` The loader also varies the prefix length (/20, /22, /24, /25, /26, /28, /30, /32) to manufacture more distinct shapes up to N. Two rules share a shape only if they constrain the same fields at the same prefix lengths — so a million `dst /24` rules are *one* shape, while `dst /24` and `dst /32` are *two*. | Distinct mask shapes (probes/pkt) | filter cyc/pkt | DUT Mpps | |---|---|---| | 1 | 77 | 142.1 | | 2 | 94 | 142.1 | | 4 | 122 | 142.1 | | 8 | 171 | 140.9 | | 16 | 290 | 138.2 | | 32 | 538 | 102.9 | | 64 | 1096 | 56.8 | cyc/pkt grows ~linearly with shape count — cost is **O(distinct mask shapes)**. Throughput holds **100GbE line rate (142 Mpps) through ~8 shapes** and stays near it to 16, then falls as the per-packet cost exceeds the worker’s cycle budget. A DDoS rule set has only a **handful of shapes**, so it sits in the flat 142-Mpps regime no matter how many rules you load; a general ACL with tens of shapes is where the climb begins — TupleMerge’s territory. ## We Tried It: Reusing VPP’s ACL Engine We also tested the obvious shortcut: reusing VPP’s stock ACL plugin (a TupleMerge classifier) as the lookup engine, wired into the same node so only the lookup differs. On identical rules and flood it cost ~29× more cycles per packet and couldn’t hold line rate — TupleMerge’s strengths (one bounded shared table, full stateful-ACL generality) are exactly what a line-rate drop filter doesn’t need. | Engine (5 rules, 1 mask shape) | Cycles / packet | Throughput | |---|---|---| | **Plain TSS** (our filter) | **82** | **142 Mpps** (line rate) | | **TupleMerge** (VPP ACL plugin) | **2,352** | **~29 Mpps** | Measured on **32 worker cores, AMD EPYC 7742 (~2.25 GHz base)**, 100GbE — same rules and flood, only the lookup engine differs. That CPU budget is why the numbers land where they do: at 2,352 cyc/pkt, 32 cores × 2.25 GHz tops out at **~29 Mpps**; TSS’s 82 cyc leaves the CPU mostly idle, so the 100GbE NIC — not the filter — sets its 142 Mpps ceiling. ## Summary 1. **Tuple-space search** over per-mask `bihash` tables keeps rule-matching off the hot path: cost is **O(#distinct masks)**, independent of how many rules you load. 2. A rule’s **mask shape** picks its table; a packet probes one table per distinct mask and takes the lowest-order match. 3. VPP’s **ACL plugin** uses **TupleMerge** (relaxed masks merged into one shared `bihash`, hits re-verified) for arbitrary ACLs; our filter uses **plain TSS** (one exact-mask `bihash` per shape) — cheaper for the handful of shapes a DDoS filter has. ## References - [FD.io VPP documentation](https://s3-docs.fd.io/vpp/26.06/) — the Vector Packet Processor and its node-graph data plane. - [VPP `bihash` — bounded-index extensible hash](https://s3-docs.fd.io/vpp/26.06/developer/corearchitecture/bihash.html) — the lock-free hash behind tuple-space search. - [Tuple Space Search (Srinivasan et al., 1999)](https://dl.acm.org/doi/10.1145/316188.316216) — the packet-classification algorithm grouping rules by mask shape. - [TupleMerge (Daly et al., IEEE/ACM ToN 2019)](https://nonsns.github.io/paper/rossi19ton.pdf) — the TSS variant VPP’s ACL plugin uses: it merges compatible masks into fewer tables, trading exact-mask hits for bounded table growth. - [The Design and Implementation of Open vSwitch (Pfaff et al., NSDI 2015)](https://www.usenix.org/conference/nsdi15/technical-sessions/presentation/pfaff) — tuple-space search in production: OVS’s megaflow classifier is a TSS (§5). - [Intel — OVS-DPDK Datapath Classifier](https://www.intel.com/content/www/us/en/developer/articles/technical/ovs-dpdk-datapath-classifier.html) — an accessible walkthrough of the TSS classifier (subtables = tuples, masking, subtable ranking). **Categories:** FastNetMon Blog, Featured **Tags:** guest post --- ### [Learning Mellanox ConnectX-5: CQE Compression Tuning](https://fastnetmon.com/2026/07/22/learning-mellanox-connectx-5-cqe-compression-tuning/) **Published:** July 22, 2026 **Author:** FastNetMon **Content:** ![Portrait of a man with short dark hair and light stubble, wearing a dark gray T-shirt, facing the camera (circular crop).](https://fastnetmon.com/wp-content/uploads/2026/06/Denys-Haryachyy-FastNetMon-Guest-Blog.png) *This post is a repost of [technical blog originally published by Denys Haryachyy](https://haryachyy.wordpress.com/2026/06/10/mellanox-connectx-5-cqe-compression-rx-performance/), shared here with permission as part of ongoing research and engineering work around FastNetMon’s inline traffic processing capabilities*. > **TL;DR.** On a **Mellanox ConnectX-5**, the firmware setting **`CQE_COMPRESSION=AGGRESSIVE`** is the biggest **receive-side** win — **+17–21 Mpps**. Instead of one 64-byte completion (CQE) per packet over PCIe, the NIC packs many into a **title CQE + 8-byte mini-CQEs**, so `rte_eth_rx_burst()` returns **~4× more packets per call** at **−28 % cyc/pkt**. That headroom let our EPYC 7742 — using **just 32 of its 64 cores** (one poll worker per core), ConnectX-5 Ex, DPDK 25.07 — absorb the **full 142 Mpps** 100GbE line rate. Enable it with `mlxconfig` + `mlxfwreset`. A traffic generator’s job is to *emit* line rate; a device under test’s job is often to *absorb* it. Absorbing 142 Mpps is a different problem, and on the ConnectX-5 the dominant lever isn’t CPU tuning — it’s how the NIC reports completions over PCIe. ## Our Test Setup Every number below comes from one machine absorbing a 100GbE flood: | Component | Spec | |---|---| | CPU | AMD EPYC 7742 — **64 cores / 128 threads** | | Poll workers | **32** — one RX queue pinned per worker, one worker per core (**only 32 of the 64 cores used**) | | NIC | Mellanox **ConnectX-5 Ex**, 100GbE, FW 16.35.4030 | | Driver / DPDK | mlx5 PMD, DPDK 25.07 | | Data plane | FD.io **VPP 25.10** | | OS | **Ubuntu 24.04.4 LTS**, kernel 6.8.0 | | Offered load | TRex at **142 Mpps** (100GbE, 64 B frames — line rate) | With `CQE_COMPRESSION=AGGRESSIVE` and one queue per core, this DUT receives and forwards the **full 142 Mpps** for cache-friendly traffic — **up to 142.2 Mpps received** — at or above what TRex can emit. Compression is the receive-side lever that makes line-rate absorption possible; the rest of this post is how it works. [![Figure 1:CQE compression packs many completions into one PCIe read, so DPDK decodes ~4× more descriptors per receive burst on the ConnectX-5.](https://haryachyy.wordpress.com/wp-content/uploads/2026/06/mellanox-connectx-5-cqe-compression-rx-performance-fig1-1.png)](https://haryachyy.wordpress.com/wp-content/uploads/2026/06/mellanox-connectx-5-cqe-compression-rx-performance-fig1-1.png)Figure 1:CQE compression packs many completions into one PCIe read, so DPDK decodes ~4× more descriptors per receive burst on the ConnectX-5.## How CQE Compression Works Every time the NIC finishes a packet — received or transmitted — it writes a **Completion Queue Entry (CQE)** into host memory over PCIe, and the DPDK 25.07 mlx5 poll-mode driver reads it to learn what happened. A standard mlx5 CQE is **64 bytes**. At 142 Mpps that is `142e6 × 64 = ~9 GB/s` of PCIe writes spent purely on *completions*, before a single byte of packet data moves — on a Gen4 link that competes directly with the DMA of the packets themselves. `CQE_COMPRESSION=AGGRESSIVE` attacks exactly this. Instead of one full CQE per packet, the NIC emits one **title CQE** carrying the fields common to a run of packets, followed by an array of tiny **mini-CQEs** (8 bytes each) for the per-packet fields that vary. Many completions now ride in a single PCIe transaction. `AGGRESSIVE` compresses unconditionally — it assumes a homogeneous packet stream, which is exactly the case under a flood. [![Figure 2: CQE compression replaces N full 64-byte completions with one title CQE plus 8-byte mini-CQEs — a fraction of the PCIe bytes.](https://haryachyy.wordpress.com/wp-content/uploads/2026/06/mellanox-connectx-5-cqe-compression-rx-performance-fig2.png)](https://haryachyy.wordpress.com/wp-content/uploads/2026/06/mellanox-connectx-5-cqe-compression-rx-performance-fig2.png)Figure 2: CQE compression replaces N full 64-byte completions with one title CQE plus 8-byte mini-CQEs — a fraction of the PCIe bytes.**Enabling it — three ways.** Firmware-persistent with the NVIDIA MFT utility, or per-application via the DPDK 25.07 mlx5 `rxq_cqe_comp_en` devarg in testpmd or VPP. *Firmware utility (`mlxconfig`) — persistent across reboots:* ``` mlxconfig -d 0000:01:00.0 set CQE_COMPRESSION=1 # 1 = AGGRESSIVEmlxfwreset -d 0000:01:00.0 --level 3 --yes reset # apply nowmlxconfig -d 0000:01:00.0 query CQE_COMPRESSION # verify ``` *testpmd (DPDK 25.07 devarg, no firmware change):* ``` dpdk-testpmd -a 0000:01:00.0,rxq_cqe_comp_en=1 -- -i ``` *VPP (dpdk plugin `startup.conf`):* ``` dpdk { dev 0000:01:00.0 { devargs rxq_cqe_comp_en=1 }} ``` ## On RX: The Burst Size Explodes The receiver’s DPDK 25.07 mlx5 PMD calls `rte_eth_rx_burst()` in a tight loop. With uncompressed CQEs it reads one 64-byte completion per packet, so each PCIe read yields one descriptor and the burst stays small. With compression, a single read of one compressed block decodes into *many* completed descriptors at once: | | Compression OFF | `CQE_COMPRESSION=AGGRESSIVE` | |---|---|---| | RX descriptors per `rx_burst()` | ~63 | **~240 (≈ 4×)** | | Cycles per packet | 122 | **88 (−28 %)** | Bigger RX bursts compound: the per-call overhead amortizes over 4× more packets, instruction-cache and prefetch locality improve, empty polls drop, and the receiver drains its RX ring fast enough to keep `rx_missed` near zero. That chain — fewer PCIe completion reads → larger RX bursts → lower cyc/pkt — is the entire +17–21 Mpps. (Those figures isolate compression alone; raising the per-worker drain rate this way is exactly what lets the full 32-worker DUT take the **142 Mpps** line rate without the NIC’s RX ring overflowing — the `rx-miss` counter stays near zero instead of silently discarding packets before `rte_eth_rx_burst`.) ## Summary 1. **CQE compression is the dominant receive-side lever** on the ConnectX-5: **+17–21 Mpps**. 2. It works by **packing many completions into one PCIe read** (title + 8 B mini-CQEs). 3. **On RX** it ~4× the `rx_burst()` size (63→240 pkt/call) and cuts cyc/pkt 28 %. 4. Set it with `mlxconfig` + `mlxfwreset`; it’s firmware-persistent. 5. **On our DUT** — AMD EPYC 7742 using **only 32 of its 64 cores** (32 poll workers), ConnectX-5 Ex, VPP 25.10 on Ubuntu 24.04 — compression is what lets VPP absorb the **full 142 Mpps** 100GbE line rate (142.2 Mpps received). ## References - [DPDK mlx5 driver — `rxq_cqe_comp_en` / CQE compression](https://doc.dpdk.org/guides/nics/mlx5.html#mlx5-common-driver-options) — the DPDK-on-Mellanox documentation of the CQE-compression device argument and its formats, the runtime counterpart to the `mlxconfig` firmware setting used here. - [NVIDIA DPDK NIC Performance Report (DPDK 25.03)](https://fast.dpdk.org/doc/perf/DPDK_25_03_NVIDIA_NIC_performance_report.pdf) — NVIDIA’s official ConnectX/BlueField DPDK benchmark methodology and results; the closest published release to the DPDK 25.07 used here, and it lists CQE compression among the tuned settings. **Categories:** FastNetMon Blog, Featured **Tags:** Network Security Insights --- ### [Learning DPDK: Eliminating NIC Receive Drops at 100GbE](https://fastnetmon.com/2026/06/17/learning-dpdk-eliminating-nic-receive-drops-at-100gbe/) **Published:** June 17, 2026 **Author:** FastNetMon **Content:** ![](https://fastnetmon.com/wp-content/uploads/2026/06/Denys-Haryachyy-FastNetMon-Guest-Blog.png) *This post is a repost of [technical blog originally published by Denys Haryachyy](https://haryachyy.wordpress.com/2026/06/12/eliminate-dpdk-nic-receive-drops-100gbe/), shared here with permission as part of ongoing research and engineering work around FastNetMon’s inline traffic processing capabilities*. *The article examines the underlying performance mechanics needed to run DPDK-based packet processing at 100GbE without packet loss, and how subtle operating system and interrupt behaviour can directly impact stability under extreme load. It is closely related to our [R&D project, code-named FastACL](https://fastnetmon.com/2026/06/11/sneak-peek-building-a-high-performance-vpp-based-inline-filter-at-fastnetmon/), which builds on these same principles at the system level to deliver a VPP-based inline DDoS filtering engine.* ## Learning DPDK: Eliminating NIC Receive Drops at 100GbE > **TL;DR — everything that matters, in one paragraph.** A DPDK poll-mode application can lose packets at 100GbE even when the **CPU has spare cycles** — because a **hardware IRQ landing on a busy-poll worker core** stalls it for a few microseconds, and at 100+ Mpps that’s enough to **overflow the NIC’s RX descriptor ring** before the worker can drain it. The fix is **isolation, not more CPU**. Pinning the NIC’s completion IRQs **off the worker cores** (onto a housekeeping core) cut the receive-miss rate from **1 in 2,275 packets to 1 in 16,000,000 — about a 7,000× reduction**. To take the residual to essentially zero, isolate the worker cores from the kernel entirely with boot parameters: **`isolcpus`, `nohz_full`, `rcu_nocbs`, `irqaffinity=0`, and `processor.max_cstate=1`**. None of this costs throughput — it just stops anything from interrupting the cores that poll the NIC. A DPDK worker is a tight loop that does nothing but poll the NIC and process packets. It has no slack: if the OS steals it for even a few microseconds, the NIC keeps filling the RX ring with no one draining it. At low rates that’s invisible; at 100GbE the ring overflows and you get silent drops. ![Default: a NIC completion IRQ on a busy-poll worker core preempts it, the RX ring overflows, and rx_missed rises.](https://haryachyy.wordpress.com/wp-content/uploads/2026/06/figa-split.png)Figure 1: By default a NIC completion IRQ can land on a busy-poll worker core, preempting it for microseconds — long enough to overflow the RX ring during a burst, so `rx_missed` rises. ![Fixed: NIC IRQs pinned to housekeeping core 0, workers poll uninterrupted, rx_missed near zero.](https://haryachyy.wordpress.com/wp-content/uploads/2026/06/figb-split.png)Figure 2: Pin the NIC IRQs to a housekeeping core (core 0) and the workers poll uninterrupted — `rx_missed` drops to ≈ 0. ## The Symptom: `rx_missed` Under Load The tell is the NIC’s `rx_missed` (a.k.a. `rx_missed_errors` / PHY discards) counter rising under load while CPU utilization shows headroom. The packets never reach the application — the **NIC** dropped them because the RX descriptor ring was full when they arrived. More workers won’t help; the cores aren’t saturated. Something is **interrupting** them. ## The Cause: Hardware IRQs on Poll Cores Even with a bifurcated or poll-mode driver, the NIC still raises **completion/async interrupts**, and by default the kernel is free to deliver them to any core — including the ones running your DPDK workers. On the box behind these numbers, the mlx5 completion IRQs defaulted onto cores 11–13, right on top of busy-poll workers (Figure 1). Each IRQ preempts the poll loop for only a few microseconds. But do the math: at ~30 Mpps per queue, a single 100 µs stall is \*\*~3,000 packets\*\* — and an 8,192-entry RX ring fills in well under that. One stray interrupt during a burst is a ring overflow. ## Pinning IRQs Off the Workers The first and biggest win is to keep NIC IRQs away from worker cores. Steer every device IRQ to a housekeeping core (core 0) by writing its `smp_affinity`: ``` # Send every mlx5 IRQ to core 0 (mask 0x1)for irq in $(grep -l mlx5 /proc/irq/*/* 2>/dev/null | grep -o '[0-9]\+' ); do echo 1 > /proc/irq/$irq/smp_affinity 2>/dev/nulldone# and stop irqbalance from moving them backsystemctl stop irqbalance ``` The effect on this hardware: | State | rx-miss rate | Drop rate | |---|---|---| | Before IRQ pin | 1 / 2,275 pkts | 0.044 % | | After IRQ pin | 1 / 16,000,000 pkts | 0.0000062 % | That’s a **~7,000× reduction** from one change — and `irqbalance` must be stopped, or it will quietly reassign the IRQs back onto the workers a minute later. ## Full Isolation: `isolcpus`, `nohz_full`, `rcu_nocbs` To take the residual misses to essentially zero, remove the worker cores from the kernel’s reach at boot. Append to the kernel command line (`/etc/default/grub`, then `update-grub` and reboot): ``` isolcpus=1-32 nohz_full=1-32 rcu_nocbs=1-32 \irqaffinity=0 processor.max_cstate=1 ``` Each one closes a different interruption source: - **`isolcpus=1-32`** — keep the scheduler from placing any other task on the worker cores. - **`nohz_full=1-32`** — stop the periodic 1 kHz timer tick on those cores (no per-millisecond interrupt). - **`rcu_nocbs=1-32`** — move RCU callback processing off the worker cores onto housekeeping cores. - **`irqaffinity=0`** — default all IRQs to core 0 from boot, before userspace even starts. - **`processor.max_cstate=1`** — forbid deep C-states, so a core never takes 50–200 µs to wake from idle. Use the **same core range** as your DPDK workers. Together these guarantee that the only thing ever running on a worker core is the poll loop — which is the entire point. ## Summary 1. NIC drops at 100GbE are usually **interruption**, not CPU saturation — `rx_missed` rises with cores to spare. 2. A hardware IRQ stalls a busy-poll worker for µs; at 30 Mpps/queue that **overflows the RX ring**. 3. **Pin NIC IRQs to a housekeeping core** (`smp_affinity`) and **stop `irqbalance`** — here a **~7,000×** drop reduction. 4. **Isolate the worker cores** at boot: `isolcpus`, `nohz_full`, `rcu_nocbs`, `irqaffinity=0`, `processor.max_cstate=1`. 5. None of it costs throughput — it removes everything that competes with the poll loop. ## References - [DPDK — Linux core isolation for performance](https://doc.dpdk.org/guides/linux_gsg/enable_func.html) — `isolcpus` and related boot options for DPDK apps. - [Linux kernel — `nohz_full` (NO\_HZ) documentation](https://www.kernel.org/doc/html/latest/timers/no_hz.html) — tickless operation on isolated cores. - [Linux kernel parameters (`isolcpus`, `rcu_nocbs`, `irqaffinity`)](https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html) — the boot-cmdline reference. **Categories:** FastNetMon Blog, Featured --- ### [FastNetMon Advanced 2.0.381](https://fastnetmon.com/2026/07/13/fastnetmon-advanced-2-0-381/) **Published:** July 13, 2026 **Author:** FastNetMon **Content:** **Release date:** 13 July, 2026 **Version:** 2.0.381 FastNetMon Advanced 2.0.381 delivers major improvements to BGP FlowSpec capabilities, including full IPv6 manual announcement support, enhanced route propagation and mirroring, and expanded FlowSpec integration across callbacks and automation. This release also introduces MongoDB TLS support, improves ClickHouse reliability, upgrades a wide range of core dependencies and toolchains, and adds numerous stability, build, and compatibility enhancements across supported platforms. In addition, it addresses a recently disclosed BGP security issue with full support for extended-length BGP attributes and includes multiple fixes to improve the robustness of routing, configuration handling, and telemetry processing. Changes: - Fully working BGP Flow Spec IPv6 manual announcement logic - Complete test coverage for encode\_bgp\_subnet\_encoding\_ipv6 and encode\_bgp\_subnet\_encoding\_ipv4 - Upgrade fcli to address problem with lack of gzip compression - Upgraded inja to v3.5.0 - Added logic to restart GoBGP when we do upgrades - Added information about source IP of malformed Netflow v9 packets to log file - Allow invalid certificates for mongodb when mongodb\_tls\_allow\_invalid\_certificates is set to true in /etc/fastnetmon/fastnetmon.conf - Added MongoDB via TLS using mongodb\_tls in /etc/fastnetmon/fastnetmon.conf - Added workaround for build issue of cppkafka on RedHat, explicitly added zlib path - Added workaround for Clickhouse compilation issues [ClickHouse/clickhouse-cpp#524](https://github.com/ClickHouse/clickhouse-cpp/issues/524) - Fixed SSL build for cppkafka and removed clang dependency entirely - Upgrade cmake 3.23.4 to 3.31.8 - Mongo c driver 1.23.0 upgrade 1.30.5 - Mongo cxx 3.7.0 upgrade to mongo\_cxx\_3\_11\_0 - Upgrade Boost ASIO API as in Community edition: [pavel-odintsov/fastnetmon@f020632](https://github.com/pavel-odintsov/fastnetmon/commit/f02063204d2b07a525d70e502571b31514653604) - Upgrade cppkafka from 0.3.1 to 0.4.1 - Upgrade rdkafka from 1.7.0 to 2.14.2 - Removed system depdency in Boost as it's not used anymore and changed Boost version pinning - Upgrade Boost from 1.81.0 to 1.91.0 - Upgrade gcc from 12.1.0 to 16.1.0 - Upgrade zlib from 1.2.13 to 1.3.2 - Upgrade bpf from 1.0.1 to 1.7.0 - No more 18.04 and 20.04 - Upgrade libelf to 0.195 - Get rid of unusual dependency on Digest::MD5::File which is not packaged on RHEL 10 - Moved dependencies to YAML - Fixed s3cmd build for Ubuntu 26.04 and enabled RHEL 10 builds - Added --disable-libsanitizer to address build issues on Ubuntu 26.04 - Added libcrypt-dev to address compilation problems with gcc on Ubuntu 26.04 - Upgrade GoBGP to GoBGP 4.6.0 - Fixed typo in connection tracking logic - Added safeguard to prevent bugs when TYPE\_EXACT is not honored by GoBGP - Added logic to propagate connection tracking - Added logic to explicitly pass Flow Spec rules everywhere - Propagated Flow Spec and conntrack structure to attack callbacks for per host bans - Upgrade nlohman json to 3.12.0 - Upgraded fmt to 12.1.0 - Added logic to propagate Flow Spec rules in Blackhole IPv4 mode to JSON callback and script in field flow\_spec\_rules - Introduced logic to queue batches in traffic\_db before sending them to Clickhouse, clickhouse\_queue\_max\_batches defines max number of entries in queue, set to 64 by default, addresses problem with Failed to push data to clickhouse: cannot execute query while inserting, use SendInsertData instead - Upgraded fcli - Extended fcli timeout for reload\_hostgroups, reload\_networks and reload\_bgp to 60 seconds instead of default 5 second one - Changed logic to show field subnet\_learning in sudo fcli show bgp - Aligned naming of class generated from configuration with fcli upstream - Upgrade Golang to 1.26.4 - Upgrade all dependencies for fastnetmon\_client - Added logic to prevent fastnetmon from crashing when /etc/fastnetmon/fastnetmon.conf has JSON syntax issues - Added logic when we have multiple announces during withdrawal - We must use remote\_ip address of BGP peer to get adj-in instead of name - Added logic to print unknown attributes when debug mode is enables - Added logic to add communities for mirrored announce - Added lists bgp\_announce\_network\_communities\_ipv4 and bgp\_announce\_network\_communities\_ipv6 - Implemented full logic to mirror BGP announces on per prefix basis for IPv4 - Added bgp\_announce\_network\_mirror\_attributes\_peer\_name\_ipv4 and bgp\_announce\_network\_mirror\_attributes\_peer\_name\_ipv6 to define peer names for mirroring - Added new options bgp\_announce\_network\_ipv4, bgp\_announce\_network\_ipv6, bgp\_announce\_network\_mirror\_attributes\_ipv4, bgp\_announce\_network\_mirror\_attributes\_ipv6 - Added logic to set GoBGP announce timestamp to address strange looking 20600d timestamps in GoBGP - Unified Flow Spec announced/withdrawal logic - Moved flow spec code to actions - Added full support for extended length BGP attributes, addresses [CVE-2026-48685](https://github.com/advisories/GHSA-4h2g-xxvj-v3w5) [FastNetMon Advanced documentation](https://fastnetmon.com/docs-fnm-advanced/) [View this release on GitHub](https://github.com/FastNetMon/fastnetmon-advanced-releases/releases/tag/v2.0.381) **Categories:** Releases --- ### [FastNetMon Advanced 2.0.382](https://fastnetmon.com/2026/07/20/fastnetmon-advanced-2-0-382/) **Published:** July 20, 2026 **Author:** FastNetMon **Content:** **Release date:** 20 July, 2026 **Version:** 2.0.382 FastNetMon Advanced 2.0.382 is a security-focused maintenance release that strengthens the platform's resilience against malformed network telemetry and configuration validation issues. This release addresses multiple security advisories by improving the robustness of sFlow, NetFlow v9/IPFIX, and packet parsing, eliminating a potential race condition in template handling, and adding strict validation for supported email authentication methods. Changes: - Added sanity check to ensure that malicious actor cannot manipulate length of sFlow sample. Addresses: [GHSA-852r-3wcv-pjx2](https://github.com/pavel-odintsov/fastnetmon/security/advisories/GHSA-852r-3wcv-pjx2) - Added limit for length of Netflow v9 interface name to address security issue [GHSA-ff5f-p5jw-8fq2](https://github.com/pavel-odintsov/fastnetmon/security/advisories/GHSA-ff5f-p5jw-8fq2) - Implemented logic to make full copy of Netflow / IFIX template to avoid potential race condition during template update, addresses [GHSA-ph88-95vc-x6gv](https://github.com/pavel-odintsov/fastnetmon/security/advisories/GHSA-ph88-95vc-x6gv) - Addressed security vulnerability in packet parser when IPv6 fragments are involved: [GHSA-jmjw-392h-4g93](https://github.com/pavel-odintsov/fastnetmon/security/advisories/GHSA-jmjw-392h-4g93) - Added validation for email\_notifications\_auth\_method to allow only following options: scram-sha-256-plus, scram-sha-1-plus, scram-sha-256, scram-sha-1, plain, gssapi, external, oauthbearer, cram-md5, digest-md5, login, ntlm, xoauth2 [FastNetMon Advanced documentation](https://fastnetmon.com/docs-fnm-advanced/) [View this release on GitHub](https://github.com/FastNetMon/fastnetmon-advanced-releases/releases/tag/v2.0.382) **Categories:** Releases --- ### [FastNetMon Now Supports HTTP and HTTPS Proxies](https://fastnetmon.com/2026/07/20/fastnetmon-now-supports-http-and-https-proxies/) **Published:** July 20, 2026 **Author:** FastNetMon **Content:** Many enterprise and service provider networks tightly control outbound Internet access. Whether you're deploying FastNetMon in a secure data centre, a regulated environment, or behind a corporate firewall, direct outbound connectivity isn't always an option. **We've recently introduced HTTP and HTTPS proxy support** for FastNetMon, making it easier to deploy and operate in environments where outbound traffic must pass through an approved proxy server. ### What's New FastNetMon now supports standard proxy environment variables across: - **FastNetMon** (the core daemon) - **fcli** - **The FastNetMon installer** Proxy configuration follows established Linux conventions using the standard `http_proxy` and `https_proxy` environment variables. Authenticated proxies are also supported, allowing you to include credentials as part of the proxy URL when required. For compatibility with existing environments and automation, the installer and `fcli` also recognise the uppercase `HTTP_PROXY` and `HTTPS_PROXY` variants. ### Built for Enterprise Deployments Many organisations require all outbound HTTP(S) traffic to traverse a corporate proxy. Until now, this often meant additional workarounds during installation or operation. With native proxy support, FastNetMon integrates cleanly into existing infrastructure and deployment workflows. Whether you're installing a new instance or running FastNetMon as a long-lived service, proxy configuration uses familiar Linux mechanisms instead of product-specific settings. For systemd deployments, proxy settings can be configured through standard service overrides. For system-wide configuration, administrators can use `/etc/environment`, and environments that execute commands through `sudo` can preserve proxy variables using the standard `env_keep` configuration. ### Simple, Standard Configuration FastNetMon uses the standard proxy environment variables already familiar to Linux administrators. There are no product-specific proxy settings to learn or maintain. If you're already managing proxy settings for other Linux applications, you'll find FastNetMon integrates naturally into existing deployment and operational workflows by using the standard `http_proxy` and `https_proxy` environment variables supported across the Linux ecosystem. ### Learn More The complete documentation includes configuration examples for: - HTTP and HTTPS proxy environment variables - Authenticated proxy configuration - Configuring the FastNetMon systemd service - System-wide proxy configuration - Using proxy settings with `sudo` - Verification and troubleshooting Read the documentation here: [**FastNetMon Proxy Support Documentation**.](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-proxy-support/) **Categories:** FastNetMon Blog, Featured, Press & Newsroom --- ### [New IoT Botnet Reveals How LLMs Are Changing Malware Development](https://fastnetmon.com/2026/07/16/new-iot-botnet-reveals-how-llms-are-changing-malware-development/) **Published:** July 16, 2026 **Author:** FastNetMon **Content:** Remember Script Kiddies? Well, it seems like we need to start talking about "Prompt Kiddies." Evidence that large language models are making their way into malware development has emerged from the analysis of **TuxBot v3 Evolution**, a newly discovered IoT botnet investigated by [Palo Alto Networks Unit 42](https://unit42.paloaltonetworks.com/tuxbot-v3-evolution-iot-botnet/). According to the researchers, the botnet's developers appear to have relied on an LLM to build substantial parts of the framework. The recovered source code still contained AI safety comments and internal reasoning traces that had never been removed, providing a rare glimpse into how AI-generated code is finding its way into real-world malware. The discovery is noteworthy not only because AI appears to have accelerated development, but also because it left behind telltale mistakes. Unit 42 found several implementation flaws that suggest generated code was incorporated with limited manual review. Yet despite these defects, the botnet's core DDoS capabilities remained fully functional. ## A New Multi-Architecture IoT Threat Behind the AI story is a functional IoT botnet built to compromise internet-connected Linux devices. TuxBot combines a C-based bot with a Go-based command-and-control (C2) server capable of generating payloads for **17 processor architectures**, including ARM, MIPS, PowerPC, RISC-V, SPARC and x86-64. That broad architecture support allows attackers to target everything from home routers and IP cameras to DVRs and other embedded systems using a single framework. To infect internet-exposed devices, TuxBot relies on a familiar combination of techniques. It performs Telnet brute-force attacks using 1,496 default and vendor-specific username and password combinations, while also scanning for exposed SSH services, HTTP interfaces, Android Debug Bridge (ADB) instances and known vulnerabilities. ## How TuxBot Stays on Compromised Devices Once a device is compromised, TuxBot focuses on remaining there. According to Unit 42, the malware establishes persistence through multiple mechanisms, including disguised system services, cron jobs, shell profile modifications, hidden backup copies and watchdog processes. It can also rename itself to resemble legitimate Linux daemons and actively remove competing botnets from infected devices. ## Built for DDoS operations Although the analysed build contained several unfinished or broken components, its primary mission was never in doubt. The malware supports **UDP, TCP and DNS flooding**, while communicating with its operators over encrypted TCP connections. To improve resilience, it can also fall back to domain generation algorithms (DGA), DNS and peer-to-peer communication if its primary command-and-control infrastructure becomes unavailable. Researchers also uncovered an SSH-accessible management panel that allowed operators to monitor infected devices and launch attacks. The accompanying development environment contained hundreds of automated benchmark reports, suggesting the framework underwent extensive testing before appearing in the wild. ## AI Makes Malware Development Faster Perhaps the most interesting lesson from TuxBot is that AI-assisted malware development is already producing real operational tools. The same generated code that appears to have accelerated development also introduced broken communication channels, incomplete attack modules and even an authentication component that claimed to implement Argon2id without actually doing so. Those mistakes did not stop the malware from operating, however, and obviously, they could be corrected quickly in future versions. For operators, TuxBot offers an early look at what is likely to become a broader trend: malware authors using LLMs to develop all kinds of tools faster than before. **Categories:** FastNetMon Blog --- ### [Press Release: FastNetMon launches Netomics, a self-hosted routing intelligence platform](https://fastnetmon.com/2026/07/09/press-release-fastnetmon-launches-netomics-a-self-hosted-routing-intelligence-platform/) **Published:** July 9, 2026 **Author:** FastNetMon **Content:** ***New platform gives network operators complete visibility into Internet routing while keeping all routing intelligence inside their own infrastructure.*** *London, UK – July 8, 2026 –* [FastNetMon](https://fastnetmon.com/) is introducing [Netomics](https://netomics.com/), a self-hosted BGP routing intelligence platform that combines live routing data, registry information, RPKI validation, routing history and AI-assisted querying into a single application. Built for Internet service providers (ISPs), cloud providers, Internet Exchange Points (IXPs) and enterprises operating large IP networks, Netomics provides complete visibility into global Internet routing without relying on third-party lookup services. Network engineers often need to consult multiple public tools to investigate routing incidents, validate prefix ownership, check route origins or review historical routing changes. Netomics brings this information together in a single platform that runs entirely within the customer's own infrastructure, creating an internal source of truth for routing intelligence. "Internet routing has become critical operational infrastructure, yet many organisations still depend on multiple external services to understand what is happening in their own networks," said Pavel Odintsov, Founder of FastNetMon. "We built Netomics to give operators complete ownership of their routing intelligence while making it easier to troubleshoot incidents, automate workflows and improve routing security." Netomics combines live BGP Monitoring Protocol (BMP) feeds with global routing data, Internet Routing Registry (IRR) information, WHOIS records, Regional Internet Registry (RIR) data, geofeed information, RPKI validation and historical routing data to provide a comprehensive view of Internet routing. Unlike public routing lookup services, Netomics is deployed entirely on-premises, ensuring routing intelligence remains private, always available and under the organisation's control. The platform also eliminates external rate limits and integrates directly with existing network infrastructure. Designed for modern network operations, Netomics provides access to routing intelligence through a web interface, REST APIs, Prometheus metrics and native Model Context Protocol (MCP) support, allowing organisations to integrate routing data into automation workflows and AI assistants such as ChatGPT and Claude. Netomics is available immediately. Selected features can be explored publicly at[ **www.netomics.com**](http://www.netomics.com/), while the full platform is deployed within customer infrastructure. ## **About FastNetMon** FastNetMon develops DDoS detection and network visibility solutions used by Internet service providers, hosting companies, cloud providers and enterprises worldwide. The company helps network operators improve visibility, automate operations and protect critical infrastructure. **Media contact** Outi Maria Pietilanaho, Head of Marketing FastNetMon Ltd Email: media@fastnetmon.com Web: www.fastnetmon.com www.netomics.com **Categories:** Press & Newsroom **Tags:** Press Releases --- ### [Press release: FastNetMon announces leadership transition with CEO Kate Fateeva stepping down](https://fastnetmon.com/2025/10/16/press-release-fastnetmon-announces-leadership-transition-with-ceo-kate-fateeva-stepping-down/) **Published:** October 16, 2025 **Author:** FastNetMon **Content:** *London, UK — October 16, 2025* — FastNetMon, a leading provider of network traffic visibility and DDoS protection solutions, today announced that Kate Fateeva, Co-founder and CEO, will step down from her role, effective October 24, 2025. Fateeva co-founded FastNetMon in 2014 and has led the company from its early days as an open-source GitHub project to a recognised global brand in network security. Under her leadership, FastNetMon launched its first commercial product in 2016, built a strong international community of network engineers and expanded operations across multiple regions. During her tenure, the company grew its presence globally, serving organisations of all sizes with advanced DDoS detection and mitigation solutions. “I am proud of what we have built together at FastNetMon,” said Kate Fateeva. “From a small GitHub project to a global solution trusted by customers around the world, it has been an incredible journey. Stepping down now allows me to explore new opportunities while ensuring the company continues to grow and thrive.” Pavel Odintsov, co-founder of FastNetMon, will assume Kate Fateeva’s responsibilities, ensuring continuity and stability during the transition. “On behalf of the entire FastNetMon team, I want to thank Kate for her dedication, vision, and hard work over the past years,” said Pavel Odintsov. “Her leadership has been instrumental in building FastNetMon into the global company it is today. We wish her all the best in her next chapter.” For media inquiries, please contact: <media@fastnetmon.com> --- ### About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit https://fastnetmon.com **Categories:** Press & Newsroom **Tags:** leadership announcements, Press Releases --- ### [NetUK3 - Event Recap](https://fastnetmon.com/2026/07/07/netuk3-event-page/) **Published:** July 7, 2026 **Author:** FastNetMon **Content:** ### NetUK3: Two great days with the UK network engineering community Over the past two days, we had the pleasure of attending NetUK3, spending some time with network operators, ISPs, vendors and infrastructure engineers from across the UK at The Brewery in London. We've travelled to quite a few conferences around the world this year, so it was especially nice to attend one much closer to home. FastNetMon continues to grow internationally, but London is where the company is headquartered, and the UK networking community has always been an important part of our journey. It was great to spend a couple of days catching up with familiar faces and meeting new people. A big thank you goes to the NetUK organisers for putting together another excellent event, and to everyone who we had a chance to connect with. These conversations are always one of the highlights of attending community events. ### A great start to NetUK3 The first afternoon opened with a strong lineup of presentations. One that immediately caught our attention was Ritesh Mukherjee's talk from Nokia on routing security. The presentation explored recent route leaks and hijacks, the current state of RPKI deployment, the role of ASPA, and the importance of improving visibility into routing anomalies. As a company working on network security every day, these topics are naturally close to what we do, and it was encouraging to see practical discussions around strengthening the resilience of the Internet's routing infrastructure. Later in the afternoon, Geoff Bennett from Nokia took the audience in a completely different direction with his fascinating presentation on space-based data centres. It is one of those ideas that initially sounds like science fiction, but the talk carefully walked through both the motivations and the engineering challenges behind the concept. Whether or not orbital data centres become reality, it certainly sparked plenty of conversations afterwards. The first day concluded with the conference social event in the Brewery courtyard. London treated us to fantastic weather, making it the perfect setting to continue conversations that had started during the sessions. Some of the best discussions at conferences happen after the presentations have finished, and NetUK was no exception. ![](https://fastnetmon.com/wp-content/uploads/2026/05/NetUK3-event-recap-FastNetMon-1024x819.png) ### Talks, ideas and more conversations The second day continued with another great set of talks and plenty of interesting discussions. David Flores kicked off one of the highlights of the day with a presentation on rethinking network monitoring. Instead of looking at monitoring as just a collection of alerts and dashboards, the talk explored a broader observability approach: bringing together metrics, logs and flows to help operators understand not only what happened, but why. As networks continue to grow more complex, having this kind of visibility is becoming increasingly important. Ralph Smit from RIPE NCC gave a great overview of Autonomous System Provider Authorisation (ASPA), a relatively new addition to the RPKI ecosystem. ASPA allows AS owners to publish their authorised upstream providers, helping to prevent route leaks, BGP path spoofing and other routing security issues. It was particularly interesting to hear that ASPA adoption is picking up speed and that more of the ecosystem is starting to support it. Stronger routing security depends on broad industry adoption, so seeing this progress is encouraging. Pete Crocker's presentation on the Network Automation Forum Framework rounded out another interesting set of talks. The framework aims to provide a vendor-neutral reference architecture and common language for network automation, making it easier for operators, vendors and developers to build systems that work well together. Bringing more consistency to automation practices across the industry is something we’re happy to see. As always, one of the biggest strengths of NetUK wasn’t just the presentations themselves, but the community around them. The opportunity to exchange operational experiences, discuss real-world challenges and learn from fellow engineers is what makes events like this so valuable. Thank you again to the NetUK team for organising another fantastic conference, and thank you to everyone who spent time talking with us over the two days. We had a great time and are already looking forward to NetUK4. **Categories:** Events, FastNetMon Blog, Featured --- ### [Introducing Netomics: a self-hosted routing intelligence platform for network operations](https://fastnetmon.com/2026/07/06/introducing-netomics-a-self-hosted-routing-intelligence-platform-for-network-operations/) **Published:** July 6, 2026 **Author:** FastNetMon **Content:** Network operators have more routing data available today than ever before. Yet in practice, the data is still scattered across multiple tools, external services, and ad hoc workflows. When investigating a routing incident, engineers typically move between BGP lookup services, RPKI validators, IRR databases, WHOIS tools, historical route collectors, and internal monitoring systems. Each provides part of the picture, but none provide the full operational context. This fragmentation is where [**Netomics**](https://netomics.com/) comes in. Netomics is a **self-hosted BGP routing intelligence platform** that brings together live routing data, registry information, routing history, validation systems, and AI-assisted querying into a single operational environment — deployed entirely inside the operator’s own infrastructure. ## **Why we built Netomics** At FastNetMon, we work closely with ISPs, cloud providers, IXPs, and large enterprises operating complex networks. One pattern has been consistent for years: routing visibility is not the problem. *Routing context is*. Operators already have access to BGP feeds, telemetry, and monitoring systems. The challenge is that answering even simple operational questions often requires correlating multiple external and internal data sources. For example: - Who originates this prefix right now? - Has this route been seen before? - Is the announcement RPKI valid? - How has this ASN behaved historically? - Is this a known customer, peer, or upstream? - Is this a new or abnormal routing path? These questions are fundamental to operations and security, yet they are typically answered by jumping between tools and manually stitching data together. Netomics was built to remove that friction. ## **A unified routing intelligence model** Netomics aggregates multiple routing data sources into a single, queryable system: - Live BGP and BMP feeds - Historical routing state and changes - ASN and prefix ownership data - Regional Internet Registry (RIR) data - WHOIS records - Internet Routing Registry (IRR) data - Geofeed information - RPKI validation - ASPA (Autonomous System Provider Authorisation) status Instead of treating these as separate systems, Netomics builds a unified model of routing intelligence that can be queried consistently across all datasets. The result is more than visibility. We are building for **contextual routing understanding**. ## **Real-time routing visibility** Traditional routing analysis systems are often snapshot-based or delayed. Netomics is designed around **live ingestion of BGP Monitoring Protocol (BMP)** feeds directly from routers. This enables operators to observe routing changes as they happen, rather than reconstructing them after the fact. In operational terms, this means: - Faster detection of routing anomalies - Immediate visibility into prefix origin changes - Real-time understanding of AS path evolution - Improved response time during incidents For large networks, this shift from “post-event analysis” to “live understanding” is critical. ## **Self-hosted by design** One of the core design decisions behind Netomics is that it runs entirely inside the operator’s infrastructure. This means: - No external API dependencies - No rate limits - No data leaving the network - No reliance on third-party uptime - Full control over routing intelligence Netomics is designed to become part of internal network operations infrastructure, with compliance and operator control built in. ## **Built for automation and AI-assisted operations** Modern network operations are increasingly automated, and Netomics is designed with that reality in mind. The platform exposes routing intelligence through: - REST APIs for integration with internal systems - Bulk lookup interfaces for large-scale analysis - Prometheus metrics for observability pipelines - Streaming interfaces for real-time systems - Model Context Protocol (MCP) support for AI assistants The inclusion of MCP support is particularly important: it allows AI systems such as ChatGPT or Claude to directly query live routing data within a controlled, self-hosted environment. This enables new workflows such as: - AI-assisted incident triage - Natural language routing queries - Automated anomaly investigation - Context-aware operational assistants Rather than replacing existing tooling, Netomics becomes a routing intelligence layer that automation and AI systems can build on. ## **Security and routing validation** Routing security remains one of the most critical challenges in Internet operations. Netomics integrates RPKI validation and routing registry data directly into its core model, enabling operators to: - Validate route origin authenticity - Identify invalid or suspect announcements - Detect potential hijack scenarios - Monitor Multi-Origin AS (MOAS) events - Correlate routing changes with registry intent This is particularly valuable in environments where routing decisions have direct operational or financial impact. ## **A platform, not just a lookup tool** While many tools focus on BGP lookups or individual datasets, Netomics is designed as an **operational routing intelligence platform**. It is intended to sit alongside existing infrastructure systems and become a central reference point for routing truth within an organisation. This makes it relevant across multiple teams: - Network Operations Centres (NOCs) - Security Operations Centres (SOCs) - Cloud networking teams - Platform engineering teams - IXP route policy teams Each of these groups interacts with routing data differently, but they share a common need: reliable, contextual, and real-time routing intelligence. ## **Availability** Netomics is available now for deployment within customer infrastructure. Selected capabilities can be explored at: [**www.netomics.com**](http://www.netomics.com) Full deployments are provided for ISPs, IXPs, cloud providers, and enterprises requiring internal routing intelligence systems. **Categories:** FastNetMon Blog, Featured --- ### [FastNetMon Community expands Fedora and EPEL support](https://fastnetmon.com/2026/07/06/fastnetmon-community-expands-fedora-and-epel-support/) **Published:** July 6, 2026 **Author:** FastNetMon **Content:** We’ve made FastNetMon Community easier to install and maintain across Fedora and Enterprise Linux environments. You can now find the updated Fedora package [here](https://packages.fedoraproject.org/pkgs/fastnetmon/fastnetmon/). **On the Fedora side**, the package has been updated to the latest version, ensuring smoother upgrades and better alignment with current Fedora releases. **For Enterprise Linux users**, FastNetMon Community is now available via the EPEL (Extra Packages for Enterprise Linux) repository. EPEL is commonly used across Red Hat Enterprise Linux (RHEL), AlmaLinux and Rocky Linux to provide access to additional open source software that is not included in the base distributions. This makes FastNetMon Community easier to adopt in environments that rely on standard system repositories and package managers, without the need for manual builds or custom installation workflows. These updates are focused on simplifying deployment in real-world production environments where consistency, repeatability and standard tooling matter. As always, we welcome feedback from users running FastNetMon Community on Fedora or Enterprise Linux systems. If you have questions or comments, feel free to reach out [via the community channels](https://fastnetmon.com/fastnetmon-engineer-community/). **Categories:** FastNetMon Blog, Featured, Press & Newsroom **Tags:** product update --- ### [New RustDuck botnet targets internet-exposed devices and servers](https://fastnetmon.com/2026/07/02/new-rustduck-botnet-targets-internet-exposed-devices-and-servers/) **Published:** July 2, 2026 **Author:** FastNetMon **Content:** A newly discovered botnet called **RustDuck** is targeting internet-connected routers, IP cameras, Android TV boxes, and exposed servers to build a DDoS attack network. Researchers at QiAnXin XLab have been [tracking the malware](https://blog.xlab.qianxin.com/rustduck-en/) since February 2026. While RustDuck is still relatively small, its rapid technical evolution makes it worth watching. Unlike many existing IoT botnets, RustDuck is being rewritten from C to Rust. The malware also incorporates advanced anti-analysis techniques, encrypted command-and-control communications, and multiple infection methods, making it more difficult for researchers to analyse and disrupt. RustDuck spreads by exploiting weak or default Telnet and SSH credentials, exposed Android Debug Bridge (ADB) services, and known vulnerabilities in routers, cameras, and enterprise software including ThinkPHP, Jenkins, Hadoop YARN, and Apache CouchDB. For network operators, the malware highlights a familiar problem: internet-facing devices with weak credentials or unpatched vulnerabilities continue to provide attackers with a steady supply of systems for DDoS botnets. Although RustDuck is not yet comparable to the largest botnets seen in recent years, it demonstrates the direction IoT malware is heading. Better evasion, stronger encryption, and faster development cycles are making botnets more resilient and harder to analyse. To reduce exposure, organisations should remove unnecessary management services such as Telnet, SSH, and ADB from the public internet, replace end-of-life networking equipment, patch supported systems promptly, and monitor their networks for signs of compromised hosts. **Categories:** FastNetMon Blog **Tags:** Botnets, DDoS News --- ### [The Current Reality of Residential Proxy DDoS Botnets](https://fastnetmon.com/2026/06/24/the-current-reality-of-residential-ddos-botnets/) **Published:** June 24, 2026 **Author:** FastNetMon **Content:** If you track cybersecurity headlines, it looks like the global battle against DDoS has entered a quiet period. The massive, record-breaking multi-terabit attacks that regularly made the front pages last year seem to have vanished. Much of this silence follows [a major international law enforcement operation](https://fastnetmon.com/2026/04/16/europol-backed-operation-poweroff-targets-ddos-for-hire-ecosystem-contacts-75000-users/), coordinated with Europol and the U.S. Department of Justice. The action successfully dismantled the command-and-control (C2) infrastructure of some of the largest botnets in history, including Kimwolf and associated networks like Aisuru, [leading to operator arrests](https://fastnetmon.com/2026/05/25/kimwolf-ddos-botnet-operator-arrested/). However, if you operate a network, manage a transit edge, or monitor daily traffic telemetry, you know that the underlying problem of DDoS just keeps growing. So what is actually happening? In this article, we’re looking into the current reality of residential DDoS botnets, drawing on research by Nokia Deepfield and the Comcast Threat Research Lab recently [presented at NANOG 97 by Craig Labovitz](https://www.nokia.com/blog/one-year-later-the-residential-proxy-botnet-problem-got-bigger-not-smaller/), [reporting from Infoblox](https://www.infoblox.com/blog/threat-intelligence/residential-proxies-in-the-wild/) and [threat intel by Bitsight](https://www.bitsight.com/blog/residential-proxy-services-malware-ecosystems#:~:text=Massive%20scale%3A%20The%20research%2C%20conducted,global%20unique%20proxy%20exit%20nodes.), combined with our own insights and operator anecdotes from the field. ### From monolithic botnets to smaller, fragmented operators When law enforcement knocked out Kimwolf’s core command servers, they cut off the centralised head, but the underlying mechanism remained completely active on millions of endpoints. As the Nokia and Comcast teams highlighted, attackers discovered a powerful weakness in parts of the residential proxy ecosystem. Rather than scanning the internet for vulnerable devices, they could abuse the proxy infrastructure itself to reach exposed Android Debug Bridge (ADB) services on participating endpoints. This allowed residential proxy access to become both the distribution channel and the attack surface, accelerating the growth of compromised device populations. Today, instead of a single, massive botnet controlling millions of nodes under a unified command, the ecosystem has broken apart: - **The Fragmented Market:** Roughly two dozen smaller, independent botnet operations are now actively competing for the same pool of infected, unpatched residential devices (smart TVs, low-cost streaming boxes, and home IoT setups). - **The Supply Chain Shift:** **Bitsight’s** latest threat research highlights that despite massive operations taking down proxy providers like **IPIDEA** earlier this year, the underlying malware supply chains (such as Badbox and Vo1d) instantly adapted, routing their hijacked device pools to competing commercial brokers within weeks. - **Explosive Growth:** Because these devices stay vulnerable despite a central C2 server being seized, new threat actors simply spin up fresh infrastructure and hijack the existing endpoints. - **The Scale:** The joint Nokia/Comcast data indicates residential proxy ecosystems growing roughly from 1 million to 8–9 million active nodes per day over the past year. The threat has transitioned from a few massive, coordinated waves into a continuous, aggressive baseline of malicious activity distributed across consumer networks worldwide. ### The perfect storm: AI capital and gigabit uploads The perfect storm: AI capital and gigabit uploads Not every residential proxy service relies on malware, and not every infected device participates in DDoS activity. However, research consistently shows significant overlap between commercial residential proxy networks and malware-operated infrastructure. The question is why this footprint continues to expand so rapidly. The answer lies in a combination of market economics and modern telecom infrastructure: #### 1. The multi-billion-dollar AI scraping engine The rapid growth of AI systems has significantly increased demand for large-scale web data collection. In some cases, scraping pipelines use residential proxy networks to reduce blocking, balance geographic distribution, or access content that is difficult to retrieve at scale from datacenter infrastructure. As a result, residential IP space has become a highly valued commodity in the data acquisition ecosystem. The Infoblox research shows that residential proxy infrastructure is also visible across enterprise environments. Over 65% of their customers generated DNS queries to domains associated with residential proxy networks in 2026, reflecting both direct usage and broader exposure within monitored networks. Across their customer base, DNS queries to residential proxy–related domains increased from roughly 400 billion per month in 2025 to over 500 billion per month in 2026. Infoblox attributes part of this growth to increased demand for large-scale data collection, including AI-related scraping activity, alongside continued use of proxyware and residential proxy services embedded in consumer and enterprise environments. #### 2. The symmetry windfall The telecom industry’s aggressive push to deploy symmetric gigabit and multi-gigabit home fibre connectivity has inadvertently handed these botnets massive upstream pipelines. Network planners historically assumed home users would rarely saturate their upload bandwidth. A compromised proxy node launching an outbound UDP flood is one of the few applications that will happily consume every single megabit of available upstream capacity. **The Reality:** Residential proxy infrastructure now rivals the world’s largest transit and content networks in aggregate upstream capacity. It is no longer a niche nuisance, but a permanent piece of internet infrastructure. ### Shifting the focus: The outbound network crisis DDoS defence has traditionally focused on the inbound vector - protecting your own data centre or downstream enterprise customers from being knocked offline. But as residential networks are weaponised from the inside out, network operators face severe, self-inflicted [operational crises caused entirely by **outbound DDoS** traffic](https://fastnetmon.com/2025/09/24/outbound-ddos-the-attack-you-might-be-unknowingly-hosting/). For an ISP, this creates an unprecedented internal strain: - **State Table Exhaustion:** High-volume outbound UDP carpet-bombing floods quickly exhaust the state tables of your own Broadband Network Gateways (BNGs) and carrier-grade NAT (CGNAT) systems, degrading service for innocent users. - **Transit Cost Explosions:** Your expensive, legitimate transit links get choked by outbound garbage traffic, driving up your commit costs. - **IP Reputation Destruction:** Your Autonomous System (AS) IP ranges end up flagged on global blocklists, causing immediate authentication failures and CAPTCHA nightmares for your legitimate subscribers. ### Practical traffic hygiene We aren’t going to see a permanent manufacturing fix for insecure home IoT devices anytime soon. Protecting your routing table right now comes down to practical, proactive network hygiene. By tracking outbound telemetry and dropping botnet traffic right at your own border routers, you starve the botnet of its upstream pipes while protecting your own infrastructure. This is exactly where **FastNetMon** can help. While historically deployed to detect inbound volumetric spikes, our engine tracks telemetry counters for [both incoming and outgoing traffic directions completely independently](https://fastnetmon.com/docs-fnm-advanced/per-direction-hostgroup-thresholds/). By analysing NetFlow, sFlow, or IPFIX records straight from your edge or border routers, FastNetMon establishes baseline metrics for regular subscriber uploads. If a cluster of compromised residential endpoints triggers a synchronized outbound attack, the system detects the anomaly based on your configured packets-per-second (PPS) or bandwidth thresholds. From there, it can automatically apply mitigation policies, such as pushing **BGP Flow Spec** or **Remote-Triggered Blackholing (RTBH),** directly to your network hardware. The infected devices stay infected for now, but they are instantly starved of their ability to harm the wider internet or your bottom line. ### A shared operational responsibility When a global takedown knocks out a major command server, the underlying industry does not vanish, unfortunately. We saw this earlier this year when U.S. proxy infrastructure was disrupted: the traffic didn't die; it simply migrated to Latin America, with Brazil quickly filling the gap. Dealing with residential proxies is a fast-moving, highly adaptable industry-wide problem. Treating outbound security as a shared operational responsibility is no longer optional. By deploying automated telemetry monitoring at your border, you protect your own transit costs and BNG state tables, while actively helping to clean up the global internet routing table. **Categories:** FastNetMon Blog --- ### [Understanding Ultra Ethernet and the 1.6T Ethernet standard](https://fastnetmon.com/2026/06/25/understanding-ultra-ethernet-and-the-1-6t-ethernet-standard/) **Published:** June 25, 2026 **Author:** FastNetMon **Content:** If you work in networking, you know the drill: optimise for throughput, minimise packet loss, and let the upper layers deal with the rest. That approach has worked well for decades. However, **AI workloads place very different demands on networks** than traditional enterprise applications. When thousands of GPUs communicate with each other to train a single AI model, they generate enormous amounts of east-west traffic and frequent bursts of data exchange. These workloads have exposed limitations in traditional data centre networking designs and are driving the industry towards new approaches. Two technologies are at the centre of this shift: Ultra Ethernet and 1.6T Ethernet. Although they are often discussed together, they solve different problems: - **1.6T Ethernet** is about moving more data through the network. - **Ultra Ethernet** is about moving AI traffic more efficiently. Think of 1.6T as building wider motorways, while Ultra Ethernet is about managing traffic more intelligently. If you're a network operator trying to make sense of the latest acronyms, here's a plain-English introduction to what these technologies are, how they work, and why they matter. ### 1. What is 1.6T Ethernet? (The physical speed) Simply put, 1.6T stands for 1.6 Terabits per second. It is the next major Ethernet speed generation after 800G. To put that into perspective, a 1.6T link can move approximately 200 gigabytes of data every second. That's roughly 1,600 times faster than the 1 Gigabit Ethernet connection still found on many laptops and office devices. The technical specifications are being defined by the IEEE 802.3dj task force, which is developing standards for 200G, 400G, 800G and 1.6T Ethernet. #### How does 1.6T work? Rather than creating a single massive data channel, manufacturers achieve 1.6T by combining multiple high-speed lanes. ##### **224G lanes** A typical 1.6T connection uses eight parallel lanes operating at approximately 200–224 Gigabits per second each. 8 × 200G = 1.6T ##### **PAM4 signalling** To transmit data at these speeds, modern Ethernet uses PAM4 (Pulse Amplitude Modulation with four levels). Traditional signalling uses two voltage levels to represent binary values. PAM4 uses four distinct signal levels, allowing each symbol to carry twice as much information and effectively doubling data density. ##### **The real-world challenge: physics** At these speeds, electrical signals degrade rapidly. Running 200G+ lanes over copper becomes increasingly difficult as distance increases. Signal loss, interference and power consumption all become significant engineering challenges. As a result, hyperscale data centres are increasingly adopting: - Active Electrical Cables (AECs), which include signal-conditioning electronics inside the cable assembly - Active Optical Cables (AOCs) - High-density optical interconnects such as MPO-based fibre systems The higher the bandwidth, the more important optical connectivity becomes. ### 2. What is Ultra Ethernet? (The smart brain) Having a 1.6T link is only useful if the network can efficiently handle the traffic flowing through it. Historically, many AI clusters have used RoCEv2 (RDMA over Converged Ethernet) to achieve low-latency communication between GPUs. RoCEv2 performs best on highly lossless networks. Even small amounts of packet loss can impact performance because distributed AI workloads are extremely sensitive to latency and retransmissions. To understand why this matters, imagine 10,000 GPUs training a large language model. Every few milliseconds, they exchange updated model parameters with thousands of other GPUs. If some GPUs are delayed waiting for network traffic, the entire training job can slow down while expensive accelerators sit idle. To address these challenges, companies including AMD, Broadcom, Cisco, Intel, Meta and Microsoft formed the [Ultra Ethernet Consortium (UEC)](https://ultraethernet.org/). Their goal is to make Ethernet better suited for large-scale AI infrastructure. Rather than relying on traditional networking approaches, Ultra Ethernet introduces new mechanisms designed specifically for AI traffic patterns. ##### **Adaptive load balancing** Instead of forcing traffic through a single path, Ultra Ethernet can distribute traffic across multiple available routes, reducing hotspots and improving bandwidth utilisation. ##### **Out-of-order delivery** Traditional networking often expects packets to arrive in sequence. Ultra Ethernet allows packets to take different paths through the network and arrive out of order, with the receiving system responsible for reassembling them correctly. ##### **Smarter recovery mechanisms** If packets are lost due to congestion or other issues, Ultra Ethernet is designed to recover efficiently without causing widespread performance degradation across the cluster. The goal is simple: keep GPUs busy and minimise time spent waiting on the network. ### 3. The comparison: InfiniBand vs Ultra Ethernet Today, large-scale AI networking is largely split between two approaches. On one side is InfiniBand, which has long been the preferred technology for high-performance computing and AI supercomputers. InfiniBand is largely controlled by Nvidia and offers a tightly integrated ecosystem of adapters, switches and management software. It delivers extremely low latency and excellent performance at scale. On the other side is Ultra Ethernet. Rather than creating a separate networking technology, Ultra Ethernet builds on the Ethernet ecosystem that already dominates modern data centres. The key advantage is openness. Because Ethernet is supported by multiple hardware vendors, operators can potentially build AI infrastructure using components from companies such as Broadcom, Intel, AMD, Cisco, Arista and others. For hyperscalers, that flexibility can help reduce costs, increase supplier choice and minimise dependence on a single vendor ecosystem. ### 4. Is Ultra Ethernet relevant beyond AI datacenters? Even if you're not building AI superclusters, these developments are worth watching. AI infrastructure is changing how modern data centres are designed. From a network operations perspective: - East-west traffic volumes continue to grow - Congestion becomes increasingly expensive - Network visibility becomes more important as clusters scale - High-speed optical interconnects are becoming mainstream Many of the innovations being developed for AI environments will eventually influence broader data centre networking designs. ### 5. When is this actually happening? The transition is already underway. ##### **Today** Ultra Ethernet 1.0 has been released, and major vendors are building products around its specifications. Meanwhile, 800G Ethernet remains the primary deployment speed for most large-scale data centre networks. ##### **The next few years** Hyperscalers are expected to begin adopting 1.6T deployments for new AI-focused infrastructure as hardware availability increases and standards mature. However, 800G is likely to remain the dominant deployment speed across much of the industry for some time. ##### **Long term** Most enterprises, campuses and office networks have no immediate need for 1.6T connectivity. For the foreseeable future, technologies such as 10G, 25G, 100G and 400G Ethernet will continue to meet the needs of the majority of organisations. ### Ethernet is evolving faster than ever Ethernet used to evolve in steady cycles. New speeds arrived every several years, and each generation took time to move from hyperscale deployments into wider use. That pattern is changing. AI infrastructure is accelerating the roadmap. The industry has moved from 400G to 800G and is already heading toward 1.6T in just a few years. At the same time, Ultra Ethernet is being developed to address not just speed, but how traffic behaves inside large AI clusters. This is one of the fastest periods of change in Ethernet’s history. What used to take close to a decade is now happening in two-to-three year cycles at the high end of the market. Also, it is noteworthy to mention that Ultra Ethernet and 1.6T are not isolated upgrades. They are signs of a broader shift where AI is now a major driver of network design, from link speeds to congestion handling and traffic flow. **Categories:** FastNetMon Blog --- ### [Case Study: Enhancing network security with country lockdown - a major American insurance corporation](https://fastnetmon.com/2024/12/25/case-study-enhancing-network-security-with-country-lockdown-a-major-american-insurance-corporation/) **Published:** December 25, 2024 **Author:** FastNetMon **Content:** [Case Study: FastNetMon Country Lockdown Solution in Insurance Environment](https://fastnetmon.com/wp-content/uploads/2024/12/Case-Study-FastNetMon-Country-Lockdown-Insurance.pdf)[Download](https://fastnetmon.com/wp-content/uploads/2024/12/Case-Study-FastNetMon-Country-Lockdown-Insurance.pdf) ## Overview A leading North American insurance corporation, specialising in life insurance and a broad array of financial products and services, has implemented FastNetMon's advanced country lockdown feature to enhance its network security posture. This case study explores the application of this feature within the corporation's network infrastructure, highlighting the technical implementation and the benefits realized. ## Challenge The insurance industry is highly susceptible to cyber threats due to the sensitive nature of the data involved. The corporation faced specific challenges related to potential intrusions from certain geographic regions, which were identified as high-risk due to recurring unauthorized access attempts and other security threats. There was a need to implement a solution that could preemptively block traffic from these regions to ensure compliance and enhance security. ## Solution The corporation opted to utilize FastNetMon's country lockdown capability, a sophisticated feature designed to block traffic from specified countries. This decision was driven by the need for a robust security measure that could be seamlessly integrated with their existing network infrastructure. ## Implementation The technical team at the insurance corporation followed a structured approach to implement the country lockdown feature: **1. Installation and Configuration**: FastNetMon Advanced was installed, and a BGP peering session was established with the corporation's routers. The necessary plugin for the country lockdown feature was obtained from FastNetMon's support team. **2. GeoIP Database Integration**: The team configured the system to use the GeoIP2-Country database from MaxMind, ensuring that the path to the database was correctly set in the `country\_lockdown.json` configuration file. This database is crucial for accurately identifying the geographical source of IP addresses. **3. Defining the Block List:** The corporation identified and listed the countries from which traffic needed to be blocked. The list of countries remains confidential, but for the sake of demonstration for this case study, let's assume the country code "TV" (Tuvalu) was used as an example in the block list to demonstrate the functionality. **4. Allow List Configuration**: To ensure legitimate traffic from blocked countries was not affected, specific IP addresses were added to an allow list. This list included IPs that were critical for business operations but originated from the otherwise blocked regions. **5. Execution and Monitoring:** The configured script was initially executed to set up the country lockdown, and the system began to announce all prefixes to block using the BGP daemon. The output logs confirmed the successful loading of the GeoIP file, the correct configuration of the next hop, and the detailed list of blocked prefixes. It is important to note that this process requires ongoing monitoring and adjustments. The script is designed to periodically update and re-evaluate the blocking rules based on changes in the GeoIP database, modifications in the list of allowed IP addresses that might affect the list of blocked countries. This continuous monitoring ensures that the network remains protected against emerging threats while accommodating necessary traffic for business continuity. ## Results The implementation of the country lockdown feature provided several key benefits: **Scalability and Flexibility**: The solution provided the flexibility to quickly adjust the list of blocked countries based on evolving threat intelligence and compliance requirements. **Enhanced Security Posture:** By blocking potentially harmful traffic from high-risk countries, the corporation significantly reduced its exposure to cyber threats originating from those regions. **Compliance Assurance**: The feature supported compliance with industry regulations that mandate specific geographic restrictions, thereby protecting the corporation from potential legal and financial penalties. **Operational Efficiency**: The automation of the blocking process through BGP announcements ensured that the network's security measures did not require manual intervention, thereby saving time and reducing the likelihood of human error. ## Conclusion The deployment of FastNetMon's country lockdown feature at the North American insurance corporation demonstrates a proactive approach to network security. By leveraging geographic data to block traffic from designated countries, the corporation has enhanced its ability to guard against cyber threats while maintaining compliance with regulatory requirements. This case study serves as a model for other organizations in the financial sector seeking to bolster their network defenses through targeted geographic restrictions. --- ## About FastNetMon FastNetMon delivers versatile DDoS detection software for companies at any scale. With extensive experience in the telecom, mobile, and cloud computing industries, we take pride in preventing DDoS attacks and protecting our customers’ networks to the highest standard. Find out more: <https://fastnetmon.com/> **Categories:** Case studies, Press & Newsroom **Tags:** case study --- ### [Engineering deep dive: How AMS-IX uses FastNetMon for automated DDoS mitigation](https://fastnetmon.com/2026/01/27/engineering-deep-dive-how-ams-ix-uses-fastnetmon-for-automated-ddos-mitigation/) **Published:** January 27, 2026 **Author:** FastNetMon **Content:** ## **Introduction** DDoS attacks have long been a thorn in the side of network operators—but AMS-IX faced a particularly unusual challenge. Unlike the massive volumetric attacks that make headlines, the attacks targeting their management network were **low-bandwidth but high-flow**, exploiting vulnerabilities in session tables, firewall logging, and internal routing. Even small bursts of DDoS traffic could cascade into network-wide disruptions, impacting office connectivity, VPN users, internal services, and DNS resolution. This deep dive explores the full journey of **how AMS-IX, in an implementation led by Stavros Konstantaras, built an automated, resilient DDoS mitigation system** from scratch. In this detailed technical analysis, you’ll learn: - How a few megabits per second of traffic brought the network to its knees, and the chain reactions that caused the collapse. - The architecture of AMS-IX’s management network, including routers, firewalls, and the spine-leaf management fabric, and how traffic flows under normal and attack conditions. - The challenges and limitations of manual mitigation, including firewall tuning, session table management, and security team coordination. - How AMS-IX designed a fully automated mitigation pipeline, combining **FastNetMon detection**, **Python orchestration/BIRD2/BGP signalling**, and **NAWAS scrubbing**. - Testing strategies, lessons learned, and results, including real-world attacks that were mitigated automatically without human intervention. - Future improvements, including router upgrades, migration from NetFlow to IPFIX, smarter mitigation algorithms, and IPv6 strategies. This deep dive is written for **network engineers, NOC teams, and technical decision-makers**, providing a full overview of the architecture, workflows, and operational considerations that went into protecting a critical Internet Exchange. *Special thanks to* ***Stavros Konstantaras, Senior Network Engineer at AMS-IX****, for designing, implementing, and stress-testing this system, and for sharing his experience with us. We also want to thank* ***AMS-IX*** *for enabling this case study and providing a detailed real-world example of complex network defence.* --- **Prefer a video? Watch Stavros walk through the case in his own words.** ## **The Problem: When Small Attacks Cause Big Collapses** The saga began when a few megabits of UDP traffic targeting AMS-IX’s public DNS servers brought the management network to a halt. VPN users were disconnected, internal email and messaging stopped, NAT and DNS transit were disrupted, while multiple internal services became unreachable. Oddly, the production network—the one carrying customer traffic—remained unaffected. Stavros and the team quickly realised: this wasn’t a typical volumetric DDoS attack. Very modest traffic volumes of a few Mbps caused cascading failures in the admin network that ended up in sudden disruption of office connectivity, leaving the entire team without access to internal and external resources for several minutes at a time. Step by step, the investigation revealed the chain reactions: **Traffic volumes appeared harmless**: Graphs showed only a few megabits per second reaching internal servers: ![](https://fastnetmon.com/wp-content/uploads/2026/01/FastNetMon-case-study-AMS-IX-traffic-volume-2-1-1024x408.png)Firewalls became the bottleneck: CPU and session tables maxed out because each DNS query, even valid ones, consumed state at the firewall’s session table. As you can see in the graph below, the timestamps CPU overload match with attack time stamps. ![](https://fastnetmon.com/wp-content/uploads/2026/02/FastNetMon-case-study-AMS-IX-CPU-overload-1024x408.png)**Cascading failures ensued**: Overloaded firewalls triggered LACP BPDU drops, OSPF session expirations, and lost default gateways for internal systems, leading to internal applications spiking syslog traffic. This created a feedback loop, compounding the problem. **NetFlow overhead worsened the situation**: Pre-enabled NetFlow on Palo Alto’s added CPU load, accelerating the collapse. The team tried the built-in firewall mitigations, including zone protection and session limits, but nothing prevented a new round of collapse. Manual intervention proved too slow—**the network needed a fully automated detection and mitigation system to stop the attacks in real time.** ## **Understanding the Network Architecture** To better illustrate the problem and the solution, it is useful to understand exactly how traffic flows through the AMX-IX management network. The architecture looks rather straightforward: ![](https://fastnetmon.com/wp-content/uploads/2026/02/FastNetMon-case-study-AMS-IX-network-diagram-1--1024x538.png)**Border routers**: Two Cisco ASR1001 routers handled initial packet inspection and forwarding. **Firewall clusters**: Two clusters of Palo Alto 3050 firewalls in active-passive mode managed security inspection and session tracking. **Management layer**: Dell switches running Pluribus OS in a spine-leaf fabric connected the network internally. **Internal services**: DNS, HTTP, mail, and other internal services resided behind the firewalls in the DMZ. Taking as an example the DNS traffic, the flow into the network looks according to the following diagram: ![](https://fastnetmon.com/wp-content/uploads/2026/02/FastNetMon-case-study-AMS-IX-network-diagram-2-1024x538.png) 1. Packet arrives from transit providers and hits a border router. 2. Border router verifies the packet and forwards it to the management fabric. 3. The firewall establishes a session, inspects the payload and forwards it to the internal DNS server. 4. DNS response is returned through the same path. Yet this “simple” flow hid a problem: **firewalls logged sessions for every packet**, creating a massive state burden. Even small flow-based attack bursts quickly consumed session tables, triggering the chain reaction described above. ## **Early Mitigation Attempts and Limitations** The first attempts to mitigate the attacks were purely manual: - Firewall tuning (Palo Alto zone protection, session limits) - Manual activation of scrubbing services from NBIP/NAWAS - Splitting public services into the cloud to absorb some traffic Despite these efforts, attacks continued to cause downtime. The flow rate was too high for the firewall to handle, and **manual mitigation took too long**—by the time an engineer reacted, firewalls were already maxed out. The need for automation became clear. ## **Designing the Automated DDoS Mitigation Pipeline** The solution combined three key elements: **detection (the brain), mitigation (the shield), and orchestration (the glue)**. ### **1. The Brain: FastNetMon Detection** FastNetMon provided: - Reliable, automated detection of flow-based DDoS attacks - Support for multiple sampling methods (NetFlow, sFlow, IPFIX) - Integration with home-made scripts to trigger mitigation ### **2. The Shield: NAWAS Scrubbing** [NAWAS](https://www.nbip.nl/en/nawas/) is a DDoS scrubbing centre run by NBIP, a Dutch non-profit that helps internet and infrastructure providers with shared cybersecurity and compliance services. NAWAS served as a scrubbing centre for the solution: - Traffic is redirected during attacks to the NAWAS scrubbing centre for cleaning - Bad traffic is scrubbed, and clean traffic is returned via the Peering Platform - Existing contract and infrastructure allowed AMS-IX to use it without extra cost ### **3. The Glue: Python-based Orchestration with Bird2 and BGP Signaling** Automation relied on a **custom pipeline**: ![](https://fastnetmon.com/wp-content/uploads/2026/02/FastNetMon-case-study-AMS-IX-network-diagram-3-1024x538.png) 1. **Traffic sampling**: Border routers send flow data to FastNetMon via the peering fabric. 2. **Attack detection**: FastNetMon detects an attack and triggers the script notify\_about\_attack.sh. 3. **Python orchestration**: Custom script determines which prefixes are under attack and configures Bird2. 4. **BGP signalling:** Bird2 communicates via iBGP with the CISCO border routers to signal the prefixes that are under attack. Consequently, the Cisco border routers re-advertise those more-specific prefixes to NAWAS via eBGP. Since NAWAS has direct access to DFZ via TIER-1 providers, it will quickly attract all traffic destined for those prefixes, and eventually, the DDoS traffic will be scrubbed. ![](https://fastnetmon.com/wp-content/uploads/2026/02/FastNetMon-case-study-AMS-IX-network-diagram-4-1024x538.png)## **Testing the System** To ensure reliability, Stavros and the team: - Launched external DDoS tests using a virtual machine hosted several hops away to mimic real-world conditions - Generated millions of packets for both IPv4 and IPv6 DNS queries - Measured **reaction time from the second of launching the attack to the moment of full mitigation**, achieving **a fully automated reaction in ~45 seconds** for IPv4 traffic ## **Summary and results** The story paints a picture of a painful reality many engineers can relate to: even small amounts of UDP DNS traffic—just a few megabits per second—were enough to bring down the network. Firewalls hit session limits, CPUs spiked, and internal services failed. Engineers scrambled with manual mitigation steps, often arriving too late, leading to repeated periods of downtime and operational disruption. The solution, meticulously designed and implemented by Stavros and his team, turned this around. FastNetMon became the brain of the operation, automatically detecting suspicious traffic flows and signalling exactly which prefixes were under attack. Python scripts and Bird2 handled the orchestration, sending only the affected subnets to NAWAS for scrubbing, while clean traffic continued uninterrupted. The solution was clean, simple, and it works. During internal testing, millions of attack packets were sent at once, yet the system responded in just 45 seconds. Later, in live conditions, multiple DDoS attempts were fully mitigated without the NOC even noticing—engineers no longer had to use time and resources to respond manually. In short, what had once been a painful disruption is now a seamless, automated defence. The management network remains stable under attack, firewalls no longer collapse, and services stay online. The solution not only restored reliability but also gave the engineering team confidence and peace of mind: the network could now reliably withstand the kinds of bot-driven, rampant attacks that had previously been very problematic. This case illustrates how deep technical understanding, combined with automation and carefully integrated tools, can transform a reactive, fragile network into a resilient, self-defending system. It is a blueprint for engineering teams facing similar DDoS challenges: identify the weak points, automate detection, and integrate mitigation tightly with routing and scrubbing mechanisms. --- ## **About FastNetMon** FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** Case studies, FastNetMon Blog, Press & Newsroom --- ### [Case Pentanet: Real-Time DDoS Detection at the Edge](https://fastnetmon.com/2026/04/06/case-pentanet-real-time-ddos-detection-at-the-edge/) **Published:** April 6, 2026 **Author:** FastNetMon **Content:** ## Introduction For network engineers running ISP infrastructure, DDoS activity does not always present as an obvious incident. Instead, unusual traffic patterns may only become visible during later analysis, long after the event itself. This was the operational reality at Australian ISP Pentanet. As the network grew and traffic arrived through multiple upstream and peering paths, existing monitoring tools provided visibility into traffic trends but lacked real-time detection and automated response. At the same time, customers increasingly expected DDoS protection as part of connectivity services. Pentanet needed a way to gain immediate visibility into edge traffic while introducing scalable DDoS detection and mitigation capabilities into their network. This case study is based on discussions with **Jeremy Hall, CTO and Head of Product at Pentanet**, about Pentanet’s deployment and operational use of FastNetMon. We appreciate him for taking the time to share his team’s experience. ## About the Customer [Pentanet](https://pentanet.com.au/) is an Australian telecommunications provider delivering connectivity services to residential and enterprise customers across Australia. In addition to traditional ISP services, Pentanet also exclusively hosts and operates the NVIDIA GeForce NOW powered by CloudGG platform and service ([cloud.gg](http://cloud.gg/)) as an official NVIDIA alliance partner, delivering streaming cloud gaming services to a customer base across Australia and New Zealand. This combination of broadband access and latency-sensitive cloud infrastructure creates a diverse and demanding traffic environment. Pentanet’s network supports multiple service types simultaneously, including: - carrier-grade NAT (CGN) networks - residential services with public IPs - enterprise customer connectivity - internal infrastructure systems supporting hosted platforms such as CloudGG Traffic reaches the network through multiple paths, including transit providers, internet exchanges, and peered cloud networks. Each ingress path introduces different traffic characteristics, operational requirements, and potential attack vectors. For an ISP operating both consumer connectivity and real-time cloud platforms, maintaining consistent service quality depends on understanding traffic behaviour at the edge — where congestion, abuse, and DDoS activity first become visible. ## The Challenge: Sample-based flow monitoring was not enough Before deploying FastNetMon, Pentanet relied on a sample-based flow monitoring solution. While useful for general monitoring, it lacked the granularity required for operational security. At the same time, customers increasingly expected DDoS protection as part of connectivity services, creating a need for detection and mitigation capabilities that could operate directly within Pentanet’s own network. ![](https://fastnetmon.com/wp-content/uploads/2026/03/quote.png) > **"We had challenges with limited visibility coming from a lack of granularity… making post-incident analysis difficult, with no clear pathway to alerts or real-time automated actions"** The team could observe overall traffic trends, but the monitoring setup did not reliably detect attacks in real time. Incidents were typically identified only after investigation, by manually correlating spikes in throughput graphs with unusual traffic behaviour. In practice, detection depended on engineers recognising anomalies themselves rather than the network generating actionable alerts. ### Limits of Upstream Mitigation Pentanet also had access to automated mitigation from an upstream provider. However, this approach introduced operational gaps: - mitigation activated slowly - visibility into attack behaviour was limited - less effective against highly distributed attacks Large distributed attacks increasingly arrived through internet exchanges, peered cloud providers, or alternative transit connections, bypassing upstream controls. The team needed detection capability within their own network — close to the edge routers handling incoming traffic. ## Implementation: Introducing FastNetMon Pentanet deployed FastNetMon initially as a proof of concept focused on detection and alerting. The results appeared quickly: Just days after deploying a trial PoC it was detecting actual DDoS which otherwise would have gone unnoticed. ![](https://fastnetmon.com/wp-content/uploads/2026/03/Pentanet-FastNetMon-Case-study.png)*A DDoS event detected only a day after deploying FastNetMon in monitoring mode*### Real-Time Edge Visibility with sFlow FastNetMon receives [sFlow telemetry](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-sflow-configuration/) from Pentanet’s edge routers and continuously analyses traffic in real time. ![](https://fastnetmon.com/wp-content/uploads/2026/03/quote.png) > **“FastNetMon receives sFlow from each of our edge routers and gives us high resolution insight into the traffic on our edge.”** This provides engineers with immediate visibility into [host-level traffic behaviour](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-per-host-hostgroups/) rather than aggregated historical metrics. Traffic anomalies become operational events instead of forensic discoveries. ### Detection Built Around Network Structure Pentanet configured FastNetMon to reflect how their network actually operates. Separate host groups are defined for: · CGN IP ranges · Residential/business services with public IPs · Enterprise customers · Pentanet’s internal infrastructure · NVIDIA GeForce NOW zones [Each group uses independent detection thresholds](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-per-host-hostgroups/) and mitigation actions. This prevents enterprise traffic patterns from triggering residential thresholds and allows policies aligned with real traffic expectations. Initial thresholds are based on Mbps and packets-per-second values appropriate to each customer class. FastNetMon’s [built-in baselining tool](https://fastnetmon.com/docs-fnm-advanced/automated-baseline-calculation-with-fastnetmon-advanced/) helps establish these safely: ![](https://fastnetmon.com/wp-content/uploads/2026/03/quote.png) > **"FastNetMon’s built-in baselining tool is super useful and made defining our first set of thresholds easy and low risk.**" The team now iterates toward more adaptive detection using the flexible\_thresholds feature. ### Automated Mitigation via BGP RTBH FastNetMon integrates directly with Pentanet’s routing infrastructure to automate mitigation. The deployment includes: - GoBGP peering from FastNetMon - integration with Arista EOS routers - automated Remote Triggered Black Hole (RTBH) announcements When traffic exceeds defined thresholds, FastNetMon automatically triggers mitigation through BGP signalling, suppressing attack traffic without manual intervention. Detection and response occur as part of normal routing behaviour rather than a separate workflow. ### Operational Integration FastNetMon integrates into existing operational tooling instead of introducing new processes. [Notifications are sent to Slack](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-and-slack-integration/) for visibility, while incident response workflows are integrated with PagerDuty using FastNetMon’s [email notification system.](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-e-mail-notification/) ![](https://fastnetmon.com/wp-content/uploads/2026/03/quote.png) > **“Ban events from FastNetMon create a PagerDuty incident and unban events resolve a correlated incident.”** This links detection directly to the incident lifecycle: alerts generate incidents automatically, and mitigation resolution closes them. ## Outcomes and Operational Impact Following deployment, DDoS events that previously went unnoticed are now detected and surfaced in near real time. FastNetMon quickly begins identifying active attacks during the proof-of-concept phase, providing immediate operational value. Pentanet gained: - near real-time DDoS detection at the network edge - automated response through BGP RTBH mitigation - immediate operational alerting via Slack and PagerDuty - improved visibility into traffic behaviour across customer groups Detection and mitigation now operate as part of normal network workflows rather than manual investigation. Events generated by FastNetMon automatically create and resolve incidents in PagerDuty, allowing engineers to monitor the situation in real-time while reducing manual and investigative overhead. Beyond DDoS protection, FastNetMon also provides high-resolution traffic visibility, helping the team better understand baseline behaviour across different customer segments. ### Why FastNetMon Fits the Environment For Pentanet, adopting FastNetMon is less about introducing a new platform and more about extending existing network operations with tooling that behaves the way engineers expect. The system integrates naturally into a network-centric workflow. Its network-device-style CLI, straightforward configuration model, and clear documentation allow the team to deploy and operate it without adding operational complexity. Configuration remains simple while still providing the flexibility needed to support different customer types and traffic profiles across the network. Equally important is predictability. Detection, alerting, and mitigation behave consistently, allowing FastNetMon to become part of daily operations rather than a tool used only during incidents. ![](https://fastnetmon.com/wp-content/uploads/2026/03/quote.png) > **“The product simply does what it’s supposed to do.”** In practice, that reliability — combined with fast detection and seamless integration into existing tooling — is what makes FastNetMon a practical fit for Pentanet’s production environment. **Categories:** Case studies, FastNetMon Blog, Featured, Press & Newsroom --- ### [Case Joy Services: Automated DDoS detection and hardware-accelerated mitigation](https://fastnetmon.com/2026/06/15/case-joy-services-automated-ddos-detection-and-hardware-accelerated-mitigation/) **Published:** June 15, 2026 **Author:** FastNetMon **Content:** ### **Introduction** For cloud infrastructure and infrastructure-as-a-service (IaaS) providers handling highly dynamic workloads, network availability is directly tied to customer retention. When volumetric DDoS attacks strike, the immediate consequence is often network congestion that can affect customer services and infrastructure availability. This was the challenge faced by Indian provider [Joy Services](https://joy.services/). Following the expansion of their cloud platforms into gaming workloads, the network became the target of high-volume DDoS attacks. The attacks saturated network capacity and caused service disruption, highlighting the need for both automated detection and rapid mitigation. To address this challenge, Joy Services upgraded parts of its network infrastructure to hardware that could handle heavy packet floods without overloading the CPU and deployed FastNetMon Community Edition to detect and mitigate attacks in real time. This case study is based on discussions with Chander Parkash from Joy Services regarding the company's implementation and use of FastNetMon. We appreciate him for taking the time to share his experience. ### **About the Customer** Joy Services is an Indian cloud and infrastructure provider established in 2022. The company operates an edge delivery ecosystem that provides cloud infrastructure and hosting services, including VPS, dedicated servers, DNS, storage solutions, content delivery services, cloud gaming infrastructure, cybersecurity services, backup solutions, and database services. To support this infrastructure, Joy Services runs a highly multi-homed network built on Cisco Nexus switches and Juniper PTX1000 routing hardware. Their edge topology includes a minimum of two upstream transit providers per location and direct peering paths with more than 500 ISPs. For internal visibility and monitoring, the engineering team utilises a mix of both NetFlow and sFlow traffic telemetry across their environments. ### **The challenge: Volumetric DDoS attacks affecting network availability** In mid-2024, shortly after onboarding a new gaming customer, Joy Services faced its first major DDoS incident: a DNS amplification attack targeting customer infrastructure. The incident exposed the impact that large-scale DDoS attacks could have on the network. #### **Network saturation** High-volume attack traffic completely consumed the available capacity of a network link, causing approximately 10 to 15 minutes of downtime during the first incident. As targeted attacks became more frequent, the lack of automated defence workflows led to operational challenges and customer impact. The engineering team needed a solution that combined specialised hardware forwarding with real-time attack detection and automated mitigation. ### Implementation: Decoupling forwarding and automation The mitigation strategy executed by Joy Services was split into two primary layers: a hardened network edge and the deployment of FastNetMon to orchestrate automated defence. #### Hardware-Assisted Edge Protection To better handle high packets-per-second (PPS) attacks, the team replaced a standard router with specialised Juniper PTX1000 routing hardware alongside Cisco Nexus switches. According to Joy Services, the key advantage of this approach is that ASIC-based packet forwarding does not overload the CPU during high-PPS attack scenarios. This architectural change helped ensure the network could continue forwarding traffic efficiently even during large attack events. #### Telemetry Processing and Real-Time Visibility With the hardware layer secured, Joy Services deployed FastNetMon Community Edition as its centralised DDoS detection and network visibility platform. The edge routers and switches stream continuous NetFlow and sFlow data directly into FastNetMon. Network engineers use the platform to gain visibility into traffic patterns, monitor per-host and per-subnet statistics, and identify top-talker IP addresses through Grafana dashboards. Instead of relying solely on customer reports or downstream monitoring systems, the team gained real-time visibility into anomalous traffic and attack activity across the network. #### Automated Mitigation via RTBH To handle incoming volumetric attacks without manual intervention, Joy Services integrated FastNetMon with an upstream provider that supports [Remote Triggered Black Hole (RTBH) mitigation](https://fastnetmon.com/bgp-blackhole-automation/). **Fast Detection:** FastNetMon detects incoming DDoS anomalies within approximately 2 to 15 seconds, according to Joy Services. **Upstream Mitigation:** When attack thresholds are exceeded, FastNetMon automatically triggers RTBH mitigation through the upstream provider, allowing attack traffic to be dropped before it can continue affecting the targeted destination. **Automated Recovery:** RTBH mitigation is applied temporarily for approximately 200 seconds. Once attack traffic subsides, normal routing is restored automatically. ### **Suppressing outbound DDoS attack vectors** By 2025, the threat landscape expanded to include outgoing DDoS attacks originating from within the cloud environment. Joy Services leveraged FastNetMon's traffic monitoring capabilities to identify and mitigate these outbound attack events. By monitoring both inbound and outbound traffic, the team gained additional visibility into suspicious traffic patterns and potential security issues affecting customer infrastructure. If an internal server begins generating abnormal outbound traffic, FastNetMon can help identify the activity and enable rapid mitigation, reducing the operational impact of the incident. ![](https://fastnetmon.com/wp-content/uploads/2026/03/quote.png) > **"I would like to recommend FastNetMon. Everyone should deploy this to secure their network and detect both incoming and outgoing attacks. If all ISPs filtered outgoing attacks, then automatically it would reduce DDoS attacks on the entire Internet."** ### **Outcomes and Operational Impact** By combining hardware-accelerated packet forwarding with FastNetMon's automated detection and mitigation capabilities, Joy Services transitioned from a reactive approach to a significantly more resilient operational model. Following the implementation, Joy Services achieved: **Near-Zero Downtime:** DDoS incidents that previously caused service disruption can now be detected and mitigated automatically. **Sub-15 Second Detection and Response:** The time required to detect major attack events dropped to a consistent 2-to-15-second window. **Comprehensive Network Visibility:** Real-time metrics allow engineers to monitor traffic spikes, track per-host and per-subnet statistics, identify top talkers, and receive instant alert notifications when attacks are detected. ![](https://fastnetmon.com/wp-content/uploads/2026/03/quote.png) > **"Today, we experience nearly zero downtime, and FastNetMon has become one of the most important tools in our infrastructure. Its DDoS detection capabilities have provided tremendous help in protecting our network and maintaining service stability."** ### **Why FastNetMon Fits the Environment** For Joy Services, the major advantage was the accessibility and completeness of the toolset available in the Community Edition. The team was able to build a robust DDoS detection and automated mitigation workflow while also gaining valuable network visibility and monitoring capabilities. The platform fit well within a network environment that includes multiple upstream providers, extensive peering relationships, and a mixture of network devices, making FastNetMon an important component of Joy Services' operational infrastructure. **Categories:** Case studies, FastNetMon Blog, Featured --- ### [FastNetMon at Route to Networking Podcast](https://fastnetmon.com/2025/03/18/fastnetmon-at-route-to-networking-podcast/) **Published:** March 18, 2025 **Author:** FastNetMon **Content:** ## An in-depth discussion on all things DDoS In this episode of the Router Networking Podcast, James Dean interviews Pavel Odintsov, co-founder of FastNetMon. Pavel shares his journey from a curious child dismantling audio equipment to becoming a key figure in cybersecurity. He discusses the challenges of dealing with DDoS attacks, the evolution of network security, and the importance of understanding fundamental technologies. Pavel also highlights FastNetMon's role in identifying and mitigating DDoS attacks, offering insights into the future of network security. Tune in to learn about Pavel's experiences and his advice for aspiring tech professionals. [Listen to the podcast on our YouTube channel](https://www.youtube.com/watch?v=lryg9EeMZnQ) --- **Read the podcast transcript:** James Dean: Hi, my name is James Dean. You're listening to the Router Networking Podcast. Today I've got a special guest, Pavel Odintsov, who is the co-founder of FastNetMon. Today we're going to learn all about Pavel's background, how he got started in the security space, what he's up to now, and where he sees the future of security going. How are you, Pavel? Pavel Odintsov: Hello, hello. I'm just wonderful. Thank you for inviting me. I'm happy to talk about my story, about FastNetMon in general, and everything happening in the cybersecurity field. James Dean: Perfect. Yeah, it's been good to finally speak. We've had the Corbett team for a couple of months now, right? So it's good to get this set up. One place I always like to start, Pavel, is how did you get started in the world of security? Pavel Odintsov: Oh, actually, it was a long story for me. I got a formal education in computer science and then started working as expected. I got an internship, then my first job as a Perl developer. It was focused on software development. I had requirements, a list of tasks, and many weeks to implement what I was asked to do. It was old-style software development, but by accident, my first company was a domain name registrar, and my first project was to implement billing integration with a new department introduced by the company. It was a hosting department. That's how I was dragged into not just software engineering. After that, I spent around five years in heavy operation of Linux operating systems. I started as a software engineer and moved to operations. Then I was invited to join a company in the cloud compute area as a technical co-founder, as CTO, and it was the first place where I met cybersecurity. Our company operated in very low-margin hosting services. It had plenty of customers, about 25,000 in total, but very cheap, like on the minimum possible borderline of what you can afford to sell. Can you imagine we had lots of problems with those? At first, it started like one attack per month. It was something incredible. Everyone thought, wow, it's exciting. I mean, it's dangerous. It's a broken network. After a few more months, we accepted that once per month, we have some issues with the network. In the coming months, it became once per week, and at some point, when I left this company, it was around six attacks on a daily basis every single workday. This is how I was dragged into cybersecurity. At first, it was a minor issue for me as CTO, as a system administrator, but as the days and months went by, it became more important. At some point, I was involved. I wouldn't say it's full-time, but maybe 20% of my time was allocated just to deal with cybersecurity issues, to talk with network operators, to find out what we can do and how to stop them. So I would say I was dragged into cybersecurity by the urgent need to deal with problems. James Dean: Yeah, it's funny, a lot of people don't set out to do the role they're now in, but it just seems to happen when they worked at a company, and that came about. So yeah, obviously, you were pursuing a career as a software engineer in the first place. What drew you to the software engineering space? Pavel Odintsov: It wasn't a hard choice because, since childhood, I started what I would call the start of my career. I started at home by disassembling my father's sound amplifiers and different audio systems. I was curious about what's inside. It's one of the things that follows me, like I need to check what's inside, how it works, what kind of magic happens inside. But the problem was I was just wonderful at disassembling stuff. Sometimes my father was able to put it back. But at the final steps of my career, I was about eight years old, and my father just looked at what I did and gave up. He couldn't put it back because it was disassembled so hard. So, you know, with my serious skills in disassembling stuff, at some point, you need to do something on your own, assemble something. I had problems with this kind of option. So, when I finished school, I thought maybe I need to learn how to actually do something good instead of just assembling stuff. That's how I decided to join a computer science course at university. James Dean: And when you first started university with computer science, apart from breaking things and putting them back together, what made you passionate about that? Pavel Odintsov: Back in time, I had a major passion for physics. James Dean: Yeah. Pavel Odintsov: And that's how I started my education at university. Not directly, not from the first time as a computer science student, because I spent around one course as an applied physicist. It was a great experience because, in school, I was passionate about physics and all that stuff. Then maybe it was a great idea because my local university introduced a very new shiny course about physics. Brand new, not typical stuff because universities usually have quite old courses, old programs. But this one was shiny, everything was new. They had a course on Linux, can you imagine? That was 2005. Linux, C language, lots of distributed systems. It looked exciting. I had a great deal of interest in how I could assemble stuff. Applied physics is quite close to what you assemble, like literally everything. But quite soon, I realized that it's not actually my cup of tea. Then I got confirmation that in school, I had a passion for physics, but it had nothing to do with applied physics. So I switched to computer science. James Dean: You started a business very young. I know you touched on it earlier, but you co-founded a business pretty much out of university, is that right? Pavel Odintsov: Yes, absolutely right. James Dean: What was the motivation to do that then? Most people would just get into a grad scheme or... Pavel Odintsov: Oh, it was a weird story. I started working in my third year of university. It wasn't a part-time job; it was a full-time job. I was born in a small town called Samara, literally in the middle of nowhere. The problem is we had no great selection of shiny computer companies. Back in my university times, it was about selling computers, not writing software. It was amazing because most of the stuff about computers around me was like, we can do a website for you. That's all, the first offering of technological companies in my hometown. But at some point, my friend, actually my classmate from the physics course I started, we kept in touch. He said, we have a great company you may be interested in because they have Linux and Perl, but their position was full-time only. It was like a chance, one in a million. In my hometown, it was literally impossible to find any kind of software engineering job. But this one was great, great technology, great stuff. I had lots of problems with my university. I was about to be kicked out about three times, but I survived it. James Dean: Oh, because your grades were so bad. Pavel Odintsov: You know, when you try to work full-time at university and a full-time job, you need to sacrifice something sometimes. But I wasn't able to sacrifice my job because I didn't expect that I could get such a great job. It was like winning millions of pounds. Just keep it, stick with it. James Dean: So you finished uni and then started your own business pretty much. Pavel Odintsov: Straight away. I joined as a co-founder after having two years at this job. I worked at this company, and they offered maybe we can work together in the cloud compute area. Back in time, it was just a dream job, but now they think of me working on my own stuff again. I just went for it. It's exciting. James Dean: It's quite exciting. I imagine at such a young age as well. How big did the company get to? Pavel Odintsov: So far, this company still exists. They have about 45 people, but when I left, we had 25 folks. Most of them were in technical support because it's a hosting company, and the main area of what you need to do is answer customer questions. Many of them had issues with Apache, PHP, MySQL. James Dean: You mentioned earlier about the attacks going from once a month to six a day. Attacks have been an ever-growing part of the security space. For you personally, being involved at such a young age and being a co-founder of a business at such an age, what do you think has been the most significant changes in networks or in security since you've been involved? Pavel Odintsov: So I would say, yeah, for the first time, when at my company we started getting the DoS attacks, I started talking with friends in my industry, like from telecoms, data centers, and many of them were like, no, don't see them that often. So are you talking real stuff, or are you just exaggerating, like so many attacks per day, daily basis? It just cannot be because even for large folks from large companies, you don't see them. And only one company who actually trusted my complaints and my questions, it was my ISP, and they saw exactly the same number of attacks. You can see like you are definitely not exaggerating. You have many of them, and many reasons why we had it this way because I suppose we had quite a large and diverse audience of our customers from many countries, from many backgrounds, many of them were from the gaming industry. It was just emerging. There were many Minecraft servers, Counter-Strike servers, and they're very well known to attract so much DDoS attack. But what changed now, everyone perfectly knows about DDoS attacks. Like all people in technical industries, they experienced them firsthand. And now it's ever more different because sometimes we also can hear about businesses completely devastated and ruined by DDoS attacks. James Dean: I'm not massively technical myself, so it'd be good for you to give me an insight. But also, some of the listeners on here may not know specifically what a DDoS attack is. So, what is a DDoS attack? Pavel Odintsov: So, a DDoS attack, to be precise, is distributed. The terminology is quite misleading sometimes because typically people use DoS and DDoS. But it's a problem because it doesn't explain everything you're working with. Because distributed, it involves at least thousands of different devices attacking your website or your service. It's typically a small number of requests, but because of the number of them, and typically like theories, they're attacking for attacking the it's not prepared to this number of requests. For example, it may be like, for example, it's just maybe the site of a local council, and they have maybe 20,000 residents. But if some bad guy starts an attack having like 100,000 fake residents just opening their main page or just opening how I can move into your borough or what's happening. And because of scale, because of the number of them, it just knocks the service down. And so, first of all, it is to exponential spike of resource consumption for some short time. Services may be able to handle because all the time they have some spare capacity because, you know, every single service is built to have some gap, some spare capacity to make it a little bit more like we have on average maybe 100 visitors for a day. But typically, services handle like maybe a thousand visitors, but not 10,000 or 100,000. And at some point, it just knocks the service down. And that's all. And at this point, you need to do some magic. You need to allocate more resources. You need to hire maybe some special company or try to do magic or deploy FastNetMon to understand because one of the great problems is DDoS attacks. So I would say it started happening quite recently, maybe a few years ago. People just blame DDoS attacks for their faults like misconfiguration. It's called DDoS. James Dean: Now, why would someone do a DDoS attack though? Is it just out of vendetta, or is it to try and dip into other parts of the site? Pavel Odintsov: I would call it a gray area. My understanding is limited because DDoS attacks are very distributed, coming from different countries and services. It's extremely complicated to find out who actually started it. If someone buys a DDoS attack from bad actors, the person you bought it from will never start the attack themselves. They'll go to another person and buy it again. There may be tens of people working on different levels, and only at the end of that line is the person who actually starts the attack. Most of the time, it's hate. I don't like this site, what they are talking about, their idea, or this specific person. It's quite common with gamer sites. If your clan failed in some competition, it's one of the things. James Dean: Yeah, yeah. Pavel Odintsov: In developing markets, it's competition. It typically happens in extremely competitive and fast-growing markets. For many developing countries, the Internet is just emerging. Some densely populated areas just got Internet, and people see it as a gold mine. They think they can sell Internet and earn thousands of dollars. Then they start thinking, maybe we can knock them down and get more customers. James Dean: Oh yeah, it's one of those things. If you're not involved in it daily, you don't really hear about it unless it's a really bad attack. So, you mentioned the big changes in the DDoS space since you've been involved. What's most concerning for you right now? Pavel Odintsov: One of the most concerning things is that DDoS attacks are typically run by a protocol called UDP. The problem is that the IETF recently introduced a new version of the HTTP protocol, HTTP/3, which uses UDP. Back in the day, it was simple to filter out DDoS attacks by filtering out UDP. UDP isn't widely used outside of networks. You can run your own DNS service or have a local VoIP service, and then you can ban everything else and be safe. But because HTTP uses UDP, we can't filter it out anymore. It eliminates the option for simple and cheap DDoS filtering for small companies. They need to move to more sophisticated and expensive equipment to filter it out. We need to improve tools and find out what we can do. Many companies have suffered from it and can't use their old approaches for DDoS mitigation. James Dean: That's one of the things you're working on at the moment with FastNetMon. What does FastNetMon do? Pavel Odintsov: FastNetMon solves one of the first problems with DDoS attacks. When you experience DDoS attacks, your network is often dead. If you work from home, you can't access your network to check what's happening. You need to find out what is the target of the attack. Even small networks have tens of thousands of different hosts, typically with different IPs and services. FastNetMon helps you find out which IP is under attack. Instead of logging into your equipment and running TCP dump, FastNetMon will tell you which IP is under attack. It can also automatically mitigate the attack. FastNetMon can create BGP announcements to do different things, depending on what the company wants to do. It automates actions. We receive an attack, and FastNetMon can create a BGP announcement with specific community, IP, and next hop. It's up to the network administrator what they can do. Sometimes they want to blackhole it, literally stop all traffic to this host. It may sound harsh, but it saves the network. In a calmer environment, we can think about what to do next. Using BGP, specific services can be moved to a scrubbing center. A scrubbing center has equipment for filtering DDoS attacks. FastNetMon can create BGP panels to move malicious traffic away from the normal path to equipment prepared for DDoS attacks. The last resort option is using capabilities from routers. It's called BGP FlowSpec. Most modern routers like Juniper MX series, Cisco SR series, Nokia series, and Huawei support BGP FlowSpec. It's a distributed way to make changes for ACLs using BGP protocol. FastNetMon can help with it. For example, if your network is under attack from DNS amplification, which typically involves fragmented UDP packets, FastNetMon can find out the problem and create a specially crafted BGP FlowSpec to filter out malicious traffic. James Dean: So you would have customers come to you pre-DDoS attack. You don't get called in if something really bad happens, it's too late by then. Pavel Odintsov: People never solve a problem if they don't have one. James Dean: Yeah, true. Pavel Odintsov: We have only a small fraction of customers. James Dean: What's next for the business? Where do you see FastNetMon going next? Pavel Odintsov: We have a great deal of plans. We focus on two areas. First, of course, is DDoS. We're passionate about DDoS. We work hard to add more support for different vendors and equipment, make it better, and make deployment faster. The second area is network visibility. To detect DDoS attacks, we need lots of metrics. We realized we have so many metrics. We have counters about per protocol distribution, per network, per host, per group of hosts. We have top talkers, peering reports, graphs about peak usage for specific interfaces, routers, and upstreams. It's a great addition for DDoS mitigation because after we mitigate an attack, we need to understand what happened, why it happened, and what the impact was. Traffic visibility is crucial to have in place after you mitigate a DDoS attack because it provides lots of information about what happened during the attack. DDoS attacks have become more sophisticated. Sometimes they can do a DDoS attack just to move attention away from specific servers. It happened with Band. Bad guys started a DDoS attack, and everyone started running around, but at the same time, bad guys stole all their secrets. Accounts and transactions were very quiet and relaxed because nobody cared. James Dean: What's been the most challenging disaster you've personally encountered in your career? Pavel Odintsov: It wasn't technical. I remember the first company I founded, all network engineers left without any notice. I wasn't a network engineer. I was CTO, so I was in charge of DDoS, but I wasn't the guy who actually handled BGP routers and all that stuff. But next month, I learned how to do it because it was the only option. We started hiring new people, but it's not easy to find a network engineer. We worked in a not very large town, so we had no great choice. We started interviewing people, but at the same time, we needed to keep the network running. It was like emergency onboarding into serious networking. By the end of it, I was in perfect condition, knowing how Quagga works, what kind of BGP communities I need to set, and how to create VLANs. It was a great experience, but I would say it was the most stressful month of my life. James Dean: Just become a network engineer in a month. Yeah, I bet that was hard. Not just becoming a network engineer in a month, but with your whole career, how do you think your computer science degree played a part in that? Pavel Odintsov: It was very helpful. I started working in my third year of university, but the first and second courses provided a great background. It was graph theory, computational theory, algorithms, lots of basic stuff you must know. Many people may say they'll never use compute theory, but I found out during my career that when you work in deep tech areas, you can't just Google stuff. If you're a popular technologist, you may think you don't need to know how computers work, but I find the same approaches still apply even after 10 years. Microprocessors became faster, but they didn't change. If I need to understand why something is slow, I can use my knowledge. It was very useful. In Britain, it's fine to get basic knowledge for two or three years and then keep your hands dirty. That's what happened with me. I got a job, and it was a great choice. James Dean: We've had previous guests say you can learn as much as you want in a book, but unless you do it, you won't pick it up. You've expressed that, learning full-time at uni while working a full-time job. It's probably the best way to pick up what you're learning at uni. Is there any particular advice you'd give someone now who's an 18-year-old looking to get started in the industry? Pavel Odintsov: We have a choice. We can focus on shiny products, shiny companies, shiny technologies. During my career, I've witnessed many sunrises and sunsets of companies. My career is not that long, around a decade. I've witnessed the death of many technologies that were the best possible when I was at university. If you look around and see a shiny technology, it will likely be dead in 10 years. My recommendation is to focus on stuff that will not change. Learn how networks work inside, how BGP is implemented, what kind of internals, read software, read code, understand how operating systems work. This knowledge will last way longer than any vendor or product. My best example is the protocol called DNS. It recently crossed 36 years, and it still works. If you decided to be a DNS engineer 36 years ago, you could make some money, not get rich, but some money. James Dean: It's funny you'd say that because some of the guys we've had on the network engineering side, their advice is not to focus on the shiny objects but actually understand the basics of networking, how a packet goes across a network, and the basic routing protocols. It's funny you'd say that for your specialty as well. Is there anything you would advise your younger self? Pavel Odintsov: Keep doing what you're doing. I made lots of mistakes, but I learned from them. Mistakes are one of the best ways to learn. You don't learn from success stories. We need to mess up something seriously. James Dean: You'll make some serious mistakes. No, you're right. I appreciate that. It's been great speaking to you today. We've got a quick-fire round to go. This part is five questions, just a bit about you personally. It's called Quick 5, but you can go into as much detail as you wish or be as quick as you want. If you could describe yourself using just three adjectives, what would they be? Pavel Odintsov: Loud, dedicated, persistent. James Dean: Perfect. How much caffeine would you say you consume in a day? Pavel Odintsov: On average, one cup. If I do two cups, my day will be ruined because I'll be shaking, and I need to do something, but I can't because I'm shaking. James Dean: You get too energetic for me. Pavel Odintsov: Yes, exactly. I'm already crazy, and I don't need coffee to make it worse. James Dean: Apple or Android products? Pavel Odintsov: iPhone. Many years ago, I moved away from Mac OS and MacBooks in general. They're getting better now, but it was too complicated for me as a software engineer. I need to develop on hardware and need access to hardware. That's why I work on Linux. From iPhone, it's just convenience. It works fast, works well, and can survive a few years of my heavy use. I look for things to be simple and not need much attention. If it starts asking for too much attention or breaks too frequently, I'll look for different options. James Dean: Do you prefer working from home or in the office? Pavel Odintsov: Something in between. Since the start of my career, I've worked remotely because it's the only way I can keep my university place and work for a company. But I miss people. I want to discuss stuff, make planning meetings, exchange ideas, and test ideas. I hate working from home. James Dean: I hated it. Anyway, I don't mind at the weekends if I have a bit to do. I'll just put my headphones on and crack on for a bit, but generally speaking, I do much prefer the office. What was your favorite subject in school? Pavel Odintsov: Physics. James Dean: And you've carried it on in some way. Perfect. Pavel, it's been great getting to know you better, hearing more about your career. I didn't know too much about DDoS, being more of an IP recruiter myself. I've learned a lot today, and I hope the listeners have too. If anybody wanted to reach out or had any questions for you, where's the best place they can find you? Pavel Odintsov: Just Google my name, and you'll find lots of options. LinkedIn, I have open messages, message me anytime. I'm quite active on Twitter, and of course, FastNetMon.com is the best option to reach me, to ask questions. Because we're an open-source project, my account on GitHub is Pavel\_Odintsov. We have around 10 different social media accounts, rooms, chats. Just Google them, join any of them, and you'll meet many nice people, including me. Sometimes I can answer stuff, but more often, someone from the community will provide better, faster, and more skilled answers than me. That's the power of communities, that's how it should work. James Dean: I really appreciate your time, thank you very much, and have a great weekend. Pavel Odintsov: Thank you so much, you too. James Dean: Bye. **Categories:** FastNetMon Blog **Tags:** press features --- ### [Free FastNetMon Advanced License For All Non-Profit IXPs](https://fastnetmon.com/2022/09/16/free-fnm-license-for-ixps/) **Published:** September 16, 2022 **Author:** FastNetMon **Content:** We at FastNetMon have a strong determination to make the Internet more resilient to DDoS attacks. We help our customers to deliver network connectivity which cannot be interrupted by malicious actors. Keeping connections running smoothly is vital for businesses. That’s why every organisation should think about ways to protect itself and their customers from DDoS attacks. We believe that a reliable and versatile DDoS protection must be available for all kinds of companies. We strongly believe that Internet Exchange Points are extremely important parts of the Internet. Their performance and security must be first priority. Many IXPs are run by volunteers, and we’re grateful for their service and their effort to keep people connected. To make our humble contribution into Internet resilience and stability, we are delighted to introduce free unlimited licences of our industry-leading DDoS detection and mitigation product FastNetMon Advanced for all non-profit IXPs. [FastNetMon Advanced](/ddos-detection-and-mitigation/) offers great visibility into your network and can scale to multi-terabit networks easily. In addition to DDoS detection, our product offers a broad range of insights into your [traffic](https://fastnetmon.com/traffic-visibility/ "FastNetMon can Help Solve your Network Traffic Visibility Challenges and Protect your Data"). It will help you to see your traffic in real time and help you to investigate events that happened in the past. To claim your licence, please email us to sales@fastnetmon.com and we will issue the licence and technical assistance required to deploy our product. Bear in mind, as an International company, we must follow compliance regulations from the UK, EU and US and your request will be subject to regulations put in place by these countries. To implement these policies, we need to confirm that your IXP is affiliated with a business entity. **Categories:** FastNetMon Blog **Tags:** IXP --- ### [Exploring FastNetMon at The Hedge Podcast](https://fastnetmon.com/2025/03/06/exploring-fastnetmon-at-the-hedge-podcast/) **Published:** March 6, 2025 **Author:** FastNetMon **Content:** ## Read the discussion on DDoS Detection and Network Security In this episode of the Hedge podcast, hosts Russ White and Pavel Odintsov explore the functionalities of FastNetMon, a powerful open-source DDoS detection software. They discuss its capabilities in monitoring network traffic, detecting potential threats, and integrating with various BGP implementations for effective traffic management. Pavel shares insights into the software's development journey, its deployment flexibility, and the community support that drives its continuous improvement. Whether you're a network engineer or simply interested in cybersecurity, this episode offers valuable insights into how FastNetMon can help safeguard your network infrastructure. [Listen to the podcast on our YouTube channel](https://youtu.be/zlGh_XaI1Lc) --- **Read the podcast transcript:** Podcast Host: Welcome to the Hedge, where we discuss engineering, technology, and business. In this episode, Russ White and Pavel Odintsov delve into FastNetMon. Russ White: Hi Pavel. Where are you in the world, and what time is it there? I always get lost. Pavel Odintsov: It's 7pm here in East London, Britain. Russ White: East London, nice. I have fond memories of London from my IETF days, visiting Rye, Reading, Oxford, and enjoying sights like Madame Tussauds and the London Eye. It's a great city. So, this week on the Hedge, episode 10, we're discussing FastNetMon. Let's start with an overview for those who might not be familiar with this software project. Pavel Odintsov: Sure. FastNetMon is DDoS detection software designed to identify network issues. While it doesn't focus on remediation or mitigation, it uses network telemetry like IPFIX, sFlow, NetFlow, and jFlow to process traffic information. FastNetMon then notifies you or your APIs about potential DDoS attacks on your network. It's a straightforward concept, but it's incredibly useful for understanding the impact of DDoS attacks on subnets and customer services. Russ White: Let's back up a bit. You mentioned several monitoring methods. Do you also monitor BMP from routers, or do you focus on sFlow, jFlow, NetFlow, and similar protocols? How do you gather information to detect DDoS attacks? Pavel Odintsov: Historically, we started with soft routers, capturing traffic via SPAN ports or Airspan. FastNetMon can read data directly from a port on Linux or FreeBSD, using port mirrors from switches or routers. While popular, this method doesn't scale well due to port and capacity limitations. We then added support for sFlow, a popular method for exporting traffic information from switches. It's preferred over IPFIX and NetFlow because it doesn't add latency, which is important for DDoS detection. We support various flavors of IPFIX and NetFlow as well. Russ White: So, you're capturing packet and transport-level data. How do you determine a DDoS attack is happening? What's your heuristic? Pavel Odintsov: FastNetMon uses a threshold-based detection engine. Users set baselines to define expected traffic levels for their network. FastNetMon collects data from sFlow, NetFlow, IPFIX, and port mirrors, checking traffic direction and allocating counters for different traffic types. When values exceed thresholds, FastNetMon triggers scripts, sends emails, or creates BGP black holes to manage the situation. Russ White: Interesting. Are you checking for TCP half-open connections, or just counting TCP traffic volume? Pavel Odintsov: We have counters for total packets, TCP packets, and TCP SYN packets. We focus on L3 and L4 levels, as NetFlow provides more detailed information like HTTP traffic types. Russ White: Does encryption impact your ability to measure traffic, or is it irrelevant to your packet counting? Pavel Odintsov: Encryption doesn't affect us, but we've faced challenges with UDP traffic, especially with Google's QUIC protocol. Networks relying on low UDP thresholds find DDoS detection harder. Adjusting thresholds or whitelisting traffic types helps. Russ White: Yeah, okay, so it doesn't automatically set thresholds. Right. It's something that it's not like it takes a moving average or anything, it's something that you manually set as a network operator. Is that correct? Pavel Odintsov: Not entirely. While operators can set thresholds, FastNetMon exports traffic data for analysis in tools like Graphite, InfluxDB, and Grafana. We offer scripts to generate thresholds based on historical data, allowing for automated configuration. Russ White: Right, but now is that dynamic when you use those scripts, Is that what you're saying you can actually dynamically use those scripts to set it like over every seven days it resets or every day it resets based on the seven-day moving average. Or is this something where you run the script and then you like take the information from that script and then set it yourself. Pavel Odintsov: The scripts can run automatically, adjusting thresholds based on averages or percentiles. Operators can customize them to exclude specific traffic types. Regular reviews are recommended to account for anomalies like DDoS or flash effects. Russ White: Ah, okay, good, cool. So you said something about configuring BGP. So what does it do in terms of BGP? Does it use one on communities? Is there something you've got to arrange with your provider? How does this piece work? I mean, what are the options in the BGP world? I guess is my first question. Pavel Odintsov: From FastNetMon's perspective, we avoid predefined solutions, supporting multiple BGP daemons like Quagga, xBGP, and GoBGP. FastNetMon specifies custom communities, announces affected prefixes or hosts, and uses BGP flow spec for granular control. BGP unicast is useful for blocking specific hosts, while BGP black holes can protect the network during emergencies. Russ White: Okay, so how are you interfacing with these different BGP implementations that you have that you've just listed? You say GoBGP Quagga, which you know, I would say FR routing, but anyway Quagga and then you said xBGP. So how are you interfacing with those? Is this like a Yang backend? Are you like kind of screen scraping, modifying things? Pavel Odintsov: It depends. For xBGP, we use its API. GoBGP uses GRPC and protobuf, while Quagga relies on callback scripts. Each has its advantages, and FastNetMon integrates with them accordingly. Russ White: Okay? Excellent. And I'll just. Have you considered using FR routing? Because the FR routing has a full Yang interface. Open conf interface. Well it's not really open conf. It's actually its own Yang models into the BGP implementation there. So it might be interesting to think about that instead of using Quagga just. Pavel Odintsov: Yes, it's a potential next step, as Quagga is quite old. Russ White: Yeah, it's quite old. Pavel Odintsov: It's very old school software. Yes. Russ White: So you just run this BGP in a different container or you're just running on top of Linux. I mean this all runs within a container or bare metal on Linux. Or how does this, how does this actually deploy for somebody who's trying to run. Pavel Odintsov: Deployment is flexible. FastNetMon can run on bare metal or in containers, supporting various Linux distributions. It's available in standard repositories for easy installation. We also offer Docker images and support Kubernetes deployments. Russ White: Kubernetes is becoming popular. I'm learning it myself, as the industry moves in that direction. Pavel Odintsov: Absolutely. Even telecom companies are adopting Kubernetes, which is an exciting shift. Russ White: Yeah, yeah, exactly. So how can you kind of describe breakdown what the modules are within FastNetMon or is it just like one monolithic program? Or are there different pieces of it that someone who's running it could dig into a little bit and understand it? Pavel Odintsov: Initially, we experimented with various languages, starting with Python, then Perl, and finally settling on C for performance. FastNetMon handles high packet rates, scaling well under DDoS conditions. Russ White: Yeah, no, it scales. That's good. So you're using C and you're using direct to kernel or are you pulling off of a NIC or how are you pulling the traffic in? Like if I had a Broadcom based box, could you pull off of psi or is it strictly coming off the kernel? Or how does that piece work? Pavel Odintsov: That's a great question. For standard methods like NetFlow, IPFIX, and sFlow, the packet volume isn't too high, so the Linux network stack handles it well. But for high-speed capture, we started with pcap, then moved to PF Ring, and now support AF Packet and AFXDP for better performance. Russ White: AFXDP sounds promising. Pavel Odintsov: Yes, it's a significant improvement, achieving higher packet rates on the same hardware. Russ White: Wow. Cool. Good. Pavel Odintsov: It's really exciting. Russ White: Yeah, it is. That's really, that's really, really neat. So just to recap a little bit before we shut down and plan another podcast to talk about another episode, to talk about use cases and go into a little bit more detail perhaps. So FastNetMon is open source. You can just go to the Linux repository, download it, install it on standard Linux implementation or distribution, run it and you can either do packet captures and or use any of these other methods sFlow or something IPFIX to grab the data and then it's going to do threshold-based DDoS detection which in the next time, next time we talk about this, I want to talk about all the use cases for that because we want to think that's really focused on my network edge. But there's actually a lot of other places you can use this and then it'll feed back through other systems using GoBGP or xBGP to allow you to modify your BGP advertisements to redirect traffic or do whatever using communities. So where can people find you and where can people find. Do you blog or anything? Or are you kind of silent on social media? Pavel Odintsov: I'm on Twitter, but I recommend subscribing to the FastNetMon mailing list for updates and community discussions. We also have Telegram, Slack, and IRC groups for communication. Russ White: Yeah. So it's a real community. It's not a small group. It's actually a large community and it's doing a lot, lot of good work. Great. Pavel Odintsov: Exactly. Exactly. And we have lots of ways how you can reach me. We have Telegram group, we have Slack group, we have IRC on freenote. It's just FastNetMon. Lots of ways how we communicate because from first times when you start FastNetMon based on customer experience, customer feedback, advices, ideas, just proof of concepts. Russ White: So excellent. All right. Well thanks Pavel and we'll bring you back on to talk again about FastNetMon because this is pretty fascinating particularly for frontline network engineers who are working on, you know, real world problems or trying to solve some of this stuff. And again we'll, we'll work through some of the use cases and stuff. So thanks for joining us and thanks Pavel and yep, we'll bring you back on. Thanks. Pavel Odintsov: Thank you. Bye. Podcast Host: Thank you for joining us. You can find the Hedge at Rule 11 Tech. **Categories:** FastNetMon Blog **Tags:** press features --- ### [Layer 3 DDoS attacks explained](https://fastnetmon.com/2025/03/11/layer-3-ddos-attacks-explained/) **Published:** March 11, 2025 **Author:** FastNetMon **Content:** ## What are L3 DDoS attacks, and how do they work? Layer 3 DDoS attacks are a type of cyber assault that targets the third layer of the OSI (Open Systems Interconnection) model, which is responsible for routing data packets across networks. These attacks focus on overwhelming core network devices like switches and routers, which are essential for directing traffic and maintaining network performance. Any DDoS attack aims to overwhelm the targets with an excess of data or requests. In a Layer 3 DDoS attack, the hacker intends to disrupt the normal functioning of a network by flooding it with an excessive volume of traffic. This is achieved by exploiting vulnerabilities in network protocols such as Internet Protocol (IP), Internet Control Message Protocol (ICMP), and Address Resolution Protocol (ARP). By doing so, attackers can exhaust the resources of network devices, leading to a significant slowdown or a complete crash of the network. Understanding these attacks is essential for implementing effective security measures to protect network integrity and ensure continuous service availability. ## L3, L4, and L7 DDoS attacks - what’s the difference? To understand better what kinds of DDoS attacks there are and how L3 attacks work exactly, let’s have a look at the entire OSI model: ![](https://fastnetmon.com/wp-content/uploads/2025/03/Layer-3-DDoS-attacks-explained-the-OSI-Model-1024x609.png)Layer 3, the network layer in the OSI model, is essential for routing data across interconnected networks like the Internet. It handles the division and addressing of data packets, primarily using the Internet Protocol (IP). Unlike Layer 4 and Layer 7, which involve transport and application layer processes, Layer 3 focuses solely on network routing without establishing connections or ensuring data delivery. Layer 3 DDoS attacks specifically target this network layer, bypassing the need for transport layer or application layer processes. These attacks do not require opening a TCP connection with the target, nor do they target specific ports. Instead, they flood the network infrastructure with data packets, overwhelming the network software and causing disruptions. By exploiting the connectionless nature of Layer 3, these attacks can saturate network resources without engaging in the more complex processes of higher layers, leading to significant service disruptions. ## What are the different types of L3 DDoS attacks? In this chapter, we are explaining the typically observed types of Layer 3 DDoS attacks and how they function. While these attacks often carry commercial names, our focus is on explaining their technical nature and classifying them to aid in understanding and mitigating their impact. By breaking down these attacks, we aim to provide insights into their mechanisms, helping network professionals develop effective defence strategies. ### **ICMP Flood** ICMP Flood DDoS attacks are a type of DDoS attack that involves overwhelming a target system with a large volume of ICMP packets. The primary aim is to consume the target's network bandwidth and processing resources, causing service disruption or making the system unresponsive to legitimate traffic. ICMP is typically used for diagnostic purposes, such as the "ping" command, which checks the reachability of a host on a network. In an ICMP Flood attack, the attacker sends a high volume of ICMP Echo Request packets to the target. The target system is forced to process and respond to each request with an ICMP Echo Reply, consuming its resources. When executed as a distributed attack (DDoS), multiple systems are used to send ICMP packets to the target, making it more difficult to mitigate. This distributed nature amplifies the attack's impact, as the target is bombarded from numerous sources simultaneously. To defend against ICMP Flood attacks, network administrators can implement measures such as rate-limiting ICMP traffic, configuring firewalls to block excessive ICMP packets, and using intrusion detection systems to identify and mitigate such attacks. ### **Ping Flood** Ping flood DDoS attacks are a type of denial-of-service attack where the attacker overwhelms a target system with ICMP Echo Request (ping) packets. The goal is to consume the target's available bandwidth or processing power, rendering it unable to respond to legitimate traffic. In a typical ping flood, the attacker sends a large number of ping requests to the target. Each request requires the target to send back an ICMP Echo Reply, consuming both incoming and outgoing bandwidth. If the attack is distributed (DDoS), multiple sources send ping requests, making it harder to mitigate. ICMP Flood and Ping Flood attacks are closely related, but there are subtle differences between them. A Ping Flood is a subset of an ICMP Flood, focusing specifically on ICMP Echo Requests. Both aim to disrupt the target's ability to handle legitimate traffic by overwhelming it with unnecessary requests. ### **IP Fragmentation** IP fragmentation attacks exploit the process of dividing large IP packets into smaller fragments to accommodate network transmission limits. These attacks aim to overwhelm a target system's resources by sending a flood of fragmented packets, causing service disruption or degradation. When a system receives fragmented packets, it must reassemble them to process the data. Attackers take advantage of this by sending excessive or malformed fragments, leading to resource exhaustion or system errors. Such attacks can bypass security measures, as fragmented packets may evade detection by firewalls and intrusion detection systems. This makes them a potent tool for attackers seeking to disrupt services or exploit vulnerabilities. Defending against IP fragmentation attacks requires robust security configurations, including the use of firewalls to filter suspicious fragments, intrusion detection systems to identify anomalies, and regular system updates to handle malformed packets effectively. ### **DNS Amplification attacks** DNS Amplification DDoS attacks are a type of DDoS attack that exploits the functionality of open DNS resolvers to overwhelm a target system with a flood of traffic. The attack takes advantage of the fact that DNS queries are typically much smaller than the responses they generate, allowing attackers to amplify their impact. DNS Amplification attacks are particularly effective because they can generate a large amount of traffic with relatively little effort from the attacker. While DNS itself is an application-layer protocol (Layer 7), the amplification attack focuses on exploiting the network and transport layers to flood the target with traffic rather than directly targeting application-layer functions. ## How to mitigate the L3 DDoS attacks? There are several techniques on how to defend against Layer 3 DDoS attacks, and often, the best defense strategy depends on your specific setup. In this chapter, we will explain these methods briefly. ### **Blackholing / RTBH** One of the simplest mitigation techniques is blackholing, which involves redirecting traffic from specific IP address ranges to a null route, effectively removing it from the network. While this can quickly eliminate large volumes of malicious traffic, it also discards legitimate traffic from the same IP range. As a result, blackholing is best reserved as a last resort, particularly during large-scale or prolonged attacks. Read a full explanation on how RTBH blackholing works [here](https://fastnetmon.com/2024/12/07/bgp-blackhole-automation-for-ddos-mitigation/). ### **Rate Limiting** Another approach is rate limiting, which controls the volume of traffic allowed to reach the target system. By setting limits on traffic per IP address, this method can prevent overwhelming volumes of malicious traffic. However, it is less effective against attacks using numerous IP addresses and can inadvertently block legitimate traffic if limits are set too low. ### **Traffic Filtering** Traffic filtering involves identifying and blocking malicious traffic while allowing legitimate traffic to pass through. This technique requires sophisticated analysis to distinguish between harmful and benign traffic. The effectiveness of traffic filtering also depends on the scale of the attack and the capacity of the filtering solution to handle large volumes of data. ### **Scrubbing Centers** Scrubbing centers provide robust protection by diverting incoming traffic to specialized facilities for analysis and filtering. These centers use advanced technologies and algorithms to remove malicious traffic, forwarding only clean traffic to the target system. With sufficient redundancy, scrubbing centers can effectively manage large-scale attacks, offering a reliable defence against Layer 3 DDoS threats. Read more about scrubbing center automation [here](https://fastnetmon.com/ddos-scrubbing-centre-diversion/). ## **Conclusion** Layer 3 DDoS attacks pose a significant threat to network infrastructure by targeting the core network layer responsible for routing data packets. These attacks can severely disrupt services by overwhelming essential network devices like routers and switches. Understanding the mechanics of Layer 3 attacks, such as ICMP Floods, Ping Floods, IP Fragmentation, and DNS Amplification, is key to developing effective defence strategies. Mitigating these attacks requires a multi-faceted approach. Techniques such as [blackholing](https://fastnetmon.com/bgp-blackhole-automation/), rate limiting, traffic filtering, and the use of [scrubbing centres](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-and-ddos-scrubbing-centers-integration/) can provide varying levels of protection. However, each method has its limitations and downsides and may not be sufficient on its own. Some approaches [may also be very costly,](https://fastnetmon.com/2023/10/24/how-fastnetmon-can-reduce-the-cost-of-cloud-based-ddos-scrubbing/) especially against large-scale or sophisticated attacks. FastNetMon offers a best-in-class solution for detecting and mitigating Layer 3 DDoS attacks. By providing the fastest attack detection on the market, FastNetMon can identify and implement response actions before the attack causes a disruption. By deploying FastNetMon, organisations can bolster their defences against Layer 3 DDoS attacks, ensuring robust protection for their critical network infrastructure. Read more about our solution here: <https://fastnetmon.com/> **Categories:** FastNetMon Blog **Tags:** Network Security Insights --- ### [FastNetMon at the Packet Pushers Podcast discussing DDoS defence](https://fastnetmon.com/2025/03/16/fastnetmon-at-the-packet-pushers-podcast-discussing-ddos-defence/) **Published:** March 16, 2025 **Author:** FastNetMon **Content:** ## Read the in-depth discussion on DDoS Detection and Mitigation In this episode of the Packet Pushers podcast, we dive into the world of DDoS detection with FastNetMon, an open-source solution designed to identify and mitigate distributed denial of service attacks. Hosted by the Packet Pushers, the conversation features Pavel Odintsov, the project leader of FastNetMon. Pavel shares the origins of FastNetMon, highlighting its development journey from a GitHub project to a robust tool capable of handling millions of packets per second. He discusses the software's focus on Level 3 and Level 4 attack types, its integration capabilities with BGP Unicast and BGP Flow Spec, and its low hardware requirements. The podcast also explores the differences between the community and commercial versions of FastNetMon, the importance of detection versus mitigation, and the flexibility of the platform for customization and integration with existing network infrastructure. Whether you're a network engineer or an IT security specialist, this episode offers valuable insights into the capabilities and benefits of FastNetMon in the fight against DDoS attacks. [Listen to the podcast on our YouTube channel](https://youtu.be/zlGh_XaI1Lc) --- **Read the podcast transcript:** Podcast host: Today on the PriorityQ, we're discussing open source DDoS detection with FastNetMon. If you're unfamiliar with DDoS, it's a type of attack common across the Internet, short for distributed denial of service. These attacks are tricky to detect and defend against, and chances are you'll encounter one either directly or indirectly in your IT career. For more on DDoS, check out packetpushers.net for articles and podcasts. Today, we're focusing on the FastNetMon project for DDoS detection. Joining me is Pavel Odintsov, the project leader. Pavel, welcome to the Packet Pushers Priority Queue. Tell us about FastNetMon. What is this project? Pavel Odintsov: Hi everyone. FastNetMon is DDoS detection software. It detects DDoS attacks and automatically applies filtering rules to block them. One of its main purposes is to save you from waking up in the middle of the night to fix network issues. FastNetMon focuses on Level 3 and Level 4 attack types, specifically targeting popular amplification attacks and various floods. Podcast host: There are many DDoS products and services available, often at a high cost. What led you to start FastNetMon? Pavel Odintsov: It's an interesting story. I spent a lot of time searching for solutions to DDoS attacks. FastNetMon was initially published on GitHub in 2013. It was born out of market research to find affordable DDoS detection software for companies in emerging markets. Initially, it was a naive approach to automate tasks like packet analysis and network monitoring. We chose C for its performance, as we needed to handle 2 million packets per second without NetFlow or SFlow support. Podcast host: I didn't realize C was a requirement. I assumed Golang might offer the performance needed. Pavel Odintsov: If you have less traffic, Go might work. But for 40 or 100 gigabits, C is necessary due to its performance and available packet capture libraries. When FastNetMon started, Go wasn't as popular, and there were fewer libraries for packet processing. Podcast host: So, performance and cost are major features of FastNetMon. What are the other main features? Pavel Odintsov: FastNetMon's main feature is DDoS detection. It provides options to detect when an attack hits your network and offers detailed information about it. You can set traffic baselines, and FastNetMon will alert you when thresholds are crossed. It supports automation, BGP Unicast, and BGP Flow Spec for traffic filtering. FastNetMon also provides traffic statistics and integrates with various storage backends like Graphite and InfluxDB. Podcast host: There's a lot there. Detection, notification, and BGP announcements are all part of it. How does detection help with mitigation? Pavel Odintsov: FastNetMon focuses on detection, providing information about attacks. Complete mitigation is complex, especially for sophisticated attacks. FastNetMon can work with cloud scrubbing centers and integrate with existing filtering hardware. It can also use BGP blackhole to block traffic to affected hosts, saving the rest of your network. Podcast host: So, detection is primary, and mitigation involves other devices. FastNetMon informs them about the attack. Pavel Odintsov: Yes, and it can integrate with sophisticated systems for additional processing. Combining different systems or cloud services provides comprehensive DDoS mitigation. Podcast host: There's a free version of FastNetMon and a commercial version. What's the difference? Pavel Odintsov: FastNetMon started as open source. The community version supports various Linux distributions and architectures. The commercial version, FastNetMon Advanced, offers all features in a single package, including BGP implementations, APIs, and easy installation tools. Podcast host: Are there functionality differences between the two? Pavel Odintsov: Yes, FastNetMon Advanced has an enhanced detection engine and supports all DDoS attack types, including multi-vector attacks. It offers more options for BGP Flow Spec and integrates with various external systems. Podcast host: Flow Spec is growing in popularity. How has vendor support been? Pavel Odintsov: It's available on modern, high-end routers. Most top vendors support BGP Flow Spec, and FastNetMon works well with their implementations. It's a great technology that works according to standards. Podcast host: Who typically uses FastNetMon? Service providers or enterprises? Pavel Odintsov: It's a mix, but mainly telecoms, hosting providers, and data centers. We've also seen interest from wireless service providers. Podcast host: What hardware does FastNetMon need? Pavel Odintsov: FastNetMon has low hardware requirements. It can run on a single CPU machine, but two cores are better. Memory requirements depend on network size, but 1-2 GB is usually sufficient. Podcast host: What about exporting traffic to FastNetMon? What's the best method? Pavel Odintsov: It depends on your hardware. NetFlow and SFlow are common, but port mirroring is an option if those aren't available. FastNetMon supports various bandwidths and optimized processing engines. Podcast host: Does FastNetMon support IP Fix records? Pavel Odintsov: Yes, we support IP Fix. Podcast host: What about sampled versus unsampled flow data? Pavel Odintsov: It depends on your hardware. Sampling is often necessary to avoid overloading routers. FastNetMon supports sampling, but configurations may vary by vendor. Podcast host: Can FastNetMon replace commercial products? Pavel Odintsov: FastNetMon complements other solutions. It can integrate with various filtering hardware for better results. We support A10 Networks, Adware Defense Flow, and more. Podcast host: FastNetMon is open source, allowing customization for specific needs. Pavel Odintsov: Yes, you can customize FastNetMon for your needs and contribute to the community. It's flexible and can integrate with various systems. Podcast host: What about IPv4 versus IPv6 support? Pavel Odintsov: We're working on IPv6 support, but it's complex and will take time. IPv4 is still the main target for DDoS attacks. Podcast host: Does FastNetMon provide insights beyond DDoS detection? Pavel Odintsov: Yes, FastNetMon Advanced includes a traffic persistence engine for storing flow data. It offers scalability and detailed traffic reports. Podcast host: What about the community version? Pavel Odintsov: The community version doesn't support this feature. It's exclusive to FastNetMon Advanced. Podcast host: How does integration with DDoS mitigation tools work? Pavel Odintsov: FastNetMon can consume NetFlow or SFlow streams from existing solutions and mix them for comprehensive analysis. Podcast host: Does FastNetMon have an API for automation? Pavel Odintsov: Yes, FastNetMon Advanced has a complete API for configuration and management. The community version has basic API support. Podcast host: Are you looking for developers to help with the project? Pavel Odintsov: We're looking for contributors with experience in protocols like NetFlow and IP Flow. Feedback from hardware vendors is also valuable. Podcast host: How can people interact with the FastNetMon community? Pavel Odintsov: We support IRC, Slack, Telegram, and Google Groups. You can choose your preferred platform to connect with us. Podcast host: Where can people learn more about FastNetMon? Pavel Odintsov: Visit fastnetmon.com for more information and links to our community channels. You can also find us on GitHub for contributions and feedback. Podcast host: Are you active on social media or have a blog? Pavel Odintsov: We have a blog on our official site, but it's not very active due to time constraints. We share insights on NetFlow and SFlow implementations. Podcast host: Thanks for joining us today, Pavel. It's been a great conversation about FastNetMon. To our listeners, thanks for tuning in to the Packet Pushers Priority Queue. You can find more podcasts and our community blog at packetpushers.net. Follow us on Twitter @packetpushers and on LinkedIn. We're also on Facebook. If you like what you hear, please rate us on Apple Podcasts. Remember, too much networking would never be enough. **Categories:** FastNetMon Blog **Tags:** press features --- ### [Second visit of FastNetMon at The Hedge Podcast](https://fastnetmon.com/2025/03/18/second-visit-of-fastnetmon-at-the-hedge-podcast/) **Published:** March 18, 2025 **Author:** FastNetMon **Content:** ## Read the in-depth discussion on FastNetMon use cases In this episode of the Hedge, hosts Russ White and Tom Ammon are joined by Pavel Odintsov, the CTO of FastNetMon, to explore the capabilities and use cases of this open-source DDoS detection tool. The discussion delves into the unique features of FastNetMon, including its ability to detect outbound DDoS attacks, its reliance on BGP for traffic diversion, and its flexibility in deployment across various platforms, including Raspberry Pi. Pavel shares insights into how FastNetMon can be used to manage network traffic, reduce costs, and enhance security. Whether you're a network engineer or IT professional, this episode offers valuable perspectives on leveraging FastNetMon for robust network protection. [Listen to the podcast on our YouTube channel](https://www.youtube.com/watch?v=LhnezZkuHVg) --- **Read the podcast transcript:** Podcast Host: Join us at the Hedge for a conversation about engineering, technology, and business. In this episode, Russ White, Tom Ammon, and Pavel Odintsov dig into FastNetMon. Russ White: Well, hello Tom. You're in your home office today, which is cool. Do you have your Christmas tree up yet? That's not right. If it is, don't. Pavel, how are you today? Pavel Odintsov: Excellent, excellent. Russ White: Good. Our second shot at running and talking about FastNetMon on the Hedge, which is good. We like open source stuff. We like projects where people can get their hands dirty and do what needs to be done. Last time we talked about FastNetMon, we discussed how it works and its history. This time, we want to talk more about use cases for FastNetMon. Before we started recording, you mentioned outbound attack detection, which is interesting because most people think about inbound DDoS. Explain what you mean by outbound. Pavel Odintsov: When we started FastNetMon, we tried to find the root cause of DDoS attacks. After experiencing downtime from a serious DDoS attack, you start looking for the root cause. You end up identifying a particular network or server that initiated the attack. Companies usually have problems with incoming DDoS attacks, but if you work for a data center or hosting provider, you'll notice a lot of outgoing traffic that doesn't look legitimate. FastNetMon can identify when a host in your network starts generating an enormous amount of traffic. It's a good point to look at, and you can apply different actions. Modern hardware can generate a lot of traffic with a single machine, enough to disrupt services on the Internet. Tom Ammon: So is the assumption that a high volume UDP flow means we should look at this for DDoS? Pavel Odintsov: In some cases, yes. You usually have a good understanding of the services running in your network. If you see a high volume of UDP traffic, it might indicate a DDoS attack. You can use the number of UDP packets and flows as indicators. Russ White: Interesting. So if one of your machines has been taken over, what are you thinking of? It's easy to generate a lot of traffic, right? Pavel Odintsov: Yes, it usually starts with web software that has security issues, like outdated WordPress. Attackers upload malware, often small scripts, to generate UDP traffic. It's common for a single server to be taken over by multiple botnets using different malware. Russ White: I remember cases where this would have been helpful. Code Red infected large networks, causing major problems. FastNetMon could have helped identify traffic patterns. Pavel Odintsov: Yes, FastNetMon isn't focused on intrusion detection, but it can notify you of unusual traffic patterns, like gigabits of UDP traffic in a quiet network segment. Tom Ammon: I'm curious about the placement of the service. For outbound detection, where do you place it? Pavel Odintsov: It depends. For residential services, deploy FastNetMon before port translation to see internal IPs. Keep it close to your billing system and core network. Russ White: Another case where this would be interesting is if software was misinstalled on thousands of desktops, causing network issues. FastNetMon could help identify traffic patterns. Pavel Odintsov: Exactly. FastNetMon has no licensing limits, so you can install it on every machine. It's often deployed on virtual machines in VPS services to detect outgoing attacks. Russ White: Right, and with this solution, you can bring the policy to the traffic. Another use case we discussed was diverting traffic. What do you mean by that? Pavel Odintsov: Customers use FastNetMon to detect incoming DDoS and can use RTBH or Blackhole to block traffic. If you don't have enough capacity to absorb the attack, you can divert traffic to a cloud scrubbing center. FastNetMon can create BGP announcements or call APIs for remote scrubbing centers. Russ White: How do you stage this in your network? Pavel Odintsov: You can use BGP to divert traffic to a remote scrubbing center or within your network. FastNetMon can act as a kill switch, redirecting traffic to specialized equipment for filtering. Russ White: Interesting. You can use FastNetMon for detecting elephant flows or hot links in a data center fabric. Pavel Odintsov: Yes, FastNetMon can export bandwidth information for decision-making. You can use it for traffic engineering and see real-time changes in load distribution. Russ White: You're primarily relying on BGP for this, right? Pavel Odintsov: Yes, we use BGP Unicast and Flow Spec. Flow Spec is more flexible, allowing you to discard, rate limit, or tag traffic for quality of service. Tom Ammon: It sounds like you could build your own scrub center with FastNetMon. Pavel Odintsov: Yes, but FastNetMon focuses on L3 and L4. For sophisticated attacks, you need additional equipment. Some customers have built scrubbing centers with FastNetMon. Russ White: We discussed fine-tuning on-premises equipment. FastNetMon can help with that, right? Pavel Odintsov: Yes, FastNetMon can help reduce costs by minimizing scrubbing center usage. It can redirect traffic on demand, saving on filtering equipment licenses. Russ White: If I have multiple upstream providers, I can use FastNetMon for traffic diversion, right? Pavel Odintsov: Yes, it's possible. Tom Ammon: What's the inspection engine built out of? Pavel Odintsov: FastNetMon uses counters and calculates exponential moving averages for different traffic types. It exports information to time series databases like InfluxDB and Graphite. Tom Ammon: Have you seen FastNetMon replace other NetFlow collection tools? Pavel Odintsov: Sometimes, but customers often use them together. FastNetMon operates in real-time, while other tools store data for historical reports. Russ White: Where can you run FastNetMon? Pavel Odintsov: FastNetMon is a C binary application. You can run it on Docker, bare metal, or in cloud environments. It's lightweight, with no major dependencies. Russ White: You could run it on Raspberry Pi, right? Pavel Odintsov: Yes, Raspberry Pi is powerful enough for FastNetMon. It's often used in network companies that lack Linux machines. Russ White: Tom, any other questions? Tom Ammon: No, but I have a Raspberry Pi ready for FastNetMon. Pavel Odintsov: You can install it with apt install fastnetmon on Debian. It supports ARM 64. Russ White: You could use it on your home network to monitor IoT devices. Where can people get FastNetMon? Pavel Odintsov: GitHub is the best place. Search for FastNetMon, and you'll find contributions from the community, integrations, and packaging for different platforms. Russ White: Do you blog or anything else? Pavel Odintsov: You can find my blog at pavel.network. Russ White: Tom, you're on Twitter, right? Tom Ammon: Yes, @TomAmmon. Russ White: I'm @RussWhite, and you can find me at Rule 11 Tech. Thanks for joining us on this episode of the Hedge. **Categories:** FastNetMon Blog **Tags:** press features --- ### [DDoS attack cause another DigiD outage in the Netherlands](https://fastnetmon.com/2025/03/18/ddos-attack-cause-another-digid-outage-in-the-netherlands/) **Published:** March 18, 2025 **Author:** FastNetMon **Content:** Imagine trying to file your taxes or access your medical records, only to find the system completely down. That’s what happened with DigiD, the Dutch government’s login system. Twice. A large DDoS attack disrupted the service in the first week of March, leaving a lot of people unable to use important online services. It wasn’t just tax forms; things like medical portals and even paying traffic fines were affected. Plus, MijnOverheid, where people keep track of their government admin, was also hit hard. Within the first hour of the outage, over a thousand individuals reported issues on the downtime monitoring website AlleStoringen. The Belastingdienst, the country’s Tax and Customs Office, received several thousand complaints about access issues, exacerbated by the fact that Monday marked the first full working day for annual income tax return filings and digital payroll submissions. The affected systems included BSNk (Burger Service Nummer-koppelregister), DigiD Machtigen, Digipoort Services, and Machtigen en Mededelen. Logius, the Dutch government’s digital service provider, is actively investigating the incident and working to mitigate the DDoS attacks. Authorities are striving to restore full functionality to DigiD, DigiD Machtigen, BSNk, Digipoort, and MijnOverheid, which were only partially available during the outage. This incident is not isolated. Just six weeks ago, a similar disruption linked to a DDoS attack led to network overload. The latest incident followed a weekend of heavy traffic that had already strained access to the Belastingdienst’s tax filing system for 2024 income declarations. These repeated DDoS attacks against critical digital infrastructure underscore the need for effective cybersecurity measures in the Netherlands’ public service systems. As reliance on digital platforms for government, healthcare, and financial services continues to grow, strong cybersecurity measures become increasingly important. Authorities have not yet provided a timeline for when all affected services will be fully restored. Residents are advised to monitor official channels for updates and expect potential delays in accessing critical online services. --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit https://fastnetmon.com **Categories:** FastNetMon Blog **Tags:** DDoS Attacks --- ### [DDoS defence for hosting providers](https://fastnetmon.com/2025/04/03/ddos-defence-for-hosting-providers/) **Published:** April 3, 2025 **Author:** FastNetMon **Content:** ## Understanding DDoS Attacks from the hosting provider’s point of view As the backbone of the internet, hosting providers are pivotal in defending against DDoS attacks. Their ability to maintain the accessibility and reliability of websites and applications is vital for customer satisfaction and their own reputation. However, this responsibility also exposes them to the threat of Distributed Denial of Service (DDoS) attacks, which can disrupt services and lead to financial and reputational damage. In this article, we'll explore effective DDoS defence strategies that hosting providers can implement to protect their infrastructure, ensure uninterrupted service, and maintain trust with their clients. ### Why Hosting Providers Struggle with DDoS Attacks? DDoS attacks involve overwhelming a target server, service, or network with a flood of internet traffic. This can be achieved through various methods, such as volumetric attacks that consume bandwidth and protocol attacks that exploit server resources. The goal is to render the service unavailable to legitimate users. Hosting environments are often caught in the crossfire of DDoS attacks due to the vast number of customers they serve. With tens of thousands to millions of clients, an attack on a single customer can inadvertently affect many others, causing widespread disruption. This collateral damage occurs because the interconnected nature of hosting environments means that when one customer is targeted, the attack can spill over, impacting other clients on the same infrastructure. As a result, the hosting provider's reputation can suffer, as it appears they are unable to maintain service availability, even though the attack was not directed at them. ### DDoS defence strategies for hosting providers In hosting environments, DDoS attacks often target specific IP addresses or the IP range of a particular customer, leading to an overload of the link between routers and physical servers. This not only disrupts the attacked customer but others sharing the same resources. The primary goal of DDoS defence in such settings is to maximise uptime for all customers while maintaining efficiency. An effective strategy should focus on pinpointing and mitigating the problem without affecting the vast majority of customers who are not under attack. FastNetMon is designed with the needs of hosting providers in mind, offering an efficient solution to maintain high service levels. By efficiently identifying and mitigating DDoS threats, FastNetMon helps ensure uninterrupted service for all customers, allowing providers to focus on delivering quality hosting services. **Simple and efficient defense: BGP blackhole / RTBH** Blackholing, or Remote Triggered Black Hole (RTBH) routing, is a highly efficient and cost-effective strategy for mitigating DDoS attacks in hosting environments. With FastNetMon, hosting providers can quickly identify when a specific IP is under attack and automatically isolate that IP by redirecting its traffic to a null route. This effectively removes the malicious traffic from the network, preventing it from affecting other customers. One of the key advantages of blackholing is its simplicity and ease of implementation. It does not require sophisticated equipment, making it an ideal solution for small and medium-sized hosting operations. By focusing on the targeted IP, blackholing minimises the impact on the rest of the network, ensuring that unaffected customers continue to receive uninterrupted service. This targeted approach allows hosting providers to maintain high service levels while managing costs effectively. You can read more in detail how BGP blackhole works [here](https://fastnetmon.com/2024/12/07/bgp-blackhole-automation-for-ddos-mitigation/). **Next-level defence: BGP Flow Spec** For hosting companies that require more sophisticated rules to manage malicious traffic, BGP Flow Spec offers an advanced solution. While basic strategies like blackholing are effective for many scenarios, some situations demand a more nuanced approach to traffic management. BGP Flow Spec allows hosting providers to define granular rules for filtering traffic based on a variety of attributes, such as source and destination IP addresses, ports, and protocols. This level of detail enables providers to target and mitigate malicious traffic precisely without impacting legitimate users. By leveraging BGP Flow Spec, hosting companies can implement dynamic and flexible defence strategies that adapt to the evolving nature of DDoS attacks. This approach is particularly beneficial for larger hosting operations or those with high-value clients, where maintaining service availability is paramount and blackholing the affected IPs is not an option. FastNetMon is the perfect tool to implement BGP Flow Spec, and you can learn more about how it works [here](https://fastnetmon.com/2025/02/10/bgp-flow-spec-for-ddos-mitigation/). ### Conclusions Hosting providers face significant challenges in defending against DDoS attacks, which can disrupt services and damage reputations. These attacks often spill over from targeted customers to affect others on shared infrastructure, making effective defence strategies essential. FastNetMon offers hosting providers a practical and effective solution to maintain service levels. With tools like BGP blackholing for straightforward mitigation and BGP Flow Spec for more nuanced traffic management, FastNetMon helps providers address threats without impacting unaffected customers. This approach ensures that hosting environments remain robust, protecting both infrastructure and customer trust. Read more at [https://fastnetmon.com](https://fastnetmon.com/), and contact us at <sales@fastnetmon.com> to discuss more! **Categories:** FastNetMon Blog **Tags:** Network Security Insights --- ### [Fact & Fiction of X DDoS Attack: DDoS professionals comment](https://fastnetmon.com/2025/04/04/x-formerly-twitter-ddos-attack-fact-fiction/) **Published:** April 4, 2025 **Author:** FastNetMon **Content:** ## What can we learn from the alleged high-profile cyber attack? Earlier this month, social media platform X (formerly Twitter) experienced a major DDoS attack that caused intermittent outages for users worldwide. While service was eventually restored, the real story began after the attack, when Elon Musk published claims about its origin. Just weeks after the first large-scale DDoS attack, X faced another outage on March 30. The impact was again global, particularly for users of the X mobile app. According to the data, over 57% of users affected were using the app on iOS and Android, while others experienced issues accessing the platform via desktop. The latter outage has not yet been officially acknowledged by X’s technical team, which leaves room for speculation - is this another cyberattack or just platform instability? In this article, DDoS professionals shed light on the reality of such claims and explain the realities and common misconceptions about DDoS attacks. ## Where do DDoS attacks originate from? Elon Musk published several posts about the incident, initially claiming that the attack was conducted by a coordinated group or even a nation-state with vast resources. Later, he claimed that a large proportion of the traffic came from Ukraine, insinuating responsibility. ![](https://fastnetmon.com/wp-content/uploads/2025/03/Elon-Musk-on-X-DDoS-Attack.png)This statement was met with swift criticism from cybersecurity professionals across various news outlets. The reality is that attributing a DDoS attack, or any cyberattack, based on IP address alone is naive at best. Attackers systematically use VPNs, proxies, spoofing, and botnets to mask their origin. These tactics make it nearly impossible to say with certainty where an attack comes from — or who is responsible. In general, the IPs used in a DDoS campaign do not belong to the attacker at all. They come from hijacked devices scattered across the globe: poorly maintained IoT equipment like security cameras or smart home devices, poorly maintained routers, printers, and more. Countries with large populations or a high number of internet-connected devices often appear overrepresented in DDoS traffic simply because there’s more opportunity for devices to be compromised - not because the attackers are necessarily located in those countries. Attribution in this context is more art than science, and careless claims can cause more confusion than clarity. Additionally, attacks much more often originate from far less benign actors than nation-states' coordinated cyberwar efforts. The overwhelming majority of attacks reportedly come from competitors or unhappy customers. ## The risks of saying too much When it comes to handling any cyberattack, sharing technical post-mortems in public can backfire. The same goes for DDoS attacks: It is very risky to disclose too many details — such as how the attack was conducted, how the malicious traffic was blocked, what tools and techniques were used, or where gaps were discovered. This may give the attackers a chance to regroup and come back better prepared. We at [FastNetMon](https://fastnetmon.com/) are also well aware of this risk. While FastNetMon is an [active news outlet](https://fastnetmon.com/blog/) for DDoS-related cybersecurity news, with a wealth of insider insight, we sometimes have to curb the information shared. Cybersecurity isn’t just about patching holes. It’s also about managing what you communicate, both internally and externally. Sometimes, silence is part of the strategy. ## Claiming the blame for a DDoS attack DDoS attacks are hard to trace because they are intentionally decentralised. Tens of thousands of devices can be used in a single attack. Some of these attacks are launched using DDoS-as-a-Service tools, which are increasingly easy to access. So-called ‘Stresser’ services are sold as legitimate testing tools, but ‘booter’ services are deliberately built to be used for disruption. These services are unfortunately very easily accessible, and at price points even regular consumers can afford. Technically, anyone could have paid for a booter service to initiate a DDoS attack towards X. The larger, more high-profile attacks are often claimed by known groups of hackers, not individual actors. In X’s case, one such group, Dark Storm Team, claimed responsibility. Dark Storm Team is a pro-Palestinian hacker group that has been operating since late 2023. However, claims don’t always equal truth. Hacker groups are sometimes, quite controversially, seeking publicity for their actions and claiming unclaimed attacks to attract more attention and support for their hacktivist causes. ## What can DDoS victims do to improve their defences? Defence options against DDoS exist, but no single measure is foolproof. Much of the mitigation techniques depend on the exact attack surface, infrastructure, and hardware setup. What matters is layered defence that is well thought out for the specific use case — combining traffic monitoring, rate limiting, early detection, and lightning-fast automation to act before the network is overwhelmed with malicious traffic. --- ## **About FastNetMon** FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. **Categories:** FastNetMon Blog **Tags:** DDoS Attacks --- ### [FastNetMon becomes a Code Protector of OpenSSL Foundation](https://fastnetmon.com/2026/02/27/fastnetmon-becomes-a-code-protector-of-openssl/) **Published:** February 27, 2026 **Author:** FastNetMon **Content:** We’re pleased to share that **FastNetMon** is now officially a *Code Protector* supporter of **OpenSSL**, as published by [**the** **OpenSSL Foundation**](https://openssl.foundation/donate/our-supporters). This reflects our commitment to strong cryptography and to supporting the open-source projects that form the foundation of secure internet communications. ## **Why we support OpenSSL** OpenSSL is one of the most widely used open-source implementations of TLS and cryptographic algorithms. It is integrated into operating systems, servers, networking software, and countless applications that require secure data transmission. Secure communication depends on correctly implemented and actively maintained cryptographic libraries. Open-source projects like OpenSSL provide transparency, peer review, and broad industry adoption — all of which are important characteristics for trusted security components. As a company operating in the network security space, we recognise the importance of well-established cryptographic standards and mature implementations. Supporting OpenSSL at the Code Protector level is a practical way to contribute to the long-term sustainability of a project that underpins secure communications worldwide. ## **Backing critical internet infrastructure** Strong encryption and secure protocols are essential building blocks of modern infrastructure. Organisations across industries rely on TLS and related cryptographic mechanisms to protect sensitive data in transit. By supporting OpenSSL, we are reinforcing our commitment to trusted, standards-based security technologies and to the broader open-source ecosystem that helps maintain them. Security is a shared responsibility. We are proud to contribute to the continued development of OpenSSL and to stand alongside other organisations that support its mission. **Categories:** FastNetMon Blog, Featured, Press & Newsroom --- ### [Unusual Large-Scale Outbound DDoS Activity Observed Across Indian Networks](https://fastnetmon.com/2026/03/26/unusual-large-scale-outbound-ddos-activity-observed-across-indian-networks/) **Published:** March 26, 2026 **Author:** FastNetMon **Content:** We are tracking a significant surge in outbound DDoS activity originating from residential broadband networks across India. Over the last 72 hours, traffic analysis indicates abnormal outbound UDP patterns affecting hundreds of networks. This analysis is based on telemetry from a major Broadband Network Gateway (BNG) vendor and corroborated by several operator observations. The activity consists of sustained outbound traffic dominated by UDP packets with highly unusual behavioural characteristics. ![](https://fastnetmon.com/wp-content/uploads/2026/03/Total-outgoing-traffic-bandiwdth-by-type-outbound-DDoS-analysis-indian-networks-1-1024x567.png)![](https://fastnetmon.com/wp-content/uploads/2026/03/Outgoing-UDP-traffic-per-host-Indian-networks-FastNetMon-analysis-1-1024x535.png)### Key Traffic Observations - Outbound traffic volumes exceeding inbound traffic across residential networks - Coordinated traffic bursts occurring simultaneously across large numbers of subscriber hosts - A portion of malicious UDP traffic sourced from port 443 at unusually high rates - A large and shifting set of destination IP addresses and ports - Some traffic targeting internal ISP infrastructure rather than external internet hosts ### Distinguishing Malicious UDP from QUIC While some UDP/443 traffic is expected due to QUIC-based applications, these upload-heavy, synchronised patterns deviate sharply from normal user behaviour. ![](https://fastnetmon.com/wp-content/uploads/2026/03/quote.png) > "These patterns are consistent with compromised edge devices generating coordinated outbound traffic," says **Pavel Odintsov, Founder of FastNetMon**. "In several cases, traffic appears to target infrastructure within ISP networks themselves, which could indicate an intention to destabilize broadband gateways and NAT systems." ### Risks to ISP Infrastructure Outbound DDoS occurs when compromised subscriber devices (CPEs/IoT) send attack traffic outward. At this scale, the traffic doesn't just impact external targets; it threatens the ISP’s own BNG and NAT capacity by saturating state tables and processing power. ### Detection and Monitoring Recommendations FastNetMon’s detection technology enables operators to identify outbound DDoS activity early through [analysis of network traffic telemetry and threshold anomalies ](https://fastnetmon.com/docs-fnm-advanced/per-direction-hostgroup-thresholds/)across subscriber networks. FastNetMon encourages broadband operators to monitor for sudden outbound UDP spikes, abnormal packet rates from port 443, traffic to port 0, and concentrated destination patterns. **Categories:** FastNetMon Blog, Press & Newsroom --- ### [CloudFest 2026 - Event Recap](https://fastnetmon.com/2026/03/27/cloudfest-2026-event-recap/) **Published:** March 27, 2026 **Author:** FastNetMon **Content:** From March 23–26, the FastNetMon team attended **CloudFest 2026**, one of the largest global gatherings for the internet infrastructure industry, held at the ever-so-fun Europa-Park in Germany. Representing FastNetMon on-site was **Virgil Truica, Head of Sales**, who spent four intensive days meeting partners, reconnecting with industry peers, and discussing the evolving challenges facing network operators and cloud providers. [![](https://fastnetmon.com/wp-content/uploads/2026/03/Youtube_shorts.png)](https://www.youtube.com/@FastNetMon/shorts) [Check out our CloudFest 2026 shorts on YouTube!](https://www.youtube.com/@FastNetMon/shorts) ## **What’s happening at CloudFest?** CloudFest brings together the global cloud computing and internet infrastructure ecosystem, from hosting providers and ISPs to hardware vendors, cybersecurity companies, and platform builders. According to the organiser, the 2026 edition gathered: - 10,000+ participants - 250+ speakers - 150+ partners - 80+ countries represented Across four days, the event combined conference sessions, exhibitions, and networking activities focused on the technologies shaping the future of the internet — plus much more fun than one would normally expect from a standard work trip! ## **Meetings, meetups, and memorable moments** While the official agenda covered a wide spectrum of topics, including web infrastructure, AI, cloud platforms, hardware innovation, cybersecurity, and network operations, much of the value came from direct conversations. For FastNetMon, CloudFest was primarily about people. ![](https://fastnetmon.com/wp-content/uploads/2026/03/CloudFest-people.png)Virgil’s schedule quickly filled with back-to-back meetings, partner discussions, and spontaneous catchups across the venue. ![](https://fastnetmon.com/wp-content/uploads/2026/03/quote.png) > I jumped straight into meetings from the morning, caught up with old friends I haven’t seen in a while, and had some really good conversations. It’s always great to see how quickly things can click when you’re face-to-face. > — Virgil Truica, Day 1 at CloudFest These in-person discussions remain critical in an industry where operational trust and long-term collaboration matter as much as technology itself. ![](https://fastnetmon.com/wp-content/uploads/2026/03/CloudFest-people-–-2.png)## **Information security and sovereignty increasingly central to industry discussions** One clear trend throughout the event was the growing attention around DDoS defence. According to Virgil, conversations around network resilience and attack mitigation were noticeably more frequent – and more serious – than in previous years, alongside broader discussions around cybersecurity services, DNS infrastructure, and European cloud alternatives. ![](https://fastnetmon.com/wp-content/uploads/2026/03/quote.png) > Back-to-back meetings, great conversations, and a lot of new connections. One thing that stood out was how many discussions touched DDoS security, EU cloud sovereignty, and cybersecurity in general. Interest is clearly growing given what’s happening worldwide. > — Virgil Truica, Day 2 at CloudFest Operators, hosting providers, and infrastructure teams are increasingly looking for more control, improved visibility and transparency with everything they do. ### Some of the topics beyond the stage Many discussions during the week reflected broader operational challenges facing hosting providers today. Across meetings and informal conversations, several recurring topics emerged: - growing interest in European-operated cloud services as alternatives to hyperscalers - increasing focus on DNS reliability and security services - rising RAM and storage prices impacting providers of all sizes - and AI moving from hype into practical integration across infrastructure and operations These themes came up consistently in conversations rather than just conference sessions, highlighting where operators are currently focusing their investments and attention. ## **Work hard, play hard, throw servers** CloudFest is known as much for its community atmosphere as for its technical programme. Beyond keynotes and panels, much of the magic happens in the informal moments — catching up with peers over a coffee, sharing stories at booth gatherings, or making connections during speed networking and community meetups. And then, of course, there’s the CloudFest tradition that turns heads: the **World Server Throwing Championship**. For over a decade, servers have been hurled in data-center basements, a secret pastime organised by the Dutch Cloud Community. Now brought into the open by the World Server Throwing Association (WSTA), this underground sport is finally celebrated in the mainstream — a true test of strength, skill, and bravado. As the competition showed, it’s where the cloud world finds out who’s strong, who’s fearless, and who’s keeping their datacenter tidy. ![](https://fastnetmon.com/wp-content/uploads/2026/03/CloudFest-FastNetMon-Event-Recap.png)## **Why we love CloudFest** We probably love remote work even more than you do, but some things are just better face-to-face – like CloudFest. Face-to-face meetings have a way of cutting through all the noise. At an event like CloudFest, a short chat over coffee can spark ideas and build trust far faster than any online meeting. Showing up in the flesh changes everything: projects move quicker, partnerships deepen, and conversations take on a level of honesty and nuance that only real-world connection can provide. For FastNetMon, CloudFest 2026 reinforced a clear signal: network operators are placing increasing emphasis on visibility, automation, infrastructure independence, and reliable DDoS mitigation as foundational capabilities. ![](https://fastnetmon.com/wp-content/uploads/2026/03/CloudFest-Virgil-Truica-FastNetMon-Event-Recap.png)## **See you at the next event** If you met Virgil during CloudFest — thank you for the conversations and insights shared throughout the week. We look forward to continuing those discussions and meeting more members of the community at the next one! **Categories:** Events, FastNetMon Blog, Press & Newsroom --- ### [Sneak peek: Building a high-performance VPP-based inline filter at FastNetMon](https://fastnetmon.com/2026/06/11/sneak-peek-building-a-high-performance-vpp-based-inline-filter-at-fastnetmon/) **Published:** June 11, 2026 **Author:** FastNetMon **Content:** For the past decade, FastNetMon has been trusted by network operators globally as an elite, ultra-fast out-of-band DDoS detection engine. It acts as the intelligent detection plane, analysing flow telemetry such as NetFlow, sFlow, and IPFIX, spotting anomalies in seconds, and orchestrating upstream mitigation via BGP FlowSpec or RTBH. But a major evolution is currently brewing in our labs. We are giving the community a sneak peek at an internal R&D project (currently code-named **FastACL**). We are building a high-performance **inline DDoS filtering stack** entirely in-house. FastNetMon is expanding from a world-class detector into a line-rate, software-defined network traffic scrubbing engine. ### From DDoS detection to in-line mitigation FastNetMon is already the best out-of-band DDoS sensor on the market. For thousands of networks globally, the workflow of detecting anomalies by reading network telemetry and mitigating them using BGP FlowSpec or RTBH has been incredibly efficient. This is a proven architectural pattern we’ve built the product on so far. But we are not stopping there. There is a distinct need in the market for a fine-tuned, surgical mitigation capability that doesn't rely on edge routers to execute the filtering rules. That is why we are building an inline DDoS mitigation engine completely in-house. We are excited to share the development story so far, with very interesting lab results. ![](https://fastnetmon.com/wp-content/uploads/2026/06/FastNetMon-Sneak-peek-into-product-development-768x1024.jpeg)**Moment of truth: the lab hardware arrived, and it is time to set up a test lab.** While the product development started much earlier, the project became tangible three months ago when we received a delivery of our specialised server infrastructure. That hardware allowed us to spin up a dedicated VPP lab and finally benchmark our engine against real hardware links. The engineering objective was simple: put standard x86 commodity hardware directly inside the live data path of a backbone link. **Instead of straining a router's finite hardware ACL tables with massive blocklists**, every single packet physically flows through our software-defined engine in real time. This allows us to surgically drop malicious traffic on the wire while passing legitimate traffic with minimal latency. ### Lab Benchmarks: Testing the Limits of 100G Hardware To achieve this kind of throughput without relying on proprietary ASIC hardware, our team is building the inline filter on top of **VPP (Vector Packet Processing) and DPDK**. Inside our dedicated lab environment – which emulates a 100G backbone using physical DAC and fibre links – we subjected the system to sustained packet-rate stress tests using TRex traffic generation. ![](https://fastnetmon.com/wp-content/uploads/2026/06/Sneak-peek-from-FastNetMon-lab-768x1024.jpeg)*The VPP lab up, running, and executing live filter tests under load.* The initial results were a massive success. Here is exactly how the data broke down across our two primary testing phases: #### 1. Pass-through baseline (no filtering rules) Before enabling filtering, we established a pass-through baseline with zero rules installed to observe how VPP behaves under sustained high packet rates. In this configuration, the system sustained approximately **120–126 Mpps depending on measurement layer**, with near-full forwarding throughput under load. Port-level and aggregate measurements show: - TRex transmit rate: **~142 Mpps** - DUT receive/forwarding range: **~119–122 Mpps** - Aggregate processing rate: **~121.26 Mpps** This provided a reference point for subsequent filtering performance tests under identical hardware conditions. ![](https://fastnetmon.com/wp-content/uploads/2026/06/pass-through-baseline-scenario.png)*Pass-through baseline (0 rules) fwd-flood-32 test showing TRex offered load versus DUT forwarding performance and DPDK processing efficiency metrics.* ![](https://fastnetmon.com/wp-content/uploads/2026/06/fwd-flood-32-test-.png)*Pass-through baseline (0 rules) fwd-flood-32 test showing TRex offered load versus DUT forwarding performance and DPDK processing efficiency metrics.* ![](https://fastnetmon.com/wp-content/uploads/2026/06/Aggregate-counters.png)*Aggregate counters during pass-through baseline testing showing ~121 Mpps sustained processing rate.* ![](https://fastnetmon.com/wp-content/uploads/2026/06/Interface-counters.png)*Interface counters showing RX/TX activity during the pure baseline forwarding test.* #### 2. The 1-Million-Rule Stress Test The true test of an inline filter is how it performs under an enormous firewall rule set during a sustained high-intensity traffic scenario. We loaded the FastACL stack with **1,000,000 active filtering rules** and subjected it to a TRex-generated **fwd-flood-32 traffic profile**, consisting entirely of minimum-sized 64-byte packets. ``` Aggregate counters during drop execution: Packets Bytes pps L3 bps L1 bps Processed: 1476998528 (1.48 G) 73849926400 (73.85 GB) 140.90 Mpps 56.36 Gbps 99.19 Gbps Dropped: 1476992993 (1.48 G) 73849649650 (73.85 GB) 140.90 Mpps 56.36 Gbps 99.19 Gbps ``` The metrics speak for themselves: the working code sustained **140.90 Mpps at 99.19 Gbps**, operating at near line-rate for 100G Ethernet with minimum-sized packets, while dropping the traffic and keeping the host system stable under sustained load. We achieved this by utilising RSS (Receive Side Scaling) to distribute the packet processing workload evenly across 32 physical CPU cores, keeping our per-packet processing budget down to that tiny 225-cycle window. ### Lab Environment Specifications - Device Under Test (DUT): AMD EPYC 7742 (64 cores / 128 threads, single socket), 256 GB DDR4-3200, Mellanox ConnectX-5 100G. - Traffic Generator (TG): AMD Ryzen 7 5800X, 32 GB DDR4-2133, Mellanox ConnectX-5 100G executing TRex packet generation. Because our architecture is built on top of the DPDK and VPP ecosystems, we retain low-level control over the data path, enabling fine-grained optimisation of packet processing behaviour as the system evolves. ### The 12-Month Roadmap We are building this technology out in three distinct phases over the next year: - **Stage 1 (Now): Stateless Line-Rate Filtering.** The current engine focuses on hyper-fast, stateless packet drops using a FlowSpec-like matching approach (IPs, ports, and basic protocol flags). - **Stage 2 (+3 Months): Deep Payload Bit-Masking.** We will introduce flexible filtering that allows operators to match signatures *anywhere* inside a packet payload using programmable shifts and masks. For example: *skip 24 bytes from the beginning of the packet, check if the next two bytes match a specific signature, if not, discard.* Operators can stack up to four of these rules per profile for highly complex, per-protocol matching. - **Stage 3 (+12 Months): Stateful TCP Tracking Machine.** The engine will evolve to track the state of live connections, allowing it to defend against sophisticated, session-based TCP abuse right at line speed. ### Keeping It Open Source True to FastNetMon’s DNA, this new inline filtering stack will be **partially open-source**. The core engine is supported by modern, developer-friendly management tools written in **Go (Golang)**, which communicate directly with the VPP backend via a high-speed binary API. ### Call for Early Testers The lab binaries and Go-based management tools will be functional soon. We want to get this into the hands of our community early. If you are a network operator who has been **operating VPP at scale for at least a few years** and you want to test-drive this inline filtering technology in your own environment, we want to hear from you. Reach out to our team to join the closed testing group early! **Categories:** FastNetMon Blog, Featured, Press & Newsroom --- ### [NANOG 97 - Event Recap](https://fastnetmon.com/2026/06/08/see-you-at-nanog-97/) **Published:** June 8, 2026 **Author:** FastNetMon **Content:** [![](https://fastnetmon.com/wp-content/uploads/2026/03/Youtube_shorts.png)](https://www.youtube.com/@FastNetMon/shorts) [Check out our event shorts on YouTube!](https://www.youtube.com/@FastNetMon/shorts) Last week, the team headed to Bellevue, Washington, for NANOG 97. Three packed days of operator debates, deep-dive engineering presentations, and the kind of high-value hallway conversations you only get when this community piles into one building. ![](https://fastnetmon.com/wp-content/uploads/2026/04/NANOG-97-FastNetMon-Event-Recap-–-team.png)For FastNetMon, NANOG is always a priority. Over the years, it’s consistently been a place where we meet operators we end up working with, and have conversations that turn into something real later on. Among operator group meetings, this is one of the few where things don’t stay at the level of discussion; they tend to move into actual implementation very fast. ### On Stage: Monitoring 2,800 BGP Sessions via BMP The highlight of the week for us was Pavel Odintsov’s presentation: **Monitoring 2,800 BGP Sessions using BMP protocol.** Pavel dug into why traditional monitoring setups such as SNMP, gNMI, and massive full-table dumps completely choke when you try to get real-time, per-peer BGP visibility at scale. He walked through how a BMP-based pipeline can handle full-fidelity telemetry across thousands of sessions and tens of millions of routes, backed by production benchmarks, showing how it holds up under heavy, real-world operational loads. Watch the full presentation: [See the presentation slides here](https://fastnetmon.com/wp-content/uploads/2026/06/Monitoring-2800-BGP-Sessions-using-BMP-protocol-may-22.pdf)[Download](https://fastnetmon.com/wp-content/uploads/2026/06/Monitoring-2800-BGP-Sessions-using-BMP-protocol-may-22.pdf) The room was packed with operators, and the Q&A afterwards got straight to the point. The technical questions and immediate real-world challenges raised by the audience showed us that the exact problems we’re trying to solve are top-of-mind for engineering teams right now. In fact, the presentation didn't really end when the timer ran out — the debate spilled out into the corridors and kept going for quite a while. ![Two men and a woman talk in a bright conference hall with brick columns and large windows in the background and natural light on them.](https://fastnetmon.com/wp-content/uploads/2026/04/Hallway-talks-NANOG-97-FastNetMon-1.png)### Other highlights Beyond the presentations and hallway debates, this was easily one of our busiest NANOGs for media and interviews. We caught up with Eric Chou from *Packet Pushers* and *Network Automation Nerds* for a quick micro-interview about network automation and visibility that will be going live very soon. On top of that, the official NANOG media team caught up with our very own Irina for a quick hallway interview highlighting her experience as a NANOG newcomer, sharing what it’s like to navigate the event for the first time. It was a massive week for the team on the media front, and we can't wait to share the footage once it drops. ![](https://fastnetmon.com/wp-content/uploads/2026/04/NANOG-97-FastNetMon-Event-Recap-media.png)### Beer & Gear, Socials, and Catching Up The main conference social was fantastic—great execution and an easy environment to reconnect with long-time industry friends and meet new operators. A major highlight for us this year was the Beer & Gear expo. We actually featured Beer & Gear as [part of a live stream](https://www.youtube.com/live/mnw0mLw9G7k?si=B7Qa3jMeMHFLf7S7) this time around, which brought some great energy and broader reach to the room. It was awesome to see community content naturally evolving alongside the main event. ![](https://fastnetmon.com/wp-content/uploads/2026/04/FastNetMon-at-NANOG-97-socials-1024x576.png)### Some of the standout Sessions The NANOG agenda is always intense, but a couple of presentations particularly hit home for us from a security and operations standpoint: - **The Kimwolf Aftershock: Residential Proxy Botnets One Year Later (Nokia)**: This talk looked at how residential proxy-based botnets have evolved over the last year and their massive footprint in modern DDoS attacks. The speakers showed how resilient these ecosystems are; even after major takedowns, successor botnets quickly fill the vacuum by recycling the same residential abuse vectors. The sheer scale of endpoint growth they discussed is a stark reminder that modern DDoS defense is no longer about handling isolated incidents—it’s about defending against highly adaptive infrastructure. - **50 Years of Networking (APNIC):** Geoff Huston delivered an incredible, reflective look at the last five decades of networking. He traced how open collaboration and operator-driven engineering built the modern internet, while posing some tough questions about whether those foundational models can survive today's commercial and technical pressures. It was a great reality check and a nice break from the immediate, day-to-day operational grind. ![](https://fastnetmon.com/wp-content/uploads/2026/04/NANOG-97-presentations-FastNetMon-recap-1024x576.png)### Thank you & see you again soon! NANOG 97 delivered exactly what makes this event unique: deep technical transparency, honest operational feedback, and plenty of face-to-time with the engineers who keep the internet running. A huge thank you to the NANOG organisers, and to everyone who stopped by to share feedback, talk shop, or catch up. Meeting existing customers, swapping notes with partners, and making new connections is exactly why we keep coming back. See you at the next one! **Categories:** Events, FastNetMon Blog, Featured --- ### [Taiwan Internet Week & TWNOG 7 - Event Recap](https://fastnetmon.com/2026/05/16/see-you-at-taiwan-internet-week-twnog-7/) **Published:** May 16, 2026 **Author:** FastNetMon **Content:** FastNetMon attended Taiwan Internet Week 2026 and TWNOG 7 in Taipei on 12–15 May 2026. It was a great week filled with impromptu meetings, technical discussions, catching up with friends, and conversations about where DDoS defence and network security are heading next. ![](https://fastnetmon.com/wp-content/uploads/2026/03/Youtube_shorts.png) [Check out our event shorts on YouTube!](https://www.youtube.com/@FastNetMon/shorts) ## Taiwan Internet Week On 14 May, Pavel Odintsov joined the Taiwan Internet Week panel discussion: **“NIS2 Directive and beyond: Resilience in Digital Landscape”** The session focused on the operational and compliance challenges introduced by the EU NIS2 Directive and how organisations are adapting to a much stricter cybersecurity and reporting environment. The discussion covered key NIS2 requirements, including tighter classification of Essential and Important Entities, 24-hour incident reporting obligations, enhanced identity verification requirements under Article 28, and increased accountability at the management level. A major theme throughout the panel was the growing expectation that organisations must demonstrate operational resilience in practice, not just through policy documentation. For network operators and security teams, that means faster detection, better visibility, more mature incident response workflows, and the ability to produce reliable reporting under tight timelines. The panel also explored the practical tension between GDPR privacy requirements and NIS2 transparency obligations, especially when organisations need to rapidly share information during active security incidents. The session was moderated by Joy Chan, Deputy CEO of TWNIC, and featured panellists Pavel Odintsov from FastNetMon, Léo Gaillard from National Institute for Cybersecurity Research, Alexandre from Formind, Daniel (IT Contract Manager), and Alex Leung from Akamai. The panel brought together perspectives from network security, infrastructure operations, compliance, and cybersecurity research, leading to a very practical discussion about how regulatory requirements are increasingly shaping day-to-day operational realities for technical teams. ## TWNOG 7 ![](https://fastnetmon.com/wp-content/uploads/2026/04/Photos-from-Taiwan-Internet-Week-2026-TWNOG-7.png)On 15 May, Pavel presented at TWNOG 7 with a talk titled: **“Challenges of DDoS Detection on Terabit scale”** The presentation was based on real deployment experience building DDoS detection systems for very large ISP environments operating at a terabit scale. The talk covered challenges, including: - handling telemetry rates above 50,000 UDP packets per second - processing inline monitoring data from Juniper MX and PTX platforms - dealing with double- and triple-tagged VLANs - differences in telemetry implementations between platforms - Linux kernel limitations around UDP socket scaling - eBPF-based load balancing approaches - achieving near real-time DDoS detection at very high traffic volumes A big part of the session focused on operational realities rather than theory — the kind of issues engineers usually only encounter once traffic volumes become large enough. Some of the most interesting discussions after the presentation were around telemetry processing bottlenecks, kernel behaviour under heavy UDP workloads, and the unexpected edge cases that appear when trying to build reliable, high-performance monitoring systems. See the presentation slides below! [Challenges of DDoS Detection on Terabit scale 2026](https://fastnetmon.com/wp-content/uploads/2026/04/Challenges-of-DDoS-Detection-on-Terabit-scale-2026-.pdf)[Download](https://fastnetmon.com/wp-content/uploads/2026/04/Challenges-of-DDoS-Detection-on-Terabit-scale-2026-.pdf) ## Great discussions and new connections TWNOG turned out to be one of the best places to talk directly with engineers running large production networks across the region. Pavel from the FastNetMon team had a great time meeting both long-time industry contacts and many new people during the week. As always, some of the best conversations happened outside the conference rooms — discussing operational challenges, deployment experiences, routing, telemetry, DDoS attacks, and infrastructure scaling over coffee and hallway chats. And naturally, all remaining spare time was spent exploring Taipei’s famous electronics districts! ## Thank you, Taiwan Internet Week & TWNOG ![](https://fastnetmon.com/wp-content/uploads/2026/04/Photos-from-Taiwan-Internet-Week-2026-TWNOG-7-2.png)A big thank you to the organisers, speakers, volunteers, and everyone wo took the time to discuss with us during the week. We especially want to thank Joy Chan and Nai-Wen Hsu for the kind invitation and for organising such a well-run event bringing together operators, engineers, and security professionals from across the region. Taiwan Internet Week and TWNOG created an excellent environment for open technical discussions and knowledge sharing, and we were very happy to be part of it. We look forward to joining again in the future. **Categories:** Events --- ### [FastNetMon Advanced 2.0.380](https://fastnetmon.com/2026/05/27/fastnetmon-advanced-2-0-380/) **Published:** May 27, 2026 **Author:** FastNetMon **Content:** **Release date:** 27 May, 2026 **Version:** 2.0.380 This release includes multiple security fixes and stability improvements across BGP, Flow Spec, Netflow v9, IPFIX, packet parsing, and internal buffer handling code. It addresses several vulnerabilities (CVE-2026-48682, CVE-2026-48683, CVE-2026-48684, CVE-2026-48686, CVE-2026-48688, CVE-2026-48689, CVE-2026-48690, and CVE-2026-48691) through stricter boundary validation, safer parsing logic, integer overflow protections, and expanded test coverage. The release also includes improvements to Netflow v9 and IPFIX processing, enhanced Flow Spec parser safety, full support for all BGP origin types, and a complete rework of remote host unban logic with new configuration controls and attack direction detection. **We strongly recommend all FastNetMon users upgrade immediately to this release.** ### Full list of changes - Added explicit block when we try to encode too long ASPATH to avoid uint8\_t overflow, [CVE-2026-48691](https://github.com/advisories/GHSA-pjmc-gjwh-qr2w) - Added full support of all origin types. Previously we had hardcoded BGP\_ORIGIN\_INCOMPLETE - Addressed integer overflow for pcap buffer allocation logic, [CVE-2026-48690](https://github.com/advisories/GHSA-h9r4-jj3x-8857) - Tightened security of decode\_mp\_reach\_attribute\_to\_ipv6\_announce with all required extensive security checks, [CVE-2026-48688](https://github.com/advisories/GHSA-rxgw-72v4-4rvj) - Add test for single byte next hop for IPv6 announce - Tightened number of flows per IPFIX packet to 256 - Added additional boundary checks in process\_netflow\_v9\_data() to ensure that no read outside of flowset is happening, [CVE-2026-48683](https://github.com/advisories/GHSA-242v-wx3w-qx8x) - Reduced number of allowed flow per packet for Netflow v9 from 0x4000 to 256 - Added strict check that Netflow v9 options records and scopes sections must be in 4 byte chunks - Added check to ensure that we do not read outside of packet in IPFIX template mode, [CVE-2026-48684](https://github.com/advisories/GHSA-6jf7-3j4w-4v3m) - Multiple improvements for Netflow v9 templates code - Disabled 'Flow duration' log message in IPFIX code which flooded logs - Added sanity check before we read scope offset for Netflow v9 options templates, [CVE-2026-48684](https://github.com/advisories/GHSA-6jf7-3j4w-4v3m) - Full tests for process\_netflow\_v9\_options\_template and process\_netflow\_packet\_v9 - Fixed multiple issues with boundaries check off by one in dynamic\_binary\_buffer\_t, [CVE-2026-48689](https://github.com/advisories/GHSA-5444-f65m-f3c8) - More strict Flow Spec reader logic if read\_one\_or\_more\_values\_encoded\_with\_operator\_byte returned error - Migrated Flow Spec wire parser to use safe version of decode\_bgp\_subnet\_encoding\_ipv4. Removed decode\_bgp\_subnet\_encoding\_ipv4 entirely due to unsafety issues, [CVE-2026-48686](https://github.com/advisories/GHSA-7p7c-c3vp-p386) - Full Flow Spec test coverage for encode and decode - Added sanity check for logic which decoded IPv4 prefixes from the wire. It addresses security issues in code - Removed duplicate function convert\_cidr\_to\_binary\_netmask\_local\_function\_copy - Added test for how\_much\_bytes\_we\_need\_for\_storing\_certain\_subnet\_mask - Addressed security issue in packet parser for IP packets which affects all plugins with exception Netflow and IPFIX. IP packet with artifically high IHL / header length may trigger read outside of allowed memory region, CVE-2026-48682 - Fully implemented unban logic for remote hosts with unban\_remote\_host\_only\_if\_attack\_finished support - Added unban\_remote\_host\_only\_if\_attack\_finished - Added options unban\_remote\_host\_enabled\_ipv4, unban\_remote\_host\_enabled\_ipv6, ban\_time\_remote\_host\_ipv4, ban\_time\_remote\_host\_ipv6 to control remote unban logic - Reworked remote unban logic to use queue and run callback script - Added attack direction detection for remote attacks - Added field notify\_script\_remote\_path to control path for remote script callback - Breaking change: we're removed logic to define per direction remote hostgroups using names remote\_host\_incoming and remote\_host\_outgoing. Pleae use name name remote\_host which includes thresholds for both directions [FastNetMon Advanced documentation](https://fastnetmon.com/docs-fnm-advanced/) [View this release on GitHub](https://github.com/FastNetMon/fastnetmon-advanced-releases/releases/tag/v2.0.380) **Categories:** Releases --- ### [KimWolf DDoS botnet operator arrested](https://fastnetmon.com/2026/05/25/kimwolf-ddos-botnet-operator-arrested/) **Published:** May 25, 2026 **Author:** FastNetMon **Content:** Canadian authorities have arrested a 23-year-old man suspected of operating the [KimWolf](https://fastnetmon.com/2025/12/26/kimwolf-possible-aisuru-successor-capable-of-multi-tbps-ddos-attacks/) IoT DDoS-for-hire botnet as part of a coordinated international investigation involving Canada, the United States, and Germany. The suspect, Jacob Butler (alias “Dort”), is accused of developing and managing KimWolf, a large IoT-based botnet built from compromised devices, including webcams and digital photo frames. Investigators say the botnet infected more than one million devices worldwide and was offered as a cybercrime-as-a-service platform, allowing customers to launch distributed denial-of-service (DDoS) attacks at scale. KimWolf was linked to high-volume DDoS campaigns targeting systems globally, including IP ranges associated with the U.S. Department of Defence Information Network (DoDIN). Authorities attribute attack peaks reaching nearly 30 Tbps to the botnet, placing it among the largest recorded volumetric DDoS events. According to investigators, KimWolf carried out more than 25,000 attack commands before its command-and-control (C2) infrastructure was disrupted in a court-authorised operation in March 2026. That same operation formed part of [a wider crackdown](https://fastnetmon.com/2026/04/16/europol-backed-operation-poweroff-targets-ddos-for-hire-ecosystem-contacts-75000-users/) on IoT botnets, including Aisuru, JackSkid, and Mossad, and led to the seizure of infrastructure tied to 45 DDoS-for-hire platforms. Many of these domains were redirected to law enforcement warning pages stating that DDoS services are illegal. Butler was identified through a combination of IP address evidence, account records, transaction data, and chat logs obtained via legal process. He now faces one count of aiding and abetting computer intrusion in the United States, carrying a maximum sentence of 10 years, and is currently in custody in Canada pending extradition. The broader picture is that two of the most recent record-breaking IoT botnets have now been disrupted, and arrests have been made. This is a positive development for defenders and shows that large-scale enforcement actions against DDoS infrastructure are increasingly coordinated and effective. At the same time, experience from previous takedowns suggests that the ecosystem rarely stays quiet for long. When major botnets are dismantled, new operators and variants typically emerge to fill the gap. We are watching closely to see how the landscape develops. **Categories:** FastNetMon Blog **Tags:** DDoS News, legal --- ### [RIPE 92 - Event Recap](https://fastnetmon.com/2026/05/22/see-you-at-ripe-92/) **Published:** May 22, 2026 **Author:** FastNetMon **Content:** RIPE 92 took place in Edinburgh, Scotland, bringing together ISPs, network operators, registries, and engineers for a week of working groups, plenaries, and a lot of hallway discussions. From FastNetMon, Outi Pietilanaho attended, splitting time between sessions and the usual RIPE meeting rhythm: talks, coffees, and meetings with friends and partners. of FastNetMon. ## Our plenary highlights The plenary agenda was packed, as usual, a mix of operational updates, research, and security talks. Here are a few sessions that stood out to us, mainly because they were directly DDoS-related or touched on real-world routing security and attack infrastructure in a way that’s relevant to our community. ### What DDoS scrubbing looks like in BGP data One of the more curious pieces of work came from [Shyam Krishna Khadka](https://ripe92.ripe.net/programme/meeting-plan/sessions/78/QKVKRR/) from the University of Twente, who analysed DDoS scrubbing behaviour using global BGP data across major mitigation providers. The focus was on how scrubbing centres show up in AS paths during mitigation events, and how that differs between always-on protection and on-demand activation. The dataset also included measurements around how long scrubbing sessions typically last and how consistently traffic is steered through mitigation infrastructure. Worth following this line of work further as it develops. ### What the terabit-scale DDoS looks like in today's environment A strong operational security talk came from [Jérôme Meyer](https://ripe92.ripe.net/programme/meeting-plan/sessions/79/7AETZG/) from Nokia, who gave a very grounded view of current DDoS traffic sources and botnet ecosystems. The key point: a lot of today’s attack traffic is not coming from “classic IoT botnets” anymore. It’s a mix of residential proxy networks, consumer devices with proxy SDKs, and large-scale distributed fleets that are effectively monetised as bandwidth infrastructure. From an operator point of view, this is what matters: attack traffic is increasingly indistinguishable from “normal-looking” residential or subscriber-originated flows, it just happens at a massive at scale. ### Routing security: trust boundaries and deployment reality Two talks in the opening plenary highlighted different sides of the same underlying theme: how routing security is increasingly shaped by implementation details and operational reality rather than just protocol design. [Sasha Romijn (Reliably Coded, IRRD / IRRexplorer / internet.nl) ](https://ripe92.ripe.net/programme/meeting-plan/sessions/65/YHQY7N/)presented their work on how seemingly harmless data fields across infrastructure systems, from TLS certificates and DNS responses to RIPE database objects, can become a security issue when rendered or processed without strict trust boundaries. The talk turned slightly provocative (in a positive way!), exploring how these flows can propagate into sensitive systems such as RPKI-related workflows, depending on how tooling and authentication layers are implemented. [Maria Matejka (BIRD / CZ.NIC) ](https://ripe92.ripe.net/programme/meeting-plan/sessions/65/TDYAZY/)gave an update on [ASPA](https://fastnetmon.com/2026/02/25/aspa-the-next-layer-of-routing-security/) and why it remains in draft despite being close to feature-complete. The focus was on deployment friction: integrating AS path validation into real-world routing policy systems, and the operational considerations that slow adoption more than the protocol itself. ## Working groups, policy, and operational updates Beyond security topics, the usual RIPE working group structure was there: address policy, routing, DNS, operational updates, and the steady flow of operator input that keeps the system aligned. It’s still one of the few places where protocol designers, registry people, and day-to-day network operators are in the same room debating about how things should work. ## RIPE 92 socials: The Dome, Dynamic Earth, and Edinburgh after-hours The main social was on Tuesday at The Dome of Edinburgh. A Category A listed building from 1847, originally the Commercial Bank of Scotland headquarters, with a heavy Graeco-Roman frontage and a domed interior that does most of the visual work. Good space for a few casual drinks and chats before turning it into a dancefloor. The Thursday dinner took place at Dynamic Earth, Edinburgh, at the base of Salisbury Crags. A modern contrast — glass-and-steel science centre built around geological history. We didn’t make it into the exhibition, but the venue itself was strong enough to carry the evening. Between organised events, the usual RIPE pattern filled the gaps: informal catch-ups across Edinburgh pubs, continuing off-agenda, and the standard mix of reconnecting with people you only see a few times a year. And with a packed week, the FastNetMon delegation once again missed the famous whisky BoF, second time running. ## Thank you, RIPE NCC & Edinburgh! As the event closes, we want to thank the RIPE NCC team for running RIPE 92 smoothly and keeping everything on track throughout the week. It was a productive and pleasant RIPE meeting overall, with plenty of useful conversations and familiar faces. Looking forward to seeing everyone again at RIPE 93 in Sofia. **Categories:** Events, FastNetMon Blog --- ### [ITW 2026 - Event Recap](https://fastnetmon.com/2026/05/22/see-you-at-itw-2026/) **Published:** May 22, 2026 **Author:** FastNetMon **Content:** ITW is always one of those events where the telecom industry compresses months of conversations into a few very busy days. This week, Virgil Truica represented FastNetMon at International Telecoms Week 2026 in National Harbor, meeting with carriers, telecom operators, infrastructure providers, hosting companies, IXPs, and long-time industry partners from around the world. ![Virgil Truica from FastNetMon - 'Welcome to ITW 2026'](https://fastnetmon.com/wp-content/uploads/2026/04/signal-2026-05-18-090200.jpeg)What makes ITW different is the density of the people attending. You are not walking around collecting random leads. Most conversations are directly with decision-makers responsible for international connectivity, peering relationships, transport capacity, infrastructure expansion, and commercial partnerships across global telecom networks. For us, that means real discussions about network visibility, DDoS mitigation, operational reliability, and protecting critical infrastructure from increasingly large-scale attacks. This year, one topic kept surfacing repeatedly across conversations: the continued growth of massive IoT-driven botnets and the operational pressure caused by increasingly large volumetric attacks. Telecom operators and infrastructure providers are seeing attack traffic volumes continue to rise, while expectations for uptime and resilience remain uncompromising. ![](https://fastnetmon.com/wp-content/uploads/2026/04/ITW2026-event-recap-FastNetMon.png)One thing remains consistent across the industry: operators want better visibility and faster response times without adding operational complexity. That is exactly the problem FastNetMon was built to solve. ITW also gave us a chance to reconnect with existing customers and partners we have worked with for years. Events like this are still one of the best reminders that the internet industry is ultimately built on long-term relationships and trust. ![](https://fastnetmon.com/wp-content/uploads/2026/04/FastNetMon-at-ITW-2026-event-recap-1024x576.jpeg)We also had the opportunity to meet new providers and infrastructure teams exploring ways to improve their DDoS detection and mitigation workflows as attacks continue to grow in scale and sophistication. There is always value in hearing directly from the companies operating large-scale telecom and connectivity infrastructure every day. Those conversations help shape both our roadmap and the way we think about operational simplicity, scalability, and deployment flexibility. ![](https://fastnetmon.com/wp-content/uploads/2026/04/ITW2026-event-recap-with-FastNetMon.png)Beyond meetings and discussions, Virgil Truica also took part in the TSF Charity Run organised during International Telecoms Week 2026. The annual 5K run supports Friends of Telecom Without Borders and helps raise funds for emergency telecommunications services for people affected by crises and disasters around the world. It was great to see the telecoms community come together for a good cause outside the meeting rooms and conference halls. ![](https://fastnetmon.com/wp-content/uploads/2026/04/ITW2026-TSF-Charity-Run-FastNetMon.png)Thanks to everyone who met with us during the week. It was great to see familiar faces, make new connections, and spend a few days talking networks and infrastructure with the global telecoms community. See you at the next event! **Categories:** Events, FastNetMon Blog, Featured --- ### [RIPE SEE 14 - Event Recap](https://fastnetmon.com/2026/04/23/see-you-at-ripe-see-14/) **Published:** April 23, 2026 **Author:** FastNetMon **Content:** We just visited the RIPE SEE regional meeting in Belgrade, Serbia, now organised for the 14th time. More than 200 attendees from across the South East Europe Internet community gathered for two days of technical discussions, operational knowledge sharing and regional networking. Held on 21–22 April 2026 at the Crowne Plaza Belgrade, the event continued the RIPE tradition of regional meetings that help connect operators, engineers, policymakers and Internet organisations through open collaboration and knowledge sharing. Here's our recap of the event and what stood out. ## What is SEE? [SEE](https://www.ripe.net/meetings/regional-meetings/see/) is the RIPE regional meeting for South East Europe. It brings the RIPE community closer to local operators and organisations, creating a forum to discuss regional infrastructure priorities, routing security, resilience and Internet growth. These meetings are especially valuable because they connect engineers working on real operational challenges and help strengthen relationships across networks, IXPs, regulators and service providers. ## Key themes from SEE 14 ![](https://fastnetmon.com/wp-content/uploads/2026/04/RIPE-SEE-14-Belgrade-Serbia-FastNetMon-Event-Recap-1024x576.png)This year’s programme covered a broad range of topics relevant to network operators and infrastructure teams. Routing security and protocol development featured strongly, with sessions on Segment Routing for IPv6 (SRv6), Autonomous System Provider Authorisation ([ASPA](https://fastnetmon.com/2026/02/25/aspa-the-next-layer-of-routing-security/)), RPKI Route Origin Validation (ROV), BMP and BGP maximum-prefix controls. Attendees also heard updates from the RIPE NCC and RIPE community, alongside operational talks covering: - DNS measurement and DNS4EU analysis using RIPE Atlas - Data centre power usage effectiveness (PUE) and AI workload impact - DNS software security research - WHOIS and legacy protocol discussions - Satellite and terrestrial network integration - Regional IXP traffic patterns and expansion initiatives - Telemetry and LAN automation - Data centre operations and recursive DNS services Lightning talks added practical insights from engineers working directly on infrastructure, documentation and automation projects across the region. ## Strong regional support SEE 14 was made possible with the support of the local hosts: - Serbian Open eXchange - Serbian National Internet Domain Registry (RNIDS) - RATEL – Regulatory Authority for Electronic Communications and Postal Services Their collaboration helped deliver another successful gathering for the South East Europe Internet community. ## Looking ahead Our next RIPE event will be the main [RIPE Meeting in Edinburgh, Scotland](https://fastnetmon.com/2026/04/06/see-you-at-ripe-92/), where the wider community will gather again to discuss the future of Internet operations and infrastructure. We also look forward to attending more regional meetings like SEE. South East Europe remains one of the most vibrant parts of the community, with strong engineering expertise, practical operational insight and valuable knowledge sharing. **Categories:** Events, FastNetMon Blog --- ### [MAP-T in 2026: Stateless IPv4-over-IPv6 translation and what operators debate in production networks](https://fastnetmon.com/2026/05/06/map-t-in-2026-stateless-ipv4-over-ipv6-translation-and-what-operators-actually-debate-in-production-networks/) **Published:** May 6, 2026 **Author:** FastNetMon **Content:** As we move through 2026, IPv6 adoption continues to increase steadily across service provider networks, enterprise backbones, and mobile infrastructures. However, IPv4 is still far from disappearing in practice. A large portion of global internet traffic, applications, and legacy services continues to rely on IPv4 connectivity, which means operators must still maintain mechanisms to bridge IPv4 and IPv6 environments. This has led to continued interest in transition technologies that allow operators to simplify their core networks while still supporting IPv4 access. One of these mechanisms is MAP-T (Mapping of Address and Port using Translation), which is designed to support IPv4 connectivity over an IPv6-only infrastructure without requiring per-connection state in the core. In this article, we will first take a closer look at how MAP-T actually works in practical terms. After that, we will shift the focus to something more relevant to 2026 operator discussions: how MAP-T behaves in real deployments, what trade-offs engineers report, and why many of the interesting questions are operational rather than protocol-level. ## Understanding MAP-T: how IPv4 works over an IPv6-only core MAP-T, defined in RFC 7599, is a stateless mechanism for transporting IPv4 traffic across an IPv6-only network using deterministic translation rules. At a high level, MAP-T exists to solve a specific problem: how to allow IPv4 communication to continue working when the provider network itself has removed IPv4 from its internal infrastructure. Instead of maintaining large state tables like Carrier-Grade NAT systems, MAP-T relies on a pre-defined mapping function. This function allows both the customer-side device and the provider-side gateway to independently calculate how IPv4 addresses and port ranges correspond to IPv6 addressing. ### The key idea: shared IPv4 + port partitioning In a typical MAP-T deployment, multiple customers share a single IPv4 address. What distinguishes one customer from another is not the IPv4 address itself, but the range of ports assigned to them. Each subscriber is given: - a shared IPv4 address - a specific subset of transport-layer ports, defined by a Port Set ID (PSID) This means that IPv4 addressing becomes less about unique addresses and more about structured sharing of both address and port space. These parameters are then embedded into the IPv6 address structure using what are known as Embedded Address (EA) bits. This embedding allows the network to carry enough information within IPv6 packets to reconstruct the original IPv4 context when needed. A simplified way to think about this mapping is: ``` IPv6 address = IPv6 prefix + embedded IPv4 + port-set identifier + interface identifier ``` This is not a literal packet format, but it is a useful conceptual model for understanding how MAP-T preserves IPv4 semantics inside an IPv6-native environment. ### The role of Customer Edge and Border Relay MAP-T deployments are typically built around two functional components. The first is the Customer Edge (CE), which is usually the subscriber’s home or enterprise router. The CE is responsible for applying local translation rules and ensuring that outgoing traffic conforms to the assigned IPv4 address and port range. The second is the Border Relay (BR), which sits at the edge of the service provider network. The BR is responsible for translating traffic between the IPv6-only core and the external IPv4 Internet. Because both sides use the same deterministic mapping rules, the system does not require per-session state. Instead, it relies entirely on address structure and rule consistency. ### Packet flow in practice When a device sends traffic, the Customer Edge first translates private IPv4 traffic into the assigned shared IPv4 space using NAT44. After this step, the packet is translated into IPv6 using MAP-T rules and forwarded into the provider’s IPv6-only core network. Within the core, the traffic is treated as native IPv6 and does not require any IPv4 routing capability. When return traffic arrives, the Border Relay uses the destination IPv4 address and port combination to determine which subscriber the traffic belongs to. It then applies the same mapping logic in reverse, reconstructing the correct IPv6 destination and forwarding the packet to the appropriate Customer Edge device. The important property here is determinism: both sides independently arrive at the same mapping decision without exchanging state information. ## What operators actually talk about in 2026 MAP-T deployments While the mechanism itself is relatively straightforward, most operator discussions in 2026 are not focused on the protocol design. Instead, they revolve around operational trade-offs, deployment constraints, and real-world behaviour under scale. In practice, MAP-T is less of a theoretical design discussion and more of a “how does this behave in my environment” topic. ### 1. Stateless forwarding vs operational state reality One of the first clarifications that often appears in operator conversations is that “stateless” refers only to packet forwarding behaviour in the core network. In reality, operators still maintain a significant operational state, including: - Port Set ID allocations per subscriber - Mapping rule consistency across provisioning systems - Coordination between DHCP, BNG, and translation systems - Troubleshooting metadata for support and engineering teams This leads to a subtle but important distinction that is frequently discussed in ISP engineering groups: MAP-T removes per-flow state from the forwarding plane, but it does not remove the need for structured state in the operational and provisioning layers. In other words, the network becomes simpler in one dimension, but more structured in another. ### 2. Port allocation becomes a design constraint, not just a detail In operator discussions, port allocation is one of the most practical constraints in MAP-T design. Because each subscriber receives only a subset of the available port space, operators must carefully balance: - IPv4 address efficiency - expected user behaviour - application requirements - support overhead In real deployments, issues rarely come from steady-state traffic. Instead, they tend to emerge from burst behaviour, where a user temporarily exceeds expected connection patterns. This leads to a recurring engineering question in operator forums: > How aggressively can we share IPv4 addresses before port constraints become visible to end users? MAP-T does not remove this constraint; it makes it explicit and structurally enforced. ### 3. Customer equipment remains a persistent operational limitation Another consistent theme in 2026 deployment discussions is customer-premises equipment compatibility. Even though MAP-T is conceptually clean in the core network, it requires correct implementation at the edge device. In practice, operators frequently encounter challenges such as: - inconsistent vendor support across router firmware versions - limited availability of MAP-T-capable consumer devices - difficulties supporting customer-owned hardware - operational overhead in managing firmware fragmentation As a result, MAP-T deployments tend to work best in environments where operators control the customer edge device, or where equipment is tightly standardised. This is one of the reasons MAP-T is not universally deployed, even when it is architecturally attractive. ### 4. MAP-T vs MAP-E: an ongoing operational preference debate Although MAP-T and MAP-E are closely related in design, operators often prefer one over the other based on operational experience rather than theoretical efficiency. MAP-T is typically described as more “native” to IPv6 networks, since it avoids encapsulation and operates through translation alone. However, this also means that packet reconstruction and debugging require deeper awareness of mapping rules. MAP-E, by contrast, uses encapsulation, which some operators find easier to troubleshoot because IPv4 packets remain intact inside IPv6 transport. A common summary from engineering discussions is: MAP-T tends to be preferred for architectural cleanliness, while MAP-E is often preferred for operational simplicity. ### 5. Observability is more complex than the stateless model suggests One of the more subtle findings from operator discussions in 2026 is that stateless forwarding does not automatically translate into simpler observability. Because IPv4 headers are translated and partially embedded into IPv6 structure, troubleshooting often requires: - access to mapping rule definitions - correlation between IPv4 and IPv6 address spaces - understanding of Port Set ID allocation logic This means that packet-level debugging can be less intuitive than in either pure IPv4 or dual-stack environments. To address this, operators often implement additional tooling around MAP-T deployments, including enhanced telemetry at Border Relays and internal systems that reconstruct subscriber identity from flow data. ### 6. MAP-T is typically a later-stage transition mechanism In most 2026 deployments, MAP-T is not the first step in IPv6 transition strategy. Instead, operators typically progress through stages such as dual-stack deployment, CGNAT introduction, and gradual exploration of IPv6-only core designs using different transition technologies. MAP-T is usually considered when operators are explicitly trying to reduce IPv4 dependency in the core while maintaining deterministic control over address sharing and port allocation. This positions MAP-T as a refinement stage rather than an initial adoption tool. ## Final thoughts MAP-T is best understood not simply as a translation mechanism, but as part of a broader operational shift in 2026 network design. It replaces per-flow state with deterministic mapping rules, enabling IPv6-only core architectures while preserving IPv4 connectivity. However, the real-world experience of MAP-T is shaped less by its protocol design and more by operational realities: port allocation strategy, customer equipment constraints, observability requirements, and the complexity of large-scale ISP environments. In that sense, MAP-T does not eliminate complexity — it redistributes it. And in 2026 operator discussions, that redistribution is exactly where the most interesting engineering debates continue to happen. **Categories:** FastNetMon Blog, Featured **Tags:** IPv6, Network Security Insights --- ### [FastNetMon Advanced 2.0.379](https://fastnetmon.com/2026/05/21/fastnetmon-advanced-2-0-379/) **Published:** May 21, 2026 **Author:** FastNetMon **Content:** **Release date:** 31 May, 2026 **Version:** 2.0.379 FastNetMon Advanced 2.0.379 introduces a major rewrite of IPv4 and IPv6 network loading and lookup logic, improving scalability, concurrency, and memory management for large-scale deployments. The release also enhances traffic\_db with fully asynchronous ClickHouse inserts to prevent packet drops on busy systems, alongside new Prometheus monitoring support and expanded observability options. In addition, the release adds advanced network-level mitigation controls, including BGP-based network learning, live network reloads, improved Flow Spec matching, IPv6 allow lists, and expanded per-network blocking options. Support for additional IPFIX fields and multiple traffic processing improvements further extend packet visibility and detection capabilities. ### Full list of changes - Added support for parsing IPFIX\_IP\_TTL, IPFIX\_ICMP\_TYPE\_IPV4, IPFIX\_ICMP\_CODE\_IPV4, IPFIX\_TCP\_WINDOW\_SIZE, IPFIX\_TCP\_ACKNOWLEDGEMENT\_NUMBER, IPFIX\_TCP\_SEQUENCE\_NUMBER in IPFIX mode - Rename mbit to Mbit in flexible hostgroups schema - Rename mbits to Mbits in hostgroup section - Fixed Mbits from pps for TCP SYN pps and IP Fragmented packets per second - Made logic of Clickhouse insert fully async in traffic\_db. It ensures that we keep receiving new packets while another thread is working on Clickhouse inserts. It addresses drops of traffic in traffic\_db on loaded instances - Added support for Prometheous for traffic\_db, can be configured via /etc/fastnetmon/traffic\_db.conf options prometheus, prometheus\_host, prometheus\_port - Unified Promethtous logic to work for multiple instances - Added logic to trace duration of Clickhouse insert - Added logging\_level to traffic\_db daemon which can be set to info by default or debug - Added logic to load networks list from BGP when load\_networks\_from\_bgp is enabled and subnet\_learning is enabled for peer - Added field load\_networks\_from\_bgp\_filter\_communities to filter only prefixes with defined community when load\_networks\_from\_bgp is enabled - Full rewrite of IPv4 and IPv6 loading logic - Reworked prefix normalization logic for IPv4 networks - Added test to confirm that Patricia does not have function to normalize prefix before storing, when we add 192.168.1.121/24 it stores it same way as 192.168.1.121/24 instead of 192.168.1.0/24 - Removed logic which sorted networks from largest to smallest, we definitely do not need it anymore and it's overhead - Added command sudo fcli set reload\_networks to live reload networks - New logic to introduce concurrent access to IPv4 and IPv6 lookup trees - No more manual memory management for network lookups - Reworked Patricia tree for whitelist of IPv6 traffic to standard lookup logic - Reworked Patricia tree for IPv4 traffic to standard lookup logic - Added logic to run callback script when network is under attack with notify\_script\_network\_enabled notify\_script\_network\_path - Added logic to check banned networks - sudo fcli show network\_block and block / unblock them - Added option for networks unban\_network\_only\_if\_attack\_finished - Implemented /etc/fastnetmon/allow\_list\_rules.dat for IPv6 - Added logic to match flow spec rules on non /128 boundaries - Added configuration option to enable / disable per network blocks fpr all protocols: enable\_ban\_network - Added logic to load hostgroup with network level configuration: global\_network\_ipv4 and calculaion\_method = network\_ipv4 - added new configuration options: enable\_ban\_network\_ipv4, enable\_ban\_network\_ipv6, ban\_time\_network\_ipv4, ban\_time\_network\_ipv6, unban\_network\_enabled\_ipv4, unban\_network\_enabled\_ipv6 - Implemented logic for disable\_local\_host\_counters\_ipv4 and disable\_local\_host\_counters\_ipv6 to selectively disable host counters - Added options disable\_local\_host\_counters\_ipv4 and disable\_local\_host\_counters\_ipv6 [FastNetMon Advanced documentation](https://fastnetmon.com/docs-fnm-advanced/) [View this release on GitHub](https://github.com/FastNetMon/fastnetmon-advanced-releases/releases/tag/v2.0.379) **Categories:** Releases --- ### [Datacenter Forum 2026 - Event Recap](https://fastnetmon.com/2026/05/11/see-you-at-datacenter-world-2026/) **Published:** May 11, 2026 **Author:** FastNetMon **Content:** Last week FastNetMon attended DataCenter Forum Romania 2026 in Bucharest. Representing our team at the event was Virgil Truica, FastNetMon’s Head of Sales, who spent the day meeting with infrastructure operators, hosting providers, cloud teams, and data centre professionals from across the region. Now in its 8th edition, the event has clearly become one of the key meeting points for the data centre and cloud infrastructure community in Eastern Europe. This year’s discussions heavily focused on AI infrastructure, high-performance computing, cloud growth, and the operational challenges that come with scaling modern infrastructure. One of the recurring themes throughout the conference was how quickly AI is changing infrastructure requirements. Several sessions explored AI-ready data centres, GPU-heavy workloads, and the growing pressure these environments place on power, cooling, connectivity, and network resilience. There were also interesting discussions around Romania’s AI Factory initiatives and the region’s growing investment in HPC infrastructure. Beyond the AI discussions, the agenda covered a broad mix of topics, including cloud scalability, connectivity, sustainability, operational resilience, and cybersecurity. For us, it was especially interesting to hear how operators are thinking about visibility and resilience as networks continue to grow in scale and complexity. Virgil had many good conversations during the event around DDoS protection, traffic visibility, and the challenges providers face when trying to maintain reliable services in increasingly demanding environments. These are exactly the kinds of discussions we value most at industry events — practical conversations with the people operating real-world infrastructure every day. Thank you to the organisers and everyone who stopped by to connect with our team during the conference. We’re looking forward to continuing the conversations. **Categories:** Events **Tags:** events --- ### [Ubuntu and Canonical services disrupted by a DDoS attack](https://fastnetmon.com/2026/05/04/ubuntu-and-canonical-services-disrupted-by-ddos-attack/) **Published:** May 4, 2026 **Author:** FastNetMon **Content:** Ubuntu users experienced widespread service disruptions last week after a sustained DDoS attack targeted infrastructure operated by [Canonical](https://canonical.com/), impacting critical systems, including package updates and security-related services. According to public statements, the attack began on Thursday, May 1, with Canonical confirming that its “web infrastructure \[was\] under a sustained, cross-border attack.” The disruption affected multiple Ubuntu and Canonical web properties, as well as backend systems relied upon by users and developers. ### **Update failures and API disruption** Reports from the Ubuntu community indicated that the attack impacted the Ubuntu security API and package distribution infrastructure. This had a direct operational impact: users were unable to install updates or retrieve packages from repositories. Independent verification confirmed that update processes failed on active Ubuntu systems during the incident window. Given Ubuntu’s role as one of the most widely deployed Linux distributions globally, even short-lived disruptions to its update mechanisms can have cascading effects across enterprise environments, cloud workloads, and CI/CD pipelines. ### **Attack attribution and methods** A hacktivist group identifying itself as *The Islamic Cyber Resistance in Iraq 313 Team* claimed responsibility for the attack via Telegram. The group stated it leveraged a DDoS-for-hire platform known as Beamed. [Booter (or “stresser”) services](https://fastnetmon.com/2025/04/10/ddos-booters-and-ip-stressers-explained-by-experts/) like Beamed significantly lower the barrier to entry for launching large-scale DDoS attacks. These platforms offer on-demand traffic flooding capabilities, often advertising attack bandwidth in the multi-terabit-per-second range. In this case, the service reportedly supports attacks exceeding 3.5 Tbps. ### **Current status** As of today, Monday, May 4, all affected services appear to have recovered. According to [Canonical Status Page](https://status.canonical.com/), all systems are operational, indicating that Canonical has successfully mitigated the attack and restored service availability. **Categories:** FastNetMon Blog **Tags:** DDoS Attacks, DDoS News --- ### [Network Engineering Community News: April 2026](https://fastnetmon.com/2026/04/30/network-engineering-community-news-april-2026/) **Published:** April 30, 2026 **Author:** FastNetMon **Content:** # Welcome to our Network Engineering Community News! Hi from FastNetMon! March brought plenty to share. We released two new FastNetMon Advanced versions, added Debian 13 support and Bison router integration, welcomed a new senior engineering contributor to the team, and covered key updates and industry events. Happy reading! Want this letter straight to your inbox? Sign up to our monthly Network Engineering Community News [here](https://cdn.forms-content.sg-form.com/b3c8181d-c30d-11ef-b203-ca12671f70d2). --- ## FastNetMon LiveView is here [ ![Introducing FastNetMon LiveView](https://eoolnbw.stripocdn.email/content/guids/CABINET_0e3d38ac7aa097f7347943a9336c1ae98aa32a170859302567fcdd604693850c/images/introducing_fastnetmon_liveview.gif) ](https://fastnetmon.com/2026/04/29/introducing-fastnetmon-liveview/) The wait is over: one of the most requested FastNetMon product upgrades has arrived! FastNetMon LiveView brings real-time traffic visibility, DDoS monitoring, and configuration into a single, intuitive web interface. See what’s happening across your network instantly, investigate attacks faster, and manage settings more easily through a browser-based interface. Available as an add-on for FastNetMon Advanced. [ EXPLORE LIVEVIEW ](https://fastnetmon.com/2026/04/29/introducing-fastnetmon-liveview/) ## Additional product updates This month, we’ve released FastNetMon Advanced versions **[2.0.376](https://fastnetmon.com/2026/04/07/fastnetmon-advanced-2-0-376/)**, **[2.0.377](https://fastnetmon.com/2026/04/17/fastnetmon-advanced-2-0-377/)**, and **[2.0.378](https://fastnetmon.com/2026/04/27/fastnetmon-advanced-2-0-378/)**, alongside a **[new integration with PagerDuty](https://fastnetmon.com/2026/04/01/fastnetmon-advanced-now-supports-pagerduty-integration/)** to improve our alerting capabilities. The latest version updates bring improvements in BGP performance and stability, enhanced IPv6 traffic visibility, stronger ClickHouse integrations, and broader flow processing and analytics capabilities, along with some bug fixes. --- ## The Strait of Hormuz & beyond: when cables, conflict and connectivity collide [ ![The connectivity at Hormuz Strait and beyond](https://eoolnbw.stripocdn.email/content/guids/CABINET_0e3d38ac7aa097f7347943a9336c1ae98aa32a170859302567fcdd604693850c/images/network_security_insights_the_connectivity_at_hormuz_strait_and_beyond.png) ](https://fastnetmon.com/2026/04/10/the-strait-of-hormuz-beyond-tracking-data-routes-across-the-gulf/) This month, we’ve published a deep-dive into one of the most interesting parts of global internet infrastructure — and it’s especially relevant right now: the Strait of Hormuz and the wider Gulf region. It’s a look at how dense subsea cable routes, stalled mega-projects, and emerging land corridors all interact in a high-stakes environment where geography still very much dictates how the internet flows. [ READ THE ARTICLE ](https://fastnetmon.com/2026/04/10/the-strait-of-hormuz-beyond-tracking-data-routes-across-the-gulf/) --- ## Real-time DDoS visibility at the edge: Pentanet case study [ ![Pentanet case study](https://eoolnbw.stripocdn.email/content/guids/CABINET_0e3d38ac7aa097f7347943a9336c1ae98aa32a170859302567fcdd604693850c/images/case_pentanet.png) ](https://fastnetmon.com/2026/04/06/case-pentanet-real-time-ddos-detection-at-the-edge/) We’ve published a new case study with Australian ISP Pentanet on how they use FastNetMon for real-time DDoS detection at the edge. With sFlow visibility and tailored thresholds across their services, they’ve built a setup that fits their network well. FastNetMon also enables automated BGP RTBH mitigation, with alerts into Slack and PagerDuty for fast operational response. [ READ THE CASE ](https://fastnetmon.com/2026/04/06/case-pentanet-real-time-ddos-detection-at-the-edge/) --- ## RIPE SEE 14 - highlights from Belgrade [ ![RIPE SEE 14 Belgrade event recap](https://eoolnbw.stripocdn.email/content/guids/CABINET_0e3d38ac7aa097f7347943a9336c1ae98aa32a170859302567fcdd604693850c/images/ripe_see_14_belgrade_serbia_fastnetmon_event_recap.png) ](https://fastnetmon.com/2026/04/23/see-you-at-ripe-see-14/) We attended RIPE SEE 14 in Belgrade, where more than 200 network operators, engineers and Internet stakeholders from across South East Europe came together. [ SEE HIGHLIGHTS ](https://fastnetmon.com/2026/04/23/see-you-at-ripe-see-14/) --- ## Industry news & insights April saw a number of significant DDoS developments and high-profile incidents. Here are the key highlights. Happy reading! [ ![Bluesky hit by DDoS attack](https://eoolnbw.stripocdn.email/content/guids/CABINET_0e3d38ac7aa097f7347943a9336c1ae98aa32a170859302567fcdd604693850c/images/bluesky_social_media_company_hit_by_a_ddos_attack_causing_widespread_app_outages.png) ](https://fastnetmon.com/2026/04/20/bluesky-hit-by-prolonged-ddos-attack-causing-widespread-outages/) **Bluesky hit by prolonged DDoS attack causing widespread outages** across feeds, notifications, threads, search functions and profile access. Read the story [here](https://fastnetmon.com/2026/04/20/bluesky-hit-by-prolonged-ddos-attack-causing-widespread-outages/). [ ![Mastodon hit by DDoS attack](https://eoolnbw.stripocdn.email/content/guids/CABINET_0e3d38ac7aa097f7347943a9336c1ae98aa32a170859302567fcdd604693850c/images/mastodonsocial_social_media_hit_by_a_ddos_attack.png) ](https://fastnetmon.com/2026/04/21/mastodon-says-flagship-mastodon-social-server-hit-by-ddos-attack/) **Mastodon flagship mastodon.social server was hit by DDoS attack** causing intermittent outages; only days after the Bluesky attack. Read more [here](https://fastnetmon.com/2026/04/21/mastodon-says-flagship-mastodon-social-server-hit-by-ddos-attack/). [ ![Operation PowerOFF targets DDoS-for-hire ecosystem](https://eoolnbw.stripocdn.email/content/guids/CABINET_0e3d38ac7aa097f7347943a9336c1ae98aa32a170859302567fcdd604693850c/images/significant_ddos_disruption_affects_russian_state_telecom_rostelecom_1.png) ](https://fastnetmon.com/2026/04/16/europol-backed-operation-poweroff-targets-ddos-for-hire-ecosystem-contacts-75000-users/) **Law-enforcement Operation PowerOFF contacts 75,000+ botnet customers** in a large-scale action against the DDoS-for-hire ecosystem. Read more [here](https://fastnetmon.com/2026/04/16/europol-backed-operation-poweroff-targets-ddos-for-hire-ecosystem-contacts-75000-users/). [ ![Alleged DDoS-for-hire operator behind Fluxstress arrested](https://eoolnbw.stripocdn.email/content/guids/CABINET_0e3d38ac7aa097f7347943a9336c1ae98aa32a170859302567fcdd604693850c/images/ddosforhire_fluxtress_operator_arrested_in_thailand.png) ](https://fastnetmon.com/2026/04/14/alleged-ddos-for-hire-operator-behind-fluxstress-arrested-in-thailand/) **Alleged DDoS-for-hire operator behind Fluxstress arrested** in Thailand, following a multi-year international investigation involving INTERPOL. Read the story [here](https://fastnetmon.com/2026/04/14/alleged-ddos-for-hire-operator-behind-fluxstress-arrested-in-thailand/). --- ## 💌 Get this newsletter straight to your inbox Sign up to our monthly Network Engineering Community News [here](https://cdn.forms-content.sg-form.com/b3c8181d-c30d-11ef-b203-ca12671f70d2) **Categories:** Newsletter --- ### [Introducing FastNetMon LiveView](https://fastnetmon.com/2026/04/29/introducing-fastnetmon-liveview/) **Published:** April 29, 2026 **Author:** FastNetMon **Content:** ### Real-time visibility, DDoS analysis, and control in one interface We’re introducing **FastNetMon LiveView**, the official web interface add-on for FastNetMon. LiveView brings real-time traffic analytics, DDoS visibility, reporting, and configuration management into a single browser-based interface. It is designed to give network operators and security teams immediate insight into what is happening on their infrastructure. ### From signal to insight, faster FastNetMon has always focused on high-performance network telemetry ingestion and real-time DDoS detection. However, as environments grow more complex, operators need a clearer and faster way to observe what the system is seeing. LiveView addresses this by providing a unified view of: - Real-time traffic metrics across networks, hosts, and ASNs - Top talkers and traffic breakdowns - Active and historical DDoS events - System configuration and operational settings Instead of switching between tools or parsing logs, operators can now see and act on this information directly in the web interface. ### Real-time traffic visibility ![](https://fastnetmon.com/wp-content/uploads/2026/04/FastNetMon-LiveView-network-traffic-visibility-interfaces.png)LiveView provides continuously updated dashboards for network traffic analysis. Key views include: - Total traffic overview - Network traffic reports - Host-level traffic visibility - ASN-level traffic analysis - Top networks, hosts tables and graphs This makes it easier to understand traffic patterns, spot anomalies, and validate expected behaviour in real time. ### DDoS visibility and historical context LiveView gives direct access to both active and past DDoS events. This allows teams to: - Review ongoing attacks as they unfold - Analyse historical attack patterns - Improve incident response and post-event investigation - Maintain operational awareness over time ### Simplified configuration and operations ![Close-up of a dark network dashboard showing Flow Spec settings with toggle switches labeled 'BGP Flowspec IPv4 mitigation mode' and related options, on a tilted UI layout with a FastNetMon logo in the corner.](https://fastnetmon.com/wp-content/uploads/2026/04/FastNetMon-LiveView-configuring-Dashboards-for-DDoS-detection-and-mitigation-1024x576.png)Beyond monitoring, LiveView also introduces web-based management for FastNetMon configuration. Operators can manage: - Detection thresholds - Notifications - Mitigation actions - User access - Operational settings This reduces dependency on manual configuration workflows and makes day-to-day operations more accessible across teams. ### Built for shared visibility LiveView is designed for more than just engineers. Dashboards and reports can be easily shared across teams, including operations, security, and management stakeholders. This helps improve communication during incidents and provides a shared understanding of network behaviour. ![](https://fastnetmon.com/wp-content/uploads/2026/04/FastNetMon-LiveView-works-on-mobile-1024x676.png)### Availability FastNetMon LiveView is available as a **paid add-on** for the FastNetMon platform. Pricing: - $70 per user/month - $720 per user/year (annual billing, discounted) LiveView can be purchased [together with a FastNetMon licence](https://fastnetmon.com/pricing/), or added later to an existing subscription on [your account](https://fastnetmon.chargebee.com/portal/v2/login?forward=home). Read more about installation [in our documentation](https://fastnetmon.com/docs-fnm-advanced/web-user-interface-for-fastnetmon-advanced/). **Categories:** FastNetMon Blog, Featured, Press & Newsroom --- ### [FastNetMon Advanced 2.0.378](https://fastnetmon.com/2026/04/27/fastnetmon-advanced-2-0-378/) **Published:** April 27, 2026 **Author:** FastNetMon **Content:** **Release date:** 27 April, 2026 **Version:** 2.0.378 FastNetMon Advanced 2.0.378 improves flexible counters by fixing a minor degradation issue in the underlying fcli component. The release also enhances BGP processing with up to 2x faster table loading, additional profiling, and expanded support for standard BGP attributes. ClickHouse integrations have been strengthened with TLS connectivity, improved cloud compatibility, and reliability updates for metrics storage. In addition, new traffic database fields have been introduced to extend packet metadata collection. ### Full list of changes - Added logic to efficiently check if remote table already exists in Clickhouse for metrics - Added logic to catch exceptions in create\_clickhouse\_database\_for\_metrics - Enabled logic set\_enable\_only\_binary for bgp\_announces\_incoming to improve table load time 2 times - Eliminated not needed data copy with api::Path my\_path - Added time profiling for BGP table loading code in bgp\_announces\_incoming - Added custom thread name for GetIncomingAnnounces to see it in htop - Added BGP\_ATTRIBUTE\_ORIGINATOR\_ID type 9 and BGP\_ATTRIBUTE\_CLUSTER\_LIST type 10 BGP attributes - Upgraded fcli to fix critical bug in flexible counters - Added logic to connect to Clickhouse using TLS clickhouse\_metrics\_tls, clickhouse\_metrics\_disable\_certificate\_checks, clickhouse\_metrics\_tls\_ca\_paths, clickhouse\_metrics\_tls\_client\_auth, clickhouse\_metrics\_tls\_client\_certificate\_path, clickhouse\_metrics\_tls\_client\_certificate\_private\_key\_path - Added logic to ignore error Dictionary source of type file is disabled with Clickhouse Cloud - Upgraded Clickhouse 2.6.1 version - Breaking change for traffic\_db: traffic table now requires presence of srcMac and dstMac fileds which can be created that way: alter table fastnetmon.traffic ADD COLUMN srcMac FixedString(6); alter table fastnetmon.traffic ADD COLUMN dstMac FixedString(6); - New fields for UDP packets: l4\_payload\_pointer and l4\_payload\_length [FastNetMon Advanced documentation](https://fastnetmon.com/docs-fnm-advanced/) [View this release on GitHub](https://github.com/FastNetMon/fastnetmon-advanced-releases/releases/tag/v2.0.378) **Categories:** Releases **Tags:** releases --- ### [FastNetMon Advanced 2.0.377](https://fastnetmon.com/2026/04/17/fastnetmon-advanced-2-0-377/) **Published:** April 17, 2026 **Author:** FastNetMon **Content:** **Release date:** 17 April, 2026 **Version:** 2.0.377 FastNetMon Advanced 2.0.377 delivers a major refactor of the command line tool and API, making integrations more modern and maintainable. The release also improves IPv6 traffic visibility by fixing an issue that could prevent network traffic from being detected correctly. New operational controls have been added to give administrators more flexibility over traffic calculation and system permissions. In addition, several outdated configuration options have been deprecated or removed as part of ongoing efforts to simplify setup and reduce legacy complexity. ## Full list of changes - Full refactoring of fcli tool and API - Added new flag web\_api\_v2 to switch to new API endpoint path /api/v2 - Fixed bug for single\_network\_counters\_v6 which caused inability to find traffic for IPv6 network - Added ENV variable for FastNetMon daemon to suspend traffic calculation: FASTNETMON\_DO\_NOT\_CALCULATE\_SPEED - Added ENV variable for fcli to suppress root requirements: FASTNETMON\_SKIP\_ROOT\_TESTS, it need to be set to 1 or on - Deprecated tera\_flow\_ports and tera\_flow\_host. Please use tera\_flow\_local\_addresses instead - Removed flag influxdb\_push\_host\_ipv6\_counters, now per host IPv6 export in InfluxDB covered by influxdb\_skip\_host\_counters - Removed Influxdb\_push\_host\_ipv4\_flexible\_counters and Influxdb\_push\_host\_ipv6\_flexible\_counters as we never used them [FastNetMon Advanced documentation](https://fastnetmon.com/docs-fnm-advanced/) [View this release on GitHub](https://github.com/FastNetMon/fastnetmon-advanced-releases/releases/tag/v2.0.377) **Categories:** Releases --- ### [Mastodon says flagship mastodon.social server hit by DDoS attack](https://fastnetmon.com/2026/04/21/mastodon-says-flagship-mastodon-social-server-hit-by-ddos-attack/) **Published:** April 21, 2026 **Author:** FastNetMon **Content:** Mastodon says its primary public instance, mastodon.social, was targeted by a DDoS attack on 20 April 2026, causing intermittent outages and rendering the service inaccessible for some users. The incident follows the [recent prolonged DDoS attack against Bluesky](https://fastnetmon.com/2026/04/20/bluesky-hit-by-prolonged-ddos-attack-causing-widespread-outages/), another decentralised social network. [According to public updates](https://mastodon.social/@andypiper@macaw.social/116436859196010930), the incident was identified at around 7:00 a.m. ET, when Mastodon said it was investigating the attack. By 9:05 a.m. ET, the organisation said countermeasures had been deployed, and site access had been restored, while warning that instability could continue as the attack remained active. ## Service disruption limited to mastodon.social During the incident, users reported error messages and full-screen outage warnings when attempting to access mastodon.social. Mastodon later said the traffic pattern involved millions of malicious requests consistent with a DDoS attack. The company added that, so far, only mastodon.social had been targeted. This distinction is important because Mastodon operates as a federated network of independent servers rather than a single centralised platform. While the flagship instance experienced disruption, other Mastodon servers and compatible Fediverse services remained operational. ## Access restored while the wider network remained unaffected Mastodon said countermeasures restored access to mastodon.social within a couple of hours of the attack starting, although some instability could continue while mitigation efforts remained in place. The disruption was limited to mastodon.social. Other Mastodon instances and compatible Fediverse services remained operational, allowing users outside the affected server to continue reading, posting and interacting normally. **Categories:** FastNetMon Blog --- ### [Bluesky hit by prolonged DDoS attack causing widespread outages](https://fastnetmon.com/2026/04/20/bluesky-hit-by-prolonged-ddos-attack-causing-widespread-outages/) **Published:** April 20, 2026 **Author:** FastNetMon **Content:** Bluesky has confirmed that a recent wave of outages affecting its app and website was caused by a sophisticated DDoS attack that disrupted several core platform services between 15 and 17 April 2026. According to public statements, service interruptions began on 15 April at around 8:40 p.m. ET and continued intermittently through 17 April as mitigation efforts remained in progress. The incident led to intermittent failures across feeds, notifications, threads, search functions and profile access, with users reporting repeated errors, slow loading times and temporary unavailability throughout the disruption window. ## Attack caused intermittent application-layer failures Bluesky said the attack intensified throughout the day, with intermittent disruption affecting feeds, notifications, threads and search. Users reported partial service availability alongside repeated application errors. Users could intermittently access the platform, while requests to feeds, profiles, threads and search frequently failed or timed out, suggesting congestion or protective controls somewhere in the application delivery path. Reports of “Rate Limit Exceeded” messages on popular feeds suggest temporary throttling controls were applied during mitigation. Intermittent availability is consistent with active traffic management, where some endpoints are prioritised while higher-load functions remain constrained. ## Status page also affected Bluesky’s own status page reportedly suffered intermittent issues during the event, reducing visibility for users trying to confirm whether the disruption was local or platform-wide. This can happen when status infrastructure shares dependencies with affected production systems, or when supporting services are indirectly impacted during a broader attack response. ## No evidence of a data breach Bluesky stated that it had not seen evidence of unauthorised access to private user data. While DDoS attacks are typically designed to impact availability rather than compromise confidentiality, prolonged disruption can still create significant operational and reputational damage. ## Infrastructure resilience under scrutiny The outage follows another recent disruption earlier in the month, prompting questions about resilience as Bluesky continues to grow. Public-facing social platforms are common DDoS targets due to their large user bases, highly exposed APIs and dependence on real-time service delivery. Bluesky said mitigation efforts were ongoing and that further updates would follow as engineers worked to restore full stability. **Categories:** FastNetMon Blog **Tags:** DDoS Attacks, DDoS News --- ### [Europol-backed Operation PowerOFF targets DDoS-for-hire ecosystem, contacts 75,000+ users](https://fastnetmon.com/2026/04/16/europol-backed-operation-poweroff-targets-ddos-for-hire-ecosystem-contacts-75000-users/) **Published:** April 16, 2026 **Author:** FastNetMon **Content:** A coordinated international law enforcement action supported by Europol has targeted the global DDoS-for-hire ecosystem, identifying more than 75,000 users involved in launching attacks. The operation, part of the ongoing Operation PowerOFF initiative, brought together authorities from 21 countries during a joint action week on 13 April 2026. [According to Europol](https://www.europol.europa.eu/media-press/newsroom/news/europol-supported-global-operation-targets-over-75-000-users-engaged-in-ddos-attacks), enforcement and prevention measures included over 75,000 warning messages sent to identified users, four arrests, 25 search warrants, and the takedown of 53 domains linked to booter services. ### Infrastructure disruption and data exploitation Ahead of the coordinated action, law enforcement agencies conducted a series of operational sprints targeting high-value users and infrastructure behind DDoS-for-hire platforms. [Booter services](https://fastnetmon.com/2025/04/10/ddos-booters-and-ip-stressers-explained-by-experts/), commercialised platforms that allow users to launch DDoS attacks against servers, websites, and networks, were the primary focus. Authorities seized backend infrastructure, including servers and databases, effectively disrupting service availability and degrading operational capacity. Analysis of seized datasets played a key role. Europol reports that data from these systems exposed more than 3 million user accounts associated with DDoS-for-hire services. This intelligence was shared across participating countries, enabling coordinated enforcement actions and user notifications at scale. ### Low barrier to entry continues to drive abuse DDoS-for-hire services remain one of the most accessible entry points into cybercrime. Platforms typically offer simplified interfaces and step-by-step workflows, allowing users with minimal technical expertise to launch attacks. At the same time, more advanced actors continue to customise attack parameters, optimise traffic generation, and target specific infrastructure. Europol notes that targets are often regionally aligned and include online services, telecommunications providers, and web-based platforms. Motivations vary widely, ranging from experimentation and curiosity to financial extortion, competitive disruption, and ideologically motivated activity. ### PowerOFF working to reduce DDoS-for-hire demand Operation PowerOFF is now moving further into its prevention phase, combining enforcement with proactive disruption tactics aimed at reducing demand. Measures highlighted by Europol include: - Removal of more than 100 URLs advertising DDoS-for-hire services from search engine results - Targeted advertising campaigns aimed at users searching for booter platforms - Blockchain-based warning messages directed at users transacting for DDoS services - Continued updates to public-facing resources tracking enforcement actions From an operational perspective, Europol provided analytical support, crypto-tracing, and forensic expertise, alongside coordinating intelligence sharing and hosting a central command post during the action phase. *Image credits: adapted from OSeveno, CC BY-SA 3.0 <https://creativecommons.org/licenses/by-sa/3.0>, via Wikimedia Commons* **Categories:** FastNetMon Blog **Tags:** DDoS News, legal --- ### [Installation and configuration of FastNetMon: simple on the surface, deeply configurable underneath](https://fastnetmon.com/2026/04/16/installation-and-configuration-of-fastnetmon-simple-on-the-surface-deeply-configurable-underneath/) **Published:** April 16, 2026 **Author:** FastNetMon **Content:** We often hear the same feedback from FastNetMon users: ![](https://fastnetmon.com/wp-content/uploads/2026/03/quote.png) > **It’s simple, it just works, and it does exactly what it’s supposed to do: detect DDoS attacks and launch mitigation actions.** That’s not by coincidence. It reflects a core philosophy we’ve followed from day one: build simple, functional tools for network operators that hold up in real-world conditions — day to day, year to year. But this perception of simplicity can sometimes hide an important detail. FastNetMon is simple to use, but it is anything but simple under the hood. Behind that simplicity is a set of over 300 configuration options, built to make FastNetMon adapt to the specific needs of your network. In this article, we’ll walk you through the journey of installing and configuring FastNetMon Advanced, and highlight some of its rich configuration options. In the end, you’ll have a clearer picture of what the product is capable of and how you can configure it best for your network. ## Fast to deploy, easy to start Getting FastNetMon up and running is very straightforward, and most operators can go from zero to a working setup in a few minutes. Before starting the installation, you’ll need to [request a trial license](https://fastnetmon.com/trial/). The process then comes down to preparing a supported environment – typically a standard Linux server (Ubuntu, Debian, or RHEL-based) with enough CPU and memory to handle your traffic. FastNetMon runs on both physical servers and virtual machines, including common cloud platforms. Installation is done by downloading and running a single script. It installs all required components and automatically retrieves and assigns a license to your server based on its hardware and IP address. You can read the full install guide [here](https://fastnetmon.com/docs-fnm-advanced/advanced-install-guide/). After this, you can move to the initial configuration. ## Setting up traffic capture After installation, the next step is to enable traffic capture so FastNetMon can start receiving and processing your network traffic. You begin by defining your network prefixes in CIDR format. This is required so FastNetMon understands which traffic belongs to your infrastructure and can correctly determine traffic direction. Without this, traffic classification will not work properly. ![](https://fastnetmon.com/wp-content/uploads/2026/04/FastNetMon-example-view-networks-configuration-1024x580.png)*Example view of networks configured for monitoring.* [*See documentation*](https://fastnetmon.com/docs-fnm-advanced/advanced-quick-start/) *how to add your networks.*Next, you select and enable your traffic source depending on your environment. FastNetMon supports several options, including [NetFlow](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-configuration-for-netflow-and-ipfix/), [sFlow](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-sflow-configuration/), [port mirroring](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-port-mirror-configuration/), vendor-specific mirror modes, and cloud flow logs. The right choice depends on your network equipment and how you export traffic data - you can refer to [this table](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-navigating-all-available-telemetry-protocols-for-different-vendors/) to find the best option. ![](https://fastnetmon.com/wp-content/uploads/2026/04/FastNetMon-example-view-SFlow-configuration-1024x576.png)*Example view of SFlow configuration. Find out what telemetry protocol is recommended for your platform in* [*this chart*](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-navigating-all-available-telemetry-protocols-for-different-vendors/)*.*Once configured, you can quickly verify that traffic is being received on the dashboards, checking built-in traffic counters, or using the CLI tools. If everything is set up correctly, you will see live inbound and outbound traffic being tracked. You can read the full quick guide for enabling the traffic capture [here](https://fastnetmon.com/docs-fnm-advanced/advanced-quick-start/). ![](https://fastnetmon.com/wp-content/uploads/2026/04/FastNetMon-example-view-networks-monitored-1024x576.png)*Example view of network traffic configured on FastNetMon.*Configuring detection thresholds Once FastNetMon is receiving traffic, the next step is defining what “normal” looks like — and what should be treated as an attack. FastNetMon provides [a wide range of threshold options](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-threshold-types/) for this purpose. At its core, the system tracks multiple traffic counters for every host and network, including packets per second, bandwidth (Mbps), and flows. On top of that, traffic is also broken down by protocol, such as TCP, UDP, ICMP, and specific patterns like TCP SYN traffic. Thresholds can be applied at different levels, including individual hosts ([per host thresholds](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-per-host-threshold-configuration/)) and groups of networks ([hostgroup thresholds](https://fastnetmon.com/docs-fnm-advanced/per-hostgroup-thresholds/)). This allows detection logic to be applied either very precisely to a single IP or consistently across larger parts of a network. In addition, thresholds can be configured independently [for incoming and outgoing traffic](https://fastnetmon.com/docs-fnm-advanced/per-direction-hostgroup-thresholds/). This flexibility is what allows FastNetMon to adapt to very different network environments – from simple setups to highly specialised deployments. In practice, you can build [all kinds of thresholds](https://fastnetmon.com/docs-fnm-advanced/flexible-thresholds/) using most fields available at the L3 and L4 OSI layers, which means the level of granularity is effectively defined by your own requirements and use case. ![](https://fastnetmon.com/wp-content/uploads/2026/04/FastNetMon-example-view-Adding-configuring-and-setting-thresholds-for-host-groups-1024x576.png)*Example view of adding, configuring and setting thresholds for host groups*### Automatic baseline calculation To make this easier, FastNetMon includes [built-in tools to calculate thresholds automatically](https://fastnetmon.com/docs-fnm-advanced/automated-baseline-calculation-with-fastnetmon-advanced/) based on your real traffic. Instead of guessing values, you can let FastNetMon observe your network over time and calculate peak traffic levels across different metrics. These baselines can then be used to define thresholds, typically by applying a multiplier (for example, 2–3x peak traffic). This gives you a practical starting point that reflects your actual network behaviour, not assumptions. ## Configuring mitigation actions: what happens when a DDoS attack is detected? Once FastNetMon detects an attack, the next step is deciding how to respond. Just like detection, mitigation is highly configurable and can be adapted to your network and operational model. Some of the common approaches are: - **BGP Blackhole The simplest and fastest option. FastNetMon announces a route that effectively drops all traffic to the attacked host, removing the load from your network. This is reliable and widely used when immediate protection is needed. Read how to configure [here](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-bgp-blackhole-automation/). - **BGP Flow Spec A more granular approach. Instead of blocking all traffic, FastNetMon identifies patterns in the attack and installs filtering rules on your routers to drop only malicious traffic, allowing legitimate traffic to continue. Read how to configure [here](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-bgp-flow-spec-configuration/). - **Scrubbing centre diversion Traffic can be redirected to an external DDoS scrubbing provider, either via BGP or API integrations. This allows large-scale attacks to be cleaned upstream before reaching your network. Read more [here](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-and-ddos-scrubbing-centers-integration/). ![](https://fastnetmon.com/wp-content/uploads/2026/04/FastNetMon-example-view-Configuring-BGP-Flow-Spec-mitigation-1024x576.png)*Example view of configuring BGP Flow Spec mitigation mode*Each approach has its place, and many operators use a combination depending on the type and scale of the attack. ## **Built for real networks** FastNetMon is designed to work reliably in production, under real network conditions. That requires two things: a detection engine that is easy to deploy and trust, and the flexibility to adapt when networks behave differently. Over the years, we’ve worked with ISPs handling backbone traffic, hosting providers protecting customer infrastructure, IXPs operating at extreme scale, and enterprises with highly specific traffic patterns. Each of these environments introduces real-world edge cases, and the configuration options in FastNetMon come directly from those requirements. That is why the system includes 300+ configuration options — not as theoretical features, but as direct responses to operational needs observed in production environments. We continue to develop FastNetMon in the same way, guided by feedback from operators. If you’re new to FastNetMon, [start a trial](https://fastnetmon.com/trial/) and see how it works in your own network. ## What’s next? We are about to launch a new web dashboard that will make it easier to manage the entire configuration from a single interface, alongside powerful traffic visualisations, as you can see in this article. If you’d like early access, contact us at **sales@fastnetmon.com**. **Categories:** FastNetMon Blog **Tags:** core product --- ### [Event recap - Bucharest Cybersecurity Conference 2025](https://fastnetmon.com/2025/10/09/event-recap-bucharest-cybersecurity-conference-2025/) **Published:** October 9, 2025 **Author:** FastNetMon **Content:** The **Bucharest Cybersecurity Conference 2025 (BCC2025)** is wrapping up today - and it has been an interesting week! Hosted by the Romanian National Cyber Security Directorate (DNSC) with support from ENISA, ECCC, and ANSSI, this three-day event brought together policymakers, industry leaders, and technical experts from across Europe. With hundreds of participants and dozens of sessions, BCC2025 once again proved its importance in the regional cybersecurity scene. ### A community coming together The agenda was packed with conversations that matter right now: implementing the EU’s cybersecurity framework in practice, securing critical sectors, and addressing the fast-moving threats posed by AI-driven attacks and quantum computing. The geopolitical context was also front and centre. From Ukraine to Moldova and Romania’s own elections, it’s clear that cybersecurity has become a core element of resilience and national security — and collaboration across borders is more critical than ever. ### Highlights from the sessions ![](https://fastnetmon.com/wp-content/uploads/2025/10/Event-recap-Bucharest-Cybersecurity-Conference-2025-FastNetMon-1024x493.jpg)Across the three days, we heard excellent perspectives from policymakers, operators, and researchers. Some of our favourite moments included: - ***“Europe’s cybersecurity rules at crossroads”*** *— a lively discussion on how NIS2, the Cyber Resilience Act, and the EU’s broader framework are reshaping operational requirements for both public and private sector operators. The focus was on practical enforcement, supply chain trust, and the need for continuous visibility across complex infrastructures. - ***“Cyber resilience in wartime: lessons learned from Ukraine”*** *— a powerful panel showing how national-scale cyber defence adapts under extreme conditions. The discussion highlighted the importance of distributed monitoring and fast information sharing to maintain uptime and stability even under sustained attack. - ***“When the telecom network breaks, everything stops”*** *— a technical deep dive into critical dependencies between telecom infrastructure and other essential services. Speakers stressed the importance of network observability and early anomaly detection to prevent cascading failures. - ***“Powering resilience: securing Europe’s energy sector”*** *— an insightful look into how grid operators and service providers are improving visibility and response automation across distributed networks to defend against increasingly sophisticated, cross-border threats.* Beyond the official sessions, the **side events** added real depth to the programme — with workshops, roundtables, and the EU Impact Day giving space for more specialised discussions on NIS2, resilience, and the market impact of European cybersecurity initiatives. ![](https://fastnetmon.com/wp-content/uploads/2025/10/FastNetMon-at-Bucharest-Cybersecurity-Conference-2025--1024x798.png)### What we’re taking home from BCC2025 For FastNetMon, BCC2025 was about more than just listening to talks. Events like this are an opportunity to connect with decision makers, share lessons learned from the front lines, and build a stronger common approach to network visibility and DDoS defence. DDoS attacks continue to grow in scale and sophistication, and hybrid threats are increasingly used as part of geopolitical strategies. The ability to see what’s happening on the network in real time, and to react fast, is no longer optional — it’s essential for resilience. ### Looking ahead We left Bucharest optimistic about the level of collaboration across the European cybersecurity community. A big thank you to the organisers and to everyone who took the time to meet with us during the event. If we didn’t get a chance to connect in person, we’d be glad to continue the conversation — drop us a message anytime. We’re already looking forward to next year! --- ### About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps **Categories:** Events, Press & Newsroom **Tags:** events --- ### [NANOG 96 - Event Recap](https://fastnetmon.com/2026/02/06/nanog-96-event-recap/) **Published:** February 6, 2026 **Author:** FastNetMon **Content:** FastNetMon attended [**NANOG 96**](https://nanog.org/events/nanog-96/), held 2–4 February 2026 in San Francisco, joining over 800 network engineers, operators, and architects for three days of technical talks, hallway debates, and community catch-ups. As always, NANOG delivered exactly what makes it unique. The conference combined deeply practical presentations with open sharing of operational experience, alongside the informal conversations that often turn into real production changes months later. The spotlight topic for NANOG 96 was AI and network infrastructure, and it was visible across keynotes, technical sessions, and countless hallway discussions about traffic patterns, telemetry requirements, and how AI workloads are already changing network capacity and design assumptions. For FastNetMon, the biggest moment of the week was seeing FastNetMon founder, Pavel Odintsov, present to the NANOG community. The previous talk he gave at NANOG was in 2023 (about [Network Telemetry on Modern Routers](https://youtu.be/6gGQMVia3CQ?si=vRK4K2L2SOxbO2p0)), and it was a good time to get back on the stage again! ## **FastNetMon presentation at NANOG 96** ![](https://fastnetmon.com/wp-content/uploads/2026/02/NANOG96-presentation-FastNetMon-Pavel-Pdintsov.png)On day three of NANOG 96, Pavel presented FastNetMon Community: an *open source tool for DDoS detection*. The session focused on how FastNetMon is actually used in production networks, rather than theoretical detection models. The talk walked through deployment patterns seen across networks, practical detection approaches that hold up under real traffic conditions, and lessons learned from operators running FastNetMon at scale. It also highlighted how the open source community continues to influence the direction of the project. You can download the slides to explore the technical details further. [Fastnetmon Community - NANOG96 Presentation by Pavel Odintsov](https://fastnetmon.com/wp-content/uploads/2026/02/20260204_Odintsov_Fastnetmon_Community_Open_v1.pdf)[Download](https://fastnetmon.com/wp-content/uploads/2026/02/20260204_Odintsov_Fastnetmon_Community_Open_v1.pdf) One of the strongest aspects of presenting at NANOG is always the discussion afterwards. The questions and feedback came directly from engineers running large networks in production, which is exactly the environment FastNetMon is built for. ## **What stood out technically at NANOG 96** If there was one consistent theme across NANOG 96, it was how quickly long-standing assumptions about network traffic are changing. AI workloads are already reshaping how networks behave. Operators are seeing significantly higher east-west traffic density inside data centres, traffic bursts that are harder to predict using historical baselines, and a much stronger dependency on real-time telemetry to understand what is happening across infrastructure. There was also repeated emphasis on the need for faster detection and response cycles when something goes wrong, whether that is congestion, misconfiguration, or active attack traffic. ![](https://fastnetmon.com/wp-content/uploads/2026/02/NANOG96-Recap-FastNetMon-1024x648.png)For traffic visibility and DDoS detection, these shifts are no longer future concerns. They are already visible in production environments and are directly influencing how operators think about monitoring and detection architecture. Routing security and BGP remained, as expected, a central part of the conversation at NANOG 96. Multiple sessions and hallway discussions focused on improving observability and access to data, alongside very practical conversations about RPKI adoption in real operational environments. There was also strong interest in recent routing incidents and what they revealed about failure detection, propagation behaviour, and recovery patterns in modern large-scale networks. As is typical for NANOG, some of the most useful knowledge sharing happened outside formal presentations, where operators exchanged real operational experience rather than theory. ## **The hallway track and operator conversations** We had a full calendar of meetings throughout NANOG 96 with service providers, hosting companies, IXPs, and infrastructure vendors. The discussions covered everything from DDoS detection strategy and mitigation workflows to routing security and the realities of operating large distributed networks today. ![](https://fastnetmon.com/wp-content/uploads/2026/02/N96-Nanog-FastNetMon-team-2026-1024x645.jpg)Just as importantly, NANOG gave us the opportunity to reconnect with long-time friends in the community and meet many new teams evaluating how to improve traffic visibility and automated detection. These conversations are often where we learn the most about how networks are actually evolving in the wild. ## **Community highlights from NANOG 96** The Women in Tech mixer on Sunday evening stood out as particularly welcoming and energetic. It set a strong tone before the conference even started and created space for meaningful conversations across different parts of the community. The evening continued with sponsor-hosted socials, including the Megaport event, where people had a chance to reconnect in a relaxed environment before the technical schedule began. ![](https://fastnetmon.com/wp-content/uploads/2026/02/NANOG96-women-in-tech-1024x576.jpeg)Tuesday evening’s Beer n’ Gear once again delivered the classic NANOG mix of technical conversations and community atmosphere. This year it also came with a fun surprise for us, as Virgil Truica from the FastNetMon team won one of the prizes, which made the evening even more memorable. ![](https://fastnetmon.com/wp-content/uploads/2026/02/Virgil-Truica-Nanog-96-Beer-n-Gear-1024x646.jpeg)On Wednesday, we organised a small treasure hunt across the venue. Participants searched for hidden FastNetMon merch placed around the conference space, and the winner received FastNetMon gear together with an Amazon gift card. It was a simple idea, but it added some extra energy to an already lively conference environment and showed once again how much people enjoy a bit of friendly competition when networking swag is involved. ![](https://fastnetmon.com/wp-content/uploads/2026/02/FastNetMon-treasure-hunt-at-NANOG-1024x529.png)## **NANOG week beyond the conference rooms** San Francisco delivered unusually generous sunny weather for early February, which made the week even more enjoyable. Outside conference hours, the team had a chance to see some of the city’s iconic sights. While NANOG schedules are always busy, having a bit of time to experience the city is always a welcome bonus during event travel. ![](https://fastnetmon.com/wp-content/uploads/2026/02/FastNetMon-NANOG86-Recap-1-1024x576.jpeg)## **See you at the next NANOG** If you met us at NANOG 96, thank you for the conversations, feedback, and ideas you shared with us. If you missed Pavel’s talk, we highly recommend watching the recording and reviewing the slides to see how FastNetMon continues to evolve together with the operator community. If you want to talk about FastNetMon deployments, DDoS detection strategy, or traffic visibility challenges, we are always happy to continue the conversation. We are looking forward to seeing many of you again at the next event! [![](https://fastnetmon.com/wp-content/uploads/2026/02/NANOG96-Highlight-shorts-1024x492.png)](https://youtube.com/shorts/cuh3VtLcbV4?si=JULwNswt6aw6Os0l) **Categories:** Events, FastNetMon Blog, Featured, Press & Newsroom --- ### [APRICOT 2026 - Event Recap](https://fastnetmon.com/2026/02/12/apricot-2026-event-recap/) **Published:** February 12, 2026 **Author:** FastNetMon **Content:** APRICOT 2026 in Jakarta brought together one of the most technically sharp and operationally focused Internet communities we’ve seen this year. As Asia Pacific’s largest Internet operations conference, APRICOT continues to be a place where engineers, operators, researchers, and policy communities meet to exchange very practical knowledge about running and protecting real networks at scale. The nine-day summit, co-organised by APNOG and APNIC and local host APJII, covered everything from routing security and DNS operations to network performance, peering, and emerging infrastructure challenges across the region. The FastNetMon team attended the conference part of the event, from the Sunday social through to the Wednesday closing social, focusing on connecting with operators across the region, as well as attending sessions around DDoS, routing security, network visibility, and operational security. ## **A strong start: community, history, and the future Internet** The ISOC social set the tone for the week. While small and intimate event, the conversations were open, practical, and strongly community-driven, which is something APRICOT consistently does well. It felt less like a vendor-heavy conference and more like an operator-first environment where people are comfortable sharing real production lessons. ![](https://fastnetmon.com/wp-content/uploads/2026/02/APRICOT-2026-recap--scaled.png)On Monday, the opening sessions balanced future-looking themes with deep historical context. Jim Cowie’s Internet History Initiative keynote highlighted the importance of preserving operational knowledge and Internet data history, while broader conference themes explored how AI is reshaping infrastructure and operations. Across plenary and SIG sessions, we saw strong participation from global ecosystem organisations including APNIC, ICANN, and the RIR community, reinforcing how tightly coupled policy, routing security, and real-world network operations are in the Asia Pacific region. ## **Routing, security, and DDoS: operational reality over theory** For FastNetMon, the most relevant content sat in routing security, DNS, and operational security sessions. Dave Phelan’s talk on **DDoS in Indonesia — has it improved** stood out as a grounded regional view of attack trends and mitigation realities. This kind of operator-level regional analysis is exactly what helps teams understand how threat landscapes differ between regions and infrastructure maturity levels, and Dave’s insights on mitigation were also spot-on. ![](https://fastnetmon.com/wp-content/uploads/2026/02/Dave-Phelan-APNIC-DDoS-in-Indonesia-1024x502.jpg)Routing security discussions were equally strong. Sessions covering RPKI, ASPA development, and post-ROV attack scenarios showed how the community is moving from theory into deployment and operational tooling. The Routing Security SIG discussions reinforced how adoption is progressing across APAC and how operators are approaching validation, policy enforcement, and automation. From a visibility and measurement standpoint, Randy Bush’s session on debugging routing and forwarding using RIPE Atlas demonstrated how distributed measurement continues to be essential for troubleshooting complex interdomain behaviour. The security track also highlighted the operational reality of defence-in-depth. Sessions and training tracks focused on device security, routing protocol protection, DNSSEC, threat detection, and incident response practices for real production environments, not just theoretical frameworks. ## **IPv6, DNS, and the operational Internet at scale** IPv6 deployment and measurement continued to be a major theme. Case studies on large-scale IPv6-first deployments and scanning methodologies showed how the transition is no longer experimental in many parts of APAC, but operational and business-critical. DNS sessions led by speakers such as Geoffrey Huston and Shaila Sharmin focused on resolver behaviour, DNSSEC deployment journeys, and multilingual Internet enablement. These topics are particularly relevant in APAC, where language diversity and scale introduce very different operational constraints compared to other regions. The consistent theme across these sessions was operational pragmatism: what works in production, what breaks, and how teams are fixing it. ## **The APAC operator community: technically sharp and genuinely welcoming** One thing that stood out throughout APRICOT was the quality of the people. The technical level was extremely high, but the environment stayed approachable and collaborative. Conversations moved easily from deep protocol discussions into practical deployment lessons, and then into social events without losing that strong sense of shared purpose. We were also invited to a large number of regional NOG communities across Asia Pacific. The NOG reports session alone showed how active and diverse the regional operator ecosystem is, from well-established groups to fast-growing newer communities. It is very clear that knowledge sharing in APAC does not happen once a year at a single conference — it is continuous, local, and extremely operationally focused. We fully intend to attend as many regional NOG events as possible moving forward. ![](https://fastnetmon.com/wp-content/uploads/2026/02/APRICOT-community--1024x768.jpg)## **Post-conference musings** From a FastNetMon perspective, APRICOT is not just a regional event. The Asia Pacific region is one of the fastest-growing Internet markets in the world, with very different infrastructure constraints, threat models, and deployment realities compared to Europe or North America. You see earlier adoption of some technologies, different attack patterns, and often extremely creative engineering solutions driven by geography, scale, and cost constraints. That makes APRICOT an important place to come to listen and learn. The week in Jakarta confirmed something we already suspected: FastNetMon needs to spend more time in the Asia Pacific region. The conversations around DDoS, network visibility, routing security, and operational tooling were highly relevant, and we met operators facing challenges that map directly to what we’re building. We are already planning to participate in more regional events and deepen our engagement with the APAC network operator community. The next few years will be extremely interesting for Internet infrastructure development across the region. **Categories:** Events, FastNetMon Blog, Featured, Press & Newsroom --- ### [FastNetMon strengthens engineering team with Sergei Mamonov](https://fastnetmon.com/2026/03/10/fastnetmon-welcomes-sergei-mamonov-as-senior-systems-engineer/) **Published:** March 10, 2026 **Author:** FastNetMon **Content:** We’re pleased to be working with **Sergei Mamonov**, who will be contributing to FastNetMon as a **Senior Systems Engineer**, strengthening our engineering team as adoption of FastNetMon continues to grow across hosting providers, ISPs, and telecom operators worldwide. Sergei brings more than 15 years of hands-on experience operating large-scale production infrastructure in the hosting and web infrastructure industry. His background spans virtualisation platforms, infrastructure automation, and running production systems at scale, with a strong focus on reliability and operational ownership. At FastNetMon, Sergei plays an integral role within the technical team, helping us continue developing comprehensive solutions for DDoS security on the network layer and supporting our customers in defending their networks against modern DDoS attacks. As network environments become increasingly complex and attack patterns continue to evolve, strong operational and infrastructure expertise remains essential to building practical security solutions for real-world networks. Sergei’s experience working close to production systems and operators aligns naturally with FastNetMon’s engineering-driven approach. We’re excited to collaborate with Sergei and look forward to building the next chapter of FastNetMon together. **Categories:** FastNetMon Blog, Press & Newsroom --- ### [FastNetMon collaborates with NLnet Labs on Rotonda BGP and Flow Spec development](https://fastnetmon.com/2026/03/12/fastnetmon-collaborates-with-nlnet-labs-on-rotonda-bgp-and-flow-spec-development/) **Published:** March 12, 2026 **Author:** FastNetMon **Content:** [FastNetMon](http://fastnetmon.com/) is collaborating with [NLnet Labs](https://nlnetlabs.nl/) to advance the development of [Rotonda](https://nlnetlabs.nl/projects/routing/rotonda/), an open source routing platform designed for high-performance routing data processing. The collaboration focuses on expanding Rotonda into a fully functional BGP daemon with BGP Flow Spec support, enabling new capabilities for routing automation, traffic filtering, and network security applications. Functionality developed through this collaboration will be delivered on a rolling basis through upcoming Rotonda releases and will be integrated into the main Rotonda codebase as open source. ## Advancing Rotonda’s BGP capabilities Rotonda is a modern routing platform built in Rust and designed to efficiently process large volumes of routing data. Through this collaboration, FastNetMon and NLnet Labs are working together to extend Rotonda’s capabilities in several key areas of BGP functionality. Development efforts include improvements such as: - **Add Path capability**, enabling processing and storage of BGP updates with path identifiers - **BGP message creation**, allowing Rotonda to generate BGP UPDATE announcements and withdrawals programmatically - **Advanced RIB inspection**, providing high-throughput interfaces for querying routing information - **Detailed BGP session visibility**, including peer capabilities and session state Together, these capabilities move Rotonda closer to operating as a fully functional BGP daemon suitable for integration into routing automation and monitoring workflows. ## Introducing Flow Spec support A key area of collaboration is the addition of BGP Flow Spec functionality to Rotonda. Flow Spec allows operators to distribute traffic filtering rules using BGP, enabling networks to respond rapidly to unwanted traffic patterns and security incidents. Within Rotonda, Flow Spec rules can be parsed, processed, and stored within dedicated routing tables. Future development will further expand programmability and automation through Rotonda’s scripting capabilities. This functionality can support use cases such as automated traffic filtering and DDoS mitigation workflows, where Flow Spec rules are distributed across networks to block or rate-limit malicious traffic. ![](https://fastnetmon.com/wp-content/uploads/2026/03/quote.png) > **“Rotonda provides a powerful foundation for working with routing data, and this collaboration helps move it closer to a full BGP daemon with Flow Spec support,”** said Pavel Odintsov, founder of FastNetMon. ## Open source collaboration All features developed through this collaboration will be released as open source and integrated into the Rotonda project. The Rotonda application is available under the Mozilla Public License 2.0, while supporting libraries are released under the BSD 3-Clause license. This ensures that improvements funded through this collaboration remain available to the broader networking community. FastNetMon looks forward to continuing its collaboration with NLnet Labs and contributing to the development of high-performance open source infrastructure for routing and network security. ![](https://fastnetmon.com/wp-content/uploads/2026/03/quote.png) > **“We’re pleased to collaborate with FastNetMon to further develop Rotonda and expand its capabilities,”** said a Jasper den Hertog, Rotonda developer at NLnet Labs. **“Partnerships like this help accelerate development while ensuring the technology remains open and available to the networking community.”** **Categories:** FastNetMon Blog, Featured, Press & Newsroom **Tags:** News, partnership --- ### [FastNetMon Advanced Adds Support for Debian 13](https://fastnetmon.com/2026/03/23/fastnetmon-advanced-adds-support-for-debian-13/) **Published:** March 23, 2026 **Author:** FastNetMon **Content:** FastNetMon Advanced now officially supports Debian 13 (Trixie), enabling deployment on the latest stable release of one of the most widely used Linux distributions in server and network environments. This ensures that network operators can take advantage of the newest system libraries, toolchains, and kernel improvements while maintaining the stability and reliability they expect from both Debian and FastNetMon. Debian 13 introduces updated components that improve performance, security, and long-term maintainability. FastNetMon Advanced has been fully validated against this release, confirming compatibility with its core dependencies and reliable operation in production environments for high-performance network monitoring and DDoS detection. ## **Debian ecosystem integration** Beyond Advanced support, FastNetMon Community Edition is an official package in the Debian project and can be installed directly from standard repositories. It remains the only DDoS detection tool available in Debian’s official package ecosystem, offering native access to open-source DDoS detection and real-time network traffic monitoring capabilities. ## **Broad Linux platform support** FastNetMon Advanced continues to support a wide range of major Linux distributions commonly used in server and network environments, including Ubuntu LTS releases and Red Hat-family distributions such as RHEL, CentOS, AlmaLinux, and Rocky Linux. Debian 13 support builds on this established compatibility, ensuring that network operators can deploy FastNetMon Advanced on modern Linux platforms with confidence. ## **Availability** For installation instructions, deployment guidance, and best practices for Linux-based DDoS protection and network traffic visibility, please refer to the [official documentation](https://fastnetmon.com/docs-fnm-advanced/). FastNetMon continues to expand platform compatibility to meet modern infrastructure requirements, helping network operators deploy scalable, real-time DDoS detection and mitigation across their preferred Linux environments. **Categories:** FastNetMon Blog, Featured, Press & Newsroom **Tags:** Linux, product update --- ### [Alleged DDoS-for-hire operator behind Fluxstress arrested in Thailand](https://fastnetmon.com/2026/04/14/alleged-ddos-for-hire-operator-behind-fluxstress-arrested-in-thailand/) **Published:** April 14, 2026 **Author:** FastNetMon **Content:** Thai authorities have arrested a 27-year-old German national suspected of operating major DDoS-for-hire platforms, following a multi-year international investigation involving European law enforcement and INTERPOL. The suspect, identified as Noah Christopher, was detained in Bangkok’s Thong Lo district during a joint operation by Thailand’s Cyber Crime Investigation Bureau (CCIB) and Immigration Bureau. The arrest was executed under an INTERPOL Red Notice and is linked to 74 outstanding warrants in Germany. The arrest was reported in detail in the [Bangkok Post](https://www.bangkokpost.com/thailand/general/3235285/german-hacker-facing-74-cybercrime-warrants-arrested-in-bangkok). ## Long-running operation of Fluxstress and Netdowner Investigators allege that Christopher was behind the operation of two well-known DDoS-for-hire services, Fluxstress and Netdowner (also referred to as Neldowner in some reports). The platforms were active between 2021 and 2025 and formed part of a broader cybercrime-as-a-service model. These services enabled customers globally to launch DDoS attacks against targets of their choosing. Users reportedly paid fees—often in cryptocurrencies such as Bitcoin—to generate large volumes of malicious traffic designed to overwhelm servers and disrupt online services. Authorities state that the platforms significantly lowered the technical barrier required to execute DDoS attacks, making them accessible to non-technical users and contributing to a wide range of incidents, including attacks against businesses and public sector organisations. ## Arrest follows international manhunt Christopher is believed to have evaded authorities for several years, reportedly moving between countries, including the United Arab Emirates and China, before settling in Thailand. He had been residing in a high-end apartment in Bangkok and had reportedly travelled in and out of the country over a two-year period. German federal authorities ultimately traced his location and coordinated with Thai police to carry out the arrest. Thai immigration officials revoked his visa shortly before the operation. ## Equipment seized, investigation ongoing During the raid, authorities seized multiple electronic devices, including computers, smartphones, tablets, and a hardware cryptocurrency wallet. Digital forensics teams are currently analysing the equipment for evidence, including potential links to additional suspects and attack activity. Officials have indicated that the seized data may provide insight into the infrastructure behind the DDoS platforms, customer activity, and possible target lists. ## Services may still be active Despite the arrest, there are indications that parts of the infrastructure may remain operational. Independent researchers have suggested that at least one of the platforms, Fluxstress, was still accessible following the arrest, raising questions about the resilience and decentralisation of such services. Thai authorities are also examining whether any attacks were launched from within the country during the suspect’s residence. ## Extradition proceedings underway Christopher remains in custody in Thailand pending extradition to Germany, where he is expected to face multiple charges related to cybercrime operations, including running platforms that facilitate DDoS attacks and other forms of online disruption. The case highlights the continued global nature of DDoS-for-hire ecosystems and the role of international cooperation in identifying and apprehending operators behind them. **Categories:** FastNetMon Blog **Tags:** legal --- ### [The Strait of Hormuz & Beyond: Cables, conflict and connectivity analysed](https://fastnetmon.com/2026/04/10/the-strait-of-hormuz-beyond-tracking-data-routes-across-the-gulf/) **Published:** April 10, 2026 **Author:** FastNetMon **Content:** ## Introduction: The Strait of Hormuz and Gulf Connectivity While the world watches the Strait of Hormuz for its energy impact, for network engineers, the story runs deeper. This narrow waterway is a primary artery for international data, where a dense cluster of subsea cables follows the same channels that carry global energy. Today, these waters are increasingly defined by military activity, restricted navigation, and the resulting operational uncertainty. The risk here isn't necessarily a total outage as the internet is architected to reroute. But a lot is going on in the connectivity front in the region right now. Cable routes are geographically concentrated, maintenance logistics now depend on safe maritime access, and major projects intended to add much-needed redundancy have reached a standstill. Simultaneous instability in the Red Sea and the Persian Gulf has created a rare "Dual-Front" scenario: both primary connectivity corridors are facing elevated risk at once. Some of the capacity and redundancy adding projects are getting interesting reroutes, and alternative solutions. All in all, it is a very interesting engineering scene right now, and we're covering the nitty-gritty details with maps, anecdotes, history and future in this article. *Disclaimer: The data in this article is compiled from publicly available resources and may contain errors. Maps and diagrams are for **illustrative purposes only**; they do not follow exact cable routes 100%, as the precise locations of certain infrastructure are often classified or commercially sensitive. To ensure a clear visualisation for this article, some technical data points may have been simplified or omitted.* ## Mapping the Gulf connectivity Much of the Gulf’s international traffic enters through submarine cables crossing the Strait of Hormuz, where systems share a narrow physical corridor before distributing connectivity across regional landing stations. Redundancy is currently achieved through a mix of five legacy "workhorse" networks. These systems are the backbone of the region, but under current conditions, they are being pushed to their technical limits. ### The Legacy Workhorses of the Hormuz Strait International connectivity into the Gulf typically follows a consistent physical layout. Submarine cables approach from the Arabian Sea and land first along the Omani coast, which acts as the primary "southern gateway" for the region. From these entry points, branching units (BUs) distribute capacity across the Gulf countries, connecting landing stations in the UAE, Qatar, Bahrain, Saudi Arabia, Kuwait, and Iraq. Because regional cable permits historically favored routing through Omani waters, multiple systems follow closely aligned seabed paths while crossing the Strait of Hormuz. While logical diversity exists at the network layer—meaning data can be rerouted through different software paths—the physical routes are geographically very clustered. In the high-tension environment of April 2026, this clustering has transformed from a matter of convenience into a critical vulnerability. Major systems transiting this corridor pictured: - AAE-1 (Asia–Africa–Europe-1) - FALCON - Gulf Bridge International (GBI) - Tata TGN-Gulf - SEA-ME-WE 5 ![](https://fastnetmon.com/wp-content/uploads/2026/04/Gulf-connectivity-Main-submarine-cables-of-the-Gulf-region.png)Let's look at the maritime cable systems one by one to better understand the challenges of the ecosystem: - **AAE-1 (Asia–Africa–Europe-1):** A 25,000 km veteran of the region. Despite a history of frequent cuts in the Red Sea, it remains the primary legacy route currently forced to carry the overflow from newer, stalled systems. It is effectively the most congested "pipe" in the 2026 network. - **FALCON (GCX):** A unique regional loop with landings in both the northern and southern Gulf. Its proximity to active maritime conflict zones in early 2026 has made it a high-risk asset, with repair vessels often unable to reach its northern segments safely. - **Gulf Bridge International (GBI):** Known for pioneering the "North Route" through Iraq, GBI’s terrestrial rights-of-way are currently serving as the architectural blueprint for the region's emergency land-bypass projects. - **Tata TGN-Gulf:** The primary enterprise link connecting the GCC to Mumbai. It is widely claimed to be operating at its maximum design capacity as it absorbs the traffic of corporate users who have migrated away from unstable Red Sea routes. - **SEA-ME-WE 5 (SMW5):** A high-performance predecessor to the currently stalled SMW6. In 2026, it is likely operating in a "degraded" state due to unresolved electrical shunt faults in the Red Sea, where the security situation has prevented deep-sea maintenance for several months. Once ashore, traffic moves through landing stations into terrestrial DWDM (Dense Wavelength Division Multiplexing) transport networks and national fiber backbones. Here, operators interconnect with regional Internet Exchange Points (IXPs) and upstream providers. From an operational perspective, redundancy in the Strait was historically achieved through multi-operator capacity and routing policy. However, as of 2026, the industry has realised that this logical redundancy cannot compensate for the physical risk of a single narrow maritime corridor. There are a few alternatives, namely the red sea corridor and land routes - let's explore them next! ### Alternative path: the Red Sea corridor The primary alternative to Gulf routing is the Red Sea–Egypt corridor, which carries a large share of Asia–Europe traffic.This corridor hosts several major long-haul systems and functions as a parallel east–west connectivity path independent of Hormuz-based routing. Traffic entering the Middle East via Oman or Saudi Arabia can often be steered toward this route depending on operator capacity and peering arrangements. In this model, cables run westward from the Arabian Sea through the Gulf of Aden into the Red Sea, then transition mostly across Egypt via terrestrial fibre before continuing into the Mediterranean and Europe. The Primary trunk cables securing the connectivity across the Red Sea are: - SEA-ME-WE 5 (SMW5) - AAE-1 (Asia–Africa–Europe-1) - EIG (Europe India Gateway) - Blue-Raman ![](https://fastnetmon.com/wp-content/uploads/2026/04/Gulf-connectivity-Main-submarine-cables-of-the-Red-Sea.png)The current problem is that th instability in the Red Sea and the Persian Gulf has created a rare "Dual-Front" scenario: both primary connectivity corridors are facing elevated risk at once. As we'll observe when we explore each of these routes one by one, they're not an optimal solution to create redundancy for the situation at the Hormuz Strait: - **SEA-ME-WE 5 (SMW5):** This system was designed for "matchless" low latency, but in 2026, it serves as a case study in the difficulties of conflict-zone maintenance. It has historically been plagued by electrical "shunt faults" in the shallow, high-traffic areas of the Red Sea. In the current environment, specialized repair vessels often cannot safely secure the maritime insurance required to enter contested waters. As a result, the cable is reportedly operating in a "degraded" state, with bandwidth restricted to prevent total system failure while repairs remain pending. - **AAE-1 (Asia–Africa–Europe-1):** Often described by engineers as a "Red Sea Survivor," AAE-1 has remained operational despite a history of multiple cuts and regional disruptions. In the 2026 landscape, it functions as the overloaded artery of the Middle East. Because it is one of the few legacy systems with the scale to absorb traffic from the stalled 2Africa project, it is facing unprecedented congestion at its Egyptian landing stations, resulting in noticeable latency spikes for regional users. - **EIG (Europe India Gateway):** A critical dependency for international enterprise data, the EIG is currently viewed as a high-risk asset due to its landing geography. Its path through the Bab el-Mandeb Strait—now a restricted military zone—means that any physical damage could lead to an indefinite outage. This vulnerability has made the EIG a primary candidate for emergency traffic migration onto Saudi Arabia’s terrestrial fiber backbones, which bypass the southern maritime chokepoints entirely. - **Blue-Raman:** This Google-backed system is perhaps the most strategically significant cable in the 2026 environment, as it was explicitly designed to break the "Egyptian Bottleneck." By transitioning to land in Jordan and crossing to the Mediterranean via Israel, it avoids the Suez transit entirely. While other cables face delays or degradation, Blue-Raman remains a high-speed, operational outlier, though its unique geopolitical path requires constant security monitoring to maintain its status as the region's "Digital Lifeboat." Now that we have looked into all the major submarine cables, it seems that we are coming to a conclusion where the problems are critical and geographically unresolvable in the two straits. And these straits carry most of the region's data highways. The natural next question is, what's going on on land? ### Terrestrial data routes of the Gulf In addition to subsea systems, regional operators are increasingly developing terrestrial fibre corridors designed to complement submarine connectivity. These routes typically run: - across Saudi Arabia’s national backbone, - through Iraq toward Turkey and European networks, - or via cross-border interconnects between Gulf states. ![](https://fastnetmon.com/wp-content/uploads/2026/04/Terrestrial-fibre-connection-corridors-in-the-middle-east.png)The shift from sea to land is a massive re-engineering of the Middle East’s geography. Here are the five key terrestrial corridors for regional connectivity, some of them operational and others under construction: - **SNFN (Saudi National Fiber Network):** The SNFN is the largest terrestrial network in the region. Managed by STC, this sprawling system creates a high-capacity bridge across the Saudi interior. In 2026, its role is to act as the primary bypass for the Red Sea. Data that lands at the Red Sea coast is instantly tunnelled overland to the Gulf coast, effectively removing the need for data to transit the dangerous waters of the southern Bab el-Mandeb Strait. - **MEETS (Middle East-Europe Terrestrial System):** MEETS is a unique 1,400km system that runs fiber alongside high-voltage power transmission lines. Unlike traditional cables buried in the ground, MEETS is an aerial network where the fiber is housed inside the uppermost shield wire of the power pylons. By running up in the air, the cable is far less prone to the accidental cuts or construction damage that typically plague buried lines, and it benefits from the high security of the regional power grid. - **The Iraq–Turkey Corridor (WorldLink):** While the subsea portion of WorldLink remains stalled, the terrestrial segment has become a focal point of investment. This corridor seeks to transform Iraq into a global data hub, running fiber from the Al-Faw Peninsula northward through Baghdad to the Turkish border. Though the full project is officially targeted for 2027, emergency phases are already being activated to provide a Suez-free land path for traffic moving toward Istanbul and Frankfurt. - **The Kuwait–Iraq Strategic Link**: This is a critical short-haul gateway that connects the internal Gulf networks to the Iraq-Turkey transit route. In early 2026, this link was significantly hardened to serve as the switch that allows data coming from the UAE or Qatar to jump off the Gulf's subsea systems and onto the safer Iraqi land corridor. It is the essential physical hand-off point that makes the entire "North Route" viable. - **The Blue-Raman (Israel Crossing):** Google’s Blue-Raman project is the only system providing a 100% operational alternative to the Suez Canal today. The Raman segment lands in Jordan and transitions into a terrestrial fiber bridge that crosses Israel to reach the Mediterranean. In the 2026 landscape, this is the region’s digital lifeboat—the only route that bypasses both the Red Sea maritime zones and the Egyptian transit bottleneck. ## The 2026 Force Majeure: halted and disrupted infrastructure projects The current reality is a paradox of plenty: the seafloor is littered with billions of dollars’ worth of "mega-cables" that are 90% finished, yet the region is hanging by a thread, relying on aging, congested legacy systems that are literally breaking under the strain. Let's look at the halted projects and the lost potential in the region's connectivity. Some of the very major projects include: - 2Africa (Pearls Extension) - SEA-ME-WE 6 (SMW6) - Fibre in Gulf (FIG) - WorldLink (Subsea Segment) In the map below, the unbuilt or unconnected parts of the infrastructure are marked with dotted line: ![](https://fastnetmon.com/wp-content/uploads/2026/04/Connectivity-in-middle-east-disrupted-and-halted-projects.png)Here are the most notable project disruptions explained: - **2Africa (Pearls Extension):** This project was supposed to be the "final boss" of Gulf connectivity. In March 2026, Alcatel Submarine Networks (ASN) officially declared Force Majeure after the Persian Gulf became a no-go zone. Most of the 2Africa Pearls cable is physically sitting on the seafloor right now, but the "landing" operations—the final 5km where the cable meets the beach—have been abandoned. The *Ile De Batz* remains laid up in Dammam, essentially a floating warehouse for a digital revolution that is currently on hold. - **SEA-ME-WE 6 (SMW6):** SMW6 was designed as the high-speed replacement for the ageing SMW5. While the "eastern" and "western" ends are moving forward, the Red Sea Gap has turned it into a project in limbo. The consortium has been forced to postpone the Ready-for-Service (RFS) date to late 2027. This delay is catastrophic because it prevents the "unloading" of traffic from the degraded SMW5, leaving the region’s highest-demand route stuck on a failing legacy backbone. - **Fibre in Gulf (FIG):** Originally Ooredoo’s crown jewel for local GCC connectivity, the FIG subsea loop is a victim of the "Strait of Hormuz Blockade." Construction was halted in early 2026 when maritime border tensions made cable-laying in the northern Gulf impossible. In a desperate pivot, Ooredoo formed OFN (Ooredoo Fibre Networks) in February 2026 to try to move FIG’s logic onto land, but the subsea "super-loop" remains a series of disconnected segments on the ocean floor. - **WorldLink (Subsea Segment):** WorldLink is a tale of two realities. While the land corridor through Iraq is a success story, its subsea "Express" segment—intended to link the UAE directly to Iraq—is officially suspended. The project cannot secure maritime insurance for its vessels in the current northern Gulf climate. This leaves the land corridor as a "bridge to nowhere" until the subsea connection can safely link the UAE’s massive data centers to the Iraqi land pipe. The 2026 conflict has done more than just delay construction; it has triggered a systemic failure of the region’s digital plumbing. While the land cables we’ve discussed provide a desperate "safety valve," they were never designed to handle the firehose of data that the region and the world demands. ## Conclusion: The Maritime Standstill In this article, we’ve explored how connectivity across the Gulf is built on a combination of submarine and terrestrial systems — from the tightly clustered cable routes in the Strait of Hormuz to the Red Sea corridor and overland fibre paths that provide alternative routing options. We’ve also looked at how several major projects intended to expand capacity and improve resilience are now on hold, delaying much-needed diversification of these routes. From an operational perspective, the key takeaway is that resilience in this region is defined less by the number of cable systems and more by their physical distribution. Multiple networks may exist, but when they share the same corridor, redundancy has limits. When disruption occurs, traffic can and does reroute — but not without constraints in capacity and performance. The more immediate concern is not a single failure event, but what follows. Submarine infrastructure depends on continuous maintenance, and in unstable conditions, even routine repairs can be delayed significantly. This extends the impact of otherwise manageable faults and reduces the system’s ability to recover within expected timeframes. The Gulf remains connected, and the internet continues to function as designed. But the current situation highlights a fundamental characteristic of global infrastructure: physical topology still matters. Geography, access, and logistics ultimately define how resilient networks are — especially in regions where multiple critical paths converge. **Categories:** FastNetMon Blog --- ### [Significant DDoS disruption affects Russian state telecom and online services](https://fastnetmon.com/2026/04/08/significant-ddos-disruption-affects-russian-state-telecom-and-online-services/) **Published:** April 8, 2026 **Author:** FastNetMon **Content:** On 6 April 2026, Russian state-run telecommunications provider Rostelecom was hit by a large-scale DDoS attack, affecting internet access, online banking, and government platforms across 30 major cities. The disruptions started unfolding around 9:00 p.m. Moscow time, according to Downdetector reports. Rostelecom confirmed the intrusion to state media, saying the attack was “neutralised” by 11:09 p.m., with incoming malicious traffic filtered to restore network operations. Some services continued to experience outages into Tuesday. The attack impacted millions of users and disrupted a wide range of services, including Microsoft Outlook, Discord, Telegram, Steam, CharacterAI, League of Legends, World of Tanks, and government platforms like Gosuslugi, among many others. Reports from Habr, a Russian IT community platform, indicate that roughly 70% of users experienced general service failures, 11% reported website crashes, and fewer than 10% faced issues accessing accounts or mobile apps. Following the Rostelecom mitigation, additional outages were reported on RuNet, the Russian internet segment, affecting banks, telecom operators, and other online services. User complaints also extended to other major Russian telecoms including MTS, Beeline, Megafon, and T2, as well as platforms like Russian Railways, retailer Wildberries, classifieds site Avito, and social media platforms VKontakte and VK Video. No group has claimed responsibility for the attack. Rostelecom, which serves over 100 million subscribers across mobile, broadband, and PayTV, continues to monitor network activity to prevent further disruptions. Apart from Rostelecom's announcement, no further details on the architecture or the scale of the attack have been disclosed. **Categories:** FastNetMon Blog **Tags:** DDoS Attacks --- ### [FastNetMon Advanced 2.0.375](https://fastnetmon.com/2026/03/30/fastnetmon-advanced-2-0-375/) **Published:** March 30, 2026 **Author:** FastNetMon **Content:** **Release date:** 30 March, 2026 **Version:** 2.0.375 FastNetMon Advanced 2.0.375 delivers improvements to traffic visibility, flow tracking, and analytics, alongside expanded protocol parsing and ClickHouse enhancements. This release introduces deeper sFlow observability with new parsing success and error counters, PPP traffic extraction support, and improved MPLS handling across NetFlow v9, IPFIX, XDP, and AF\_PACKET inputs. Flow tracking has been refactored and extended to cover non-TCP/UDP/ICMP traffic, enabling better anomaly detection, while GRE parsing has been enhanced with RFC 2890 support. ClickHouse analytics gain major updates, including per-protocol schemas, top ASN reporting, UDP top talker calculations, and new export options for pre-computed metrics. Additional updates improve configuration management and API capabilities, add ongoing attack status reporting via web callbacks, modernise fcli resources, and fix multiple operational issues, resulting in better stability, visibility, and operational control. ## Full list of changes - Added counter sflow\_parse\_success\_nested\_header to track successfully parsed packets - Added detailed errors about sFlow parser, now each error code has separate counter - Added option sflow\_extract\_ppp\_traffic which can parse IPv4 traffic inside of PPP encapsulation - Added logic to calculate top talkers by UDP protocol for Clickhouse - Added Netflow v9 encoding of Bison router which uses types 85 and 86 to encoding number of packets and packets length - Refactored flow tracking structure for IPv4 to pass it properly to handlers - Added flow tracking for non tcp/udp/icmp traffic to track spikes in anomalies with other traffic - Added logic to report all ongoing attacks to web endpoint using web\_callback\_attack\_status\_updates - Extracted total counters to external module - Extracted connection tracking logic to separate unit - Added icmp\_type and icmp\_code to simple\_packet and refactored simple packet print logic - Fixed exit code for --configuration\_check - Added MPLS parser option for all types of traffic: netflow\_v9\_strip\_mpls\_tags, ipfix\_strip\_mpls\_tags, xdp\_strip\_mpls\_tags, af\_packet\_strip\_mpls\_tags - Added support of GRE unpacking when key bit is set for EX switches mirroring - Improved GRE parser to read fields which were added in RFC 2890 - Updated resource for fcli which was heavily outdated and caused issues for fields/main, fields/hostgroup and fields/bgp endpoints - new fields were missing - Added flag web\_api\_legacy\_path to control when we use legacy API - Added log message about size of generated file by keep\_traffic\_counters\_during\_restart - Reworked logic of import\_configuration to remove existing collections and create full backup of them - Added API endpoints -X PUT export\_configuration/import\_configuration/create\_configuration and fixed bug in backup logic for create\_configuration which did not backup collections users\_configuration roles\_configuration - Fully implemented clickhouse\_metrics\_export\_top\_networks - Potentially breaking: schema for total traffic tables in Clickhouse was unconditionally moved to new format which includes per protocol counters - Potentially breaking: schema for network tables in Clickhouse was unconditionally moved to new format which includes per protocol counters - Added schema for TOP ASN IPv4 and IPv6 counters - Added full implementation of TOP ASN talker function for Clickhouse - Fixed bug in sudo fcli show baseline\_per\_host which caused capture of one additional network which was outside of range - Added per flow sorter to top hosts table - Added clickhouse\_metrics\_export\_top\_asns option to pre-calculate top ASNs [FastNetMon Advanced documentation](https://fastnetmon.com/docs-fnm-advanced/) [View this release on GitHub](https://github.com/FastNetMon/fastnetmon-advanced-releases/releases/tag/v2.0.375) **Categories:** Releases --- ### [FastNetMon Advanced 2.0.376](https://fastnetmon.com/2026/04/07/fastnetmon-advanced-2-0-376/) **Published:** April 7, 2026 **Author:** FastNetMon **Content:** **Release date:** 7 April, 2026 **Version:** 2.0.376 **FastNetMon Advanced 2.0.376** introduces protocol parsing improvements, enhanced flow visibility, and platform lifecycle updates, while continuing to refine analytics and integrations. This release adds PPPoE IPv6 parsing and expanded counter handling for the sFlow plugin, alongside a new option to process counters delivered via sFlow. Flow Spec workflows are improved with richer flow tracking information in notifications and cleaner email output, while remote attack handling gains new integration groundwork and callback propagation. ClickHouse metrics are extended with remote top talker exports, NAT event tracking is improved for NetFlow v9, and parser observability is enhanced with detailed error tracking. The release also upgrades GoBGP to version 4.4.0. **Support for Ubuntu 18.04 and 20.04 is now deprecated** as these operating systems are no longer under security support; users are strongly advised to upgrade to a supported Ubuntu version to ensure continued security updates and compatibility. ## Full list of changes - Deprecated Ubuntu 18.04 and 20.04 - Added PPPoE IPv6 parser logic for sFlow plugin - Enabled logic to handle expanded counters in sFlow mode - Added option sflow\_process\_counters to process counters delivered via sFlow protocol - GoBGP upgrade to 4.4.0 - Added new option notify\_script\_remote\_enabled to call script when we detect remote attack but logic is not here yet - Added Protobuf option to sort by protocol - Hide attack packet dump section for flow spec emails for unblock and when we do manual blocks. Added Flow tracking information to initial ban emails - Do not show Packets dump for Flow Spec unban emails - Propagated flow tracking structures to Flow Spec callbacks - Added logic to count NAT event events in Netflow 9 mode as counter netflow\_v9\_nat\_events and then entirely ignore them - Added detailed parser error tracking for App Packer SR - Started populating Agent IP for Nokia SHIM mode - Reworked remote host counters to use uint32\_t ass key and added option clickhouse\_metrics\_export\_remote\_top\_hosts to export remote top talkers to remote\_host\_metrics\_ipv4\_top [FastNetMon Advanced documentation](https://fastnetmon.com/docs-fnm-advanced/) [View this release on GitHub](https://github.com/FastNetMon/fastnetmon-advanced-releases/releases/tag/v2.0.376) **Categories:** Releases --- ### [FastNetMon Advanced now supports PagerDuty integration](https://fastnetmon.com/2026/04/01/fastnetmon-advanced-now-supports-pagerduty-integration/) **Published:** April 1, 2026 **Author:** FastNetMon **Content:** FastNetMon Advanced now supports sending attack notifications directly to PagerDuty, enabling organisations to route DDoS detection events into their existing incident response workflows. Teams using PagerDuty for on-call management and escalation can now receive FastNetMon alerts as structured incidents, allowing network attacks to be handled through standard operational processes. ## **Incident-driven DDoS response** FastNetMon detects abnormal traffic patterns and attack activity in real time. With PagerDuty integration enabled, detection events can automatically generate incidents and follow configured escalation policies without additional tooling or manual intervention. This allows network security events to integrate directly into NOC and SRE workflows alongside other infrastructure alerts. ## **How it works** The integration connects FastNetMon’s notification system with PagerDuty’s Events API. When an attack is detected, FastNetMon sends structured event data, which PagerDuty converts into incidents and routes according to existing escalation rules. ![](https://fastnetmon.com/wp-content/uploads/2026/04/PagerDuty-FastNetMon-Integration.png)### Key capabilities - Automatic incident creation from FastNetMon detection events - Configurable event severity - Alert deduplication with optional IP or hostgroup grouping - Structured event delivery via PagerDuty Events API - Integration through FastNetMon JSON notification callbacks ## **Availability** PagerDuty integration support is available for FastNetMon Advanced. Setup instructions and technical details are available on [GitHub](https://github.com/FastNetMon/pagerduty_integration). **Categories:** FastNetMon Blog, Featured, Press & Newsroom --- ### [Network Engineering Community News: March 2026](https://fastnetmon.com/2026/03/31/network-engineering-community-news-march-2026/) **Published:** March 31, 2026 **Author:** FastNetMon **Content:** Network Engineering Community News - from FastNetMon # Welcome to our Network Engineering Community News! Hi from FastNetMon! March brought plenty to share. We released two new FastNetMon Advanced versions, added Debian 13 support and Bison router integration, welcomed a new senior engineering contributor to the team, and covered key updates and industry events. Happy reading! Want this letter straight to your inbox? Sign up to our monthly Network Engineering Community News [here](https://cdn.forms-content.sg-form.com/b3c8181d-c30d-11ef-b203-ca12671f70d2). --- ## Product updates: March releases, Debian 13 support, and Bison router integration We released two new versions of FastNetMon Advanced in March — **[ 2.0.374 ](https://fastnetmon.com/2026/03/09/fastnetmon-advanced-2-0-374/) and [ 2.0.375 ](https://fastnetmon.com/2026/03/30/fastnetmon-advanced-2-0-375/)** , introducing stability improvements, protocol enhancements, and new observability features. Alongside the release, we’ve added **[ official support for Debian 13 (Trixie) ](https://fastnetmon.com/2026/03/23/fastnetmon-advanced-adds-support-for-debian-13/)** and introduced new **[ Bison router integration ](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-and-bison-router-integration/)** , enabling Flow Spec-based mitigation even on devices without native Flow Spec support. --- ## Engineering insight: Understanding the BGP Monitoring Protocol (BMP) [ ![](https://eoolnbw.stripocdn.email/content/guids/CABINET_328069c03321b69b21d47f0199814d1df4a51347c3a32a8928de1bb94c79dcdb/images/bmp_bgp_monitoring_protocol_explained_1.png) ](https://fastnetmon.com/2026/03/04/understanding-the-bgp-monitoring-protocol/) BGP controls how traffic moves across the Internet, but observing its behaviour at scale can be challenging. BMP (BGP Monitoring Protocol) solves this by streaming detailed routing and peer information from routers to a central collector, giving operators real-time visibility into the control plane. This makes troubleshooting, monitoring, and auditing routing behaviour far more efficient, especially in large networks with hundreds of peers and complex policies. We explored this topic with Brian Wilson, creator of the BGP Black Belt community and BGP educator: [ READ THE ARTICLE ](https://fastnetmon.com/2026/03/04/understanding-the-bgp-monitoring-protocol/) --- ## Expanding the FastNetMon Engineering Team [ ![](https://eoolnbw.stripocdn.email/content/guids/CABINET_328069c03321b69b21d47f0199814d1df4a51347c3a32a8928de1bb94c79dcdb/images/sergei_mamonov_joins_fastnetmon.png) ](https://fastnetmon.com/2026/03/10/fastnetmon-welcomes-sergei-mamonov-as-senior-systems-engineer/) We’re pleased to be working with Sergei Mamonov, who contributes to FastNetMon as a Senior Systems Engineer. Sergei brings more than 15 years of experience operating large-scale production infrastructure, strengthening our engineering efforts as FastNetMon adoption continues to grow across hosting providers, ISPs, and telecom operators worldwide. [ WELCOME SERGEI! ](https://fastnetmon.com/2026/03/10/fastnetmon-welcomes-sergei-mamonov-as-senior-systems-engineer/) --- ## CloudFest 2026 highlights [ ![](https://eoolnbw.stripocdn.email/content/guids/CABINET_328069c03321b69b21d47f0199814d1df4a51347c3a32a8928de1bb94c79dcdb/images/cloudfest_newsletter_grid.png) ](https://fastnetmon.com/2026/03/27/cloudfest-2026-event-recap/) CloudFest 2026 brought the internet infrastructure community together in Germany, and FastNetMon was right in the middle of it. From industry discussions to memorable community moments, catch the photos and vibes on our [event recap](https://fastnetmon.com/2026/03/27/cloudfest-2026-event-recap/) and watch our [CloudFest YouTube shorts!](https://www.youtube.com/@FastNetMon/shorts) --- ## FastNetMon and IP Infusion deliver automated DDoS mitigation with OcNOS [ ![](https://eoolnbw.stripocdn.email/content/guids/CABINET_328069c03321b69b21d47f0199814d1df4a51347c3a32a8928de1bb94c79dcdb/images/fastnetmon_collaborates_with_nlnetlabs_x_rotonda_2.png) ](https://fastnetmon.com/2026/03/16/fastnetmon-and-ip-infusion-collaborate-on-automated-ddos-protection-with-ocnos/) We’re excited to announce our collaboration with IP Infusion on an automated DDoS protection solution combining OcNOS and FastNetMon. [ READ MORE ](https://fastnetmon.com/2026/03/16/fastnetmon-and-ip-infusion-collaborate-on-automated-ddos-protection-with-ocnos/) --- ## Industry news & insights Here are some interesting industry takes and major DDoS incidents in March. Happy reading! [ ![](https://eoolnbw.stripocdn.email/content/guids/CABINET_328069c03321b69b21d47f0199814d1df4a51347c3a32a8928de1bb94c79dcdb/images/total_outgoing_traffic_bandiwdth_by_type_outbound_ddos_analysis_indian_networks.png) ](https://fastnetmon.com/2026/03/26/unusual-large-scale-outbound-ddos-activity-observed-across-indian-networks/) **Unusually large-scale outbound DDoS activity** is being observed across Indian residential networks, what the traffic patterns reveal, and why ISPs should monitor more closely. Read our analysis [here](https://fastnetmon.com/2026/03/26/unusual-large-scale-outbound-ddos-activity-observed-across-indian-networks/). [ ![](https://eoolnbw.stripocdn.email/content/guids/CABINET_328069c03321b69b21d47f0199814d1df4a51347c3a32a8928de1bb94c79dcdb/images/kimwolf_and_aisuru_takedown_new_mirai_variant.png) ](https://fastnetmon.com/2026/03/20/aisuru-and-kimwolf-disrupted-but-the-botnet-cycle-continues/) **Aisuru and KimWolf botnets were disrupted** in a major international operation. However, a new Mirai variant is already emerging. Read what's new in the super-botnet landscape [here](https://fastnetmon.com/2026/03/20/aisuru-and-kimwolf-disrupted-but-the-botnet-cycle-continues/). --- ## 💌 Get this newsletter straight to your inbox Sign up to our monthly Network Engineering Community News [here](https://cdn.forms-content.sg-form.com/b3c8181d-c30d-11ef-b203-ca12671f70d2) <html><p class="wp-block-paragraph"></p> **Categories:** Newsletter --- ### [Aisuru and KimWolf disrupted, but the botnet cycle continues](https://fastnetmon.com/2026/03/20/aisuru-and-kimwolf-disrupted-but-the-botnet-cycle-continues/) **Published:** March 20, 2026 **Author:** FastNetMon **Content:** ## **Record-breaking botnets disrupted as a new challenger quietly appears** March 19, 2026, international law enforcement [announced](https://www.justice.gov/usao-ak/pr/authorities-disrupt-worlds-largest-iot-ddos-botnets-responsible-record-breaking-attacks) one of the largest coordinated disruptions of IoT DDoS infrastructure to date. Authorities in the United States, Germany, and Canada targeted command-and-control infrastructure behind the Aisuru, KimWolf, JackSkid, and Mossad botnets: the networks responsible for hundreds of thousands of attacks worldwide and most of the largest DDoS events recently recorded. According to U.S. Department of Justice disclosures, the combined botnets infected more than three million devices globally, primarily consumer IoT hardware such as DVRs, IP cameras, and home routers. Investigators linked the infrastructure to attacks reaching approximately 30 Tbps, placing them among the [most powerful DDoS campaigns publicly acknowledged so far](https://fastnetmon.com/2026/02/01/aisuru-botnet-sets-a-new-ddos-record-at-31-4-tbps/). At nearly the same time, however, researchers were documenting something familiar to anyone tracking the DDoS ecosystem: a new Mirai-based botnet variant already competing for control of vulnerable IoT devices. [Analysis published by Nokia Deepfield researchers](https://github.com/deepfield/public-research/blob/main/katana/report.md) shows an emerging actor aggressively infecting exposed devices and even removing rival malware – a sign that competition for botnet dominance remains active. One botnet infrastructure is dismantled, while another begins expanding. So what is actually happening in the botnet ecosystem at this very moment? Let’s look closer. ## **Law enforcement operation targets large-scale DDoS infrastructure** The coordinated operation focused on disrupting the botnets Aisuru, Kimwolf, and others that have recently caused the majority of record-breaking DDoS attacks. According to court documents, botnet operators rented access to infected devices, allowing customers to launch DDoS attacks on demand. Authorities report: - Over 3 million infected devices worldwide - Hundreds of thousands of executed DDoS attacks - Extortion campaigns demanding payment to stop attacks - Significant financial losses reported by victims - Targets including commercial services and Department of Defense infrastructure Attack commands attributed to individual botnets illustrate their operational scale: - Aisuru: more than 200,000 attack commands issued - KimWolf: more than 25,000 attack commands - JackSkid: over 90,000 attack commands - Mossad: more than 1,000 attack commands The operation involved collaboration between multiple international agencies alongside industry partners and infrastructure providers, demonstrating how mitigation of large botnets increasingly requires coordinated global response, across public and private sectors. While disruptions of this scale can temporarily reduce attack capacity, history shows they rarely eliminate the underlying ecosystem – and some of the recently published research points to the same direction. ## **Researchers observe a new Mirai evolution** Right before the takedown operation, on March 18th, Nokia Deepfield researchers [reported](https://github.com/deepfield/public-research/blob/main/katana/report.md) active deployment of a new Mirai-derived botnet targeting Android-based TV set-top boxes exposed through Android Debug Bridge (ADB) services. Unlike earlier Mirai variants that relied heavily on automated scanning, this botnet appears to leverage externally identified vulnerable devices and focuses on persistence and control once access is obtained. Key observations include: - Infection of tens of thousands of Android TV devices - Installation of malicious Android applications to maintain persistence - Aggressive removal of competing malware from infected hosts - Multiple supported DDoS attack vectors - Encrypted and rotating command-and-control infrastructure Perhaps most notably, researchers observed behavior indicating active competition between botnets for the same pool of vulnerable devices; effectively a resource war over available IoT bandwidth. This mirrors patterns seen repeatedly since the original Mirai source code leak in 2016: disruption events reduce one operator’s footprint, while others rapidly expand to fill the gap. ## **Takeaways from the recent Mirai activity** The two events together highlight several practical realities about today’s DDoS landscape: - **IoT remains the dominant attack platform.** Cheap, exposed consumer devices continue to provide scalable bandwidth for attackers. - **Botnets behave like replaceable infrastructure.** Takedowns reduce capacity temporarily, but new variants quickly reuse the same infection surface. - **Operator competition is increasing.** Modern botnets actively remove rivals to retain control of compromised devices. - **Attack scale keeps growing.** Multi-terabit attacks are no longer theoretical edge cases. For network operators, the implication is straightforward: The disruption of Aisuru and KimWolf represents a significant operational success for international law enforcement. But as current research already shows, the broader botnet cycle continues: evolving, competing, and scaling alongside the internet itself. Botnet disruption helps, but exposure persists. Continuous traffic visibility and automated mitigation remain necessary because new botnets emerge faster than the global IoT ecosystem can be secured. **Categories:** FastNetMon Blog, Featured --- ### [Cloud vs on-prem DDoS protection](https://fastnetmon.com/2025/06/03/cloud-vs-on-prem-ddos-protection/) **Published:** June 3, 2025 **Author:** FastNetMon **Content:** ## DDoS protection in cloud or on-premise: pros, cons, and the rise of hybrid defences Distributed-Denial-of-Service attacks used to be the headache of large carriers and gaming giants. Today they reach everyone from small hosting firms to municipal websites. That change has pushed security teams to decide where DDoS filtering should live: in the cloud, on their own routers, or split between the two. This post walks through the practical trade-offs of each model and explains how FastNetMon lets you combine them. **What does ‘in the cloud’ mean in DDoS protection?** Cloud DDoS services sit upstream from your network. Traffic is routed (or permanently flows) through a provider’s scrubbing centres, where bad packets are filtered before the clean stream returns on a private tunnel or GRE connection. Typical features: - Terabit-scale bandwidth to soak up large floods - 24 × 7 SOC teams who tune filters for you - API hooks or web portals for manual triggers - Always-on or on-demand routing options **When is the cloud the best option?** Off-network scrubbing is ideal when floods dwarf local links; a 10 Gbps circuit will not survive a 200 Gbps barrage, but a cloud service with terabits of headroom can soak it up invisibly. Providers also supply a 24 × 7 security operations centre, handy for teams that don’t keep engineers on call at 3 a.m. Because many platforms have worldwide points of presence, traffic can be filtered near the attacker and re-injected close to end users, trimming latency spikes for a global audience. **Where the cloud can fall short?** The detour that protects a site can hurt real-time services—voice, streaming and gaming users may notice the extra hop through distant scrub hubs. Costs can climb, too: pricing often hinges on the volume of “clean” traffic passed back after mitigation, meaning a busy retail launch might incur higher fees than the attack that triggered them. Adding cloud protection also introduces routing gymnastics with BGP fail-over, GRE tunnels or DNS cut-overs, any of which can misfire. Finally, data-residency rules in finance, healthcare or government may forbid traffic from leaving certain jurisdictions, limiting where cloud scrubbing is permissible. **What does ‘on-prem’ mean?** On-prem (or ‘inline’) systems run inside your own ASN – physical appliances, virtual machines, or containerised detectors talking straight to your routers. Typical features: - NetFlow, sFlow, or packet capture for sub-second detection - BGP Remote Triggered Black Hole (RTBH) or Flow Spec for fast blocking - Full control of detection thresholds and mitigation logic **When is on-prem an attractive option?** Keeping the scrubbing kit inside your own racks means packets never leave the network path, so latency stays low. Because the controls live on your hardware, you can enforce fine-grained policy—dropping, rate-limiting or redirecting only the prefixes and ports you choose. Data privacy is easier to guarantee when traffic remains under the same compliance umbrella, and a one-off capital purchase (or a fixed annual licence) brings predictable spend instead of open-ended clean-traffic fees. **Where on-prem struggles?** The model falters if an attack exceeds available transit: once links saturate, no appliance can restore capacity until extra bandwidth or upstream filtering is in place. It also demands round-the-clock vigilance; smaller teams must be ready to watch alerts, tune thresholds and push emergency routing changes at any hour. **Why are hybrid models becoming more prevalent?** A hybrid setup mixes local detection with cloud off-load. The on-prem system watches flows from the first packet, scrubs small to medium floods, and invokes cloud scrubbing only when a threshold (for example 80 % of link capacity) is crossed. This “autoscaling” limits cloud bills while protecting against the true headline attacks. It also keeps latency in check for everyday traffic, because packets stay on-net unless a surge demands diversion. At the same time, operational teams keep a single view of both layers, making policy updates and post-incident reviews far simpler than juggling two isolated solutions. **How to choose the right mix?** - Measure baseline traffic – know your typical 95th percentile and peak spikes. - Assess uplink limits – if the largest single circuit is 40 Gbps, plan for floods above that size to divert early. - Factor response time – on-prem detection plus automated cloud API calls should move faster than manual ticketing. - Plan your test days – schedule live drills, flushing prefixes through the scrubber and back, to confirm routing and application behaviour. - Budget realistically – weigh capital spend on appliances against potential per-gigabit cloud costs during holiday peaks. **No single model fits every network** Latency-sensitive trading floors may lean local; SaaS providers with bursty traffic may lean cloud. For many operators, a hybrid design delivers the best of both worlds: on-prem agility for day-to-day events and cloud capacity for once-a-year floods. FastNetMon’s platform was built with that blend in mind. It spots anomalies fast, applies the right filter in the right place, and hands control back to your team rather than locking protection into one vendor’s black-box. If you’re mapping out the next stage of your DDoS defence, take a closer look at how FastNetMon can help you stitch local and cloud layers into a single, responsive shield. --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit <https://fastnetmon.com> **Categories:** FastNetMon Blog **Tags:** Network Security Insights --- ### [FastNetMon Advanced 2.0.374](https://fastnetmon.com/2026/03/09/fastnetmon-advanced-2-0-374/) **Published:** March 9, 2026 **Author:** FastNetMon **Content:** **Release date:** 9 March, 2026 **Version:** 2.0.374 FastNetMon Advanced 2.0.374 introduces multiple stability improvements, protocol enhancements, and new observability features. This release adds full MPLS parsing support for the sFlow v5 plugin, expanded Nokia SR Shim capabilities, and improved BGP functionality including better IPv6 next hop handling, BMP support, and per-hostgroup community configuration. It also introduces new API and CLI counters for specific networks and ASNs, enhanced packet visibility with ISO 8601 timestamps and additional TCP metadata, and improved Prometheus metrics. Several fixes address potential crashes, parsing issues, and database error handling, alongside improvements to IPFIX processing, MongoDB error reporting, and ClickHouse resilience when encountering corrupted database parts. ### Full list of changes: - Added fix to avoid crash in Clickhosue code when Clickhouse database is corrupted due to suspiciously many broken parts - Implemented full MPLS support for parser in sFlow v5 plugin and it can be enabled using sudp fcli set main sflow\_strip\_mpls\_tags - Added support of 32 bit next hop for IPv6 announces, addresses bug - We support only 16 byte next hop for IPv6 MP Reach NLRI but got 32 byte long next hop - Implemented single\_asn\_counters\_v4 and single\_asn\_counters\_v6 to get traffic for particular ASN - Added support for sampling configuration for Nokia SR Shim mode via option: app\_packet\_sr\_sampling\_ratio - Added support for Nokia SHIM version 2 - Added timestamp\_iso8601 for each packet in packet dump to provide human friendly date and time - Fixed for parsing URL for GET command to accept networks encoded as: 11.22.33.4%2f24 - Added API and CLI command to get counters for specific IPv6 network single\_network\_counters\_v6, IPv4 network single\_network\_counters\_v4 and specific /24 IPv4 network single\_network\_counters\_24\_v4 - Behaviour change: network\_counters,network\_counters\_24 and network\_counters\_v6 now return only 10 top talkers by traffic - Added ttls field for flexible filters - Added logic in parser to retrieve TCP window size, ack and seq numbers - Implemented logic for gobgp\_flow\_spec\_announces\_dry\_run\_mode which does not publish announces to RIB - Added error checking for .insert\_one() to catch why we cannot push information to MongoDB occasionally - Moved sFlow metrics to separate file - Added attack\_start and attack\_end in format iso8601 for per host and per hostgroup attack events - Added missing space for fastnetmon\_total\_traffic\_flows in Prometheus - Fixed bug with incorrect formatting for HELP field in Prometheus endpoint which led to error: decoding response failed: text format parsing error in line 4: second HELP line for metric name Total - Fixed typo which lead to crash of what(): boost::too\_few\_args: format-string referred to more arguments than were passed - Moved BGP daemon settings to independent class - Added BMP management options for our BGP daemon: gobgp\_bmp, gobgp\_bmp\_port, gobgp\_bmp\_host - Added logic to clean Enterprise bit for record\_type for IPFIX templates - Changed argument for ipfix\_record\_to\_flow to propagate whole template record - Added logic to print flow direction for IPFIX to debug log - Added vendor name for Juniper for enterprise record IDs - Improved IPFIX trace logic - Added configuration variables bgp\_next\_hops\_hostgroup\_networks\_ipv4 and bgp\_next\_hops\_hostgroup\_networks\_ipv6 to manage next hops for total hostgroups - Added counter netflow\_v9\_flows\_with\_sampling\_encoded\_in\_data\_packet\_number to track number of flows with sampling packet present in data Netflow v9 packets, this encoding is used by Mikrotik - Fixed error with inability to print next hop for IPv6 - Implemented logic to set per hostgroup BGP Communities using bgp\_communities\_hostgroup\_networks\_ipv4 and bgp\_communities\_hostgroup\_networks\_ipv6 for total hostgroups - Improved logic which retrieves incoming IPv6 announces to continue processing even if we had issues with one announce - Explicitly specified Content-Type to application/json for JSON callbacks ### Learn more [FastNetMon Advanced documentation](https://fastnetmon.com/docs-fnm-advanced/) [View this release on GitHub](https://github.com/FastNetMon/fastnetmon-advanced-releases/releases/tag/v2.0.374) **Categories:** Releases --- ### [Understanding the BGP Monitoring Protocol (BMP)](https://fastnetmon.com/2026/03/04/understanding-the-bgp-monitoring-protocol/) **Published:** March 4, 2026 **Author:** FastNetMon **Content:** ![](https://fastnetmon.com/wp-content/uploads/2026/03/Brian-Wilson.png) *This is a guest contribution from Brian Wilson (BGP Brian), creator of the BGP Black Belt community and educator focused on BGP operations.* **Border Gateway Protocol (BGP)** is the routing protocol of the Internet. It determines how traffic moves between autonomous systems and ultimately decides where packets go. But while BGP makes routing decisions, it doesn’t provide an easy way to *observe* those decisions at scale. To solve this visibility problem, a protocol called the **BGP Monitoring Protocol (BMP)** was developed. In this post, we’ll examine what BMP is and how it can be used for troubleshooting, visibility, and control-plane monitoring in modern networks. ## **What is BMP?** The **BGP Monitoring Protocol (BMP)** is a standardized protocol (RFC 7854) that allows routers to export detailed BGP control-plane information to an external monitoring system. Unlike BGP itself, BMP does not influence routing decisions. It is strictly observational. BMP streams routing updates and other BGP statistics from a router to a centralized collector in real time, giving engineers full visibility into what the router is seeing and doing. ![](https://fastnetmon.com/wp-content/uploads/2026/03/bmp-diagram-1024x558.png)## **The Visibility Challenge with BGP** Traditionally, engineers troubleshoot BGP using CLI commands such as: ``` show ip bgp show ip bgp neighbors [ip address] ``` This works well on individual routers. But in large enterprise or service provider networks, you might have hundreds of BGP peers, millions of prefixes, and complex route policies. If a prefix is missing or behaving unexpectedly, we might typically ask the following questions: - Did the peer send it? - Did inbound policy filter it? - Was it rejected due to AS path? - Was it withdrawn? Answering these questions by logging into each router individually does not scale. In large networks, it is far more efficient to maintain a centralized repository of BGP control-plane data. BMP enables this by continuously exporting BGP information from each router to a central data collector. ## **How BMP Works** BMP establishes a separate TCP session from a router to a monitoring station, known as a **BMP collector**. The collector’s IP address and port are configured under the BGP process on the router, and then activated per neighbor. For example: ``` router bgp 65000 bmp server 1 address 10.10.10.100 port 5000 neighbor 192.0.2.1 remote-as 65001 neighbor 192.0.2.1 bmp-activate server 1 ``` The BMP collector does not send any messages to the router but simply listens for incoming messages. Once the session is established, the router sends: - Initiation / Termination messages - Peer Up / Peer Down messages - Route Monitoring messages (initial BGP table dump + incremental route updates) - Statistics Reports (number of prefixes sent and received, etc) - Route Mirroring messages (allows exact duplication of a BGP session) One of BMP’s most powerful capabilities is its ability to export both: ### **Pre-Policy Routes** Routes exactly as received from a peer, before any route maps or filters are applied. ### **Post-Policy Routes** Routes after inbound policies have been applied, showing what was actually accepted into the BGP table. This distinction is critical. If a route disappears, BMP allows you to determine whether: - The peer never sent it - Your policy filtered it - It failed validation - It was withdrawn ## **Key Advantages of BMP** BMP provides several major advantages. ### **1. Scalable Troubleshooting** In networks with route reflectors and layered policies, control-plane visibility is essential. BMP provides centralized insight across all routers and peers. Instead of logging into devices individually, you analyze a unified stream of BGP activity. ### **2. Security Monitoring** BMP enables detection of: - Route leaks - Prefix hijacks - Unexpected mass withdrawals - Abnormal update churn Security teams can monitor routing behavior in near real time and correlate anomalies across the network. ### **3. Historical Analysis** Unlike CLI commands, BMP feeds collectors that store data over time. This enables: - Trend analysis - Churn measurement - Peer stability tracking - Capacity planning When something breaks, you can rewind and see exactly when and why it happened. ## **BMP in Route Reflector Environments** BMP is particularly valuable in route reflector architectures. Route reflectors simplify iBGP scaling, but they can obscure routing differences between clients. If one client is missing a route, troubleshooting can become difficult. With BMP enabled on route reflectors (or clients), you can see: - What each peer advertised - What policies accepted or rejected - What was reflected - What was installed For large-scale networks, this level of visibility is transformative. ## **Deployment Considerations** Before enabling BMP, keep a few factors in mind: - **CPU impact** – exporting full routing tables can be resource-intensive - **Bandwidth usage** – initial table dumps are large - **Storage requirements** – historical BGP data grows quickly - **Collector security** – control-plane data should be protected A best practice is to: - Start with route reflectors - Monitor system performance - Scale collectors appropriately Because BMP is observational and does not alter routing decisions, it can generally be deployed with low operational risk. ## **Final Thoughts** BMP offers advanced telemetry and diagnostic capabilities for BGP. In modern networks where many systems are centrally managed and software-driven, network-wide visibility into the BGP control plane is a significant operational advantage. BMP delivers continuous, real-time insight into BGP behavior, including which prefixes were received, filtered, and installed. It allows a full audit of BGP anomalies from a centralized location. And in large networks, that audit log can help resolve BGP issues in a fraction of the time it would take to manually troubleshoot via CLI. --- ### **About the Author** BGP Brian (Brian Wilson) runs a BGP training community on Discord called BGP Black Belt. He also regularly posts about BGP topics on LinkedIn. You can find him at [www.linkedin.com/in/brianwilson-bgp](http://www.linkedin.com/in/brianwilson-bgp). **Categories:** FastNetMon Blog **Tags:** BGP, BMP, guest post, network monitoring, Network Visibility --- ### [Geofeed RFC 9632: Why Operators Should Publish Their IP Geolocation Data](https://fastnetmon.com/2026/02/19/geofeed-rfc-9632-why-operators-should-publish-their-geoip-data/) **Published:** February 19, 2026 **Author:** FastNetMon **Content:** ## IP geolocation in the modern network stack IP geolocation data quietly influences a large number of operational decisions on today’s Internet. It affects: - Geo-based cybersecurity policies - Compliance and sanctions enforcement - Content licensing restrictions - Fraud detection systems - Traffic analytics and reporting Yet in most cases, the geographic location of IP address space is still determined by inference performed by third-party commercial databases. There is a better way. Geofeed, standardised in RFC 9632, allows network operators to publish authoritative geographic information for their own prefixes. It is a simple, standardised and independent workflow free of any vendor involvement. ### This article explains: - What Geofeed is and how it works - How it evolved and where adoption stands today - Why operators should take it seriously - How to publish IP geolocation data for your network ### Terminology note: Before going further, it is worth clarifying terminology. - **IP geolocation** refers to the process of mapping IP address space to geographic locations. This is a generic, industry-wide term describing the technical function, not a specific product. - **Geofeed** refers to the standardised mechanism defined in RFC 8805 and updated in RFC 9632 that allows network operators to publish authoritative IP-to-location mappings for their own prefixes. - **GeoIP** is a trademark of MaxMind and refers to that company’s product line. While the underlying concept of IP geolocation is vendor-neutral and implemented by many providers, the term “GeoIP” itself is not generic. In this article, we use the term *IP geolocation* to describe the broader ecosystem, and *Geofeed* to describe the standards-based publication mechanism. ## The IP geolocation accuracy problem ### **The uncomfortable reality: IP geolocation is mostly inference** Historically, and still partially today, most IP geolocation databases are built and maintained by commercial providers such as MaxMind and Digital Element. Their datasets are assembled using a combination of datapoints: - WHOIS and registry information - BGP announcements - Latency and topology measurements - Traffic observation - Customer-submitted corrections At Internet scale, this approach works surprisingly well. But it is still inference. There is no field in BGP that says “this prefix is physically located in Helsinki.” Registry objects were never designed to serve as structured, machine-readable geolocation sources. Routing data does not encode physical deployment geography. As a result, most commercial IP geolocation data is a best-effort approximation based on educated guessing. When the approximation is correct, nobody notices. But when something breaks, the guesswork becomes painfully obvious. ### When inference gets it wrong The failure modes are familiar to many network teams. For example, a company registered in one country deploys infrastructure in another, but databases map its prefixes to headquarters rather than physical location. Or, a recently transferred IPv4 space retains the previous owner’s country attribution for months. Another example would be when anycast prefixes are treated as single-location deployments. Also, hosting providers with globally distributed infrastructure may appear to exist in one jurisdiction only. These are not edge cases. They are natural consequences of a system built on inference rather than authoritative declaration. #### **Common IP geolocation misclassification scenarios** These are some of the very common and well-documented scenarios where IP geolocation data gets misclassified. - **Corporate registration vs physical deployment** - IP space registered to a UK company but physically deployed in Germany gets mapped to the UK. - Geo-based filtering now behaves incorrectly. - **Reassigned address space** - Transferred IPv4 blocks retain old country mappings in databases for months. - Traffic analytics and fraud systems misclassify users. - **Anycast and distributed infrastructure** - Anycast prefixes get treated as single-location deployments. - Country-level traffic reporting becomes misleading. - **Hosting and cloud providers** - Infrastructure deployed in multiple jurisdictions gets simplified into one country entry. ### The dirty laundry of bad data Network operators have historically had limited control over how their IP space is geographically represented on the Internet. Yet when inaccurate IP geolocation data causes problems, it is the operators who are expected to resolve them. When location data is incomplete or incorrect, the remediation process is rarely straightforward. Correcting errors typically requires opening support tickets with each IP geolocation database provider individually. Operators have no control over the timelines, internal workflows or prioritisation decisions of commercial vendors, who may not share the same operational urgency. Even after a correction is accepted, propagation across downstream consumers is not always predictable. Some services update quickly; others refresh data on longer cycles. In the meantime, filtering rules, analytics systems and compliance controls may continue operating on outdated information. It is not difficult to understand why many operators concluded that there had to be a better way — one where authoritative data could be published directly, rather than negotiated indirectly through vendor processes. ## The solution: Geofeed under RFC 9632 ### How it works Geofeed introduces a simple but important shift. Instead of relying purely on inference, the address holder can publish authoritative location data. Under RFC 9632, an operator creates a publicly accessible, machine-readable CSV file that maps IP prefixes to geographic information. Each entry includes: - IPv4 or IPv6 prefix - Country code (ISO 3166-1 alpha-2) - Optional region - Optional city A minimal example looks like this: 203.0.113.0/24,FI,Uusimaa,Helsinki 2001:db8::/32,GB,England,London The file is hosted over HTTPS and referenced from the relevant RIR object (inetnum/inet6num) or exposed via RDAP. IP geolocation database providers can automatically discover and ingest the data. ### Why it works The design philosophy of RFC 9632 is intentional: - Minimal format - No proprietary API - No central authority - No vendor dependency This moves IP geolocation from a vendor-inferred model to an operator-declared model. This mirrors other developments in Internet hygiene. RPKI allows operators to declare valid route origins. IRR allows them to publish routing policy. Geofeed allows them to declare geographic location. In each case, authoritative publication reduces ambiguity. For operators who already maintain accurate IPAM data, Geofeed is not about creating new information. It is about exposing existing truth in a structured, ecosystem-consumable way. ## History and adoption ### How it started: RFC 8805 in 2020 Geofeed was first standardised in 2020 through RFC 8805. Over time, the community refined the mechanism based on real-world deployment experience, leading to the publication of RFC 9632 in 2024. Before standardisation, some networks experimented with informal methods. A few operators published CSV files describing prefix-to-location mappings, and certain IP geolocation providers began consuming them on an ad hoc basis. However, there was no agreed format, no discovery mechanism and no consistent validation model. This informal ecosystem highlighted two things: 1. Operators wanted a way to declare authoritative IP geolocation data. 2. Vendors were willing to consume it, but they needed a standardised format. That led to the development of RFC 8805, published in 2020. RFC 8805 formally defined: - The CSV format - Field structure and ordering - Discovery via RIR inetnum/inet6num objects - Basic validation expectations It was intentionally simple. The goal was not to build a complex geolocation framework, but to introduce a lightweight mechanism that could be widely adopted. ### Operational maturity and refinement Between 2020 and 2024, real-world deployment exposed edge cases and ambiguities: - Clarifications were needed around file formatting and validation behaviour. - RDAP-based discovery became more important as registry systems evolved. - Operators needed clearer guidance on handling overlapping or granular prefixes. Rather than replacing the mechanism, the IETF refined it. This work resulted in RFC 9632, published in 2024. RFC 9632 obsoletes RFC 8805 but does not fundamentally redesign Geofeed. Instead, it: - Clarifies validation requirements - Improves alignment with RDAP-based discovery - Incorporates operational lessons learned - Strengthens interoperability expectations This transition marked an important point: Geofeed moved from initial deployment into a more mature and operationally stable phase. Today, Geofeed is no longer experimental. It is a stable IETF standard backed by several years of production deployment experience. From a protocol lifecycle perspective, Geofeed has passed the “early concept” stage. The remaining challenge is not technical viability; it is ecosystem adoption. ### Steady growth but incomplete coverage Adoption has grown steadily since 2020. The most detailed public measurement study from late 2023 observed roughly 34 million IPv4 addresses published in geofeed files, representing around 0.8% of globally allocated IPv4 space. Approximately 2,800 autonomous systems were publishing feeds at that time, equating to only a few percent of all ASNs. Since then, additional operators — particularly in IPv6 space — have begun publishing feeds. Major networks and infrastructure providers have integrated Geofeed into their workflows. The direction of travel is clearly upward. However, the broader picture remains the same: the majority of networks still do not publish authoritative IP geolocation data. As long as adoption remains partial, most IP geolocation databases will continue to rely primarily on inference. The ecosystem benefits of Geofeed increase with participation, but we are not yet at the point where operator-declared data dominates. This creates a clear opportunity — and arguably a responsibility — for network operators. ## Why operators should adopt Geofeed now Geofeed under RFC 9632 is arguably the best way to publish geographic information about your IP space without relying on commercial IP geolocation providers. It is standardised, simple and field-tested. With RFC 9632, the mechanism is mature and production-grade. At this point, publishing authoritative IP geolocation data should not be optional for serious operators. If you do not publish a Geofeed, your prefixes will still be geolocated — just not by you. ### What can go wrong without Geofeed? - **Unintended traffic filtering** Country-based filtering may block legitimate traffic if prefixes are misclassified. - **Compliance risk** Over-blocking or under-blocking due to incorrect country attribution. - **Weakened fraud detection** Inaccurate geolocation reduces signal quality in risk-scoring systems. - **Misleading analytics** Country-level traffic reporting may not reflect actual deployment. - **Slow correction cycles** Fixing errors requires vendor tickets and unpredictable propagation. Geofeed does not solve every IP geolocation issue. But it replaces inference with operator-declared data — a material improvement for systems that depend on geographic signals. ### The strategic question If you do not publish authoritative data, others will classify your network for you. For small networks, that may be tolerable. For larger or distributed operators, it introduces unnecessary uncertainty. Geofeed is a low-effort, standards-based way to regain control over how your IP space is represented. The protocol is mature. The ecosystem support exists. The remaining step is adoption. ## How to publish a Geofeed Deploying Geofeed is generally straightforward, but it should be treated as a formal operational task rather than an afterthought. First, generate a clean and consistent CSV file from your IPAM system. Ensure prefixes are valid, properly aggregated, and accurately mapped to ISO 3166-1 alpha-2 country codes. Avoid overlapping or conflicting entries. Strict adherence to RFC 9632 formatting rules is important, as ingestion systems may reject malformed files. Second, host the file over HTTPS at a stable, publicly accessible URL. Avoid unnecessary redirects and monitor availability. Reliability matters; if the file becomes inaccessible, automated ingestion may fail. Third, add the geofeed attribute to the relevant inetnum or inet6num object in your RIR database. Verify via RDAP that the reference is visible externally. Discovery depends on this linkage. Finally, integrate Geofeed maintenance into your IP lifecycle processes. When prefixes are reassigned, moved geographically or decommissioned, the Geofeed file must be updated. Treat it with the same discipline as RPKI ROAs or IRR route objects. ## Closing thoughts Geofeed under RFC 9632 provides a simple, standardised mechanism for publishing authoritative IP geolocation data. It addresses a long-standing structural gap in how geographic information about IP space is shared. Adoption is growing, but it is still far from universal. Most IP geolocation data remains inference-based, even though operators are in the best position to declare accurate information. For networks that already maintain structured IPAM data, publishing a Geofeed requires limited additional effort. The benefits — improved accuracy, reduced dependency on vendor correction workflows and stronger alignment between operational reality and public data — are tangible. At this point, Geofeed should be viewed not as an experimental feature, but as part of modern network hygiene. The mechanism is stable. The operational cost is low. The ecosystem impact increases with every additional operator who chooses to participate. **Categories:** FastNetMon Blog, Featured **Tags:** Network Security Insights --- ### [ASPA: the next layer of routing security](https://fastnetmon.com/2026/02/25/aspa-the-next-layer-of-routing-security/) **Published:** February 25, 2026 **Author:** FastNetMon **Content:** For more than a decade, RPKI and Route Origin Validation (ROV) have helped reduce accidental prefix hijacks. Today, it is much harder for a network to incorrectly announce someone else’s address space without being detected. But origin validation never answered a deeper question: *Is this AS path economically and topologically plausible?* That gap is what Autonomous System Provider Authorization — ASPA — is designed to close. And in early 2026, ASPA moved from standards discussions into operational availability: With ARIN [announcing full ASPA availability](https://www.arin.net/announcements/20260120/) in its January 2026 ARIN Online release, ASPA publishing is now production-ready in both the ARIN and RIPE NCC regions. This is what ASPA is, why it exists, and why network engineers should start paying attention. ## **What ASPA actually does** ASPA is a new RPKI object type standardised through the Internet Engineering Task Force (IETF), specifically in the SIDROPS working group. In simple terms, it allows an AS holder to declare: “These ASNs are my authorised upstream providers.” That declaration is cryptographically signed and published in RPKI. Routers that consume validated RPKI data can then check whether the AS\_PATH in BGP updates aligns with those declared customer–provider relationships. If a path contradicts published ASPA data, it can be marked invalid. Unlike BGPsec, which attempted full path cryptographic validation and saw limited deployment, ASPA takes a pragmatic approach. It does not attempt to sign every hop in the path. It validates only provider relationships, relying on long-standing “valley-free” routing assumptions. That trade-off makes deployment realistic. ## **Why origin validation wasn’t enough** ROV solved a major problem: prefix hijacking. But many of the most disruptive routing incidents in the past decade were not hijacks. They were route leaks. In a route leak scenario: - The origin AS is legitimate. - The prefix is valid under RPKI. - But the route is propagated through an unexpected provider chain. From the perspective of origin validation, everything looks fine. From an economic and operational perspective, it is clearly wrong. ASPA targets exactly this class of failure. It allows networks to detect when a customer is announcing routes in ways that contradict declared upstream relationships — a strong signal of a leak. ## **How ASPA verification works in practice** Operationally, ASPA extends the same toolchain already used for RPKI: 1. An AS publishes an ASPA object listing its upstream providers. 2. RPKI validators fetch and validate the object. 3. Routers receive validated ASPA payloads via the RPKI-to-router protocol. 4. Routers perform AS\_PATH verification locally. No new cryptography is required inside the router. Verification produces three possible states: - **Valid - **Invalid - **Unknown The recommended deployment pattern mirrors early ROV: - Reject invalid customer routes. - Accept valid and unknown. - Start with monitoring before enforcement. Even partial deployment can detect a significant class of route leaks. ## **The long road to deployment** Work on ASPA began around 2019–2020 in the IETF, after years of analysis of route leak incidents. By 2022–2024, the object profile and verification procedures had matured through multiple draft iterations. But standards are only half the story. Operational adoption depends on three layers: - RIR support for publishing objects - Validator support - Router implementation On the RIR side, progress has been very recent: In December 2025, the [RIPE NCC integrated ASPA into its production RPKI Dashboard](https://labs.ripe.net/author/tim_bruijnzeels/aspa-in-the-rpki-dashboard-a-new-layer-of-routing-security/?utm_source=chatgpt.com), making it available to operators across its service region. And even more recently, in January 2026, [ARIN announced](https://www.arin.net/announcements/20260120/): “ARIN’s implementation of Autonomous System Provider Authorizations (ASPA) is now fully available in ARIN Online as part of the RPKI security features.” Elsewhere, rollout timelines are becoming clearer. APNIC has indicated that ASPA support is planned for deployment by the end of Q2 2026. LACNIC has publicly committed to adding ASPA capability by the end of 2026 as part of its broader RPKI programme updates. AFRINIC has also signalled intent to support ASPA within its evolving RPKI roadmap, though specific production timelines remain dependent on organisational developments. At the software layer, ASPA object validation is supported in major relying-party implementations. Router-side path verification is available in Bird and OpenBGPD, with implementation and testing underway in Cisco IOS-XR. Wider vendor support is expected to follow operator demand. We are still early, but the pieces are assembling fast. ## **Adoption still remains low** Despite the infrastructure now existing in key regions, ASPA adoption remains minimal. Only a very small fraction of ASNs globally have published ASPA records as per February 2026: well under one percent of the global ASN space. This is not unusual. ROV followed a similar trajectory: years of discussion, early cautious deployment, then gradual acceleration. But ASPA’s value increases with participation. The more ASNs that publish provider relationships, the stronger path validation becomes. With sparse coverage, many paths will simply fall into the “unknown” category. ASPA’s effectiveness is directly tied to ecosystem participation. ## **Why opt to publish ASPA?** There is a subtle but important point here. Even before you enforce ASPA validation on your routers, publishing accurate ASPA records contributes to global routing security. ### Benefits of publishing ASPAs: - You make it harder for malicious actors to fabricate plausible AS paths involving your ASN. - You reduce the risk of your ASN being misused in leaked transit scenarios. - You improve the quality of data available for path validation across the ecosystem. - You prepare your network for future enforcement without rushing later. Much like early ROA publication strengthened origin validation before universal enforcement, early ASPA publication strengthens the foundation for path validation. Waiting until validation becomes widespread increases operational risk. Publishing early allows careful testing, monitoring, and correction. ## **Operational responsibility** ASPA is not “set and forget.” When you publish an ASPA, you commit to maintaining an accurate list of upstream providers. If you omit one, ASPA-aware networks may mark routes via that provider as invalid once enforcement becomes common. Complex relationships, including hybrid peer/provider arrangements and certain route server deployments, require careful review. This is operational work. But it is work that aligns with the discipline already required for ROA management. ## **Final thoughts about the important shift to ASPA** ASPA does not change BGP. It does not introduce heavy cryptographic overhead. It does not require synchronised global deployment. Instead, it encodes economic relationships into RPKI and allows routers to verify whether observed AS paths make sense. With ARIN joining RIPE NCC in offering production ASPA publication, ASPA has crossed an important threshold. Adoption is still low. Enforcement is still cautious. Vendor implementation is still maturing. But the direction is clear: ROA-based origin validation became the norm because operators made it so. ASPA should be the next foundational layer of routing security — and its success depends on operators publishing now. **Categories:** FastNetMon Blog, Featured --- ### [Network Engineering Community News: November 2025](https://fastnetmon.com/2024/11/30/network-engineering-community-news-november-2025/) **Published:** November 30, 2024 **Author:** FastNetMon **Content:** Network Engineering Community News – FastNetMon # Welcome to our Network Engineering Community News! Hi from FastNetMon! November came with plenty to talk about. We’ve got a standout guest post from one of the most recognisable voices in BGP, a very cool webinar to help you shape your DDoS strategy for 2026, an early look at a product update we’re very excited about, and—as always—fresh insights from the DDoS battlefield. Happy reading! Want this letter straight to your inbox? Sign up to our monthly Network Engineering Community News [here](https://cdn.forms-content.sg-form.com/b3c8181d-c30d-11ef-b203-ca12671f70d2). --- ## On automating BGP Blackhole for DDoS mitigation: BGP Brian explains [ ![BGP Brian Article](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff8a0299c956ef43d12ab7f1a40ef114862c0b64df77fe9c6c08a1ed16341ae0/images/bgp_brian_blackhole_guest_post.png) ](https://fastnetmon.com/2025/11/14/bgp-blackhole-for-ddos-mitigation-and-how-to-automate-it-with-fastnetmon/) We’re excited to welcome BGP Brian (Brian Wilson) as a guest contributor for FastNetMon! In this article, Brian explains how BGP blackholing (RTBH) can be used to stop DDoS attacks before they reach your network—and how FastNetMon can automate the process for faster, more consistent mitigation. Brian runs a BGP Black Belt training community, and is very active on LinkedIn, sharing insights on BGP and network engineering – you can follow Brian [here](https://www.linkedin.com/in/brianwilson-bgp/). [READ BRIAN'S ARTICLE](https://fastnetmon.com/2025/11/14/bgp-blackhole-for-ddos-mitigation-and-how-to-automate-it-with-fastnetmon/) --- ## Get your anti-DDoS game ready for 2026! Join our joint webinar with StormWall [ ![Webinar with StormWall](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff8a0299c956ef43d12ab7f1a40ef114862c0b64df77fe9c6c08a1ed16341ae0/images/fastnetmon_x_stormwall_webinar.png) ](https://get.stormwall.pro/webinar-from-detection-to-protection-2026) On December 9 at 11:00 AM CET, FastNetMon and StormWall host a joint webinar to walk you through what we learned from DDoS attacks in 2025, and what teams should prepare for in 2026. Virgil Truica from our team will be presenting. We’ll cover how attack patterns are changing, why multi-vector attacks are becoming more common, and when to use Always-On vs On-Demand mitigation. We’ll also explain how FastNetMon and StormWall work together – from early detection to effective mitigation. If you want a clear, practical view of how to strengthen your DDoS defences for next year, join us in the webinar! [SIGN UP](https://get.stormwall.pro/webinar-from-detection-to-protection-2026) --- ## Sneak peek to our new web interface! 👀 ![New Web Interface](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff8a0299c956ef43d12ab7f1a40ef114862c0b64df77fe9c6c08a1ed16341ae0/images/web_interface_fastnetmon.png) FastNetMon has always been a command-line tool for monitoring network traffic and detecting attacks. Soon, it will also include a web interface! We’re genuinely excited about this update. The new UI gives you real-time dashboards, traffic reports, hostgroup overviews, and clear visibility into ongoing attacks. Same reliable functionality, now easier to visualise. Launch is coming soon, stay tuned! --- ## Event Recap: LINX125 [ ![LINX125 Recap](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff8a0299c956ef43d12ab7f1a40ef114862c0b64df77fe9c6c08a1ed16341ae0/images/event_recap_linx125_london_internet_exchange_fastnetmon.png) ](https://fastnetmon.com/2025/11/21/event-recap-linx125/) Last week we attended LINX125 in London as an Ascending Member. It was a great chance to meet the community, see how LINX operates, and hear talks on network resilience, peering strategies, AI data centres, and even the history of BT Tower. Big thanks to LINX and all the speakers for making it such an interesting couple of days. You can read our event recap in the blog! [READ THE RECAP](https://fastnetmon.com/2025/11/21/event-recap-linx125/) --- ## Industry News Here are some interesting industry takes and major DDoS incidents you should know about. Enjoy the reading! [ ![Sanctions on bulletproof hosting](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff8a0299c956ef43d12ab7f1a40ef114862c0b64df77fe9c6c08a1ed16341ae0/images/allies_sanction_russian_bulletproof_ddos_hosting_providers.png) ](https://fastnetmon.com/2025/11/21/us-uk-and-australia-sanction-russian-hosting-providers-behind-major-ransomware-and-ddos-activity/) **Coordinated sanctions target Russia-based bulletproof hosting providers long used for ransomware and DDoS activity.** Read the story [here](https://fastnetmon.com/2025/11/21/us-uk-and-australia-sanction-russian-hosting-providers-behind-major-ransomware-and-ddos-activity/). [ ![ShadowRay 2.0 Botnet](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff8a0299c956ef43d12ab7f1a40ef114862c0b64df77fe9c6c08a1ed16341ae0/images/ddos_news_shadowray_20_selfreplicating_botnet_that_launches_ddos_attacks_fastnetmon.png) ](https://fastnetmon.com/2025/11/21/shadowray-2-0-self-replicating-botnet-turns-ray-clusters-into-ddos-weapons/) **ShadowRay 2.0 hijacks exposed Ray clusters worldwide, turning AI workloads into self-propagating DDoS bots.** Over 230,000 clusters at risk—find out how the botnet spreads and what defenders can do [here](https://fastnetmon.com/2025/11/21/shadowray-2-0-self-replicating-botnet-turns-ray-clusters-into-ddos-weapons/). [ ![Hezi Rash Hacktivist Group](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff8a0299c956ef43d12ab7f1a40ef114862c0b64df77fe9c6c08a1ed16341ae0/images/hezi_rash_new_hacktivist_group_linked_to_350_ddos_attacks_worldwide.png) ](https://fastnetmon.com/2025/11/07/hezi-rash-new-hacktivist-group-claims-over-350-ddos-attacks-worldwide/) **Hezi Rash, a new hacktivist group, claims over 350 DDoS attacks worldwide in just months, targeting governments, media and financial services.** Read the news [here](https://fastnetmon.com/2025/11/07/hezi-rash-new-hacktivist-group-claims-over-350-ddos-attacks-worldwide/). [ ![BLIK Mobile Payment Outage](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff8a0299c956ef43d12ab7f1a40ef114862c0b64df77fe9c6c08a1ed16341ae0/images/ddos_attacks_disrupt_polands_blik_mobile_payment_system.png) ](https://fastnetmon.com/2025/11/07/ddos-attacks-disrupt-polands-leading-mobile-payment-system-blik/) **Poland’s top mobile payment platform BLIK was hit by DDoS attacks, causing intermittent outages.** High visibility makes financial services a growing target—read more [here](https://fastnetmon.com/2025/11/07/ddos-attacks-disrupt-polands-leading-mobile-payment-system-blik/). --- ## 💌 Get this newsletter straight to your inbox Sign up to our monthly Network Engineering Community News [here](https://cdn.forms-content.sg-form.com/b3c8181d-c30d-11ef-b203-ca12671f70d2). --- **Categories:** Newsletter --- ### [Network Engineering Community News: June 2025](https://fastnetmon.com/2025/06/25/network-engineering-community-news-june-2025/) **Published:** June 25, 2025 **Author:** FastNetMon **Content:** Greetings from FastNetMon, your fast and reliable DDoS detection solution provider. Here's your monthly dosis of hottest industry events, network security threats, and useful product updates we think you should know to keep your networks safe. Enjoy! # ⚡️ Network Engineering Community News Hello from FastNetMon! This month’s newsletter includes two sharp DDoS strategy insights you won’t want to miss, a very unique book review, key takeaways from TRNOG and Infosec Europe, and a round-up of the most interesting industry news to keep you informed and your network secure. If you want to get this newsletter straight to your inbox, sign up [here](https://cdn.forms-content.sg-form.com/b3c8181d-c30d-11ef-b203-ca12671f70d2) ## 🛡️ Inside the Stack: Building a Layered DDoS Defence Strategy ![DDoS Defence Diagram](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff8a0299c956ef43d12ab7f1a40ef114862c0b64df77fe9c6c08a1ed16341ae0/images/multilayeredddosdefencefastnetmon.png)This blog post breaks down the practical implementation of multi-layered DDoS protection, covering BGP Flowspec, RTBH, inline filtering, and scrubbing. Each layer helps real-time mitigation and resilient service continuity. [Read the article](https://fastnetmon.com/2025/05/28/building-a-multi-layered-ddos-defense-architecture/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=building-a-multi-layered-ddos-defense-architecture&utm_term=june) ## 🌍 Event Recap: TRNOG Izmir TRNOG Izmir gathered amazing network operators for a day of practical, technical exchange. FastNetMon shared insights on scalable DDoS mitigation and took away ideas on IXP growth and automation. [Read event recap](https://fastnetmon.com/2025/05/27/event-recap-trnog-izmir?utm_medium=email+&utm_source=newsletter&utm_campaign=all&utm_content=trnog-izmir&utm_term=june) ## 🔐 Event Recap: Infosecurity Europe This year’s Infosecurity Europe was full of energy — with the spotlight on AI, automation, and real-world resilience. We talked to security professionals tackling DDoS, supply chain risks, and SOC tooling. [Read event recap](https://fastnetmon.com/2025/06/05/event-recap-infosecurity-europe-2025/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=inforsecurity-europe&utm_term=june) ## 📚 Book Recommendation: A Must-Read on DDoS ![DDoS Book Cover](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff8a0299c956ef43d12ab7f1a40ef114862c0b64df77fe9c6c08a1ed16341ae0/images/ddos_in_the_book.png)*DDoS: Understanding Real-Life Attacks and Mitigation Strategies* by Stefan Behte is the most practical and hands-on book on DDoS we’ve seen in years. Packed with real-world examples and configs. [Read our full review](https://fastnetmon.com/2025/06/25/book-review-ddos-understanding-real-life-attacks-and-mitigation-strategies-by-stefan-behte/) ## 📰 Industry News Round-up Here are some interesting industry takes and major DDoS incidents you should know about. Enjoy the reading!: - **📈 Record breaking 7.3 Tbps:** A new record was set with a 7.3 Tbps DDoS attack blocked at the edge, one of the most intense seen to date. Our analysis breaks down what made it possible, and what defenders need to learn from it. Dig into details [here](https://fastnetmon.com/2025/06/23/internet-under-fire-analysis-of-the-record-breaking-7-3-tbps-ddos-attack/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=record-breaking-7-3-tbps-ddos-attack&utm_term=june) - **🎯 DDoS has a new hit list:** Universities, journalists, and NGOs are now in the crosshairs of DDoS attackers, signalling a broader weaponisation of DDoS as a tool for disruption, not just profit. Read all about it [here](https://fastnetmon.com/2025/06/19/ddos-attacks-are-now-targeting-journalists-universities-ngos-what-has-changed/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=ddos-new-hit-list&utm_term=june) - **🚨 6.3 Tbps DDoS attack against a cybersecurity blog:** The latest DDoS attack on KrebsOnSecurity clocked in at 6.3 Tbps in under a minute. Speed and scale are accelerating, leaving less room for human-in-the-loop mitigation. Full story is [here](https://fastnetmon.com/2025/05/27/6-3-tbps-in-45-seconds-what-the-latest-assault-on-krebsonsecurity-tells-us-about-hyper-volumetric-ddos/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=6-3-tbps-in-45-seconds-assault-on-krebsonsecurity&utm_term=june) - **🤔 DDoS to demand open source:** A recent DDoS attack took down the Byond game engine, pushing its developers to rethink how much control should rest in closed, centralised hands. How the attack unfolded read [here](https://fastnetmon.com/2025/06/05/ddos-attack-targets-byond-game-engine-in-push-to-open-source-it/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=ddos-attack-targets-byond&utm_term=june) ## 💌 Get this newsletter straight to your inbox Sign up to our monthly Network Engineering Community News [here](https://cdn.forms-content.sg-form.com/b3c8181d-c30d-11ef-b203-ca12671f70d2) **Categories:** Newsletter **Tags:** Community, Newsletter --- ### [Network Engineering Community News: September 2025](https://fastnetmon.com/2025/09/25/network-engineering-community-news-september-2025/) **Published:** September 25, 2025 **Author:** FastNetMon **Content:** # Welcome to our Network Engineering Community News! Hi from FastNetMon! September has been anything but quiet: record-scale DDoS attacks, new botnets, and plenty of network security updates kept us busy. In this issue, we’re sharing a practical telemetry guide, recapping our recent webinar, and bringing news from RONOG 10. And as usual, we're rounding up the latest DDoS news you don’t want to miss. Enjoy! Want this letter straight to your inbox? Sign up to our monthly Network Engineering Community News [here](https://cdn.forms-content.sg-form.com/b3c8181d-c30d-11ef-b203-ca12671f70d2). --- ## FastNetMon detects a record scale 1.5Gpps attack ![Record DDoS](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff8a0299c956ef43d12ab7f1a40ef114862c0b64df77fe9c6c08a1ed16341ae0/images/detectedandmitigatedddosattacktrafficfastnetmon.jpg) Earlier this month, FastNetMon picked up one of the largest DDoS attacks ever seen in the wild—**1.5 billion packets per second** at peak. Numbers that big show how today’s attackers are pushing networks harder than ever and forcing defences to react in real time. The story made waves across the industry: - **[BleepingComputer:](https://www.bleepingcomputer.com/news/security/ddos-defender-targeted-in-15-bpps-denial-of-service-attack/)** *“The attack originated from thousands of IoTs and MikroTik routers, and it was mitigated by FastNetMon, a company that offers protection against service disruptions.”* - **[The Register:](https://www.theregister.com/2025/09/11/fastnetmon_ddos_attack/)** *“A DDoS mitigation provider was given a taste of the poison it tries to prevent, after being smacked by one of the largest packet-rate attacks ever recorded.”* - **[SC Media:](https://www.scworld.com/brief/massive-ddos-attack-discovered-mitigated)** *“Threat actors have launched a distributed denial-of-service attack peaking at 1.5 billion packets per second against an unnamed European DDoS scrubbing vendor.”* - **[Cybersecurity News:](https://cybersecuritynews.com/1-5-billion-packets-per-second-ddos-attack-detected/)** *“The malicious traffic was primarily a UDP flood launched from compromised customer-premises equipment (CPE), including IoT devices and routers, across more than 11,000 unique networks worldwide.”* --- ## Webinar Recap: FastNetMon & Inter.link on Network Threat Landscape 2025 [ ![Webinar Recap](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff8a0299c956ef43d12ab7f1a40ef114862c0b64df77fe9c6c08a1ed16341ae0/images/fastnetmon_interlink_webinar_network_threat_landscape_2025.png) ](https://www.youtube.com/watch?v=BhNCCfnAN1Q) Earlier this month, FastNetMon joined forces with Inter.link for a live panel diving into the current network threat landscape. Pavel Odintsov and Ciprian Abaseaca unpacked the latest DDoS trends, from record-breaking attacks like the recent 1.5 Gpps assault to the emergence of highly accessible botnets that were once only within reach of state actors. Hear them out on how detection and mitigation work hand-in-hand to keep networks running smoothly, offering practical insights for engineers and security teams alike. If you missed the live session, the full discussion is now available on YouTube - catch the key insights and strategies straight from the experts. [WATCH ON YOUTUBE](https://www.youtube.com/watch?v=BhNCCfnAN1Q) --- ## LACNIC ft. Pavel Odintsov: Making sense of network telemetry [ ![LACNIC Blog: Network Telemetry](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff8a0299c956ef43d12ab7f1a40ef114862c0b64df77fe9c6c08a1ed16341ae0/images/screenshot_20250923_at_163912.png) ](https://blog.lacnic.net/en/making-sense-of-network-telemetry-a-practical-guide-for-operators/) In his latest blog featured on LACNIC, our CTO Pavel Odintsov walks readers through network telemetry, breaking down flow-based and packet-based approaches in a way that’s easy to follow. Whether you’re monitoring traffic, spotting anomalies, or planning incident responses, this guide gives practical tips to help network engineers and operators make sense of the data that matters most. [READ THE GUIDE](https://blog.lacnic.net/en/making-sense-of-network-telemetry-a-practical-guide-for-operators/) --- [ ![DDoS Taxonomy Guide](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff8a0299c956ef43d12ab7f1a40ef114862c0b64df77fe9c6c08a1ed16341ae0/images/screenshot_20250820_at_141224.png) ](https://fastnetmon.com/2025/07/25/classification-of-ddos-attacks-every-modern-ddos-attack-vector-explained/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=classification-of-ddos-attacks&utm_term=august) ## DDoS Taxonomy DDoS attacks aren’t all the same, and treating them as if they are often leads to poor defences. In this guide, you'll find every major DDoS attack vector, from floods at L3/L4 to the more complex L7 patterns, and explain how they work in practice. It’s a practical taxonomy you can use to better understand, detect, and mitigate real-world attacks. [ READ HERE ](https://fastnetmon.com/2025/07/25/classification-of-ddos-attacks-every-modern-ddos-attack-vector-explained/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=classification-of-ddos-attacks&utm_term=august) --- ## From RONOG 10: 2025 DDoS patterns, tips and insights ![RONOG 10 DDoS Session](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff8a0299c956ef43d12ab7f1a40ef114862c0b64df77fe9c6c08a1ed16341ae0/images/ronog10_newsletter.png) We were at RONOG 10, catching up with the network engineering community and sharing insights on the latest DDoS trends. Virgil from our team presented on attack patterns, mitigation strategies, and what operators should watch for in 2025. While we’re still putting together a full event recap, you can check out the slides from the presentation to get the key takeaways. [ GET THE PRESENTATION ](https://fastnetmon.com/wp-content/uploads/2025/09/DDoS-Attacks-2025-Trends-and-Mitigation-RONOG10_final.pdf?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=ronog10_ddos_attacks_trends&utm_term=september) --- ## Industry News Here are some interesting industry takes and major DDoS incidents you should know about. Enjoy the reading! [ ![22.2Tbps DDoS record](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff8a0299c956ef43d12ab7f1a40ef114862c0b64df77fe9c6c08a1ed16341ae0/images/screenshot_20250924_at_124233.png) ](https://fastnetmon.com/2025/09/23/a-new-world-record-ddos-attack-22-2-tbps/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=ddos-attack-22-2-tbps&utm_term=september) **The bar just moved again.** Attack volumes continue to hit new highs, with a flood peaking at 22.2Tbps. How can networks withstand traffic levels once thought impossible? Find details [here](https://fastnetmon.com/2025/09/23/a-new-world-record-ddos-attack-22-2-tbps/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=ddos-attack-22-2-tbps&utm_term=september). [ ![1.5 billion packets per second](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff8a0299c956ef43d12ab7f1a40ef114862c0b64df77fe9c6c08a1ed16341ae0/images/screenshot_20250923_at_152344.png) ](https://fastnetmon.com/2025/09/09/1-5-billion-packets-per-second-ddos-attack-detected-with-fastnetmon/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=1-5-bpps-fastnetmon-detected&utm_term=september) **FastNetMon caught one of the most intense packet-rate assaults ever observed, measuring 1.5 billion packets every second.** How do attackers push packet floods to extremes? Read [here](https://fastnetmon.com/2025/09/09/1-5-billion-packets-per-second-ddos-attack-detected-with-fastnetmon/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=1-5-bpps-fastnetmon-detected&utm_term=september). [ ![Arch Linux DDoS](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff8a0299c956ef43d12ab7f1a40ef114862c0b64df77fe9c6c08a1ed16341ae0/images/screenshot_20250924_at_125908.png) ](https://fastnetmon.com/2025/08/26/arch-linux-confirms-week-long-ddos-attack-on-core-infrastructure/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=ddos-arch-linux&utm_term=september) **Arch Linux confirmed that a week-long DDoS assault hampered its core infrastructure and mirrors.** Open-source platforms, despite their resilience, are not immune to persistent disruption. More info [here](https://fastnetmon.com/2025/08/26/arch-linux-confirms-week-long-ddos-attack-on-core-infrastructure/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=ddos-arch-linux&utm_term=september). [ ![Cambridge study DDoS-for-hire](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff8a0299c956ef43d12ab7f1a40ef114862c0b64df77fe9c6c08a1ed16341ae0/images/screenshot_20250924_at_130717.png) ](https://fastnetmon.com/2025/09/11/cambridge-study-examines-global-law-enforcement-efforts-against-ddos-for-hire-services/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=cambridge-study-against-ddos-for-hire&utm_term=september) **Cambridge’s latest study looks at global efforts to shut down DDoS-for-hire ops.** It shows a mix of achievements and frustrations as the underground market adapts and resurfaces. Full story [here](https://fastnetmon.com/2025/09/11/cambridge-study-examines-global-law-enforcement-efforts-against-ddos-for-hire-services/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=cambridge-study-against-ddos-for-hire&utm_term=september). ## 💌 Get this newsletter straight to your inbox Sign up to our monthly Network Engineering Community News [here](https://cdn.forms-content.sg-form.com/b3c8181d-c30d-11ef-b203-ca12671f70d2) **Categories:** Newsletter **Tags:** Community, Newsletter --- ### [Network Engineering Community News: October 2025](https://fastnetmon.com/2025/10/30/network-engineering-community-news-october-2025/) **Published:** October 30, 2025 **Author:** FastNetMon **Content:** # Welcome to our Network Engineering Community News! Hi from FastNetMon! October brought plenty of tricks and treats on the network front: outbound DDoS attacks, new botnets lurking in misconfigured servers, Linux updates that improve resilience under DDoS attacks, and much more. Happy reading! Want this letter straight to your inbox? Sign up to our monthly Network Engineering Community News [here](https://cdn.forms-content.sg-form.com/b3c8181d-c30d-11ef-b203-ca12671f70d2). --- ## Outbound DDoS: the industry-wide problem demanding attention [ ![Outbound DDoS](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff8a0299c956ef43d12ab7f1a40ef114862c0b64df77fe9c6c08a1ed16341ae0/images/screenshot_20251028_at_131315.png) ](https://fastnetmon.com/2025/09/24/outbound-ddos-the-attack-you-might-be-unknowingly-hosting/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=outbound_ddos&utm_term=october) Outbound DDoS is an emerging threat vector that too many networks overlook. When compromised devices inside your infrastructure become attack sources, you’re part of the problem — and the wider DDoS epidemic. This article explains why proactive egress monitoring is now a shared responsibility for every operator, and how FastNetMon helps you ensure your network isn’t unknowingly fuelling attacks. [READ ARTICLE](https://fastnetmon.com/2025/09/24/outbound-ddos-the-attack-you-might-be-unknowingly-hosting/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=outbound_ddos&utm_term=october) --- ## FastNetMon partners with Gcore for automated DDoS scrubbing [ ![FastNetMon & Gcore](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff8a0299c956ef43d12ab7f1a40ef114862c0b64df77fe9c6c08a1ed16341ae0/images/fastnetmongcore.png) ](https://fastnetmon.com/2025/10/15/fastnetmon-partners-with-gcore-for-automated-ddos-scrubbing/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=gcore&utm_term=october) We’re excited to announce that FastNetMon now integrates with [Gcore](https://gcore.com/gcore-fastnetmon-ddos-protection), enabling fully automated DDoS mitigation with sub-second detection. With FastNetMon Advanced, networks can detect attacks in real time and automatically divert only affected traffic to Gcore’s powerful scrubbing centres — keeping normal traffic flowing without added latency. This integration supports both IPv4 and IPv6, and joins our ecosystem of automated scrubbing partners, including F5 and Cloudflare Magic Transit. [READ MORE](https://fastnetmon.com/2025/10/15/fastnetmon-partners-with-gcore-for-automated-ddos-scrubbing/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=gcore&utm_term=october) --- ## Last week in Bucharest – RIPE 91 [ ![RIPE 91 Recap](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff8a0299c956ef43d12ab7f1a40ef114862c0b64df77fe9c6c08a1ed16341ae0/images/ripe91_event_recap_newsletter.png) ](https://fastnetmon.com/2025/10/24/event-recap-ripe-91/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=ripe_91&utm_term=october) We had a great time last week in Bucharest at RIPE 91. This event recap comes from Outi Maria, who experienced her very first RIPE meeting — and lived to tell the tale. We're already looking forward to the next one! [READ THE RECAP](https://fastnetmon.com/2025/10/24/event-recap-ripe-91/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=ripe_91&utm_term=october) --- [ ![DDoS Taxonomy Guide](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff8a0299c956ef43d12ab7f1a40ef114862c0b64df77fe9c6c08a1ed16341ae0/images/ddos_taxonomy.jpeg) ](https://www.ukcybersecuritycouncil.org.uk/blogs/the-fastnetmon-ddos-taxonomy-understanding-classifying-and-responding-to-modern-threats) ## Our DDoS Taxonomy published on UK Cyber Security Council In our latest article on the UK Cyber Security Council, we've introduced a structured DDoS taxonomy, breaking attacks into categories like bandwidth, application, and infrastructure-focused threats. A clear DDoS taxonomy helps organisations move from reactive firefighting to automated, structured defence. [READ THE ARTICLE](https://www.ukcybersecuritycouncil.org.uk/blogs/the-fastnetmon-ddos-taxonomy-understanding-classifying-and-responding-to-modern-threats) --- ## Industry News Here are some interesting industry takes and major DDoS incidents you should know about. Enjoy the reading! [ ![Aisuru IoT botnet](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff8a0299c956ef43d12ab7f1a40ef114862c0b64df77fe9c6c08a1ed16341ae0/images/screenshot_20251029_at_121920.png) ](https://fastnetmon.com/2025/10/15/ddos-botnet-aisuru-drives-record-outbound-floods-from-infected-isp-hosted-iot/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=aisuru-drives-record-outbound-floods-from-infected-isp-hosted-iot&utm_term=october) The Aisuru IoT botnet unleashed nearly 30 Tbps of outbound flood traffic via infected ISP-hosted devices, turning internal egress ports into attack vectors. Read details and how to expose infected hosts [here](https://fastnetmon.com/2025/10/15/ddos-botnet-aisuru-drives-record-outbound-floods-from-infected-isp-hosted-iot/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=aisuru-drives-record-outbound-floods-from-infected-isp-hosted-iot&utm_term=october). [ ![Aisuru gaming outages](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff8a0299c956ef43d12ab7f1a40ef114862c0b64df77fe9c6c08a1ed16341ae0/images/screenshot_20251029_at_122402.png) ](https://fastnetmon.com/2025/10/08/another-record-breaking-ddos-aisuru-botnet-suspected-behind-29-69-tbps-gaming-outages/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=aisuru_gaming_outages&utm_term=october) The Aisuru botnet is the main suspect behind a new scale of DDoS intensity — 29.69 Tbps attack against major gaming platforms on Oct 06. ‘Carpet-bomb’ TCP flood exposes new gaps in gaming defences. Full story [here](https://fastnetmon.com/2025/10/08/another-record-breaking-ddos-aisuru-botnet-suspected-behind-29-69-tbps-gaming-outages/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=aisuru_gaming_outages&utm_term=october). [ ![ShadowV2 botnet](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff8a0299c956ef43d12ab7f1a40ef114862c0b64df77fe9c6c08a1ed16341ae0/images/screenshot_20251029_at_123539.png) ](https://fastnetmon.com/2025/10/01/shadowv2-a-new-botnet-that-turns-misconfigured-docker-apis-into-a-pay-to-use-cloud-ddos-platform/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=shadowv2-turns-misconfigured-docker-apis-into-a-pay-to-use-cloud-ddos-platform&utm_term=october) ShadowV2 turns mis-configured Docker APIs on cloud hosts into a pay-to-use DDoS launch-pad. How does this DDoS-as-a-service platform exploit container workflows and API abuse? Learn [here](https://fastnetmon.com/2025/10/01/shadowv2-a-new-botnet-that-turns-misconfigured-docker-apis-into-a-pay-to-use-cloud-ddos-platform/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=shadowv2-turns-misconfigured-docker-apis-into-a-pay-to-use-cloud-ddos-platform&utm_term=october). [ ![Linux 6.18 performance](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff8a0299c956ef43d12ab7f1a40ef114862c0b64df77fe9c6c08a1ed16341ae0/images/screenshot_20251029_at_124037.png) ](https://fastnetmon.com/2025/10/09/linux-6-18-improves-server-performance-under-ddos-attacks/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=linux-6-18-improves-server-performance-under-ddos-attacks&utm_term=october) Kernel version Linux 6.18 boosts UDP-receive throughput by 47 % in DDoS-style test traffic, thanks to major lock-contention and queue-handling improvements. Find full story [here](https://fastnetmon.com/2025/10/09/linux-6-18-improves-server-performance-under-ddos-attacks/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=linux-6-18-improves-server-performance-under-ddos-attacks&utm_term=october). --- ## 💌 Get this newsletter straight to your inbox Sign up to our monthly Network Engineering Community News [here](https://cdn.forms-content.sg-form.com/b3c8181d-c30d-11ef-b203-ca12671f70d2). **Categories:** Newsletter **Tags:** Community, Newsletter --- ### [Network Engineering Community News: February 2026](https://fastnetmon.com/2026/02/26/network-engineering-community-news-february-2026/) **Published:** February 26, 2026 **Author:** FastNetMon **Content:** # Welcome to our Network Engineering Community News! If you’re new here, welcome. This monthly update goes out to everyone who has used or trialed FastNetMon. In February, we were at APRICOT in Jakarta and NANOG in San Francisco, rolled out major web updates, and kicked off a new community initiative, while also covering key industry developments. Enjoy the read. Want this letter straight to your inbox? Sign up to our monthly Network Engineering Community News [here](https://cdn.forms-content.sg-form.com/b3c8181d-c30d-11ef-b203-ca12671f70d2). --- ## February event highlights: NANOG & APRICOT [ ![NANOG recap](https://eoolnbw.stripocdn.email/content/guids/CABINET_328069c03321b69b21d47f0199814d1df4a51347c3a32a8928de1bb94c79dcdb/images/nanog_96_pavel_odintsov_E1t.png) ](https://youtu.be/EFTM-P4eWJQ?si=HTbngzgbPNm9X4Hk) NANOG 92 in San Francisco was a strong event for us, with plenty of good conversations and time spent with the operator community. Pavel Odintsov presented an official session on the FastNetMon community and how the project has evolved over more than a decade of open-source development and real-world DDoS detection. Watch the full talk [on our YouTube](https://youtu.be/EFTM-P4eWJQ?si=HTbngzgbPNm9X4Hk), read [NANOG’s blog feature](https://nanog.org/stories/inside-nanog-96-attendees-share-what-made-our-last-conference-unforgettable/), and check out our [detailed event recap](https://fastnetmon.com/2026/02/06/nanog-96-event-recap/). [ READ THE NANOG RECAP ](https://fastnetmon.com/2026/02/06/nanog-96-event-recap/) APRICOT 2026 in Jakarta was equally great for us, meeting customers and partners across the APAC region and discussing DDoS detection, network visibility, and operational challenges. Read our [event recap](https://fastnetmon.com/2026/02/12/apricot-2026-event-recap/) for highlights, and browse our [YouTube Shorts](https://www.youtube.com/shorts/L2EmRS7Xrxw) for conference moments and behind-the-scenes clips. [ READ THE APRICOT RECAP ](https://fastnetmon.com/2026/02/12/apricot-2026-event-recap/) --- ## Big updates to FastNetMon interfaces [ ![FastNetMon interfaces](https://eoolnbw.stripocdn.email/content/guids/CABINET_328069c03321b69b21d47f0199814d1df4a51347c3a32a8928de1bb94c79dcdb/images/fastnetmon_interfaces.png) ](https://fastnetmon.com/) Our new FastNetMon website is now live, with clearer navigation, polished documentation, and updated visuals that make it easier to find what you need. Later this year, we’ll launch the new FastNetMon web interface — one of the biggest product upgrades since FastNetMon was first released. It’s designed around how operators actually work: clearer traffic visibility, real-time attack context, hostgroup-level views, and dashboards that reduce guesswork when traffic deviates from normal. This isn’t just a visual refresh; it’s about making network data easier to see, interpret, and act on. [ VISIT OUR NEW WEBSITE ](https://fastnetmon.com/) --- ## Spotlighting the operators who keep networks running We’re exploring a FastNetMon Community Awards initiative to recognise the operators who quietly keep networks online — and we’d like your input before we move forward. If we launch it, which award category should we include? [ CAST YOUR VOTE ](https://www.linkedin.com/feed/update/urn:li:activity:7430921733441773568) --- ## Industry news & insights Here are some interesting industry takes and major DDoS incidents in February 2026. Happy reading! [ ![ASPA Routing Security](https://eoolnbw.stripocdn.email/content/guids/CABINET_328069c03321b69b21d47f0199814d1df4a51347c3a32a8928de1bb94c79dcdb/images/aspa.png) ](https://fastnetmon.com/2026/02/25/aspa-the-next-layer-of-routing-security/) **The next layer in routing security.** About the 2026 developments around ASPA rollout, what’s important in routing security this year, and what operators should know about ASPA. Read our take [here](https://fastnetmon.com/2026/02/25/aspa-the-next-layer-of-routing-security/). [ ![IP Geolocation & Geofeed](https://eoolnbw.stripocdn.email/content/guids/CABINET_328069c03321b69b21d47f0199814d1df4a51347c3a32a8928de1bb94c79dcdb/images/ip_geolocation.png) ](https://fastnetmon.com/2026/02/19/geofeed-rfc-9632-why-operators-should-publish-their-geoip-data/) **Why publish geofeed data?** On IP Geofeed accuracy, why it matters for your network and wider ecosystem, and what operators should do to publish their geofeed information. Read our take [here](https://fastnetmon.com/2026/02/19/geofeed-rfc-9632-why-operators-should-publish-their-geoip-data/). [ ![31.4 Tbps DDoS](https://eoolnbw.stripocdn.email/content/guids/CABINET_328069c03321b69b21d47f0199814d1df4a51347c3a32a8928de1bb94c79dcdb/images/222_tbps_record_ddos_attack_mitigated_by_cloudflare_news.png) ](https://fastnetmon.com/2026/02/01/aisuru-botnet-sets-a-new-ddos-record-at-31-4-tbps/) **A new DDoS peak: 31.4 Tbps.** Another record-breaking DDoS attack was reported recently, just 3 months after the previous. Aisuru botnet was involved once again. Read our report [here](https://fastnetmon.com/2026/02/01/aisuru-botnet-sets-a-new-ddos-record-at-31-4-tbps/). ## 💌 Get this newsletter straight to your inbox Sign up to our monthly Network Engineering Community News [here](https://cdn.forms-content.sg-form.com/b3c8181d-c30d-11ef-b203-ca12671f70d2). **Categories:** Newsletter --- ### [Aisuru botnet sets a new DDoS record at 31.4 Tbps](https://fastnetmon.com/2026/02/01/aisuru-botnet-sets-a-new-ddos-record-at-31-4-tbps/) **Published:** February 1, 2026 **Author:** FastNetMon **Content:** Another DDoS record has been reported, and once again, it is the same botnet setting it. In late January 2026, Cloudflare disclosed details of what is now the largest publicly reported DDoS attack to date, an incident that occurred in December 2025 and peaked at 31.4 Tbps. The attack was attributed to the Aisuru botnet. While Kimwolf is often mentioned alongside Aisuru in public reporting, the two are generally understood to be closely related but distinct botnets, with indications that they may be operated independently or by partially overlapping groups. The latest record-breaking attack has been attributed specifically to Aisuru and exceeded its own previous record of 29.7 Tbps observed just three months earlier. ## **The Night Before Christmas campaign** The campaign, which Cloudflare dubbed “The Night Before Christmas”, began on 19 December and consisted of a large number of short but extremely intense network-layer attacks. Rather than a single sustained flood, the activity was characterised by repeated bursts designed to deliver maximum impact in a very limited time window. Most of the attacks peaked between 1 and 5 Tbps, with only a small fraction exceeding 10 Tbps. Attacks at the extreme end of the spectrum, including the 31.4 Tbps peak, were rare but significant enough to reset expectations around what is now technically achievable. From a packet-rate perspective, the majority of attacks generated between one and five billion packets per second, underlining the continued shift toward high-volume, packet-intensive Layer 4 attacks. Duration data paints a similarly clear picture. More than half of the attacks lasted between one and two minutes, while only around six percent exceeded two minutes in length. This preference for short-lived, high-intensity bursts mirrors a broader trend seen across recent large-scale DDoS campaigns, where attackers aim to overwhelm detection and mitigation systems before defenders can react. ## **Network-layer attacks at unprecedented scale** While the campaign also included application-layer HTTP floods exceeding 200 million requests per second, the defining feature of this incident was its scale at the network layer. According to Cloudflare’s reporting, network-layer attacks continue to account for the majority of DDoS growth, both in absolute numbers and in overall impact. ## **Targeted industries and regions** Targeting during the campaign focused primarily on high-traffic and latency-sensitive sectors. Telecommunications providers were among the main victims, alongside IT and online services, gaming platforms and gambling-related businesses. These industries tend to operate infrastructure where even short disruptions can have immediate and visible consequences. Geographically, attacks were concentrated on major internet hubs and economically significant regions. The United States absorbed the largest share of hyper-volumetric attacks, followed by China, Hong Kong, Germany, Brazil and the United Kingdom. Disruptions in these regions can have knock-on effects well beyond a single organisation, particularly when shared infrastructure is involved. ## **Inside the Aisuru / Kimwolf botnet** The scale of the Aisuru botnet is largely explained by its underlying device population. The Kimwolf variant has been linked to the compromise of millions of unofficial Android TV and streaming devices, which are routinely exposed, poorly secured and rarely patched. This provides attackers with a vast, globally distributed pool of traffic sources that is difficult to disrupt permanently. Despite ongoing takedown and null-routing efforts by multiple security teams, the botnet has shown an ability to rapidly shift command-and-control infrastructure and continue operating. ## **A broader acceleration in DDoS activity** The record-breaking attack took place against a backdrop of rapidly accelerating DDoS activity. Cloudflare reports that total DDoS attacks reached 47.1 million in 2025, representing a 121 percent increase year over year. Network-layer attacks more than tripled compared to 2024, and the fourth quarter alone accounted for millions of incidents. Attacks exceeding 100 million packets per second grew by 600 percent, while attacks larger than 1 Tbps continued to rise quarter over quarter. Taken together, these figures suggest that while attacks at the scale of 30 Tbps remain exceptional, multi-terabit DDoS events are no longer unusual. For network operators, the challenge is less about preparing for a single headline-grabbing peak and more about consistently detecting and mitigating frequent, short-lived but extremely aggressive network-layer attacks. As botnets such as Aisuru continue to evolve and expand, manual intervention and slow detection pipelines are increasingly inadequate. Effective defence depends on real-time visibility, accurate classification and automated response at the packet and flow level. **Categories:** FastNetMon Blog, Featured --- ### [Network Engineering Community News: December 2025](https://fastnetmon.com/2025/12/27/network-engineering-community-news-december-2025/) **Published:** December 27, 2025 **Author:** FastNetMon **Content:** # Welcome to Network Engineering Community News – End of Year 2025 Hello from all of us at FastNetMon, your trusted partner in DDoS detection and mitigation. While the year is coming to a close, December was far from quiet in the network security field. In this issue, we cover some of the key activities from the past month and take a look back at the year in DDoS defence. We hope you find it a useful and informative read. Want this letter straight to your inbox? Sign up to our monthly Network Engineering Community News [here](https://cdn.forms-content.sg-form.com/b3c8181d-c30d-11ef-b203-ca12671f70d2). --- ## Year 2025 in Network Security [ ![2025 in DDoS Defence](https://eoolnbw.stripocdn.email/content/guids/CABINET_1bf36edcac5e3c1fc9f9893c8414bc6e7e8f6db6097738f02ee0bd35b4dcce25/images/what_noc_and_soc_teams_are_reading_fastnetmon_network_engineering_insights.png) ](https://fastnetmon.com/2025/12/30/2025-in-ddos-defence-wrapped/) 2025 was a busy year. DDoS records were broken seven times, new hyper-scale botnets emerged, and the landscape evolved faster than ever. We covered over 120 of the most important stories in the industry — now, here’s a recap of what **YOU** found most interesting. Enjoy! [ SEE THE TOP DDOS STORIES OF 2025 ](https://fastnetmon.com/2025/12/30/2025-in-ddos-defence-wrapped/) --- ## DDoS Defense by Design Architecture that survives when everything else fails [ ![DDoS Defense by Design](https://eoolnbw.stripocdn.email/content/guids/CABINET_1bf36edcac5e3c1fc9f9893c8414bc6e7e8f6db6097738f02ee0bd35b4dcce25/images/ddos_defense_by_design_architecture_that_survives_when_everything_else_fails_by_herve_hildenb.png) ](https://fastnetmon.com/2025/12/12/ddos-defense-by-design-architecture-that-survives-when-everything-else-fails/) Herve Hildenbrand walks us through a high-stakes DDoS scenario where solid network architecture made the difference between an outage and staying online. Republished on our blog with the author’s permission. [ READ THE ARTICLE ](https://fastnetmon.com/2025/12/12/ddos-defense-by-design-architecture-that-survives-when-everything-else-fails/) --- ## Case study How Bangladesh’s leading ISP solved DDoS detection and mitigation [ ![Case Study Link3](https://eoolnbw.stripocdn.email/content/guids/CABINET_1bf36edcac5e3c1fc9f9893c8414bc6e7e8f6db6097738f02ee0bd35b4dcce25/images/case_study_fastnetmon_ddos_detection_and_mitigation_isp.png) ](https://fastnetmon.com/2025/12/17/case-study-ddos-detection-and-automated-mitigation-at-link3-with-fastnetmon/) At Bangladesh’s leading ISP, their NOC/SOC team built custom FastNetMon workflows with per-host thresholds, deterministic rules, and automated scrubbing-centre diversion—no magic buttons, just full control. [ READ THE CASE STUDY ](https://fastnetmon.com/2025/12/17/case-study-ddos-detection-and-automated-mitigation-at-link3-with-fastnetmon/) --- ## FastNetMon featured in Fortune [ ![FastNetMon in Fortune](https://eoolnbw.stripocdn.email/content/guids/CABINET_1bf36edcac5e3c1fc9f9893c8414bc6e7e8f6db6097738f02ee0bd35b4dcce25/images/rise_of_22super_botnets22_fastnetmon_feature_in_forbes.png) ](https://fortune.com/press-releases/rise-super-botnets-fastnetmon-ddos-attacks-2025-12-11/?utm_content=494218426&utm_medium=social&utm_source=linkedin&hss_channel=lcp-18291520) We highlight why compromised devices powering today’s botnets are putting global networks under pressure—and why rapid detection and mitigation are now critical. Proud to see this conversation reaching a wider audience. [ READ PRESS RELEASE ](https://fortune.com/press-releases/rise-super-botnets-fastnetmon-ddos-attacks-2025-12-11/?utm_content=494218426&utm_medium=social&utm_source=linkedin&hss_channel=lcp-18291520) --- --- ## Industry news Here are some interesting industry takes and major DDoS incidents from December 2025. Happy reading! [ ![Kimwolf Botnet](https://eoolnbw.stripocdn.email/content/guids/CABINET_1bf36edcac5e3c1fc9f9893c8414bc6e7e8f6db6097738f02ee0bd35b4dcce25/images/kimwolf_possible_aisuru_successor_capable_of_multitbps_ddos_attacks.png) ](https://fastnetmon.com/2025/12/26/kimwolf-possible-aisuru-successor-capable-of-multi-tbps-ddos-attacks/) **Kimwolf, a massive botnet likely linked to Aisuru, has been observed at a million-device scale with highly resilient DDoS infrastructure.** Read more [here](https://fastnetmon.com/2025/12/26/kimwolf-possible-aisuru-successor-capable-of-multi-tbps-ddos-attacks/). [ ![La Poste DDoS](https://eoolnbw.stripocdn.email/content/guids/CABINET_1bf36edcac5e3c1fc9f9893c8414bc6e7e8f6db6097738f02ee0bd35b4dcce25/images/ddos_news_french_national_postal_services_la_poste_ddos_attack.png) ](https://fastnetmon.com/2025/12/23/ddos-attack-disrupts-la-poste-services-just-before-christmas/) **La Poste confirmed a pre-Christmas DDoS attack that disrupted postal and banking services during peak delivery season.** Read the full story [here](https://fastnetmon.com/2025/12/23/ddos-attack-disrupts-la-poste-services-just-before-christmas/). [ ![29.7 Tbps DDoS](https://eoolnbw.stripocdn.email/content/guids/CABINET_1bf36edcac5e3c1fc9f9893c8414bc6e7e8f6db6097738f02ee0bd35b4dcce25/images/297_tbps_aisuru_botnet_sets_a_new_ddos_world_record.png) ](https://fastnetmon.com/2025/12/04/new-record-breaking-ddos-29-7-tbps-aisuru-attack-marks-new-high-in-hyper-volumetric-threats/) **A new record-breaking DDoS attack has been confirmed, with the Aisuru botnet peaking at 29.7 Tbps in 69 seconds.** Read the full story [here](https://fastnetmon.com/2025/12/04/new-record-breaking-ddos-29-7-tbps-aisuru-attack-marks-new-high-in-hyper-volumetric-threats/). [ ![Solana DDoS](https://eoolnbw.stripocdn.email/content/guids/CABINET_1bf36edcac5e3c1fc9f9893c8414bc6e7e8f6db6097738f02ee0bd35b4dcce25/images/solana_blockchain_ddos_attack_fstnetmon_ddos_news.png) ](https://fastnetmon.com/2025/12/18/solana-reports-stable-network-operation-during-sustained-multi-terabit-ddos-attack/) **Solana reported stable network operation during a week-long DDoS attack peaking near 6 Tbps.** Read the full story [here](https://fastnetmon.com/2025/12/18/solana-reports-stable-network-operation-during-sustained-multi-terabit-ddos-attack/). --- ## 💌 Get this newsletter straight to your inbox Sign up to our monthly Network Engineering Community News [here](https://cdn.forms-content.sg-form.com/b3c8181d-c30d-11ef-b203-ca12671f70d2). **Categories:** Newsletter --- ### [Case Study: DDoS detection and automated mitigation at Link3 with FastNetMon](https://fastnetmon.com/2025/12/17/case-study-ddos-detection-and-automated-mitigation-at-link3-with-fastnetmon/) **Published:** December 17, 2025 **Author:** FastNetMon **Content:** ### Case study summary As one of Bangladesh’s leading internet service providers, Link3 Technologies operates a high-traffic network that must remain stable and responsive under all conditions. To support this, Link3 deployed FastNetMon as the central platform for real-time DDoS detection and automated mitigation. By integrating FastNetMon directly into their network automation and remote scrubbing workflows, Link3 gained faster detection, deterministic control over mitigation actions, and a cost-effective way to protect customer traffic at scale. [Get the PDF format: FastNetMon – Link3 case study](https://fastnetmon.com/wp-content/uploads/2026/01/Case-study-FastNetMon-DDoS-Detection-and-Mitigation-Link3-Technologies-ISP-Dhaka-Bangladesh.pdf)[Download](https://fastnetmon.com/wp-content/uploads/2026/01/Case-study-FastNetMon-DDoS-Detection-and-Mitigation-Link3-Technologies-ISP-Dhaka-Bangladesh.pdf) ### About the customer and engineering requirements Link3 Technologies Ltd. is one of Bangladesh’s leading ISPs, delivering nationwide connectivity alongside a wide range of enterprise networking services. Operating a large, high-volume network means that even short-lived DDoS events can impact customer experience and operational stability. To support their NOC and SOC teams, Link3 required a DDoS detection platform that could be deployed quickly, integrate cleanly with existing automation workflows, and scale reliably in an ISP environment. Rapid detection, reliable notifications, and seamless integration with a remote scrubbing centre were key technical requirements. Equally important was maintaining flexibility and operator control, rather than adopting a rigid, black-box mitigation model. ### DDoS detection with full operator control FastNetMon is deployed at ISPs globally, where network operators need full control over DDoS detection and mitigation workflows. The platform exposes traffic data, supports configurable per-host and per-host-group thresholds, and provides deterministic detection logic that operators can directly integrate into custom mitigation workflows. Instead of enforcing predefined responses, FastNetMon acts as a programmable detection and control layer. This allows engineering teams to build mitigation paths that match their own network topology, routing policies, and operational practices — an approach well suited to complex ISP environments. ### The FastNetMon solution and implementation at Link3 Link3 uses FastNetMon as the central engine for real-time DDoS detection and automated mitigation. Traffic is monitored at both per-host and per-host-group levels, using multiple threshold tiers to classify anomalies with high precision. When FastNetMon detects an attack, it automatically triggers a predefined sequence of actions based on the attack pattern. These actions include signalling customer-edge routers, initiating RTBH where appropriate, and triggering Link3’s remote scrubbing centre via BGP to divert and clean malicious traffic in real time. This automation allows mitigation decisions to be executed consistently and immediately, without requiring manual intervention from operators during an active attack. ### Results With FastNetMon in place, Link3 benefits from near-real-time attack detection, instant notifications, and automated activation of both local and remote mitigation controls. The solution provides a cost-effective way to strengthen network resilience while maintaining the flexibility and scalability required by a high-volume ISP. Integration with the remote scrubbing centre ensures that malicious traffic is handled efficiently and consistently, reducing operational load on the NOC team and allowing engineers to focus on maintaining overall network performance. ### From the NOC & SOC Team > Link3 chose FastNetMon for its speed, automation-friendly > architecture, and customisation capabilities. The platform’s > ability to scale, integrate with existing BGP-based workflows, > and support features like Flow Spec, RTBH, and automated > scrubbing diversion made it the most suitable option for our > environment. **NOC & SOC Team, Link3 Technologies Ltd.** - Ujjal Biswas, Senior Manager - Ahasan Ahmed, Senior Manager - Subrata Sarker, Senior Manager [Get the PDF format: FastNetMon – Link3 case study](https://fastnetmon.com/wp-content/uploads/2026/01/Case-study-FastNetMon-DDoS-Detection-and-Mitigation-Link3-Technologies-ISP-Dhaka-Bangladesh.pdf)[Download](https://fastnetmon.com/wp-content/uploads/2026/01/Case-study-FastNetMon-DDoS-Detection-and-Mitigation-Link3-Technologies-ISP-Dhaka-Bangladesh.pdf) --- ### About FastNetMon FastNetMon delivers high-performance DDoS detection software for companies at any scale. With extensive experience in telecom, mobile, and cloud environments, FastNetMon enables network operators to build fully automated, operator-controlled mitigation workflows tailored to their infrastructure.Learn more at[ **www.fastnetmon.com**](http://www.fastnetmon.com/) or get in touch at **sales@fastnetmon.com** **Categories:** Case studies, Press & Newsroom --- ### [Event Recap – LINX125](https://fastnetmon.com/2025/11/21/event-recap-linx125/) **Published:** November 21, 2025 **Author:** FastNetMon **Content:** FastNetMon had the opportunity to attend LINX125 in London on 19–20 November 2025 as a guest, in the capacity of an ascending LINX member. It was a valuable chance for us to learn more about LINX, meet the community, and understand the current conversations shaping one of the world’s most influential internet exchanges. We are grateful to the LINX team for the invitation and the very warm welcome. ![](https://fastnetmon.com/wp-content/uploads/2025/11/Jennifer-Holmes-CEO-of-LINX-at-LINX-125-London-FastNetMon-event-Recap-1-1024x455.jpeg)The two-day programme brought together a rich mix of perspectives from across the networking and infrastructure ecosystem. Several sessions stood out, each offering something different but equally relevant to the shifting landscape of interconnection. One of the most memorable talks explored the history and hidden role of BT Tower. Andy Sutton from BT delivered a fascinating look at the history how the tower became a central point for national telecommunications, carrying microwave links from the Shetland Isles all the way to the Isles of Scilly. It was curious to learn how some of the most iconic structures in our cities also carry decades of engineering stories inside them. ![](https://fastnetmon.com/wp-content/uploads/2025/11/Andy-Sutton-BT-group-at-LINX125-FastNetMon-event-recap-1024x590.jpeg)Another session that sparked a lot of thought came from Google, with Arturo Servin explaining how the company’s peering policy is evolving to support a world increasingly defined by cloud workloads and latency sensitive applications. The shift away from broad open peering toward a more targeted, cloud-aligned strategy felt like a natural consequence of accelerating enterprise demand at the edge. ![](https://fastnetmon.com/wp-content/uploads/2025/11/Arturo-Servin-Google-at-LINX125-FastNetMon-event-recap-1024x580.jpeg)From a resilience perspective, Alastair Strachan’s presentation on Baltic Sea cable damage showed how the Internet adapts under pressure. Using RIPE Atlas measurements, he demonstrated how routes shifted, latency changed, and connectivity was preserved in the face of submarine cable failures. It was a technically grounded look at real-world network behaviour and a good reminder of how dynamic the global routing system really is. The relationship between geopolitics and Internet topology surfaced again in a talk from Josh Levett of the University of York. His research connected political events with routing patterns and infrastructure deployment, offering a broader lens on how global tensions shape the structure of the network itself. It was one of the more reflective moments of the programme. Geoff Bennett’s session on the energy demands of AI scale data centres added a different kind of urgency. As compute requirements grow into the gigawatt range, the environmental and infrastructure implications become impossible to ignore. His analysis of how major AI companies are approaching power planning gave the room a clear signal that the race toward AGI is reshaping more than just technology. There was also a thoughtful look at the growth of Stuttgart IX from Moritz Frenzel, who shared what it takes to turn a small local exchange into a thriving regional platform. The honesty about what worked and what didn’t resonated strongly, especially with the many operators in the room facing similar challenges. In a different tone entirely, Tony O’Sullivan from RETN offered a very direct view on what it means to build infrastructure that actually stands up in a world full of instability. His message was clear and grounded in lived experience across a complex, multi-country network. ![](https://fastnetmon.com/wp-content/uploads/2025/11/Moriz-Frenzel-Stuttgart-Internet-Exhange-at-LINX125-FastNetMon-event-recap-1024x537.jpeg)Alongside these external sessions, LINX provided updates on its operations, technical roadmap, route server work, financial outlook and regulatory initiatives. The membership survey results helped frame where the exchange is heading and the priorities that matter most to its community. These overviews offered useful context for us as a growing participant in the ecosystem. As the event wrapped up, one small but important detail stood out to us. Beyond the excellent content, the food was great and the Wednesday social was genuinely fun. It made the experience feel warm, well organised and surprisingly personal. ![](https://fastnetmon.com/wp-content/uploads/2025/11/IMG_9761-1-1024x561.jpg)Overall, LINX125 was an insightful and engaging two days for FastNetMon. We appreciated the chance to learn, meet so many members of the community and gain a closer view into the inner workings of LINX. Thank you again to the LINX team for allowing us to peek inside. --- ### About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** Press & Newsroom --- ### [End may be near for Aisuru and Kimwolf botnets after large-scale C2 disruption](https://fastnetmon.com/2026/01/19/end-may-be-near-for-aisuru-and-kimwolf-botnets-after-large-scale-c2-disruption/) **Published:** January 19, 2026 **Author:** FastNetMon **Content:** One of the largest DDoS botnet operations observed in recent years may be facing sustained disruption after hundreds of command-and-control (C2) servers linked to the Aisuru and Kimwolf botnets were taken offline. According to [research published](https://www.linkedin.com/pulse/keeping-kimwolf-bay-putting-leash-massive-ddos-botnet-t1pyc/) by Lumen’s Black Lotus Labs, more than 550 C2 servers used by the botnets have been null-routed over the past four months, significantly impairing their ability to control infected devices. Aisuru and its successor, Kimwolf, have been linked to record-breaking DDoS attacks and are estimated to control well over two million Android devices, most of them low-cost, uncertified Android TV boxes deployed in residential networks. ### **Record-scale attacks and rapid expansion** After the RapperBot botnet was disrupted in August 2025, Aisuru quickly expanded to fill the gap. By September, attacks attributed to the botnet exceeded **1**1 Tbps, making it the most powerful DDoS botnet observed at the time. Black Lotus Labs reported a sharp rise in bot activity during this period, with the daily average number of active bots increasing from around 50,000 to 200,000 in a matter of weeks. As activity intensified, network-level action was taken against known C2 infrastructure, cutting off infected devices from receiving further instructions. ### **Botnet control linked to residential infrastructure** Analysis of Aisuru backend servers revealed traffic aggregation from multiple C2 nodes and active operator access via residential SSH connections. Several of the IP addresses involved were traced to Canada, and the activity was reported to law enforcement. Independent reporting by cybersecurity journalist Brian Krebs, who was previously targeted by a massive DDoS attack attributed to Aisuru, later identified overlapping infrastructure tied to the botnet’s operation. ### **Kimwolf emerges as operators shift tactics** In early October, researchers observed a series of infrastructure changes, including new domain names, modified ports, and updated malware payloads. Malware samples retrieved from affected servers initially connected to Aisuru C2 nodes but were later replaced with binaries pointing to newly established infrastructure. Security researchers, including Xlab, later confirmed that these changes marked the emergence of a new botnet, now tracked as Kimwolf. The transition did little to slow growth. Within days, Kimwolf infections surged by 300%, reaching approximately 800,000 active bots by mid-October. Many of the compromised devices were found listed for sale through a single residential proxy service. ### **Residential proxy abuse fuels scale** Traffic analysis showed Kimwolf infrastructure interacting heavily with multiple residential proxy networks, particularly PYPROXY. Researchers observed large-scale scanning activity targeting vulnerable devices, which preceded each major growth phase. Research published by **Synthient** later confirmed that Kimwolf exploited weaknesses in residential proxy services to compromise devices at scale. Synthient estimates the total botnet size to be well above two million devices, with major concentrations in Vietnam, Brazil, India, and Saudi Arabia. ### **Disruptions trigger visible operator response** As C2 servers were identified, they were null-routed to prevent further coordination. In several cases, botnet operators were observed restoring infrastructure within hours, highlighting the resilience of the operation. However, subsequent disruptions triggered spikes in traffic to malware hosting servers, suggesting that operators were attempting to push updated payloads to retain control of infected devices. These servers were also taken offline. Following the disruptions, operators launched DDoS attacks containing profanity-laden payloads aimed at researchers, a reaction previously documented by Xlab. ### **Botnet activity continues under pressure** While Aisuru and Kimwolf infrastructure continues to reappear, researchers note that sustained C2 disruption at this scale is unusual and may limit the botnets’ ability to operate at peak strength. Black Lotus Labs and other security researchers continue to monitor the botnets’ activity, while [Synthient](https://synthient.com/blog/a-broken-system-fueling-botnets) has released a public tool allowing users to check whether their Android devices are part of the Kimwolf botnet. Further developments are expected as infrastructure churn continues and investigations progress. --- ### **About FastNetMon** FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com/). **Categories:** FastNetMon Blog --- ### [OCCRP reports sustained DDoS attack targeting its investigative journalism website](https://fastnetmon.com/2026/01/14/occrp-reports-sustained-ddos-attack-targeting-its-investigative-journalism-website/) **Published:** January 14, 2026 **Author:** FastNetMon **Content:** The Organized Crime and Corruption Reporting Project (OCCRP) has reported that its website has been targeted by a large-scale DDoS attack, slowing access and making it difficult for readers to reach its investigative reporting. [According to OCCRP](https://www.occrp.org/en/news/occrp-website-hit-by-sophisticated-ddos-attack), the attack began on Monday and was still ongoing as of January 13, 2026. While the website has not gone fully offline, readers may experience delays or additional verification steps introduced to block automated traffic. ### Coordinated attack with signs of active control OCCRP said the attack appears to be driven by a large, internationally distributed [botnet](https://fastnetmon.com/2025/06/18/anatomy-of-a-botnet/). The organisation’s security team observed that attackers adjusted their methods as defensive measures were introduced — behaviour that points to direct human involvement rather than a purely automated campaign. The source of the attack has not been identified, and OCCRP has not attributed it to any specific group or state actor. Recent upgrades to OCCRP’s digital infrastructure helped prevent a complete outage. The organisation noted that without these improvements, its website would likely have been unreachable for many hours. ### A familiar tactic against media and civil society This kind of attack has become a common pressure tool against [independent journalism and nonprofit organisations](https://fastnetmon.com/2025/06/19/ddos-attacks-are-now-targeting-journalists-universities-ngos-what-has-changed/). In 2023 and 2024, several Hungarian independent news outlets and the International Press Institute were hit by sustained DDoS attacks that took their websites offline for extended periods. Authorities later [arrested a suspect ](https://fastnetmon.com/2025/07/23/hungarian-police-arrest-alleged-ddos-attacker-targeting-ipi-and-independent-media/)who allegedly used DDoS-for-hire services to target critical media, while pro-government outlets were unaffected. Independent outlets elsewhere have faced similar disruption. Novaya Gazeta Europe, an investigative news site, has reported repeated DDoS attacks that temporarily blocked access to its reporting. Threat monitoring from organisations that protect at-risk nonprofits and media outlets shows a steady increase in DDoS activity aimed at human rights groups, investigative journalists, and civil-society organisations. Many of these attacks involve massive volumes of traffic designed to overwhelm relatively small publishing platforms. The pattern is consistent: rather than silencing reporting directly, attackers aim to make it unreachable at key moments. ### Staying online under pressure OCCRP’s ability to keep its website online, despite the ongoing attack, shows the importance of resilient infrastructure and real-time visibility into network traffic. As DDoS campaigns become more adaptive and sustained, organisations that rely on public access need to be prepared for prolonged disruption attempts, not just short spikes in traffic. FastNetMon will continue monitoring significant DDoS incidents affecting media organisations, NGOs, and other targets where availability is critical. --- ### About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com/). **Categories:** FastNetMon Blog --- ### [Venezuela’s routing anomaly and the bigger problem with BGP security](https://fastnetmon.com/2026/01/09/venezuelas-routing-anomaly-and-the-bigger-problem-with-bgp-security/) **Published:** January 9, 2026 **Author:** FastNetMon **Content:** In early January 2026, unusual Internet routing behaviour was observed involving AS8048, operated by CANTV, Venezuela’s state-owned telecommunications provider. The anomalies were highlighted by Graham Helton, a red team engineer writing on his blog [*Low End Orbit*](https://loworbitsecurity.com/radar/radar16/), based on publicly available BGP data. Soon after, Cloudflare published its [own technical analysis](https://blog.cloudflare.com/bgp-route-leak-venezuela/) of the same routing events, presenting another point of view. Cloudflare argued that the observed patterns were consistent with a **BGP route leak**, a type of incident that occurs regularly on the Internet and is most often caused by configuration or policy errors rather than deliberate interference. This article does not analyse the specific incident further. Instead, it uses it as a brief reminder of a broader issue: **BGP incidents are common, difficult to interpret, and still fundamentally hard to secure**. ### **Why BGP anomalies are hard to interpret** BGP is the protocol that allows autonomous systems (ASes) to exchange routing information and decide how traffic flows across the global Internet. It was designed decades ago, at a time when the network was smaller, more cooperative, and largely based on mutual trust between operators. That design assumption still shapes BGP today. The protocol does not include native mechanisms to: - cryptographically verify that an AS is authorised to originate a prefix, or - validate that the advertised AS path reflects legitimate business or routing relationships. As a result, when routing data shows unexpected paths, repeated AS prepending, or sudden changes in reachability, **the protocol itself provides no way to determine intent**. From BGP’s perspective, a benign misconfiguration and a malicious manipulation can look identical. ### **Route leaks: a routine failure with global impact** One of the most common BGP failure modes is the **route leak**. A route leak occurs when an AS unintentionally announces routes beyond their intended scope. Typical examples include exporting routes learned from one upstream provider to another, or propagating internal or customer routes more widely than intended. Route leaks do not require an attacker. A single configuration mistake, combined with permissive policies elsewhere in the routing ecosystem, is enough to affect traffic far beyond the originating network. Their impact can include degraded performance, increased latency, packet loss, partial outages, or large-scale traffic shifts across regions. Because BGP is global and transitive, even small errors can propagate widely. ### **Why “bad” routes still propagate** Some routing anomalies draw attention because they appear counterproductive, such as excessive AS path prepending that makes a route less attractive rather than more. This showcases a key limitation of BGP: **the protocol does not evaluate whether a route is sensible**. As long as an announcement is syntactically valid and passes local policy checks, it can be propagated. BGP does not understand intent, quality, or expected topology. It only compares attributes. Without strong filtering and validation, degraded or unusual paths can still spread across the Internet. ### **The core security gaps in BGP** The security limitations of BGP are well understood and long-standing. First, **there is no native authentication**. Traditional BGP allows any AS to announce reachability to almost any prefix. Trust is implicit, and validation is external. Second, **policy enforcement is decentralised**. Prefix filtering, max-prefix limits, and strict export policies are effective when applied consistently, but deployment and maintenance vary widely between operators. Third, **security extensions are only partially adopted**. RPKI enables cryptographic verification of *route origin*, allowing networks to confirm whether the originating AS is authorised to announce a given prefix. This significantly reduces simple prefix hijacks. However, RPKI does **not** validate the full AS path and does not prevent route leaks where the origin itself is legitimate. BGPsec extends this concept by cryptographically signing each hop in the AS path. While standardised, BGPsec has seen little to no real-world deployment due to operational complexity, performance overhead, and the requirement for universal participation along the path. More recently, mechanisms such as **ASPA (AS Provider Authorization)** aim to detect certain classes of route leaks by validating provider–customer relationships using RPKI. ASPA is promising, but deployment is still emerging and far from universal. Finally, **detection remains largely reactive**. Most operators rely on legacy monitoring systems, third-party alerts, or community coordination to identify routing incidents after they have already affected traffic. ### **What routing anomalies reveal about BGP security** Modern security discussions often focus on applications, APIs, and endpoints. Yet availability and integrity still depend on the network layer — and BGP remains central to that layer. Routing incidents can disrupt services, interfere with DDoS mitigation paths, enable traffic interception, or amplify existing attacks, often without compromising a single server. The uncomfortable reality is that **BGP failures are not rare or exceptional events**. They are a routine part of Internet operations, and they will continue to be until stronger security mechanisms are both widely deployed and consistently enforced. The value of recent routing anomalies lies not in what they prove about intent, but in what they reveal about the Internet’s underlying trust model — and how fragile that model still is: BGP’s security challenges are not the result of negligence, but of historical design choices that no longer match today’s threat landscape. At Internet scale, trust alone is not a security strategy — and BGP still depends on it more than any critical infrastructure should. --- ### **About FastNetMon** FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats.For more information, visit [https://fastnetmon.com](https://fastnetmon.com/). **Categories:** FastNetMon Blog, Featured --- ### [DDoS attacks disrupt Final Fantasy XIV Savage raid launch](https://fastnetmon.com/2026/01/07/ddos-attacks-disrupt-final-fantasy-xiv-savage-raid-launch/) **Published:** January 7, 2026 **Author:** FastNetMon **Content:** The launch of Final Fantasy XIV’s latest Savage raid tier in patch 7.4 was disrupted by a sustained wave of DDoS attacks, primarily affecting North American gamers. While European and Japanese regions remained largely stable, players in the US experienced repeated disconnects throughout the launch window, including during the high-profile race to world first. Community reports and public tracking accounts indicate **more than 15 suspected DDoS-related disruptions within a single 24-hour period**, with incidents occurring roughly once per hour and, at times, more frequently. ### **Attack pattern: short freezes followed by mass disconnects** Affected players consistently reported the same failure mode: - Severe latency or complete world freezes lasting 30–60 seconds - Followed by mass disconnects across entire data centres - Login queues and loss of progress once services recovered This behaviour points to **network-layer disruption upstream of the game servers**, rather than application-level failures within Square Enix’s infrastructure. The timing of the attacks aligned precisely with the Savage raid release — a period of highly concentrated player activity — maximising disruption to organised raid groups and competitive teams. ### **Regional impact and routing-level indicators** The attacks disproportionately affected **North American data centres**, while European and Japanese regions remained largely unaffected. Oceania servers later reported intermittent issues, potentially as player traffic shifted regions in search of stability. Some players reported that altering their network routing — for example by connecting via consumer VPN services — allowed them to remain connected while others continued to disconnect. From a network perspective, this suggests the disruptions were **isolated to specific transit paths or upstream nodes**, rather than Square Enix’s core game servers. Such behaviour is consistent with DDoS activity targeting **shared routing infrastructure or regional aggregation points**, creating widespread impact without directly attacking application endpoints. ### **Impact on competitive play** Savage raids represent Final Fantasy XIV’s highest-difficulty content, requiring long, uninterrupted progression sessions. Repeated disconnects forced many North American groups to pause or abandon attempts entirely. Despite the disruption, the race to world first concluded with a decisive victory by Japanese team Lucrezia — a result largely insulated from the attacks due to regional separation from the affected network paths. --- ### **About FastNetMon** FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com/). **Categories:** FastNetMon Blog --- ### [Orange Polska mitigated a large multi-vector DDoS attack on Christmas Eve](https://fastnetmon.com/2026/01/02/orange-polska-mitigated-a-large-multi-vector-ddos-attack-on-christmas-eve/) **Published:** January 2, 2026 **Author:** FastNetMon **Content:** Orange Polska mitigated a sizable DDoS attack on Christmas Eve, peaking at 1.5 Tbps. Orange Polska is the Polish national telecommunications operator and part of the Orange Group. The incident was first reported by [the operator’s CERT team](https://cert.orange.pl/aktualnosci/rekordowy-atak-ddos-w-sieci-orange-polska-skala-i-brutalnosc-rosna/). ![](https://fastnetmon.com/wp-content/uploads/2026/01/image.png)The timing of the attack is notable. Christmas Eve typically coincides with elevated baseline traffic levels and reduced operational staffing, conditions that can lower defensive margins and increase the likelihood of service impact. Despite this, Orange reported no customer-visible disruption. ### **Single-IP target, multi-vector execution** Unlike many large-scale attacks aimed at shared infrastructure, this campaign targeted a **single IP address**. This suggests the attacker’s objective was likely to overwhelm a specific service or user rather than cause widespread network instability. The case is part of a growing trend: **terabit-scale DDoS attacks are no longer reserved for large public platforms and can now be directed at individual endpoints**. From a technical perspective, the attack was classified as a **hyper-volumetric, multi-vector DDoS**. Orange Polska identified the simultaneous use of: - IP fragmentation floods - DNS floods - UDP floods - NetBIOS amplification - Total traffic floods At peak, packet rates reached **134.5 million packets per second (Mpps)**, placing significant stress on both bandwidth and packet-processing capacity. ### **Largest for Orange, but far from global records** While 1.5 Tbps represents a record-breaking event within Orange Polska’s network, it remains well below the largest DDoS attacks reported globally in recent months. For comparison, Cloudflare disclosed a **29.7 Tbps** DDoS attack linked to the Aisuru botnet in December 2025. This contrast is becoming a familiar reality for many network operators: **attack capacity continues to grow faster than most networks’ organic traffic growth**, and even “mid-range” terabit attacks are now becoming operationally routine. ### **Effective mitigation, limited visibility** Orange confirmed that mitigation systems operated as designed, absorbing the attack without measurable impact on end users. However, the operator also cautioned against complacency. By nature, DDoS attacks leave little to no forensic trace on targeted systems, and successful mitigation can mask the true scale and frequency of these events. For network engineers and security teams, the incident reinforces several lessons: - Terabit-scale DDoS attacks are increasingly common at the national ISP level - Single-IP targets can now attract extreme attack volumes - Multi-vector floods remain the dominant tactic - Continuous traffic visibility and fast, automated mitigation are critical As attacker capabilities continue to scale, incidents like this demonstrate why real-time network traffic analysis and rapid mitigation remain foundational controls for modern ISP and enterprise networks. --- ### **About FastNetMon** FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats.For more information, visit [https://fastnetmon.com](https://fastnetmon.com/). **Categories:** FastNetMon Blog --- ### [Kimwolf: possible Aisuru successor capable of multi-Tbps DDoS attacks](https://fastnetmon.com/2025/12/26/kimwolf-possible-aisuru-successor-capable-of-multi-tbps-ddos-attacks/) **Published:** December 26, 2025 **Author:** FastNetMon **Content:** ### A new “super botnet” Kimwolf reported by researchers Security researchers at XLab recently disclosed Kimwolf, a newly identified Android-based botnet that has allegedly infected more than 1.8 million devices worldwide. According to XLab’s findings, the botnet has issued over 1.7 billion DDoS attack commands in just three days, making it one of the largest active botnets observed. Kimwolf primarily targets Android-powered TV boxes and smart devices and has demonstrated the ability to generate hypervolumetric DDoS traffic at multi-Tbps scale. *This article summarises key findings from XLab’s research for informational purposes. The data, and analysis presented are those of XLab and are not confirmed by FastNetMon at the time of writing this article.* ### Links to Aisuru and likely shared operators XLab’s investigation uncovered strong technical and operational links between Kimwolf and the previously known Aisuru botnet. Shared infection scripts, overlapping infrastructure, reused certificates, and common tooling strongly suggest that both botnets are operated by the same threat actor group. Researchers believe Kimwolf represents a redesigned and more stealthy evolution of Aisuru, likely developed to evade detection after Aisuru samples became widely flagged by security products. ### Technical overview of the Kimwolf botnet The following technical details are based on XLab’s public analysis report. Kimwolf is compiled using the Android NDK and primarily targets Android TV boxes, smart TVs, and similar consumer devices. While its architecture is relatively straightforward, it incorporates several advanced techniques that complicate detection and takedown efforts: - Massive scale: Researchers observed up to 1.83 million active nodes in a single day, with cumulative infected IPs exceeding 3.6 million during C2 sinkholing. - DDoS capability: Kimwolf supports multiple Mirai-style DDoS attack vectors and is assessed to be capable of attacks approaching 30 Tbps, based on observed real-world incidents. - Stealthy communications: The botnet uses DNS over TLS (DoT) to hide C2 resolution and encrypts traffic using TLS, significantly reducing visibility for traditional network monitoring. - Resilient C2 infrastructure: Kimwolf rapidly rotates C2 domains and has adopted Ethereum Name Service (ENS)–based EtherHiding to resist takedowns. - Authentication mechanisms: C2 commands are protected using elliptic curve digital signatures, preventing easy takeover by defenders. - Multi-purpose malware: Beyond DDoS, Kimwolf supports traffic proxying, reverse shell access, and file operations, with proxying accounting for the majority of observed commands. Infected devices have been observed in 222 countries and regions, with the highest concentrations in Brazil, India, the United States, and Argentina. XLab notes that the true number of infected devices is likely higher due to dynamic IP addressing and partial visibility into Kimwolf’s infrastructure. ### Hypervolumetric DDoS threats will keep growing in 2026 Kimwolf is another clear signal that hyper-scale DDoS botnets are no longer exceptional events. As attackers increasingly abuse poorly secured consumer devices—especially smart TVs and TV boxes—the internet continues to inherit systemic risk from mass-market hardware with weak security controls. Looking ahead to 2026, we expect: - Continued growth in number of multi-Tbps attacks - Further growth in infection rates of the large botnets - Greater use of stealth techniques and decentralised infrastructure to evade takedowns In this environment, DDoS detection, inbound **and** outbound, is no longer optional function. It is a foundational requirement for service providers, networks, and critical internet infrastructure. Visibility, early detection, and automated mitigation will play an increasingly important role in keeping the internet stable as botnets like Kimwolf continue to evolve. --- ### About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats.For more information, visit [https://fastnetmon.com](https://fastnetmon.com/). **Categories:** FastNetMon Blog, Featured --- ### [DDoS attack disrupts La Poste services just before Christmas](https://fastnetmon.com/2025/12/23/ddos-attack-disrupts-la-poste-services-just-before-christmas/) **Published:** December 23, 2025 **Author:** FastNetMon **Content:** *DDoS News:* **France’s national postal service, La Poste**, has confirmed that a **DDoS attack disrupted its digital infrastructure**, partially taking services offline and slowing parcel deliveries just before Christmas — one of the busiest periods of the year for the organisation. The incident began this Monday, December 22nd, and has persisted over 12 hours, affecting multiple public-facing platforms and internal systems used to support postal operations. La Poste stated that while there is **no evidence of customer data compromise**, the attack directly impacted parcel distribution and online services. ### Digital services knocked offline As a result of the DDoS incident, several La Poste services became unavailable, including: - **laposte.fr** website - La Poste mobile application - **Digiposte** secure document storage service - La Poste digital identity services La Poste acknowledged that some post offices were forced to operate at **reduced capacity**, though essential postal services at physical counters remained available. Customers took to social media to report delays and uncertainty around parcel deliveries, with French media outlets noting that some people attempting to send or collect packages were turned away due to operational limitations. With Christmas approaching, even short disruptions created visible logistical challenges across the network. ### La Banque Postale also affected The disruption reportedly extended beyond postal services to **La Banque Postale**, the banking arm of La Poste. The bank confirmed that access to its **online banking platform and mobile application** was temporarily unavailable. In a public statement, the bank said: “A computer incident has temporarily made access to our mobile app and online banking unavailable. Our teams are working to resolve the situation as quickly as possible.” Despite the outage, **card payments, ATM withdrawals, and SMS-authenticated online payments** continued to function, limiting the impact on everyday financial transactions. ### Confirmed DDoS attack, limited public telemetry La Poste later confirmed that the incident was caused by a **distributed denial-of-service attack**, which overwhelmed parts of its digital infrastructure. The company has not attributed the attack to any specific threat actor. Public internet telemetry showed traffic anomalies around the time the disruption began, though no sustained nationwide traffic surge was clearly visible in the hours following the initial outage. This suggests a **targeted attack against specific infrastructure components**, or a short but impactful attack window followed by prolonged recovery. ### Extended recovery during peak period While the attack itself may have been limited in duration, the **extended service restoration** highlights the downstream effects DDoS incidents can have on interconnected systems, particularly when postal, identity, and banking platforms share supporting infrastructure. The timing — just days before Christmas — amplified the operational impact, with delays to parcel distribution and degraded digital services affecting both consumers and businesses. At the time of writing, La Poste says remediation efforts are ongoing and that teams remain fully mobilised to restore all services. ### About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats.For more information, visit [https://fastnetmon.com](https://fastnetmon.com/). **Categories:** FastNetMon Blog --- ### [Solana reports stable network operation during sustained multi-terabit DDoS attack](https://fastnetmon.com/2025/12/18/solana-reports-stable-network-operation-during-sustained-multi-terabit-ddos-attack/) **Published:** December 18, 2025 **Author:** FastNetMon **Content:** On **December 16, 2025**, Solana reported that its network had been **under a sustained DDoS attack for approximately a week**, with traffic **peaking near 6 Tbps**. Solana described the event as the **fourth-largest DDoS attack ever recorded against any distributed system**. Traffic volumes at this level are no longer exceptional in today’s DDoS environment and can be generated using widely available attack infrastructure. **What is unusual, however, is the duration**: multi-day, multi-terabit attacks are rarely reported, as most hyper-volumetric DDoS events typically last **seconds or minutes**, rather than being sustained over extended periods. FastNetMon does not have the ability to verify the attack details, and this report is based on public statements from Solana and information published in the media. According to those reports, the attack did **not** result in downtime or material degradation of block production. Solana stated that on-chain performance metrics, including transaction confirmation times and block scheduling, remained within normal operating ranges throughout the attack period. From a network security perspective, this was a **classic** **volumetric DDoS attack**, aimed at saturating validator ingress and transaction pathways rather than exploiting a protocol vulnerability. Under similar conditions, blockchain networks often experience increased latency, missed blocks, or temporary halts. Solana reported that none of these effects were observed at scale during this event. The network’s ability to absorb the traffic is attributed to a combination of protocol-level controls and operational improvements introduced following earlier congestion-related incidents. **Stake-weighted quality of service** prioritised transaction traffic backed by economic stake, while low-value or abusive traffic was rate-limited under load. In parallel, **local fee markets** helped contain congestion to specific areas, preventing chain-wide disruption. Operational maturity also contributed. Validators increasingly operate high-availability deployments with improved monitoring and automated recovery, reducing the risk that individual node failures escalate into broader network instability. For comparison, media reports indicate that the Sui network experienced delayed block production and degraded performance during a similar attack window, underscoring how different transaction prioritisation and traffic-handling models can produce very different outcomes under DDoS pressure. While details of the attacking infrastructure have not been fully disclosed, the incident reflects a broader shift. Public blockchains are now routine targets for **multi-terabit-scale DDoS attacks** and must be engineered with the same defensive assumptions as other high-exposure distributed systems. In this case, Solana reports that the attack was largely invisible to end users, marking a clear improvement over its historical behaviour under heavy network stress. --- ### About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com/). **Categories:** FastNetMon Blog --- ### [CISA warns of hacktivist DDoS attacks on critical infrastructure OT systems](https://fastnetmon.com/2025/12/12/cisa-warns-of-hacktivist-ddos-attacks-on-critical-infrastructure-ot-systems/) **Published:** December 12, 2025 **Author:** FastNetMon **Content:** CISA, together with the FBI, the Department of Energy, the EPA, and international partners, have issued a joint advisory highlighting ongoing DDoS and intrusion attacks targeting operational technology (OT) and industrial control systems (ICS) within critical infrastructure. The alert focuses on opportunistic campaigns conducted by pro-Russia hacktivist groups, which continue to exploit exposed OT devices—including SCADA and HMI systems—over the internet. These groups—including Cyber Army of Russia Reborn (CARR), NoName057(16), Z-Pentest, and Sector16—primarily scan for internet-facing VNC devices, leveraging default or weak passwords to gain access. While their attacks are technically unsophisticated, they often combine DDoS campaigns with direct manipulation of HMI systems to disrupt operations, cause loss-of-view incidents, and generate remediation work. Targeted sectors include water and wastewater, energy, and food and agriculture. ### Attack methods According to the advisory, hacktivist activity typically follows a straightforward pattern: - Scan for exposed VNC-enabled OT devices on public IP ranges. - Use brute-force or default credentials to gain access. - Manipulate HMI settings, change credentials, disable alarms, or restart devices. - Launch DDoS attacks against affected networks to facilitate intrusions or distract operators. - Publicly post evidence of the compromise, often exaggerating impact. Even low-sophistication attacks can disrupt operations, requiring manual intervention, recovery of PLCs, or restoration of HMI configurations. ### Mitigation measures CISA and partners recommend the following to reduce risk: - **Remove internet-facing OT systems** or restrict access via VPNs, firewalls, and time-limited connections. - **Enforce strong authentication**, replace default passwords with unique, robust credentials, and enable phishing-resistant MFA where possible. - **Segment IT and OT networks** and introduce DMZs to limit potential DDoS and intrusion impact. - **Monitor network traffic** for unusual connections, logins, or protocol use that could indicate scanning, brute-force attempts, or DDoS activity. - **Maintain manual control readiness** with tested backups, fail-safes, and disaster recovery procedures. - **Coordinate with vendors and service providers** to identify and remediate misconfigurations that may create vulnerabilities. The advisory also encourages asset owners to implement mature asset management practices, map data flows, and validate security controls against MITRE ATT&CK techniques relevant to OT intrusions. ### Operational impact and further resources Even though these hacktivist attacks are not as technically advanced as state-sponsored campaigns, they are opportunistic, easily replicable, and capable of causing real operational disruption. The combination of DDoS and HMI manipulation shows that even minor intrusions can have significant consequences if internet-facing OT systems are not properly secured. Read the entire advisory on [CISA’s website](https://www.cisa.gov/news-events/cybersecurity-advisories/aa25-343a). --- ### About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com/). **Categories:** FastNetMon Blog --- ### [DDoS Defense by Design: Architecture That Survives When Everything Else Fails](https://fastnetmon.com/2025/12/12/ddos-defense-by-design-architecture-that-survives-when-everything-else-fails/) **Published:** December 12, 2025 **Author:** FastNetMon **Content:** ***This article is written by [Herve Hildenbrand](https://www.linkedin.com/in/hervehildenbrand/) and was originally published on [LinkedIn](https://www.linkedin.com/pulse/ddos-defense-design-architecture-survives-when-else-herve-hildenbrand-mfohf/?trackingId=s4uu6tg9SxqHbjxslqLBpw%3D%3D). Reposted with the author’s permission.*** --- **A DDoS attack almost ruined my 40th birthday.** Not the party, but the infrastructure I was responsible for. Friends texted “happy birthday.” Colleagues texted… differently. Even though they were kind enough to shield me that day, I couldn’t stay on the sidelines. I watched our scrubbing center eat legitimate traffic alongside the attack. The protection had become the outage. Let’s call this **“Scrubbing Blindness”**: when your security solution knows less about your traffic than the attacker does. We thought we were prepared. We had the tools. We had the vendor contracts. We’d even tested it. But tests never mimic the real thing: the scale, the chaos and the presure of a live attack. What we didn’t have was architecture that understood what “normal” looked like before everything went sideways. > Your connectivity strategy IS your security strategy. You cannot bolt on DDoS protection to a fragile network. If you read my previous article on [Building Enterprise Internet Connectivity: A Practical Guide from the Trenches](https://www.linkedin.com/pulse/building-enterprise-internet-connectivity-practical-from-hildenbrand-n6flf/), you know I advocate for network sovereignty: own your AS, own your IP space, treat the edge as a strategic asset. That foundation wasn’t just about resilience. It was the architecture that makes DDoS defense *possible*. Here’s the uncomfortable truth we network engineers learn too late: the defense must be designed in, not bolted on after an attacker teaches you what you forgot. --- ### The Diversity Dividend: Why more doors mean more survivors Most enterprises connect through 1-2 upstream providers and call it “redundant.” During a volumetric attack, that’s like having two doors into a room, both facing the same angry mob. **The math of distributed entry:** Under normal conditions, multiple ingress points let you serve traffic from the closest edge. Latency drops. User experience improves. Nothing controversial here. Under attack, everything changes. A 400 Gbps attack against a dual-homed network doesn’t split politely across your links. It follows the attacker’s sources and your carrier capillarity. One upstream saturates while the other barely sweats. Here’s the cruel irony: your BGP sessions will most likely survive. CoPP protects the control plane. QoS marks protocol traffic as priority. Hold timers give you 90 seconds of grace. But your customers or the infrastructure behind your edge? They’re drowning. The 100G link is full of garbage. Legitimate traffic drops. And because BGP is fine, your monitoring shows “all green.” When that saturated link finally gets blackholed or manually shut, the **domino failure** begins: traffic shifts to your surviving upstream and brings the attack with it. That same attack against an enterprise with 6 entry points? The math shifts in your favor. Traffic still follows attacker sources and carrier capillarity, but now it fragments across more paths. Instead of two links fighting for survival, you have six absorbing the blow. Some will take more heat than others, but none drowns alone. You stay online. You have headroom. You can think. But there’s a third advantage nobody discusses: attackers hate complexity. Saturating one 10G link is trivial. Saturating six geographically distributed 100G links across different providers, different IXPs, different physical paths? That’s an expensive and technically challenging problem. Most attackers move on or change the attack vector. > **The Entry Point Multiplier:** Every additional ingress point you add doesn’t just improve resilience linearly; it exponentially increases the cost of attacking you. --- ### Detection: The “Three-Speed” problem You need three detection speeds. Most enterprises have none or one. **Speed 1: Strategic visibility (minutes to hours)** This is where [Kentik](https://www.kentik.com/) shines. Flow telemetry, historical baselines, anomaly detection across your entire topology. You see attack patterns evolve over time. You build intelligence. **Speed 2: Tactical visibility (seconds to minutes)** [Akvorado](https://github.com/akvorado/akvorado) or Kentik fills this gap beautifully in the open-source world. Real-time flow analysis, customizable dashboards, enough granularity to understand what’s happening now. **Speed 3: Reaction visibility (sub-second)** This is where [FastNetMon](https://github.com/pavel-odintsov/fastnetmon) becomes essential. [Pavel Odintsov](https://www.linkedin.com/in/podintsov/) built something remarkable: detection-to-action in seconds, not minutes. When a volumetric attack ramps up, you don’t have time for human analysis. FastNetMon sees the spike and triggers your automated response before your BGP sessions even feel pressure. Pavel is always willing to help, a brilliant mind behind a tool that does exactly what it promises. I encourage you to run a blend of all those tools. They’re not competitors; they’re complementary layers in the detection stack. > **The detection architecture:** Kentik / Akvorado for the big picture. FastNetMon for the *now* picture and *instant* actions. --- ### Flowspec: Your first line of defense (not your only line) BGP Flowspec is elegant. You push a rule to your border routers: “Drop UDP port 53 traffic from this source to this destination.” Within seconds, your entire edge enforces it. No ACL surgery. No human touch. But Flowspec has limits… **When Flowspec wins:** - Amplification attacks (NTP, DNS, SSDP) with identifiable signatures - Single-vector volumetric floods - Protocol-specific abuse (malformed packets, known attack patterns) **When Flowspec struggles:** - Application-layer attacks that look like legitimate traffic - Randomized multi-vector attacks that mutate faster than you can write rules - Attacks from clean residential IPs (botnets behind carrier-grade NAT) Here’s where the 100G port strategy from my previous article becomes critical. Flowspec stops traffic at your border. The attack doesn’t transit your internal backbone. > **The 100G + Flowspec equation:** Capacity buys you time. Flowspec buys you precision. You need both. --- ### The Scrubbing Center: Your last line (not your first !) External scrubbing centers (Lumen, Akamai, Cloudflare, your Tier-1’s DDoS service) are the nuclear option. Route your traffic through their infrastructure, let them absorb and filter the attack, receive clean traffic out the other side. **The problem with “Always-On” scrubbing:** You surrender inbound sovereignty. Every packet, every session, every customer interaction now traverses a third-party black box. I’ve debugged MTU issues, TCP window problems, and mysterious latency spikes that traced back to a scrubber “optimizing” my traffic. Good luck troubleshooting why a customer’s API calls are failing when the answer is buried inside infrastructure you don’t control. **The correct posture: On-demand activation, automatically triggered by BGP.** Your detection platform (FastNetMon/Kentik/Akvorado … ) sees an attack. It signals your automation layer. Your edge routers announce the affected prefix with a specific BGP community. Your upstream scrubbing provider sees that community and activates mitigation for just that prefix. **The cascade:** > Detection → Automation → Edge Router (BGP community tag) → Scrubber activation Your edge can also take local action. Maybe you stop announcing the attacked prefix to your IXP peers (reducing attack surface) while keeping it active toward your scrubbing-enabled transit. **Pick your scrubber wisely:** Global Tier-1 networks make sense here. Lumen, Tata, NTT: they have regional scrubbing centers distributed across their backbone. An attack originating in São Paulo gets scrubbed in São Paulo, not hair-pinned to Ashburn and back. The attack dies where it’s born. **The Surrender Protocol: Why RTBH is a trap** ![Article content](https://media.licdn.com/dms/image/v2/D4D12AQG-scrKLP9WZw/article-inline_image-shrink_1500_2232/B4DZrHpxkSIEAY-/0/1764286210533?e=1767225600&v=beta&t=LYfFzmJee_pC57M_frDfyH_1PzCRLbl3vsOuV_UFykU)RTBH aka Remote Triggered Black Hole routing. Sounds powerful, no ? Here’s what you’re actually doing: announcing to your upstream providers “please drop ALL traffic to this prefix.” Every packet. Attack traffic. Customer traffic. Everything. Let’s call this “Voluntary Extinction.” You’re not defending your infrastructure you’re executing it yourself before the attacker has to. The attacker wins twice: First, your service goes globally unavailable. The exact outcome they wanted. Congratulations… you saved them the bandwidth. Second, you broadcast weakness. You’ve just told every threat actor monitoring your network: “Look this target folds under pressure. Hit them again.” “But we protected our infrastructure!” Did you? You just forced the attacker to **move laterally**, target by target. By the time you’re done reacting, you’ve **blackholed the entire network** in a scorched earth type defense. There’s maybe a time for RTBH: when the alternative is catastrophic collateral damage to shared infrastructure you don’t own. When your upstream’s entire PoP is melting because of traffic destined to you. That’s not defense. That’s triage. > The RTBH Paradox: The moment you use it, you’ve already lost. It should exist in your playbook the way a cyanide pill exists in a spy movie: acknowledged, never celebrated, never the plan. ### The /32 Trick: Surgical Scrubbing (and the polarization play) Here’s a technique I call “Prefix Slicing.” It allows you to scrub a single attacked IP without disrupting the entire network block. This is another cheat code in the spirit of the BGP hacks from my previous article, but it requires precision. The scenario: You announce your /24 to the Internet. Normal routing. Normal traffic. An attack hits a specific IP within that range. The traditional response: Route the entire /24 through the scrubber. All 256 IPs get the scrubber treatment. Latency increases for everyone, and filtering artifacts might affect legitimate traffic. **The Constraint: Why You Can’t “Just” Scrub a /32** You might think, “I’ll just announce a /32 for the attacked IP to my scrubber.” This won’t work. The minimum globally routable prefix on the Internet is /24. If you simply announce the /32 to your scrubbing provider while leaving the /24 announced normally to your other transit providers, traffic will continue to follow the path of the /24 via your clean transit links. Most of the attack traffic bypasses the scrubber entirely, and the attack continues unabated. **The Solution: Polarization and Slicing** To make surgical scrubbing work, you must ensure that the scrubbing provider is the *globally preferred* path to your entire /24. This is called “Polarization.” Here is the surgical approach, executed via automation: 1. **Polarize the /24:** You must make the scrubbing provider the dominant path for the /24. This is achieved by withdrawing the /24 announcement from your other transit providers. The global internet must see the path to your network for this /24 through the scrubber’s AS (Autonomous System). 2. **Inject the /32 (The Slice):** Simultaneously, announce the /32 (the single attacked IP) to the scrubbing provider, tagged with the specific BGP community that activates mitigation. **How it works:** All traffic for the /24 now flows toward the scrubbing provider’s network. Once inside their AS, their internal routing takes over. BGP longest-match wins. They see two routes for the attacked IP: the /24 and the /32. The /32 is more specific. - Traffic for the attacked IP follows the /32 route and is directed to the scrubbing appliances. - The remaining 255 IPs in your /24 follow the standard /24 route, passing through the provider’s backbone *without* intensive scrubbing (depending on the provider’s implementation). This minimizes latency and potential issues for your clean traffic while ensuring the attack is mitigated. When the attack subsides, you withdraw the /32 and remove the polarization (readvertise the /24 normally to your other providers). Return to normal in seconds. --- ### The Asymmetric Reality DDoS is asymmetric warfare. You don’t know when. You don’t know how. You don’t know the vector, the volume, or the duration. But you know it’s coming. The US military uses [DEFCON](https://en.wikipedia.org/wiki/DEFCON) levels to describe readiness states. DEFCON 5 is peacetime. DEFCON 1 is nuclear war imminent. DEFCON 2 is “FAST PACE”: Armed forces ready to deploy and engage in less than six hours. That’s exactly where your DDoS defense must live. You cannot be at DEFCON 1 permanently. That’s “always-on scrubbing,” and we’ve discussed why surrendering your inbound sovereignty to a third-party black box is a trap. You cannot be at DEFCON 5 either. That’s “hoping your ISP notices before your customers do.” **DEFCON 2 means:** - Detection systems watching every ingress in real-time - Automation scripts pre-tested, staged, ready to execute - Flowspec rules templated, one API call from deployment - Scrubbing activation tested monthly, communities documented - Runbooks that require zero human decisions at 3 AM The difference between surviving a 400 Gbps attack and going dark for hours? It’s not budget. It’s not fancy hardware. It’s whether your network can reach DEFCON 1 automatically when the attack lands. BGP makes this possible. It’s not just a routing protocol; it’s an orchestration layer. Detection systems trigger routers. Routers signal upstream providers. Communities cascade actions across your entire edge faster than any human could type a single command. > **The DEFCON 2 Principle:** You don’t react to DDoS attacks. You pre-configure your reactions and let the network execute them autonomously. --- ### ​​**About the Author** **Herve Hildenbrand** is a senior network and infrastructure architect with 25+ years of experience across European enterprise and service provider networks. He leads network infrastructure for a major payment processor and specialises in VXLAN/EVPN fabrics, MPLS/BGP backbones, routing design, and large-scale migrations. Connect with Herve and read more of his articles on [LinkedIn](https://www.linkedin.com/in/hervehildenbrand/) **Categories:** FastNetMon Blog, Featured --- ### [The good and the bad of GRE tunnels in DDoS scrubbing](https://fastnetmon.com/2025/12/05/the-good-and-the-bad-of-gre-tunnels-in-ddos-scrubbing/) **Published:** December 5, 2025 **Author:** FastNetMon **Content:** One of the most common ways to protect a network from large volumetric DDoS attacks is to [divert the malicious traffic to a scrubbing centre](https://fastnetmon.com/ddos-scrubbing-centre-diversion/). These dedicated networks remove harmful packets and return only the clean traffic back to your network. GRE tunnels are often used for this return path because they work with any network that can speak BGP, and they do not require changes to your infrastructure, DNS, or application stack. At first glance, this approach seems simple and reliable. When set up correctly, it allows legitimate traffic to continue flowing back from the scrubbing center, even during massive attacks. However, the simplicity can be deceptive. Once you start tunneling heavy traffic through GRE, you’ll start noticing the myriad of headaches this approach comes with. In this article, we will explain from the ground up how GRE tunneling functions in DDoS mitigation, how traffic flows to scrubbing centres and back, and the common problems engineers encounter. We’ll also provide practical advice on mitigating these challenges. By the end, you’ll understand why GRE tunneling remains a standard tool in DDoS protection, despite its quirks and complexities. ### **Understanding GRE tunnels** GRE, or Generic Routing Encapsulation, is a simple yet powerful protocol used to send packets from one network to another through a tunnel. Think of GRE like an envelope: the original packet is the letter, and the GRE header is the envelope that allows the packet to travel safely across a different path. Just as a letter can be sent to a remote office without opening it, the original packet can pass through multiple networks without being altered. When traffic is sent through a GRE tunnel, the original IP packet is encapsulated inside a new packet that contains the GRE header and a new outer IP header. This encapsulation allows the scrubbing provider to route traffic back to your network, keeping the original source and destination addresses intact. At the receiving end, the GRE header is removed, revealing the original packet, which is then delivered to your server as if it had never left your network. This mechanism makes GRE a versatile tool for returning cleaned traffic from a scrubbing centre because it works independently of the original protocol or service, whether that’s IPv4, IPv6, or any other protocol encapsulated within IP. ### **GRE tunnels in DDoS traffic diversion** If a DDoS defence stack includes [scrubbing centre automation](https://fastnetmon.com/2025/08/06/ddos-scrubbing-centre-automation-explained/), incoming traffic can be automatically redirected to a scrubbing centre where malicious packets are filtered out. GRE tunnels provide a reliable way to return the clean traffic to your network without altering your existing infrastructure or applications. The process works as follows: once the scrubbing centre has removed harmful traffic, each clean packet is encapsulated in a GRE header — much like putting a letter into an envelope. This encapsulation allows the packets to travel across the network to your edge routers while preserving the original IP information. When the traffic arrives, the GRE header is removed, and the original packets are delivered to your servers seamlessly. Using GRE in this way makes DDoS scrubbing largely transparent to your network. BGP reroutes the traffic to the scrubbing centre automatically, while GRE ensures the safe return of clean traffic. This setup avoids the need for changes to DNS, application configuration, or network infrastructure. However, this simplicity comes with hidden costs and technical challenges, which will be discussed in the next chapter. ### **Common challenges of GRE tunnelling** GRE tunnels are a key component of automated DDoS scrubbing, but they introduce specific challenges that network operators need to understand. At a high level, there are three main categories of issues: packet size overhead, MTU-related problems, and operational complexity. #### **1. Packet size overhead** Every packet sent through a GRE tunnel gains an additional header, typically around 24 bytes for IPv4. While this may seem small, the extra bytes can add up at high traffic volumes. This increase in packet size is called packet size overhead. If the network devices along the path are not prepared for the larger packets, fragmentation can occur. Fragmented packets reduce throughput, can introduce latency, and may even break protocols that do not handle fragmentation gracefully. #### **2. MTU-related problems** Packet size overhead directly impacts the Maximum Transmission Unit (MTU) of the path. If a GRE-encapsulated packet exceeds the MTU at any point along the route, it can be fragmented or dropped. Misconfigured MTU settings, blocked ICMP messages, or failure of Path MTU Discovery (PMTUD) can result in silent packet loss. During a DDoS attack, high traffic volumes amplify these effects, potentially impacting performance and reliability of critical services. #### **3. Operational complexity** GRE tunnels require careful configuration, monitoring, and ongoing maintenance. Operators must ensure tunnel endpoints are properly verified, MTU settings are aligned, necessary ICMP messages are allowed, and traffic patterns are continuously monitored. During live DDoS events, misconfigurations or failures can cause traffic loss or session resets. Troubleshooting under attack conditions is stressful and time-consuming, emphasizing the importance of thorough preparation and regular testing. ### **Solutions and alternatives to GRE tunnelling issues** When you use GRE tunnels for DDoS scrubbing, you don’t have to accept the risks silently – there *are* well‑understood best practices to mitigate the problems, and in some cases, legitimate alternatives that avoid GRE entirely. ### **How to mitigate GRE‑specific problems** #### **Tune MTU / MSS carefully** Because GRE adds header overhead, you should reduce the MTU on the GRE/tunnel interface or adjust TCP segment sizes so that encapsulated packets remain under the MTU limit. For example: - Lower the GRE interface MTU (many recommend something like 1400 bytes) to give headroom for the extra GRE header and avoid fragmentation. - Use TCP MSS (Maximum Segment Size) clamping: force TCP sessions to negotiate a smaller MSS so payloads won’t exceed the safe size after encapsulation. - Ensure that “don’t fragment” (DF) settings, PMTUD (Path‑MTU Discovery), and ICMP “fragmentation needed” messages are allowed end‑to‑end. Without proper PMTUD, packets may be silently dropped when too large – a common cause of mysterious failures after scrubbing. In short: treat the GRE link MTU and packet size as a first‑class configuration parameter – set and test it before any real traffic has to be sent to the scrubbing centre. #### **Combine with fallback mechanisms or hybrid mitigation** Because GRE isn’t bullet‑proof, a robust defence stack often doesn’t rely solely on it. For example: - Use scrubbing – and therefore GRE for **only for selected traffic / prefixes** when required. You can automate this with [FastNetMon’s scrubbing centre diversion](https://fastnetmon.com/ddos-scrubbing-centre-diversion/) - Keep alternate mitigation methods (like [blackholing](https://fastnetmon.com/bgp-blackhole-automation/) or filtering at upstream) as fallback when GRE paths break. - Use proper documentation and runbooks so that operators know when to switch or failover if the tunnel misbehaves. ### **Alternatives to GRE‑based return paths** If you find GRE too fragile or complex, there are other options — each with trade‑offs: #### **Clean‑pipe / direct return over BGP (no GRE)** Some providers offer to send scrubbed traffic back over the same transit link via BGP announcements or routing changes, avoiding tunnels entirely. This eliminates encapsulation overhead and MTU/mss problems. However, it requires close coordination with your upstream provider and may not be available everywhere. #### **Anycast / edge‑based scrubbing (no backhaul tunnel)** With a global anycast network (often provided by large scrubbing / CDN providers), the attacker traffic is dropped at the edge, clean traffic is delivered directly — so there is no need for a tunnel back to your origin. This offers excellent performance and removes GRE‑tunnel risk. The trade‑off: you effectively put your service behind the provider’s edge, which might not fit every infrastructure or compliance requirement. #### **MPLS or Layer‑2 / L2VPN backhaul from scrubbing centre** If you have the ability (or the provider offers it), using a private link (MPLS, L2VPN, VLAN cross‑connect) from the scrubbing centre back to your network bypasses GRE/IP encapsulation entirely. This can give clean, stable connectivity. The downside is higher cost and more setup complexity, and usually only feasible for larger networks. #### **Use in‑network filtering (BGP FlowSpec / blackholing) instead of scrubbing + return** Depending on your use case, lightweight [BGP-based mitigation](https://fastnetmon.com/flowspec-ddos-mitigation/) like flow filtering or [remote blackhole](https://fastnetmon.com/bgp-blackhole-automation/) may be enough. This avoids tunnelling pitfalls entirely — but only works if filtering is effective and legitimate traffic is easy to separate from attack traffic. ### **Which option is “best practice”?** The honest answer: **it depends**. GRE tunnels are far from obsolete. In many cases – especially when you control both ends, can manage MTU/MSS, and have fallback plans – GRE remains **the most flexible and universal** way to return scrubbed traffic. That said: when your applications are latency‑sensitive, deliver real‑time traffic (gaming, VoIP), or your network cannot easily support MTU tuning and reliable ICMP/PMTUD, then alternatives like anycast‑based scrubbing or clean‑pipe return (without tunnelling) often deliver **more stable and predictable** results. --- ### **About FastNetMon** FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats.For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** FastNetMon Blog --- ### [New record-breaking DDoS: 29.7 Tbps Aisuru attack marks new high in hyper-volumetric threats](https://fastnetmon.com/2025/12/04/new-record-breaking-ddos-29-7-tbps-aisuru-attack-marks-new-high-in-hyper-volumetric-threats/) **Published:** December 4, 2025 **Author:** FastNetMon **Content:** *DDoS news: December 4th 2025* A new world-record DDoS attack has been confirmed, peaking at **29.7 terabits per second (Tbps)** and launched by the **Aisuru botnet**, a large DDoS-for-hire network using an estimated **one to four million compromised routers and IoT devices** worldwide. The attack lasted **69 seconds** and was mitigated by Cloudflare, fending off a stream of randomised junk traffic targeting an average of **15,000 destination ports per second**. The intended target was not disclosed. This is certainly not the first time Aisuru has been associated with extreme volumetric traffic. A few months ago, we reported on a [suspected **29.69 Tbps gaming outage**](https://fastnetmon.com/2025/10/08/another-record-breaking-ddos-aisuru-botnet-suspected-behind-29-69-tbps-gaming-outages/). While unconfirmed, it demonstrated that operators were already facing attack magnitudes close to today’s validated record. We also recently [analysed a Aisuru related 15.2 Tbps attack on Microsoft Azure](https://fastnetmon.com/2025/11/21/aisuru-isnt-done-with-ddos-and-the-azure-attack-shows-why-the-industry-isnt-ready/), highlighting that the botnet’s reach and accessibility are changing the logistics of offensive traffic in the entire industry. ### **Why DDoS attacks peak toward the end of the year** The timing aligns with a predictable and recurring trend. DDoS activity often escalates in Q4, coinciding with peak traffic periods such as retail holidays, gaming spikes, seasonal online events and end-of-year commercial load. These conditions increase the value and impact of disruption. As more botnet capacity becomes available through commercialised leasing models, attackers simply rent the bandwidth they need for the period of highest leverage. ### **Collateral damage and outbound DDoS risks** One of the emerging concerns highlighted in this record attack is that **collateral disruption can occur even when an organisation is not the intended target**. When volumetric attacks exceed local infrastructure limits or propagate through upstream carriers, they can affect networks along the path, including internet service providers, cloud environments and peering partners. We have previously written extensively about [**outbound DDoS**](https://fastnetmon.com/2025/09/24/outbound-ddos-the-attack-you-might-be-unknowingly-hosting/), where compromised assets inside a network unknowingly contribute to attacks. Even if a business believes it is not at risk due to its smaller profile or limited public-facing footprint, it may still be used as part of someone else’s DDoS campaign. The risks are not only external disruption but reputational damage, blacklisting, traffic throttling and loss of carrier trust. Additionally, high-capacity botnets such as Aisuru amplify this concern, as the sheer volume of junk traffic is growing to unbearable levels for some ISPs to handle. ### **How to defend against hyper-volumetric DDoS: the FastNetMon way** Always-on scrubbing may appear to be the safest DDoS defence model, but in reality it is **neither technically preferable nor financially viable for many organisations**. Sending all traffic through a scrubbing provider introduces unnecessary latency, increases complexity and inflates operational cost – especially when most attacks last only a few seconds. However, to defend against attacks at the scale delivered by Aisuru, access to cloud-capacity scrubbing is essential. FastNetMon enables this in a **vendor-neutral, cost-efficient way**, [integrating seamlessly with large scrubbing platforms](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-and-ddos-scrubbing-centers-integration/) such as **Cloudflare Magic Transit** – while remaining compatible with other providers in the same tier. FastNetMon continuously monitors network telemetry via NetFlow, sFlow, IPFIX and other data sources. When an attack crosses thresholds, it can automatically announce **only the impacted prefix (commonly a /24)** to the chosen scrubbing provider. Platforms such as Magic Transit then absorb and filter the malicious traffic at global network scale, returning clean traffic via GRE or IPsec tunnels. Crucially, **clean traffic continues to flow directly**, without routing all traffic through the scrubbing cloud. This approach reduces cost, avoids latency penalties and ensures operators can defend against even terabit-scale floods without redesigning their everyday traffic path or locking themselves into a single mitigation vendor. --- ## **About FastNetMon** FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats.For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** FastNetMon Blog --- ### [Why DDoS botnets are so hard to take down?](https://fastnetmon.com/2025/12/02/why-ddos-botnets-are-so-hard-to-take-down/) **Published:** December 2, 2025 **Author:** FastNetMon **Content:** Every time law enforcement announces a major DDoS botnet operation, the Internet seems to exhale in relief. Servers are seized, operators arrested, domains pulled out from under them. For a moment, attack volumes dip, and the collective hum of malicious traffic grows quieter. But the silence rarely lasts. Within days – sometimes within hours – the same operators are back, rebuilt, rebranded, and [ready to sell attack capacity again](https://fastnetmon.com/2025/04/30/most-infamous-ddos-booter-services-and-user-consequences/). This cycle has played out repeatedly over the past two years, even as international coalitions have executed some of the most sophisticated cybercrime disruptions to date. The pattern raises a difficult question: why is it so hard to make a DDoS takedown stick? The answer begins with the architecture of the botnets themselves. Modern DDoS botnets did not grow from the old model of a single command-and-control server hiding in a shadowed corner of the Internet. They have evolved into sprawling systems designed to survive being hunted. Many use peer-to-peer control layers that avoid creating any central point to target. Others employ rolling domain algorithms that generate fresh rendezvous points faster than police can file takedown paperwork. Some scatter their infrastructure across constantly shifting IP pools, slipping through the cracks of fast-flux DNS long enough to regroup. And even if you remove every server they rely on, the real heart of a botnet still beats elsewhere: inside millions of insecure devices. Home routers with forgotten firmware, cameras that never received a security patch, cheap IoT gadgets that were never designed to survive on the open Internet. These devices live for years and are easily reinfected. Even when authorities obtain rare court orders to clean infected routers, the relief is temporary. Once a device is abandoned by its vendor, it remains exposed, and attackers know it. The frustration for defenders is that the attackers’ job has become easier, not harder. DDoS crews no longer need a massive botnet to deliver headline-making attacks. They can borrow strength from open DNS resolvers, misconfigured NTP servers, or vulnerable protocol implementations that act as amplifiers. They can mix modest IoT botnets with bursts of cloud compute abuse. They can tap into weaknesses like the HTTP/2 Rapid Reset flaw and turn a small number of machines into disproportionate firepower. The raw materials for an attack are everywhere, and [they remain embarrassingly cheap](https://fastnetmon.com/2025/04/10/ddos-booters-and-ip-stressers-explained-by-experts/). With all this, it is tempting to frame takedowns as a losing battle. But that is not the full picture. Over the past year, international law enforcement has shown remarkable persistence and coordination. Each new wave of Operation PowerOFF demonstrates how global agencies have become more agile and more willing to move together. When Europol took action against the pro-Russian collective NoName057(16), the operation spanned multiple countries, over a hundred servers, and a web of search warrants and notices to supporters. These actions do not eradicate botnets, but they do slow operators down, cause financial losses, disrupt their infrastructure, and push the most experienced criminals into hiding. They also deter a generation of would-be copycats who see the increased risk. The challenge, then, is not that law enforcement is failing. It is that the ecosystem they are fighting has been engineered to regenerate. Botnets bounce back quickly because rebuilding costs almost nothing. Cleaning the global device fleet, on the other hand, is slow, fragmented, and dependent on manufacturers and end users who may never even realise their hardware has been hijacked. This is the core tension that defines the DDoS problem today. Police can pursue operators, seize servers, and take down the storefronts that sell attack time. But they cannot patch the world’s routers, cannot force vendors to eliminate default passwords, and cannot harden the millions of devices that remain exposed by design. Still, the situation is far from hopeless. In fact, the most promising path forward lies in combining strengths rather than relying on any single solution. Law enforcement can keep increasing pressure on operators, raising the cost and lowering the reward. Network operators can strengthen their own infrastructure, making DDoS attacks more expensive, less effective, and more likely to be absorbed or mitigated instantly. And across the industry, collaboration matters: upstream providers can monitor and block outbound attacks just as aggressively as inbound ones, cutting off malicious traffic closer to its source and shrinking the usable footprint for botnets. DDoS will not disappear overnight. But with stronger global cooperation, more resilient networks, and a willingness to treat DDoS not just as an inbound threat but as a shared responsibility, the economics begin to shift. When the cost of launching attacks rises and the damage they can inflict falls, the business model behind these botnets starts to collapse. And that is where real, lasting progress becomes possible. --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** FastNetMon Blog --- ### [ShadowV2 resurfaces: IoT botnet activity amid AWS outage highlights persistent device vulnerabilities](https://fastnetmon.com/2025/11/26/shadowv2-resurfaces-iot-botnet-activity-amid-aws-outage-highlights-persistent-device-vulnerabilities/) **Published:** November 26, 2025 **Author:** FastNetMon **Content:** During late October 2025, a new Mirai-derived botnet dubbed **ShadowV2** was observed exploiting unpatched IoT devices across multiple sectors and 28 countries. While the activity lasted only a day, it underscores the ongoing risks posed by unsecured connected hardware. ## Technical summary of the current ShadowV2 campaign Industry research reports that ShadowV2 primarily targeted consumer and enterprise IoT devices from vendors including **D-Link, TP-Link, DigiEver, TBK, and DD-WRT**-based systems. Infection occurred through a set of known vulnerabilities, such as command injection and buffer overflow issues, enabling attackers to drop a downloader script (*binary.sh*) that retrieved device-specific binaries from a remote host. Once installed, ShadowV2 mirrors aspects of the LZRD Mirai variant: - XOR-encoded configuration file decrypted at runtime - Contact with a command-and-control server for instructions - Multiple DDoS vectors supported (UDP floods, TCP SYN floods) - Obfuscation techniques to blend attack traffic with legitimate network activity The botnet affected a diverse range of industries, including **technology, retail, manufacturing, telecoms, education, and government**, demonstrating how widespread unpatched devices remain a critical security weakness. ## Geographic reach Observed infections spanned 28 countries, including the US, Canada, UK, France, Italy, China, Japan, and Australia. While total device counts are not yet disclosed, the scale demonstrates the rapid mobilisation potential of IoT-targeting botnets. ## Reference to previous ShadowV2 campaigns Earlier in 2025, [we reported](https://fastnetmon.com/2025/10/01/shadowv2-a-new-botnet-that-turns-misconfigured-docker-apis-into-a-pay-to-use-cloud-ddos-platform/) ShadowV2 as a **cloud-native, DDoS-as-a-service platform** exploiting misconfigured Docker APIs on AWS and other cloud providers. That iteration allowed paying customers to launch DDoS attacks via a self-service portal, containerised malware, and subscription-based models — a notable shift from traditional botnet approaches. While both campaigns share the ShadowV2 name, **there is currently no confirmed technical link between the cloud-based and IoT-targeting versions**: - Target environments differ: cloud containers versus IoT devices - Attack techniques and payload delivery mechanisms are distinct - No shared command-and-control infrastructure has been documented For more on the previously reported ShadowV2, read our earlier analysis of the cloud-based, pay-to-use DDoS platform [here](https://fastnetmon.com/2025/10/01/shadowv2-a-new-botnet-that-turns-misconfigured-docker-apis-into-a-pay-to-use-cloud-ddos-platform/). --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats.For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** FastNetMon Blog --- ### [Aisuru isn’t done with DDoS — and the Azure attack shows why the industry isn’t ready](https://fastnetmon.com/2025/11/21/aisuru-isnt-done-with-ddos-and-the-azure-attack-shows-why-the-industry-isnt-ready/) **Published:** November 21, 2025 **Author:** Outi Maria Pietilanaho **Content:** This week, Microsoft confirmed it had mitigated the largest DDoS attacks ever observed on Azure: a 15.72 Tbps, 3.64 Bpps barrage against a single public IP endpoint in Australia. The attack was powered by Aisuru — the same TurboMirai-class botnet behind the 22 Tbps attack recently reported by Cloudflare. That alone is noteworthy. But the more interesting part is *when* this happened. Only weeks ago, many of us in the industry — including FastNetMon and KrebsOnSecurity — noted that [Aisuru appeared to be shifting its focus towards residential proxy services](https://fastnetmon.com/2025/11/07/aisuru-botnet-shifts-focus-from-ddos-to-residential-proxy-services/) and broader “multi-use” abuse, potentially stepping back from DDoS as its primary business model. Our own research suggested a tactical pivot: moving away from high-profile DDoS events and towards monetisable, less noisy operations. But this latest attack shows something different. Aisuru hasn’t left the DDoS scene — it’s simply operating with a highly selective, high-impact strategy. ### **A powerful botnet, but a blunt instrument** Despite its size and sophistication in other areas, Aisuru has notable weaknesses when used for DDoS: - **Single-vector attacks Most Aisuru attacks are direct-path UDP floods or simple TCP/UDP bursts — not the complex, multi-vector sequences we often see in more advanced campaigns. - **Little to no spoofing TurboMirai-class malware can’t generate spoofed traffic, which makes traceback possible - **Blunt-force strategy Aisuru relies on raw volume — enormous bandwidth and packet rates — rather than subtlety. It hits hard, but not cleverly. So should we conclude that Aisuru is less dangerous than it looks? Not quite. ### **The operational reality: if you’re too slow, you’re down** The uncomfortable truth is this: unless an organisation has a very rapid response capability *and* the network capacity to absorb the immediate impact, an Aisuru-class attack is not survivable. The attacks Aisuru launches are over and done with usually in less than a minute. If you cannot detect and mitigate within seconds, you will experience an outage. Many networks simply don’t have that level of readiness — and Aisuru is build around this factor. ### **The blind spot no one is talking about: outbound DDoS** There’s an even more interesting angle that the industry is barely discussing yet: the collateral damage of the attacks. Aisuru’s attacks send extraordinary volumes of traffic *through networks that are not the intended targets*. These are often broadband access networks hosting compromised devices. This raises a critical, under-examined challenge: **outbound DDoS**. [We wrote about this recently](https://fastnetmon.com/2025/09/24/outbound-ddos-the-attack-you-might-be-unknowingly-hosting/) — the idea that networks may unknowingly host massive attacks leaving their ASN. The operational, regulatory, and reputational risks here are there, yet many operators still focus almost exclusively on inbound protection. Outbound DDoS may well be the quietest problem in the DDoS ecosystem today. But as the attack volumes are growing exponentially, how much longer can we afford to ignore it? ### **Where we go from here** The Azure attack is a reminder that: - Aisuru hasn’t abandoned DDoS — it is doubling down on high-volume, low-complexity attacks. - Major scrubbing centers can absorb the attack volume, but the speed of detection may pose a problem. - The real systemic risk may become in the form of the *networks carrying the attack*, not only the networks receiving it. If we want a more resilient Internet, the telco and ISP community must collaborate. Inter-ASN FlowSpec and outbound traffic monitoring offer a vendor-neutral way to contribute to resolving the situation. The solutions already exist — but they only work if deployed across the ecosystem. The DDoS landscape is evolving fast, and the times are, in every sense, very interesting. --- ### About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** FastNetMon Blog --- ### [US, UK and Australia sanction Russian hosting providers behind major ransomware and DDoS activity](https://fastnetmon.com/2025/11/21/us-uk-and-australia-sanction-russian-hosting-providers-behind-major-ransomware-and-ddos-activity/) **Published:** November 21, 2025 **Author:** FastNetMon **Content:** The U.S. Department of the Treasury, together with the UK and Australia, has announced coordinated sanctions against a network of Russian “bulletproof” hosting providers (BPH) used to run ransomware operations and repeated DDoS attacks against organisations in the U.S. and allied countries. The action focuses on **Media Land**, a long-standing St. Petersburg–based hosting operator, as well as several related companies and individuals who helped maintain its infrastructure. ### Media Land’s role in supporting DDoS campaigns Media Land has been a known infrastructure provider for groups behind high-impact ransomware campaigns, including Lockbit, BlackSuit and Play. According to the U.S. Treasury, Media Land’s servers have also been involved in **multiple DDoS attacks targeting U.S. enterprises and critical infrastructure**. The provider operated using the typical BPH model: servers provisioned quickly, minimal verification, rapid replacement of abused resources, and active measures to evade takedowns. OFAC also sanctioned **ML Cloud, Media Land Technology, and Data Center Kirishi**, which host parts of the same infrastructure and are frequently used in tandem during ransomware and DDoS activity. Leadership figures—including director **Aleksandr Volosovik**, known online as *Yalishanda*, and employee **Kirill Zatolokin**—were designated for running and maintaining the service, handling payments, and providing operational support to cybercriminal customers. ### Continued pressure on Aeza Group The sanctions also expand to **Hypercore Ltd.**, a UK-based company linked to **Aeza Group**, which was designated earlier this year. After its initial sanctioning, Aeza attempted to rebrand and migrate infrastructure through new front companies. OFAC now lists Hypercore, along with Serbian and Uzbek entities **Smart Digital Ideas DOO** and **Datavice MCHJ**, as part of this broader sanctions-evasion effort. Individuals behind this activity, including **Maksim Makarov** and **Ilya Zakirov**, have also been designated for facilitating infrastructure moves and establishing new payment channels. ### What this means for defenders For network defenders and service providers, this announcement reinforces a familiar pattern: **large-scale DDoS operations depend heavily on resilient, obscure hosting networks with little to no oversight**. Bulletproof hosting remains a key enabler because it offers the combination of bandwidth, persistence and operational freedom attackers need to launch and sustain campaigns. Sanctioning infrastructure operators does not remove all malicious capacity from the internet, but it does increase friction for attackers. It disrupts payment flows, forces relocation, and often results in temporary instability across their hosting footprint. Defenders can expect some short-term shifts in command-and-control endpoints and DDoS orchestration nodes as these actors attempt to move workloads off the newly sanctioned networks. ### Guidance for organisations CISA and international partners have also released updated guidance for identifying and mitigating risks associated with bulletproof hosting providers. Organisations should continue monitoring for traffic patterns associated with fast-moving or frequently re-provisioned infrastructure—common indicators of BPH-backed DDoS operations. FastNetMon will continue tracking developments in the hosting ecosystem and sharing updates as new infrastructure trends and threat behaviours emerge. --- ### About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** FastNetMon Blog --- ### [ShadowRay 2.0: Self-replicating botnet turns Ray clusters into DDoS weapons](https://fastnetmon.com/2025/11/21/shadowray-2-0-self-replicating-botnet-turns-ray-clusters-into-ddos-weapons/) **Published:** November 21, 2025 **Author:** FastNetMon **Content:** Researchers are tracking a self-replicating botnet campaign, **ShadowRay 2.0**, that is targeting internet-facing **Ray clusters**, the open-source distributed computing framework used to run AI and other workloads. The attackers exploit a **two-year-old, unpatched vulnerability (CVE-2023-48022)** to take control of exposed clusters. The malware uses the exposed Ray dashboards to submit jobs without authentication, allowing it to **spread automatically across clusters worldwide**. In addition to **cryptomining and data theft**, the compromised machines are being used to launch **DDoS attacks** against external websites and other infrastructure. Oligo Security researchers describe how the attackers leverage Ray’s orchestration features to pivot to other nodes in the cluster and propagate the payload. The campaign has targeted organisations globally, with clusters running expensive GPUs among the most affected. “The attackers have turned legitimate cluster management features into tools for a self-propagating operation,” the researchers said. The compromised systems can run jobs across nodes, establish reverse shells, and maintain persistence while keeping CPU usage below 60% to avoid detection. Despite takedowns on GitLab and GitHub, the operation continues, illustrating its automated nature. With more than **230,000 Ray clusters exposed online**, the attack surface is significant. **Mitigation** requires limiting access to Ray dashboards, implementing firewall rules, and adding authentication where possible. Anyscale, the original developer of Ray, provides a **Ray Open Ports Checker** to help identify exposed clusters. ShadowRay 2.0 shows that misconfigured compute clusters can be weaponised for DDoS at scale. Organisations running Ray should assume that exposed dashboards will be **targeted automatically** by this self-replicating botnet. --- ### About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** FastNetMon Blog --- ### [DDoS trends in public administration – new data from ENISA report](https://fastnetmon.com/2025/11/14/ddos-trends-in-public-administration-new-data-from-enisa-report/) **Published:** November 14, 2025 **Author:** FastNetMon **Content:** The European Union’s cybersecurity agency, ENISA, has published a new sectorial threat landscape report and a [press release](https://www.enisa.europa.eu/news/public-administration-increasingly-targeted-by-ddos-attacks) showing that public administrations are increasingly targeted by cyber-attacks, with DDoS emerging as the most common threat. Public administration, classified as highly critical under the NIS2 Directive, delivers essential services such as education, healthcare, transportation, and government functions. This makes the sector a high-value target, and for network engineers, it signals the importance of revisiting DDoS mitigation and monitoring strategies. ENISA analysed 586 publicly reported cyber incidents across EU Member States in 2024. Public administration accounted for around 38% of all incidents, more than any other sector. Within the sector, central government entities were hit the hardest, representing roughly 69% of incidents, while local and regional authorities made up about 24% and 7%, respectively. DDoS attacks were responsible for approximately 60% of all incidents affecting public administration, making them the dominant threat. While most attacks were short-lived and did not directly disrupt services, their frequency and timing—particularly during July and December—create an ongoing risk profile for public-facing services. Hacktivist activity drove the majority of these attacks, accounting for nearly 63% of incidents, while cybercrime operators were responsible for around 16%, and state-linked actors for 2.5%. The motivations behind hacktivist campaigns are often ideological rather than financial, aiming to cause disruption or attract attention. This pattern can influence how network teams configure detection thresholds, monitor traffic, and respond to application-layer floods or short, repeated bursts of traffic. Data-related incidents, including breaches and exposures, were less common but carried a higher impact. Data breaches accounted for about 17% of incidents, and exposures roughly 1%. Even though ransomware and cyberespionage events were observed less frequently, their potential disruption to critical services, such as e-ID systems, tax portals, and court scheduling, highlights the importance of layered cybersecurity strategies. ENISA recommends strengthening architectural resilience by placing critical portals behind content delivery networks or web application firewalls with always-on protection and publishing static fallback pages with DNS failover. Redundancy across service providers is also crucial to prevent a single point of failure. Operational preparedness is equally important. Public administration teams should maintain incident response plans, including contacts for ISPs and cloud providers, and run exercises to test how cascading failures could affect multiple agencies. Collaboration and intelligence sharing with national CERTs and other agencies can help identify emerging threats and anticipate coordinated campaigns. For FastNetMon users, these findings reinforce the value of real-time traffic monitoring and automated alerts. While public sector DDoS attacks are often short, having visibility into abnormal traffic patterns, a clear response playbook, and a community to share detection rules can reduce downtime and improve mitigation speed. Integrating these practices helps ensure that public services remain available even under repeated attack attempts. The 2025 ENISA report confirms that public administrations in the EU are likely to remain among the most targeted sectors in the short-to-mid term. Network engineers and security teams must focus on resilience, detection, and collaboration to protect critical services and maintain citizen trust. Ensuring telemetry coverage, fallback site readiness, and well-practiced response plans is essential in this evolving threat landscape. --- ### About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** FastNetMon Blog --- ### [Belgium hit by twin DDoS campaigns — what we know](https://fastnetmon.com/2025/11/14/belgium-hit-by-twin-ddos-campaigns-what-we-know/) **Published:** November 14, 2025 **Author:** FastNetMon **Content:** In early November 2025, Belgian networks were hit by two related DDoS campaigns targeting telecom operators, healthcare services, and military-intelligence websites. The pro-Russian hacktivist group NoName057 publicly claimed responsibility, citing Belgium’s political stance as the motive. ### Telecom and healthcare impact On 5 November, Proximus and Scarlet reported brief website outages after technicians detected unusual traffic around 07:20 CET, followed by a sharp surge at 07:30. Proximus confirmed that systems held and disruption remained limited. Around the same time, Ghent University Hospital (UZ Gent) experienced slower communication with several external systems, causing temporary delays in accessing information, though internal systems and patient care continued normally. NoName057 boasted on Telegram that it had hit the telecom operators and an internal Telenet portal, though Telenet denied any impact. The group referenced comments made by Belgium’s defence minister in a recent interview as justification for the attacks. Additional Belgian targets—including industrial printer manufacturer CP Bourg and the municipality of Comines-Warneton—reported cyber disruptions on the same day. ### Military-intelligence websites targeted Shortly afterwards, the same group claimed another DDoS attack—this time on several websites belonging to Belgium’s military-intelligence service, SGRS/ADIV. The attack coincided with a national-security meeting. The Defence Ministry confirmed that the websites were briefly unavailable but stressed that no breach occurred and there was no indication of data being accessed or leaked. ### Recurring activity Belgium has been repeatedly targeted by NoName057 over the past two years, including campaigns during the 2024 election period and multiple government-website disruptions earlier in 2025. The group appears to have renewed its focus on Belgian institutions, with indications of further activity circulating on Telegram. --- ### About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats.For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** FastNetMon Blog --- ### [BGP Blackhole for DDoS Mitigation — and How to Automate It with FastNetMon](https://fastnetmon.com/2025/11/14/bgp-blackhole-for-ddos-mitigation-and-how-to-automate-it-with-fastnetmon/) **Published:** November 14, 2025 **Author:** FastNetMon **Content:** *We are pleased to welcome a guest contributor: BGP Brian (Brian Wilson). Brian leads the BGP Black Belt training community and the consultancy BGP Engineering and Design Group, and is an active voice on LinkedIn discussing all things BGP.* --- Border Gateway Protocol (BGP), as you’re probably aware, is the routing protocol of the Internet. It allows **autonomous systems** (i.e. large organizations like service providers or enterprises) to exchange routing information. However, one of the more interesting uses of BGP is to serve as a control mechanism for mitigating DDoS attacks. This approach, known as BGP blackholing or **Remote Triggered Black Hole (RTBH)** filtering, is simple, effective, and supported by virtually all major routers. In this post, we’ll examine how RTBH works in detail and how FastNetMon can automate its deployment for faster and more consistent DDoS response. ### **What is a DDoS Attack?** [A DDoS (Distributed Denial of Service) attack ](https://fastnetmon.com/2026/09/21/ddos-explained-what-is-a-distributed-denial-of-service-attack/↗)is when a target such as an IP address, website, or network service is flooded with massive volumes of traffic from distributed sources. These attacks are often carried out using large botnets with thousands or even hundreds of thousands of compromised devices. Because the traffic comes from so many sources, it’s nearly impossible to stop the attack by blocking a single IP or host. The result is predictable: legitimate traffic can’t get through, and the service becomes unavailable. DDoS attacks have become one of the most common and disruptive cybersecurity threats. Every major ISP, hosting provider, and enterprise network has had to develop strategies to defend against them. ### **The Traditional Response: Manual Null Routing** On a single router, one of the quickest ways to drop unwanted traffic is to create a static null route. For example, to configure this on a Cisco router: ip route \[target-ip\] Null0 This sends all traffic to the target IP destination to a “black hole”, i.e. simply dropping it. While this works for one router, it quickly becomes impractical for large networks with hundreds or thousands of routers. Even worse, the attack traffic might still traverse part of your network before being dropped, consuming bandwidth and potentially affecting other services. A more efficient way to handle DDoS attacks is to use BGP. ### **Using BGP for Blackholing** BGP allows you to propagate routing information across your entire network, or even to your upstream providers. By announcing a route for the attacked IP address with a special community value, you can signal to your upstream carrier to drop that traffic before it ever reaches you. This process is called **Remote Triggered Black Hole (RTBH)** filtering. For example: - You advertise the attacked IP prefix to your upstream provider via BGP. - You attach a special community (e.g. <ASN>:666) via a route map. - Your upstream provider’s routers recognize the community and automatically route traffic for that IP to a null interface. This results in the malicious traffic being stopped upstream, ideally as close to the source as possible, before it can overwhelm your network. ### **Blackholing Inside Your Own Network** You can also deploy internal blackholing, for example if you yourself are a service provider. This involves creating a static route on every router in your network that drops all traffic to a fixed “dummy” ip address (say 192.0.2.1): ip route 192.0.2.1 Null0 Then, when a specific IP is attacked, you use BGP to advertise a route for that IP with the dummy address as its next hop: ip route \[target-ip\] 192.0.2.1 The advantage here is that you only have to configure this route once, and then use the network command or redistribution to inject it into BGP, which will advertise the route throughout your network. After a recursive route lookup, each router will resolve the next hop to Null0, and drop the malicious traffic. ### **Automating Blackhole Routing with FastNetMon** Traditionally, blackholing was a manual process. Network engineers detected attacks, logged into routers, and triggered null routes themselves. But this is a time consuming process that can leave parts of your network unavailable for long periods of time. That’s where **FastNetMon** comes in. FastNetMon continuously monitors your network using NetFlow**,** analyzing traffic patterns in real time. When it detects an anomaly that looks like a DDoS attack (for example, a sudden spike in packets per second to a single host) it automatically triggers a BGP announcement for the target IP with the blackhole community or a dummy next-hop. Your routers (and optionally your upstream providers) propagate this route and start dropping traffic for that destination. Once the attack subsides, FastNetMon automatically withdraws the route, restoring normal service. Importantly, FastNetMon doesn’t need to run on a router. It can run on a dedicated server that peers with your routers via BGP. That makes integration simple and non-intrusive. ### **Final Thoughts** BGP blackholing remains one of the simplest and most powerful DDoS mitigation techniques. And with automation tools like **FastNetMon**, it’s easier than ever to implement. By combining real-time monitoring, instant reaction, and upstream cooperation, FastNetMon helps ensure that DDoS attacks are stopped at the edge. Or better yet, before they even reach your network. To learn more about how FastNetMon automates RTBH and integrates with your routing infrastructure, visit:[ https://fastnetmon.com/bgp-blackhole-automation/](https://fastnetmon.com/bgp-blackhole-automation/) --- ### **About the Author** BGP Brian (Brian Wilson) runs a BGP training community on Discord called BGP Black Belt, as well as the consulting firm BGP Engineering and Design Group. He also regularly posts about BGP topics on LinkedIn. You can find him at [www.linkedin.com/in/brianwilson-bgp](http://www.linkedin.com/in/brianwilson-bgp). ### **About FastNetMon** FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** FastNetMon Blog --- ### [Aisuru botnet shifts focus from DDoS to residential proxy services](https://fastnetmon.com/2025/11/07/aisuru-botnet-shifts-focus-from-ddos-to-residential-proxy-services/) **Published:** November 7, 2025 **Author:** FastNetMon **Content:** The Aisuru botnet, responsible for multiple record-breaking DDoS attacks this year, has reportedly altered its operations to supply infected IoT devices for use as residential proxies. This marks a shift from high-volume, short-term attacks toward a more sustainable, revenue-generating model. First identified in August 2024, Aisuru has infected by now at least 700,000 IoT devices, including routers and security cameras. Earlier this year, it executed DDoS attacks exceeding 6 terabits per second, with some campaigns reportedly [reaching close to 30 terabits per second](https://fastnetmon.com/2025/10/08/another-record-breaking-ddos-aisuru-botnet-suspected-behind-29-69-tbps-gaming-outages/), overwhelming targeted networks and, in some cases, [disrupting ISP services](https://fastnetmon.com/2025/10/15/ddos-botnet-aisuru-drives-record-outbound-floods-from-infected-isp-hosted-iot/). Multiple broadband operators experienced significant operational impact due to [outbound DDoS traffic](https://fastnetmon.com/2025/09/24/outbound-ddos-the-attack-you-might-be-unknowingly-hosting/) exceeding 1.5 Tb/sec from infected devices. [As reported in *KrebsOnSecurity*](https://krebsonsecurity.com/2025/10/aisuru-botnet-shifts-from-ddos-to-residential-proxies/#comments), Aisuru’s operators recently updated the botnet’s malware to allow compromised devices to be rented to residential proxy providers. These services route Internet traffic through infected devices, making connections appear as though they originate from legitimate residential IP addresses. Experts note that this shift has coincided with a dramatic increase in residential proxies, which are being used for large-scale content scraping and data collection activities, including feeding AI and large language model projects. Residential proxies are often resold through a complex ecosystem. Proxy providers operate reseller programs and software development kits (SDKs) that allow other apps and developers to turn end-user devices into traffic relays. Some proxy networks are white-labeled, creating multiple layers between the original compromised devices and the end customer. Notable providers cited in industry research include Luminati (Bright Data), Oxylabs, and IPidea, along with several of IPidea’s associated brands, which collectively manage millions of residential IPs. The trend of repurposing IoT botnets for residential proxies is not unique to Aisuru. Other malware families, such as Badbox 2.0, have similarly infected millions of smart devices—including TVs, projectors, and vehicle infotainment systems—to enable proxy or other persistent operations. Experts say that the increasing availability of residential IPs has facilitated aggressive content scraping campaigns, which can be difficult to detect because traffic appears to originate from legitimate home users. The operational impact of the botnet extends beyond DDoS. Even when not used to flood targets, infected devices contribute to network congestion for ISPs, potentially overloading line cards or degrading service for other customers. Analysts say that Aisuru now functions as both a proxy infrastructure provider and a latent DDoS platform, capable of returning to high-throughput attacks if needed. While Aisuru continues to operate as a considerable IoT threat, its focus on proxy services represents a notable evolution from the headline-grabbing DDoS campaigns that defined the botnet earlier in 2025. FastNetMon is actively monitoring the situation and will continue reporting updates as new developments emerge. --- ## **About FastNetMon** FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** FastNetMon Blog --- ### [DDoS attacks disrupt Poland’s leading mobile payment system BLIK](https://fastnetmon.com/2025/11/07/ddos-attacks-disrupt-polands-leading-mobile-payment-system-blik/) **Published:** November 7, 2025 **Author:** FastNetMon **Content:** Poland’s largest digital payment service, BLIK, has suffered periodic outages after being targeted by distributed denial-of-service attacks over the weekend and into Monday. The incidents caused intermittent disruption for customers attempting to complete transactions through their mobile banking apps. BLIK confirmed that its infrastructure was hit by “external DDoS-type attacks” and noted that mitigation efforts were underway to restore normal service. The platform provides instant payments for online purchases, point-of-sale transactions and ATM withdrawals, processing more than 1.39 billion operations in the first half of 2025 alone. Its popularity has made it a core part of Poland’s financial system, surpassing card usage in online commerce. Polish Digital Affairs Minister Krzysztof Gawkowski said the attacks originated outside Poland and that state security services are working closely with operators to contain the impact. He also commented on a separate breach involving the travel agency Itaka, which led to leaked customer login details. It is not yet clear whether the two incidents are connected. The disruption comes as Poland remains on heightened alert for hybrid threats amid ongoing geopolitical tensions in the region. Analysts have warned that high-visibility financial services and national digital infrastructure are increasingly attractive targets for adversaries seeking to spread instability and undermine public trust with [geopolitically motivated cybercrime](https://fastnetmon.com/2025/05/19/ddos-in-geopolitics-when-network-traffic-becomes-a-digital-weapon/). While the attacks have been managed without long-term outages, the events highlight how quickly DDoS activity can cause operational challenges for widely used payment systems. Continuous monitoring, fast-acting mitigation and strong upstream protections remain essential as threat levels rise across Europe. --- ## **About FastNetMon** FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** FastNetMon Blog --- ### [Hezi Rash – new hacktivist group claims over 350 DDoS attacks worldwide](https://fastnetmon.com/2025/11/07/hezi-rash-new-hacktivist-group-claims-over-350-ddos-attacks-worldwide/) **Published:** November 7, 2025 **Author:** FastNetMon **Content:** A newly emerged hacktivist collective calling itself Hezi Rash (‘Black Force’) has sharply increased [DDoS activity](https://fastnetmon.com/2025/08/05/what-is-a-ddos-attack-history-motives-and-methods-explained/) across multiple countries. Between August and October 2025, researchers observed around 350 attacks — a remarkable volume for a group that had only surfaced recently. Unlike more [traditional hacktivist campaigns](https://fastnetmon.com/2025/05/19/ddos-in-geopolitics-when-network-traffic-becomes-a-digital-weapon/), Hezi Rash does not limit its focus to one region or sector. Targets have included government services, news outlets, financial portals and entertainment platforms. The operations are ideologically motivated and often triggered by perceived cultural or political provocations. One recent trigger was the online spread of content showing Kurdish symbols being defaced, which prompted a series of retaliatory attacks. Japan, Turkey, Israel, Germany and Iran were among the most frequently hit countries, with Japan alone recording more than 60 incidents in just a few months. Rather than building custom attack tools, the group has taken advantage of [rental infrastructure](https://fastnetmon.com/2025/04/10/ddos-booters-and-ip-stressers-explained-by-experts/) and shared [botnets](https://fastnetmon.com/2025/06/18/anatomy-of-a-botnet/), allowing fast scaling and instant visibility without requiring significant technical expertise. Researchers say this pace of activity is unusual for an ideologically driven actor. The volume of attacks in such a short period indicates coordinated logistics and access to powerful infrastructure. The group’s targeting also breaks expected patterns: symbolic triggers and media flashpoints are increasingly driving operations against non-regional targets, which makes defensive prioritisation more complex for organisations that might not consider themselves likely victims. Attribution is another challenge. Because the attacks rely on publicly accessible [DDoS-as-a-Service platforms](https://fastnetmon.com/2025/04/30/most-infamous-ddos-booter-services-and-user-consequences/) such as EliteStress and Abyssal DDoS v3, the same infrastructure can be reused by other actors. This overlap makes it difficult to distinguish between different hacktivist operations and limits the effectiveness of simple IP-based filtering. The attacks are not always exceptionally large in terms of bandwidth, but their frequency and unpredictability place a continuous burden on network defenders. Hezi Rash emerged in 2023, framing itself as a digital defender of Kurdish communities and blending nationalist and religious messaging. Its online presence spans Telegram, TikTok, YouTube and X, where the group shares announcements and screenshots of claimed downtime. Public evidence indicates links to other well-known collectives including NoName057(16), Killnet and Keymous+, which provide access to wider attack infrastructure. Most of the observed attacks run for minutes or hours before moving on to new targets. Traffic patterns suggest semi-automated workflows rather than manual control, and the group frequently combines HTTP floods with TCP SYN floods or other vectors to maximise disruption of availability. Although motivation may be political, the reliance on rental DDoS tooling highlights a broader shift in hacktivism. Organised alliances and readily available attack services enable rapid mobilisation and make it far easier to launch global campaigns with minimal effort. Security teams are encouraged to maintain layered DDoS defences and actively watch for unusual residential or proxy traffic patterns, which often signal the use of DDoS-as-a-Service platforms. --- ## **About FastNetMon** FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** FastNetMon Blog --- ### [FastNetMon partners with Gcore for automated DDoS scrubbing](https://fastnetmon.com/2025/10/15/fastnetmon-partners-with-gcore-for-automated-ddos-scrubbing/) **Published:** October 15, 2025 **Author:** FastNetMon **Content:** We’re excited to announce our [new integration with **Gcore**](https://gcore.com/gcore-fastnetmon-ddos-protection), enabling fully automated DDoS mitigation through real-time detection and instant redirection to Gcore’s scrubbing centres. With this integration, networks using **FastNetMon Advanced** can automatically detect and redirect DDoS traffic for scrubbing in under one second — with no manual operator intervention. ### **How it works** FastNetMon Advanced continuously analyses network traffic using NetFlow, sFlow, and IPFIX. When DDoS indicators are detected, FastNetMon automatically triggers a **BGP announcement** to redirect only the affected prefixes to Gcore’s scrubbing centre. Gcore filters out malicious traffic and returns clean traffic to your network over a secure GRE tunnel. Once the attack subsides, routing is automatically restored to normal. This integration combines FastNetMon’s real-time detection with Gcore’s advanced filtering infrastructure to deliver **sub-second, zero-touch DDoS protection**. The Gcore + FastNetMon integration supports **both IPv4 and IPv6 traffic**, ensuring comprehensive protection across all environments with the same response time and precision mitigation capabilities. ### **Benefits for your network** **Reduced latency and better performance** FastNetMon only redirects traffic under attack, keeping normal traffic on the shortest path to your infrastructure. This selective diversion avoids unnecessary detours through scrubbing centres, reducing latency and preserving performance for legitimate users. **Lower costs through on-demand mitigation** With FastNetMon, scrubbing only happens when it’s needed. By activating Gcore’s filtering automatically during active attacks, you eliminate the expense of always-on protection while maintaining the same level of security. **Precision detection and faster recovery** FastNetMon continuously analyses network traffic in real time to detect DDoS indicators within seconds. Only the affected prefixes are redirected, and routing is automatically restored once the threat subsides — ensuring fast response and minimal disruption. ### **About FastNetMon scrubbing centre integrations** All automation scripts used for this integration are **open-source and fully customisable**, available in the [official FastNetMon GitHub repository](https://github.com/FastNetMon/scrubbing_services_integration). This new integration joins our growing ecosystem of automated scrubbing partnerships, including **F5** and **Cloudflare Magic Transit**, allowing network operators to choose the provider that best fits their infrastructure. Learn more about scrubbing centre automation and other supported integrations in our[ documentation](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-and-ddos-scrubbing-centers-integration/). --- ### **About FastNetMon** FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats.For more information, visit[ fastnetmon.com](https://fastnetmon.com). **Categories:** Press & Newsroom **Tags:** integration, partnership --- ### [The DDoS Protection FAQ](https://fastnetmon.com/2023/01/09/ddos-protection-faq/) **Published:** January 9, 2023 **Author:** FastNetMon **Content:** Over the last decade, DDoS has become one of the most common forms of cyberattack. And that’s hardly surprising. From a bad actor’s perspective, DDoS attacks are fast, easy, low-cost… and potentially destructive enough to take targets offline for an extended period. Responding to the growth in attacks, most organisations now have at least some [DDoS protection](https://fastnetmon.com/ddos-detection-and-mitigation/ "DDoS protection") in place. However, there are still plenty of misconceptions about DDoS attacks and the systems needed to protect against them. In this article, we’ll answer eight common questions about DDoS protection. ### Answering 8 Common DDoS Protection Questions #### \#1: Can my firewall protect against DDoS attacks? A network firewall can help detect and protect against small scale and low traffic DDoS attacks, but these devices have little value against large scale attacks. There are several reasons for this: - Firewall devices are light on computational resources and memory, which quickly become overwhelmed by high-magnitude DDoS attacks. - Firewalls rely on a set of rules to detect malicious activity. These rules are easily circumvented, particularly by attacks that resemble legitimate traffic. - Not all assets are behind a firewall. For example, websites, web applications, and edge devices can’t be protected by an on-premise firewall. There are alternative forms of protection for these assets—e.g., Web Application Firewalls (WAF)—but these tools are also inappropriate for protecting against DDoS attacks. In some cases, software firewalls may decrease a network's resilience against DDoS attacks. Normally, routers and switches use high performance hardware network processors (ASICs) and can process a significant amount of malicious traffic without service degradation. Adding firewalls in front of these high performance traffic processors can create an artificial bottleneck, allowing a smaller scale DDoS attack to disrupt the network. ### \#2: How do we protect against reflection amplification DDoS attacks? Reflection and amplification are techniques used to trick legitimate Internet services into sending unwanted responses to a targeted asset. In a reflection attack, a bad actor spoofs their target’s IP address and sends requests for information to an Internet service. The service sends its responses to the target’s IP address. When this process is conducted at scale—for example, by an entire botnet—the result is a large volumetric DDoS attack. Amplification attacks take reflection to the next level by requesting large responses from the Internet service that must be split over several packets. This results in huge volumetric attacks that can also be difficult to detect, as the target must reassemble several packets of data per response to understand what it’s being sent. Reflection amplification attacks are naturally worrying to organisations, particularly since they have been used to conduct some of the [largest DDoS attacks](https://www.thesslstore.com/blog/largest-ddos-attack-in-history/) ever recorded. However, the countermeasures needed to protect against them are the same as with any other DDoS attack: 1. Fast and accurate DDoS detection 2. Layered attack mitigation systems There is no one-size-fits-all approach to mitigation systems—that decision needs to be made based on your organisation’s budget, network topology, and risk tolerance. Some of the most common and effective DDoS mitigation approaches include [BGP blackhole](https://fastnetmon.com/bgp-blackhole-automation/), [BGP FlowSpec](https://fastnetmon.com/flowspec-ddos-mitigation/), [blacklist filtering](https://fastnetmon.com/blocklist-filtering/), and [DDoS scrubbing centres](https://fastnetmon.com/ddos-scrubbing-centre-diversion/). However, whatever approach you decide to adopt, you must also ensure you have detection capabilities to quickly uncover malicious activity and apply the appropriate mitigation rules, e.g., diverting traffic through a DDoS scrubbing centre. ### \#3: Are cloud-based DDoS protection solutions more effective? A common argument used by cloud-based providers is that today’s large-scale DDoS attacks overwhelm local network resources before they can be detected. So, instead of local detections, these providers suggest routing traffic through a cloud DDoS protection service that filters out malicious traffic before it hits your network. It is true that cloud services are a valuable layer in protecting against large DDoS attacks. However, not all traffic must be routed through these services all the time—this creates latency and increases costs. Instead, a powerful DDoS detection technology can identify malicious activity in seconds and route all traffic through (for example) a cloud-based scrubbing service for the duration of the attack. DDoS Scrubbing may be an appropriate option for content providers and web hosts, as they have predominantly outgoing traffic which can be sent directly without proxying it to the scrubbing centre. However, for ISPs which have a high volume of incoming traffic, DDoS scrubbing results in much higher costs, degrades latency, and exposes more traffic to the risk of false positive attacks. There are many ways for clean traffic to be delivered from a scrubbing centre, but most require Internet connectivity. This provides an additional link in the chain that could also be disrupted by attackers. To prevent this, organisations must have mitigation and detection in place to keep this link operational. ### \#4: Does digital transformation make us more vulnerable to DDoS attacks? Yes. Digital transformation initiatives typically result in a huge increase in an organisation’s attack surface. The larger your attack surface grows, the more targets a bad actor has for DDoS attacks. DDoS protection also becomes more challenging as your attack surface grows, requiring more sophisticated network monitoring and anomaly detection. For more information on building DDoS mitigation into your organisation’s digital transformation strategy, check out this article: [Why DDoS Mitigation Should Be Built Into Your Digital Transformation Strategy](/2023/01/09/why-you-need-ddos-mitigation/ "Why DDoS Mitigation Should Be Built Into Your Digital Transformation Strategy"). ### \#5: Can our ISP protect us against DDoS attacks? Many Internet Service Providers (ISPs) offer basic services to help protect customers from DDoS attacks. This makes a lot of sense, as ISPs serve as Internet gateways and—where possible—this allows them to prevent DDoS threats closer to their source. However, ISPs do not provide the level of DDoS detection and mitigation required to protect an organisation’s business and digital operations. This is for two reasons: 1. ISPs can’t risk blocking legitimate traffic, so they must be certain a connection is malicious before blocking it. This means plenty of malicious traffic passes through unfiltered. 2. Modern DDoS attacks are often highly sophisticated and change techniques regularly to avoid detection. Employing fine-grained detection across an ISP's entire traffic profile to identify these attacks is simply not feasible. So, while it certainly doesn’t hurt to have an ISP that provides some DDoS mitigation capabilities, you shouldn’t rely on them to protect your organisation. Most networks using the BGP protocol are connected to the Internet via more than one upstream provider for redundancy and to at least a handful of IXP (Internet Exchange Points) to reduce connectivity costs. If one ISP offers DDoS protection but others don’t, you can use a network automation solution to reroute traffic away from IXPs and remaining upstream sources to this ISP. ### \#6: Can our CDN provider protect us against DDoS attacks? To a point, yes. CDN providers have everything required to deliver your web assets to a group of servers around the world. This allows website visitors to benefit from faster loading times, as they can communicate with a server close to them instead of one thousands of miles away. As well as improving customer experience, this approach allows the provider to distribute bandwidth automatically to prevent strain on any individual server or data centre. If your website is the target of a DDoS attack, your CDN will automatically distribute incoming connections across a large number of servers, often distributed across multiple data centres and locations. For small-scale attacks, this may be enough to prevent (or at least minimise) outages. Global CDN providers such as [Fastly](https://www.fastly.com/) offer DDoS protection as part of their CDN product line. For website attacks, it may be sensible to protect your web assets by using services like these that are built with DDoS threats in mind. However, many DDoS attacks today are far too large to be prevented purely by a CDN provider. Instead, these attacks would simply overwhelm all servers within the group (and even entire data centres), completely denying legitimate users access to your web assets. This highlights the importance of choosing a CDN provider that has itself invested in robust DDoS protection to ensure its infrastructure isn’t compromised by high volume attacks. ### \#7: What is the difference between DoS and DDoS? DoS stands for Denial of Service, a category of cyberattacks that includes a wide range of techniques—including DDoS or *distributed* DoS. A DDoS attack is simply a DoS attack that originates from multiple sources spread across different locations. Typically, this is achieved using a botnet. When most people hear “denial of service,” they immediately think of DDoS attacks. There’s a good reason for this. Volumetric DDoS attacks are easily the most common form of DoS and typically the most destructive *and* hardest to recover from. However, non-distributed DoS attacks can still be damaging, and you should have defences in place to protect against them. Broadly, network DoS attacks fall into three categories: **Volumetric attacks**, including UDP floods, ICMP floods, and other spoofed-packet floods. These attacks aim to exhaust the available bandwidth of an attacked asset (usually a website). Attacks are measured in bits per second (Bps). **Protocol attacks**, including SYN floods, fragmented packet attacks, and Ping of Death. These attacks consume the resources of servers and network equipment. Attacks are measured in packets per second (pps). **Application layer attacks**, including low-and-slow attacks, GET/POST floods, and slow loris attacks. These attacks aim to crash targeted web servers by overloading a web application with seemingly legitimate requests. Attacks are measured in requests per second (rps). Note that any DoS attack can be delivered from a single attacking device *or* (to increase attack magnitude) by a distributed group of devices. In practice, most non-application layer attacks are delivered as DDoS attacks, as modern networks and cloud environments can usually absorb non-distributed attacks even without specialised DDoS protections. ### \#8 What are the most important DDoS countermeasures? The #1 most important countermeasure for DDoS attacks is fast, accurate detection. While there are many different mitigation tools and strategies, they all rely on detecting attacks quickly and applying the appropriate mitigations. At FastNetMon, we provide one of the fastest DDoS detection tools in the market, capable of uncovering even complex multi-vector attacks in seconds. FastNetMon integrates seamlessly with all your network hardware, mitigation capabilities, cloud analytics, and more. It also allows you to write your own custom detections and instantly deploy them across your entire network. Want to keep your network safe? [Try FastNetMon FREE for one month](https://fastnetmon.com/trial/). **Categories:** FastNetMon Blog **Tags:** 2023 --- ### [Why DDoS Mitigation Should Be Built Into Your Digital Transformation Strategy](https://fastnetmon.com/2023/01/09/why-you-need-ddos-mitigation/) **Published:** January 9, 2023 **Author:** FastNetMon **Content:** Internet-connected devices, services, and applications are now abundant in every industry. Even traditional industries are going through rapid digital transformation programs, using technology to create or modify business processes, culture, and customer experiences. While many organisations are deep into digital transformation initiatives, others are only just beginning. No matter where your organisation falls on that spectrum, it’s important to understand that your transformation doesn’t just increase business opportunities… it also increases *risk*. ### Digital Transformation and the Growing Attack Surface Any device or software asset accessible via the Internet is part of your attack surface. The more Internet-connected software and hardware assets you have, the larger your attack surface. [NIST 800-53](https://doi.org/10.6028/NIST.SP.800-53r5) defines attack surface as: *“The set of points on the boundary of a system, a system element, or an environment where an attacker can try to enter, cause an effect on, or extract data from.”* A larger attack surface means more potential points of entry for a bad actor and more things for your organisation to protect. So, as your attack surface grows, so does your cyber risk profile. Your risk profile also grows the more your organisation *relies* on Internet-connected assets as the impact of a cyber incident increases. In general, digital transformation initiatives lead to a huge expansion of an organisation’s attack surface—often much larger than they believe. ### Why Worry About DDoS Attacks? DDoS attacks are among the most common—and damaging—cyberattacks. For a bad actor, DDoS attacks are typically an easy and low-cost way to achieve their objectives. While there are many types of DDoS attacks, their motivation broadly falls into three categories: - Disruption and vandalism - Extortion (similar to [ransomware](https://www.checkpoint.com/cyber-hub/threat-prevention/ransomware/)) - Distraction while a more targeted attack occurs If your organisation isn’t high profile due to its size or function, you probably won’t experience many attacks intended purely to disrupt operations. However, if you rely on Internet-connected assets for any of your operations, you are *very* likely to experience DDoS-based extortion and distraction attacks. A [2022 survey](https://www.comparitech.com/blog/information-security/ddos-statistics-facts/) found that 70% of organisations experience between 20-50 DDoS attacks each month—and the number of confirmed DDoS attacks worldwide grows every year. The business consequences of DDoS attacks can include: - Downtime of key systems and applications - Disruption of internal and partner operations - Consumption of IT time and resources - Emergency recovery costs Naturally, the financial impact of attacks attracts most of the attention. [Research shows](https://www.msspalert.com/cybersecurity-research/kaspersky-lab-study-average-cost-of-enterprise-ddos-attack-totals-2m/) that SMBs spend $120,000 on average to recover from a DDoS attack, while enterprises can expect costs of over $2 million. Across all industries and organisation sizes, the [average cost](https://www.infosecurity-magazine.com/opinions/the-true-cost-of-ddos-attacks/#) of recovering from a DDoS attack is $218,000 *before* considering any ransom demands. Costs could, of course, be much higher. An e-commerce enterprise could face enormous losses from downtime, particularly during peak business times. This makes them highly susceptible to extortion attempts, so these organisations typically have extremely robust DDoS mitigation controls. ### Recovery Isn’t a Sustainable Strategy Organisations that rely on digital assets for critical operations can’t afford to go through cycles of attacks and recovery. The cost of disrupted operations can be huge—just an hour of downtime for a high priority application is [estimated to cost $67,651](https://www.veeam.com/news/cxo-research-legacy-technology-and-lack-of-skills-hindering-digital-transformation-and-it-modernization.html). And while [most attacks last less than four hours](https://securelist.com/ddos-report-q3-2022/107860/), some last much longer—days or even weeks. Without mitigation, even minor DDoS attacks can impact service availability. This creates direct costs due to lost sales or productivity and many indirect costs associated with service recovery. Given that DDoS attacks are almost inevitable in the medium to long term, a pure recovery strategy simply doesn’t make sense. Instead, organisations should build DDoS mitigation into their digital transformation strategy. ### Building DDoS Mitigation Into Your Digital Transformation Strategy How can you protect your expanding attack surface? Fundamentally, it comes down to four steps. #### **1. Understand your attack surface** This is hardly a new idea—the globally recognised [ITIL](https://www.axelos.com/certifications/itil-service-management/what-is-itil) framework has recommended thorough cataloguing of digital assets since the 1980s. However, in a rapidly changing digital environment, it’s far from straightforward. Traditionally, organisations relied on a combination of scanners (particularly vulnerability scanners) and human processes to track digital assets. However, historically this process has been incomplete for many organisations, leaving them unaware of many assets—and consequently, unable to protect them. The huge increase in attack surface size for modern organisations has led to new categories of tools and services to support this process, including [Attack Surface Management (ASM) tools](https://www.crowdstrike.com/cybersecurity-101/attack-surface-management/). Regardless of how you do it, building a complete, real-time picture of your attack surface is essential. #### **2. Understand and monitor network activity** The larger your attack surface grows, the more challenging it is to monitor. However, comprehensive monitoring, logging, and log analysis are essential to understanding what normal traffic looks like in your environment. Without this, there is no easy way to detect anomalies such as those observed during DDoS or other cyberattacks. This is known as network visibility—being aware of all components within your network and how traffic flows between them. To enable effective network traffic management, your organisation should combine real-time network visibility with comprehensive logs that enable historical point-in-time visibility. #### **3. Real-time detection** Speed of detection is key to preventing DDoS attacks. Every second that passes before you take action to mitigate an attack results in higher costs, disrupted operations, missed KPIs, and potentially lost sales. Ideally, your organisation should implement a detection technology that processes network traffic information and detects attacks in real time. Since DDoS techniques evolve very quickly, it should be able to detect a wide range of attack types, including: - Flood attacks via UDP, TCP, ICMP - IP Protocol attacks via fragmented packets - TCP Protocol attacks via SYN, SYN-ACK, and FIN floods - Amplification attacks via NTP, SNMP, SSDP, DNS, GRE, chargen, and more - Multi-vector attacks using a combination of techniques #### **4. Use a layered approach to mitigation** Many organisations rely on their ISP or CDN provider to protect against DDoS attacks. While these companies often provide basic detection and prevention, they are not enough. DDoS mitigation requires a layered approach to match your organisation’s needs, network architecture, risk tolerance, and budget. Some common controls include: - **BGP Blackhole** mitigates DDoS attacks by redirecting traffic for hosts under attack to a null0 interface. This effectively blocks all traffic (including malicious) from or towards hosts under attack, preventing attacks from overloading upstream ISPs and network equipment. The purpose of a BGP Blackhole is not to save a particular service or host but to protect the wider network and avoid large scale network outages. It can be considered as an emergency countermeasure when all softer mitigation approaches have failed. - **FlowSpec DDoS mitigation** blocks only malicious traffic while ensuring legitimate traffic remains unaffected. This mitigation method requires the use of BGP Flowspec capable routers. Increasingly, ISPs are offering BGP FlowSpec filtering, allowing customers to rely on the very large network capacity available to upstream ISPs to filter out malicious traffic. This largely eliminates the need for DDoS scrubbing centres and significantly reduces mitigation costs. - **DDoS scrubbing centres** reduce the impact of attacks by routing traffic through a cloud-based service to eliminate malicious traffic while allowing legitimate requests to pass through to your network. While effective, these services can create latency and become expensive if they are used as an “always on” security control. - **Blacklist-based filtering** blocks traffic that originates from known malicious IP addresses. ### The Best of Breed Strategy Many DDoS protection providers are vertically integrated services that combine some or all of the controls described above. In principle, that’s a good thing. However, these providers typically can’t provide the best available service in each control category—and they also lock customers into their ecosystem, often making it impossible to integrate with other detection and mitigation solutions. At FastNetMon, we believe in a best-of-breed DDoS mitigation strategy. That means giving network administrators the power to design, configure, monitor, and manage their network operations (including DDoS mitigation) to suit their organisation’s needs, budget, and topology.Ours is among the fastest [DDoS detection tools](https://fastnetmon.com/ddos-detection-and-mitigation/) in the market and can uncover even complex multi-vector attacks in seconds. Integrating seamlessly with all network hardware, mitigation controls, cloud analytics, and more, FastNetMon adapts to *your* network—putting the power back in your hands. If you like, you can even write custom detections and deploy them through the solution. Want to keep your network safe? [Try FastNetMon FREE for one month](https://fastnetmon.com/trial/). **Categories:** FastNetMon Blog **Tags:** 2023 --- ### [Your Anti-DDoS Strategy: Three Ways to Prevent Attacks](https://fastnetmon.com/2023/02/01/anti-ddos-strategy-three-ways-to-prevent-attacks/) **Published:** February 1, 2023 **Author:** FastNetMon **Content:** Anti-DDoS systems have become a crucial part of any cybersecurity strategy. According to the [2022 Data Breach Investigations Report](https://www.verizon.com/business/resources/reports/dbir/), DDoS attacks account for 40% of all security incidents. Attacks are used for a variety of malicious purposes, including: - Covering up more targeted cyberattacks. - Extorting target organisations with ransom demands in exchange for stopping an attack. - Disruption and cyber vandalism for ideological, personal, or political reasons. DDoS attacks target every industry. While most organisations experience 10 or fewer attacks each year—most of which last less than four hours—some organisations experience *more than a thousand attacks* yearly. Typically, these are organisations that stand to lose the most from disruption, e.g., ecommerce and financial services institutions. Having an anti-DDoS strategy is crucial regardless of which camp your organisation falls into. This article will look at three ways you can mitigate DDoS attacks. ### Detection: The Key to Your Anti-DDoS Strategy The first component of any anti-DDoS strategy is rapid detection. Even brief exposure to a large volumetric attack can have serious consequences, particularly for organisations that rely on Internet-connected systems for their business model. Today, many DDoS attacks use sophisticated techniques to avoid detection, including cycling vectors throughout an attack to evade protective systems. To combat this, rapid and [reliable DDoS detection ](https://fastnetmon.com/ddos-detection-and-mitigation/)is essential. The detection system your organisation uses should be able to identify a broad range of attack types, including: - UDP, TCP, and ICMP flooding attacks. - TCP protocol attacks such as SYN, SYN-ACK, and FIN floods. - IP Protocol attacks that use fragmented packets. - Reflection and amplification attacks through NTP, SNMP, SSDP, DNS, GRE, Chargen, etc. - Multi-vector attacks that employ a combination of techniques to evade mitigations. Ideally, your organisation should have a system that can [detect attacks within seconds](https://fastnetmon.com/2023/02/01/indian-isp-protects-against-ddos-with-fastnetmon/ "detect attacks within seconds") and apply the appropriate mitigation measures. ### \#1: Blackhole Automation A BGP BlackHole is an affordable anti-DDoS routing technique that can effectively mitigate large volumetric attacks. When an attack is detected, an organisation can use the Border Gateway Protocol (BGP) to broadcast rules to all routers within their network to begin routing traffic to attacked IP addresses to a null0 interface—a virtual interface that doesn’t forward or receive network traffic. This results in the traffic being dropped from the network without sending a response to the sender. These rules can also be pushed to upstream service providers via BGP, helping to disrupt attacks closer to their source. This typically requires obtaining a blackholing service from your ISP—sometimes for a cost, but often free of change—and has the significant advantage of blocking traffic *before* it reaches your network. While undoubtedly effective, blackholing routes *all* traffic to affected IPs to a null0 interface. As a result, while a blackhole is in place, it’s likely that legitimate traffic will also be dropped, affecting the user and customer experience. However, since only traffic sent to targeted IPs is dropped, there is usually only a partial degradation of service during an attack. Once an attack has ended, blackhole rule removal instructions can be broadcast to all routers and upstream providers via BGP. This can be done manually by a network engineer or automatically by a powerful DDoS detection solution. ### \#2: FlowSpec Mitigation Another BGP-based protection, FlowSpec is an effective technique that filters out volumetric DDoS attacks at the routing stage based on predefined rules. FlowSpec rules allow network engineers to specify mitigation actions when traffic flows match defined criteria, e.g., due to their source, destination, L4 parameters, and packet data. Common actions can include dropping traffic, redirecting traffic to a VRF (Virtual Route Forwarding) for further analysis, and limiting traffic to a defined rate. A network engineer can create rules to filter traffic manually or use a powerful DDoS detection solution to generate and maintain rules automatically. FlowSpec is ideal for filtering out most volumetric attacks, including TCP floods, DNS amplification and reflection attacks, GRE floods, and SSDP, SNMP, and Memcached amplification attacks. Unlike BGP BlackHole Mitigation, which blocks all traffic to attacked IPs, FlowSpec mitigation aims to catch *only* malicious traffic and stop it at the routing stage. Since these techniques are active at different stages of the DDoS attack chain, they can easily be used together for extra protection. For example, an organisation can use FlowSpec to capture and filter traffic until its network capacity is maxed out and then switch to BGP blackholing. ### \#3: Blocklist-Based Filtering Blocklist filtering is a routing-level anti-DDoS technique that blocks traffic originating from specified senders. This approach can be highly effective for mitigating DDoS activity from sources known to be malicious. It can also disrupt other threats, such as malware, e.g., by [blocking communications with external C2](https://www.microsoft.com/en-us/security/blog/2022/11/03/stopping-c2-communications-in-human-operated-ransomware-through-network-protection/) infrastructure. Blocklists—also known as blacklists or denylists—are produced in two primary ways: 1. Developed in-house based on known or previously encountered threats. 2. Purchased from external intelligence providers. Since maintaining a current blocklist is resource-intensive and requires a broad view of the DDoS landscape, most organisations prefer to purchase them from external providers in the form of threat feeds. However, this comes with its challenges. Typically, providers specialise in specific types of threat content, for example, hosts known to be associated with malicious activity, hosts with adult content, or hosts with pirated content. Different providers also deliver threat content in varying formats, making it difficult for an organisation to maintain a master blocklist (including removing defunct threats) that is up to date. To address this, organisations can use a filtering tool to ingest various threat feeds and update the master blocklist with new and defunct threats in real-time. While this approach will never be a complete solution to DDoS, it will help to mitigate known threats and lessen the need for more robust techniques such as Blackholing. ### Protect Your Organisation with FastNetMon FastNetMon fully supports all three anti-DDoS mitigations described above. At FastNetMon, we believe speed and accuracy of detection are essential to combat the threat of DDoS attacks. As one of the fastest DDoS detection tools on the market, our solution can uncover even complex multi-vector attacks in seconds and apply the appropriate mitigation strategies. To protect against the most advanced attacks, FastNetMon can be configured to automatically switch between mitigations throughout an attack to match changes in attack volume and vectors. Integrating seamlessly with all your network hardware, mitigation controls, and analytics, FastNetMon adapts to *your* network—you can even write custom detections and deploy them instantly across your network. Want to keep your network safe? [Try FastNetMon FREE for one month](https://fastnetmon.com/trial/). **Categories:** FastNetMon Blog **Tags:** 2023 --- ### [2022 Roundup: What Happened in the World of DDoS?](https://fastnetmon.com/2023/02/14/2022-roundup-ddos/) **Published:** February 14, 2023 **Author:** FastNetMon **Content:** It’s 2023. A new year. But before we start talking about the latest DDoS trends, news, and mitigation advice, it’s worth looking back over the events of the year past. In this article, we’ll look at some of the highest-profile attacks of 2022 and take a more in-depth view of DDoS attack trends and motivations. ### Significant DDoS Attacks of 2022 In September 2022, we saw the [largest DDoS attack ever detected in Europe](https://www.akamai.com/blog/security/record-breaking-ddos-attack-in-europe). Peaking at 704.8 Mpps, the attack was a long way shy of the largest attacks worldwide—but still more than enough to cripple any business network without thorough mitigation strategies. The attack, which used the UDP protocol, targeted over 1800 IPs spread across eight subnets and six physical locations. Significantly, the attackers’ command and control (C2) infrastructure enabled them to scale the distributed aspect of the attack from 100 to 1,813 IPs in just 60 seconds. Without advanced detection and automated remediation, protecting against this type of attack is impossible. Casting the net wider, the [Q3 attack against the Wynncraft Minecraft server](https://www.infosecurity-magazine.com/news/mirai-botnet-targeted-wynncraft) was among the largest DDoS attacks ever observed at 2.5 Tbps. The attack employed a variant of the well-known Mirai botnet to initiate a mixture of UDP and TCP floods, cycling vectors to evade defences. Meanwhile, pro-Russian hacktivist group [Killnet took responsibility for a series of DDoS attacks](https://securelist.com/ddos-report-q3-2022/107860/) against targets in Estonia and Lithuania. The attacks, which were the largest affected organisations had seen in over a decade, disrupted over 200 websites. Killnet also took responsibility for an attack that succeeded in [disrupting the US Congress website](https://www.cyberscoop.com/killnet-congress-ddos-russia-hacktivist/) for a short time, during which the group claimed it was “testing a new DDoS method.” Of course, no roundup of 2022 would be complete without recognising Google Cloud’s successful blocking of the [largest Layer 7 (application) DDoS attack](https://cloud.google.com/blog/products/identity-security/how-google-cloud-blocked-largest-layer-7-ddos-attack-at-46-million-rps) of all time—which peaked at a remarkable 46 million requests per second (rps). To put the scale of the attack in context, Google likened it to *“receiving all the daily requests to Wikipedia (one of the top 10 trafficked websites in the world) in just 10 seconds.”* ### A Broader View of DDoS While it’s always interesting to read about the largest DDoS attacks—and we all know they get most of the publicity—it’s not particularly helpful. To an average organisation, there’s no difference between a 2.5 Tbps attack and a 500 Mbps attack. Without effective (and automated) detection and mitigation, either attack (and possibly a much smaller one) will wreak havoc. So the question is, how big a problem is DDoS *really*? According to the Verizon [2022 Data Breach Investigations Report](https://www.verizon.com/business/resources/reports/dbir/) (DBIR), DDoS attacks account for roughly 40% of all cybersecurity incidents. That’s… a lot. While DDoS attacks are sometimes used to distract defenders during a targeted attack, the attacks themselves don’t compromise data. The more significant characteristic of DDoS attacks is the damage and disruption they cause—which can be just as costly as a data breach under the right circumstances. DDoS attacks target organisations in every industry… but not equally. The median DDoS attack lasts just a few hours, and most victims are hit with 10 or fewer attacks per year. Damaging, costly, and disruptive, certainly—but not always crippling. This begs an obvious question: If most organisations only face 10 DDoS attacks per year, how come DDoS accounts for **40%** of all cybersecurity incidents? Simple. A small proportion of organisations experience over 1,000 attacks each year. That's roughly three attacks per day, and for some organisations, the true number is much higher. This is partly why we believe so firmly in a custom strategy for DDoS mitigation that matches *your* organisation’s needs. Everybody needs fast, effective detection—but appropriate mitigation measures vary wildly depending on your organisation’s nature, attack profile, and network topology. [Research](https://blog.cloudflare.com/cloudflare-ddos-threat-report-2022-q3/) found that network-layer DDoS attacks rose by 97% in 2022 compared to the previous year. While there have been ups and downs in DDoS activity, the big picture is that the number of attacks worldwide has grown steadily over the last two decades. Since DDoS is still such a successful tactic for bad actors, don’t expect this to change any time soon. Of course, that doesn’t mean the DDoS space is devoid of change. While the broad tactics have been around for many years, the last decade has seen an array of new techniques designed to increase the effectiveness of attacks while making them more difficult to detect and mitigate. These include: - Increased use of malware-driven botnets to enslave Internet-connected devices and use them to conduct attacks of previously impossible volume. - Further use of reflection and amplification techniques—including many more sophisticated than long-used [NTP amplification](https://www.imperva.com/learn/ddos/ntp-amplification/) techniques. - Use of sophisticated C2 infrastructure that allows attackers to cycle attack techniques, targets, and vectors rapidly to evade detection and mitigation. ### Understanding DDoS Attackers Broadly, cyberattack motivations have been solved: it’s around 90% financially motivated, with the remaining 10% consisting of espionage, cyber warfare, and other state-sponsored activity. The thing is, DDoS completely bucks this trend. No doubt you’ve heard about DDoS extortion attacks, where criminal groups target an organisation with volumetric attacks and demand payment before they stop. These attacks are roughly equivalent to an organised crime protection racket and usually target organisations in ecommerce and finance that stand to suffer large financial losses from extended downtime. While these happen, they are *far* less common than you might expect. Aside from the obvious barriers to receiving payment, it’s easier, safer, and less costly for a financially motivated group to use ransomware than to extort using DDoS. No surprise, then, [research ](https://blog.cloudflare.com/cloudflare-ddos-threat-report-2022-q3/)finds extortion attacks account for just 9-19% of DDoS incidents over the last five quarters. So… why? Why go to all the effort of conducting a major (and criminal) cyberattack if not to make money? It can’t be espionage since a DDoS attack has no network intrusion component. There has to be another purpose. There are at least four other motivations for DDoS attacks: - **Ideological** — hacktivism, revenge, grudges, etc. - **Political** — cyber warfare, disruption, sabotage, etc. - **Competitive** — disruption or sabotage of a rival - **Obscuration** — distracting defenders from more subtle cyber activities - **Personal** — fun, intellectual challenge, “because they can” So, which is it? Unfortunately, unless a group announces its intention, it’s not always easy to understand the motivation behind an attack. Hacktivist groups like Killnet frequently do this, but rivals, hostile governments, advanced threat groups, and plain old-fashioned basement hackers are rarely so public about their motivations. Thankfully, we can draw a few conclusions about the most common motivations based on observable factors: - DDoS is the attack vector most accessible to individual hackers because the tools and infrastructure can be rented or purchased at minimal cost. As a result, a very high proportion of personal and grudge-based attacks use DDoS. - Obscuration attacks do happen, but they are rare and most likely to be the domain of high-level criminal and state-sponsored groups. - Due to their effectiveness at disrupting operations, many DDoS attacks fall into ideological and political categories. For example, most military action today is coupled with DDoS (and other cyber) activity, [spikes in patriotic ‘hacktivism’](https://www.techtarget.com/searchsecurity/news/252521150/Major-DDoS-attacks-increasing-after-invasion-of-Ukraine) can be seen on both sides of modern conflicts. ### Protect Your Organisation with FastNetMon At FastNetMon, we believe in a bespoke DDoS mitigation strategy that fits your organisation’s needs. Whether you’re a multinational that faces hundreds of attacks per day or an SME that needs to protect against a handful per month, our goal is to help you implement a protective strategy that matches your needs, network topology, and budget. Either way, effective DDoS mitigation starts with fast, accurate detection. As one of the fastest DDoS detection tools on the market, our solution can uncover even complex multi-vector attacks in seconds and apply the appropriate mitigation strategies. Integrating seamlessly with all your network hardware, mitigation controls, and analytics, FastNetMon adapts to *your* network—and can be configured to automatically apply and switch between mitigation strategies during an attack to match changes in attack volume and vectors. Want to keep your network safe? [Try FastNetMon FREE for one month](https://fastnetmon.com/trial/). **Categories:** FastNetMon Blog **Tags:** 2023 --- ### [Network Observability: A Key Component of Your Anti-DDoS Strategy](https://fastnetmon.com/2023/03/20/network-observability/) **Published:** March 20, 2023 **Author:** FastNetMon **Content:** Network observability is the first step in preventing any network-based cyberattack. Without the ability to observe the entire network, there is simply no way to detect and prevent malicious activity, such as DDoS attacks, before they cause damage and disruption. Put more simply: You can’t stop what you can’t see. ### What is Network Observability? Network observability involves monitoring the performance and behaviour of IT networks to help understand normal activity and identify and prevent issues before they become major disruptions. Strong network observability enables network administrators to proactively address issues such as malicious traffic before they cause outages or service degradation. It also provides insight into network performance so steps can be taken to improve its efficiency and reliability. By leveraging these insights, network administrators and security teams can set up automated alerts and preventative measures to protect the network from DDoS attacks and other malicious activity. ### How Does Network Observability Help with Anti-DDoS Strategies? Network observability helps network administrators detect anomalies in their networks that could indicate the early stages of a DDoS attack. When detected early, most DDoS attacks can be mitigated before they cause major damage or disruption to business-critical systems. Network monitoring tools like FastNetMon provide real-time network monitoring, enabling network administrators to react quickly when an attack occurs. Typically, this is done by implementing a [DDoS mitigation strategy](/2023/02/01/anti-ddos-strategy-three-ways-to-prevent-attacks/) such as BGP Blackhole or BGP FlowSpec. The faster an organisation can move from detection to mitigation, the less disruption it will experience. The more granular the data provided by a network monitoring tool, the more proactive network and security professionals can be when responding to suspicious or malicious network activity. In addition to mitigating DDoS attacks, network observability can help organisations learn past attacks. By conducting forensic analysis of network activity before and during confirmed attacks, an analyst can identify indicators that can be used to identify similar attacks in the future more quickly. Ideally, these indicators should be used to automate alerts and defensive strategies. ### Three Steps to Effective Network Observability Organisations need a network monitoring tool that supports three key functions: **1) Network activity capture**. The ability to capture and store network data from a range of sources is a fundamental requirement for network observability. This is typically done using input methods such as [NetFlow, IPFIX, and sFlow traffic monitoring](/traffic-visibility/) to transmit activity data from network devices like switches and routers to a network monitoring tool. Modern IT networks produce vast quantities of network activity data, so it is important to have a sufficient storage solution. **2) Reporting and insights**. An effective network monitoring solution provides powerful reporting capabilities and dashboards to make it easy for network administrators to understand and query activity data once ingested. For example, it should be easy for an administrator to see the following: - Top network talkers - Autonomous system dropdowns - Bandwidth to specific local or remote hosts - Bandwidth to or from specific autonomous system numbers **3) Action**: The ultimate purpose of network observability is to inform action. While this typically requires input from network administrators and security teams, it’s important to choose a network monitoring tool that makes it easy to implement improvements and threat mitigation strategies. For example, it should be straightforward to automate DDoS mitigation strategies to activate when specific types of activity are detected. ### 5 Anti-DDoS Use Cases for Network Observability While there are many use cases, preventing DDoS attacks is undoubtedly among the most important. Here are five ways you can use it to more effectively identify, understand, and mitigate today’s sophisticated DDoS attacks. **1) Prompt attack detection**. Early detection and mitigation of a DDoS attack can make all the difference when safeguarding your infrastructure. Network monitoring tools can detect suspicious traffic patterns in real-time by comparing them to historical data. This enables network and security teams to act quickly to protect their networks from harm while avoiding costly disruptions. **2) Detecting low-volume attacks**. While huge volumetric flooding attacks make the best headlines, [many DDoS attacks](https://www.securitymagazine.com/articles/91308-small-ddos-attacks-on-the-rise-why-these-supersized-assaults-are-going-tiny) are short-term assaults with limited volumes. These attacks can be harder to detect as they are too small to trigger common volume-based mitigations. However, smaller DDoS attacks can still cause damage. For example, they can: - Overload a network device’s CPU - Disrupt load balancers - Fill up firewall state tables Often, these attacks aim to create weaknesses in a target network that can be exploited to conduct more targeted and profitable cyber attacks—for example, data theft or ransomware installation. A powerful network monitoring tool helps security and network teams understand different types of malicious activity and set alerts and thresholds to monitor for even the stealthiest DDoS attacks. **3) Traffic analysis**. Knowing where your network traffic comes from is essential to maintaining a robust security defence. With the help of a network monitoring tool, organisations can collect and study context-specific information such as geolocation data. This enables the development of policies to alert against any suspicious activity in embargoed countries or unusual sources, improving the accuracy of early detections and mitigating threats promptly. **4) Monitoring network flow**. To mitigate attacks, network and security teams need the full context of network activity. This requires going beyond basic SNMP data. Flow monitoring provides a deeper level of insight by providing details such as where an attack originated and what IP addresses, ports, and protocols were used. Network and security teams can use this additional information to implement more effective, granular filters to prevent future attacks. **5) Setting and refining mitigation policies**. Over time, network administrators can identify patterns in malicious traffic that can be used to set and improve mitigation policies. This requires two capabilities: 1. Thorough network observability. 2. A DDoS detection solution that supports custom rulesets. As malicious actors become more sophisticated, the patterns of DDoS attacks are becoming harder to recognise. Network observability provides a way to look back at past incidents to review any trends or similarities that could signal an incoming attack. These insights can inform automated detection and mitigation strategies, ensuring the fastest possible resolution of future DDoS attacks. ### Protect Your Organisation with FastNetMon FastNetMon combines DDoS detection and mitigation features with powerful network flow monitoring capabilities. Utilising input methods such as NetFlow, IPFIX, and sFlow traffic monitoring, FastNetMon can help your organisation detect even the most sophisticated DDoS attacks. FastNetMon captures network activity in real-time and allows network and security teams to set granular, dynamic policies for detection and mitigation. To protect against the most advanced attacks, FastNetMon can be configured to automatically switch between mitigations throughout an attack to match changes in attack volume and vectors. Integrating seamlessly with all your network hardware, mitigation controls, and analytics, FastNetMon adapts to *your* network—you can even write custom detections and deploy them instantly across your network. Want to keep your network safe? [Try FastNetMon FREE for one month](https://fastnetmon.com/trial/). **Categories:** FastNetMon Blog **Tags:** 2023 --- ### [Why is Network Traffic Visibility Important?](https://fastnetmon.com/2023/03/20/why-is-network-traffic-visibility-important/) **Published:** March 20, 2023 **Author:** FastNetMon **Content:** Network security is a critical function for any business today—and it started with network traffic visibility. To protect against increasingly sophisticated cyberattacks, organisations must be able to detect and prevent malicious activity on their networks. However, this is only possible if an organisation has visibility across its entire IT environment—including the network. After all, you can’t protect what you can’t see. Network traffic visibility gives organisations the insight and oversight they need to identify threats before they cause serious damage or disruption. This article will discuss why visibility is so important and how it can help protect an organisation’s data and infrastructure. ### What is Network Traffic Visibility Network traffic visibility is the ability to monitor, analyse, and act on network traffic in real time. By providing a detailed picture of incoming and outgoing traffic, a network monitoring tool can help network and security teams identify threats quickly and give administrators the insights they need to manage networks more efficiently. Network visibility also helps administrators detect suspicious patterns of behaviour that could indicate malicious actors attempting to gain access or disrupt services. With deep packet inspection, organisations can view the header, payload, and other metadata associated with every data packet, enabling malicious activity to be identified and blocked before serious harm is done. Organisations need a network monitoring tool that provides various capabilities to support prompt threat detection and mitigation. These include: - Capturing data from multiple sources, including traffic telemetry protocols such as NetFlow, IPFIX, and sFlow. - Integration with all common network hardware, e.g., switches, routers, etc. - Enough storage for current and historical data—often running to terabytes and even petabytes. - Comprehensive reporting and querying capabilities. - Automation and custom rule settings to support efficient threat detection and mitigation. ### 5 Cybersecurity Use Cases for Network Traffic Visibility #### 1) Faster threat detection Network visibility enables organisations to swiftly detect and prevent malicious activity. For example, real-time analysis of network activity can enable security teams to detect and prevent unauthorised data exfiltration—potentially saving the organisation from a costly data breach. Similarly, threats targeting smart technologies such Internet of Things (IoT), Operational Technology (OT), and medical devices can often *only* be detected by analysing network traffic. These devices often run on outdated or uncommon operating systems and can’t be protected using common cybersecurity practices such as installing endpoint security agents on each device. To spot malicious activity, organisations can use a network monitoring tool to detect anomalous or suspicious network traffic flowing to or from these devices. #### 2) Shedding light on blind spots Modern business networks are growing larger and more complicated by the year. The more complex a network is, the harder it becomes to maintain full visibility. [Digital transformation](/2023/01/09/why-you-need-ddos-mitigation/) initiatives, hybrid cloud infrastructure, and increasingly remote workforces have made network monitoring a tougher task than ever before—and this creates risk. A strong network traffic visibility program—powered by a powerful network monitoring tool—addresses this problem, shedding light on blind spots and helping network and security teams uncover anomalous or suspicious activity no matter where it occurs. #### 3) Compliance with cybersecurity frameworks Industry frameworks such as the [National Cyber Security Centre CAF Guidance](https://www.ncsc.gov.uk/collection/caf) highlight network monitoring and visibility as essential components of any cybersecurity strategy. The [National Institute of Standards and Technology (NIST)](https://www.nist.gov/) offers similar recommendations in its report, [Security and Privacy Controls for Information Systems and Organizations](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf). NIST recommends the use of networking monitoring to detect: 1. Cyber threats and indicators of attack 2. Unauthorised local, network, and remote connections Often, network activity—as opposed to device activity—provides the earliest warning signs a security team can investigate to uncover potentially malicious activity. #### 4) Optimising network performance Complex business networks aren’t just hard to monitor—they’re also hard to optimise. As complexity rises, configuration issues can easily lead to a drop in performance, reducing operational efficiency and potentially harming customer experience. Full network traffic visibility—along with powerful data analysis and reporting capabilities—supports network teams to uncover misconfigurations, bottlenecks, inactive hosts, and other network issues. By promptly addressing these problems as they arise, organisations can maintain higher network performance and avoid costly slowdowns and downtime. #### 5) DDoS Protection Network traffic visibility helps security and network teams identify and mitigate DDoS attacks before they can disrupt business or customer activities. For example, large and unexplained spikes in traffic to specific network IPs are a common sign that a volumetric DDoS attack may be underway. By quickly recognising these spikes, organisations can take preemptive action or respond swiftly to mitigate the attack and prevent it from disrupting critical operations. Of course, not all DDoS attacks are so obvious. It’s important to invest in a network monitoring tool capable of ingesting the full spectrum of network data and which supports custom-written detection and mitigation rules designed to protect against more sophisticated attacks. For complex DDoS threats, administrators can view the header and payload of every packet of data travelling through their network and determine if there is any suspicious or malicious activity. This process is most commonly used in the aftermath of an attack, and insights obtained can inform new automated detection and mitigation rules to prevent similar attacks in the future. ### Protect Your Organisation with FastNetMon FastNetMon isn’t just a DDoS detection solution—it also provides real-time and historical network traffic visibility. Integrating seamlessly with all common network hardware, it gathers network activity data from various sources, including NetFlow, IPFIX, and sFlow traffic monitoring. Combining state-of-the-art DDoS detection and mitigation with real-time network monitoring, FastNetMon supports security and network teams to uncover the most sophisticated cyber threats. At FastNetMon, we believe speed and accuracy of detection are essential to combat the threat of DDoS attacks. As one of the fastest DDoS detection tools on the market, our solution can uncover even complex multi-vector attacks in seconds and apply the appropriate mitigation strategies. To protect against the most advanced attacks, FastNetMon can be configured to automatically switch between mitigations throughout an attack to match changes in attack volume and vectors. Integrating seamlessly with all your network hardware, mitigation controls, and analytics, FastNetMon adapts to *your* network—you can even write custom detections and deploy them instantly across your network. Want to keep your network safe? [Try FastNetMon FREE for one month](https://fastnetmon.com/trial/). **Categories:** FastNetMon Blog **Tags:** 2023 --- ### [How To Choose the Right Network Monitoring Tool](https://fastnetmon.com/2023/04/06/how-to-choose-the-right-network-monitoring-tool/) **Published:** April 6, 2023 **Author:** FastNetMon **Content:** Recently, we wrote about how network visibility can help organisations detect cyber threats, illuminate network blind spots, optimise network performance, and more. Today, we’re taking a step back and asking a more fundamental question… How do you *get* visibility? The answer is simple: use a powerful network monitoring tool that provides the functionality you need to monitor, manage, and protect your business network. This article will explain why it’s important to choose the right monitoring tool and what to consider when choosing the best tool for your organisation. ### Why is a Network Monitoring Tool Important? A network monitoring tool enables organisations to monitor and analyse network traffic and take action to resolve issues and protect against cyber threats. Monitoring tools provide a detailed, real-time picture of incoming and outgoing traffic, enabling network teams to identify potential issues and ensure networks run efficiently. Common issues that tools can help network teams address include network misconfigurations, bottlenecks, and inactive hosts. Monitoring tools are also crucial for detecting security threats such as DDoS attacks and the presence of malicious actors inside a network. ### 6 Things to Consider when Choosing a Network Monitoring Tool #### 1. Ease of implementation Being able to get up and running quickly with a new network monitoring tool is a huge advantage. Free tools, in particular, often require a significant investment of time, energy, and resources to implement and set up correctly. This is partly because each tool typically provides a small range of functionality, so network teams must simultaneously implement several tools to fulfil their full requirements. Even within paid tools, there are significant variations in the level of effort and cost required for implementation. When evaluating tools, consider the time and cost of implementing each tool, including: - Provisioning servers and storage. - Deploying agents. - Creating databases. - Implementing backup procedures and infrastructure. - Implementation and maintenance of supporting tools (if needed). - Learning and managing the full network monitoring stack. #### 2. Features When it comes to features, there are significant differences between tools. At one end of the scale, there are some relatively inexpensive—even free—offerings that complete basic network monitoring tasks. While these tools may be sufficient for very small organisations, they don’t provide the functionality needed to detect and address serious network issues and security threats. At the other end of the spectrum, you’ll find fully functional solutions that provide granular insight into all network activity, along with strong integrations, remediation capabilities, and more. Serious network teams should look for a tool that provides: - Data capture from multiple sources, including NetFlow, IPFIX, sFlow traffic monitoring, Port mirror, and SPAN. - Integration with all common network hardware, e.g., switches, routers, etc. - Storage for current and historical data—often running to terabytes and even petabytes. - Comprehensive reporting and querying capabilities. - Automation and custom rule settings to support efficient threat detection and mitigation. #### 3. Reporting It’s one thing to observe network activity in real time. However, in practice, many network issues and security threats are uncovered in retrospect by analysing network traffic reports. A network monitoring tool should include powerful reporting capabilities and dashboards that enable network administrators to understand and query network activity data. At a minimum, it should be easy for administrators to view: - Top host talkers in network. - Autonomous system dropdowns. - Bandwidth to specific local host, network or group of hosts. - Bandwidth to or from specific autonomous system numbers. #### 4. Scalability Some business networks will always stay within certain confines. In these cases, scalability may not be a big concern. However, for organisations that aim to grow, it’s important to choose IT solutions and infrastructure that can scale as necessary. For example, FastNetMon has been tested on networks up to 5 Tbits and 3 million unique flows per second for a single server. It can also be scaled linearly by adding any number of clustered servers. #### 5. Integration While [network observability](/2023/03/20/network-observability/ "network observability") is crucial, it’s not the only function of a network monitoring tool. A powerful tool must also enable network and security teams to *take action* to resolve issues and prevent threats. For this to be possible, the tool *must* integrate with a wide range of network devices, software tools, and internal and external services. Some of the most important integrations include: - All network devices, including routers, and switches. - Cyberattack mitigation services such as BGP Blackhole and cloud DDoS scrubbing centres. - Observability and analytics tools such as Grafana. - Security monitoring and log management tools such as SIEMs. #### 6. DDoS Protection Among the most important functions of a network monitoring tool is detecting anomalies that could indicate the early stages of a DDoS attack. Most DDoS attacks can be mitigated if they are detected early, enabling organisations to avoid major damage or disruption to sensitive systems or assets. Powerful monitoring tools combine real-time visibility of all network activity with rules-based attack detection, enabling network administrators to react quickly to attacks. With the addition of automation capabilities, many DDoS attacks can be detected and mitigated automatically using a [DDoS mitigation strategy](https://fastnetmon.com/2023/02/01/anti-ddos-strategy-three-ways-to-prevent-attacks/) such as BGP Blackhole or FlowSpec. Naturally, the faster you can detect and mitigate an attack, the less damage and disruption your organisation will experience. Of course, not all attacks can be detected automatically. This is why it’s important to choose a monitoring tool that provides granular activity data—it enables security teams to be more proactive in identifying and responding to suspicious or anomalous network activity. ### Protect Your Organisation with FastNetMon FastNetMon isn’t just a network monitoring tool—it’s also a state-of-the-art DDoS detection and mitigation solution that supports security and network teams to uncover even the most sophisticated cyber threats. At FastNetMon, we believe speed and accuracy of detection are essential to combat the threat of DDoS attacks. As one of the fastest DDoS detection tools on the market, our solution can uncover even complex multi-vector attacks in seconds and apply the appropriate mitigation strategies. To protect against the most advanced attacks, FastNetMon can be configured to automatically switch between mitigation strategies and approaches throughout an attack to match changes in attack volume and vectors. Integrating seamlessly with all your network hardware, mitigation controls, and analytics, FastNetMon adapts to *your* network—you can even write custom detection rules and deploy them instantly across your network. Want to keep your network safe? [Try FastNetMon FREE for one month](/trial/). **Categories:** FastNetMon Blog **Tags:** 2023 --- ### [IT Leaders Believe Visibility is Key to Network Security](https://fastnetmon.com/2023/04/06/it-leaders-believe-visibility-is-key-to-network-security/) **Published:** April 6, 2023 **Author:** FastNetMon **Content:** A recent survey found 81% of IT leaders believe network visibility is essential for strong network security and response. The [survey](https://info.infoblox.com/resources-whitepapers-independent-research-20-20-visibility-clarifies-network-security), conducted by Forrester on behalf of Infoblox, reached 423 IT leaders worldwide across a range of industries. According to respondents, improved security and response is the most significant benefit of network visibility, followed by network performance (76%) and operational efficiency (72%). We’ve written in the past about the broader benefits of strong [network traffic visibility](/2023/03/20/why-is-network-traffic-visibility-important/)—in this article, we’ll focus exclusively on security advantages. ### Why is Visibility so Important for Network Security? Network visibility enables network and security teams to monitor and analyse network traffic in real-time and take appropriate actions. Typically, organisations use a network monitoring tool—either open source or premium—to provide a detailed, real-time picture of incoming and outgoing traffic. These tools support a range of IT and security functions, from ensuring efficient network operations to promptly identifying security threats for remediation. On the surface, the role of visibility in network security seems obvious—you can’t secure what you can’t see. If you can’t observe precisely what is connected to a network and how traffic flows around it, your chance of detecting security weaknesses and threats is severely limited. The Forrester survey report notes: *“Poor network visibility impedes security response and capabilities. Without clear visibility, leaders struggle to know what is on their network, manage capacity, and identify tools at their disposal.”* There’s nothing groundbreaking or surprising here—most IT leaders are already aware that a lack of network visibility is holding them back. The report goes on to note that the vast majority (97%) of IT leaders have already invested in network visibility tools OR are planning to invest within the next three years—while 61% believe their organisation should invest more heavily in this area. The question we need to ask is *why* network visibility is so important. Simply observing network activity has value, but in isolation, it does very little to improve network security. To achieve the desired outcome, something more is needed. ### Network Visibility Informs Action As with any aspect of security, monitoring and detection are just one part of the equation. The other is fast, effective response. Whether your responses are automated or require human intervention, a prompt response using an appropriate mitigation strategy is essential to quickly control a threat. For example: - DDoS attacks that trigger detection rules in a network monitoring tool may be mitigated automatically. - DDoS attacks that evade detection rules may be identified by human analysts and require manual mitigation. In both cases, the [DDoS mitigation strategy](/2023/02/01/anti-ddos-strategy-three-ways-to-prevent-attacks/) may be the same (e.g., BGP blackholing or Flowspec), but the path to get there is either machine-led or human-led. This requires a combination of powerful tooling and best-practice human processes to ensure threats are identified and resolved quickly and appropriately every time. Unfortunately, this is where security and network teams often face a significant challenge. In many cases, the ability to take proactive action to reduce security risk is hindered by a lack of technology and process integration. ### Integration of Tools and Processes Supports Action It’s simply not possible for humans to monitor traffic in real-time—and with security incidents, time is of the essence. To detect security threats such as DDoS attacks or the presence of malicious actors inside a network, organisations need to take advantage of automated detection and response. However, automated detection and response are only possible if two things are in place: 1. A powerful network monitoring tool that supports rules-based detection and automation. 2. Broad integrations with network equipment, security tools, and mitigation strategies. Today, many organisations lack these two critical components of a strong network security program. According to the Forrester survey, the top challenges for network and security teams are: - Lack of automation (58%) - Siloed tools/technologies (54%) - Lack of skilled workers (50%) - Insufficient network visibility (47%) Three of the top four challenges relate to a lack of suitable technology infrastructure to support effective network security and management. Still, simply purchasing better tools is not the full solution. To fully leverage even the strongest tools, organisations *also* need to ensure network and security teams have processes and communication channels in place that allow them to cooperate on both routine and emergency duties. These needs are reflected in the results of the Forrester survey. IT leaders highlighted **integration** of tools and technologies, **cooperation** between network and security teams, and improved **culture** as the top changes required to improve collaboration and maximise network security benefits. As the report puts it: *“If organisational barriers segment and silo these teams, a holistically sound security approach is impossible. If done right, an integrated approach can foster benefits, including better performance and capacity planning, reduced costs, and device discovery. In short, with integration comes visibility.”* ### Protect Your Organisation with FastNetMon FastNetMon combines powerful network monitoring capabilities with the industry’s fastest and most reliable DDoS detection and mitigation capabilities. Supporting input methods such as NetFlow, IPFIX, port mirror, SPAN, and sFlow traffic monitoring, FastNetMon can help your organisation detect even the most sophisticated DDoS attacks. FastNetMon captures network activity in real time and allows network and security teams to set granular, dynamic policies for detection and mitigation. To protect against the most advanced attacks, FastNetMon can be configured to automatically switch between mitigation strategies throughout an attack to match changes in attack volume and vectors. Integrating seamlessly with all your network hardware, mitigation controls, and analytics, FastNetMon adapts to *your* network—you can even write custom detection rules and deploy them instantly across your network. Want to keep your network safe? [Try FastNetMon FREE for one month](https://fastnetmon.com/trial/). **Categories:** FastNetMon Blog **Tags:** 2023 --- ### [The Threat of DNS Amplification Attacks: Safeguarding Your Infrastructure](https://fastnetmon.com/2023/10/24/the-threat-of-dns-amplification-attacks-safeguarding-your-infrastructure/) **Published:** October 24, 2023 **Author:** FastNetMon **Content:** Denial of service attacks all have one goal in common – to use network traffic to overload a target system causing it to fail or become unresponsive. For the criminals behind these attacks, there is another consideration – how to achieve that goal at minimal cost to themselves. Which is where DNS amplification comes into play. ## What is a DNS amplification attack? DNS servers are an essential part of the internet, allowing us to route traffic to the correct server from anywhere in the world. And the usual query/response between systems and DNS servers is quick and lightweight. But it can also be weaponised. DNS relies on UDP transport to accelerate query/response times, so it does not perform any verifications on the packets received. For hackers this means that they can forge (‘spoof’) the originating address, ensuring the DNS response is directed to their victim’s server. Like any denial of service (DoS) attack method, generating enough traffic will overwhelm local resources, causing the server to crash. To increase the effectiveness of their attack, criminals ‘amplify’ traffic. A typical DNS request is just a few bytes – as is a typical response from the server. But by passing the ‘ANY’ argument in the request, hackers can increase the size of the response by as much as 150x because the packet now contains all of the associated details of the DNS address, not just the target IP address. Small amount of data in, large amount of data out. ## Give me an example Here’s a scenario that helps to visualise the DNS amplification attack. One of your closest competitors decides that the best way to poach customers is to prevent them from being able to contact your sales team. They have their sales team take it in turns to contact various Amazon warehouses, requesting an agent return their call to read their entire stock inventory (the DNS type ANY command). However, they ask Amazon to call back on your sales line phone number (spoofed return address). A series of Amazon agents then call your sales line and begin reading their product inventory which contains millions of items (amplifying the size of the request). Now all of your phone lines are tied up with junk calls, preventing ‘real’ customers from calling to place orders (the DoS). Too much traffic overwhelms your sales team and they are unable to function. And because you don’t know where the original request came from, you can’t tell who requested the calls from Amazon. Just like a DDoS attack, the outage could be extremely costly in terms of financial loss and damage to corporate reputation. ## How can I protect infrastructure against DNS amplification attacks? There are a few things you can do to mitigate this kind of DDoS attack: ### **Rate limiting** An obvious starting point is to implement rate limiting. If inbound traffic reaches a pre-defined threshold, you can reduce throughput to prevent resources being overloaded. Rate limiting can help buy time for your infrastructure team to identify and block an attack. ### **Server blocking** DNS amplification attacks use open DNS servers to do their dirty work. One way to reduce risk of attack is to block traffic from known open DNS servers. Just bear in mind that this may cause occasional problems with misconfigured devices that rely on those services. ### **Load balancing** Distributing incoming traffic between multiple DNS points of presence (PoP) can ensure that no single server is overloaded and that enough resources remain available to fulfil legitimate requests. ### **DDoS scrubbing** Cleaning inbound traffic before it arrives in your environment will help to prevent infrastructure overload. DDoS scrubbing providers use deep packet inspection (DPI) to assess each request, automatically diverting malicious traffic and preventing it affecting your network services. ### **Block internal spoofing** There is always a risk that your own DNS servers could be used as part of an amplification attack. Your infrastructure should be configured to automatically drop any internal traffic that appears to originate from an external address – it is almost certain such traffic has been spoofed and is malicious. ## The key to ultimate success – rapid detection All of these mitigation techniques will help you respond effectively to a DNS amplification attack – but first you need to know if such an attack is underway. Using a tool like FastNetMon to monitor network traffic is vital because it can automatically confirm an attack and implement the initial stages of your mitigation plan. And in the case of FastNetMon, it can respond to an attack in just two seconds – dramatically reducing the window of opportunity for cybercriminals to disrupt your operations. To learn more about detecting DNS amplification attacks and to see how FastNetMon could work for you, sign up for a [free one month trial](https://fastnetmon.com/trial/). **Categories:** FastNetMon Blog **Tags:** 2023 --- ### [Mitigating Application Layer DDoS Attacks: Best Practices for Online Businesses](https://fastnetmon.com/2023/10/24/mitigating-application-layer-ddos-attacks-best-practices-for-online-businesses/) **Published:** October 24, 2023 **Author:** FastNetMon **Content:** Application Layer DDoS attacks are an extremely popular, and effective, technique used by cybercriminals to disrupt web-based services. There are several variations of application layer attacks, so mitigating them can be a challenge. ## What are application layer DDoS attacks? Essentially, application layer DDoS attacks are designed to overload a web-based resource, such as a website, stopping it from functioning properly. Also known as a Layer 7 attack (after the application layer in the OSI networking model), the idea is to consume as many system resources as possible, preventing legitimate traffic from being served. For an online business, loss of web app functionality or availability could be disastrous. There are six ways that hackers can launch application layer DDoS attacks: ***1. Slowloris*** – A tool that allows a single computer to send partial requests, forcing the receiving web server to keep each connection open until the request is completed. Eventually, the number of open ports exceeds the maximum allocated to the application, causing the server to slow and/or crash. ***2. Slow post*** – Similar in aim to slowloris, the slow POST attack uses a botnet to send thousands of POST requests to a web server. The traffic appears completely legitimate, but each POST message is sent as slowly as possible, sometimes just one byte every two minutes. Again, the server dedicates resources to each request until it runs out of allocation, bringing the web application to a standstill. ***3. Slow read*** – The opposite of the slow post, this technique sees the botnet taking as long as possible to read responses *sent* by the web server. Each bot maintains an active connection to prevent timeout, eventually overwhelming resources, causing the server to crash. ***4. Low and slow*** – Slowloris is just one example of this form of attack. Again, easily accessible tools can crash a server with relatively small amounts of web traffic, simply by sending network packets very slowly to the target machine until allocated resources are exhausted. These attacks can be launched using HTTP or TCP protocols. ***5. Jumbo payload attacks*** – Hackers send a data structure encoded XML to the target webserver. The application then tries to decode the data structure by creating an in-memory SOAP message, consuming all available memory and causing the application to crash. ***6. HTTPs flooding/Mimicked user browsing*** – A distributed botnet sends thousands of simultaneous *legitimate looking* HTTP/HTTPs requests to a webserver, overloading its resources and causing it to crash. This attack looks very similar to a spike in normal web traffic. Some online businesses may experience similar crashes caused by genuine web users during periods of peak traffic like on Black Friday and Cyber Monday. ## Tips for mitigating Layer 7 DDoS attacks Here are some proven best practices for mitigating application layer DDoS attacks: #### ***Stay vigilant*** Many DDoS attacks are designed to go undetected to maximise damage and disruption. The more ‘normal’ the incoming traffic requests look, the less likely they are to trigger DDoS mitigation systems. By establishing a baseline of what ‘normal’ traffic looks like, your web application engineers will be better placed to identify a DDoS attack when it does happen. #### ***Use your logs*** Web server logs contain a goldmine of information about web traffic norms. If you suspect the early stages of a slow post/slow read attack, the server logs will help to confirm if one is underway. #### ***Employ a multi-layer approach to defence*** No single tool will protect completely against application layer attacks – so deploy several. DDoS detection and mitigation can be complemented by network perimeter firewalls, web application firewalls and advanced network routing and filtering rules. #### ***Invest in next-gen DDoS monitoring and mitigation*** Criminals will typically monitor the progress of their attack, tweaking configurations to avoid detection and mitigation techniques. A next generation detection tool like FastNetMon uses a range of techniques to proactively identify application layer DDoS attacks in just two seconds without having to rely on retroactively applied signatures and rules. Automating monitoring, detection and mitigation can stop an attack before server and application performance are affected. #### ***Keep up-to-date*** That’s not to say you should ignore signatures completely. If your DDoS prevention mechanisms include updates, you should test and apply them as quickly as possible. The more layers of defence you can implement, the better protected you will be against attack. Application layer DDoS attacks are particularly sneaky because they don’t always rely on vast volumes of traffic. As we have discussed, some attacks are extremely slow, using very small amounts of traffic to cause disproportionate levels of damage. As such, traditional DDoS mitigation tools and strategies may not be effective in the modern cybersecurity environment. To learn more about FastNetMon and how it will help your online business avoid application layer DDoS attacks and outages, sign up for a [free one-month trial](https://fastnetmon.com/trial/). **Categories:** FastNetMon Blog **Tags:** 2023 --- ### [The Rise of IoT Botnets: Protecting Your Network from Mirai Attacks](https://fastnetmon.com/2023/10/24/the-rise-of-iot-botnets-protecting-your-network-from-mirai-attacks/) **Published:** October 24, 2023 **Author:** FastNetMon **Content:** First used in 2016, the Mirai botnet is old news. Built by two university students, the IoT-powered botnet was initially used to extort money from games server hosts. A few months later Mirai was used to launch one of the largest DDoS attacks ever seen against internet DNS provider Dyn. Using malware infected IoT devices like CCTV cameras, the botnet was able to generate tens of millions of malicious requests, directed at Dyn’s DNS service. When the service eventually failed, several of the world’s most popular websites were taken offline for approximately two hours. ## Why does Mirai still matter? There are a few reasons why Mirai still matters, even now, nearly six years after the original attack. First, the Mirai botnet is still active, meaning that there are tens of thousands of infected devices out there, primed for use in another DDoS attack. The [Wynncraft Minecraft server attack](https://www.infosecurity-magazine.com/news/mirai-botnet-targeted-wynncraft) in Q3 2022 proves the danger of Mirai has not gone away. Second, the Mirai source code was leaked online, providing cybercriminals with a codebase on which to build and refine their own malware. Mirai code and techniques are believed to have inspired more recent botnet variants including the Okiru, the Satori, the Masuta and the PureMasuta. In many ways, Mirai has shown the future of DDoS attacks. Using a decentralized, self-propagating network of zombie devices, cybercriminals are able to generate and direct vast amounts of traffic at their targets. Decentralizing the control process also makes it much harder to stop an attack because there is no longer a single command server for your security team to focus on. As such, expect to see these kind of IoT-based DDoS attacks more frequently in future. ## Why do we have to protect our own resources? Given that Mirai (and similar malware) works by compromising IoT devices, who should take responsibility for preventing future DDoS attacks? #### **Manufacturers?** Mirai malware works by exploiting known vulnerabilities in the embedded Linux operating system used by various IoT devices like IP cameras and home routers. By issuing software updates, manufacturers could help to patch these exploits. However, many of the compromised devices are from budget manufacturers who provide little or no support. Software updates are rare – or completely non-existent. As a result, these vendors have little or no interest in providing after-sales support or fixes. #### **IoT device owners?** Often the compromised IoT devices are consumer-grade devices. Even if manufacturers provide firmware updates, many end users lack the knowledge or confidence to update their hardware. Given that the effects of infection are almost negligible (slightly increased bandwidth usage, occasional sluggishness), most users would not bother applying the patches anyway. #### **ISPs?** ISPs could detect and block malicious traffic if they chose to. Because DDoS traffic volumes tend to be lower than regular video streaming, most ISPs classify the bandwidth usage as manageable – and therefore not worth worrying about. #### **You?** As the only party with a vested interest, it is down to your business to protect against malware botnet activity. It is your bandwidth and resources being targeted, so you need to implement the relevant safeguards to identify and mitigate a DDoS attack. ## How to protect your network against Mirai The key to managing a Mirai DDoS attack is preparation, having mitigation safeguards in place before an attack is launched. FastNetMon provides reliable and accurate detection and response automation. Importantly, FastNetMon can respond in as little as two seconds, allowing you to block an attack before your resources are overwhelmed. FastNetMon has been engineered to protect against the most advanced DDoS attacks, including: - UDP, TCP, and ICMP flooding attacks. - TCP protocol attacks such as SYN, SYN-ACK, and FIN floods. - IP Protocol attacks that use fragmented packets. - Reflection and amplification attacks through NTP, SNMP, SSDP, DNS, GRE, Chargen, etc. - Multi-vector attacks that employ a combination of techniques to evade mitigations. But more than simply detecting DDoS attacks, FastNetMon can also automate your response. There are three key tools for mitigating a Mirai botnet attack: - Blackhole automation - routing traffic to attacked IP addresses to a null0 interface, resulting traffic being dropped from the network without returning a response to the sender. - FlowSpec mitigation – which filters out most volumetric attacks, including TCP floods, DNS amplification and reflection attacks, GRE floods, and SSDP, SNMP, and Memcached amplification attacks. Importantly, FlowSpec mitigation only catches and blocks malicious traffic at the routing stage. - Block-list based filtering – which blocks traffic originating from specific senders. This approach can also disrupt malware activity by blocking communications with external C2 infrastructure. ## Ready to learn more? FastNetMon is future ready, able to protect against DDoS attacks from the Mirai botnet – or any other malware-driven source. To learn more, why not [try FastNetMon free for one month](https://fastnetmon.com/trial/)? **Categories:** FastNetMon Blog **Tags:** 2023 --- ### [Rise of carpet bombing DDoS attacks and ways to detect and defend against them using FastNetMon Advanced](https://fastnetmon.com/2023/10/24/rise-of-carpet-bombing-ddos-attacks-and-ways-to-detect-and-defend-against-them-using-fastnetmon-advanced/) **Published:** October 24, 2023 **Author:** FastNetMon **Content:** Carpet bombing DDoS attacks are an increasingly common form of cybercrime because they are harder to detect and block than a traditional targeted attack. However, FastNetMon provides powerful configuration options to help you identify and defend your systems. ## What is a carpet bomb DDoS attack? A typical DDoS attack uses hundreds (or thousands) of compromised systems to overload the resources of a specific target. By generating enough network requests, an unprotected system will eventually crash, making it unavailable to legitimate traffic. A carpet bomb DDoS attack is slightly different. Rather than attack a single endpoint, thousands of requests are directed at a range of addresses or subnets. This approach allows hackers to target hundreds, or even thousands, of endpoints with malicious traffic. Because more endpoints are attacked, the damage caused can be exponentially greater than a regular DDoS attack. Carpet bomb attacks can be directed at a range of IP addresses belonging to a specific target, overloading a range of services. Alternatively, hackers may attack a broad range of addresses to overload multiple services simultaneously, obfuscating the intended target and making it harder to identify the perpetrator. The collateral damage and costs of these wide-scale attacks can also be exponentially greater. Carpet bomb DDoS attacks can overwhelm scrubbing facilities used by enterprise-class organisations to process and filter malicious traffic. Where the scrubbing function is outsourced, cloud redirection budgets can be quickly exhausted, leaving the victim unprotected. Unable to accurately detect an attack, alerting and reporting systems cannot respond effectively. ## Give me some examples of carpet bomb DDoS attacks Because they fly ‘under the radar’, carpet bomb attacks are effective against even the most secure companies, like ISPs. Cool Ideas, one of South Africa’s largest ISPs, became the target of one such attack. Over the course of several days, hackers bombarded a range of IP addresses belonging to the ISP - including those used by their customers. Eventually the attack brought down Cool Idea’s connections to other ISPs, preventing any of their customers from [accessing the internet](https://www.zdnet.com/article/carpet-bombing-ddos-attack-takes-down-south-african-isp-for-an-entire-day/). The technique is so effective that back in 2019, hackers were able to [take an entire country offline](https://www.zdnet.com/article/mirai-botnet-attack-briefly-knocked-an-entire-country-offline/). Due to low uptake and investment, Liberia had just one undersea fibre connection to the rest of the world at that time. By attacking the country’s two ISPs, criminals were able to overload the connection, effectively cutting Liberia off. Just 6% of the Liberian population use the internet so the effects were relatively moderate - most analysts believe the attack was a proof-of-concept test to measure effectiveness. For the wider IT industry this incident proves the destructive capabilities of DDoS carpet bombing. ## Why are carpet bombing attacks increasing in frequency? Hackers are choosing carpet bomb DDoS attacks for several reasons: - Attacking a broad range of systems helps to obscure the intended target, ideal for more covert crimes - DDoS mitigation systems that operate on a per target address basis can themselves be overloaded if thousands of addresses are targeted - Hackers may combine reflection-amplification techniques to maximise their distributed reach and traffic directed at targets - By design, carpet bombing DDoS attacks can be quite difficult to detect and mitigate - Carpet bombing can be more effective - and damaging - than traditional DDoS attack methods ## Why are DDoS carpet bombing attacks hard to defend against? The main reason why carpet bomb DDoS attacks are so difficult to defend against is the actual design of the attack. By targeting a range of devices, the attack often uses a smaller amount of traffic per host. This reduced level of network traffic tends to be below the detection threshold configured in mitigation systems, meaning that defences are never triggered and that the targeted systems experience performance issues – or crash entirely. The methodology may be slightly different, but the effect of a carpet bombing DDoS attack on network devices is the same as any other DDoS attack. Even if some malicious traffic is detected and blocked by a traditional DDoS mitigation detection system, the majority will still reach its target. The good news is that FastNetMon can be configured to detect and block distributed denial of service carpet bombing attacks. ## Configuring FastNetMon to detect and block carpet bombing DDoS attacks The key to mitigating carpet bombing attacks with FastNetMon is to properly configure per hostgroup thresholds. This will allow you to calculate total traffic for a number of prefixes and to take custom actions when it reaches a specified value. You can read more about [enabling hostgroup counters](https://fastnetmon.com/docs-fnm-advanced/per-hostgroup-thresholds/) in FastNetMon in the developer documentation. To further assist your security and network engineers, FastNetMon has also developed a Grafana dashboard for monitoring [advanced hostgroups traffic](https://grafana.com/grafana/dashboards/10449-fastnetmon-advanced-hostgroups-traffic/), providing at a glance access to key metrics. To learn more about FastNetMon and how we can help you detect and mitigate DDoS carpet bombing attacks, please get in touch. **Categories:** FastNetMon Blog **Tags:** 2023 --- ### [The importance of having a rapid DDoS protection to defend from flash attacks](https://fastnetmon.com/2023/10/24/the-importance-of-having-a-rapid-ddos-protection-to-defend-from-flash-attacks/) **Published:** October 24, 2023 **Author:** FastNetMon **Content:** Distributed denial of service attacks (DDoS) are a significant risk to businesses of any size. One study found that recovering from a DDoS attack costs between [$120,000 and $2m](https://www.msspalert.com/cybersecurity-research/kaspersky-lab-study-average-cost-of-enterprise-ddos-attack-totals-2m/) (£93,000 - £1.55m) depending on the size of the company affected. Most of this cost is borne whilst fighting a flash attack and restoring services. Which means that identifying and blocking DDoS attacks can dramatically reduce IT security costs – particularly in relation to service disruption and breaches. ## Speed is of the essence Every organisation has mission-critical IT systems; any disruption or inability to access these resources will have a knock-on effect on operations. They must be available and operating optimally to maximise efficiency, productivity and customer experience. A DDoS attack that affects access to key business systems will result in losing business to competitors. Worse still, lost customers may never return, particularly if the strike causes personal loss or damages the reputation of your organisation. Consequently, DDoS attack detection and mitigation has to be fast and effective. Speed of response is crucial to limiting potential damage to network resources and the user experience. It is also important to note that many DDoS attacks last less than 10 minutes. However, these ‘drive by’ incidents are typically just a test run, used by hackers as a proof of concept. Often they are a precursor to a more serious, sustained attack at some point in the future. Mitigating this initial attack will prevent re-targeting. So-called ‘hacktivist’ groups rely heavily on DDoS attacks to cause widespread disruption - often for political reasons - to organisations across sectors including government, healthcare, education or finance. Often they are targeted for no other reason than their geographic location. DDoS attacks are not just for cyberwarfare however. Sustained distributed denial of service attacks took popular games like The Last of Us and Grand Theft Auto offline for several days, potentially costing publishers Sony and Rockstar Games millions of dollars in lost revenue. Accelerating response to DDoS attacks is therefore essential to protecting revenue and maintaining full operationality. ## How FastNetMon accelerates DDoS response An effective response to DDoS flash attacks requires constant, in-depth monitoring. To assist with this process, FastNetMon uses state of the art traffic telemetry protocols available from some vendors. There are two protocols which may help to improve attack detection speed and provide more information about attack vector: - sFlow v5 from InMon Inc - PSAMP based family of protocols as described in RFC 5476 sFlow is a well known protocol but it’s available mostly on switches and rarely can be found on routers which opens a large gap for deployment of rapid detection as the majority of Telco networks use routers to export traffic. Recently multiple vendors such as Cisco and Juniper introduced support for new PSAMP based protocols. They use brand specific names such as Cisco IPFIX 315 and Juniper inline monitoring service. These protocols are implemented on a data plane and do not use any aggregation which may delay export of traffic to DDoS sensors. In addition to that, these protocols provide raw packet headers which allow them to extract all the information available in the packet and identify malicious traffic with greater precision. FastNetMon has solid support of these protocols and its high performance multi thread telemetry traffic information ingestion engine can handle telemetry from Terabit scale networks without any issues. Note that these network telemetry protocols are available in: - Juniper MX routers (inline monitoring services) - Cisco ASR9000 and NCS 5500 routers (IPFIX 315) You can find step-by-step configuration instructions for these devices [here](https://fastnetmon.com/docs-fnm-advanced/netflow-lite-and-ipfix-inline-monitoring-services/). ## Why use PSAMP based telemetry protocols? When enabled, PSAMP based monitoring allows FastNetMon to recognise an attack in just two seconds. This rapid detection allows for a rapid response – and provides an opportunity to mitigate an attack before web application performance is significantly affected. This is important when you consider the average DDoS attack has gone from 30 minutes duration in 2021 to [3000 minutes](https://securelist.com/ddos-attacks-in-q2-2022/107025/) (50 hours!) in 2022. Blocking an attack within two seconds offers major, long-term benefits, highlighting the importance of ultra-fast detection and response. To learn more about FastNetMon and how we can help you with fast DDoS detection and mitigation, please get in touch. **Categories:** FastNetMon Blog **Tags:** 2023 --- ### [The Evolution of DDoS Attacks: Trends and Countermeasures](https://fastnetmon.com/2024/02/14/the-evolution-of-ddos-attacks-trends-and-countermeasures/) **Published:** February 14, 2024 **Author:** FastNetMon **Content:** The UK’s National Crime Agency has identified two key cyberthreats to business – ransomware and DDoS attacks. But how do we find ourselves in this situation? And what can be done to better protect your organisation? ### From bedroom to boardroom Up until 2007, DDoS attacks were mostly carried out by hackers looking to create mischief. Generally these attacks were borne out of a desire to disrupt rather than destroy. This changed in 2007 when the Estonian government and several key organisations were targeted by DDoS attacks. Post attack analysis suggested that foreign agencies may have been involved, marking the first publicly acknowledged example of cyber warfare. ### DDoS as a tool for extortion Given that responsive IT is essential to modern data-driven operations, any kind of outage is disruptive and costly. So the threat of an impending DDoS attack is a very effective way of extracting cryptocurrency ransom payments from a potential target. To prove they are serious, the extortionists will often launch a small-scale attack to prove their capability – and the potentially devastating consequences of a larger DDoS strike. Evidence suggests that the technique is effective too as the number of ransoms being paid continue to increase year-on-year. ### DDoS-as-a-Service As legitimate businesses move towards subscription-based software and services, so too has cybercrime. Hackers have developed ways to commoditise their DDoS botnets, making them available for hire in almost the same way you would sign up for an Office 365 subscription. This means that sophisticated DDoS attacks no longer require any technical knowledge or expertise – just a credit card. Importantly, the relative cost is extremely low, allowing anyone to attack any organisation for any reason. ### Amplification and multi-vector attacks Volume is key to a successful DDoS attack, so criminals have developed new ways to increase – amplify – traffic. The most famous example is the Mirai botnet which uses a vast network of compromised Internet of Things (IoT) devices for staging. From a central console, hackers can produce over 1.3Tbps of attack traffic. At the same time, detection techniques are getting smarter, able to spot large volumes of suspicious traffic. This led to the development of multi-vector attacks, where traffic is generated and directed in several directions to hide its malicious intent. Because several different infrastructure components are attacked simultaneously, overall volumes of traffic tend to be lower – but the results are no less devastating. ### Increased botnet power The Mirai network is an example of relatively low-power devices being used to create significant disruption. But generating massive amounts of traffic requires a large number of compromised devices. As DDoS mitigation techniques improve, attackers need to generate greater quantities of traffic. To do this, criminals are now using enterprise grade servers and devices to maximise potential power of their botnets. Coupled with IP address spoofing and reflection-amplification techniques, these server grade attacks can generate enormous amounts of traffic – as much as 2.5 terabits per second. Each. ### Carpet bombing attacks As defences have evolved, traditional DDoS attacks are relatively easy to identify and mitigate. So cybercriminals have adapted their methods once more, leading to the development of new techniques like carpet bombing. Using botnets, hackers attack a range of addresses and subnets simultaneously. This approach mimics natural traffic, making it harder to detect. And it can quickly overwhelm DDoS mitigation systems. By affecting multiple resources, or organisations, Carpet bomb DDoS attacks are also used to obfuscate the intended target. ### So how have DDoS countermeasures evolved? Initially, DDoS attack mitigation revolved around blacklists. Suspicious IP addresses would be added to a ban list, allowing perimeter network devices to drop traffic from known sources. But as botnets have grown in size, managing these lists, even automatically, is too slow. Blacklists were followed by traffic scrubbing services. Incoming traffic is routed via a third party service for analysis and ‘scrubbing’, ensuring that only legitimate packets are forwarded to the target network. Although very effective, these services are relatively expensive. More problematically still, a well-designed attack may be able to overload target infrastructure *before* it can redirect incoming traffic to the scrubbing centre. The solution? Smarter perimeter detection systems that can spot multi-vector attacks and suspicious activity faster. FastNetMon is capable of detecting and mitigating DDoS attacks in as little as two seconds. Which means that even sneaky new attacks like carpet bombing can be identified and dealt with before infrastructure becomes overwhelmed. To learn more about FastNetMon and how the product develops to meet evolving DDoS challenges, please contact us to arrange a free 30-day [demo](/trial/). **Categories:** FastNetMon Blog --- ### [The Benefits of FastNetMon for Small and Medium-sized Enterprises](https://fastnetmon.com/2024/02/14/the-benefits-of-fastnetmon-for-small-and-medium-sized-enterprises/) **Published:** February 14, 2024 **Author:** FastNetMon **Content:** It may be tempting to think of DDoS detection and mitigation as being an enterprise-only requirement. But as 40% of all cybersecurity events are now caused by distributed denial of service attacks, *all* businesses are at risk of disruption. As a result, all small and medium-sized enterprises (SMEs) begin reviewing their DDoS strategies to cope with this increasing threat. And part of those considerations will include selecting a detection and mitigation toolset to assist. So why should your SME consider FastNetMon for DDoS protection? ### Enterprise-class protection for all Whether your company has 100,000 employees or 100, DDoS attacks have the same devastating consequences. They also work in exactly the same way, using excessive network traffic to overload your internet-connected systems and forcing them offline. FastNetMon can be deployed in any setting to protect any number of assets. And it will grow as you do. Which means that your business is fully protected against DDoS attacks as you scale. It also explains why FastNetMon is the DDoS protection tool of choice for companies of all sizes. ### Fast and automated Once implemented, FastNetMon will continue to operate unattended and unnoticed. When a potential attack is detected, pre-configured rules will automate your response too, blocking or redirecting malicious traffic as appropriate. This relieves the burden on SME IT, allowing resources to be deployed where they can be most effective. And because FastNetMon can detect and mitigate attacks in as little as two seconds, it is also considerably faster than trying to manage a DDoS attack manually. ### All the help and advice you need Mitigating a DDoS attack is a specialist skill – one that many SMEs lack – leading to incomplete or unsatisfactory mitigation efforts. FastNetMon provide comprehensive support to all their customers, helping to plug these skills gaps and ensuring an appropriate response to any event. The FastNetMon support team is fully qualified and experienced, ready to assist with any DDoS query. We’re always available to help our customers, no matter how big or small they may be. ### Quick and simple to deploy Unlike other DDoS mitigation technologies, FastNetMon does not require any specialist hardware or non-standard configuration work, helping to reduce total cost of ownership. In fact, the system will drop into your existing infrastructure – installation and configuration takes just 40 minutes on average. Which means you can have enterprise-grade DDoS protection for all your networked assets in less than an hour. Rapid deployment reduces total cost of ownership (TCO) – and boosts return on investment, making FastNetMon a sensible investment for SMEs. ### Native vendor support To further reduce TCO, your DDoS mitigation solution needs to be compatible with your existing network hardware. FastNetMon offers full vendor compatibility for a wide range of devices including Cisco, Juniper, Dell, HP, D-Link, Fortinet, Nokia, Nvidia, Huawei, ZTE, Mikrotik, Ubiquiti, and more. [Contact our support team](/contact/) if you don’t see your device listed – we probably *do* support it. ### Future ready technology As an SME, your IT needs may be relatively simple at present – but that will not always be the case. As we have already said, FastNetMon can scale automatically as your network grows. However, a selection of powerful developer tools allow you to extend and enhance functionality as needs change. With the FastNetMon developer tools you can configure your unique attack profile via REST JSON API, callback scripts, and webhooks. The system also supports Graphite, Clickhouse, and InfluxDB, with optional Kafka support to cover most needs. ### SME friendly pricing Obviously SMEs have fewer resource demands than an enterprise competitor – and FastNetMon pricing reflects this reality. There are a range of pricing tiers available to ensure even the smallest businesses can afford fast, effective, reliable DDoS detection and mitigation safeguards. You can find out more about our SME friendly pricing plans [here](/price/). ### See what FastNetMon can do for your SME Interested? Why not see exactly what FastNetMon offers your business with a one-month free trial? Simply complete this [trial sign-up form](/trial/) and one of our team will be in touch to discuss set-up and deployment. **Categories:** FastNetMon Blog --- ### [Network Security Best Practices: Insights from FastNetMon Experts](https://fastnetmon.com/2024/02/14/network-security-best-practices-insights-from-fastnetmon-experts/) **Published:** February 14, 2024 **Author:** FastNetMon **Content:** Effective network security can be reduced to two goals; keeping unauthorised users out and keeping sensitive data in. But as IT systems continue to evolve, particularly in the era of the cloud, the strategies and techniques to achieve these twin goals must also change. So as you refine your strategy, here is some best practice advice from the FastNetMon team of experts. ### Adopt a Zero Trust policy The border between corporate systems and the world has completely disappeared as cloud services, remote working and BYOD become the norm. This means that the IT security team has had to yield much of the control over the devices used to connect to company resources. The solution is to adopt a Zero Trust approach, where users, devices and applications pass through multi-factor authentication mechanisms before being granted access. Zero Trust authentication will also consider the context of every request, providing granular controls on what is being accessed, by whom, from which device, at which time and whether the connecting device meets certain basic security criteria. By trusting nothing (Zero Trust), you can ensure complete control over network resources without having to control the endpoints or granting excessive access rights. Which means that you can solve many of the shortcomings of traditional VPN connections which do not offer the granular access control your network needs. ### Audit infrastructure regularly Without definite borders, the network continues to grow and evolve, particularly as new cloud-based assets are adopted. This means that the various interconnections of applications, devices and infrastructure will change over time. And unless your IT security team stays on top of these changes, new vulnerabilities will be created or exposed. Conducting regular audits of network and security controls will be essential for identifying and rectifying vulnerabilities before they can be exploited. Audits are also a good way to ensure your IT team is up-to-date in their knowledge of current infrastructure, allowing them to be more effective in their roles. ### Implement an SIEM strategy and toolkit Your infrastructure is under constant threat, making event analysis even more important. But with so much ‘noise’ being logged, identifying genuine threats can be quite difficult. Implementing Security Information and Event Management (SIEM) automates event log analysis, highlighting only those issues which do require further investigation. A dedicated SIEM toolkit or platform can automate many of the initial exploratory functions too, accelerating your response to a potential event and better protecting assets. All of which means that you can focus your resources fully on dealing with incidents. If nothing else, adopting SIEM encourages your network security team to formulate an effective strategy for identifying and responding to events. Which means they will be better prepared when the inevitable happens and your business is attacked. ### Strengthen your DDoS Defences Distributed Denial of Service attacks are becoming more frequent, more devastating and more devious. In fact, DDoS attacks make up 40% of all cybersecurity incidents each year. Worse still, any internet-connected business is at risk of DDoS attack. Having a solution to detect and mitigate suspicious / malicious activity is absolutely essential to ensuring your web-facing assets remain online. FastNetMon provides near instant (~2 seconds) detection of DDoS activity, allowing you to apply the appropriate mitigation strategy before your users are even aware there may be a problem. FastNetMon can detect all DDoS variations and can be used to protect assets on-premises *and* in the cloud alike. Combining FastNetMon with a traffic scrubbing service offers even greater protection against DDoS attacks, ensuring that your services continue to run unaffected for legitimate users. ### Upgrade your firewalls As previously mentioned, cybercriminals are becoming more devious. So although traditional firewalls remain an essential network security safeguard, you must consider implementing Next Generation firewalls (NGFW) too. NGFWs provide Layer 7 (application layer) packet inspection functionality. This deep packet inspection (DPI) capability can be used to detect and block malicious *application* traffic. Which is particularly useful in an age where distributed applications based in the cloud are a regular aspect of business and network operations. Secure Web Gateways (SWG) offer similar Layer 7 functionality, allowing administrators to secure web traffic. An SWG increases network oversight through URL filtering, application control, inspection of encrypted traffic delivered over HTTPS and malware protection for files delivered over the web. **Categories:** FastNetMon Blog **Tags:** 2024 --- ### [FastNetMon vs. Traditional Network Monitoring Solutions: A Comparative Analysis](https://fastnetmon.com/2024/02/27/fastnetmon-vs-traditional-network-monitoring-solutions-a-comparative-analysis/) **Published:** February 27, 2024 **Author:** FastNetMon **Content:** An old IT proverb states, ‘If ain’t broke, don’t fix it’; if a system continues to deliver the results you want, there is no need to replace it. But at a time when cybersecurity threats evolve exponentially, traditional network monitoring solutions are probably not delivering all the benefits and functionality you need to be properly protected. So why should you consider replacing your traditional network monitoring solution with the next-gen capabilities of FastNetMon? ### Detection speed The longer a DDoS attack lasts, the greater the overall cost to the victim. Fast detection and mitigation is therefore essential to limiting the potential damage caused by an attack. Traditional network monitoring solutions have two drawbacks. First, they must compare incoming traffic against their internal blacklists. When a suspicious event is detected, they must then propagate that finding across other systems to maintain network-wide protections. FastNetMon uses intelligent traffic analysis to identify suspicious activity, regardless of source. This analysis is far faster than blacklist comparisons, allowing the mitigation process to be started *and finished* earlier. And because analysis takes place in the FastNetMon engine rather than on the network infrastructure, there is no network performance overhead to worry about either. ### Intelligent detection Unlike some traditional solutions that require traffic sampling and analysis, FastNetMon performs all monitoring on live traffic in real time. Importantly, it is capable of analysing a range of telemetry protocols including NetFlow, IPFIX, sFlow, and SPAN/port mirror. Real time monitoring reduces DDoS attack detection time to just two seconds when dealing with sFlow and SPAN/Mirror mode – and thirty seconds when working with Netflow 5/9 and IPFIX. This is considerably faster than traditional technologies. ### Cloud-ready network traffic analysis Cloud systems are not impervious to DDoS attacks – and most traditional tools do not offer the required functionality to protect PaaS and SaaS properties. On the other hand, FastNetMon *can* import and analyse popular traffic logging formats from AWS and Google Cloud services. This functionality ensures that businesses can protect all of their network resources, regardless of where they are physically hosted. By choosing FastNetMon for DDoS detection and mitigation, businesses can employ a single tool for monitoring *all* of their assets, helping to reduce management overheads and costs and preventing tool sprawl. Notably, FastNetMon is also fully scalable, keeping pace with traffic growth and ensuring that the network is always fully protected against attack. ### Instant automated traffic diversion Scrubbing centres are an essential aspect of DDoS attack mitigation. The faster suspicious traffic can be redirected for scrubbing, the less risk there is of your network being overloaded. Traditional DDoS mitigation systems built around BGP traffic diversion are comparatively slow to respond. This delay will have a marked effect on network performance, impairing the user experience and functionality of critical business applications. FastNetMon does not need to propagate diversion instructions. Instead it automatically implements redirection to the off-site DDoS scrubbing centre allowing for ultra-fast response times and ensuring legitimate traffic is unaffected. ### Vendor neutral Traditional network monitoring solutions may be tailored to a specific vendor’s tech stack. In order to provide a complete understanding of traffic flow, administrators must chain several different solutions together. This reduces transparency and leads to duplicated effort in terms of set-up and maintenance, increasing the risk of an important configuration being ‘missed’, leaving the network vulnerable. FastNetMon is vendor neutral, ensuring it can be used with any hardware from any vendor for total transparency and control. By aggregating and actioning data from a range of built-in capture engines, administrators can dramatically simplify network configurations, using rules built into FastNetMon to handle DDoS mitigation directly. ### Simple, fast install Hardware network monitoring devices require physical installation adding to deployment time and disruption – and that is before configuration work begins. FastNetMon is supplied as a virtual appliance, reducing disruption and accelerating deployment. The entire installation process can be completed in as little as 40 minutes. And thanks to one-click installers, the deployment is just as fast and simple when configuring DDoS attack detection on premises or in the cloud. ### More than just a protective measure Unlike traditional monitoring systems which perform a single function, DDoS attack detection, FastNetMon analysis can be applied to other business challenges. By collating and analysing *all* network traffic, your infrastructure team can gather a more granular understanding of exactly how the network is being used. These insights are invaluable, allowing you to better plan infrastructure deployment and configuration for maximum performance. It also provides actionable intelligence about how resource-billed assets, like cloud infrastructure, are being used – identifying options for re-configuration that improve the user experience *and* help to reduce costs. ### Take the next step To learn more about FastNetMon and why it is the ultimate upgrade for your DDoS mitigation strategy, please contact us to arrange a free 30 day trial. **Categories:** FastNetMon Blog --- ### [FastNetMon's Role in Protecting Cloud Infrastructure from DDoS Attack](https://fastnetmon.com/2024/02/29/fastnetmons-role-in-protecting-cloud-infrastructure-from-ddos-attack/) **Published:** February 29, 2024 **Author:** FastNetMon **Content:** One of the biggest benefits of cloud infrastructure is its (theoretically) infinite scalability. Cloud applications can scale automatically to cope with increased demand, dynamically allocating additional bandwidth and resources as and when required. And at the most basic level, this elasticity should help to manage enormous surges in network traffic – but you still need to be prepared for distributed denial of service (DDoS) attacks. Particularly as [DDoS attacks continue to increase in frequency](https://cybermagazine.com/articles/ddos-protection-market-to-grow-amid-increase-in-attacks) – up 109% over the last year. ### What’s the problem with DDoS in the cloud? There are two major problems. First, cloud resources are not truly infinitely scalable – there are concrete limits imposed by the hardware installed in the cloud provider’s regional data centres. This is particularly true of network connectivity – there is a finite amount of bandwidth available that needs to be shared among all tenants. Which means that a DDoS attack could still cripple your applications and services by overloading your external connections. Second, infinite scalability is not cheap. Cloud services use a resource billing model which ensures you are charged for every MB of data transferred and CPU cycle used – and cloud providers make no distinction between legitimate and illegitimate traffic. Given that data transfer is one of the largest components of your cloud costs, it makes no sense to pay for unwanted activity caused by a DDoS attack. Which is why FastNetMon is a valuable addition to your cloud network toolkit. ### Are you experiencing a DDoS attack? Amazon AWS and Google Cloud do not supply native DDoS attack detection at the tenant level, nor do they typically monitor tenant traffic to detect malicious activity (they do monitor and block attacks aimed at their underlying infrastructure). Under the shared responsibility model your business is responsible for implementing its own DDoS defences, particularly inside your virtual network. As always, speed of detection has a direct effect on how quickly you can mitigate an attack. Which is why FastNetMon has been designed for native integration with services from two of the most popular platforms – Google Cloud and AWS. ### How does FastNetMon work in the cloud? There is one distinct advantage to on-premise network management – you have direct access to incoming and outgoing traffic. FastNetMon takes a slightly different approach in a cloud deployment. The system is configured in such a way that monitoring is performed using the VPC flow logs generated by the platform. These logs are imported in real time into a cloud-based database (Amazon Lambda or Google Cloud Datastore as appropriate) for rapid analysis. FastNetMon then uses its advanced detection algorithms to quickly spot and mitigate suspicious activity. ### Can FastNetMon in the cloud do anything else? Piping VPC flow logs into a database allows for granular analysis in real-time *and* as part of your general network monitoring activities. In addition to malicious activity you can also assess legitimate traffic and how it impacts cloud infrastructure. These insights can be applied to improving architecture design and performance, shifting assets and elements from cloud to content distribution network (CDN) for instance. Indeed, a deeper understanding of usage will enable your architects to make smarter design choices that reduce operating costs for legitimate activity too. ### What next? Any internet connected system is at risk of being involved in a DDoS attack – including those hosted in the cloud. By unifying their exceptional attack detection software with native cloud tools, AWS and Google Cloud users can ensure they are fully protected against cyberattacks. And with one-click install options, your business could enhance DDoS protection within a matter of minutes. To learn more about FastNetMon and how your business can better protect itself, [please get in touch](https://connect.fastnetmon.com/fastnetmon-your-ultimate-solution-to-ddos-protection-for-business-security) to arrange a short, no-obligation trial. **Categories:** FastNetMon Blog **Tags:** 2024 --- ### [A Guide to FastNetMon's Advanced Features](https://fastnetmon.com/2024/02/14/a-guide-to-fastnetmons-advanced-features/) **Published:** February 14, 2024 **Author:** FastNetMon **Content:** Distributed Denial of Service attacks (DDoS) remain one of the most significant cybersecurity threats posed to businesses today. This is particularly true as DDoS attacks are now typically accompanied by at least one other threat, further increasing risk to your operations. Defending against DDoS relies on having a fast, reliable detection mechanism, capable of identifying malicious traffic quickly and accurately. That’s where FastNetMon can assist. More than just another IP blacklisting solution, FastNetMon offers a range of advanced features that will help your business protect against current and future threats. Here’s why you should consider deploying FastNetMon. ### Super-simple software based protection Sometimes simplicity is an invaluable asset. FastNetMon can be installed in a Docker container or as a VMware virtual machine, integrating neatly with your existing environment. This software-based approach means that you can deploy and configure your initial FastNetMon instance in as little as 40 minutes. Your organisation could be benefitting from ultra-fast, accurate DDoS detection and mitigation in less than one business day. Importantly, FastNetMon can be installed on any server or VM – so there is no need to purchase a costly, proprietary hardware device. Which is great news if your data centre has already run out of rack capacity. ### High availability configuration options Protecting high availability systems against DDoS attacks is a strategic imperative. By definition, these systems must be available at all times. Because of its unlimited scalability, FastNetMon provides enhanced protection for HA environments. To increase detection and mitigation speeds, simply add additional clustered servers as required. This scalability ensures that you can increase your DDoS detection capacity quickly and easily to protect your expanding HA estate. ### Fully extensible FastNetMon is not a magic black box where all DDoS detection capabilities are hidden in a proprietary hardware device. Our system not only integrates neatly with your existing infrastructure, we also encourage you to extend it as required. To this end, FastNetMon includes several development features including a full API along with support for hook scripts and filter scripts. Configurations and attack details are stored in a developer friendly JSON database, offering potential to read and use FastNetMon data in your other security tools. ### Cloud analytics The cloud plays an integral role in most organisations’ digital transformation plans. The option of infinite scalability on a pay-as-you-use basis solves many of the headaches associated with infrastructure planning. However, platforms like [AWS](/aws-network-analytics/) and [Google Cloud ](/google-cloud-network/)offer limited traffic monitoring and visibility capabilities. Available as a one-click install for both cloud platforms, FastNetMon can ‘open the box’ allowing you to identify problems and bottlenecks and how to fix them. Once deployed, FastNetMon detects incoming traffic for each instance, and assesses which instances/networks are becoming overloaded. Granular reporting allows you to drill-down to see which countries or autonomous systems are creating excessive amounts of traffic. This data can be used to support strategic decision making, such as deciding whether to move specific components from your cloud to content delivery networks to improve load balancing. And of course, FastNetMon also provides [DDoS detection and mitigation](/ddos-detection-and-mitigation/) for your cloud-based assets too. ### Embedded device options Although the most common deployment method is via containers or virtual machines, FastNetMon also supports embedded computing devices. Typically reserved for testing and proof of concept purposes, FastNetMon can run on ARM64 chipsets. This means that any ARM64 device capable of running Ubuntu 22.04 LTS can become a FastNetMon node, such as the RockPro64, ESPRESSObin or Raspberry Pi. ARM64 support is still experimental, but it offers a low-cost option for developers and network engineers to build and test functionality without taking resources away from line-of-business operations. ### Building for the future FastNetMon is being constantly refined and improved to meet the changing nature of DDoS attacks. And the advanced features we have outlined here will prove invaluable for any business that is serious about increasing resilience and quality of service for their users and customers. To learn more about FastNetMon’s advanced features, contact us to arrange a free 30-day [trial](/trial/). **Categories:** FastNetMon Blog **Tags:** 2024 --- ### [Ministry of defence in South Korea under DDoS attack](https://fastnetmon.com/2024/11/12/ministry-of-defence-in-south-korea-under-ddos-attack/) **Published:** November 12, 2024 **Author:** FastNetMon **Content:** In recent weeks, South Korea has found itself at the center of a series of distributed denial-of-service (DDoS) attacks, coinciding with heightened geopolitical tensions. The South Korean President’s Office has reported an uptick in cyber-attacks from politically motivated hacktivist groups, primarily targeting government websites and private companies. Among the targets have been the websites of ministries of defense, environment several courts, but also private companies. These attacks have resulted in temporary disruptions, although no significant damage has been observed. The series of DDoS attacks starter on November 5, when the South Korean Ministry of National Defense website was hit by a DDoS attack, rendering it inaccessible for a period. The Ministry quickly activated its DDoS mitigation system, restoring normal operations. The Korea Internet and Security Agency has since advised all domestic institutions to enhance their cybersecurity measures, citing the increased threat from international hacking groups. ![](https://fastnetmon.com/wp-content/uploads/2024/11/DDoS-News-South-Korea-Ministry-Of-Defence.png)*Screen capture of the Ministry of Defence website on November 6th, 2024*South Korea’s National Cyber Crisis Management Team is actively monitoring these developments, coordinating with related agencies to bolster defenses. As the situation unfolds, the need for robust cybersecurity strategies and faster DDoS mitigation becomes increasingly evident. --- ## About FastNetMon FastNetMon delivers versatile DDoS detection software for companies at any scale. With extensive experience in the telecom, mobile, and cloud computing industries, we take pride in preventing DDoS attacks and protecting our customers’ networks to the highest standard. Find out more: <https://fastnetmon.com/> **Categories:** FastNetMon Blog **Tags:** DDoS Attacks --- ### [Card readers malfunctioning in Israel due to a DDoS attack](https://fastnetmon.com/2024/11/13/card-readers-malfunctioning-in-israel-due-to-a-ddos-attack/) **Published:** November 13, 2024 **Author:** FastNetMon **Content:** On Sunday November 10th, a DDoS attack caused widespread disruption to credit card readers across Israel, affecting several payment systems in supermarkets and gas stations. The incident, which lasted approximately an hour, targeted the communications services of Hyp’s CreditGuard product, a key payment gateway company in the country. According to reports from the local media, the DDoS attack disrupted the communication between card terminals and the broader payment system. No sensitive information or transaction data were compromised. Hyp's spokesperson communicated that the attack was rapidly identified and blocked, allowing services to return to normal shortly thereafter. The attack specifically targeted some of the company's services and the communication providers connected to them. While the identity of the attackers remains unclear, few local news sources have reported claims from an Iran-linked hacker group, though these claims have not been substantiated with sources. This incident follows a similar attack in October on the payment firm Sheba, which caused a three-hour disruption in the national payment system. The increase in cyberattacks on civilian infrastructure in Israel is occurring amidst regional tensions, with politically-motivated groups, including those affiliated with Iran and Hezbollah, being active participants. --- ## About FastNetMon FastNetMon delivers versatile DDoS detection software for companies at any scale. With extensive experience in the telecom, mobile, and cloud computing industries, we take pride in preventing DDoS attacks and protecting our customers’ networks to the highest standard. Find out more: <https://fastnetmon.com/> **Categories:** FastNetMon Blog **Tags:** DDoS Attacks --- ### [FastNetMon Advanced 2.0.366](https://fastnetmon.com/2024/06/27/fastnetmon-advanced-2-0-366/) **Published:** June 27, 2024 **Author:** FastNetMon **Content:** FastNetMon has released a new update with several enhancements and additions. The update includes options for pcap reader to load networks list, a counter for tracking UDP packets, and improved logic for IPv6 address use in Netflow and IPFIX plugin. It also introduces FerretDB support for community configuration import and Ubuntu 24.04 support to the installer. Additionally, the update provides per protocol counters for ASN, networks, and interfaces, and an option to calculate speed in parallel. Full list of updates below. Changes: - Adding option to pcap reader to load networks list from /tmp/networks\_list\_pcap.dat - Added cron installation for Panel - Added counter to track UDP packets for Netflow or IPFIX plugin which exceed 1500 bytes - Switched Nginx signature to binary format - Changed the way how we sign key for Ubuntu and Debian for Nginx - Added explicit checks that repos work on Debian platforms - Added logic to verify that MongoDB repo works fine on Ubuntu and Debian - Added explicit check that FastNetMon and Grafana repos fro Debian and Ubuntu work fine before installing anything from them - Added logic to check that FastNetMon repo works before installing from it - Added logic to explicitly check that Nginx repo works - Finished logic to set password in Grafana and for Nginx http auth in same time - Moved to new logic which just replicates password of Grafana user on Nginx auth as old scheme was broken around Grafana 11 and we weren't able to pin point issue - Added logic to pass IPv6 address in Netflow and IPFIX plugin. Also improve logic to use IPv6 address as is in pcap readers - Deprecated visual stack for Ubuntu 16.04 because Clickhouse is not working on it - Switched MongoDB to FerretDB for Ubuntu 16.04 - Switched to use FerretDB on Debian and Ubuntu and RedHat machines without AVX or when old CPU is forced via CLI - Added per protocol counters for asn\_counters\_v4 and asn\_counters\_v6 - Added logic to respect unit passed to total\_traffic\_counters using GET query bandwidth\_unit set to bps - Added logic to pass unit to FNM internal API - Added installer flag to install only FerretDB - Added logic to start GoBGP daemon to eliminate errors like context deadline exceeded in Panel - Added logic to export per protocol counters for network counters and per interface counters endpoints - Added per protocol counters for networks and interfaces - Unified networks\_counters for IPv6 per network counters - Ported ASN counters to new per protocol counters logic - Added per protocol counters for ASNs and for networks for internal API - Added optional capability to use TTL for Flow spec attack detection - Added proxy\_set\_header for Grafana to address origin not allowed issue - Introduced option to calculate speed in parallel. Please note that it performs best if you have ban disabled - Added configuration options parallel\_speed\_calculation and parallel\_speed\_calculation\_threads - Implemented previously missing logic for flow\_spec\_ignore\_do\_not\_fragment\_flag - Changed permissions for systemd unit files for CentOS family from 755 to 644 as RHEL 8 does not like it: Configuration file /usr/lib/systemd/system/fastnetmon.service is marked executable. Please remove executable permission bits. Proceeding anyway - Added flows\_per\_second sorter for Partner integration - Added FerretDB support for logic to import community configuration - Added logic to use Nginx repository from Ubuntu 22.04 Jammy for Ubuntu 24.04 as we do not have official one yet - Added Ubuntu 24.04 support to installer See this release on [GitHub](https://github.com/FastNetMon/fastnetmon-advanced-releases/releases/tag/v2.0.366) **Categories:** Releases **Tags:** release, releases --- ### [FastNetMon Advanced 2.0.363](https://fastnetmon.com/2024/03/26/fastnetmon-advanced-2-0-363/) **Published:** March 26, 2024 **Author:** FastNetMon **Content:** The version update 2.0.363 is packed with many requested updates from our users. We migrated from Patricia tree to a new lookup\_tree\_128bit\_t and implemented full support for gobgp\_next\_hop\_host\_ipv6 and gobgp\_next\_hop\_subnet\_ipv6. We've also added logic to provide additional BGP communities on a hostgroup basis and unified various functions and types for improved efficiency. We've also introduced an API endpoint to reload BGP settings without a FastNetMon restart. And much more! Read the full list of updates below. Changes: - Migrated from Patricia tree with manual memory management to new lookup\_tree\_128bit\_t - Implemented complete support for gobgp\_next\_hop\_host\_ipv6 and gobgp\_next\_hop\_subnet\_ipv6 which allow settings next top for per host and per network announces independently - Added logic to provide additional BGP communities on hostgorup basis via: bgp\_communities\_subnet\_ipv6 and bgp\_communities\_host\_ipv6 hostgroup options - Added logic to provide additional BGP communities on hostgorup basis via: bgp\_communities\_subnet\_ipv4 and bgp\_communities\_host\_ipv4 hostgroup options - Eliminated parent\_host\_group as individual field - Renamed ban\_settings\_t to hostgroup\_t - Added ban\_settings\_t to attack\_details\_t - Added clickhouse\_table\_name as configuration option for traffic\_db - Added clickhouse\_database\_name as configuration option for traffic\_db - Extracted all configuration values for traffic\_db into separate class - Add per protocol detailed counters for host\_counters\_per\_hostgroup\_v4 and host\_counters\_per\_hostgroup\_v6 - Add per protocol counters for API mode of sudo fcli show remote\_host\_counters - Added per protocol counters for API mode of sudo fcli show host\_counters\_v6 - Added per protocol counters for sudo fcli show host\_counters in API mode - Unified function to return metrics for GetHostCountersRemote, GetHostCountersV4, GetHostCountersV6 - Unified types HostCounterRemote, HostCounterV6 to HostCounter - Added API endpoint sudo fcli set reload\_bgp to reload BGP settings without FastNetMon restart - Extracted read\_bgp\_configuration from fastnetmon\_configuration\_parser - Breaking change for logic used to check if BGP Flow Spec is enabled. Now to enable it you just need to set flag gobgp\_flow\_spec\_announces. We removed logic which required presence of at least one BGP peer with BGP Flow Spec enabled - Increased default MongoDB timeout for retrieval of hostgroups\_max\_talkers, hostgroup\_traffic\_stats, attack\_traffic\_stats to 96 seconds and added option to independently control it from configuration /etc/fastnetmon/fastnetmon.conf using option mongodb\_timeout\_heavy - Switched all the code to use only Patricia wrappers for IPv4 lookups - Improved design of ip\_lookup\_tree to hide private members - Added method lookup\_network() for ip\_lookup\_tree and covered by tests - Migrated lookup\_ip\_in\_integer\_form\_inpatricia\_and\_return\_subnet\_if\_found to lookup\_tree\_ipv4.lookup\_network\_which\_includes\_ip - Added new IP lookup method lookup\_network\_which\_includes\_ip and added tests for lookup\_ip - Moved GoBGP configuration generation into separate library - Split one large definition of all our configuration structures in a well defined isolated classes - Moved gobgp configuration generation to gobgp\_actions - Split fastnetmon\_configuration\_structures to bunch of independent files - Split logic to generate configuration structures and readers to two different scripts - Reworked logic to init networks\_whitelist\_remote by adding strict input data validation and avoid potential crashes when IPv6 prefix specified - Reworked Patricia test to avoid using deprecated function - Split ip\_lookup\_tree\_with\_payload to ip\_lookup\_tree\_with\_payload and ip\_lookup\_tree\_with\_dynamically\_allocated\_payload to provide more clarity about interfaces we use - Extracted IP lookup logic with payload to library ip\_lookup\_tree\_with\_payload.hpp **Categories:** Releases **Tags:** release, releases --- ### [FastNetMon Advanced 2.0.361](https://fastnetmon.com/2024/03/04/fastnetmon-advanced-2-0-361/) **Published:** March 4, 2024 **Author:** FastNetMon **Content:** In our latest release, we've made significant enhancements to improve efficiency and user control. We've enabled netflow\_ipfix\_inline and netflow\_v9\_lite support by default, and added the option for custom password setting via the installer flag reset\_visual\_passwords. We've also implemented complete logic for BGP Flow Spec redirect action and improved its rate and discard encoding. Additionally, we've introduced logic to calculate TCP, UDP, ICMP, and other flows per second for each host individually, and migrated flow tracking structure to std::unordered\_map for faster performance. See the full list of changes below! Changes: - Added logic to create stub config file for gobgp from installer - Enabled netflow\_ipfix\_inline by default and removed configuration option - Enabled netflow\_v9\_lite support by default and removed configuration option netflow\_v9\_lite - Exposed average\_calculation\_time as system\_counter as we want to see it all the time - Added option for installer flag reset\_visual\_passwords to set custom password passed via password flag - Implemented complete logic for BGP Flow Spec redirect action - Improved BGP Flow spec rate and discard encoding - Added redirect\_as and redirect\_value to action section - Added redirect and mark actions for flow spec logic - Added 4 byte encoding of sampler id in Netflow v9 used by Huawei - Reworked flow tracking table cleanup logic - Reworked global flow counters and introduced counter for flow calculation logic duration - Extracted flow calculation speed logic to separate function - Introduced logic to calculate tcp, udp, icmp and other flows per second for each host individually - Migrated flow tracking structure from std::map to std::unordered\_map because it's 2-10 times faster. - Extracted flow callback to be standard function - Made internal tracking variables for flow tracking logic external to reduce lambda complexity - Removed checks if connection tracking is enabled from lambda as we do checks outside **Categories:** Releases **Tags:** release, releases --- ### [FastNetMon Advanced 2.0.359](https://fastnetmon.com/2024/02/09/fastnetmon-advanced-2-0-359/) **Published:** February 9, 2024 **Author:** FastNetMon **Content:** Our latest release introduces several enhancements and fixes. We've added support for IPFIX UDP and TCP port encoding used by AMD Pensando, and extracted Netflow v5, v9, and IPFIX into separate modules. We've also fixed a bug with IPFIX sampling rate persistence. New features include support for multiple flows per packet for IPFIX inline monitoring services used by Juniper PTX, and logic to strip up nested vlans. We've also reworked Mikrotik integration to allow multiple devices and added complete support for VyOS route management. Additionally, we've added options to override prefix to ASN lookup logic and to control how long we wait for a bucket to receive traffic. Full details below. Changes: - Added support for IPFIX IPFIX\_UDP\_SOURCE\_PORT and IPFIX\_UDP\_DESTINATION\_PORT encoding used by AMD Pensando - Added support for IPFIX IPFIX\_TCP\_SOURCE\_PORT and IPFIX\_TCP\_DESTINATION\_PORT encoding used by AMD Pensando - Extracted Netflow v5, v9 and IPFIX into separate modules - Fixed bug with IPFIX sampling rate persistence which prevented us from storing it correctly to disk - Added logic to remove IPFIX and Netflow v9 sampling between upgrades - Added support for multiple flows per packet for IPFIX inline monitoring services used by Juniper PTX - Added logic to strip up nested vlans. We can strip 1, 2 or 3 nested vlans - Added logic to support two byte variable field encoding in inline monitoring services used by Juniper PTX - Added counter ipfix\_inline\_encoding\_error to track inline encoding errors - Added logic to export per interface counters to Clickhouse table interface\_metrics - Added logic to export system\_counetrs to Clickhouse table system\_metrics - Reworked Mikrotik integration to allow multiple devices and encode username and login in URL - Complete support for VyOS route management - Added logic to extract flags ip\_more\_fragments and ip\_fragment\_offset for raw packet payload in IPFIX / Netflow traffic telemetry - Added option to override prefix to ASN lookup logic using prefix\_asn\_mapping\_ipv4\_user.json and prefix\_asn\_mapping\_ipv6\_user.json - Added logic to export per protocol total counters - Added schema to generate per protocol total metrics - Reduced time to wait for bucket to receive traffic to 60 seconds from 120 - Added configuration option bucket\_traffic\_collection\_timeout to control how long we can wait for bucket to receive traffic - Added logic to print status of IPv4 and IPv4 attacks to syslog for ban\_status\_updates capability - Added configuration option notify\_script\_attack\_status\_updates to report all active attacks **Categories:** Releases **Tags:** release, releases --- ### [BGP Flow Spec for DDoS Mitigation](https://fastnetmon.com/2025/02/10/bgp-flow-spec-for-ddos-mitigation/) **Published:** February 10, 2025 **Author:** FastNetMon **Content:** ## Introduction to BGP Flow Spec The frequency and scale of DDoS attacks are continuing to rise. Incidents involving hundreds of gigabits are becoming increasingly routine, and organisations face severe threats to their network infrastructures. BGP Flow Spec has become an essential tool for combating large volumetric attacks. Using BGP to propagate detailed traffic filtering rules throughout networks rapidly, BGP Flow Spec facilitates the real-time detection and blocking of malicious traffic based on specific criteria such as source/destination IP, port numbers, protocol type, and packet length. BGP Flow Spec serves as an initial line of defense against volumetric DDoS attacks, and, when combined with accurate and fast detection systems, it greatly improves the coordination to effectively mitigate these threats. In this article, we lay out everything you need to know about BGP Flow Spec, and illustrate step-by-step how it works for DDoS mitigation. ## What is BGP Flow Spec? BGP Flow Spec is an extension to BGP (Border Gateway Protocol) that allows for the propagation of traffic flow specification rules. BGP Flow Spec introduces a set of enhancements to the standard BGP features to support the rapid distribution of traffic filtering and rate-limiting rules across the network. This capability is especially useful for preemptive traffic management, and therefore mitigating DDoS attacks. In other words, Flow Spec enables you to proactively deploy mitigation rules in real time when a DDoS attack is observed. ## Brief History from RTBH to BGP Flow Spec Historically, network administrators relied on techniques like Remote Triggered Black Hole (RTBH) filtering to mitigate DDoS attacks. RTBH works by directing traffic destined for an attacked host to a null route, effectively dropping the traffic before it can consume network resources. However, RTBH is somewhat blunt as it blocks all traffic to the targeted host, not just the malicious traffic. As a more refined alternative, BGP Flow Spec was developed to allow for detailed specification of traffic flows to be blocked or redirected, without impacting legitimate traffic. This specificity is achieved through the use of multiple network layer and transport layer attributes to define flow specifications. ## DDoS Mitigation Using BGP Flow Spec - full illustration BGP Flow Spec works for DDoS mitigation by enabling precise control over traffic flows. We will walk you through how this works in practice and illustrate the traffic flows from the beginning of a DDoS attack to the post-mitigated state. First, let’s start with the complete picture, and then we will break it down step by step: ![](https://fastnetmon.com/wp-content/uploads/2025/02/BGP-Flowspec-explained-full-animation.gif)Now, let’s start from the beginning. First, we can see how the networks operate in a normal state before the attack: ![](https://fastnetmon.com/wp-content/uploads/2025/02/BGPFlowSpec-step1-legitimate-traffic.gif)We have legitimate network traffic coming from multiple sources. In this case, the victim of the attack is pictured on the left side of the illustration. As usual, the attackers are targeting the “eyeballs”, intending to cause service disruption to the users. Let’s observe the attack unfolding: ![](https://fastnetmon.com/wp-content/uploads/2025/02/BGPFlowSpec-step2-DDoSattack.gif)The hacker on the right side of the illustration initiates the attack and starts sending a high volume of traffic to the network. The network is under distress, but the source of the traffic can be hard to identify as the hacker is imitating legitimate internet traffic via a botnet. The hacker can send hundreds of gigabits of traffic in a matter of seconds, and therefore acting fast is crucial. Now, let’s observe how this attack can be mitigated with BGP Flow Spec: ![](https://fastnetmon.com/wp-content/uploads/2025/02/BGPFlowSpec-step3-Analysingtraffictelemetry.gif)The Flow Spec clients of the service provider send traffic telemetry for analysis, and the network operators can create rules that specify detailed conditions under which traffic should be rate-limited or redirected. These rules are then distributed across the network in real-time, allowing for immediate response to emerging threats. In this illustration, the network operator is using FastNetMon to automatically analyse the telemetry. Next, let’s observe how the attack is mitigated: ![](https://fastnetmon.com/wp-content/uploads/2025/02/BGPFlowSpec-step4-SendingBGPinstructions.gif)Here, we can observe FastNetMon sending BGP instructions to the Flow Spec clients to filter the malicious traffic. The protocol supports various actions such as traffic rate limiting, redirection, and filtering based on numerous attributes like IP addresses, ports, and packet types. This granularity ensures that only malicious traffic is mitigated, preserving normal network operations. The malicious traffic is detected in seconds, and the rules are deployed in real-time. ## Vendor Support The effectiveness of BGP Flow Spec in real-world applications depends significantly on vendor support. Major network equipment vendors including Cisco, Juniper, Huawei, Nokia, and Arista have implemented BGP Flow Spec in their devices, allowing network operators to [deploy Flow Spec](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-bgp-flow-spec-configuration/) rules directly onto routers and switches. These implementations vary in terms of the specific features and capabilities supported, and understanding these differences is crucial for network engineers when planning and deploying BGP Flow Spec solutions. ## Conclusion BGP Flow Spec represents a significant advancement in network traffic management and DDoS mitigation. It provides the capability to specify detailed traffic rules and rapidly distribute these rules across the network. BGP Flow Spec offers a powerful protocol to protect network resources from the growing threat of DDoS attacks, and FastNetMon provides the[toolset](https://fastnetmon.com/flowspec-ddos-mitigation/) for network operators to set up and manage their Flow Spec implementation. --- ## About FastNetMon FastNetMon delivers versatile DDoS detection software for companies at any scale. With extensive experience in the telecom, mobile, and cloud computing industries, we take pride in preventing DDoS attacks and protecting our customers’ networks to the highest standard. Contact us at <sales@fastnetmon.com> **Categories:** FastNetMon Blog **Tags:** BGP Flow Spec --- ### [How FastNetMon can reduce the cost of cloud based DDoS scrubbing](https://fastnetmon.com/2023/10/24/how-fastnetmon-can-reduce-the-cost-of-cloud-based-ddos-scrubbing/) **Published:** October 24, 2023 **Author:** FastNetMon **Content:** The increased severity and sophistication of DDoS attacks means that network security administrators need a collection of tools to mitigate risk. One effective option to reduce malicious traffic is the use of a cloud-based DDoS scrubbing service. But under the pay-as-you-use cloud resource billing model, DDoS scrubbing can be extremely expensive. Your line of business systems may be better protected – but you still face a large bill for managing and mitigating an attack. ## How do you scrub? There are two general approaches to DDoS scrubbing which are defined by how a business manages incoming network traffic. The first option is to route all incoming traffic via a scrubbing center, so that any DDoS attack is detected and blocked automatically. Although extremely effective, this approach is also extremely expensive, placing it well outside the budget of all but the largest enterprises. The second option is to maintain a DDoS detection system at the perimeter. When an attack is identified, malicious traffic is diverted to a remote service for scrubbing, helping to maintain satisfactory network conditions for legitimate users. This tends to be more affordable because the scrubbing system is only engaged as required – which is why most organizations choose this approach. ## The challenges of on-demand DDoS scrubbing On-demand DDoS scrubbing has two significant concerns – traffic identification and speed of response. #### **Filtering the right traffic** Because you are being billed for the traffic to be scrubbed, you need to be sure that you are only diverting the most suspicious activities. Yes, you want to ensure that ‘bad’ traffic is kept away from your assets, but you also want to limit the amount of legitimate traffic that is sent to the scrubber so that you can better contain the cost of the attack. #### **Rapid DDoS response** At the same time, you need to be sure that your detection system is capable of spotting and re-routing malicious traffic very quickly. The faster you can react, the smaller the impact on your network load. ## How can FastNetMon help? FastNetMon is a vendor-neutral tool that works with all existing network equipment vendors, DDoS Mitigation systems, and scrubbing centers. It is easy to set up on your network and requires minimal configuration. The system combines DDoS detection and mitigation capabilities with scrubbing center automation for enhanced protection. As a vendor neutral solution, FastNetMon supports a variety of methods to redirect attack traffic to external scrubbing centers for scrubbing, including: - BGP Unicast protocol to trigger traffic redirection to Cloud based scrubbing centers - BGP Flow Spec protocol, RFC 5575 to trigger traffic diversion to in house deployment of cloud scrubbing center - Provider specific API based integrations - Custom integration which uses callback script in any programming language, in this case FastNetMon supplies all needed information about detected attack in JSON format and script implementer decides what to do As exampled of provider specific API based integration we offer we feature following providers: - [F5](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-integration-with-f5-silverline-ddos-scrubbing-centre/) - [Cloudflare Magic transit](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-integration-with-cloudflare-magic-transit-scrubbing-centre/) - [Other scrubbings](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-and-ddos-scrubbing-centers-integration/) ## So where do the cost savings come from? First, FastNetMon fits neatly into your cloud-based DDoS scrubbing strategy. Reliable and responsive, you benefit from: - Automatic and near-instantaneous attack detection with zero human interaction. - Faster, automated redirection of attack traffic to the scrubbing centre. - Mitigating malicious traffic with a customizable, rule-based configuration for automated blocking - Reducing the latency between your network and scrubbing centers - Reducing network security costs, freeing up resources to pay for scrubbing center costs - Eliminating inefficiencies present in conventional BGP redirection techniques. Using FastNetMon and cloud-based DDoS scrubbing, attack traffic is filtered on arrival – removing unwanted traffic from your network and reducing attack detection latency. This minimizes the negative impact an attack can have on your network performance and reduces associated costs. Legitimate traffic can also be returned to you after it has been filtered and cleaned. ## How does FastNetMon deliver these benefits? Traditional BGP traffic diversion can suffer from delays during a DDoS attack, mainly because it has to announce propagation across the network components. FastNetMon eliminates this delay by automating and accelerating your response to the attack and minimizing its effects. FastNetMon can automatically switch a network of any size, redirecting traffic to DDoS scrubbing centers. The most popular and recommended redirection method is to switch network traffic by advertising a /24 IP block to the scrubbing center but keep the parent prefix for this /24 block with your normal ISP. Because of BGP protocol selection logic, every network across the planet will select this identified path over /24 to the scrubbing center instead of following the normal route. Note that IPv6 network boundaries might be different. In this case, you can set up the length of the covering network size using FastNetMon for specific /48 announcements. FastNetMon has complete support for BGP unicast protocol and includes our own BGP daemon. After detecting the attack, FastNetMon will automatically determine which network contains that host. Based on that information, FastNetMon triggers an BGP announcement and redirects the affected host’s traffic to a scrubbing center. In turn, the scrubbing center should start scrubbing malicious traffic as soon as it receives the announcement. FastNetMon can also run a script or send the announcement to your own network routers. This will remove the affected host with the attacked prefix on your network and send malicious traffic from your network to the scrubbing center. And remember – this whole process takes just two seconds. Find out more about our integrations with top-tier scrubbing centres: [Path.net](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-integration-with-path-net-ddos-scrubbing-centre/), [Cloudflare Magic](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-integration-with-cloudflare-magic-transit-scrubbing-centre/) and [F5](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-integration-with-f5-silverline-ddos-scrubbing-centre/). ## Learn more Automated attack detection and traffic redirection coupled with lightning-fast response times make FastNetMon an important tool in your cybersecurity defenses. And thanks to its exceptional detection capabilities, FastNetMon can reduce cloud resource demand – and costs. Ready to learn more? [Try FastNetMon free for a month](https://fastnetmon.com/trial/). **Categories:** FastNetMon Blog **Tags:** Scrubbing --- ### [Virgil Truica joins the FastNetMon team as Growth & Partnerships Lead](https://fastnetmon.com/2024/11/27/virgil-truica-joins-the-fastnetmon-team-as-growth-partnerships-lead/) **Published:** November 27, 2024 **Author:** FastNetMon **Content:** ## **Welcome to the FastNetMon, Virgil Truica!** We are delighted to welcome Virgil Truica to the FastNetMon team. Virgil brings with him over 16 years of experience in the International Telecom industry, with a particular focus on DDoS solutions, network security, and enterprise solutions. Virgil's extensive knowledge and experience will be instrumental in helping our customers and partners navigate the complexities of network security. His ability to understand the threat landscape and recommend the best defence strategies will be invaluable in helping our clients make informed decisions. In addition, Virgil's strong connections within the industry will help us to strengthen our partnerships and collaborations further. His passion for network security aligns perfectly with our commitment to staying at the forefront of the DDoS solution landscape. We are confident that Virgil's addition to our team will enhance our ability to provide our customers and partners the highest level of service. > *“I’ve followed FastNetMon’s journey from the beginning and have always admired how the company has evolved to become a leader in the DDoS security space by actively listening to the customers and incorporating feedback. Being part of the FastNetMon community channels over the years, I’ve witnessed the passion and dedication that drives both the team and its users. I’m excited to now work alongside all of you, FastNetMon’s team and customers, to create efficient DDoS protection strategies that meet the unique needs of your networks. Together, we can continue making the internet a safer place.“* **Get in touch with Virgil:** Tel: +40742991619 Email: virgil@fastnetmon.com LinkedIn: https://www.linkedin.com/in/virgiltruica/ **Categories:** Press & Newsroom **Tags:** leadership announcements --- ### [Dutch hosting provider Argeweb battles week-long DDoS attack](https://fastnetmon.com/2025/04/14/dutch-hosting-provider-argeweb-battles-week-long-ddos-attack/) **Published:** April 14, 2025 **Author:** FastNetMon **Content:** Late March, a well-known Dutch web hosting provider, Argeweb, found itself under fire from a DDoS attack that spiralled into a week-long struggle to stay online. What started as a few complaints about slow-loading sites turned into widespread disruption as DNS servers were overwhelmed. The incident seemed like a simple technical issue, but after a few days of inconsistent service, the company confirmed the real cause is a sustained DDoS attack targeting its core infrastructure. **A tough week for users and engineers** We are used to DDoS attacks flooding systems with junk traffic until nothing legitimate can get through. However, this time the attackers kept changing tactics, forcing engineers to respond in real time while customers waited for services to return. Attempts to fix the issue worked briefly, only to be undone as new waves of traffic hit again. After several days of firefighting and coordination behind the scenes, things finally started to settle. By early April, the platform had stabilised, and additional defences were put in place to catch any renewed activity early. **DDoS attacks are rarely a one-time event** There are no allegations or claims of responsibility, but this isn’t the first time this provider has been hit by a DDoS attack, and it likely won’t be the last. The playbook is familiar: DNS servers go down, websites follow, and customer trust takes a hit. What has changed is the persistence. Attacks that used to last minutes now stretch into days, sometimes weeks. That’s why preparation matters - not just good infrastructure, but fast detection, clear communication, and enough breathing room to recover without disruption spreading. Read more about best practices of DDoS defence for hosting providers [here](https://fastnetmon.com/2025/04/03/ddos-defence-for-hosting-providers/). --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit <https://fastnetmon.com> **Categories:** FastNetMon Blog **Tags:** DDoS Attacks, DDoS News --- ### [DDoS, DoS, RDoS explained](https://fastnetmon.com/2025/04/16/ddos-dos-rdos-explained/) **Published:** April 16, 2025 **Author:** FastNetMon **Content:** ## What’s the difference between DoS, DDoS, RDoS, and how to prevent these cyberattacks? Not all cyberattacks are created equal. If you’ve ever heard terms like DoS, DDoS or RDoS and wondered what they mean, and why they keep showing up in the news, here’s a simple breakdown. **DoS: The digital jam-up** A Denial of Service (DoS) attack is like someone calling your landline over and over so no one else can reach you. It’s a one-device, one-target attack designed to flood a website or service with requests until it crashes. It can be annoying and disruptive, but relatively easy to spot and block. Due to the simple nature of the attack, these days DoS is often not considered a hugely serious threat in the cybersecurity space. However, there have been cases of very specific DoS attacks, where the hacker been able to take an entire system down by crafting a single packet to exploit a very precise vulnerability, such as a broken protocol rule or a buffer overflow. **DDoS: DoS, but with backup** A Distributed Denial of Service (DDoS) attack takes that same idea and scales it up. Instead of one computer, attackers use thousands of computers, or an army of hijacked devices, (usually called a botnet). It’s the digital version of a traffic jam with no exit. Harder to trace, harder to stop, and often causes longer outages. One of the earliest known denial-of-service attacks took place in 1996, when Panix — one of the oldest internet service providers in the world — was hit by a SYN flood. This type of attack overwhelmed its servers with half-open TCP connections, effectively knocking the service offline for several days. At the time, it was a wake-up call to the vulnerabilities of online infrastructure. Nearly three decades later, DoS and DDoS attacks have only grown more sophisticated and remain a serious threat. **RDoS: the threat before the storm** Ransom DoS (RDoS) adds blackmail into the mix. Technically, often identical to DDoS, the term RDoS refers to a situation where hackers send a ransom note demanding payment. Ransom is usually demanded in crypto, to prevent or stop a DDoS attack. Sometimes, the offenders start with a small test attack to find out the vulnerabilities of their target before turning up the heat. If the ransom isn’t paid, the attack continues and can keep going for days to an ends. In some cases, attackers pretend to be well-known cyber gangs to turn up the pressure. **What can you do to stop DoS DDoS and RDoS attacks?** These attacks are noisy, stressful, and unpredictable, however, they’re not unstoppable. The best defence is to prepare before it happens: know what parts of your system are vulnerable, have a response plan, and work with a provider who knows how to spot and stop these threats. Some of the defence strategies include [blackholing](https://fastnetmon.com/2024/12/07/bgp-blackhole-automation-for-ddos-mitigation/) the illegitimate traffic, using [DDoS traffic scrubbing centres](https://fastnetmon.com/ddos-scrubbing-centre-diversion/), or set up rules with [BGP Flow Spec protocol](https://fastnetmon.com/2025/02/10/bgp-flow-spec-for-ddos-mitigation/) in your network. Because whether it’s noise from one attacker or thousands, the goal is the same, and so is your best shot at staying online. --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit <https://fastnetmon.com> **Categories:** FastNetMon Blog **Tags:** basics --- ### [BreachForums seized again, but who’s behind it this time?​](https://fastnetmon.com/2025/04/16/breachforums-seized-again-but-whos-behind-it-this-time/) **Published:** April 16, 2025 **Author:** FastNetMon **Content:** The notorious cybercrime marketplace BreachForums has gone offline once more, but this time, no one’s quite sure who’s behind it. While some suspect another FBI takedown, a group calling itself the Dark Storm Team claims they launched a DDoS attack on the site ‘for fun.’ ​ Dark Storm Team is a pro-Palestinian hacktivist group known for targeting Israeli infrastructure, and it has recently expanded its activities. They’ve claimed responsibility for attacks on [X (formerly Twitter)](https://fastnetmon.com/2025/04/04/x-formerly-twitter-ddos-attack-fact-fiction/), Finland’s Central Bank, and Hungary’s Defence Ministry. The group also offers [DDoS-for-hire services](https://fastnetmon.com/2025/04/10/ddos-booters-and-ip-stressers-explained-by-experts/) and has been promoting its own cryptocurrency, DARKSTORM/SOL, raising concerns about potential financial motives behind their attacks. The FBI has officially seized previous versions of BreachForums in the past and did take down similar marketplaces like RaidForums and Nulled. But this time there’s no typical FBI splash page or clear takedown signature, only DNS disruption and speculation. Meanwhile, rumours are circulating about the arrest of ‘IntelBroker,’ a prominent figure associated with BreachForums, but nothing has been confirmed by law enforcement. While these claims circulated, others spotted a fake domain charging $250 in crypto for access to a ‘new’ version of the forum, a classic scam layered on top of the chaos. BreachForums has a history of being taken down and resurfacing. After the 2023 arrest of its founder, Conor Brian Fitzpatrick, the site was revived by other cybercriminals, including ShinyHunters and USDoD. Given this pattern, it’s likely that the forum, or a similar platform, will reappear.​ Even when major platforms like BreachForums go dark, it’s rarely the end of the story. More often than not, someone always picks up the pieces, unfortunately. --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit <https://fastnetmon.com> **Categories:** FastNetMon Blog **Tags:** DDoS News --- ### [How did DDoS begin? A short history of DDoS reviewed](https://fastnetmon.com/2025/04/23/how-did-ddos-begin-a-short-history-of-ddos-reviewed/) **Published:** April 23, 2025 **Author:** FastNetMon **Content:** ## Evolution of DDoS: From single PCs to Terabit floods Twenty‑five years ago a teenager with a dial‑up modem discovered he could knock Yahoo! offline by hammering it with junk traffic. Since then denial‑of‑service attacks have morphed into a multi‑billion‑pound headache that can rattle entire countries. Let’s trace that journey, chapter by chapter, to see how a nuisance became an industry—and what defenders have learned along the way. **When did denial‑of‑service attacks start?** Late‑1990s security mailing lists carried warnings about tools named Trinoo and Tribal Flood Network. They were simple scripts: compromise a handful of Unix boxes, point them at a victim, and watch the website vanish. The motive was bragging rights, nothing more sophisticated than pulling the plug on your mate’s games console. **How did worms and cheap bandwidth change the game?** Broadband replaced dial‑up in the early 2000s. Suddenly home users had megabits of upload capacity. At the same time worms such as Code Red and SQL Slammer spread autonomously, clogging networks and proving that you didn’t need an army of volunteers; malware could build one for you. Attack peaks jumped from kilobits to tens of gigabits per second. **Why did DDoS‑as‑a‑Service take off?** By 2006 underground forums began selling ‘IP stress tests’ for £10 a go. You paid in PayPal or bitcoin, picked a target, and the service did the damage. Reflection tricks, sending a small query to a public DNS or NTP server that bounced back a much larger reply, meant sellers could promise bigger floods without owning bigger botnets. And DDoS‑as‑a‑Service was born. **What made Mirai a turning point?** The Mirai malware swept through cheap internet cameras and routers in September 2016. Within weeks an estimated half‑million devices were under its control. One terabit‑per‑second blast at a major DNS provider took Spotify, Reddit and Twitter offline for hours. The message was clear: insecure IoT hardware had become a ready‑made army for hire. **Where are we today?** Cloud providers now report blocking attacks above 3 Tbps. Techniques grow ever more creative: - Flash floods – huge bursts lasting under ten minutes, hoping to outrun manual response. - Carpet‑bombing – small packets sprayed across every IP in a subnet, hiding the real target. - Multi‑vector shifts – switching protocols mid‑attack to dodge filters. Motives have widened too. Extortion letters demand bitcoin or services stay dark. Hacktivist collectives aim at banks and media outlets to push political messages. Some groups even sell ‘protest packages’ to anyone with a grievance and a wallet. **How do defenders keep up with DDoS attacks?** Experience shows that speed matters more than scale. Modern playbooks focus on: [Instant visibility](https://fastnetmon.com/traffic-visibility/) – flow telemetry or packet sampling flags an anomaly within seconds. Automation – [RTBH](https://fastnetmon.com/bgp-blackhole-automation/) or [Flow Spec routes](https://fastnetmon.com/flowspec-ddos-mitigation/) bad traffic into a digital bin before links fill up. [Cloud scrubbing](https://fastnetmon.com/ddos-scrubbing-centre-diversion/) – always‑on or on‑demand cleaning centres soak up multi‑terabit streams. Layered controls – rate limits, anycast DNS and application firewalls filter what slips through. Response time matters: industry studies show the average attack in 2024 lasted under five minutes. Manual action is rarely quick enough. **What might happen in the future?** AI‑guided botnets could analyse defences in real time and pivot faster than humans can click. Faster home links—fibre and 5G—hand attackers more raw ammunition. Tighter IoT rules may slow botnet growth, but billions of legacy gadgets will stay online for years. DDoS history mirrors the internet’s own: more users, more bandwidth, more automation, both good and bad. Understanding that timeline helps organisations plan for what’s next: not whether attacks will hit, but how quickly they can spot and stop them. --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit <https://fastnetmon.com> **Categories:** FastNetMon Blog **Tags:** basics --- ### [Massive Power Outage Hits Spain, Portugal, and Parts of France](https://fastnetmon.com/2025/04/28/massive-power-outage-hits-spain-portugal-and-parts-of-france/) **Published:** April 28, 2025 **Author:** FastNetMon **Content:** ## Speculation of a cyber attack and data centre vulnerability raises concerns amidst a blackout in southern Europe In a dramatic turn of events, a widespread power outage has left millions across Spain, Portugal, and parts of France in the dark. This blackout, which began on April 28, 2025, has disrupted daily life, halting operations at major airports, affecting telecommunications, and bringing public transportation to a standstill. As authorities scramble to restore power, questions are being raised about the vulnerabilities in the region's electric grid and the potential role of cyberattacks. According to reports from Euronews, the blackout affected the entire country of Portugal and large parts of Spain, including major cities like Madrid, Barcelona, and Valencia. The Spanish rail network was forced to shut down, and internet services across the Iberian Peninsula were severely impacted. Airports, including Madrid's Barajas International, experienced significant disruptions, further complicating the situation. The exact cause of the outage remains uncertain, but several factors are being considered. Domestic media have pointed to problems within the European electric grid as a potential source of the disruption. Additionally, a fire on Alaric Mountain in southwestern France, which damaged a high-voltage power line between Perpignan and eastern Narbonne, is being investigated as a contributing factor. Portuguese grid operator E-Redes attributed the outage to "a problem with the European electricity system" and implemented power cuts in specific areas to stabilise the network. Amidst these explanations, speculation has grown over the possibility of a cyberattack. The SUN reported fears of a geopolitical cyberattack, citing past incidents targeting European infrastructure. The Portuguese Ministry of Internal Administration has not ruled out this possibility, while Spain’s Cybersecurity Coordination Office has cautioned that it is still "too early" to draw any conclusions. The impact of the outage on the data centre sector remains unknown. Spain and Portugal have become hubs for data centre activity, with 156 operational data centres in Spain and 41 in Portugal. These facilities typically rely on diesel standby generators during outages, which can run for 24-48 hours depending on fuel availability. However, the prolonged nature of the blackout raises concerns about the resilience of these critical infrastructures. This incident highlights the fragility of modern infrastructure and the potential for single points of failure to cause widespread disruption. The complexity of our systems across power, communications and data infrastructures can obscure risks, making us vulnerable to unexpected events. The recent blackout serves as a reminder of the need for contingency planning to protect against both physical and cyber threats. As investigations continue, authorities are working to restore power gradually. Spanish grid operator Red Electrica has reported progress in recovering power in the north and south of the country, but full restoration is expected to take several hours. In the meantime, residents are advised to monitor official channels for updates and prepare for potential delays in accessing essential services. The events in Spain, Portugal, and France underscore the interconnectedness of modern infrastructure and the cascading effects of disruptions. As reliance on digital platforms and electric grids continues to grow, ensuring the security and resilience of these systems becomes increasingly important. --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** FastNetMon Blog **Tags:** DDoS News --- ### [Most infamous DDoS booter services - and user consequences](https://fastnetmon.com/2025/04/30/most-infamous-ddos-booter-services-and-user-consequences/) **Published:** April 30, 2025 **Author:** FastNetMon **Content:** ## Some of the largest IP booter services listed - and what happens if you use them Hiring a DDoS attack used to mean building a botnet or knowing someone who had. Booter services changed all that: pay a small fee, enter your target’s IP address, and a DDoS booter service does the rest. Schools, banks, gaming servers, nothing has been off-limits. Cheap prices and click-and-go dashboards have attracted countless first-time offenders into cybercrime and caused real-world outages that cost companies millions. In this article, we will list some of the infamous DDoS booter services and explain what the real-world consequences are for anyone employing them. **How to hire an IP booter?** A booter site sells ‘attack time’ much like a vending machine sells snacks, with the difference that buying a DDoS attack is a crime in most countries. The buyer enters the victim’s IP address, pays a fee, and presses ‘launch.’ The service then unleashes a surge of junk traffic from hijacked computers around the world. Legitimate requests can’t get through, so websites, payment gateways or game servers freeze until the flood stops or is filtered out. If you are new to this topic, read [our previous article](https://fastnetmon.com/2025/04/10/ddos-booters-and-ip-stressers-explained-by-experts/) explaining IP booters and stressers in detail. **What are some of the well-known IP booter services?** Here is a short list of the most notorious DDoS booter services: - **Webstresser** – once the market leader, linked to four million attacks before its 2018 takedown. - **Quantum** – advertised “instant power”, later cited by the FBI for 50,000 attacks. - **ZDstresser**, **OrbitalStress**, **StarkStresser** – some of the largest of the 27 sites seized in late-2024’s Operation PowerOFF sweep. - **DigitalStress**, **Stresser.tech**, **RoyalStresser** – individual brands whose admins have since pleaded guilty or faced trial. Each closure followed the same pattern: domains seized, servers imaged, and user lists passed to law enforcement for further investigation. **What is Operation PowerOFF?** Over the past few years, police have been busy taking the worst offenders offline. As cybercrime often expands over national borders, law enforcement came up with a specialised international unit to combat the issue - Operation PowerOFF. Launched in 2018 and very much active to date, Operation PowerOFF brings together the FBI, Europol, the UK’s NCA, Dutch and German cybercrime units and a dozen others. Cloud providers and payment firms tip off police when a new DDoS booter pops up; detectives trace hosting, freeze cryptocurrency wallets and arrest the operators. The most recent phase pulled 27 sites in one night and led to arrests in France, Germany, the US and the Netherlands. Hundreds of paying customers have since received warning letters, and some may face prosecution. **What happens if you use an IP booter?** If you are reading this article and considering DDoS for hire via an IP booter service, our message is very clear: do not do it. Conducting a DDoS attack is a cybercrime, punishable by law in most countries. For example, many people who bought ‘ten-minute stress tests’ from the now-seized websites were teenagers testing game servers. Even if the sites guarantee anonymity, law enforcement will be able to trace individual users who paid for booter services. Police say ignorance is no defence: using a booter is an unauthorised attack, and you are responsible for it. Past cases show penalties ranging from cautions and equipment confiscation to full criminal convictions. It is also wise to consider that employers and universities now run background checks that spot these records. **How to stay protected from DDoS-for-hire?** Booter services may be dropping like flies, yet copy-cats appear just as fast. Organisations should treat low-cost DDoS floods as part of everyday threat modelling: - A layered defence combining [on-premise mitigation](https://fastnetmon.com/) with [cloud scrubbing ](https://fastnetmon.com/ddos-scrubbing-centre-diversion/)keeps bandwidth free for legitimate users. - [Always-on monitoring](https://fastnetmon.com/traffic-visibility/) spots sudden traffic spikes before they snowball. - Automated blocking: for example, [RTBH](https://fastnetmon.com/bgp-blackhole-automation/) or [FlowSpec rules](https://fastnetmon.com/flowspec-ddos-mitigation/) correctly configured will mitigate most IP booter attacks. --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit <https://fastnetmon.com> **Categories:** FastNetMon Blog **Tags:** basics --- ### [DDoS in geopolitics: when network traffic becomes a digital weapon](https://fastnetmon.com/2025/05/19/ddos-in-geopolitics-when-network-traffic-becomes-a-digital-weapon/) **Published:** May 19, 2025 **Author:** FastNetMon **Content:** ### **The rise of DDoS in global conflicts** With societies increasingly dependent on online services, the front lines of geopolitical conflict are no longer limited to physical borders. Increasingly, state-sponsored actors and politically motivated groups are turning to cyber tactics to assert influence, sow disruption, or make public statements. Among these tactics, Distributed Denial-of-Service (DDoS) attacks have emerged as a low-cost, high-impact tool — capable of overwhelming critical infrastructure with malicious traffic in a matter of seconds. DDoS attacks are not new, but their role in geopolitical tensions has grown significantly. Unlike espionage-focused intrusions that seek to steal data or disrupt covertly, DDoS campaigns are often loud, visible, and immediate. They target the availability of online services — government portals, news outlets, financial systems, and public utilities — undermining trust and creating confusion during politically sensitive moments. According to industry reports, over 8.9 million DDoS attacks were recorded in the second half of 2024 alone — a 30% increase compared to the same period in 2023. Spikes in attack volume frequently align with elections, policy announcements, and civil unrest, indicating a growing use of these attacks as tools of influence rather than financial gain. The simplicity and effectiveness of DDoS attacks make them especially appealing in an era where global tensions play out in the digital arena. They require no insider access, no data exfiltration, and no physical presence — just a flood of traffic, often rented on demand, to bring public-facing services to a halt. ### **Why are DDoS attacks more dangerous than ever?** Distributed Denial-of-Service (DDoS) attacks have become a preferred method of disruption for a simple reason: they’re cheap, fast, and highly visible. With just a small investment, attackers can rent powerful tools online and launch an attack within minutes. These traffic floods don’t need to break into a system or steal data — they just need to overwhelm it, making the service unavailable to users. And when the timing is right — during an election, a budget announcement, or a political crisis — the impact is amplified by media attention and public reaction. One of the biggest challenges is that the end users often don’t realise it is an attack at all. When a hospital portal stalls or a public transport app fails, users blame the service provider, not the invisible attacker. This creates an instant loss of trust. In critical sectors like healthcare, finance, or government, even a few minutes of downtime can have serious consequences. The longer the attack, the more public uncertainty it creates. The attackers are aware of this. For example, India’s presidential website was hit with [a 19-hour DDoS in May 2024](https://fastnetmon.com/2025/05/15/india-pakistan-conflict-evokes-a-wave-of-cross-boarder-ddos-attacks/). In the Netherlands, more than [50 public services were taken offline over a week-long campaign](https://fastnetmon.com/2025/05/08/50-dutch-public-services-flooded-by-noname05716-in-one-week-as-a-punishment/), reportedly as political retaliation. These prolonged disruptions show how attackers are pushing the limits — and how unprepared many services still are. ### **How are DDoS attackers getting more advanced?** DDoS attacks used to be fairly basic: send a lot of traffic, crash a website, and move on. But that’s no longer the case. Attackers are becoming more sophisticated, using smarter tools and longer attack windows to cause greater disruption. Instead of relying on just one traffic source, today’s attackers use botnets — large networks of hijacked devices like home routers, webcams, or IoT gadgets — to send huge volumes of traffic from all over the world. These devices are often poorly secured, making them easy to control and hard to trace. Attackers also use automation and machine learning to make their traffic harder to block. Scripts can now bypass CAPTCHAs, change packet patterns in real time, and respond to mitigation efforts mid-attack. This makes it much more difficult for defenders to detect and stop the traffic effectively. Even more worrying is how easy it’s become to launch an attack. So-called [“booter” or “stresser” services](https://fastnetmon.com/2025/04/10/ddos-booters-and-ip-stressers-explained-by-experts/) offer user-friendly dashboards where customers can choose a target, set an attack time, and pay with cryptocurrency. Some of these services even suggest targets based on news trends, helping attackers time their hits for maximum impact. This evolution means DDoS is no longer just a nuisance — it’s a real threat to critical services. Hospitals, banks, public transport, and government websites all rely on constant uptime. A few minutes of downtime can delay care, block payments, or stop emergency communications. And when these services go dark during tense political moments, public trust takes a hit — exactly what politically motivated attackers want. ### **How to build a resilient DDoS defence plan?** With DDoS attacks becoming more common — and more targeted — having a defence plan is no longer optional. It’s a key part of digital resilience, especially for public services and critical infrastructure. The good news? A strong plan doesn’t have to be complex. It just needs to be proactive, layered, and suit the needs of your network. Here's what a resilient defence stack looks like: #### **• Real-time monitoring** The sooner you detect unusual traffic patterns, the faster you can respond. [Continuous and automated monitoring of your network](https://fastnetmon.com/traffic-visibility/) helps you spot spikes, anomalies, or early signs of an attack before they impact services. FastNetMon, for example, identifies threats within seconds and alerts you immediately when things get out of normal parameters. #### **• Automated mitigation with intelligent controls** Once an attack is detected, fast mitigation is critical. Set [rate limits](https://fastnetmon.com/docs-fnm-advanced/automated-baseline-calculation-with-fastnetmon-advanced/) to throttle abusive traffic at the source. Use [BGP FlowSpec](https://fastnetmon.com/flowspec-ddos-mitigation/) to define fine-grained filtering rules and apply them across your network dynamically. In more severe cases, [Remote Triggered Black Hole (RTBH)](https://fastnetmon.com/bgp-blackhole-automation/) filtering can drop malicious traffic upstream, keeping it off your infrastructure entirely. #### **• Blocklist-based filtering** [Blocklists help filter known malicious IPs](https://fastnetmon.com/blocklist-filtering/) or networks before they cause damage. FastNetMon supports automatic updates of community-driven and commercial blocklists, enabling you to drop bad traffic at the edge — often before it even enters your environment. #### **• Scrubbing centre automation** In some cases, [redirecting traffic through a scrubbing centre](https://fastnetmon.com/ddos-scrubbing-centre-diversion/) is the best way to mitigate a DDoS attack. Automating this process ensures that clean traffic is routed back to your systems quickly, without manual delays. The goal is seamless mitigation that preserves user experience even during high-volume attacks. In modern conflict, a flood of traffic can cause as much disruption as a data breach — or more. Protecting uptime isn’t just about IT anymore. It’s about maintaining trust, stability, and public confidence during the moments that matter most. --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit <https://fastnetmon.com> **Categories:** FastNetMon Blog **Tags:** political --- ### [Building a Multi-Layered DDoS Defense Architecture](https://fastnetmon.com/2025/05/28/building-a-multi-layered-ddos-defense-architecture/) **Published:** May 28, 2025 **Author:** FastNetMon **Content:** ## Effective DDoS Mitigation Strategies: Building a Tiered Defence System DDoS attacks still remain one of the most persistent and disruptive cyber threats in today’s internet infrastructure. From volumetric floods to subtle, low-rate protocol attacks, the scale and variety of DDoS techniques demand more than a one-size-fits-all solution. That’s why resilient organisations rely on a **multi-layered DDoS defence architecture** — a tiered approach that combines real-time detection, dynamic mitigation, and visibility across the entire network stack. Let’s explore what this kind of architecture looks like in practice and how each layer contributes to faster, more effective DDoS defence. ### **Layer 1: Network-Level Detection (The Front Line)** At the heart of any strong DDoS defence is the ability to **spot an attack early and accurately**. This is where [network telemetry](https://www.youtube.com/watch?v=6SfT1h9OpTE) becomes invaluable. Modern detection starts by ingesting data from routers and switches using protocols such as: - NetFlow - sFlow - IPFIX These flow-based technologies provide a near real-time view of who’s talking to whom on your network — and at what volume. When traffic patterns deviate from baselines (such as spikes in DNS or NTP traffic, or a sudden flood of SYN packets), a properly tuned system can detect anomalies within seconds. **Best practice: Use [threshold-based detection](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-threshold-types/) (per IP, per subnet, or per customer group) combined with traffic classification to pinpoint suspicious flows — without false positives. ### **Layer 2: Automated Mitigation via BGP** Once an attack is detected, time is critical. A well-architected system can move from alert to action in milliseconds — by dynamically modifying network behaviour using **Border Gateway Protocol (BGP)**. Two core techniques are widely used: - [**BGP Blackholing**](https://fastnetmon.com/2024/12/07/bgp-blackhole-automation-for-ddos-mitigation/)**: Temporarily withdraws the route to the attacked IP, dropping traffic upstream. Effective for stopping volumetric floods before they hit internal infrastructure. - [**BGP FlowSpec**](https://fastnetmon.com/2025/02/10/bgp-flow-spec-for-ddos-mitigation/)**: Allows for **fine-grained traffic filtering**, blocking only the attack traffic while keeping legitimate traffic flowing. Useful for precision response to targeted protocol or port-based attacks. **Best practice: [Automate](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-bgp-blackhole-automation/) mitigation triggers with defined thresholds and fallbacks, and always log route changes for auditing and incident review. ### **Layer 3: Integration with Upstream Scrubbing Centres** For large-scale attacks that exceed on-premise capacity or require deeper packet inspection, traffic can be **diverted to a DDoS scrubbing centre**. This layer is typically engaged via: - BGP-triggered redirection - Integration with a third-party scrubbing provider (cloud-based or ISP-provided) The key is automation: once an attack is identified, the redirection should be hands-off, restoring traffic once the threat subsides. **Best practice: Look for tools that support [vendor-neutral integration](https://fastnetmon.com/ddos-scrubbing-centre-diversion/) with any scrubbing provider — to maintain control and avoid lock-in. ### **Layer 4: Visibility and Post-Incident Analysis** A critical but often overlooked layer is **visibility**. Being able to understand: - When an attack started and ended - What kind of traffic was involved - Who was affected …is essential for reporting, customer communication, and future prevention. This is where **dashboards and time-series analytics** come in — providing clear visual timelines of traffic patterns, trigger points, and mitigation actions. **Best practice: Use [Grafana or similar tools](https://fastnetmon.com/docs-fnm-advanced/advanced-visual-traffic/) to create real-time dashboards of top talkers, attack timelines, and BGP action logs. ### **Final Thoughts** A strong DDoS defence isn’t about relying on a single tool or vendor — it’s about **layering smart detection, fast response, and deep visibility** into one cohesive system. The goal isn’t just to stop attacks, but to do it without disrupting legitimate traffic, overreacting, or leaving blind spots. By building a layered architecture grounded in flow telemetry, automated BGP mitigation, and real-time analytics, defenders can stay ahead of the evolving threat landscape — while keeping their network calm, stable, and secure. --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** FastNetMon Blog **Tags:** Network Security Insights --- ### [Tier 1 transit and the DDoS comfort myths](https://fastnetmon.com/2025/06/11/tier-1-transit-and-the-ddos-comfort-myths/) **Published:** June 11, 2025 **Author:** FastNetMon **Content:** If your organisation buys bandwidth from one of the big backbone carriers, you already sit behind formidable pipes and global scrubbing clouds. Sales decks often call this ‘built-in DDoS protection’. It sounds reassuring: why invest in extra defences when petabit routers stand between you and the internet? Yet every quarter we see outages at banks, gaming platforms and government portals that purchase Tier 1 connectivity. The lesson is simple. Backbone capacity alone is not a full shield, and some attack types glide straight past provider-side filters until damage is visible on your side of the hand-off. **What is a Tier 1 ISP?** The public Internet is stitched together by thousands of networks known as autonomous systems. At the top sit a handful of carriers, often called Tier 1s, that can reach every other network without paying anyone for transit. They achieve this by exchanging traffic with their peers on a settlement-free basis and by owning, leasing or swapping enough international capacity to deliver packets to any corner of the globe. If you buy a connection from a Tier 1 you are said to have ‘transit’. The carrier advertises your routes to the rest of the Internet and carries inbound and outbound traffic across its backbone. Below Tier 1 you find Tier 2 providers (large regionals that still pay at least some transit costs) and Tier 3 or ‘access’ ISPs (local broadband or hosting companies that rely almost entirely on upstreams). **Why is DDoS protection often bundled with transit?** Large carriers operate routers that push terabits per second and peer at dozens of exchange points. Any attack they can block at the outer edge saves backbone bandwidth, keeps latency stable for all customers, and prevents knock-on failures in congested links. Scrubbing early is therefore cheaper than allowing junk traffic to travel halfway around the world before it is discarded. To achieve this, most Tier 1s install several layers of defence. Stateless access-control lists drop obviously spoofed packets in hardware. Remote-triggered black-hole routes can be injected within seconds to sink traffic aimed at an overloaded prefix. For bigger or more complex floods, traffic is diverted into regional scrubbing centres that inspect every packet and return only the clean flows to the customer. Because these measures also protect the carrier’s own infrastructure, a basic level of filtering is offered ‘for free’, with enhanced tiers sold as add-ons. Marketing turns that operational necessity into a pitch: ‘Our backbone is so large a flood can’t touch you, and if it does we’ll clean it automatically.’ In reality, the bundled protection is designed to keep the core safe first; ensuring every individual service stays online still requires local visibility and policy control on the customer side. **The comfort myth: where blind spots appear** Carrier defences are tuned for events that threaten the backbone itself. They watch for sudden multi-terabit floods, spoofed reflection traffic or routing loops. Smaller yet still damaging attacks can slip through because they never trigger backbone-level alarms. A four-gigabit HTTPS flood will sail under the radar of a router handling six-terabit links, but it can still choke a data-centre link or exhaust a web cluster. Even when the carrier intervenes the preferred tool is often a black-hole route that simply drops every packet to the victim prefix. That saves upstream capacity yet removes the target application from the Internet. Granular filters, blocking only one port, one botnet subnet or one protocol option, require context carriers rarely have for thousands of customers. Application-layer floods add another wrinkle. These attacks mimic genuine user sessions and produce modest packet rates, so backbone monitors that focus on bandwidth or packets per second may mark the traffic as normal. **Why ‘leave it to the carrier’ fails during hyper-volumetric events** Tier 1 backbones can swallow multi-terabit floods, but that capacity is gated by operational and commercial caveats. A carrier generally waits until traffic crosses a pre-set threshold (often 2 Gbps for a /32 or 10 Gbps for a /24) before it diverts flows into its scrubbing cloud. The trigger is usually a BGP community tag or a ticket raised via the customer portal, and both steps rely on humans or automation inside the customer’s NOC. Industry incident reviews by NANOG and FIRST show an average of three to five minutes between the first alarm and full diversion. Billing is rarely transparent. Most wholesale contracts bundle a fixed ‘clean-traffic’ allowance, typically 2–5 Gbps, after which the provider charges by 95th-percentile or per-gigabit egress. And latency is the quiet tax. Scrubbing nodes sit where fibre is cheap, not necessarily next door to users. For example, Riot Games has documented packet-time jumps of 15–20 ms when traffic for its European shard is rerouted through London during mitigation, enough to trigger hit-registration complaints in fast-twitch titles. Voice-over-IP codecs like Opus tolerate roughly 20 ms jitter; add another dozen and call quality degrades audibly. In capital-markets networks governed by MiFID II and Reg SCI, even a 2 ms swing can flag best-execution alerts. There are architectural blind spots too. Carriers seldom accept BGP advertisements more specific than /24, forcing an operator to black-hole an entire subnet to stop a single host’s flood. Encrypted L7 assaults—HTTP/2, WebSocket, QUIC - get past volumetric filters because backbone scrubbers do not terminate TLS. The attack footprint shrinks from terabits to a few gigabits, but those connections still hammer application threads and database pools once they exit the cloud. For businesses that trade on milliseconds or maintain stateful services, carrier mitigation is a safety net, not a silver bullet. Local detection, prefix-level FlowSpec, and the ability to shed only the bad traffic remain indispensable for staying online while the backbone catches up. **Building a layered defence** Defence works best when upstream capacity and local intelligence cooperate. Keep the carrier’s giant pipes in reserve, but place fast detection at your edge, inside your own routing domain, so that every flow is inspected from the first packet. FastNetMon listens to NetFlow, sFlow, IPFIX or mirrored traffic, flags anomalies in seconds and generates precise BGP Flow Spec or RTBH announcements. Malicious sources can be rate-limited or dropped while legitimate sessions keep flowing. When the attack grows toward circuit capacity, the same system can automatically signal your transit provider or cloud scrubbing partner and withdraw the route once the wave subsides. That automation shortens downtime, avoids unnecessary detours and keeps bills predictable. **What does FastNetMon add that a Tier 1 cannot?** - First-hop visibility – your routers export flows that show packet sizes, port numbers and TCP flags. FastNetMon turns those details into real-time alerts long before an upstream sees trouble. - Fine-grained mitigation – [generate Flow Spec rules](https://fastnetmon.com/flowspec-ddos-mitigation/) that block only the abusive port or subnet instead of null-routing the whole prefix. - Actionable telemetry – [Grafana dashboards](https://fastnetmon.com/docs-fnm-advanced/advanced-visual-traffic/) reveal whether the attacker is using UDP floods, HTTPS keep-alive abuse or mixed vectors, arming you with data for post-incident tuning and insurance reporting. Tier 1 transit stops a fair share of the noise, but its view is wholesale and its triggers protect the backbone, not your customer experience. Precision filtering, application awareness and rapid escalation still need to live inside your perimeter. Combine carrier scale with site-level detection, keep clear run-books for triggering upstream scrubbing, and treat DDoS defence as a partnership—not a single outsourced checkbox. --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit <https://fastnetmon.com> **Categories:** FastNetMon Blog **Tags:** Network Security Insights --- ### [When is BGP blackholing a good choice for DDoS mitigation — and when is it not?](https://fastnetmon.com/2025/06/18/when-is-bgp-blackholing-a-good-choice-for-ddos-mitigation-and-when-is-it-not/) **Published:** June 18, 2025 **Author:** FastNetMon **Content:** **BGP Blackholing**, also known as **RTBH (Remotely Triggered Black Hole)**, is a well-established technique in the DDoS mitigation playbook. It’s fast, effective, and uses your upstream providers’ infrastructure to stop attack traffic before it ever reaches your network. But despite its power, **RTBH is not always the right tool for the job**. In this post, we’ll explore when BGP blackholing is a smart response — and when it could cause more harm than good. ### **A Quick Recap: What is BGP Blackholing?** RTBH is a routing technique that drops all traffic destined for a specific IP address by directing it to a null route (Null0). From the attacker’s perspective, it’s as if the destination has vanished from the internet. RTBH is often used in automated DDoS protection systems (like[ FastNetMon](https://fastnetmon.com/)) to rapidly shut down attack traffic. It works by broadcasting a BGP route for the attacked IP with specific communities that instruct upstream routers to drop the traffic before it enters your network. You can learn more in our complete guide on [BGP Blackhole Automation for DDoS mitigation](https://fastnetmon.com/2024/12/07/bgp-blackhole-automation-for-ddos-mitigation/) ### **When RTBH Is a Good Choice** 1. **Volumetric DDoS attacks If your network is under a massive Layer 3/4 flood (like UDP or SYN flood), blackholing an attacked IP can instantly remove the pressure from your infrastructure. 2. **Attacks on non-critical services If the attacked host is already offline or not essential, blackholing it may have minimal impact but prevent broader damage. 3. **Protecting shared infrastructure If an attack threatens shared links, routers, or services (like firewalls), blackholing a single target can protect everything else. 4. **As an emergency triage measure When response time is critical, RTBH can act as a quick mitigation while more advanced techniques (like BGP FlowSpec) are deployed. 5. **As part of automated DDoS mitigation Integrated with tools like[ FastNetMon](https://fastnetmon.com/), RTBH becomes a smart, fast, and hands-off way to control high-volume attacks. ### **When RTBH Is Not a Good Choice** 1. **When the target is a critical service or customer RTBH drops all traffic — good and bad. You’re essentially unplugging yourself from the internet. Not ideal if the attacked service is revenue-critical. 2. **Application-layer (L7) attacks If attackers are mimicking legitimate web traffic (HTTP floods, bot attacks), RTBH won't help — it doesn’t inspect or filter by application logic. In these cases, scrubbing or WAFs are more effective. 3. **Spoofed or distributed attacks across multiple targets Blackholing one IP won’t solve a broader attack or one that’s constantly shifting between targets. 4. **In multi-tenant environments or shared hosting If multiple services or customers share an IP, RTBH can create unintended outages. 5. **If misused or triggered too aggressively Without clear thresholds and logic, RTBH can be used maliciously or mistakenly, causing self-inflicted downtime. ### **FastNetMon Makes RTBH Smarter** [FastNetMon](https://fastnetmon.com/) automates the entire RTBH workflow for fast and effective DDoS response: - Real-time attack detection in under 5 seconds - Configurable thresholds and automatic unblocking - Integration with your BGP setup to trigger blackholing based on[ community values](https://fastnetmon.com/bgp-blackhole-automation/) - Custom actions, alerts, and notifications for full visibility FastNetMon announces BGP routes for targeted IPs, which your routers can be configured to handle using predefined community-based policies — such as null routing at the edge or upstream. Whether you want simple RTBH, or a more advanced setup with FlowSpec, scrubbing, or traffic analysis, FastNetMon helps you build a fast, flexible, and resilient DDoS defence strategy. [Learn more about FastNetMon’s RTBH automation](https://fastnetmon.com/bgp-blackhole-automation/) --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** FastNetMon Blog **Tags:** Blackhole, Network Security Insights --- ### [DDoS attacks are now targeting journalists, universities, NGOs. What has changed?](https://fastnetmon.com/2025/06/19/ddos-attacks-are-now-targeting-journalists-universities-ngos-what-has-changed/) **Published:** June 19, 2025 **Author:** FastNetMon **Content:** Historically, DDoS attacks focused on obvious targets: banks, telecoms, gaming platforms, and government services. But in 2025, the landscape has shifted. Today’s DDoS campaigns are increasingly aimed at organisations that weren’t considered strategic targets just a few years ago. Nonprofits, universities, and independent media outlets are now regularly under fire. These attacks aren’t always large or long-lasting — but they’re timed for disruption and designed to silence. Let’s look at who’s in the crosshairs and why. ### **1. Civil Society & Nonprofits: Disruption as a Political Tool** Human rights groups, nonprofits, and advocacy organisations are experiencing a sharp uptick in DDoS activity — especially around elections, protests, or the release of sensitive investigations. These aren’t random. They’re deliberate attempts to knock platforms offline during high-stakes moments. Civil society groups often operate with limited resources, lean infrastructure, and minimal security hardening. This makes them ideal targets for volumetric floods or burst attacks that overwhelm basic hosting. - **Cloudflare** reported a 241% year-over-year increase in blocked DDoS traffic targeting independent media and civil society organisations. - The **CyberPeace Institute** and other watchdogs have linked these campaigns to broader attempts at censorship and digital repression. ### **2. Education: Infrastructure That Wasn’t Built for This** Education moved online fast — and security has not always kept up with the digitalisation. Student portals, grading systems, and remote learning tools are now core infrastructure for schools and universities worldwide. DDoS attacks in this sector tend to spike during: - Exam periods - Registration deadlines - Major political events (when targeting research-active institutions) Whether it’s activism-related or opportunistic, education networks are increasingly being hit — not for money, but to disrupt. ### **3. Independent Media: Shut Down the Story Before It Spreads** Smaller media outlets and independent journalists are facing a growing wave of targeted DDoS attacks — especially when publishing sensitive or politically charged stories. These attacks are cheap to launch and devastating when timed right. Many small outlets run on basic setups: a CMS, a CDN, and minimal backend capacity. A few minutes of well-timed downtime can kill visibility and momentum. The [recent 6.3 Tbps attack against KrebsOnSecurity](https://fastnetmon.com/2025/05/27/6-3-tbps-in-45-seconds-what-the-latest-assault-on-krebsonsecurity-tells-us-about-hyper-volumetric-ddos/) demonstrates that attackers now have access to staggering amounts of traffic — often far more than is needed to disable a target. In that case, the site remained online, but the message was clear: attackers are willing to unleash massive force, even against relatively small, independent voices. ### **Why Is This Happening Now?** Yes, DDoS is easier and cheaper to launch than ever. - Botnets are rentable - Toolkits are plug-and-play - IoT vulnerabilities continue to provide firepower for attackers We broke this down in detail in our blog post: [**DDoS Booters and IP Stressers: Explained by Experts**](https://fastnetmon.com/2025/04/10/ddos-booters-and-ip-stressers-explained-by-experts/) But the deeper shift is geopolitical. We're seeing DDoS used more frequently as a low-cost, high-impact tool for censorship and destabilisation — a way to disrupt services without attribution and to apply pressure without a physical presence. For more, read: [**DDoS in Geopolitics: When Network Traffic Becomes a Digital Weapon**](https://fastnetmon.com/2025/05/19/ddos-in-geopolitics-when-network-traffic-becomes-a-digital-weapon/) ### **What Can Organisations Do?** No one is immune from being targeted, but there are ways to prepare and respond: **Map Your Exposure** Identify your public-facing infrastructure, assess vulnerabilities, and understand what’s likely to break under load. **Avoid Single Points of Failure** Use caching, redundant DNS, and geographically distributed infrastructure to avoid total service outages. **Use the Right Protection Tools** For civil society, nonprofits, and smaller networks, [**FastNetMon Community Edition**](https://fastnetmon.com/install/) offers free, high-quality DDoS detection and basic mitigation. It’s used globally by universities, internet exchanges, and research organisations. For larger-scale or more complex environments, **FastNetMon Advanced Edition** adds automation, flow protocol support (NetFlow, IPFIX, sFlow), and deeper visibility into traffic anomalies. You can [compare Community and Advanced editions here](https://fastnetmon.com/compare-community-and-advanced/). --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** FastNetMon Blog **Tags:** DDoS News --- ### [Book Review: DDoS – Understanding Real-Life Attacks and Mitigation Strategies by Stefan Behte](https://fastnetmon.com/2025/06/25/book-review-ddos-understanding-real-life-attacks-and-mitigation-strategies-by-stefan-behte/) **Published:** June 25, 2025 **Author:** FastNetMon **Content:** Comprehensive resources on Distributed Denial of Service (DDoS) attacks are surprisingly hard to come by—especially ones that are both technically accurate and grounded in real-world experience. That’s why **Stefan Behte’s** new book, ***"DDoS: Understanding Real-Life Attacks and Mitigation Strategies"*** (2025), caught our attention right away. ### **Why this book is worth your time** As one of the leading DDoS detection and mitigation solution providers globally, **FastNetMon** works with some of the most demanding networks in the world. We live and breathe DDoS defence every day—analysing live attacks, building defence mechanisms, and helping service providers, enterprises, and governments stay online under pressure. We’ve seen almost every type of DDoS strategy in the wild, and we know just how quickly the threat landscape evolves. We also run a **global community of thousands of DDoS defenders**—from ISPs and hosting providers to security engineers and researchers. Through that network, we have ears and eyes on the ground 24/7, constantly learning how attackers operate and how defenders adapt. This book reflects the kind of real-world knowledge we see shared in those communities every day. So when we say this book is one of the most practical and well-informed resources on the topic, we mean it. It’s rare to find a technical book that gets the details right *and* reflects the messy, tactical nature of defending production systems under attack. Behte manages both. ### **What makes this book stand out** Stefan Behte is no armchair analyst. With over 20 years in managed hosting, he’s led defences against real attacks targeting high-profile German government and corporate sites like **Bundestag.de**, **Henkel.com**, and **Auswaertiges-amt.de**. His experience dealing with adversaries such as **Anonymous**, **Killnet**, and **NoName057(16)** shapes every chapter of this book. This isn’t a textbook—it’s a field guide. Here’s a glimpse what’s covered: - **Detailed breakdowns of all attack types** from L3 to L7 - **Concrete mitigation strategies** that can be applied in production environments - **Labs and configuration examples** using open-source tools like HAProxy and Nginx - **Deep dives into datacenter architecture**, botnet behaviour, and the origins of traffic - A rare look into the **economics of DDoS**—how attackers weigh cost vs. impact, and what defenders need to consider - A thought-provoking section on **active self-defense**, exploring where the line is between defence and offence ### **Who should read it?** This book is especially valuable for: - **Network engineers** responsible for building and maintaining DDoS-resilient infrastructure - **Security teams** looking for proven mitigation tactics - **Service providers** who need to understand attack origins and volumetric trends - **Students and early-career professionals** who want more than just theoretical coverage It balances **depth and clarity** exceptionally well—accessible without oversimplifying. ### **FastNetMon’s verdict** We rarely recommend books, but this one’s an exception. *"DDoS: Understanding Real-Life Attacks and Mitigation Strategies"* is a smart, focused, and deeply practical guide written by someone who’s actually defended networks under fire. If your role involves protecting infrastructure from DDoS attacks, this belongs on your reading list. ### **Where to find it** The book is available at: <https://ddos-book.com/> The site includes everything you need to get started—details about the book’s structure, topics covered, and the author’s background. You’ll also find ordering options for both the **eBook** and **hardcover editions**. We highly recommend picking up a copy—and sharing it with your team. --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** FastNetMon Blog **Tags:** Network Security Insights --- ### [A new variant of the Flodrix botnet has entered the scene…](https://fastnetmon.com/2025/06/26/a-new-variant-of-the-flodrix-botnet-has-entered-the-scene/) **Published:** June 26, 2025 **Author:** FastNetMon **Content:** A new variant of the Flodrix botnet has entered the scene, and it’s taking aim at poorly secured open-source tools with an unusual level of stealth and versatility. The newest Flodrix variant builds on the same old principles: find vulnerable software, exploit it for remote access, and quietly conscript the machine into a global network of bots. But the toolkit is evolving fast. We’re now seeing DDoS malware equipped with encrypted C2 channels, automatic update systems, and cross-architecture payloads designed for scale. ## Who’s the latest Flodrix target? This latest campaign targets Langflow, a Python-based platform used to build LLM-powered applications. The vulnerability it exploits, CVE‑2025‑3248, allows unauthenticated attackers to run arbitrary code through a debug API, a simple misconfiguration with outsized consequences. ## How does Flodrix attack? The infection chain begins with internet-wide scans looking for Langflow instances with exposed developer endpoints. Attackers use publicly available exploits – often shared on GitHub within days of a CVE being published – to send crafted payloads that abuse Python’s abstract syntax tree parser, which in turn leads to full code execution. From there, a downloader script connects to an IP address hardcoded in the exploit chain, which fetches a compiled binary tailored to the victim’s architecture, whether ARM, MIPS, or x86. Once executed, this payload installs the Flodrix botnet client and begins its silent operations. ## What sets this Flodrix variant apart? 1\. Multi-protocol C2 communication Unlike simpler botnets, Flodrix communicates over both TCP and UDP, and even includes optional support for routing through the Tor network. This complicates detection, as traffic may appear innocuous or bypass standard firewall rules. 2\. Encrypted payloads and obfuscation Strings inside the binary are XOR-encrypted (key: qE6MGAbI), which hides configuration data like C2 IPs and attack instructions. Basic static analysis won’t reveal much. 3\. Process enumeration and targeting Once active, Flodrix combs through /proc to identify running processes and services. It may terminate known daemons or resource-intensive processes, reporting this back to its controller via an encrypted message format (KILLDETAIL\|...). 4\. Self-deletion and evasion The malware can delete itself after execution if no valid arguments are provided, removing evidence from the infected system. It also clears installation traces, log entries, and temporary files. 5\. DDoS attack modes It supports a wide range of encrypted DDoS vectors, including: \* tcpraw \* udpplain \* handshake \* tcplegit \* ts3 (TeamSpeak-based flooding) Each mode targets different layers and protocols, enabling attackers to bypass traditional filtering methods. ## Who’s being targeted by Flodrix? So far, most infections have occurred in Asia and North America, according to Censys data. Over 700 IPs have been flagged as compromised, many of them IoT devices and embedded systems running vulnerable configurations of Langflow or exposed container services. This botnet appears to be architecture-agnostic. Its binaries are compiled for multiple chipsets, including ARM variants found in routers, DVRs, and NAS units. That’s a clear indicator of how attackers are looking for broad coverage, not just traditional servers. ## How does Flodrix fit into the bigger picture? If the original Flodrix strain was a basic DDoS tool, this variant looks like a full-fledged platform. It borrows ideas from earlier families like Moobot and LeetHozer, while adding its own refinements in obfuscation, modularity, and adaptability. We’re seeing a clear shift in botnet design: \* Less visibility: Through encrypted traffic and stealthy execution. \* More automation: Infection, update, and execution steps are tightly scripted. \* Greater reach: With binaries built for everything from home routers to public cloud instances. This mirrors what we saw after Mirai’s codebase was leaked – a spike in derivative projects and more hands on the tooling. But Flodrix isn’t just another clone. It shows an understanding of how to blend into cloud environments and sidestep modern defences. What are defenders up against? In practical terms, detection and mitigation become more complex when: \* The malware deletes itself after execution. \* Communication is encrypted or routed through Tor. \* Target devices are under-monitored or run default configurations. \* Attack traffic mimics legitimate services or leverages rarely filtered protocols. Flodrix also reflects the growing use of open-source software as an attack vector. While Langflow isn’t inherently insecure, misconfigured deployments – especially those exposing developer interfaces – are proving to be fertile ground for attackers. ## What should network engineers look for? A few indicators may help identify compromised systems or attack attempts: \* Unusual outbound UDP/TCP traffic on non-standard ports. \* Devices connecting to IPs like 80.66.75\[.\]121:25565. \* Short-lived processes executing shell scripts or unknown binaries. \* POST requests to /api/v1/validate/code with embedded Python payloads. If you’re running Langflow or similar tools in production, make sure developer endpoints are disabled or properly secured. Even better, isolate those environments from public access altogether. ## Looking ahead The Flodrix case shows just how quickly botnets evolve when new exploits emerge. Within weeks of CVE-2025-3248’s disclosure, attackers had weaponised it, deployed infrastructure, and begun real-world attacks, showing us once again that modern botnets aren’t static threats. On the contrary, they’re adaptive, opportunistic, and increasingly modular. As defenders, we need to watch both the tools and the terrain. --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** FastNetMon Blog **Tags:** threats and vulns --- ### [FastNetMon Interviewed by Safety Detectives: Rethinking DDoS Protection for a Faster, Safer Internet](https://fastnetmon.com/2025/07/02/fastnetmon-interviewed-by-safety-detectives-rethinking-ddos-protection-for-a-faster-safer-internet/) **Published:** July 2, 2025 **Author:** FastNetMon **Content:** FastNetMon was recently featured in an interview with Safety Detectives, a cybersecurity blog. The conversation covers the rising threat of Distributed Denial of Service (DDoS) attacks and how FastNetMon is addressing these challenges with innovative solutions. In today’s environment, DDoS attacks are becoming more frequent, larger in scale—often reaching terabits per second—and increasingly accessible through easy-to-use DDoS-for-hire platforms. Pavel Odintsov, Co-Founder of FastNetMon, explains why traditional DDoS defences are struggling to keep pace and how FastNetMon’s lightweight, automated platform offers rapid detection and mitigation that can be deployed by organisations of any size. The interview also includes real-world examples from FastNetMon customers who have successfully eliminated downtime caused by attacks and achieved near-instant response times, demonstrating the solution’s reliability and efficiency. Serving networks across 180 countries, FastNetMon continues to evolve its platform with advanced telemetry and smarter automation to make DDoS attacks a manageable and ultimately non-issue problem. This conversation is a useful read for anyone responsible for network security or interested in the future of cyber defense. Discover the full interview and learn more about how FastNetMon is shaping the future of DDoS protection here: <https://www.safetydetectives.com/blog/fastnetmon-interview/> --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** Press & Newsroom **Tags:** press features --- ### [How to set a threshold for RTBH/BGP Blackhole: A practical guide to threshold-based DDoS defence](https://fastnetmon.com/2025/07/02/how-to-set-a-threshold-for-rtbh-bgp-blackhole-a-practical-guide-to-threshold-based-ddos-defence/) **Published:** July 2, 2025 **Author:** FastNetMon **Content:** **Threshold-based DDoS defence** is one of the most effective ways to automate [blackhole routing](https://fastnetmon.com/2024/12/07/bgp-blackhole-automation-for-ddos-mitigation/) for high-volume attacks, without the need for constant manual oversight. In this post, we’ll break down how threshold-based mitigation works, how to configure it in FastNetMon, and how it differs from rate limiting. Whether you're an ISP, hosting provider, or enterprise security engineer, understanding how to **set a threshold** for RTBH (Remote Triggered Black Hole) can dramatically reduce your mitigation time and prevent network disruption. ### **What is threshold-based DDoS mitigation?** Threshold-based DDoS mitigation automatically triggers a defence action (RTBH or BGP blackhole) when a specific traffic metric exceeds a predefined **threshold**. For example, if a single IP starts receiving over 500,000 packets per second (PPS), FastNetMon can immediately signal your router to null-route the target IP, effectively mitigating the attack before it impacts other customers or services. This model of defence is particularly effective for volumetric attacks, where response time is critical and the attack signature is obvious in traffic volume. You can set thresholds based on: - Packets per second (PPS) - Bits per second (BPS) - Flows per second (FPS) ### **Threshold-based mitigation vs rate limiting: what’s the difference?** Although both threshold-based mitigation and rate limiting are tools used in DDoS defence, they operate on different principles and serve distinct purposes. **Threshold-based DDoS mitigation** is a reactive mechanism. It involves continuously monitoring traffic levels—such as packets per second, bits per second, or flows per second, and taking action only when those levels exceed a predefined threshold. When triggered, this action is typically drastic and immediate, such as activating BGP blackhole routing to null-route the target IP address. This form of mitigation is particularly useful for defending against large-scale volumetric attacks, where the goal is to absorb or isolate the attack traffic as quickly as possible to prevent it from overwhelming the network. On the other hand, **rate limiting** is a proactive control mechanism that intentionally restricts the rate of incoming or outgoing traffic, regardless of whether an attack is happening. It enforces a cap on the amount of traffic a host or application can send or receive over a given period. For example, you might configure a firewall or application gateway to allow no more than 100 requests per second to an API endpoint. If that rate is exceeded, excess traffic is either delayed, dropped, or degraded. This is useful for managing legitimate but excessive usage, such as limiting bursts of traffic from a single user or bot, or ensuring fair resource distribution among tenants. The key distinction lies in their purpose and execution. Threshold-based mitigation is designed to detect and respond to abnormal or malicious spikes in traffic volume, usually with automated actions that isolate the affected IP or segment. It's a line of defence used when things go wrong. Rate limiting, on the other hand, is more about ongoing traffic control, not attack detection. It shapes traffic flows by keeping usage within acceptable bounds to ensure stability and fairness under normal conditions. Importantly, these two methods are not interchangeable. Rate limiting does not offer the kind of decisive action required during high-throughput DDoS attacks. And while threshold-based mitigation can quickly shut down a targeted attack, it's not suitable for general traffic management or abuse prevention in non-attack scenarios. In practice, many robust DDoS protection strategies use both. Rate limiting ensures baseline service quality and prevents abuse, while threshold-based detection and blackholing are reserved for acute attack mitigation. ### **How to set up a threshold on FastNetMon**? FastNetMon Advanced supports per-host threshold configuration, which gives you flexibility to apply different thresholds to different IPs or networks. Once a threshold is exceeded, FastNetMon will trigger a predefined mitigation step, such as announcing a BGP blackhole route. **Step 1: Enable BGP Blackhole Support** Start by configuring a BGP session between FastNetMon and your router or route reflector. This is required for FastNetMon to announce blackhole routes when thresholds are exceeded. **Step 2: Configure Global Thresholds (Optional)** You can set system-wide default thresholds that apply to all IPs. First, enable threshold tracking, then set a default PPS value, i.e. 500,000 packets per second. These values can be overridden later on a per-IP basis. **Step 3: Enable Per-Host Thresholds** To define specific limits for individual IP addresses, turn on per-host thresholding. Once enabled, you can set a custom PPS and BPS value for any IP. For instance, you might set one host to trigger at 250,000 packets per second or 1 Gbps. **Step 4: Define the Mitigation Action** Once a host crosses its threshold, FastNetMon needs to know how to respond. Here, you define the BGP community tag that your router uses to recognise a blackhole route - commonly something like 65535:666. **Step 5: Monitor Triggered Events** FastNetMon logs every threshold breach and mitigation event. You can monitor these logs directly or plug them into your existing alerting setup using tools like Syslog, Kafka, or webhooks. ### **What else can you do with threshold-based defence?** Once you’ve got the basics of setting thresholds down, there are a few extra options that can really help you fine-tune your DDoS protection, especially if you’re dealing with more complex setups or bigger networks. **1. Group hosts together and set limits for the whole group** Instead of managing thresholds for every single IP, you can lump IPs or subnets into groups - say, all the servers in a data centre or all the customers in a particular region - and set a threshold for the whole bunch. If traffic to that group goes over the limit, the system can trigger a defence action. It’s a lot easier to manage when you have lots of addresses. **2. Watch incoming and outgoing traffic separately** Most people think about attacks coming in, but don’t forget traffic leaving your network. If a machine inside your network gets compromised and starts blasting out traffic, having separate limits for outgoing traffic helps catch that early. **3. Get more specific with what you watch** Instead of just counting packets or bits, you can set thresholds based on things like protocol type, ports, or packet details. That way, you can catch specific attack types, like DNS floods or SYN floods, without accidentally triggering on normal traffic. **4. Find out what “normal” looks like first** If you’re not sure what numbers to pick for your thresholds, spend some time measuring your usual traffic patterns. That way, you can set your limits just above what’s typical for your network, which helps avoid false alarms. **5. Have a backup plan when the attack keeps going** Sometimes blocking a single IP isn’t enough, especially if the attacker switches targets or uses many IPs. Some setups let you create an escalation path: if the traffic keeps spiking, you can block a whole subnet or a larger group of addresses to keep things under control. You don’t need to use all these tricks right away. But as your network grows or your threat landscape changes, they give you ways to stay one step ahead, and avoid getting overwhelmed by noisy or sophisticated attacks. The better you understand your traffic, the easier it gets to tune your defence to fit your real-world needs. For a full walkthrough and configuration examples, visit the documentation: [FastNetMon: Per-Host Threshold Configuration](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-per-host-threshold-configuration/) **Need more?** Explore our guides: - FastNetMon: Per-Host Threshold Setup - <https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-per-host-threshold-configuration/> - BGP Blackhole Configuration Guide - <https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-blackhole/> --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** FastNetMon Blog **Tags:** Network Security Insights --- ### [Filtering L3/L4 DDoS attacks with BGP Flow Spec and RTBH: A practical guide for engineers](https://fastnetmon.com/2025/07/08/filtering-l3-l4-ddos-attacks-with-bgp-flow-spec-and-rtbh-a-practical-guide-for-engineers/) **Published:** July 8, 2025 **Author:** FastNetMon **Content:** Distributed Denial of Service (DDoS) attacks at [layers 3 and 4 ](https://fastnetmon.com/2025/03/11/layer-3-ddos-attacks-explained/)are blunt, fast, and disruptive. If you’re running networks at any scale, chances are you’ve already seen your fair share of UDP floods, TCP SYN storms, and other packet-level abuse. Detection is step one. But what comes next, or how (*how fast*) you mitigate these attacks, is what really determines whether you're back to normal in seconds or stuck firefighting for hours. ## **How to filter a DDoS attack at the routing layer?** When a DDoS attack hits, upstream bandwidth and router CPU are often your most limited resources. Two popular BGP-based approaches help you mitigate: - **Flow Spec**, for fine-grained, rule-based filtering based on IP, ports, protocol, TCP flags, and more. - **RTBH**, for quickly dropping all traffic to a target prefix, typically using a Null0 route. Both approaches rely on injecting routes via BGP, which means they can scale across providers, peers, or transit depending on your setup. This guide walks through these two practical, well-tested methods for filtering DDoS traffic at scale using BGP. We’ll look at how they work, when to use them, configuration examples, and the trade-offs involved. ## BGP Flow Spec: granular filtering in real-time Flow Spec allows you to push specific traffic-matching rules directly into routers via BGP. It’s especially useful when you want to stop an attack without disrupting all traffic to the destination. **How Flow Spec works** 1. Flow monitoring tools (like NetFlow, sFlow, or IPFIX) identify a potential DDoS pattern. 2. A filtering rule is generated i.e., to “block UDP traffic to port 53”. 3. That rule is sent over BGP to supported routers, which apply it immediately. 4. Traffic matching the rule is dropped, rate-limited, or redirected, depending on the action defined. 5. See a ground-up explanation and visual diagrams on BGP flowspec [here](https://fastnetmon.com/2025/02/10/bgp-flow-spec-for-ddos-mitigation/) ## Example: FastNetMon Flow Spec config ``` bash CopyEdit # Enable BGP and FlowSpec globally sudo fcli set main gobgp enable sudo fcli set main gobgp_flow_spec_announces enable sudo fcli set main gobgp_flow_spec_default_action discard # Optional: rate-limit instead of discard sudo fcli set main gobgp_flow_spec_rate_limit_value 1000000 # Enable on your BGP router session sudo fcli set bgp my_router ipv4_flowspec enable sudo fcli commit ``` ## Considerations - **Platform support**: Flow Spec is widely supported on Juniper, Cisco, Arista, Huawei, and others, but with quirks. See what fields your platform supports (especially TCP flags and fragments). - **Rule validation**: Some platforms ignore invalid combinations silently. Always test. - **Monitor live rules**: Use tools to track what’s currently announced and how traffic is responding. ## **RTBH: The all-or-nothing approach** RTBH is the oldest trick in the book for DDoS mitigation, and it still works. Instead of matching on ports or flags, you simply drop all traffic to a prefix by advertising a route to a special next-hop (usually Null0). It’s simple, fast, and works even on routers without Flow Spec support. ### When to use RTBH - When you're under a high-volume flood and need to cut traffic immediately - If upstream providers don’t support Flow Spec - As a fallback for attacks where packet-level filtering is too slow or doesn’t apply ### How RTBH works - A BGP route is announced with a predefined next-hop (e.g., 192.0.2.1) - Routers apply the drop action to all traffic towards that prefix - BGP communities are used to control the reach and scope of the announcement - See a ground-up explanation and visual diagrams on BGP Blackhole [here](https://fastnetmon.com/2024/12/07/bgp-blackhole-automation-for-ddos-mitigation/) ### Example: FastNetMon RTBH config (goBGP) ``` bash CopyEdit sudo fcli set bgp my_router ipv4_unicast enable # RTBH settings (example using goBGP or ExaBGP) # On attack detection: # exabgp_next_hop=192.0.2.1 # exabgp_community=65001:666 sudo fcli commit ``` ### Edge router example (Cisco IOS-XE) ``` bash CopyEdit router bgp 65000 neighbor 10.10.2.2 remote-as 65000 neighbor 10.10.2.2 send-community ip route 192.0.2.1 255.255.255.255 Null0 ip community-list expanded RTBH permit 65000:666 route-map RTBH permit 10 match community RTBH set ip next-hop 192.0.2.1 router bgp 65000 neighbor 10.10.2.2 route-map RTBH in ``` ## Flowspec vs RTBH: A quick comparison | **Feature** | **BGP Flowspec** | **RTBH (Null Routing)** | |---|---|---| | **Granularity** | Packet-level (ports, flags) | Prefix-level (all-or-nothing) | | **Speed** | Fast (2–5 sec detection + push) | Fast (similar detection + drop) | | **Network load** | Low — just bad flows | High — all traffic dropped | | **Support quirks** | Some vendor caveats (IPv6, flags) | Widely supported, simpler | | **Collateral impact** | Minimal | High — legitimate traffic lost | ## Real-world tips for safer, smarter mitigation - If you can, start with Flow Spec, and escalate to RTBH if things get out of hand. - Don’t assume all platforms behave the same. Lab-test Flow Spec if possible, and document any quirks in your network. - Use timers or [auto-unblock](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-bgp-blackhole-automation/) where possible to remove stale rules. - Log everything - both what you’re announcing and what gets dropped. DDoS attacks are noisy, stressful, and often cause disproportionate damage. The best thing you can do is prepare, test, and automate as much of the response as possible. Both BGP Flow Spec and RTBH are time-tested tools that give you control over what enters your network, and what gets stopped at the gate. If you’re running a NOC, peering network, or backbone and haven’t integrated these into your toolkit yet, now’s the time. --- # About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats.For more information, visit <https://fastnetmon.com> **Categories:** FastNetMon Blog **Tags:** Network Security Insights --- ### [FastNetMon Interviewed by Website Planet: The Real Reason Websites Crash During DDoS Attacks](https://fastnetmon.com/2025/07/15/fastnetmon-interviewed-by-website-planet-the-real-reason-websites-crash-during-ddos-attacks/) **Published:** July 15, 2025 **Author:** FastNetMon **Content:** **FastNetMon was recently featured in an interview with Website Planet, an expert blog focused on hosting, infrastructure, and web technologies.** In the conversation, our Founder Pavel Odintsov shares insights into the growing scale and speed of DDoS attacks, the limitations of traditional protection methods, and how automation is changing the landscape for network defense. When services go offline during a DDoS attack, it’s rarely due to application overload. The real failure typically occurs upstream—at the level of transit links, ISPs, or shared network infrastructure. Once these are saturated, even indirect targets can suffer from collateral damage and loss of service. The interview explores why legacy DDoS mitigation systems often fail to keep up. Many still rely on manual thresholds, delayed detection, or static rules that don’t match the pace of modern attacks. In today’s environment, any delay in response—even seconds—can result in service disruption, customer impact, and increased operational costs. Real-time detection and mitigation, implemented at the network edge, is now essential. FastNetMon is built for this exact purpose: continuously monitoring traffic patterns, identifying anomalies in seconds, and triggering automated mitigation before harmful traffic reaches its destination. The article also addresses the hidden costs of DDoS—particularly for providers billed by bandwidth—and outlines what network teams should look for in a modern defense strategy, from automation to multi-layer protection against a wide range of attack types. You can read the full article [here](https://www.websiteplanet.com/blog/fastnetmon-interview/). --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats.For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** Press & Newsroom **Tags:** press features --- ### [Meet the botnets breaking the Internet: Part 2](https://fastnetmon.com/2025/07/03/meet-the-botnets-breaking-the-internet-part-1/) **Published:** July 3, 2025 **Author:** FastNetMon **Content:** For over two decades, botnets have been at the heart of some of the most disruptive activity online - from large-scale DDoS campaigns to credential theft and malware distribution. While the end goals haven’t changed much, the technical machinery behind them has evolved in significant ways. In the first part of this learning series, we covered the basics of [what a botnet actually is](https://fastnetmon.com/2025/06/18/anatomy-of-a-botnet/). This blog offers a side-by-side view of how botnets have developed over time. We look at their infection strategies, command-and-control (C2) infrastructure, and the attack types they’re built to deliver. In the third part, we will cover some of the botnet evolution and discuss modern botnate architectures. ### **How did early botnets operate?** The earliest botnets made use of basic but effective building blocks: centralised control, insecure services like telnet, and often minimal obfuscation. **BASHLITE,** for example, was one of the first to exploit the Shellshock vulnerability and open telnet ports to conscript IoT devices into simple flood-based DDoS attacks. Its architecture was straightforward - infected devices reported back to an IRC or HTTP server that would broadcast commands. **GameOver Zeus,** on the other hand, introduced a more resilient model with its peer-to-peer (P2P) design. Rather than talking to a single C2 server, each infected node could forward commands and updates, making takedown attempts far more complex. It doubled as a loader for ransomware and financial malware, often stealing credentials before delivering a secondary payload. **Necurs** took a different route. Rather than relying on centralised or P2P infrastructure, it used a Domain Generation Algorithm (DGA) to dynamically produce lists of potential command-and-control domains. This made it difficult to block via static blacklists. Necurs was primarily used as a spam delivery engine, often pushing payloads like Dridex and Locky through massive email campaigns. It also supported malware loaders, giving it flexibility beyond pure spamming. **Emotet** started as a banking trojan but evolved into a modular platform that distributed other malware families, including TrickBot and Ryuk. It spread via malicious email attachments and used macros to establish footholds in corporate environments. Its infrastructure blended centralised control with fast-flux DNS, which rotated C2 endpoints rapidly to avoid detection and takedown. **Mirai**, which went public in 2016, made a name for itself by targeting IoT devices with default credentials. Its architecture remained centralised but modular, allowing attackers to push updates and switch between attack modes easily. Mirai's floods included SYN, UDP, HTTP, and even GRE-based vectors, making it one of the most versatile DDoS tools at the time. Each of these early botnets demonstrates a step forward in automation, resilience, or scalability. From simple command broadcasts to dynamic domain lookups and polymorphic loaders, attackers continued to iterate on what made previous generations work, while defenders played catch-up. The chart below illustrates the fundamental architecture and communication methods used by early botnets, highlighting their reliance on centralised control and unencrypted protocols. ![](https://fastnetmon.com/wp-content/uploads/2025/07/botnets_technical_overview-1024x337.png) The early botnets were noisy, largely unencrypted, and relatively easy to take down if the central C2 infrastructure was identified. But they worked - largely because devices were unpatched, unmonitored, and completely exposed to the public internet. ### **What are the botnets doing once deployed?** Early botnets typically stuck to simple tasks: spam, flooding, or keylogging. Modern botnets are more ambitious. They run layered attacks, mix DDoS with crypto mining, and often act as malware delivery systems for hire. Let’s take **Aquabot** and **GorillaBot** as examples. Aquabot targets Linux-based routers and cameras with UPnP and telnet vulnerabilities. Once inside, it launches HTTP/2 floods, a protocol-level attack that bypasses many legacy DDoS filters. GorillaBot, meanwhile, supports a wide array of DDoS vectors, from DNS amplification to TLS handshake abuse, and compiles itself for multiple chipsets to maximise coverage. Some, like **AIRASHI**, go further by mixing application- and transport-layer attacks, often launching Layer 7 floods that mimic legitimate browser behaviour. Others, such as **Matrix**, appear to target containers and virtual machines directly, suggesting an increasing focus on enterprise systems, not just consumer-grade hardware. Matrix doesn’t go after your average smart camera or dusty home router. It sets its sights higher - on servers and container platforms, the kind powering apps, cloud services, and virtual machines. First spotted in 2024, Matrix feels like a botnet built by someone who knows infrastructure. It quietly slips into Linux environments, often via misconfigured or unpatched systems. Its command network is scattered and encrypted, so even if you shut down one part, others keep running. Matrix is deliberate, but not chaotic. It doesn’t flood the internet just to make noise. Instead, it launches targeted, high-cost attacks - like overwhelming HTTPS connections or abusing HTTP/2 protocols, meant to drain resources and make services buckle under pressure. It’s less about brute strength and more about strategic disruption. And **Eleven11Bot**, by contrast, feels like a street brawler. It’s aggressive, loud, and has one goal: break in and hit hard. Surfacing in 2025, it’s been seen prowling the edges of the internet, finding overlooked HiSilicon-based devices (security cameras, DVRs, and cheap routers) and muscling its way in through weak login pages or insecure firmware. Once it’s in, the devices are quickly drafted into a fast-moving swarm that launches raw, overwhelming traffic toward whatever target the operator picks. There’s no elegance here, just relentless pressure. Eleven11Bot rotates its IPs, keeps the flood steady, and wears down defences over time. It’s the kind of threat that doesn’t need to be clever, just persistent enough to break through. ### **How has botnet architecture evolved?** Modern botnets have borrowed from both models. Some still rely on centralised infrastructure, often obfuscated or hidden behind DNS tunnelling and fast-flux domains. Others have gone fully P2P. Many now use encrypted channels, frequently rotate addresses, or layer their infrastructure across multiple regions and ISPs to slow down attribution and disruption. Mirai marked a turning point. Its source code was released in 2016 and led to an explosion of variants and derivatives. Written in C and designed for IoT environments, Mirai infected devices by brute-forcing default credentials. Its modular design and simple architecture made it easy to adapt and impossible to fully contain once the source was public. Today’s botnets often include their own update mechanisms, loaders for additional malware, and support for multiple CPU architectures (MIPS, ARM, x86). This allows them to target a much wider pool of devices, from routers and DVRs to NAS units and cloud instances. ### **How have botnets changed, and what are defenders up against today?** - More encrypted C2 traffic: Plain HTTP is out. Many modern botnets use custom protocols, TLS over non-standard ports, or tunnelled communications. - Multiple infection paths: They no longer rely solely on one vulnerability or service - brute-force, CVEs, phishing, and supply-chain compromise are all in play. - Self-updating code: Like software projects, many botnets now include their own patching systems or loaders that fetch new binaries. - Multi-platform support: They run on more than just Linux or Windows, targeting IoT firmware, Android, and virtualised environments as well. While early botnets were easy to fingerprint and block with signature-based tools, today’s variants often blend in with normal traffic. The traffic may be encrypted, the payload polymorphic, and the infrastructure decentralised or rapidly shifting. In part 3 of this learning series, we’ll dig into today’s most active botnet families and how they spread, what they target + why traditional defences are struggling to keep up. --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** FastNetMon Blog **Tags:** Botnets --- ### [Meet the Botnets Breaking the Internet: Part 3](https://fastnetmon.com/2025/07/15/meet-the-botnets-breaking-the-internet-part-3/) **Published:** July 15, 2025 **Author:** FastNetMon **Content:** **The Modern Era: from modular loaders to multi-vector flood engines** As defenders have become more aware of the classic tactics used by earlier botnets like BASHLITE, Mirai, and GameOver Zeus, threat actors have shifted focus to more resilient and evasive designs. In this second part of our botnet learning series, we explore how newer botnets – some active right now – are using encryption, peer-to-peer architecture, and multi-platform payloads to stay effective and hidden. This article is part of a learning series about botnets: - Part 1: [Anatomy of a Botnet](https://fastnetmon.com/2025/06/18/anatomy-of-a-botnet/) - Part 2:[ Early Botnets](https://fastnetmon.com/2025/07/03/meet-the-botnets-breaking-the-internet-part-1/): Analysis of infection methods, architecture and capabilities - Part 3: (This article) Modern botnets: modular loaders and multi-vector flood engines **How are modern botnets spreading?** Recent botnets tend to avoid single points of failure. Instead of relying on hardcoded command-and-control IPs or simple credential brute-forcing, they scan across device types (especially routers and IoT nodes), use domain generation or DNS tunnelling for persistence, and often support multiple CPU architectures from the outset - including ARM, MIPS, and x86. Modern botnets are harder to detect, harder to stop, and built for more than just volume. Unlike earlier waves that relied on brute-force floods, current variants are often cross-platform, encrypted, and designed to persist inside networks while generating revenue quietly. **Take PumaBot** as an example. It uses brute-force SSH attacks to break into Linux-based IoT devices. Once inside, it sets up encrypted control channels and repurposes the hardware for cryptomining, proxy traffic, or credential theft, all with minimal noise. **HTTPBot**, first seen in 2024, focuses on application-layer (Layer 7) DDoS. It targets smart devices and servers alike, delivering HTTP/2 floods that exhaust web-facing services. Written in Go, it’s fast, portable, and efficient. **Ballista** exploits known router vulnerabilities, like those in certain 2023 TP-Link models. Once installed, it hides behind Tor and enables remote control through an encrypted channel. It’s often used for targeted disruption or traffic manipulation. **Vo1d** takes aim at Android TV boxes, embedding itself via compromised firmware. These devices are then used for DDoS, ad fraud, or traffic redirection. It’s another reminder that consumer electronics are fully in scope for botnet operators. **Chaos** supports multiple platforms, including Windows and Linux, and comes with centralised C2 and support for cryptomining. Built in Go, it’s compact and easy to deploy across diverse environments. **FritzFrog** operates without central control. It spreads laterally using SSH and forms a peer-to-peer mesh network where each node can receive and forward commands. It mines crypto and resists takedown due to its decentralised structure. In short, today’s botnets combine stealth, persistence, and multi-purpose payloads. They don’t just flood, they adapt, hide, and monetise. **What architectures are we seeing now?** Where botnets once leaned on simple centralised infrastructure (e.g. IRC or HTTP C2s), today’s threats are more diverse. We’ve seen: • **Encrypted centralised C2s**: Like in **HTTPBot**, which sends Layer 7 flooding commands over encrypted TCP, using self-updating configurations to adapt its targeting. • **Decentralised P2P**: Seen in **FritzFrog**, which avoids a single C2 by relying on a peer-to-peer model over SSH. Each infected node acts as a relay, making detection and mapping far more complex. • **Hybrid control systems**: Used by **GorillaBot** and **AIRASHI**, combining central servers with encrypted relay layers or domain-fluxed C2 addresses to avoid IP blacklisting. These design choices show that evasion is now a key design principle for active botnet developers. **Are they harder to stop?** Yes, and not just because of encryption or P2P. Many modern botnets include self-patching mechanisms, obfuscate their binaries, and rotate infrastructure as frequently as possible. Infection rates have climbed due to the sheer number of exploitable consumer-grade devices now connected to the internet with poor configurations or no firmware updates. Botnets like **Chaos** and **AIRASHI** don’t just use new techniques , they also recycle old ones effectively. Weak SSH configurations, open Telnet, outdated firmware: these remain the low-hanging fruit. What’s changed is how quickly attackers can scale — and how long they can stay inside undetected. **What to expect next?** As we’ve seen from these charts, botnets are no longer simple DDoS engines, but evolving platforms with plugin-style payloads, and many of them operate as rented infrastructure in criminal marketplaces. The next wave will likely include more automation, better persistence, and deeper integration with AI-assisted reconnaissance. That’s not speculation as it’s already visible in leaked forums and in the design of loaders seen this year. If your defensive tools rely on fixed IP blocks or regex filtering alone, they’re going to fall behind. Real-time behavioural analysis, anomaly detection, and layered DDoS mitigation are now baseline requirements for any infrastructure with public exposure. --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** FastNetMon Blog **Tags:** Botnets --- ### [Europol Disrupts Notorious DDoS Group NoName057(16)](https://fastnetmon.com/2025/07/16/europol-disrupts-notorious-ddos-group-noname05716/) **Published:** July 16, 2025 **Author:** FastNetMon **Content:** In a major win for cybersecurity defenders across Europe, **Europol and Eurojust** have successfully coordinated an international operation—**[Operation Eastwood](https://www.europol.europa.eu/media-press/newsroom/news/global-operation-targets-noname05716-pro-russian-cybercrime-network)**—to disrupt the infrastructure and operations of the pro-Russian hacktivist group **NoName057(16)**. This group has been responsible for hundreds of DDoS attacks targeting critical infrastructure and institutions since the beginning of the war in Ukraine. ### **The Background: Weaponised Hacktivism** Launched in early 2022, NoName057(16) has weaponised distributed denial-of-service (DDoS) attacks as a form of [geopolitical cyber-propaganda](https://fastnetmon.com/2025/05/19/ddos-in-geopolitics-when-network-traffic-becomes-a-digital-weapon/). Their attacks have consistently aligned with Russian political interests, targeting European countries supporting Ukraine, as well as Israel and Ukraine itself. Their operations are largely crowdsourced via Telegram and the DDoSia software project, which enables volunteers to join attacks using their own devices. Victims have ranged from government ministries and media outlets to banks, power companies, and even NATO-affiliated organisations. ### **Operation Eastwood: A Coordinated Strike** On July 15, 2025, law enforcement agencies across 13 countries, including Germany, France, Finland and the US, executed a coordinated takedown of the group’s infrastructure. The operation resulted in: - **100+ servers** seized or taken offline - **Searches across 7 countries,** including Spain, Italy, and Poland - **2 arrests** and **7 European arrest warrants issued - **1,100 Telegram users and 17 admins** warned of criminal liability While most of the group's core leadership is believed to reside in Russia, this disruption sends a strong message that DDoS attacks—even under the banner of hacktivism—carry consequences. ![](https://fastnetmon.com/wp-content/uploads/2025/07/Europol-operation-eastwood-DDoS-hacktivist-group-NoName-disrupted-1024x576.jpg)Highlights of Operation Eastwood (Source: Europol)### **Why This Matters for Defenders** NoName057(16)'s campaign is a stark reminder of how geopolitical tensions now play out in cyberspace. Their strategy relies on amateur participation, decentralised tools, and speed—making them a difficult adversary to contain. This development also emphasises the importance of international collaboration in cybercrime enforcement. At FastNetMon, we welcome this joint action and see it as an opportunity for security teams to take stock of their DDoS defense readiness. ### **Is NoName057(16) now completely defeated?** Despite this victory, NoName057(16) has already resumed activities, continuing to claim new DDoS attacks as of today. While unfortunately, this is not the end of the story, it is an important milestone and a reminder for defenders: As cyber threats become more politically charged and globally distributed, **having reliable DDoS detection and response capabilities is your best defence**. --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** FastNetMon Blog **Tags:** DDoS News, legal --- ### [Making Sense of Network Traffic Visibility in Modern Infrastructure](https://fastnetmon.com/2025/07/31/making-sense-of-network-traffic-visibility-in-modern-infrastructure/) **Published:** July 31, 2025 **Author:** FastNetMon **Content:** In 2025, network traffic visibility isn’t just a technical requirement—it’s a strategic necessity. As networks grow in size and complexity, visibility has become critical to performance, security, and resilience. Without it, network engineers and security teams are flying blind in an environment that’s increasingly fast, fragmented, and encrypted. In this blog post, we’ll break down: - What modern network traffic visibility means - How the latest trends in observability are reshaping the space - Key challenges organisations face in 2025 - How FastNetMon helps you achieve scalable, real-time visibility at speed ## What Is Network Traffic Visibility? Network traffic visibility is the ability to monitor, analyse, and act on the data flowing through your network in real time. It gives you situational awareness across your infrastructure—whether on-prem, in the cloud, or at the edge. At its core, visibility helps you: - Detect and mitigate threats before they cause disruption - Optimise performance by identifying bottlenecks or misconfigurations - Investigate incidents quickly with historical traffic data - Comply with security and regulatory frameworks like NIST or ISO 27001 In 2025, visibility goes beyond flow records and SNMP polling. It means understanding what’s happening at every layer—from endpoints to services to user behavior—across an ever-expanding mix of technologies. ## Why Visibility Has Gotten Harder Today’s networks are anything but simple. The following trends have made traditional visibility tools and methods less effective: - Encryption everywhere: Over 90% of enterprise traffic is encrypted using protocols like TLS 1.3 and QUIC, limiting the usefulness of payload inspection. - Cloud-native complexity: Microservices, Kubernetes, and service meshes introduce east-west traffic that often bypasses traditional monitoring tools. - Hybrid infrastructure: With workloads spanning cloud, on-prem, and edge, gaining end-to-end visibility is more challenging than ever. - Data volume explosion: High-fidelity monitoring can generate terabytes of flow and packet data per day, straining storage and analysis pipelines. Put simply: the more distributed and encrypted your network becomes, the more sophisticated your visibility solution needs to be. ## What’s New in Network Traffic Visibility (2025 Edition) To meet these challenges, organisations are turning to a new generation of observability tools and practices. Here are the key developments shaping the space in 2025: ### 1. Flow-Based Visibility with Enriched Context NetFlow, IPFIX, and sFlow remain foundational for scalable monitoring. But today’s tools enrich these flow records with metadata—like geolocation, AS numbers, TLS fingerprints, or BGP info—to unlock deeper insights. FastNetMon excels here: We ingest flow data from all major vendors and enrich it in real time, helping you identify anomalous patterns, trace attack sources, and make faster decisions. ### 2. Encrypted Traffic Analytics Full payload inspection isn’t feasible or legal in many contexts. Instead, visibility tools are now using: - TLS fingerprinting (JA3/JA4) to classify applications without decryption - Flow-based heuristics and ML to detect threats within encrypted traffic - Metadata analysis to track suspicious behavior without touching sensitive content FastNetMon supports JA3 detection, making it easier to classify traffic and spot anomalies—while remaining compliant with privacy regulations. ### 3. Programmable Observability With APIs and infrastructure-as-code now standard, visibility tools must be programmable and integrable. Engineers want to automate alerting, reporting, and mitigation through CI/CD pipelines and monitoring platforms. FastNetMon delivers: - REST APIs for automation - SQL-based dashboards - Export to tools like ClickHouse, Prometheus, InfluxDB, and more This allows you to plug FastNetMon directly into your observability stack—whether you’re running a NOC, SOC, or both. ### 4. Cloud-Ready, Edge-Aware Hyperscalers offer native traffic mirroring (like AWS VTAPs or Google Packet Mirroring), but they often lack full visibility and control. In hybrid or edge deployments, gaps in visibility can become blind spots attackers exploit. FastNetMon helps fill these gaps by offering consistent, flow-based visibility across distributed environments. Whether you're monitoring cloud workloads, core routers, or IoT edge networks, FastNetMon helps you maintain visibility without adding complexity. ## Challenges You’ll Face—and How to Prepare Even with the right tools, visibility comes with its own challenges. Here's how to think about them in 2025: - Scale: Visibility at 100 Gbps+ requires high-performance processing and storage. FastNetMon is optimised for massive scale, using ClickHouse to store and query petabytes of data without slowing down. - Fragmentation: Different environments (cloud, on-prem, containers) often require different monitoring approaches. FastNetMon provides a central point of flow aggregation and enrichment—helping unify your visibility layer. - Compliance: Regulations like GDPR, HIPAA, and national cybersecurity laws require strict controls over traffic monitoring. FastNetMon supports role-based access, granular data retention policies, and visibility without payload inspection. ## Why FastNetMon? At FastNetMon, we’ve built our platform from the ground up for visibility at speed and scale. Here's what sets us apart: - Real-time DDoS detection in under 2 seconds - Support for NetFlow, sFlow, IPFIX, and custom input formats - Unlimited flow storage using ClickHouse for long-term analysis - Custom dashboards and reports, written in SQL - BGP Blackhole and FlowSpec automation for instant response - TLS fingerprint detection (JA3) for encrypted traffic observability - Integration with Prometheus, Grafana, Elastic, InfluxDB, and more Whether you’re protecting a Tier 1 ISP, monitoring a government network, or managing multi-cloud infrastructure, FastNetMon helps you see clearly, respond quickly, and stay ahead of threats. ## Final Thoughts: Visibility Is the New Control Plane In 2025, network traffic visibility is more than just a defensive tool—it’s the foundation for control. From performance optimisation to cyber defense, every decision starts with knowing what’s happening in your network.If you're ready to upgrade your visibility stack, explore how FastNetMon can support your goals. [Start a free](https://fastnetmon.com/trial/) trial today or [reach out to our team](mailto:sales@fastnetmon.com) for a tailored demo. **Categories:** FastNetMon Blog **Tags:** Network Security Insights --- ### [Understanding Volumetric & Amplification DDoS Attacks](https://fastnetmon.com/2025/07/30/understanding-volumetric-amplification-ddos-attacks/) **Published:** July 30, 2025 **Author:** FastNetMon **Content:** ## How bandwidth-focused DDoS campaigns work—and why they’re still effective at scale Volumetric DDoS attacks remain one of the most common and disruptive forms of denial-of-service activity across the internet. Despite evolving tactics, the core objective is the same: exhaust the network capacity of a target by overwhelming it with traffic. This article explores how volumetric attacks work, how amplification plays into them, and what defenders should understand when detecting and mitigating these threats. *This article is part of a longer series of articles about different types of DDoS attacks. If you’re new here, have a look at our* [*DDoS taxonomy*](https://fastnetmon.com/2025/07/25/classification-of-ddos-attacks-every-modern-ddos-attack-vector-explained/) *to start with a solid understanding of how volumetric and amplification attacks fit into the wider DDoS attack landscape.* ### What Is a Volumetric DDoS Attack? A **volumetric DDoS attack** aims to consume the bandwidth of the target system—or its upstream providers—by sending overwhelming amounts of data. These attacks are designed to [flood the network layer (Layer 3)](https://fastnetmon.com/2025/03/11/layer-3-ddos-attacks-explained/) and transport layer (Layer 4), effectively clogging all available capacity. This approach doesn’t try to exploit application vulnerabilities. Instead, it focuses on brute-force disruption of internet connectivity. ### How Volumetric Attacks Work At their core, volumetric attacks use large volumes of packets—often from distributed sources—to saturate links and infrastructure. The most common mechanisms include: #### **UDP Flood** A **UDP flood** sends large numbers of User Datagram Protocol packets to random or targeted ports on the victim’s IP address. Because UDP is stateless, the server either processes the traffic or responds with ICMP Destination Unreachable messages, consuming additional resources. #### **ICMP Flood (Ping Flood)** This method sends a large number of ICMP Echo Request (ping) packets, often targeting infrastructure or endpoints directly. Some variants use broadcast addresses to generate amplified ICMP replies to the spoofed victim IP. #### **TCP-Based Floods** While not as common in pure volumetric campaigns, **TCP SYN floods** and **RST floods** can be used to consume state on connection tables, especially if combined with other tactics. ### Key Characteristics Here are some of the common characteristics of volumetric attacks: | Feature | Description | |---|---| | **Attack Goal** | Maximize traffic volume to saturate bandwidth | | **Measurement** | Typically in Gbps or packets per second (pps) | | **Common Protocols** | UDP, ICMP, TCP SYN | | **Botnet Requirement** | Usually requires high-scale distributed traffic sources | | **Mitigation Challenge** | Volume alone can overwhelm links before deeper filtering can take place | ### Amplification: A Subclass of Volumetric Attacks **Amplification attacks** are a more efficient variant of volumetric DDoS. Rather than sending large volumes directly, attackers send small, spoofed requests to vulnerable third-party servers, which then respond with much larger replies to the target. This allows an attacker to multiply their outbound bandwidth—turning a small investment into a massive flood. #### How Amplification Works (Step-by-Step) 1. **Spoofed Source**: Attacker sends a forged request with the victim's IP address. 2. **Open Service Responds**: Vulnerable server replies with a much larger response. **Victim Flooded**: The response is directed to the victim, consuming their bandwidth. ### Common Amplification Vectors Here are some of the most common amplification vectors explained, with their typical amplification ratio: | Protocol/Service | Vector Description | Amplification Ratio (Typical) | |---|---|---| | **DNS** | Queries (e.g., ANY/TXT) sent to open resolvers | 30x–100x | | **NTP** | Abuse of the `monlist` command | 20x–200x | | **Memcached** | Spoofed queries result in multi-megabyte responses | Up to 50,000x | | **CLDAP / SSDP** | Lightweight protocols with poor access controls | 50x–70x | These services are often exposed due to misconfiguration or legacy deployments. Their amplification ratios depend on response size vs request size. ### Real-World Example: DNS Amplification A typical DNS amplification attack might involve: - Sending a **60-byte ANY-type DNS query** to an open resolver, spoofing the victim’s IP. - The resolver responds with a **4,000-byte DNS response**. - Amplification ratio: **≈ 67×**. With just **1 Gbps of spoofed queries**, an attacker could generate **67+ Gbps** of inbound traffic directed at the victim. ### Volumetric vs Amplification: Key Differences It’s important to note: **all amplification attacks are volumetric**, but not all volumetric attacks involve amplification. Below are some of the key technical differences listed. | Characteristic | Volumetric Attack | Amplification Attack | |---|---|---| | **Traffic Source** | Direct from attacker (often via botnet) | Reflected from third-party servers | | **Spoofing Required** | Optional | Required | | **Efficiency** | Low (relies on raw scale) | High (relies on protocol weaknesses) | | **Detection Clues** | Large traffic volumes, many sources | High-volume responses from known reflectors | | **Mitigation Approach** | Rate-limiting, filtering, blackholing | Reflection-aware filtering, IP reputation, Flowspec rules | Detection and Defence: What Matters Most To effectively mitigate these attacks in real time, defenders need: - **Protocol and Port-Level Visibility**: Identify abnormal surges in traffic types (e.g., UDP/123, UDP/53). Have a look at FastNetMon’s network visibility tools [here](https://fastnetmon.com/traffic-visibility/). - **Per-IP and Per-Prefix Thresholds**: Customise detection rules for bandwidth, packet rate, and flow count per asset. Read our guide on setting thresholds [here](https://fastnetmon.com/2025/07/02/how-to-set-a-threshold-for-rtbh-bgp-blackhole-a-practical-guide-to-threshold-based-ddos-defence/). - **Anomaly Detection**: Spot deviations from baseline traffic—especially relevant for low-and-slow or spread-out (carpet bombing) attacks. - **Reflection Pattern Awareness**: Recognise common amplification signatures (e.g., many unsolicited DNS responses). - **Automated Mitigation Tools**: BGP blackholing, Flowspec filtering, and integration with inline scrubbing or firewalls. Have a look at FastNetMon’s stack [here](https://fastnetmon.com/ddos-detection-and-mitigation/). Fast detection and precise reaction are critical. Bandwidth exhaustion can happen in seconds once a volumetric campaign starts. ### Summary Volumetric and amplification attacks continue to dominate the DDoS landscape due to their simplicity, scalability, and ability to take networks offline without exploiting application logic. - **Volumetric attacks** rely on high packet volume to flood links directly. - **Amplification attacks** abuse misconfigured third-party services to dramatically increase attack size. - A strong DDoS defence strategy requires r**eal-time traffic analytics, dynamic thresholds, and automated mitigation methods** that respond in seconds. Want a full understanding of different DDoS attack types and how to defend agains them? Continue reading our article for [a full DDoS classification](https://fastnetmon.com/2025/07/25/classification-of-ddos-attacks-every-modern-ddos-attack-vector-explained/). --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** FastNetMon Blog **Tags:** classification --- ### [Understanding Transport and State-Exhaustion DDoS Attacks](https://fastnetmon.com/2025/08/12/understanding-transport-and-state-exhaustion-ddos-attacks/) **Published:** August 12, 2025 **Author:** FastNetMon **Content:** How connection state exhaustion attacks threaten your firewalls and proxies Transport and state-exhaustion DDoS attacks represent a growing and sophisticated category of denial-of-service threats targeting the resource limitations of network infrastructure. Instead of flooding bandwidth, these attacks exploit the costly state and CPU resources needed to manage connections and sessions in firewalls, proxies, load balancers, and servers. This article breaks down how these attacks work, their evolving vectors, and key considerations for detection and mitigation. This article is part of a longer series about different types of DDoS attacks. If you’re new here, start with our[ DDoS taxonomy](https://fastnetmon.com/2025/07/25/classification-of-ddos-attacks-every-modern-ddos-attack-vector-explained/) to understand how transport and state-exhaustion attacks fit within the broader DDoS landscape. ## What are Transport and State-Exhaustion Attacks? Transport and state-exhaustion attacks are closely related but distinct classes of DDoS threats targeting connection management rather than bandwidth: - **Transport Attacks** focus on abusing transport-layer protocols like TCP and QUIC. They disrupt connection establishment, teardown, or handshake processes. Examples include SYN floods and spoofed TCP reset floods. - **State-Exhaustion Attacks** target the stateful resources that devices allocate for connection tracking, such as memory, CPU, and connection tables. By creating numerous half-open, stalled, or malformed connections, these attacks deplete critical infrastructure capacity. Though interrelated (transport attacks often cause state exhaustion), the distinction clarifies attack mechanics and informs mitigation strategies. ## Why Transport & State-Exhaustion Attacks Matter Unlike volumetric floods that overwhelm bandwidth pipes, these attacks exploit the asymmetric cost of connection management. Small volumes of malicious traffic can trigger disproportionate resource consumption in stateful devices like firewalls, proxies, and application servers, leading to outages or degraded service. These attacks can be stealthier and more complex to detect, as they may generate moderate traffic while causing an outsized impact by exhausting CPU, memory, or connection tables. ## Common Attack Vectors and Their Impact In the table below, we summarise some of the most common transport and state-exhaustion attack vectors observed in the wild. For each, we highlight the targeted protocol layer, notable peak attack metrics, and the core resource or mechanism being exploited. This overview provides a quick reference to understand the diversity and impact of these threats. | Attack Type | Layer | Description | Notable Peak Impact | Resource Targeted | |---|---|---|---|---| | SYN Flood | 3/4 | Floods half-open TCP connections by sending SYN packets without completing handshake | 4.2 Tbps seen | Half-open TCP connection queue | | TCP Reset Flood | 4 | Spoofs TCP RST packets to tear down legitimate sessions prematurely | 11 Mpps observed | Session teardown | | HTTP/2 Rapid Reset | 7 | Sends excessive RST\_STREAM frames to stall backend processing | 398M resets per second (2023) | Backend thread pool exhaustion | | HTTP/2 Continuation | 7 | Sends endless CONTINUATION frames without END\_HEADERS flag, causing memory and CPU exhaustion | Proof of concept (2024) | Memory overflow, CPU spike | | QUIC-Loris Initial Flood | 4/7 | Abuses QUIC 0-RTT handshake loops causing high CPU load | High CPU load (2025) | CPU exhaustion during handshake | | gRPC SETTINGS/HPACK | 7 | Sends continuous SETTINGS frames and abuses header compression to stall applications | Ongoing since 2019–2024 | Application stall | | IP Fragment Overlap | 3 | Sends overlapping IP fragments to exhaust reassembly buffers | 80 Gbps observed | Buffer overflow | | Pulse-Wave Modulation | Meta | Alternates bursts and silence to evade detection | 300–350 Gbps bursts (2024) | Evasion of baseline detection | How These Attacks Work: Transport vs. State Exhaustion - **Transport attacks** like SYN floods overwhelm the TCP handshake process by flooding servers with SYN packets, leaving many half-open connections that consume resources. - **TCP Reset floods** use spoofed RST packets to abruptly terminate legitimate connections, disrupting service with low bandwidth. - **State-exhaustion attacks** at Layer 7 abuse protocol features to force servers and proxies into high CPU or memory consumption. For example, HTTP/2 Rapid Reset floods generate massive stream resets that stall backend threads. - QUIC-Loris exploits incomplete QUIC handshakes to spike CPU usage on proxies. - gRPC abuses SETTINGS frames and header compression to exhaust application processing power. - Pulse-wave modulation alternates high attack bursts and silence to evade rate-based anomaly detection. ## Real-World Examples - The **2023 HTTP/2 Rapid Reset attack** generated nearly 400 million stream resets per second, overwhelming backend servers without breaching TCP connection limits. - **QUIC-Loris**, discovered in 2025, showed how QUIC handshake loops can cause high CPU usage on proxies, leading to denial of service. - Classic **SYN floods** have reached peaks of multiple terabits per second and remain a major vector, often combined with amplification for scale. ## Key Differences Between Transport and State-Exhaustion Attacks To better understand how transport-layer attacks differ from state-exhaustion attacks, the table below outlines their key characteristics side-by-side. | Aspect | Transport Attacks | State-Exhaustion Attacks | |---|---|---| | Primary Target | Transport protocols (TCP, QUIC) | Stateful device/application resources | | Attack Mechanism | Disrupting connection setup or teardown | Consuming memory, CPU, or state tables | | Traffic Volume | Moderate to high | Moderate but resource-intensive | | Detection Difficulty | Moderate (signatures possible) | High (behavioral/anomaly detection) | Mitigation Strategies for Transport and State-Exhaustion Attacks Transport and state-exhaustion DDoS attacks target the resource-intensive connection and session management mechanisms in network devices and servers. Mitigating these sophisticated attacks requires a layered approach combining network-level defences, protocol hardening, and application-aware protections. **Network-Level Defenses** - **Flow-Based Anomaly Detection:** Tools like FastNetMon leverage NetFlow, IPFIX, and sFlow telemetry to [monitor connection rates, session counts, and protocol-specific anomalies](https://fastnetmon.com/traffic-visibility/). Customizable thresholds enable early detection of unusual spikes indicative of SYN floods, TCP reset floods, or HTTP/2 rapid resets. - **Automated Mitigation:** FastNetMon supports integration with network infrastructure to trigger reactive measures such as [BGP blackholing](https://fastnetmon.com/bgp-blackhole-automation/) or [BGP Flowspec filtering](https://fastnetmon.com/flowspec-ddos-mitigation/). These actions help drop attack traffic upstream, reducing the load on firewalls and proxies. - **[Rate Limiting and Connection Controls](https://fastnetmon.com/2025/07/02/how-to-set-a-threshold-for-rtbh-bgp-blackhole-a-practical-guide-to-threshold-based-ddos-defence/):** Implementing per-IP connection limits and request rate caps at the network edge reduces the risk of state table exhaustion. **Protocol and Application Hardening** - **Stateless TCP Defences:** Techniques like SYN cookies prevent resource allocation until TCP handshakes are completed, effectively mitigating SYN flood attacks. - **QUIC and HTTP/2 Protections:** Enforcing frame size limits, connection limits, and retry token usage helps prevent abuse of modern protocols vulnerable to state exhaustion. - **Server and Proxy Configuration:** Tuning timeout values, limiting simultaneous connections per client, and monitoring for suspicious HTTP/2 or gRPC frame patterns improve resilience against higher-layer state attacks. **Application-Layer Protections** While [FastNetMon](https://fastnetmon.com/) excels at network-level detection and mitigation, defending against state-exhaustion attacks targeting application servers and proxies often requires specialised application-layer defences, including: - Application-specific rate limiting and challenge-response mechanisms. - Web Application Firewalls (WAFs) with protocol-specific filtering. - Deep packet inspection and behavioural analytics. ## Conclusion Transport and state-exhaustion DDoS attacks exploit connection management weaknesses and resource limitations rather than raw bandwidth. Their increasing sophistication at Layer 7 demands layered defence strategies combining stateless filtering, rate limiting, anomaly detection, and infrastructure robustness. *Want a full understanding of different DDoS attack types and how to defend against them? Continue reading our* [*full DDoS taxonomy article*](https://fastnetmon.com/2025/07/25/classification-of-ddos-attacks-every-modern-ddos-attack-vector-explained/) *to explore the entire landscape of attacks and defence techniques.* --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** FastNetMon Blog **Tags:** classification --- ### [Classification of DDoS attacks: every modern DDoS attack vector explained](https://fastnetmon.com/2025/07/25/classification-of-ddos-attacks-every-modern-ddos-attack-vector-explained/) **Published:** July 25, 2025 **Author:** FastNetMon **Content:** ## A practical breakdown of DDoS attack vectors, built for network operators When your NOC wallboard lights up red, you don’t have 5 seconds. And if you’re relying on manual triage at that point, it is a tough job. Ideally, you’ve preloaded mitigation rules for the most common vectors. But when something new slips through, classification still matters. Knowing *what kind of attack* you’re seeing—and *what response path* to trigger—can make the difference between a minor incident and a major outage. This guide acts as your mental model and checklist for exactly that moment. It helps turn reactive scrambling into repeatable, automatable playbooks. In 2025, the attack surface is broader than ever. Cloudflare reported [7.3 Tbps / 4.8 Bpps network floods in Q2 2025](https://fastnetmon.com/2025/06/23/internet-under-fire-analysis-of-the-record-breaking-7-3-tbps-ddos-attack/), while Google weathered a 398 million RPS HTTP/2 Rapid Reset storm. The techniques are evolving—and so should your defence logic. ## FastNetMon’s DDoS Taxonomy We group attacks by what they try to break: | Group | What it targets | Key question | |---|---|---| | [A. Volumetric / Amplification](https://fastnetmon.com/2025/07/30/understanding-volumetric-amplification-ddos-attacks/) | Links, NICs, routers | Will it fill my pipes? | | [B. Transport / State-Exhaustion](https://fastnetmon.com/2025/08/12/understanding-transport-and-state-exhaustion-ddos-attacks/) | Firewalls, proxies, OS stacks | Will it kill my state tables? | | C. Application / Resource Abuse | CPUs, databases, APIs | Will it burn my backend? | | D. Stealth / Modulation Techniques | Detection heuristics | Will it evade thresholds? | ## A. Volumetric & Amplification Attacks **Will it fill my pipes?** | Vector | Proto / Port | Typical Amp. | Record Size | Short Mechanics | |---|---|---|---|---| | DNS amplification | UDP/53 | ≤70× | 1.3 Tbps | Spoofed ANY/TXT to open resolvers | | NTP MONLIST | UDP/123 | 200–500× | 400 Gbps | Server replies with 600 host list | | CLDAP | UDP/389 | 56–70× | 70 Gbps | Conn-less LDAP reply | | SSDP / UPnP | UDP/1900 | 20–30× | 112 Gbps | Spoofed M-SEARCH to IoT | | Memcached | UDP/11211 | 10,000–51,000× | 1.7 Tbps | Cached payload dump | | Jenkins discovery | UDP/3283 | 20–100× | Growing fast | Multicast reflection | | RIPv1 | UDP/520 | 10–20× | 0.5 Tbps | Routing table spoof | | QUIC broadcast | UDP/443 | 8–30× + CPU | Emerging | One Initial pkt → many workers | | TCP middlebox refl. | TCP/80,443 | 2–75× | 11 Gbps | Proxy rejects reflected | | TCP SYN-ACK refl. | TCP/\* | 5–50× | Common | LB SYN-ACKs on spoofed SYNs | | Smurf / Fraggle | ICMP / UDP/7 | 2–5× | Rare | Broadcast echo/reply | ### Understanding Volumetric Attacks Volumetric and amplification-based DDoS attacks are designed to consume network bandwidth, often overwhelming routers, switches, and firewalls before the traffic even hits your application layer. These attacks exploit open or misconfigured servers to amplify small requests into massive payloads directed at a victim. Classic UDP-based amplifiers such as DNS, NTP, and CLDAP are still widely abused due to their high amplification factors and continued presence in legacy systems. More recent additions like Memcached offer staggering amplification ratios, with single-packet queries returning hundreds of kilobytes. A newer trend is the exploitation of protocols that were not traditionally seen as reflective, such as QUIC. By abusing initial handshake behavior or load-balancer misconfigurations, attackers can trigger wide amplification patterns that include CPU burn, not just bandwidth floods. **Carpet-bombing** is an increasingly common stealth technique. Instead of flooding a single IP, attackers distribute packets evenly across entire IP blocks—such as a /24—making per-host traffic appear benign, while the total volume exceeds hundreds of Gbps. This method bypasses many per-IP detection thresholds and demands broader visibility to detect. The key defence here is network-layer filtering using [BGP Flowspec](https://fastnetmon.com/flowspec-ddos-mitigation/), access control lists (ACLs), and upstream [scrubbing providers](https://fastnetmon.com/ddos-scrubbing-centre-diversion/). Detection must go beyond absolute volume and account for protocol anomalies and dispersion patterns. To understand volumetric and amplification attacks in more detail, read [this complete guide](https://fastnetmon.com/2025/07/30/understanding-volumetric-amplification-ddos-attacks/). ## B. Transport & State-Exhaustion Attacks **Will it kill my firewalls or proxies?** | Attack | Layer | CVE / Year | Peak Seen | Core Abuse | |---|---|---|---|---| | SYN flood | 3/4 | — | 4.2 Tbps | Half-open queue exhaustion | | TCP Reset flood | 4 | — | 11 Mpps | Spoofed RST tears down sessions | | HTTP/2 Rapid Reset | 7 | 2023 | 398M rps | RST\_STREAM spam to hold conn | | HTTP/2 Continuation | 7 | 2024 | PoC → OOM | Infinite CONTINUATION frames | | QUIC-loris (Initial flood) | 4/7 | 2025 | High CPU | 0-RTT handshake loops | | gRPC SETTINGS/HPACK | 7 | 2019–2024 | App stall | SETTINGS loop + header abuse | | IP fragment overlap | 3 | — | 80 Gbps | Reassembly buffer overflow | | Pulse-wave modulation | meta | 2024 | 300–350 Gbps | On/off bursts defeat baselines | ### Understanding State-Exhaustion Attacks These attacks exploit the asymmetric cost of maintaining connection state. A small number of malicious packets can consume disproportionately large amounts of CPU, memory, or table entries in firewalls and proxies. SYN floods remain a classic and effective attack by filling up the half-open TCP connection queue. Meanwhile, TCP Reset floods tear down legitimate sessions by spoofing RST packets, disrupting user experience without consuming significant bandwidth. State-exhaustion attacks have evolved to layer 7, with HTTP/2 being the prime target. The Rapid Reset vulnerability, for instance, enables a client to reuse a single TCP connection to generate millions of stream resets, effectively stalling backend thread pools while staying under protocol stream limits. QUIC and gRPC are also vulnerable, often by abusing handshake flows or metadata processing logic. These attacks tend to result in CPU spikes or thread starvation in proxies and load balancers. Pulse-wave modulation—a modulation technique where attackers alternate between bursts and silence—makes these attacks harder to detect using baseline rate thresholds. For mitigation, consider stateless defenses such as SYN cookies, QUIC retry tokens, header-size caps, and connection rate limits per source IP. To understand transport and state exhaustion attacks in more detail, read [this complete guide](https://fastnetmon.com/2025/08/12/understanding-transport-and-state-exhaustion-ddos-attacks/). ## C. Application-Layer & Low-and-Slow Attacks **Will it burn my CPUs or databases?** | Vector | Metric | Trick | Target Environment | |---|---|---|---| | HTTP GET/POST flood | Up to 200M rps | Bot swarms with cache-bust params | E-commerce, fintech | | Slowloris / slow POST | <1 Mbps stalls | Partial headers/bodies | Apache, Nginx | | GraphQL introspection | 1–10k rps | 1000+ directives or recursion | API backends | | WebSocket flood | 100k conn/s | Chat open + discard frames | Gaming, social | | gRPC ping-pong | Few k rps | Keep-alive + metadata loop | Microservice meshes | | Login/cache-bust spray | 10–40k rps | Unique queries bypass CDN | SaaS, portals | | Prefix-scatter L7 | 1–2k rps/IP | Same req across /24 | Hosting infra | ### Understanding Application-Layer Abuse Layer-7 attacks focus on CPU, memory, and application logic, often flying under the radar of volumetric detection systems. These vectors abuse HTTP, WebSocket, GraphQL, and gRPC to exhaust server resources. The simplest form is an HTTP GET or POST flood, often using browser-like bots with randomised headers or query strings that bypass caching layers. Slowloris-style attacks consume sockets by sending partial HTTP headers or bodies at a trickle. Modern APIs introduce new risks. GraphQL introspection queries can trigger deep recursion with minimal input. gRPC SETTINGS floods and header compression loops are capable of stalling or crashing backend services even with low RPS. Layer-7 vectors are particularly dangerous due to their low bandwidth profile, often staying under traditional detection thresholds. Furthermore, CDN and WAF layers are not immune, especially when attackers vary queries to force cache misses. To mitigate, deploy dynamic rate-limiting per endpoint, enable CAPTCHA and authentication challenges, use circuit breakers, and enforce schema/query depth limits on APIs. ## D. Emerging and Evasive Techniques Several trends in DDoS evolution demand attention: - **IPv6 Reflection**: Over 3,500 ASes expose v6 amplifiers. Source validation (SAV) is lacking in over 60% of them. - **WebTransport & WebRTC Abuse**: TURN relays can reflect traffic with 10–15× amplification. Early PoCs already exist. - **AI-Powered Bots**: Attackers now emulate real browser behavior—jitter, headers, cookie use—making them harder to filter. **Modulation techniques** such as carpet-bombing and pulse-wave attacks further complicate detection. These methods spread load across the address space or time to evade traditional alerts based on volume or sustained rates. Detection systems must evolve to correlate traffic patterns across subnets, monitor time-based anomalies, and analyse protocol behaviour at the application layer. ## How to Use This Taxonomy in Real Incidents | Symptom | Likely Vector | Lookup Table | |---|---|---| | Huge PPS on one port | Amp/reflection | Table A | | High conn/sec, low bandwidth | State exhaustion | Table B | | Backend 500s, normal NetFlow | Application abuse | Table C | **Mitigation Matchups:** | Attack Class | Mitigation Strategy | |---|---| | Volumetric | BGP Flowspec, scrubbing, ACLs | | State Exhaustion | Protocol hardening (SYN cookies, stream caps) | | Application | Dynamic rate-limiting, query caps, circuit breakers | Detection systems should be updated with heuristics for: - **Carpet-bombing**: Multi-IP floods per /24 or /22 - **Pulse-wave**: High-frequency burst/idle cycles ## Summary: Know the Beast, Load the Bullet - Reflection attacks are evolving—QUIC and TCP are viable amplifiers now. - Protocol design flaws (e.g., HTTP/2, gRPC) drastically increase DDoS efficiency. - Low-and-slow vectors remain potent, especially against APIs. - IPv6 will be the next hot zone—start enabling uRPF and source validation today. Stick this post on your team wiki. When the next flood hits, you’ll know what you’re facing—and exactly how to respond. Happy packet herding! --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** FastNetMon Blog **Tags:** classification --- ### [How to defend against a DDoS attack?](https://fastnetmon.com/2025/08/19/how-to-defend-against-a-ddos-attack/) **Published:** August 19, 2025 **Author:** FastNetMon **Content:** ## DDoS defence explained: how to detect and mitigate a DDoS attack? DDoS attacks are easier than ever to launch, harder to trace, and can cause real damage if you're not prepared. The end result is typically the same: your users can’t reach you or your systems are unavailable. This article is a starting point. We’ll walk through what DDoS actually is and how to detect one, how different types of attacks behave, and what you can do to defend against them. All backed by hands-on experience and technical guidance we’ve collected over the years at [FastNetMon](https://fastnetmon.com/). ### **1. Understand the threat** Begin with knowing [*what a DDoS attack is*](https://fastnetmon.com/2025/08/05/what-is-a-ddos-attack-history-motives-and-methods-explained/): a flood of traffic directed at a system from multiple sources aiming to overload bandwidth, exhaust connection tables, or hog application resources. Some of the most common attack vectors include: - UDP floods, DNS or NTP amplification - SYN floods and TCP state exhaustion - HTTP/POST floods, Slowloris-style attacks - Slow or bursty traffic patterns designed to bypass thresholds Understanding the[ types of attacks](https://fastnetmon.com/2025/07/25/classification-of-ddos-attacks-every-modern-ddos-attack-vector-explained/) will help you map your attack surface and set up the correct defence mechanisms for your infrastructure. ### **2. Set up traffic monitoring and threshold detection** Visibility is the foundation. Collect traffic data using[ flow telemetry](https://www.youtube.com/watch?v=6SfT1h9OpTE) (NetFlow, IPFIX or sFlow), or via inline monitoring tools. Establish baselines for normal traffic - pps, Mbps, flows per second. When thresholds are exceeded, an alert or mitigation plan should trigger immediately. Static thresholds may work in some cases, but consider grouping hosts with similar patterns or important profiles to manage thresholds more accurately. ### **3. Use threshold‑based mitigation (RTBH / Blackholing)** A [BGP BlackHole](https://fastnetmon.com/2024/12/07/bgp-blackhole-automation-for-ddos-mitigation/) is a routing technique that serves as an effective and affordable method for mitigating DDoS attacks. As the name suggests, “blackholing” network traffic makes it disappear without a trace, which is a very desirable outcome for malicious traffic. For high-volume L3/L4 attacks,[ threshold-based blackholing](https://fastnetmon.com/2025/07/02/how-to-set-a-threshold-for-rtbh-bgp-blackhole-a-practical-guide-to-threshold-based-ddos-defence/) can be a fast and effective response. Once an offending IP crosses a defined limit, route it to a null‑route (Null0) via BGP, effectively discarding all traffic for that address or prefix Ideal conditions: - Massive packet rate to a single IP or small prefix - Non-critical service or external-facing infrastructure - Immediate suppression is needed before attack traffic saturates shared resources Be aware: this blocks all traffic to/from a target, including legitimate users. To understand when blackholing is a good mode of defence - and when it is not, [read this article](https://fastnetmon.com/2025/06/18/when-is-bgp-blackholing-a-good-choice-for-ddos-mitigation-and-when-is-it-not/). ### **4. Apply granular filtering (BGP Flow Spec)** When attacks target critical services or aim to exploit specific protocols, use[ Flow Spec](https://fastnetmon.com/2025/02/10/bgp-flow-spec-for-ddos-mitigation/) based traffic filtering. Flow Spec enables control over traffic by matching ports, IPs, TCP flags or other packet attributes, and discarding only selected flows. Flow Spec advantages: - Precise mitigation without full service interruption - unlike blunt tools like full blackholing, Flow Spec lets you surgically remove malicious traffic by filtering on specific characteristics (e.g. a port or flag), while letting legitimate traffic pass through. Critical services are more likely to remain available during an attack. - Rapid deployment once an attack signature is confirmed - Flow Spec rules can be pushed across your network in seconds. As soon as an attack pattern is identified, whether it's a UDP flood targeting port 53 or a TCP SYN attack, filters can be activated almost instantly, minimising response time. - Minimal collateral impact on network or user experience - because rules are narrowly tailored, you avoid over-blocking and service disruption for non-targeted users. Latency slow and availability high, even while an attack is in progress. Read more about how to set up Flow Spec-based DDoS mitigation [here](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-bgp-flow-spec-configuration/). ### **5. Mitigate application‑layer attacks** While FastNetMon focuses on detecting and mitigating attacks at the [network and transport layers](https://fastnetmon.com/2025/07/08/filtering-l3-l4-ddos-attacks-with-bgp-flow-spec-and-rtbh-a-practical-guide-for-engineers/) (L3/L4), it’s important to recognise that application-layer (L7) attacks often require separate handling. L7 attacks often mimic legitimate requests, bypassing volumetric defences. Methods include: - HTTP GET/POST floods - Slow or partial header attacks (e.g. Slowloris) - Protocol-based misuse like gRPC or GraphQL loops Defence options: - Apply rate limiting or connection caps per source IP - Use web application firewalls (WAF) - Route suspect traffic through content scrubbing services ### **6. Scrubbing centre and hybrid routing** A scrubbing centre is a network facility or cloud-based service designed to defend against large-scale DDoS attacks. Scrubbing centres are specialised in filtering out malicious flows while allowing legitimate traffic through. While filtering all network traffic via a scrubbing centre is certainly an option, it may not be optimal, as it increases latency and can be very expensive. Luckily, many scrubbing providers support[ automatic diversion](https://fastnetmon.com/ddos-scrubbing-centre-diversion/) via BGP community tags or API triggers. Steps: - Monitor attack detection triggers - use your DDoS detection system to watch for traffic anomalies that indicate an active attack. Once thresholds are breached, it’s time to initiate diversion. - Route traffic for affected prefixes to scrubbing site - announce the IP prefixes under attack using special BGP community tags or automated tools. This redirects inbound traffic through the scrubbing provider’s infrastructure, where filtering takes place. - Filter and return clean traffic to your network - The scrubbing centre filters out malicious flows and sends only legitimate traffic back via a secure tunnel or peering link. Minimal disruption for end users is ensured while protecting your network capacity. Learn more about how scrubbing centre automation works [in this article](https://fastnetmon.com/2025/08/06/ddos-scrubbing-centre-automation-explained/). ### **7. Combine approaches in a layered architecture** A layered mitigation strategy lets you respond fast and scale your defences as attacks evolve, starting with broad detection, then applying more precise controls as needed. A comprehensive defence model might include: 1. Real-time monitoring and injection of flow telemetry - continuously monitor traffic for example using[ sFlow](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-sflow-configuration/),[ NetFlow or IPFIX](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-configuration-for-netflow-and-ipfix/). This provides the visibility needed to spot abnormal patterns early , whether it’s a sudden flood or stealthier low-rate attack. 2. [Automated threshold-based blocking](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-threshold-types/) (RTBH) in applicable use cases - when traffic to a destination exceeds safe limits, RTBH routes can be used to drop traffic to that specific IP before it reaches your network, preventing congestion and collateral damage. 3. Targeted[ Flow Spec](https://fastnetmon.com/flowspec-ddos-mitigation/) or [block list based filtering](https://fastnetmon.com/blocklist-filtering/) for nuanced control - for attacks that can't be blocked wholesale, use BGP Flow Spec or blocklists to filter traffic based on specific attributes to allow legitimate flows while stopping the bad ones. 4. [Application-level defences](https://fastnetmon.com/2023/10/24/mitigating-application-layer-ddos-attacks-best-practices-for-online-businesses/) - not all attacks are volumetric. Some target application logic, i.e. login pages or search forms. You must do a deeper inspection and mitigation at the web or app layer, often with support from scrubbing centres. 5. Ongoing traffic analysis and threshold adjustment based on patterns - after each incident, review traffic trends and[ tune your thresholds](https://fastnetmon.com/2025/07/02/how-to-set-a-threshold-for-rtbh-bgp-blackhole-a-practical-guide-to-threshold-based-ddos-defence/). Attackers constantly adapt, so your defences must evolve too. Avoid false positives with regular refinement and improve response accuracy over time. This phased approach enables rapid throughput control followed by granular intervention as needed. ### **8. Reduce mistakes and false triggers** - Group hosts with similar traffic patterns and assign sensible thresholds - Separate thresholds by traffic type, direction and protocols - Only ban when an attack condition persists for a short interval to avoid blocking legitimate bursts - Review alerts and mitigation rules to prevent overblocking important services Defending against DDoS begins with visibility and ends in measured action. By combining threshold-based mitigation, protocol-aware filtering, and smart application‑layer defences, you gain layered resilience. --- # **About FastNetMon** FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats.For more information, visit <https://fastnetmon.com> **Categories:** FastNetMon Blog **Tags:** basics --- ### [Understanding Application-Layer & Low-and-Slow DDoS Attacks](https://fastnetmon.com/2025/09/04/understanding-application-layer-low-and-slow-ddos-attacks/) **Published:** September 4, 2025 **Author:** FastNetMon **Content:** ### Application-layer and “low-and-slow” DDoS attacks explained by DDoS defence professionals Application-layer (L7) and “low-and-slow” DDoS attacks are among the most insidious forms of denial-of-service threats. Rather than saturating bandwidth, they burn server CPU, memory, and database resources by forcing expensive operations—TLS handshakes, header decompression, routing, authentication, or cache misses—while looking deceptively like normal client traffic. This article explains how these attacks work, the modern vectors (HTTP/2, HTTP/3, GraphQL, gRPC, WebSockets), and how defenders can detect and mitigate them. This article is part of our ongoing series on DDoS classification. If you’re new here, start with [our DDoS taxonomy](https://fastnetmon.com/2025/07/25/classification-of-ddos-attacks-every-modern-ddos-attack-vector-explained/) to see how L7 attacks fit within the wider threat landscape. ### What Are Application-Layer & Low-and-Slow Attacks? Application-layer DDoS attacks operate at Layer 7 of the OSI model, targeting the actual applications and APIs that users rely on. Unlike volumetric attacks, their aim is to force disproportionate work on servers, proxies, and databases. - **Application-Layer Floods** generate high request rates (GET, POST, GraphQL, gRPC, etc.) that bypass caches and drive load on dynamic backends. - **Low-and-Slow Attacks** keep many connections alive with minimal traffic—trickling headers or body data—tying up sockets, threads, and memory buffers without consuming significant bandwidth. The unifying theme is **cost asymmetry**: attackers expend little bandwidth or CPU, while defenders spend far more per request or connection. ### What makes application layer attacks dangerous? - **Stealth**: Traffic often mimics legitimate clients, staying below volumetric detection thresholds. - **Cost asymmetry**: TLS handshakes, JSON parsing, template rendering, and cache misses are expensive for servers but cheap for attackers. - **Modern protocol abuse**: HTTP/2 Rapid Reset and gRPC cancellation churns, or WebSocket floods, exploit protocol features to amplify impact. - **Low bandwidth, high pain**: Attacks like Slowloris succeed with sub-Mbps traffic by exhausting per-connection resources. ### Common Attack Vectors and Their Impact Below we summarise common application-layer and low-and-slow attack vectors, their mechanics, peak observations, and primary targets. | Attack Type | Layer | Description | Notable Peak Impact | Resource Targeted | |---|---|---|---|---| | HTTP GET/POST Flood with Cache-Busting | 7 | Random query strings/headers force cache misses, driving load to origin | 10M+ rps seen at CDNs | Origin CPU, DB/cache | | HTTP/2 Rapid Reset (CVE-2023-44487) | 7 | Opens many streams then cancels with RST\_STREAM, overwhelming state machines | 201–398M rps (2023) | Proxy thread pools, CPU | | Slowloris / RUDY | 7 | Dribbles partial headers/bodies just above timeout thresholds | Effective <1 Mbps | Sockets, worker threads | | GraphQL Deep Recursion | 7 | Nested/aliased queries explode resolver and DB work | Exploitable at low RPS | DB pools, CPU | | WebSocket Floods | 7 | Many concurrent upgrades plus idle/junk frames | 1M+ concurrent conns possible | Sockets, memory | | gRPC Ping/Metadata Abuse | 7 | Excessive keepalives, SETTINGS, metadata churn | Reported since 2019 | Thread pools, per-conn streams | | Login Spray / Credential Stuffing | 7 | Distributed low-rate auth attempts bypass per-IP limits | Widely reported | Auth CPU, DB, session store | | Prefix Scatter (Carpet Bombing at L7) | 7 | Spreads small RPS across many endpoints | Ongoing (2024–2025) | Endpoint budgets, detection systems | ### How These Attacks Work: Floods vs. Low-and-Slow - **Floods**: Cache-busting HTTP floods, Rapid Reset, and GraphQL recursion generate enormous request or stream churn, hammering CPU, databases, and thread pools. - **Low-and-Slow**: Attacks like Slowloris or RUDY tie up sockets and worker threads by sending headers or bodies extremely slowly. Bandwidth stays low, but per-connection state and file descriptors get exhausted. - **Protocol exploitation**: HTTP/2 and gRPC enable multiplexing and metadata, which attackers abuse to create churn without breaching simple concurrency limits. ### Real-World Examples - **HTTP/2 Rapid Reset (2023, 2025)**: Record floods of 201M–398M rps against hyperscalers; required urgent patches across CDNs, proxies, and gRPC servers. More recent variation of this attack vector is [MadeYouReset (2025)](https://fastnetmon.com/2025/08/13/madeyoureset-the-new-http-2-ddos-threat-and-mitigation-strategies/) - **Slowloris**: Still effective against unprotected Apache deployments, consuming threads with minimal bandwidth. - **GraphQL recursion**: Exploited by adversaries to drive high CPU and DB calls from only a handful of queries. - **WebSocket floods**: Seen in gaming and chat services, overwhelming per-IP connection limits where WAF inspection stops after upgrade. ### Key Differences: L7 Floods vs. Low-and-Slow Although both application-layer floods and low-and-slow techniques target Layer 7, they differ significantly in how they apply pressure on infrastructure. The table below highlights the main contrasts. | Aspect | Floods | Low-and-Slow | |---|---|---| | Primary Target | Application endpoints, APIs | Connections, sockets, threads | | Attack Mechanism | High RPS, cache-busting, stream churn | Long-lived idle/slow connections | | Traffic Volume | Moderate to very high | Very low bandwidth | | Detection Difficulty | High (mimics clients) | High (low traffic signature) | | Resource Impact | CPU, DB, cache, proxy pools | File descriptors, memory, worker threads | ### Mitigation Strategies for Application-Layer & Low-and-Slow Attacks Defending against L7 and low-and-slow attacks is very different from handling volumetric floods. These threats don’t just overwhelm pipes; they exploit how your applications and infrastructure are built. That means the right defence strategy depends heavily on your own environment—your CDN setup, reverse proxies, application servers, APIs, and databases. In this chapter, we’ll highlight the main defensive methodologies available. Not all will apply to every stack, but together they form a comprehensive toolbox. The best results come from layering these measures across the edge, proxy, application, and backend. #### 1. Edge, CDN, and WAF Protections The edge is your first line of defence, filtering and rate-limiting traffic before it hits origin servers. - **Patch known protocol issues**: Ensure your CDN, reverse proxies, and origin servers are patched against HTTP/2 Rapid Reset (CVE-2023-44487) and gRPC advisories. Track cancellation rates and abusive patterns, not just concurrent stream counts. - **Composite-key rate limiting**: Go beyond IP-only rules. Rate-limit based on a mix of factors—IP + TLS fingerprint (JA3/JA4) + cookie + endpoint—to resist botnets and prefix-scatter attacks. - **Cache hardening**: Normalise or ignore non-essential query parameters in cache keys so attackers can’t force origin hits with randomised URLs. Configure “cache everything” rules for safe static pages. - **Bot management**: Use device fingerprints, behavioural signals, and action-point challenges (e.g. CAPTCHAs or Turnstile on login) to stop credential stuffing and scripted floods. #### 2. Reverse Proxy and HTTP Server Hardening Tuning your reverse proxies and web servers helps cut off abusive connections early. - **Timeouts for slow attacks**: - Apache: mod\_reqtimeout with RequestReadTimeout for headers/bodies. - Nginx: client\_header\_timeout and client\_body\_timeout. These kill Slowloris-style attacks by refusing to hold sockets open indefinitely. - **Connection and stream limits**: Cap concurrent streams (max\_concurrent\_streams) and header/metadata sizes in HTTP/2/3. Monitor RST\_STREAM or PING abuse and close abusive connections quickly. - **WebSocket controls**: Require authentication before upgrade, cap per-IP connection counts, enforce idle timeouts, and apply size limits on frames. Remember that many WAFs stop inspecting after the initial handshake. #### 3. Application- and API-Specific Safeguards Different application protocols have unique risks that need targeted countermeasures. - **GraphQL**: - Disable or restrict introspection in production. - Enforce query depth/complexity limits. - Use persisted or allow-listed queries only. - Add timeouts and execution budgets per identity. - **gRPC**: - Set conservative keepalive policies (minimum intervals, no pings without calls). - Cap concurrent streams and metadata sizes. - Apply circuit breakers in Envoy/meshes to bound pending requests. - Keep gRPC libraries patched against Rapid Reset vulnerabilities. - **Login and transactional endpoints**: - Apply per-user/session rate limits, not just per IP. - Detect anomalies like credential stuffing via leaked-credential checks and fingerprinting. - Place challenges at the action point (login/checkout), not just on page load. #### 4. Backend and Database Resilience Even with strong edge and application defences, some traffic will hit your backends. Resilience here prevents total collapse. - **Backpressure and load shedding**: Enforce maximum queue lengths and return 429 or 503 when circuits trip. Serve stale content where possible instead of hammering databases. - **Database and cache guardrails**: - Limit pool sizes per instance. - Protect “hot keys” and isolate critical queries (e.g. logins, payments) into dedicated pools. - **Autoscaling with limits**: Allow scaling to absorb legitimate surges, but prevent runaway autoscaling that simply shifts bottlenecks onto the database layer. #### 5. Operational Playbook Finally, effective defence means preparation and practice. - **Before an attack**: Patch protocol stacks, tune cache keys, set basic timeouts, and run canary drills that simulate floods and login sprays. - **During an attack**: Drop abusive connections early (e.g. high RST\_STREAM ratios), tighten rate limits on hot endpoints, enable managed challenges, and serve stale responses to protect backends. - **After an attack**: Review dashboards, refine rate limits, adjust keepalive/stream policies, and harden high-risk APIs (GraphQL, login). ### Conclusion Application-layer and low-and-slow attacks are complex and highly infrastructure-dependent. The right mix of mitigations will differ between, say, an e-commerce platform with dynamic cart endpoints and a gaming backend running WebSockets. The goal is to build layered defences: edge filtering and bot management, proxy and server tuning, protocol-specific safeguards, and backend guardrails. When combined, these controls give you a realistic chance of withstanding attacks that bandwidth-only tools can’t stop. For a full understanding of DDoS attack types and defence strategies, continue reading our full [DDoS taxonomy](https://fastnetmon.com/2025/07/25/classification-of-ddos-attacks-every-modern-ddos-attack-vector-explained/). --- ## **About FastNetMon** FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit <https://fastnetmon.com> **Categories:** FastNetMon Blog **Tags:** classification, Network Security Insights --- ### [DDoS FAQ for beginners](https://fastnetmon.com/2025/09/03/ddos-faq-for-beginners/) **Published:** September 3, 2025 **Author:** FastNetMon **Content:** ### Introduction: Questions you always wanted to ask about DDoS DDoS is one of those topics that everyone in the industry has heard about, but few feel confident they fully understand. Maybe you’ve sat in a meeting where terms like “RTBH,” “FlowSpec,” or “amplification” were thrown around and thought, *I should probably know all this… but I feel lost!* This FAQ is written exactly for that moment. Whether you’re a junior defender taking your first steps in network security, starting your cybersecurity career, or simply someone who wants a clear, no-nonsense explanation — this guide is for you. We’ve gathered the most common questions about DDoS attacks and answered them in plain language, with links to deeper resources when you’re ready to dive further. Think of it as a friendly knowledge base that covers everything from *“What is a DDoS attack?”* to *“How do you test if your defences actually work?”* The goal is simple: to help you feel more confident about the fundamentals of DDoS — and to show you how solutions like FastNetMon can make defending your network easier. --- ### 1. What is a DDoS attack? A Distributed Denial of Service (DDoS) attack is when multiple compromised devices flood a target network, service, or website with traffic, overwhelming its resources and making it inaccessible to legitimate users. ### 2. Why are DDoS attacks so common? DDoS attacks are relatively cheap to launch, widely available as a service (’DDoS-for-hire’), and effective at causing disruption. Attackers may be motivated by financial gain, politics, activism, or extortion. ### 3. What types of DDoS attacks exist? - **Volumetric attacks**: Flooding bandwidth (UDP floods, amplification). - **Protocol attacks**: Exploiting weaknesses in protocols (SYN floods, fragmented packets). - **Application-layer attacks**: Targeting specific applications or APIs (HTTP floods). Full classification is [here](https://fastnetmon.com/2025/07/25/classification-of-ddos-attacks-every-modern-ddos-attack-vector-explained/). ### 4. What is the difference between volumetric, protocol, and application-layer DDoS attacks? - Volumetric attacks aim to saturate available bandwidth with massive amounts of traffic (e.g., UDP floods). - Protocol attacks exploit weaknesses in network protocols (e.g., SYN floods, fragmented packets). - Application-layer attacks target specific services, like HTTP or DNS queries, to exhaust server resources. Learn more about the attack types:[ **Understanding Volumetric & Amplification DDoS Attacks**](https://fastnetmon.com/2025/07/30/understanding-volumetric-amplification-ddos-attacks/) ### 5. What should I do if my network is under a DDoS attack? - Use automated detection tools like FastNetMon. - Apply (automatic) filtering or blackholing to stop attack traffic. - Work with your upstream provider if the attack exceeds your capacity. - Investigate the attack post-mortem and apply further defences if necessary More details about how to defend against a DDoS attack can be read [here](https://fastnetmon.com/2025/08/19/how-to-defend-against-a-ddos-attack/). ### 6. What is BGP Blackhole routing or RTBH? BGP Blackhole routing is a mitigation strategy where attack traffic is redirected to a null route before it reaches the target, protecting the rest of the network. Read more:[FastNetMon’s guide to BGP Blackhole automation](https://fastnetmon.com/2024/12/07/bgp-blackhole-automation-for-ddos-mitigation/) ### 7. What is BGP Flow Spec? BGP Flow Spec allows fine-grained filtering rules to be distributed across routers, enabling more targeted mitigation than blackholing. Read a detailed guide [here](https://fastnetmon.com/2025/02/10/bgp-flow-spec-for-ddos-mitigation/). ### 8. What is a multi-layered DDoS defence strategy? It combines different techniques (rate-limiting, filtering, blackhole routing, FlowSpec, scrubbing centres) to cover multiple attack vectors and different scenarios. Read our blog on[ Building a Multi-Layered DDoS Defence Architecture](https://fastnetmon.com/2025/05/28/building-a-multi-layered-ddos-defense-architecture/). ### 9. Who launches DDoS attacks and why? - Hacktivists and politically motivated groups. - Criminals extorting businesses. - Competitors trying to disrupt rivals. - State-sponsored actors. - Other individuals and organisations with varying motivations. Read more about the various motivations behind DDoS attaks [here](https://fastnetmon.com/2025/08/27/why-do-ddos-attacks-happen-top-motivations-behind-ddos-cybercrime/). ### 10. Can DDoS attacks be completely stopped? No, but with the right detection and layered defence strategy, their impact can be reduced to near zero. ### 11. Who is at risk of being targeted by a DDoS attack? Any online service is a potential target: ISPs, hosting providers, gaming platforms, e-commerce sites, financial institutions, and even government agencies. In 2025, the list became longer with some previously unheard targets: [DDoS attacks are now targeting journalists, universities, NGOs. What has changed?](https://fastnetmon.com/2025/06/19/ddos-attacks-are-now-targeting-journalists-universities-ngos-what-has-changed/?utm_source=chatgpt.com) ### 12. What is the largest DDoS attack ever recorded? Attacks exceeding **several terabits per second (Tbps)** have been observed in recent years, often exploiting amplification vectors like DNS or NTP. At the time of writing, the largest attack was [11.5 Tbps recorded by Cloudflare](https://fastnetmon.com/2025/09/03/cloudflare-mitigates-record-breaking-11-5-tbps-ddos-attack/); however, new hypervolumetric attacks surface constantly. ### 13. What is a botnet? And what’s their role in modern DDoS campaigns? A botnet is a network of infected devices (IoT, PCs, servers) controlled by attackers. Botnets like Mirai and Agobot pioneered techniques for large-scale DDoS, adding automation and modular attack capabilities. Botnets are often the backbone of many DDoS campaigns. They allow attackers to generate distributed traffic, making it harder to block by IP or geography. Read everything about[ the anatomy of a botnet](https://fastnetmon.com/2025/06/18/anatomy-of-a-botnet/). ### 14. How are botnets built? They compromise devices such as IoT gadgets, PCs, and servers that have been typically infected by malware, then control them remotely to generate coordinated attack traffic. [Meet the botnets breaking the Internet and learn all about them](https://fastnetmon.com/2025/07/03/meet-the-botnets-breaking-the-internet-part-1/). ### 15. How does BGP Blackhole / RTBH help mitigate DDoS attacks? RTBH is one of the most common ways to mitigate an attack. BGP Blackhole routing lets ISPs or networks discard malicious traffic targeting a specific IP prefix before it reaches the victim’s infrastructure. This ‘sacrifices’ the attacked service but protects the rest of the network. Read through:[ BGP Blackhole automation for DDoS mitigation](https://fastnetmon.com/2024/12/07/bgp-blackhole-automation-for-ddos-mitigation/) ### 16. What is BGP Flow Spec, and how does it compare to Blackhole in DDoS mitigation? BGP Flow Spec allows for more granular filtering than Blackhole routing. Instead of discarding all traffic to a prefix, it enables filtering by packet attributes (protocol, port, source/destination). This keeps legitimate traffic alive while dropping malicious flows. Read more about when to use blackholing and when Flow Spec or other methodologies are preferred: [To blackhole or not to blackhole?](https://fastnetmon.com/2025/06/18/when-is-bgp-blackholing-a-good-choice-for-ddos-mitigation-and-when-is-it-not/) ### 17. How can rate-limiting or threshold-setting help mitigate DDoS attacks? Rate-limiting caps the number of requests a server accepts within a timeframe. While useful against application-layer floods, it risks blocking legitimate users during peak load if thresholds aren’t tuned properly. Rate limiting, however, is a different methodology compared to threshold-based mitigation, such as RTBH. Threshold-based DDoS mitigation is a reactive mechanism. It involves continuously monitoring traffic levels—such as packets per second, bits per second, or flows per second, and taking action only when those levels exceed a predefined threshold Read about each, and how to use them →[ How to set a threshold for RTBH/BGP Blackhole - FastNetMon](https://fastnetmon.com/2025/07/02/how-to-set-a-threshold-for-rtbh-bgp-blackhole-a-practical-guide-to-threshold-based-ddos-defence/) ### 18 What’s the risk of false positives in automated DDoS mitigation? Aggressive filtering may block legitimate traffic, leading to service disruption. The challenge lies in balancing speed of mitigation with accuracy in distinguishing real customers from attackers. You can try[ FastNetMon baseline calculation](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-naseline-calculation/). ### 19. What’s the difference between mitigation at the ISP level vs. the enterprise level? → ISP-level mitigation protects upstream bandwidth and absorbs larger attacks before they hit the customer. → Enterprise-level mitigation focuses on filtering at the edge or inside the organisation’s network, which is effective but limited in scale. For deeper reading on layered strategies and the importance of upstream protections check out[ DDoS and your digital transformation strategy](https://fastnetmon.com/2023/01/09/why-you-need-ddos-mitigation/). ### 20. How can I test if my DDoS defences work? By running controlled DDoS simulations (’red teaming’), traffic stress testing, and tabletop exercises with their incident response team. Testing validates both technology and operational playbooks. ### 21. What are DDoS-for-hire services? So-called ‘booter’ or ‘stresser’ services rent out DDoS capabilities for as little as $10/hour. This lowers the barrier of entry for attackers and significantly increases attack frequency. Here’s more about[ DDoS booters and IP stressers explained by experts](https://fastnetmon.com/2025/04/10/ddos-booters-and-ip-stressers-explained-by-experts/) ### 22. What is the difference between DoS and DDoS? A Denial of Service (DoS) attack originates from a single source, while a DDoS attack uses multiple distributed sources, often part of a botnet. This makes DDoS attacks harder to stop. ### 22. What is an RDDoS attack? RDDoS, or **Ransom DDoS**, is a specific type of attack where adversaries demand payment (usually in cryptocurrency) under the threat of launching or continuing a DDoS attack against the target. Unlike ransomware, attackers don’t encrypt data - they weaponise downtime as leverage. More on the topic →[ DoS, DDoS and RDoS explained](https://fastnetmon.com/2025/04/16/ddos-dos-rdos-explained/) ### Have more questions? This FAQ is just the beginning. If you want to dive deeper or have a DDoS question we didn’t cover, join the conversation on our social channels. We share insights, answer questions, and keep you updated on the latest in DDoS defence — drawing on over a decade of experience helping networks around the world stay secure. --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats.For more information, visit <https://fastnetmon.com> **Categories:** FastNetMon Blog **Tags:** basics --- ### [Common myths and misconceptions about DDoS attacks](https://fastnetmon.com/2025/09/10/common-myths-and-misconceptions-about-ddos-attacks/) **Published:** September 10, 2025 **Author:** FastNetMon **Content:** Despite being a decades-old threat, DDoS attacks still come with a cloud of misunderstanding. Every time a myth goes unchecked, organisations risk underestimating threats or misallocating resources. This post debunks the most stubborn DDoS myths and explains what actually matters in DDoS defence. ### Myth 1: DDoS attacks are only a problem for big companies It’s easy to assume that attackers only go after large enterprises, banks, or global platforms. The reality is that any organisation with an online presence can be a target. From small blogs to regional ISPs and even local government websites, attackers often pursue victims based on opportunity rather than size. In fact, smaller companies may be more attractive because they lack advanced defences. Attackers know that a few minutes or hours of downtime can have a damaging effect on operations and customer trust, making smaller targets just as vulnerable. ### Myth 2: Our firewall will protect us from DDoS. Well, this one depends on what the attack targets, and what kind of attack are we looking at - but to say “our firewall is our DDoS defence strategy” is naive at best. Basic firewalls, especially stateful ones, can easily be overwhelmed. They’re not built to handle the scale, volume, or sophistication of modern DDoS tactics, which frequently involve hundreds of thousands, or even millions, of compromised devices flooding a target with requests. Once the attack volume exceeds the capacity of the firewall or internet link, the service goes offline, regardless of how well those tools normally perform. Mitigation requires dedicated detection and traffic redirection methods that are specifically designed to separate legitimate traffic from attack traffic at scale. ### Myth 3: DDoS is just about downtime While service outages are the most visible outcome, downtime is not the only risk. DDoS is often used as a smokescreen while attackers attempt to break into systems or exfiltrate data elsewhere. By overwhelming monitoring tools and distracting IT staff, attackers create gaps in visibility that can be exploited. There’s also the financial dimension. Downtime leads to lost sales, missed opportunities, SLA penalties, and damage to brand reputation. In the case of ransom-driven attacks (RDoS), businesses face extortion demands on top of operational disruption. ### Myth 4: DDoS attacks are simple and unsophisticated Early DDoS attacks were relatively basic, relying on flooding techniques like SYN floods or ICMP floods. Today’s attackers have access to highly flexible botnets and attack tools capable of switching between multiple vectors. Some attacks target the application layer with carefully crafted requests that mimic real user behaviour, making them far harder to distinguish from legitimate traffic. Others exploit amplification vulnerabilities in internet protocols, multiplying traffic to devastating levels. Modern campaigns often blend multiple methods in quick succession, creating complex attack scenarios that demand equally advanced detection and mitigation strategies. ### Myth 5: Buying more bandwidth solves the problem While additional bandwidth can absorb small-scale floods, it’s not a long-term solution. Attackers can easily scale their efforts to overwhelm even very large connections. Bandwidth alone does nothing to differentiate between real and malicious traffic. Relying on bandwidth expansion without traffic filtering is like trying to fight a flood by building a bigger bucket. At some point, the bucket still overflows. The more effective approach is to combine sufficient capacity with intelligent filtering and rerouting strategies. ### Myth 6: DDoS attacks don’t last long Many attacks do end quickly, sometimes within minutes. But attackers are increasingly using sustained or repeated assaults, especially against targets that show weak defences. Multi-hour or multi-day campaigns are not uncommon. Short bursts of traffic, known as “pulse attacks,” are also used to probe defences, identify weak points, and wear down responders. Even brief attacks can be enough to disrupt online transactions, delay services, and frustrate users. ### Myth 7: DDoS is a problem of the past Because DDoS has been around since the late 1990s, some assume it’s no longer relevant in today’s threat landscape. In reality, attack volumes continue to grow, botnet operators constantly adapt their tools, and new attack vectors appear as internet protocols and services evolve. Far from disappearing, DDoS remains a favourite tool of hacktivists, extortionists, competitors, and state-sponsored groups. In fact, DDoS has grown into an entire industry in the dark side of the internet, and categorising it as a “problem of the past” is dangerous for the entire internet ecosystem. ### Myth 8: Attack detection is easy In theory, a sudden surge of traffic should be easy to spot. In practice, distinguishing between a legitimate spike (i.e. a flash sale or viral campaign, or any other event that brings an unusually large amount of users to the service) and malicious activity is difficult. Application-layer attacks complicate the picture further, as they mimic real user patterns. Accurate detection requires analysing traffic behaviour, not just volume, and correlating it across multiple layers. This requires dedicated monitoring and automated systems rather than manual guesswork. ### Myth 9: On-premise tools alone are enough Some organisations rely entirely on on-premise appliances for mitigation. While these play an important role, and may be sufficient in some cases, they have physical and bandwidth limits. Large-scale attacks often need to be absorbed upstream, at the ISP or cloud provider level, before they reach the target network. The most resilient defence model is layered: on-premise systems handle smaller attacks and provide visibility, while upstream partners filter or divert massive volumes. This hybrid approach ensures protection across a range of attack sizes. ### Myth 10: DDoS attacks have been the same for decades It’s tempting to think of attackers as recycling the same old tricks and do not innovate. In reality, they constantly experiment. Each year brings new variations of protocol abuse, application targeting, and botnet structures. The rise of IoT devices has dramatically expanded the pool of resources attackers can weaponise. This innovation is driven by the market: DDoS-for-hire services compete with each other, meaning operators invest in new features to keep customers. As long as this underground economy exists, defenders must expect continual adaptation. ### Why these myths persist - and what you can do? **Media bias** Gigantic, eye-catching attacks get attention. Smaller, stealthier ones don’t, so the misconception grows. **Overconfidence in legacy tools** Firewalls, CDNs, or ISP protection—used in isolation—give a false sense of safety. **Alert fatigue** Teams focused only on volume spikes may ignore anomalous behaviour in low-rate or polymorphic attacks. **Misunderstanding attack mechanics** Terms like ‘DDoS’ invite assumptions about scale, and make intermediate attackers seem less dangerous. ### Real defence starts with myth-busting To protect your organisation effectively: - Recognise that not all attacks announce themselves with volumetric noise. - Assume your firewalls and CDNs are part of a layered defence, but not enough alone. - Invest in real-time monitoring (flows, application behaviour, user patterns). - Use a hybrid approach: on-prem signatures, BGP/Flow Spec routing, and cloud scrubbing. - Test and rehearse incident response, not just infrastructure. Misconceptions about DDoS are more dangerous than the attacks themselves. By clearing the fog and grounding your defence in reality, you’ll be better positioned to maintain uptime, reduce risk, and respond effectively. ### Summary Table: Myths vs. The Reality | Myth | Reality | |---|---| | DDoS are always big bandwidth floods | Many are low-rate, targeted, or application-layer campaigns. | | Firewalls will stop them | No—firewalls are often overwhelmed or bypassed. | | ISPs protect us entirely | They can help at scale, but lack internal visibility or speed. | | Small organisations aren’t targets | Attackers often target smaller businesses for ease and extortion. | | DDoS-for-hire means sophistication | Many attackers use simple automated tools, not advanced skills. | | Cloud is instant bulletproof protection | Cloud solutions add value—but can have delayed response or cost issues. | | CDN = Total security | CDNs help—they aren't replacement for layered defence, especially at L7. | | Pen testing covers DDoS risk | Pen tests don’t evaluate capacity or resource exhaustion risk. | | DDoS attacks are easy to detect | Low-profile or evasive attacks require behavioural logic and enhanced visibility. | | Smart attacks need advanced tech | Some of the most damaging are subtle and efficient—low-volume yet high-impact. | --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats.For more information, visit <https://fastnetmon.com> **Categories:** FastNetMon Blog **Tags:** basics --- ### [Cambridge study examines global law enforcement efforts against DDoS-for-hire services](https://fastnetmon.com/2025/09/11/cambridge-study-examines-global-law-enforcement-efforts-against-ddos-for-hire-services/) **Published:** September 11, 2025 **Author:** FastNetMon **Content:** Researchers from the University of Cambridge’s Security Group recently published important findings on the effectiveness of global law enforcement actions against DDoS-for-hire services, also known as *[booters](https://fastnetmon.com/2025/04/10/ddos-booters-and-ip-stressers-explained-by-experts/)*. Their study, *[Assessing the Aftermath: the Effects of a Global Takedown against DDoS-for-hire Services](https://www.lightbluetouchpaper.org/2025/09/06/taking-down-booters-the-cat-and-mouse-game/)*, was presented at the USENIX Security Symposium 2025 and awarded an Honourable Mention. The work was carried out by Anh V. Vu, Ben Collier, Daniel R. Thomas, John Kristoff, Richard Clayton, and Alice Hutchings. Booters have long offered an easy way for anyone with a few dollars to launch denial-of-service attacks. Marketed as “stress-testing” tools, they are widely used for malicious purposes and pose a persistent challenge to defenders. The paper analyses the coordinated law enforcement takedowns in December 2022 and May 2023, which together seized around 60 domains. The research team drew on a wide range of data sources—traffic analytics, DDoS attack datasets, splash page logs, and online forums—to understand both the technical and social impact of the interventions. Key findings include: - **Fast recovery, but lasting disruption**: Booter operators typically resurrected their services within 20–40 hours, often under new domains. However, site traffic collapsed by 80–90%, with many domains reduced to negligible daily visits. - **Temporary reduction in DDoS volumes**: The December 2022 takedown coincided with a 20–40% drop in global DDoS traffic, especially UDP-based attacks. Volumes rebounded within weeks, but the short-term impact was clear. - **Undermining trust in the market**: Law enforcement also deployed deceptive booter sites and messaging campaigns, creating doubt among operators and users. This erosion of trust is seen as a significant deterrent. - **Changing user profile**: Most visitors to seized booter sites came from the US and Europe, often gamers rather than seasoned cybercriminals. Few attempted to hide their identities, highlighting the low barrier to entry in this ecosystem. The research underlines that while takedowns do not eliminate booters, they serve as valuable disruptions. By making the market unstable, forcing operators to waste resources, and discouraging casual users, these interventions reduce overall harm—even if only temporarily. As the authors note, the fight against DDoS-for-hire is not about a single decisive victory. Instead, it is a long-term effort to keep the ecosystem fragile and unappealing, gradually pushing it away from being a casual tool into a riskier niche. This is an excellent example of rigorous, data-driven research that sheds light on both the technical and human aspects of cybercrime. We congratulate the University of Cambridge Security Group and the authors for their contribution to the field and for helping the community better understand how to tackle the persistent challenge of DDoS-for-hire services. --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit <https://fastnetmon.com> **Categories:** FastNetMon Blog **Tags:** DDoS News, legal --- ### [How to tell if you’re under a DDoS attack](https://fastnetmon.com/2025/09/16/how-to-tell-if-youre-under-a-ddos-attack/) **Published:** September 16, 2025 **Author:** FastNetMon **Content:** DDoS attacks remain one of the most disruptive threats facing ISPs, backbone networks, hosting providers, and enterprises. Detecting the attacks quickly is essential to keeping networks stable and services running. This guide looks at how network engineers can recognise the signs of an attack and how FastNetMon provides the visibility needed to detect them in real time. ## Recognising the signs of a DDoS attack DDoS attacks can appear similar to ordinary traffic peaks at first glance, but they leave distinct technical fingerprints across the network stack. ### Transport-layer anomalies Many large-scale attacks exploit the TCP handshake. For example, a SYN flood sends large numbers of half-open connections that fill backlog queues. Engineers should watch for: - A spike in flows with the SYN flag set but no corresponding ACK. - Abnormal flag combinations such as SYN+FIN or repeated RST floods. - Reduced source IP entropy, suggesting many spoofed IPs hitting one target. ### Bandwidth and packet floods Floods can saturate either by sheer bandwidth or by overwhelming devices with packets per second (PPS). Indicators include: - A sharp increase in bits per second (BPS) showing volumetric floods. - A PPS surge from small UDP or ICMP packets, even when bandwidth does not grow equally. - Rapid rises in flows per second, with shrinking flow sizes that look more like scanning than real traffic. ### Server and application strain On servers and load balancers, backlogs and connection tables expose the impact quickly: - SYN backlog queues fill, leading to dropped connections. - If SYN cookies are enabled, CPU usage climbs as the system works harder to validate connections. - Logs show incomplete TCP handshakes, repeated abnormal HTTP requests, or floods of identical GET/POST requests. ### Network and service disruption As traffic pressure mounts, the attack often spills over into wider service disruption: - Routers and switches show queue drops, buffer overruns, and CRC errors. - Firewalls see CPU interrupts spike. - Services like VoIP degrade with jitter, VPN sessions disconnect, and web services return errors. ### Correlation matters No single symptom confirms an attack. Engineers rely on correlation: - Flow data shows anomalies. - Router counters confirm congestion. - Server logs highlight incomplete sessions. - Service monitors flag user-visible impact. Building a baseline of normal behaviour is critical. Once you know what “normal” looks like for your traffic, deviations stand out clearly. ## How FastNetMon detects attacks Detecting attacks manually is time-consuming and error-prone. FastNetMon Advanced automates this process by ingesting traffic telemetry (NetFlow, IPFIX, sFlow, or mirrored packets) and keeping per-host, per-subnet, and per-hostgroup counters. Configurable thresholds help distinguish between normal surges and malicious floods, and once an attack is detected, FastNetMon can trigger mitigation automatically through BGP FlowSpec or Remotely Triggered Black Hole (RTBH) routing. ### Key signals and how FastNetMon detects them | **Signal** | **What it looks like in an attack** | **How FastNetMon detects it** | |---|---|---| | SYN floods | High SYN-to-ACK ratio, incomplete handshakes, unusual flag combinations | Dedicated SYN PPS counters and SYN bandwidth tracking | | Bandwidth spikes | Sudden surge in Mbps, often saturating links | Per-host, per-hostgroup, and global bandwidth thresholds | | Packet floods | Excessive PPS from small UDP/ICMP packets | PPS counters by protocol and global PPS monitoring | | Flow anomalies | Many short-lived flows per second | Flows-per-second counters | | Fragmentation | Spoofed or fragmented packets to bypass filtering | Fragmented packet counters | | Service-wide attacks | Carpet bombing across subnets | Hostgroup and global thresholds to spot distributed floods | | Routing anomalies | Triggered RTBH or FlowSpec routes | Integration with BGP Blackhole and FlowSpec for automated mitigation | ### Going deeper: FastNetMon in practice FastNetMon’s detection workflow mirrors an engineer’s investigative process, but at machine speed: - **Collect**: It ingests flow data from routers or mirrored packets from taps. - **Measure**: Counters track bandwidth, PPS, and flow creation rates per host and group. - **Detect**: When thresholds are exceeded, FastNetMon marks an event as a potential attack. - **Confirm**: Engineers can drill into packet captures or logs to validate if needed. - **Mitigate**: With BGP integration, mitigation can be triggered automatically. This combination of telemetry, thresholds, and automation means FastNetMon doesn’t just alert engineers — it gives them the tools to respond in time. ## Conclusion Recognising a DDoS attack comes down to spotting patterns of anomalies across flows, protocols, routers, and services. Doing it by hand takes time, and during an attack, time is the one thing you don’t have. FastNetMon helps by automating detection, correlating signals across the network, and integrating directly with routing controls to enable fast mitigation. For ISPs, hosting providers, and enterprises alike, it provides the visibility and speed needed to protect infrastructure from today’s increasingly complex attack landscape. --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** FastNetMon Blog **Tags:** basics --- ### [ShadowV2: A new botnet that turns misconfigured Docker APIs into a pay-to-use cloud DDoS platform](https://fastnetmon.com/2025/10/01/shadowv2-a-new-botnet-that-turns-misconfigured-docker-apis-into-a-pay-to-use-cloud-ddos-platform/) **Published:** October 1, 2025 **Author:** FastNetMon **Content:** ShadowV2 has been identified as a new DDoS-as-a-service platform that stands out for its use of cloud infrastructure. Instead of relying on home routers or compromised IoT devices, it exploits misconfigured Docker daemons running in public cloud environments. Many of these daemons were deployed on Amazon Web Services, but the same exposure exists across providers. Earlier campaigns often relied on ad-hoc scripts. ShadowV2 takes a different form: a self-service portal where customers can run their own DDoS jobs. It provides attack configuration, real-time dashboards, and subscription plans - features that mirror those of legitimate SaaS products. ## **How the infections work** To grow, the botnet hunts for Docker APIs left open without authentication. When it finds one, it deploys containers that download the attacker’s images. Inside are binaries designed to run multiple DDoS attack types, from TCP and UDP floods to various amplification methods. The advantage for operators is clear: - Cloud workloads provide far greater bandwidth and CPU than IoT devices. - Containers can be deployed and destroyed quickly, making takedown harder. - Victims of the compromise are often billed for the attacker’s compute time. ## **Why is ShadowV2 different?** This is not the first time cloud misconfigurations have been abused for DDoS, but ShadowV2 is notable for how commercially packaged it is. Buyers don’t need technical knowledge — the platform abstracts away the attack scripts and replaces them with sliders, menus, and an automated payment flow. The service demonstrates a shift: DDoS-for-hire operations no longer look like underground IRC bots, but instead like **cloud dashboards** designed for efficiency and scale. That lowers the entry barrier for anyone wanting to launch attacks. ## **Defensive considerations** Because ShadowV2 thrives on exposed Docker services, preventing these instances from being reachable on the internet is the most direct control. Security teams should regularly audit their environments to confirm that container APIs are locked down. In cases where misconfigurations already exist, unusual outbound traffic can serve as an early warning — compromised containers generating floods will stand out from normal application behaviour. Detection is only part of the picture, however. Cloud-hosted botnets are capable of sustaining higher rates for longer periods, so automated response and rapid mitigation at the network level become critical. When identified, reporting compromised containers to cloud providers can lead to swift removal, cutting off the attacker’s resources. --- ## **About FastNetMon** FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit <https://fastnetmon.com> **Categories:** FastNetMon Blog **Tags:** Botnets, DDoS News --- ### [The IPv6 Divide: How Slow Adoption Creates Digital Vulnerabilities and Economic Inequality](https://fastnetmon.com/2025/10/08/the-ipv6-divide-how-slow-adoption-creates-digital-vulnerabilities-and-economic-inequality/) **Published:** October 8, 2025 **Author:** FastNetMon **Content:** ###### Guest post by Vincentas Grinius, Co-Founder at IPXO The shift to IPv6 has escalated into a matter of national security, as nations lagging in adoption are increasingly exposed to cyber threats and diminished control over their digital infrastructure due to the limited availability of IPv4. With IPv6-only environments becoming more common, reliance on IPv4 may lead to slower connectivity, deepening the digital divide and potentially worsening economic disparities. In this geopolitical landscape, moving to IPv6 serves as a critical step toward maintaining digital independence. As global tensions continue to rise, the vulnerability of digital infrastructure is drawing increased attention. For instance, a [Chinese ship](https://www.euronews.com/my-europe/2024/11/21/denmark-and-norway-continue-to-investigate-damaged-cables-in-baltic-sea) disrupted undersea internet cables in the Baltic Sea last year – an event that highlights a broader trend, with cybersecurity professionals reporting a growing frequency of deliberate [digital disruptions](https://www.politico.eu/article/russia-sabotage-undersea-cables-baltic-sea-europe-war/). Compounding this is an unprecedented surge in [data breaches](https://www.cdpinstitute.org/news/numbers-hit-by-2024-data-breaches-second-highest-ever-itrc/). Against this troubling backdrop, the move to IPv6 is no longer merely a technical progression, it’s becoming a strategic imperative tied to national security and geopolitical influence. The [cyber threat](https://www.weforum.org/publications/global-cybersecurity-outlook-2025/) environment in 2025 is defined by more advanced attack methods, the rise of AI-driven criminal activity, and persistent threats targeting digital systems. Security professionals around the world emphasise that even small inefficiencies can carry [serious consequences](https://www.mdpi.com/2079-9292/12/6/1333). A prime example is the delay in adopting IPv6, which can leave countries vulnerable to strategic setbacks in connectivity and digital infrastructure, ranging from heightened cybersecurity threats to diminished control over their digital assets. Countries that delay transitioning to IPv6 often remain dependent on IPv4-based systems, which can hinder their digital sovereignty due to the limited availability of IPv4 addresses. This shortage forces reliance on technologies like NAT (Network Address Translation), which restricts direct peer-to-peer communication – an essential requirement for modern innovations such as 5G networks, the Internet of Things, and edge computing. When countries don’t have enough IP address resources, they often end up depending on cloud and network services owned by foreign providers. That weakens their digital independence and puts up major roadblocks in digital trade, especially when it comes to fully joining IPv6-powered systems. Relying on IPv4 infrastructure also increases the risk of facing sanctions or being disconnected from critical routing networks. ### The risk of deepening the digital divide A growing number of nations, among them the U.S., China, Germany, Brazil, and India, are [pushing forward](https://www.stackscale.com/blog/china-plan-ipv6-adoption) with IPv6 adoption as a way to strengthen and modernise their digital infrastructure. Both public institutions and private organisations are taking action, introducing policies, incentives, and support mechanisms designed to speed up the global move away from IPv4 and toward IPv6. Take India, for instance: it completed the transition of all government departments to IPv6 by the [end of 2022](https://timesofindia.indiatimes.com/business/india-business/dot-fixes-december-2022-deadline-for-transition-to-new-ip-addresses/articleshow/87541813.cms), setting a benchmark for national-level adoption. Meanwhile, China is aggressively pursuing its IPv6 [goals](https://blog.apnic.net/2019/06/06/100-by-2025-china-getting-serious-about-ipv6/), targeting at least 60% of internet traffic to run on IPv6 by the close of 2025. Such plans are essential for both the development of digital infrastructure and for achieving security advantages IPv6 unlocks new possibilities for implementing advanced features, something increasingly vital in an era marked by constant cyber threats. More importantly, the rise of [IPv6-only networks](https://blog.apnic.net/2024/10/29/the-realities-of-building-an-ipv6-only-city/) may leave users who still rely on IPv4 facing reduced performance or limited access to parts of the internet. This growing disconnect threatens to widen the digital divide, fueling economic disparities and obstructing participation in global digital trade. Government systems that continue to rely on outdated infrastructure may also find themselves more vulnerable to security breaches. Delaying the shift to IPv6 can significantly hinder a nation’s progress in developing robust digital infrastructure. With every additional connected device, the demand for IP addresses grows, and the ageing IPv4 framework is no longer equipped to handle it. This shortfall creates roadblocks to innovation. Moreover, as the global internet ecosystem increasingly adopts IPv6, systems that rely solely on IPv4 face the danger of becoming outdated and potentially excluded from modern routing networks. It’s important to recognise that IP address resources, and the protocols that manage them, serve as strategic assets. IPv6 represents more than just a technological improvement. It’s a fundamental tool for asserting digital sovereignty. During this phase of transition, IP leasing has become an essential strategy, offering organisations a practical way to navigate the shift from IPv4 to IPv6 and maintain operational continuity. --- ### About the author Vincentas Grinius is a co-founder at [IPXO](https://www.ipxo.com/), an all-in-one automated IP address platform offering secure, compliant, and flexible solutions to drive internet sustainability and help businesses scale. Vincentas has a long track record and 10+ years of experience combining today’s technologies and making IPXO the first IPv4 lease and monetisation platform in the market. The platform brings RIRs, LIRs, and small to large enterprises together to share IPv4 resources and to make the Internet much more sustainable. --- ### About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** FastNetMon Blog **Tags:** guest post, IPv6 --- ### [Outbound DDoS: The attack you might be unknowingly hosting](https://fastnetmon.com/2025/09/24/outbound-ddos-the-attack-you-might-be-unknowingly-hosting/) **Published:** September 24, 2025 **Author:** FastNetMon **Content:** When we talk about DDoS attacks, the focus is almost always on protecting services from inbound floods. But there’s another side to the story that often goes unnoticed: outbound DDoS attacks. These are attacks where malicious traffic originates from inside your network and targets external systems. While the victim suffering the most damage is outside your organisation, some of the responsibility — and the consequences — fall on you as well. If your infrastructure is being used to attack others, you are part of the problem. ### Shared responsibility in a global DDoS epidemic The internet is experiencing a global DDoS epidemic. Attacks are larger, more frequent, and more disruptive than ever before. Every operator has a responsibility to ensure their infrastructure is not contributing to this problem. Outbound DDoS traffic is not just “somebody else’s problem.” If you ignore it, you risk damaging your own reputation, consuming your bandwidth with malicious traffic, and leaving compromised systems unchecked inside your network. Reputation suffers quickly when your network is seen as a source of attacks. Upstream providers may throttle or block your ranges. Customers may lose trust in your ability to secure infrastructure. And, perhaps most importantly, malicious outbound traffic is a clear indicator of a deeper security issue: devices in your network have been compromised or misconfigured. Taking action against outbound DDoS is therefore both an act of industry responsibility and a necessary step in maintaining the security and stability of your own environment. ### Detecting outbound DDoS traffic with FastNetMon The first step in addressing the problem is visibility. Outbound DDoS traffic often manifests as sudden spikes in outbound bandwidth, unusual flows to unexpected destinations, or massive bursts of UDP traffic leaving your network. These patterns are easy to miss without proper monitoring, but with the right tools, they can be identified in real time. FastNetMon is designed to do exactly this. By continuously analysing telemetry from your routers and switches, it builds a baseline of what “normal” traffic looks like. When abnormal spikes or floods appear, FastNetMon detects them instantly and alerts you, or even triggers automated mitigation actions depending on your configuration. This means you can see when your network is being abused for outbound attacks — often before upstream providers or peers notify you. And because FastNetMon Community Edition is free, there is no cost barrier to putting this basic layer of protection in place. Detecting outbound DDoS traffic is not optional or a “nice-to-have.” It is the bare minimum of responsible network operation, and every operator should do it today without an excuse. ### Preventing your network from fuelling attacks Detection is only the beginning. True prevention means stopping malicious traffic before it leaves your network. That starts with enforcing basic hygiene — anti-spoofing (BCP 38/84), sensible egress filters, and securing or disabling any services that can be used for amplification. These measures ensure your infrastructure cannot be easily abused as a launch point for attacks. FastNetMon Advanced extends this protection with **[per-direction hostgroup thresholds](https://fastnetmon.com/docs-fnm-advanced/per-direction-hostgroup-thresholds/)**, allowing operators to define different limits for inbound and outbound traffic. This means you can detect and automatically mitigate outbound floods without affecting normal inbound usage. Combined with features like **BGP FlowSpec** or **RTBH automation**, FastNetMon Advanced gives you precise, real-time control to block abusive traffic at the edge — often before it causes harm to others or damages your reputation. ### Conclusion Outbound DDoS attacks may not cause outages for your own services, but they do cause real harm elsewhere — and ignoring them only increases the risk to your own organisation. As part of the global internet community, operators share responsibility for keeping networks clean and secure. With FastNetMon, detecting outbound DDoS traffic is straightforward, effective, and for this basic use case, free. By taking this basic step, you not only protect your own network, but you also help reduce the scale of the global DDoS problem. The choice is simple: either risk being part of the attack, or take responsibility and make sure your traffic is not being used against others. --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit <https://fastnetmon.com> **Categories:** FastNetMon Blog **Tags:** Network Security Insights, Outbound DDoS --- ### [Help — I’ve Been Sent a Ransom Note from a DDoS Group: What Should I Do?](https://fastnetmon.com/2025/10/16/help-ive-been-sent-a-ransom-note-from-a-ddos-group-what-should-i-do/) **Published:** October 16, 2025 **Author:** FastNetMon **Content:** Every now and then, a network operator’s inbox lights up with a DDoS ransom note — bold claims, big threats, and a bitcoin address waiting for payment. We’ve seen plenty of them ourselves. Some come from actors with real bandwidth behind them; others are clearly written by people who just discovered a booter service. A few are serious, many are ludicrous, and all share the same goal: to scare you into reacting. In this article, we’ll unpack what these ransom DDoS threats are about, why they happen, and what you should actually do when one lands in your inbox. ### **Understanding Ransom DDoS** Ransom Distributed Denial-of-Service (RDDoS) — also known as RDoS — is a form of cyber-extortion in which attackers threaten to overwhelm an organisation’s online infrastructure with massive traffic floods unless a ransom is paid. Unlike ransomware, there is no data theft or encryption; the damage comes from disruption. Attackers rely on fear of downtime, financial loss, and reputational harm to coerce victims into compliance. These campaigns often begin with a short, menacing email sent to public addresses such as noc@ or abuse@, claiming that a powerful attack will begin within hours unless a payment is made in cryptocurrency. Some actors run small “demo” floods to appear credible, while others never send a single packet. The goal is to create urgency and panic — not necessarily to deliver a technically complex attack. ### **A Short History of RDDoS** The concept of pairing denial-of-service with extortion has existed for over a decade. Early organized campaigns surfaced in the mid-2010s, when groups realized that threatening disruption could be just as profitable as stealing data. Since then, RDDoS has matured alongside the broader DDoS ecosystem. Modern attacks are powered by vast botnets composed of compromised IoT and cloud-based systems, capable of delivering multi-terabit floods. Yet many RDDoS campaigns never reach that stage. During global waves of extortion, thousands of ransom emails are sent to potential victims, but only a handful result in actual traffic. Even so, the psychological and operational stress of receiving such threats keeps the tactic effective. ### **How the Attackers Operate** Most RDDoS actors are not highly technical criminals. Many simply harvest contact information for suitable targets — often organizations with visible online services — and send out mass-produced ransom notes in bulk. When a recipient reacts, the attackers may rent capacity from *booter* or *stresser* services to launch a modest flood, buying a few minutes of noise to appear credible. These operators typically reside in regions where cybercrime enforcement is weak or nonexistent, allowing them to continue their campaigns with little risk of prosecution. The more capable groups follow a predictable pattern: an initial ransom note, an optional proof-of-capability attack, and sometimes a brief escalation if ignored. The underlying traffic is conventional DDoS — UDP amplification through DNS or NTP, TCP SYN or ACK floods, or HTTP floods targeting application endpoints. What distinguishes RDDoS from generic denial-of-service is the extortion layer — a human message added to a mechanical attack. From a defender’s standpoint, every ransom note should be logged, timestamped, and correlated with traffic monitoring. The real question is not *whether* to respond but *how* to confirm if any actual flood follows. In most cases, no attack materializes, and the threat disappears as quickly as it arrived. ### **Responding to a Ransom DDoS Threat** The correct response to a ransom DDoS threat is consistent and simple: never pay, never reply, and never engage with the criminals in any way. Paying offers no protection and signals weakness, inviting repeat attempts. There is no negotiation, no honor among extortionists, and no guarantee the attack will stop. Instead, quietly prepare. Confirm that your monitoring systems are active, thresholds calibrated, and mitigation automation ready. If an attack follows, activate your filtering and traffic diversion mechanisms according to plan. Keep detailed logs of the ransom message and any related traffic patterns for internal review and, if necessary, later reporting to law enforcement. If no traffic follows — as is often the case — there is no need for public escalation or panic. Treat it as background noise and an opportunity to validate your readiness. Only when real attack traffic appears should coordination with upstream providers or mitigation partners become necessary. ### **In a nutshell** Ransom DDoS thrives on fear and uncertainty. The attackers count on victims reacting emotionally, not operationally. The real defence is composure: understand the threat, monitor for activity, and maintain proven mitigation workflows. When your network and team are prepared, a ransom DDoS threat is just another event to record and move past — not a crisis to negotiate. The goal is resilience. Build strong detection, responsive filtering, and clear incident procedures so that when the next ransom note arrives, you can log it, monitor for anomalies, and simply ignore it — not debate it. --- ### **About FastNetMon** FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit[ fastnetmon.com](https://fastnetmon.com). **Categories:** FastNetMon Blog **Tags:** basics, ransom DDoS --- ### [FastNetMon Advanced 2.0.370](https://fastnetmon.com/2024/12/16/fastnetmon-advanced-2-0-370/) **Published:** December 16, 2024 **Author:** FastNetMon **Content:** In our latest update, we've added several safety checks in our IPFIX and Netflow v9 code to prevent reading outside of our memory region and potential division by zero. We've also blocked zero length data and options templates for Netflow v9 to reduce chances of DoS attacks. We've fixed a DoS vulnerability in our sFlow v5 plugin and added explicit checks for the number of counter and flow records in sFlow packets. Additionally, we've added logic to correctly populate hostgroup for Flow Spec announces and fixed a bug with traffic buffer size reporting for IPv6. Lastly, we've added Kafka support for traffic export. Full details below. Changes: - Added sanity check in IPFIX code to avoid reading outside of our memory region - Added sanity check in Netflow v9 code to avoid reading outside of our memory region - Added safety check in IPFIX to avoid potential division by zero - DoS: explicitly blocked zero length data templates for Netflow v9 as they have no sense - DoS: explicitly blocked zero length options templates for Netflow v9 as they have no sense - DoS: Added fix for FPE / division by zero in Netflow v9 logic when length of template is zero, CVE [CVE-2024-56073](https://github.com/advisories/GHSA-vwvq-gh67-jhjv) - Added explicit check about number of counter records in sFlow packet to reduce chances of DoS attack - Added explicit check about number of flow records in sFlow packet to reduce chances of DoS attack - Fixed DoS vulnerability in sFlow v5 plugin which crashed FastNetMon with specially crafted packet, [CVE-2024-56072](https://github.com/advisories/GHSA-x89m-rvq3-8g32) - Added logic to correctly populate hostgroup for Flow Spec announces injected manually - Moved current attack logic up in function to grant space for hsotgroup lookup - Switched text/html to text/plain for Prometheus endpoint: [https://github.com/prometheus/docs/blob/main/content/docs/instrumenting/exposition\_formats.md](https://github.com/prometheus/docs/blob/main/content/docs/instrumenting/exposition_formats.md) - Fixed bug with traffic buffer size reporting for IPv6: IPv6 traffic buffer is too small to generate attack\_traffic\_samples correctly and IPv6 traffic buffer is too small to generate hostgroup\_traffic\_samples correctly - Added Kafka support for traffic export via configuration options kafka\_traffic\_export, kafka\_traffic\_export\_topicm kafka\_traffic\_export\_format, kafka\_traffic\_export\_brokers for Kafka traffic export' **Categories:** Releases **Tags:** releases --- ### [Event recap – RIPE 91](https://fastnetmon.com/2025/10/24/event-recap-ripe-91/) **Published:** October 24, 2025 **Author:** Outi Maria Pietilanaho **Content:** ### Packets, People, and Post-Quantum Coffee – Notes from a RIPE Newbie After ten years, the RIPE community returned to Bucharest — a city that’s clearly spent the last decade delightfully upgrading its vibrant tech scene. With 485 participants onsite and another 180 online, RIPE 91 packed a full week of routing revelations, hallway debates, and social events that definitely qualified as heavy-duty networking. FastNetMon was there in full force — us three team members on site taking notes, talking shop, and drinking way too much coffee. It was my first RIPE meeting, so I went in with equal parts curiosity and wide-eyed wonder. Spoiler: it did not disappoint. Here’s what went down. ![](https://fastnetmon.com/wp-content/uploads/2025/10/RIPE-91-FastNetMon-1024x438.png)### ****Monday: Clouds, Keys, and the Joy of Jazz**** RIPE 91 booted up on Monday, October 20th, with Mirjam Kühne’s trademark welcome and a burst of Romanian folk rhythms courtesy of our hosts at InterLAN-IX. Hans Petter Holen reminded us that he’d stood on this same stage ten years ago — a nostalgic reminder that while the Internet evolves, RIPE’s energy remains the same. The opening plenary wasted no time. Yoshinobu Matsuzaki from IIJ led us into the mysterious world of IPv6 scanning, where the address space is so vast you need detective work to find hosts. DNS clues, TLS certificates, and a bit of patience go a long way. The takeaway? In IPv6, silence really is stealth. Tom Strickx from Cloudflare then explored gNMI versus SNMP — old-school versus new-school network monitoring. SNMP may be the granddad of telemetry, but gNMI arrives encrypted, structured, and ready for modern data collection, if you can survive the documentation. Next up, Dirk Doesburg from Radboud University and SIDN Labs brought some cryptographic heat with his proposal for post-quantum-ready RPKI. His hybrid migration strategy avoids painful “flag days” — a pragmatic roadmap for when quantum computing finally crashes the party. The afternoon turned to BGP security. Lefteris Manassakis from Cisco revealed just how sneaky BGP prefix hijacks can be — including one incident targeting root DNS servers that lingered for more than a year. A good reminder that “trust but verify” is not just a proverb; it’s an operational survival tactic. By evening, Monday had delivered what every operator loves: full buffers of knowledge and a mild sense of paranoia about unverified routes. Perfect start. ### **Tuesday: BGP FlowSpec and the FastNetMon + NLnet Labs Collab** Tuesday kicked off with plenaries focused on routing tools and measurement innovation. Luuk Hendriks from NLnet Labs opened with an introduction to Rotonda, their open-source routing analysis platform — a fitting stage for our big announcement: we’re teaming up with NLnet Labs to bring BGP FlowSpec and a host of other advanced capabilities to Rotonda. Together, we’re making routing analytics faster, smarter, and more actionable for operators worldwide. The day’s talks covered plenty of ground. Radu Anghel from TU Delft toured the landscape of route collector projects, unpacking the pros and cons of each data source. Antonios Chariton from Cisco picked up where he left off at RIPE 90, continuing his hunt for BGP “zombie routes” — those undead entries haunting ASes due to update bugs — introducing the Stuck Route Observatory to track and tame them. Branimir Rajtar from 5x9 Networks then demonstrated how his team squeezed 1.2 Tbps throughput from plain x86 gear, proving that software optimization can still outmuscle hardware if you know what knobs to twist. Later, Geoff Huston from APNIC gave everyone an existential crisis with his “measurements in the dark” talk — showing how modern encryption is blinding traditional network telemetry. If you’ve ever wondered why your visibility graphs look emptier these days, Geoff’s your culprit. Security and human-side discussions followed. Yury Zhauniarovich from TU Delft dissected long-lived public secrets, Thomas Daniels from DNS Belgium demonstrated real-time domain-abuse detection, and the Diversity & Inclusion session grounded the day with personal stories about empathy and leadership in tech. Then came the official networking event, which quickly lived up to its name — morphing from handshakes to high-energy dance-floor diplomacy. BGP peering requests may or may not have been exchanged mid-chorus. Let’s call that dynamic route advertisement. ![](https://fastnetmon.com/wp-content/uploads/2025/10/RIPE91-Day2-Tuesday-1024x276.png)### **Wednesday: Scope Creep, Rusty Birds, and Airbeam Hospitality** By Wednesday, caffeine dependency was officially an operational necessity. The day opened with the Connect and Open Source working groups — where Leo Vegoda from PeeringDB, Stefano Servillo from Sapienza University, and Mike Blanche dissected IXPs, route-filtering vulnerabilities, and interconnection policy. In the Open Source WG, Ondrej Zajicek from CZ.NIC used BIRD as a case study in the perils of scope creep, while Annika Hannig shared her beautifully nerdy three-year rewrite of Birdwatcher in Rust — a story equal parts code and courage. The Routing WG picked up with Lisa Bruder, Moritz Müller, and Tim Bruijnzeels covering ASPA and MNRS+ compliance. James Bensley from Inter.link then peeled back the curtain on how transit providers sometimes tweak BGP origin attributes to win traffic, joking that it’s a “zero-sum game, but at least we’re transparent about it.” The Cooperation WG and RIPE NCC Services WG closed the afternoon. Hans Petter Holen walked through the draft 2026 Activity Plan and Budget, while Antony Gollan, Eleonora Petridou, and Robert Kisteleki led a live poll on AI at the RIPE NCC — where the audience enthusiastically voted yes, then changed their mind 20 minutes later. Democracy in action. As daylight faded, Airbeam hosted an unofficial dinner that became the night’s highlight — excellent food, relaxed company, and enough route-policy discussion to qualify as continuing professional education. Thanks, Airbeam — you kept the RIPE 91 crowd cheerful and very well fed. Somewhere later that evening, the famous Whiskey BoF was said to be taking place — that mythical after-hours tradition where a small room, unlimited whiskey, and an indeterminate number of network engineers collide. As a first-timer, I was already far too tired to confirm its existence, but judging from the stories, it was smoky, peaty, and surprisingly well-peered. ### **Thursday: IPv6 Reality Checks and DNS Tea** Thursday arrived too early for anyone who danced the previous night, but the IPv6 Working Group was already awake. Dmitry Melnik gave the wake-up call: doing nothing about IPv6 costs more than doing something. Wilhelm Boeddinghaus and Jen Linkova reinforced the point with real-world deployments and Android updates that make IPv6 just a bit easier to love. The Database WG finally said farewell to MD5 passwords (yes, some were still out there). Ed Shryane’s operational update drew cheers for “zero whois outages,” which is basically a mic-drop in registry terms. Over in DNS land, Jim Reid’s Hyperlocal Roots talk and Ulrich Wisser’s timing deep-dives had the room buzzing. By the end, the co-chairs handed Willem Toorop a well-earned farewell gift: tea, of course. Because the DNS WG always has a bit of tea to spill. The community plenary wrapped everything up with RIPE Chair transitions, strategy previews, and one last standing ovation for Niall O’Reilly. By the time the RIPE dinner and party rolled around, Bucharest was glowing. Between the laughter, good food, and the inevitable debates about whether ASPA should be mandatory, it was the perfect send-off to an incredible week. ### **Wrapping up RIPE 91: Bucharest, you beauty** RIPE 91 reevalled me why this community is special: it’s smart, funny, opinionated, and somehow still functional after four nights of social events. From our FlowSpec partnership with NLnet Labs to every conversation in the hallways, this was a week of true collaboration and connection — the kind that keeps the Internet alive and evolving. One of our teammates is actually from Bucharest, so they had the home-field advantage, but for the rest of us the city was a revelation — warm people, late nights, and golden autumn light. We’re already hoping to be back soon. Thanks to everyone who stopped by to chat with us, share ideas, or share the dance floor. See you all at RIPE 92! --- ### **About FastNetMon** FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit[ fastnetmon.com](https://fastnetmon.com). **Categories:** Press & Newsroom **Tags:** events --- ### [Event recap - RITE 2025](https://fastnetmon.com/2025/10/28/event-recap-rite-2025/) **Published:** October 28, 2025 **Author:** FastNetMon **Content:** FastNetMon joined the Romanian Internet Technologies Event (RITE) this week in Bucharest — a gathering focused on how decentralisation, enhanced security and shifting traffic dynamics are reshaping the Internet. Organised by ANISP together with the Internet Society, RITE brings together ISPs, content providers, and infrastructure operators to debate some of the most critical topics driving today’s digital economy: AI, cloud, IoT, quantum computing, sustainability of network infrastructure, regulatory change and — of course — security. ### Spotlight on DDoS: Hyper-Scale Attacks Are Here Our colleague Virgil Truica spoke in the AI & Security session, sharing his perspective on the state of DDoS mitigation and what ISOC Pulse data tells us about current attack patterns. ![](https://fastnetmon.com/wp-content/uploads/2025/10/rite-2025-095-1024x683.jpg)His key message: > Hyper-scale DDoS attacks are no longer a future concern — they’re already shaping how providers must protect their networks. Responding to this shift requires: - Real-time traffic visibility - Automated mitigation at scale - Collaboration across the network operator community At FastNetMon, this is exactly where we focus: enabling defenders to detect and stop large-scale traffic anomalies before they cause service impact. If you missed the presentation, you can flip through the slides below! [DDoS Attacks 2025 Trends and Mitigation - RITE2025](https://fastnetmon.com/wp-content/uploads/2025/10/DDoS-Attacks-2025-Trends-and-Mitigation-RITE2025.pdf)[Download](https://fastnetmon.com/wp-content/uploads/2025/10/DDoS-Attacks-2025-Trends-and-Mitigation-RITE2025.pdf) ### Strong Conversations, Strong Community RITE continues a great run of high-quality industry events in Bucharest this season — and we were glad to be part of the discussions again. Thank you to the organisers and everyone who joined the session. We’re looking forward to the next opportunity to meet the community and talk network security. --- ### About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit[ fastnetmon.com](https://fastnetmon.com/). **Categories:** Press & Newsroom **Tags:** events --- ### [Indian ISP Protects Against Large Volumetric DDoS Attacks with FastNetMon](https://fastnetmon.com/2023/02/01/indian-isp-protects-against-ddos-with-fastnetmon/) **Published:** February 1, 2023 **Author:** FastNetMon **Content:** For an ISP, DDoS attacks can be hugely damaging. A large volumetric attack can disrupt customer-facing services, harming an ISP’s business model, damaging the customer experience, and potentially costing the business heavily in SLAs. In 2017, an Indian ISP contacted [Anurag Bhatia](https://anuragbhatia.com/), a Network Researcher based in Haryana, India, after experiencing several DDoS attacks. The ISP had been the victim of several large volumetric DDoS attacks and needed Anurag’s help to implement a solution. ### Large Volumetric Attacks Saturate ISP’s Upstream Bandwidth The attacks had been much higher in volume than the ISP’s available bandwidth and had also saturated its upstream bandwidth. This created an additional challenge, as an attack of this scale can’t be mitigated by an on-site device and must instead be dealt with upstream. To combat similar attacks in the future, Anurag suggested the ISP request a BGP blackholing service from its upstream provider and manually blackhole traffic when an attack occurs. This solution would allow the ISP to signal to its upstream provider when an attack occurred, providing details of which IP address pools were under attack. The provider would then either drop traffic to these IPs directly or relay the same information to a larger network in their upstream, which would drop the traffic from all edge routers, i.e., as close as possible to the entry point of the attack. When a blackhole is activated, all incoming and outgoing traffic to specified IP pools is dropped without responding to the sender to inform them their data did not reach its intended target. The ISP adopted this solution and manually switched on blackholing each time an attack occurred. While this solution effectively mitigated large DDoS attacks, the process was labour-intensive. It required the ISP’s network engineers to manually identify which IP pools were under attack and activate the blackhole. Instead, the ISP needed a solution that would automatically identify DDoS attacks—including which IP pools were targeted—and immediately apply the appropriate blackhole rules. ### The Solution: Fast, Accurate Detection with FastNetMon FastNetMon is one of the fastest DDoS detection tools on the market, able to detect even the most advanced multi-vector attacks within seconds. Crucially, FastNetMon gives network administrators full control over the mitigation process, allowing them to design, configure, monitor, and manage DDoS defences that suit their organisation’s needs, budget, and network hardware. Having discovered FastNetMon through an NLNOG presentation by Job Snijders, Principal Engineer at Fastly, Anurag recommended it to the ISP. The solution supports a broad range of capture engines, including port mirroring, NetFlow, sFLOW, IPFIX, which feed it information about incoming traffic. It can detect incoming DDoS attacks quickly based on increases in bandwidth usage, packet per second (Pps) count, and flow count. It also enables network engineers to alter each parameter based on past attack profiles. Most importantly, FastNetMon can be configured to automatically signal routers to drop malicious traffic *and* export BGP policies to any upstream provider’s blackhole community. This ensures the remediation process is robust against even large volumetric attacks that saturate a targeted organisation’s upstream bandwidth. Network engineers can define how long an IP remains blocked and automate the unblocking process after a defined period. Combined, these features made FastNetMon an ideal solution for the ISP. It would allow them to automate the DDoS detection and blackholing process, reducing manual effort and minimising time to mitigation for new attacks. Seeing this, the ISP engaged Anurag to support the setup process. ### Detecting DDoS Attacks in 2-3 Seconds Initially, the ISP tried using NetFlow with a Mikrotik CCR router to feed FastNetMon traffic data. However, this led to a delay in detecting new attacks of almost two minutes. This was not an ideal solution, as it exposed the ISP and its upstream provider to large attacks for nearly two minutes. Instead, they opted to use port mirroring with a Cisco switch which dropped all transit packets and tagged them with specified VLANs. The switch then mirrored these VLANs to FastNetMon, providing traffic data more quickly and enabling the solution to detect new attacks within 2-3 seconds. While FastNetMon supports DDoS detection from multiple indicators, the ISP opted to set detection rules based exclusively on bandwidth limits for incoming traffic. This matched the profile of the large volumetric attacks it had experienced. ### Mitigating DDoS Attacks with BGP Blackholing Once an attack was detected, the next step was to apply the correct mitigation rules. Again, there were several options available to complete this process. For instance, the ISP could have used standard BGP-based signalling—FastNetMon would simply maintain a BGP session with a router and inform it whenever an IP came under attack. This solution would work as standard, as all of the ISP’s routers supported BGP. Instead, the ISP opted to use a [dedicated plugin](https://github.com/elmaxid/Fastnetmon-MikroTik-Plugin) for Mikrotik devices developed by Maximiliano Dobladez from [MKE Solutions](https://www.mkesolutions.net/). The plugin uses a PHP-based API to alter rules on the router. The ISP selected this mitigation option because the plugin included a feature that would add a comment to blackhole route announcements, allowing for clearer communication with upstream providers. With this in place, the ISP had a complete DDoS detection and mitigation solution that could automatically identify and mitigate DDoS attacks within seconds—eliminating manual burden for the network team and reducing the lag between the start of a new attack and mitigation. ### Recovering From an Attack The final component of this DDoS mitigation strategy is removing blackhole rules once an attack has finished. While blackholing is extremely useful, it can’t be left on indefinitely—affected IPs must eventually be restored to regular use. To achieve this safely, FastNetMon allows network administrators to periodically check whether an attack has ended after a specified time. The process is simple. Once the specified time—e.g., five minutes—has passed, FastNetMon disables blackhole rules. If the solution detects the attack is still ongoing, it reinstates the blackhole and announces it to upstream providers, mitigating the attack. This way, the ISP is only exposed to the attack for a very short period (around 7-8 seconds) before re-establishing blackhole mitigation. Once an attack has ended, FastNetMon will no longer reinstate blackhole rules, restoring the network to normal functionality. ### Protect Your Organisation with FastNetMon FastNetMon is one of the market's fastest DDoS detection and mitigation solutions. Designed to be the brains of a best-of-breed DDoS mitigation strategy, it can uncover even the most complex, multi-vector attacks in a few seconds. Our solution integrates seamlessly with all your network hardware, mitigation controls, and analytics. Built *by* network people *for* network people, FastNetMon puts control firmly in the hands of network administrators, giving them the power to design, configure, monitor, and manage their network operations (including DDoS mitigation) to suit your organisation’s needs, budget, and topology. Want to keep your network safe? [Try FastNetMon FREE for one month](https://fastnetmon.com/trial/). **Categories:** FastNetMon Blog **Tags:** case study --- ### [Russias food safety under DDoS attack](https://fastnetmon.com/2025/10/31/russias-food-safety-under-ddos-attack/) **Published:** October 31, 2025 **Author:** FastNetMon **Content:** Russia’s national food-safety regulator, Rosselkhoznadzor, faced a [DDoS incident](https://fastnetmon.com/2025/08/05/what-is-a-ddos-attack-history-motives-and-methods-explained/) last week that took down its digital certification systems and disrupted product shipments across the country. ### What happened? On 22 October 2025, a DDoS attack flooded the public-facing services of VetIS and Saturn. The Mercury interface became unreachable, blocking certificate generation and validation. Suppliers could not confirm shipments, and some retailers stopped accepting deliveries entirely until access was restored. Officials said the attack did not affect stored data, only availability. Connectivity returned later that day once network operators filtered the malicious traffic. Availability loss alone can cascade into full operational shutdowns when regulatory systems are centralised and interdependent. The VetIS and Saturn platforms sit at the core of Russia’s national food-safety infrastructure. Both are operated by Rosselkhoznadzor and used daily by producers, distributors, and regional authorities to keep agricultural shipments moving. VetIS is a large online environment that links veterinary services, laboratories, logistics providers, and retailers. It manages everything from test results to product traceability records and shipment approvals. Inside VetIS, the Mercury subsystem issues electronic veterinary certificates (EVCs) — mandatory digital documents for meat, dairy, and other animal-based products. Without them, goods cannot legally move through the supply chain. Saturn supports VetIS by handling high-volume transaction processing and synchronisation between regional databases. It acts as the control layer that keeps Mercury and other VetIS modules consistent across thousands of connected endpoints ### Repeated outages This is the fourth disruption of Mercury in 2025. Previous outages also forced a temporary return to paper-based certificates, showing how dependent supply chains have become on a single online system ### Technical takeaways No telemetry data has been published, but the symptoms are consistent with a [volumetric](https://fastnetmon.com/2025/07/30/understanding-volumetric-amplification-ddos-attacks/) or [protocol-layer flood](https://fastnetmon.com/2025/09/04/understanding-application-layer-low-and-slow-ddos-attacks/). Even without direct compromise, the operational effect was severe: delayed shipments, unprocessed certificates, and growing backlogs at regional distribution centres. From a network-operations standpoint: 1. Availability is a regulatory dependency. When certification or [tracking systems](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-connection-tracking/) go down, the impact spreads far beyond IT. 2. Early escalation to upstream ISPs remains one of the fastest recovery paths in such incidents. 3. Service observability (pps, concurrent sessions, flow counts) is often the first indicator that something abnormal is happening. 4. Resilience means fallback. Offline or redundant workflows, even if temporary, are worth keeping tested. ### Perspective for operators DDoS can disrupt **entire national logistics chains** when digital certification systems go offline. Even systems that aren’t labelled ‘critical infrastructure’ can bring supply chains to a halt if they’re central to approvals or tracking. For operators, the lessons are clear: [**continuous traffic monitoring, real-time visibility into service health, and fast coordination with upstream providers**](https://fastnetmon.com/traffic-visibility/) are the only reliable ways to contain outages. Fallback procedures such as offline processes, queued validations, or alternate communication channels, should be tested and ready because when these systems go down, delays ripple across multiple industries in real time. --- ### About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit <https://fastnetmon.com> **Categories:** FastNetMon Blog **Tags:** DDoS Attacks --- ### [FastNetMon Advanced 2.0.373](https://fastnetmon.com/2025/10/16/fastnetmon-advanced-2-0-373/) **Published:** October 16, 2025 **Author:** FastNetMon **Content:** **Release date:** 16 October, 2025 **Version:** 2.0.373 FastNetMon Advanced 2.0.373 has been released with security hardening, telemetry enhancements, and new integrations. We’ve added device allow-lists for Netflow v5/v9 and IPFIX collectors and introduced a Flow Spec–based allow list to tighten policy control. AF\_PACKET mode now populates input/output interfaces using kernel interface indices, and usage telemetry can export internal and other traffic classes. This release adds GCore support for scrubbing integration and improves troubleshooting by printing the sFlow agent IP when sample parsing fails. Breaking change: sudo fcli show traffic\_buffer now returns packets in JSON instead of writing them to the log. We also enabled CGNAT use for internal IPs on external licenses and deprecated CentOS 7. Full details below. ### Full list of changes: - Added logic to print agent IP address when we have error with parsing sFlow samples - Added logic to export other and internal traffic in usage telemetry - Breaking change: sudo fcli show traffic\_buffer will start returning packets in JSON instead of logging them to log file - Added GCore support for scrubbing integration - Update scrubbing integration to latest version to add gCore support - Added full logic to implement Flow Spec based allow list - Added logic to lock down Netflow v5, v9 and IPFIX to only specific list of routers: ipfix\_devices\_allow\_list, netflow\_v9\_devices\_allow\_list, netflow\_v5\_devices\_allow\_list - Added logic to populate input and output interfaces information in AF\_PACKET mode by using internal linux network number which can be got via sudo ip link in first column - Allowed usage of CGNAT for internal IP address for external licenses - Deprecated CentOS 7 ### Learn more [FastNetMon Advanced documentation ](https://fastnetmon.com/docs-fnm-advanced/) [View this release on GitHub](https://github.com/FastNetMon/fastnetmon-advanced-releases/releases/tag/v2.0.373) **Categories:** Releases **Tags:** releases --- ### [DDoS botnet Aisuru drives record outbound floods from infected ISP-hosted IoT](https://fastnetmon.com/2025/10/15/ddos-botnet-aisuru-drives-record-outbound-floods-from-infected-isp-hosted-iot/) **Published:** October 15, 2025 **Author:** FastNetMon **Content:** *Aisuru*, a massive IoT botnet, recently pushed outbound traffic close to **30 Tbps** from infected devices inside major U.S. ISPs — one of the largest DDoS events ever recorded. [Outbound DDoS attacks](https://fastnetmon.com/2025/09/24/outbound-ddos-the-attack-you-might-be-unknowingly-hosting/), where malicious traffic leaves your network rather than entering it, are increasingly straining upstream capacity and exposing operators to significant operational and reputational risk. Let’s look at what’s happening across ISP networks, why outbound DDoS requires a different response model, and how **FastNetMon’s per-direction hostgroup thresholds** can help detect and suppress such attacks quickly. ### **Aisuru: record outbound floods shake U.S. ISPs** As reported by[ KrebsOnSecurity](https://krebsonsecurity.com/2025/10/ddos-botnet-aisuru-blankets-us-isps-in-record-ddos/), *Aisuru* has rapidly evolved into the world’s most disruptive IoT botnet. On **October 6, 2025**, it briefly reached a staggering **29.6 terabits per second** in outbound traffic — a short-lived record-breaking flood allegedly connected to the [major gaming platform outages](https://fastnetmon.com/2025/10/08/another-record-breaking-ddos-aisuru-botnet-suspected-behind-29-69-tbps-gaming-outages/). Aisuru draws its strength from hundreds of thousands of compromised consumer devices — routers, cameras, and DVRs — many hosted within U.S. broadband providers. This heavy domestic concentration means large volumes of attack traffic now *originate* from inside the same networks that deliver internet access to millions of customers, amplifying the risk of collateral congestion and service degradation. In recent months, Aisuru had already broken several records: [a 11 Tbps flood](https://fastnetmon.com/2025/09/03/cloudflare-mitigates-record-breaking-11-5-tbps-ddos-attack/) in September, followed by an [attack measuring 1.5 billion packets per second](https://fastnetmon.com/2025/09/09/1-5-billion-packets-per-second-ddos-attack-detected-with-fastnetmon/) just a few weeks later, and another one reaching [**22 Tbps**](https://fastnetmon.com/2025/09/23/a-new-world-record-ddos-attack-22-2-tbps/). While many of these attacks targeted gaming networks and hosting providers, they collectively signaled a broader shift — DDoS traffic is no longer primarily an *inbound* threat. Increasingly, it’s something operators must monitor and control on the *way out*. The latest wave of events shows that even large ISPs can struggle when hundreds of thousands of their own customer devices begin transmitting at terabit-per-second rates simultaneously. Outbound attacks of this scale don’t just affect their immediate targets — they can congest peering links, disrupt adjacent services, and trigger automatic mitigation or rate limiting from upstream peers. **The ability to detect and suppress outbound abuse in real time is now an operational necessity, not an optional safeguard.** ### **Why outbound DDoS demands a new defensive mindset** The Aisuru events revealed a simple but often-overlooked truth: some of the largest DDoS attacks in history are now being launched **from within ISP networks** themselves. Infected consumer IoT devices are generating enormous volumes of outbound traffic, concentrated across limited egress points, overloading shared uplinks and affecting legitimate customers. Unlike traditional inbound DDoS events, these floods **originate inside your own infrastructure**, often going unnoticed until they congest upstream links or trigger mitigation from peers. Operators can’t directly disinfect or patch customer IoT devices, but they *can* **contain and control their behavior** at the network level. That means detecting abusive sources early, limiting their impact, and automating response wherever possible. Mitigation starts with **visibility** — monitoring egress flows per host and per direction — followed by **automated containment** that can throttle or block malicious traffic before it leaves the network. Networks that rely only on manual intervention or inbound defenses are already behind the curve. This is where **FastNetMon** comes in: it gives operators the per-direction visibility, thresholds, and automation required to detect and suppress outbound attacks in real time. ### **FastNetMon approach to outbound DDoS — technical overview** FastNetMon analyses **NetFlow**, **IPFIX**, **sFlow**, or **mirrored packet samples** to detect abnormal per-host traffic rates in real time. Exporters should use short export intervals (≤30 seconds) and appropriate sampling (1:1000 or finer) for best responsiveness. Detection is based on **packets per second (pps)**, **bytes per second (bps)**, and **flows per second**. To detect outbound events specifically, enable per\_direction\_hostgroup\_thresholds = true in FastNetMon Advanced. This allows operators to configure **different thresholds for outbound traffic**, applying more aggressive limits to egress flows that indicate abuse. When thresholds are exceeded, FastNetMon can trigger automatic mitigations: - **BGP FlowSpec** rules to drop or rate-limit malicious traffic directly at the router. - **Dynamic ACL insertion** at access or aggregation layers. - **Local blackhole routing** as a controlled, short-term containment measure. Integration via **Ansible**, **NETCONF**, or **REST APIs** ensures automated and consistent deployment across multi-vendor environments. For configuration details, see the documentation: [Per-direction hostgroup thresholds — FastNetMon Advanced](https://fastnetmon.com/docs-fnm-advanced/per-direction-hostgroup-thresholds/?utm_source=chatgpt.co) ### **The bigger picture** Aisuru’s record-setting floods mark a turning point for the industry: large-scale DDoS attacks now originate from inside broadband networks, powered by infected IoT devices. Outbound detection is no longer optional — it’s essential to maintaining stability and reputation. With **FastNetMon Advanced**, operators can deploy per-direction thresholds, automate containment, and stop outbound abuse in real time — protecting not only their own customers, but the wider internet. --- ### **About FastNetMon** FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats.For more information, visit[ fastnetmon.com](https://fastnetmon.com). **Categories:** FastNetMon Blog **Tags:** Aisuru, DDoS News, ISP --- ### [Event recap - BalticNOG 2025](https://fastnetmon.com/2025/09/30/event-recap-balticnog-2025/) **Published:** September 30, 2025 **Author:** FastNetMon **Content:** Last week we joined the Baltic network operator community in Vilnius for **BalticNOG 2025**. The two-day event brought together engineers, researchers, and operators from across the region to share knowledge and experiences on building and securing the internet. The programme was packed with technical depth and practical insights. From Geoff Huston’s thought-provoking *“Networking in the Dark”* to hands-on case studies and lively panels, the event reinforced BalticNOG’s role as one of the most valuable community-driven gatherings for network professionals. ## **Bringing BGP Flow Spec Into Practice for DDoS Mitigation** FastNetMon Co-Founder Pavel Odintsov took the stage on day one to present about BGP Flow Spec for DDoS mitigation. His session focused on the realities of deploying Flow Spec in production environments, including varying levels of vendor support and common implementation pitfalls. With DDoS remaining a major operational challenge, the session resonated strongly with the operator audience and sparked valuable discussion. Get the presentation slides [here](https://fastnetmon.com/wp-content/uploads/2025/09/Pavel-Odintsov-FastNetMon-at-BalticNOG-2025-BGP-Flow-Spec-for-DDoS-Mitigation-practical-aspects.pdf)! ![](https://fastnetmon.com/wp-content/uploads/2025/09/BalticNOG-BGP-Flow-Spec-for-DDoS-mitigation-FastNetMon-1024x768.png)## **Other Highlights** One of the standout talks came from **Timur Pertenava of RETN**, who shared his perspective on *“Future-Proofing Global Connectivity: Trends, Threats, and Tactics for a Resilient Network.”* His insights into building resilience into backbone infrastructure resonated with many in the room who face similar challenges in their own networks. ![](https://fastnetmon.com/wp-content/uploads/2025/09/BalticNOG-2025-Event-Recap-by-FastNetMon-REITN-Timur-presentation-1024x768.jpeg)The **Network Resilience Panel** also sparked an engaging discussion on how operators can maintain stability under pressure, bringing together different perspectives from across the community. Later in the programme, several speakers provided updates on building secure and reliable infrastructure in difficult environments, alongside practical sessions on defending peering networks against DDoS and blackholing risks. Another memorable moment was **Paulius Judickas’s** presentation *“The Curious Case of IPv4: Sustaining the Internet Until IPv6 Arrives.”* This talk revisited the ongoing reality of IPv4 scarcity and the creative ways in which the industry continues to extend its lifetime while preparing for broader IPv6 adoption. ![](https://fastnetmon.com/wp-content/uploads/2025/09/BalticNOG-2025-Event-Recap-by-FastNetMon-Paulius-Judickass-presentation-The-Curious-Case-of-IPv4-1024x768.jpeg)Day two continued with an equally strong set of sessions on automation, orchestration, and datacenter networking best practices. The panel discussion *“IPv6: From Hype to Reality”* generated particularly lively debate on the pace of adoption, shedding light on both successes and remaining barriers in moving toward a fully IPv6-enabled internet. ## **Looking Ahead** As always, BalticNOG delivered on its reputation: a highly technical, community-driven event with open knowledge sharing at its core. We were glad to meet many friends, partners and customers, and to contribute to the ongoing conversation on how to make networks more resilient against ever-changing threats. And of course, we also gave away some cool **FastNetMon merch** at the sticker table, which proved to be a popular stop for attendees. ![](https://fastnetmon.com/wp-content/uploads/2025/09/BalticNOG-2025-and-FastNetMon-event-recap-1024x768.jpeg)A big thank you to the organisers and volunteers who made the event possible. We’re already looking forward to the next one! --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit <https://fastnetmon.com> **Categories:** Events, Press & Newsroom **Tags:** events --- ### [Behind the screen. Non-technical story of FastNetMon: From GitHub to a Brand with the Global Name.](https://fastnetmon.com/2025/10/13/behind-the-screen-non-technical-story-of-fastnetmon-from-github-to-a-brand-with-the-global-name/) **Published:** October 13, 2025 **Author:** FastNetMon **Content:** Today, FastNetMon protects networks of all sizes from DDoS attacks and serves customers in dozens of countries worldwide. But how did it all begin? This is the story of the company's early days—not from a technical perspective, but from the journey of building the brand, operations, and community that shaped what FastNetMon is today. I am Kate, co-founder and CEO of FastNetMon since the very first day the company was set up.*(If you’re interested in the technical milestones of our product, you can read more here:* [*Reflecting on 10 Years in Open Source Network Security – FastNetMon*](https://blog.apnic.net/2025/08/20/reflecting-on-10-years-in-open-source-network-security-fastnetmon/)*).* --- ### The Beginning Pavel and I met in 2012 in a local online chat. We originally were from the same region, but left our home cities shortly after graduation from the universities. Pavel had a very deeply technical mind, while I was more business-focused, but we both shared a passion for technology and what was happening in the industry. Those early conversations quickly grew into a friendship. During one of the meetings, in 2014, Pavel told me about his open-source project he started to develop in 2013 which later became his hobby and got some interest on GitHub. He told me he had some challenges with that because people wanted more information about the tool, but GitHub didn’t have a lot of capabilities to share it. I suggested building a separate website for this tool that would help to overcome these challenges and add some flexibility and he asked if I could help with that. By then, I had already built strong skills in digital marketing and online strategy through my post-graduation work at one of EMEA’s leading tech companies, and I was excited to contribute. ### Finding the Name One of the first tasks was giving the project a proper name. After brainstorming hundreds of ideas (some of them were just wild) we landed on **FastNetMon** which means: - **Fast** – speed and responsiveness - **Net** – network - **Mon** – monitoring It was simple, clear, and reflected the product perfectly. ### Building the First Website The first FastNetMon website launched in 2015. It was very simple—basic visuals, straightforward text with some search engine optimisation for helping users find us faster. Despite its chaotic design, it gave the project visibility beyond GitHub and helped introduce the tool to a wider audience. As interest grew, users started asking for more advanced features that couldn’t be included in the open-source version. That’s when the idea of **FastNetMon Advanced** was born. In 2016, we launched a beta, with 65 community members participating in testing, and their feedback shaped the early features of the product. By the end of the year, the first commercial version was available on our website. ![](https://fastnetmon.com/wp-content/uploads/2025/09/Screenshot-of-the-first-website-1024x469.png)### Creating the Brand We knew we needed to build a brand, but with no budget in the beginning, our marketing tools were extremely limited. I chose to focus on content and building a social media presence. It required a lot of time and effort, but it allowed us not only to spread the word about what we were doing but also to share valuable tips and insights on network security. At that time, the industry was still relatively new, and very few companies were openly sharing their expertise. I also created simple visuals for all social posts and websites, so everything was done by hand. ![](https://fastnetmon.com/wp-content/uploads/2025/09/FastNetMon-early-social-media-assets-1024x491.png)We also needed a logo that would reflect our mission. A friend of mine volunteered to create one for us for free. The result was the name with a light-blue lightning symbol instead of N—simple, striking, and memorable—which quickly became recognised by our customers and remains unchanged to this day. ![](https://fastnetmon.com/wp-content/uploads/2025/09/FastNetMon-company-story-logo-1024x491.png)At the same time, we defined our brand colours: **blue** for reliability, **white** for calmness, and **salmon** for care. Together, they represented how we wanted customers to feel: you can rely on FastNetMon, and you can rest easy knowing your network is under reliable protection. These colours would later become the dominant theme of the redesigned website we launched in 2021. We began building a community to bring passionate network engineers together in one place. It was never meant to be commercial—and it still isn’t. The goal was simple: to support people in their fight against attacks, create a space where they could share what worked for them, and ask questions to their peers. Community was in our DNA—it shaped the Advanced edition and has always been at the heart of how we grow. ### Bootstrapping the Business In the first few years, it was just the two of us. Pavel was deep in development and support, while I was juggling everything else—marketing, communications, branding and operations. The list of tasks never seemed to end; in fact, it only kept growing. We worked late nights, weekends, and even holidays, all with zero budget to bring in extra help. ![](https://fastnetmon.com/wp-content/uploads/2025/09/Early-days-Story-of-FastNetMon-company-history-1024x646.png)*Catching up on post comments during a night, / Fixing a bug*We made the decision not to take outside investment, even if we had a couple of offers. We wanted the freedom to focus on what mattered: our users, our mission, and the product. That path wasn’t easy. Sometimes we wished we could move faster, chase every idea we had. But being bootstrapped forced us to slow down, to plan carefully, to listen closely to our customers and make choices that truly served them. I still remember the moment we received our very first payment. It was pure joy—the kind of happiness that makes all the sleepless nights worth it. We even saved a screenshot of it as a reminder of that milestone. It was a turning point for us—a moment of validation that what we were building truly mattered. ![](https://fastnetmon.com/wp-content/uploads/2025/09/celebration-768x1024.jpg)*Celebrating the first payment*And through it all, it was the support, trust and feedback of our earliest adopters that kept us going and believed that we were building something that mattered. ### A Turning Point The pandemic changed everything. As the world moved online, cyberattacks exploded. Many businesses needed effective protection, and they came to us. By that time, our presence online was already established with social media, community,y and website became more visible on searches. At the same time, DDoS attacks were evolving in both scale and tactics. Our flexibility allowed us to respond quickly, adding new features faster than larger competitors and adapting the product to meet market needs. As the world gradually returned to in-person events after COVID, we began attending industry events such as RIPE, NANOG, and DDoS Day. Meeting our users face-to-face and hearing firsthand how FastNetMon was helping them was incredibly rewarding. ![](https://fastnetmon.com/wp-content/uploads/2025/09/FastNetMon-conference-pictures-1.png)![](https://fastnetmon.com/wp-content/uploads/2025/09/NANOG-N88-fastnetmon-1024x727.png)![](https://fastnetmon.com/wp-content/uploads/2025/09/FastNetMon-early-days--1024x659.png)In 2021, we furthered our commitment to the industry by joining the UK Cyber Security Council and participating in its initiatives. ### Growing Beyond Two People As awareness grew, so did our team. We expanded into new regions like Latin America, North America and Asia, working closely with partners to overcome cultural and language barriers. We brought on new team members in marketing, sales, and content, which allowed us to explore new channels and strategies to reach customers around the world. At the same time, our roles within the company began to shift, moving from hands-on tasks toward more strategic and management responsibilities. ![](https://fastnetmon.com/wp-content/uploads/2025/09/team-1024x613.jpg)### My Personal Journey For me, FastNetMon has been more than a business. When I joined, it was just an open-source tool on GitHub. Today, it’s a recognised name in network security with customers around the world. Being a female CEO in a technical industry has not been easy at all, but it has been deeply rewarding. My background is in cyberpsychology and the human factors behind cyberattacks. DDoS is a very technical type of attack, but behind every attack is also intent, motivation, and human behaviour. Bringing that perspective to the company, alongside Pavel’s deep technical expertise, gave us a unique foundation to grow. ![](https://fastnetmon.com/wp-content/uploads/2025/09/NCSC-635x1024.jpg)Now, my chapter here is coming to a close. It’s time for me to explore new opportunities. But I will always carry pride in what we built together: a company that started from nothing, grew through community, and stayed true to its mission—to provide a versatile DDoS detection tool for organisations of all sizes and help make the internet a safer place.I will always be open for our customers, partners and followers, and if you want to contact me, you can find me on LinkedIn: <https://www.linkedin.com/in/kate-fateeva/> **Categories:** FastNetMon Blog **Tags:** leadership announcements --- ### [Linux 6.18 improves server performance under DDoS attacks](https://fastnetmon.com/2025/10/09/linux-6-18-improves-server-performance-under-ddos-attacks/) **Published:** October 9, 2025 **Author:** FastNetMon **Content:** Recent kernel updates led by **Google engineer Eric Dumazet**, and first reported by [**Michael Larabel (Phoronix)**](https://www.phoronix.com/news/Linux-6.18-DDoS-Improvement), show that **Linux 6.18** delivers significant improvements in how servers handle high-rate DDoS traffic. The work focuses on **optimising the UDP receive path** under stress—scenarios where multiple CPU cores handle massive packet floods targeting one or more sockets. Dumazet’s changes reduce lock contention and improve how packets are queued and processed across NUMA nodes, leading to much better scalability and stability during [DDoS events](https://fastnetmon.com/2025/08/05/what-is-a-ddos-attack-history-motives-and-methods-explained/). ### What changed in Linux 6.18 The patch series reorganises several parts of the UDP and IPv6 stack for greater efficiency. Socket structures were streamlined to improve cache locality, while shared spinlocks were replaced with **per-socket and per-NUMA-node lockless queues**. This allows each CPU to handle incoming packets independently, reducing contention and making it possible to process traffic in batches without significant latency penalties. The update also adopts skb\_attempt\_defer\_free(), a mechanism that previously improved TCP performance, now applied to UDP for better memory handling under load. Together, these low-level changes reduce CPU overhead when many cores process concurrent packet streams. ### Performance under DDoS conditions Testing on a **six-NUMA-node Intel Xeon platform** demonstrated a **47% increase in UDP receive throughput** during simulated DDoS attacks. The host processed an additional **14.2 million packets per second** compared to previous kernel versions. These improvements mean that Linux systems can now sustain higher packet rates before dropping traffic or experiencing congestion within the networking stack. Legitimate packets are less likely to be delayed or lost, even as total packet volume surges. ### Implications for operators For operators running Linux-based servers, these kernel changes provide a stronger foundation before any external mitigation kicks in. Services that rely on high-volume UDP traffic—such as DNS resolvers, game servers, or real-time applications—will see more predictable behaviour under flood conditions without additional tuning. By reducing unnecessary CPU contention and dropped-packet noise, the update also improves the quality of network telemetry. This translates into cleaner signal data for tools such as **FastNetMon**, allowing for more accurate detection and faster response during attack events. ### A quiet but meaningful milestone Linux 6.18 is expected to become the next **Long-Term Support (LTS)** kernel release, meaning these improvements will soon reach most enterprise and cloud environments. While not a replacement for dedicated mitigation measures, the changes make Linux inherently more resilient—absorbing more attack traffic before defences need to activate. --- ### About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit <https://fastnetmon.com> **Categories:** FastNetMon Blog **Tags:** DDoS News, Linux --- ### [Another record-breaking DDoS? Aisuru botnet suspected behind 29.69 Tbps gaming outages](https://fastnetmon.com/2025/10/08/another-record-breaking-ddos-aisuru-botnet-suspected-behind-29-69-tbps-gaming-outages/) **Published:** October 8, 2025 **Author:** FastNetMon **Content:** ### Incident summary: - **Date:** October 6, 2025 - **Targets:** Steam, Riot Games, PlayStation Network, AWS, and others - **Peak bandwidth (unconfirmed):** 29.69 Tbps - **Suspected source:** Aisuru botnet - **Attack vector (reported):** TCP-based carpet bomb traffic - **Status:** Under investigation — no official confirmation ### What we know so far Several major gaming platforms — including Steam and Riot Games — experienced simultaneous disruptions on October 6th. Players reported widespread connectivity issues across titles such as Counter-Strike, Dota 2, Valorant, and League of Legends. While the cause has not been confirmed, early reports from the cybersecurity community point to a possible large-scale DDoS attack. The Aisuru botnet, previously associated with record-breaking incidents, has been mentioned as a potential source. If verified, this event could have peaked at **29.69 Tbps**, surpassing the 22.2 Tbps attack recorded in September. ### Simultaneous outages across platforms Outage data from Downdetector shows a sharp increase in reports starting around 8:00 PM EDT. Players across multiple regions noted sudden disconnections and login failures. Riot Games acknowledged the problem on its service status page and temporarily disabled ranked play. Steam users also reported intermittent downtime and error messages. Other major services — including PlayStation Network, Epic Games, AWS, and multiple ISPs — experienced higher-than-usual error reports around the same time, suggesting a broader internet-scale event. ### Aisuru botnet suspected, but not confirmed No official statement has yet confirmed the nature of the disruptions. However, researchers and independent analysts have speculated that the **Aisuru botnet** could be involved. Aisuru has previously delivered several multi-terabit DDoS attacks since its discovery in 2024, most recently peaking at 22.2 Tbps in September. Reports shared on social media platforms X and Reddit suggest the latest spike may have reached **29.69 Tbps**, though these figures remain unverified. The attack was reportedly characterised by “sophisticated TCP carpet bomb” traffic — a method that closely mimics legitimate packets, complicating detection and mitigation. ### Escalation in scale and sophistication If the reports prove accurate, this incident marks another step in the steady rise of DDoS capacity over the past year. Large-scale botnets like Aisuru continue to expand through vulnerable IoT devices — routers, cameras, gateways, and other internet-connected hardware — providing attackers with vast distributed bandwidth. Aisuru is estimated to control more than 300,000 compromised nodes globally and has demonstrated an ability to sustain multi-terabit floods against diverse targets. FastNetMon continues to monitor the situation and track developments related to large-scale DDoS activity. We will update this story as more verified data becomes available. --- ### About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit <https://fastnetmon.com> **Categories:** FastNetMon Blog **Tags:** Aisuru, DDoS Attacks, DDoS News, gaming --- ### [Event recap - RONOG 10](https://fastnetmon.com/2025/09/29/event-recap-ronog-10/) **Published:** September 29, 2025 **Author:** FastNetMon **Content:** On 18 September 2025, the Romanian Network Operators Group hosted **RONOG 10** in Bucharest. The one-day conference, organised by InterLAN, brought together network operators, engineers, regulators, and technology providers to share technical knowledge and exchange ideas. Held at the Radisson Blu Hotel, the event combined presentations, networking breaks, and plenty of hallway conversations — creating a space where operators could discuss the challenges and opportunities shaping today’s Internet infrastructure. ## FastNetMon at RONOG 10 Our colleague **Virgil Truica** presented **“DDoS Attacks 2025: Trends & Mitigation – The Era of Hyper-Scale Attacks.”**. Get the presentation slides [here!](https://fastnetmon.com/wp-content/uploads/2025/09/DDoS-Attacks-2025-Trends-and-Mitigation-RONOG10_final.pdf) ![](https://fastnetmon.com/wp-content/uploads/2025/09/Virgil-Truica-FastNetMon-speaking-at-RONOG10-1024x634.jpg)The talk explored how DDoS threats are evolving, with a particular focus on the rise of hyper-scale attacks that push existing defences to their limits. Virgil shared fresh statistics and recent trends observed across the global operator community, highlighting both shifts in attacker behaviour and the growing sophistication of their tools. The session also touched on practical mitigation approaches that can help operators stay prepared as these threats continue to scale. ## Highlights from the agenda Beyond FastNetMon’s contribution, the programme was full of insightful presentations spanning network resilience, automation, security, and future technologies. The morning opened with a session on recent subsea cable disruptions, where RETN explored the cascading effects of failures on routing and resilience across Europe and Asia. Later, ZET.NET offered a fascinating look into how intelligent automation is enabling them to scale their global backbone towards 50 Tbps, providing a concrete example of automation as a necessity rather than a choice for operators running large infrastructures. ![](https://fastnetmon.com/wp-content/uploads/2025/09/Image-from-RONOG10-1024x619.jpg)Security remained a strong theme throughout the day. NBIP examined the challenge of defending European networks against DDoS in an increasingly fragmented world, while Recorded Future gave a technical breakdown of the DDoSia cybercriminal group and their methods. These talks, together with Virgil’s, sparked plenty of discussion on how operators can share knowledge and strengthen defences collectively. The agenda also branched into other pressing topics for operators. [IPXO](https://www.ipxo.com/) revisited the ongoing role of IPv4 in sustaining the Internet as IPv6 adoption progresses slowly, and RIPE NCC presented an update on Romania’s position as a growing interconnection hub in South Eastern Europe. Towards the end of the day, the focus shifted to people and technology, with sessions on workplace culture and mental health, as well as forward-looking perspectives on the role of AI and large language models in shaping the networks of the future. ## Looking back RONOG is not only a solid platform for knowledge sharing in the operator community, it’s also a genuinely enjoyable event. From the presentations and hallway chats to the afterparty, it was great to catch up with familiar faces and meet new ones. We’re glad we could be part of the conversations on keeping networks secure and resilient — and already looking forward to the next edition. --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** Events, Press & Newsroom **Tags:** events --- ### [A new world record DDoS attack: 22.2 Tbps](https://fastnetmon.com/2025/09/23/a-new-world-record-ddos-attack-22-2-tbps/) **Published:** September 23, 2025 **Author:** FastNetMon **Content:** The cybersecurity landscape witnessed a new benchmark in DDoS attacks as Cloudflare reported mitigating a hyper-volumetric assault that peaked at 22.2 terabits per second (Tbps) and 10.6 billion packets per second (Bpps). This attack more than doubled the previous UDP flood record of 11.5 Tbps only a few weeks ago, underlining the accelerating capabilities of botnets and the sophistication of modern attackers. Unlike traditional prolonged campaigns, this attack unfolded in a “hit-and-run” fashion, lasting approximately 40 seconds. Attackers combined multiple vectors, including volumetric floods, protocol misuse, and application-layer noise, to maximise disruption within a very narrow window. The sheer scale of the traffic indicates the use of massive botnets composed of compromised servers and Internet-of-Things devices, orchestrated to saturate network pipes and exhaust server resources. The assault’s intensity and brevity demonstrate a shift toward flash DDoS tactics, which are designed to strike and vanish before manual mitigation can be applied. Technical details of the attack reveal a peak of 10.6 Bpps, indicating that the traffic was not just volumetrically extreme but also highly packet-intensive. UDP amplification and reflection techniques appear to have been leveraged to generate the surge, stressing network hardware and testing the limits of edge routers and firewall appliances. We have detected [very similar attacks](https://fastnetmon.com/2025/09/09/1-5-billion-packets-per-second-ddos-attack-detected-with-fastnetmon/) with FastNetMon in recent weeks. These types of attacks require rapid detection and automated mitigation to prevent service disruption. ### Hypervolumetric attacks are becoming the new normal The pace at which record-breaking DDoS attacks are emerging is a growing concern. Only a few weeks ago, the previous peak of [11.5 Tbps was reported](https://fastnetmon.com/2025/09/03/cloudflare-mitigates-record-breaking-11-5-tbps-ddos-attack/)—already a major milestone at the time. Now, that record has been more than doubled with this 22.2 Tbps event. This frequency marks a sharp departure from the past. Two to three years ago, large-scale DDoS incidents of this magnitude were rare, with perhaps one or two significant events each year. Five years ago, even double-digit terabit-per-second floods were virtually unheard of. Today, hypervolumetric attacks are reported every few weeks, driven by ever-expanding botnets and increasingly automated attack tooling. For defenders, this shift demonstrates not just the rising scale but also the accelerating tempo of the threat landscape—demanding faster detection, larger capacity, and fully automated mitigation pipelines. ### FastNetMon with Cloudflare Integration FastNetMon is a leading solution for network security, providing advanced DDoS detection and mitigation with real-time analytics and rapid response capabilities. It helps organisations identify attacks early and protect their infrastructure from evolving threats. FastNetMon Advanced integrates natively with Cloudflare Magic Transit, enabling seamless mitigation of DDoS attacks. When an attack is detected, FastNetMon can automatically trigger traffic redirection to Cloudflare’s global scrubbing centres. This ensures that only malicious traffic is sent for cleaning, while legitimate traffic continues to flow normally, delivering powerful scrubbing capacity on demand without unnecessary cost. For more information, visit[ https://fastnetmon.com](https://fastnetmon.com) **Categories:** FastNetMon Blog **Tags:** DDoS Attacks, DDoS News --- ### [Press Release: FastNetMon detects a record-scale DDoS attack](https://fastnetmon.com/2025/09/09/press-release-fastnetmon-detects-a-record-scale-ddos-attack/) **Published:** September 9, 2025 **Author:** FastNetMon **Content:** *London, UK – Tuesday, September 9th 2025* – FastNetMon today announced that it detected [a record-scale distributed denial-of-service (DDoS) attack](https://fastnetmon.com/2025/09/09/1-5-billion-packets-per-second-ddos-attack-detected-with-fastnetmon/) targeting the website of a leading DDoS scrubbing vendor in Western Europe. The attack reached **1.5 billion packets per second (1.5 Gpps)** — one of the largest packet-rate floods publicly disclosed. The malicious traffic was primarily a **UDP flood** launched from compromised customer-premises equipment (CPE), including IoT devices and routers, across more than **11,000 unique networks worldwide**. The disclosure comes only days after Cloudflare reported mitigating an 11.5 Tbps DDoS attack, showing how attackers are pushing both packet and bandwidth volumes to unprecedented levels. “**This event is part of a dangerous trend**”, said Pavel Odintsov, Founder of FastNetMon. “When tens of thousands of CPE devices can be hijacked and used in coordinated packet floods of this magnitude, the risks for network operators grow exponentially. The industry must act to implement detection logic at the ISP level to stop outgoing attacks before they scale.” **FastNetMon Advanced platform** is designed to handle attacks of this size. Using highly optimised C++ algorithms for real-time network visibility, FastNetMon enabled its customer to automatically detect the flood within seconds — preventing disruption to the target service. ![](https://fastnetmon.com/wp-content/uploads/2025/09/Detected-and-mitigated-DDoS-attack-traffic-FastNetMon-1-1024x507.jpg)--- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit <https://fastnetmon.com> ## Press contact Outi Maria Pietilanaho Innovation & Insights FastNetMon <outi@fastnetmon.com> **Categories:** Press & Newsroom **Tags:** Press Releases --- ### [1.5 billion packets per second DDoS attack detected with FastNetMon](https://fastnetmon.com/2025/09/09/1-5-billion-packets-per-second-ddos-attack-detected-with-fastnetmon/) **Published:** September 9, 2025 **Author:** FastNetMon **Content:** *Breaking DDoS news from FastNetMon* At FastNetMon, we recently worked with a customer — a DDoS scrubbing provider — who faced one of the largest DDoS attacks ever publicly recorded. - **The target:** the provider’s website - **The scale:** 1.5 billion packets per second in a sustained UDP flood - **The source:** compromised CPE, including IoT devices and MikroTik routers, spread across **11,000 unique networks worldwide** ![](https://fastnetmon.com/wp-content/uploads/2025/09/Detected-and-mitigated-DDoS-attack-traffic-FastNetMon-1024x507.jpg)This disclosure comes shortly after Cloudflare announced mitigation of an **[11.5 Tbps DDoS attack](https://fastnetmon.com/2025/09/03/cloudflare-mitigates-record-breaking-11-5-tbps-ddos-attack/)**. Taken together, these incidents show that adversaries are escalating both packet volumes and bandwidth floods beyond what many networks are prepared to handle. What makes this case remarkable is the sheer number of distributed sources and the abuse of everyday networking devices. Without proactive ISP-level filtering, compromised consumer hardware can be weaponised at a massive scale. FastNetMon detected the flood in real time, giving the customer immediate visibility into its size and distribution. Mitigation was then carried out using the provider’s own scrubbing facility, supported by ACLs deployed on edge routers for known amplification vectors. Both the **open-source FastNetMon Community Edition** and the **FastNetMon Advanced platform** are powerful tools for detecting outgoing attacks in real time. While the Community Edition provides robust detection capabilities for a range of networks, **FastNetMon Advanced is designed for extreme scalability and high-performance environments**. Some examples of how FastNetMon Advanced handles very large networks: - **Netflow/IPFIX and sFlow modes:** deployments exceeding **2 Tbps** of traffic have been proven. In these modes, FastNetMon Advanced scales almost indefinitely, using a proprietary high-performance C++ packet parser. - **Port mirror / SPAN mode:** FastNetMon Advanced can leverage all available CPU resources. Typically, 2–4 CPU cores are needed per 10–40G port, but with kernel-side sampling, requirements can drop to 1–2 CPU cores for a 40G interface with a high-quality network card. This technical efficiency allows operators to detect **large-scale, high-speed attacks** in real time, giving them the visibility required to act quickly and protect critical services from billion-packet floods. This case demonstrates why scalable detection is more important than ever. As attacks grow larger and more distributed, only modern, high-performance approaches to network visibility can meet the challenge. --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats.For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** FastNetMon Blog **Tags:** DDoS Attacks, DDoS News --- ### [Cloudflare mitigates record-breaking 11.5 Tbps DDoS attack](https://fastnetmon.com/2025/09/03/cloudflare-mitigates-record-breaking-11-5-tbps-ddos-attack/) **Published:** September 3, 2025 **Author:** FastNetMon **Content:** Cloudflare has disclosed that it successfully mitigated the largest DDoS attack recorded to date — a hyper-volumetric UDP flood peaking at **11.5 terabits per second (Tbps)**. The attack **lasted only 35 seconds**, but its scale tells something about the growing headaches network operators face in defending against cloud-enabled botnets capable of overwhelming infrastructure in seconds. ### **What happened** - The attack traffic originated largely from compromised resources within **Google Cloud Platform (GCP)**, though currently, Google disputes this claim. - Attack volume ramped from background noise to over 11 Tbps in **under** **10 seconds**. - The attack was mitigated with **rate-limiting and IP filtering** immediately, which prevented service disruption. This event surpassed the **7.3 Tbps DDoS attack reported in June 2025**, which itself was record-setting at the time. The new peak represents a **12% increase in bandwidth volume** over previous attacks. ### **Details of the attack: a UDP flood a massive scale** The 11.5 Tbps assault was a **UDP flood**, aimed at a single IP address and distributed across more than **21,000 ports per second** at peak. Cloudflare reports that traffic volume spiked from near zero to record levels in less than 10 seconds, overwhelming normal traffic patterns before defences kicked in. UDP remains a preferred vector for hyper-volumetric attacks because of its **stateless design**. Each packet forces the target to allocate processing resources without a handshake, making it easy to exhaust bandwidth and CPU. When attackers hijack cloud instances with effectively unlimited outbound capacity, the impact is amplified — enabling short but devastating bursts of traffic that can saturate backbone links. ### **Broader trend: hyper-volumetric DDoS campaigns** This attack was part of a wider wave of assaults observed in recent weeks, including multiple events exceeding **1 Tbps** and one that delivered **5.1 billion packets per second (Bpps)**. The trend is clear: adversaries are leveraging **public cloud infrastructure** to orchestrate short-lived, massive-scale attacks that overwhelm traditional on-premises defences. ### **Implications for network operators** For defenders, the key challenges are: - **Speed of escalation** – Attacks can peak within seconds, leaving no time for manual intervention. - **Cloud-scale adversaries** – Attackers now wield the same elastic resources defenders rely on. - **Protocol choice** – UDP floods remain highly effective for bandwidth saturation. ### **Takeaway** While record-breaking attacks like this one grab headlines, **attack volume is only part of the story**. Smaller but more persistent floods, application-layer disruptions, and multi-vector campaigns can be just as damaging or more, if they slip past detection. Defending against DDoS requires a **holistic view** — monitoring the full spectrum of attack types, sizes, and durations — not just preparing for the “biggest attack ever”. For network operators, this particular incident is a reminder to: - Continuously review DDoS response strategies. - Ensure visibility into traffic at high granularity (packet rates, protocol mix, source distribution). - Rely on automation for mitigation at line rate. --- ## FastNetMon with Cloudflare Integration FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. FastNetMon Advanced also [integrates natively with **Cloudflare Magic Transit**](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-integration-with-cloudflare-magic-transit-scrubbing-centre/), enabling seamless redirection of attack traffic to Cloudflare’s global scrubbing centres. When FastNetMon detects an attack, it can automatically trigger mitigation through Magic Transit, ensuring traffic is cleaned before reaching the target network. For more information, visit <https://fastnetmon.com> **Categories:** FastNetMon Blog **Tags:** DDoS Attacks, DDoS News --- ### [Network Engineering Community News: August 2025](https://fastnetmon.com/2025/08/28/network-engineering-community-news-august-2025/) **Published:** August 28, 2025 **Author:** FastNetMon **Content:** In this month's issue: register for our webinar with Inter.link, see where to meet us at RONOG10, learn about scrubbing centre automation, read our APNIC feature on 10 years in open-source security, and catch up with fresh DDoS and network security news. If you want to get even cooler version of this newsletter straight to your inbox, sign up [here!](https://cdn.forms-content.sg-form.com/b3c8181d-c30d-11ef-b203-ca12671f70d2) --- ## Webinar: Network Threat Landscape 2025 with Inter.link [ ![Webinar](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff8a0299c956ef43d12ab7f1a40ef114862c0b64df77fe9c6c08a1ed16341ae0/images/fastnetmoninterlink_webinar_ddos_network_security.png) ](https://zoom.us/webinar/register/WN_KZsKoGHMTM-X_hHLm9Pk_g#/registration) **Date:** 19 September at 13:30 CET FastNetMon’s Pavel Odintsov and Inter.link’s Ciprian Abaseaca share fresh stories from the front lines of DDoS mitigation and network defence. Sign up and join us! [SIGN UP](https://zoom.us/webinar/register/WN_KZsKoGHMTM-X_hHLm9Pk_g#/registration) --- [ ![APNIC Blog](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff8a0299c956ef43d12ab7f1a40ef114862c0b64df77fe9c6c08a1ed16341ae0/images/reflecting_on_10_years_in_open_source_network_security_lessons_from_fastnetmon.png) ](https://blog.apnic.net/2025/08/20/reflecting-on-10-years-in-open-source-network-security-fastnetmon/) ## A decade of open source DDoS defence: our musings on the APNIC blog From humble beginnings as a small open source project, FastNetMon has evolved to help shape DDoS and network security worldwide. We reflect on what’s changed, lessons learned, and what’s next. Read our story on the APNIC blog. [READ OUR STORY ON APNIC](https://blog.apnic.net/2025/08/20/reflecting-on-10-years-in-open-source-network-security-fastnetmon/) --- ## How to automate scrubbing centres into your DDoS defence stack? [ ![Scrubbing Automation](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff8a0299c956ef43d12ab7f1a40ef114862c0b64df77fe9c6c08a1ed16341ae0/images/screenshot_20250820_at_152003.png) ](https://fastnetmon.com/2025/08/06/ddos-scrubbing-centre-automation-explained/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=ddos-scrubbing-centers-explained&utm_term=august) Scrubbing centres are a powerful defence against large-scale DDoS attacks – but routing all your traffic through them 24/7 adds cost and latency. FastNetMon automates on-demand diversion so scrubbing only activates when an attack hits. [READ THE GUIDE](https://fastnetmon.com/2025/08/06/ddos-scrubbing-centre-automation-explained/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=ddos-scrubbing-centers-explained&utm_term=august) --- ## Join us at RONOG next month! [ ![RONOG10](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff8a0299c956ef43d12ab7f1a40ef114862c0b64df77fe9c6c08a1ed16341ae0/images/ronog_newsletter_visual1.png) ](https://www.ronog.ro/) We’re heading to RONOG 10 in Bucharest on September 18th! Virgil Truica from our team will talk about DDoS trends and effective modern mitigation. RONOG always means real conversations—come say hi! [JOIN US AT RONOG 10](https://www.ronog.ro/) --- ## Industry News Here are some interesting industry takes and major DDoS incidents you should know about. Enjoy the reading! [ ![RapperBot takedown](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff8a0299c956ef43d12ab7f1a40ef114862c0b64df77fe9c6c08a1ed16341ae0/images/screenshot_20250821_at_155647.png) ](https://fastnetmon.com/2025/08/19/u-s-authorities-take-down-rapperbot-ddos-for-hire-service-after-370000-attacks/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=rapperbot-taken-down-after370000-attacks&utm_term=august) **US authorities take down RapperBot DDoS-for-hire service after 370,000 attacks.** One of the largest known DDoS-for-hire operations was shut down, linked to more than 370,000 attacks. A win for defenders, but similar services are likely to pop up. All details [here](https://fastnetmon.com/2025/08/19/u-s-authorities-take-down-rapperbot-ddos-for-hire-service-after-370000-attacks/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=rapperbot-taken-down-after370000-attacks&utm_term=august). [ ![MadeYouReset http2 DDoS](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff8a0299c956ef43d12ab7f1a40ef114862c0b64df77fe9c6c08a1ed16341ae0/images/screenshot_20250821_at_155833.png) ](https://fastnetmon.com/2025/08/13/madeyoureset-the-new-http-2-ddos-threat-and-mitigation-strategies/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=madeyoureset_new_ddos_threat&utm_term=august) **MadeYouReset: the new HTTP/2 DDoS threat & mitigation strategies.** A new HTTP/2 attack technique forces servers to reset connections at scale. What’s behind it, how is it different, and how can you mitigate? We explain [here](https://fastnetmon.com/2025/08/13/madeyoureset-the-new-http-2-ddos-threat-and-mitigation-strategies/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=madeyoureset_new_ddos_threat&utm_term=august). [ ![Windows DC DDoS attacks](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff8a0299c956ef43d12ab7f1a40ef114862c0b64df77fe9c6c08a1ed16341ae0/images/screenshot_20250821_at_160242.png) ](https://fastnetmon.com/2025/08/11/win-dos-new-windows-zero-click-vulnerabilities-enable-domain-controller-powered-ddos-botnets/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=win-dos-new-windows-zero-click-vulnerabilities&utm_term=august) **WinDoS: New zero-click Windows vulnerabilities for DDoS botnets.** Security researchers flag zero-click Windows bugs already abused in the wild—turning domain controllers into DDoS botnet assets. Find info and defensive steps [here](https://fastnetmon.com/2025/08/11/win-dos-new-windows-zero-click-vulnerabilities-enable-domain-controller-powered-ddos-botnets/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=win-dos-new-windows-zero-click-vulnerabilities&utm_term=august). [ ![Drama Monero DDoS](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff8a0299c956ef43d12ab7f1a40ef114862c0b64df77fe9c6c08a1ed16341ae0/images/screenshot_20250821_at_160920.png) ](https://fastnetmon.com/2025/08/05/ddos-or-drama-qubics-monero-takeover-attempt-sparks-controversy/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=qubics-monero-takeover-attempt&utm_term=august) **DDoS or drama? Qubic’s Monero takeover attempt sparks controversy.** The messy takeover attempt for Monero by the Qubic community spilled over into the DDoS world, sparking attacks and heated debate. Ideology, finance, and network abuse collide; full story [here](https://fastnetmon.com/2025/08/05/ddos-or-drama-qubics-monero-takeover-attempt-sparks-controversy/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=qubics-monero-takeover-attempt&utm_term=august). --- ## 💌 Get this newsletter straight to your inbox Sign up to our monthly Network Engineering Community News [here](https://cdn.forms-content.sg-form.com/b3c8181d-c30d-11ef-b203-ca12671f70d2) **Categories:** Newsletter **Tags:** Community, Newsletter --- ### [Making Sense of Network Telemetry: FastNetMon Featured on LACNIC](https://fastnetmon.com/2025/08/26/making-sense-of-network-telemetry-fastnetmon-featured-on-lacnic/) **Published:** August 26, 2025 **Author:** FastNetMon **Content:** FastNetMon was recently featured on LACNIC, where our Founder, Pavel Odintsov provides a practical guide to network telemetry for operators. The article explains the differences between flow-based protocols like NetFlow and IPFIX, and packet-based approaches such as sFlow and PSAMP, highlighting their trade-offs, use cases, and real-world performance. Drawing on a decade of experience testing telemetry across hundreds of networks, Pavel shares best practices for choosing the right protocol for fast detection, anomaly tracking, and DDoS response. The article also emphasises why low-latency, high-quality telemetry is essential for modern network visibility. Read the full article on LACNIC [here](https://blog.lacnic.net/en/making-sense-of-network-telemetry-a-practical-guide-for-operators/). --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** Press & Newsroom **Tags:** press features --- ### [Arch Linux Confirms Week-Long DDoS Attack on Core Infrastructure](https://fastnetmon.com/2025/08/26/arch-linux-confirms-week-long-ddos-attack-on-core-infrastructure/) **Published:** August 26, 2025 **Author:** FastNetMon **Content:** The Arch Linux project has confirmed that its core infrastructure has been under sustained [DDoS attack](https://fastnetmon.com/2025/08/05/what-is-a-ddos-attack-history-motives-and-methods-explained/) for more than a week. The campaign, which began on **August 16, 2025**, has disrupted user access to the project’s main website, the Arch User Repository (AUR), and the community forums. Service interruptions remain ongoing, with many users reporting intermittent connectivity and degraded performance. ## ​​**What is Arch Linux?** Arch Linux is a lightweight, rolling-release Linux distribution that gives users full control over their system. Instead of shipping with preconfigured defaults, it provides a minimal base that can be customised to fit specific needs. Software is delivered through official repositories and the **Arch User Repository (AUR)**, a large community-maintained package collection. Arch is widely used by experienced Linux users and system administrators who value flexibility, transparency, and up-to-date software. ## **Technical Characteristics of the Attack** The Arch Linux DevOps team has described the incident as a [**volumetric Layer 3/4 flood**](https://fastnetmon.com/2025/07/30/understanding-volumetric-amplification-ddos-attacks/). Attack traffic has saturated available bandwidth and exhausted server resources, overwhelming the project’s hosting environment. The disruption has been most visible to users as **TCP SYN resets** on initial connection attempts. In many cases, subsequent retries succeed, but latency and reliability remain inconsistent. Mitigation measures deployed to date include **TCP SYN authentication** provided by the hosting provider, as well as **emergency rate limiting and selective traffic filtering** to reduce malicious flows. The team has also relied on **geo-distributed mirrors** to ensure that key downloads such as installation images remain available. Coordination with upstream providers is ongoing, and the project has confirmed that it is evaluating commercial DDoS protection solutions. However, as a volunteer-driven project, Arch Linux emphasised that any long-term decision must balance **cost, technical efficacy, and ethical considerations**. ## **Service Impact and User Workarounds** While the main Arch Linux domains remain partially degraded, the project has published recommended workarounds to maintain continuity of operations. These include alternative mirror endpoints for packages and ISOs, GitHub-hosted AUR mirrors, and offline snapshots of the Arch Wiki. | **Affected Service** | **Alternative Endpoint / Mirror** | **Access Instructions** | |---|---|---| | **archlinux.org main site** | Default mirror list from `pacman-mirrorlist` package | Use `reflector` or manually update `/etc/pacman.d/mirrorlist` with entries from `pacman-mirrorlist`. | | **Installation ISOs** | Geomirror archive (<https://geo.mirror.pkgbuild.com/iso/>) | Download ISO and verify signature with key `0x54449A5C`. | | **aur.archlinux.org** | GitHub AUR mirror (<https://github.com/archlinux/aur>) | `git clone --branch --single-branch https://github.com/archlinux/aur.git `. | | **wiki.archlinux.org** | `arch-wiki-docs` or `arch-wiki-lite` snapshots | Use offline snapshots or static mirror repositories. | Arch Linux has urged users to verify their mirror configurations and leverage these fallback mechanisms until primary services are fully restored. ## **Ongoing Response and Next Steps** To maintain transparency, the project has launched[ **status.archlinux.org**](https://status.archlinux.org/) as its official communications channel for real-time updates. Automated health checks have been implemented to provide visibility into the availability of the website, AUR, forums, and supporting infrastructure. Forensic data and log collections are being preserved for post-incident analysis. The project has stated that a **comprehensive post-mortem** will be published once the attack subsides. This report is expected to include root cause analysis, details of the mitigation effort, and potential attribution if feasible. Despite limited resources, the Arch Linux team has impressively maintained essential functionality through mirrors and fallback endpoints, while working with providers to contain the impact of the attack. --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** FastNetMon Blog **Tags:** DDoS Attacks, DDoS News --- ### [Reflecting on 10 Years of Open Source DDoS Defense: FastNetMon Featured on APNIC](https://fastnetmon.com/2025/08/20/reflecting-on-10-years-of-open-source-ddos-defense-fastnetmon-featured-on-apnic/) **Published:** August 20, 2025 **Author:** FastNetMon **Content:** FastNetMon was recently featured on the APNIC blog, where FastNetMon Founder Pavel Odintsov reflects on a decade of the DDoS landscape while building the open source DDoS detection platform. What started as a small proof-of-concept tool in a home lab has grown into a globally deployed system trusted by ISPs, hosting providers, and enterprises. The article explores how DDoS attacks have evolved over the last ten years—from simple volumetric floods to multi-vector, automated campaigns—and how FastNetMon has adapted in response, adding flow-based detection, BGP integrations, and high-speed analytics. We also share lessons learned from developing an operator-focused, high-performance security tool, including the importance of simplicity, performance, and community-driven development. Through every feature and improvement, operator feedback has been at the heart of FastNetMon’s growth, helping make DDoS detection fast, reliable, and accessible. Join us down memory lane and read the full article on APNIC [here](https://blog.apnic.net/2025/08/20/reflecting-on-10-years-in-open-source-network-security-fastnetmon/). --- # **About FastNetMon** FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats.For more information, visit <https://fastnetmon.com> **Categories:** Press & Newsroom **Tags:** press features --- ### [U.S. Authorities Take Down “RapperBot” DDoS-for-Hire Service After 370,000 Attacks](https://fastnetmon.com/2025/08/19/u-s-authorities-take-down-rapperbot-ddos-for-hire-service-after-370000-attacks/) **Published:** August 19, 2025 **Author:** FastNetMon **Content:** The U.S. Department of Justice has charged a 22-year-old Oregon man for operating *RapperBot*, a large-scale botnet-for-hire that powered more than 370,000 DDoS attacks between April and August 2025. Built on tens of thousands of compromised IoT devices, the botnet was linked to some of the most disruptive attacks of the past year, including the March 2025 flood that knocked Twitter/X offline. Federal agents arrested Ethan J. Foltz of Springfield, Oregon on August 6, seizing administrative control of RapperBot’s infrastructure. According to the criminal complaint, Foltz admitted to running the botnet together with a partner known online as “Slaykings.” The two split profits and rented out access to paying customers, many of whom used the service to extort businesses. Gambling operators in China were among the most frequent victims, but attacks were recorded across Japan, the United States, Ireland and Hong Kong. RapperBot, also called “Eleven Eleven Botnet” and “CowBot in some instances,” is a direct descendant of the Mirai malware that has fueled some of the largest DDoS events since 2016. The botnet borrowed heavily from fBot, or Satori, and spread by brute-forcing Telnet and SSH credentials to compromise routers, DVRs and other IoT devices. Once infected, those devices became part of a network capable of overwhelming almost any online service. By the time of Foltz’s arrest, RapperBot had enslaved an estimated 65,000 to 95,000 devices worldwide. The botnet was capable of launching floods that consistently measured between two and three terabits per second, with some campaigns exceeding six terabits. Investigators noted that such traffic volumes were hundreds of times greater than the typical capacity of a data center server. Most customers were only permitted to launch short, one-minute floods, but trusted clients were granted access to longer and more destructive campaigns. Beyond DDoS-for-hire, RapperBot was also used to hijack device computing resources to mine cryptocurrency, adding an extra revenue stream for its operators. The investigation traced Foltz through a series of digital breadcrumbs. One of RapperBot’s command servers was hosted at an ISP in Arizona and paid for via PayPal. That account led investigators to Foltz’s Gmail address, which in turn revealed repeated Google searches for “RapperBot” and updates about competing botnets. When confronted, Foltz admitted his role and even provided chat logs detailing his collaboration with Slaykings. Just before his arrest, he told his partner that he had discovered 32,000 new vulnerable devices and declared, “Once again we have the biggest botnet in the community.” RapperBot’s takedown was part of Operation PowerOFF, an international initiative to dismantle DDoS-for-hire services. Amazon Web Services supported the effort by helping identify command-and-control servers across 39 countries and reverse engineering the malware to map its operations. The case is being prosecuted in the District of Alaska, where some of the infected devices were located. Although Foltz faces a maximum sentence of 10 years in prison, legal experts note that such an outcome is unlikely for a first-time conviction. Still, the disruption of RapperBot marks a significant milestone. Since Mirai’s source code was leaked nearly a decade ago, countless botnets have emerged by repurposing its methods, and RapperBot was one of the most notorious to date. Its fall demonstrates that law enforcement and industry cooperation can dismantle even large, well-managed DDoS operations — but it also serves as a reminder that the wider ecosystem of IoT botnets continues to evolve. --- # **About FastNetMon** FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats.For more information, visit <https://fastnetmon.com> **Categories:** FastNetMon Blog **Tags:** DDoS News, legal --- ### [MadeYouReset: The New HTTP/2 DDoS Threat and Mitigation Strategies](https://fastnetmon.com/2025/08/13/madeyoureset-the-new-http-2-ddos-threat-and-mitigation-strategies/) **Published:** August 13, 2025 **Author:** FastNetMon **Content:** MadeYouReset is a new HTTP/2 DDoS vector related to 2023’s Rapid Reset. By provoking the server to reset streams with malformed frames, an attacker keeps backend request processing alive while freeing the stream from HTTP/2 accounting. One TCP connection can drive an effectively unbounded number of in-flight requests through a proxy to origins. Patching affected implementations and enforcing **request and control-frame rate limits** are the fastest mitigations. ## **What’s new vs. Rapid Reset?** - **Rapid Reset:** the **client** floods RST\_STREAM to cancel streams quickly, exhausting server resources via per-stream churn. - **MadeYouReset:** the attacker sends **invalid frames** so that the **server** emits RST\_STREAM (hence “made you reset”). The stream is considered closed for MAX\_CONCURRENT\_STREAMS, but backend work continues. Result: a single connection can keep origins busy far beyond negotiated stream limits. Imperva and Tel Aviv University disclosed the issue; CERT/CC described it as a mismatch between HTTP/2 stream accounting and actual backend activity. At the time of disclosure, no exploitation in the wild was reported. The attack also blends with normal traffic, so naïve RPS or connection counters may not light up. ## **Affected software and patch status** The underlying flaw (CVE-2025-8671) impacts a wide set of HTTP/2 stacks and proxies/projects, including **AMPHP, Apache Tomcat, Eclipse Foundation projects, F5, Fastly, gRPC, Mozilla, Netty, SUSE Linux, Varnish Software, Wind River, and Zephyr Project**. Patches have been released by **Apache Tomcat, F5, Fastly, and Varnish**; others are investigating or preparing fixes. Some vendors track the issue under their own CVE IDs. (Mozilla noted Firefox itself is not affected; their hosted services are being patched.) ## **Root cause (why this works)** HTTP/2 allows either endpoint to cancel a stream at any time. Many implementations **continue processing** a request that has already been reset, because work has already been scheduled upstream (cache lookup, origin forward, buffering, etc.). Meanwhile the stream no longer counts against SETTINGS\_MAX\_CONCURRENT\_STREAMS. The attacker exploits this gap: - Send a request (HEADERS, often with END\_STREAM). - Send an **invalid** frame on that stream to trigger a **stream error** on the server (examples below). - The server replies with RST\_STREAM (stream closes in accounting) but keeps backend work alive. - Repeat quickly to accumulate unbounded concurrent requests on one TCP connection. **Frames that can trigger server-side resets:** - WINDOW\_UPDATE with 0 or > 2^31−1 increment. - HEADERS, DATA, CONTINUATION sent on a half-closed (remote) stream. - PRIORITY with invalid length. Frames that force a **connection** error are less useful to the attacker (they close the TCP session). ## **Attack walk-through** ![](https://fastnetmon.com/wp-content/uploads/2025/08/Made-You-Reset-DDoS-explained-FastNetMon-1024x689.png)Left: normal operation bounded by MAX\_CONCURRENT\_STREAMS. Right: repeated invalid frames force server RST\_STREAM; streams drop from accounting while origin work continues, so the proxy/origin collapses under queued responses. ## **Why proxies and origins suffer** - **Proxies do more per request** than clients: decode, transform headers, cache lookups, origin selection, buffer management, re-encode, flow control. - When the client-side stream disappears, the proxy still carries the cost of **origin I/O and buffering**, then discards results late. - Concurrency is now bounded by backend capacity, not by HTTP/2 stream limits, so small attack rates can snowball into **CPU, memory, and socket exhaustion**. ## **What to monitor (practical signals)** Even if you don’t parse HTTP/2 frames on the wire, you can watch for these effects: - **Rising origin concurrency** with flat client-side stream counts. - **High request starts vs. low response writes** on the client side (lots of work thrown away late). - **Spike in server-emitted RST\_STREAM**, GOAWAY, or HTTP/2 stream errors in proxy logs/metrics. - **Upstream throughput and latency increase** without a matching growth in successful responses. - **Per-connection anomalies:** one IP keeping a single HTTP/2 connection busy for a long time while driving substantial upstream traffic. From a FastNetMon perspective (flow/packet telemetry): - Fewer new TCP connections than expected for the observed server CPU/throughput. - Long-lived flows with steady upstream bytes to origins and comparatively low downstream payload to clients. - Abrupt origin egress spikes without corresponding ingress from diverse clients (botnet distributing low request rates). ## **Mitigation checklist** ### **1) Patch first** Upgrade affected servers, proxies, and libraries. Many vendors have shipped updates; others are in progress. Apply vendor-specific CVEs as they appear. ### **2) Drop on invalid frames (prefer connection errors)** Where policy allows, treat malformed WINDOW\_UPDATE/PRIORITY/illegal frame sequences as **connection-fatal** instead of stream-fatal. This removes the accounting gap. ### **3) Request-rate and concurrency controls** - Enforce per-client request rate limits and **per-connection** concurrency caps. - Be careful with shared forward proxies/VPNs to limit false positives; whitelist known egresses where needed. ### **4) Control-frame rate limiting** If your HTTP/2 stack supports it, enforce small sliding-window limits on control frames to blunt both Rapid Reset and MadeYouReset. Reasonable **starting** baselines reported by one vendor’s testing: - PING: ~100/sec per connection - SETTINGS: ~5/sec per connection - PRIORITY: ~30/sec per connection - RST\_STREAM: ~5/sec per connection (apply to both directions) Tune with production telemetry; browsers usually reconnect automatically if a connection is dropped by policy. ### **5) WINDOW\_UPDATE sanity** Aim to prevent abusive WINDOW\_UPDATE patterns: - Allow an initial burst up to **MAX\_CONCURRENT\_STREAMS** frames at connection start. - Cap ongoing rate to **~6 WINDOW\_UPDATE per DATA frame** sent by the server. - Require **≥128 bytes of DATA** per WINDOW\_UPDATE to avoid “data dribble”. (If your platform exposes multipliers or counters for these, monitor and tune them under load testing.) ### **6) Backpressure and buffering hygiene** - Bound proxy buffering per stream and per connection. - Prefer **early cancel** of upstream requests when the client-side stream goes away. - Propagate client aborts to origin aggressively. ### **7) Detection → automation** - Alert on the signals listed above. - Where possible, **classify** abusive client connections and auto-apply temporary blocks or stricter limits. - For hybrid architectures, feed signals into upstream scrubbing/FastNetMon to trigger diversion or policy changes when L7 attacks escalate. ### **8) Consider HTTP/3 policies** Operators often fall back to HTTP/2 during HTTP/3 incidents. Track draft efforts like “Using HTTP/3 Stream Limits in HTTP/2” and prefer connection-fatal handling for invalid sequences where compliant. ## **Key takeaways** Visibility matters: correlate proxy/origin metrics with network telemetry to catch the pattern early and automate response. MadeYouReset exploits a **design/implementation gap**: backend work continues after a stream reset while stream accounting drops to zero. It can **hide inside a single connection** and look like normal traffic until the origin buckles. **Patching**, **tighter control-frame handling**, and **rate limits** are the most effective immediate defenses. --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats.For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** FastNetMon Blog **Tags:** DDoS News, threats and vulns --- ### [Win-DoS: New Windows Zero-Click Vulnerabilities Enable Domain Controller-Powered DDoS Botnets](https://fastnetmon.com/2025/08/11/win-dos-new-windows-zero-click-vulnerabilities-enable-domain-controller-powered-ddos-botnets/) **Published:** August 11, 2025 **Author:** FastNetMon **Content:** SafeBreach Labs researchers Or Yair and Shahak Morag disclosed a new class of Windows [denial-of-service (DoS)](https://fastnetmon.com/2025/04/16/ddos-dos-rdos-explained/) vulnerabilities that can be exploited to crash critical infrastructure or conscript **publicly accessible Windows Domain Controllers (DCs)** into high-bandwidth [DDoS attacks](https://fastnetmon.com/2025/08/05/what-is-a-ddos-attack-history-motives-and-methods-explained/). The researchers have dubbed the discovery the **“Win-DoS Epidemic”** and have released proof-of-concept tooling demonstrating exploitation across multiple Windows services. ## Vulnerability Overview The issues are all categorised as *uncontrolled resource consumption* vulnerabilities. Three can be triggered remotely without authentication; one requires minimal authenticated access: - **CVE-2025-26673** (CVSS 7.5) – DoS in Windows LDAP service - **CVE-2025-32724** (CVSS 7.5) – DoS in Windows LSASS; also core to the Win-DDoS attack chain - **CVE-2025-49716** (CVSS 7.5) – DoS in Windows Netlogon - **CVE-2025-49722** (CVSS 5.7) – DoS in Windows Print Spooler (requires authenticated user on adjacent network) The first three vulnerabilities can be exploited via a single crafted packet or message sequence against an Internet-reachable service endpoint, requiring no user interaction. ## Operational Impact on Domain Controllers Domain Controllers run **Active Directory Domain Services (AD DS)**, handling authentication (Kerberos, NTLM), authorisation, and directory look-ups. A DoS against a DC has immediate operational consequences: - Users cannot obtain Kerberos tickets or log in. - Group Policy Objects cannot be applied. - Resource access dependent on Active Directory is blocked. Earlier work from the same researchers (*LDAPNightmare*, CVE-2024-49113) showed that LDAP services on DCs could be crashed remotely. The new Win-DoS set extends the attack surface to **LSASS**, **Netlogon**, and **Print Spooler** — affecting multiple critical code paths. ## Win-DDoS: Turning DCs into a Botnet The most severe outcome is the **Win-DDoS** technique, leveraging CVE-2025-32724 to transform public DCs into **stateless DDoS agents**. **Attack chain:** 1. **Trigger CLDAP connection** – Send a crafted RPC call to an Internet-reachable DC, coercing it into acting as a CLDAP client. 2. **Referral injection** – The attacker’s CLDAP server returns an LDAP referral pointing to an attacker-controlled LDAP/TCP endpoint. 3. **Referral amplification** – The LDAP/TCP endpoint responds with thousands of LDAP URLs resolving to the victim’s IP and port. 4. **Relentless traffic generation** – The DC cycles through the referral list, repeatedly initiating TCP connections and sending LDAP payloads to the victim. Because most web servers (and other non-LDAP services) immediately close the TCP session upon receiving invalid LDAP data, the DC retries the next referral in the list — a loop that continues until the referral list is exhausted. **Key attributes of Win-DDoS:** - No code execution or compromise of the DC is required. - Traffic originates from legitimate infrastructure (public DCs), making attribution and filtering more difficult. - Potential scale: tens of thousands of DCs with public LDAP exposure. - No need for attacker-controlled botnet infrastructure. ## RPC Abuse for Zero-Click DoS The team also identified weaknesses in **Windows RPC binding behaviour**. By crafting repeated calls to a target RPC server, they bypassed concurrency limits, forcing **resource exhaustion** without authentication. This results in complete service termination or a system crash. The method works against any RPC service that accepts unauthenticated calls — common across default Windows deployments. ## Mitigation and Patching Microsoft has issued security updates for supported Windows versions in **April, June, and July 2025** covering all four CVEs. Given that exploitation now has public proof-of-concept tooling, patching should be considered urgent. ### Recommended defensive actions: - Apply Microsoft patches to all Windows Servers and endpoints, prioritising Domain Controllers and other LDAP/Netlogon/LSASS-exposed systems. - Restrict public exposure of DCs and related services (LDAP, CLDAP, RPC) via network segmentation and firewall policy. - Implement DDoS detection that can profile anomalous **outbound** traffic patterns from DCs as well as inbound floods. - Adjust threat models — do not assume that internal services are immune to DoS without full compromise. ## Final notes This research underlines the increasing trend of attackers **repurposing legitimate, high-capacity infrastructure** for DDoS rather than maintaining [traditional botnets](https://fastnetmon.com/2025/06/18/anatomy-of-a-botnet/). For network defenders, this demands equal focus on **egress monitoring** and **internal service hardening** alongside conventional perimeter DDoS protection. --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats.For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** FastNetMon Blog **Tags:** DDoS News, threats and vulns --- ### [What Is a DDoS Attack? History, Motives, and Methods Explained](https://fastnetmon.com/2025/08/05/what-is-a-ddos-attack-history-motives-and-methods-explained/) **Published:** August 5, 2025 **Author:** FastNetMon **Content:** If you’ve managed a network for more than a week, chances are you’ve seen it, or at least worried about it: the DDoS attack. You know the symptoms. Traffic spikes. Routing instability. Customers raising tickets before monitoring even kicks in. But how did we get here? What exactly qualifies as a DDoS attack today, and how has it evolved from script-kiddie chaos to geopolitical weapon? This post explores the origins, classification, motivations, and infamous examples that shaped how we understand DDoS today. ## **What is a DDoS attack?** At its simplest, a Distributed Denial-of-Service (DDoS) attack involves overwhelming a target (typically a network, server or application) with traffic from multiple sources, making it unresponsive to legitimate users. It’s ‘distributed’ because the attack is coordinated across many endpoints:[ botnets](https://fastnetmon.com/2025/06/18/anatomy-of-a-botnet/), amplifiers,[ hijacked proxies](https://fastnetmon.com/2025/07/08/new-botnet-rondodox-targets-unpatched-dvrs-and-routers-for-stealthy-ddos-campaigns/), and in some cases, legitimate[ cloud infrastructure](https://fastnetmon.com/2024/02/29/fastnetmons-role-in-protecting-cloud-infrastructure-from-ddos-attack/). But that’s just the surface. There’s a range of intent, scale, and method behind each attack. What separates a few bots from a network-wide disruption comes down to technique and amplification, not just brute force. ## **Pre-DDoS: local exploits and manual floods** Before the rise of distributed attacks, denial-of-service was largely limited to local or single-source exploits.[ The first DDoS incidents](https://fastnetmon.com/2025/04/23/how-did-ddos-begin-a-short-history-of-ddos-reviewed/) weren’t motivated by money or politics. In the late 1990s, they were about control, or more often, boredom. Impact was usually limited to a single machine or subnet. 1999–2000: The first coordinated floods The real shift came with tools like Trinoo and Tribal Flood Network (TFN). These were some of the first to allow remote control over multiple Unix systems to launch simultaneous floods: UDP, ICMP, and later, TCP-based attacks. With them, attackers could orchestrate hundreds of compromised machines to target a single service. The victims? Rival hackers, gaming servers, university networks. These early botnets weren’t automated. They required manual setup on each compromised host. Still, the damage was clear: university servers were taken offline, and attackers began testing the limits of bandwidth-based disruption. In February 2000, a coordinated series of attacks hit Yahoo!, CNN, eBay, and Amazon, bringing them offline with what we’d now recognise as simple volumetric floods. The attacks didn’t rely on clever exploits, just volume and timing. And they worked. 2001–2003: Worms, bandwidth, and botnets The next leap came with the spread of automated worms like Code Red, Nimda, and SQL Slammer. These propagated without user interaction, compromising thousands of Windows machines in minutes. Attackers quickly realised they could harness this scale for DDoS. Botnets formed using these infected systems gave attackers thousands of nodes with real bandwidth. Unlike modem-era hosts, broadband-connected devices could push sustained traffic measured in megabits per second, multiplied across thousands of endpoints. Malware like Agobot added scanning, backdoor access, and built-in flood capabilities, bringing automation to propagation, control, and attack delivery. 2005 Onwards: DDoS becomes a service With growing scale and automation came commercialisation. By the mid-2000s, online services known as[ booters or stressers](https://fastnetmon.com/2025/04/10/ddos-booters-and-ip-stressers-explained-by-experts/) appeared. These offered DDoS-as-a-service to anyone with basic funds and a target IP. Typical services allowed customers to select attack types (UDP, TCP, HTTP, DNS) and set duration, often with subscription pricing. No technical knowledge was required. Payment could be made through PayPal, Liberty Reserve, or later, cryptocurrency. Attack infrastructure was often comprised of IoT devices, misconfigured cloud VMs, and home routers - easy to infect and hard to trace. Amplification and reflection Reflection-based amplification became a popular tactic. Instead of relying entirely on botnet bandwidth, attackers spoofed victim IPs in queries to open services like DNS, NTP, or Memcached. These services responded with far more data than the request, redirecting a large payload to the victim. [Amplification](https://fastnetmon.com/2025/07/30/understanding-volumetric-amplification-ddos-attacks/) factors of 30× to 50× were common, and in some cases, single hosts could generate over 1 Gbps of attack traffic without needing a botnet. This was particularly effective in bypassing simple threshold-based detection systems, and remains a common tactic today. ## **Classification: not all DDoS is the same** To defend against an attack, you have to understand what type you're dealing with. Here’s how DDoS attacks are typically categorised: - **Volumetric attacks The classic floods - DNS amplification, UDP floods, or spoofed traffic designed to saturate bandwidth. - **State exhaustion attacks Targeting firewalls, load balancers, or NAT tables by consuming connection slots with SYN floods or other transport-layer tricks. - **Application-Layer attacks More subtle. These attacks mimic legitimate behaviour (like slow HTTP requests or malformed API calls) and tie up backend resources. - **Stealthy / low-rate attacks Designed to bypass traditional thresholds and slowly degrade service or trigger failover logic. These attack types are often layered, with adversaries combining techniques to maximise disruption and complicate mitigation. Read all details:[ **Classification of DDoS attacks: every modern DDoS attack vector explained**](https://fastnetmon.com/2025/07/25/classification-of-ddos-attacks-every-modern-ddos-attack-vector-explained/) ## **Why do DDoS attacks happen?** The motivations have changed as much as the techniques. While extortion is often assumed, it accounts for only a small share of incidents in practice. Here are some common drivers: - **Hacktivism** – Protest campaigns against governments, corporations or ideologies. Think Anonymous or[ NoName(057)16](https://fastnetmon.com/2025/07/16/europol-disrupts-notorious-ddos-group-noname05716/). - [**Geopolitical operations**](https://fastnetmon.com/2025/05/19/ddos-in-geopolitics-when-network-traffic-becomes-a-digital-weapon/) – State-linked or nationalist groups targeting infrastructure in adversarial regions. - **Business disruption** – Competitors or insiders taking services offline, sometimes during critical sales windows. - **Diversion** – Distracting defenders while another exploit unfolds. - **Revenge or mischief** – Especially in[ gaming](https://fastnetmon.com/2025/06/05/ddos-attack-targets-byond-game-engine-in-push-to-open-source-it/), where server takedowns are often personal. Many large attacks reported in the wild have either political or economic objectives—making attribution difficult and defence even more complex. ## **Memorable incidents in DDoS history** A few landmark events reveal just how far DDoS has come: - **2009 – Operation Troy South Korea's government and financial sites were disabled by what was likely a state-sponsored campaign - one of the first nation-level DDoS incidents. - **2010 – Operation Payback Coordinated by Anonymous, this campaign targeted copyright groups and payment platforms in retaliation for anti-piracy enforcement. - **2016 – Dyn DNS Outage Powered by the Mirai botnet, this attack disrupted major platforms including Twitter, Spotify, and Netflix by taking down a core DNS provider. - **2022–2024 – Killnet, NoName057(16) These pro-Russian groups launched sustained attacks against NATO-member state infrastructure during the Ukraine war. Their methods changed frequently and often relied on decentralised C2 infrastructure, making them harder to track or contain. These examples demonstrate the range of motivations, from political retaliation to financial gain, and the growing sophistication of attack infrastructure. ## **Looking Ahead** Attackers today combine protocol abuse, traffic shaping, and bot orchestration with enough nuance to bypass[ threshold-based systems](https://fastnetmon.com/2025/07/02/how-to-set-a-threshold-for-rtbh-bgp-blackhole-a-practical-guide-to-threshold-based-ddos-defence/), so DDoS is no longer just a volume game. We’ll cover how to build a modern[ DDoS mitigation strategy](https://fastnetmon.com/ddos-detection-and-mitigation/) - across[ BGP](https://fastnetmon.com/bgp-blackhole-automation/),[ Flow Spec](https://fastnetmon.com/flowspec-ddos-mitigation/), application firewalls, and behaviour-based detection - in our next article. For now, understanding the intent and mechanics is a solid first step. --- ## **About FastNetMon** FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats.For more information, visit <https://fastnetmon.com> **Categories:** FastNetMon Blog --- ### [DDoS or Drama? Qubic’s Monero Takeover Attempt Sparks Controversy](https://fastnetmon.com/2025/08/05/ddos-or-drama-qubics-monero-takeover-attempt-sparks-controversy/) **Published:** August 5, 2025 **Author:** FastNetMon **Content:** August 3, 2025, a crypto mining pool called **Qubic** claimed it was hit by a **[Distributed Denial-of-Service (DDoS) attack](https://fastnetmon.com/2025/08/05/what-is-a-ddos-attack-history-motives-and-methods-explained/ "Distributed Denial-of-Service (DDoS) attack")** after launching an aggressive bid to gain control of the **Monero** blockchain. While no impact was observed on the Monero network itself, the events raised new questions about the intersection of **cyber attacks, economic rivalry, and decentralisation**. Here’s a brief introduction to the actors, and the alleged course of events. ## **What Is Monero?** **Monero (XMR)** is a privacy-first cryptocurrency designed to be *decentralized, untraceable, and censorship-resistant*. It uses advanced cryptography to hide sender, receiver, and transaction amounts. These features make Monero popular for both legitimate privacy use and illicit transactions. Monero is mined using standard CPUs and GPUs, with algorithms designed to resist specialized ASIC hardware. To maintain network integrity, Monero relies on a decentralized group of miners. If a single pool gains more than 50% of the hashrate, it could potentially censor transactions — an event known as a **51% attack**. ## **What Is Qubic?** **Qubic** is a separate crypto project run by Sergey Ivancheglo (a.k.a. *Come-from-Beyond*), previously a founder of IOTA and NXT. The Qubic ecosystem incentivises users to mine other cryptocurrencies like Monero, while being paid in Qubic tokens. According to Qubic’s own statements, Monero mining profits are used to fund Qubic’s internal token economy — including token buybacks and burns. This created a financial incentive to gain significant hashrate on Monero’s network. ## **The Qubic Takeover Attempt** In July 2025, the Qubic mining pool rapidly rose to dominate a significant portion of the Monero network’s hashrate — reportedly as high as **35–40%** at its peak. On social media, Ivancheglo made it clear: Qubic intended to **centralize Monero mining** by rejecting blocks from other pools. This sparked a strong backlash from the Monero community, who encouraged miners to switch to smaller, decentralized pools like P2Pool and SupportXMR. By late July, Qubic’s hashrate had dropped significantly — and by July 30, it stopped reporting public hashrate data altogether. ## **The Alleged DDoS Attack** On **August 3**, Ivancheglo claimed on X that the Qubic mining pool was under a **DDoS attack**, causing hashrate to fall from **2.6 GH/s to 0.8 GH/s**. He implied that the attack came from Monero-aligned actors, possibly using a botnet previously used for Monero mining malware. In a follow-up post, he alleged that **Sergei Chernykh**, lead developer of the popular **XMRig** Monero mining software, was behind the attack. Chernykh denied involvement, calling the accusation defamation. He added that while he opposes Qubic’s actions, he has never advocated for illegal countermeasures. Meanwhile, external parties were unable to verify any ongoing DDoS activity. Qubic pool endpoints responded within normal latency ranges, and no outages were detected. At the same time, public tracking sites continued to show Qubic’s hashrate at or near **0 GH/s**, adding to the speculation. ## **DDoS as a Competitive Tool — and a PR Weapon** DDoS attacks are a **well-known tactic in competitive and high-stakes environments** — especially in industries like gaming, crypto, or digital finance, where uptime equals revenue. Whether motivated by profit, disruption, or retaliation, DDoS attacks can force services offline or undermine user trust. But **publicly claimed DDoS attacks are often difficult to verify post-mortem**. Without access to traffic logs or packet-level data, outside observers rely on second-hand reports or circumstantial evidence (like latency spikes or service unavailability). In this case, technical checks showed no clear evidence of disruption — raising questions about whether the DDoS happened, whether it had already ended, or whether the claim served another purpose. This incident highlights the increasingly blurred lines between: - **Technical attacks - **Economic pressure - **Public relations narratives - And **organizational rivalry It’s a reminder that **DDoS is not always just a technical event** — it can be a tool of *influence*, *misdirection*, or *defensive spin*. Whether the Qubic DDoS attack was real, exaggerated, or strategically framed remains unresolved. But it offers a textbook case of how DDoS threats can be entangled with **reputation battles**, **market manipulation**, and **protocol-level governance conflicts**. --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** FastNetMon Blog **Tags:** DDoS Attacks, DDoS News --- ### [SVF Botnet Campaign Targets Linux SSH Servers Using Discord-Based C2](https://fastnetmon.com/2025/07/29/svf-botnet-campaign-targets-linux-ssh-servers-using-discord-based-c2/) **Published:** July 29, 2025 **Author:** FastNetMon **Content:** AhnLab Security Intelligence Center (ASEC) has recently uncovered a wave of malicious activity involving the **SVF Botnet**, a lightweight yet capable Python-based malware used to launch **DDoS attacks** via compromised Linux SSH servers. The campaign highlights the continuing abuse of weak or default SSH credentials on internet-facing infrastructure. ### Infection Tactics: Fast and Scripted ASEC researchers observed attackers infiltrating Linux honeypots by brute-forcing SSH credentials. Once access is gained, the infection chain is executed in a single shell command: 1. Create a Python virtual environment 2. Install required packages: discord.py, requests, aiohttp, lxml 3. Download the malicious payload from a public URL 4. Execute it with parameters to register the infected server in a designated group The malware then authenticates using a hardcoded Discord bot token and reports in via webhook, effectively using Discord as its **command-and-control (C2) infrastructure**. ### SVF Bot Capabilities SVF Bot supports multiple DDoS vectors, including: - **Layer 7 (HTTP Flood) - **Layer 4 (UDP Flood) Operators can control attack intensity through configurable parameters like concurrency, thread count, and packet size. Notably, the bot integrates a **proxy scraping and validation module** to bolster attack anonymity: - Scrapes proxy lists from GitHub and other public sources - Validates proxies using real-time Google login attempts - Uses validated proxies to route HTTP floods Commands like $load, $customhttp, and $customudp allow for highly targeted attacks. The malware’s modular design also supports remote updates, forced restarts, and recovery from crashes—making it both persistent and flexible. ### Discord as a C2 Platform By using Discord as its C2 hub, SVF Bot operators avoid the overhead of maintaining dedicated infrastructure. Discord’s widespread adoption and real-time communication features allow attackers to issue instructions, receive infection reports, and coordinate campaigns with ease. This also complicates traditional detection and takedown efforts, as the botnet traffic blends in with legitimate communications on a mainstream platform. ### Indicators of Compromise (IOCs) Security teams should monitor for the following IOCs associated with SVF Bot activity: - **MD5 Hash:** cffe3fb6cb3e4b9b453c4147bdcd8c12 - **Download URL:** https://146.59.239.144:55/ - **Payload URL:** https://termbin.com/4ccx - **Attacker IP:** 185.254.75.44 ### Implications for Defenders ASEC’s findings are a strong reminder that **Linux servers remain a prime target for** [**botnet operators**](https://fastnetmon.com/2025/06/18/anatomy-of-a-botnet/), especially when basic hardening practices are ignored. The use of Python, open-source libraries, and Discord lowers the barrier for running large-scale attacks—even for less sophisticated threat actors. ### FastNetMon’s Recommendations **1. Strengthen SSH Security** - Disable password-based login and use SSH keys - Enforce strong, unique credentials - Limit access via firewall to known IPs **2. Keep Systems Patched** - Update Python, SSH services, and OS packages regularly - Apply endpoint protection with active malware scanning **3. Monitor for Anomalous Network Behavior** - Watch for outbound traffic to known IOCs - Use behavior-based detection systems to flag unusual proxy usage or Discord-based C2 traffic **4. Deploy Network-Level DDoS Mitigation** - Use systems like [**FastNetMon Advanced**](https://fastnetmon.com/) to detect traffic spikes, floods, and botnet behaviour in real-time - Implement automated blocking and rate-limiting for attack traffic ### Conclusion This incident demonstrates how attackers are adapting to modern ecosystems—using familiar tools like Discord, scripting languages like Python, and freely available proxies to build resilient and scalable [botnet infrastructures](https://fastnetmon.com/2025/07/15/meet-the-botnets-breaking-the-internet-part-3/). Thanks to the detailed analysis by AhnLab Security Intelligence Center**,** defenders have a clearer picture of the threat and the steps required to mitigate it. --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** FastNetMon Blog **Tags:** DDoS News, Linux, threats and vulns --- ### [Network Engineering Community News: July 2025](https://fastnetmon.com/2025/07/29/network-engineering-community-news-july-2025/) **Published:** July 29, 2025 **Author:** FastNetMon **Content:** # ⚡️ Network Engineering Community News Summer greetings from FastNetMon! While temperatures rise, so do DDoS attack volumes—and we’re here to help you stay cool under pressure. This month, we’re sharing two practical guides for tackling attacks, a press interview on SafetyDetectives, and major botnet updates, a peek at some of the biggest attacks we’ve seen recently and more. If you want to get even cooler version of this newsletter straight to your inbox, sign up [here!](https://cdn.forms-content.sg-form.com/b3c8181d-c30d-11ef-b203-ca12671f70d2) ## 🛡️ Practical guide to filtering L3/L4 DDoS attacks [![](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff8a0299c956ef43d12ab7f1a40ef114862c0b64df77fe9c6c08a1ed16341ae0/images/engineersguidetostoppingl3l4ddoswithbgpflowspecrtbhbgpblackhole.png)](https://fastnetmon.com/2025/07/08/filtering-l3-l4-ddos-attacks-with-bgp-flow-spec-and-rtbh-a-practical-guide-for-engineers/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=l3-l4-filtering-ddos-attacks&utm_term=july) UDP floods, TCP SYN storms, and other packet-level attacks can overwhelm even well-prepared networks. In this new guide, we explain how to use BGP Flow Spec and RTBH to filter malicious traffic efficiently - without impacting legitimate users. [READ HERE](https://fastnetmon.com/2025/07/08/filtering-l3-l4-ddos-attacks-with-bgp-flow-spec-and-rtbh-a-practical-guide-for-engineers/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=l3-l4-filtering-ddos-attacks&utm_term=july) ## 💬 Interview: Rethinking DDoS defence with Safety Detectives [![](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff8a0299c956ef43d12ab7f1a40ef114862c0b64df77fe9c6c08a1ed16341ae0/images/safetydetectives_interview_newsletter.png)](https://fastnetmon.com/2025/07/02/fastnetmon-interviewed-by-safety-detectives-rethinking-ddos-protection-for-a-faster-safer-internet/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=interview-safe-detectives&utm_term=july) We recently sat down with Safety Detectives to talk through the realities of defending against today’s DDoS threats. From why static rules are no longer enough to how we see automation reshaping mitigation, the interview covers both practical strategies and long-term thinking. [READ THE INTERVIEW](https://fastnetmon.com/2025/07/02/fastnetmon-interviewed-by-safety-detectives-rethinking-ddos-protection-for-a-faster-safer-internet/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=interview-safe-detectives&utm_term=july) ## 📚 FastNetMon library: Our DDoS talks, slides, and videos in one place [![](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff8a0299c956ef43d12ab7f1a40ef114862c0b64df77fe9c6c08a1ed16341ae0/images/screenshot_20250722_at_145030.png)](https://fastnetmon.com/presentation/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=fastnetmon-library-ddos-talks-videos-events&utm_term=july) Missed one of our recent talks? Slow day in the office? We've put together a growing library of our presentations - covering FastNetMon Community, Flow Spec for DDoS, Network Telemetry and more. Whether you want to catch up on a deep-dive technical session or share slides with your team, everything’s now in one place for easy access. More content is coming soon, so it’s worth bookmarking. [GO TO LIBRARY](https://fastnetmon.com/presentation/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=fastnetmon-library-ddos-talks-videos-events&utm_term=july) ## 🎯 Setting the thresholds for RTBH [![](https://eoolnbw.stripocdn.email/content/guids/CABINET_ff8a0299c956ef43d12ab7f1a40ef114862c0b64df77fe9c6c08a1ed16341ae0/images/networkengineeringguidetoddosdefencethresholdbasedmitigationandratelimiting.png)](https://fastnetmon.com/2025/07/02/how-to-set-a-threshold-for-rtbh-bgp-blackhole-a-practical-guide-to-threshold-based-ddos-defence/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=threshold-for-rtbh-bgp-blackhole&utm_term=july) In this guide, we walk through a practical method for setting RTBH thresholds that strike the right balance. It’s based on what we’ve seen work in production: quick to implement, easy to adjust, and designed to give you better control during live attacks. If you're running mitigation manually or fine-tuning an automated setup, this walkthrough will help you avoid guesswork and protect availability more effectively. [READ HERE](https://fastnetmon.com/2025/07/02/how-to-set-a-threshold-for-rtbh-bgp-blackhole-a-practical-guide-to-threshold-based-ddos-defence/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=threshold-for-rtbh-bgp-blackhole&utm_term=july) ## 📰 Industry News Round-up Here are some interesting industry takes and major DDoS incidents you should know about. Enjoy the reading!: - **🕵️‍♂️ Europol Busts Major Botnet Crew:** A coordinated takedown hits one of the most persistent pro-Russian DDoS crews, but their decentralised infrastructure remains a concern. Read all about Europol action [here](https://fastnetmon.com/2025/07/16/europol-disrupts-notorious-ddos-group-noname05716/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=europol-disrupts-noname05716&utm_term=july). - **💀 Rise of RondoDox:** This stealthy new botnet quietly builds firepower by targeting vulnerable routers and DVRs across global networks. We wrote about how it operates and vulnerabilities it exploits. RondoDox explained [here](https://fastnetmon.com/2025/07/08/new-botnet-rondodox-targets-unpatched-dvrs-and-routers-for-stealthy-ddos-campaigns/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=new-botnet-rondodox&utm_term=july). - **💣 New DDoS botnet alert: HpingBot.** This new botnet uses the open-source hping3 tool alongside Pastebin for command and control. How accessible has DDoS tooling become for anyone willing to put in minimal effort? Find out [here](https://fastnetmon.com/2025/07/07/new-botnet-hpingbot-emerges-with-pastebin-based-payload-delivery-and-hping3-ddos-engine/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=new-botnet-hpingbot&utm_term=july). - **🎮 Game On, DDoS Off:** After a string of outages affecting gameplay, the developers have rolled out stronger filtering and control rules. The move appears to be holding off attacks - for now. Catch up on the full story [here](https://fastnetmon.com/2025/07/02/path-of-exile-tightens-ddos-protection-following-service-disruptions/?utm_medium=email&utm_source=newsletter&utm_campaign=all&utm_content=path-of-exile-tightens-ddos-protection&utm_term=july). ## 💌 Get this newsletter straight to your inbox Sign up to our monthly Network Engineering Community News [here](https://cdn.forms-content.sg-form.com/b3c8181d-c30d-11ef-b203-ca12671f70d2) **Categories:** Newsletter --- ### [Hungarian Police arrest alleged DDoS attacker targeting IPI and independent media](https://fastnetmon.com/2025/07/23/hungarian-police-arrest-alleged-ddos-attacker-targeting-ipi-and-independent-media/) **Published:** July 23, 2025 **Author:** FastNetMon **Content:** On July 21, 2025, the Hungarian National Investigation Bureau’s Cybercrime Investigation Unit announced the arrest of a 23-year-old suspect behind a series of coordinated **DDoS attacks** targeting the International Press Institute (IPI) and over 40 independent media websites in Hungary between 2023 and 2024. The suspect, operating under the alias “Hano”, allegedly used [“DDoS-for-hire” services](https://fastnetmon.com/2025/04/10/ddos-booters-and-ip-stressers-explained-by-experts/) and a variety of anonymisation techniques to orchestrate long-running disruptions that took down high-profile journalistic platforms such as Telex, HVG, and 444.hu. Forensic evidence from seized digital devices confirmed the presence of access logs, fake profiles, and operational traces linking the individual to the attacks. ### **Targeted DDoS Campaigns and Political Implications** The attacks began shortly after IPI published a report highlighting a surge in DDoS incidents aimed specifically at **independent media outlets**, with **pro-government media notably unaffected**. IPI’s own website was taken offline for three days starting on 1 September 2023, in what was later verified as a retaliatory action by Qurium, a non-profit security lab based in Sweden. Interestingly, the attacker left distinct digital signatures embedded in payloads, such as the tag **\#HanoHatesU**, suggesting a mix of personal motive and [political intent](https://fastnetmon.com/2025/05/19/ddos-in-geopolitics-when-network-traffic-becomes-a-digital-weapon/). The same tag appeared in follow-up attacks against Germany’s *taz* after it reported on the IPI incident—demonstrating a pattern of reprisal targeting press freedom advocates. While formal charges are still pending, Hungarian authorities are working with Austrian law enforcement due to the cross-border dimension of the attacks. The investigation also raised questions about possible **external funding or coordination**, which have yet to be confirmed. ### **DDoS-as-a-Service Still Fueling Threat Landscape** This incident underscores how [**DDoS-as-a-Service ecosystems**](https://fastnetmon.com/2025/04/30/most-infamous-ddos-booter-services-and-user-consequences/) continue to enable relatively young, non-state actors to carry out impactful and politically charged attacks at scale. The suspect’s use of rented [botnets](https://fastnetmon.com/2025/06/18/anatomy-of-a-botnet/) and commercial stresser platforms reflects broader trends seen in the threat landscape, where accessibility and automation drive attack volume. From a technical standpoint, the attacks fit the **Advanced Persistent Threat (APT)** profile—long-term targeting, consistent TTPs, and a political or ideological motivation. However, it’s worth noting that experts unofficially categorised “Hano” as an APT despite lacking any confirmed state sponsorship, which blurs traditional APT definitions. ### **FastNetMon's Perspective** At FastNetMon, we continuously monitor and profile DDoS activity across global networks. This case serves as a strong reminder that even **low-cost, outsourced DDoS attacks** can have outsized effects—especially when aimed at vulnerable civil society infrastructure. We encourage all media organisations and NGOs to: - Deploy **network-layer DDoS mitigation tools - Work with trusted upstream providers for **real-time traffic filtering - Monitor anomalies via **flow telemetry and NetFlow/sFlow exports - Maintain up-to-date incident response plans and backup infrastructure Our team supports at-risk organisations with **traffic profiling**, **early warning systems**, and **real-time detection models** that help stop attacks before they cause major outages. Many non-profit organisations use the open-source FastNetMon Community Edition to protect against DDoS. ### **Final Thoughts** While the arrest marks progress in holding cyberattackers accountable, the full scope and motivation behind these attacks are still being uncovered. Law enforcement’s ability to trace operational artefacts—despite anonymisation techniques—also highlights the value of robust digital forensics and international cooperation in attribution. We will continue tracking developments in this case as it progresses and share technical insights as new data becomes available.**If you're a media outlet or civil society organisation facing persistent DDoS threats**, reach out to us for support and guidance on modern mitigation strategies. Our free and open source Community Edition is available for small-scale networks and non-profits, while FastNetMon Advanced suits larger scale commercial needs. Compare [here](https://fastnetmon.com/compare-community-and-advanced/). --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** FastNetMon Blog **Tags:** DDoS News, legal --- ### [New Junos OS Vulnerability Can Cause BGP Session Resets](https://fastnetmon.com/2025/07/14/new-junos-os-vulnerability-can-cause-bgp-session-resets/) **Published:** July 14, 2025 **Author:** FastNetMon **Content:** **Juniper Networks has disclosed a new vulnerability (CVE-2025-52953) affecting Junos OS and Junos OS Evolved**, which allows an unauthenticated adjacent attacker to send a valid BGP UPDATE packet that resets live BGP sessions, leading to a sustained denial of service (DoS) condition.The issue resides in the routing protocol daemon (rpd) and impacts both iBGP and eBGP in IPv4 and IPv6 environments. Crucially, your network is only vulnerable if it’s configured to support the inet6-vpn unicast address family. This includes any of the following minimal configurations: ``` [protocols bgp group neighbor family inet6-vpn unicast] [protocols bgp group family inet6-vpn unicast] [protocols bgp family inet6-vpn unicast] ``` **Affected Versions** All Junos OS and Junos OS Evolved versions **prior to the following fixed releases** are impacted: - **Junos OS: - 21.2R3-S9, 21.4R3-S11, 22.2R3-S7, 22.4R3-S7 - 23.2R2-S4, 23.4R2-S4, 24.2R2, 24.4R1-S3, 24.4R2 - 25.2R1 and later - **Junos OS Evolved: - 22.2R3-S7-EVO, 22.4R3-S7-EVO, 23.2R2-S4-EVO - 23.4R2-S4-EVO, 24.2R2-EVO, 24.4R1-S3-EVO, 24.4R2-EVO - 25.2R1-EVO and later ### **Severity** - **CVSS v3.1 Score:** 6.5 (Medium) - **CVSS v4.0 Score:** 7.1 (High) - No workarounds are currently available. - No known active exploitation in the wild. Juniper discovered the issue during routine production use and is tracking it under **bug ID 1855477**. **Recommended actions: If you're running Junos OS or Junos OS Evolved with **IPv6 VPN unicast address families in BGP**, prioritize patching immediately. These kinds of session-reset vulnerabilities can lead to traffic blackholing, network instability, and outages—especially in service provider and data center environments. Monitoring BGP session stability and unexpected resets is critical. FastNetMon users can use real-time BGP anomaly detection to catch disruptions like these early. --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** FastNetMon Blog **Tags:** threats and vulns --- ### [New Botnet “RondoDox” Targets Unpatched DVRs and Routers for Stealthy DDoS Campaigns](https://fastnetmon.com/2025/07/08/new-botnet-rondodox-targets-unpatched-dvrs-and-routers-for-stealthy-ddos-campaigns/) **Published:** July 8, 2025 **Author:** FastNetMon **Content:** In a continuing wave of new malware activity, researchers have uncovered a botnet dubbed **RondoDox**, which is actively exploiting known vulnerabilities in **TBK digital video recorders (DVRs)** and **Four-Faith routers** to take over Linux-based devices. These devices—often unpatched and deployed in retail, warehouse, or small office environments—are easy targets for long-term compromise. RondoDox follows a growing trend in botnet development: stealth-first architecture, multi-platform support, and highly evasive behaviours. ### **A Surge in Botnet Activity** RondoDox is just one of several **new botnets or botnet variants** reported in recent weeks. Other recent threats include: - [**Hpingbot**](https://fastnetmon.com/2025/07/07/new-botnet-hpingbot-emerges-with-pastebin-based-payload-delivery-and-hping3-ddos-engine/): Uses Pastebin and hping3 for flexible DDoS payload delivery - [**Flodrix variant**](https://fastnetmon.com/2025/06/26/a-new-variant-of-the-flodrix-botnet-has-entered-the-scene/): A retooled classic with DNS-based evasion and TCP floods These developments show how attackers are moving beyond brute-force DDoS to build long-term, multi-functional malware ecosystems. ### **Vulnerabilities Exploited** RondoDox infects devices using: - **CVE-2024-3721**: Command injection in TBK DVR-4104 and DVR-4216 - **CVE-2024-12856**: OS command injection in Four-Faith F3x24 and F3x36 routers These exploits have been used before in Mirai variants and continue to pose real-world risks due to widespread device exposure and lack of maintenance. ### **How RondoDox Works** The malware is distributed via a shell script that: - Detects CPU architecture (supports ARM, MIPS, x86, PowerPC, and more) - Checks for writable directories (/var/tmp, /mnt, /dev, etc.) - Ignores termination signals (SIGINT, SIGQUIT, SIGTERM) - Downloads and executes the payload - Clears shell history to hide activity Once installed, the malware ensures persistence and actively kills off: - Network tools (e.g., wget, curl) - Analysis tools (e.g., gdb, Wireshark) - Competing malware processes (e.g., miners or Redtail variants) It even **renames critical Linux binaries** like iptables, ufw, and shutdown to random strings, making recovery and remediation much harder. ### **DDoS and Proxy Infrastructure** RondoDox contacts a C2 server to receive commands for **DDoS attacks over HTTP, UDP, and TCP**. But it goes further: it can **masquerade as gaming, VPN, or chat traffic** to blend in with legitimate usage and avoid detection. This includes emulating traffic patterns from: - Valve, Roblox, Fortnite, GTA - Discord, WireGuard, OpenVPN - Custom tunneling and RTC services This makes it difficult for defenders to distinguish malicious traffic from real user activity. ### **More on Botnets: How They Work and Why They're Evolving** To understand how threats like RondoDox fit into the broader ecosystem, check out our foundational posts: - [**What is a Botnet?**](https://fastnetmon.com/2025/06/18/anatomy-of-a-botnet/): A primer on the anatomy of botnets and how they gain control of devices - [**The Evolution of Modern Botnets**](https://fastnetmon.com/2025/07/03/meet-the-botnets-breaking-the-internet-part-1/): From Mirai to multi-functional proxy networks and evasion frameworks ### **FastNetMon’s View** RondoDox is a powerful example of where botnet design is heading: **cross-architecture**, **stealth-oriented**, and **multi-purpose**. It’s not just about DDoS anymore. Attackers are building long-lasting infrastructure to support fraud, tunneling, and advanced attack staging. FastNetMon continues to track these threats closely. Our [real-time network analytics and anomaly detection](https://fastnetmon.com/traffic-visibility/) can help identify and mitigate abnormal traffic—even when it’s disguised as something legitimate. --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** FastNetMon Blog **Tags:** Botnets --- ### [New Botnet “Hpingbot” Emerges with Pastebin-Based Payload Delivery and Hping3 DDoS Engine](https://fastnetmon.com/2025/07/07/new-botnet-hpingbot-emerges-with-pastebin-based-payload-delivery-and-hping3-ddos-engine/) **Published:** July 7, 2025 **Author:** FastNetMon **Content:** A newly discovered [botnet](https://fastnetmon.com/2025/06/18/anatomy-of-a-botnet/) family dubbed **Hpingbot** is gaining attention in the cybersecurity community for its novel approach to malware delivery and DDoS execution. Detected by NSFOCUS’s Fuying Lab in June 2025, Hpingbot is a **cross-platform Go-based botnet** actively targeting both Windows and Linux/IoT environments—and it’s evolving fast. ### **Payload Delivery via Pastebin** Unlike most botnets that use traditional infrastructure for malware delivery, Hpingbot cleverly uses **Pastebin**—a public text-sharing platform—to distribute payloads. It embeds multiple hard-coded Pastebin links to host instructions or shell scripts (payload.sh) that download and install the malicious binaries. This allows attackers to **quickly update payloads** without retooling the botnet, while staying under the radar. ### **Real-World Testing with NetData Targets** In early activity, Hpingbot was observed launching attacks against IPs hosting the **NetData** performance monitoring tool. These targets may have been used to test and validate the effectiveness of Hpingbot’s DDoS modules in live environments, a tactic that suggests boldness and operational confidence from the attackers. ### **DDoS Attacks Using hping3** The botnet’s name is derived from its use of **hping3**, a legitimate network testing tool repurposed to launch customised DDoS attacks. Supported attack types include: - SYN, ACK, and RST floods - UDP floods - Mixed-mode "BOTOX" attacks - Custom TCP flag combinations Interestingly, the **Windows variant does not support hping3**, yet continues to spread actively—indicating a broader intent beyond DDoS. ### **Persistent and Modular Design** Hpingbot ensures system persistence using a mix of **Systemd**, **SysVinit**, and **Cron jobs**, making it resilient across varied Linux environments. Its architecture supports multiple processor types (amd64, ARM, MIPS, etc.), and its **propagation module is split from the payload**, following a growing trend in modular botnet design that enables better obfuscation and tighter control. ### **Continuous Evolution and Professional Development** Attackers have iterated on Hpingbot **at least 10 times since mid-June**, updating everything from installation scripts to payload logic and C&C server addresses. The speed of updates and sophistication of the delivery chain suggest the botnet is being maintained by **a professional team**, potentially for long-term campaigns. ### **Strategic Use in APT and Ransomware Ecosystems** Beyond DDoS, Hpingbot’s ability to **download and execute arbitrary payloads** makes it a prime candidate for use in **advanced persistent threat (APT)** or **ransomware** operations. As attackers increasingly weaponise botnets as initial access vectors, Hpingbot could serve as a stepping stone to more severe breaches. ### **FastNetMon’s Take** Hpingbot is a clear signal that [botnets are evolving](https://fastnetmon.com/2025/07/03/meet-the-botnets-breaking-the-internet-part-1/)—leveraging public platforms, open-source tools, and agile development practices to outpace defenders. While its DDoS footprint is currently limited, its payload delivery capabilities and rapid iteration cycle demand attention. At FastNetMon, we’re continuously monitoring the shifting DDoS landscape. [Our real-time traffic analysis and detection tools](https://fastnetmon.com/ddos-detection-and-mitigation/) help customers stay ahead of threats like Hpingbot by recognising unusual network behaviours early—before damage is done. ### **Stay Protected** If you're running Linux or IoT systems, monitor for suspicious use of hping3, unexpected scheduled tasks, or traffic to Pastebin. Consider tightening SSH password policies and restricting outbound traffic to known-good domains to reduce exposure. --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** FastNetMon Blog **Tags:** Botnets --- ### [Path of Exile tightens DDoS protection following service disruptions](https://fastnetmon.com/2025/07/02/path-of-exile-tightens-ddos-protection-following-service-disruptions/) **Published:** July 2, 2025 **Author:** FastNetMon **Content:** Grinding Gear Games (GGG), the developer of the action RPG *Path of Exile*, has implemented new security updates to strengthen its protection against Distributed Denial‑of‑Service (DDoS) attacks. The changes follow a period of significant server instability after the release of the game’s latest expansion, *Secrets of the Atlas*. In a post published on June 26, GGG confirmed that recent disruptions stemmed from both increased malicious traffic and unintended consequences of their mitigation strategy. Protective filters aimed at blocking DDoS traffic also interfered with legitimate player connections, leading to session drops and blocked access for some users. “We’ve been very focused on improving DDoS protection for our servers. Unfortunately, some of the protective measures have blocked legitimate traffic, causing instances to unexpectedly close,” the developers stated. “We’re working closely with our server providers to finish setting up protection and resolve these issues as soon as possible.” The post also addressed two other concerns: an uptick in player-reported account compromises and visual flickering affecting gameplay during intense action. GGG confirmed no evidence of a breach in its internal systems and committed to releasing a fix for the flickering issue in the following update. ## **DDoS at launch: A global problem** The launch of *Secrets of the Atlas* between June 14–18 triggered a spike in player activity—and with it, a new wave of DDoS attacks. GGG confirmed that European servers were the primary targets early on, with ripple effects reaching other regions as players switched to different gateways in search of stability. According to an update shared by the developers, “European servers but also servers across the globe have been facing a barrage of DDOS attacks… This is unacceptable service and we are deeply sorry.” Server disruptions included login failures, rollback events, and connection timeouts, particularly during peak hours. The combination of external attacks and internal infrastructure stress created a challenging environment for real-time mitigation. Some players speculated that high traffic loads from legitimate users may have further contributed to the issues, especially as players migrated between regional servers and overloaded fallback infrastructure. ## **What Network Engineers should note** 1. **Confirmed DDoS activity** – GGG’s infrastructure came under coordinated attack, resulting in the deployment of more aggressive filtering strategies. 2. **False positives during mitigation** – Legitimate player traffic was affected due to tightened thresholds. The need for behaviour-aware traffic baselining is critical in such scenarios. 3. **Cross-regional traffic overflow** – Pressure on European servers caused traffic spillover to other regions, underlining the importance of global load balancing and elastic scaling. 4. **Client-side vs server-side confusion** – Game engine issues such as UI flickering occurred alongside network symptoms, illustrating how easily different failure modes can be conflated during high-impact events. ## **A measured and ongoing response** While the situation has caused frustration among *Path of Exile*’s dedicated player base, Grinding Gear Games has demonstrated a strong commitment to resolving the issues transparently and thoroughly. The company has communicated with the community frequently and taken immediate steps to diagnose and address the problems as they emerge. This case is a good example of the complexity of protecting low-latency, real-time services from attack while maintaining high availability and performance. GGG’s focus on fixing root causes—alongside their willingness to acknowledge missteps—reflects a proactive and resilient approach to network defence. As the studio works closely with service providers to refine its mitigation strategies, players and operators alike can expect improved stability in the weeks ahead. --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** FastNetMon Blog **Tags:** DDoS News, gaming --- ### [Internet Under Fire: Analysis of the record-breaking 7.3 Tbps DDoS attack](https://fastnetmon.com/2025/06/23/internet-under-fire-analysis-of-the-record-breaking-7-3-tbps-ddos-attack/) **Published:** June 23, 2025 **Author:** FastNetMon **Content:** ### The Internet Just Survived the Largest DDoS Attack Ever—Here’s What You Need to Know A new milestone in Distributed Denial of Service (DDoS) attacks has been reached: 7.3 terabits per second (Tbps) of malicious traffic launched in a single, ultra-short burst lasting just 45 seconds. The attack delivered 37.4 terabytes of data—equivalent to streaming an entire year of HD video in under a minute. The victim? A hosting provider. The impact? Minimal—thanks to modern mitigation strategies. But the implications are much bigger. ### Infrastructure providers are in the crosshairs This record-breaking event underscores a clear pattern: hosting providers and internet infrastructure platforms continue to be [high-value targets for increasingly aggressive DDoS campaigns](https://fastnetmon.com/2025/04/03/ddos-defence-for-hosting-providers/). The stakes are growing, and so is the technical sophistication behind these attacks. ### Dissecting the 7.3 Tbps attack This was not just a brute-force volumetric flood. It was a multi-vector campaign. While the vast majority (99.996%) of the traffic came from UDP floods, attackers also used a mix of reflection and amplification techniques via outdated protocols like QOTD, NTP, Portmap, and RIPv1—many of which persist due to unpatched legacy systems. In total, more than **122,000 unique IPs** from **161 countries and 5,400 networks** were involved. The majority of traffic originated from Brazil and Vietnam, with significant contributions from China, Taiwan, and the U.S. Botnets like **Mirai** played a central role—yet another reminder of how vulnerable IoT devices continue to be exploited at scale. ### Real-world scale To put the numbers in perspective: - One IP address was hit at **34,500 ports per second**. - In bandwidth terms, it was like **downloading 9,000 HD movies in under a minute**. ### Mitigation strategies that worked In this case, the attack was successfully neutralised by an anycast-based network infrastructure capable of absorbing global-scale DDoS events. Cloudflare, the service provider in this incident, used a globally distributed system to route and mitigate traffic with near-instant responsiveness. While Cloudflare’s approach involved kernel-level packet sampling (eBPF), automated rule deployment, and real-time threat intelligence propagation, the broader takeaway is this: **defeating today’s DDoS attacks requires automation, real-time analysis, and scale.** ### Why “low and slow” attacks might be more dangerous While 7.3 Tbps makes headlines, many of today’s most effective DDoS campaigns are **small, stealthy, and smart**. These “low and slow” attacks are designed to degrade service performance or exhaust application-layer resources without triggering volume-based alarms. They’re harder to detect, harder to defend against, and can be just as disruptive as massive floods. ### DDoS-as-a-Service: the threat is cheap, fast, and global Attacks of this size are no longer rare. Multi-terabit-per-second DDoS events have become almost routine. Worse still, they’re widely available via booter and stressor services for less than the price of a takeaway lunch. That accessibility makes **proactive defence** more critical than ever. ### What defenders need to do This attack serves as a wake-up call for defenders everywhere. Here's what matters most: - **Don’t just filter by size**—you need to analyse behaviour and intent. - **Automation is key**—manual response times can’t match attack speeds. - **Legacy systems remain a weak link**—patching and protocol hardening are essential. - **Global threat intelligence sharing** is no longer optional. ### Final thoughts The 7.3 Tbps attack is a new benchmark—but it won’t be the last of its kind. As attackers evolve, so must defenders. That means investing in real-time, autonomous mitigation tools and collaborating across ecosystems. DDoS attacks are getting bigger, faster, and cheaper. But with the right strategy and infrastructure, even the most powerful attacks can be neutralised in seconds—not hours. --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** FastNetMon Blog **Tags:** DDoS Attacks, DDoS News --- ### [Event Recap - Infosecurity Europe 2025](https://fastnetmon.com/2025/06/05/event-recap-infosecurity-europe-2025/) **Published:** June 5, 2025 **Author:** FastNetMon **Content:** ### **Infosec Europe:** **Key Takeaways from London’s Leading Cybersecurity Event** FastNetMon’s CEO Kate Fateeva and Maria Pietilanaho visited Infosecurity Europe 2025—this year marking the event’s 30th anniversary at ExCeL London. As always, it was a great mix of catching up on the latest cybersecurity trends, meeting old friends and new faces, and yes… grabbing some seriously cool merch. From early keynotes to casual chats over coffee, we walked away with fresh insights, new connections, and a renewed sense of how fast the cyber world is evolving. Here are some highlights that stood out to us: ![](https://fastnetmon.com/wp-content/uploads/2025/06/fastnetmon-at-infosecurity-2025-1024x347.png)Great conversations, good vibes, and a signed copy of Joe Tidy’s book—Infosec Europe 2025 delivered once again.### **1. Geopolitics is now a cyber topic** Cybersecurity conversations are no longer just about tech—they're about [geopolitical influence](https://fastnetmon.com/2025/05/19/ddos-in-geopolitics-when-network-traffic-becomes-a-digital-weapon/). A recurring theme at the event was the rise of state-sponsored cyber activity and the idea that we’re entering a kind of “Cyber Cold War.” Attacks on critical sectors like healthcare and energy are becoming more strategic, long-term, and data-focused. ### **2. Quantum & AI: the new frontier** AI is changing the threat landscape on both sides—defenders are using it to predict and detect, while attackers are using it to scale and automate their campaigns. And with quantum computing moving closer to reality, protecting long-term encrypted data is starting to feel more urgent than hypothetical. ![](https://fastnetmon.com/wp-content/uploads/2025/06/infosecurity-conference-2025-London-FastNetMon-1024x347.png)### **3. Cybercrime moves quicker than defence** Several talks touched on the frustrating reality that attackers often move faster than defenders. They don’t have to worry about compliance or process—they just act. But the good news? More organisations are getting proactive, and smarter tools are helping close the gap. ### **4. Zero trust is the new normal** If there’s one thing almost every speaker agreed on, it’s this: traditional perimeter defences aren’t enough anymore. Zero-trust models, least-privilege access, and continuous verification are becoming the go-to strategies for keeping systems secure in a world where threats can come from anywhere. ![](https://fastnetmon.com/wp-content/uploads/2025/06/30th-infosecurity-event-2025-ExCel-London-FastNetMon-1024x347.png)### **5. The skills gap is still acute** There’s no sugarcoating it—cyber talent is still hard to find. Many organisations are struggling to build or retain strong security teams. AI might help fill some of the gaps, but for now, it’s clear that people are still the most valuable (and scarce) resource in cybersecurity. ### **Wrapping up** We had a great time at Infosec this year. It was a pleasure to see so many familiar faces—especially colleagues from our partners and clients—and to meet loads of new ones. We came back with plenty of insights, a renewed sense of where the industry’s headed, and yes… a tote bag full of swag. As always, Infosecurity Europe proved to be a valuable stop on the calendar, and we’re already looking forward to the next one. ![](https://fastnetmon.com/wp-content/uploads/2025/06/Infosecurity-Europe-2025-Keynotes-Conference-summary-FastNetMon-1024x347.png) **Categories:** Events, Press & Newsroom **Tags:** events --- ### [DDoS attack targets BYOND game engine in push to open-source it](https://fastnetmon.com/2025/06/05/ddos-attack-targets-byond-game-engine-in-push-to-open-source-it/) **Published:** June 5, 2025 **Author:** FastNetMon **Content:** As of June 2025, the BYOND game engine continues to face a persistent and disruptive Distributed Denial-of-Service (DDoS) attack that began on May 10. This sustained assault has severely impacted BYOND's central services, including its website, multiplayer lobby, and update servers, leading to widespread disruption across its community. ### What’s Happening? The attack involves large volumes of junk traffic overwhelming BYOND's infrastructure, causing intermittent outages of the main website and central login services. Players have resorted to connecting directly to game servers using IP addresses, bypassing the usual server list. Bug reports and game downloads are now shared through community platforms like Discord. A now-deleted Reddit post from a group calling itself the "FOSS Brethren of BYOND" has claimed responsibility. The group demands that BYOND's creator open-source the engine, stating the attacks will continue until this happens. The creator has refused, and moderators suggest the campaign may be driven more by a personal grudge than a coordinated open-source push. ### Community Impact The attack has hit smaller projects especially hard, as they rely on BYOND’s master server list for visibility and updates. With the central services down, new players struggle to find servers and game updates fail silently. Community members have been sharing manual connection details via Discord, but overall player numbers have dropped. Fans are encouraged to support the platform through Patreon or SubscribeStar while the normal shopfront remains inaccessible. ### Why This Matters While DDoS attacks are typically used for extortion, using them to pressure a platform into open-sourcing is rare. This case shows how cheaply and easily public services can be disrupted—and how political or ideological goals can also motivate attackers. It’s a wake-up call for any online platform to prepare for outsized threats it may not have planned for. ### Staying Online The BYOND team is working with providers to strengthen filtering and reduce the impact of the attacks. Developers are hosting mirrors off-site, and the community continues to share tips and connection methods to keep games running. For other indie platforms, the takeaway is clear: maintain alternative communication channels, publish fallback connection guides, and separate critical revenue infrastructure from vulnerable public-facing systems. Despite everything, BYOND’s community remains resilient—finding creative workarounds and keeping their games alive. The attackers want an open-source release. Instead, they’ve helped prove how tightly knit and determined this fan base truly is. --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit <https://fastnetmon.com> **Categories:** FastNetMon Blog **Tags:** DDoS News, gaming --- ### [FastNetMon Advanced 2.0.372](https://fastnetmon.com/2025/06/03/fastnetmon-advanced-2-0-372/) **Published:** June 3, 2025 **Author:** FastNetMon **Content:** FastNetMon Advanced 2.0.372 has been released with a critical fix and several improvements. This release addresses a stability issue that could cause FastNetMon to crash when processing malformed ASN feed data. We've also enhanced IPv6 address formatting, improved ASN allocation performance, and made refinements across Netflow, IPFIX, and sFlow logic. Additionally, this release introduces support for Juniper SRX via new IPFIX fields and resolves several minor bugs related to integrations and platform support. Changes: - Added support for IPv6 sudo sudo fcli show ip\_asn command - Addressed crash when ASN feed has malformed data - Reworked print\_ipv6\_address to use Boost based functions to print IPv6 addresses as our own IPv6 compression broke up addresses like 0000::1/128 and printed them as :0001/128 - Moved away from lookup\_tree\_32bit\_with\_dynamically\_allocated\_payload\_t to lookup\_tree\_32bit\_with\_payload\_t which stores data in leafs and does not use intermediate pointers. Some speed up for ASN allocation is expected. As side affect we have improved sanity checks for input data - Re-enabled usage stats for offline licenses - Enabled sflow\_track\_sampling\_rate by default - Small improvement for performance of sFlow sampling rate tracking - Addressed bug in Mikrotik API based integration which used /128 instead of /32 - Removed Debian 9, 10 and Ubuntu 16.04 as we deprecated them long time ago - Implemented move constructor to address issue with gcc 13 and LLVM, GitHub #1013 - Added support for IPFIX fieds with IDs 85 and 86 to implement Juniper SRX support - Fixed content type for Prometheus endpoint to be text/plain - Reduced logging level for: Successfully loaded flexible threshold - Added log level checking for Netflow v9 logic as it may be root cause of performance degradation - Added log level checking for IPFIX logic as it may be root cause of performance degradation - Suppressed error 'process\_ipfix\_sets returned error' when we have no template to continue processing for other flowsets - Added logic to agent address matches in Flow Cpec filters - Added input\_interface\_matches and output\_interface\_matches for Flow Spec based filter - Added input\_interfaces and output\_interfaces to Flow Spec structure **Categories:** Releases **Tags:** release, releases --- ### [6.3 Tbps in 45 Seconds: what the latest assault on KrebsOnSecurity tells us about hyper-volumetric DDoS](https://fastnetmon.com/2025/05/27/6-3-tbps-in-45-seconds-what-the-latest-assault-on-krebsonsecurity-tells-us-about-hyper-volumetric-ddos/) **Published:** May 27, 2025 **Author:** FastNetMon **Content:** On 12 May 2025, digital-forensics journalist Brian Krebs watched his site absorb a flood of traffic that briefly touched 6.3 terabits per second. The surge lasted just 45 seconds, delivering about 585 million UDP packets per second to random ports - enough throughput to overwhelm all but the biggest carrier links. Size and technique point to Aisuru (also called Airashi), a year-old botnet built from compromised routers, DVRs and other IoT devices. Researchers first tracked Aisuru in August 2024; since then it has re-emerged with new exploits, including [a zero-day in Cambium cnPilot routers](https://fastnetmon.com/2025/01/24/cybercriminals-leverage-zero-day-vulnerability-to-launch-airashi-ddos-botnet/), and is openly advertised on Telegram at up to US $600 per week. Brian Krebs’ 2016 Mirai incident showed how source-code leaks can fracture a monolithic botnet into weaker clones. Aisuru is still private, giving one operator control of uncommon fire-power. Experts noted that public release of Aisuru’s code, or at least the exploit list, would force that power to fragment, bringing individual floods back within reach of most mitigation services. The attack also underlines a shift towards hyper-volumetric ‘demo’ blasts. Bursts under a minute are long enough to prove capability to prospective customers yet short enough to avoid lengthy engagement with defenders. Cloudflare says it blocked more than 700 attacks above 1 Tbps in Q1 2025; most lasted 35–45 seconds. For defenders, the lesson is readiness rather than attribution. Services must assume that trafficked IoT devices and [for-hire channels](https://fastnetmon.com/2025/04/10/ddos-booters-and-ip-stressers-explained-by-experts/) can deliver terabit-scale hits on short notice. That means: - Keeping capacity on hand or under contract for sudden multi-Tbps spikes - Deploying stateless filtering and [rate-limiting](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-configuration-options/) at the edge to drop large UDP floods before they reach application layers - Instrumenting networks to [react automatically in the first few seconds](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-bgp-blackhole-automation/) - Sharing fingerprints of new botnet traffic quickly with upstream providers Until the underlying device security improves, hyper-volumetric floods will remain a risk that must be well planned for. Read Brian Krebs' analysis of the events [here](https://krebsonsecurity.com/2025/05/krebsonsecurity-hit-with-near-record-6-3-tbps-ddos/#more-71303). --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit <https://fastnetmon.com> **Categories:** FastNetMon Blog **Tags:** DDoS Attacks --- ### [Event Recap – TRNOG Izmir](https://fastnetmon.com/2025/05/27/event-recap-trnog-izmir/) **Published:** May 27, 2025 **Author:** FastNetMon **Content:** FastNetMon was pleased to attend **TRNOG event in Izmir** on May 24, 2025. This was the second official event organised by the Turkish Network Operators Group ([TRNOG](https://trnog.net/)), following the [successful launch in Ankara](https://fastnetmon.com/2025/01/28/event-recap-trnog-2025/) earlier this year. TRNOG is a non-profit community of network engineers committed to advancing internet infrastructure and collaboration across Turkey. The Izmir event continued this mission, bringing together professionals from ISPs, telecom companies, academia, and the wider networking community. ![](https://fastnetmon.com/wp-content/uploads/2025/05/TRNOG-Izmir-speakers-FastNetMon-1-1024x534.jpeg)TRNOG Speakers with Pavel Odintsov: Seher Sağıroğlu, Osman Makal, Serkan Gencel, Abdullah Ayaz, Nurhan Nasuflar, Yaşar Semih Alev, Mahmut Aydın, Gökhan Candoğan, Salih Alçın, Mehmet Usanmaz, Oğuzhan Yılmaz.The day featured a full schedule of technical presentations, networking sessions, and discussions around the future of TRNOG. The event opened with a session on the group’s roadmap and formalisation process, followed by a diverse range of topics including: - **Unwanted Traffic Removal Service (UTRS)** – Osman Makal - **DDoS Prevention and Mitigation Strategies** – Serkan Gencel - **DNS System Security** – Abdullah Ayaz - **Carrier-Grade NAT (CGNAT) Architectures and IPv4 Resource Management** – Nurhan Nasuflar - **Recursive DNS with SDNS** – Yaşar Semih Alev - **VXLAN-based Overlay Networks and Data Center Segmentation** – Mahmut Aydın - **Routing and Traffic Localisation in Turkey** – Gökhan Candoğan - **5G’s Impact on Traditional Internet Infrastructure** – Salih Alçın - **Infrastructure Automation with DevOps** – Mehmet Usanmaz - **Service Provider Challenges** – Oğuzhan Yılmaz ![](https://fastnetmon.com/wp-content/uploads/2025/05/TRNOG-Izmir-2025-Audience-FastNetMon-1024x478.png)Talks from representatives of **Nokia**, **Huawei**, and **Türk Telekom** added depth to the day’s discussions, with highly technical sessions covering current and emerging issues in network operations. As with the [Ankara event](https://fastnetmon.com/2025/01/28/event-recap-trnog-2025/), TRNOG Izmir concluded with an open mic session, giving participants the chance to share thoughts, ask questions, and contribute ideas to the community. The event drew strong attendance and engagement throughout the day, highlighting the momentum behind the TRNOG initiative. FastNetMon is proud to support this growing community and remains committed to contributing to the exchange of knowledge and collaboration among network professionals in Turkey. --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** Events, Press & Newsroom **Tags:** events --- ### [HTTPBot: A New Breed of Windows-Based DDoS Botnet](https://fastnetmon.com/2025/05/20/httpbot-a-new-breed-of-windows-based-ddos-botnet/) **Published:** May 20, 2025 **Author:** FastNetMon **Content:** ## New Windows botnet HTTPBot zeroes in on game and tech portals For years, most DDoS botnets have operated from compromised routers, IoT devices, or Linux servers. HTTPBot breaks that pattern. Written in Go and compiled specifically for Windows, this new botnet has emerged as a stealthy and precise threat. Since April 2025, it has targeted gaming, tech, and education sites—especially in China—with sophisticated HTTP-based attacks that closely mimic real browser traffic. ### What Makes HTTPBot Different? Unlike traditional botnets that flood networks with massive volumes of data, HTTPBot operates like a scalpel. It doesn’t just try to exhaust bandwidth—it targets application logic, aiming to disrupt services at the software level. Once installed, HTTPBot hides its presence by removing any visual interface and adding itself to the Windows startup registry. From there, it connects to a command-and-control server to receive attack instructions. Each command includes a method, target, duration, and a unique attack ID. It supports seven different HTTP-based DDoS methods, including: - **BrowserAttack**: Opens hidden Chrome sessions to keep server threads occupied. - **HttpAutoAttack & CookieAttack**: Replays session cookies and automates requests to look like genuine user traffic. - **HttpFpDlAttack**: Exploits HTTP/2 features to trigger large file downloads, increasing CPU load on servers. - **WebSocketAttack**: Leverages both `ws://` and `wss://` protocols to consume backend resources. - **PostAttack**: Sends high volumes of POST requests to overwhelm application endpoints. To avoid detection, HTTPBot wraps its traffic in Base64 encoding and rotates URLs frequently. Some of its modules even require Windows 8 or newer, suggesting a deliberate pivot away from outdated IoT devices and toward more powerful and modern Windows systems. ### Why Gaming and Payment Portals Are Vulnerable Gaming and financial services depend on ultra-fast, low-latency backends—especially login systems and payment APIs. Even a small disruption can cause customer frustration and revenue loss. HTTPBot’s operators exploit this by sending low-volume, high-fidelity traffic that appears legitimate. These structured bursts fly under the radar until backend resources quietly degrade. According to NSFOCUS, this marks a shift from brute-force suppression to business-layer strangulation. Telemetry data shows HTTPBot’s attacks are spread out across the day, indicating automation rather than manual campaigns. ### How to Defend Against HTTPBot Traditional DDoS defenses focused on blocking bandwidth spikes won’t cut it anymore. HTTPBot requires **deep Layer 7 visibility**—that means monitoring the actual behavior of traffic at the application layer. Recommended strategies include: **Patch Windows systems**: Many infected hosts are edge servers or desktops running outdated Windows versions. Keeping systems updated reduces the botnet's foothold. **Baselining APIs**: Track normal patterns in cookies, payload sizes, and WebSocket usage. Alert on anomalies before users are affected. **Layer 7 filtering**: Use application-aware security solutions that can distinguish between real and synthetic HTTP sessions. --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit <https://fastnetmon.com> **Categories:** FastNetMon Blog **Tags:** Botnets, DDoS News --- ### [Event Recap: RIPE 90](https://fastnetmon.com/2025/05/19/event-recap-ripe-90/) **Published:** May 19, 2025 **Author:** FastNetMon **Content:** From 12–16 May, the RIPE community gathered in Lisbon for RIPE 90, bringing together over 820 attendees from 55 countries. With 648 joining in person and 172 online, the event once again proved to be a vital space for collaboration across network operations, policy, and research. ### **A Strong Start and Key Themes** The event kicked off with welcomes from RIPE Chair Mirjam Kühne, .PT’s Luisa Ribeiro Lopes, and RIPE NCC’s Hans Petter Holen. It set the stage for a packed week of talks focused on routing security, network resilience, visibility tools, and community leadership. Maria Farrell’s keynote, *How to Rewild the Internet*, offered a fresh perspective on how we think about Internet openness and control. Another popular session was Timo Hilbrink’s story of launching an ISP with zero resources—grounded, inspiring, and very RIPE. Technical deep-dives followed, covering topics like: - The state of **RouteViews** (Nina Bargisen) - **Hidden attack traffic** as the “microplastics of the Internet” (Leslie Daigle) - **BGP and BMP data collection** (Alexander Azimov) - Monitoring **submarine cable outages** and power blackouts via RIS and Atlas Fast-paced lightning talks also stood out, covering IPv6 routing loops, Kubernetes networking, and cache eviction algorithms—all showing the wide range of operational challenges facing today’s Internet. ![](https://fastnetmon.com/wp-content/uploads/2025/05/RIPE90-Event-Recap-by-FastNetMon.-Day-1-1024x482.jpg)### **Research Meets Reality** This year’s RACI (RIPE Academic Cooperation Initiative) talks created important bridges between academia and operations. Topics ranged from critical BGP prefix analysis and SSH key abuse detection, to the impact of the Ukraine war on Internet peering. These talks reminded us how academic work can have direct, practical relevance—especially when backed by real measurement data and operational context. ### **Community Transitions** As always, RIPE 90 wasn’t just about tech—it was also about people. The community welcomed several new Working Group Chairs: - Yevheniya Nosyk (DNS) - Anna Maria Mandalari (IoT) - Franziska Lichtblau (Address Policy) We also thank the outgoing chairs—William Sylvester, Peter Wehrle, and Doris Hauser—for their long-standing contributions. On the Programme Committee side, Clara Wade was re-elected, and Amedeo Beck Peccoz joined as a new member. ![](https://fastnetmon.com/wp-content/uploads/2025/05/RIPE90-Event-Recap-FastNetMon-day-2-1024x482.jpg)### **Takeaways from FastNetMon** For us at FastNetMon, RIPE 90 reinforced the importance of visibility tools, routing hygiene, and crisis resilience. Talks about how the network reacts to disruption—whether geopolitical or infrastructural—align closely with the work we do, helping operators monitor and defend their networks. It’s always inspiring to see the strength and openness of the RIPE community. We're looking forward to continuing the conversations at RIPE 91 in Bucharest later this year. --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** Events, Press & Newsroom **Tags:** events --- ### [India-Pakistan conflict evokes a wave of cross-boarder DDoS attacks](https://fastnetmon.com/2025/05/15/india-pakistan-conflict-evokes-a-wave-of-cross-boarder-ddos-attacks/) **Published:** May 15, 2025 **Author:** FastNetMon **Content:** ## DDoS escalates alongside India-Pakistan hostilities When military tensions flared between India and Pakistan in early May, a parallel cyber campaign unfolded at speed. Threat-hunting data show a clear pattern: each round of air- or missile-strikes was mirrored by larger, longer Distributed Denial-of-Service (DDoS) assaults on networks. **What happened?** 7 May – India carried out ‘Operation Sindoor’, hitting nine sites it called terrorist infrastructure. Within hours, daily DDoS activity aimed at Indian targets rose nearly ten-fold. 8–10 May – Pakistan launched its “Iron/Solid Wall” response. Botnets and reflection attacks followed, peaking on 10 May with 97 separate incidents – fourteen times the rate seen during late-April border skirmishes. 11 May onwards – After both capitals agreed a cease-fire, volumes fell but did not stop, underlining the lag between physical de-escalation and cyber calm. **Who was most affected by these attacks?** The first wave of traffic hammered telecoms and news portals, but as hostilities intensified attackers turned their fire on higher-value government sites. Between 7 and 8 May the Indian President’s Office was struck twice with DNS-reflection floods, the second barrage lasting almost twenty hours. On 9 May a Mirai-driven ACK flood hit the Jammu & Kashmir government portal. The next day saw three more high-profile targets: the Ministry of Defence suffered a three-hour-plus NTP-amplification assault; the Prime Minister’s Office, the Press Information Bureau and the National Informatics Centre. Pakistan-based sources claimed cyber operations paralysed “70 % of India’s power grid”, a statement denied by Indian officials. Independent telemetry does confirm repeated attacks on government-linked name servers; whether wider outages followed remains unverified. **The wider hacktivist scene** Commercial and ideological groups quickly joined in. Analysts counted at least 26 outfits – including RipperSec, Keymous+ and Sylhet Gang – claiming 250-plus Indian targets since January. Government websites made up more than half of all DDoS declarations; finance, telecoms and manufacturing followed. AI-driven tools, turnkey botnets and open-source scripts such as MegaMedusa lower the bar to entry. Many campaigns blend high-bandwidth UDP floods with application-layer hits that mimic genuine users, complicating defence. **What was the purpose of these DDoS attacks?** DDoS is a mainstream instrument of statecraft: capable of silencing public portals, slowing critical services and amplifying battlefield narratives. Even after ceasefires, online pressure can persist, raising the risk of miscalculation or retaliation. --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit <https://fastnetmon.com> **Categories:** FastNetMon Blog **Tags:** political --- ### [Event Recap: DataCenter Forum Romania](https://fastnetmon.com/2025/05/12/event-recap-datacenter-forum-romania/) **Published:** May 12, 2025 **Author:** FastNetMon **Content:** ## **FastNetMon at DataCenter Forum Romania 2025: AI, Sustainability, and Growth in Southeastern Europe** Last week, FastNetMon had the pleasure of attending the **DataCenter Forum Romania 2025**, held at the Face Convention Center in Bucharest. The event brought together over 600 data centre professionals, technology leaders, and policymakers to explore the future of digital infrastructure in Southeastern Europe. We were thrilled to meet several of our regional partners and customers during the day and engage in meaningful conversations about the challenges and opportunities shaping the market. ![](https://fastnetmon.com/wp-content/uploads/2025/05/DataCentre-forun-conference-Romania-2025-FastNetMon-1024x616.jpeg)### **Key Learnings & Takeaways from the Forum** **1. AI Is Reshaping Data Centre Infrastructure** A clear theme throughout the event was the rapid rise of AI-driven workloads. Discussions focused on the transition from traditional setups to **AI-optimised, high-density environments**, with technologies like **liquid cooling** becoming increasingly relevant. **2. Sustainability Is Not Optional With Romania facing a critical shortage in data centre capacity—only **5% vacancy in space and power**—sustainability and energy efficiency were front and centre. Thought leaders shared strategies for reducing environmental impact, including **renewables integration**, **advanced battery solutions**, and paths to **energy autonomy**. **3. Compliance as a Competitive Advantage Regulatory insight sessions led by the **Uptime Institute** and **European Commission** emphasised how proactive compliance with evolving EU regulations can drive both efficiency and competitiveness. **4. Romania's Growing Role in Regional Infrastructure** Despite current capacity limitations, Romania is positioned as a compelling location for future investments. With **low construction costs**, **renewable energy availability**, and a **strategic geographic position**, the country is emerging as a key hub for digital infrastructure in Southeastern Europe. **Looking Ahead** At FastNetMon, we continue to stay close to developments across the region, especially where **network visibility**, **security**, and **infrastructure resilience** intersect. It was inspiring to witness the energy and ambition in Romania’s digital infrastructure community, and we’re excited to support our partners as this market evolves. ![](https://fastnetmon.com/wp-content/uploads/2025/05/DataCenter-Forum-Romania-2025-Conference-Virgil-Truica-FastNetMon-1024x572.png)--- ## About FastNetMon FastNetMon delivers versatile DDoS detection software for companies at any scale. With extensive experience in the telecom, mobile, and cloud computing industries, we take pride in preventing DDoS attacks and protecting our customers’ networks to the highest standard. Read more at [fastnetmon.com](https://fastnetmon.com/). **Categories:** Events, Press & Newsroom **Tags:** events --- ### [50+ Dutch public services flooded by NoName057(16) in one week as a ‘punishment’](https://fastnetmon.com/2025/05/08/50-dutch-public-services-flooded-by-noname05716-in-one-week-as-a-punishment/) **Published:** May 8, 2025 **Author:** FastNetMon **Content:** ## NoName057(16) ‘punishes’ the Dutch government by sending the largest single DDoS burst at their public services sector NoName057(16), the infamous hacktivist crew that has spent two years peppering Europe with nuisance floods, has turned its sights back on the Netherlands. Starting on Monday, the group launched three waves of DDoS traffic, knocking municipal portals in Apeldoorn, Nijmegen, Breda and Tilburg offline. By mid‑week the list had grown to 50‑plus targets, from local transport operators GVB and Arriva to national newspaper NRC. Pages either timed‑out or crawled for several hours, but no data was taken. **What made this week different?** The National Cyber Security Centre confirmed the activity is the largest single DDoS burst aimed at Dutch infrastructure since 2023. NoName057(16) claims it is ‘punishing’ the Dutch government for military aid to Ukraine. In reality, the attacks were textbook volumetric floods: UDP, SYN and TCP packets hurled at public websites to drum up headlines rather than cause long‑term damage. **A pattern that keeps repeating** This is hardly the first time Dutch services have faced DDoS pressure in 2025: January – several universities and the government’s DigiD login portal were slowed by [coordinated floods](https://fastnetmon.com/2025/03/18/ddos-attack-cause-another-digid-outage-in-the-netherlandshttps://fastnetmon.com/2025/01/20/institutions-in-the-netherlands-affected-by-ddos-attacks-several-universities-and-government-login-service-impacted/). March –[ another DigiD outage](https://fastnetmon.com/2025/03/18/ddos-attack-cause-another-digid-outage-in-the-netherlands/) disrupted citizens trying to file taxes online. April – hosting provider Argeweb spent a week fending off [repeated hits to its DNS platform](https://fastnetmon.com/2025/04/14/dutch-hosting-provider-argeweb-battles-week-long-ddos-attack/), affecting customer sites nationwide. Put together, these incidents show how public‑facing portals, from payments to transport timetables, remain easy PR targets for ideologically driven crews. **Why does it matter?** Even when sites return within hours, every outage chips away at public trust and forces IT teams into fire‑fighting mode. For local councils that now deliver services almost entirely online, repeated downtime means interrupted appointments, citizen frustration and extra support desk costs. --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit <https://fastnetmon.com> **Categories:** FastNetMon Blog **Tags:** political --- ### [DDoS-for-Hire Network shut down in Poland](https://fastnetmon.com/2025/05/07/ddos-for-hire-network-shut-down-in-poland/) **Published:** May 7, 2025 **Author:** FastNetMon **Content:** ## A successful international operation takes down several IP booter services In a major international crackdown on cybercrime, Polish authorities have arrested four individuals suspected of running a network of platforms that facilitated thousands of DDoS attacks worldwide. These platforms, known as[ stresser/booter services](https://fastnetmon.com/2025/04/10/ddos-booters-and-ip-stressers-explained-by-experts/), allowed users to pay as little as 10 euros to flood websites and servers with malicious traffic, with the intention of taking them offline. The news of the successful take-down was published on May 7th 2025 by Europol [on their website](https://www.europol.europa.eu/media-press/newsroom/news/ddos-for-hire-empire-brought-down-poland-arrests-4-administrators-us-seizes-9-domains). [Stresser and booter services](https://fastnetmon.com/2025/04/30/most-infamous-ddos-booter-services-and-user-consequences/) are often marketed as legitimate testing tools but are widely misused to disrupt online services. They industrialise DDoS attacks by using centralised, rented infrastructure, making them accessible to a broader audience through underground forums and the dark web. **Some of the infamous DDoS booter platforms involved** The dismantled platforms, including Cfxapi, Cfxsecurity, neostress, jetstress, quickdown, and zapcut, were used to target a wide range of entities, from schools and government services to businesses and gaming platforms, between 2022 and 2025. These services offered user-friendly interfaces, enabling even those without technical skills to launch powerful cyberattacks by simply entering a target IP address and selecting attack parameters. **Internationally coordinated effort** This operation was part of a coordinated effort involving law enforcement agencies from four countries, with Europol providing crucial analytical and operational support. The Dutch authorities contributed by setting up fake booter sites to deter potential users and sharing data from seized booter websites with international partners, aiding in the arrests.The United States also played a significant role by seizing nine domains linked to these illegal services, continuing its campaign against commercialised DDoS platforms. Meanwhile, Germany assisted the Polish investigation by identifying suspects and sharing vital intelligence. This action is part of Operation PowerOFF, an ongoing international initiative targeting the infrastructure behind DDoS-for-hire activities. Europol has reported on this significant development, highlighting the collaborative efforts of international law enforcement in tackling cybercrime. ## **About FastNetMon** FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit <https://fastnetmon.com> **Categories:** FastNetMon Blog **Tags:** legal --- ### [Record-size DDoS batters betting site during a major NHL event](https://fastnetmon.com/2025/04/30/record-size-ddos-batters-betting-site-during-a-major-nhl-event/) **Published:** April 30, 2025 **Author:** FastNetMon **Content:** On 3 April 2025, an online bookmaker was battered by the largest public DDoS disclosed so far in 2025. [As reported by Techradar](https://www.techradar.com/pro/largest-ddos-attack-of-2025-hit-an-online-betting-organization-with-1tbps-brute-force-heres-what-we-know), the traffic began spiking at 11:15 UTC, jumped from 67 Gbps to 217 Gbps in eight minutes, and peaked at 965 Gbps by 11:36. The flood faded after 90 minutes, but not before punters across several regions saw payment pages time out and in-play bets vanish. **What happened?** The assault combined four classic techniques: - UDP flood – the biggest wave, topping 965 Gbps - SYN flood – 229 Gbps of half-open handshakes - IP flood – 214 Gbps of raw packets - TCP flood – 169 Gbps aimed at state tables Using several vectors forces defences to chase multiple signatures at once, buying attackers extra minutes of disruption. **Why are betting platforms tempting targets?** Betting sites process thousands of micro-transactions per second. When a major sporting moment sends traffic soaring, even a brief slowdown can freeze odds or cancel cash-outs, costing both house and players. Attackers bank on that urgency. An one-hour outage during peak play can translate to lost turnover, charge-backs and frustrated customers ready to switch providers. **How a near-terabit flood is assembled?** Today’s DDoS crews rent power rather than build it. They compromise unpatched routers, webcams and servers, then lease the combined bandwidth as an hourly service. Because devices are scattered worldwide, filtering by geography or single IP blocks rarely works. **How to reduce the blast radius?** - Plan for surge traffic – model capacity on finals, not off-season averages. - Layer controls – edge rate-limits, [automated blackholing](https://fastnetmon.com/bgp-blackhole-automation/) for confirmed targets, and [real-time scrubbing](https://fastnetmon.com/ddos-scrubbing-centre-diversion/) in the cloud form a safety net. - Rehearse fail-over – run tabletop drills so staff know who pulls which lever when dashboards go red. --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit <https://fastnetmon.com> **Categories:** FastNetMon Blog **Tags:** DDoS News --- ### [Three DDoS waves in one evening: Adyen’s payments put to the test](https://fastnetmon.com/2025/04/24/three-ddos-waves-in-one-evening-adyens-payments-put-to-the-test/) **Published:** April 24, 2025 **Author:** FastNetMon **Content:** ## Dutch payment processor experiences multiple DDoS attacks in one day **An evening of false starts** Just after 7 p.m. on 8 April, diners in Dutch cafés and shoppers across Europe noticed card readers freezing. The culprit wasn’t a bad internet connection, but a flood of DDoS traffic aimed at Adyen, the Amsterdam-based payment processor that handles billions in transactions every year. Engineers fought back, cleared the traffic, and services steadied… until 8:35 p.m., when a second surge arrived. By 11:35 p.m. a third wave was rolling in, turning routine purchases into an exercise in patience. **Why a wobble at Adyen ripples worldwide** Adyen acts as the middleman between tills, apps and banks for giants such as Meta, Uber and eBay. Last year alone it shepherded nearly €1.3 trillion in payments. When its servers choke, queues form from Rotterdam to Reykjavík and online baskets get abandoned. Tuesday’s trading session told the story in numbers: Adyen’s share price slipped more than 2% at the bell. **Counting the cost of minutes** DDoS attacks are blunt instruments as there’s no data theft, just brute congestion. Yet a 30-minute outage can drain sales, trigger angry tweets and push support teams into overdrive. Merchants often learn the hard way that ‘card declined’ flashes faster than brand loyalty. **What can merchants do next time?** - Spread the load. A second gateway or acquiring bank can keep cash flowing if one route jams. - Automate fail-over. Modern checkout software can switch providers in seconds once error rates spike. - Filter early. Fast [rate-limiting](https://fastnetmon.com/ddos-detection-and-mitigation/) and [blocklist filtering](https://fastnetmon.com/blocklist-filtering/) stop a chunk of malicious traffic before it reaches the core. - Drills beat post-mortems. A late-night [stresser rehearsal](https://fastnetmon.com/2025/04/10/ddos-booters-and-ip-stressers-explained-by-experts/) of your incident plan is cheaper than peak-hour chaos. By 3:30 a.m. most Adyen functions were back; only fringe features lagged into the morning. For a platform processing hundreds of transactions a second, that’s a swift comeback. Still, the episode shows how fragile the last click at checkout can be. --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit <https://fastnetmon.com> **Categories:** FastNetMon Blog **Tags:** DDoS News --- ### [Russian railways RZD app crashes in major cyber disruption](https://fastnetmon.com/2025/04/05/russian-railways-rzd-app-crashes-in-major-cyber-disruption/) **Published:** April 5, 2025 **Author:** FastNetMon **Content:** On 1 April, Russia’s state-owned railway RZD was hit by a DDoS attack that knocked its website and mobile app offline. **No tickets, no timetables, just timeout errors** The disruption began Tuesday evening and affected users nationwide, many of whom were unable to check train schedules or purchase tickets online. Although station offices remained open, the outage created delays and confusion for travellers who rely on the app for real-time updates. RZD confirmed the incident on Telegram, describing it as a ‘mass DDoS attack,’ and said efforts were underway to restore services. They did not disclose how long the disruption lasted or how many users were affected, but public monitoring platforms showed a surge in reports throughout the evening. **Same week, same pattern: Moscow Metro also affected** The attack came just one day after a similar disruption affected Moscow’s metro app and website. While officials called that incident ‘technical work,’ reports suggested it may have also been caused by a DDoS attack. A message written in Ukrainian briefly appeared on the Metro site, raising questions about potential defacement. Elsewhere, the Belgorod regional administration experienced an outage during a livestream, also attributed to DDoS activity. **RZD’s history with cyber attacks** These events are not isolated. RZD has previously dealt with DDoS attacks in 2022 and 2024. Earlier this year, the pro-Ukrainian group CyberSec claimed to have accessed RZD’s internal systems and leaked employee data. Whether or not the latest incident is linked, the trend is clear: transport networks remain vulnerable targets. **A simple flood of traffic, a complex set of consequences** DDoS attacks don’t break infrastructure, but they overload it. In a sector where digital tools are now central to day-to-day operations, the impact is immediate - causing delays, miscommunication, and operational pressure. Whether coordinated or coincidental, the timing and nature of these attacks point to growing pressure on digital services in public infrastructure. Building resilience against such attacks is no longer optional. ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit <https://fastnetmon.com> **Categories:** FastNetMon Blog **Tags:** DDoS Attacks --- ### [OnlyFangs disbands after WoW intense DDoS attacks — what it says about gaming security in 2025](https://fastnetmon.com/2025/04/03/onlyfangs-disbands-after-wow-intense-ddos-attacks-what-it-says-about-gaming-security-in-2025/) **Published:** April 3, 2025 **Author:** FastNetMon **Content:** One of World of Warcraft Hardcore’s most watched guilds, OnlyFangs, has officially disbanded — not because of in-game failure, but due to repeated DDoS attacks. The group, made up of streamers and creators like Sodapoppin, Tyler1, and Zizaran, decided to call it quits after players repeatedly lost characters and raid progress because of connection issues caused by targeted server overloads. The decision came after several attacks interrupted gameplay, including a failed Blackwing Lair run where random disconnects during boss fights left players vulnerable. In Hardcore mode, where character death is permanent, technical disruptions don’t just mean frustration — they mean hours or weeks of progress lost in an instant. **What actually happened** Starting early March, a wave of DDoS attacks hit Blizzard’s infrastructure. These types of attacks flood servers with traffic, causing lag, disconnections, or full downtime. In WoW Hardcore, the stakes are uniquely high: the game mode offers no revives, no retries. When your character dies, it’s over. The OnlyFangs guild wasn’t just any group, it was made of top creators streaming their journey to thousands of fans. That visibility likely made them a high-value target for trolls hoping to disrupt content. And it worked. Sodapoppin, who founded the guild, eventually stated that ‘it’s a terrible ending, but that’s the ending we got.’ **The fallout: Blizzard responds** In an unusual move, Blizzard has now announced that it may selectively revive characters killed during mass-disconnection events, which is something the studio has never done in the Hardcore mode before. They stressed this would be a rare decision, based solely on whether they believe the deaths were tied to events that compromise the integrity of the game, such as a DDoS attack. While some players applauded the change, others weren’t convinced. Many argued that smaller players who lost characters during similar events in the past were offered no support, and that Blizzard only stepped in when high-profile streamers were affected. **Why DDoS attacks keep happening** At its core, this is a security problem. DDoS attacks have become increasingly cheap and easy to execute, especially with the rise of DDoS-as-a-Service platforms that let anyone pay to flood servers with fake traffic. Gaming platforms, particularly those hosting high-stakes or public-facing content, have become frequent targets. Streaming guilds like OnlyFangs draw a lot of attention. With that attention comes a higher risk of disruption, either for clout, trolling, or sabotage. And since even a second of lag can be fatal in Hardcore, the consequences are steep. **What can be done?** DDoS attacks weaponise the very infrastructure games rely on. That makes mitigation a different kind of challenge. Real-time traffic monitoring, adaptive filtering, and layered defences like scrubbing centres and rate limiting are all part of the modern toolkit. Still, as the situation with OnlyFangs shows, even major studios can struggle to respond quickly enough, and players are the ones who pay the price. For gamers, especially those streaming high-risk content, the takeaway is clear: internet visibility cuts both ways. For developers and platform providers, this is another case that shows just how disruptive modern DDoS attacks can be, not just to services, but to entire communities built around them. --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit <https://fastnetmon.com> **Categories:** FastNetMon Blog **Tags:** DDoS Attacks, gaming --- ### [Event Wrap - CloudFest 2025](https://fastnetmon.com/2025/03/28/event-wrap-cloudfest-2025/) **Published:** March 28, 2025 **Author:** FastNetMon **Content:** CloudFest 2025, hosted from March 17-20 at Europa Park in Rust, Germany, brought together over 11,000 cloud industry professionals from across the globe. This year's event was the largest to date, with an expanded exhibition area to accommodate the growing number of companies eager to showcase their innovations. The atmosphere was buzzing with a sense of community and shared purpose as attendees engaged in discussions shaping the future of the internet and cloud infrastructure. ![](https://fastnetmon.com/wp-content/uploads/2025/03/CloudFest-2025-Stage-FastNetMon-1-1024x559.jpg) CloudFest proved to be a productive event for FastNetMon. We found the conference to be a dynamic environment where we had the chance to connect with a diverse range of cloud and DDoS security professionals through both scheduled meetings and spontaneous interactions. The recognition of FastNetMon among attendees was noteworthy, and we were delighted to hear positive experiences and familiarity with our solutions, which facilitated meaningful discussions and the potential for future collaborations. The event also featured a diverse lineup of keynotes, panels, and workshops, covering topics from web hosting and customer support to sustainability and innovation. Each day had a distinct theme, with discussions on boosting profits, innovation with empathy, and creating solutions with a human touch. Notable speakers included author Cory Doctorow, who addressed the decline in online platform quality, and improv sessions that encouraged spontaneity and creative problem-solving. ![](https://fastnetmon.com/wp-content/uploads/2025/03/CloudFest-2025-FastNetMon-Virgil-Truica-1024x585.jpg)Artificial Intelligence was a prominent theme, with discussions on its role in cloud computing and hosting. While some attendees, like Dainius Kavoliūnas from Hostinger Horizons, viewed current AI applications as incremental improvements, there was a strong focus on AI-driven software creation. This innovation is seen as a potential disruptor, enabling individuals to build web apps using natural language prompts. Beyond the conference halls, CloudFest embraced a "work hard, play hard" mentality, offering attendees the chance to unwind at themed social events and explore Europa Park's attractions. The event fostered meaningful conversations, not just at booths but throughout the venue and during informal gatherings. As CloudFest 2025 wrapped up, it left attendees with a wealth of insights and connections. The discussions on AI, cloud infrastructure, and the evolving landscape of the industry will undoubtedly continue to resonate, setting the stage for next year's event. For FastNetMon, the event was an opportunity to engage with the community and explore new avenues for collaboration and growth in the ever-evolving world of cloud and network security. We are looking forward to attending the conference next year! ![](https://fastnetmon.com/wp-content/uploads/2025/03/CloudFest-2025-Conference-Hall-FastNetMon-1024x561.jpeg)--- ## About FastNetMon FastNetMon delivers versatile DDoS detection software for companies at any scale. With extensive experience in the telecom, mobile, and cloud computing industries, we take pride in preventing DDoS attacks and protecting our customers’ networks to the highest standard. Read more at [fastnetmon.com](https://fastnetmon.com/). **Categories:** Events, Press & Newsroom **Tags:** events --- ### [CO.ZA domains disrupted by a DDoS attack](https://fastnetmon.com/2025/03/24/co-za-domains-disrupted-by-a-ddos-attack/) **Published:** March 24, 2025 **Author:** FastNetMon **Content:** A major DDoS attack hit South Africa’s CO.ZA domain services, leaving businesses and users unable to access websites linked to the country’s most widely used domain. The ZA Registry Consortium confirmed that the issue was triggered by an unprecedented system load that impacted secondary domains under their management. Some industry stakeholders questioned whether this was a direct DDoS attack or an internal infrastructure failure, but either way, the consequences were significant. **What went wrong?** According to ZARC, the issues began on 6 March 2025, with CO.ZA being the most affected of the domains they manage. The organisation explained that extraordinary traffic spikes overwhelmed its nameservers, triggering built-in DDoS mitigation mechanisms. This all led to difficulty resolving domains, slowing access, or making some websites completely unreachable One of the biggest concerns raised by the industry was ZARC’s infrastructure setup. Reports indicated that CO.ZA relied on just three nameservers, with only one using an anycast-based system—an approach that raised questions about whether the system was prepared to withstand high-traffic events. **How DDoS attacks target DNS systems** Attackers overwhelm nameservers with a flood of requests, pushing them to their limits and making it impossible to resolve domain names. When DNS servers buckle under the strain, websites that rely on them become unreachable, even if their hosting infrastructure is working fine. Whether caused by an attack or an unexpected surge in traffic, the result was the same—widespread disruption. **Lessons from the CO.ZA Disruption** Many businesses use DNS as the backbone of their online operations. Even a brief outage can disrupt services, frustrate customers, and lead to lost revenue. A strong, well-distributed DNS infrastructure keeps websites and applications accessible, no matter what happens. Network admins and DNS operators need to prepare for both sudden traffic spikes and targeted attacks, to stay ahead of cyber threats. Resilient infrastructure, built-in redundancy, and proactive monitoring are the best defence. --- ## About FastNetMon FastNetMon delivers versatile DDoS detection software for companies at any scale. With extensive experience in the telecom, mobile, and cloud computing industries, we take pride in preventing DDoS attacks and protecting our customers’ networks to the highest standard. Read more at https://fastnetmon.com/ **Categories:** FastNetMon Blog **Tags:** DDoS Attacks --- ### [Event Recap: CLNOG 2025](https://fastnetmon.com/2025/03/21/event-recap-clnog-2025/) **Published:** March 21, 2025 **Author:** FastNetMon **Content:** On 21 March 2025, we had the pleasure of attending [CLNOG 2025](https://eventos.nog.lat/event/28/), held in Santiago, Chile. This event brought together network operators and industry experts from across the region, highlighting Chile's role as a key hub of network connectivity in Latin America. It was a fantastic opportunity to be part of this vibrant community. The event kicked off with a warm welcome from Patricia Peña of ISOC Chile, who introduced CLNOG's objectives and projects. The agenda featured a range of insightful presentations, including Vinicius Esteves from Netflix discussing their CDN strategies, and Ariel Weher from LACNOG sharing updates on their initiatives. Our own CTO, Pavel Odintsov, took the stage to present on DDoS detection and mitigation techniques. His session covered the latest strategies for recognising and countering denial-of-service attacks, providing valuable insights to attendees. Watch the presentation on [our YouTube channel](https://youtu.be/T3CYmYR9ZYQ), or find the presentation slides [here](https://fastnetmon.com/presentation/)! Following a brief break, the programme continued with Hugo Salgado from Tucows Domains discussing the 2026 DNS root key rollover, a critical topic for maintaining internet security. The day concluded with a "Peer & Beer" session, offering a relaxed environment for networking and conversation over drinks. It was a great chance to connect with peers and discuss the day's learnings. We are grateful to the organisers, speakers, and attendees for making CLNOG 2025 happen. We look forward to future opportunities to contribute to the community, and meet again soon! --- ## About FastNetMon FastNetMon delivers versatile DDoS detection software for companies at any scale. With extensive experience in the telecom, mobile, and cloud computing industries, we take pride in preventing DDoS attacks and protecting our customers’ networks to the highest standard. Read more at <https://fastnetmon.com/> **Categories:** Events, Press & Newsroom **Tags:** events --- ### [Event Recap: Red Button DDoS Day 2025](https://fastnetmon.com/2025/03/24/event-recap-red-button-ddos-day-2025/) **Published:** March 24, 2025 **Author:** FastNetMon **Content:** Last Thursday, March 20th, we had the privilege of attending Red Button’s DDoS Day 2025, an exclusive event hosted at the iconic House of Lords in the United Kingdom. As DDoS attacks grow in number and complexity, this gathering brought together cybersecurity professionals to discuss the latest developments and explore strategies for maximising protection. This was the second DDoS Day in London organised by [Red Button](https://www.red-button.net/), and it was at least equally enjoyable as the first one! The event featured a series of insightful talks from industry leaders. Paddy McGuinness, former UK Deputy National Security Adviser, opened with a keynote addressing the misconception of DDoS attacks as low-tech criminal activities and their use by hostile states. He stressed the importance of national resilience and reducing vulnerabilities. Manish Arora from Cloudflare shared insights into DDoS attack trends, revealing the largest recorded attack on their network, which peaked at 5.6 Tbps. Sebastien Ceuterickx of Proton discussed the challenges of maintaining on-premise infrastructure to withstand sophisticated DDoS attacks, sharing valuable lessons from his decade of experience. Andrey Slastenov from Gcore explored the dynamic landscape of modern DDoS threats and presented a spectrum of defence strategies. Ziv Gadot, CEO of Red Button, addressed the rising threat of Account Takeover (ATO) attacks, providing insights into distinguishing them from DDoS incidents. Finally, Gili Birchat El, Director of DDoS Services at Red Button, highlighted best practices for enhancing DDoS defence. Key takeaways from the event included the rapid growth of DDoS and ransomware as common cyber threats, with over 80 nation states developing offensive cyber capabilities. The rise of DDoS-as-a-Service has made launching attacks easier, while AI-powered DDoS attacks are becoming more sophisticated and harder to mitigate. Motivations behind DDoS attacks include competitor sabotage, state-sponsored attacks, and unhappy customers. The average DDoS attack duration in 2024 was 4.9 minutes, emphasising the need for automated detection. Predictions for the future include an increase in hyper-volumetric DDoS attacks due to IoT vulnerabilities and a rise in geopolitical-driven attacks. Multi-layered protection remains key, and while cloud-based solutions are popular, privacy-focused businesses may require on-prem solutions due to strict data regulations. The venue was fantastic, and attendees had the chance to bask in the sunny weather on a terrace facing the Thames during breaks and networking sessions. It was a wonderful opportunity to meet colleagues, connect with new faces, and catch up with old friends in such a picturesque setting. We extend our thanks to the organisers from the Red Button team, speakers, and attendees for making this day insightful and enjoyable. DDoS Day 2025 was truly an valuable experience, offering great perspectives and strategies to combat the ever-evolving threat landscape. As John Tavor from RedButton expressed, If you haven’t faced a DDoS attack yet, it's only a matter of time. Preparation is important, as most operations that rely on online infrastructure are left vulnerable to DDoS if not properly protected. --- ## About FastNetMon FastNetMon delivers versatile DDoS detection software for companies at any scale. With extensive experience in the telecom, mobile, and cloud computing industries, we take pride in preventing DDoS attacks and protecting our customers’ networks to the highest standard. Read more at <https://fastnetmon.com/> **Categories:** Events, Press & Newsroom **Tags:** events --- ### [Azerbaijan state and media infrastructure faces massive DDoS attacks](https://fastnetmon.com/2025/03/10/azerbaijan-state-and-media-infrastructure-faces-massive-ddos-attacks/) **Published:** March 10, 2025 **Author:** FastNetMon **Content:** Azerbaijan has faced a series of massive DDoS attacks targeting state information resources. The country’s digital infrastructure is challenged as the attacks have been disrupting the services and overwhelming systems with a flood of traffic. The Special Communication and Information Security State Service of the Republic of Azerbaijan has been actively working to neutralise these cyberattacks and ensure the continuous operation of state information resources. The DDoS attacks have led to the implementation of measures to filter out malicious traffic. However, in the process of clearing anomalous traffic, some legitimate IP addresses may also be temporarily blocked. Citizens using state information resources have been advised to be aware of potential short-term disruptions as these protective measures are carried out. The nature of DDoS attacks makes them particularly challenging to defend against because they can come from various sources, making it highly tricky to tell apart genuine users from malicious traffic. These attacks come just a few weeks after online resources belonging to the Global Media Group were hit by a large-scale DDoS attack, causing disruptions to websites such as Report.Az, Oxu.Az, Media.Az, Baku.ws, and BakuTV. There were attempts to hack servers and control panels of these sites, and the specialists were labelling the attack as an attempt to capture the servers. There is yet no information on the culprits of the attacks and the potential motive. --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit <https://fastnetmon.com> **Categories:** FastNetMon Blog **Tags:** DDoS Attacks --- ### [A new powerful botnet Eleven11bot discovered](https://fastnetmon.com/2025/03/04/a-new-powerful-botnet-eleven11bot-discovered/) **Published:** March 4, 2025 **Author:** FastNetMon **Content:** A newly identified botnet, Eleven11bot, has emerged as a significant cyber threat, compromising over 80,000 internet-connected devices globally. Nokia Deepfield’s Emergency Response Team (ERT) has reported that this botnet primarily targets security cameras and network video recorders (NVRs), utilising them to launch distributed denial of service (DDoS) attacks. These attacks have notably impacted telecom providers and gaming platforms, causing disruptions that have lasted for several days. Security researchers have highlighted the scale of Eleven11bot, describing it as one of the largest DDoS botnet campaigns since early 2022. The botnet's activity has been traced largely to Iran, with industry analysis indicating that a significant portion of the botnet's IPs are based in the region. This surge in activity coincides with recent economic sanctions imposed on Iran by the U.S. administration. Reports reveal that the majority of the observed IPs are non-spoofable, indicating they originate from genuine, accessible devices. The botnet's expansion strategy includes brute-force attacks on login systems, exploiting weak and default passwords on IoT devices, and specifically targeting certain security camera brands using hardcoded credentials. Additionally, the botnet conducts network scans for exposed Telnet and SSH ports, which are often left unprotected on IoT hardware. For organisations looking to defend against Eleven11bot, several proactive measures are recommended. These include [blocking traffic from known malicious IPs](https://fastnetmon.com/blocklist-filtering/), monitoring network logs for unusual login attempts, and securing IoT devices by changing default passwords, updating firmware, and disabling unnecessary remote access. Implementing DDoS protection and [rate-limiting](https://fastnetmon.com/docs-fnm-advanced/automated-baseline-calculation-with-fastnetmon-advanced/) is also advised to bolster network defences against high-intensity attacks. Security Operations Centres (SOCs), vulnerability management professionals, and threat hunters can track the botnet's live activity by analysing IP data and taking immediate blocking actions based on identified threats. As the Eleven11bot continues to pose a threat, organisations are urged to remain vigilant and adopt DDoS defence measures to protect their networks from this and similar cyber threats. --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit https://fastnetmon.com **Categories:** FastNetMon Blog **Tags:** Botnets --- ### [Prop trading platform E8 Markets hit by DDoS attack](https://fastnetmon.com/2025/02/26/prop-trading-platform-e8-markets-hit-by-ddos-attack/) **Published:** February 26, 2025 **Author:** FastNetMon **Content:** ## What happened? E8 Markets, a well-known name in prop trading, faced a significant DDoS attack over the weekend, leaving traders locked out of their accounts for two days. Even as markets reopened on Monday, some users continued to report access issues, adding to their frustration. Although E8 Markets managed to restore its systems, the impact of the attack was still being felt. The trouble began on Friday, with the attack taking down both the E8 Markets website and its trading platform. On Saturday, the company confirmed they were under a DDoS attack and assured users they were working to secure their systems. They also mentioned ongoing security audits to rule out any additional problems. However, communication from the company was limited, leaving many users feeling left in the dark. ## Why was this DDoS attack so disruptive? DDoS attacks typically overwhelm websites or online services by bombarding them with massive amounts of illegitimate traffic, effectively blocking real users from accessing them. In this case, the attackers went after E8 Markets’ trading platform at a critical time—just as the markets were opening. This meant traders couldn’t manage their positions or execute trades, which could have serious financial implications. Another critical factor with timing is that if the company does not have automated detection and mitigation in place, weekend may end up more catastrophic time for a DDoS incident as there might not be engineers et site to fix the problem fat enough. The attackers used botnets, networks of compromised devices that flood the target with traffic from thousands of different IP addresses. This tactic requires more sophisticated means to block the attack than traditional security measures like IP filtering, as the traffic appears to come from legitimate sources. ## Why are trading platforms prime targets? Trading platforms are increasingly becoming attractive targets for cybercriminals, and this attack on E8 Markets is just the latest example. In recent months, other platforms like Funding Pips and TradeLocker have also faced similar attacks. These platforms are especially vulnerable because even a brief outage can result in substantial financial losses, affecting both traders and the platform itself. Cybercriminals know this, making trading platforms prime targets for disruptive attacks or ransom demands. By taking down trading systems, attackers can cause chaos, disrupt markets, and potentially extort money from the affected companies. --- ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com/) **Categories:** FastNetMon Blog **Tags:** DDoS Attacks --- ### [DDoS Attacks disrupt Italian infrastructure](https://fastnetmon.com/2025/02/20/ddos-attacks-disrupt-italian-infrastructure/) **Published:** February 20, 2025 **Author:** FastNetMon **Content:** Italy recently faced a wave of DDoS attacks that targeted critical sectors, including government institutions, transport networks, and financial services. These attacks, attributed to the Russian hacker collective NoName057(16), caused temporary disruptions but were swiftly mitigated through early detection and response. The offensive began with attacks on local and air transport services, as well as banking institutions like Banca Intesa Sanpaolo and Banca Monte dei Paschi di Siena. The hackers flooded websites with traffic, rendering them inaccessible to users. The following day, the attacks expanded to approximately 20 targets, including key government ministries such as Economy, Foreign Affairs, and Infrastructure, alongside law enforcement agencies like the Carabinieri and Guardia di Finanza. High-profile financial players, including Mediobanca and Nexi, were also affected, as were companies within the arms industry, such as Benelli Armi and Fiocchi Munizioni. The attackers used botnets, networks of hijacked devices, to generate massive amounts of malicious traffic, with the intention of overwhelming servers. While the attacks were momentarily disruptive, security teams acted quickly to minimise their impact. An effective defence in this type of attacks requires real-time traffic analysis and automated mitigation to counteract the overwhelming force of such cyber offensives. --- ## **About FastNetMon** FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit [https://fastnetmon.com](https://fastnetmon.com "https://fastnetmon.com") **Categories:** FastNetMon Blog **Tags:** DDoS Attacks, political --- ### [The impact of the speculated PlayStation DDoS attack](https://fastnetmon.com/2025/02/13/the-impact-of-the-speculated-playstation-ddos-attack/) **Published:** February 13, 2025 **Author:** FastNetMon **Content:** The recent PlayStation Network outage has left many gamers frustrated and seeking answers. The disruption, which began late on February 7 and lasted nearly 24 hours, rendered online gaming services inaccessible for popular titles such as Fortnite, Call of Duty, and Grand Theft Auto. Offline single-player games also faced issues with license verification, adding to the resentment of PlayStation users worldwide. This has reignited discussions around the vulnerabilities of online gaming platforms to DDoS attacks. While Sony has restored services and offered compensation to affected users, the lack of an official explanation has led many to speculate that a DDoS attack was the root cause. DDoS attacks pose a great threat to digital infrastructure, particularly in the gaming industry, where downtime can result in significant financial and reputational damage. DDoS attacks work by overwhelming a network with a flood of traffic, rendering services inaccessible to legitimate users. For gaming platforms like PSN, this can mean a complete halt to online gameplay. This outage disrupted popular games such as Fortnite and Call of Duty, and coincided with key gaming events, so the consequences are huge. In this context, the role of advanced DDoS detection and mitigation solutions becomes increasingly important. And as gaming platforms continue to grow in popularity, the need for effective DDoS protection becomes ever more pressing. ## About FastNetMon FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats. For more information, visit https://fastnetmon.com **Categories:** FastNetMon Blog **Tags:** DDoS Attacks, gaming --- ### [DeepSeek DDoS Attacks Explained - what really happened?](https://fastnetmon.com/2025/02/05/deepseek-ddos-attacks-explained-what-really-happened/) **Published:** February 5, 2025 **Author:** FastNetMon **Content:** DeepSeek, a rising name in artificial intelligence, has faced large-scale DDoS attacks since its reasoning model was released on January 20th. The attack came just as the company was experiencing a surge in popularity, overtaking OpenAI’s ChatGPT as the most downloaded free app on Apple’s App Store. While DeepSeek has since restored access to its V3 and DeepThink (R1) models, its web search functionality remains offline, limiting the platform’s full capabilities. ## What happened? These attacks were not random but appeared to be highly coordinated and strategically executed. The initial waves targeted DeepSeek’s API interface on January 25th, 26th, and 27th, 2025, with each assault lasting about 35 minutes. Attackers employed Network Time Protocol (NTP) and memcached reflection techniques, indicating a level of expertise in exploiting these vulnerabilities. The chat system was also hit on January 20th and 25th, with attacks averaging an hour and using NTP and Simple Service Discovery Protocol reflection. The timing coincided with the release of DeepSeek-R1, suggesting a deliberate attempt to disrupt the launch. When DeepSeek switched its resolving IP address on January 28th, the attackers quickly adapted, launching new attacks on the main domain, API, and chat system. This rapid response reflects a high degree of tactical literacy and professionalism, pointing to a well-planned operation by a skilled team rather than an opportunistic strike. The attackers’ ability to adjust their strategy and maintain pressure on DeepSeek underscores the persistent and evolving nature of cyber threats today. The infrastructure for these attacks was primarily based in the U.S. (20%), the U.K. (17%), and Australia (9%), DeepSeek did not specify any details of the attacks or attackers and has not to date commented on the incidents to the media in detail. AI companies face growing challenges as they scale, and DeepSeek is no exception. Its open-source R1 reasoning model has drawn attention for its affordability and flexibility, driving a surge in interest. But with rising demand comes increased pressure to keep services stable—especially when dealing with targeted cyber threats. As DeepSeek works to restore full functionality, the tech community is paying close attention - not just to its models’ potential, but also to the need for strong security measures against the evolving threat landscape against popular AI applications. --- ## About FastNetMon FastNetMon delivers versatile DDoS detection software for companies at any scale. With extensive experience in the telecom, mobile, and cloud computing industries, we take pride in preventing DDoS attacks and protecting our customers’ networks to the highest standard. **Categories:** FastNetMon Blog **Tags:** DDoS Attacks --- ### [Large Scale Carpet-Bombing DDoS Attacks Targeted Critical Infrastructure in Japan](https://fastnetmon.com/2025/02/05/large-scale-carpet-bombing-ddos-attacks-targeted-critical-infrastructure-in-japan/) **Published:** February 5, 2025 **Author:** FastNetMon **Content:** Recent large-scale carpet-bomb DDoS attacks in Japan have showed the evolving risks facing critical infrastructure. Unlike traditional DDoS attacks that overwhelm specific servers, carpet-bombing targets multiple devices across a network, significantly increasing disruption. The year-end and New Year period saw widespread outages affecting Japan Airlines, major banks like MUFG, Resona, and Mizuho, as well as telecom provider NTT Docomo. According to Trend Micro, at least 300 hijacked IoT devices worldwide participated in 158 attacks on 64 Japanese businesses between December 26 and February 2. These compromised devices, including Wi-Fi routers and webcams, were remotely controlled through command servers, many based overseas. This type of attack spreads across multiple systems, making it difficult to pinpoint the exact entry points and mitigate damage before it spreads. Despite having some DDoS protections in place, many affected businesses found their unprotected servers unable to withstand the attack. As a result, cybersecurity experts, including NTT Data’s Yuu Arai, have advocated for ‘active cyber defense’, which focuses on detecting and neutralising attack sources before they escalate. The Japanese government is already considering legislation to implement such a strategy, demonstrating the urgency of the situation. To understand more in detail what carpet bombing DDoS attacks are, read [this article](https://fastnetmon.com/2023/10/24/rise-of-carpet-bombing-ddos-attacks-and-ways-to-detect-and-defend-against-them-using-fastnetmon-advanced/). The scale and complexity of modern DDoS attacks mean that proactive monitoring and automation are no longer optional. Using with FastNetMon ensures that organisations can respond swiftly, maintain uptime, and reduce the risk of prolonged service disruptions. FastNetMon can be configured to detect and block carpet-bomb attacks using per-hostgroup thresholds. Have a look at [our documentation](https://fastnetmon.com/docs-fnm-advanced/per-hostgroup-thresholds/) to see how this works. --- ## About FastNetMon FastNetMon delivers versatile DDoS detection software for companies at any scale. With extensive experience in the telecom, mobile, and cloud computing industries, we take pride in preventing DDoS attacks and protecting our customers’ networks to the highest standard. Contact us at sales@fastnetmon.com **Categories:** FastNetMon Blog **Tags:** DDoS Attacks --- ### [Aquabot Botnet Exploits Mitel Phone Vulnerability for DDoS Attacks](https://fastnetmon.com/2025/02/04/aquabot-botnet-exploits-mitel-phone-vulnerability-for-ddos-attacks/) **Published:** February 4, 2025 **Author:** FastNetMon **Content:** A new Mirai botnet variant, Aquabot, is making the rounds, exploiting a flaw in Mitel phones to launch DDoS attacks. The vulnerability, CVE-2024-41710, impacts Mitel’s 6800, 6900, and 6900w Series SIP Phones, along with the 6970 Conference Unit, putting affected devices at risk. Although Mitel addressed this issue in July 2024, a proof-of-concept exploit became publicly available in August, leading to active exploitation attempts since early January 2025. Aquabot targets this medium-severity command injection flaw, which allows attackers to execute arbitrary commands during the phone’s boot process. The botnet also exploits other vulnerabilities, including those in Linksys E-series devices, to expand its reach. ## Unique Features of Aquabot Akamai security researchers were the first to spot Aquabot and its unique capabilities. One standout feature is the ‘report\_kill’ function, which notifies a command-and-control server whenever an infected device receives a kill signal. However, no server responses have been observed so far. Aquabot also attempts to conceal its presence by renaming itself to “httpd.x86” and terminating certain processes, such as local shells. ## Distribution and Impact The botnet is reportedly being advertised as a DDoS service on Telegram under names like Cursinq Firewall and The Eye Botnet, offering both layer 4 and layer 7 attack capabilities. This marks the third iteration of the Mirai botnet, which continues to exploit internet-connected devices with inadequate security measures. The persistence of such threats highlights the ongoing challenges in securing IoT devices. Many devices lack proper defences, have reached end-of-life, or are left vulnerable due to default configurations. These factors make them prime targets for botnets like Aquabot to conduct DDoS attacks. --- ## About FastNetMon FastNetMon delivers versatile DDoS detection software for companies at any scale. With extensive experience in the telecom, mobile, and cloud computing industries, we take pride in preventing DDoS attacks and protecting our customers’ networks to the highest standard. **Categories:** FastNetMon Blog **Tags:** Botnets, Vulnerability --- ### [Event Recap - TRNOG 2025](https://fastnetmon.com/2025/01/28/event-recap-trnog-2025/) **Published:** January 28, 2025 **Author:** FastNetMon **Content:** On January 28, 2025, FastNetMon had the privilege of attending the inaugural TRNOG event in Ankara, a significant gathering for the Turkish Network Operators Group. This non-profit community of network engineers is dedicated to advancing the internet in Turkey, providing a platform for sharing knowledge and fostering collaboration. The event was a one-day intensive program featuring presentations and workshops by industry experts on network technologies and internet infrastructure. With over 100 participants, the event brought together a diverse group of individuals, including government regulators, representatives from Türk Telekom, private companies, and other organisations. The vibrant discussions and exchanges of ideas demonstrated the potential of this group to drive forward the internet landscape in Turkey. The agenda was packed with insightful sessions, starting with an opening speech by Chafic Chaya from RIPE NCC and Seher Sağıroğlu from ICANN. Osman Makal provided an overview of the TRNOG community, highlighting its goals and initiatives. Presentations by Alptekin Sunnetci and Ömer Golgeli showcased projects developed under the community, such as RTBH and tools.trnog.net, offering valuable insights into the practical applications of these projects. ![](https://fastnetmon.com/wp-content/uploads/2025/01/Chafic-Chaya-RIPE-NCC-TRNOG-2025-1024x573.jpeg)![](https://fastnetmon.com/wp-content/uploads/2025/01/Seher-Sagiroglu-ICANN-TRNOG-2025-1024x565.jpeg)Seher Sağıroğlu (ICANN) and Chafic Chaya (RIPE NCC) gave the opening speeches at TRNOG2025.Further sessions were delivered by Osman Makal, Alptekin Sunnetci, and Ömer Golgeli about community projects The afternoon sessions included a presentation by Chafic Chaya on the use and future of IPv6 and RPKI in Turkey, followed by Seher Sağıroğlu's talk on the security of the DNS ecosystem and ICANN's role in this area. FastNetMon's own Pavel Odintsov delivered a presentation on DDoS detection and mitigation methods, sharing our expertise and solutions with the audience. The session was well-received, sparking engaging discussions on the importance of robust DDoS defenses in today's digital landscape. You can download the presentation slides and more on [this page](https://fastnetmon.com/presentation/)! ![](https://fastnetmon.com/wp-content/uploads/2025/01/Pavel-Odintsov-TRNOG-2025-FastNetMon-1024x597.jpeg)The event concluded with an open mic session, where attendees had the opportunity to ask questions and share comments. This interactive segment fostered a collaborative atmosphere, encouraging participants to voice their thoughts and contribute to the ongoing dialogue. Overall, TRNOG 2025 was a resounding success, marking the emergence of a vibrant community dedicated to improving the internet in Turkey. FastNetMon is proud to support TRNOG and its initiatives, and we look forward to following the group's developments and contributing to future events. --- ## About FastNetMon FastNetMon delivers versatile DDoS detection software for companies at any scale. With extensive experience in the telecom, mobile, and cloud computing industries, we take pride in preventing DDoS attacks and protecting our customers’ networks to the highest standard. **Categories:** Events, Press & Newsroom **Tags:** events --- ### [Cybercriminals Leverage Zero-Day Vulnerability to Launch AIRASHI DDoS Botnet](https://fastnetmon.com/2025/01/24/cybercriminals-leverage-zero-day-vulnerability-to-launch-airashi-ddos-botnet/) **Published:** January 24, 2025 **Author:** FastNetMon **Content:** Recent reports have revealed a serious network security issue: hackers exploiting a zero-day vulnerability in Cambium Networks cnPilot routers to deploy the AIRASHI variant of the AISURU botnet. This botnet is being used to conduct large-scale DDoS attacks, leveraging a variety of vulnerabilities, including those in AVTECH IP cameras and LILIN DVRs. According to the security researchers at QiAnXin XLab, the AIRASHI botnet has been active since June 2024, with a stable attack capacity of 1-3 Tbps. The botnet primarily compromises devices in Brazil, Russia, Vietnam, and Indonesia, while targeting its attacks towards China, the United States, Poland, and Russia. AIRASHI is an evolved version of the AISURU botnet, incorporating proxyware functionality to extend its capabilities beyond DDoS attacks. The botnet has undergone multiple updates, with the latest versions, AIRASHI-DDoS and AIRASHI-Proxy, introducing new network protocols and enhanced communication methods. AIRASHI-DDoS focuses on DDoS attacks, supporting arbitrary command execution and reverse shell access, while AIRASHI-Proxy adds proxy functionality. This development also aligns with QiAnXin's discovery of alphatronBot, a cross-platform backdoor targeting Chinese government and enterprises. This malware uses a decentralized P2P protocol, enlisting infected systems into a botnet and making it resilient to takedowns. The P2P network comprises over 700 nodes from 80 countries, involving devices like MikroTik routers and Hikvision cameras. Additionally, QiAnXin has detailed a stealthy payload delivery framework called DarkCracks, which exploits compromised GLPI and WordPress sites to function as downloaders and C2 servers. This framework aims to gather sensitive information, maintain long-term access, and use compromised devices as relay nodes, effectively concealing the attacker's footprint. --- ## About FastNetMon FastNetMon delivers versatile DDoS detection software for companies at any scale. With extensive experience in the telecom, mobile, and cloud computing industries, we take pride in preventing DDoS attacks and protecting our customers’ networks to the highest standard. **Categories:** FastNetMon Blog **Tags:** Botnets, threats and vulns --- ### [NoName057(16) target Swiss institutions amid World Economic Forum](https://fastnetmon.com/2025/01/24/noname05716-target-swiss-institutions-amid-world-economic-forum/) **Published:** January 24, 2025 **Author:** FastNetMon **Content:** Swiss institutions have recently been targeted by a series of DDoS attacks orchestrated by the pro-Russian hacker group "NoName057(16)." This collective is known for its strategic overload attacks, aiming to make target servers inaccessible by flooding them with network requests. Since Tuesday, the group has focused its efforts on Swiss institutions, coinciding with the World Economic Forum in Davos, which runs from January 20 to 24. The attacks have been dynamic, with targets shifting from one server to another. Initially, several Swiss banks' websites were rendered unavailable. The group has been openly boasting about these attacks on Telegram, where they maintain a DDoS tracker showing their current targets, including various subdomains of admin.ch, the Swiss government domain. The Swiss Federal Office for Cybersecurity anticipated such attacks during the World Economic Forum, categorizing them as demonstrations by the attackers. The group has reportedly claimed responsibility, stating, "We are continuing to test the resilience of the Swiss Internet infrastructure." NoName057(16) is not new to the scene. Last December, they orchestrated similar attacks against German companies, not for ransom, but as a political statement. The randomness of their target list suggests a broader political agenda beyond financial gain. --- ## About FastNetMon FastNetMon delivers versatile DDoS detection software for companies at any scale. With extensive experience in the telecom, mobile, and cloud computing industries, we take pride in preventing DDoS attacks and protecting our customers’ networks to the highest standard. **Categories:** FastNetMon Blog **Tags:** DDoS Attacks, political --- ### [Institutions in The Netherlands affected by DDoS attacks: Several universities and government login service impacted](https://fastnetmon.com/2025/01/20/institutions-in-the-netherlands-affected-by-ddos-attacks-several-universities-and-government-login-service-impacted/) **Published:** January 20, 2025 **Author:** FastNetMon **Content:** Several Dutch universities and the government login service DigiD have recently been targeted with DDoS attacks. The connection between the incidents is not clear nor the culprit of the attacks have been published. Last Friday, January 17th 2025, a major DDoS attack disrupted the joint network of Dutch universities, applied sciences universities, university hospitals, and research institutes, causing significant internet connectivity issues. This attack, which began around 8:20 a.m., affected institutions across the country and followed similar attacks earlier in the week that had already compromised the internet services of higher education institutions. The fault-detection site Allestorningen reported widespread internet issues in student cities including Amsterdam, Eindhoven, Groningen, Leiden, Tilburg, Utrecht, and Zwolle. The Technical University Eindhoven (TU/e), severely impacted by these disruptions, announced plans to resume classes after the weekend, with a commitment to catch up on the backlog over the coming weeks. In a separate but equally disruptive incident, the DigiD system, essential for accessing a wide range of government services, fell victim to a large-scale DDoS attack on Tuesday, January 14th 2025. This attack targeted the company called Logius that manges the DigiD system, paralysing the Logius-managed servers for over five hours. The attack prevented access to critical services including the tax office, local government offices, and health insurers. Both systems have been successfully restored from what was reported as exceptionally high-volume attack. --- ## About FastNetMon FastNetMon delivers versatile DDoS detection software for companies at any scale. With extensive experience in the telecom, mobile, and cloud computing industries, we take pride in preventing DDoS attacks and protecting our customers’ networks to the highest standard. **Categories:** FastNetMon Blog **Tags:** DDoS Attacks --- ### [FastNetMon Advanced 2.0.352](https://fastnetmon.com/2023/10/26/fastnetmon-advanced-2-0-352/) **Published:** October 26, 2023 **Author:** FastNetMon **Content:** Our latest release includes several updates to enhance your DDoS cover. We’ve added options for future TLS support for FastNetMon Flow, improved debugging with more detailed logs, and added logic to reconnect TCP flow forwarding sockets. We’ve also enabled IPv6 for Web\_api\_host and Web\_api\_ssl\_host, and added a per hostgroup dashboard for Clickhouse. Full release notes below Changes: - Added options tera\_flow\_tls\_certificate\_path and tera\_flow\_tls\_private\_key\_path for future TLS support for FastNetMon Flow - We require SSE42 for all new installations. Clickhouse is a mandatory part of stack now - Added logic to retry bind attempt for TCP socket in FastNetMon Flow logic when it's already in use as we have it normally very often - Added logic to check that certificates were generated before enabling SSL for Grafana and Nginx - Added logic to reconnect TCP flow forwarding sockets - Automatically crop long process names to 15 symbols - Added flag MSG\_NOSIGNAL to avoid calls of SIGPIPE when remote flow forwarder TCP socket was closed for some reasons - We switched from write() to send() as it allows use to use flags argument when we need it - Disabled export of InfluxDB and Clickhouse metrics to system\_counters if they are not enabled in configuration - Removed configuration option netflow\_custom\_sampling\_ratio\_enable as we never checked it and used netflow\_sampling\_ratio unconditionally - Added logic to print recalculate\_speed\_timeout and average\_calculation\_time to log file for clarity and easier debugging - Added better logic to handle empty password for MongoDB - Addressed Cannot get CPU flags - Added timeout for send operation for Flow Forwarder - Added new options flow\_forwarder and flow\_forwarder\_remote\_addresses - Added logic to read FastNetMon Flow messages when it spans over multiple recv() calls - Allowed IPv6 for Web\_api\_host and Web\_api\_ssl\_host - Unconditionally enabled IPv6 for tera flow for traffic\_db logic - Added new options to setup FastNetMon Flow to listen addresses explicit way: tera\_flow\_local\_addresses - Added logic to install certbot for Let's encrypt - Added check that port 443 is available - Added per protocol total traffic counters export to InfluxDB - Added per protocol total counters exposed via API - Unified traffic calculation logic for total counters - Eliminated instant speed array for total traffic counters - Added logic to free up memory in sFlow socket init logic - Fixed bug in host\_counters\_per\_hostgroup\_v4 and host\_counters\_per\_hostgroup\_v6 API call - Reworked fcli and internal API to use unified enum sorters - New commands sudo fcli show host\_counters\_per\_hostgroup\_v4 and host\_counters\_per\_hostgroup\_v6 to return top talkers per total hostgroup - Behaviour change. We flipped incoming and outgoing for per ASN traffic reports - Added logic to generate default configuration for GoBGP even when we do not have any BGP peers provided in configuration - Added per hostgroup dashboard for Clickhouse - Enabled total hostgroups logic by default enable\_total\_hostgroup\_counters - Added fill\_dictionaries to cron on RedHat based distros - Added automatic run of fill\_dictionaries command during installation and every day via cron - Split Grafana data source provision to use fastnetmon-clickhouse.yaml and fastnetmon.yaml - Added ASN number after ASN name for Clickhouse ASN dashboard - Replaced ASN description parsing logic by download from our site - Removed BGP table processing logic and removed dependency on libbgpdump - Added logic to download prefix to ASN dictionaries instead of processing whole dataset directly. fill\_dictionaries is x100 times faster now - Added r8152 for automatic offload configuration **Categories:** Releases **Tags:** release, releases --- ### [FastNetMon Advanced 2.0.353](https://fastnetmon.com/2023/10/31/fastnetmon-advanced-2-0-353/) **Published:** October 31, 2023 **Author:** FastNetMon **Content:** FastNetMon's latest release brings several product enhancements to improve your DDoS detection and mitigation. We've added TLS support for FastNetMon Flow TLS agent and server, reworked capnp serialization logic, and improved debug logging for IPFIX. We've also enabled netflow\_sampling\_cache for Netflow v9 and IPFIX by default to avoid traffic gaps after tool restart. For a full list of updates, see below. Changes - Added TLS support for FastNetMon Flow TLS agent - Reworked capnp serialization logic - Added logic to change password in Grafana data source provision file for Clickhouse - Extracted Clickhouse provision logic to separate file - Switched default ban time from 1900 to 675 per\_host and 771 for total hostgroups - Added TLS support for FastNetMon Flow server - Enabled netflow\_sampling\_cache for Netflow v9 and IPFIX by default. It helps to avoid traffic gaps after tool restart - Less verbose Clickhouse - Reworked sampling decoder logic for Netflow v9 - Improved debug logging for IPFIX **Categories:** Releases **Tags:** release, releases --- ### [FastNetMon Advanced 2.0.354](https://fastnetmon.com/2023/11/01/fastnetmon-advanced-2-0-354/) **Published:** November 1, 2023 **Author:** FastNetMon **Content:** FastNetMon's latest release brings several improvements to our IPFIX and Netflow v9 logic. We've migrated away from be\_copy\_function in IPFIX logic, reworked IPFIX sampling logic, and addressed a bug with 2 byte sampling rate decoder in Netflow v9 for Cisco specific encoding format. See below the full list. Changes: - Migrated away from be\_copy\_function in IPFIX logic and removed this function - Added pcap for Juniper IPFIX sampling rate encoding to test suite - Reworked IPFIX sampling logic which used IPFIX\_SAMPLING\_PACKET\_INTERVAL encoding - Reworked Juniper Netflow v9 sampling decoding logic to explicitly use 2 and 4 byte encoding - Addressed bug with 2 byte sampling rate decoder in Netflow v9 for Cisco specific encoding format. Bug caused abnormal traffic counter values and was introduced in 2.0.353 **Categories:** Releases **Tags:** release, releases --- ### [FastNetMon Advanced 2.0.355](https://fastnetmon.com/2023/11/14/fastnetmon-advanced-2-0-355/) **Published:** November 14, 2023 **Author:** FastNetMon **Content:** FastNetMon's latest release brings several enhancements to your DDoS protection. We've added logic to store source and destination MAC addresses in Clickhouse, reworked our sFlow counters logic, and added IPv6 support for Clickhouse access. We've also introduced a new dashboard to show top talkersper network and added new fields for API and fcli command hostgroup\_counters\_total. See below the full list of updates. Changes: - Added logic to explicitly export IP length in FastNetMon Flow - Added logic to store source and destination MAC addresses in Clickhouse - Reduced excessive logging for traffic\_db and added migration schema for srcMac and dstMac - Behaviour change for Clickhouse traffic and traffic\_db. Removed check for existence of fields inputInterface, outputInterface and agentIpAddress as they were introduced in release 2.0.72 and 2.0.100. If you have no such fields traffic\_db fill fail. Removed check for default value for packetDateTime - Changed traffic\_db logic to exit with failure when we cannot connect to Clickhouse - Reworked sFlow counters logic to use on demand conversion to endianless - Reworked logic to parse sFlow counter samples - Reworked sFlow plugin to use class instead of tuples for counters - Moved counters for libsflow to use plain classes - Switched all non modifying pointer operations to const - Added separate counter sflow\_expanded\_counter\_sample to track expanded counters samples - Added logic to save IPv4 and IPv6 per ASN counters to disk - Fixed names for persistent counter store from speed\_counters\_total to speed\_counters\_total.dat. - Added logic to save per\_interface\_ipv4\_device\_counters to disk too - Added serialize for device\_address\_ipv4\_and\_interface\_id\_t - Added logic to save per /24 network counters to disk - Better log for sFlow plugin - Added suffix \_outgoing for fcli output of sudo fcli show baseline\_per\_host when outgoing was requested explicitly - Added IPv6 support for Clickhouse access for show baseline\_per\_host - Added logic to fix build on machines with system Boost - FerretDB upgrade - Added BGP Flow Spec logic to enable Flow Spec on hostgroup basis using flag enable\_bgp\_flow\_spec - Added global configuration parameter flow\_spec\_per\_hostgroup\_management which delegates BGP Flow Spec control to per hostgroup basis instead of using globally enabled logic. - Fixed alignment - Moved logic to read default\_flow\_spec\_v6\_action outside of flow spec block - Moved logic to read default\_flow\_spec\_v4\_action outside of flow spec block - Improved documentation for bgp\_flow\_spec\_default\_action - Allowed only TLSv1.2 TLSv1.3 for Nginx - Added logic to show how many packets sFlow device discarded - Added logic to track dropped packets for sFlow protocol - Added new dashboard to show top talkers per network - Added new fields for API and fcli command hostgroup\_counters\_total: incoming\_packets\_tcp\_syn, outgoing\_packets\_tcp\_syn, incoming\_bytes\_tcp\_syn, outgoing\_bytes\_tcp\_syn **Categories:** Releases **Tags:** release, releases --- ### [FastNetMon Advanced 2.0.356](https://fastnetmon.com/2023/11/19/fastnetmon-advanced-2-0-356/) **Published:** November 19, 2023 **Author:** FastNetMon **Content:** FastNetMon's latest update brings significant improvements to our top hosts dashboard, now using a pre-calculated top hosts table for faster performance. We've also added a new flag to export top hosts to Clickhouse tables, improved our Clickhouse table creation logic, and reduced excessive logging in our Netflow and IPFIX plugin. Changes: - Upgraded top hosts dashboard to use pre calculated top hosts table. Significant speed improvement is expected - Added flag clickhouse\_metrics\_export\_top\_hosts to export top hosts to Clickhouse tables host\_metrics\_ipv4\_top and host\_metrics\_ipv6\_top - Extracted database creation logic into separate database - Improved Clickhouse table creation logic - Reduced excessive logging about Decoded algorithm in Netflow and IPFIX plugin **Categories:** Releases **Tags:** release, releases --- ### [FastNetMon Advanced 2.0.357](https://fastnetmon.com/2023/12/28/fastnetmon-advanced-2-0-357/) **Published:** December 28, 2023 **Author:** FastNetMon **Content:** FastNetMon's latest release introduces several enhancements to improve your network security. We've added a new capability to filter traffic inline using XDP, upgraded MongoDB to 7.0 for Debian 12, and added support for multi-set TCP flags in BGP Flow Spec mode. We've also incorporated scrubbing\_services\_integration into our official packages and added logic to upgrade Grafana. For a full list of updates, see below. Changes: - - Added new capability to [filter traffic inline](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-xdp-filter/) using XDP capability - Added logic to reset Grafana password for Clickhouse in Grafana cache - Switched to use for FerretDB on Debian 12 when we have no AVX - Switched to use FerretDB for Debian 11 when we have no AVX. - Upgraded MongoDB to 7.0 for Debian 12 - Added logic to unconditionally load tzdata and avoid need to load it from filesystem - Added installer function to reset password for Clickhouse: -reset\_clickhouse\_password - Added missing logic to update Flow Spec rules on disk when we automatically unblock BGP Flow Spec rule. - Extracted flow spec ban logic to separate function - Added capability to configure filtering mode using option filter\_xdp\_mode which can be set to skb, driver, hardware - Extracted libbpf workaround to dedicated file - Added logic to switch MongoDB to FerretDB when we have no AVX support - Added FerretDB support for RedHat family - Upgrade FerretDB to 1.16 - Added support for field NETFLOW9\_LAYER2\_PACKET\_SECTION\_SIZE 103 used by Cisco Catalyst 4500 in their Netflow lite implementation - Disabled logic which installs our own kernel headers for relatively new Linux distros as it makes more harm for us - Upgraded bpf to bpf 1.0.1 and ported AF\_XDP plugin to new version - Added support for mutli-set TCP flags in BGP Flow Spec mode: syn\|ack - Made Flow Spec encoding reader from JSON more strict. It will return error when we cannot parse some field - Fixed bug with keep\_blocked\_hostgroups\_during\_restart - Added complete logic to save blocked hostgroups to persistent storage: keep\_blocked\_hostgroups\_during\_restart - Added configuration option app\_packet\_sr\_tunnel\_traffic to decode GRE for Nokia SR Shim mode - Completely working unban\_only\_if\_attack\_finished for total hostgroups with static and flexible thresholds support - Added complete logic to configure all fields for scrubbing management - Adding support for plugin scrubbing\_services\_integration - Added clarity for messages when we cannot retrieve license from licensing server over IPv4 and then we do Ipv6 fallback - Incorporated scrubbing\_services\_integration into official packages - Added logic to upgrade Grafana when we install it to address issue with Grafana is not running **Categories:** Releases **Tags:** release, releases --- ### [FastNetMon Advanced 2.0.358](https://fastnetmon.com/2024/01/15/fastnetmon-advanced-2-0-358/) **Published:** January 15, 2024 **Author:** FastNetMon **Content:** FastNetMon's latest release brings several enhancements to improve your network security. We've added logic to export flexible counters for hostgroups and individual hosts to Clickhouse, and enabled per protocol metrics for InfluxDB and Clickhouse by default. We've also updated our traffic dashboards to the latest version and added documentation for the IPFIX\_FRAGMENT\_IDENTIFICATION IPFIX field. For a full list of updates, see below. Changes: - Added logic to export flexible counters for total hostgroups to Clickhouse - Added logic to export per host flexible counters to Clickhouse - Added per protocol counters field for tables network\_metrics and network\_metrics\_ipv6. Please drop them manually in Clickhouse to migrate to new schema - Removed version checking logic for Clickhouse host\_metrics as it was deprecated in 2.0.208 - Added logic to export per protocol counters for hostgroups - Added logic to populate per protocol counters for ASNs - Enabled per protocol metrics for InfluxDB by default. Removed configuration option influxdb\_per\_protocol\_counters - Enabled by default per protocol counters for Clickhouse and removed configuration option clickhouse\_metrics\_per\_protocol\_counters - Added logic to remove saved total, ASN, per interface, per /24 network counters during upgrade - Explicitly disabled exceptions for std::filesystem::remove to avoid potential crashes when removal fails - Added logic to cleanup hostgroup\_blocks.dat dump during upgrade - Added documentation about IPFIX\_FRAGMENT\_IDENTIFICATION IPFIX field - Added workaround to for MongoDB configuration installation on Debian 12 - Updated traffic dashboards to latest version - Fixed error reporting for MongoDB errors **Categories:** Releases **Tags:** release, releases --- ### [FastNetMon Advanced 2.0.371](https://fastnetmon.com/2025/01/13/fastnetmon-advanced-2-0-371/) **Published:** January 13, 2025 **Author:** FastNetMon **Content:** FastNetMon Advanced 2.0.371 has been released with significant updates. We've added logic to handle padding in IPFIX plugin, improved checks in IPFIX and Netflow v9 logic, and added support for IPFIX enterprise fields used by Arista. We've also implemented multiple options templates reading in IPFIX packets, added detailed logging for data templates parsing, and ensured correct reading of sampling rates. The release also includes fixes for issues in IPFIX template logic and additional sanity checks. Changes: - IPFIX plugin, added logic to gracefully handle padding on the end of data set. Previously it caused following error: Attempt to read data after end of flowset. Offset: 0 record length: 4 flowset\_maximum\_length: 2 - Reversed order of checks in IPFIX and Netflow v9 logic for forwarding status detection for Juniper reported by Samuel K. Lam - Added sanity checks for IPFIX variable length encoding - Added support for IPFIX enterprise fields used by Arista - Implemented logic to read multiple options templates in IPFIX packets. Implemented logic to detect padding on the end of IPFIX options template set - Reworked ipfix\_data\_set\_header\_t to generic ipfix\_set\_header\_common\_t to unify logic and reduce number of duplicated structures - Fixed issues that ipfix\_variable\_length\_elements\_used was accidentally set to all templates in SET even if just one had it. Extracted logic to read IPFIX template into dedicated function, ongoing refactoring - Rename ipfix\_flowsets\_with\_anomaly\_padding to ipfix\_sets\_with\_anomaly\_padding as part of getting rid non RFC compliant naming - Moved away from endian-less conversions in IPFIX logic - Added enterprise\_bit and enterprise\_number for IPFIX and Netflow v9 templates - Additional sanity checks for IPFIX template logic. Added explicit length check for enterprise numbers - Added explicit IPFIX structures length checking. - Extracted IPFIX set processing to function process\_ipfix\_sets - Added detailed logging to trace how we parse multiple data templates - Added test for Cisco 315 with multiple flows exported - Added logic to ensure that we read sampling rates correctly and added check that number of flows read correctly - Added test coverage for Nokia which sends data and template templates in same packet - Added logic to test when data and options template is carried in single packet - Typos reported by Patrick Matthai - Added information to show sequence of IPFIX packet for easier debugging - Added FastNetMon daemon dependency on network-online.target to ensure that network is configured and Internet connection is available, more details: <https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/> **Categories:** Releases **Tags:** release, releases --- ### [Case Study: A leading mobile carrier enhancing network security with FastNetMon blocklist-based filtering](https://fastnetmon.com/2025/01/13/case-study-a-leading-mobile-carrier-enhancing-mobile-network-security-with-fastnetmon-blocklist-based-filtering/) **Published:** January 13, 2025 **Author:** FastNetMon **Content:** [Case study - FastNetMon block list based filtering in telecommunications](https://fastnetmon.com/wp-content/uploads/2025/01/Case-study-FastNetMon-Block-list-based-filtering-in-mobile-network-telecommunications.pdf)[Download](https://fastnetmon.com/wp-content/uploads/2025/01/Case-study-FastNetMon-Block-list-based-filtering-in-mobile-network-telecommunications.pdf) ## Background A leading global telecommunications company, with a significant presence in Ireland, faced increasing challenges in managing threats across its expansive mobile network. The company required a robust solution to effectively block malicious traffic and protect its network and customers. ## Challenge The telecommunications industry is a prime target for cyber threats, including malware, phishing attacks, and other malicious activities. Cyber attacks can be extremely damaging for telecommunications companies as they operate extensive network infrastructures that, if disrupted by a cyber attack, can lead to widespread service outages affecting a large number of customers. Additionally, an attack can compromise sensitive customer data, resulting in reputational damage and potential regulatory fines for data breaches. The company was looking to mitigare these risks and as a part of the solution, needed to block malicious and illegitimate traffic in their mobile network. The goal was to find a solution that could seamlessly integrate with their existing infrastructure. ## Solution The company chose FastNetMon for its reliable and flexible [blocklist-based filtering capabilities](https://fastnetmon.com/blocklist-filtering/). FastNetMon's ability to support a wide range of blocklist formats, including those stored on Amazon S3-based storage and accessible via HTTP or HTTPS protocols, made it an ideal choice for the telecommunications provider. FastNetMon's system works by downloading all the data from the configured blocklist, which includes IP addresses identified as sources of malicious activities. This data is then used to configure the company’s routers through a special BGP daemon process, which announces the blocklist information, effectively blocking clients in their network from connecting to these malicious hosts. ## Implementation The implementation process involved setting up FastNetMon to regularly receive updates from selected external intelligence feed providers. These providers specialize in identifying and tracking various types of online threats, ensuring that the blocklists are continuously updated with the latest threat data. Once integrated, FastNetMon continuously monitors the blocklists for any new or updated entries. If changes were detected, the system automatically updated the internal list and announced the new blocked hosts to the routers. This dynamic approach allowed the company to adapt quickly to emerging threats and maintain a high level of network security. ## Results The deployment of FastNetMon significantly strengthened the company’s approach to network security in their Irish mobile network operations. The blocklist-based filtering system proved highly effective in blocking access to and from malicious hosts, significantly reducing the incidence of security breaches. The flexibility of FastNetMon to handle multiple blocklist formats and its compatibility with various intelligence feed providers enabled the company to achieve comprehensive threat coverage. This proactive security measure ensured that both the network and its customers were safeguarded against a wide array of cyber threats the unblocked malicious traffic produces. ## Conclusion FastNetMon has provided the telecommunications company with a simple but powerful blocklist-based filtering tool to enhance their threat detection and prevention capabilities. The ease of integration, combined with the ability to manage multiple blocklists simultaneously, has positioned FastNetMon as a critical component of the company’s cybersecurity strategy in Ireland. This case study demonstrates the effectiveness of FastNetMon in a large-scale enterprise scenario, highlighting its potential for other companies in the telecommunications sector. Read more about the blocklist-based filtering here: <https://fastnetmon.com/blocklist-filtering/> --- ## About FastNetMon FastNetMon delivers versatile DDoS detection software for companies at any scale. With extensive experience in the telecom, mobile, and cloud computing industries, we take pride in preventing DDoS attacks and protecting our customers’ networks to the highest standard. Get in touch at sales@fastnetmon.com **Categories:** Case studies, Press & Newsroom **Tags:** case study --- ### [New Mirai botnet targeting industrial routers with zero-day exploits](https://fastnetmon.com/2025/01/13/new-mirai-botnet-targeting-industrial-routers-with-zero-day-exploits/) **Published:** January 13, 2025 **Author:** FastNetMon **Content:** A new Mirai-based botnet that targets industrial routers has emerged. This botnet, discovered in February last year, has been growing in sophistication and now leverages previously unknown vulnerabilities, according to researchers at Chainxin X Lab. One of the key security issues is CVE-2024-12856, a vulnerability in Four-Faith industrial routers. This flaw was discovered in late December, but exploitation attempts were noticed around December 20. The botnet also uses custom exploits for unknown vulnerabilities in Neterbit routers and Vimar smart home devices. Currently, the botnet has 15,000 daily active bot nodes, primarily in China, the United States, Russia, Turkey, and Iran. Its main objective appears to be carrying out DDoS attacks on specified targets for profit. It targets hundreds of entities daily, with activity peaking in October and November 2024. The malware uses a mix of public and private exploits for more than 20 vulnerabilities to spread to internet-exposed devices. It targets DVRs, industrial and home routers, and smart home devices, including ASUS and Huawei routers, LB-Link routers, PZT cameras, Kguard DVR, Lilin DVR, and various 5G/LTE devices. The botnet also features a brute-forcing module for weak Telnet passwords, uses custom UPX packing with unique signatures, and implements Mirai-based command structures for updating clients, scanning networks, and conducting DDoS attacks. X Lab reports that the botnet’s DDoS attacks are short in duration, lasting between 10 and 30 seconds, but high in intensity, exceeding 100 Gbps in traffic, which can cause disruptions even for robust infrastructures. To protect their devices, users are advised to install the latest device updates from the vendor, disable remote access if not needed, and change the default admin account credentials. --- ## About FastNetMon FastNetMon delivers versatile DDoS detection software for companies at any scale. With extensive experience in the telecom, mobile, and cloud computing industries, we take pride in preventing DDoS attacks and protecting our customers’ networks to the highest standard. **Categories:** FastNetMon Blog **Tags:** Botnets, threats and vulns --- ### [Mobile operator NTT Docomo affected by a DDoS attack](https://fastnetmon.com/2025/01/06/mobile-operator-ntt-docomo-affected-by-a-ddos-attack/) **Published:** January 6, 2025 **Author:** FastNetMon **Content:** NTT Docomo, Japan's largest mobile operator was recently hit by a DDoS attack. On January 2nd, 2025 the company experienced significant network congestion from 05:27 to 16:10, impacting key services like the "goo" web portal, Lemino video streaming, dpay billing service, and "Golf me" golf-round service. This disruption affected nearly 90 million subscribers and highlights the growing intensity and frequency of cyber threats facing global telecom networks. This incident is part of a broader trend, as evidenced by a report from Stormwall noting a 102% increase in DDoS attacks globally in the first half of 2024 compared to the previous year. Additionally, Nokia's research indicates a surge in attacks on telecom networks, escalating from one or two per day in mid-2023 to over 100 daily in some cases by mid-2024. Telecommunications companies, with their critical infrastructure and massive user base, are particularly susceptible to such disruptions. The low tolerance for outages in this sector not only affects service availability but can also have broader economic impacts. This incident did not affect mobile phone services directly, but the disruption to additional services is a stark reminder of the need for robust anti-DDoS measures in the Telecommunications sector. --- ## About FastNetMon FastNetMon delivers versatile DDoS detection software for companies at any scale. With extensive experience in the telecom, mobile, and cloud computing industries, we take pride in preventing DDoS attacks and protecting our customers’ networks to the highest standard. **Categories:** FastNetMon Blog **Tags:** DDoS Attacks --- ### [Surge in FICORA and CAPSAICIN botnet activity: Old D-Link vulnerabilities exploited in global attacks](https://fastnetmon.com/2024/12/28/surge-in-ficora-and-capsaicin-botnet-activity-old-d-link-vulnerabilities-exploited-in-global-attacks/) **Published:** December 28, 2024 **Author:** FastNetMon **Content:** Cybersecurity researchers have reported a surge in malicious activity involving the exploitation of old D-Link router vulnerabilities by two different botnets, FICORA and CAPSAICIN. These botnets spread through documented D-Link vulnerabilities that allow remote attackers to execute malicious commands via the Home Network Administration Protocol (HNAP) interface. The FICORA botnet attacks have targeted various countries globally, deploying a downloader shell script from a remote server, which then downloads the main payload for different Linux architectures. The botnet malware includes a brute-force attack function and features to conduct distributed denial-of-service (DDoS) attacks using UDP, TCP, and DNS protocols. On the other hand, CAPSAICIN primarily targets East Asian territories like Japan and Taiwan. It leverages a different IP address and follows a similar approach to fetch the botnet for various Linux architectures. CAPSAICIN establishes a connection socket with its command-and-control server, sending the victim host's OS information and the nickname given by the malware back to the server. It then awaits further commands to be executed on the compromised devices, including various malicious operations. Despite these vulnerabilities being exposed and patched nearly a decade ago, these attacks remain active worldwide. This highlights the importance of regular kernel updates and comprehensive monitoring for all enterprises to ensure network security. --- ## About FastNetMon FastNetMon delivers versatile DDoS detection software for companies at any scale. With extensive experience in the telecom, mobile, and cloud computing industries, we take pride in preventing DDoS attacks and protecting our customers’ networks to the highest standard. **Categories:** FastNetMon Blog **Tags:** Botnets, threats and vulns --- ### [Delays and cancellations as JAL suffers a DDoS attack](https://fastnetmon.com/2024/12/27/delays-and-cancellations-as-jal-suffers-a-ddos-attack/) **Published:** December 27, 2024 **Author:** FastNetMon **Content:** Japan Airlines, Japan's flag carrier, recently fell victim to a cyber attack that led to the cancellation or delay of dozens of flights. The attack, which targeted the airline's network infrastructure, also caused the temporary suspension of ticket sales for both domestic and international flights. The attack began on December 26th at 7:24 a.m. local time when the company identified an issue with a router that links its infrastructure to other organizations' networks. The router was shut down about 90 minutes later as part of the airline's efforts to remediate the cyber attack. It is reported that the router likely have been targeted by a Distributed Denial-of-Service (DDoS) attack. DDoS attacks aim to disrupt systems by overwhelming them with malicious network requests, often targeting external-facing network devices such as routers. In this case, the airline confirmed that there was no customer data leakage or further damage, suggesting that the attackers did not install malware on the router. This incident at Japan Airlines highlights the growing threat of DDoS attacks in the aviation industry. It follows a similar disruption at American Airlines, which had to delay flights due to a networking issue. As these attacks become more frequent and sophisticated, it is crucial for companies to invest in robust cybersecurity measures, including DDoS detection and mitigation solutions. --- ## About FastNetMon FastNetMon delivers versatile DDoS detection software for companies at any scale. With extensive experience in the telecom, mobile, and cloud computing industries, we take pride in preventing DDoS attacks and protecting our customers’ networks to the highest standard. **Categories:** FastNetMon Blog **Tags:** DDoS Attacks --- ### [Juniper Networks alerts: Mirai botnet scans and exploits SSR devices for DDoS](https://fastnetmon.com/2024/12/26/juniper-networks-alerts-mirai-botnet-scans-and-exploits-ssr-devices-for-ddos/) **Published:** December 26, 2024 **Author:** FastNetMon **Content:** ​​Juniper Networks has issued a critical alert regarding a Mirai botnet that is actively scanning the internet for Session Smart routers (SSR) using default credentials. The Mirai malware, notorious for its role in large-scale DDoS attacks, exploits devices with default login credentials to execute commands remotely, thereby enabling a range of malicious activities. The campaign was first detected on December 11, 2024, when compromised routers were identified on customer networks. These infected devices were subsequently used to launch DDoS attacks, leveraging the compromised routers' capabilities. Juniper's security advisory highlights several indicators of compromise that administrators should monitor. These include scans for devices on common Layer 4 ports, failed login attempts on SSH services indicative of brute-force attacks, sudden spikes in outbound traffic, devices rebooting or behaving erratically, and SSH connections from known malicious IP addresses. To combat this threat, Juniper advises customers to immediately change default credentials on all SSR devices to unique and strong passwords, keep firmware updated, review access logs for anomalies, set alerts for suspicious activity, deploy intrusion detection systems to monitor network activity, and use firewalls to block unauthorized access to internet-exposed devices. Additionally, routers already infected must be reimaged before being brought back online to ensure the complete removal of the malware. --- ## About FastNetMon FastNetMon delivers versatile DDoS detection software for companies at any scale. With extensive experience in the telecom, mobile, and cloud computing industries, we take pride in preventing DDoS attacks and protecting our customers’ networks to the highest standard. Find out more: <https://fastnetmon.com/> **Categories:** FastNetMon Blog **Tags:** Botnets, threats and vulns --- ### [New DDoS Malware cShell Targets Poorly Managed Linux SSH Servers](https://fastnetmon.com/2024/12/25/new-ddos-malware-cshell-targets-poorly-managed-linux-ssh-servers/) **Published:** December 25, 2024 **Author:** FastNetMon **Content:** The AhnLab Security Intelligence Center (ASEC) has recently discovered a new strain of DDoS malware, called cShell, that is specifically targeting poorly managed Linux SSH servers. This malware exploits weak SSH credentials and leverages Linux tools to execute sophisticated DDoS attacks. The initial access and infection process involves scanning publicly exposed SSH services and employing brute force techniques to gain access. Once inside, the attackers use commands to install tools like curl and a malware strain called cARM. The malware installs itself in the /etc/de/cARM directory and uses a configuration file named sshell.service to register as a persistent service via the systemctl command. This ensures the malware remains active even after the system reboots. Unlike traditional DDoS bots, cShell relies on existing Linux utilities screen and hping3 to execute the attacks. Screen is a utility for managing multiple terminal sessions, allowing tasks to run in the background even if the terminal is closed. Hping3 is a packet generation and analysis tool used for network diagnostics. cShell exploits its ability to send TCP, UDP, and ICMP packets for various DDoS attack types. cShell was created using the Go programming language and includes an update function. It gets instructions via interacting with a command-and-control (C&C) server. The malware also connects to multiple Pastebin URLs during its update process to download the latest version of itself using curl. This redundancy ensures continued operation even if some C&C servers are taken down. Administrators managing Linux servers are urged to take proactive measures to defend against such threats. These include using strong, unique passwords for SSH accounts and changing them regularly, keeping systems updated with the latest security patches, deploying firewalls and other security tools to restrict unauthorized access, monitoring server activity for unusual behavior or unauthorized installations, and updating antivirus solutions like V3 to block malware infections proactively. Poorly secured Linux systems remain prime targets for attackers seeking to build botnets for DDoS campaigns. By implementing stringent security measures, administrators can mitigate risks and protect their infrastructure from exploitation. --- ## About FastNetMon FastNetMon delivers versatile DDoS detection software for companies at any scale. With extensive experience in the telecom, mobile, and cloud computing industries, we take pride in preventing DDoS attacks and protecting our customers’ networks to the highest standard. Find out more: <https://fastnetmon.com/> **Categories:** FastNetMon Blog **Tags:** threats and vulns --- ### [FastNetMon Advanced 2.0.368](https://fastnetmon.com/2024/11/26/fastnetmon-advanced-2-0-368/) **Published:** November 26, 2024 **Author:** FastNetMon **Content:** This release includes a new option for AF\_PACKET to unpack GTPv1 tunnels: af\_packet\_extract\_gtp\_v1\_tunnels, support for new forwardingStatus 4 byte encoding which is used by Cisco ASR9006 with IOS XR 6.4.2, a complete multi-user support for API via users\_configuration and roles\_configuration sections, see the full list of changes below! Changes: - Complete multi user support for API via users\_configuration and roles\_configuration sections (see documentation [here](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-api-user-control/)) - Improved log messages Traffic buffer size for IPv6 is too small to accommodate whole traffic calculation period. Please increase traffic buffer size to add more details - Added logic to use source\_asn and destination\_asn for filtering for Flow Spec mode and Flow Spec white list - Added source\_asns and destination\_asns to JSON representation of Flow Spec announces - Added logic to return ipv4\_nexthops for sudo fcli show flowspec - Added new option for AF\_PACKET to unpack GTPv1 tunnels: af\_packet\_extract\_gtp\_v1\_tunnels - Implemented API for sudo fcli show blackhole uuid - Switched protocol version to lowercase in blackhole details - Added command sudo fcli show blackhole UUID to show basic information about attack - Behaviour change: removed legacy fields attack\_type, initial\_attack\_power, peak\_attack\_power, attack\_protocol, attack\_direction for attack callbacks, MongoDB and POST callbacks - Behaviour change: removed legacy fields in attack notifications average\_incoming\_traffic, average\_incoming\_traffic\_bits, average\_outgoing\_traffic, average\_outgoing\_traffic\_bits, average\_incoming\_pps, average\_outgoing\_pps, average\_incoming\_flows, average\_outgoing\_flows - Removed legacy fields attack\_direction and attack\_power from attack details information - Behaviour change: we reworked logic for attack direction and attack power in PPS arguments for legacy Bash callback scripts to use modern approach for calculations - Added logic to calculate number of flows we keep in storage for TCP, UDP, ICMP and other protocols and exposed them via system counters - Added new metrics for TCP, UDP, ICMP flow tracking structures - Added new counters entries\_flow\_tracking\_tcp\_ipv4, entries\_flow\_tracking\_udp\_ipv4, entries\_flow\_tracking\_icmp\_ipv4 - Renamed counter entries\_flow\_tracking to entries\_flow\_tracking\_ipv4 - Added support for new forwardingStatus 4 byte encoding which is used by Cisco ASR9006 with IOS XR 6.4.2 See this release on [GitHub](https://github.com/FastNetMon/fastnetmon-advanced-releases/releases/tag/v2.0.368) **Categories:** Releases **Tags:** release, releases --- ### [FastNetMon Addresses Critical Vulnerabilities in Netflow and sFlow Plugins](https://fastnetmon.com/2024/12/20/fastnetmon-addresses-critical-vulnerabilities-in-netflow-and-sflow-plugins/) **Published:** December 20, 2024 **Author:** FastNetMon **Content:** FastNetMon has successfully resolved two critical vulnerabilities in the Netflow and sFlow plugins of its product. The vulnerabilities were identified by an independent security researcher on December 12th 2024, and have since been patched. The vulnerabilities, discovered through a methodology known as fuzzing, had the potential to allow remote attackers to cause crashes of the FastNetMon daemon using specially crafted UDP packets. Upon receiving the report, FastNetMon was able to replicate the issues in a lab environment and confirmed that all versions of the product were affected. FastNetMon promptly addressed these vulnerabilities by pushing fixes for both the sFlow v5 and Netflow v9 plugins, effectively closing the ability to exploit these vulnerabilities. A full code review was also conducted, and additional logic was implemented to prevent similar issues from occurring in the future. On December 16th, 2024, FastNetMon released an out-of-schedule security update, version 2.0.370, which included the security fixes. The company strongly recommends all customers to upgrade to this version as soon as possible. The upgrade guide can be found [here](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-upgrade-procedure/). FastNetMon remains committed to providing its customers with a secure and reliable DDoS solution. For more information, please contact our customer support at support@fastnetmon.com **Categories:** Press & Newsroom **Tags:** Press Releases --- ### [FastNetMon Advanced 2.0.360](https://fastnetmon.com/2024/02/20/fastnetmon-advanced-2-0-360/) **Published:** February 20, 2024 **Author:** FastNetMon **Content:** In our recent update, we've introduced the ability to calculate speed in parallel and added precise profiling for each part of the speed calculation process. We've also reworked the logic for top k speed counters and remote IP speed retrieval. We've merged data and speed counters for a speed calculation process that's approximately 1.74 times faster. Additionally, we've added the capability to specify next hop for host and subnet IPv4 announces independently and split blackhole logic for IPv4 and IPv6. We've also introduced new API queries and added options to control the number of returned elements. Lastly, we've fixed a bug with mixed prefix lengths in Mikrotik integration. Full details below. Changes: - Introduced PoC ability to calculate speed in parallel - Added very precise profiling for each part of speed calculation process and exported it via system\_counters - Reworked logic which returns top k speed counters via API - Added comparator class to compare elements stored in unified storage with speed and traffic - Migrated traffic increment logic for ipv4\_remote\_host\_counters, ipv4\_network\_counters, ipv6\_network\_counters to use unified methods - Reworked remote IP speed retrieval logic to standard API function - Merged data and speed counters to use single std::unordered\_map element for both of them. Expected speed up for speed calculation process is around 1.74 times - Upgraded both traffic-database-ipv4 and traffic-database-ipv6 dashboards to fix duplicate AND in SQL query - Added capability to specify next hop for host and subnet IPv4 announces independently using gobgp\_next\_hop\_host\_ipv4 and gobgp\_next\_hop\_subnet\_ipv4 - Split blackhole logic for IPv4 and IPv6 to two different functions - Added API queries asn\_counters\_bulk\_v4 and asn\_counters\_bulk\_v6 to export whole structure of ASN counters - Added option to control number of returned via API elements using max\_elements parameter for host\_counters\_v6, host\_counters, host\_counters\_per\_hostgroup\_v4, host\_counters\_per\_hostgroup\_v6, remote\_host\_counters - Added query variable to set number of entries which can be returned by asn\_counters\_v4 and asn\_counters\_v6: max\_elements - Added option to pass number of arguments via query parameter - Added logic to install version of installed Grafana from installer log output - Added logic to explicitly create folders for provisioned files - Fixed bug with mixed prefix lengths for IPv4 and IPv6 in Mikrotik integration. We had /128 for IPv4 and /32 for IPv6 which is completely incorrect **Categories:** Releases **Tags:** release, releases --- ### [27 DDoS-for-hire platforms shut down](https://fastnetmon.com/2024/12/11/27-ddos-for-hire-platforms-shut-down-major-breakthrough-from-operation-poweroff/) **Published:** December 11, 2024 **Author:** FastNetMon **Content:** ## Major breakthrough from Operation PowerOFF In a sweeping international effort, law enforcement agencies from 15 countries have successfully dismantled 27 DDoS-for-hire services, commonly referred to as "booters" or "stressers." These platforms, which utilize botnets on compromised devices, enable paying customers to launch disruptive DDoS attacks against selected online targets. This operation, known as 'Operation PowerOFF,' was coordinated by Europol and marks a significant stride in the global fight against cybercrime. The crackdown resulted in the arrest of several administrators who operated these illicit platforms and the identification of 300 users of these services. Notably, websites such as zdstresser.net, orbitalstress.net, and starkstresser.net were among those taken down, now displaying seizure notices to visitors. In the Netherlands, the Dutch police played a crucial role, arresting four men aged between 22-26. These individuals are now facing prosecution, with one accused of conducting 4,169 DDoS attacks, while the others carried out hundreds. Additionally, approximately 200 people in the Netherlands suspected of using these services have been identified. Many will receive direct warnings, either through letters or officer visits, and some will face prosecution based on the scale of their activities. Europol has emphasized that the success of these operations was greatly aided by its analytical support, crypto-tracing, and various forms of forensic investigation provided by specialists at the Joint Cybercrime Action Taskforce (J-CAT). Adding to the momentum, just last month, Operation PowerOFF delivered another significant blow to the DDoS-for-hire ecosystem with the [seizure of Dstat.cc](https://fastnetmon.com/2024/11/05/german-police-shuts-down-ddos-service/), one of the largest platforms of its kind, and the arrest of two suspects closely linked to it. This ongoing series of actions sends a clear message about the international community's resolve to combat cyber threats and protect digital spaces. --- ## About FastNetMon FastNetMon delivers versatile DDoS detection software for companies at any scale. With extensive experience in the telecom, mobile, and cloud computing industries, we take pride in preventing DDoS attacks and protecting our customers’ networks to the highest standard. Find out more: <https://fastnetmon.com/> **Categories:** FastNetMon Blog **Tags:** legal --- ### [Danish Municipality Websites Down with a DDoS attack](https://fastnetmon.com/2024/12/11/danish-municipality-websites-down-with-a-ddos-attack/) **Published:** December 11, 2024 **Author:** FastNetMon **Content:** Several Danish municipalities recently fell victim to Distributed Denial of Service (DDoS) attacks, disrupting the websites of cities including Vejle, Albertslund, Dragør, Esbjerg, Frederiksberg, and Frederikshavn. The director of the Danish Cybersecurity Centre (CFCS), Mark Fidel, reported that such attacks are often carried out by pro-Russian cyber-activists, who regularly target Denmark. The purpose of these attacks, according to Fidel, is to draw attention to the hackers' actions, often choosing symbolic targets connected to Denmark's support for Ukraine. While the CFCS managed to prevent a number of potential attacks, in some cases, some damage was unavoidable. The CFCS continues to work on addressing the aftermath of these attacks and strengthening defenses against similar threats. This incident underscores the importance of robust cybersecurity measures and the need for constant vigilance against potential threats. The attacks were reported first by The Copenhagen Post. --- ## About FastNetMon FastNetMon delivers versatile DDoS detection software for companies at any scale. With extensive experience in the telecom, mobile, and cloud computing industries, we take pride in preventing DDoS attacks and protecting our customers’ networks to the highest standard. Find out more: <https://fastnetmon.com/> **Categories:** FastNetMon Blog **Tags:** political --- ### [FastNetMon Advanced 2.0.362](https://fastnetmon.com/2024/03/13/fastnetmon-advanced-2-0-362/) **Published:** March 13, 2024 **Author:** FastNetMon **Content:** Our latest release includes a complete logic to reload per host hostgroups without a FastNetMon restart. We've improved IPv6 hostgroup lookup performance and added explicit logic to avoid complex JSON crafting operations. We've also added several counters to measure time required for various procedures. We've made significant improvements in our threshold checking logic and extracted some generic code for better organization. We've also added a new option for adding multiple communities to configuration and upgraded FerretDB. Check out the full list of updates below. Changes: - Complete logic to reload per host hostgroups without FastNetMon restart with sudo fcli set reload\_hostgroups - Moved hostgroup loading logic to fastnetmon\_host\_group\_configuration\_parser - Hide internals of hostgroup\_lookup\_t by using private - Added notes about potential options to improve flexible counters calculation - Improved IPv6 hostgroup lookup performance by eliminating expensive memory copy - Added explicit logic to avoid complex JSON crafting operations in max talkers, attack samplers and hostgroup sampling logic - Added counter hostgroup\_traffic\_samples\_calculation\_time to measure time required to create per hostgroup samples - Added counter attack\_traffic\_samples\_calculation\_time to measure time required for attack sampling procedure - Added counter max\_talkers\_per\_hostgroup\_accumulation\_time to track accumulation time as it's very lengthy too - Switched to new logic for checking if we should block IPv4 host or not. It features up to 2.5 speed up. It was accomplished by eliminating not needed memory copy - Added function to lookup hostgroup and check thresholds in same time - Extracted threshold checking logic into separate file - Extracted some generic code from fast\_libraries to fastnetmon\_integers, fastnetmon\_networks and fastnetmon\_strings - Extracted thresholds evaluation logic into separate library - Removed duplicate checks to skip ban action if it disabled on hostgroup basis as we have it in we\_should\_ban\_this\_entity - We decided to do bold move and duplicate speed\_calculation\_callback\_local\_ipv4\_universal into two independent functions. We have lots of condition sections which make almost half of source code for it. I think it's right move and as independent functions they will be easier to deal with - Improved design per hostgroup lookup logic - Exposed Sensitive flag for fields API - Added -demo for fastnetmon\_client to hide real IP addresses - Added new option gobgp\_communities\_host\_ipv6 which allows adding multiple communities to configuration - Upgrade FerretDB from 1.16.0 to 1.20.1 - Added new fcli and API endpoint to return all networks which belong to particular ASN: fcli show asn\_networks 269872 - Increased precision of system\_counters for API from 3 to 6 digits after point - Make XDP filter less verbose - Added logrotate for MongoDB to address flooded logs - Changed MongoDB configuration - Switched logRotate configuration from rename to reopen: <https://www.mongodb.com/docs/manual/reference/configuration-options/#mongodb-setting-systemLog.logRotate> to make possible logrotation using Linux logrotate **Categories:** Releases **Tags:** release, releases --- ### [FastNetMon Advanced 2.0.364](https://fastnetmon.com/2024/04/04/fastnetmon-advanced-2-0-364/) **Published:** April 4, 2024 **Author:** FastNetMon **Content:** Our latest update introduces new BGP peering configuration options, allowing for more control over add path logic. We've also added the ability to override default values in hostgroup configurations. Additionally, we've introduced new controls for IPv6 Flow Spec redirect. See all updates below! Changes: - Added warning message to log when capacity of traffic buffer is not enough to accommodate generate\_hostgroup\_traffic\_samples\_delay or generate\_attack\_traffic\_samples\_delay - Added BGP peering configuration options ipv4\_unicast\_add\_path and ipv6\_unicast\_add\_path to control add path logic with 8 routes for each prefix - When you specify single value in bgp\_next\_hops\_subnet\_ipv4, bgp\_next\_hops\_host\_ipv4, bgp\_next\_hops\_subnet\_ipv6, bgp\_next\_hops\_host\_ipv6 for hostgroup it overrides default value in configuration - Introduced gobgp\_flow\_spec\_v4\_redirect\_target\_as, gobgp\_flow\_spec\_v4\_redirect\_target\_community, gobgp\_flow\_spec\_v6\_redirect\_target\_as, gobgp\_flow\_spec\_v6\_redirect\_target\_community to control IPv6 Flow Spec redirect **Categories:** Releases **Tags:** release, releases --- ### [FastNetMon Advanced 2.0.365](https://fastnetmon.com/2024/04/26/fastnetmon-advanced-2-0-365/) **Published:** April 26, 2024 **Author:** FastNetMon **Content:** Changes: Multiple improvements for licensing logic **Categories:** Releases **Tags:** release, releases --- ### [FastNetMon Advanced 2.0.369](https://fastnetmon.com/2024/11/27/fastnetmon-advanced-2-0-369/) **Published:** November 27, 2024 **Author:** FastNetMon **Content:** Changes: Fixed bug with endpoints total\_traffic\_counters\_v4 and total\_traffic\_counters\_v6 which did not work and required not needed parameters **Categories:** Releases **Tags:** release, releases --- ### [BGP Blackhole Automation for DDoS mitigation](https://fastnetmon.com/2026/01/06/bgp-blackhole-automation-for-ddos-mitigation/) **Published:** January 6, 2026 **Author:** FastNetMon **Content:** In this article, we will discuss how the routing infrastructure, more specifically the BGP routing technique called “blackholing”, can provide efficient mitigation for DDoS attacks. We will go through some key concepts, and explain how to set up and manage a RTBH (Remotely Triggered Black Hole), and highlight the advantages and disadvantages of the technique. ## What exactly is a BGP Black Hole? A BGP Black Hole is a routing technique that serves as an effective and affordable method for mitigating DDoS attacks. As the name suggests, “blackholing” network traffic makes it disappear without a trace, which is a very desirable outcome to malicious traffic. Let’s discuss more into detail how this works. To put it simply, BGP black hole works by discarding the traffic, by routing it to a Null 0 (aka Null Route) within your network. The Null Route acts as a “black hole” where packets are discarded - without transmitting a status notification to the sender about the failed delivery. From the attacker's perspective, this "black hole" is virtually invisible within the network, making it highly efficient for DDoS mitigation. ## Black Hole Automation, RTBH, sRTBH, what’s the difference? Starting off with definitions: RTBH (Remote Triggered Black Hole) and Black Hole Automation, or Black Hole Routing are essentially the same methodology, and many vendors and operators use the terms interchangeably. For the ease of reading, we will use the term RTBH in this post. When we refer to RTBH we mean that we block traffic to / from hosts in our own network. We basically unplug our own services from the Internet. It’s very important to remember it as many engineers expect that it will drop traffic from the attacker side which is not the case. Slightly different, and much less commonly used methodology is sRTBH (Source-based Remote Triggered Black Hole). sRTBH is similarly a BGP-based traffic filtering methodology, but instead of simply triggering a RTBH, sRTBH would involve blocking the source of the traffic. ## The brief history of BGP black hole filtering BGP, which is the fundamental protocol that connects the Internet together, has been used for over 15 years as a core anti-DDoS tool. Up until the early 2000’s, DDoS attacks were fended of fairy manually: When a network anomaly was detected, the network engineer would first investigate and confirm whether the incident was in fact a DDoS attack. They would then manually trigger a black hole response, either by accessing the router, or by informing the ISP/network provider to start discarding the traffic. Finally, the engineer would resume the normal routing, or notify the ISP once again when the attack has ceased. Considering the current environment, this sounds hopelessly too slow and unreliable procedure, but it still is the standard approach in mitigating DDoS attacks in many organisations. As the attacks grew more commonplace and network uptime requirements more critical in many services, this same process was automated for faster response times, which led to the development of RTBH automation. With automation, the network engineers can set up specific rules on when to trigger the black hole, what to do with the blackholed traffic and what happens after. ## Why is RTBH so efficient? The key advantage of using remotely triggered black hole in DDoS mitigation is the factor that it is implemented with the assistance from all your network upstreams and their upstreams. The implementation has the full filtering capabilities of larger Internet service providers, making it basically unlimited in volume. Let’s look at a practical example how this typically unfolds in real attack situation. In this case, we have a sizable DDoS attack of 100G towards a network with three carriers and two IXPs: ![](https://fastnetmon.com/wp-content/uploads/2024/12/Diagram-how-BGP-Blackhole-filtering-works.gif)Now let’s zoom in to one of the carriers and demonstrate how we’re triggering the RTBH. The 40 Gbits of malicious traffic are coming from their 3 ISPs: ![](https://fastnetmon.com/wp-content/uploads/2024/12/DDoS-attack-mitigation-with-BGP-blackhole-2.gif)The traffic is black-holed at the upstream, and this same mechanism happens on all of the carriers of the attacked network, and their ISPs. At some point of this propagation, the filtering gets close to the source of the attack itself, and will remove attack's traffic from all intermediate ISPs as it will be dropped shortly after it was sent by attacker. ## Key considerations before configuring RTBH Now that we understand the background of the methodology, let’s discuss some of the key considerations on automating a RTBH. One of the advantages of RTBH is its flexibility, as you can configure it as simple or as complicated as you want. There are a few considerations you want to think of before configuring your RTBH: First, you need to decide which routers you will apply your policies on. To set up a RTBH, it's necessary to filter traffic at the key points within your infrastructure. You'll probably want to establish RTBH policies for routers that maintain direct connections with your transit providers or peers, as it's not desirable to let illegitimate or attack traffic through more than necessary on your network. And of course, for the use of RTBH, the routers you choose must be compatible with BGP and offer a basic implementation of routing policy. Second, you’ll need to decide on the thresholds when you want to trigger the black hole automation, and how you want to deactivate the RTBH policy. For example, you can set up a certain volume-based threshold when the policy is triggered, and time based rule to deactivate. Finally, you need to decide what to do with the discarded traffic. There are several options to forward the traffic to a scrubbing centre, or to block completely. ## Configuring your RTBH When choosing how to set up your RTBH configuration, most network engineers opt to use a software such as [FastNetMon](https://fastnetmon.com/) to avoid several manual steps to set up and maintain. FastNetMon provides a complete integration, email alert system and automated unblocking, and detects attacks in less than 5 seconds. However, to understand how RTBH is typically set up from scratch, here’s a comprehensive explanation: Configuring Remote Triggered Black Hole (RTBH) involves setting up a trigger that sends iBGP updates to its peers, setting the next hop for a network or host to a predetermined unused IP address. The trigger can be any device that runs BGP, not necessarily a router. For redundancy, it's recommended to have multiple regionalised triggering devices, each protected by dual power supplies. To contain the iBGP routing updates used to trigger black holes at the network edge, there are three recommended methods: using BGP communities, setting an extra community for the prefix used in the trigger advertisement, and using an egress prefix filter with eBGP peers. Once the trigger advertisement is sent to the iBGP peers, it's important to ensure that the peers prefer this route to one that they already have for the destination network. This can be achieved by setting a local-preference value greater than the default value of 100 and setting the origin to igp. The edge routers drop suspicious traffic by forwarding it to a Null0 interface. A static route is configured at the edge, and the next hop is set to Null0. The edge router receives an iBGP route update, which sets the next hop of the destination under attack to this static route. All future traffic to the destination is dropped at the edge because the next hop to the destination under attack is equated to Null0. It's recommended that when a Null0 interface is created at the edges, the ICMP unreachable message is disabled for this interface. If ICMP unreachable messages are not disabled, it's strongly recommended that they be rate-limited so they will not flood the network. RTBH filtering is typically deployed by configuring iBGP on the provider edge and a new triggering device at the NOC. The trigger maintains an iBGP peering relationship with all the edge routers or with all the route reflectors in the ISP environment. Manual entry of the static route is done on the trigger as well as setting all the necessary characteristics such as the next hop, local preference, and BGP communities. ## Final considerations RTBH is a very efficient methodology to defend against volumetric attacks due to its capacity to use the filtering capacity of larger ISP’s. Setting up a functional RTBH implementation does require an in-depth understanding in BGP implementations across different vendors, but this is where FastNetMon comes in. Read more how our black hole automation works here: https://fastnetmon.com/bgp-blackhole-automation/ Every DDoS mitigation methodology comes with its own set of advantages and drawbacks. For instance, a DDoS attack could be specifically engineered to compel an ISP to black hole a customer. The attack could be designed to inflict collateral damage on neighbouring customers, forcing the network to respond with a remote-triggered black hole, thereby cutting off the legitimate customer's traffic. The issue here is that the black hole is precisely what the attacker intended - to eliminate the customer's ability to receive traffic. Because of this limitation, it is essential to have a variety of mitigation tools at your disposal rather than relying solely on blackholing. Visit our website to learn more about the various techniques you have available on just one installation of FastNetMon: <https://fastnetmon.com/> --- ## About FastNetMon FastNetMon delivers versatile DDoS detection software for companies at any scale. With extensive experience in the telecom, mobile, and cloud computing industries, we take pride in preventing DDoS attacks and protecting our customers’ networks to the highest standard. Find out more: <https://fastnetmon.com/> **Categories:** FastNetMon Blog, Featured **Tags:** Blackhole --- ### [Evolution of Network Layer DDoS attacks](https://fastnetmon.com/2024/12/06/evolution-of-network-layer-ddos-attacks/) **Published:** December 6, 2024 **Author:** FastNetMon **Content:** Despite being one of the oldest types of cyberattacks, Distributed Denial of Service attacks still remain the most common cyber threat for organisations. Over the course of years, the attackers' aim has not changed: to overwhelm and disrupt online services, rendering them inaccessible to legitimate users. However, over the past decade, DDoS attacks have evolved significantly in terms of size and impact. We constantly hear reports of “record-breaking DDoS attacks”, and the frequency of this news seems to have increased within the last months. In this article, we will have a critical look at the development of network layer DDoS attacks, and asses have the attacks actually increased, and in what way. ## Measuring network layer DDoS attacks To measure the scale and impact of network layer DDoS attacks, we typically use two metrics: packets per second (pps) and bits per second (bps). Packets per second (pps) represent the number of individual packets sent to the target per second, regardless of their size. This metric is critical for network-layer attacks (Layers 3 and 4), where the attacker aims to overwhelm network infrastructure by exceeding its packet-processing capacity. Bits per second (bps) measures the total data transferred per second. This metric is especially useful in evaluating network-layer attacks that aim to saturate the bandwidth of the target or its upstream provider. Another relevant way of measuring a DDoS attack is requests per second (rps). This is a particularly relevant metric for application layer (L7) attacks. However, for the sake of focusing on network-layer attacks (L3 and L4), we will leave this metric out of scope in this article. ## Exponential growth of L3 and L4 attacks Over the last decade, DDoS attacks have grown exponentially in size. In terms of bits per second (bps), In the early 2010’s it was typical to measure large attacks in Gigabits per second (Gbps) scale. These days, significant attacks are reported in Terabits per second (Tbps). The change in measurement scale gives some indication of the change in volumes. How about the largest reported attacks? The growth in attack sizes seems to be linear, but the frequency of record-breaking DDoS reports has certainly increased. In the chart below we have listed the publicly reported attacks, which gives an indication of the development, even though many attacks are likely going unreported and therefore not providing the full picture. ![](https://fastnetmon.com/wp-content/uploads/2024/12/Record-Breaking-DDoS-Attacks-1024x522.png)Some of the publicly available data from Google and Cloudlfare indicate the same direction of development. Historical data from Google reveals a rising trend in bits per second during DDoS attacks observed between 2010 and 2022. This increase highlights a significant escalation in attack volume across the decade. Data from Cloudflare regarding large mitigated DDoS attacks observed in 2023 and 2024 shows a similar escalation. The rate of packets per second (pps) demonstrates a slight exponential growth over time, rising from 230 Mpps in 2015 to 2,100 Mpps in 2024. For bits per second (bps), the trend is also exponential and with a steeper upwards curve, building from a 309 Gbps attack in 2013 to a 5.6 Tbps (5,600 Gbps) attack in 2024. As a conclusion, it is safe to say network layer attacks have seen significant increase. Based on publicly available data, over the last decade attacks driving these metrics have grown 10-20 fold: Bits per second increased by 20x between 2013 and 2024, and Packets per second increased by 10x between 2015 and 2024. Additionally, the devices used for DDoS attacks, the attack vectors, and the duration of attacks have also evolved over time. We will explore these aspects in more detail in subsequent blog posts, providing a deeper understanding of the changing landscape and how organisations can better protect themselves. --- ## About FastNetMon FastNetMon delivers versatile DDoS detection software for companies at any scale. With extensive experience in the telecom, mobile, and cloud computing industries, we take pride in preventing DDoS attacks and protecting our customers’ networks to the highest standard. Find out more: <https://fastnetmon.com/> **Categories:** FastNetMon Blog **Tags:** Network Security Insights --- ### [DDoS capabilities installed in 240 000 satellite receivers by manufacturer](https://fastnetmon.com/2024/12/04/ddos-capabilities-installed-in-240-000-satellite-receivers-by-manufacturer/) **Published:** December 4, 2024 **Author:** FastNetMon **Content:** The Korean National Police Agency has arrested the CEO and five employees of a South Korean company for a peculiar cybercrime. The company has been manufacturing and exporting a large number of satellite receivers with embedded Distributed Denial of Service (DDoS) attack capabilities. The arrest followed a tip-off from Interpol in July, when the case picked the interest of international law enforcement. The receivers were allegedly enhanced with DDoS functionalities at the request of a foreign entity specialising in illegal broadcasting. This entity, which remains unidentified, reportedly sought DDoS functionalities to counter-attack DDoS activity from a competing illegal broadcaster. South Korean National Police Agency reported that the devices were either pre-installed with malware or modified via firmware updates after export. The relationship between the South Korean manufacturer and the foreign entity dates back to 2017, demonstrating a long-standing partnership. The malicious capabilities were added to the satellite receivers in November 2018. The DDoS functionalities were embedded directly into the receivers, effectively disguising them as ordinary broadcasting equipment. The modifications enabled the devices to launch cyberattacks on command, exploiting their distribution in networks of unsuspecting users. From January 2019 to September 2024, the manufacturer shipped 240,000 satellite receivers, 98,000 of which had a DDoS module pre-installed, and the rest had a firmware update after delivery. This case serves as a stark reminder of the potential for any device to be weaponised for DDoS, with users of these satellite receivers involuntarily participating in attacks and potentially experiencing reduced device performance during these occurrences. In response to these illegal activities, a South Korean court authorized the seizure of the company’s assets and the confiscation of $4.35 million, the revenue reportedly earned from selling the malicious satellite receivers. An international arrest warrant has also been issued for a foreign buyer linked to the client firm, which is considered a key player in orchestrating the illegal activities surrounding the DDoS-capable satellite receivers. --- ## About FastNetMon FastNetMon delivers versatile DDoS detection software for companies at any scale. With extensive experience in the telecom, mobile, and cloud computing industries, we take pride in preventing DDoS attacks and protecting our customers’ networks to the highest standard. Find out more: <https://fastnetmon.com/> **Categories:** FastNetMon Blog **Tags:** legal --- ### [FastNetMon Advanced 2.0.367](https://fastnetmon.com/2024/10/10/fastnetmon-advanced-2-0-367/) **Published:** October 10, 2024 **Author:** FastNetMon **Content:** FastNetMon has released a new update with several enhancements and bug fixes. The update includes added logic for storing unban actions in MongoDB, a fix for a bug in the Graphite plugin, and changes in BGP Flow Spec mitigation logic. We've also deprecated certain fields and improved the logic for crafting IPv4 BGP attributes. Please note, Ubuntu 16.04, Debian 9 and 10 have been deprecated and removed from releases. See the full list below! - Changes: - Added new type string for system\_counters and exposed FastNetMon version - Added logic to store unban actions to attacks collection in MongoDB - Fixed bug that clickhouse\_metrics\_push\_period was used in Graphite plugin instead of correct graphite\_push\_period - Change in BGP Flow Spec mitigation logic: DF (don't fragment) can be combined with other fragmentations flags. Previously if we had DF flag then we set only it and ignored all other fragmentation flags - Added export for ip\_dont\_fragment, ip\_more\_fragments, ip\_fragment\_offset fields for packet dump - Added logic to remove source and destination ports when flow spec rules has is-fragment flag. We do it for Arista due to their hardware limitations. It can be enabled using flag flow\_spec\_strip\_ports\_for\_fragmented\_traffic - Deprecated field attack\_protocol for JSON callbacks and explicitly set it to unknown value. Please use threshold names for attack protocol detection instead - Deprecated fields peak\_attack\_power and initial\_attack\_power for JSON callback and set them to zeroes. Please use per protocol counters instead - Manually set field attack\_type for JSON based attack notifications to unknown as this logic was broken and we're deprecating it - We stopped populating fields: average\_incoming\_traffic, average\_incoming\_traffic\_bits, average\_outgoing\_traffic, average\_outgoing\_traffic\_bits, average\_incoming\_pps, average\_outgoing\_pps, average\_incoming\_flows, average\_outgoing\_flows - Removed deprecated attack detection fields from email alerts: Attack type, Initial attack power, Peak attack power, Attack direction, Attack protocol. These fields were calculated by very flawed logic and we replaced them by new fields which precisely reflect reality of attack. - Added configuration options gobgp\_as\_path\_host\_ipv4, gobgp\_as\_path\_subnet\_ipv4, gobgp\_as\_path\_host\_ipv6, gobgp\_as\_path\_subnet\_ipv6 - Added bgp\_as\_path\_host\_ipv4, bgp\_as\_path\_subnet\_ipv4, bgp\_as\_path\_host\_ipv6, bgp\_as\_path\_subnet\_ipv6 for all hostgroups - Improved logic to craft IPv4 BGP attributes - We deprecated Ubuntu 16.04, Debian 9 and 10 and removed them from releases - Fixed bug with too high values in sudo fcli show baseline\_per\_host global outgoing for outgoing traffic - Adjusted Clickhouse datasource UID for password reset logic - Changed Clickhouse datasource to new UUID format - Added logic to set correct owner for /var/lib/grafana/plugins - Added fcli flag NO\_DATABASE\_MODE which can be set to on to suppress connection attempts to MongoDB See this release on [GitHub](https://github.com/FastNetMon/fastnetmon-advanced-releases/releases/tag/v2.0.367) **Categories:** Releases **Tags:** release, releases --- ### [“Matrix Botnet” Exploiting IoT Devices for DDoS Campaign](https://fastnetmon.com/2024/11/27/matrix-botnet-exploiting-iot-devices-for-ddos-campaign/) **Published:** November 27, 2024 **Author:** FastNetMon **Content:** The Matrix Botnet, a threat actor linked to a widespread DDoS campaign has been uncovered by security researchers. The botnet is exploiting vulnerabilities and misconfigurations in Internet of Things (IoT) devices. This operation seems to be a comprehensive one-stop shop for scanning, exploiting vulnerabilities, deploying malware, and setting up shop kits, which makes it an alarming discovery. The targets span cloud service providers and smaller enterprises. Analysis revealed up to 35 million potential devices could be affected, suggesting a botnet of 350,000 to 1.7 million devices, depending on vulnerability rates. The attacks launched using the matrix botnet have primarily targeted IP addresses located in IoT-heavy regions like China and Japan, and to a lesser extent Argentina, Australia, Brazil, Egypt, India, and the U.S. The attack chains exploit known security flaws and weak credentials to gain access to a broad spectrum of internet-connected devices such as IP cameras, DVRs, routers, and telecom equipment. The threat actor has also been observed leveraging misconfigured Telnet, SSH, and Hadoop servers, with a particular focus on targeting IP address ranges associated with cloud service providers like AWS, Microsoft Azure, and Google Cloud. The malicious activity relies on a wide array of publicly available scripts and tools available on GitHub, deploying the Mirai botnet malware and other DDoS-related programs on compromised devices and servers. Matrix utilizes a mix of Python, Shell and Golang-based scripts sourced from GitHub and other platforms. Tools like Mirai variants, SSH scanners, and Discord bots highlight the integration of pre-existing frameworks into customised campaigns. The threat actor also monetises services via Telegram, offering DDoS plans for cryptocurrency payments. While Matrix appears to lack advanced capabilities, the ease of assembling and operating these tools exemplifies the growing risk posed by low-sophistication actors armed with accessible resources. --- ## About FastNetMon FastNetMon delivers versatile DDoS detection software for companies at any scale. With extensive experience in the telecom, mobile, and cloud computing industries, we take pride in preventing DDoS attacks and protecting our customers’ networks to the highest standard. Find out more: <https://fastnetmon.com/> **Categories:** FastNetMon Blog **Tags:** Botnets --- ### [Event Recap - UK IPv6 Council Annual Meeting](https://fastnetmon.com/2024/11/20/event-recap-uk-ipv6-council-annual-meeting/) **Published:** November 20, 2024 **Author:** FastNetMon **Content:** FastNetMon had the privilege of participating in the UK IPv6 Council Annual Meeting held last Tuesday, November 19th, 2024 at Cisco Meraki in London. The event was a melting pot of knowledge and expertise, with very interesting talks from industry leaders in the Internet, telco, and networking fields. Here’s our recap of the highlights! ![](https://fastnetmon.com/wp-content/uploads/2024/11/IPv6-adoption-in-UK-UK-IPv6-Council-Meeting-1024x457.png)From FastNetMon, Pavel Odintsov delivered a talk about the journey towards IPv6 households, sharing some of his personal anecdotes of building an IPv6-only (or IPv6-mostly) work setup. You can find his presentation slides below! [![](https://fastnetmon.com/wp-content/uploads/2024/11/IPv6-Only-Household-1024x577.png)](https://fastnetmon.com/wp-content/uploads/2024/11/On-the-way-to-IPv6-only-household-UK-IPv6-Council-Meeting-2024.pdf)The event ran for the entire day, featuring one great presentation after another. Veronika McKillop, President of the UK IPv6 Council opened the presentations with a look at the impressive growth of IPv6 over the last decade, charting its rise from a mere 1% to a significant 40%. This was followed by Richard Patterson from Sky, who brought attention to an unexpected advantage of MAP-T deployment, revealing its potential for basic DDoS protection, and shared that Sky employs an 8:1 sharing ratio for their MAP-T deployment in the UK. ![](https://fastnetmon.com/wp-content/uploads/2024/11/Veronika-McKillop-UK-IPv6-Council-Annual-Meeting-1024x557.jpeg)*Veronika McKillop, President of the UK IPv6 Council giving the opening speech for the day*Another interesting presentation was by Wilhelm Boeddinghaus from Route 128, who shared his insights about deploying IPv6 for large organizations in Germany. This topic was complemented by David Stockdale from Imperial College London, who shared his institution's journey with IPv6 deployment, providing a unique perspective from one of the UK's largest universities. ![](https://fastnetmon.com/wp-content/uploads/2024/11/UK-IPv6-Council-Meeting-2024-David-Stockdale-Imperial-Colllege-London-1024x620.jpeg)*David Stockdale: IPv6-mostly at Imperial College London*Further on, Tommy Jensen from Microsoft shifted the focus to the technical aspects, emphasizing the crucial role of CLAT in enabling IPv6 compatibility for older Windows applications. This was followed by Paulius Judickas from IPXO, who offered valuable data on the dynamics of IPv4 trading. ![](https://fastnetmon.com/wp-content/uploads/2024/11/UK-IPv6-Council-Meeting-2024-Tommy-Jensen-Microsoft-1024x613.jpeg)*IPv6 in Windows Then and Now – Tommy Jensen (Microsoft)*The day was jam-packed with informative presentations and engaging discussions, offering a ton of valuable IPv6 insights and learning. Thank you IPv6 Council for organising - we look forward to further contributing to the conversation! --- ## About FastNetMon FastNetMon delivers versatile DDoS detection software for companies at any scale. With extensive experience in the telecom, mobile, and cloud computing industries, we take pride in preventing DDoS attacks and protecting our customers’ networks to the highest standard. Find out more: <https://fastnetmon.com/> **Categories:** Events, Press & Newsroom **Tags:** events --- ### [Fastnetmon at HKNOG13](https://fastnetmon.com/2024/11/08/fastnetmon-at-hknog13/) **Published:** November 8, 2024 **Author:** FastNetMon **Content:** ## How was it at HKNOG13? Here’s our conference recap Last Friday, November 1st 2024, we had the absolute pleasure of attending the annual Hong Kong Network Operators Group conference #13 - AKA HKNOG13. Flying in all the way from UK on a short notice was bt of a task, but it was more than worth it! The event brought together all the cool kids from the region and beyond to discuss the latest trends and developments in the networking field. The organisers did a fantastic job setting up just the right amount of presentations, networking, and food to keep the 300+ attendees happy and engaged. Our very own Pavel Odintsov took the stage to present on "BGP Flow Spec for DDoS mitigation". The talk was well-received, with a couple of good technical questions, shedding light on the importance of BGP protocol for DDoS mitigation. You can get the presentation slides below! [![](https://fastnetmon.com/wp-content/uploads/2024/11/BGP_Flowspec_slides-1024x575.png)](https://fastnetmon.com/wp-content/uploads/2024/11/BGP-Flow-Spec-updated-31-October-2024_compressed.pdf)The conference also featured other notable presentations. Zen Chuan NG from APNIC gave a great talk on DASH, while Rachel Lee from Cyberport and Peter Pin from BSO engaged in a fireside chat discussing the evolution from Web2.0 to Web3.0 and the new opportunities it presents. Adam Wong from A-field Tech Limited emphasized the importance of low latency networks in Web 3.0, and Donald Lam from Ciena shared the latest trends in optical industrial technology, specifically for submarine cables. ![](https://fastnetmon.com/wp-content/uploads/2024/11/HKNOG13_2024_presentations.png)One of the highlights of the event was the opportunity to meet some of our customers and partners in the APAC region. It was a nice treat to meet in person some of the people we’ve only known through email! ![](https://fastnetmon.com/wp-content/uploads/2024/11/HKNOG_FastNetMon_People-1024x953.png)Overall, HKNOG13 was a successful event, full of knowledge exchange and networking opportunities. We are particularly keen to continue expanding towards the region, and making more contacts in the network security field in APAC. Huge thank you to the organisers - we look forward to participating in future editions and continuing to contribute to the conversation. ![](https://fastnetmon.com/wp-content/uploads/2024/11/HKNOG13-1024x683.jpeg)Image courtesy of HKNOG--- ## About FastNetMon FastNetMon delivers versatile DDoS detection software for companies at any scale. With extensive experience in the telecom, mobile, and cloud computing industries, we take pride in preventing DDoS attacks and protecting our customers’ networks to the highest standard. Find out more: <https://fastnetmon.com/> **Categories:** Events, Press & Newsroom **Tags:** events --- ### [British Councils Fend Off a Series of DDoS Attacks](https://fastnetmon.com/2024/11/06/british-councils-fend-off-a-series-of-ddos-attacks/) **Published:** November 6, 2024 **Author:** FastNetMon **Content:** Last week several UK councils experienced outages on their websites, with some even knocked offline or rendered inaccessible to users, due to a series of DDoS attacks. The cyber onslaught targeted various local authorities and other organisations, including small banks and the Premier League football club Tottenham Hotspur. The attack is claimed to be work of the politically motivated hacker group NoName057. Among the affected councils were Bradford, Eastleigh, Keighley, Salford, Tameside, and Trafford. The websites of Eastleigh and Trafford, along with Salford, remained down until Wednesday afternoon, with Salford's site returning with warnings of ongoing technical difficulties. Additionally, on Thursday, October 31st, Middlesbrough, Medway, and Hastings council websites were unavailable for some time. Other councils, such as Plymouth and BCP (Bournemouth, Christchurch, and Poole), displayed banners indicating site-wide issues. NCSC, UK’s National Cyber Security Centre has been providing support for the affected councils in the form of guidance to prevent and mitigate further attacks. Security experts have suggested that certain council’s websites have remained down due to an Azure App Service, which lacks native DDoS protection, and other’s on-site webservers couldn't handle the excessive load, causing the site to go offline. --- ## About FastNetMon FastNetMon delivers versatile DDoS detection software for companies at any scale. With extensive experience in the telecom, mobile, and cloud computing industries, we take pride in preventing DDoS attacks and protecting our customers’ networks to the highest standard. Find out more: <https://fastnetmon.com/> **Categories:** FastNetMon Blog **Tags:** political --- ### [German Police Shuts Down DDoS Service](https://fastnetmon.com/2024/11/05/german-police-shuts-down-ddos-service/) **Published:** November 5, 2024 **Author:** FastNetMon **Content:** German police have announced the disruption of a DDoS-for-hire platform dstat\[.\]cc. The platform has been playing a significant role in facilitating distributed denial-of-service (DDoS) attacks, and the crackdown is a big victory for cybercrime defense. German law enforcement describes dstat\[.\]cc as a platform that was provided evaluations of stressor services, which are used to conduct DDoS attacks. Platforms like dstat\[cc\] make it possible for attackers without technical skills to hire and orchestrate cybercrime. Industry research has shown that dstat\[.\]cc offered botnet owners the ability to assess their DDoS attack services’ capacity and capabilities. The platform collected data from demonstration attacks, providing reviews and contact information for booter services, enabling potential subscribers to compare and find the best service for their malicious intents. Two suspects have been arrested in connection with this platform. They are also accused of providing criminal infrastructure for narcotics trafficking. The takedown of dstat\[.\]cc is part of the ongoing PowerOFF operation coordinated by an international group of law enforcement, which has led to the closure of several DDoS-for-hire sites. --- ## About FastNetMon FastNetMon delivers versatile DDoS detection software for companies at any scale. With extensive experience in the telecom, mobile, and cloud computing industries, we take pride in preventing DDoS attacks and protecting our customers’ networks to the highest standard. Find out more: <https://fastnetmon.com/> **Categories:** FastNetMon Blog **Tags:** legal --- ### [CUPS vulnerability explained ](https://fastnetmon.com/2024/10/23/cups-vulnerability-explained/) **Published:** October 23, 2024 **Author:** FastNetMon **Content:** ## How compromised CUPS servers can be a DDoS threat? A newly discovered vulnerability (CVE-2024-47850) in the Common Unix Printing System (CUPS) can be exploited to stage DDoS attacks. Starting an attack is surprisingly simple. It only requires sending a single packet to a vulnerable CUPS service, triggering an amplified, partially attacker-controlled IPP/HTTP request flood. There are over 198,000 vulnerable CUPS devices accessible online, and roughly a third of them can be potentially used for abuse. Read on to get the full picture! ## What is CUPS? CUPS, or Common UNIX Printing System, is a modular printing system utilized by Unix-like computer operating systems. Simply put, CUPS allows a computer to act as a printer server, in a way that the computer running CUPS is a host, accepting print jobs from client computers, process them, and then send them to printers. On September 26th 2024, security researcher Simone Margaritelli (also known as EvilSocket) discovered a vulnerability in CUPS that could potentially be exploited to stage DDoS attacks. This vulnerability is present in the "cups-browsed" package bundled with "cups-filters" and is triggered when a request to add a printer via UDP is received. ## How does the vulnerability work? ![](https://fastnetmon.com/wp-content/uploads/2024/10/Animation_CUPS_blog_GIF.gif)This vulnerability can be exploited for DDoS attacks by sending a single packet to a vulnerable and exposed CUPS service that is connected to the Internet. The attack prompts the CUPS service to generate a larger and partially attacker-controlled IPP/HTTP requests directed at a specified target. This not only affects the target but also the host of the CUPS server, as the attack consumes its network bandwidth and CPU resources. ## How impactful is the CUPS vulnerability? The impact and exposure of this CUPS vulnerability are significant, and we recommend immediate action. Some researchers have estimated that more than 198,000 devices are vulnerable and accessible on the public internet, and approximately 34% of these devices are potentially usable for DDoS abuse. Some of these vulnerable CUPS servers can establish thousands of requests, which indicates a serious potential for amplification. ## Patching the vulnerability Preventing the CUPS DDoS attacks involves either updating to the latest version of CUPS or removing it entirely, depending on your system's needs. If removal or updating isn't possible, we recommend firewalling the service ports, especially if they're accessible from the broader internet. Additionally, defenders should be prepared to identify and fend off attackers by implementing matching rules in their WAF configurations. --- ## About FastNetMon FastNetMon delivers versatile DDoS detection software for companies at any scale. With extensive experience in the telecom, mobile, and cloud computing industries, we take pride in preventing DDoS attacks and protecting our customers’ networks to the highest standard. Find out more: <https://fastnetmon.com/> **Categories:** FastNetMon Blog **Tags:** threats and vulns --- ### [Solving a large DDoS attack problem for a leading telecommunications consultancy provider](https://fastnetmon.com/2023/06/11/solving-a-large-ddos-attack-problem-for-a-leading-telecommunications-consultancy-provider/) **Published:** June 11, 2023 **Author:** FastNetMon **Content:** ## FastNetMon Stories: Here from real users of the FastNetMon solution MKE Solutions, a leading telecommunications consultancy, turned to FastNetMon to address their critical problem of enduring 35 daily DDoS attacks. Find out how FastNetMon's flexibility and network visibility proved invaluable in combating the attacks while providing cost-effective network protection. ### **The user** [MKE Solutions](https://www.mkesolutions.net/) is a telecommunications consultancy that provides IT support to companies and internet service providers. With over 15 years of experience in the market, we have been able to establish ourselves as a leading company in our sector. ### **What problem were you looking to solve?** We first spoke with FastNetMon in 2018. We were looking for help with a gigantic problem, as our network received 35 daily DDoS attacks for a period that reached several weeks, interrupting the provision of services during the hours that the attack lasted. ### **Why did you choose to partner with FastnetMon? What are the main benefits?** The main benefit of FastNetMon is its flexibility. It can be implemented to [protect us](https://fastnetmon.com/ddos-detection-and-mitigation/) from DDos attacks while also providing excellent [network traffic visibility](https://fastnetmon.com/traffic-visibility/), enabling us to identify traffic patterns and statistics of protocols, among other things. A big draw towards FastNetMon was the added benefit of having the company's backing and direct access to their support team, which has been invaluable to us. Additionally, as a [FastNetMon partner](https://fastnetmon.com/partners/), we're proud to say that we've been able to tackle the issue of DDoS attacks on our networks effectively. ### **Why do you prefer to offer FastNetMon to your customers, rather than other competitors in the market?** Based on our experience, FastNetMon has been the solution that, in terms of cost-effectiveness, is one of the best options in the market. Other solutions have expensive costs and provide the same functionality as FastNetMon. Therefore, we can have network protection at a fraction of the cost of competitor solutions. ### **You created a new interface for the FastNetMon platform to share with your customers. What made you decide to do that? And what benefits has it provided to your customers?** When we started using FastNetMon, we noticed that some clients found the CLI mode complex when making configuration changes or adjustments. Additionally, fine-tuning certain functionalities required multiple configuration steps. That's why we decided to assemble a software development team to create a web environment that could interact with FastNetMon via API. This enabled us to configure multiple configuration options with a single click. The web interface evolved to offer full support for FastNetMon, as well as some additional functionalities. For example, it includes support for a MikroTik plugin, configuration for Scrubbing Center, auto-configuration of thresholds for host groups, and traffic reporting by different filters such as ASN, networks, etc. Being in constant contact with Pavel, CTO of FastNetMon directly allows us to stay up-to-date with the latest FastNetMon updates and provide support for our web interface as soon as we hear the news. ### **Here’s what one MKE Solutions customer had to say about the newly-built solution** I came across FastNetMon while searching for a solution to a massive problem. In 2018, our network was experiencing 35 attacks per day for several weeks, causing service interruptions during the duration of the attacks. We initially installed and tested FastNetMon Community version and had excellent results. We immediately upgraded to the PRO version, which addressed the main issue. However, we felt that two important things were missing: a graphical interface and simplified management. We made our first attempts to implement Grafana, and although the results were very good, we found that the implementation required prior knowledge of this type of environment. Additionally, when the network traffic was high, the server resource demand was significant, and we still hadn't solved the simplified management of FastNetMon. That's when we discovered the Dashboard developed by MKE Solutions, which displayed graphs indicating the timing and magnitude of the attacks. It allowed us to have statistics and highly relevant information to make decisions. One significant advantage we noticed was that having such an intuitive and user-friendly graphical interface meant that advanced technical knowledge was no longer necessary for an operator. With just a few clicks, we could customise all the relevant parameters. Today, FastNetMon, along with the Dashboard developed by MKE Solutions, is an essential part of our basic service infrastructure, as important as our DNS servers. It provides us with the peace of mind that our network will autonomously respond to an attack without the need for anyone's intervention. *David Vega, Chief Technology Officer, i-TIC* Want to keep your network safe? [Try FastNetMon FREE for one month](https://fastnetmon.com/trial/). **Categories:** FastNetMon Blog **Tags:** case study, testimonials --- ## Pages ### [FastNetMon - Comprehensive Solutions for DDos Security](https://fastnetmon.com/) **Published:** January 27, 2026 **Author:** Milan Milosevic **Excerpt:** High-performance DDoS detection tool. Support BGP FlowSpec, RTBH & sFlow for real-time security without extra hardware. Deploy on your VM. **Content:** - Network Layer DDoS Detection and Mitigation # Comprehensive Solution For DDoS Security Learn More [Start a free Trial](https://fastnetmon.com/trial/) #### PRODUCT OVERVIEW ## The Control Plane of Your DDoS Defence Stack FastNetMon analyses live network traffic to detect DDoS attacks in near real time and triggers mitigation actions based on operator-defined rules and workflows. Engineers can use FastNetMon to initiate responses via BGP FlowSpec, RTBH, or redirect traffic to external scrubbing centres, while retaining full control over how, when, and where mitigation is applied within their network. ![Monitoring](https://fastnetmon.com/wp-content/uploads/2026/01/icon_monitoring-1.png "icon_monitoring") #### Real-time DDoS Detection Analyse live traffic to detect volumetric and packet-rate–based DDoS attacks in near real time using configurable thresholds and detection logic. ![GBP Blackhole](https://fastnetmon.com/wp-content/uploads/2026/01/icon_gbpblackhole.png "icon_gbpblackhole") #### BGP Blackhole Automation Automate remote-triggered blackholing (RTBH) using BGP rules defined by the operator to quickly drop attack traffic during large-scale DDoS events. ![BGP Flow Spec](https://fastnetmon.com/wp-content/uploads/2026/01/icon_bgpflowspec.png "icon_bgpflowspec") #### BGP Flow Spec Mitigation Apply targeted traffic filtering using BGP FlowSpec to mitigate DDoS attacks with minimal impact on legitimate traffic. ![](https://fastnetmon.com/wp-content/uploads/2026/01/icon_cloud_scrubbing.png "icon_cloud_scrubbing") #### Scrubbing Centre Diversion Automatically divert attack traffic to external scrubbing centres based on predefined conditions, reducing cost and latency. ![](https://fastnetmon.com/wp-content/uploads/2026/01/icon_blocklist.png "icon_blocklist") #### Blocklist-based filtering Apply dynamic IP blocklists from external threat intelligence feeds or internal sources, enforced automatically at the network level as part of a layered DDoS defence. ![](https://fastnetmon.com/wp-content/uploads/2026/01/icon_api.png "icon_api") #### API & embeddable solutions Integrate FastNetMon into existing systems using APIs and embeddable components to build custom workflows, automation, and tooling. 45 ## Partnered With the Very Best in the Ecosystem ![G-Core](https://fastnetmon.com/wp-content/uploads/2026/03/GCore-logo.png "GCore-logo") ![Radware](https://fastnetmon.com/wp-content/uploads/2026/01/radware.jpg "radware") ![F5](https://fastnetmon.com/wp-content/uploads/2026/01/f5.jpg "f5") ![Ripe NCC](https://fastnetmon.com/wp-content/uploads/2026/01/ripe-ncc.jpg "ripe-ncc") ![](https://fastnetmon.com/wp-content/uploads/2026/03/IP-Infusion.png "IP Infusion") ![UK Cyber Security Council](https://fastnetmon.com/wp-content/uploads/2026/01/uk-cyber-security.jpg "uk-cyber-security") ![AWS Partner Network](https://fastnetmon.com/wp-content/uploads/2026/01/aws-network.jpg "aws-network") ![Google Cloud Partner](https://fastnetmon.com/wp-content/uploads/2026/01/google-cloud-partner.jpg "google-cloud-partner") ##### Countries Worldwide ##### Deployments Tbits ##### Peak performance #### DDoS Detection ## Real-time network traffic visibility FastNetMon continuously analyses live traffic to detect DDoS attacks in near real time while providing visibility into traffic volumes, packet rates, and protocol behaviour. Detection thresholds and mitigation workflows are defined upfront, enabling automated response when attack conditions are met. [Explore DDoS Detection](https://fastnetmon.com/ddos-detection-and-mitigation/) ![DDoS Detection](https://fastnetmon.com/wp-content/uploads/2026/01/DDoS-detectino-diagram.jpg "DDoS-detectino-diagram") ![BGP Blackhole](https://fastnetmon.com/wp-content/uploads/2026/01/BGP-Blackhole-diagram.jpg "BGP-Blackhole-diagram") #### RTBH Automation ## Automated BGP blackholing for rapid attack containment FastNetMon automates remote-triggered blackholing (RTBH) for high-volume DDoS scenarios where temporarily dropping all traffic to a targeted IP or prefix is preferable to risking congestion or instability across the rest of the network. Operator-defined policies control when blackholing is applied and automatically withdrawn once conditions return to normal. [Explore RTBH Automation](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-bgp-blackhole-automation/) #### BGP Flow Spec ## Targeted traffic filtering using BGP Flow Spec rules FastNetMon manages Flow Spec rules based on operator-defined thresholds and policies. When traffic crosses configured thresholds, it automatically creates and announces BGP Flow Spec rules to filter or rate-limit specific attack patterns. Configurable unban logic ensures rules are withdrawn after conditions normalise, so filtering is applied only when needed. [Explore FlowSpec Automation](https://fastnetmon.com/bgp-flow-spec-ddos-mitigation/) ![BGP Flow Spec](https://fastnetmon.com/wp-content/uploads/2026/01/BGP-Flowspec-diagram.jpg "BGP-Flowspec-diagram") ![Scrubbing Centre Diversion](https://fastnetmon.com/wp-content/uploads/2026/01/scrubbing-diagram-bl.jpg "scrubbing-diagram-bl") #### Scrubbing Centre Diversion ## Automated traffic diversion to external mitigation systems FastNetMon detects attacks and automatically diverts affected traffic to scrubbing centres using routing-based controls. Engineers define when diversion occurs and which prefixes are redirected, enabling seamless integration with on-premises or third-party scrubbing infrastructure. [Explore Scrubbing Integration](https://fastnetmon.com/ddos-scrubbing-centre-diversion/) #### OUR CUSTOMERS ## Protecting Some of the World’s Largest Networks FastNetMon is deployed by telecommunications providers, ISPs, hosting companies, and enterprises operating networks of all sizes. From regional operators to global infrastructure providers, customers rely on FastNetMon to protect production networks from DDoS attacks while maintaining control over their routing and mitigation workflows. ![Vodafone](https://fastnetmon.com/wp-content/uploads/2026/01/vodafone.jpg "vodafone") ![T-Mobile](https://fastnetmon.com/wp-content/uploads/2026/01/t-mobile.jpg "t-mobile") ![Wikipedia](https://fastnetmon.com/wp-content/uploads/2026/01/wikipedia.jpg "wikipedia") ![Your Server](https://fastnetmon.com/wp-content/uploads/2026/01/yourserver.jpg "yourserver") ![PrimeTel](https://fastnetmon.com/wp-content/uploads/2026/01/primetel.jpg "primetel") ![Neterra](https://fastnetmon.com/wp-content/uploads/2026/01/neterra.jpg "neterra") ![Tranquil Hosting](https://fastnetmon.com/wp-content/uploads/2026/01/tranquilhosting.jpg "tranquilhosting") ![Codisa](https://fastnetmon.com/wp-content/uploads/2026/01/codisa.jpg "codisa") ![Conecta T](https://fastnetmon.com/wp-content/uploads/2026/01/conectat.jpg "conectat") ![Host Dime](https://fastnetmon.com/wp-content/uploads/2026/01/hostdime.jpg "hostdime") ![](https://fastnetmon.com/wp-content/uploads/2026/06/Joy-Services-Logo-FastNetMon-Case-Study.png "Joy Services Logo FastNetMon Case Study") “If all ISPs filtered outgoing attacks with FastNetMon, it would reduce DDoS attacks on the entire Internet.” [Case Study](https://fastnetmon.com/2026/06/15/case-joy-services-automated-ddos-detection-and-hardware-accelerated-mitigation/) ![](https://fastnetmon.com/wp-content/uploads/2026/04/Pentanet_case_logo.png "Pentanet_case_logo") Pentanet deploys FastNetMon for real-time DDoS detection and automated RTBH mitigation at the network edge. [Case study](https://fastnetmon.com/2026/04/06/case-pentanet-real-time-ddos-detection-at-the-edge/) ![](https://fastnetmon.com/wp-content/uploads/2026/01/am-six.jpg "am-six") AMX-IS runs FastNetMon as detection engine in its management network to detect and mitigate DDoS attacks. [Enginering story](https://fastnetmon.com/2026/01/27/engineering-deep-dive-how-ams-ix-uses-fastnetmon-for-automated-ddos-mitigation/) ![](https://fastnetmon.com/wp-content/uploads/2026/01/link3_logo.png "link3_logo") Link3 Technologies uses FastNetMon for real-time DDoS detection, automation, and remote scrubbing integration. [Case Study](https://fastnetmon.com/2025/12/17/case-study-ddos-detection-and-automated-mitigation-at-link3-with-fastnetmon/) ![](https://fastnetmon.com/wp-content/uploads/2026/01/myvirtualserver-1.png "myvirtualserver") “FastNetMon significantly improved our workflow and helped us maintain a stable network.” – Henry Spanka, MyVirtualServer [User feedback](https://fastnetmon.com/client-testimonials/) 45 [Read User Stories](https://fastnetmon.com/client-testimonials/) ## Modern DDoS defence, without legacy pricing FastNetMon delivers network-level DDoS detection and mitigation without the cost or complexity of traditional solutions. Entry plans start at **$115/month**, scaling to meet enterprise and ISP requirements. [![Explore Plans](https://fastnetmon.com/wp-content/uploads/2026/01/plans-icon.png "plans-icon")](https://fastnetmon.com/price/) #### [Explore Plans](https://fastnetmon.com/price/) [![Start a Trial](https://fastnetmon.com/wp-content/uploads/2026/01/free-trial-icon.png "free-trial-icon")](https://fastnetmon.com/trial/) #### [Start Trial](https://fastnetmon.com/trial/) ## Latest News [![Faster Packet Filtering on BlueField-3 Arm Cores with VPP’s Native RDMA Driver](https://fastnetmon.com/wp-content/uploads/2026/10/Denys-Haryachyy-Faster-Packet-Filtering-on-BlueField-3-Arm-Cores-with-VPPs-Native-RDMA-Driver.png)](https://fastnetmon.com/2026/10/14/faster-packet-filtering-on-bluefield-3-arm-cores-with-vpps-native-rdma-driver/) ## [Faster Packet Filtering on BlueField-3 Arm Cores with VPP’s Native RDMA Driver](https://fastnetmon.com/2026/10/14/faster-packet-filtering-on-bluefield-3-arm-cores-with-vpps-native-rdma-driver/) Oct 14, 2026 This post is a repost of a technical blog originally published by Denys Haryachyy, shared here with permission as part of ongoing research and engineering work around FastNetMon’s inline traffic… [![IPv6 DDoS Attacks and Mitigation with FastNetMon](https://fastnetmon.com/wp-content/uploads/2026/10/IPv6-DDoS-attacks-explained.png)](https://fastnetmon.com/2026/10/08/ipv6-ddos-attacks-and-mitigation-with-fastnetmon/) ## [IPv6 DDoS Attacks and Mitigation with FastNetMon](https://fastnetmon.com/2026/10/08/ipv6-ddos-attacks-and-mitigation-with-fastnetmon/) Oct 8, 2026 IPv6 is now a standard part of many service provider, hosting, data centre and enterprise networks. As more services become reachable over IPv6, network operators also need to make sure that their… [![Packet Filtering with VPP on BlueField-3 Arm Cores and 100G NICs](https://fastnetmon.com/wp-content/uploads/2026/10/Packet-Filtering-with-VPP-on-BlueField-3-Arm-Cores-and-100G-NICs-Denys-Haryachyy.png)](https://fastnetmon.com/2026/10/05/packet-filtering-with-vpp-on-bluefield-3-arm-cores-and-100g-nics/) ## [Packet Filtering with VPP on BlueField-3 Arm Cores and 100G NICs](https://fastnetmon.com/2026/10/05/packet-filtering-with-vpp-on-bluefield-3-arm-cores-and-100g-nics/) Oct 5, 2026 This post is a repost of a technical blog originally published by Denys Haryachyy , shared here with permission as part of ongoing research and engineering work around FastNetMon’s inline traffic… [![Introducing FastACL Community: Open-Source DDoS Scrubbing](https://fastnetmon.com/wp-content/uploads/2026/09/FastACL-1.png)](https://fastnetmon.com/2026/09/25/introducing-fastacl-community-open-source-ddos-scrubbing/) ## [Introducing FastACL Community: Open-Source DDoS Scrubbing](https://fastnetmon.com/2026/09/25/introducing-fastacl-community-open-source-ddos-scrubbing/) Sep 25, 2026 For more than a decade, FastNetMon Community has given network operators an open-source option for high-performance DDoS detection. Today, we’re extending that approach from detecting attacks to… ## FastNetMon in the Media [![Fortune](https://fastnetmon.com/wp-content/uploads/2026/01/fortune.jpg "fortune")](https://fortune.com/press-releases/rise-super-botnets-fastnetmon-ddos-attacks-2025-12-11/?utm_content=494217464&utm_medium=social&utm_source=facebook&hss_channel=fbp-526563014372607) [![](https://fastnetmon.com/wp-content/uploads/2026/02/Nanog-logo-1.png "Nanog-logo")](https://nanog.org/stories/inside-nanog-96-attendees-share-what-made-our-last-conference-unforgettable/) [![The Registar](https://fastnetmon.com/wp-content/uploads/2026/01/the-register.jpg "the-register")](https://www.theregister.com/2025/09/11/fastnetmon_ddos_attack/) [![Bloomberg](https://fastnetmon.com/wp-content/uploads/2026/01/bloomberg.jpg "bloomberg")](https://www.bloomberg.com/news/articles/2024-08-01/microsoft-azure-attack-shows-persistence-of-blunt-hacking-tool) [![MSN](https://fastnetmon.com/wp-content/uploads/2026/01/msn.jpg "msn")](https://www.msn.com/en-us/money/other/another-massive-ddos-attack-that-reached-1-5-bpps-has-been-thwarted/ar-AA1Mu2Tt) [![Tech Radar](https://fastnetmon.com/wp-content/uploads/2026/01/techradar.jpg "techradar")](https://www.techradar.com/pro/security/another-massive-ddos-attack-that-reached-1-5-bpps-has-been-thwarted) [![Bleeping Computer](https://fastnetmon.com/wp-content/uploads/2026/01/bleeping-computer.jpg "bleeping-computer")](https://www.bleepingcomputer.com/news/security/ddos-defender-targeted-in-15-bpps-denial-of-service-attack/) [![Yahoo Finance](https://fastnetmon.com/wp-content/uploads/2026/01/yahoo-finance.jpg "yahoo-finance")](https://uk.finance.yahoo.com/news/1-5-billion-packets-per-105200494.html) [![Cyber Press](https://fastnetmon.com/wp-content/uploads/2026/01/cyber-press.jpg "cyber-press")](https://cyberpress.org/ddos-1-5-gpps-attack/) [![Business Insider](https://fastnetmon.com/wp-content/uploads/2026/01/business-insider.jpg "business-insider")](https://markets.businessinsider.com/news/currencies/1-5-billion-packets-per-second-ddos-attack-detected-with-fastnetmon-1035135535) [![Cyber Security News](https://fastnetmon.com/wp-content/uploads/2026/01/cybersecuritynews.jpg "cybersecuritynews")](https://cybersecuritynews.com/1-5-billion-packets-per-second-ddos-attack-detected/) [![GB Hackers](https://fastnetmon.com/wp-content/uploads/2026/01/gbhackers.jpg "gbhackers")](https://gbhackers.com/1-5-billion-packets-per-second-ddos-attack-detected/) [![Hack Read](https://fastnetmon.com/wp-content/uploads/2026/01/hackread.jpg "hackread")](https://hackread.com/1-5-billion-packets-per-second-ddos-attack-detected-with-fastnetmon/) [![SC Media](https://fastnetmon.com/wp-content/uploads/2026/01/sc-media.jpg "sc-media")](https://www.scworld.com/brief/massive-ddos-attack-discovered-mitigated) --- ### [Nokia Netflow v9 and IPFIX configuration for FastNetMon Advanced](https://fastnetmon.com/docs-fnm-advanced/nokia-netflow-v9-and-ipfix-configuration-for-fastnetmon-advanced/) **Published:** August 7, 2023 **Author:** Pavel Odintsov **Content:** FastNetMon Advanced has complete support for both Netflow v9 and IPFIX telemetry protocols provided by Nokia SR. For all new deployments, we recommend using the IPFIX protocol. If you're looking for options to detect attacks in 1-3 seconds, please check the alternative traffic capture protocol supported by [Nokia](https://fastnetmon.com/docs-fnm-advanced/app-packet-sr-plugin/). To enable IPFIX support on Nokia SR, we can provide the following example configuration: ``` admin-state enable export-mode automatic inband-collector-export-only false overflow 1 template-retransmit 60 use-vrtr-if-index false active-flow-timeout 15 inactive-flow-timeout 15 sample-profile 1 { sample-rate 1000 } collector 10.1.1.1 port 2055 { admin-state enable description "FastnetMon" autonomous-system-type origin router-instance "Base" template-set basic version 10 } ``` On FastNetMon’s side, you may specify the sampling rate if needed using [this guide](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-netflow-and-ipfix-sampling-configuration/): ``` sudo fcli set main netflow_sampling_ratio 1000 sudo fcli commit ``` To specify the [average calculation time](https://fastnetmon.com/docs-fnm-advanced/what-is-average_calculation_time/) value: ``` sudo fcli set main average_calculation_time 30 sudo fcli commit ``` **Document Categories:** Netflow and IPFIX --- ### [FastNetMon Advanced Mikrotik configuration](https://fastnetmon.com/docs-fnm-advanced/mikrotik/) **Published:** January 25, 2018 **Author:** Pavel Odintsov **Content:** In the video below, we cover every step of configuration using WinBox. After making all changes as presented in the video, change src address for Netflow target to router IP to avoid issues with Netflow delivery to Linux machine. If you keep it as 0.0.0.0, Linux will discard such traffic. From FastNetMon Advanced side, you need to change [average\_calculation\_time](https://fastnetmon.com/docs-fnm-advanced/what-is-average_calculation_time/): ``` sudo fcli set main average_calculation_time 60 sudo fcli commit ``` If you prefer to use command line you can continue and use instructions below. As the first step, please open the NetFlow configuration: ``` /ip traffic-flow ``` And enable NetFlow for all ports with affordable timeouts: ``` set enabled=yes set interfaces=all set cache-entries=128k set active-flow-timeout=00:00:30 set inactive-flow-timeout=00:00:30 ``` 128k value works for almost all carrier-grade devices. In case you encounter issues, try 64k, 32k, or 16k instead. Change to Netflow target configuration: ``` /ip traffic-flow target ``` And specify FastNetMon here by replacing 192.168.88.13 by address of machine with FsatNteMon installed. You will need to replace 10.0.0.1 by IP of your router. ``` add dst-address=192.168.88.13 src-address=10.0.0.1 port=2055 version=9 v9-template-refresh=1000 v9-template-timeout=15 ``` - v9-template-timeout configures delay in seconds between repeat submissions of Netflow templates to collector. - v9-template-refresh configures number of Netflow data packets after sending which Mikrotik will send Netflow template to collector again. ## Sampling enabled Netflow and IPFIX Flow tracking process is very expensive in terms of CPU resources and you can reduce CPU usage on router during DDoS attacks by enabling flow sampling. FastNetMon supports sampling for Router OS 6 and 7. To enable sampling on Mikrotik, you need to apply the following commands: ``` /ip/traffic-flow/set packet-sampling=yes sampling-interval=1 sampling-space=1000 ``` After that, enable the following flag on FastNetMon side: ``` sudo fcli set main netflow_v9_read_sampling_rate_in_data_section true sudo fcli commit ``` To address [bug](https://github.com/pavel-odintsov/fastnetmon/issues/985) in Router OS 6 sampling implementation you will need to enable logic to ignore sampling rate announcements from router as they're encoded incorrectly: ``` sudo fcli set main netflow_ignore_sampling_rate_from_device enable sudo fcli commit ``` After that, specify the sampling rate manually: ``` sudo fcli set main netflow_sampling_ratio 1000 sudo fcli commit ``` If you configured everything correctly but all counters on FastNetMon are zero, check that source IP for NetFlow/IPFIX on Mikrotik side is not set to 0.0.0.0 but set to correct IP address. Linux discards traffic when it's coming from 0.0.0.0 as it's not legitimate IP address. Such packets are called [martian](https://en.wikipedia.org/wiki/Martian_packet). If you experience any issues, we can recommend upgrade to latest stable version of [RouterOS](https://mikrotik.com/download) as it may address previously known issues. **Document Categories:** Netflow and IPFIX --- ### [FastNetMon BGP Flow spec based DDoS mitigation](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-bgp-flow-spec-configuration/) **Published:** April 14, 2019 **Author:** Pavel Odintsov **Content:** In BGP Flow spec mode FastNetMon can detect and isolate patterns of malicious traffic and filter it out using high performance filters on your routers. For some platforms which do not support BGP Flow Spec natively we provide API or CLI based integrations: - [Bison](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-and-bison-router-integration/) router As first step of detection Flow Spec logic relies on thresholds. FastNetMon checks all hosts against specified in hostgroup configuration threshold every second. When any your host crosses threshold, FastNetMon creates “traffic capture request”. To continue please configure [thresholds](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-per-host-threshold-configuration/) using this guide. After capture request creation, FastNetMon will collect all traffic to specified host. By default, FastNetMon captures 500 (for mirror/SPAN mode) or 20 (for sFlow v5, Netflow, IPFIX) packets. By default FastNetMon captures all traffic to / from specific host and it may lead to blocks of legitimate traffic in some rare cases. You can switch it to new logic which process only traffic which actually triggered threshold (i.e. only UDP traffic when attack was triggered by UDP threshold) and it can be enabled this way: ``` sudo fcli set main threshold_specific_ban_details true sudo fcli commit ``` You can change number of collected packets that way but we normally do not recommend setting it to very low value as it may cause issues for pattern detection: ``` sudo fcli set main ban_details_records_count 5 sudo fcli commit ``` If it cannot capture this amount of packets for 120 second (can be configured using bucket\_traffic\_collection\_timeout starting from 2.0.359) it removes “traffic capture request” as orphaned and removes it completely. You can find such cases in log file /var/log/fastnetmon/fastnetmon.log: ``` [WARN] We've found orphaned bucket for IP: 10.251.23.1 [WARN] It has 3 parsed packets [WARN] And 3 raw packets [WARN] We will remove it ``` In this case, FastNetMon declares attack as false positive and does not apply any actions. When FastNetMon successfully captures attack sample then tries hard to find best match using all possible configurations of BGP Flow spec rules, for example: - almost all packets come from IP XX to port YY - almost all packets use fragmentation flag and come from port ZZ - almost all packets use protocol M and come from IP XX After that, FastNetMon orders all rules by number of packets / bytes which match each rule. For example, it may get following intermediate results: - port=53 protocol=udp 100 packets 10 packets - port=53 source\_ip=11.22.33.44 protocol=udp 5 packets - port=53 source\_ip=11.33.88.22 protocol=udp 5 packets FastNetMon is interested in finding best possible (which covers as many packets as possible) and shortest rule (which has less parameters ). In this example FastNetMon will select first rule because it shortest and has much more packets that other. After finding best coverage rule for malicious traffic it announces it to BGP Flow Spec router and then it filters out this malicious traffic. In same time FastNetMon excludes all traffic which matches this new Flow Spec rule from processing and starts monitoring if any threshold is crossed again. In this case all traffic of previously known attacks is filtered and it looks for new patterns in this case to address multi vector attacks. If that happens it captures sample of traffic and applies same logic again and again until it filters out attack. Normally, FastNetMon can create around 5-10 rules for each host to filter out attack. To learn more about our detection engine we recommend enabling debug logging and then checking /var/log/fastnetmon/fastnetmon.log: ``` sudo fcli set main logging_level debug sudo fcli commit ``` For next step, you need to have working [BGP peering session](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-bgp-peering-session-setup/). Please enable flow spec AFI on router’s side and then we could start. Enable flow spec for your peering connection ``` sudo fcli set bgp connection_to_my_router ipv4_flowspec enable ``` Enable flow spec globally: ``` sudo fcli set main gobgp_flow_spec_announces enable ``` We could specify action type for FastNetMon’s announces (accept, discard, redirect, rate-limit): ``` sudo fcli set main gobgp_flow_spec_default_action discard ``` For rate-limit you could specify actual rate (usually "bytes per second" but please check with your network vendor): ``` sudo fcli set main gobgp_flow_spec_rate_limit_value 1000 ``` For redirect (supported starting from 2.0.364) you can specify target ASN (16 bit) and target Community (32 bit): ``` sudo fcli set main gobgp_flow_spec_v4_redirect_target_as 65535 sudo fcli set main gobgp_flow_spec_v4_redirect_target_community 4294967295 sudo fcli commit ``` Apply changes: ``` sudo fcli commit ``` When FastNetMon detects new attack and creates BGP Flow Spec rule you will be able to see it here: ``` sudo fcli show flowspec ``` By default, FastNetMon enables Flow Spec mitigations for all hostgroups. Starting from 2.0.355 you can switch to logic which enables them on hostgroup basis: ``` sudo fcli set main flow_spec_per_hostgroup_management true ``` After that you can enable it only for specific hostgroup: ``` sudo fcli set hostgroup global enable_bgp_flow_spec true ``` For testing purposes we can prepare custom announce (please replace our example addresses here by your real addresses specified in networks list) ``` sudo fcli set flowspec '{ "source_prefix": "4.0.0.0/32", "destination_prefix": "127.0.0.0/32", "destination_ports": [ 80 ], "source_ports": [ 53, 5353 ], "packet_lengths": [ 777, 1122 ], "protocols": [ "tcp" ], "fragmentation_flags": [ "is-fragment", "dont-fragment" ], "tcp_flags": [ "syn" ], "action_type": "rate-limit", "action": { "rate": 1024 } }' ``` Then check that it appeared in list of blocked traffic rules: ``` sudo fcli show flowspec ``` And check BGP daemon output: ``` gobgp global rib -a ipv4-flow ``` Output should be like this: ``` Network Next Hop AS_PATH Age Attrs *> [destination:127.0.0.0/24][source:4.0.0.0/24][protocol: tcp][destination-port: =80][source-port: =53 =5353][tcp-flags: syn][packet-length: =777 =1122][fragment: is-fragment dont-fragment]fictitious 00:01:36 [{Origin: ?} {Extcomms: [discard]}] ``` We have multiple flags to exclude specific fields from flow spec rule generation and you can enable them if you prefer: ``` sudo fcli set main flow_spec_do_not_process_ip_fragmentation_flags_field false sudo fcli set main flow_spec_do_not_process_length_field false sudo fcli set main flow_spec_do_not_process_source_address_field false sudo fcli set main flow_spec_do_not_process_tcp_flags_field false ``` Starting from 2.0.367 you can enable logic to strip source and destination ports when fragmentation flag is-fragment is present. ``` sudo fcli set main flow_spec_strip_ports_for_fragmented_traffic true sudo fcli commit ``` It's required for Arista's [BGP](https://www.arista.com/en/um-eos/eos-border-gateway-protocol-bgp "BGP") implementation because of following hardware limitations: ``` For fragment flags, only the Is a fragment (IsF) bit is supported only for IPv4 packets. Combining source and destination ports and the Fragment flags in the same rule is not supported ``` To configure BGP Flow spec on router side you can use our official guides for flowing vendors: - [Cisco ASR 1000](https://fastnetmon.com/bgp-flow-spec-configuration-on-cisco-asr1000/) By default FastNetMon executes full validation for all Flow Spec announces using following logic: - Source and destination prefix should be exactly /32 - Source or destination prefix should belong to networks\_list If you accept risks related with injection of wide unrestricted rules you could disable validation this way: ``` sudo fcli set main flow_spec_execute_validation disable sudo fcli commit ``` FastNetMon can do variety of actions when it creates new BGP Flow spec filtering rule: - [Email alerts](https://fastnetmon.com/fastnetmon-e-mail-notification/) - [Script call](https://fastnetmon.com/notify-script-in-bash/) - [JSON script call](https://fastnetmon.com/fastnetmon-advanced-json-notify-script-in-python/) - [Web callback](https://fastnetmon.com/example-web-hook-receiver-for-fastnetmon-advanced/) - [InfluxDB / Grafana alert](https://fastnetmon.com/fastnetmon-attack-notification-in-grafana/) IPv6 support for Flow Spec mode is not available but it has high priority on our [roadmap](https://features.fastnetmon.com/feature-requests/p/ipv6-support-for-bgp-flow-spec-mode). If you run BGP Flow Spec mitigation in environment with constrained bandwidth you may be in position when BGP Blackhole may be needed to avoid network overload. In this case you can configure BGP Blackhole logic using this [guide](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-bgp-blackhole-automation/). BGP Flow Spec uses same thresholds as BGP Blackhole and that's why these modes cannot be used in same time in fully automated mode but you can manually run bgp blackhole commend manually this way even if you run BGP Flow Spec mode: ``` sudo fcli set blackhole 1.2.3.4 ``` After these actions FastNetMon will announce BGP Blackhole announce for affected host and will stop generating BGP Flow Spec rules. As an option to automate this logic you can use this [script](https://fastnetmon.com/docs-fnm-advanced/escalation-script-for-fastnetmon-advanced/). BGP Flow Spec is an RFC standard which works smoothly with majority of vendors on market but for some vendors you may need to use vendor specific flags. On 6Wind VSR you may experience issues with BGP Flow Spec rules containing more then 1 port. FastNetMon itself does not use such rules and it will work with with following router. Huawei routers may not accept BGP Flow Spec announces which have TCP Flags and IP fragmentation flags unless you specify following options in FastNetMon configuration: ``` sudo fcli set main flow_spec_fragmentation_options_use_match_bit true sudo fcli set main flow_spec_tcp_options_use_match_bit true sudo fcli commit ``` Some models of Arista ("Unsupported Match - Fragment Flags") and Extreme routers have no ability to accept BGP Flow Spec announces which include IP fragmentation flags. To stop FastNetMon's attack mitigation engine from using these fields you can set following flags: ``` sudo fcli set main flow_spec_do_not_process_ip_fragmentation_flags_field true sudo fcli commit ``` Optionally you can disable only do not fragment flag processing this way and keep other IP flags intact (available starting from 2.0.366): ``` sudo fcli set main flow_spec_ignore_do_not_fragment_flag true sudo fcli commit ``` In addition to standard actions such as accept, discard or rate-limit we have option to specify single or multiple next hop addresses as target. It based on following [RFC draft](https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-redirect-ip-01) and can be enabled following way: ``` sudo fcli set main gobgp_flow_spec_next_hop_ipv4 10.3.44.6 sudo fcli set main gobgp_flow_spec_next_hop_ipv4 10.3.44.7 sudo fcli commit ``` Optionally you can inject such next hops manually: ``` sudo fcli set flowspec '{ "source_prefix": "4.0.0.0/32", "destination_prefix": "127.0.0.0/32", "destination_ports": [ 80 ], "source_ports": [ 53, 5353 ], "packet_lengths": [ 777, 1122 ], "protocols": [ "tcp" ], "fragmentation_flags": [ "is-fragment", "dont-fragment" ], "tcp_flags": [ "syn" ], "action_type": "accept", "ipv4_nexthops": ["11.22.33.44"] }' ``` We're aware that Juniper support this capability in their routers. #### Flow Spec per rule traffic drop monitoring Starting from v2.0.385 you can monitor amount of traffic dropped by each Flow Spec rule this way: ``` sudo fcli show flowspec_drop_counters_v4 UUID ``` Example output: ``` dropped_in_bytes 0 dropped_in_packets 0 dropped_out_bytes 0 dropped_out_packets 0 fragmented_in_bytes 0 fragmented_in_packets 0 fragmented_out_bytes 0 fragmented_out_packets 0 icmp_in_bytes 0 icmp_in_packets 0 icmp_out_bytes 0 icmp_out_packets 0 in_bytes 11396733 in_flows 0 in_packets 12523 out_bytes 0 out_flows 0 out_packets 0 tcp_in_bytes 0 tcp_in_packets 0 tcp_out_bytes 0 tcp_out_packets 0 tcp_syn_in_bytes 0 tcp_syn_in_packets 0 tcp_syn_out_bytes 0 tcp_syn_out_packets 0 udp_in_bytes 11396733 udp_in_packets 12523 udp_out_bytes 0 udp_out_packets 0 ``` #### Flow Spec per IP traffic drop monitoring Starting from v2.0.385 you can get total amount of traffic bandwidth filtered by all Flow Spec rules for particular IP address: ``` sudo fcli show flowspec_host_drop_counters_v4 1.2.3.4 ``` Example output: ``` dropped_in_bytes 0 dropped_in_packets 0 dropped_out_bytes 0 dropped_out_packets 0 fragmented_in_bytes 0 fragmented_in_packets 0 fragmented_out_bytes 0 fragmented_out_packets 0 icmp_in_bytes 0 icmp_in_packets 0 icmp_out_bytes 0 icmp_out_packets 0 in_bytes 0 in_flows 0 in_packets 0 out_bytes 4463256 out_flows 0 out_packets 4793 tcp_in_bytes 0 tcp_in_packets 0 tcp_out_bytes 0 tcp_out_packets 0 tcp_syn_in_bytes 0 tcp_syn_in_packets 0 tcp_syn_out_bytes 0 tcp_syn_out_packets 0 udp_in_bytes 0 udp_in_packets 0 udp_out_bytes 4463256 udp_out_packets 4793 ``` **Document Categories:** Mitigation modes --- ### [FastNetMon Advanced Traffic Persistence](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-traffic-persistency/) **Published:** December 9, 2017 **Author:** Pavel Odintsov **Content:** ### Introduction FastNetMon has bundled ability to store all traffic inside a special column-oriented database. You could store all traffic inside it and retrieve it using a well-known SQL syntax. ### System requirements You should have a working instance of FastNetMon before using this guide. Also, you need to install [visual traffic stack](https://fastnetmon.com/advanced-visual-traffic/) because we use Grafana for traffic persistence. ### Configure FastNetMon to store traffic in the traffic database ``` sudo fcli set main traffic_db_host 127.0.0.1 sudo fcli set main traffic_db_port 8100 sudo fcli set main traffic_db enable sudo fcli commit ``` If you run port mirror mode, you may need to adjust this value, which has the purpose of reducing load on the database and sampling all incoming data in addition to the sampling rate configured on port mirror plugin side. If you run port mirror with a reasonable sampling rate, then you can set this value to 1. ``` sudo fcli set main traffic_db_sampling_rate 1 sudo fcli commit ``` And start traffic\_db daemon: ``` sudo systemctl restart traffic_db ``` Traffic database daemon uses its own configuration file /etc/fastnetmon/traffic\_db.conf, and you can change default options as follows: ``` { "traffic_db_host":"127.0.0.1", "traffic_db_port": 8100, "clickhouse_batch_size": 1000, "clickhouse_batch_delay": 1, "clickhouse_queue_max_batches": 64, "clickhouse_host": "127.0.0.1", "clickhouse_port": 9000, "clickhouse_user": "default", "clickhouse_password": "", "clickhouse_database_name": "fastnetmon", "clickhouse_table_name": "traffic", "logging_level": "info", "prometheus_enabled": false, "prometheus_host": "127.0.0.1", "prometheus_port": 9091 } ``` Please note that options clickhouse\_database\_name and clickhouse\_table\_name were added in 2.0.363. Starting from 2.0.385 you can specify TLS credentials: ``` { "clickhouse_tls": true, "clickhouse_tls_ca_paths": [ "/tmp/ca.crt" ], "clickhouse_tls_client_auth": false, "clickhouse_tls_client_certificate_path": "/tmp/cert.ssl", "clickhouse_tls_client_certificate_private_key_path": "/tmp/cert.key" "clickhouse_disable_certificate_checks": false, } ``` To enable client side TLS authentication you need to enable clickhouse\_tls\_client\_auth and provide paths for certificate and private key for it using clickhouse\_tls\_client\_certificate\_path and clickhouse\_tls\_client\_certificate\_private\_key\_path. For testing only you can use flag clickhouse\_disable\_certificate\_checks to disable certificate checks entirely The `traffic_db` daemon writes traffic records to ClickHouse in batches. The `clickhouse_batch_size` option controls how many records should be accumulated before sending them to ClickHouse. The `clickhouse_batch_delay` option controls the maximum time, in seconds, to wait before flushing the current batch, even if it has not reached `clickhouse_batch_size` yet. A batch is inserted when either the configured batch size is reached, or the configured delay expires. After making any changes, you need to restart the daemon. ``` sudo systemctl restart traffic_db ``` Starting from 2.0.381 we added logic to insert traffic batches using queue (only one insert operation in time), maximum number of entities in queue controlled using clickhouse\_queue\_max\_batches (default value 64). In case of Clickhouse performance issues when number of entries exceeds 64 we drop entire batch and write following message to log file /var/log/fastnetmon/traffic\_db.log: ``` ClickHouse queue is full, dropping oldest batch. Total batches dropped: 1 total packets dropped: 1000 ``` Version 2.0.380 is known to have issue which caused concurrent inserts in Clickhouse which were reflected with following messages in /var/log/fastnetmon/traffic\_db.log: ``` [ERROR] Failed to push data to clickhouse: cannot execute query while inserting, use SendInsertData instead ``` In this case we strongly recommend upgrading to 2.0.381 which includes queue based Clickhouse insert logic. ### Making example queries Start client: ``` clickhouse-client --host 127.0.0.1 ``` Example query: ``` select * from fastnetmon.traffic limit 10; ``` Execute ASN query: ``` use fastnetmon SELECT dstAsn, count(dstAsn) AS cnt FROM traffic GROUP BY dstAsn  ORDER BY cnt DESC  LIMIT 10 ``` As output, you could find the number of packets per destination ASN for required time slice. ![](https://fastnetmon.com/wp-content/uploads/2017/12/asn-report-300x240.png)Clickhouse has logic (TTL) in place to [remove data](https://fastnetmon.com/docs-fnm-advanced/data-retention-for-clickhouse-persistent-data-storage/) which is older than 7 days. You can find the SQL schema for traffic table in our GitHub [repo](https://github.com/FastNetMon/clickhouse_schema/blob/main/schema/traffic.sql). PacketDirection uses the following integers to encode directions: - Incoming 0 - Outgoing 1 - Internal 2 - Other 3 Source uses the following integers to encode the plugin which captured traffic: - Unknown 0 - Mirror 1 - sFlow = 2 - Netflow / IPFIX = 3 - FastNetMon Flow = 4 Default schema uses index configuration, which may not provide the best performance for all types of queries. You can alter the index configuration and then re-create the table using preferred index granularity and configuration for your case. You just need to keep all fields as-is. After making changes in schema you will need to restart the traffic\_db daemon this way: ``` sudo systemctl restart traffic_db ``` As another option to speed up certain queries, you can copy all data from the original traffic table to another table with a different index configuration using the MATERIALIZED VIEW capability: ``` CREATE MATERIALIZED VIEW fastnetmon.traffic_sampled ENGINE = MergeTree PARTITION BY packetDate ORDER BY (srcIp, dstIp, packetDate) TTL packetDate + toIntervalDay(7) SETTINGS index_granularity = 8192 populate as select * from fastnetmon.traffic WHERE rand() % 100 = 1; ``` In this example, we used sampling with rand() section to make queries even faster, but you can copy all the data without using sampling. ### Example dashboards Dashboards to access traffic flow information are installed by default when you install [visual traffic](https://fastnetmon.com/docs-fnm-advanced/advanced-visual-traffic/) stack. ![](https://fastnetmon.com/wp-content/uploads/2024/01/traffic_database-1024x486.png)If you're interested in peering per ASN traffic reports, we recommend using this [dashboard](https://fastnetmon.com/fastnetmon-asn-peering-reports/). In case of any issues with traffic\_db we recommend checking the following log file: /var/log/fastnetmon/traffic\_db.log **Document Categories:** Traffic reports --- ### [FastNetMon Advanced configuration for NetFlow and IPFIX](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-configuration-for-netflow-and-ipfix/) **Published:** April 14, 2019 **Author:** Pavel Odintsov **Content:** FastNetMon supports many different implementations of the standard NetFlow protocol: - NetFlow v5 - NetFlow v9 - IPFIX - NetFlow Lite - Inline monitoring services - Netstream - jFlow - cFlow You can enable NetFlow plugin this way: ``` sudo fcli set main netflow enable ``` Specify port for Netflow capture (2055 is the default port for the Netflow protocol). You may add multiple ports if you prefer: ``` sudo fcli set main netflow_ports 2055 ``` Then specify the interface for listening (0.0.0.0 is the default): ``` sudo fcli set main netflow_host 0.0.0.0 ``` To listen on IPv4 and IPv6 protocols on the same port, you need to set the host to the following value: ``` sudo fcli set main netflow_host :: sudo fcli commit ``` If you run any kind of firewall on your network or on a server with FastNetMon itself, you will need to allow traffic over ports you've added towards the machine with FastNetMon. FastNetMon could automatically [extract sampling rate](https://fastnetmon.com/fastnetmon-netflow-and-ipfix-sampling-configuration/) from Netflow v5, v9 and IPFIX, but in some rare cases, you should specify it explicitly ``` sudo fcli set main netflow_sampling_ratio 1 sudo fcli commit ``` The most important part of NetFlow / IPFIX configuration is the flow timeout setup. If you do not configure active and inactive flow timeouts correctly, then FastNetMon will not be able to calculate bandwidth correctly and traffic measurements will be wrong and it will lead to incorrect attack detection. As a safe default, we recommend setting the active and inactive flow timeout for routers to 30 seconds. We do not recommend setting timeouts to very low values, as it may overload the router's CPU. In addition to flow timeout setup on the router side, you need to adjust [average\_calculation\_time](https://fastnetmon.com/docs-fnm-advanced/what-is-average_calculation_time/) value on FastNetMon side. This value *must* exceed both active and inactive flow timeouts by a few seconds. In case of standard setup with both active and inactive timeouts set to 30 seconds, we can recommend setting it to 45: ``` sudo fcli set main average_calculation_time 45 sudo fcli commit ``` To simplify flow duration configuration, we have official guides for multiple popular vendors below. You can confirm that the router uses the correct flow duration using this command ``` sudo fcli show system_counters|grep duration ``` Apply changes and restart the daemon: ``` sudo fcli commit ``` After these steps, you need to configure Netflow / IPFIX on the agent’s side (switch, router, server) to the configured port. If you run Juniper MX, Cisco ASR 9000, Cisco NSC 5500-based routers, we recommend using modern protocols such as IPFIX 315 and Inline Monitoring services as both of them offer the best detection speed and provide excellent traffic bandwidth calculation accuracy. You may find a detailed [configuration guide](https://fastnetmon.com/docs-fnm-advanced/netflow-lite-and-ipfix-inline-monitoring-services/) here. Otherwise, please follow the guides below. We have detailed guides for the following vendors: - [Juniper inline monitoring services](https://fastnetmon.com/docs-fnm-advanced/netflow-lite-and-ipfix-inline-monitoring-services/) (recommended) - [Juniper IPFIX](https://fastnetmon.com/docs/junos_integration/) - [Cisco IPFIX 315](https://fastnetmon.com/docs-fnm-advanced/netflow-lite-and-ipfix-inline-monitoring-services/) (recommended) - [Cisco ASR 9000 Series Netflow](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-netflow-v9-configuration-for-cisco-asr-9000/) - [Cisco ASR 1000 Series Netflow](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-netflow-v9-configuration-for-cisco-asr-1000/) - [Nokia](https://fastnetmon.com/docs-fnm-advanced/nokia-netflow-v9-and-ipfix-configuration-for-fastnetmon-advanced/) - [Netgate TNSR](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-integration-with-tnsr-high-performance-router-and-vpn-concentrator/) - [Huawei](https://fastnetmon.com/huawei-routers-configuration-with-fastnetmon-advanced/) - [Mikrotik](https://fastnetmon.com/mikrotik/) - [A-10 Networks](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-ipfix-configuration-for-a-10-networks-thunder/) - [VyOS](https://fastnetmon.com/fastnetmon-vyos-netflow-configuration/) If you operate many devices which export Netflow or IPFIX, you may need better visibility about which device actually exports traffic to FastNetMon. To implement it, you will need to enable this flag: ``` sudo fcli set main netflow_count_packets_per_device true sudo fcli commit ``` And then you will be able to see the counter for the number of UDP packets received from each device using these commands: ``` sudo fcli show netflow9_packets_per_device sudo fcli show netflow5_packets_per_device sudo fcli show ipfix_packets_per_device ``` On deployments with a significant amount of Netflow / IPFIX traffic, you may face issues with UDP traffic drops due to UDP buffer overflow. You may detect such cases by increasing the number of the following counters: ``` sudo fcli show system_counters |grep global_system_rcvbuferrors; sleep 1; sudo fcli show system_counters |grep global_system_rcvbuferrors; ``` This counter is system-wide and if you have other UDP-based services on the machine, it will show drops for both services which makes debugging more complicated. To pinpoint traffic drop issues, we have an alternative option to read UDP traffic, which offers the option to count the number of packets dropped due to UDP buffer size issues: ``` sudo fcli set main netflow_socket_read_mode recvmsg sudo fcli commit ``` After that change, you will be able to see an additional system counter which counters packets dropped on FastNetMon's UDP socket: ``` sudo fcli show system_counters|grep drops netflow_ipfix_udp_packet_drops 0 ``` Unfortunately, there are cases where this counter does not track dropped packets, even if the drop occurred on FastNetMon's socket. If your network has a very large amount of Netflow traffic (50+ Mbits of telemetry), you may reach a limitation of a single CPU core for Netflow parsing, and in this case, you may not see all traffic. To confirm such cases, we recommend enabling the option to show custom thread names in htop (F2, Display options, Show custom thread names). ![](https://fastnetmon.com/wp-content/uploads/2023/08/overloaded_kernel-1-1024x193.png)Example look of saturated single coreFastNetMon has an option to run multiple threads for Netflow processing per port, and it can be enabled this way: ``` sudo fcli set main netflow_multi_thread_processing true sudo fcli set main netflow_threads_per_port 2 sudo fcli commit ``` After that, you will see that FastNetMon will spawn 2 threads and will spread traffic between them, and it will reduce CPU pressure on a particular CPU core. Unfortunately, traffic distribution between threads is not very predictable and may not be even. You may use more than 2 cores, but we recommend not setting it to a very large value as it will cause lock contention and slow processing. ![](https://fastnetmon.com/wp-content/uploads/2023/08/Screenshot-from-2023-08-23-22-22-11-1024x209.png)If you see significant differences in the amount of traffic each Netflow worker thread receives, you may consider using BPF-based load balancing logic (available starting from 2.0.348), which will distribute traffic evenly. You can enable it that way: ``` sudo fcli set main netflow_multi_thread_mode random sudo fcli commit ``` ## Can I use nfcapd or other NetFlow forwarders? Yes, you can. But all your devices should have a unique source\_id. Because we use agent\_ip + source\_id as a unique identifier for templates. If you use NetFlow forwarders/aggregators, they replace the agent’s IP with the forwarder’s IP, and you could encounter a template conflict. The result of this conflict could be very dangerous: completely incorrect traffic calculation and dangerously high risk of false positive alerts. ## Why are flow counters zero? If you use sampling, then due to [sampling theory](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-connection-tracking/) limitations, we cannot calculate the flow / second correctly. ## Can I limit devices which can send Netflow v5, v9 or IPFIX to FastNetMon? Starting from 2.0.373 you can specify a list of IP addresses of devices which can send traffic telemetry to FastNetMon in the following way: ``` sudo fcli set main ipfix_devices_allow_list 10.0.0.0.1 sudo fcli set main ipfix_devices_allow_list 10.0.0.0.2 sudo fcli set main netflow_v9_devices_allow_list 10.0.0.0.3 sudo fcli set main netflow_v5_devices_allow_list 10.0.0.0.4 sudo fcli commit ``` As soon as you add at least a single element into any of these lists, FastNetMon will start blocking telemetry from all IPs which do not belong to the list. ## IPFIX / Netflow v9 template conflict If you noticed errors like this in fastnetmon.log then you have very serious problems with accuracy of Netflow or IPFIX which imminently lead to full outage of FastNetMon: ``` 2026-03-01 00:02:27,683 [ERROR] Netflow v9 template 256 was updated for a.b.c.d_0 2026-03-01 00:02:27,683 [ERROR] Netflow v9 template update may be sign of RFC violation by vendor and if you observe this behaviour please reach support@fastnetmon.com and share information about your equipment ``` You can learn more information why it's bad and why it may happen [here](https://features.fastnetmon.com/feature-requests/p/fix-active-inactive-timeout-notification-logic) If you've recently upgraded software on your routers or switches it may be caused by change in number of fields from device side To address issue you need to shutdown FastNetMon: ``` sudo systemctl stop fastnetmon ``` Then you need to remove all Netflow and IPFIX template cache files in /var/cache/fastnetmon by re-creating it: ``` sudo mv /var/cache/fastnetmon ~/old_fastnetmon_cache sudo mkdir /var/cache/fastnetmon sudo chmod 600 /var/cache/fastnetmon sudo chown root:root /var/cache/fastnetmon ``` Then download ASN database and start FastNetMon again: ``` sudo fill_dictionaries sudo systemctl start fastnetmon ``` If tempalte conflict happens again please ensure to capture pcap of all data for Netflow v9 or IPFIX port for long period of time (few hours) to capture incident and share it with support@fastnetmon.com with comprehensive information about your switch / router vendor: ``` sudo tcpdump -w netflow_data.pcap -n 'udp dst port 2055' ``` What are the symptoms of this issue? Very long traffic calculation time and exceptionally high load on CPU or artificially large number of interfaces in interface counters ## Note about IPFIX on Juniper devices Some Juniper platforms, including the SRX340, may export total byte and packet counters in IPFIX records instead of delta counters. This behavior is incompatible with the standard semantics of the IPFIX `octetDeltaCount` and `packetDeltaCount` Information Elements, which are defined as delta counters in [RFC 5102](https://www.rfc-editor.org/rfc/rfc5102.html). As a result, traditional IPFIX export from affected Juniper devices produce incorrect traffic calculations. If this behavior is present on your Juniper device and the platform supports **Inline Monitoring (IMON)**, we recommend using IMON as the preferred option. Otherwise, please use **NetFlow v9 / J-Flow v9**, which exports delta counters and does not have this issue. This behavior is not limited to the SRX340 and may apply to other Juniper platforms using the same IPFIX export implementation. **Document Categories:** Netflow and IPFIX --- ### [FastNetMon and BGP traffic diversion](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-and-bgp-traffic-diversion/) **Published:** August 3, 2022 **Author:** Pavel Odintsov **Content:** In addition to the option to announce /32 or /128 hosts which are under attack, FastNetMon can announce whole networks where the attacked host is located. It may be useful for DDoS scrubbing centre diversion or internal network policy changes (i.e. to move the prefix under attack to in-house scrubbing or move it to another ISP). We made multiple changes to the BGP announces logic in subnet mode. Please [ensure](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-upgrade-procedure/) that you run at least 2.0.363 before starting with this guide. To start with, you need to have a BGP session up and running as documented [here](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-bgp-unicast-configuration/). To enable prefix announces, you can usethe following option for IPv4: ``` sudo fcli set main gobgp_announce_whole_subnet true ``` And following for IPv6: ``` sudo fcli set main gobgp_announce_whole_subnet_ipv6 true ``` Then you need to set a list of one or more communities for each case. For IPv4: ``` sudo fcli set main gobgp_communities_subnet_ipv4 65004:445 sudo fcli set main gobgp_communities_subnet_ipv4 65004:447 ``` For IPv6: ``` sudo fcli set main gobgp_communities_subnet_ipv6 65004:445 sudo fcli set main gobgp_communities_subnet_ipv6 65004:447 ``` By default, FastNetMon will use exact same prefix length as specified in networks\_list. I.e. if you've specified a prefix as /21 and then host from this network as attacked, then it will be announced as /21. We have an option to control the scope of such announces, and you can easily set it to the required boundary, such as /24 (external DDoS Scrubbing case): ``` sudo fcli set main gobgp_announce_whole_subnet_force_custom_prefix_length true sudo fcli set main gobgp_announce_whole_subnet_custom_prefix_length 24 ``` For IPv6, it will look like the following: ``` sudo fcli set main gobgp_announce_whole_subnet_force_custom_ipv6_prefix_length true sudo fcli set main gobgp_announce_whole_subnet_custom_ipv6_prefix_length 48 ``` After this, specify the next hop only for subnet announces: ``` sudo fcli set main gobgp_next_hop_subnet_ipv4 1.2.3.4 sudo fcli set main gobgp_next_hop_subnet_ipv6 dead::beef sudo fcli commit ``` As an alternative option, FastNetMon has the capability to announce a list of networks when their total traffic exceeds a defined threshold value using [BGP alerts for total ](https://fastnetmon.com/bgp-announces-for-total-hostgroups/)[hostgroups](https://fastnetmon.com/bgp-announces-for-total-hostgroups/). Starting from 2.0.363, you can assign custom BGP Communities for each hostgroup this way: ``` sudo fcli set hostgroup aaa bgp_communities_subnet_ipv4 65001:772 sudo fcli commit ``` Starting from 2.0.364, you can specify a custom next hop for announces for each hostgroup: ``` sudo fcli set hostgroup aaa bgp_next_hops_subnet_ipv4 1.2.3.4 sudo fcli commit ``` Starting from 2.0.367, you can specify a custom AS\_PATH in the following way: ``` sudo fcli set main gobgp_as_path_subnet_ipv4 12345 sudo fcli set main gobgp_as_path_subnet_ipv4 56789 sudo fcli commit ``` Alternatively, you can provide a custom AS\_PATH for each hostgroup: ``` sudo fcli set hostgroup global bgp_as_path_subnet_ipv4 12345 sudo fcli set hostgroup global bgp_as_path_subnet_ipv4 56789 sudo fcli commit ``` Starting from 2.0.384 you can specify AS\_PATH to total hostgroups BGP announces this way: ``` sudo fcli set main gobgp_as_path_hostgroup_networks_ipv4 12345 sudo fcli set main gobgp_as_path_hostgroup_networks_ipv4 56789 sudo fcli set main gobgp_as_path_hostgroup_networks_ipv6 12345 sudo fcli set main gobgp_as_path_hostgroup_networks_ipv6 56789 sudo fcli set hostgroup my_networks bgp_as_path_hostgroup_networks_ipv4 12345 sudo fcli set hostgroup my_networks bgp_as_path_hostgroup_networks_ipv6 12345 sudo fcli commit ``` #### Automatic next hop detection Starting from 2.0.385 we added option to get next hop for whole subnet announces from incoming BGP announce. It can be enabled this way: ``` sudo fcli set main gobgp_announce_whole_subnet_mirror_next_hop_ipv4 true ``` Then you need to specify peer name to read incoming BGP announce from: ``` sudo fcli set main gobgp_announce_whole_subnet_mirror_peer_name_ipv4 peer_name sudo fcli commit ``` After making these changes FastNetMon will try getting next hop from incoming announce, in case of success you will see following entries in /var/log/fastnetmon/fastnetmon.log: ``` Mirrored next hop for IPv4 subnet 10.0.0.0/24 is 10.10.10.10 ``` In case of failure it will be this way: ``` Could not retrieve mirrored next hop for IPv4 subnet ... ``` **Document Categories:** BGP --- ### [FastNetMon Advanced manual deployment on Docker platform](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-manual-deployment-on-docker-platform/) **Published:** April 19, 2023 **Author:** Pavel Odintsov **Content:** To store state data and configuration, FastNetMon uses MongoDB, and we will need to install it first. You can deploy FastNetMon on Docker using our official Docker images. To keep MongoDB data and FastNetMon configuration and state, we will use folders from the host, and we need to create them in the following way: ``` sudo mkdir /var/lib/fastnetmon_docker ``` And then create folders for MongoDB: ``` sudo mkdir /var/lib/fastnetmon_docker/mongodb sudo mkdir /var/lib/fastnetmon_docker/mongodb/data ``` And then create folders for FastNetMon: ``` sudo mkdir /var/lib/fastnetmon_docker/fastnetmon sudo mkdir /var/lib/fastnetmon_docker/fastnetmon/logs sudo mkdir /var/lib/fastnetmon_docker/fastnetmon/conf sudo mkdir /var/lib/fastnetmon_docker/fastnetmon/conf/keychain ``` First of all, we need to create a private network to use between FastNetMon and MongoDB for additional security: ``` sudo docker network create fastnetmon-network ``` Check that the network was created successfully: ``` sudo docker network ls ``` Example output: ``` NETWORK ID NAME DRIVER SCOPE 684149c93997 bridge bridge local 3598a7913410 fastnetmon-network bridge local a4eebee9cf76 host host local 9a2c93f8408a none null local ``` Then pull the latest MongoDB 6 image based on Ubuntu 22.04: ``` sudo docker pull mongo:latest ``` Then generate a password for MongoDB: ``` MONGO_PASSWORD=`printf "%s" $(pwgen 16 1)` ``` Save it to the FastNetMon configuration for fcli and the FastNetMon daemon: ``` echo -n $MONGO_PASSWORD | sudo tee /var/lib/fastnetmon_docker/fastnetmon/conf/keychain/.mongo_fastnetmon_password ``` And then run it: ``` sudo docker run --name mongo-server.networkd --network fastnetmon-network -p 127.0.0.1:27017:27017/tcp -v /var/lib/fastnetmon_docker/mongodb/data:/data/db --restart always -e MONGO_INITDB_ROOT_USERNAME=administrator -e MONGO_INITDB_ROOT_PASSWORD=$MONGO_PASSWORD -d mongo:latest ``` Then confirm that MongoDB is running fine: ``` sudo docker exec -it mongo-server.networkd mongosh --authenticationDatabase admin --username administrator -password `cat /var/lib/fastnetmon_docker/fastnetmon/conf/keychain/.mongo_fastnetmon_password` --eval 'db.version()' ``` The next step is to configure FastNetMon: Put the following data to /var/lib/fastnetmon\_docker/fastnetmon/conf/fastnetmon.conf: ``` { "mongodb_host": "mongo-server.networkd", "mongodb_port": 27017, "mongodb_database_name": "fastnetmon", "mongodb_username": "administrator", "mongodb_auth_source": "admin" } ``` Then pull FastNetMon Advanced image: ``` sudo docker pull fastnetmon/fastnetmon-advanced:latest ``` Then we need to run the fcli command line tool to create a configuration in MongoDB; we need to do it before running FastNetMon: ``` sudo docker run --network fastnetmon-network -v /var/lib/fastnetmon_docker/fastnetmon/conf:/etc/fastnetmon fastnetmon/fastnetmon-advanced:latest fcli create_configuration ``` Then check that the configuration is present: ``` sudo docker run --network fastnetmon-network -v /var/lib/fastnetmon_docker/fastnetmon/conf:/etc/fastnetmon fastnetmon/fastnetmon-advanced:latest fcli show main api_host ``` Then, enable local API to bind on all available interfaces; we need it to have access to the internal API from fcli: ``` sudo docker run --network fastnetmon-network -v /var/lib/fastnetmon_docker/fastnetmon/conf:/etc/fastnetmon fastnetmon/fastnetmon-advanced:latest fcli set main api_host 0.0.0.0 ``` Then, finally, run FastNetMon: ``` sudo docker run --name fastnetmon-server.networkd --cap-add=NET_ADMIN --cap-add=CAP_IPC_LOCK --network fastnetmon-network -p "0.0.0.0:6343:6343/udp" -p "0.0.0.0:2055:2055/udp" -v /var/lib/fastnetmon_docker/fastnetmon/logs:/var/log/fastnetmon -v /var/lib/fastnetmon_docker/fastnetmon/conf:/etc/fastnetmon --restart always -d --init fastnetmon/fastnetmon-advanced:latest ``` If you do not have plans to use port mirror or AF\_XDP-based capture, then you can skip NET\_ADMIN and CAP\_IPC\_LOCK flags. Then you can confirm that FastNetMon is running correctly using this command: ``` ps aux|grep fastnetmon ``` Example output: ``` root 11145 0.0 0.0 1112 4 ? Ss 17:03 0:00 /sbin/docker-init -- /bin/sh -c exec /opt/fastnetmon/app/bin/fastnetmon root 11195 0.0 0.2 801120 32964 ? Sl 17:03 0:00 /opt/fastnetmon/app/bin/fastnetmon ``` If you have any issues, you may check the content of the log file: /var/lib/fastnetmon\_docker/fastnetmon/logs/fastnetmon.log If you need to change the configuration of FastNetMon, then instead of sudo fcli commit, you need to restart the container with FastNetMon in the following way: ``` sudo docker restart fastnetmon-server.networkd ``` Finally, connect to FastNetMon internal API and MongoDB at the same time from fcli: ``` sudo FASTNETMON_API_HOST=fastnetmon-server.networkd docker run -e FASTNETMON_API_HOST --network fastnetmon-network -v /var/lib/fastnetmon_docker/fastnetmon/conf:/etc/fastnetmon fastnetmon/fastnetmon-advanced:latest fcli show system_counters ``` You will see real-time counters from FastNetMon. Or you can run fcli in interactive mode: ``` sudo FASTNETMON_API_HOST=fastnetmon-server.networkd docker run -e FASTNETMON_API_HOST --network fastnetmon-network -v /var/lib/fastnetmon_docker/fastnetmon/conf:/etc/fastnetmon -it fastnetmon/fastnetmon-advanced:latest fcli ``` You may similarly run the API daemon using this command: ``` sudo FASTNETMON_API_HOST=fastnetmon-server.networkd HTTP_API_MODE=on docker run -e FASTNETMON_API_HOST -e HTTP_API_MODE --network fastnetmon-network -v /var/lib/fastnetmon_docker/fastnetmon/conf:/etc/fastnetmon -it fastnetmon/fastnetmon-advanced:latest fcli ``` **Document Categories:** Deployment --- ### [FastNetMon LiveView](https://fastnetmon.com/fastnetmon-liveview/) **Published:** September 17, 2026 **Author:** Outi Maria Pietilanaho **Content:** ## See what’s happening across your network **FastNetMon LiveView is the official web interface for FastNetMon Advanced.** Get a live operational view of your network, investigate DDoS attacks, explore traffic reports, and manage your FastNetMon configuration — all from your browser. **[Try FastNetMon LiveView](https://fastnetmon.com/how-to-get-fastnetmon-liveview/)** ![](https://fastnetmon.com/wp-content/uploads/2026/09/FastNetMon_LiveView-1024x577.png)## Real-time network visibility See what’s happening across your network in real time. LiveView provides continuously updated traffic dashboards and reports, with the ability to drill down across **networks, individual hosts, and ASNs**. Explore overall traffic, identify top talkers, and investigate unusual changes in network behaviour. ## Investigate DDoS attacks Keep active and historical DDoS attacks together in one place. LiveView lets you follow attacks as they happen and return to previous incidents for investigation and reporting. Drill into individual attacks to understand the traffic behind an event and support post-attack analysis. ## Manage FastNetMon from your browser Configure and manage FastNetMon directly through LiveView. Manage **detection thresholds, notifications, mitigation settings, user access, and other operational configuration** through the web interface, while retaining the flexibility of FastNetMon’s command-line tools. ## Built for day-to-day network operations LiveView brings **network monitoring, DDoS attack analysis, reporting, and FastNetMon configuration** into one interface, giving network and security teams a shared view of what’s happening across their infrastructure. ### See FastNetMon LiveView in action Watch our product walkthrough for a quick tour of the LiveView dashboard, traffic reports, attack investigation, and configuration. ## Try FastNetMon LiveView LiveView is available as an add-on for **FastNetMon Advanced** and can be added to an existing FastNetMon subscription. Want to see how it works with your network? **Contact our team** **at sales@fastnetmon.com or read how to upgrade [here](https://fastnetmon.com/how-to-get-fastnetmon-liveview/)**. --- ### [How to Get FastNetMon LiveView](https://fastnetmon.com/how-to-get-fastnetmon-liveview/) **Published:** September 17, 2026 **Author:** Outi Maria Pietilanaho **Content:** [FastNetMon LiveView](https://fastnetmon.com/fastnetmon-liveview/) is available as an add-on for **FastNetMon Advanced**. Whether you're ordering FastNetMon for the first time or adding LiveView to an existing installation, you can get started in a few steps. ### Ordering the LiveView Add-on **New FastNetMon customers** If you don't already have FastNetMon Advanced, you can compare options and order a license from our [**pricing page**](https://fastnetmon.com/pricing/). When ordering your FastNetMon Advanced license, select the **FastNetMon LiveView add-on** to include LiveView with your subscription. **Existing FastNetMon Advanced customers** If you already have an active FastNetMon Advanced license, you can add LiveView through your **[customer portal](https://fastnetmon.chargebee.com/portal/v2/login?forward=home)**. Open your active subscription, select **Edit subscription**, choose **Add add-ons**, and select the LiveView add-on. If needed, our [subscription upgrade guide](https://fastnetmon.com/fastnetmon-subscription-upgrade-process/) walks through the process step by step. ### Want to try LiveView first? For new customers, LiveView will be included in your FastNetMon Advanced trial by default. Existing FastNetMon customers can try LiveView with a **30-day trial** before adding it to their subscription. Contact us at **sales@fastnetmon.com**, and we'll help you get started. ### Installing FastNetMon LiveView Already purchased the LiveView add-on? Our [LiveView installation guide](https://fastnetmon.com/docs-fnm-advanced/web-user-interface-for-fastnetmon-advanced/) covers the requirements and configuration needed to enable LiveView, including the required FastNetMon Advanced version, database requirements, API configuration, user setup, and starting the LiveView service. **Prefer a video walk-through?** We've also created [a step-by-step video](https://youtu.be/KNJcU4qRRBc?si=85-QzVm6GkiRxIVn) showing how to upgrade an existing FastNetMon Advanced installation to use LiveView. ### Need help? If you're unsure which option applies to your FastNetMon installation or need help ordering LiveView, contact our team at **sales@fastnetmon.com**. --- ### [FastNetMon Advanced: Network-Level DDoS Defence and Monitoring](https://fastnetmon.com/product-overview/) **Published:** March 22, 2017 **Author:** FastNetMon **Content:** FastNetMon provides real-time visibility into network traffic by collecting telemetry from routers and switches using sFlow, NetFlow, IPFIX, jFlow and mirrored traffic. Traffic is analysed continuously to establish a baseline of normal behaviour and to identify abnormal patterns associated with L3 and L4 attacks. [Detection](https://fastnetmon.com/ddos-detection-and-mitigation/) happens within seconds, allowing operators to identify volumetric floods, packet-rate spikes and abnormal flow behaviour early. FastNetMon is built for high-throughput environments and can scale to terabits of traffic and millions of flows per second on commodity hardware, supporting both IPv4 and IPv6 across diverse network topologies. ## **Automated DDoS Mitigation** FastNetMon combines fast detection with automated response, enabling mitigation actions to be triggered directly at the network layer as soon as an attack is identified. This removes reliance on manual workflows during incidents and ensures that response is consistent, fast and repeatable. Mitigation is implemented using standard routing and traffic-control mechanisms already present in service provider and enterprise networks, allowing FastNetMon to integrate seamlessly into existing operational models. ## **BGP BlackHole and RTBH Automation** When an attack exceeds defined thresholds, FastNetMon can [automatically announce BGP BlackHole ](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-bgp-blackhole-automation/)(RTBH) routes for the affected prefixes. This allows malicious traffic to be dropped upstream or within the network, preventing attack traffic from reaching protected infrastructure. Automation ensures that blackholing is applied quickly and only when required, reducing response time and operational overhead. FastNetMon works with existing BGP sessions and commonly used blackhole communities, making it suitable for ISP, hosting and large enterprise environments without introducing proprietary routing dependencies. Read more about the RTBH capability [here](https://fastnetmon.com/bgp-blackhole-automation/). ## **BGP FlowSpec-Based Traffic Filtering** For attacks where full blackholing is too disruptive, [FastNetMon supports BGP Flow Spec](https://fastnetmon.com/flowspec-ddos-mitigation/) to apply fine-grained traffic filtering rules directly on FlowSpec-capable routers. This allows mitigation policies to target specific protocols, ports or packet characteristics associated with an attack. By filtering only the malicious traffic, FlowSpec helps preserve availability for legitimate users and reduces collateral damage during complex or multi-vector DDoS events. ## **Scrubbing Centre Diversion Automation** FastNetMon [integrates with external scrubbing centres](https://fastnetmon.com/ddos-scrubbing-centre-diversion/) to automatically divert attack traffic for cleaning while allowing legitimate traffic to continue flowing normally. Traffic diversion is triggered only when an attack is detected and automatically withdrawn once conditions return to normal. This approach enables significant cost savings by eliminating the need for always-on scrubbing. Only malicious traffic is sent to the scrubbing provider, reducing scrubbing capacity requirements and associated costs. At the same time, legitimate traffic avoids unnecessary detours, resulting in lower latency and better user experience during both normal operation and attack conditions. ## **Broad Vendor and Infrastructure Support** FastNetMon is designed for real-world, multi-vendor networks and relies on standard telemetry and routing protocols rather than proprietary integrations. It works with networking equipment from major vendors used in service provider and enterprise environments, including Cisco, Juniper, Nokia, Huawei, Arista and others. Support for standard flow export protocols and BGP allows FastNetMon to integrate into existing infrastructure with minimal friction and no vendor lock-in. ## **And More** Beyond its core role as a network-level DDoS detection and mitigation platform, FastNetMon includes additional capabilities that extend visibility and control across modern environments: - [FastNetMon LiveView](https://fastnetmon.com/fastnetmon-liveview/): The official FastNetMon web interface with real-time traffic dashboards, attack data and history, and system configuration. - [Blocklist-based traffic filtering](https://fastnetmon.com/blocklist-filtering/) - Traffic visibility for [AWS](https://fastnetmon.com/aws-network-analytics/) and [Google Cloud ](https://fastnetmon.com/google-cloud-network/)environments - Historical traffic analysis and Grafana dashboards - [Embeddabe solutions](https://fastnetmon.com/embeddable-solutions/) These features complement the core platform while keeping the primary focus on fast, automated defence against L3 and L4 DDoS attacks. ## **Get Started** [FastNetMon Advanced](https://fastnetmon.com/fastnetmon-advanced/) is ideal for telcos, ISPs, cloud providers and enterprise networks seeking **fast, automated, network-level DDoS defence** with wide vendor support and integration into existing infrastructure. [Start a free trial](https://fastnetmon.com/trial/) or [contact us ](https://fastnetmon.com/contact/)for more information. **Document Categories:** Introduction --- ### [FastACL Administrator CLI Reference](https://fastnetmon.com/docs-fnm-advanced/fastacl-administrator-cli-reference/) **Published:** September 16, 2026 **Author:** Outi Maria Pietilanaho **Content:** FastACL is an inline packet-filtering plugin for [FD.io VPP](https://fd.io/). It receives traffic diverted to a scrubbing appliance, matches it against an ordered set of [RFC 8955](https://www.rfc-editor.org/rfc/rfc8955.html) (IPv4) / [RFC 8956](https://www.rfc-editor.org/rfc/rfc8956.html) (IPv6) FlowSpec rules, and applies an action — drop, rate-limit, or DSCP re-mark — to matching packets while forwarding the rest untouched. This document is the operator reference: everything a system administrator needs to configure, run, and monitor FastACL from the VPP CLI. All commands are issued through `vppctl` (either `vppctl ` or interactively inside `vppctl`). ## 1. Concepts - **Rule** — an ordered match/action entry. A packet is tested against all rules; the highest-precedence matching rule decides its fate. - **Order** — the operator-assigned precedence of a rule (`order `). Lower order wins. Ties are broken by RFC 8955 §5.1 FlowSpec precedence, then by insertion order. - **Index** — the internal slot a rule occupies, shown in the `Index` column of `show fastacl rules`. `fastacl rule del` takes the index, not the order. - **Match** — one or more components (destination prefix, ports, TCP flags, …). A rule matches only when all its components match. - **Action** — what happens to a matching packet: `drop`, `rate-limit`, or `dscp-mark`. - **TSS classifier** — internally, rules that share the same shape (which fields they match on) are grouped into a "tuple" and looked up in a hash, so lookup cost scales with the number of distinct rule shapes, not the number of rules. This is transparent to the operator but visible in `show fastacl tuples`. - **Datapath modes** — FastACL runs in either bridge mode (transparent L2 cross-connect between two ports) or routed mode (on the IPv4/IPv6 unicast path). The same rules and commands apply to both; only the interface wiring differs (see §3). ## 2. Startup configuration FastACL is a VPP plugin. Enable it and optionally tune it in `/etc/vpp/startup.conf`: ``` plugins { plugin fastacl_plugin.so { enable } } fastacl { tss-bihash-buckets 65536 tss-bihash-memory-mb 128 } ``` | Stanza key | Default | Meaning | |---|---|---| | `tss-bihash-buckets ` | 65536 | Hash buckets allocated per rule-shape (tuple). Raise for very large rule sets. Values below 1024 are clamped up. | | `tss-bihash-memory-mb ` | 128 | Memory cap (MB) per tuple hash. Values below 1 are clamped up. | The `fastacl { }` stanza is optional; with no stanza the defaults above apply. Changes take effect at VPP start. ## 3. Enabling the filter on an interface The filter is armed per interface. Nothing is filtered until you enable it. ``` set interface fastacl [enable | disable] ``` `enable` is the default when neither keyword is given. Enabling attaches the filter to both the routed (`ip4-unicast` / `ip6-unicast`) and bridged (`l2-input`) arcs of the interface; the unused arc stays dormant, so the same command works for both datapath modes. **Bridge mode** — transparently filter traffic passing between two ports: ``` set interface l2 xconnect pg0 pg1 set interface l2 xconnect pg1 pg0 set interface fastacl pg0 set interface fastacl pg1 ``` **Routed mode** — filter on an interface's IP path: ``` set interface fastacl TenGigabitEthernet0/0/0 ``` List the interfaces that currently have the filter armed: ``` vpp# show fastacl interface pg0 pg1 ``` Disable on one interface: ``` vpp# set interface fastacl pg0 disable fastacl disabled on pg0 ``` ## 4. Managing rules ### 4.1 Add a rule Use the following syntax to add a rule: ``` fastacl rule add order [dst /] [dst6 /] [src /] [src6 /] [proto ] [dst-port [-]] [src-port [-]] [either-port [-]] [icmp-type ] [icmp-code ] [tcp-flags value mask ] [pkt-len [-]] [dscp ] [fragment ] | [fragment flags mask ] [flex-match offset len mask 0x value 0x [op ]] action {drop | dscp-mark <0-63> | rate-limit burst } [sample [group ]] ``` `order ` and an action are required; every match component is optional, but a rule with no match components matches all traffic. On success, the command prints the assigned index: ``` vpp# fastacl rule add order 10 dst 203.0.113.0/24 proto 17 dst-port 53 action drop rule index 0 added ``` See §5 for the match components and §6 for the actions. ### 4.2 Rule precedence Rules are evaluated by precedence and the lowest `order` value wins. Give your most specific / highest-priority rules the lowest order numbers. Leave gaps (10, 20, 30, …) so you can insert rules later without renumbering. ### 4.3 Delete a rule ``` fastacl rule del { | all} ``` `` is the value in the `Index` column of `show fastacl rules` — **not the order**. Deleting a non-existent index returns an error: ``` vpp# fastacl rule del 0 rule index 0 deleted vpp# fastacl rule del all all rules deleted vpp# fastacl rule del 999 fastacl rule del: fastacl_rule_del returned -6 ``` **Common mistake:** `fastacl rule del 50` when 50 was the rule's order deletes nothing (`returned -6`). Look up the index in `show fastacl rules` first. ### 4.4 Rebuild the index after a bulk load ``` fastacl rule-reindex ``` When rules are loaded in bulk through the binary API, run `rule-reindex` once afterward to rebuild the TSS lookup index: ``` vpp# fastacl rule-reindex reindexed: 10 rules, 8 tuples, .011 s ``` Rules added one at a time through `fastacl rule add` are indexed immediately and do not need this. ## 5. Match components All 12 RFC 8955/8956 match types are supported, for both IPv4 and IPv6. A rule matches only when every component present matches. | Keyword | Type | Semantics | Example | |---|---|---|---| | `dst /` | 1 | IPv4 destination prefix | `dst 203.0.113.0/24` | | `dst6 /` | 1 | IPv6 destination prefix | `dst6 2001:db8::/32` | | `src /` | 2 | IPv4 source prefix | `src 198.51.100.0/24` | | `src6 /` | 2 | IPv6 source prefix | `src6 2001:db8:a::/48` | | `proto ` | 3 | IP protocol / IPv6 next-header (exact) | `proto 17` (UDP) | | `dst-port [-]` | 4 | Destination port or range | `dst-port 80-443` | | `src-port [-]` | 5 | Source port or range | `src-port 1024-65535` | | `either-port [-]` | 6 | Source or destination port in range | `either-port 5000-6000` | | `icmp-type ` | 7 | ICMP / ICMPv6 type (exact) | `icmp-type 8` | | `icmp-code ` | 8 | ICMP / ICMPv6 code (exact) | `icmp-code 0` | | `tcp-flags value mask ` | 9 | TCP flags: match value over the masked bits | `tcp-flags value 0x02 mask 0x02` (SYN) | | `pkt-len [-]` | 10 | IP total length or range | `pkt-len 0-64` | | `dscp ` | 11 | DSCP value (exact, 0–63) | `dscp 46` | | `fragment ` | 12 | Fragment flags (see below) | `fragment 2` | | `flex-match …` | — | Arbitrary offset/mask/value (see §5.2) | See below | Ports and lengths accept either a single value (`dst-port 53`) or an inclusive range (`dst-port 80-443`). Protocol, DSCP, and ICMP type/code are exact matches. ### 5.1 Fragment flags `fragment ` matches the fragmentation state, where `` is the OR of: | Bit | Value | Meaning | |---|---|---| | DF | 1 | Don't-Fragment set | | IsF | 2 | Is a fragment (MF set, or offset > 0) | | FF | 4 | First fragment (MF set, offset == 0) | | LF | 8 | Last fragment (MF clear, offset > 0) | `fragment ` uses `` as both the required bits and the mask. For finer control use the explicit form `fragment flags mask `, e.g. `fragment flags 0x2 mask 0x2` to match "is a fragment" regardless of the other bits. Hex (`0x2`) and decimal (`2`) are both accepted. ### 5.2 Flexible match ``` flex-match offset len mask 0x value 0x [op ] ``` Reads `len` bits (8, 16, or 32) at byte `offset` from the start of the Ethernet frame, applies `mask`, and compares against `value` using operator `op`: | op | Comparison | |---|---| | 0 (default) | field == value | | 1 | field < value | | 2 | field > value | | 3 | low ≤ field ≤ high (`value` packs min in the low 16 bits, max in the high 16) | Up to 4 flex conditions may be combined in one rule. Example — match the two bytes at offset 34: ``` flex-match offset 34 len 16 mask 0xffff value 0x1234 ``` ## 6. Actions Every rule carries exactly one action. | Action | Effect | |---|---| | `drop` | Discard matching packets. | | `dscp-mark <0-63>` | Rewrite the packet's DSCP to the given value (0–63) and forward it. The IP checksum is fixed up automatically. | | `rate-limit burst ` | Police matching traffic to `` bits/sec with a `` token-bucket burst. Conforming packets are forwarded; excess is dropped. Policing is per-rule (not per-flow). | `dscp-mark` validates its argument — out of range is rejected: ``` vpp# fastacl rule add order 5 proto 6 action dscp-mark 99 fastacl rule add: dscp value must be 0-63 ``` Examples: ``` fastacl rule add order 10 dst 203.0.113.0/24 proto 17 dst-port 53 action drop fastacl rule add order 20 proto 6 dst-port 80-443 action rate-limit 1000000000 burst 262144 fastacl rule add order 30 src 198.51.100.0/24 action dscp-mark 46 ``` ### 6.1 Sampling modifier Append `sample [group ]` to any rule to mirror 1-in-N matching packets to the kernel psample channel (see §8). `group ` sets the psample group ID (default 0). ``` fastacl rule add order 100 proto 17 dst-port 123 action drop sample 1000 ``` ## 7. Monitoring and counters ### 7.1 List rules ``` vpp# show fastacl rules Index Order Dst Prefix Src Prefix Proto Match Extra Action Packets Bytes pps L3 bps L1 bps 0 10 203.0.113.0/24 * 17 dp=53 drop 0 0 0.0 pps 0.0 bps 0.0 bps 1 20 * * 6 dp=80-443 rate-limit 1 0 0 0.0 pps 0.0 bps 0.0 bps 2 30 * 198.51.100.0/24 * * dscp-mark 46 0 0 0.0 pps 0.0 bps 0.0 bps ``` The Action column is width-limited, so a long rate-limit rate is truncated in this view (e.g. `rate-limit 1` above is the 1 Gbps rule) — the configured value is unaffected. The Match Extra column encodes the non-prefix match components: `dp=` / `sp=` / `ep=` (dst/src/either port), `fl=value/mask` (TCP flags), `len=` (packet length), `frag=` (fragment flags), `icmp-t=` / `icmp-c=`, `flex(offset,len,mask,value,op)`. `*` means "any". When there are no rules the command prints `no rules configured`. The Packets / Bytes columns are the per-rule totals and pps / L3 bps / L1 bps are live rates. L3 bps is the IP-layer rate; L1 bps adds the on-the-wire framing overhead and matches what a traffic generator reports. This is the per-rule counter view — there is no separate counters command. ### 7.2 Aggregate counters ``` vpp# show fastacl aggregate-counters Aggregate counters: Packets Bytes pps L3 bps L1 bps Processed: 5 (5) 300 (300 B) 2.7 pps 1.3 Kbps 2.1 Kbps Dropped: 5 (5) 300 (300 B) 2.7 pps 1.3 Kbps 2.1 Kbps ``` Plugin-wide totals: Processed is everything the filter saw; Dropped is what a rule discarded. ### 7.3 Clear counters ``` vpp# clear fastacl counters counters cleared ``` Zeroes all per-rule and aggregate counters. Rules themselves are untouched. ### 7.4 TSS classifier state ``` vpp# show fastacl tuples tuples: 8, ipv6 fallback: 1 rules id flags dplen splen v6 rules buckets 0 0xd 24 0 0 1 0 1 0xc 0 0 0 2 0 ``` Diagnostic view of the internal classifier: one row per rule shape (tuple), how many rules share it, and the prefix lengths that define it. Useful for capacity planning — the number of tuples, not the number of rules, drives lookup cost. ## 8. Traffic sampling (psample) FastACL can mirror a fraction of matching packets to the Linux psample netlink channel, where tools such as `tcpdump` / `libpsample` consumers or a flow collector can read them. ``` fastacl psample {enable | disable} ``` Sampling requires the kernel psample module. If it is not loaded, enabling reports: ``` vpp# fastacl psample enable fastacl psample: psample netlink family not found - is the psample module loaded? ``` Load it with `modprobe psample` on the host first. Per-rule sampling is armed with the `sample [group ]` modifier on `fastacl rule add` (§6.1). Inspect sampling state and per-rule sample counts: ``` vpp# show fastacl sampling psample: disabled rule ratio group sampled send-failed 9 1:1000 0 0 0 ``` ## 9. Common operational recipes **Blackhole a victim prefix's DNS reflection traffic:** ``` fastacl rule add order 10 dst 203.0.113.0/24 proto 17 dst-port 53 action drop ``` **Rate-limit inbound HTTP/HTTPS to 1 Gbps:** ``` fastacl rule add order 20 proto 6 dst-port 80-443 action rate-limit 1000000000 burst 262144 ``` **Drop TCP SYN floods to a host:** ``` fastacl rule add order 30 dst 203.0.113.10/32 proto 6 tcp-flags value 0x02 mask 0x02 action drop ``` **Drop small-packet floods (≤ 64-byte frames):** ``` fastacl rule add order 40 pkt-len 0-64 action drop ``` **Drop an IPv6 ICMPv6 echo flood:** ``` fastacl rule add order 50 dst6 2001:db8::/32 proto 58 icmp-type 128 action drop ``` **Watch the effect, then clear the stats:** ``` show fastacl rules show fastacl aggregate-counters clear fastacl counters ``` ## 10. Troubleshooting | Symptom | Cause / fix | |---|---| | `fastacl rule del … returned -6` | The index does not exist. `fastacl rule del` takes the **index** (`show fastacl rules`), not the order. | | `dscp value must be 0-63` | `dscp-mark` argument out of range. | | Rule added but nothing is filtered | The filter is not armed on the interface — run `set interface fastacl ` and confirm with `show fastacl interface`. | | `psample netlink family not found` | Kernel psample module not loaded — `modprobe psample` on the host. | | Two rules overlap and the wrong one applies | Precedence is by lowest `order`. Give the intended rule a lower order value. | | `unknown input '…'` | A keyword or value was mistyped. Check the syntax in §4.1. | ## 11. Command quick reference | Command | Purpose | |---|---| | `set interface fastacl <if> [enable\|disable]` | Arm / disarm the filter on an interface | | `show fastacl interface` | List armed interfaces | | `fastacl rule add order … action {…}` | Add a rule | | `fastacl rule del {<index>\|all}` | Delete a rule (by index) or all rules | | `fastacl rule-reindex` | Rebuild the index after a bulk API load | | `show fastacl rules` | List rules with match/action and per-rule counters | | `show fastacl aggregate-counters` | Plugin-wide processed/dropped totals | | `show fastacl tuples` | TSS classifier state (diagnostic) | | `clear fastacl counters` | Zero all counters | | `fastacl psample {enable\|disable}` | Turn packet sampling on/off | | `show fastacl sampling` | Sampling state and per-rule sample counts | **Document Categories:** Inline filtering --- ### [FastNetMon Advanced Release Lifecycle](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-release-lifecycle/) **Published:** July 9, 2024 **Author:** Pavel Odintsov **Content:** On this page, you can find information about FastNetMon Advanced releases' support for old distributions. Our standard policy is to provide official releases as long as the vendor provides standard free security support for a particular Linux distribution. For Ubuntu Linux LTS, it covers "LTS standard security maintenance" and explicitly excludes "LTS Expanded Security Maintenance (ESM)" and "Legacy support". For Debian Linux, it covers official "Debian LTS" support. For Red Hat-based distributions, it covers "Full Support Phase", "Maintenance Support Phase" but does not cover "Extended Life Phase". Below you can find a list of platforms which were supported previously but reached their end of life. - Ubuntu 14.04 LTS (Trusty Tahr): [last](https://repo.fastnetmon.com/fastnetmon/) version of FastNetMon Advanced which supported it was [2.0.252](https://github.com/FastNetMon/fastnetmon-advanced-releases/releases/tag/v2.0.252). Deprecation date 21th of August 2021. - Ubuntu 16.04 LTS (Xenial Xerus): [last](https://repo.fastnetmon.com/fastnetmon_ubuntu_xenial/pool/fastnetmon/f/fastnetmon/) version of FastNetMon Advanced which supported it was [2.0.365](https://github.com/FastNetMon/fastnetmon-advanced-releases/releases/tag/v2.0.365) Deprecation date 27th of June 2024. - Debian 9 (Stretch): [last](https://repo.fastnetmon.com/fastnetmon_debian_stretch/) version of FastNetMon Advanced which supported it was [2.0.365](https://github.com/FastNetMon/fastnetmon-advanced-releases/releases/tag/v2.0.365) Deprecation date 27th of June 2024. - Debian 10 (Buster): [last](https://repo.fastnetmon.com/fastnetmon_debian_buster/) version of FastNetMon Advanced which supported it was [2.0.365](https://github.com/FastNetMon/fastnetmon-advanced-releases/releases/tag/v2.0.365) Deprecation date 27th of June 2024. - Debian 11 (Bullseye): [last](http://bullseye.debian.repo.fastnetmon.com) version of FastNetMon Advanced which supported it was [2.0.383](https://fastnetmon.com/2026/08/06/fastnetmon-advanced-2-0-383/) Deprecation date 15th of September 2026. - CentOS 7: [last](https://repo.fastnetmon.com/fastnetmon_centos_7/) version of FastNetMon Advanced which supported it was [2.0.372](https://github.com/FastNetMon/fastnetmon-advanced-releases/releases/tag/v2.0.372) Deprecation date 2nd of June 2025. - Ubuntu 18.04 LTS (Bionic Beaver): [last](https://repo.fastnetmon.com/fastnetmon/) version of FastNetMon Advanced which supported it was [2.0.375](https://github.com/FastNetMon/fastnetmon-advanced-releases/releases/tag/v2.0.375). Deprecation date April 6th of 2026. - Ubuntu 20.04 LTS (Focal Fossa): [last](https://repo.fastnetmon.com/fastnetmon/) version of FastNetMon Advanced which supported it was [2.0.375](https://github.com/FastNetMon/fastnetmon-advanced-releases/releases/tag/v2.0.375). Deprecation date April 6th of 2026. Even after the official deprecation date, we keep [archives](https://repo.fastnetmon.com/) of all FastNetMon binary packages for the platform. Also, for a few months after the official platform deprecation, we may keep doing developer builds for deprecated platforms, which can be used to fix urgent issues. We strongly recommend running only the latest versions of FastNetMon Advanced, as we provide official support only for the latest builds. **Document Categories:** Maintenance operations --- ### [FastNetMon Partner Ecosystem](https://fastnetmon.com/partners/) **Published:** July 30, 2026 **Author:** Outi Maria Pietilanaho **Content:** Our partners play an important role in helping customers successfully deploy and operate FastNetMon across diverse network environments. This page brings together our Solution Partners, Technology Partners, cloud-based DDoS scrubbing providers, recent partnership announcements, and information on joining our growing ecosystem. ## Partner Highlights & News [![ZanaNET Joins FastNetMon Partner Ecosystem](https://fastnetmon.com/wp-content/uploads/2026/10/zanaNET-partnership-announcement.png)](https://fastnetmon.com/2026/10/05/zananet-joins-fastnetmon-partner-ecosystem/) ## [ZanaNET Joins FastNetMon Partner Ecosystem](https://fastnetmon.com/2026/10/05/zananet-joins-fastnetmon-partner-ecosystem/) [![FastNetMon and IP Infusion introduce automated DDoS protection with OcNOS + FastNetMon](https://fastnetmon.com/wp-content/uploads/2026/03/FastNetMon-collaborates-with-NLNetLabs-x-Rotonda-1.png)](https://fastnetmon.com/2026/03/16/fastnetmon-and-ip-infusion-collaborate-on-automated-ddos-protection-with-ocnos/) ## [FastNetMon and IP Infusion introduce automated DDoS protection with OcNOS + FastNetMon](https://fastnetmon.com/2026/03/16/fastnetmon-and-ip-infusion-collaborate-on-automated-ddos-protection-with-ocnos/) Page 1 of 21[2](https://fastnetmon.com/wp-cron.php/page/2/?doing_wp_cron=1792528011.6662390232086181640625&et_blog "Page 2")[»](https://fastnetmon.com/wp-cron.php/page/2/?doing_wp_cron=1792528011.6662390232086181640625&et_blog) ## Solution Partners Our Solution Partners help organisations evaluate, purchase, deploy, and operate FastNetMon. They combine product expertise with real-world networking experience to deliver successful DDoS protection deployments and ongoing support. Interested in becoming a Solution Partner? Read more on our Partner Onboarding page. [Become a partner](https://fastnetmon.com/partner-register/) ##### Find a Solution Partner All FastNetMon Solution Partners are listed below. See their coverage area, services provided, vendors supported and contact details. ##### ZanaNET | **Website** | [www.zananet.com](http://www.zananet.com/) | |---|---| | **Contacts** | email:[ sales@zananet.com](mailto:sales@zananet.com), tel. +44 (0)1329 800478 | | **Coverage Area** | Global | | **Languages** | English | | **Services** | FastNetMon Installation and Configuration, Enterprise and Service Provider DDOS Protection, Network Consultancy, Design, Build and Management, Managed Services, Connectivity, Virtual Data Centre Cloud, Proxmox VE | ##### ib-red | **Website** | [www.ibred.es](https://www.ibred.es/) | |---|---| | **Contacts** | f.hidalgo@ibred.es | | **Coverage Area** | Spain | ##### Logical Net Corporation | **Website** | [logical.net](https://logical.net/) | |---|---| | **Contacts** | sales@logical.net \| phone number: 518-292-4500 | | **Coverage Area** | USA | | **Languages** | English, Albanian | | **Services** | Managed IT Services, Cloud Hosting, Business VoIP Systems, Web & Email Hosting, Office 365, Network Security, Cyber Security, Network Management | | **Vendors** | Cisco, Fortinet, Microsoft, Kaseya, Dell EMC, Veeam, VMware, Webroot, Trend Micro, HP, Linux, Intel, NetApp, WordPress, Axient, Azure | ##### Clue24 GmbH | **Contacts** | sales@clue24.de \| phone number: +49 607 350 39800 | |---|---| | **Coverage Area** | EU | | **Languages** | German, English | | **Services** | Consulting, Implementation, Hosting, Managed-Services, Individual Software Development | | **Vendors** | Vendor independent - especially including Cisco, Juniper, Arista, Extreme Networks, Huawei, Alcatel-Lucent, HPE, Dell, Mikrotik, Ubiquiti | ##### StormWall | **Website** | [stormwall.network](https://stormwall.network/) | |---|---| | **Contacts** | sales@stormwall.pro \| phone number: +1 (646) 491-62-59 | | **Coverage Area** | Worldwide | | **Languages** | English, Russian | | **Services** | DDoS protection, IP transit | | **Vendors** | Any | ##### NaWas by NBIP | **Website** | [nbip.nl](https://www.nbip.nl/) | |---|---| | **Contacts** | f.dupker@nbip.nl \| phone number: +31 655 398 999 | | **Coverage Area** | Europe | | **Languages** | English, German, Dutch | | **Services** | DDoS Mitigation, DDoS Testing, DDoS Training & Exercising | | **Vendors** | any, independent | ##### NIXVAL (FALBOX, S.L.) | **Website** | [nixval.com](https://nixval.com/) | |---|---| | **Contacts** | noc@nixval.com \| phone number: +34 961 344 927 | | **Coverage Area** | SPAIN | | **Languages** | Spanish, English | | **Services** | Managed services, Network solutions consulting | | **Vendors** | JUNIPER, CISCO | ##### Redes Brasil | **Website** | [redesbrasil.com](https://redesbrasil.com/) | |---|---| | **Contacts** | contato@redesbrasil.com \| phone number: +55 62 999 071 262 | | **Coverage Area** | Brazil, Europe, USA | | **Languages** | Portuguese, English, Spanish | | **Services** | Network trainings and consulting | | **Vendors** | Cisco, Juniper, Huawei, MikroTik, Ubiquiti, Fiberhome | ##### Vaecom Telecomunicaciones, SL | **Website** | [www.vaecom.com](https://www.vaecom.com/) | |---|---| | **Contacts** | info@vaecom.com \| phone number: +34965641641 | | **Coverage Area** | Spain | | **Languages** | English, Spanish | | **Services** | Network engineering | | **Vendors** | Mikrotik, Cisco, Juniper, Huawei | ##### IT-Invest LLC | **Website** | [it-invest.ua](https://it-invest.ua/) | |---|---| | **Contacts** | Artem.Dashevskyi@it-invest.ua \| phone number: +380987888078 | | **Coverage Area** | Ukraine | | **Languages** | Russian, Ukrainian | | **Services** | Software sell, Internet services | | **Vendors** | Juniper, Extreme, D-Link, Mikrotik, Eltex | ##### RioRey | **Website** | [riorey.com](https://riorey.com/) | |---|---| | **Contacts** | sales@riorey.com \| phone number: +1240-497-0330 | | **Coverage Area** | Worldwide | | **Languages** | English | | **Services** | Leading DDoS mitigation provider (hardware and VM) | ##### QuattroSEC GmbH | **Website** | [quattrosec.com](https://quattrosec.com/) | |---|---| | **Contacts** | office@quattrosec.com \| phone number: +43 1 268 444 100 | | **Coverage Area** | Austria, Germany | | **Languages** | German, English | | **Services** | IT Security: Support Service (DDoS) | | **Vendors** | Vendor independent (manufacturer-independent) | ##### TOYO Internet Service Co | **Website** | [www.tyis.co.jp](https://www.tyis.co.jp/) | |---|---| | **Contacts** | sales@tyis.co.jp \| phone number: +81-45-319-4590 | | **Coverage Area** | World | | **Languages** | Japanese, Korean, English | | **Services** | Data Centre and Cloud, total IT solution consulting, Managed services | | **Vendors** | Cisco, Juniper, DELL, HP, Fujitsu, NEC, Huawei, Mikrotik, Fortigate, Paloalto, Vyatta & More | ##### CHAROTAR TELELINK PVT LTD | **Contacts** | me@nishitthaker.com \| phone number: 9879565765 | |---|---| | **Coverage Area** | India | | **Languages** | English, Hindi | | **Services** | Network support | ##### WDZ GmbH | **Website** | [wdz.de](https://www.wdz.de/) | |---|---| | **Contacts** | consulting@wdz.de \| phone number: +49 5361 8911272 | | **Coverage Area** | Europe | | **Languages** | German, English | | **Services** | Consulting, Integration, Custom Development | | **Vendors** | NVIDIA/Mellanox, Juniper, Cisco, EdgeCore, Arista | ##### BR Networks | **Contacts** | soporte@brnet.es | |---|---| | **Coverage Area** | Spain | | **Languages** | Spanish | | **Services** | ISP Consultant (routing, switching, provisioning) | | **Vendors** | Cisco, Juniper, Huawei, Fortinet | ##### Netviser | **Website** | [netviser.com.tr](https://netviser.com.tr/) | |---|---| | **Contacts** | info@netviser.com.tr \| phone number: +908503000999 | | **Coverage Area** | EMEA: Turkey, All over Africa, all over Europe, all over Middle East | | **Languages** | Turkish, English, Russian | | **Services** | Network Consulting, Network Management, Data center, Internet services, Cloud Hosting, Web & Email Hosting, Network Security, Cyber Security. | | **Vendors** | Juniper, Arista, Cisco Huawei, Mikrotik, Fortigate, Paloalto, Vyatta & More | ##### Technovage Solution | **Website** | [technovage.io](https://technovage.io/) | |---|---| | **Contacts** | vannak.ken@technovage.io | | **Coverage Area** | Cambodia | | **Languages** | English | | **Services** | Network Monitoring | | **Vendors** | FortiGate, Zabbix | ##### COREUN | **Website** | [coreun.com](https://coreun.com/) | |---|---| | **Contacts** | info@coreun.com \| phone number: +34 917 542 289 | | **Coverage Area** | Spain | | **Languages** | Spanish, English | | **Services** | Audit, consulting, solution design, implementation, support. Specialised in ISP and Mission Critical environments. | | **Vendors** | Huawei, Cisco, Juniper, A10 Networks, Fortinet, Palo Alto | ##### Juniteck LLC | **Website** | [juniteck.com](https://juniteck.com/) | |---|---| | **Contacts** | office@juniteck.com | | **Coverage Area** | Georgia | | **Languages** | English | | **Services** | ICT Systems Integration, Software Development | | **Vendors** | Juniper, Huawei, Avaya, Oracle | ##### GINERNET | **Website** | [ginernet.com](https://ginernet.com/) | |---|---| | **Contacts** | soporte@ginernet.com \| phone number: +34 965 064 386 | | **Coverage Area** | Spain | | **Languages** | Spanish, English | | **Services** | DDoS protected IP transit | | **Vendors** | Mikrotik, Juniper, Cisco (Any router with BGP) | ##### ZeroTTL | **Website** | [zerottl.it](https://zerottl.it/) | |---|---| | **Contacts** | info@zerottl.it | | **Coverage Area** | Europe | | **Languages** | English, Italian | | **Services** | ISP Network Design, Telemetries, Instant Monitoring Tools | | **Vendors** | Juniper, Cisco | ##### TNGNET B.V. | **Website** | [www.tngnet.com](https://www.tngnet.com/) | |---|---| | **Contacts** | info@tngnet.com | | **Coverage Area** | The Netherlands | | **Services** | Whitelabel Internet Services, IP transit | | **Vendors** | Nokia, HPE, Supermicro, Gigabyte. Cisco, Extreme | ##### ITcare | **Website** | [itcare.net](https://itcare.net/) | |---|---| | **Contacts** | info@itcare.net \| phone number: +1 (201) 591-1658 | | **Coverage Area** | Worldwide, with primary focus on United States, Canada, UK, France, Germany, Netherlands, Switzerland. | | **Languages** | English, Russian, Romanian | | **Services** | Infrastructure Design, Engineering and Architecting, DevOps Services, NOC as a Service. Integration of new software, hardware and technologies. Outsourcing and Outstaffing. | | **Vendors** | Almost any vendor. Primary focus on: Juniper, Cisco, Arista, Dell, Huawei, Edgecore, Mikrotik. | ##### Zero Services GmbH | **Website** | [zeroservices.eu](https://www.zeroservices.eu/) | |---|---| | **Contacts** | info@zeroservices.eu | | **Coverage Area** | DE, AT, UK, NL, FR, ES, CH, PL, BE, DK, NO, FI | | **Languages** | English, German | | **Services** | Network Security / ISP networking consulting, managed services | | **Vendors** | Cisco, Juniper, FRR, Arista | ##### Inleed | **Website** | [inleed.se](https://inleed.se/) | |---|---| | **Contacts** | support@inleed.se \| phone number: +4 685 197 06 66 | | **Coverage Area** | World | | **Languages** | English, Swedish, Russian | | **Services** | ISP, IP Transit, Remote NOC, domains (ICANN registrar), web hosting, VPS, dedicated servers, co-location | | **Vendors** | Any (Juniper, Cisco, Mikrotik, Dell, and more) | ##### Flowspec Solutions Anti DDoS Brazil | **Website** | [flowspec.net.br](https://flowspec.net.br/) | |---|---| | **Contacts** | soc@flowspec.net.br \| phone number: +55 21 97999-5110 | | **Coverage Area** | Brazil | | **Languages** | Portuguese, English, Apsnish | | **Services** | SOC anti-DDoS and NOC services, Anti-DDoS Scrubbing Center in Brazil, trainings for ISP providers. | | **Vendors** | Huawei, Cisco, Juniper, Extreme, Mikrotik, Nokia, EdgeCore, Radware, Netscout, A10 TPS, Mellanox, Intel, Dell. | ##### Config Services Ltd | **Website** | [www.configuration.co.uk](https://www.configuration.co.uk/) | |---|---| | **Contacts** | team@configuration.co.uk \| phone number: +44 203 422 6822 | | **Coverage Area** | Global | | **Languages** | English | | **Services** | NMS Consultancy, NMS Development Services, NMS Management and Support, FastNetMon Installation and Configuration | | **Vendors** | Any vendor | ##### LinkSecured LLC | **Website** | [linksecured.net](https://linksecured.net/) | |---|---| | **Contacts** | sales@linksecured.net | | **Coverage Area** | USA, Canada | | **Languages** | English | | **Services** | DDoS Protection, IP Transit, Colocation, VoIP, System Management, Network Management, DWDM, Optical Services, Managed Services, Cloud Hosting, Web & Email Hosting, Network Security, and general maintenance contracts. | | **Vendors** | Cisco, Arista, Juniper, Dell, Veeam, VMware, Linux, Intel, Ubuntu, WordPress, VyOS | ## Technology Partnerships FastNetMon works with technology vendors to ensure reliable interoperability across networking, security, and cloud platforms. Through close technical collaboration, we build and maintain integrations that help customers deploy FastNetMon alongside the infrastructure and services they already use. See some of our technology partnerships below. [![Google Cloud Partner](https://fastnetmon.com/wp-content/uploads/2026/01/google-cloud-partner.jpg "google-cloud-partner")](https://fastnetmon.com/google-cloud-network/) [![](https://fastnetmon.com/wp-content/uploads/2026/01/aws-network.jpg "aws-network")](https://fastnetmon.com/aws-network-analytics/) [![](https://fastnetmon.com/wp-content/uploads/2026/03/IP-Infusion.png "IP Infusion")](https://fastnetmon.com/2026/03/16/fastnetmon-and-ip-infusion-collaborate-on-automated-ddos-protection-with-ocnos/) [![Radware](https://fastnetmon.com/wp-content/uploads/2026/01/radware.jpg "radware")](https://fastnetmon.com/2017/02/17/fastnetmon-integration-with-radware-defenseflow/) ## Scrubbing Centre Partners FastNetMon integrates with leading cloud-based DDoS scrubbing providers, giving customers the flexibility to choose the mitigation service that best fits their network. Want to see integration with your own Cloud DDoS Scrubbing service? You can find our [technical requirements](https://fastnetmon.com/docs-fnm-advanced/requirements-for-integration-with-new-cloud-based-ddos-scrubbing-centers/) here. Please [reach out to us](https://fastnetmon.com/contact/ "https://fastnetmon.com/contact/") and we will be happy to discuss details. ##### Native Cloud Scrubbing Integrations In addition to comprehensive support for BGP Unicast announcements to redirect traffic for affected prefixes to cloud-based DDoS scrubbing centres, FastNetMon Advanced offers native API integrations with multiple scrubbing providers for fully automated attack mitigation. ##### GCore Global DDoS protection [Website](https://gcore.com/ddos-protection) [Documentation](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-integration-with-gcore-global-ddos-protection-scrubbing-centre/) ##### F5 DDoS scrubbing centre [Website](https://www.f5.com/products/distributed-cloud-services/l3-and-l7-ddos-attack-mitigation) [Documentation](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-integration-with-f5-silverline-ddos-scrubbing-centre/) ##### Cloudflare Magic Transit [Website](https://www.cloudflare.com/en-gb/network-services/products/magic-transit/) [Documentation](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-integration-with-cloudflare-magic-transit-scrubbing-centre/) ## Interested in partnering with FastNetMon? We're always looking to expand the FastNetMon ecosystem with organisations that share our commitment to protecting networks from DDoS attacks. Whether you provide implementation and consulting services, develop complementary technologies, or see opportunities to collaborate with FastNetMon, we'd love to hear from you. Read more about how you can become a FastNetMon Partner on our Partner Onboarding page. [read more](https://fastnetmon.com/partner-register/) --- ### [Become a FastNetMon Partner](https://fastnetmon.com/partner-register/) **Published:** May 16, 2022 **Author:** FastNetMon **Content:** Partner with FastNetMon to bring advanced DDoS detection and mitigation to more networks. The FastNetMon Partner Program is built for companies that help network operators, enterprises, and digital infrastructure providers strengthen their network security. Whether you want to introduce FastNetMon to your customers, deliver FastNetMon as part of your solutions, or build our technology into your own offering, we provide partnership models designed around the way you do business. ## **Solution Partnership Models** ![Monitoring](https://fastnetmon.com/wp-content/uploads/2026/01/icon_monitoring-1.png "icon_monitoring") #### **Referrer** **Introduce customers to FastNetMon.** Referral partners identify relevant opportunities and introduce customers to FastNetMon. Our team then works directly with the customer through technical evaluation and the sales process. **Best suited for:** Consultants, advisors, technology providers, service providers. [get in touch](https://fastnetmon.com/fastnetmon-partner-onboarding-enquiry/) ![GBP Blackhole](https://fastnetmon.com/wp-content/uploads/2026/01/icon_gbpblackhole.png "icon_gbpblackhole") #### **Reseller** **Offer FastNetMon to your customers.** Reseller partners include FastNetMon in their product or service portfolio and manage the customer relationship, working with our commercial and technical teams where needed. **Best suited for:** Integrators, MSPs, security providers, VARs, and infrastructure consultancies. [get in touch](https://fastnetmon.com/fastnetmon-partner-onboarding-enquiry/) ![BGP Flow Spec](https://fastnetmon.com/wp-content/uploads/2026/01/icon_bgpflowspec.png "icon_bgpflowspec") #### **White Label** **Deliver FastNetMon under your own brand.** White Label partners incorporate FastNetMon technology into their own branded services or solutions. These partnerships involve closer technical integration and are reviewed individually. **Best suited for:** Technology firms building DDoS protection or network security services. [get in touch](https://fastnetmon.com/fastnetmon-partner-onboarding-enquiry/) 45 ## **Technology & Cloud Scrubbing Partnership Models** **Build an integrated DDoS protection ecosystem with FastNetMon.** We work directly with technology vendors, infrastructure platforms, and cloud scrubbing providers to make FastNetMon part of a broader network security ecosystem. Technology partnerships can include product integrations, interoperability, automation, and joint solutions that help customers detect attacks and take action across their network infrastructure. Cloud Scrubbing Partnerships connect FastNetMon's on-premises detection capabilities with external mitigation capacity, enabling customers to redirect malicious traffic when an attack requires upstream scrubbing. These partnerships are developed collaboratively rather than through a standard programme model. **Interested in integrating your technology or scrubbing service with FastNetMon?** Contact our team at [partner@fastnetmon.com](mailto:partners@fastnetmon.com) or fill in the form below to discuss your technology, use case, and potential partnership. [FILL IN AN ENQUIRY](https://fastnetmon.com/fastnetmon-partner-onboarding-enquiry/) ## **Why Partner with FastNetMon?** As a FastNetMon partner, you can combine your customer relationships, services, and expertise with technology purpose-built for high-performance DDoS detection and mitigation. Depending on your partnership model, you can benefit from: - Partner-specific commercial terms - Direct access to FastNetMon sales and technical expertise - Support throughout customer evaluation and deployment - Priority technical support - Early access to selected new capabilities - Opportunities for technical and go-to-market collaboration - Visibility within the FastNetMon partner ecosystem and marketing collaborations ![Professional headshot of a middle-aged man with dark hair and glasses, wearing a navy suit and blue patterned tie.](https://fastnetmon.com/wp-content/uploads/2026/08/Tush-Nikiollaj.jpeg) **FastNetMon is a powerful and reliable platform for network visibility and DDoS detection.** The solution is flexible, effective, and backed by a knowledgeable and highly responsive team. We have been very pleased with both the product and the partnership and would confidently recommend FastNetMon to organizations looking for dependable DDoS protection. ***[Tush Nikollaj](https://www.linkedin.com/in/tushnikollaj/), CEO, [Logical.Net](https://www.logical.net/)*** ## **Become a FastNetMon Partner** Tell us about your business, your customers, and how you would like to work with FastNetMon. Complete our non-binding partner onboarding form, and our team will review your submission, identify the partnership model that best fits your business, and contact you to discuss the next steps. [partner onboarding](https://fastnetmon.com/fastnetmon-partner-onboarding-enquiry/) --- ### [FastNetMon Partner Onboarding Enquiry](https://fastnetmon.com/fastnetmon-partner-onboarding-enquiry/) **Published:** August 25, 2026 **Author:** Outi Maria Pietilanaho **Content:** Partner Onboarding FormName Company Name URL Country of Company Registration Business Email Type of partnership - Select -ReferrerResellerWhite LabelingTechnology PartnershipCloud ScrubbingOther/Unsure Additional details Submit Form --- ### [FastNetMon Careers](https://fastnetmon.com/careers/) **Published:** October 8, 2025 **Author:** FastNetMon **Content:** ![](https://fastnetmon.com/wp-content/uploads/2026/01/FastNetMon-Careers-page-Join-us-to-build-the-future-of-DDoS-defence-1-1024x424.png) FastNetMon is a fast-growing technology company building cutting-edge DDoS detection and mitigation tools used by network operators and enterprises in over 130 countries. As we scale globally, we’re looking for curious, technically minded people to help us protect the world’s internet infrastructure. We’re a remote-first team based in London, UK, with deep roots in the open source community. Our commercial and community offerings secure some of the most advanced networks in the world. ### How We Work at FastNetMon We are a fully remote, distributed team typically considering candidates working in the UK, EU, US and Canada. Our team and setup is built for flexibility, focus and deep work—without the need for offices or micromanagement. We work asynchronously across time zones, communicate clearly, and take full ownership of our work. What matters most is delivering real impact—solving complex problems, improving our product, and supporting our customers in meaningful ways. ![](https://fastnetmon.com/wp-content/uploads/2026/01/FastNetMon-Illustration-how-the-team-works-careers-1024x746.png) ### Open roles We’re a small, highly specialised team, and we hire with intention. Every role we open plays a key part in shaping our product and supporting our customers. We’re not growing for the sake of it—we’re building a team of skilled, motivated people who care deeply about our joint mission. Below you’ll find our current openings. If one of them sounds like the right fit, we’d love to hear from you. | Position | Details | Type | Location | Seniority | |---|---|---|---|---| | No open roles currently | - | - | - | - | ### Looking for something else? We’re always keen to hear from talented people who share our curiosity, technical mindset, and drive to build something meaningful. If you think you’d be a great fit for FastNetMon but don’t see an open role that matches your skills, feel free to reach out to **careers@fastnetmon.com** with an open application—we’d love to hear from you. --- ### [FastNetMon Advanced API](https://fastnetmon.com/docs-fnm-advanced/advanced-api/) **Published:** December 7, 2017 **Author:** Pavel Odintsov **Content:** We offer a complete REST based API in FastNetMon Advanced. API is disabled by default due to a blank default password. You need to generate a new password to enable it. Generate a secure password and specify it as the API password: ``` sudo fcli set main web_api_login admin sudo fcli set main web_api_password your_password_replace_it sudo fcli set main web_api_port 10007 sudo fcli set main web_api_host 127.0.0.1 ``` Please note that FastNetMon LiveView web interface capability requires API v2 logic which changes address of API URL to /api/v2: ``` sudo fcli set main web_api_v2 true sudo fcli commit ``` To create multiple admin accounts, please use this guide regarding our [new access control system](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-api-user-control/). Optionally, you can bind the API daemon to IPv6 addresses in the following way: ``` sudo fcli set main web_api_host ::1 ``` If you experience any issues, we suggest checking the logs: ``` sudo tail -f /var/log/fastnetmon/api_gateway.log ``` You may enable detailed logging level this way: ``` sudo fcli set main web_api_trace_queries true sudo fcli commit sudo systemctl restart fastnetmon_web_api ``` After making this change, you will see very detailed information about all actions in the log file api\_gateway.log. ## SSL certificates Optionally, you can enable an SSL/TLS-enabled endpoint on another port this way. You need to use your own SSL certificates created manually. FastNetMon expects PEM-encoded files: \- X.509 server certificate ( may include intermediate CA chain certificates in the same file). \- Unencrypted PEM private key ( supported key types RSA, ECDSA, PKCS#8 (BEGIN PRIVATE KEY)). Encrypted/private keys protected with a passphrase are not supported. ``` sudo fcli set main web_api_ssl true sudo fcli set main web_api_ssl_host 127.0.0.1 sudo fcli set main web_api_ssl_port 10443 sudo fcli set main web_api_ssl_private_key_path /etc/ssl.key sudo fcli set main web_api_ssl_certificate_path /etc/ssl.crt sudo systemctl restart fastnetmon_web_api ``` Example of generating self-signed RSA certificate: ``` openssl req -x509 -newkey rsa:2048 \ -keyout ssl.key \ -out ssl.crt \ -days 365 \ -nodes \ -subj "/CN=fasetnetmon.node.com" \ -addext "subjectAltName=DNS:localhost,IP:127.0.0.1" ``` To listen on localhost and all external interfaces simultaneously, you can set web\_api\_ssl\_host to 0.0.0.0. For security reasons, we recommend using only HTTPS-enabled API port for external connections. Also you can use it with reverse proxy. Example of NGINX config for LiveView/API ``` server { # Listen on IPv6 listen [::]:82; # Listen on IPv4 listen 82; # Listen on IPv6 listen [::]:443 ssl; # Listen on IPv4 listen 443 ssl; # We support only secure versions of TLS ssl_protocols TLSv1.2 TLSv1.3; ssl_certificate ; ssl_certificate_key ; proxy_connect_timeout 300; proxy_send_timeout 300; proxy_read_timeout 300; send_timeout 300; location / { proxy_pass http://127.0.0.1:80; proxy_http_version 1.1; proxy_set_header Host $host; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Real-IP $remote_addr; } } ``` FastNetMon's API does not provide fine-grained permission control, and we strongly advise against exposing it to non-trusted systems/clients. Execute example query to get license: ``` curl -X GET -u admin:YOU_PASSWORD https://127.0.0.1:10007/license ``` FastNetMon API is based on the [fcli tool](https://fastnetmon.com/advanced-cli-reference/). For debugging purposes, you could switch fcli to JSON mode in the following: ``` JSON_MODE=on sudo -E fcli show bgp ``` It will provide the same messages as the API provides. Instead of "set" command, you will need to use PUT HTTP method, for example (Note - we use URL Encode for the network name because it consists slash symbol): ``` curl -X PUT -u apiuser:securepass9 https://127.0.0.1:10007/main/networks_list/11.22.33.44%2f22 ``` Instead of the "delete" command, you will need to use DELETE HTTP method, for example: ``` curl -X DELETE -u apiuser:securepass9 https://127.0.0.1:10007/main/networks_list/11.22.33.44%2f22 ``` To list all networks: ``` curl -q -X GET -u admin:admin 'https://127.0.0.1:10007/main/networks_list' ``` Example output: ``` {"success":true,"error_text":"","values":["1.1.1.0/22","2a01:4b00::1"]} ``` To show something, you can use GET HTTP method: ``` curl -X GET -u apiuser:securepass9 https://127.0.0.1:10007/hostgroup/global/threshold_mbps ``` To show the whole category use: ``` curl -X GET -u apiuser:securepass9 https://127.0.0.1:10007/hostgroup ``` As you can see, in almost all cases, you can replace a space symbol with a slash and use fcli's format of command to talk with the API. If the method failed for any reason, we return the following document: ``` {"success":false,"error_text":"Category name hostgroupddd is not supported"} ``` If a command returns a single value, we return it in "value" field. Example for Boolean value: ``` curl -X GET -u apiuser:securepass9 https://127.0.0.1:10007/main/sflow {"success":true,"error_text":"","value":true} ``` Example for string value: ``` curl -X GET -u apiuser:securepass9 https://127.0.0.1:10007/main/sflow_host {"success":true,"error_text":"","value":"94.76.167.202"} ``` If a command returns multiple elements, we return it in "values" field: ``` curl -X GET -u apiuser:securepass9 https://127.0.0.1:10007/main/sflow_ports {"success":true,"error_text":"","values":["3432","6343"]} ``` If a command returns a hash map/table/dictionary, FastNetMon encodes it as a JSON dictionary: ``` curl -X GET -u apiuser:securepass9 https://127.0.0.1:10007/main/influxdb_tags_table {"success":true,"error_text":"","table":{"ddd":"vvvv","foo":"bar"}} ``` If a command returns a document (hash map, dictionary), we return it in "object" field: ``` curl -X GET -u apiuser:securepass9 https://127.0.0.1:10007/bgp/connection_to_my_router {"success":true,"error_text":"","values":[{"name":"connection_to_my_router","description":"","local_asn":65001,"local_address":"11.22.33.44","subnet_learning":false,"remote_asn":65001,"remote_address":"22.33.44.55","device_vendor":"","device_model":"","multihop":false,"md5_auth":true,"md5_auth_password":"suxx","snmp_address":"","snmp_version":"","snmp_community":"","ipv4_unicast":true,"ipv6_unicast":false,"ipv4_flowspec":true,"ipv6_flowspec":false,"ipv4_unicast_announces_limit":0,"ipv6_unicast_announces_limit":0,"ipv4_flowspec_announces_limit":0,"ipv6_flowspec_announces_limit":0,"active":true}]} ``` We have some rather complicated examples, for example, for blackhole announces: ``` curl -X GET -u apiuser:securepass9 https://127.0.0.1:10007/blackhole {"success":true,"values":[{"uuid":"6575af53-301a-4dae-ab9d-7e89c2a1fada","ip":"127.0.0.1/32"},{"uuid":"22965d4e-83b0-42c0-a442-848cd80a9ca7","ip":"127.0.0.2/32"}]} ``` Or flow spec announces: ``` curl -X GET -u apiuser:securepass9 https://127.0.0.1:10007/flowspec {"success":true,"values":[{"uuid":"00fde1c5-bce4-4752-9d08-4e5be115e1c0","announce":{"source_prefix":"4.0.0.0/32","destination_prefix":"127.0.0.0/32","destination_ports":[80],"source_ports":[53,5353],"packet_lengths":[777,1122],"protocols":["tcp"],"fragmentation_flags":["is-fragment","dont-fragment"],"tcp_flags":["syn"],"action_type":"rate-limit","action":{"rate":1024}}},{"uuid":"7bc20126-ae1e-4e5b-8bc6-3493a55a0511","announce":{"source_prefix":"4.0.0.0/32","destination_prefix":"127.0.0.0/32","destination_ports":[80],"source_ports":[53,5353],"packet_lengths":[777,444],"protocols":["tcp"],"fragmentation_flags":["is-fragment","dont-fragment"],"tcp_flags":["syn"],"action_type":"rate-limit","action":{"rate":1024}}}]} ``` To insert a blackhole host, use this: ``` curl -X PUT -u admin:securepass9 https://127.0.0.1:10007/blackhole/127.0.0.1 ``` After making any changes, you have to trigger commit command to apply the changes for FastNetMon's engine: ``` curl -X PUT -u admin:securepass9 https://127.0.0.1:10007/commit ``` ### Complete example to ban and unban a host Ban it: ``` curl -X PUT -u admin:securepass9 https://127.0.0.1:10007/blackhole/127.0.0.1 ``` Check list of banned hosts: ``` curl -X GET -u admin:securepass9 https://127.0.0.1:10007/blackhole ``` Output: ``` {"success":true,"values":[{"uuid":"a1080f8f-46bb-4fcf-932c-5cc837105589","ip":"127.0.0.1/32"}]} ``` And finally unban it by UUID: ``` curl -X DELETE -u admin:securepass9 https://127.0.0.1:10007/blackhole/a1080f8f-46bb-4fcf-932c-5cc837105589 ``` Some some command which expect large JSON documents you may pass JSON documents as part of JSON query: ``` curl -vv -X PUT -u admin:securepass9 https://127.0.0.1:10007/flowspec -H "Content-Type: application/json" -d '{"source_prefix":"11.22.33.44/32", "destination_prefix":"11.22.33.44/32", "action_type":"discard"}' ``` ### How to get per host counters? Example: ``` curl -s -X GET -u admin:securepass9 https://127.0.0.1:10007/host_counters/incoming/bytes ``` Feel free to replace "incoming" by "outgoing" and "bytes" by "packets" or "flows" to change ordering. Example output: ``` { "success": true, "values": [ { "host": "192.168.1.125", "incoming_packets": 0, "incoming_bytes": 0, "incoming_flows": 0, "fragmented_incoming_packets":0, "fragmented_incoming_bytes":0, "dropped_incoming_packets":0, "dropped_incoming_bytes":0, "tcp_incoming_packets":1468, "tcp_incoming_bytes":2226553, "tcp_syn_incoming_packets":0, "tcp_syn_incoming_bytes":0, "udp_incoming_packets":0, "udp_incoming_bytes":0, "icmp_incoming_packets":0, "icmp_incoming_bytes":0 }, { "host": "192.168.1.109", "incoming_packets": 0, "incoming_bytes": 0, "incoming_flows": 0, "fragmented_incoming_packets":0, "fragmented_incoming_bytes":0, "dropped_incoming_packets":0, "dropped_incoming_bytes":0, "tcp_incoming_packets":1468, "tcp_incoming_bytes":2226553, "tcp_syn_incoming_packets":0, "tcp_syn_incoming_bytes":0, "udp_incoming_packets":0, "udp_incoming_bytes":0, "icmp_incoming_packets":0, "icmp_incoming_bytes":0 } ] } ``` To get host counters for IPv6 you need to use following query: ``` curl -s -X GET -u admin:securepass9 https://127.0.0.1:10007/host_counters_v6/incoming/bytes ``` ### How to get traffic counters for single IP? You can do it this way: ``` curl -X GET -u 'admin:password' https://127.0.0.1:10007/single_host_counters/1.2.3.4 ``` Example output: ``` { "success": true, "error_text": "", "object": { "dropped_in_bytes": 0, "dropped_in_packets": 0, "dropped_out_bytes": 0, "dropped_out_packets": 0, "fragmented_in_bytes": 0, "fragmented_in_packets": 0, "fragmented_out_bytes": 0, "fragmented_out_packets": 0, "icmp_in_bytes": 123, "icmp_in_packets": 0, "icmp_out_bytes": 244, "icmp_out_packets": 0, "in_bytes": 9199870, "in_flows": 23, "in_packets": 7034, "out_bytes": 506644, "out_flows": 22, "out_packets": 3135, "tcp_in_bytes": 5415572, "tcp_in_packets": 4022, "tcp_out_bytes": 362532, "tcp_out_packets": 2278, "tcp_syn_in_bytes": 848007, "tcp_syn_in_packets": 636, "tcp_syn_out_bytes": 37889, "tcp_syn_out_packets": 374, "udp_in_bytes": 3783062, "udp_in_packets": 2987, "udp_out_bytes": 135935, "udp_out_packets": 826 } } ``` To get single host counters for IPv6 we need to use following query: ``` curl -X GET -u 'admin:password' https://127.0.0.1:10007/single_host_counters_v6/face::cafe ``` ### How to get counters for specific network? Starting from 2.0.374 you can get per network traffic this way: ``` curl -X GET -u 'admin:password' 'http://127.0.0.1:10007/single_network_counters_v4/10.0.2.0%2F23' ``` Example output: ``` {"success":true, "error_text":"", "object":{ "dropped_in_bytes":0, "dropped_in_packets":0, "dropped_out_bytes":0, "dropped_out_packets":0, "fragmented_in_bytes":0, "fragmented_in_packets":0, "fragmented_out_bytes":0, "fragmented_out_packets":0, "icmp_in_bytes":56769, "icmp_in_packets":901, "icmp_out_bytes":0, "icmp_out_packets":0, "in_bytes":516949011, "in_flows":0, "in_packets":488321, "out_bytes":0, "out_flows":0, "out_packets":0, "tcp_in_bytes":340983764, "tcp_in_packets":268637, "tcp_out_bytes":0, "tcp_out_packets":0, "tcp_syn_in_bytes":205730, "tcp_syn_in_packets":3498, "tcp_syn_out_bytes":0, "tcp_syn_out_packets":0, "udp_in_bytes":175908472, "udp_in_packets":218777, "udp_out_bytes":0, "udp_out_packets":0}} ``` In addition to this endpoint you can use following one to get traffic for IPv4 networks split on /24 boundaries this way: ``` curl -X GET -u 'admin:password' 'http://127.0.0.1:10007/single_network_counters_24_v4/10.0.2.0%2F24' ``` And you can use this IPv6 endpoint to get traffic for IPv6 networks this way: ``` curl -X GET -u 'admin:password' 'http://127.0.0.1:10007/single_network_counters_v6/dead::beef%2F32' ``` Both endpoints return JSON documents in exactly same format as single\_network\_counters\_v4 ## How to get counters for specific ASN? Starting from 2.0.374 you can use following endpoint to get traffic for particular ASN: ``` curl -X GET -u 'admin:password' 'http://127.0.0.1:10007/single_asn_counters_v4/12345' ``` For IPv6 you need to use another endpoint: ``` curl -X GET -u 'admin:password' 'http://127.0.0.1:10007/single_asn_counters_v6/12345' ``` Example output format: ``` {"success":true, "error_text":"", "object":{ "dropped_in_bytes":0, "dropped_in_packets":0, "dropped_out_bytes":0, "dropped_out_packets":0, "fragmented_in_bytes":0, "fragmented_in_packets":0, "fragmented_out_bytes":0, "fragmented_out_packets":0, "icmp_in_bytes":56769, "icmp_in_packets":901, "icmp_out_bytes":0, "icmp_out_packets":0, "in_bytes":516949011, "in_flows":0, "in_packets":488321, "out_bytes":0, "out_flows":0, "out_packets":0, "tcp_in_bytes":340983764, "tcp_in_packets":268637, "tcp_out_bytes":0, "tcp_out_packets":0, "tcp_syn_in_bytes":205730, "tcp_syn_in_packets":3498, "tcp_syn_out_bytes":0, "tcp_syn_out_packets":0, "udp_in_bytes":175908472, "udp_in_packets":218777, "udp_out_bytes":0, "udp_out_packets":0}} ``` ### Create / read / update for for hostgroups Starting from FastNetMon 2.0.332 you can use single large JSON document to create new hostgroup or completely overwrite configuration for existing hostgroup. The easiest way to get all field names to manually [create hostgroup](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-per-host-hostgroups/) via fcli and then get JSON output from it this way: ``` JSON_MODE=on sudo -E fcli show hostgroup servers ``` You will see document like this: ``` { "success":true, "error_text":"", "values":[ { "name":"servers", "parent_name":"", "description":"", "calculation_method":"per_host", "enable_ban":false, "ban_for_pps":false, "ban_for_bandwidth":false, "ban_for_flows":false, "threshold_pps":0, "threshold_mbps":0, "threshold_flows":0, "ban_for_tcp_bandwidth":false, "ban_for_udp_bandwidth":false, "ban_for_icmp_bandwidth":false, "ban_for_tcp_pps":false, "ban_for_udp_pps":false, "ban_for_icmp_pps":false, "threshold_tcp_mbps":0, "threshold_udp_mbps":0, "threshold_icmp_mbps":0, "threshold_tcp_pps":0, "threshold_udp_pps":0, "threshold_icmp_pps":0, "ban_for_tcp_syn_pps":false, "threshold_tcp_syn_pps":0, "ban_for_tcp_syn_bandwidth":false, "threshold_tcp_syn_mbps":0, "ban_for_ip_fragments_pps":false, "threshold_ip_fragments_pps":0, "ban_for_ip_fragments_bandwidth":false, "threshold_ip_fragments_mbps":0, "enable_ban_incoming":false, "enable_ban_outgoing":false, "ban_for_pps_outgoing":false, "ban_for_bandwidth_outgoing":false, "ban_for_flows_outgoing":false, "threshold_pps_outgoing":0, "threshold_mbps_outgoing":0, "threshold_flows_outgoing":0, "ban_for_tcp_bandwidth_outgoing":false, "ban_for_udp_bandwidth_outgoing":false, "ban_for_icmp_bandwidth_outgoing":false, "ban_for_tcp_pps_outgoing":false, "ban_for_udp_pps_outgoing":false, "ban_for_icmp_pps_outgoing":false, "threshold_tcp_mbps_outgoing":0, "threshold_udp_mbps_outgoing":0, "threshold_icmp_mbps_outgoing":0, "threshold_tcp_pps_outgoing":0, "threshold_udp_pps_outgoing":0, "threshold_icmp_pps_outgoing":0, "ban_for_tcp_syn_pps_outgoing":false, "threshold_tcp_syn_pps_outgoing":0, "ban_for_tcp_syn_bandwidth_outgoing":false, "threshold_tcp_syn_mbps_outgoing":0, "ban_for_ip_fragments_pps_outgoing":false, "threshold_ip_fragments_pps_outgoing":0, "ban_for_ip_fragments_bandwidth_outgoing":false, "threshold_ip_fragments_mbps_outgoing":0 } ] } ``` You need to use first element from array values to get whole document which describes hostgroup. Then you need to adjust required fields and pass them via API using PUT method to main hostgroup endpoint (/hostgroup) this way: ``` curl -vv -X PUT -u admin:securepass9 https://127.0.0.1:10007/hostgroup -H "Content-Type: application/json" -d '{"name":"servers","parent_name":"","description":"","calculation_method":"per_host","enable_ban":false,"ban_for_pps":false,"ban_for_bandwidth":false,"ban_for_flows":false,"threshold_pps":0,"threshold_mbps":0,"threshold_flows":0,"ban_for_tcp_bandwidth":false,"ban_for_udp_bandwidth":false,"ban_for_icmp_bandwidth":false,"ban_for_tcp_pps":false,"ban_for_udp_pps":false,"ban_for_icmp_pps":false,"threshold_tcp_mbps":0,"threshold_udp_mbps":0,"threshold_icmp_mbps":0,"threshold_tcp_pps":0,"threshold_udp_pps":0,"threshold_icmp_pps":0,"ban_for_tcp_syn_pps":false,"threshold_tcp_syn_pps":0,"ban_for_tcp_syn_bandwidth":false,"threshold_tcp_syn_mbps":0,"ban_for_ip_fragments_pps":false,"threshold_ip_fragments_pps":0,"ban_for_ip_fragments_bandwidth":false,"threshold_ip_fragments_mbps":0,"enable_ban_incoming":false,"enable_ban_outgoing":false,"ban_for_pps_outgoing":false,"ban_for_bandwidth_outgoing":false,"ban_for_flows_outgoing":false,"threshold_pps_outgoing":0,"threshold_mbps_outgoing":0,"threshold_flows_outgoing":0,"ban_for_tcp_bandwidth_outgoing":false,"ban_for_udp_bandwidth_outgoing":false,"ban_for_icmp_bandwidth_outgoing":false,"ban_for_tcp_pps_outgoing":false,"ban_for_udp_pps_outgoing":false,"ban_for_icmp_pps_outgoing":false,"threshold_tcp_mbps_outgoing":0,"threshold_udp_mbps_outgoing":0,"threshold_icmp_mbps_outgoing":0,"threshold_tcp_pps_outgoing":0,"threshold_udp_pps_outgoing":0,"threshold_icmp_pps_outgoing":0,"ban_for_tcp_syn_pps_outgoing":false,"threshold_tcp_syn_pps_outgoing":0,"ban_for_tcp_syn_bandwidth_outgoing":false,"threshold_tcp_syn_mbps_outgoing":0,"ban_for_ip_fragments_pps_outgoing":false,"threshold_ip_fragments_pps_outgoing":0,"ban_for_ip_fragments_bandwidth_outgoing":true,"threshold_ip_fragments_mbps_outgoing":12345}' ``` You can create new hostgroup by setting field "name" to name of new hostgroup. Starting from 2.0.360 you can control number of entries returned by API calls asn\_counters\_v4, asn\_counters\_v6, host\_counters\_v6, host\_counters, host\_counters\_per\_hostgroup\_v4, host\_counters\_per\_hostgroup\_v6, remote\_host\_counters using query parameter max\_elements. Starting from 2.0.374 you can use this flag for network\_counters, network\_counters\_24 and network\_counters\_v6. Starting from 2.0.383 same logic can be used for hostgroup\_counters\_total and interface\_counters ``` curl -s -X GET -u admin:your_password_replace_it https://[::1]:10007/asn_counters_v4/outgoing?max_elements=50 ``` ### Examples We have number of example tools implemented for our API to provide examples: - [API client](https://fastnetmon.com/fastnetmon-advanced-example-api-client/) which creates and removes networks from FastNetMon - [API client](https://fastnetmon.com/fastnetmon-advanced-example-api-client-which-blocks-and-unblocks-ip/) which can block and unblock IP address ### Technical details FastNetMon REST API is implemented as gateway which accepts HTTP / HTTPS queries from end client and then reaches FastNetMon daemon using internal non public gRPC based API (which listens TCP port 50052 by default ) to execute command. For configuration management commands REST API reached MongoDB or FerretDB directly. In case of FastNetMon daemon reachability issues you will see following error: ``` Show function returned error: XXX call failed: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial tcp 127.0.0.1:50052: connect: connection refused" ``` ### Schema reflection API Our normal API endpoints do not provide detailed information about fields in main and hostgroup categories. You can get it using special API calls: ``` curl -s -X GET -u admin:your_password_replace_it https://127.0.0.1:10007/fields/main ``` Example answer: ``` { "success": true, "error_text": "", "values": [ { "name": "enable_ban", "type": "bool", "unit": "", "description": "Completely enable or disable all ban actions", "tooltip": "", "category": "ban_management", "group": "", "pretty_name": "Enable blocking", "manage_with_web": true }, { "name": "enable_ban_hostgroup", "type": "bool", "unit": "", "description": "Completely enable or disable all ban for total traffic per hostgroup", "tooltip": "", "category": "ban_management", "group": "", "pretty_name": "Enable blocking per hostgroup", "manage_with_web": true }, { "name": "web_api_password", "type": "string", "unit": "", "description": "Password for web API", "tooltip": "", "category": "web_api", "group": "", "pretty_name": "Password", "sensitive": true, "manage_with_web": true } ] } ``` For hostgroup configuration it will look this way: ``` curl -s -X GET -u admin:your_password_replace_it https://127.0.0.1:10007/fields/hostgroup ``` Example output: ``` { "success": true, "error_text": "", "values": [ { "name": "name", "type": "string", "unit": "", "description": "Name of host group", "tooltip": "Name of newly created group of hosts", "category": "", "group": "", "pretty_name": "Host group name", "manage_with_web": true }, { "name": "parent_name", "type": "string", "unit": "", "description": "Parent host group name", "tooltip": "Parent host group name", "category": "", "group": "", "pretty_name": "Parent host group name", "manage_with_web": true } ] } ``` Due to large number of configuration option in main configuration we distinguish them into categories and full list of categories with description can be requested this way: ``` curl -s -X GET -u admin:your_password_replace_it https://127.0.0.1:10007/configuration_categories/main ``` Example output: ``` { "success": true, "error_text": "", "values": [ { "name": "traffic_calculation_management", "pretty_name": "Traffic calculation", "manage_with_web": true }, { "name": "ban_management", "pretty_name": "Attack detection", "manage_with_web": true }, { "name": "network_management", "pretty_name": "Networks configuration", "manage_with_web": true }, { "name": "af_packet", "pretty_name": "Mirror / SPAN AF_PACKET", "manage_with_web": true }, { "name": "xdp", "pretty_name": "Mirror / SPAN AF_XDP", "manage_with_web": true }, { "name": "sflow", "pretty_name": "sFlow", "manage_with_web": true }, { "name": "netflow", "pretty_name": "Netflow / IPFIX", "manage_with_web": true }, { "name": "tera_flow", "pretty_name": "Tera Flow", "manage_with_web": true }, { "name": "bgp", "pretty_name": "BGP settings", "manage_with_web": true }, { "name": "email_notification", "pretty_name": "Email notification", "manage_with_web": true }, { "name": "notify_script", "pretty_name": "Notify script", "manage_with_web": true }, { "name": "web_callback", "pretty_name": "Web hooks", "manage_with_web": true }, { "name": "influxdb", "pretty_name": "InfluxDB metrics", "manage_with_web": true }, { "name": "clickhouse_metrics", "pretty_name": "Clickhouse metrics", "manage_with_web": true }, { "name": "graphite", "pretty_name": "Graphite metrics", "manage_with_web": true }, { "name": "traffic_db", "pretty_name": "Traffic persistency", "manage_with_web": true }, { "name": "redis", "pretty_name": "Redis configuration", "manage_with_web": true }, { "name": "system", "pretty_name": "System options", "manage_with_web": true }, { "name": "web_api", "pretty_name": "Web API", "manage_with_web": true }, { "name": "logging", "pretty_name": "Log configuration", "manage_with_web": true } ] } ``` ### Getting total traffic counters To get total traffic counters you can use following query: ``` curl -q -X GET -u admin:password https://127.0.0.1:10007/total_traffic_counters { "success": true, "values": [ { "counter_name": "incoming traffic", "value": 74960, "unit": "pps" }, { "counter_name": "incoming tcp traffic", "value": 43982, "unit": "pps" }, { "counter_name": "incoming udp traffic", "value": 30830, "unit": "pps" }, { "counter_name": "incoming icmp traffic", "value": 107, "unit": "pps" }, { "counter_name": "incoming fragmented traffic", "value": 0, "unit": "pps" }, { "counter_name": "incoming tcp_syn traffic", "value": 9483, "unit": "pps" }, { "counter_name": "incoming dropped traffic", "value": 0, "unit": "pps" }, { "counter_name": "incoming traffic", "value": 739, "unit": "mbps" }, { "counter_name": "incoming tcp traffic", "value": 458, "unit": "mbps" }, { "counter_name": "incoming udp traffic", "value": 281, "unit": "mbps" }, { "counter_name": "incoming icmp traffic", "value": 0, "unit": "mbps" }, { "counter_name": "incoming fragmented traffic", "value": 0, "unit": "mbps" }, { "counter_name": "incoming tcp_syn traffic", "value": 90, "unit": "mbps" }, { "counter_name": "incoming dropped traffic", "value": 0, "unit": "mbps" }, { "counter_name": "incoming traffic", "value": 676, "unit": "flows" }, { "counter_name": "outgoing traffic", "value": 30533, "unit": "pps" }, { "counter_name": "outgoing tcp traffic", "value": 21009, "unit": "pps" }, { "counter_name": "outgoing udp traffic", "value": 9378, "unit": "pps" }, { "counter_name": "outgoing icmp traffic", "value": 99, "unit": "pps" }, { "counter_name": "outgoing fragmented traffic", "value": 0, "unit": "pps" }, { "counter_name": "outgoing tcp_syn traffic", "value": 5341, "unit": "pps" }, { "counter_name": "outgoing dropped traffic", "value": 0, "unit": "pps" }, { "counter_name": "outgoing traffic", "value": 57, "unit": "mbps" }, { "counter_name": "outgoing tcp traffic", "value": 24, "unit": "mbps" }, { "counter_name": "outgoing udp traffic", "value": 32, "unit": "mbps" }, { "counter_name": "outgoing icmp traffic", "value": 0, "unit": "mbps" }, { "counter_name": "outgoing fragmented traffic", "value": 0, "unit": "mbps" }, { "counter_name": "outgoing tcp_syn traffic", "value": 6, "unit": "mbps" }, { "counter_name": "outgoing dropped traffic", "value": 0, "unit": "mbps" }, { "counter_name": "outgoing traffic", "value": 661, "unit": "flows" }, { "counter_name": "internal traffic", "value": 173, "unit": "pps" }, { "counter_name": "internal tcp traffic", "value": 172, "unit": "pps" }, { "counter_name": "internal udp traffic", "value": 0, "unit": "pps" }, { "counter_name": "internal icmp traffic", "value": 0, "unit": "pps" }, { "counter_name": "internal fragmented traffic", "value": 0, "unit": "pps" }, { "counter_name": "internal tcp_syn traffic", "value": 37, "unit": "pps" }, { "counter_name": "internal dropped traffic", "value": 0, "unit": "pps" }, { "counter_name": "internal traffic", "value": 0, "unit": "mbps" }, { "counter_name": "internal tcp traffic", "value": 0, "unit": "mbps" }, { "counter_name": "internal udp traffic", "value": 0, "unit": "mbps" }, { "counter_name": "internal icmp traffic", "value": 0, "unit": "mbps" }, { "counter_name": "internal fragmented traffic", "value": 0, "unit": "mbps" }, { "counter_name": "internal tcp_syn traffic", "value": 0, "unit": "mbps" }, { "counter_name": "internal dropped traffic", "value": 0, "unit": "mbps" }, { "counter_name": "other traffic", "value": 2475, "unit": "pps" }, { "counter_name": "other tcp traffic", "value": 2132, "unit": "pps" }, { "counter_name": "other udp traffic", "value": 260, "unit": "pps" }, { "counter_name": "other icmp traffic", "value": 50, "unit": "pps" }, { "counter_name": "other fragmented traffic", "value": 0, "unit": "pps" }, { "counter_name": "other tcp_syn traffic", "value": 1118, "unit": "pps" }, { "counter_name": "other dropped traffic", "value": 0, "unit": "pps" }, { "counter_name": "other traffic", "value": 20, "unit": "mbps" }, { "counter_name": "other tcp traffic", "value": 19, "unit": "mbps" }, { "counter_name": "other udp traffic", "value": 1, "unit": "mbps" }, { "counter_name": "other icmp traffic", "value": 0, "unit": "mbps" }, { "counter_name": "other fragmented traffic", "value": 0, "unit": "mbps" }, { "counter_name": "other tcp_syn traffic", "value": 10, "unit": "mbps" }, { "counter_name": "other dropped traffic", "value": 0, "unit": "mbps" } ] } ``` If mbits granularity is not precise for you then you can specify bits per second using query argument this way: ``` curl -X GET -u admin:password https://127.0.0.1:10007/total_traffic_counters?bandwidth_unit=bps ``` Example output: ``` { "success": true, "values": [ { "counter_name": "incoming traffic", "value": 79322, "unit": "pps" }, { "counter_name": "incoming tcp traffic", "value": 43687, "unit": "pps" }, { "counter_name": "incoming udp traffic", "value": 35519, "unit": "pps" }, { "counter_name": "incoming icmp traffic", "value": 72, "unit": "pps" }, { "counter_name": "incoming fragmented traffic", "value": 0, "unit": "pps" }, { "counter_name": "incoming tcp_syn traffic", "value": 12040, "unit": "pps" }, { "counter_name": "incoming dropped traffic", "value": 0, "unit": "pps" }, { "counter_name": "incoming traffic", "value": 723954760, "unit": "bps" }, { "counter_name": "incoming tcp traffic", "value": 414577552, "unit": "bps" }, { "counter_name": "incoming udp traffic", "value": 309300432, "unit": "bps" }, { "counter_name": "incoming icmp traffic", "value": 56304, "unit": "bps" }, { "counter_name": "incoming fragmented traffic", "value": 0, "unit": "bps" }, { "counter_name": "incoming tcp_syn traffic", "value": 104146192, "unit": "bps" }, { "counter_name": "incoming dropped traffic", "value": 0, "unit": "bps" }, { "counter_name": "incoming traffic", "value": 677, "unit": "flows" }, { "counter_name": "outgoing traffic", "value": 32456, "unit": "pps" }, { "counter_name": "outgoing tcp traffic", "value": 19920, "unit": "pps" }, { "counter_name": "outgoing udp traffic", "value": 12376, "unit": "pps" }, { "counter_name": "outgoing icmp traffic", "value": 112, "unit": "pps" }, { "counter_name": "outgoing fragmented traffic", "value": 0, "unit": "pps" }, { "counter_name": "outgoing tcp_syn traffic", "value": 5556, "unit": "pps" }, { "counter_name": "outgoing dropped traffic", "value": 0, "unit": "pps" }, { "counter_name": "outgoing traffic", "value": 66208392, "unit": "bps" }, { "counter_name": "outgoing tcp traffic", "value": 21041712, "unit": "bps" }, { "counter_name": "outgoing udp traffic", "value": 45059632, "unit": "bps" }, { "counter_name": "outgoing icmp traffic", "value": 89744, "unit": "bps" }, { "counter_name": "outgoing fragmented traffic", "value": 0, "unit": "bps" }, { "counter_name": "outgoing tcp_syn traffic", "value": 6489344, "unit": "bps" }, { "counter_name": "outgoing dropped traffic", "value": 0, "unit": "bps" }, { "counter_name": "outgoing traffic", "value": 654, "unit": "flows" }, { "counter_name": "internal traffic", "value": 64, "unit": "pps" }, { "counter_name": "internal tcp traffic", "value": 53, "unit": "pps" }, { "counter_name": "internal udp traffic", "value": 0, "unit": "pps" }, { "counter_name": "internal icmp traffic", "value": 0, "unit": "pps" }, { "counter_name": "internal fragmented traffic", "value": 0, "unit": "pps" }, { "counter_name": "internal tcp_syn traffic", "value": 38, "unit": "pps" }, { "counter_name": "internal dropped traffic", "value": 0, "unit": "pps" }, { "counter_name": "internal traffic", "value": 59352, "unit": "bps" }, { "counter_name": "internal tcp traffic", "value": 28912, "unit": "bps" }, { "counter_name": "internal udp traffic", "value": 30304, "unit": "bps" }, { "counter_name": "internal icmp traffic", "value": 0, "unit": "bps" }, { "counter_name": "internal fragmented traffic", "value": 0, "unit": "bps" }, { "counter_name": "internal tcp_syn traffic", "value": 22848, "unit": "bps" }, { "counter_name": "internal dropped traffic", "value": 0, "unit": "bps" }, { "counter_name": "other traffic", "value": 7165, "unit": "pps" }, { "counter_name": "other tcp traffic", "value": 6857, "unit": "pps" }, { "counter_name": "other udp traffic", "value": 270, "unit": "pps" }, { "counter_name": "other icmp traffic", "value": 9, "unit": "pps" }, { "counter_name": "other fragmented traffic", "value": 0, "unit": "pps" }, { "counter_name": "other tcp_syn traffic", "value": 3710, "unit": "pps" }, { "counter_name": "other dropped traffic", "value": 0, "unit": "pps" }, { "counter_name": "other traffic", "value": 68813904, "unit": "bps" }, { "counter_name": "other tcp traffic", "value": 67173808, "unit": "bps" }, { "counter_name": "other udp traffic", "value": 1626032, "unit": "bps" }, { "counter_name": "other icmp traffic", "value": 13856, "unit": "bps" }, { "counter_name": "other fragmented traffic", "value": 0, "unit": "bps" }, { "counter_name": "other tcp_syn traffic", "value": 35634448, "unit": "bps" }, { "counter_name": "other dropped traffic", "value": 0, "unit": "bps" } ] } ``` ### Getting per network counters Example for IPv4: ``` curl -s -q -X GET -u admin:password 'https://127.0.0.1:10007/network_counters' ``` Output: ``` { "success": true, "values": [ { "network_name": "1.2.3.0/22", "incoming_packets": 55977, "incoming_bytes": 60999091, "fragmented_incoming_packets": 0, "fragmented_incoming_bytes": 0, "dropped_incoming_packets": 0, "dropped_incoming_bytes": 0, "tcp_incoming_packets": 26120, "tcp_incoming_bytes": 27493327, "tcp_syn_incoming_packets": 7124, "tcp_syn_incoming_bytes": 5356426, "udp_incoming_packets": 29717, "udp_incoming_bytes": 33478976, "icmp_incoming_packets": 86, "icmp_incoming_bytes": 7169, "outgoing_packets": 21648, "outgoing_bytes": 5241102, "fragmented_outgoing_packets": 0, "fragmented_outgoing_bytes": 0, "dropped_outgoing_packets": 0, "dropped_outgoing_bytes": 0, "tcp_outgoing_packets": 12606, "tcp_outgoing_bytes": 2141609, "tcp_syn_outgoing_packets": 3058, "tcp_syn_outgoing_bytes": 615520, "udp_outgoing_packets": 8883, "udp_outgoing_bytes": 3086342, "icmp_outgoing_packets": 96, "icmp_outgoing_bytes": 8507 } ] } ``` Example for IPv4 per /24: ``` curl -s -q -X GET -u admin:password 'https://127.0.0.1:10007/network_counters_24' ``` Output: ``` { "success": true, "values": [ { "network_name": "3.2.1.0/24", "incoming_packets": 11594, "incoming_bytes": 13214969, "fragmented_incoming_packets": 0, "fragmented_incoming_bytes": 0, "dropped_incoming_packets": 0, "dropped_incoming_bytes": 0, "tcp_incoming_packets": 5168, "tcp_incoming_bytes": 6276432, "tcp_syn_incoming_packets": 842, "tcp_syn_incoming_bytes": 867279, "udp_incoming_packets": 6404, "udp_incoming_bytes": 6937760, "icmp_incoming_packets": 1, "icmp_incoming_bytes": 715, "outgoing_packets": 5174, "outgoing_bytes": 1394130, "fragmented_outgoing_packets": 0, "fragmented_outgoing_bytes": 0, "dropped_outgoing_packets": 0, "dropped_outgoing_bytes": 0, "tcp_outgoing_packets": 2844, "tcp_outgoing_bytes": 466008, "tcp_syn_outgoing_packets": 567, "tcp_syn_outgoing_bytes": 117357, "udp_outgoing_packets": 2301, "udp_outgoing_bytes": 927206, "icmp_outgoing_packets": 1, "icmp_outgoing_bytes": 853 }, { "network_name": "1.2.3.0/24", "incoming_packets": 5837, "incoming_bytes": 2983589, "fragmented_incoming_packets": 0, "fragmented_incoming_bytes": 0, "dropped_incoming_packets": 0, "dropped_incoming_bytes": 0, "tcp_incoming_packets": 4582, "tcp_incoming_bytes": 1557957, "tcp_syn_incoming_packets": 2403, "tcp_syn_incoming_bytes": 770899, "udp_incoming_packets": 1166, "udp_incoming_bytes": 1402097, "icmp_incoming_packets": 37, "icmp_incoming_bytes": 3631, "outgoing_packets": 980, "outgoing_bytes": 258966, "fragmented_outgoing_packets": 0, "fragmented_outgoing_bytes": 0, "dropped_outgoing_packets": 0, "dropped_outgoing_bytes": 0, "tcp_outgoing_packets": 636, "tcp_outgoing_bytes": 96589, "tcp_syn_outgoing_packets": 75, "tcp_syn_outgoing_bytes": 23469, "udp_outgoing_packets": 281, "udp_outgoing_bytes": 158878, "icmp_outgoing_packets": 16, "icmp_outgoing_bytes": 1694 } ] } ``` Example for IPv6 networks: ``` curl -s -q -X GET -u admin:password 'https://127.0.0.1:10007/network_counters_v6' ``` ### Getting top ASN counters Example query: ``` curl -X GET -u admin:password https://127.0.0.1:10007/asn_counters_v4 { "success": true, "values": [ { "asn_number": 12345, "incoming_packets": 23726, "incoming_bytes": 32799035, "incoming_flows": 0, "fragmented_incoming_packets": 0, "fragmented_incoming_bytes": 0, "dropped_incoming_packets": 0, "dropped_incoming_bytes": 0, "tcp_incoming_packets": 14191, "tcp_incoming_bytes": 20256697, "tcp_syn_incoming_packets": 2804, "tcp_syn_incoming_bytes": 4027798, "udp_incoming_packets": 9520, "udp_incoming_bytes": 12542321, "icmp_incoming_packets": 0, "icmp_incoming_bytes": 0 }] } ``` For IPv6 traffic you need to use another query: ``` curl -X GET -u admin:password https://127.0.0.1:10007/asn_counters_v6 ``` ### Getting whole main configuration ``` curl -q -X GET -u admin:admin 'https://127.0.0.1:10007/main' ``` Example output: ``` { "success": true, "error_text": "", "object": { "mirror_afpacket": false, "af_packet_extract_tunnel_traffic": false, "mirror_af_packet_sampling": true, "mirror_af_external_packet_sampling": false, "mirror_af_packet_socket_stats": true, "mirror_af_packet_disable_multithreading": true, "mirror_af_packet_fanout_mode": "cpu", "mirror_af_packet_sampling_rate": 100, "mirror_external_af_packet_sampling_rate": 100, "mirror_af_packet_workers_number_override": false, "mirror_af_packet_workers_number": 1, "afpacket_strict_cpu_affinity": false, "af_packet_read_packet_length_from_ip_header": false, "enable_api": true, "api_host": "127.0.0.1", "api_port": 50052, "app_packet_sr": false, "app_packet_sr_tunnel_traffic": false, "app_packet_sr_read_packet_length_from_ip_header": false, "enable_ban": false, "enable_ban_hostgroup": false, "enable_ban_remote_outgoing": false, "enable_ban_remote_incoming": false, "do_not_ban_incoming": false, "do_not_ban_outgoing": false, "per_direction_hostgroup_thresholds": true, "flexible_thresholds": true, "flexible_thresholds_disable_multi_alerts": false, "keep_flow_spec_announces_during_restart": false, "keep_blocked_hosts_during_restart": false, "keep_blocked_hostgroups_during_restart": false, "enable_ban_ipv6": false, "unban_enabled": true, "ban_status_updates": false, "ban_status_delay": 20, "ban_time": 300, "unban_only_if_attack_finished": true, "gobgp_flow_spec_announces": false, "gobgp_flow_spec_v6_announces": false, "flow_spec_unban_enabled": true, "flow_spec_per_hostgroup_management": false, "flow_spec_ban_time": 1900, "collect_attack_pcap_dumps": false, "collect_simple_attack_dumps": true, "ban_details_records_count": 25, "threshold_specific_ban_details": false, "do_not_cap_ban_details_records_count": false, "unban_total_hostgroup_enabled": true, "ban_time_total_hostgroup": 675, "bucket_traffic_collection_timeout": 60, "gobgp": false, "gobgp_api_host": "localhost", "gobgp_api_port": 50051, "gobgp_bgp_listen_port": 179, "gobgp_router_id": "", "gobgp_next_hop": "1.2.3.4", "gobgp_next_hop_host_ipv4": "0.0.0.0", "gobgp_next_hop_subnet_ipv4": "0.0.0.0", "gobgp_next_hop_remote_host": "0.0.0.0", "gobgp_do_not_manage_daemon": false, "gobgp_announce_host": false, "gobgp_announce_whole_subnet": false, "gobgp_announce_whole_subnet_force_custom_prefix_length": false, "gobgp_announce_whole_subnet_custom_prefix_length": 24, "gobgp_announce_whole_subnet_force_custom_ipv6_prefix_length": false, "gobgp_announce_whole_subnet_custom_ipv6_prefix_length": 48, "gobgp_announce_remote_host": false, "gobgp_community_host": "65536:668", "gobgp_community_subnet": "65001:667", "gobgp_community_remote_host": "65001:669", "gobgp_ipv6": false, "gobgp_next_hop_ipv6": "100::1", "gobgp_next_hop_host_ipv6": "", "gobgp_next_hop_subnet_ipv6": "", "gobgp_announce_host_ipv6": false, "gobgp_announce_whole_subnet_ipv6": false, "gobgp_community_host_ipv6": "65001:668", "gobgp_community_subnet_ipv6": "65001:667", "gobgp_flow_spec_default_action": "discard", "gobgp_flow_spec_v4_redirect_target_as": 0, "gobgp_flow_spec_v4_redirect_target_community": 0, "gobgp_flow_spec_v6_redirect_target_as": 0, "gobgp_flow_spec_v6_redirect_target_community": 0, "gobgp_flow_spec_v6_default_action": "discard", "gobgp_flow_spec_v6_rate_limit_value": 1024, "gobgp_flow_spec_rate_limit_value": 1024, "flow_spec_tcp_options_use_match_bit": false, "flow_spec_fragmentation_options_use_match_bit": false, "flow_spec_strip_ports_for_fragmented_traffic": false, "flow_spec_do_not_process_length_field": false, "flow_spec_do_not_process_tcp_flags_field": false, "flow_spec_do_not_process_ip_fragmentation_flags_field": false, "flow_spec_ignore_do_not_fragment_flag": false, "flow_spec_do_not_process_source_address_field": false, "flow_spec_execute_validation": false, "do_not_withdraw_unicast_announces_on_restart": false, "do_not_withdraw_flow_spec_announces_on_restart": false, "gobgp_announce_hostgroup_networks": false, "gobgp_announce_hostgroup_networks_ipv4": false, "gobgp_announce_hostgroup_networks_ipv6": false, "gobgp_next_hop_hostgroup_networks_ipv4": "0.0.0.0", "gobgp_next_hop_hostgroup_networks_ipv6": "100::1", "clickhouse_metrics": true, "clickhouse_metrics_database": "fastnetmon", "clickhouse_metrics_username": "default", "clickhouse_metrics_password": "", "clickhouse_metrics_host": "127.0.0.1", "clickhouse_metrics_port": 9000, "clickhouse_metrics_push_period": 1, "clickhouse_metrics_export_top_hosts": true, "email_notifications_enabled": true, "email_notifications_disable_certificate_checks": false, "email_notifications_host": "smtp.gmail.com", "email_notifications_port": 587, "email_notifications_tls": true, "email_notifications_auth": true, "email_notifications_auth_method": "", "email_notifications_username": "fastnetmon@yourdomain.com", "email_notifications_password": "super-secret-password", "email_notifications_from": "fastnetmon@yourdomain.com", "email_notifications_recipients": [ "pavel@fastnetmon.com" ], "email_notifications_hide_flow_spec_rules": false, "email_notifications_add_simple_packet_dump": true, "email_subject_blackhole_block": "FastNetMon blocked host {{ ip }}", "email_subject_blackhole_unblock": "FastNetMon unblocked host {{ ip }}", "email_subject_partial_block": "FastNetMon partially blocked traffic for host {{ ip }}", "email_subject_partial_unblock": "FastNetMon partially unblocked traffic for host {{ ip }}", "slack_notifications_add_simple_packet_dump": true, "filter_xdp": false, "filter_xdp_mode": "skb", "graphite": false, "graphite_host": "127.0.0.1", "graphite_port": 2003, "graphite_prefix": "fastnetmon", "graphite_push_period": 1, "influxdb_kafka": false, "influxdb_kafka_topic": "fastnetmon", "influxdb_kafka_partitioner": "consistent", "influxdb": false, "influxdb_database": "fastnetmon", "influxdb_host": "127.0.0.1", "influxdb_port": 8086, "influxdb_custom_tags": false, "influxdb_tag_name": "node", "influxdb_tag_value": "master", "influxdb_skip_host_counters": false, "influxdb_push_host_ipv6_counters": false, "influxdb_push_host_ipv4_flexible_counters": false, "influxdb_push_host_ipv6_flexible_counters": false, "influxdb_user": "fastnetmon", "influxdb_password": "fastnetmon", "influxdb_auth": false, "influxdb_attack_notification": false, "influxdb_push_period": 1, "logging_level": "info", "logging_local_syslog_logging": false, "logging_remote_syslog_logging": false, "logging_remote_syslog_server": "10.10.10.10", "logging_remote_syslog_port": 514, "mikrotik_announce_host": false, "mikrotik_announce_host_blackhole": true, "mongo_store_attack_information": true, "netflow": true, "netflow_count_packets_per_device": true, "netflow_multi_thread_processing": false, "netflow_threads_per_port": 1, "netflow_multi_thread_mode": "", "netflow_ports": [ 2055 ], "netflow_host": "0.0.0.0", "netflow_socket_read_mode": "recvfrom", "netflow_rx_queue_overflow_monitoring": false, "netflow_ignore_sampling_rate_from_device": false, "netflow_ignore_long_duration_flow_enable": false, "netflow_long_duration_flow_limit": 1, "netflow_v9_read_sampling_rate_in_data_section": false, "netflow_v9_extract_tunnel_traffic": false, "ipfix_extract_tunnel_traffic": false, "netflow_sampling_ratio": 1, "netflow_v5_custom_sampling_ratio_enable": false, "netflow_v5_sampling_ratio": 1, "netflow_templates_cache": true, "netflow_sampling_cache": true, "netflow_process_only_flows_with_dropped_packets": false, "netflow_mark_zero_next_hop_and_zero_output_as_dropped": false, "networks_list": [ "1.2.3.0/22", "aaaa:bbb::36ff/64" ], "monitor_local_ip_addresses": false, "notify_script_hostgroup_enabled": false, "notify_script_hostgroup_path": "/etc/fastnetmon/scripts/notify_about_attack.sh", "notify_script_enabled": true, "notify_script_attack_status_updates": false, "notify_script_path": "/var/www/html/notify_json.php", "notify_script_format": "json", "prometheus": true, "prometheus_host": "0.0.0.0", "prometheus_port": 9209, "prometheus_export_host_ipv4_counters": true, "prometheus_export_host_ipv6_counters": true, "prometheus_export_network_ipv4_counters": true, "prometheus_export_network_ipv6_counters": true, "redis_enabled": false, "redis_host": "127.0.0.1", "redis_port": 6379, "redis_prefix": "fastnetmon", "sflow": false, "sflow_extract_tunnel_traffic": false, "sflow_count_packets_per_device": false, "sflow_ports": [ 6343 ], "sflow_host": "0.0.0.0", "sflow_read_packet_length_from_ip_header": false, "sflow_track_sampling_rate": false, "slack_notifications_enabled": false, "slack_notifications_url": "https://hooks.slack.com/services/TXXXXXXXX/BXXXXXXXXX/LXXXXXXXXX", "cache_path": "/var/cache/fastnetmon", "asn_lookup": true, "country_lookup": false, "force_asn_lookup": false, "pid_path": "/var/run/fastnetmon.pid", "api_host_counters_max_hosts_in_response": 100, "system_user": "fastnetmon", "system_group": "fastnetmon", "drop_root_permissions": false, "license_use_port_443": true, "telegram_notifications_enabled": false, "telegram_notifications_bot_token": "xxx:xxx", "telegram_notifications_add_simple_packet_dump": true, "tera_flow": false, "tera_flow_host": "0.0.0.0", "tera_flow_tls_certificate_path": "", "tera_flow_tls_certificate_chain": false, "tera_flow_tls_private_key_path": "", "keep_traffic_counters_during_restart": true, "process_incoming_traffic": true, "process_outgoing_traffic": true, "override_internal_traffic_as_incoming": false, "override_internal_traffic_as_outgoing": false, "process_ipv6_traffic": true, "enable_connection_tracking": true, "remote_host_tracking": false, "connection_tracking_skip_ports": false, "enable_total_hostgroup_counters": true, "enable_interface_counters": true, "enable_asn_counters": true, "build_total_hostgroups_from_per_host_hostgroups": false, "dump_other_traffic": false, "dump_internal_traffic": false, "dump_all_traffic": false, "dump_all_traffic_json": false, "speed_calculation_delay": 1, "parallel_speed_calculation": false, "parallel_speed_calculation_threads": 0, "average_calculation_time": 30, "flow_forwarder": false, "flow_forwarder_sampling_rate": 512, "ipv6_automatic_data_cleanup": true, "ipv6_automatic_data_cleanup_threshold": 300, "ipv6_automatic_data_cleanup_delay": 300, "ipv4_automatic_data_cleanup": true, "ipv4_automatic_data_cleanup_threshold": 300, "ipv4_automatic_data_cleanup_delay": 300, "ipv4_remote_automatic_data_cleanup": true, "ipv4_remote_automatic_data_cleanup_threshold": 300, "ipv4_remote_automatic_data_cleanup_delay": 300, "traffic_buffer": true, "traffic_buffer_size": 100000, "traffic_buffer_port_mirror": false, "generate_attack_traffic_samples": false, "generate_attack_traffic_samples_delay": 60, "generate_max_talkers_report": true, "generate_max_talkers_report_delay": 60, "generate_hostgroup_traffic_samples": true, "generate_hostgroup_traffic_samples_delay": 60, "traffic_db": true, "traffic_db_host": "127.0.0.1", "traffic_db_port": 8100, "traffic_db_sampling_rate": 512, "vyos_announce_host": false, "vyos_announce_host_blackhole": true, "web_api_host": "127.0.0.1", "web_api_port": 10007, "web_api_login": "admin", "web_api_password": "xxxx", "web_api_ssl": false, "web_api_trace_queries": true, "web_api_ssl_port": 10443, "web_api_ssl_host": "127.0.0.1", "web_api_ssl_certificate_path": "", "web_api_ssl_private_key_path": "", "web_callback_enabled": false, "web_callback_url": "https://127.0.0.1:8080/attack/notify", "mirror_xdp": false, "xdp_read_packet_length_from_ip_header": false, "force_native_mode_xdp": false, "zero_copy_xdp": false, "poll_mode_xdp": false, "xdp_set_promisc": false, "xdp_extract_tunnel_traffic": false, "microcode_xdp_path": "/etc/fastnetmon/xdp_kernel.o" } } ``` ### Getting whole BGP settings ``` curl -q -X GET -u admin:admin 'https://127.0.0.1:10007/bgp' ``` Example output: ``` { "success": true, "error_text": "", "values": [ { "name": "new", "description": "", "local_asn": 5435, "local_address": "1.2.3.4", "subnet_learning": false, "remote_asn": 12323, "remote_address": "1.2.3.4", "multihop": false, "ipv4_unicast_add_path": false, "ipv6_unicast_add_path": false, "md5_auth": false, "md5_auth_password": "", "ipv4_unicast": true, "ipv6_unicast": false, "ipv4_flowspec": false, "ipv6_flowspec": false, "ipv4_unicast_announces_limit": 0, "ipv6_unicast_announces_limit": 0, "ipv4_flowspec_announces_limit": 0, "ipv6_flowspec_announces_limit": 0, "active": true }, { "name": "second_peer", "description": "", "local_asn": 0, "local_address": "", "subnet_learning": false, "remote_asn": 0, "remote_address": "", "multihop": false, "ipv4_unicast_add_path": false, "ipv6_unicast_add_path": false, "md5_auth": false, "md5_auth_password": "", "ipv4_unicast": false, "ipv6_unicast": false, "ipv4_flowspec": false, "ipv6_flowspec": false, "ipv4_unicast_announces_limit": 0, "ipv6_unicast_announces_limit": 0, "ipv4_flowspec_announces_limit": 0, "ipv6_flowspec_announces_limit": 0, "active": false } ] } ``` ### Getting whole hostgroup configuration ``` curl -q -X GET -u admin:admin 'https://127.0.0.1:10007/hostgroup' ``` Example output: ``` { "success": true, "error_text": "", "values": [ { "name": "global", "parent_name": "", "description": "This is default group for all hosts", "calculation_method": "per_host", "enable_ban": false, "ban_for_pps": false, "ban_for_bandwidth": false, "ban_for_flows": false, "threshold_pps": 100000, "threshold_mbps": 1000, "threshold_flows": 3500, "ban_for_tcp_bandwidth": false, "ban_for_udp_bandwidth": true, "ban_for_icmp_bandwidth": false, "ban_for_tcp_pps": false, "ban_for_udp_pps": false, "ban_for_icmp_pps": false, "threshold_tcp_mbps": 1000, "threshold_udp_mbps": 700, "threshold_icmp_mbps": 1000, "threshold_tcp_pps": 100000, "threshold_udp_pps": 100000, "threshold_icmp_pps": 100000, "ban_for_tcp_syn_pps": false, "threshold_tcp_syn_pps": 1000, "ban_for_tcp_syn_bandwidth": false, "threshold_tcp_syn_mbps": 1000, "ban_for_ip_fragments_pps": false, "threshold_ip_fragments_pps": 1000, "ban_for_ip_fragments_bandwidth": false, "threshold_ip_fragments_mbps": 1000, "enable_ban_incoming": false, "enable_ban_outgoing": false, "enable_bgp_flow_spec": false, "ban_for_pps_outgoing": false, "ban_for_bandwidth_outgoing": false, "ban_for_flows_outgoing": false, "threshold_pps_outgoing": 100000, "threshold_mbps_outgoing": 1000, "threshold_flows_outgoing": 3500, "ban_for_tcp_bandwidth_outgoing": false, "ban_for_udp_bandwidth_outgoing": false, "ban_for_icmp_bandwidth_outgoing": false, "ban_for_tcp_pps_outgoing": false, "ban_for_udp_pps_outgoing": false, "ban_for_icmp_pps_outgoing": false, "threshold_tcp_mbps_outgoing": 1000, "threshold_udp_mbps_outgoing": 1000, "threshold_icmp_mbps_outgoing": 1000, "threshold_tcp_pps_outgoing": 100000, "threshold_udp_pps_outgoing": 100000, "threshold_icmp_pps_outgoing": 100000, "ban_for_tcp_syn_pps_outgoing": false, "threshold_tcp_syn_pps_outgoing": 1000, "ban_for_tcp_syn_bandwidth_outgoing": false, "threshold_tcp_syn_mbps_outgoing": 1000, "ban_for_ip_fragments_pps_outgoing": false, "threshold_ip_fragments_pps_outgoing": 1000, "ban_for_ip_fragments_bandwidth_outgoing": false, "threshold_ip_fragments_mbps_outgoing": 1000, "flexible_thresholds": { "dns": { "name": "dns", "active": false, "incoming_mbits_enable": false, "outgoing_mbits_enable": false, "incoming_mbits_value": 0, "outgoing_mbits_value": 0, "incoming_packets_enable": false, "outgoing_packets_enable": false, "incoming_packets_value": 0, "outgoing_packets_value": 0, "incoming_flows_enable": false, "outgoing_flows_enable": false, "incoming_flows_value": 0, "outgoing_flows_value": 0 }, "memcache": { "name": "memcache", "active": true, "incoming_mbits_enable": true, "outgoing_mbits_enable": false, "incoming_mbits_value": 200, "outgoing_mbits_value": 0, "incoming_packets_enable": false, "outgoing_packets_enable": false, "incoming_packets_value": 0, "outgoing_packets_value": 0, "incoming_flows_enable": false, "outgoing_flows_enable": false, "incoming_flows_value": 0, "outgoing_flows_value": 0 }, "ntp": { "name": "ntp", "active": false, "incoming_mbits_enable": false, "outgoing_mbits_enable": false, "incoming_mbits_value": 0, "outgoing_mbits_value": 0, "incoming_packets_enable": false, "outgoing_packets_enable": false, "incoming_packets_value": 0, "outgoing_packets_value": 0, "incoming_flows_enable": false, "outgoing_flows_enable": false, "incoming_flows_value": 0, "outgoing_flows_value": 0 } } }, ] } ``` ### Blackhole attack information To get information about blackhole attack you can use following API query: ``` curl -q -X GET -u admin:admin 'https://127.0.0.1:10007/blackhole/b76cbf5c-4857-4148-8639-e59c0fa846e7' ``` Example response: ``` {"success":true,"error_text":"","attack_uuid":"e8581e65-b734-4d09-b0c7-5d3648ef6276","ip_address":"10.0.0.1","protocol_version":"ipv4","host_group":"global","attack_detection_threshold":"unknown","attack_detection_threshold_direction":"unknown","host_network":"10.0.0.0/24","attack_detection_source":"manual","attack_severity":"middle"} ``` ### Getting total hostgroups counters Example query: ``` curl -q -X GET -u admin:admin 'https://127.0.0.1:10007/hostgroup_counters_total' ``` Example answer: ``` { "success": true, "values": [ { "bgp_in_bytes": 0, "bgp_in_packets": 0, "bgp_out_bytes": 0, "bgp_out_packets": 0, "chargen_in_bytes": 0, "chargen_in_packets": 0, "chargen_out_bytes": 0, "chargen_out_packets": 0, "dhcp_in_bytes": 0, "dhcp_in_packets": 0, "dhcp_out_bytes": 0, "dhcp_out_packets": 0, "dns_in_bytes": 18469, "dns_in_packets": 104, "dns_out_bytes": 0, "dns_out_packets": 0, "dropped_in_bytes": 0, "dropped_in_packets": 0, "dropped_out_bytes": 0, "dropped_out_packets": 0, "fragmented_in_bytes": 0, "fragmented_in_packets": 0, "fragmented_out_bytes": 0, "fragmented_out_packets": 0, "hostgroup_name": "global_total", "icmp_in_bytes": 8918, "icmp_in_packets": 113, "icmp_out_bytes": 5265, "icmp_out_packets": 50, "in_bytes": 24334186, "in_flows": 0, "in_packets": 21007, "incoming_bytes": 24334186, "incoming_bytes_dropped": 0, "incoming_bytes_fragmented": 0, "incoming_bytes_icmp": 8918, "incoming_bytes_tcp": 16140753, "incoming_bytes_tcp_syn": 2913653, "incoming_bytes_udp": 8182418, "incoming_packets": 21007, "incoming_packets_dropped": 0, "incoming_packets_fragmented": 0, "incoming_packets_icmp": 113, "incoming_packets_tcp": 13101, "incoming_packets_tcp_syn": 2686, "incoming_packets_udp": 7755, "memcache_in_bytes": 0, "memcache_in_packets": 0, "memcache_out_bytes": 0, "memcache_out_packets": 0, "mt_api_in_bytes": 47, "mt_api_in_packets": 0, "mt_api_out_bytes": 0, "mt_api_out_packets": 0, "mt_winbox_in_bytes": 24, "mt_winbox_in_packets": 0, "mt_winbox_out_bytes": 54054, "mt_winbox_out_packets": 333, "ntp_in_bytes": 329, "ntp_in_packets": 0, "ntp_out_bytes": 2, "ntp_out_packets": 0, "out_bytes": 3094181, "out_flows": 0, "out_packets": 10297, "outgoing_bytes": 3094181, "outgoing_bytes_dropped": 0, "outgoing_bytes_fragmented": 0, "outgoing_bytes_icmp": 5265, "outgoing_bytes_tcp": 1425819, "outgoing_bytes_tcp_syn": 477591, "outgoing_bytes_udp": 1660954, "outgoing_packets": 10297, "outgoing_packets_dropped": 0, "outgoing_packets_fragmented": 0, "outgoing_packets_icmp": 50, "outgoing_packets_tcp": 7086, "outgoing_packets_tcp_syn": 1606, "outgoing_packets_udp": 3110, "tcp_in_bytes": 16140753, "tcp_in_packets": 13101, "tcp_out_bytes": 1425819, "tcp_out_packets": 7086, "tcp_syn_in_bytes": 2913653, "tcp_syn_in_packets": 2686, "tcp_syn_out_bytes": 477591, "tcp_syn_out_packets": 1606, "udp_in_bytes": 8182418, "udp_in_packets": 7755, "udp_out_bytes": 1660954, "udp_out_packets": 3110 } ] } ``` ### Total per hostgroup blocks To block hostgroup you can use following query: ``` curl -q -X PUT -u admin:admin@1518 'https://127.0.0.1:10007/hostgroup_block/global_total' ``` Example response: ``` {"success":true,"error_text":""} ``` To list all blocked hostgroups please use this command: ``` curl -q -X GET -u admin:admin 'https://127.0.0.1:10007/hostgroup_block' ``` Example response: ``` {"success":true,"values":[{"uuid":"61475403-cf4a-45cb-b685-8c5f9706c164","hostgroup_name":"global_total"}]} ``` To unblock hostgroup please use this command: ``` curl -q -X DELETE -u admin:admin 'https://127.0.0.1:10007/hostgroup_block/61475403-cf4a-45cb-b685-8c5f9706c164' ``` Example response: ``` {"success":true,"error_text":""} ``` ### Getting list of all physical interfaces on server Query: ``` curl -q -X GET -u admin:admin 'https://127.0.0.1:10007/interfaces' ``` Example response: ``` {"success":true,"error_text":"","values":["ens4"]} ``` ### How to get all traffic from traffic buffer about our particular IP? Query: ``` curl -q -X GET -u admin:admin 'https://127.0.0.1:10007/traffic_buffer/10.0.0.1' ``` Example answer: ``` { "success": true, "values": [ { "agent_address": "0.0.0.0", "destination_asn": 15169, "destination_country": "", "destination_ip": "216.58.204.142", "destination_mac": "0c:c4:7a:b0:00:0b", "destination_port": 443, "forwarding_status": "unknown", "fragmentation": false, "input_interface": 2, "ip_dont_fragment": true, "ip_fragment_offset": 0, "ip_length": 1278, "ip_more_fragments": false, "ip_version": "ipv4", "length": 1292, "output_interface": 2, "packets": 1, "protocol": "udp", "sample_ratio": 100, "source_asn": 0, "source_country": "", "source_ip": "192.168.249.98", "source_mac": "4c:77:cb:ed:94:d7", "source_port": 36523, "timestamp": 1755708556, "ttl": 64 }, { "agent_address": "0.0.0.0", "destination_asn": 15169, "destination_country": "", "destination_ip": "216.58.204.142", "destination_mac": "0c:c4:7a:b0:00:0b", "destination_port": 443, "forwarding_status": "unknown", "fragmentation": false, "input_interface": 2, "ip_dont_fragment": true, "ip_fragment_offset": 0, "ip_length": 1278, "ip_more_fragments": false, "ip_version": "ipv4", "length": 1292, "output_interface": 2, "packets": 1, "protocol": "udp", "sample_ratio": 100, "source_asn": 0, "source_country": "", "source_ip": "192.168.249.98", "source_mac": "4c:77:cb:ed:94:d7", "source_port": 36523, "timestamp": 1755708556, "ttl": 64 } ] } ``` ### Configuration creation, import and export via API Starting from 2.0.375 you can create new configuration using such method, please note that it will **remove** existing configuration entirely: ``` curl --user "admin:password" -X PUT http://127.0.0.1:10007/create_configuration ``` Example answer: ``` {"success":true,"error_text":""} ``` Also in same version you can export configuration to arbitrary place in filesystem, please notice that / is encoded as %2f: ``` curl --user "admin:password" -X PUT http://127.0.0.1:10007/export_configuration/%2ftmp%2fdump.tar ``` Also you cam import it similar way: ``` curl --user "admin:password" -X PUT http://127.0.0.1:10007/import_configuration/%2ftmp%2fdump.tar {"success":true,"error_text":""} ``` **Document Categories:** Developer guides --- ### [BGP announces for total hostgroups](https://fastnetmon.com/docs-fnm-advanced/bgp-announces-for-total-hostgroups/) **Published:** August 16, 2022 **Author:** Pavel Odintsov **Content:** This guide covers FastNetMon's ability to run BGP announces when total amount of traffic for a group of hosts or networks exceeds a specified threshold. This capability is called total hostgroups and is well covered in this [guide](https://fastnetmon.com/docs-fnm-advanced/per-hostgroup-thresholds/). To use this guide, you will need to have attack detection enabled for total hostgroups using this [guide](https://fastnetmon.com/docs-fnm-advanced/attack-detection-for-per-hostgroup-thresholds/). Please ensure that you have [BGP session](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-bgp-peering-session-setup/) established using this guide. To enable this logic you will need to set this flag: ``` sudo fcli set main gobgp_announce_hostgroup_networks true sudo fcli commit ``` As each total hostgroup may include both IPv4 and IPv6 prefixes simultaneously, we offer separate flags to enable announce for each of them: ``` sudo fcli set main gobgp_announce_hostgroup_networks_ipv4 true sudo fcli set main gobgp_announce_hostgroup_networks_ipv6 true sudo fcli commit ``` After making these changes, FastNetMon will announce all IPv4 and IPv6 prefixes listed for hostgroup via BGP. Then you can add list of one of more communities required for each IPv4 or IPv6 announce: ``` sudo fcli set main gobgp_communities_hostgroup_networks_ipv4 65001:771 sudo fcli set main gobgp_communities_hostgroup_networks_ipv4 65001:772 sudo fcli set main gobgp_communities_hostgroup_networks_ipv6 65001:773 sudo fcli set main gobgp_communities_hostgroup_networks_ipv6 65001:774 sudo fcli commit ``` And then you can set different next hop addresses in each case: ``` sudo fcli set main gobgp_next_hop_hostgroup_networks_ipv4 0.0.0.0 sudo fcli set main gobgp_next_hop_hostgroup_networks_ipv6 100::1 sudo fcli commit ``` After that, I can recommend testing this logic and confirming that all announces will propagate correctly via BGP. You can block some example hostrgroup in the following way: ``` sudo fcli set hostgroup_block example ``` Then check that it was blocked successfully: ``` sudo fcli show hostgroup_block ``` Then check active BGP announces on FastNetMon's BGP daemon: ``` gobgp global rib -a ipv4 gobgp global rib -a ipv6 ``` And unblock hostgroup: ``` sudo fcli delete hostgroup_block ``` After that, check that announces disappeared: ``` gobgp global rib -a ipv4 gobgp global rib -a ipv6 ``` If you have flag unban\_total\_hostgroup\_enabled then FastNetMon will remove such BGP announces automatically for you. Starting from 2.0.374 you can provide list of communities for total hostgroups on per hostgroup basis this way: ``` sudo fcli set hostgroup servers bgp_communities_hostgroup_networks_ipv4 65001:444 sudo fcli set hostgroup servers bgp_communities_hostgroup_networks_ipv6 65001:606 ``` Starting from 2.0.374 you can specify custom next hops for total hostgroups basis: ``` sudo fcli set hostgroup servers bgp_next_hops_hostgroup_networks_ipv4 5.6.7.8 sudo fcli set hostgroup servers bgp_next_hops_hostgroup_networks_ipv6 dead::beef ``` Starting from 2.0.384 you can specify AS\_PATH to total hostgroups BGP announces this way: ``` sudo fcli set main gobgp_as_path_hostgroup_networks_ipv4 12345 sudo fcli set main gobgp_as_path_hostgroup_networks_ipv4 56789 sudo fcli set main gobgp_as_path_hostgroup_networks_ipv6 12345 sudo fcli set main gobgp_as_path_hostgroup_networks_ipv6 56789 sudo fcli set hostgroup my_networks bgp_as_path_hostgroup_networks_ipv4 12345 sudo fcli set hostgroup my_networks bgp_as_path_hostgroup_networks_ipv6 12345 sudo fcli commit ``` ### **Known limitations** If you use parent\_name capability instead of specifying networks manually for total hostgroup FastNetMon will [not](https://features.fastnetmon.com/feature-requests/p/total-hostgroup-do-not-announce-networks-when-parent-name-us-used-for-network-co) able to announce all prefixes from hostgroup via BGP **Document Categories:** BGP --- ### [FastNetMon Advanced install on Hyper-V](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-install-on-hyper-v/) **Published:** March 2, 2024 **Author:** Pavel Odintsov **Content:** This guide was tested with Windows 2022 Server Standard. To start with, you'll need to download our VHD image for Hyper-V [here](https://storage.googleapis.com/fastnetmon_advanced_vm_images/fastnetmon-ubuntu-22.04-amd64-2.0.383.0.vhd). We do automated image builds on the next day from stable release. Feel free to change the file name of the image if you prefer to use the latest release. As a first step, please download the image to a folder where you prefer to keep disk of created VM. Then, on the right panel, select "New" and select "Virtual Machine". ![](https://fastnetmon.com/wp-content/uploads/2024/03/step-7-create-vm.jpg)Select generation 1 as only this one supports VHD format of disks: ![](https://fastnetmon.com/wp-content/uploads/2024/03/gen1.jpg)Then allocate at least 8192 MB of memory. Configure network connectivity to provide access to both the Internet and your internal network. Then, select path to downloaded VHD: ![](https://fastnetmon.com/wp-content/uploads/2024/03/vhd.jpg)And finally launch VM by clicking "Start on right panel" and wait until VM finishes loading: ![](https://fastnetmon.com/wp-content/uploads/2024/03/vm_loading-1.jpg)Default login and password for VM are: fastnetmon/fastnetmon. We have enabled SSH by default. Be very careful and change default passwords right after logging in. After finishing installation, please request a trial license using our form. When you receive the activation coupon, please activate it this way: ``` sudo ./installer -activate_coupon -activation_coupon [coupon_code] ``` To confirm successful activation, please restart FastNetMon and check the license status: ``` sudo fcli commit sudo fcli show license ``` As the first step, reset the password for metrics access: ``` sudo ./installer -reset_clickhouse_password ``` To enable Grafana Web UI for metrics, you have to generate passwords for it: ``` sudo ./installer -reset_visual_passwords ``` It will print the login and password required for Grafana to access the metrics and traffic persistency database Log in to FastNetMon’s UI: https://you.ip.address:81 using passwords from the previous step Finally, you can start the initial configuration of FastNetMon using the standard [guide](https://fastnetmon.com/advanced-quick-start/). **Document Categories:** Virtual machines and hypervisors --- ### [FastNetMon Advanced installation on Proxmox VM](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-installation-on-proxmox-vm/) **Published:** March 1, 2024 **Author:** Pavel Odintsov **Content:** We offer official QCOW2 images which can be used with a variety of KVM-based hypervisors. To start, please download the latest image. We do automated image builds on the next day from the stable release. Feel free to change the file name of the image if you prefer to use the latest release. This guide was prepared for Proxmox Virtual Environment 8.1.4 Start the process by creating a VM for FastNetMon: ![](https://fastnetmon.com/wp-content/uploads/2024/03/create-vm-step-1-1024x763.png)We do not need any installation media as we will use a pre-created VM disk image: ![](https://fastnetmon.com/wp-content/uploads/2024/03/step-2-1024x763.png)Specify empty disk space on local storage. We will not use it, and we will remove it later. ![](https://fastnetmon.com/wp-content/uploads/2024/03/step-3-1-1024x763.png)Then allocate at least 4 CPU cores for FastNetMon and switch "type" to use "host" CPU as it will allow to use all modern CPU features in VM: ![](https://fastnetmon.com/wp-content/uploads/2024/03/step-4-1-1024x763.png)Review settings and click finish: ![](https://fastnetmon.com/wp-content/uploads/2024/03/step-5-review-1024x763.png)Then log in to the Proxmox server using the root account via SSH and download our official QCOW2 image (please ensure to replace 371 by the latest release version as instructed above): ``` mkdir /var/lib/vz/template/qcow cd /var/lib/vz/template/qcow wget https://storage.googleapis.com/fastnetmon_advanced_vm_images/fastnetmon-ubuntu-22.04-amd64-2.0.383.0.qcow2 ``` And import it to the local LVM storage. Please replace with VM ID for your VM, which was set during creation. Please be patient as it will be a relatively lengthy process: ``` sudo qm importdisk fastnetmon-ubuntu-22.04-amd64-2.0.383.0.qcow2 local-lvm ``` Wait until it finishes to get the name of the disk (disk-1 in this case): ``` Wait until it finishes import: transferred 145.9 GiB of 146.5 GiB (99.57%) transferred 146.5 GiB of 146.5 GiB (100.00%) transferred 146.5 GiB of 146.5 GiB (100.00%) Successfully imported disk as 'unused0:local-lvm:vm-100-disk-1' ``` Then open disk configuration for new VM: ![](https://fastnetmon.com/wp-content/uploads/2024/03/open-disk-configuration-for-new-vm-1024x251.png)Select "Hard Disk (scsi0)" and click "Detach" on the top menu: ![](https://fastnetmon.com/wp-content/uploads/2024/03/step-7-detach-disk-1024x329.png)Then double click on "Unused disk-N" at the bottom of the table, which should match to disk image we imported to Proxmox previously and click "Add": ![](https://fastnetmon.com/wp-content/uploads/2024/03/step-9-double-click-on-disk-1-and-add-1024x375.png)Then switch to the "Options tab" and click on "Boot order": ![](https://fastnetmon.com/wp-content/uploads/2024/03/step-10-open-options-boot-order-1024x375.png)After that, enable our freshly created disk: ![](https://fastnetmon.com/wp-content/uploads/2024/03/step-11-select-scsi0-and-ok-1024x420.png)And then pull scsi0 element to be the first one in boot order: ![](https://fastnetmon.com/wp-content/uploads/2024/03/step-12-drag-scsi0-to-be-first-element-1024x420.png)Finally, launch the VM by clicking Start: ![](https://fastnetmon.com/wp-content/uploads/2024/03/step-13-start-it-1024x467.png)Default login and password for VM are: fastnetmon/fastnetmon. We have enabled SSH by default. Be very careful and change default passwords right after logging in. After finishing installation, please request a trial license using this [form](https://fastnetmon.com/trial/). When you receive an activation coupon, please activate it in the following way: ``` sudo ./installer -activate_coupon -activation_coupon [coupon_code] ``` To confirm successful activation, please restart FastNetMon and check the license status: ``` sudo fcli commit sudo fcli show license ``` As a first step, please reset the password for metrics access: ``` sudo ./installer -reset_clickhouse_password ``` To enable Grafana Web UI for metrics, you have to generate passwords for it: ``` sudo ./installer -reset_visual_passwords ``` It will print the login and password required for Grafana to access the metrics and traffic persistency database Log in to FastNetMon’s UI: https://you.ip.address:81 using passwords from the previous step Finally, you can start the initial configuration of FastNetMon using the standard [guide](https://fastnetmon.com/advanced-quick-start/). **Document Categories:** Virtual machines and hypervisors --- ### [FastNetMon and Juniper JunOS integration in IPFIX mode](https://fastnetmon.com/docs-fnm-advanced/junos_integration/) **Published:** August 17, 2016 **Author:** FastNetMon **Content:** Documentation to integrate FastNetMon with inline jFlow / IPFIX using Juniper MX Series routers. To get the most reliable Netflow / IPFIX export, we recommend enabling the option flex-flow-sizing. It provides a very convenient way to automatically adjust the size of flow tables according to the amount of traffic in your network. If you cannot use it for any reason, please refer to our manual configuration guide [fine tuning for flow tables](https://fastnetmon.com/juniper-handling-jflow-ipfix-export-issues/). If you want to achieve better DDoS attack detection speed, we recommend checking this [article](https://fastnetmon.com/docs-fnm-advanced/netflow-lite-and-ipfix-inline-monitoring-services/). In this example, we use rate=500. It works well for the amount of traffic from 100 Mbits/s. You can increase to rate=1000, depending on your traffic. FastNetMon can learn the sampling rate automatically, and you do not need to configure it on the FastNetMon side. We recommend capturing traffic telemetry from the transit / upstream port. In this example, it will be ge-1/0/0.0 Setting sampling on transit interfaces: Run this on those interfaces for each router: ``` set interfaces ge-1/0/0.0 family inet sampling input ``` Check interfaces configuration: ``` r1# show interfaces ge-1/0/4 unit 0 { description netflow-collector; family inet { address 10.50.1.1/30; } } r1# show interfaces ge-1/0/4 | display set set interfaces ge-1/0/4 unit 0 description netflow-collector set interfaces ge-1/0/4 unit 0 family inet address 10.50.1.1/30 ``` Now add templates configuration on r1 and r2. Take care of flow-active-timeout and flow-inactive-timeout it should be less than average\_calculation\_time. For FastNetMon Advanced, you could use the command line interface to configure it: ``` sudo fcli set main average_calculation_time 20 sudo fcli commit ``` Full configuration: ``` set services flow-monitoring version-ipfix template ipv4 flow-active-timeout 15 set services flow-monitoring version-ipfix template ipv4 flow-inactive-timeout 15 set services flow-monitoring version-ipfix template ipv4 template-refresh-rate packets 1000 set services flow-monitoring version-ipfix template ipv4 template-refresh-rate seconds 10 set services flow-monitoring version-ipfix template ipv4 option-refresh-rate packets 1000 set services flow-monitoring version-ipfix template ipv4 option-refresh-rate seconds 10 set services flow-monitoring version-ipfix template ipv4 ipv4-template set chassis tfeb slot 0 sampling-instance ipfix flow-monitoring { version-ipfix { template ipv4 { flow-active-timeout 15; flow-inactive-timeout 15; template-refresh-rate { packets 1000; seconds 10; } option-refresh-rate { packets 1000; seconds 10; } ipv4-template; } } } slot 0 { sampling-instance ipfix; } ``` Now set up IPFIX exports: ``` r1# show forwarding-options sampling { instance { ipfix { input { rate 500; } family inet { output { flow-server 10.50.1.2 { port 2055; version-ipfix { template { ipv4; } } } inline-jflow { source-address 10.50.1.1; } } } } } } r1# show forwarding-options | display set set forwarding-options sampling instance ipfix input rate 500 set forwarding-options sampling instance ipfix family inet output flow-server 10.50.1.2 port 2055 set forwarding-options sampling instance ipfix family inet output flow-server 10.50.1.2 version-ipfix template ipv4 set forwarding-options sampling instance ipfix family inet output inline-jflow source-address 10.50.1.1 ``` The majority of DDoS attacks involve fragmented traffic, and we recommend enabling this option to deliver fragmentation flags to FastNetMon this [way](https://www.juniper.net/documentation/us/en/software/junos/flow-monitoring/topics/concept/services-ipfix-flow-aggregation-ipv6-extended-attributes.html). ## IPv6 IPFIX configuration To configure IPv6, please usethe following configuration as a reference: ``` set services flow-monitoring version-ipfix template ipv6 flow-active-timeout 15 set services flow-monitoring version-ipfix template ipv6 flow-inactive-timeout 15 set services flow-monitoring version-ipfix template ipv6 template-refresh-rate packets 1000 set services flow-monitoring version-ipfix template ipv6 template-refresh-rate seconds 10 set services flow-monitoring version-ipfix template ipv6 option-refresh-rate packets 1000 set services flow-monitoring version-ipfix template ipv6 option-refresh-rate seconds 10 set services flow-monitoring version-ipfix template ipv6 ipv6-template set forwarding-options sampling instance ipfix input rate 500 set forwarding-options sampling instance ipfix family inet6 output flow-server 2::9e port 2055 set forwarding-options sampling instance ipfix family inet6 output flow-server 2::9e version-ipfix template ipv6 set forwarding-options sampling instance ipfix family inet6 output inline-jflow source-address 2::9e set chassis fpc 0 sampling-instance ipfix set interfaces et-0/0/0 unit 403 family inet6 sampling input set interfaces et-0/0/0 unit 403 family inet6 sampling output ``` **Document Categories:** Netflow and IPFIX --- ### [FastNetMon Advanced per-network hostgroups](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-per-network-hostgroups/) **Published:** August 14, 2026 **Author:** Pavel Odintsov **Content:** FastNetMon Advanced provides an option to implement attack detection for all networks in FastNetMon configuration (as defined in networks\_list) on per network basis. In this mode FastNetMon counts all traffic for particular prefix and sends alerts when total traffic for particular network exceeds defined value. Current implementation does not allow to set thresholds for particular network. Same thresholds apply for all prefixes configured for your network. To enable this logic please use following command: ``` sudo fcli set main enable_ban_network true sudo fcli commit ``` Then you need to enable alerts for each protocol version (please note that IPv6 is not supported yet): ``` sudo fcli set main enable_ban_network_ipv4 true sudo fcli set main enable_ban_network_ipv6 true sudo fcli commit ``` After that you need to create hostgroup with special name global\_network\_ipv4 and set calculation methoid to "network\_ipv4": ``` sudo fcli set hostgroup global_network_ipv4 sudo fcli set hostgroup global_network_ipv4 calculation_method network_ipv4 sudo fcli set hostgroup global_network_ipv4 enable_ban true sudo fcli set hostgroup global_network_ipv4 enable_ban_incoming true sudo fcli set hostgroup global_network_ipv4 enable_ban_outgoing true sudo fcli commit ``` Please do not forget to enable [all thresholds](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-threshold-types/) for newly created hostgroup. After that FastNetMon will show networks which exceed threshold in output of following command: ``` sudo fcli show network_block ``` You can manually block particular network this way: ``` sudo fcli set network_block 11.22.33.44/24 ``` To unblock network you need to use UUID of network this way: ``` sudo fcli delete network_block ``` We have full support of standard notify script for per network alerts and you can enable it this way: ``` sudo fcli set main notify_script_network_enabled true sudo fcli set main notify_script_network_path /usr/local/bin/notify_json.py sudo fcli commit ``` In addition to this logic we have so called BGP attribute mirroring option which reads BGP attributes from particular BGP session (defined by name) and overrides some of them: ``` sudo fcli set main bgp_announce_network_mirror_attributes_ipv4 true sudo fcli set main bgp_announce_network_mirror_attributes_ipv6 true sudo fcli set main bgp_announce_network_mirror_attributes_peer_name_ipv4 CORE_ROUTER_EXT sudo fcli set main bgp_announce_network_mirror_attributes_peer_name_ipv6 CORE_ROUTER_EXT sudo fcli commit ``` Then you can define BGP communities to use for these announces: ``` sudo fcli set main bgp_announce_network_communities_ipv4 65001:777 sudo fcli commit ``` With this configuration in place FastNetMon will read announces from your own routers and re-announce them with new communities and all original attributes in place. Please note that no standalone BGP announces are supported for per network hostgroups yet. **Document Categories:** Mitigation modes --- ### [FastNetMon Advanced licensing logic](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-licensing-server/) **Published:** May 4, 2018 **Author:** Pavel Odintsov **Content:** In this article, you can find details about FastNetMon's licensing implementation. When you install FastNetMon for the first time, it uses your external and internal IPs (if you use NAT) and information about hardware to generate a license and store it in /etc/fastnetmon/license.lic. It uses the following hardware details: - CPU model - Number of logical CPUs If you change any of these hardware options, FastNetMon will issue a new license automatically (you need to have an active Internet connection) when you change it a reasonable number of times (a few times per week). If you change it more often, our support team will contact you. We may limit the number of allowed hardware assignment changes. If you're thinking about changing the external or internal IP address, please create a ticket for our support team before taking action. Any IP-related changes will break the license allocation process. For license usage monitoring reasons and product usage survey, all editions of FastNetMon send the following information to [stats](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-usage-analytics/) (stats.fastnetmon.com) server. For all production licenses on a monthly or annual billing cycle, our licensing server issues licenses only for 14 days. Every day FastNetMon contacts the licensing server and extends it for one more day until end of per paid period. During automatic license extension, check the following log messages in /var/log/fastnetmon/fastnetmon.log: ``` [INFO] Start automatic license refresh process [INFO] External IP address of this server: aa.bb.cc.dd [INFO] We have license for: 14 days [INFO] Correctly received and checked license [INFO] We store license on disk ``` To check license status, use this fcli command: ``` sudo fcli show license Production license for 10000 mbits valid until 2023-03-29 ``` There is an option to manually extend the license to check that it will work fine after configuration or routing change: ``` sudo fcli set renew_license ``` If your license was suspended or cancelled previously, you will need to restart FastNetMon to fetch the license: ``` sudo fcli commit ``` We use following domains for licensing purposes: - license.fastnetmon.com - license-ipv6.fastnetmon.com - stats.fastnetmon.com Please note that IPs which are used by these domains may change with time due to our Fastly CDN routing policy changes. We do not recommend specifying these services as IPs in your firewalls as it may lead to issues with license renewal ## Port translation, NAT compatibility FastNetMon licensing supports following scenarios: - External IPv4 directly assigned on VM - External IPv6 directly assigned on VM - Private IPv4 directly assigned on VM and has access via fixed external IPv4 (NAT) Following cases are **NOT SUPPORTED**: - Local external IPv4 is assigned on machine and NAT translated via another external IPv4 address - Local external IPv6 us assigned on machine and NAT translated via another external IPv6 address - External IPv4 is dynamic and can change frequently If these cases are critical for you then please reach our [support](https://support.fastnetmon.com/hc/en-gb/requests/new) ## Offline licenses If your machine does not have external connectivity, we can allocate an offline license, which does not require a connection to the licensing server. If you need this type of license, please discuss it with the sales team. These licenses are subject to additional security checks for the company and can be issued *only* for *annual* licenses starting from FastNetMon 100G. To generate such a license, we will need a hardware fingerprint, which can be generated this way: ``` sudo fcli show license_hardware_data > hw_data.lic ``` After this, please send it to our support or sales team, and we will provide a license file which should be put to /etc/fastnetmon/license.lic. After placing the license file there, you will need to restart FastNetMon this way: ``` sudo fcli commit ``` And then check license status: ``` sudo fcli show license ``` Please be aware that after offline license expiration, FastNetMon will stop working, and even if you have an active subscription with us, you will need to reach us to generate a new license. If you change local IP address on machine, CPU model, number of CPUs or amount of memory, it will stop working too, as the license is based on these parameters. We recommend adding a calendar notification a few weeks before license expiration. ## Get online license via installer Also, you can get online license with installer flags `-download_license` or `-download_license_restart` ``` wget https://install.fastnetmon.com/installer -Oinstaller sudo chmod +x installer sudo ./installer -download_license_restart ``` **Document Categories:** Introduction --- ### [FastNetMon ASN peering reports](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-asn-peering-reports/) **Published:** July 4, 2022 **Author:** Pavel Odintsov **Content:** We offer ASN analytics reports capability for FastNetMon Advanced, which implements native support for per ASN bandwidth calculation and stores it into InfluxDB or Clickhouse in pre-calculated format. It is implemented in the following way for outgoing traffic: ``` sudo fcli show asn_counters_v4 outgoing 28026 4810 pps 38 mbps 52374 3028 pps 25 mbps 52376 2345 pps 17 mbps 15169 1769 pps 10 mbps 20940 1285 pps 8 mbps 2906 1075 pps 8 mbps 3356 484 pps 3 mbps 15133 412 pps 3 mbps 16509 633 pps 2 mbps ``` And in the following way for incoming traffic: ``` sudo fcli show asn_counters_v4 incoming 28026 4810 pps 38 mbps 52374 3028 pps 25 mbps 52376 2345 pps 17 mbps 15169 1769 pps 10 mbps 20940 1285 pps 8 mbps 2906 1075 pps 8 mbps 3356 484 pps 3 mbps 15133 412 pps 3 mbps 16509 633 pps 2 mbps ``` To enable it, you will needthe following options: ``` sudo fcli set main enable_asn_counters enable sudo fcli set main asn_lookup enable sudo fcli commit ``` To get more than 10 ASNs in the top ASN output, you can use the following environment variable: ``` sudo HOST_COUNTERS_MAX_HOSTS=25 -i fcli show asn_counters_v4 ``` It can read ASNs from Netflow, or we can use our own mapping tables (more details below) to enrich it, and it's included inthe default installation of FastNetMon. In some cases router may report wrong ASNs in network telemetry about observed traffic. In this case, you can use this flag to force overwrite ASN information from telemetry by ASNs retrieved using our own IP to ASN mapping table: ``` sudo fcli set main force_asn_lookup true sudo fcli commit ``` After this, restart FastNetMon: ``` sudo fcli commit ``` Our default installation of [visual traffic](https://fastnetmon.com/docs-fnm-advanced/advanced-visual-traffic/) includes top ASN graphs. If you have any issues with IP to ASN number conversion, you can check our tool, which makes queries to our internal ASN database: ``` sudo fcli show ip_asn 11.22.33.44 ``` Starting from 2.0.362, you can get a list of networks (IPv4+IPv6) which belong to a specific ASN using our own daily updated dataset: ``` sudo fcli show asn_networks 65536 ``` ## IP to ASN mapping tables FastNetMon distribution includes mapping tables required to obtain ASN numbers from IPv4 or IPv6 addresses. We have an automatic cron task which runs the command /opt/fastnetmon/app/bin/fill\_dictionaries daily and keeps these mapping tables up to date. These files are stored in the folder `/var/lib/fastnetmon/` ( since FastNetMon version 2.0.383, before that they were stored in `/var/cache/fastnetmon/`) under the names` prefix_asn_mapping_ipv4.json` and `prefix_asn_mapping_ipv6.json`. If you would like to add your own IP prefix to ASN information to IPv4 or IPv6 tables, you can create the following files in the folder /var/lib/fastnetmon: prefix\_asn\_mapping\_ipv4\_user.json and prefix\_asn\_mapping\_ipv6\_user.json, and FastNetMon will load them after loading our regular mapping files. Example format used in these files for IPv4: ``` {"asn":123,"prefix":"1.1.1.1/21"} {"asn":456,"prefix":"2.2.2.2/24"} ``` And for IPv6: ``` {"asn":555,"prefix":"dead:beef::0000/48"} {"asn":777,"prefix":"beef:dead::0000/32"} ``` ## IP to ASN mapping tables manual download If you prefer you can manually download IP to ASN tables from followings URLs: - https://storage.googleapis.com/fastnetmon\_ip\_dictionaries/prefix\_asn\_mapping\_ipv4.json - https://storage.googleapis.com/fastnetmon\_ip\_dictionaries/prefix\_asn\_mapping\_ipv6.json Then place to folder` /var/lib/fastnetmon/ `( for FastNetMon older than 2.0.383 it is `/var/cache/fastnetmon` ) and restart FastNetMon using: ``` sudo fcli commit ``` For Clickhouse you will need to download table with ASN names from this link https://storage.googleapis.com/fastnetmon\_ip\_dictionaries/asn\_descriptions.tsv and then put to folder /var/lib/clickhouse/user\_files and then restart Clickhouse: ``` sudo systemctl restart clickhouse-server ``` **Document Categories:** Traffic reports --- ### [FastNetMon VM Vmware Esxi image install](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-vm-image-install/) **Published:** November 19, 2019 **Author:** Pavel Odintsov **Content:** We offer official OVA images which can be used with variety of hypervisors. To start, please download latest [image](https://storage.googleapis.com/fastnetmon_advanced_vm_images/fastnetmon-ubuntu-22.04-amd64-2.0.383.0.ova). We do automated image builds on next day from stable [release](https://github.com/FastNetMon/fastnetmon-advanced-releases). Feel free to change file name of image if you prefer to use latest release. We offer separate guide for [vmware vCenter](https://fastnetmon.com/fastnetmon-vm-image-install-in-vmware-vcenter/). This image includes full installation of FastNetMon with traffic visibility dashboards Minimum system requirements for VM image: - 16 GB Ram or more - 8 CPU cores or more - 150GB of disk space or more To import OVA image to vmware ESXi please execute following steps in web UI. ![](https://fastnetmon.com/wp-content/uploads/2019/11/vmware_step1-1024x549.png)Select “Create / Register VM”![](https://fastnetmon.com/wp-content/uploads/2019/11/vmware-step2-1024x644.png)Select “Deploy a virtual machine from an OVF or OVA file”![](https://fastnetmon.com/wp-content/uploads/2019/11/vmware-step3-1-1024x647.png)Drag FastNetMon’s OVA file to field in the central part of scree![](https://fastnetmon.com/wp-content/uploads/2019/11/vmware-step4-1024x647.png)![](https://fastnetmon.com/wp-content/uploads/2019/11/vmware-step5-1024x643.png)![](https://fastnetmon.com/wp-content/uploads/2019/11/vmware-step6-1024x652.png)After starting import process, please prepare to wait up to 20 minutes. Default login and password for VM are: fastnetmon/fastnetmon. We have enabled SSH by default. Be very careful and change default passwords right after logging in. After finishing installation, please request trial license using our [form](https://fastnetmon.com/trial/) When you receive activation coupon, please activate it this way: ``` sudo ./installer -activate_coupon -activation_coupon [coupon_code] ``` To confirm successful activation, please restart FastNetMon and check license status: ``` sudo fcli commit sudo fcli show license ``` As first step please reset password for metrics access: ``` sudo ./installer -reset_clickhouse_password ``` To enable Grafana Web UI for metrics you have to generate passwords for it: ``` sudo ./installer -reset_visual_passwords ``` It will print login and password required for Grafana to access metrics and traffic persistency database Login into FastNetMon’s UI: https://you.ip.address:81 using passwords from previous step To extend disk space, please use this [guide](https://fastnetmon.com/extending-disk-space-for-fastnetmon-vm-installs/). Finally, you can start initial configuration of FastNetMon using standard [guide](https://fastnetmon.com/advanced-quick-start/). **Document Categories:** Virtual machines and hypervisors --- ### [FastNetMon VM image install in vmware vCenter](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-vm-image-install-in-vmware-vcenter/) **Published:** December 11, 2019 **Author:** Pavel Odintsov **Content:** We offer official OVA images which can be used with a variety of hypervisors. For production deployments, we support only vmware ESXi. To begin, please download the latest [image](https://storage.googleapis.com/fastnetmon_advanced_vm_images/fastnetmon-ubuntu-22.04-amd64-2.0.383.0.ova). We do automated image builds on the next day from a stable [release](https://github.com/FastNetMon/fastnetmon-advanced-releases). Feel free to change file name of the image if you prefer to use the latest release. This image includes the following components: - FastNetMon - MongoDB - BGP daemon - Grafana - Clickhouse Minimum system requirements for VM image: - 16 GB Ram or more - 8 CPU cores or more - 150GB of disk space or more If you do not use vCenter, you can deploy FastNetMon directly using ESXI web UI: [ESXi guide](https://fastnetmon.com/fastnetmon-vm-image-install/) To import OVA image to vmware vCenter please execute the following steps in vCenter Web UI. ![](https://fastnetmon.com/wp-content/uploads/2019/12/vcenter-1-deploy-ovf-1024x555.png)Select "deploy OVF template"![](https://fastnetmon.com/wp-content/uploads/2019/12/v-center-page2-1024x848.png)Upload OVA image![](https://fastnetmon.com/wp-content/uploads/2019/12/vcenter-page3-1024x849.png)Select target cluster for it![](https://fastnetmon.com/wp-content/uploads/2019/12/vcenter-page4-1024x851.png)Select compute resource![](https://fastnetmon.com/wp-content/uploads/2019/12/vcenter-5-1024x838.png)Review details![](https://fastnetmon.com/wp-content/uploads/2019/12/vCenter-6-1024x837.png)Select storage array![](https://fastnetmon.com/wp-content/uploads/2019/12/vcenter-7-1024x828.png)Configure network ![](https://fastnetmon.com/wp-content/uploads/2019/12/vcenter-8-1024x837.png)Ignore all custom settings, we do not use them![](https://fastnetmon.com/wp-content/uploads/2019/12/vcenter-10-1024x828.png)Confirm deployment After starting the import process, please prepare to wait up to 20 minutes. Default login and password for VM are: fastnetmon/fastnetmon. We have enabled SSH by default. Be very careful and change default passwords right after logging in. After finishing installation, please request a trial license using [this form](https://fastnetmon.com/trial/). When you receive an activation coupon, please activate it this way: ``` sudo ./installer -activate_coupon -activation_coupon [coupon_code] ``` To confirm successful activation, please restart FastNetMon and check the license status: ``` sudo fcli commit sudo fcli show license ``` As a first step, reset the password for metrics access: ``` sudo ./installer -reset_clickhouse_password ``` To enable Grafana Web UI for metrics, you have to generate passwords for it: ``` sudo ./installer -reset_visual_passwords ``` It will print the login and password required for Grafana to access the metrics and traffic persistency database Log in to FastNetMon's UI: https://you.ip.address:81 using passwords from the previous step To extend disk space, please use this [guide](https://fastnetmon.com/extending-disk-space-for-fastnetmon-vm-installs/). Finally, you can start the initial configuration of FastNetMon using the standard [guide](https://fastnetmon.com/advanced-quick-start/). **Document Categories:** Virtual machines and hypervisors --- ### [Flexible thresholds](https://fastnetmon.com/docs-fnm-advanced/flexible-thresholds/) **Published:** July 14, 2022 **Author:** Pavel Odintsov **Content:** In addition to a wide range of [static thresholds](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-threshold-types/), FastNetMon offers the capability to create completely custom thresholds using almost all fields available in L3 and L4 OSI model layers. Flexible thresholds can be used for both per\_host and total hostgroups. To enable this logic, you will need to set the following flag: ``` sudo fcli set main flexible_thresholds true ``` After this, you will need to create up to 16 traffic rules using the following fields: - name - name of traffic rule, will be used as prefix for all metrics related to the same rule. This must be in lowercase, Latin letters, digits or the \_ symbol. - active - flag which enables the rule, when set to false, FastNetMon will ignore it. Useful to temporarily deactivate a rule without removing it. - description - description, can be any - source\_ports - allows a positive integer from 0 to 65535. This field may be empty, which means "any source port". May have multiple ports (up to 10), and all ports will be evaluated using "OR" for packet matching - destination\_ports - allows positive integers from 0 to 65535. This field may be empty, which means "any destination port". May have multiple ports (up to 10) and all ports will be evaluated using "OR" for packet matching - packet\_lengths - allows positive integers from 0 to 65535 (we allow such large values to accommodate jumbo datagrams and long flows). This field may be empty, which means "any length". May have multiple lengths (up to 10) and all ports will be evaluated using "OR" for packet matching. - protocols - may carry protocol name (lowercase, IANA compliant) or protocol number (0..255). This field may be empty, which means "any protocol". May have multiple protocols (up to 10), and all [protocols](https://fastnetmon.com/docs-fnm-advanced/protocol-names-supported-by-fastnetmon-advanced/) will be evaluated using "OR" for packet matching. The intention is to allow using well-known protocol names, such as tcp, udp, and gre, but have an option to encode any protocol with a number. - fragmentation\_flags - can be set to dont-fragment, is-fragment, first-fragment, last-fragment, not-a-fragment or can be empty. We do not recommend using this field as IPFIX / Netflow does not allow fragmentation encoding. - tcp\_flags - can be empty or syn / ack / fin / urgent / push / rst or combination of them separated by vertical line (syn\|ack) - ttls - it can be empty or have list of TTLs, each TTL must be in range between 0 and 255. Please note that not all traffic telemetry protocols can provide information about TTL value. This option is available starting from 2.0.374 Create a new traffic rule: ``` sudo fcli set traffic_rule new_rule ``` You may find an example configuration below: ``` sudo fcli set traffic_rule dns protocols udp sudo fcli set traffic_rule dns active true sudo fcli set traffic_rule dns source_ports 53 sudo fcli commit ``` To list all available traffic rules, you can use the following command: ``` sudo fcli show traffic_rule ``` If you configured everything correctly, you will be able to see byte and packet counters from fcli: ``` sudo fcli show single_host_counters 1.2.3.4 dns_in_bytes 0 dns_in_packets 0 dns_out_bytes 0 dns_out_packets 0 ``` To enable flexible thresholds for a specific hostgroup you need to assign it to a specific hostgroup in the following: ``` sudo fcli set hostgroup flex flexible_thresholds dns ``` After that, you need to set threshold values (please adjust the value to be relevant for your specific network) for the traffic rule with the same name: ``` sudo fcli set hostgroup flex flexible_thresholds dns active true sudo fcli set hostgroup flex flexible_thresholds dns incoming_mbits_enable false sudo fcli set hostgroup flex flexible_thresholds dns incoming_mbits_value 100000 sudo fcli set hostgroup flex flexible_thresholds dns incoming_packets_enable false sudo fcli set hostgroup flex flexible_thresholds dns incoming_packets_value 100000 sudo fcli set hostgroup flex flexible_thresholds dns outgoing_mbits_enable false sudo fcli set hostgroup flex flexible_thresholds dns outgoing_mbits_value 100000 sudo fcli set hostgroup flex flexible_thresholds dns outgoing_packets_enable false sudo fcli set hostgroup flex flexible_thresholds dns outgoing_packets_value 100000 sudo fcli commit ``` Flexible thresholds may work with both per\_direction\_hostgroup\_thresholds enabled or disabled, but you must explicitly set enable\_ban\_incoming or enable\_ban\_outgoing on hostgroup basis to enable flexible thresholds for them. This can be done in the following way: ``` sudo fcli set hostgroup enable_ban_incoming true sudo fcli set hostgroup enable_ban_outgoing true sudo fcli commit ``` After FastNetMon detects an attack using any of these thresholds, it will trigger standard actions exactly as for static thresholds (email alert, BGP, Grafana notification). In the callback script, you will see additional information which explains which threshold was triggered. For all attacks triggered via flexible thresholds, FastNetMon will add current values of all flexible counters for the affected host during the attack time to email reports: ``` Incoming tcp_ack traffic: 27 mbps Outgoing tcp_ack traffic: 0 mbps Incoming tcp_ack pps: 2283 packets per second Outgoing tcp_ack pps: 1087 packets per second ``` **Document Categories:** Mitigation modes --- ### [Case Studies & User Stories](https://fastnetmon.com/client-testimonials/) **Published:** August 19, 2016 **Author:** FastNetMon **Content:** [![Case Joy Services: Automated DDoS detection and hardware-accelerated mitigation](https://fastnetmon.com/wp-content/uploads/2026/06/FastNetMon-Case-Study-Joy-Services-RTBH-automation-BGP-Blackhole.png)](https://fastnetmon.com/2026/06/15/case-joy-services-automated-ddos-detection-and-hardware-accelerated-mitigation/) ## [Case Joy Services: Automated DDoS detection and hardware-accelerated mitigation](https://fastnetmon.com/2026/06/15/case-joy-services-automated-ddos-detection-and-hardware-accelerated-mitigation/) Jun 15, 2026 [![Case Pentanet: Real-Time DDoS Detection at the Edge](https://fastnetmon.com/wp-content/uploads/2026/03/Pentanet-case-study-FastNetMon.png)](https://fastnetmon.com/2026/04/06/case-pentanet-real-time-ddos-detection-at-the-edge/) ## [Case Pentanet: Real-Time DDoS Detection at the Edge](https://fastnetmon.com/2026/04/06/case-pentanet-real-time-ddos-detection-at-the-edge/) Apr 6, 2026 [![Engineering deep dive: How AMS-IX uses FastNetMon for automated DDoS mitigation](https://fastnetmon.com/wp-content/uploads/2026/01/Engineering-Deep-Dive-with-Stavros-Konstantaras-How-AMS-IX-Uses-FastNetMon-for-Automated-DDoS-Mitigation.png)](https://fastnetmon.com/2026/01/27/engineering-deep-dive-how-ams-ix-uses-fastnetmon-for-automated-ddos-mitigation/) ## [Engineering deep dive: How AMS-IX uses FastNetMon for automated DDoS mitigation](https://fastnetmon.com/2026/01/27/engineering-deep-dive-how-ams-ix-uses-fastnetmon-for-automated-ddos-mitigation/) Jan 27, 2026 [![Case Study: DDoS detection and automated mitigation at Link3 with FastNetMon](https://fastnetmon.com/wp-content/uploads/2026/01/Case-study-FastNetMon-DDoS-Detection-and-Mitigation-ISP-Link3-Technologies-Dhaka-Bangladesh.png)](https://fastnetmon.com/2025/12/17/case-study-ddos-detection-and-automated-mitigation-at-link3-with-fastnetmon/) ## [Case Study: DDoS detection and automated mitigation at Link3 with FastNetMon](https://fastnetmon.com/2025/12/17/case-study-ddos-detection-and-automated-mitigation-at-link3-with-fastnetmon/) Dec 17, 2025 Page 1 of 21[2](https://fastnetmon.com/wp-cron.php/page/2/?doing_wp_cron=1792528011.6662390232086181640625&et_blog "Page 2")[»](https://fastnetmon.com/wp-cron.php/page/2/?doing_wp_cron=1792528011.6662390232086181640625&et_blog) ## Some of our happy customers and partners Deployed by ISPs, telecoms, hosting providers, data centers, and enterprises globally. From regional networks to Tier 1 operators, engineers trust FastNetMon to automate DDoS mitigation while maintaining complete control over their routing logic. ![Vodafone](https://fastnetmon.com/wp-content/uploads/2026/01/vodafone.jpg "vodafone") ![T-Mobile](https://fastnetmon.com/wp-content/uploads/2026/01/t-mobile.jpg "t-mobile") ![Wikipedia](https://fastnetmon.com/wp-content/uploads/2026/01/wikipedia.jpg "wikipedia") ![Your Server](https://fastnetmon.com/wp-content/uploads/2026/01/yourserver.jpg "yourserver") ![PrimeTel](https://fastnetmon.com/wp-content/uploads/2026/01/primetel.jpg "primetel") ![Neterra](https://fastnetmon.com/wp-content/uploads/2026/01/neterra.jpg "neterra") ![Tranquil Hosting](https://fastnetmon.com/wp-content/uploads/2026/01/tranquilhosting.jpg "tranquilhosting") ![Codisa](https://fastnetmon.com/wp-content/uploads/2026/01/codisa.jpg "codisa") ![Conecta T](https://fastnetmon.com/wp-content/uploads/2026/01/conectat.jpg "conectat") ![Host Dime](https://fastnetmon.com/wp-content/uploads/2026/01/hostdime.jpg "hostdime") ![Professional headshot of a middle-aged man with dark hair and glasses, wearing a navy suit and blue patterned tie.](https://fastnetmon.com/wp-content/uploads/2026/08/Tush-Nikiollaj.jpeg) **FastNetMon is a powerful and reliable platform for network visibility and DDoS detection.** The solution is flexible, effective, and backed by a knowledgeable and highly responsive team. We have been very pleased with both the product and the partnership and would confidently recommend FastNetMon to organizations looking for dependable DDoS protection. ***[Tush Nikollaj](https://www.linkedin.com/in/tushnikollaj/), CEO, [Logical.Net](https://www.logical.net/)*** ![Close-up portrait of a man with light brown hair looking at the camera.](https://fastnetmon.com/wp-content/uploads/2026/06/73x73.png) **FastNetMon is the Swiss army knife of DDoS mitigation tools.** I have been a FastNetmon Advanced customer since 2019, and it's been a super useful swiss army knife to manage DDOS attacks and mitigate them. I can highly recommend. Roelf Diedericks, Cool Ideas Service Provider ![](https://fastnetmon.com/wp-content/uploads/2026/06/Fastnetmon-testimonials-4.png) **Fastnetmon has shown to be the most effective solution.** Compared to other options, cost of integration was very competitive and we now get an insight into an attack within a minute. This allows us to activate necessary mitigating measures practically immediately. Kleanthis Hadjisoteriou, Primetel ![Smiling man in a dark blazer and light shirt, portrait against a light background.](https://fastnetmon.com/wp-content/uploads/2026/06/73x732.png) **FastNetMon has been great for our operations.** The platform is very helpful for DDoS detection and gives us the visibility we need for day-to-day operations. It has become an important part of our network monitoring workflow. Rizky Muhammad, Dihostingin.com ![](https://fastnetmon.com/wp-content/uploads/2026/06/fastnetmon-testimonials-2.png) **We're very happy.** Before FastNetMon it was a nightmare with attacks every week, since I have installed it I haven’t had a single fall, it has stopped with perfect accuracy 100% of the attacks. Conecta-t Servicios de Banda Ancha S.L. ![](https://fastnetmon.com/wp-content/uploads/2026/06/fastnetmon-testimonials-3.png) Our company has been a customer of FastNetMon for many years. We've always received fast and knowledgeable support from them when needed (very rarely), and their software works amazingly well. DDoS detection takes under a second with port mirrors. The engine underneath is frequently updated with bug fixes and new features. **In general it's a set-and-forget piece of awesome software that just works.** Alexander Barakov, AlphaVPS ![Logo featuring an orange circle with a white server rack icon and the text 'YOUR SERVER' beneath.](https://fastnetmon.com/wp-content/uploads/2026/06/fastnetmon-testimonials-1.png) **The best thing about FastNetMon — it’s simple, but extremely powerful.** We use FastNetMon to analyze traffic from our border switches and make decisions on protecting our network automatically. With FastNetMon and 10 lines of bash code we decide to ban, re-route or simply do nothing with the attack while informing the customer about the issue within couple of seconds after the problem arrises. Ted Nordin, Yourserver.se [![Trustpilot logo with a row of five green rating tiles; four tiles show white stars, the fifth shows a faded/gray star, indicating a near five-star rating.](https://fastnetmon.com/wp-content/uploads/2026/06/trustpilot-4.6-excellent-rating.png "trustpilot-4.6-excellent-rating")](https://www.trustpilot.com/review/fastnetmon.com) [Read more reviews and leave yours on Trustpilot](https://www.trustpilot.com/review/fastnetmon.com) --- ### [FastNetMon LiveView installation](https://fastnetmon.com/docs-fnm-advanced/web-user-interface-for-fastnetmon-advanced/) **Published:** April 20, 2026 **Author:** Pavel Odintsov **Content:** To configure and manage FastNetMon Advanced, you can use the official web user interface FastNetMon LiveView (chargeable per user, as an addon). LiveView is available for free during trial period ![](https://fastnetmon.com/wp-content/uploads/2026/04/FastNetMon-Panel-1024x630.png)To use LiveView, please ensure that you run at [least](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-upgrade-procedure/) FastNetMon Advanced 2.0.378, and that your FastNetMon installation use MongoDB and Clickhouse. FerretDB and InfluxDB are not supported by LiveView. FastNetMon LiveView can be enabled this way on http port 80 (not encrypted): ``` sudo fcli set main web_api_port 80 sudo fcli set main web_api_host 0.0.0.0 ``` Then you need to switch to API v2, which is required for LiveView. Please note that it will break all existing API clients as it changes the URL for API endpoint to /api/v2: ``` sudo fcli set main web_api_v2 true sudo fcli set main mongo_store_attack_information true ``` Then you need to create an admin user in the following way: ``` sudo fcli set user admin sudo fcli set user admin password sudo fcli set user admin role administrator ``` And finally apply changes and start LiveView: ``` sudo fcli commit sudo systemctl restart fastnetmon_web_api.service ``` After that, you will be able to log in to LiveView on port 80 of your VM: http://a.b.c.d:80 ![](https://fastnetmon.com/wp-content/uploads/2026/04/FastNetMon-Login.png)For more detailed information about LiveView configuration, please refer to the official [API](https://fastnetmon.com/docs-fnm-advanced/advanced-api/) page **Document Categories:** Deployment --- ### [Enabling BGP BMP monitoring on JunOS Juniper platforms](https://fastnetmon.com/docs-fnm-advanced/enabling-bgp-bmp-monitoring-on-junos-juniper-patforms/) **Published:** April 28, 2026 **Author:** Pavel Odintsov **Content:** To enable BMP monitoring on Juniper platforms you need to apply following configuration: ``` routing-options { bmp { station BMPServerFastNetMon { initiation-message "FastNetMon"; local-address XXX; connection-mode active; monitor enable; route-monitoring { pre-policy; } station-address XXX; station-port XXX; statistics-timeout 300; } } ``` Unfortunately it explicitly does not support hostnames and you have to use IP addresses in configuration: "The address must be a valid IPv4 or IPv6 address" To show BMP status you can use following command: ``` run show bgp bmp Station name: BMPServerFastnetmon Local address/port: 10.0.0.1/-, Station address/port: 10.0.0.2/11020, active State: established Local: 10.0.0.1+49682 Remote: 10.0.0.2+11020 Last state change: 12 Monitor BGP Peers: enabled Route-monitoring: pre-policy Hold-down: 600, flaps 3, period 300 Initiation message: FastNetMon Priority: low Statistics timeout: 300 Version: 3 Routing Instance: default ``` To see more details BMP analytics you can use following command: ``` show bgp bmp statistics route-monitoring ``` Which shows information like this: ``` Station Name Monitor-type Advertised Prefix Withdrawn Prefix BMPServerFastNetMon Rib-In-Pre 3108822 1252 Rib-In-Post 0 0 Loc Rib 0 0 Rib-Out-Pre 0 0 Rib-Out-Post 0 0 ``` **Document Categories:** BMP --- ### [Automatic blocks for remote attackers](https://fastnetmon.com/docs-fnm-advanced/automatic-blocks-for-remote-attackers/) **Published:** November 21, 2018 **Author:** Pavel Odintsov **Content:** FastNetMon has an experimental ability to detect remote attackers (/32 hosts) and announce them using BGP Unicast announces. You can use it for a production environment only if you run sFlow or sampled Netflow / IPFIX. To use this option, please enable this mode in FastNetMon: ``` sudo fcli set main remote_host_tracking enable ``` You can also get top remote talkers this way: ``` sudo fcli show remote_host_counters ``` You can enable actions separately for incoming and outgoing directions of traffic: ``` sudo fcli set main enable_ban_remote_outgoing enable sudo fcli set main enable_ban_remote_incoming enable ``` Create a single hostgroup with the name "remote\_host" in the following way: ``` sudo fcli set hostgroup remote_host sudo fcli set hostgroup remote_host enable_ban enable ``` Then enable detection for incoming traffic: ``` sudo fcli set hostgroup remote_host enable_ban_incoming enable sudo fcli set hostgroup remote_host ban_for_bandwidth enable sudo fcli set hostgroup remote_host threshold_mbps 200 ``` And outgoing (if needed): ``` sudo fcli set hostgroup remote_host enable_ban_outgoing enable sudo fcli set hostgroup remote_host ban_for_bandwidth_outgoing enable sudo fcli set hostgroup remote_host threshold_mbps_outgoing 200 ``` After these configuration steps, FastNetMon will block all remote hosts which exceed 200 Mbits of traffic in any direction. Also, starting from FastNetMon version 2.0.381, you can configure ban time and another parameters similar to usual ban with ``` sudo fcli set main ban_time_remote_host_ipv4 675 sudo fcli set main ban_time_remote_host_ipv6 675 sudo fcli set main unban_remote_host_enabled_ipv4 true sudo fcli set main unban_remote_host_enabled_ipv6 true sudo fcli set main unban_remote_host_only_if_attack_finished true sudo fcli set main notify_script_remote_enabled false sudo fcli set main notify_script_remote_path /etc/fastnetmon/scripts/notify_about_attack.sh sudo fcli commit ``` You can list blocked hosts this way: ``` sudo fcli show remote_blackhole ``` In addition to this, FastNetMon can generate BGP announces for blocked hosts, and you can block them using your routers: ``` sudo fcli set main gobgp_announce_remote_host enable ``` You can also configure the community and next hop for these announces: ``` sudo fcli set main gobgp_next_hop_remote_host 1.0.0.0 sudo fcli set main gobgp_community_remote_host 65001:669 ``` You can manually block hosts using fcli interface: ``` sudo fcli set remote_blackhole 10.11.12.13 ``` To unblock host, please use uuid from the list command: ``` sudo fcli delete remote_blackhole 9a67b518-df3f-465c-a281-f62a5abf575f ``` Please be careful with really heavily loaded networks because FastNetMon does not free up tracking entries and can consume a significant amount of memory. To check the current traffic for a specific remote host, use this command: ``` sudo fcli show single_remote_host_counters 1.2.3.4 ``` To maintain a high level of performance in environments with a very large number of monitored hosts, we have cleanup logic which removes tracking entries for remote hosts which do not generate or receive any traffic for rather long period of time. This logic is enabled by default for all new installations. On an existing installation, you can enable it manually this way: ``` sudo fcli set main ipv4_remote_automatic_data_cleanup enable sudo fcli set main ipv4_remote_automatic_data_cleanup_threshold 300 sudo fcli set main ipv4_remote_automatic_data_cleanup_delay 300 sudo fcli commit ``` ## Deprecation announcement for old style remote hostgroups In 2.0.380 release we've removed old way to define per direction remote hostgroups using specially named hostgroups remote\_host\_incoming and remote\_host\_outgoing. Please switch to using new unified bi direction detection logic implemented in "remote\_host" logic. Starting from 2.0.380 per\_direction\_hostgroup\_thresholds flag is no longer needed for remote detection logic as it's enabled by default. Also, before 2.0.380 there were restrictions: - No automatic unblock option - Lack of automatic counter cleanup. Leads to speed calculation delays for loaded networks. In some cases can be fixed by frequent FastNetMon restarts **Document Categories:** Mitigation modes --- ### [FastNetMon Advanced Install guide](https://fastnetmon.com/docs-fnm-advanced/advanced-install-guide/) **Published:** March 22, 2017 **Author:** Pavel Odintsov **Content:** ### Order a license Please request a trial license before starting the installation process here: [order trial](https://fastnetmon.com/trial/) ### System requirements **Server requirements:** - Physical server or virtual machine (VMware, Hyper-V, KVM, [Proxmox](https://fastnetmon.com/docs-fnm-advanced/proxmox-vm-configuration-for-fastnetmon-advanced/), Xen, Google Cloud Compute, Amazon AWS, Microsoft Azure) **Supported operating systems:** We offer production support only for x86\_64 hardware platform. - Ubuntu Linux 22.04, 24.04 (recommended) LTS - Debian Linux 12, 13 - RHEL-based platforms (CentOS, AlmaLinux, RockyLinux) 8, 9, 10 **Hardware requirements:** - Memory: 16Gb - CPUs: 16 cores (AVX required) - 1Terabyte of hard drive space or more (SSD or NVME recommended) If you run a network with a large number of active IPv4 and IPv6 hosts (100k+), we strongly recommend preferring CPUs with higher single-core performance and frequency. If you want to use port mirror mode, you will need: - An additional 4 physical CPU cores per port - High-performance network card. For 10G capacity, we can guarantee performance only for Mellanox cards Connect-X 4 or newer And you need to have reliable network connectivity (IPv4 is required, IPv6 is recommended) to the following hosts: - license.fastnetmon.com port 443 - license-ipv6.fastnetmon.com port 443 - repo.fastnetmon.com ports 80, 443 - install.fastnetmon.com port 443 - stats.fastnetmon.com port 443 - repo.mongodb.org ports 80, 443 - nginx.org ports 80, 443 - apt.grafana.com ports 80, 443 - packages.clickhouse.com ports 80, 443 - storage.googleapis.com port 443 If you use a machine behind NAT/CGNAT, please keep your external IPv4 address persistent. Even if your machine has no global IPv6 connectivity, you must have IPv6 enabled locally, as we use it for inter-process interactions. FastNetMon works in an IPv6-only environment, but you have to keep direct connectivity without any kind of address translation. If you operate ARM64-based infrastructure, you can try experimental support for [ARM64](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-arm-64-edition/). ## Install steps Please prepare a freshly installed physical server or virtual machine. Then please log in with SSH and run the following commands: ``` wget https://install.fastnetmon.com/installer -Oinstaller sudo chmod +x installer sudo ./installer ``` As an alternative option, you can use our pre-created virtual machine [images](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-installation-on-hypervisors-or-virtual-machines/) for a variety of hypervisors. During this process, FastNetMon will assign a license to your hardware and IP address. Please carefully review our [licensing server guide](https://fastnetmon.com/fastnetmon-advanced-licensing-server/) to understand our licensing process. For full list of installer options please check [this](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-installer-configuration-options-reference/) page ## Next steps For the initial configuration of FastNetMon for your network, please read the [FastNetMon quick start](https://fastnetmon.com/advanced-quick-start/) after this guide. If you want to enable visual traffic dashboards, you will need a few additional steps for [FastNetMon Visual Traffic](https://fastnetmon.com/advanced-visual-traffic/). ## Cloud deployment option In addition to on-premise install, you can easily deploy FastNetMon as a container in [Docker](https://hub.docker.com/r/fastnetmonltd/fastnetmon-advanced). **Document Categories:** Deployment --- ### [Clean attack records from MongoDB](https://fastnetmon.com/docs-fnm-advanced/clean-attack-records-from-mongodb/) **Published:** July 30, 2026 **Author:** Sergei Mamonov **Content:** By default, when we install MongoDB usually you can connect with command `mongosh` from root (without args). Or with stored for FastNetMon password with ``` mongosh --username administrator --password $(cat /etc/fastnetmon/keychain/.mongo_admin) ``` command or with ``` mongosh --username fastnetmon_user --password $(cat /etc/fastnetmon/keychain/.mongo_fastnetmon_password) ``` After you connected to MongoDB, to clean all attack records run ``` use fastnetmon db.attacks.drop() ``` ``` To find and delete more specific records by IP - ``` ``` use fastnetmon db.attacks.find({ip:"IP"}) db.attacks.deleteMany({ip:"IP"}) ``` or by attack uuid - ``` use fastnetmon db.attacks.find({"attack_details.attack_uuid": "ATTACK_UUID"}) db.attacks.deleteMany({"attack_details.attack_uuid": "ATTACK_UUID"}) ``` **Document Categories:** Maintenance operations --- ### [FastNetMon Advanced upgrade procedure](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-upgrade-procedure/) **Published:** November 25, 2022 **Author:** Pavel Odintsov **Content:** For all supported Linux distributions, we offer official repositories which simplify the installation of upgrades. For Ubuntu, Debian and RedHat family of distributions, if you use the standard way to upgrade all system packages, FastNetMon will be upgraded too. You will find detailed information about [latest versions](https://github.com/FastNetMon/fastnetmon-advanced-releases/releases) of FastNetMon at GitHub. We strongly recommend doing a full backup of the server to external storage before upgrading to avoid data loss. In addition, we recommend doing a full export of FastNetMon's configuration and saving it on an external server. To upgrade FastNetMon Advanced on any supported Linux distribution, you can use our installer tool: ``` wget https://install.fastnetmon.com/installer -Oinstaller sudo chmod +x installer sudo ./installer -upgrade_fastnetmon_advanced ``` Alternatively, to upgrade only FastNetMon to the latest version on Ubuntu or Debian, you need to use the following commands: ``` sudo apt-get update sudo apt-get install --only-upgrade fastnetmon ``` But please before that ensure, that you using actual FastNetMon repository - [FastNetMon Advanced APT repositories](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-apt-repositories/ "FastNetMon Advanced APT repositories") On RedHat family you can use the following command: ``` sudo yum update fastnetmon ``` After this, you can perform an optional step and add new configuration parameters: ``` sudo fcli upgrade_configuration ``` After finishing the upgrade, we recommend checking that FastNetMon daemon is running using the following command: ``` sudo systemctl status fastnetmon ``` Also, we recommend checking that FastNetMon sees all the traffic: ``` sudo fcli show total_traffic_counters ``` In case of any issues with FastNetMon, please start checking from the log file /var/log/fastnetmon/fastnetmon.log. Our [support team](https://support.fastnetmon.com/hc/en-gb/requests/new) will be happy to help you with any issues. If your server uses an offline license and does not have access to the Internet, you can download RPM packages manually [here](https://repo.fastnetmon.com/). For DEB packages please use domain, that match you OS version from - [FastNetMon Advanced APT repositories](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-apt-repositories/ "FastNetMon Advanced APT repositories"). You can find the latest version of FastNetMon via this [link](https://github.com/FastNetMon/fastnetmon-advanced-releases/releases). Please ensure that you use packages for your version of Linux distribution. After downloading packages manually, you need to install them in the following way on Debian and Ubuntu Linux: ``` sudo dpkg -i fastnetmon.deb ``` On RedHat-based systems, you need to use the following command: ``` sudo yum install ./fastnetmon.rpm ``` FastNetMon relies on MongoDB for configuration storage, and it may be affected by an upgrade. We recommend checking [MongoDB integration](https://fastnetmon.com/docs-fnm-advanced/mongodb-integration-with-fastnetmon-advanced/) guide to find out options to address any MongoDB-related issues. Visual graphs system uses Grafana, InfluxDB, Nginx and Clickhouse. Each of them needs to be upgraded too, and we recommend doing it as part of a system-wide upgrade. If the upgrade procedure asks you about configuration changes, you need to keep the old configuration. If you're looking for FastNetMon releases for old platforms, please check this [page](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-release-lifecycle/). **Document Categories:** Maintenance operations --- ### [FastNetMon Advanced APT repositories](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-apt-repositories/) **Published:** July 22, 2026 **Author:** Sergei Mamonov **Content:** FastNetMon Advanced packages are distributed through separate APT repository domains for each supported Debian and Ubuntu release. Supported repository domains: | **Release** | **Repository domain** | |---|---| | Debian 11 Bullseye | bullseye.debian.repo.fastnetmon.com | | Debian 12 Bookworm | bookworm.debian.repo.fastnetmon.com | | Debian 13 Trixie | trixie.debian.repo.fastnetmon.com | | Ubuntu 22.04 Jammy | jammy.ubuntu.repo.fastnetmon.com | | Ubuntu 24.04 Noble | noble.ubuntu.repo.fastnetmon.com | The repository configuration is stored in: `/etc/apt/sources.list.d/fastnetmon.list` For example, on Ubuntu 22.04 Jammy, the file contains: ``` deb [arch=amd64 signed-by=/usr/share/keyrings/fastnetmon_dearmor.gpg] https://jammy.ubuntu.repo.fastnetmon.com stable main ``` Public gpg key fastnetmon\_dearmor.gpg, that should be putted in `/usr/share/keyrings/fastnetmon_dearmor.gpg`, you can download here as zip archive: [fastnetmon\_dearmor.zip](https://fastnetmon.com/wp-content/uploads/2026/07/fastnetmon_dearmor.zip)[Download](https://fastnetmon.com/wp-content/uploads/2026/07/fastnetmon_dearmor.zip) To setup repository you can use our installer: ``` wget https://install.fastnetmon.com/installer -Oinstaller sudo chmod +x installer sudo ./installer -update_fastnetmon_advanced_repo ``` ## Legacy repository Before August 2026, FastNetMon Advanced packages were distributed through the legacy repository at: ``` https://repo.fastnetmon.com/ ``` The legacy repository used a different repository signing key. Existing installations configured with the old repository should be migrated to the release-specific repository domain and the current signing key. **Document Categories:** Maintenance operations --- ### [FastNetMon Advanced configuration with Huawei sFlow v5](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-configuration-with-huawei-sflow-v5/) **Published:** March 26, 2026 **Author:** Pavel Odintsov **Content:** In thus guide you will learn how to configure sFlow v5 on Huawei switches or routers with FastNetMon Advanced First of all you need to enable sFlow v5 globally: ``` sflow enable ``` Then you need to configure IP for sFlow v5 agent, it will use this IP to send data to FastNetMon: ``` sflow agent ip 10.1.10.1 ``` After that you need to create sFlow v5 collector configuration: ``` sflow collector 1 ip port 6343 ``` And then finally enable sFlow v5 configuration for particular interface (usually, upstream facing interfaces for incoming DDoS detection): ``` interface 40GE0/0/2 sflow counter-sampling collector 1 sflow flow-sampling collector 1 sflow flow-sampling rate 1000 sflow flow-sampling max-header 256 ``` On some platforms (like CE6851-48S6Q-HI) instead of "flow-sampling" you need to use just "sampling". For some platforms (like CE6851-48S6Q-HI) you will need to enable sampling for interface explicitly: ``` sflow sampling inbound sflow sampling outbound ``` We add export of first 256 bytes to address [issue](https://pavel.network/sflow-on-huawei-story-of-scarcity-and-redundancy/) with too short packet export by default. To ensure that configuration is correct you can use following command: ``` dis sflow ``` Example output: ``` sFlow Version 5 Information: -------------------------------------------------------------------------- Collector Information: Collector ID: 1 IP Address: 10.0.0.1 Address family: IPV4 Vpn-instance: NA Port: 6343 Datagram size: 1400 Time out: NA Description: NA -------------------------------------------------------------------------- Port on slot 0 Information: Interface: 40GE0/0/2 Flow-sample collector: 1 Counter-sample collector : 1 Flow-sample rate(1/x): 256 Counter-sample interval(s): 10 Flow-sample maxheader: 256 Flow-sample direction: IN,OUT ``` You can check global sFlow configuration this way: ``` dis sflow slot 0 ``` Example output: ``` sFlow Version 5 Information: -------------------------------------------------------------------------- Collector Information: Collector ID: 1 IP Address: 10.0.0.1 Address family: IPV4 Vpn-instance: NA Port: 6343 Datagram size: 1400 Time out: NA Description: NA ``` There is one more command to ensure that sFlow v5 data is coming out: ``` dis sflow statistics ``` Example output: ``` sFlow Version 5 statistic Information: -------------------------------------------------------------------------- Collector 1 Current sample sequence: 2506298 -------------------------------------------------------------------------- Port on slot 0 statistic Information: Interface: 40GE0/0/2 Flow-sample sequence : 8229787 Counter-sample sequence : 14577 Flow-sample inbound pool: 1494319872 Flow-sample outbound pool: 612505856 ``` **Document Categories:** sFlow v5 --- ### [FastNetMon Advanced Proxy support](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-proxy-support/) **Published:** July 17, 2026 **Author:** Sergei Mamonov **Content:** FastNetMon, fcli, and the FastNetMon installer support HTTP and HTTPS proxies through standard environment variables: ``` export https_proxy="http://proxy.example.com:3128" export http_proxy="http://username:password@proxy-with-auth.example.com:3128" ``` Uppercase variants HTTP\_PROXY and HTTPS\_PROXY also supported by installer and fcli. ## FastNetMon systemd service To configure proxy access for FastNetMon running as a systemd service, create a service override: ``` sudo systemctl edit fastnetmon ``` Add the required environment variables: ``` [Service] Environment="http_proxy=http://proxy.example.com:3128" Environment="https_proxy=http://proxy.example.com:3128" Environment="no_proxy=localhost,127.0.0.1,::1" ``` Then restart the service: ``` sudo systemctl daemon-reload sudo systemctl restart fastnetmon ``` You can verify the configured environment with: ``` sudo systemctl show fastnetmon --property=Environment ``` ## Installer and fcli For persistent system-wide proxy configuration, these variables may be added to /etc/environment. When running the installer or fcli through sudo, ensure that the required proxy variables are preserved, for example by configuring env\_keep in sudoers. The exact configuration procedure may differ between Linux distributions; refer to your distribution’s official documentation for details. **Document Categories:** Maintenance operations --- ### [FastNetMon Advanced: navigating all available telemetry protocols for different vendors](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-navigating-all-available-telemetry-protocols-for-different-vendors/) **Published:** March 20, 2026 **Author:** Pavel Odintsov **Content:** FastNetMon Advanced has comprehensive support for variety of telemetry protocols and it may not be easy to find out protocol which is the best in your particular case You can find full table with all vendors and telemetry protocols supported by FastNetMon, recommended protocols highlighted by star: | | Port Mirror | Netfow v9 | IPFIX | IPFIX 315 | sFlow v5 | Vendor specific | |---|---|---|---|---|---|---| | Juniper MX | [Yes](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-port-mirror-configuration/) | [Yes](https://fastnetmon.com/docs/junos_integration/) | [Yes](https://fastnetmon.com/docs/junos_integration/) | [Yes](https://fastnetmon.com/docs-fnm-advanced/netflow-lite-and-ipfix-inline-monitoring-services/) ⭐ | [Yes](https://fastnetmon.com/docs-fnm-advanced/sflow-on-juniper-mx-fastnetmon-advanced/), has issues | | | Juniper PTX | [Yes](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-port-mirror-configuration/) | [Yes](https://fastnetmon.com/docs/junos_integration/) | [Yes](https://fastnetmon.com/docs/junos_integration/) | [Yes](https://fastnetmon.com/docs-fnm-advanced/netflow-lite-and-ipfix-inline-monitoring-services/) ⭐ | [Yes](https://fastnetmon.com/docs-fnm-advanced/sflow-on-juniper-mx-fastnetmon-advanced/) | | | Juniper EX, QFX | [Yes](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-port-mirror-configuration/) | No | No | No | [Yes](https://fastnetmon.com/docs-fnm-advanced/juniper-ex-and-qfx-sflow-v5-configuration-for-fastnetmon-advanced/) ⭐ | | | Nokia SR | [Yes](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-port-mirror-configuration/) | [Yes](https://fastnetmon.com/docs-fnm-advanced/nokia-netflow-v9-and-ipfix-configuration-for-fastnetmon-advanced/) | [Yes](https://fastnetmon.com/docs-fnm-advanced/nokia-netflow-v9-and-ipfix-configuration-for-fastnetmon-advanced/) | [Yes](https://fastnetmon.com/docs-fnm-advanced/netflow-lite-and-ipfix-inline-monitoring-services/) ⭐ | Yes ⭐ | [SHIM](https://fastnetmon.com/docs-fnm-advanced/app-packet-sr-plugin/) ⭐ | | Cisco ASR 1000 | No | [Yes](https://fastnetmon.com/bgp-flow-spec-configuration-on-cisco-asr1000/) | [Yes](https://fastnetmon.com/bgp-flow-spec-configuration-on-cisco-asr1000/) | No | No | | | Cisco ASR 9000 | [Yes](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-port-mirror-configuration/) | [Yes](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-netflow-v9-configuration-for-cisco-asr-9000/) | [Yes](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-netflow-v9-configuration-for-cisco-asr-9000/) | [Yes](https://fastnetmon.com/docs-fnm-advanced/netflow-lite-and-ipfix-inline-monitoring-services/) ⭐ | [Yes](https://fastnetmon.com/docs-fnm-advanced/cisco-asr-9000-sflow-configuration-for-fastnetmon-advanced/) ⭐ | | | Cisco NCS | [Yes](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-port-mirror-configuration/) | Yes | Yes | [Yes](https://fastnetmon.com/docs-fnm-advanced/netflow-lite-and-ipfix-inline-monitoring-services/) ⭐ | Yes | | | Cisco Nexus | [Yes](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-port-mirror-configuration/) | No | No | No | [Yes](https://fastnetmon.com/docs-fnm-advanced/sflow-configuration-on-cisco-nexus-9000-for-fastnetmon-advanced/) ⭐ | | | Arista | [Yes](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-port-mirror-configuration/) | Yes | Yes | No | [Yes](https://fastnetmon.com/docs-fnm-advanced/sflow-v5-configuration-on-arista/) ⭐ | | | Huawei | [Yes](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-port-mirror-configuration/) | [Yes](https://fastnetmon.com/huawei-routers-configuration-with-fastnetmon-advanced/) | [Yes](https://fastnetmon.com/huawei-routers-configuration-with-fastnetmon-advanced/) | No | [Yes](https://fastnetmon.com/fastnetmon-advanced-technical-documentation/fastnetmon-advanced-configuration-with-huawei-sflow-v5/) ⭐ | | | Extreme | [Yes](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-port-mirror-configuration/) | No | No | No | [Yes](https://fastnetmon.com/docs/extreme/) | | | Mikrotik | No | [Yes](https://fastnetmon.com/docs-fnm-advanced/mikrotik/) ⭐ | [Yes](https://fastnetmon.com/docs-fnm-advanced/mikrotik/) ⭐ | No | No | | | OcNOS | [Yes](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-port-mirror-configuration/) | No | No | No | [Yes](https://fastnetmon.com/docs-fnm-advanced/ip-infusion-ocnos-sflow-v5-configuration-with-fastnetmon-advanced/) ⭐ | | | VyOS | No | No, buggy | No, buggy | No | [Yes](https://fastnetmon.com/fastnetmon-vyos-sflow-v5-configuration/) ⭐ | | | Netgate TNSR | No | No | [Yes](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-integration-with-tnsr-high-performance-router-and-vpn-concentrator/) ⭐ | No | No | | | A-10 Networks | No | [Yes](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-ipfix-configuration-for-a-10-networks-thunder/) ⭐ | [Yes](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-ipfix-configuration-for-a-10-networks-thunder/) ⭐ | No | No | | | Amazon AWS | No | No | No | No | No | [VPC Flow Logs](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-and-amazon-vpc-flow-logs/) | | Google Cloud | No | No | No | No | No | [VPC Flow Logs](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-and-google-compute-gce-vpc-flow-logs/) | According to this page we can make conslusions: - If your support supports IPFIX 315 (also known as ie315 and inline monitoring services) then it's the best protocol for DDoS detection - If your platform supports sFlow then it's second best protocol for DDoS detection Port mirror is fully supported by FastNetMon but we recommend it only in cases when no other options are available due to complexity of operations **Document Categories:** Capture engines --- ### [FastNetMon Community edition Terms and Conditions](https://fastnetmon.com/fastnetmon-community-edition-terms-and-conditions/) **Published:** August 8, 2023 **Author:** FastNetMon **Content:** [fastnetmon-community-edition-terms-and-conditions-10-aug-2023](https://fastnetmon.com/wp-content/uploads/2025/12/fastnetmon-community-edition-terms-and-conditions-10-aug-2023.pdf)[Download](https://fastnetmon.com/wp-content/uploads/2025/12/fastnetmon-community-edition-terms-and-conditions-10-aug-2023.pdf) Looking for something else? See the full list of [FastNetMon Policies and Terms](https://fastnetmon.com/legal/). --- ### [Software Licensing Terms and Conditions](https://fastnetmon.com/terms-conditions/) **Published:** July 18, 2017 **Author:** FastNetMon **Content:** [Software\_Licensing\_Terms\_and\_Conditions\_FastNetMon\_30\_04\_2021](https://fastnetmon.com/wp-content/uploads/2023/09/Software_Licensing_Terms_and_Conditions_FastNetMon_30_04_2021.pdf) Looking for something else? See the full list of [FastNetMon Policies and Terms](https://fastnetmon.com/legal/). --- ### [FastNetMon Privacy Policy](https://fastnetmon.com/privacy-policy/) **Published:** September 16, 2018 **Author:** FastNetMon **Content:** [Privacy\_Policy\_and\_Cookies\_Policy\_FastNetMon\_Ltd\_23\_04\_2021](https://fastnetmon.com/wp-content/uploads/2023/09/Privacy_Policy_and_Cookies_Policy_FastNetMon_Ltd_23_04_2021.pdf) Looking for something else? See the full list of [FastNetMon Policies and Terms](https://fastnetmon.com/legal/). --- ### [Website Terms of Use](https://fastnetmon.com/website-terms-of-use/) **Published:** September 26, 2023 **Author:** FastNetMon **Content:** Looking for something else? See the full list of [FastNetMon Policies and Terms](https://fastnetmon.com/legal/). --- ### [Website Accessibility Statement](https://fastnetmon.com/website-accessibility-statement/) **Published:** September 26, 2023 **Author:** FastNetMon **Content:** Looking for something else? See the full list of [FastNetMon Policies and Terms](https://fastnetmon.com/legal/). --- ### [Hostgroup Max Talkers capability](https://fastnetmon.com/docs-fnm-advanced/hostgroup-max-talkers-capability/) **Published:** March 10, 2024 **Author:** Pavel Odintsov **Content:** Please note that this capability is a part of the partner-only integration feature set, and we strongly advise against using it unless you have discussed it with our engineering team. This logic can be changed or removed without any further notice, and it is not a part of FastNetMon's backward compatibility guarantee. To enable the max talkers collection logic, you will need to enable these configuration options: ``` sudo fcli set main generate_max_talkers_report true sudo fcli set main generate_max_talkers_report_delay 60 sudo fcli commit ``` After that, FastNetMon will calculate top talkers for each per\_host hostgroup you have in configuration and will store them to MongoDB in the collection: hostgroups\_max\_talkers. It will do it every generate\_max\_talkers\_report\_delay seconds. To get them in [MongoDB](https://fastnetmon.com/docs-fnm-advanced/mongodb-integration-with-fastnetmon-advanced/), you can use the following query: ``` db.hostgroups_max_talkers.find({}) ``` Example output: ``` { "_id" : ObjectId("65edd444cb342dccea093b66"), "hostgroups" : { "global" : { "ipv4" : { "incoming" : { "bytes_per_second" : [ { "host" : "192.168.1.108", "value" : 1631 } ], "icmp_bytes_per_second" : [ ], "icmp_packets_per_second" : [ ], "ip_fragmented_bytes_per_second" : [ ], "ip_fragmented_packets_per_second" : [ ], "packets_per_second" : [ { "host" : "192.168.1.108", "value" : 18 } ], "tcp_bytes_per_second" : [ ], "tcp_packets_per_second" : [ ], "tcp_syn_bytes_per_second" : [ ], "tcp_syn_packets_per_second" : [ ], "udp_bytes_per_second" : [ { "host" : "192.168.1.108", "value" : 1631 } ], "udp_packets_per_second" : [ { "host" : "192.168.1.108", "value" : 18 } ] }, "outgoing" : { "bytes_per_second" : [ { "host" : "192.168.1.106", "value" : 1486 } ], "icmp_bytes_per_second" : [ ], "icmp_packets_per_second" : [ ], "ip_fragmented_bytes_per_second" : [ ], "ip_fragmented_packets_per_second" : [ ], "packets_per_second" : [ { "host" : "192.168.1.106", "value" : 18 } ], "tcp_bytes_per_second" : [ ], "tcp_packets_per_second" : [ ], "tcp_syn_bytes_per_second" : [ ], "tcp_syn_packets_per_second" : [ ], "udp_bytes_per_second" : [ { "host" : "192.168.1.106", "value" : 1486 } ], "udp_packets_per_second" : [ { "host" : "192.168.1.106", "value" : 18 } ] } } } }, "period_end" : "2024-03-10T15:39:48Z", "period_start" : "2024-03-10T15:38:48Z" } ``` On recent versions of MongoDB, you can request the whole structure this way: ``` mongosh --username administrator --password `sudo cat /etc/fastnetmon/keychain/.mongo_admin` --eval 'use fastnetmon' --eval 'db.hostgroups_max_talkers.find()' ``` After that, you will be able to request the max talkers list via API. You can make a request to retrieve all records this way: ``` curl -X GET -u admin:password https://127.0.0.1:10007/hostgroup_max_talkers ``` To retrieve records from a specific date, please use another query: ``` curl -X GET -u admin:password https://127.0.0.1:10007/hostgroup_max_talkers/2022-02-01T00:58:40Z ``` FastNetMon has logic to remove these entries from MongoDB automatically every 15 minutes. If you run a query and the API responds with error 500 in the following way: ``` [martini]2024/04/12 15:45:56 Completed GET /hostgroup_max_talkers/2023-04-12T31:44:38Z 500 Internal Server Error in 7.135398ms [martini]2024/04/12 15:45:56 Show function returned error: We do not have any samples for your query ``` This means that, for some reason, FastNetMon was not able to calculate max talkers and store them in MongoDB. Very likely, you will find details at /var/log/fastnetmon/fastnetmon.log. **Document Categories:** Maintenance operations --- ### [FastNetMon Advanced web callbacks](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-web-callbacks/) **Published:** March 24, 2026 **Author:** Pavel Odintsov **Content:** FastNetMon Advanced has capability to send attack information in JSON format to remote URL when it detects attack against IP or identifies malicious pattern (BGP Flow Spec mode). In addition it can report information ongoing attacks using attack status capability To send information it uses POST request with JSON encoded document inside and content-type is set to application/json. FastNetMon use standard JSON documents which are described [here](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-json-formats/). To enable this logic you need to use following options: ``` sudo fcli set main web_callback_enabled enable sudo fcli set main web_callback_url https://127.0.0.1:8080/attack/notify sudo fcli commit ``` Starting from FastNetMon 2.0.320, you will be able to use IPv6 addresses for callbacks this way: ``` sudo fcli set main web_callback_enabled enable sudo fcli set main web_callback_url https://[::1]:8080/attack/notify sudo fcli commit ``` ### Attack status information Starting from version 2.0.375, FastNetMon has the capability to send web callback for all blocked IPs (IPv4+IPv6) and pass attack details to it. Please note that attack performance is **not updated** in this case; we plan to add this capability in future releases. This capability can be enabled this way; ``` sudo fcli set main web_callback_attack_status_updates true sudo fcli commit ``` You can configure how often FastNetMon runs this logic in seconds in the following way (please note that this flag is shared with notification logic which uses callback scripts): ``` sudo fcli set main ban_status_delay 20 sudo fcli commit ``` We have examples of web callbacks in following programming languages: - [Python](https://fastnetmon.com/docs-fnm-advanced/example-web-hook-receiver-for-fastnetmon-advanced/) - [Golang](https://github.com/FastNetMon/fastnetmon-go) **Document Categories:** Callback scripts --- ### [Legal](https://fastnetmon.com/legal/) **Published:** September 26, 2023 **Author:** FastNetMon **Content:** ## FastNetMon policies and terms Find FastNetMon’s legal policies and terms, including website usage, privacy, accessibility, and software licensing information, via the links below. [Website accessibility statement](https://fastnetmon.com/website-accessibility-statement/) [Website Terms of Use](https://fastnetmon.com/website-terms-of-use/) [Privacy policy](https://fastnetmon.com/privacy-policy/) [Software Licensing Terms and Conditions](https://fastnetmon.com/terms-conditions/) [Website Cookie Policy](https://fastnetmon.com/cookie-policy/) [FastNetMon Community Edition Terms and Conditions](https://fastnetmon.com/fastnetmon-community-edition-terms-and-conditions/) [FastNetMon Community Edition Privacy Notice](https://fastnetmon.com/fastnetmon-community-edition-privacy-notice/) FastNetMon uses several external contractors and software to provide the best service for you. See the list of [subprocessors and subcontractors here](https://fastnetmon.com/fastnetmon-ltd-subprocessors-and-subcontractors/). --- ### [FastNetMon Advanced XDP filter](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-xdp-filter/) **Published:** December 5, 2023 **Author:** Pavel Odintsov **Content:** Starting from release 2.0.357, we offer an experimental capability which allows you to filter traffic in line using FastNetMon. We leverage the XDP capability of the Linux Kernel for lightning-fast traffic filtering. You can use this capability to defend a Linux server from attacks from the outside. To enable logic which automatically creates filtering rules for malicious traffic, please follow this [guide](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-bgp-flow-spec-configuration/). You will need to skip the section about BGP configuration as we do not need it, but you may prefer to keep BGP Flow Spec and XDP filter enabled at the same time for the most efficient filtering. Please note that the licensing scheme for filter capability may be changed in future. Existing deployments will not be affected. Currently not supported, but it will be added in future releases: Transparent bridge/filter mode when the machine with a filter acts like a filter and processes all traffic towards your network. We support only Ubuntu 22.04 LTS as a platform for the filter. To use this capability, you need to install clang 17 this way: ``` wget -qO- https://apt.llvm.org/llvm-snapshot.gpg.key | sudo tee /etc/apt/trusted.gpg.d/apt.llvm.org.asc echo -e "deb https://apt.llvm.org/jammy/ llvm-toolchain-jammy-17 main\n" | sudo tee -a /etc/apt/sources.list.d/clang.list sudo apt-get update sudo apt-get install -y clang-17 libbpf-dev libc6-dev-i386 ``` To enable this capability, you need to set this flag: ``` sudo fcli set main filter_xdp true ``` After that, you need to specify a list of network interfaces where FastNetMon will install XDP filtering rules: ``` sudo fcli set main interfaces_filter_xdp wlp82s0 ``` In the current version of FastNetMon, you can add filtering rules manually using the standard BGP Flow Spec [format](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-bgp-flow-spec-rfc-5575-json-representation/). ``` sudo fcli set flowspec '{ "source_prefix": "4.0.0.0/32", "destination_prefix": "127.0.0.0/32", "destination_ports": [ 80 ], "source_ports": [ 53, 5353 ], "packet_lengths": [ 777, 1122 ], "protocols": [ "udp" ], "fragmentation_flags": [ "dont-fragment" ], "action_type": "discard" }' ``` We have the following limitations when you use BGP Flow Spec rules for attack filtering: - Only a single element is supported for "fragmentation\_flags" field - Only a single element is supported for "tcp\_flags" field and the protocol should be set to TCP - Element "not-a-fragment" has no effect as it's not supported by RFC - Only IPv4 protocol is supported - Only /32 prefixes are supported for source\_prefix and destination\_prefix - If you specify a source or destination port in a rule, then you need to keep exactly a single protocol in the list, and this protocol should be only UDP or TCP - The only supported action is "discard" XDP can work in three possible modes: - skb - enabled by default, copy mode for network cards without official support for XDP (slowest of all modes). - driver - filtering on driver level, way faster than skb - hardware - filtering with offload to network card hardware, fastest, rarely supported You can configure them in the following way: ``` sudo fcli set main filter_xdp_mode skb sudo fcli commit ``` If the configured mode is not supported by your network cards, it will return an error during attempts to load filters. FastNetMon implements additional validation that source and destination prefixes belong to networks you own. To disable this logic, you can use the following command: ``` sudo fcli set main flow_spec_execute_validation disable sudo fcli commit ``` **Document Categories:** Introduction --- ### [FastNetMon Advanced installation on ARM 64 edition](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-arm-64-edition/) **Published:** December 25, 2018 **Author:** Pavel Odintsov **Content:** We offer experimental availability of our product for ARM64 (Aarch64) platform. Known limitations: - Support only for Ubuntu 22.04 and 24.04 LTS. - We do not offer ARM64 repository for FastNetMon You can follow the standard process to [get free one month trial license](https://fastnetmon.com/trial/) and use it for ARM64 edition. To install ARM64 version, please use this process: ``` wget https://install.fastnetmon.com/installer_arm64 -Oinstaller sudo chmod +x installer sudo ./installer -developer_version ``` You can also install full visual graphic stack (InfluxDB, Grafana, Clickhouse) using the standard installation process: ``` wget https://install.fastnetmon.com/installer_arm64 -Oinstaller sudo chmod +x installer sudo ./installer -install_graphic_stack ``` We have good experience with the following platforms: - Ampere Altra - Amazon Graviton - [RockPro64](https://www.pine64.org/?product=rockpro64-4gb-single-board-computer) - [ESPRESSObin](https://espressobin.net/) **Document Categories:** Deployment --- ### [Press & Newsroom](https://fastnetmon.com/news-and-pr/) **Published:** March 24, 2026 **Author:** Outi Maria Pietilanaho **Content:** # Press & Newsroom [Home](https://fastnetmon.com/ "Home")‣ Press & Newsroom ## Information for the press ### About FastNetMon FastNetMon develops DDoS detection and network traffic visibility solutions for telecommunications providers, Internet Service Providers, hosting companies, and organisations operating large-scale networks. The platform enables network operators to monitor traffic in real time, detect DDoS attacks, and automate mitigation workflows at the network level. Originating as an open-source project, FastNetMon is deployed by operators of some of the world’s largest networks across 148 countries, providing operational visibility and improving infrastructure resilience against modern network threats. ### Company Factsheet **Company name:** FastNetMon LTD **Founded:** 2017 **Headquarters:** London, United Kingdom **Industry:** Information Technology (Cybersecurity) **Product category:** Network security software platform for DDoS protection **Primary users:** Telecom operators, ISPs, hosting and cloud providers, data centres, and large enterprises **Website:** www.fastnetmon.com **Media contact:** <media@fastnetmon.com> **Media Kit: Logos, visuals, and brand assets are available [here](https://fastnetmon.com/fastnetmon-brand-kit/).** ****Events and conferences:** See FastNetMon’s event presence [here](https://fastnetmon.com/events/).** ****Company Newsletter:** Find the company newsletter archive [here](https://fastnetmon.com/newsletter/).** ### FastNetMon in Media [![Bloomberg](https://fastnetmon.com/wp-content/uploads/2026/06/Hackernoon.png "Hackernoon")](https://hackernoon.com/why-we-built-liveview-moving-fastnetmon-from-the-terminal-to-the-operational-surface) [![Business Insider](https://fastnetmon.com/wp-content/uploads/2026/06/NY-Networking.png "NY-Networking")](https://ny-networking.com/fastnetmon-launches-liveview-to-expand-real-time-ddos-visibility-and-network-traffic-analytics/) [![The Registar - Enterprise technology news for IT](https://fastnetmon.com/wp-content/uploads/2026/06/TelecomDrive.png "TelecomDrive")](https://telecomdrive.com/fastnetmon-launches-liveview-for-telecom-network-operators-real-time-ddos-visibility/) [![Cyber Security News](https://fastnetmon.com/wp-content/uploads/2026/06/InsideTelecom.png "InsideTelecom")](https://insidetelecom.com/fastnetmon-liveview-ddos-network-visibility/) [![Fortune](https://fastnetmon.com/wp-content/uploads/2026/06/Pulse2.0.png "Pulse2.0")](https://pulse2.com/fastnetmon-profile-pavel-odintsov-interview/) [![Cyber Press](https://fastnetmon.com/wp-content/uploads/2026/06/ArabNews.png "ArabNews")](https://www.arabnews.com/node/2646844/amp) [![Bloomberg](https://fastnetmon.com/wp-content/uploads/2026/01/bloomberg.jpg "bloomberg")](https://www.bloomberg.com/news/articles/2024-08-01/microsoft-azure-attack-shows-persistence-of-blunt-hacking-tool) [![Business Insider](https://fastnetmon.com/wp-content/uploads/2026/01/business-insider.jpg "business-insider")](https://markets.businessinsider.com/news/currencies/1-5-billion-packets-per-second-ddos-attack-detected-with-fastnetmon-1035135535) [![The Registar - Enterprise technology news for IT](https://fastnetmon.com/wp-content/uploads/2026/01/the-register.jpg "Enterprise technology news for IT")](https://www.theregister.com/2025/09/11/fastnetmon_ddos_attack/) [![Cyber Security News](https://fastnetmon.com/wp-content/uploads/2026/01/cybersecuritynews.jpg "cybersecuritynews")](https://cybersecuritynews.com/1-5-billion-packets-per-second-ddos-attack-detected/) [![Fortune](https://fastnetmon.com/wp-content/uploads/2026/01/fortune.jpg "fortune")](https://fortune.com/press-releases/rise-super-botnets-fastnetmon-ddos-attacks-2025-12-11/?utm_content=494217464&utm_medium=social&utm_source=facebook&hss_channel=fbp-526563014372607) [![Cyber Press](https://fastnetmon.com/wp-content/uploads/2026/01/cyber-press.jpg "cyber-press")](https://cyberpress.org/ddos-1-5-gpps-attack/) [![GB Hackers](https://fastnetmon.com/wp-content/uploads/2026/01/gbhackers.jpg "gbhackers")](https://gbhackers.com/1-5-billion-packets-per-second-ddos-attack-detected/) [![Yahoo Finance](https://fastnetmon.com/wp-content/uploads/2026/01/yahoo-finance.jpg "yahoo-finance")](https://uk.finance.yahoo.com/news/1-5-billion-packets-per-105200494.html) [![SC Media](https://fastnetmon.com/wp-content/uploads/2026/01/sc-media.jpg "sc-media")](https://www.scworld.com/brief/massive-ddos-attack-discovered-mitigated) [![Tech Radar](https://fastnetmon.com/wp-content/uploads/2026/01/techradar.jpg "techradar")](https://www.techradar.com/pro/security/another-massive-ddos-attack-that-reached-1-5-bpps-has-been-thwarted) [![Bleeping Computer](https://fastnetmon.com/wp-content/uploads/2026/01/bleeping-computer.jpg "bleeping-computer")](https://www.bleepingcomputer.com/news/security/ddos-defender-targeted-in-15-bpps-denial-of-service-attack/) [![MSN](https://fastnetmon.com/wp-content/uploads/2026/01/msn.jpg "msn")](https://www.msn.com/en-us/money/other/another-massive-ddos-attack-that-reached-1-5-bpps-has-been-thwarted/ar-AA1Mu2Tt?ocid=finance-verthp-feeds&apiversion=v2&domshim=1&noservercache=1&noservertelemetry=1&batchservertelemetry=1&renderwebcomponents=1&wcseo=1) ### Company News & Press Releases [![Introducing FastACL Community: Open-Source DDoS Scrubbing](https://fastnetmon.com/wp-content/uploads/2026/09/FastACL-1.png)](https://fastnetmon.com/2026/09/25/introducing-fastacl-community-open-source-ddos-scrubbing/) ## [Introducing FastACL Community: Open-Source DDoS Scrubbing](https://fastnetmon.com/2026/09/25/introducing-fastacl-community-open-source-ddos-scrubbing/) Sep 25, 2026 \| [FastNetMon Blog](https://fastnetmon.com/category/blog/), [Featured](https://fastnetmon.com/category/featured/), [Press & Newsroom](https://fastnetmon.com/category/news-and-media/) For more than a decade, FastNetMon Community has given network operators an open-source option for high-performance DDoS detection. Today, we’re extending that approach from detecting attacks to… [![Introducing Netom: an open-source BGP/BMP monitoring engine built for scale](https://fastnetmon.com/wp-content/uploads/2026/09/Introducing-Netom-BGPBMP-monitoring-at-scale.png)](https://fastnetmon.com/2026/09/24/introducing-netom-an-open-source-bgp-bmp-monitoring-engine-built-for-scale/) ## [Introducing Netom: an open-source BGP/BMP monitoring engine built for scale](https://fastnetmon.com/2026/09/24/introducing-netom-an-open-source-bgp-bmp-monitoring-engine-built-for-scale/) Sep 24, 2026 \| [FastNetMon Blog](https://fastnetmon.com/category/blog/), [Featured](https://fastnetmon.com/category/featured/), [Press & Newsroom](https://fastnetmon.com/category/news-and-media/) We’re excited to announce the first release of Netom, an open-source BGP and BMP monitoring engine developed and maintained by FastNetMon. Netom is built for network operators who need to collect,… [![Welcome Denys Haryachyy to the FastNetMon Team](https://fastnetmon.com/wp-content/uploads/2026/09/Team-announcement-Denys-Haryachyy--e1789393713253.png)](https://fastnetmon.com/2026/09/14/welcome-denys-haryachyy-to-the-fastnetmon-team/) ## [Welcome Denys Haryachyy to the FastNetMon Team](https://fastnetmon.com/2026/09/14/welcome-denys-haryachyy-to-the-fastnetmon-team/) Sep 14, 2026 \| [FastNetMon](https://fastnetmon.com/category/fastnetmon/), [FastNetMon Blog](https://fastnetmon.com/category/blog/), [Featured](https://fastnetmon.com/category/featured/), [Press & Newsroom](https://fastnetmon.com/category/news-and-media/) We’re pleased to welcome Denys Haryachyy to FastNetMon as our Senior SDN Software Engineer. Denys brings more than 20 years of experience in high-performance networking, software-defined networking,… [![Feature update banner with blue background and geometric right-side graphic; text reads: Simulate sFlow traffic for DDoS testing. (FAST NETMON)](https://fastnetmon.com/wp-content/uploads/2026/08/Sflowgen-DDoS-testing-tool-from-FastNetMon.png)](https://fastnetmon.com/2026/08/11/introducing-sflowgen-lightweight-sflow-traffic-generator/) ## [Introducing sFlowgen: Lightweight sFlow Traffic Generator](https://fastnetmon.com/2026/08/11/introducing-sflowgen-lightweight-sflow-traffic-generator/) Aug 11, 2026 \| [FastNetMon Blog](https://fastnetmon.com/category/blog/), [Featured](https://fastnetmon.com/category/featured/), [Press & Newsroom](https://fastnetmon.com/category/news-and-media/) Testing DDoS mitigation can be surprisingly difficult. You may want to see how your monitoring system reacts to a 10 or 15 Gbps attack, but generating that much real traffic requires suitable… [![FastNetMon logo beside Snap Store badge with a vertical divider, indicating Ubuntu snap is available (top-right banner).](https://fastnetmon.com/wp-content/uploads/2026/08/FastNetMon-Community-is-Now-Available-on-the-Ubuntu-Snap-Store.png)](https://fastnetmon.com/2026/08/04/fastnetmon-community-is-now-available-on-the-ubuntu-snap-store/) ## [FastNetMon Community is Now Available on the Ubuntu Snap Store](https://fastnetmon.com/2026/08/04/fastnetmon-community-is-now-available-on-the-ubuntu-snap-store/) Aug 4, 2026 \| [FastNetMon Blog](https://fastnetmon.com/category/blog/), [Featured](https://fastnetmon.com/category/featured/), [Press & Newsroom](https://fastnetmon.com/category/news-and-media/) We’re pleased to announce that FastNetMon Community is now available as an official package on the Ubuntu Snap Store. FastNetMon Community is a high-performance DDoS detection sensor that monitors… [![Feature update banner announcing FastNetMon Advanced HTTP and HTTPS proxy support](https://fastnetmon.com/wp-content/uploads/2026/07/Feature-update-HTTP-and-HTTPS-Proxy-support.png)](https://fastnetmon.com/2026/07/20/fastnetmon-now-supports-http-and-https-proxies/) ## [FastNetMon Now Supports HTTP and HTTPS Proxies](https://fastnetmon.com/2026/07/20/fastnetmon-now-supports-http-and-https-proxies/) Jul 20, 2026 \| [FastNetMon Blog](https://fastnetmon.com/category/blog/), [Featured](https://fastnetmon.com/category/featured/), [Press & Newsroom](https://fastnetmon.com/category/news-and-media/) Many enterprise and service provider networks tightly control outbound Internet access. Whether you’re deploying FastNetMon in a secure data centre, a regulated environment, or behind a corporate… [![Press release banner with blue left panel, FASTNETMON logo, and large 'PRESS RELEASE' text plus the date, July 9, 2026; dark right section backdrop.](https://fastnetmon.com/wp-content/uploads/2026/07/Press-release-July-9thpng.png)](https://fastnetmon.com/2026/07/09/press-release-fastnetmon-launches-netomics-a-self-hosted-routing-intelligence-platform/) ## [Press Release: FastNetMon launches Netomics, a self-hosted routing intelligence platform](https://fastnetmon.com/2026/07/09/press-release-fastnetmon-launches-netomics-a-self-hosted-routing-intelligence-platform/) Jul 9, 2026 \| [Press & Newsroom](https://fastnetmon.com/category/news-and-media/) New platform gives network operators complete visibility into Internet routing while keeping all routing intelligence inside their own infrastructure. London, UK – July 8, 2026 – FastNetMon is… [![Banner showing expanded Linux support: Fedora Packages → FastNetMon → EPEL/RHEL/ Rocky/AlmaLinux logos with arrows and a light blue header text.](https://fastnetmon.com/wp-content/uploads/2026/07/FastNetMon-Community-expands-Fedora-and-EPEL-support.png)](https://fastnetmon.com/2026/07/06/fastnetmon-community-expands-fedora-and-epel-support/) ## [FastNetMon Community expands Fedora and EPEL support](https://fastnetmon.com/2026/07/06/fastnetmon-community-expands-fedora-and-epel-support/) Jul 6, 2026 \| [FastNetMon Blog](https://fastnetmon.com/category/blog/), [Featured](https://fastnetmon.com/category/featured/), [Press & Newsroom](https://fastnetmon.com/category/news-and-media/) We’ve made FastNetMon Community easier to install and maintain across Fedora and Enterprise Linux environments. You can now find the updated Fedora package here. On the Fedora side, the package has… [![Server rack with multiple servers and tangled cables in a data center, used for a product development article.](https://fastnetmon.com/wp-content/uploads/2026/06/FastNetMon-product-development-sneak-peek-inline-filtering-solution-in-the-tests.png)](https://fastnetmon.com/2026/06/11/sneak-peek-building-a-high-performance-vpp-based-inline-filter-at-fastnetmon/) ## [Sneak peek: Building a high-performance VPP-based inline filter at FastNetMon](https://fastnetmon.com/2026/06/11/sneak-peek-building-a-high-performance-vpp-based-inline-filter-at-fastnetmon/) Jun 11, 2026 \| [FastNetMon Blog](https://fastnetmon.com/category/blog/), [Featured](https://fastnetmon.com/category/featured/), [Press & Newsroom](https://fastnetmon.com/category/news-and-media/) For the past decade, FastNetMon has been trusted by network operators globally as an elite, ultra-fast out-of-band DDoS detection engine. It acts as the intelligent detection plane, analysing flow… [![Promotional banner for FastNetMon LiveView showing three monitors with network traffic graphs and bar charts.](https://fastnetmon.com/wp-content/uploads/2026/04/Introducing-FastNetMon-LiveView.png)](https://fastnetmon.com/2026/04/29/introducing-fastnetmon-liveview/) ## [Introducing FastNetMon LiveView](https://fastnetmon.com/2026/04/29/introducing-fastnetmon-liveview/) Apr 29, 2026 \| [FastNetMon Blog](https://fastnetmon.com/category/blog/), [Featured](https://fastnetmon.com/category/featured/), [Press & Newsroom](https://fastnetmon.com/category/news-and-media/) Real-time visibility, DDoS analysis, and control in one interface We’re introducing FastNetMon LiveView, the official web interface add-on for FastNetMon. LiveView brings real-time traffic… Page 1 of 61[2](https://fastnetmon.com/wp-cron.php/page/2/?doing_wp_cron=1792528011.6662390232086181640625&et_blog "Page 2")[3](https://fastnetmon.com/wp-cron.php/page/3/?doing_wp_cron=1792528011.6662390232086181640625&et_blog "Page 3")[4](https://fastnetmon.com/wp-cron.php/page/4/?doing_wp_cron=1792528011.6662390232086181640625&et_blog "Page 4")[5](https://fastnetmon.com/wp-cron.php/page/5/?doing_wp_cron=1792528011.6662390232086181640625&et_blog "Page 5")…[»](https://fastnetmon.com/wp-cron.php/page/2/?doing_wp_cron=1792528011.6662390232086181640625&et_blog)[Last »](https://fastnetmon.com/wp-cron.php/page/6/?doing_wp_cron=1792528011.6662390232086181640625&et_blog) --- ### [Events](https://fastnetmon.com/events/) **Published:** April 3, 2026 **Author:** FastNetMon **Content:** # Events [Home](https://fastnetmon.com/ "Home")‣ Events ## Upcoming events We regularly attend industry conferences, network operator group meetings, and cybersecurity events around the world. See below where you can catch up with FastNetMon next. [![See you at NANOG 89](https://fastnetmon.com/wp-content/uploads/2026/08/FastNetMon-is-attending-NANOG-98.png)](https://fastnetmon.com/2026/07/13/nanog-89-event-page/) ## [See you at NANOG 89](https://fastnetmon.com/2026/07/13/nanog-89-event-page/) [Featured](https://fastnetmon.com/category/featured/), [Upcoming Events](https://fastnetmon.com/category/upcoming-events/) FastNetMon will be attending NANOG 98 on October 19–21, 2026, in Miami, Florida, and we’re looking forward to three days with the network operator community. Several members of the FastNetMon team… [![See you at RITE 2026!](https://fastnetmon.com/wp-content/uploads/2026/09/RITE-2026.png)](https://fastnetmon.com/2026/07/13/rite-2026-event-page/) ## [See you at RITE 2026!](https://fastnetmon.com/2026/07/13/rite-2026-event-page/) [Upcoming Events](https://fastnetmon.com/category/upcoming-events/) RITE 2026 – Romanian Internet Technologies Event is an annual meeting of Romania’s Internet and telecommunications community, bringing together ISPs, network operators, technology providers and… [![See you at DENOG 18!](https://fastnetmon.com/wp-content/uploads/2026/09/FastNetMon-is-attending-DENOG-18-.png)](https://fastnetmon.com/2026/07/12/see-you-at-denog-18/) ## [See you at DENOG 18!](https://fastnetmon.com/2026/07/12/see-you-at-denog-18/) [Upcoming Events](https://fastnetmon.com/category/upcoming-events/) FastNetMon will be attending DENOG 18 on November 15–17, 2026, in Essen, Germany, and we’re looking forward to connecting with the German network operator community. Members of the FastNetMon team… ## Past events Browse event recaps, presentations, and resources from past FastNetMon events, sharing insights from real-world deployments and operator discussions. You can find most of our recorded conference talks [on this page](https://fastnetmon.com/video/), and download the slides [here](https://fastnetmon.com/presentation). [![RONOG 11 – Event Recap](https://fastnetmon.com/wp-content/uploads/2026/07/RONOG-11-EVENT-RECAP.png)](https://fastnetmon.com/2026/09/30/ronog-11-event-page/) ## [RONOG 11 – Event Recap](https://fastnetmon.com/2026/09/30/ronog-11-event-page/) Sep 30, 2026 \| [Events](https://fastnetmon.com/category/events/) FastNetMon was pleased to join RONOG 11 in Bucharest, bringing together the Romanian network operator community for a full day of technical talks, discussions and networking. Our Bucharest-based… [![NOG.HR Meetup 7 – Event Recap](https://fastnetmon.com/wp-content/uploads/2026/07/Event-recap-NOG.HR-FastNetMon-8.png)](https://fastnetmon.com/2026/09/10/nog-hr-meetup-7-event-page/) ## [NOG.HR Meetup 7 – Event Recap](https://fastnetmon.com/2026/09/10/nog-hr-meetup-7-event-page/) Sep 10, 2026 \| [Events](https://fastnetmon.com/category/events/) Last week, FastNetMon joined the Croatian network operator community in Zagreb for NOG.HR Meetup 7, held on September 10 at Algebra Campus. Representing FastNetMon was Outi Maria Pietilänaho, who… [![NONOG-8 / NIX-2026 – Event Recap](https://fastnetmon.com/wp-content/uploads/2026/07/Event_NONOG-8.png)](https://fastnetmon.com/2026/09/09/snonog-8-nix-2026-event-page/) ## [NONOG-8 / NIX-2026 – Event Recap](https://fastnetmon.com/2026/09/09/snonog-8-nix-2026-event-page/) Sep 9, 2026 \| [Events](https://fastnetmon.com/category/events/) Last week, FastNetMon joined the Nordic network operator community in Oslo for NONOG-8 / NIX-2026 , held on September 9 at Oslo Handelsstands Forening. Representing FastNetMon was our founder, Pavel… [![MDNOG 1 – Event Recap](https://fastnetmon.com/wp-content/uploads/2026/07/Copy-of-FastNetMon-is-attending-MDNOG-Meeting-1.png)](https://fastnetmon.com/2026/07/14/see-you-at-mdnog/) ## [MDNOG 1 – Event Recap](https://fastnetmon.com/2026/07/14/see-you-at-mdnog/) Jul 14, 2026 \| [Events](https://fastnetmon.com/category/events/) Last week, FastNetMon joined the Moldovan network operator community in Chișinău for MDNOG 1, held on October 8–9 at Digital Park. And what a start for a brand-new NOG! With 360 people registered… [![Event recap banner for NETUK3: London, United Kingdom, with logos and cityscape background](https://fastnetmon.com/wp-content/uploads/2026/05/NetUK-Event-Recap-FastNetMon.png)](https://fastnetmon.com/2026/07/07/netuk3-event-page/) ## [NetUK3 – Event Recap](https://fastnetmon.com/2026/07/07/netuk3-event-page/) Jul 7, 2026 \| [Events](https://fastnetmon.com/category/events/), [FastNetMon Blog](https://fastnetmon.com/category/blog/), [Featured](https://fastnetmon.com/category/featured/) NetUK3: Two great days with the UK network engineering community Over the past two days, we had the pleasure of attending NetUK3, spending some time with network operators, ISPs, vendors and… [![Event recap banner for NANOG 97 in Bellevue, WA, June 1–3, 2026, featuring a speaker at a podium](https://fastnetmon.com/wp-content/uploads/2026/04/NANOG-97-Event-Recap-FastNetMon.png)](https://fastnetmon.com/2026/06/08/see-you-at-nanog-97/) ## [NANOG 97 – Event Recap](https://fastnetmon.com/2026/06/08/see-you-at-nanog-97/) Jun 8, 2026 \| [Events](https://fastnetmon.com/category/events/), [FastNetMon Blog](https://fastnetmon.com/category/blog/), [Featured](https://fastnetmon.com/category/featured/) Check out our event shorts on YouTube! Last week, the team headed to Bellevue, Washington, for NANOG 97. Three packed days of operator debates, deep-dive engineering presentations, and the kind of… [![Graphic poster for RIPE 92 event recap in Edinburgh, Scotland, with bold blue shapes and city skyline.](https://fastnetmon.com/wp-content/uploads/2026/04/Event-recap-RIPE_92-fastnetmom.png)](https://fastnetmon.com/2026/05/22/see-you-at-ripe-92/) ## [RIPE 92 – Event Recap](https://fastnetmon.com/2026/05/22/see-you-at-ripe-92/) May 22, 2026 \| [Events](https://fastnetmon.com/category/events/), [FastNetMon Blog](https://fastnetmon.com/category/blog/) RIPE 92 took place in Edinburgh, Scotland, bringing together ISPs, network operators, registries, and engineers for a week of working groups, plenaries, and a lot of hallway discussions. From… [![Event recap banner for ITW 2026 in the Washington DC area, featuring blue geometric design and cityscape imagery with logos (itw and partners).](https://fastnetmon.com/wp-content/uploads/2026/05/ITW-event-recap-FastNetMon-2026.png)](https://fastnetmon.com/2026/05/22/see-you-at-itw-2026/) ## [ITW 2026 – Event Recap](https://fastnetmon.com/2026/05/22/see-you-at-itw-2026/) May 22, 2026 \| [Events](https://fastnetmon.com/category/events/), [FastNetMon Blog](https://fastnetmon.com/category/blog/), [Featured](https://fastnetmon.com/category/featured/) ITW is always one of those events where the telecom industry compresses months of conversations into a few very busy days. This week, Virgil Truica represented FastNetMon at International Telecoms… [![Event recap banner for TWOG 7 & Taiwan Internet Week with Taipei skyline and dates (May 12–15, 2026).](https://fastnetmon.com/wp-content/uploads/2026/04/Event-recap-Taiwan-Internet-Week-TWNOG-7-FastNetMon.png)](https://fastnetmon.com/2026/05/16/see-you-at-taiwan-internet-week-twnog-7/) ## [Taiwan Internet Week & TWNOG 7 – Event Recap](https://fastnetmon.com/2026/05/16/see-you-at-taiwan-internet-week-twnog-7/) May 16, 2026 \| [Events](https://fastnetmon.com/category/events/) FastNetMon attended Taiwan Internet Week 2026 and TWNOG 7 in Taipei on 12–15 May 2026. It was a great week filled with impromptu meetings, technical discussions, catching up with friends, and… [![Datacenter Forum 2026 poster: May 7 in Bucharest, Romania, with blue geometric design and FAST branding.](https://fastnetmon.com/wp-content/uploads/2026/04/Event-Recap-Datacenter-Forum-2026-FastNetMon.png)](https://fastnetmon.com/2026/05/11/see-you-at-datacenter-world-2026/) ## [Datacenter Forum 2026 – Event Recap](https://fastnetmon.com/2026/05/11/see-you-at-datacenter-world-2026/) May 11, 2026 \| [Events](https://fastnetmon.com/category/events/) Last week FastNetMon attended DataCenter Forum Romania 2026 in Bucharest. Representing our team at the event was Virgil Truica, FastNetMon’s Head of Sales, who spent the day meeting with… Page 1 of 31[2](https://fastnetmon.com/wp-cron.php/page/2/?doing_wp_cron=1792528011.6662390232086181640625&et_blog "Page 2")[3](https://fastnetmon.com/wp-cron.php/page/3/?doing_wp_cron=1792528011.6662390232086181640625&et_blog "Page 3")[»](https://fastnetmon.com/wp-cron.php/page/2/?doing_wp_cron=1792528011.6662390232086181640625&et_blog) --- ### [FastNetMon Advanced cli reference guide](https://fastnetmon.com/docs-fnm-advanced/advanced-cli-reference/) **Published:** December 4, 2017 **Author:** Pavel Odintsov **Content:** **fcli** is the simplest way to configure FastNetMon in a convenient network operations approach. You could use TAB for options auto-completion. Run this tool only with root permissions or with sudo, and use only the following syntax: ``` sudo fcli ``` **Overview** We have following configuration categories: - main - toolkit wide options - bgp - BGP configuration options - hostgroup - custom threshold configurations for different networks - user - user management - role - user role management To get the option value, you could use the following form: ``` show ``` To change the string or integer value, use the following form: ``` set value ``` For boolean fields, a slightly different approach is used: ``` set (disable|enable) ``` To add a new value to a list (networks\_list, for example), use the following: ``` set new_value ``` To remove an element from a list option, use the following approach instead: ``` delete value_for_remove ``` Also, you can retrieve configuration options for the whole category with this approach: ``` show ``` After making any configuration changes, apply them by restarting FastNetmon daemon with a commit command. This command simply restarts the daemon, and it re-reads the entire configuration again: ``` commit ``` If you use a non-standard port and host for API, you could specify them using environment variables: ``` API_PORT=46551 API_HOST=127.0.0.7 sudo -E -i fcli ``` You can change the FastNetMon API internal port that way: ``` sudo fcli set main api_host ::1 sudo fcli commit ``` ## Non interactive mode In addition to interactive mode you can use fcli in non interactive mode by directly specifying desired configuration option as command line argument: ``` sudo fcli show license ``` Or for configuration options: ``` sudo fcli show main sflow ``` ### Blackhole management Block host: ``` set blackhole 11.22.33.44 ``` Example output: Ban executed Show blocked hosts: ``` show blackhole ``` Example output: ``` 11.22.33.44/32 312e3232-2e33-332e-3434-000000000000 ``` Unblock host: ``` delete blackhole 312e3232-2e33-332e-3434-000000000000 ``` Example output: Disabled correctly ### Flow spec rules management Apply new rule: ``` set flowspec '{ "source_prefix": "4.0.0.0/24", "destination_prefix": "127.0.0.0/24", "destination_ports": [ 80 ], "source_ports": [ 53, 5353 ], "packet_lengths": [ 777, 1122 ], "protocols": [ "tcp" ], "fragmentation_flags": [ "is-fragment", "dont-fragment" ], "tcp_flags": [ "syn" ], "action_type": "rate-limit", "action": { "rate": 1024 } }' ``` List flow spec rules ``` show  flowspec ``` Example output: ``` { "source_prefix": "4.0.0.0\/24", "destination_prefix": "127.0.0.0\/24", "destination_ports": [ 80 ], "source_ports": [ 53, 5353 ], "packet_lengths": [ 777, 1122 ], "protocols": [ "tcp" ], "fragmentation_flags": [ "is-fragment", "dont-fragment" ], "tcp_flags": [ "syn" ], "action_type": "rate-limit", "action": { "rate": 1024 } } c58b3558-e3ea-4202-b104-33d59587e283 ``` Delete flow spec announce ``` delete blackhole 312e3232-2e33-332e-3434-000000000000 ``` Example output: Disabled correctly ### Get system counters ``` show system_counters ``` Example output: ``` our_ipv6_packets                       0 total_unparsed_packets_speed           0 total_unparsed_packets                 0 speed_recalculation_time_seconds       0 speed_recalculation_time_microseconds  407 ``` ### Get total traffic counters ``` show total_traffic_counters ``` Example output: ``` incoming traffic   0 incoming traffic   0 outgoing traffic   0 outgoing traffic   0 internal traffic   0 internal traffic   0 other traffic      0 other traffic      0 ``` ### Interfaces management Get interfaces list ``` show interfaces ``` Example output: ``` em2 ``` ### Per subnet counters Get counters for all subnets in networks list. ``` show network_counters incoming packets ``` Example output: ``` 11.22.33.0/24      in packets: 0 out packets: 0 in mbps: 0 out mbps: 0 ``` You could use following sort options here: bytes, packets, incoming or outgoing. ### Per host counters Get the top 10 hosts by specified traffic type (packets, bytes, flows) in a specific direction (incoming, outgoing) from your network. ``` show host_counters flows incoming ``` You can use the following sort options here: bytes, flows, packets, incoming or outgoing. Also, you could increase the number of hosts in the output with an environment variable: ``` sudo HOST_COUNTERS_MAX_HOSTS=40 -i fcli ``` You can increase the number of hosts via API, but it will require more changes. Please edit this file: /lib/systemd/system/fastnetmon\_web\_api.service to following content: ``` [Unit] Description=FastNetMon Advanced web API gateway After=network.target remote-fs.target [Service] Type=simple Environment=HTTP_API_MODE=on Environment=HOST_COUNTERS_MAX_HOSTS=40 ExecStart=/opt/fastnetmon/app/bin/fcli Restart=on-failure RestartSec=5s [Install] WantedBy=multi-user.target ``` After that, please apply the changes: ``` sudo systemctl daemon-reload sudo systemctl restart fastnetmon_web_api ``` Unfortunately, after an upgrade, FastNetMon will reset these values to default, and you will need to apply them again. ### Enable or disable traffic capture If `threshold_specific_ban_details` is enabled, this command is not supported and will not start manual traffic capture. You could trigger it manually if you are sure that you are under attack. When triggered, FastNetMon processes the specified IP address through the regular attack-handling logic, similar to a threshold-triggered attack event. This may include executing configured ban actions, notifications, mitigation scripts, and collecting the attack traffic snapshot / deep analytics details. ``` set traffic_capture 11.22.33.44 ``` Disable: ``` delete traffic_capture 11.22.33.44 ``` ### List all host groups: ``` show hostgroup ``` ### show certain host group ``` show hostgroup my_group ``` ### Create a new host group with name "new\_group" ``` set hostgroup new_group ``` ### Delete host group with name: ``` delete hostgroup new_group ``` ### Check option value for a certain host group ``` show hostgroup global networks ``` ### Set option for a certain host group: ``` show hostgroup host_group_name networks ``` ### Lookup host group for the specified IP address ``` show ip_hostgroup 11.22.33.44 ``` ### White lists We have two kinds of whitelists. Local whitelist. Use only for your own hosts: ``` sudo fcli set main networks_whitelist 11.22.33.44/32 ``` Remote whitelist. You could use it for remote hosts outside of your networks: ``` sudo fcli set main networks_whitelist_remote 11.22.33.44/32 ``` FastNetMon will completely discard all traffic from these IPs and will not count it for per host, per network or per hostgroup counters. When FastNetMon discards traffic which matches this list it increments following system counters: ``` sudo fcli show system_counters |grep total_remote_whitelisted_packets_packets ``` ### Can I whitelist arbitrary traffic from FastNetMon? FastNetMon can whitelist any traffic from processing using a rich set of rules. You can check [syntax here](https://fastnetmon.com/fastnetmon-bgp-flow-spec-rfc-5575-json-representation/) (these rules do not use section "actions"). Please add whitelist rules into file /etc/fastnetmon/whitelist\_rules.dat. Please add a single rule per line. For example: ``` { "destination_ports": [ 443 ], "protocols": [ "udp" ] } { "source_ports": [ 443 ], "protocols": [ "udp" ] } ``` FastNetMon will track such packets using counter total\_flowspec\_whitelist\_packets (sudo fcli show system\_counters). This traffic will be completely discarded from processing and completely ignored. Be very careful with this option because it may cause issues with DDoS detection. Please note that FastNetMon checks these rules linearly one-by-one and large number of rules can easily degrade FastNetMon performance. Please do not use more then 10 rules. ### Can I allow only specific types of traffic telemetry to FastNetMon? Starting from 2.0.373 you can add rules which describe which traffic will be accepted by FastNetMon using file /etc/fastnetmon/allow\_list\_rules.dat, you need to place single rule in [Flow Spec JSON](https://fastnetmon.com/fastnetmon-bgp-flow-spec-rfc-5575-json-representation/) format per line. As soon as you add at least single rule into this file FastNetMon will ignore all traffic which does not match rules in this file. Please note that IPv6 support was added only in 2.0.379 For example to allow only traffic from specific routers and their interfaces you can add rules like this: ``` { "agent_addresses": [ "1.2.3.4'], "input_interfaces": [1, 2, 3, 4] } { "agent_addresses": [ "2.3.4.5'], "input_interfaces": [6, 8] } ``` ### How to remove all networks from networks\_list? ``` for i in `sudo fcli show main networks_list`;do sudo fcli delete main networks_list $i;done ``` ### How to remove all host groups? ``` for i in `sudo fcli show hostgroup|egrep "^name"|awk '{print $2}'`;do sudo fcli delete hostgroup $i;done ``` ### How to add a large number of networks If you have a text file with all networks in CIDR format like this: ``` 22.33.44.55/29 44.66.11.66/27 ``` You can add all of them this way: ``` for i in `cat list`; do sudo fcli set hostgroup group_name networks $i;done ``` After executing this script, please commit changes: ``` sudo fcli commit ``` If you have duplicating networks, FastNetMon will ignore duplicates and report error this way: ``` Command returned error: This option is already exists ``` Feel free to ignore such warnings. ### How to account internal traffic as outgoing or incoming? If packet or flow has source and destination IPs in your networks list then it will be accounted as "internal". If you prefer to count internal traffic as incoming you can use this flag: ``` sudo fcli set main override_internal_traffic_as_incoming true sudo fcli commit ``` If you prefer to count internal traffic as outgoing you can use this flag: ``` sudo fcli set main override_internal_traffic_as_outgoing true sudo fcli commit ``` Please note that override\_internal\_traffic\_as\_incoming and override\_internal\_traffic\_as\_outgoing are mutually exclusive. FastNetMon does not provide capability to count internal as both incoming and outgoing in same time due to technological limitations in design. If you want to see it changed, please subscribe and vote for this [feature request](https://features.fastnetmon.com/feature-requests/p/add-capability-to-count-internal-traffic-as-outgoing-and-incoming-in-same-time). **Document Categories:** Introduction --- ### [Subnet collection from BGP peering session](https://fastnetmon.com/docs-fnm-advanced/subnet-collection-from-bgp-peering-session/) **Published:** July 21, 2018 **Author:** Pavel Odintsov **Content:** FastNetMon relies on list of prefixes operated by your network to detect direction of traffic. However, in a dynamic environment with a large number of peers and frequent changes, it may be complicated to maintain a list of monitored networks up to date manually Starting from release [2.0.379](https://github.com/FastNetMon/fastnetmon-advanced-releases/releases/tag/v2.0.379) provide an option to read all required networks from BGP To enable this feature, please redistribute all networks which belong to your company. Please do not redistribute the full BGP table because it will overload FastNetMon's BGP daemon. To use this facility, you need to establish a BGP peering session between FastNetMon and your routers as [documented here](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-bgp-peering-session-setup/). We offer command which can return all networks received from the BGP session directly: ``` sudo fcli show bgp_announces_incoming peer_name ``` peer\_name you can get from your BGP configuration: ``` sudo fcli show bgp | grep name ``` Then you need to enable BGP network configuration: ``` sudo fcli set main load_networks_from_bgp true sudo fcli commit ``` Optionally you need to set list of communities which need to be handled by FastNetMon, by default it loads all networks from BGP session: ``` sudo fcli set main load_networks_from_bgp_filter_communities 65535:123 sudo fcli set main load_networks_from_bgp_filter_communities 65535:321 sudo fcli commit ``` Then you need to enable network collection for particular BGP peer: ``` sudo fcli set bgp peer1 subnet_learning true sudo fcli commit ``` After that you need to run this command to load all networks from BGP this way. Please note that this command does not restart FastNetMon to apply configuration and applies all changes for running daemon: ``` sudo fcli set reload_networks ``` After that please check /var/log/fastnetmon/fastnetmon.log for entries like this which confirms successful network loading: ``` 2026-06-15 12:19:44,422 [INFO] Loading networks from BGP peer peer1 2026-06-15 12:20:08,026 [INFO] IPv4 ListPath read loop took 23.6036 seconds 2026-06-15 12:20:08,077 [INFO] IPv6 ListPath read loop took 0.00366753 seconds 2026-06-15 12:20:08,078 [INFO] We loaded 98258 IPv4 and 0 IPv6 networks from BGP peers 2026-06-15 12:20:08,135 [INFO] Loading 194143 IPv4 and 0 IPv6 subnets 2026-06-15 12:20:08,485 [INFO] Total size of all IPv4 networks: 491277889 2026-06-15 12:20:08,485 [INFO] load_our_networks_list took 24150 ms ``` Then create following cron configuration file to configure soft reload of networks list every hour (or more often if needed): /etc/cron.d/network\_learning: ``` SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin 1 * * * * root /opt/fastnetmon/app/bin/fcli set reload_networks ``` It will sync networks list on FastNetMon side with list of prefixes received from BGP **Document Categories:** BGP --- ### [FastNetMon Advanced Docker installation](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-docker-installation/) **Published:** July 24, 2020 **Author:** Pavel Odintsov **Content:** We offer official support for using FastNetMon on the Docker platform. You can use it on top of any platform supported by Docker, and you can find [official FastNetMon images](https://hub.docker.com/r/fastnetmon/fastnetmon-advanced/tags) here. FastNetMon can be used on top of Kubernetes platform without any issues. Known restrictions for Docker packaging: - No BGP support (can be enabled via GoBGP daemon installed on VM via API) - No visual traffic support To simplify the installation process for Ubuntu 18.04 and CentOS 7, we offer a completely automated installer which will install Docker, configure it, download all required images and configure them. After finishing the installation process, you will have a fully functional installation of FastNetMon Advanced. To start, please order a trial coupon from our official trial order page and then activate the license on the server which runs Docker: ``` curl https://install.fastnetmon.com/installer -oinstaller sudo chmod +x installer sudo ./installer -activate_coupon -activation_coupon ``` All containers on a physical machine can share the same license, but we will calculate their total traffic for licensing purposes. After successful activation, you can install Docker engine and all FastNetMon containers this way: ``` sudo ./installer -fastnetmon_docker ``` If you have Docker deployed and you just need to install FastNetMon, then you can try our [manual](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-manual-deployment-on-docker-platform/) installation guide for Docker platform. We offer exactly the same experience with Docker as we offer for bare metal install, after installing you can follow our quick start guide: <https://fastnetmon.com/advanced-quick-start/> The installer tool will install fcli binary directly on the host machine, and you can use fcli from the host only: ``` sudo fcli ``` **Document Categories:** Deployment --- ### [FastNetMon Pricing Plan](https://fastnetmon.com/pricing/) **Published:** August 30, 2017 **Author:** FastNetMon **Excerpt:** FastNetMon pricing starts at $115 USD for 10 Gbps observed traffic and includes 1 FastNetMon instance. Plans scale from smaller deployments to enterprise-level network volumes, with optional add-ons available. **Content:** # FastNetMon Pricing Plan FastNetMon pricing is based on the volume of traffic processed per instance, so you can choose a plan that matches your network size and architecture. Pricing starts at $115 USD for 10 Gbps observed traffic and includes 1 FastNetMon instance. Plans scale from smaller deployments to enterprise-level network volumes, with optional add-ons and yearly discounts available. [Monthly](#) [Yearly](#) [Monthly](#) [Yearly](#) #### 10G #### US$115/m - 10 Gbps observed traffic - Unlimited Network Devices - 1 Ticket per month support - 1 Instance of FastNetMon allowed [Order Now](https://fastnetmon.com/fastnetmon-order.php?plan_name=10g) #### 40G #### US$220/m - 40 Gbps observed traffic - Unlimited Network Devices - 2 Tickets per month support - 2 Instances of FastNetMon allowed [Order Now](https://fastnetmon.com/fastnetmon-order.php?plan_name=40g) #### 100G #### US$350/m - 100 Gbps observed traffic - Unlimited Network Devices - 3 Tickets per month support - 3 Instances of FastNetMon allowed [Order Now](https://fastnetmon.com/fastnetmon-order.php?plan_name=100g) #### Enterprise #### Custom - Up to 200 Tbps observed traffic - Unlimited Network Devices - Dedicated support - Compliance assistance [Get Quote](mailto:sales@fastnetmon.com) #### 10G #### US$1380/y - 10 Gbps observed traffic - Unlimited Network Devices - 1 Ticket per month support - 1 Instance of FastNetMon allowed [Order Now](https://fastnetmon.com/fastnetmon-order.php?plan_name=10g-annual) #### 40G #### US$2640/y - 40 Gbps observed traffic - Unlimited Network Devices - 2 Tickets per month support - 2 Instances of FastNetMon allowed [Order Now](https://fastnetmon.com/fastnetmon-order.php?plan_name=40g-annual) #### 100G #### US$4200/y - 100 Gbps observed traffic - Unlimited Network Devices - 3 Tickets per month support - 3 Instances of FastNetMon allowed [Order Now](https://fastnetmon.com/fastnetmon-order.php?plan_name=100g-annual) #### Enterprise #### Custom - Up to 200 Tbps observed traffic - Unlimited Network Devices - Dedicated support - Compliance assistance [Get Quote](mailto:sales@fastnetmon.com) ![](https://fastnetmon.com/wp-content/uploads/2026/04/LiveView_lightmode_illustration-scaled.png "LiveView_lightmode_illustration") ## **FastNetMon LiveView add-on pricing** **FastNetMon LiveView** is the official web interface add-on for FastNetMon. Get real-time traffic analytics, DDoS visibility, reporting, and configuration management in one dashboard. LiveView add-on pricing is **$70 per user/month** when billed monthly, or **$720 per user/year** (equivalent to $60 per user/month, save 14% with annual billing). LiveView is an optional add-on to your FastNetMon licence. Instructions for existing customers to add LiveView can be found [here](https://fastnetmon.com/fastnetmon-subscription-upgrade-process/). ## **Frequently Asked Questions** ### What is the activation fee? For monthly subscriptions, a one-time activation fee of $85 USD applies and is billed separately from the plan price. ### Do you offer licences for more than 100G of total traffic? Yes. If you require licences for higher bandwidth, a custom number of instances, or additional support tickets, you can request a custom quote from our sales team. Get in touch via <sales@fastnetmon.com> ### How is monitored traffic calculated? For licensing purposes, we calculate the average total bandwidth of your network over a one-month period. This includes the combined average of incoming and outgoing traffic across your entire network. ### Can I license only part of my network? No. Even if you plan to monitor only a portion of your network, the licence must cover the total bandwidth of the entire network. In complex or distributed network environments, this can be discussed with our sales team on a case-by-case basis. ### Can you provide an example of a traffic calculation? Yes. If your network averages 10G inbound and 20G outbound traffic, you will need a 40G licence. If your network averages 40G inbound and 10G outbound traffic, you will need a 100G licence. ### What is an instance? An instance refers to a separate installation of FastNetMon on an individual server. For example, if you operate two data centres or PoPs and run FastNetMon independently in each location with separate configurations, you will need two instances. For licences that allow multiple instances, total bandwidth is calculated by summing the bandwidth across all instances. High Availability (HA) deployments are treated the same way. For example, running FastNetMon in HA mode requires a licence covering two instances. ### Are taxes included in the price? All listed prices exclude UK VAT (20%), which applies only to companies based in the United Kingdom. ### What billing cycle do you recommend? We recommend annual subscriptions to reduce the risk of service interruptions caused by payment delays or failed transactions. ### What payment options are available? We support several payment options to accommodate different customer needs. You can pay by credit card (including American Express) using either a monthly or annual subscription, or via PayPal on a monthly or annual basis. For annual subscriptions, we also offer international bank transfers to our UK bank account. Customers based in the US can use automated ACH payments. If you require a different payment method, please contact our customer care team to discuss available options. ### Can I try FastNetMon before purchasing? Yes. If you’re unsure whether FastNetMon is the right fit, you can start with a [free one-month trial](https://fastnetmon.com/trial/). ### How is my data handled during the order process? We track and analyse order-related information for fraud prevention and to improve the overall customer experience on our website. ### How was monitored traffic calculated before 4 October 2024? Before 4 October 2024, licensing was based on the 95th percentile of traffic over a one-month period, calculated in the direction with higher bandwidth usage. ### Can I transfer a licence purchased directly from FastNetMon to a Partner or Reseller? No. Licences purchased directly from FastNetMon cannot be transferred to Partners or Resellers, as partners operate under separate pricing agreements that apply only to customers they onboard themselves. ### What is the best way to contact you? If you have any questions about pricing, licensing, or deployment, please visit our [**Contact us**](https://fastnetmon.com/contact/) page to see all available ways to get in touch. Our team will be happy to help. --- ### [Data retention for Clickhouse persistent data storage](https://fastnetmon.com/docs-fnm-advanced/data-retention-for-clickhouse-persistent-data-storage/) **Published:** May 8, 2018 **Author:** Pavel Odintsov **Content:** FastNetMon creates all tables in Clickhouse with configuration to remove all data older than 7 days by default. It implemented using [TTL](https://clickhouse.com/docs/en/sql-reference/statements/alter/ttl/) capability in Clickhouse. You may alter this value using this guide. Run Clickhouse client: ``` clickhouse-client ``` Then switch to database "fastnetmon" in clickhouse-client interface: ``` USE fastnetmon ``` FastNetMon uses multiple tables, and you will need to repeat actions for all of them. List all available tables: ``` show tables ``` You will see the following list, (simply an example, as you may have more or fewer tables, as it depends on configuration): ``` asn_metrics_ipv4 asn_metrics_ipv6 host_metrics network_metrics total_metrics traffic ``` Optionally, you may find which table uses most of data using this query: ``` SELECT database, table, formatReadableSize(sum(bytes)) AS size FROM system.parts WHERE active GROUP BY database, table ORDER BY sum(bytes) DESC ``` Example output will look this way: ``` ┌─database───┬─table────────────┬─size──────┐ │ fastnetmon │ traffic │ 4.81 GiB │ │ fastnetmon │ host_metrics │ 3.68 GiB │ │ fastnetmon │ asn_metrics_ipv4 │ 2.01 GiB │ │ fastnetmon │ total_metrics │ 27.80 MiB │ │ fastnetmon │ network_metrics │ 12.20 MiB │ └────────────┴──────────────────┴───────────┘ ``` To check current retention setup you can use following command: ``` show create table total_metrics ``` And then check for TTL section in output: ``` CREATE TABLE fastnetmon.total_metrics ( `metricDate` Date DEFAULT toDate(metricDateTime), `metricDateTime` DateTime, `direction` String, `flows` UInt64, `packets` UInt64, `bits` UInt64 ) ENGINE = MergeTree PARTITION BY metricDate ORDER BY (direction, metricDate) TTL metricDate + toIntervalDay(7) SETTINGS index_granularity = 8192 ``` In this case it means that Clickhouse will remove data after 7 days. And then you can reduce or extend period to keep data using following query: ``` ALTER TABLE total_metrics MODIFY TTL metricDate + toIntervalDay(8); ``` Do not forget to repeat this command for all tables. **Document Categories:** Traffic reports --- ### [Important note for upgrades from older FastNetMon Advanced releases before 2.0.375](https://fastnetmon.com/docs-fnm-advanced/important-note-for-upgrades-from-older-fastnetmon-advanced-releases-before-2-0-375/) **Published:** June 5, 2026 **Author:** Sergei Mamonov **Content:** Starting from FastNetMon Advanced 2.0.375, the old ClickHouse metrics database schema is no longer supported. If you upgraded FastNetMon Advanced from an older release and ClickHouse metrics export was enabled before the upgrade, we recommend checking that all FastNetMon metrics tables use the current schema documented below. FastNetMon can create all required ClickHouse metrics tables automatically, but it will not automatically replace existing tables created with an older schema. To inspect the existing ClickHouse tables, run: ``` clickhouse-client ``` Then switch to the FastNetMon database: ``` USE fastnetmon; ``` List all available tables: ``` SHOW TABLES; ``` You can inspect the schema of any table using: ``` SHOW CREATE TABLE total_metrics; SHOW CREATE TABLE traffic; ``` For traffic persistence - **traffic** table now requires presence of `srcMac` and `dstMac` fileds which can be created that way: ``` alter table fastnetmon.traffic ADD COLUMN srcMac FixedString(6); alter table fastnetmon.traffic ADD COLUMN dstMac FixedString(6); ``` For metrics you could look for total\_metrics, if it doesn't have per protocol fields like `tcp_packets`/`udp_packets` - it is an old schema and should be fixed. If old tables are still present after the upgrade, there are two possible approaches: 1. Update the existing tables manually so that their schema matches the current FastNetMon schema. 2. Remove old metrics tables and let FastNetMon create them again automatically with the current schema. If historical metrics are not required, the simplest option is to stop FastNetMon, remove the old ClickHouse metrics tables, and start FastNetMon again. ``` sudo systemctl stop fastnetmon clickhouse-client ``` ``` USE fastnetmon; DROP TABLE IF EXISTS total_metrics; DROP TABLE IF EXISTS total_metrics_ipv4; DROP TABLE IF EXISTS total_metrics_ipv6; DROP TABLE IF EXISTS network_metrics; DROP TABLE IF EXISTS network_24_metrics_ipv4; DROP TABLE IF EXISTS network_metrics_ipv6; DROP TABLE IF EXISTS host_metrics; DROP TABLE IF EXISTS host_metrics_ipv6; DROP TABLE IF EXISTS host_metrics_ipv4_top; DROP TABLE IF EXISTS host_metrics_ipv6_top; DROP TABLE IF EXISTS asn_metrics_ipv4; DROP TABLE IF EXISTS asn_metrics_ipv6; DROP TABLE IF EXISTS system_metrics; DROP TABLE IF EXISTS interface_metrics; DROP TABLE IF EXISTS total_hostgroup_metrics; DROP TABLE IF EXISTS flexible_host_metrics_ipv4; DROP TABLE IF EXISTS flexible_host_metrics_ipv6; DROP TABLE IF EXISTS flexible_total_hostgroup_metrics; ``` Then start FastNetMon again: ``` sudo systemctl start fastnetmon ``` After FastNetMon starts and exports new metrics, it will recreate all required tables using the current schema. You can verify that ClickHouse metrics export works as expected using: ``` sudo fcli show system_counters | grep click ``` Expected output should include successful writes and no failed writes, for example: ``` clickhouse_metrics_writes_total 2044855 clickhouse_metrics_writes_failed 0 ``` Please note that dropping tables removes all historical metrics stored in them. If you need to preserve historical metrics, create a ClickHouse backup or rename the old tables before removing them. **Document Categories:** Maintenance operations --- ### [Videos and presentations from FastNetMon](https://fastnetmon.com/video/) **Published:** January 16, 2025 **Author:** FastNetMon **Content:** Watch conference talks, webinars, and technical presentations from the FastNetMon team on DDoS protection, network security, traffic analysis, BGP, BMP, Flow Spec, network monitoring and more. Browse recordings from industry events around the world and learn from real-world operational experience. Download presentation slides [here](https://fastnetmon.com/presentation/) and find more conference material on our [events page](https://fastnetmon.com/events/). ##### **Monitoring 2,800 BGP Sessions using BMP protocol** - NANOG 97 Pavel Odintsov's session at NANOG 97 explores why traditional approaches such as SNMP, gNMI, and full-table dumps fall short for real-time, per-peer BGP visibility at scale. ##### ****Open Source Tool for DDoS Detection - NANOG 96**** At BalticNOG 2025, Pavel Odintsov presents a practical deep dive into BGP FlowSpec (RFC 5575) for DDoS mitigation. Recorded at BalticNOG 2025 ##### **DDoS attacks in 2025: Trends & mitigation - RONOG 10** Virgil Truica FastNetMon presents at RONOG 2025 on the state of DDoS attacks and how network engineers can stay ahead. Recorded at RONOG 10, 2025 ##### **BGP Flow Spec for DDoS mitigation - BalticNOG 2025** At BalticNOG 2025, Pavel Odintsov presents a practical deep dive into BGP FlowSpec (RFC 5575) for DDoS mitigation. Recorded at BalticNOG 2025 ##### Network Threat Landscape 2025 - Inter.link & FastNetMon Webinar In this webinar, Pavel Odintsov (FastNetMon) and Ciprian Abaseaca (Inter.link) discuss recent DDoS attacks, evolving threats, and what network defenders should prepare for in 2025. Recorded on 19 September 2025. ##### DDoS Detection & Mitigation Methods In this presentation, our CTO, Pavel Odintsov, shares the latest methods for DDoS detection and mitigation. The presentation was filmed at CLNOG in March 2025, in Santiago de Chile. ##### FastNetMon Community - Open Source DDoS Detection This presentation from DKNOG13 offers an in-depth look at how FastNetMon's open-source DDoS detection tool works and how you can use it to protect your network. ##### Step by step configuration of FastNetMon Community Edition This guide walks you through the step-by-step configuration of FastNetMon Community (open source) edition for effective DDoS detection and mitigation. ##### Traffic Visibility and DDoS Detection for IXPs Learn about FastNetMon's capabilities and how it can be integrated into your IXP to effectively detect and mitigate sophisticated DDoS attacks. ##### Route to Networking podcast James Dean is joined by Pavel Odinstov from FastNetMon, discussing all things DDoS, including the significant changes Pavel has observed in this field throughout his career and his primary concerns for the industry. ##### FastNetMon visiting NetBCN Community This video is of courtesy of NetBCN community, where our CTO Pavel Odintsov has a chat with Christian Adell at a NetBCN live meetup. ##### Network Telemetry - important aspects for DDoS detection In this presentation, FastNetMon CTO Pavel Odintsov shares his knowledge about Network Telemetry for DDoS detection. The presentation was filmed at UKNOF46. ##### On the way to IPv6 only household In this video, our CTO Pavel Odintsov walks you through the topic of IPv6 households and uses his own setup of his IPv6 home network as an example. ##### DDoS Challenges in IPv6 environments In this video, we will discuss the specific challenges of DDoS detection and mitigation in IPv6 environments. ##### Complete guide for FastNetMon Community This is a full presentation walking you through how to install and set up FastNetMon Community version. This video was originally recorded with APNIC, as part of their training series. ##### BGP Flowspec for DDoS mitigation: practical aspects In this presentation, our CTO Pavel Odintsov will share practical real field aspects of using BGP Flow Spec for DDoS mitigation. ##### Pavel Odintsov FastNetMon – Open Source DDoS Mitigation Toolkit (EN) Pavel Odintsov, CTO of FastNetMon and the author of the open-source DDoS detection tool explains what are the most common DDoS attacks and how to mitigate them in your network. ##### Network Telemetry on Modern Routers Our CTO Pavel Odintsov will present an in-depth analysis of the network telemetry protocols found in contemporary routing platforms. ##### DDoS attacks from IXP customer’s perspective In this presentation, Pavel Odintsov, CTO of FastNetMon explains the specific challenges of DDoS attacks from the perspective of IXP customer's perspective. The presentation was filmed at UKNOF48. ##### FastNetMon Network Analytics and Metrics In this presentation, our CTO Pavel Odintsov explain how FastNetMon captures data from switches, routers and other sources, and aggregates it for efficient DDoS detection and mitigation. --- ### [FastNetMon presentation Slides](https://fastnetmon.com/presentation/) **Published:** August 23, 2016 **Author:** FastNetMon **Content:** Download presentation slides from FastNetMon conference talks, webinars, and industry events covering DDoS defence, network security, BGP, Flow Spec, network telemetry, monitoring and more. For video recordings and additional conference details, visit our [Videos](https://fastnetmon.com/video/) and [Events](https://fastnetmon.com/events/) pages. [![](https://fastnetmon.com/wp-content/uploads/2026/06/NANOG97-Monitoring-2800-BGP-Sessions-using-BMP-protocol-1024x576.png)](https://fastnetmon.com/wp-content/uploads/2026/06/Monitoring-2800-BGP-Sessions-using-BMP-protocol-may-22-3.pdf)Monitoring 2,800 BGP Sessions using BMP protocol - NANOG 97 [![](https://fastnetmon.com/wp-content/uploads/2026/06/Challenges-of-DDoS-Detection-on-Terabit-Scale-FastNetMon-at-TWNOG-1024x570.png)](https://fastnetmon.com/wp-content/uploads/2026/04/Challenges-of-DDoS-Detection-on-Terabit-scale-2026-.pdf)Challenges of DDoS Detection on Terabit scale - TWNOG 7 [![](https://fastnetmon.com/wp-content/uploads/2026/06/NANOG-96-FastNetMon-Community-1024x576.png)](https://fastnetmon.com/wp-content/uploads/2026/02/20260204_Odintsov_Fastnetmon_Community_Open_v1.pdf)FastNetMon Community: Open Source Tool for DDoS Detection - NANOG 96 [![](https://fastnetmon.com/wp-content/uploads/2025/09/BalticNOG-2025-Pavel-Odintsov-FastNetMon-BGP-Flow-Spec-for-DDoS-mitigation-practical-aspects-1024x576.png)](https://fastnetmon.com/wp-content/uploads/2026/06/Pavel-Odintsov-FastNetMon-at-BalticNOG-2025-BGP-Flow-Spec-for-DDoS-Mitigation-practical-aspects.pdf)BGP Flow Spec for DDoS mitigation - BalticNOG 2025 [![](https://fastnetmon.com/wp-content/uploads/2025/09/RONOG-10-presentation-DDoS-Attacks-2025-FastNetMon-Virgil-Truica-1024x576.png)](https://fastnetmon.com/wp-content/uploads/2025/09/DDoS-Attacks-2025-Trends-and-Mitigation-RONOG10_final.pdf)DDoS attacks in 2025: Trends & mitigation - RONOG 10 [![](https://fastnetmon.com/wp-content/uploads/2025/04/CLNOG-2025-DDoS-Detection-Mitigation-Methods-1024x576.png)](https://fastnetmon.com/wp-content/uploads/2025/03/FastNetMon-Community-CLNOG-preentation-2025.pdf)DDoS Detection & Mitigation Methods - CLNOG 2025 [![](https://fastnetmon.com/wp-content/uploads/2026/06/TRNOG-2025-FastNetMon-Community-presentation-by-Pavel-Odintsov-1024x576.png)](https://fastnetmon.com/wp-content/uploads/2025/01/FastNetMon-Community-TRNOG-2025-Presentation-by-Pavel-Odintsov.pdf)FastNetMon Community: Open Source DDoS Detection Tool - TRNOG 2025 [![](https://fastnetmon.com/wp-content/uploads/2025/01/Fastnetmon-at-UK-IPv6-Council-Annual-Meeting-On-the-way-to-IPv6-Household-1024x576.png)](https://fastnetmon.com/wp-content/uploads/2024/11/On-the-way-to-IPv6-only-household-UK-IPv6-Council-Meeting-2024.pdf)On the way to IPv6-only household - UK IPv6 Council annual meeting [![](https://fastnetmon.com/wp-content/uploads/2025/10/FastNetMon-at-RITE-2025-1024x576.png)](https://fastnetmon.com/wp-content/uploads/2025/10/DDoS-Attacks-2025-Trends-and-Mitigation-RITE-2025-Virgil-Truica.pdf)DDoS attacks 2025: Trends & Mitigation - RITE 2025 [![](https://fastnetmon.com/wp-content/uploads/2026/06/HKNOG-presentation-BGP-flow-spec-FastNetMon-1024x576.png)](https://fastnetmon.com/wp-content/uploads/2024/11/BGP-Flow-Spec-updated-31-October-2024_compressed.pdf)BGP Flow Spec for DDoS mitigation - HKNOG 13.0 [![](https://fastnetmon.com/wp-content/uploads/2025/01/Network-Telemetry-on-Modern-Routers-NANOG-88-FastNetMon-Pavel-Odintsov-1024x576.png)](https://fastnetmon.com/wp-content/uploads/2025/01/NANOG88-Pavel-Odintsov-Network-Telemetry-On-Modern-Routers.pdf)Network Telemetry on Modern Routers NANOG 88 [![](https://fastnetmon.com/wp-content/uploads/2025/01/Free-Open-Source-DDoS-Detection-Tool-FastNetMon-Community-1024x576.png)](https://fastnetmon.com/wp-content/uploads/2025/01/Open-Source-DDoS-Detection-FastNetMon-Community-Presentation-at-DKNOG-by-Pavel-Odintsov.pdf)Open Source DDoS Detection tool - DKNOG 13 [![](https://fastnetmon.com/wp-content/uploads/2025/01/BGP-Flowspec-for-DDoS-Mitigation-practical-aspects-DENOG-14-·-Nov-15-2022-1-1024x576.png)](https://fastnetmon.com/wp-content/uploads/2025/01/BGP-Flow-Spec-Practical-Aspects.-DENOG-Pavel-Odintsov-FastNetMon.pdf)BGP Flow Spec for DDoS Mitigation - DENOG 14 --- ### [FastNetMon Netflow and IPFIX sampling configuration](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-netflow-and-ipfix-sampling-configuration/) **Published:** September 13, 2018 **Author:** Pavel Odintsov **Content:** The simplest sampling configuration you can find in Netflow v5. Each packet carries sampling rate and FastNetMon can read it directly and it does not need any configuration. Also, for Netflow v5 FastNetMon ignores configuration options netflow\_sampling\_ratio even if you set it explicitly. For Netflow v9 and IPFIX sampling information carried in special "options data" packets. Because Netflow v9 and IPFIX are extremely flexible protocols and each vendor can add new fields these protocols also use "template options" packets. They carry information about available fields in "options data" packets. To decode information in "options data" packets each collector should read "template options" packets before. To debug Netflow v9 or IPFIX sampling rate learning FastNetMon exposes number of useful counters. First of all, we need "options templates" packets to decode "options data" packets: ``` sudo fcli show system_counters | grep options_templates_number netflow_v9_options_templates_number 2 ipfix_options_templates_number 3 ``` After that, FastNetMon should read "options data" packets: ``` sudo fcli show system_counters | grep options_packet_number netflow_v9_options_packet_number 3 ipfix_options_packet_number 3 ``` Finally, FastNetMon should extract sampling information from "options data" packets and it has counter about it too: ``` sudo fcli show system_counters | grep custom_sampling_rate_received netflow_v9_custom_sampling_rate_received 20 ipfix_custom_sampling_rate_received 3 ``` It means that FastNetMon decoded all these packets and successfully extracted sampling rate. FastNetMon can maintain custom sampling rate for each devices and you can get list for all automatically extracted sampling rates this way: ``` sudo fcli show netflow_sampling_rates 10.12.22.1 1000 ``` For IPFIX protocol you can use this commands to get per device sampling rates: ``` sudo fcli show ipfix_sampling_rates 10.12.22.1 1000 ``` In addition to this, FastNetMon print following log messages on debug level (sudo fcli set main logging\_level debug): ``` [DEBUG] Learnt new Netflow v9 sampling rate 1000 for 10.10.10.1 [DEBUG] Learnt new IPFIX sampling rate 1000 for 10.10.10.1 [DEBUG] Change Netflow v9 sampling rate from 10 to 1000 for 10.10.10.1 [DEBUG] Change IPFIX sampling rate from 10 to 1000 for 10.10.10.1 ``` In some cases, when vendor uses very unusual encoding way, FastNetMon cannot extract this information automatically and you can specify it manually this way. FastNetMon will use this information if it does not receive "options" packets from your router. ``` sudo fcli set main netflow_sampling_ratio 1000 sudo fcli commit ``` In all cases for Netflow v9 and IPFIX protocols sampling rate received from router has priority over information specified in configuration. You can explicitly ignore sampling announcements from routers and use value from configuration this way: ``` sudo fcli set main netflow_ignore_sampling_rate_from_device enable sudo fcli commit ``` In some cases you may need ability to override sampling rate on per device basis and FastNetMon allows you to do so this way: ``` sudo fcli set main netflow_v5_per_router_sampling_rate 11.11.11.11=10000 sudo fcli set main netflow_v5_per_router_sampling_rate 22.22.22.22=10000 sudo fcli set main netflow_v9_per_router_sampling_rate 11.11.11.11=10000 sudo fcli set main netflow_v9_per_router_sampling_rate 22.22.22.22=10000 sudo fcli set main ipfix_per_router_sampling_rate 11.11.11.11=10000 sudo fcli set main ipfix_per_router_sampling_rate 22.22.22.22=10000 sudo fcli commit ``` To remove override value you need to use following syntax: ``` sudo fcli delete main netflow_v5_per_router_sampling_rate 11.11.11.11 sudo fcli delete main netflow_v9_per_router_sampling_rate 11.11.11.11 sudo fcli delete main ipfix_per_router_sampling_rate 11.11.11.11 sudo fcli commit ``` FastNetMon features option to save sampling rates received from all your devices into persistent file. It helps to avoid traffic drops during restart when FastNetMon did not receive sampling rate from device yet. It's enabled by default for all new installation and can be checked that way: ``` sudo fcli show main netflow_sampling_cache ``` FastNetMon saves sampling rates to following files: netflow9\_sampling.dat and ipfix\_sampling.dat which reside in folder /var/cache/fastnetmon. If you want FastNetMon to forget sampling rate for particular device you can remove them. ### Recommended sampling rate values According to real amount of traffic in network we suggest following sampling rates: | Bandwidth | Sampling rate | |---|---| | 100 Mbit | 500 | | 1 Gbit | 1000 | | 10 Gbit | 2000 | | 40 Gbit | 4000 | | 100 Gbit | 5000 | If your sampling rates does not match these values then you may experiences bandwidth calculation inaccuracy and potential issues with attack detection. We strongly advice to follow these recommendations. **Document Categories:** Netflow and IPFIX --- ### [FastNetMon JSON formats](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-json-formats/) **Published:** December 13, 2017 **Author:** Pavel Odintsov **Content:** Here you could find examples for JSON documents used by FastNetMon. We maintain official [GitHub](https://github.com/FastNetMon/fastnetmon-json-schema/tree/main) repository for all our JSON formats. We use them for web hooks and for [JSON-enabled notify script](https://fastnetmon.com/fastnetmon-advanced-notify-script-in-perl/) Blackhole ban action: [JSON](https://github.com/FastNetMon/fastnetmon-json-schema/blob/main/blackhole_ipv4_ban.json) Blackhole unban action: [JSON](https://github.com/FastNetMon/fastnetmon-json-schema/blob/main/blackhole_ipv4_unban.json) BGP Flow Spec ban action: [JSON](https://github.com/FastNetMon/fastnetmon-json-schema/blob/main/flow_spec_ipv4_ban.json) BGP Flow Spec unban action: [JSON](https://github.com/FastNetMon/fastnetmon-json-schema/blob/main/flow_spec_ipv4_unban.json) Per hostgroup (total) ban [JSON](https://github.com/FastNetMon/fastnetmon-json-schema/blob/main/total_hostgroup_ban.json). Per hostgroup (total) unban [JSON](https://github.com/FastNetMon/fastnetmon-json-schema/blob/main/total_hostgroup_unban.json). To create versatile callback script which works for both per host and per hostgroup actions you can use field "alert\_scope" to distinguish them. **Document Categories:** Developer guides --- ### [FastNetMon Advanced integration with F5 DDoS scrubbing centre](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-integration-with-f5-silverline-ddos-scrubbing-centre/) **Published:** October 20, 2022 **Author:** Pavel Odintsov **Content:** FastNetMon Advanced offers complete production-ready integration with cloud DDoS scrubbing service provided by F5 XC and F5 Silverline (legacy). You can find the official press release of this capability on the F5 website [here](https://community.f5.com/kb/technicalarticles/fastnetmon-and-f5-distributed-cloud-xc-an-enhanced-ddos-strategy-/319472). ### How does FastNetMon scrubbing centre diversion integration work? When FastNetMon detects an attack against an IP address, it determines /24 prefix for the IP which is under attack and then announces it to the scrubbing centre. When the attack stops or the ban time expires, FastNetMon removes the announce from the scrubbing centre using their API. Please check that your version of FastNetMon is 2.0.357 or newer. To use FastNetMon with F5 Distributed Cloud XC, you will need to request a certificate from F5 management portal the followng way: 1. Log in to the Distributed Cloud Tenant 2. Click Administration 3. Under IAM -> Service Credentials -> Add Service Credential Then fill the following information: 1. Add credential email 2. Select "Credential Type" to "API Certificate" 3. Add password 4. Push expiry date as far as the calendar allows ![](https://fastnetmon.com/wp-content/uploads/2023/12/Screenshot-from-2023-12-15-23-44-27-854x1024.png)Then click on "Assign Roles and Namespace" and provide the following information: - Namespace: "system" - Set flag "Make Admin" ![](https://fastnetmon.com/wp-content/uploads/2023/12/Screenshot-from-2023-12-15-23-46-56.png)After that, click "Assign Roles" and "Download". Once downloaded, it will generate a “.p12” certificate. Check to see if the certificate is valid in the WebUI: ![](https://fastnetmon.com/wp-content/uploads/2023/12/Screenshot-from-2023-12-15-23-57-05-1024x230.png)Then please use fcli to apply the configuration: ``` sudo fcli set plugin scrubbing_services_integration provider_name f5_xc sudo fcli set plugin scrubbing_services_integration f5_tenant_url customer.specific.url.f5.io sudo fcli set plugin scrubbing_services_integration f5_p12_certificate_path /opt/f5xc/ddos.p12 sudo fcli set plugin scrubbing_services_integration f5_p12_certificate_password servicePassword sudo fcli set plugin scrubbing_services_integration log_path /var/log/fastnetmon/fastnetmon_scrubbing_services_integration.log ``` To use FastNetMon with F5 Silverline (legacy), you will need to use email and password: ``` sudo fcli set plugin scrubbing_services_integration provider_name f5 sudo fcli set plugin scrubbing_services_integration f5_email sales@domain.com sudo fcli set plugin scrubbing_services_integration f5_password cloud_security sudo fcli set plugin scrubbing_services_integration log_path /var/log/fastnetmon/fastnetmon_scrubbing_services_integration.log ``` Finally, configure it on FastNetMon side to call it when FastNetMon blocks/unblocks IP: ``` sudo fcli set main notify_script_enabled enable sudo fcli set main notify_script_format json sudo fcli set main notify_script_path /opt/fastnetmon/libraries/scrubbing_services_integration_plugin/scrubbing_services_integration sudo fcli commit ``` After this, we recommend manually blocking some IP addresses from the test prefix and checking that it works as expected. You can do it in the following way: ``` sudo fcli set blackhole 1.2.3.4 ``` And then, to unblock, list all the blocked hosts with their UUIDs: ``` sudo fcli show blackhole ``` And unblock: ``` sudo fcli delete blackhole ``` Integration logic has very detailed logging, and you can find it here: /var/log/fastnetmon/fastnetmon\_scrubbing\_services\_integration.log **Document Categories:** Attack actions --- ### [Discarded traffic monitoring in FastNetMon Advanced](https://fastnetmon.com/docs-fnm-advanced/discarded-traffic-monitoring-in-fastnetmon-advanced/) **Published:** November 7, 2023 **Author:** Pavel Odintsov **Content:** In addition to the capability which calculates bandwidth and packet rate of specific types of [packets](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-per-protocol-traffic-counters/), FastNetMon Advanced provides a very special counter which counts bandwidth and packet rate for discarded packets. The main application of this logic is to understand the amount of traffic filtered by BGP Flow Spec when FastNetMon works in BGP Flow Spec mitigation mode. We export these counters via CLI and API from the endpoint: ``` sudo fcli show single_host_counters 10.1.2.3 sudo fcli show single_host_counters_v6 beef::1 ``` Example output: ``` dropped_in_bytes 1000 dropped_in_packets 720000 dropped_out_bytes 0 dropped_out_packets 0 ``` In addition, we export this counter to both InfluxDB and Clickhouse. We support the capability to track discarded or dropped traffic for the following protocols: - sFlow v5 - Netflow v9 - IPFIX Unfortunately, this capability is very vendor-specific and your vendor may not implement it at all or may implement it in a non-RFC-compliant way. For Juniper MX routers, you need to enable special flags on the router side, which were added in JunOS OS 15.1F7 and are still in use. We did a review for JunOS 22.2R3, and this option is still available. Example configuration change: ``` inline-services { report-zero-oif-gw-on-discard; } ``` After that, you need to enable special logic to handle it on FastNetMon side: ``` sudo fcli set main netflow_mark_zero_next_hop_and_zero_output_as_dropped true sudo fcli commit ``` We require this flag because this approach does not use standardised IPFIX / Netflow v9 element forwardingStatus, elementID 89. We did a review of IPFIX elements exported by JunOS 21.4R3-S2.3, and the forwardingStatus field is still missing. We can confirm that Cisco ASR 9000 and Nokia SR routers use RFC RFC-compliant field to report this information, and FastNetMon can decode it. Unfortunately, [forwardingStatus](https://www.iana.org/assignments/ipfix/ipfix.xhtml#forwarding-status) field does not provide options to distinguish traffic discarded by ACL and traffic discarded by BGP Flow Spec, as it has only a few options documented in RFC7270: - 00b Unknown - 01b Forwarded - 10b Dropped - 11b Consumed As a consequence, we cannot distinguish them and provide a metric which includes both of them **Document Categories:** Traffic reports --- ### [BGP Flow spec configuration on Cisco ASR1000](https://fastnetmon.com/bgp-flow-spec-configuration-on-cisco-asr1000/) **Published:** July 24, 2020 **Author:** Pavel Odintsov **Content:** In this guide, we will cover all required steps to configure BGP Flow Spec on your Cisco ASR 1000 and use it for malicious traffic filtering. This guide assumes that you have configured a BGP Unicast session and it works without any issues. As a first step, please enable Flow Spec globally: ``` enable configure terminal flowspec address-family ipv4 local-install interface-all exit ``` After that, you will need to enable Flow spec for peering session to FastNetMon: ``` address-family ipv4 flowspec neighbor 192.168.11.11 activate neighbor 192.168.11.11 send-community neighbor 192.168.11.11 validation off neighbor 192.168.11.11 maximum-prefix 999 exit-address-family ``` After adding BGP flow spec announce from FastNetMon, you will see records like this on your router side: ``` show bgp ipv4 flowspec ``` Output: ``` BGP table version is 5, local router ID is 1.2.3.4 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path *> Dest:2.3.4.5/32,Source:1.2.3.4/32,Proto:=1 0.0.0.0 0 65116 ? *> Dest:2.3.4.5/32,Source:1.2.3.4/32,Proto:=1 0.0.0.0 0 65116 ? ``` That's it! Unfortunately, ASR 1000 does not expose the number of bytes/packets filtered by each flow spec rule. **Document Categories:** BGP --- ### [sFlow on Juniper MX FastNetMon Advanced](https://fastnetmon.com/docs-fnm-advanced/sflow-on-juniper-mx-fastnetmon-advanced/) **Published:** October 11, 2023 **Author:** Pavel Odintsov **Content:** We recommend using this [official guide](https://www.juniper.net/documentation/en_US/junos/topics/example/sflow-configuring-mx-series.html) to configure sFlow on the MX platform. Unfortunately, MX on Juniper has several quirks and may not work well. We recommend using [inline monitoring services](https://fastnetmon.com/docs-fnm-advanced/netflow-lite-and-ipfix-inline-monitoring-services/) instead. To address one of the well-known sFlow protocol implementation issues on Juniper MX, you may use this flag: ``` sudo fcli set sflow_read_packet_length_from_ip_header true sudo fcli commit ``` **Document Categories:** sFlow v5 --- ### [FastNetMon Advanced visual traffic with Grafana](https://fastnetmon.com/docs-fnm-advanced/advanced-visual-traffic/) **Published:** December 4, 2017 **Author:** Pavel Odintsov **Content:** In this reference, we will describe details about the traffic visualisation solution based on Grafana technology. For FastNetMon's proprietary traffic visualisation solution *FastNetMon LiveView*, refer [here](https://fastnetmon.com/docs-fnm-advanced/web-user-interface-for-fastnetmon-advanced/). ### Supported report types - Total traffic - Traffic for a specific prefix - Traffic for a specific host - Top hosts by traffic - Top networks by traffic - Top ASNs by traffic - Total traffic per hostgroup - Detailed traffic flows database All graphs are provided for IPv4 and IPv6. We maintain all our official dashboards as a repository at [GitHub](https://github.com/FastNetMon/fastnetmon-grafana-dashboards). ### System requirements Please note that your CPU should support SSE 4.2 instruction set for our time series database Clickhouse. On some virtualisation platforms like Proxmox, this capability is disabled even if CPU supports. You will need to follow this [guide](https://fastnetmon.com/docs-fnm-advanced/proxmox-vm-configuration-for-fastnetmon-advanced/) to enable it ### Install steps For installing the graphic stack, we usea special flag from FastNetMon’s installer. ``` wget https://install.fastnetmon.com/installer -Oinstaller sudo chmod +x installer sudo ./installer -install_graphic_stack ``` Please carefully read the output of the installer tool and remember the passwords for Grafana. During installation, Grafana and Clickhouse will be installed, configured and integrated with FastNetMon. To access Grafana, you use HTTP connection to port 81 or HTTPS connection to port 443 (Debian / Ubuntu only). Please note that dashboard "traffic database" uses traffic persistence capability which needed to be enabled [separately](https://fastnetmon.com/docs-fnm-advanced/advanced-visual-traffic/) By default, FastNetMon usesa self-signed SSL certificate available in your system. You may switch to your own SSL certificates by changing the following fields in file /etc/nginx/sites-enabled/grafana.conf: ``` ssl_certificate /etc/ssl/certs/ssl-cert-snakeoil.pem; ssl_certificate_key /etc/ssl/private/ssl-cert-snakeoil.key; ``` After that, you will need to restart Nginx to apply the changes: ``` sudo systemctl restart nginx ``` You can reset the password for any user or add a new user with a unique password using the following procedure: ``` wget https://install.fastnetmon.com/installer -Oinstaller sudo chmod +x installer sudo ./installer -reset_visual_passwords -visual_login admin ``` If you would like to create a non-admin user after running this command, you need to use your "admin" account, open https://10.0.0.1/admin/users and create a user with the same login and password: ![](https://fastnetmon.com/wp-content/uploads/2024/06/Screenshot-from-2024-06-10-01-04-09.png)It's required because we use HTTP basic authentication for increased security, which is not synchronised with Grafana user database. We use automatic provision of dashboards from folder, and FastNetMon installer creates the following file /etc/grafana/provisioning/datasources/fastnetmon.yaml to enable this capability: ``` apiVersion: 1 providers: - name: dashboards type: file updateIntervalSeconds: 30 editable: true options: path: /var/lib/grafana/fastnetmon_dashboards foldersFromFilesStructure: true ``` Then we copy dashboards from GitHub as is to the following folder /var/lib/grafana/fastnetmon\_dashboards. If you want to do it manually, you can do it this way: ``` sudo git clone https://github.com/FastNetMon/fastnetmon-grafana-dashboards.git /var/lib/grafana/fastnetmon_dashboards ``` If you would like to update dashboards on existing installation you can do it this way: ``` wget https://install.fastnetmon.com/installer -Oinstaller sudo chmod +x installer sudo ./installer -install_grafana_dashboards ``` Due to Grafana limitation, we have to hardcode UID for Clickhouse datastore this way in data source provisioning file /etc/grafana/provisioning/datasources/fastnetmon-clickhouse.yaml: ``` datasources: - orgId: 1 version: 1 name: Clickhouse official type: grafana-clickhouse-datasource uid: fastnetmonclickhouseofficialdatasourceuid jsonData: defaultDatabase: fastnetmon port: 9000 server: "127.0.0.1" username: "grafana" tlsSkipVerify: false secureJsonData: password: "very-secure-password-replace-it" ``` For InfluxDB (deprecated since July 2024), we have it slightly different way in /etc/grafana/provisioning/datasources/fastnetmon.yaml: ``` apiVersion: 1 datasources: - orgId: 1 version: 1 name: InfluxDB type: influxdb access: proxy url: https://127.0.0.1:8086 database: fastnetmon isDefault: true uid: fastnetmoninfluxdbdatasource ``` After making any changes with provision you will need to restart Grafana: ``` sudo systemctl restart grafana-server ``` You may check the detailed guide for manual configuration of [Clickhouse](https://fastnetmon.com/docs-fnm-advanced/traffic-metrics-in-clickhouse/) for metrics (recommended) and [InfluxDB](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-influxdb-integration/) (obsoleted, deprecated, not recommended). After this setting, you could see data on your graphs. Below you can find a few example dashboards. ![](https://fastnetmon.com/wp-content/uploads/2024/01/Total-traffic-1024x584.png)Total traffic![](https://fastnetmon.com/wp-content/uploads/2024/01/Traffic-for-specific-network-1024x584.png)Traffic for specific network![](https://fastnetmon.com/wp-content/uploads/2024/01/Traffic-for-specific-host-1024x584.png)Per host traffic![](https://fastnetmon.com/wp-content/uploads/2024/01/Top-hosts-1024x584.png)Top hosts![](https://fastnetmon.com/wp-content/uploads/2024/01/Per-ASN-traffic-1024x584.png)Per ASN traffic![](https://fastnetmon.com/wp-content/uploads/2024/01/Per-hostgroup-traffic-1024x584.png)Per group trafficIf you run a very old version of Grafana, or you have previously experienced issues with Grafana's authentication and access to Clickhouse. In this case, we recommend completely removing Grafana. You can use the following commands to remove all Grafana configuration: ``` sudo systemctl stop grafana-server.service sudo apt-get remove --purge grafana sudo rm -rf /var/lib/grafana/ sudo rm -rf /etc/grafana/ ``` And then run the visual installer again: ``` wget https://install.fastnetmon.com/installer -Oinstaller sudo chmod +x installer sudo ./installer -install_graphic_stack ``` **Document Categories:** Traffic reports --- ### [FastNetMon Advanced Technical Documentation](https://fastnetmon.com/docs-fnm-advanced/) **Published:** March 24, 2017 **Author:** Pavel Odintsov **Content:** This section provides comprehensive technical documentation for FastNetMon. It is intended to help network operators, engineers and security teams deploy, configure and operate FastNetMon in production environments. You will find guides covering installation, traffic collection methods, detection tuning, mitigation configuration and integration with existing network infrastructure. If you have questions that are not covered in the documentation, please contact our support team at <support@fastnetmon.com>. - Deployment - [Install guide](https://fastnetmon.com/docs-fnm-advanced/advanced-install-guide/) - [Docker installation](https://fastnetmon.com/fastnetmon-advanced-docker-installation/) - [FastNetMon Advanced manual deployment on Docker platform](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-manual-deployment-on-docker-platform/) - [Virtual machines and hypervisors](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-installation-on-hypervisors-or-virtual-machines/) - [Proxmox VM configuration for FastNetMon Advanced](https://fastnetmon.com/docs-fnm-advanced/proxmox-vm-configuration-for-fastnetmon-advanced/) - [FastNetMon Advanced installation on Proxmox VM](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-installation-on-proxmox-vm/) - [FastNetMon Advanced install on Hyper-V](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-install-on-hyper-v/) - [VM based installation on vmware ESXI](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-vm-image-install/) - [VM based install on vmware vCenter](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-vm-image-install-in-vmware-vcenter/) - Public cloud deploy - [Single click install on Google Cloud Engine](https://console.cloud.google.com/marketplace/details/fastnetmon-public/fastnetmon-advanced?filter=category:monitoring&id=ee824461-9928-4602-9877-534a6a70ca33) - [Single click deploy on Digital Ocean VM](https://marketplace.digitalocean.com/apps/fastnetmon) - [Manual installation on Google Cloud Engine](https://fastnetmon.com/docs-fnm-advanced/installing-fastnetmon-advanced-on-google-compute-engine/) - [Migration from Community edition to Advanced](https://fastnetmon.com/docs-fnm-advanced/migration-from-community-edition-to-advanced/) - [Installation on embedded ARM64 machines](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-arm-64-edition/) - [FastNetMon ssh shell](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-ssh-shell/) - [Manual installation](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-manual-install-process/) - Introduction - [Product overview](https://fastnetmon.com/product-overview/) - [Quick start](https://fastnetmon.com/docs-fnm-advanced/advanced-quick-start/) - [Licensing model](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-licensing-server/) - [Command line reference guide](https://fastnetmon.com/docs-fnm-advanced/advanced-cli-reference/) - [IPv6 support](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-ipv6-support/) - [Screenshots](https://fastnetmon.com/screenshoots-fastnetmon-advanced/) - [Deployment scenarios](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-deployment-scenarios/) - [High availability / HA setup](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-high-availability-setup/) - [FastNetMon multi PoP / Data Centre deployment options](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-multi-pop-data-centre-deployment-options/) - [FastNetMon Advanced XDP filter](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-xdp-filter/) - [FastNetMon Connection tracking](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-connection-tracking/) - Capture engines - Netflow and IPFIX - [Netflow and IPFIX configuration](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-configuration-for-netflow-and-ipfix/) - [Aggregation free Netflow and IPFIX with packet payload](https://fastnetmon.com/docs-fnm-advanced/netflow-lite-and-ipfix-inline-monitoring-services/) - [Netflow and IPFIX sampling configuration](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-netflow-and-ipfix-sampling-configuration/) - [Juniper IPFIX and Netflow configuration](https://fastnetmon.com/docs/junos_integration/) - [App Packet SR Plugin](https://fastnetmon.com/docs-fnm-advanced/app-packet-sr-plugin/) - [Nokia Netflow v9 and IPFIX configuration for FastNetMon Advanced](https://fastnetmon.com/docs-fnm-advanced/nokia-netflow-v9-and-ipfix-configuration-for-fastnetmon-advanced/) - [FastNetMon Netflow v9 configuration for Cisco ASR 1000](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-netflow-v9-configuration-for-cisco-asr-1000/) - [Huawei routers configuration](https://fastnetmon.com/docs-fnm-advanced/huawei-routers-configuration-with-fastnetmon-advanced/) - [Netflow v9 configuration for Cisco ASR 9000](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-netflow-v9-configuration-for-cisco-asr-9000/) - [FastNetMon Integration with TNSR High-Performance Router and VPN Concentrator](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-integration-with-tnsr-high-performance-router-and-vpn-concentrator/) - [Mikrotik Netflow configuration](https://fastnetmon.com/docs-fnm-advanced/mikrotik/) - [What is average\_calculation\_time?](https://fastnetmon.com/docs-fnm-advanced/what-is-average_calculation_time/) - [Juniper: handling jFlow/IPFIX export issues](https://fastnetmon.com/docs-fnm-advanced/juniper-handling-jflow-ipfix-export-issues/) - [FastNetMon Advanced IPFIX configuration for A-10 Networks Thunder](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-ipfix-configuration-for-a-10-networks-thunder/) - sFlow v5 - [sFlow configuration](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-sflow-configuration/) - [sFlow configuration for Extreme XOS](https://fastnetmon.com/docs/extreme/) - [sFlow configuration on Cisco Nexus 9000 for FastNetMon Advanced](https://fastnetmon.com/docs-fnm-advanced/sflow-configuration-on-cisco-nexus-9000-for-fastnetmon-advanced/) - [sFlow v5 export from Linux](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-sflow-v5-export-from-linux/) - [sFlow v5 on VyOS](https://fastnetmon.com/fastnetmon-vyos-sflow-v5-configuration/) - [sFlow on Juniper MX](https://www.juniper.net/documentation/en_US/junos/topics/example/sflow-configuring-mx-series.html) - Port mirror / SPAN - [AF\_PACKET (recommended)](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-port-mirror-configuration/) - [Port mirror or SPAN over GRE](https://fastnetmon.com/docs-fnm-advanced/port-mirror-or-span-over-gre/) - [AF\_XDP support](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-af_xdp-support/) - [FastNetMon flow](https://fastnetmon.com/docs-fnm-advanced/tera-flow/) - [Google Compute GCE VPC Flow logs](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-and-google-compute-gce-vpc-flow-logs/) - [Amazon VPC flow logs](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-and-amazon-vpc-flow-logs/) - Mitigation modes - [FastNetMon Advanced BGP Blackhole automation](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-bgp-blackhole-automation/) - [BGP Flow spec configuration](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-bgp-flow-spec-configuration/) - [Traffic buffer capability to speed up attack detection speed](https://fastnetmon.com/docs-fnm-advanced/traffic-buffer-capability-to-speed-up-attack-detection-speed/) - [Per direction hostgroup thresholds](https://fastnetmon.com/docs-fnm-advanced/per-direction-hostgroup-thresholds/) - [FastNetMon Advanced per-host hostgroups](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-per-host-hostgroups/) - [Flexible thresholds](https://fastnetmon.com/docs-fnm-advanced/flexible-thresholds/) - [FastNetMon Advanced per host threshold configuration](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-per-host-threshold-configuration/) - [FastNetMon and DDoS Scrubbing centers integration](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-and-ddos-scrubbing-centers-integration/) - [Per hostgroup thresholds](https://fastnetmon.com/docs-fnm-advanced/per-hostgroup-thresholds/) - [Attack detection for per hostgroup thresholds](https://fastnetmon.com/docs-fnm-advanced/attack-detection-for-per-hostgroup-thresholds/) - [Automated baseline calculation with FastNetMon Advanced](https://fastnetmon.com/docs-fnm-advanced/automated-baseline-calculation-with-fastnetmon-advanced/) - [Automatic blocks for remote attackers](https://fastnetmon.com/docs-fnm-advanced/automatic-blocks-for-remote-attackers/) - [BGP mitigation modes](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-bgp-mitigation-modes/) - [Threshold types](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-threshold-types/) - BGP - [FastNetMon BGP Peering session setup](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-bgp-peering-session-setup/) - [BGP unicast configuration](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-bgp-unicast-configuration/) - [BGP configuration for IPv6](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-ipv6-bgp-configuration/) - [BGP announces for total hostgroups](https://fastnetmon.com/docs-fnm-advanced/bgp-announces-for-total-hostgroups/) - [FastNetMon and BGP traffic diversion](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-and-bgp-traffic-diversion/) - [Multi level attack escalations](https://fastnetmon.com/docs-fnm-advanced/escalation-script-for-fastnetmon-advanced/) - [JunOS BGP configuration](https://fastnetmon.com/docs-fnm-advanced/junos-bgp-configuration/) - [FastNetMon BGP Flow Spec RFC 5575 JSON representation](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-bgp-flow-spec-rfc-5575-json-representation/) - [Mikrotik BGP configuration](https://fastnetmon.com/mikrotik-bgp-configuration/) - [FRR BGP configuration with FastNetMon](https://fastnetmon.com/docs-fnm-advanced/frr-bgp-configuration-with-fastnetmon/) - [Subnet collection from BGP peering session](https://fastnetmon.com/docs-fnm-advanced/subnet-collection-from-bgp-peering-session/) - [Automated BGP Feed injection](https://fastnetmon.com/docs-fnm-advanced/automated-bgp-feed-injection/) - [Country lockdown capability](https://fastnetmon.com/docs-fnm-advanced/country-lockdown-capability/) - [Selective BGP blackhole or traffic diversion](https://fastnetmon.com/docs-fnm-advanced/selective-bgp-blackhole-or-traffic-diversion-in-fastnetmon-advanced/) - BGP Flow spec configuration on Cisco ASR1000 - Traffic reports - [FastNetMon Advanced visual traffic](https://fastnetmon.com/docs-fnm-advanced/advanced-visual-traffic/) - [Traffic reports installation](https://fastnetmon.com/docs-fnm-advanced/advanced-visual-traffic/) - [Attack notification in Grafana](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-attack-notification-in-grafana/) - [FastNetMon ASN peering reports](https://fastnetmon.com/fastnetmon-asn-peering-reports/) - [FastNetMon Advanced InfluxDB integration](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-influxdb-integration/) - [Per interface counters](https://fastnetmon.com/docs-fnm-advanced/per-interface-counters/) - [Traffic Persistence](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-traffic-persistency/) - [Traffic export to InfluxDB using Kafka](https://fastnetmon.com/docs-fnm-advanced/traffic-export-to-influxdb-using-kafka/) - [Traffic Metrics in ClickHouse](https://fastnetmon.com/docs-fnm-advanced/traffic-metrics-in-clickhouse/) - [Per protocol traffic counters](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-per-protocol-traffic-counters/) - [InfluxDB data retention configuration](https://fastnetmon.com/docs-fnm-advanced/influxdb-data-retention-configuration/) - [Discarded traffic monitoring in FastNetMon Advanced](https://fastnetmon.com/docs-fnm-advanced/discarded-traffic-monitoring-in-fastnetmon-advanced/) - Attack actions - [E-mail notifications](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-e-mail-notification/) - [FastNetMon Advanced and Slack integration](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-and-slack-integration/) - [FastNetMon Advanced and Telegram integration](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-and-telegram-integration/) - [Web callback](https://fastnetmon.com/docs-fnm-advanced/example-web-hook-receiver-for-fastnetmon-advanced/) - [MongoDB integration with FastNetMon Advanced](https://fastnetmon.com/docs-fnm-advanced/mongodb-integration-with-fastnetmon-advanced/) - [FastNetMon Advanced integration with Path.net DDoS scrubbing centre](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-integration-with-path-net-ddos-scrubbing-centre/) - [FastNetMon Advanced integration with Cloudflare Magic Transit scrubbing centre](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-integration-with-cloudflare-magic-transit-scrubbing-centre/) - FastNetMon Advanced integration with F5 DDoS scrubbing centre - Callback scripts - [Text notify script in Bash](https://fastnetmon.com/docs-fnm-advanced/notify-script-in-bash/) - [JSON notify script in Perl](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-notify-script-in-perl/) - [JSON notify script in Python](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-json-notify-script-in-python/) - [Run multiple notify scripts in text mode](https://fastnetmon.com/docs-fnm-advanced/run-multiple-notify-scripts-from-fastnetmon-in-text-mode/) - [Radware DefenseFlow integration](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-radware-second-generation-integration/) - Third party integrations - Developer guides - [API](https://fastnetmon.com/docs-fnm-advanced/advanced-api/) - [Tera Flow Cap’n’proto specification](https://fastnetmon.com/docs-fnm-advanced/tera-flow-capnproto-specification/) - [Example API client which adds/removes networks](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-example-api-client/) - [Example API client which blocks and unblocks IP](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-example-api-client-which-blocks-and-unblocks-ip/) - [Tera Flow Cap’n’proto specification](https://fastnetmon.com/docs-fnm-advanced/tera-flow-capnproto-specification/) - [BGP Flow Spec RFC 5575 JSON representation](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-bgp-flow-spec-rfc-5575-json-representation/) - JSON formats - Maintenance operations - [FastNetMon Advanced support policy](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-support-policy/) - [FastNetMon Advanced components diagram](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-components-diagram/) - [FastNetMon Accessibility issues](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-accessibility-issues/) - [Clickhouse excessive disk usage with log tables](https://fastnetmon.com/docs-fnm-advanced/clickhouse-excessive-disk-usage-with-log-tables/) - [Using FastNetMon Advanced with FerretDB and PostgreSQL instead of MongoDB](https://fastnetmon.com/docs-fnm-advanced/using-fastnetmon-advanced-with-ferretdb-and-postgresql-instead-of-mongodb/) - [FastNetMon Advanced migration from MongoDB to FerretDB](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-migration-from-mongodb-to-ferretdb/) - [Using FastNetMon Advanced with FerretDB and SQLite backend instead of MongoDB](https://fastnetmon.com/using-fastnetmon-advanced-with-ferretdb-and-sqlite-backend-instead-of-mongodb/) - [FastNetMon Advanced segmentation fault](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-segmentation-fault/) - FastNetMon Advanced upgrade procedure - [Version history](https://github.com/FastNetMon/fastnetmon-advanced-releases/releases) - [Backup and restore](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-backup-restore/) - [FastNetMon Advanced Release Lifecycle](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-release-lifecycle/) - [Extending disk space for VM installs](https://fastnetmon.com/docs-fnm-advanced/extending-disk-space-for-fastnetmon-vm-installs/) - [Delivering traffic information to FastNetMon over the Internet](https://fastnetmon.com/docs-fnm-advanced/delivering-traffic-information-to-fastnetmon-over-the-internet/) - [Memory consumption](https://fastnetmon.com/docs/memory_consumption/) - [How to keep traffic counters during restart of FastNetMon](https://fastnetmon.com/docs-fnm-advanced/how-to-keep-traffic-counters-during-restart-of-fastnetmon/) - [Flexible counters for traffic calculation](https://fastnetmon.com/docs-fnm-advanced/flexible-counters-for-traffic-calculation/) - [Blackhole persistency during restart](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-blackhole-during-restart/) - [Сonfiguration options reference](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-configuration-options/) - [Scalability](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-scalability/) - [Automatic baseline calculation Clickhouse](https://fastnetmon.com/docs-fnm-advanced/automatic-baseline-calculation-for-fastnetmon/) - [Automatic baseline calculation InfluxDB](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-naseline-calculation/) - [sFlow, Netflow or IPFIX duplication to multiple servers](https://fastnetmon.com/docs-fnm-advanced/sflow-netflow-or-ipfix-duplication-to-multiple-servers/) - [Metrics export to Prometheus](https://fastnetmon.com/monitoring-fastnetmon-via-prometheus/) - [FastNetMon Advanced complete removal](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-complete-removal/) - [Attack\_protocol deprecation in version 2.0.368](https://fastnetmon.com/docs-fnm-advanced/attack_protocol-deprecation-in-version-2-0-368/) - [Log management](https://fastnetmon.com/log-management-in-fastnetmon/) --- ### [FastNetMon and DDoS Scrubbing centers integration](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-and-ddos-scrubbing-centers-integration/) **Published:** September 28, 2023 **Author:** Pavel Odintsov **Content:** In addition to solid support for BGP Unicast protocol which can be used to [move traffic for affected prefix](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-and-bgp-traffic-diversion/) to cloud based DDS scrubbing center FastNetMon Advanced features multiple API based integrations with variety of DDoS scrubbing centers. You can use FastNetMon Advanced with following scrubbing centers: - [GCore Global DDoS Protection ](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-integration-with-gcore-global-ddos-protection-scrubbing-centre/) - [F5](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-integration-with-f5-silverline-ddos-scrubbing-centre/) - [Cloudflare Magic Transit](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-integration-with-cloudflare-magic-transit-scrubbing-centre/) These integrations offer native way to enable prefix announcement via particular scrubbing center using their API. In addition FastNetMon has an option to withdraw diversion when attack finishes. Want to see integration with your own Cloud DDoS Scrubbing service? You can find our [technical requirements](https://fastnetmon.com/docs-fnm-advanced/requirements-for-integration-with-new-cloud-based-ddos-scrubbing-centers/) here. Please [reach us](https://fastnetmon.com/contact/ "https://fastnetmon.com/contact/") and we will be happy to discuss details. **Document Categories:** Mitigation modes --- ### [Using FastNetMon Advanced with FerretDB and SQLite backend instead of MongoDB](https://fastnetmon.com/docs-fnm-advanced/using-fastnetmon-advanced-with-ferretdb-and-sqlite-backend-instead-of-mongodb/) **Published:** July 5, 2023 **Author:** Pavel Odintsov **Content:** We have an experimental version of our installer, which installs FastNetMon Advanced with FerretDB automatically: ``` wget https://install.fastnetmon.com/installer -Oinstaller sudo chmod +x installer sudo ./installer -ferretdb ``` This guide is an improved version of this [guide](https://fastnetmon.com/docs-fnm-advanced/using-fastnetmon-advanced-with-ferretdb-and-postgresql-instead-of-mongodb/) with the goal to eliminate dependency on PostgreSQL and using SQLite instead. FerretDB offers complete ARM64 support; you can use FastNetMon Advanced ARM64 edition with FerretDB. ``` wget https://install.fastnetmon.com/installer_arm64 -Oinstaller sudo chmod +x installer sudo ./installer -developer_version -ferretdb ``` Please follow all steps as in the referenced guide until you reach the section about /lib/systemd/system/ferretdb.service. You will need to use a slightly different version of it: ``` [Unit] Description=FerretDB database After=network.target remote-fs.target [Service] Type=simple ExecStart=/usr/bin/ferretdb --debug-addr="127.0.0.1:8089" --handler="sqlite" --sqlite-url "file:/var/lib/ferretdb/" Restart=on-failure RestartSec=5s [Install] WantedBy=multi-user.target ``` After this, you will need to create a folder for SQLite database: ``` sudo mkdir /var/lib/ferretdb ``` After this, follow all steps from the original guide, skipping all sections about PostgreSQL. After successful creation of a database, you will see a new file in /var/lib/ferretdb/ which will carry all FastNetMon configuration: ``` ls -al /var/lib/ferretdb/ -rw-r--r-- 1 root root 49152 Jul 5 14:49 fastnetmon.sqlite ``` Then we need to explicitly disable authentication using the following option, as SQLite-backed does not support auth: ``` echo '{"mongodb_username": ""}' | sudo tee /etc/fastnetmon/fastnetmon.conf ``` **Document Categories:** Maintenance operations --- ### [Releases](https://fastnetmon.com/releases/) **Published:** March 9, 2026 **Author:** Outi Maria Pietilanaho **Content:** # Releases [Home](https://fastnetmon.com/ "Home")‣ Releases FastNetMon Advanced is actively maintained and enhanced to provide deeper traffic visibility and stronger [DDoS defence](https://fastnetmon.com/ddos-detection-and-mitigation/) capabilities. This page lists all FastNetMon Advanced version releases, including new features, improvements, and platform updates. For full technical details and historical release information, visit the [FastNetMon GitHub repository](https://github.com/FastNetMon). [![FastNetMon Advanced 2.0.385](https://fastnetmon.com/wp-content/uploads/2026/10/Release_notes_FastNetMon_Advanced_2.0.385.png)](https://fastnetmon.com/2026/10/12/fastnetmon-advanced-2-0-385/) ## [FastNetMon Advanced 2.0.385](https://fastnetmon.com/2026/10/12/fastnetmon-advanced-2-0-385/) Oct 12, 2026 \| [Releases](https://fastnetmon.com/category/releases/) Release date: 12 October, 2026 Version: 2.0.385 FastNetMon Advanced 2.0.385 introduces enhanced FlowSpec traffic filtering statistics, improved BGP announcement capabilities, and TLS support for… [![FastNetMon Advanced 2.0.384](https://fastnetmon.com/wp-content/uploads/2026/09/Release_notes_FastNetMon_Advanced_2.0.384.png)](https://fastnetmon.com/2026/09/16/fastnetmon-advanced-2-0-384/) ## [FastNetMon Advanced 2.0.384](https://fastnetmon.com/2026/09/16/fastnetmon-advanced-2-0-384/) Sep 16, 2026 \| [Releases](https://fastnetmon.com/category/releases/) Release date: 16 September, 2026 Version: 2.0.384 FastNetMon Advanced 2.0.384 introduces a new Linux psample traffic collection plugin, multi-endpoint flow forwarding, enhanced BGP configuration for… [![Release notes cover for FastNetMon Advanced 2.0.383 with a blue geometric background and server graphics](https://fastnetmon.com/wp-content/uploads/2026/08/Copy-of-Release_notes_FastNetMon_Advanced_2.0.376.png)](https://fastnetmon.com/2026/08/06/fastnetmon-advanced-2-0-383/) ## [FastNetMon Advanced 2.0.383](https://fastnetmon.com/2026/08/06/fastnetmon-advanced-2-0-383/) Aug 6, 2026 \| [Releases](https://fastnetmon.com/category/releases/) Release date: 5 August, 2026 Version: 2.0.383 FastNetMon Advanced 2.0.383 is a mandatory update for customers using online licensing. This release includes a new CA certificate required for… [![Release Notes banner for FastNetMon Advanced 2.0.382 with blue background and geometric triangles in front of a circuitry image.](https://fastnetmon.com/wp-content/uploads/2026/07/Release_notes_FastNetMon_Advanced_2.0.376-3.png)](https://fastnetmon.com/2026/07/20/fastnetmon-advanced-2-0-382/) ## [FastNetMon Advanced 2.0.382](https://fastnetmon.com/2026/07/20/fastnetmon-advanced-2-0-382/) Jul 20, 2026 \| [Releases](https://fastnetmon.com/category/releases/) Release date: 20 July, 2026 Version: 2.0.382 FastNetMon Advanced 2.0.382 is a security-focused maintenance release that strengthens the platform’s resilience against malformed network telemetry and… [![Release notes banner for FastNetMon Advanced, version 2.0.381, with a blue geometric background and circuit imagery on the right.](https://fastnetmon.com/wp-content/uploads/2026/07/Release_notes_FastNetMon_Advanced_2.0.381.png)](https://fastnetmon.com/2026/07/13/fastnetmon-advanced-2-0-381/) ## [FastNetMon Advanced 2.0.381](https://fastnetmon.com/2026/07/13/fastnetmon-advanced-2-0-381/) Jul 13, 2026 \| [Releases](https://fastnetmon.com/category/releases/) Release date: 13 July, 2026 Version: 2.0.381 FastNetMon Advanced 2.0.381 delivers major improvements to BGP FlowSpec capabilities, including full IPv6 manual announcement support, enhanced route… [![Release notes banner for FastNetMon Advanced version 2.0.380, featuring blue geometric shapes and a server/circuit background.](https://fastnetmon.com/wp-content/uploads/2026/05/Release_notes_FastNetMon_Advanced_2.0.380.png)](https://fastnetmon.com/2026/05/27/fastnetmon-advanced-2-0-380/) ## [FastNetMon Advanced 2.0.380](https://fastnetmon.com/2026/05/27/fastnetmon-advanced-2-0-380/) May 27, 2026 \| [Releases](https://fastnetmon.com/category/releases/) Release date: 27 May, 2026 Version: 2.0.380 This release includes multiple security fixes and stability improvements across BGP, Flow Spec, Netflow v9, IPFIX, packet parsing, and internal buffer… [![Release notes banner for FastNetMon Advanced 2.0.379 on a blue geometric background with circuit imagery and logo.](https://fastnetmon.com/wp-content/uploads/2026/05/Release_notes_FastNetMon_Advanced_2.0.379.png)](https://fastnetmon.com/2026/05/21/fastnetmon-advanced-2-0-379/) ## [FastNetMon Advanced 2.0.379](https://fastnetmon.com/2026/05/21/fastnetmon-advanced-2-0-379/) May 21, 2026 \| [Releases](https://fastnetmon.com/category/releases/) Release date: 31 May, 2026 Version: 2.0.379 FastNetMon Advanced 2.0.379 introduces a major rewrite of IPv4 and IPv6 network loading and lookup logic, improving scalability, concurrency, and memory… [![Release notes banner for FastNetMon Advanced 2.0.378 with a blue geometric design and server circuitry background.](https://fastnetmon.com/wp-content/uploads/2026/04/Release_notes_FastNetMon_Advanced_2.0.377-1.png)](https://fastnetmon.com/2026/04/27/fastnetmon-advanced-2-0-378/) ## [FastNetMon Advanced 2.0.378](https://fastnetmon.com/2026/04/27/fastnetmon-advanced-2-0-378/) Apr 27, 2026 \| [Releases](https://fastnetmon.com/category/releases/) Release date: 27 April, 2026 Version: 2.0.378 FastNetMon Advanced 2.0.378 improves flexible counters by fixing a minor degradation issue in the underlying fcli component. The release also enhances… [![Release notes banner for FastNetMon Advanced 2.0.377 with blue background and geometric circuit graphics.](https://fastnetmon.com/wp-content/uploads/2026/04/Release_notes_FastNetMon_Advanced_2.0.377.png)](https://fastnetmon.com/2026/04/17/fastnetmon-advanced-2-0-377/) ## [FastNetMon Advanced 2.0.377](https://fastnetmon.com/2026/04/17/fastnetmon-advanced-2-0-377/) Apr 17, 2026 \| [Releases](https://fastnetmon.com/category/releases/) Release date: 17 April, 2026 Version: 2.0.377 FastNetMon Advanced 2.0.377 delivers a major refactor of the command line tool and API, making integrations more modern and maintainable. The release… [![FastNetMon Advanced 2.0.376](https://fastnetmon.com/wp-content/uploads/2026/04/Release_notes_FastNetMon_Advanced_2.0.376.png)](https://fastnetmon.com/2026/04/07/fastnetmon-advanced-2-0-376/) ## [FastNetMon Advanced 2.0.376](https://fastnetmon.com/2026/04/07/fastnetmon-advanced-2-0-376/) Apr 7, 2026 \| [Releases](https://fastnetmon.com/category/releases/) Release date: 7 April, 2026 Version: 2.0.376 FastNetMon Advanced 2.0.376 introduces protocol parsing improvements, enhanced flow visibility, and platform lifecycle updates, while continuing to… Page 1 of 41[2](https://fastnetmon.com/wp-cron.php/page/2/?doing_wp_cron=1792528011.6662390232086181640625&et_blog "Page 2")[3](https://fastnetmon.com/wp-cron.php/page/3/?doing_wp_cron=1792528011.6662390232086181640625&et_blog "Page 3")[4](https://fastnetmon.com/wp-cron.php/page/4/?doing_wp_cron=1792528011.6662390232086181640625&et_blog "Page 4")[»](https://fastnetmon.com/wp-cron.php/page/2/?doing_wp_cron=1792528011.6662390232086181640625&et_blog) **Document Categories:** Maintenance operations --- ### [Single click install on Google Cloud Engine](https://fastnetmon.com/docs-fnm-advanced/single-click-install-on-google-cloud-engine/) **Published:** May 13, 2026 **Author:** Milan Milosevic **Content:** [![](https://fastnetmon.com/wp-content/uploads/2026/05/google-cloud-platoform-1024x741.png)](https://console.cloud.google.com/marketplace/details/fastnetmon-public/fastnetmon-advanced?filter=category:monitoring&id=ee824461-9928-4602-9877-534a6a70ca33) **Document Categories:** Public cloud deploy --- ### [FastNetMon Advanced IPv6 support](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-ipv6-support/) **Published:** February 15, 2018 **Author:** Pavel Odintsov **Content:** FastNetMon Advanced has complete support for the IPv6 protocol. Current IPv6 support limitations: - IPv6 attack detection works only in "blackhole mode". In this mode, FastNetMon blocks the host completely. It does not support selective BGP Flow Spec-based filtering. By default, all new installations of FastNetMon work with IPv6 traffic. For an old installation, you need to enable this feature explicitly: ``` sudo fcli set main process_ipv6_traffic enable sudo fcli commit ``` You also need to add all your IPv6 networks for monitoring: ``` sudo fcli set main networks_list 0000::1/128 sudo fcli commit ``` Please enable IPv6 traffic metrics on network equipment side. You can use the following commands to check the amount of IPv6 traffic captured by FastNetMon: ``` sudo fcli show total_traffic_counters_v6 sudo fcli show network_counters_v6 sudo fcli show host_counters_v6 sudo fcli show system_counters | grep total_ipv6_packets ``` Also, we added support for IPv6 in the fastnetmon\_client tool: ``` sudo fastnetmon_client -ipv6 ``` To enable ban actions for IPv6 traffic, please execute the following: ``` sudo fcli set main enable_ban_ipv6 enable sudo fcli commit ``` You can check blocked hosts using the same approach as for IPv4: ``` sudo fcli show blackhole ``` To read more about IPv6-specific options for BGP, please refer to [this](https://fastnetmon.com/fastnetmon-advanced-ipv6-bgp-configuration/) page. **Document Categories:** Introduction --- ### [FastNetMon usage analytics](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-usage-analytics/) **Published:** July 4, 2023 **Author:** Pavel Odintsov **Content:** For product usage survey purposes, FastNetMon sends the following information to the stats server multiple times per day: - Instance ID random identifier allocated during installation - Current incoming, outgoing, other and internal bandwidth for IPv4, IPv6 and IPv4+IPv6 traffic - Total number of hosts in IPv4 network - Number of active IPv4 and IPv6 hosts - Number of observed Netflow/IPFIX flows per second - Number of observed sFlow headers per second - Version of FastNetMon - Enabled plugins (af\_packet, sflow, netflow, xdp) - Virtualisation technology - Time required for speed calculation - Linux kernel version - Linux distribution name - Linux distribution version - CPU flags - Feature flags (enabled or disabled) for following features: BGP, InfluxDB, Clickhouse Metrics, Traffic DB, Prometheus, BGP Flow Spec We collect this information to prioritise the development of particular features and to focus testing effort on specific platforms. FastNetMon uses encrypted HTTPS protocol to deliver this information to our analytics servers. Our statistics server stores IPv4 / IPv6 addresses of the machine which sent data. --- ### [FastNetMon Advanced components diagram](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-components-diagram/) **Published:** October 1, 2024 **Author:** Pavel Odintsov **Content:** On this diagram, you can find all FastNetMon toolkit components ![](https://fastnetmon.com/wp-content/uploads/2024/10/FastNetMon-components_draw_io.drawio.png) **Document Categories:** Maintenance operations --- ### [FastNetMon Advanced installation on Hypervisors or Virtual Machines](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-installation-on-hypervisors-or-virtual-machines/) **Published:** March 22, 2024 **Author:** Pavel Odintsov **Content:** In addition to the option of [installing FastNetMon](https://fastnetmon.com/docs-fnm-advanced/advanced-install-guide/) on any supported Linux, we offer VM images for multiple hypervisors, which include pre-installed FastNetMon with all the components needed: - [vmware ESXi](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-vm-image-install/) - [vmware vCenter](https://fastnetmon.com/fastnetmon-vm-image-install-in-vmware-vcenter/) - [Proxmox](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-installation-on-proxmox-vm/) - [Microsoft Hyper-V](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-install-on-hyper-v/) --- ### [BGP BMP configuration instructions](https://fastnetmon.com/docs-fnm-advanced/bgp-bmp-configuration-instructions/) **Published:** April 28, 2026 **Author:** Pavel Odintsov **Content:** You can find BMP configuration examples for following vendors below: - [Juniper](https://fastnetmon.com/docs-fnm-advanced/enabling-bgp-bmp-monitoring-on-junos-juniper-patforms/) **Document Categories:** BMP --- ### [FastNetMon Accessibility issues](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-accessibility-issues/) **Published:** September 18, 2024 **Author:** Pavel Odintsov **Content:** In some exceptionally rare cases, you may experience issues caused by the fact that the FastNetMon daemon is not running. Usually, you notice such issues by following the error from fcli or from our [API daemon](https://fastnetmon.com/docs-fnm-advanced/advanced-api/): ``` sudo fcli show log 2024/09/17 15:14:31 Cannot connect to FastNetMon API localhost:50052: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial tcp 127.0.0.1:50052: connect: connection refused" 2024/09/17 15:14:31 Please check that daemon is running: sudo systemctl status fastnetmon and restart it if needed: sudo systemctl restart fastnetmon ``` Such an error may be temporary, meaning it disappears after 10-20 seconds, and you simply need to retry your command. In this case, it means that very likely you triggered FastNetMon daemon restart by using a command which internally restarts the FastNetMon daemon, and then it needs 10-60 seconds to load properly: ``` sudo fcli commit ``` If this error persists longer than 60 seconds, you should check if everything is OK with the daemon. The first step we recommend taking is to check the daemon status: ``` sudo systemctl status fastnetmon ``` Correctly running FastNetMon daemon appears as follows: ![](https://fastnetmon.com/wp-content/uploads/2024/09/Screenshot-from-2024-09-18-14-56-34-1024x220.png)You need to pay attention to the fields "Active" and the date and time stamps right after it, which indicate the time when the daemon was started. If it few hours ago, then it's OK and the daemon is running correctly. In some cases, FastNetMon daemon may be in a crash loop, and it has status "active (running)", but the time when it started may be a few seconds ago. In this case, we recommend checking the guide about [debugging segmentation faults](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-segmentation-fault/) in FastNetMon. You can also manually check that the FastNetMon process is in memory: ``` ps aux | grep fastnetmon ``` And the correct output appears as follows: ![](https://fastnetmon.com/wp-content/uploads/2024/09/Screenshot-from-2024-09-18-15-07-43-1024x73.png)If you've confirmed that the daemon is not running, the next step is to check the last entries in the FastNetMon log file: ``` tail -n 1000 /var/log/fastnetmon/fastnetmon.log ``` The most common reason for FastNetMon unavailability is an issue with MongoDB accessibility, and we recommend using this guide to find out [reasons](https://fastnetmon.com/docs-fnm-advanced/mongodb-integration-with-fastnetmon-advanced/). If FastNetMon is running but you still see an error that the API is not available, we recommend checking that FastNetMon listens on this port: ``` sudo netstat -lnpt |grep 50052 tcp6 0 0 127.0.0.1:50052 :::* LISTEN 3307319/fastnetmon ``` And if it does not, we recommend checking the FastNetMon log file for possible reasons. In addition to this, we recommend checking the firewall configuration to ensure that it allows local connections to port 50052 via TCP protocol. If none of these instructions work, please reach out to our support. **Document Categories:** Maintenance operations --- ### [FastNetMon Advanced support policy](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-support-policy/) **Published:** September 30, 2024 **Author:** Pavel Odintsov **Content:** As part of your subscription, you have a fixed number of support requests every month. ### Scope of support Our support policy is strictly limited to issues about FastNetMon Advanced itself. We can provide you with assistance only when our product is not behaving as described in the documentation. We do not provide assisted installation or assisted configuration services. If you require assistance in installation and configuration, please see the list of our [partners](https://fastnetmon.com/partners/). ### Support time Our support engineers are available from Monday to Friday, 10:00 AM to 5:00 PM UK time. We aim to provide initial feedback about your case within 12 hours, but in case of complicated issues requiring senior personnel engagement, the expected timeframe for resolution may be significantly longer. ### Components included in support FastNetMon Advanced includes the following daemons, and you can expect full support for issues regarding them: - FastNetMon daemon - Command line management tool: fcli - Command line reporting tool: fastnetmon\_client - Public REST API - Traffic DB daemon ### Third-party components In addition to our software, FastNetMon Advanced includes multiple third-party open source products: - MongoDB / FerretDB - Grafana - Clickhouse - GoBGP - Ubuntu / Debian / RedHat Linux We do not provide any support for these third-party products when they're used in a configuration which was altered in any way from our standard installation. If you're looking for any assistance regarding these products, we recommend reaching out to the third-party provider or requesting assistance from one of our partners. If you need to make any configuration changes for a Linux distribution (such as network configuration), you need to do it on your own using publicly available instructions from distribution vendors. ### Your responsibility Please note that it's your responsibility to regularly upgrade and maintain Linux used to run FastNetMon to avoid any security and stability issues. You need to [regularly](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-upgrade-procedure/) upgrade FastNetMon itself and run the latest stable version of it. If you've faced any issues and you're not on the latest version (which can be found [here](https://github.com/FastNetMon/fastnetmon-advanced-releases)), please upgrade to the latest version and replicate the issue. You need to follow your Linux distribution life cycle information about end of life and migrate to the next supported version of Linux distribution when needed. It's your responsibility to select particular hardware for running our product. We cannot recommend specific components, and we provide only generic requirements for hardware explained in the [installation](https://fastnetmon.com/docs-fnm-advanced/advanced-install-guide/) guide. It's your responsibility to install the product and finish the initial configuration as described in our official documentation. It's your responsibility to maintain the physical server in a fully operational state. We will not be able to assist in case of any issues with FastNetMon product caused by underlying hardware problems. We can provide support only if your Linux distribution is officially supported by standard support from the distribution vendor. ### Bug fixes policy As part of our software development process, we only provide bug fixes for the latest version of FastNetMon. ### Third-party integrations If you use FastNetMon as part of a larger toolkit or use third-party management systems for it, we will not be able to assist with queries which involve any information or screenshots from these systems. You need to replicate issues without using any third-party components in order to report the issue to us. ### Support channels Our support is exclusively provided via email or the ticket system. We do not provide technical support via phone and cannot schedule support sessions for specific periods of time, as all queries are handled in order as they arrive. It's expected for customers to have Linux and network engineers to maintain our software and integrate it with our network. ### Remote access to servers We do not accept SSH (or any other remote access means) access for your equipment unless it's confirmed by our support team as absolutely necessary. By granting us access to your server, you confirm that you have a tested up-to-date backup of your server. You indemnify us from any potential issues or data loss which can be caused by our intervention. You guarantee that servers have no personal information or any kind of confidential or sensitive data. After we finish the work on your equipment, it's your responsibility to revoke access and rotate all passwords shared. ### Support language Our official support language is English. ### Communication style We expect that you communicate with our support team using language acceptable in business communication. In case of any violations (for example, swearing, insults, rude language), we reserve the right to limit your access to support. ### Assistance with network equipment configuration Our engineers may provide some suggestions regarding network equipment setup from our knowledge base (mostly for BGP and traffic telemetry), but we cannot provide specific recommendations for your particular setup. Please never share access to network equipment with us, as the team is explicitly prohibited from making any corrections. **Document Categories:** Maintenance operations --- ### [Attack_protocol deprecation in version 2.0.368](https://fastnetmon.com/docs-fnm-advanced/attack_protocol-deprecation-in-version-2-0-368/) **Published:** December 19, 2024 **Author:** Pavel Odintsov **Content:** In version 2.0.368 (released 23rd November 2024) of FastNetMon Advanced, we completely removed field attack\_protocol from JSON script and POST callbacks. In version 2.0.367 (released October 20 2024), this flag was set to "unknown" and marked as obsoleted. We did this change as attack\_protocol did not reflect attack vector and was based solely on the amount of traffic for the host, and it used the following logic: ``` unsigned int detect_attack_protocol(const subnet_counter_t& speed_element, direction_t attack_direction) { if (attack_direction == INCOMING) { return get_max_used_protocol(speed_element.tcp.in_packets, speed_element.udp.in_packets, speed_element.icmp.in_packets); } else { // OUTGOING return get_max_used_protocol(speed_element.tcp.out_packets, speed_element.udp.out_packets, speed_element.icmp.out_packets); } } #define my_max_on_defines(a, b) (a > b ? a : b) unsigned int get_max_used_protocol(uint64_t tcp, uint64_t udp, uint64_t icmp) { unsigned int max = my_max_on_defines(my_max_on_defines(udp, tcp), icmp); if (max == tcp) { return IPPROTO_TCP; } else if (max == udp) { return IPPROTO_UDP; } else if (max == icmp) { return IPPROTO_ICMP; } return 0; } ``` You can get more reliable results by using [fields](https://github.com/FastNetMon/fastnetmon-json-schema/blob/361118dbbcc2d699272f67d64833eac405eb26e8/blackhole_ipv4_ban.json#L6) attack\_detection\_threshold and attack\_detection\_threshold\_direction from JSON callback. To replicate this logic as is, you can add UDP, TCP and ICMP-based thresholds instead of a single threshold for total bandwidth. **Document Categories:** Maintenance operations --- ### [Using FastNetMon Advanced with FerretDB and PostgreSQL instead of MongoDB](https://fastnetmon.com/docs-fnm-advanced/using-fastnetmon-advanced-with-ferretdb-and-postgresql-instead-of-mongodb/) **Published:** March 24, 2023 **Author:** Pavel Odintsov **Content:** Warning: This capability is in early experimental stages and **not** suitable for production deployments. Warning: This guide is not suitable for existing installations, as we will remove all configuration data. By default, FastNetMon Advanced uses [MongoDB](https://fastnetmon.com/docs-fnm-advanced/mongodb-integration-with-fastnetmon-advanced/ "MongoDB") as the default database for configuration. In addition to storing configuration in MongoDB, FastNetMon may store some optional information about attacks, but this information is not used by FastNetMon itself and can be easily skipped. FastNetMon does not store metrics or traffic in MongoDB, as we use InfluxDB and Clickhouse databases for this purpose. MongoDB uses a relatively unusual license called SSPL, which may be a limiting factor for cloud deployments. MongoDB has official builds for x86\_64 and ARM64 platforms, but other platforms are not supported. In addition to these constraints, MongoDB started requiring CPU extensions such as AVX available only for the latest generations of CPUs, which may be a limiting factor too. [FerretDB](https://www.ferretdb.io/) is an open-source proxy that translates MongoDB wire protocol queries to SQL, with PostgreSQL as the database engine. To start using FastNetMon with FerretDB, you need to use any version of FastNetMon Advanced starting from 2.0.335, as this version has the logic [changes](https://github.com/FastNetMon/fastnetmon-advanced-releases/releases/tag/v2.0.335) required to run it efficiently. To start with, please use the standard [install guide](https://fastnetmon.com/docs-fnm-advanced/advanced-install-guide/) and install FastNetMon Advanced with MongoDB as the configuration backend. Please do **not** try using this guide for an existing installation, as it will remove all configuration data. We're going to use Ubuntu 22.04 for our tests, and we support only this platform so far.\\ If you do not want to have PostgreSQL on the server, we have a lightweight [SQLite based](https://fastnetmon.com/using-fastnetmon-advanced-with-ferretdb-and-sqlite-backend-instead-of-mongodb/) alternative. Check that FastNetMon daemon is running: ``` sudo fcli show license ``` Example output: ``` Developer license for 10000 mbits valid until 2023-04-07 ``` And confirm that fcli has access to MongoDB: ``` sudo fcli show main ``` Then you need to install latest version of FerretDB: ``` wget https://github.com/FerretDB/FerretDB/releases/download/v1.5.0/ferretdb.deb ``` Then install it: ``` sudo dpkg -i ferretdb.deb ``` Then create a systemd unit file for FerretDB: ``` sudo vim /lib/systemd/system/ferretdb.service ``` With the following content: ``` [Unit] Description=FerretDB database After=network.target remote-fs.target [Service] Type=simple ExecStart=/usr/bin/ferretdb --debug-addr="127.0.0.1:8089" Restart=on-failure RestartSec=5s [Install] WantedBy=multi-user.target ``` Then reload the systemd configuration: ``` sudo systemctl daemon-reload ``` Then we need to shut down and disable MongoDB, as FerretDB uses the same port: ``` sudo systemctl stop mongod sudo systemctl disable mongod ``` And enable start on boot: ``` sudo systemctl enable ferretdb ``` And try starting it: ``` sudo systemctl start ferretdb ``` Then check that it's running well: ``` sudo systemctl status ferretdb ``` Example output: ``` ferretdb.service - FerretDB database Loaded: loaded (/lib/systemd/system/ferretdb.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2023-03-24 12:23:19 UTC; 1min 5s ago Main PID: 38127 (ferretdb) Tasks: 8 (limit: 4694) Memory: 5.1M CPU: 36ms CGroup: /system.slice/ferretdb.service └─38127 /usr/bin/ferretdb --debug-addr=127.0.0.1:8089 ``` And check that the daemon is running well: ``` ps aux|grep ferret root 38127 0.0 0.4 732812 18112 ? Ssl 12:23 0:00 /usr/bin/ferretdb --debug-addr=127.0.0.1:8089 ``` Then we need to make a configuration change to allow PLAIN authentication because it's the only single supported authentication method by FerretDB: ``` echo '{"mongodb_auth_mechanism":"PLAIN"}' | sudo tee /etc/fastnetmon/fastnetmon.conf ``` Then try to running fcli and check connection to database: ``` sudo fcli show main ``` It will fail as we have no PostgreSQL database on this machine yet, and FerretDB will show a proper error about it: ``` 2023/03/24 17:14:11 We cannot establish connection with MongoDB: connection() error occurred during connection handshake: auth error: unable to authenticate using mechanism "PLAIN": (InternalError) [msg_saslstart.go:60 pg.(Handler).MsgSASLStart] [pg.go:130 pg.(Handler).DBPool] pgdb.NewPool: failed to connect to host=127.0.0.1 user=fastnetmon_user database=ferretdb: dial error (dial tcp 127.0.0.1:5432: connect: connection refused) Attempt number: 1 ``` Then we need to install PostgreSQL: ``` sudo apt install -y postgresql postgresql-contrib ``` Enable PostgreSQL launch on boot: ``` sudo systemctl enable postgresql ``` Try starting the database: ``` sudo systemctl start postgresql ``` Then we can try connecting to the database again: ``` sudo fcli show main ``` We will see another error, which simply means that the username or password is wrong: ``` 2023/03/24 17:20:15 We cannot establish connection with MongoDB: connection() error occurred during connection handshake: auth error: unable to authenticate using mechanism "PLAIN": (InternalError) [msg_saslstart.go:60 pg.(Handler).MsgSASLStart] [pg.go:130 pg.(Handler).DBPool] pgdb.NewPool: failed to connect to host=127.0.0.1 user=fastnetmon_user database=ferretdb: failed SASL auth (FATAL: password authentication failed for user "fastnetmon_user" (SQLSTATE 28P01)) Attempt number: 1 ``` That's expected as we have not created password yet. We need to create a database user: ``` sudo -u postgres createuser fastnetmon_user --no-superuser --no-createdb --no-createrole ``` Get database password from FastNetMon configuration: ``` export PGPASSWORD=`sudo cat /etc/fastnetmon/keychain/.mongo_fastnetmon_password` ``` Then set a password for this user: ``` sudo -u postgres psql -c "ALTER USER fastnetmon_user PASSWORD '$PGPASSWORD';" ``` Create a database called ferretdb explicitly specifying locale as other locales may not be supported by FerretDB: ``` sudo -u postgres createdb ferretdb --locale=en_US.UTF-8 --template=template0 ``` Then you need to grant permission to create a schema in the database: ``` sudo -u postgres psql -c "GRANT CREATE ON DATABASE ferretdb TO fastnetmon_user;" ``` Then try connecting to the database ferretdb using the username and password we just created: ``` psql --username fastnetmon_user --host 127.0.0.1 ferretdb --command "select 1+1" ``` After that, you can try reading FastNetMon configuration from fcli: ``` sudo fcli show main ``` It's expected to see errors such as: ``` Command returned error: Could not retrieve main configuration from database mongo: no documents in result ``` Warning: The Next command will remove all data from the database. Then we need to try creating a new default FastNetMon configuration database: ``` sudo fcli create_configuration ``` Then check the content of the default configuration from fcli: ``` sudo fcli show main ``` After that, restart FastNetMon to apply changes: ``` sudo fcli commit ``` Check that FastNetMon is running correctly: ``` sudo fcli show license ``` If something does not work as expected, please reach our support and share /var/log/fastnetmon/fastnetmon, log with them. **Document Categories:** Maintenance operations --- ### [Clickhouse excessive disk usage with log tables](https://fastnetmon.com/docs-fnm-advanced/clickhouse-excessive-disk-usage-with-log-tables/) **Published:** September 28, 2023 **Author:** Pavel Odintsov **Content:** Old installations of FastNetMon (pre-2023) may consume an excessive amount of disk space as the old Clickhouse configuration had logic which logged every single query in a separate database. It may easily use tens of gigabytes of disk space. You may easily confirm that it's the root cause by running this query in clickhouse-client: ``` SELECT database, table, formatReadableSize(sum(bytes)) AS size FROM system.parts WHERE active GROUP BY database, table ORDER BY sum(bytes) DESC ``` An example affected instance may look like the following: ``` ┌─database───┬─table───────────────────┬─size───────┐ │ system │ trace_log │ 32.84 GiB │ │ system │ part_log │ 26.51 GiB │ │ system │ metric_log │ 2.83 GiB │ │ system │ asynchronous_metric_log │ 2.80 GiB │ │ fastnetmon │ host_metrics │ 664.83 MiB │ │ fastnetmon │ host_metrics_ipv6 │ 34.97 MiB │ │ fastnetmon │ total_metrics_ipv6 │ 6.87 MiB │ │ fastnetmon │ network_metrics_ipv6 │ 5.14 MiB │ │ fastnetmon │ asn_metrics_ipv4 │ 4.31 MiB │ │ fastnetmon │ network_metrics │ 4.13 MiB │ │ fastnetmon │ asn_metrics_ipv6 │ 3.18 MiB │ │ fastnetmon │ total_metrics │ 2.60 MiB │ │ system │ query_log │ 13.95 KiB │ │ system │ crash_log │ 2.14 KiB │ ``` You may notice that tables with names trace\_log, part\_log, metric\_log, asynchronous\_metric\_log use a lot of disk space, and they can be removed. To disable such excessive logging, create a file /etc/clickhouse-server/users.d/disable\_logging.xml with the following content: ``` 0 0 ``` Then you need to create another file /etc/clickhouse-server/config.d/z\_completely\_disable\_logging.xml with a few more options to disable logging: ``` ``` And lest one /etc/clickhouse-server/config.d/disable\_verbose\_file\_logging.xml with the following content: ``` warning ``` After that, please restart Clickhouse to apply changes: ``` sudo systemctl restart clickhouse-server ``` Finally, you can open clickhouse-client, switch to the system database that way: ``` use system; ``` And then drop these log tables manually one by one: ``` drop table system.trace_log; drop table system.part_log; drop table system.metric_log; drop table system.asynchronous_metric_log; ``` Clickhouse may need around ten minutes to remove data from disk, and after that, you will see that the disk space has been freed. To automate this task, you can usea special command from our installer: ``` wget https://install.fastnetmon.com/installer -Oinstaller sudo chmod +x installer sudo ./installer -configure_clickhouse_logging ``` **Document Categories:** Maintenance operations --- ### [FastNetMon Advanced segmentation fault](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-segmentation-fault/) **Published:** November 7, 2023 **Author:** Pavel Odintsov **Content:** If you observe FastNetMon Advanced suddenly stopping to work without any error messages in /var/log/fastnetmon/fastnetmon.log, it may be a crash due to a segmentation fault (segfault) error type. You can confirm it by running this command: ``` sudo dmesg ``` And then checking the output for records like this: ``` Jul 18 17:21:41 monitor kernel: fastnetmon[30157]: segfault at 0 ip 0000000000445d2f sp 00007f832d861270 error 4 in fastnetmon[400000+90000] ``` It means some traffic or event caused FastNetMon to execute an incorrect memory operation. In some cases, you may see records like this in /var/log/fastnetmon/fastnetmon.log: ``` [ERROR] Previous run crashed, you can find stack trace below [ERROR] 0# 0x00000000004831CE in /opt/fastnetmon/app/bin/fastnetmon 1# 0x00007FBF95594F10 2# 0x00007FBF9C36C817 3# 0x00007FBF95594F10 4# 0x000000000064F03D in /opt/fastnetmon/app/bin/fastnetmon 5# 0x000000000065D09E in /opt/fastnetmon/app/bin/fastnetmon 6# 0x000000000084519C in /opt/fastnetmon/app/bin/fastnetmon 7# 0x000000000084A48F in /opt/fastnetmon/app/bin/fastnetmon 8# 0x000000000084A8BF in /opt/fastnetmon/app/bin/fastnetmon 9# 0x000000000084B3D5 in /opt/fastnetmon/app/bin/fastnetmon 10# 0x000000000084BD13 in /opt/fastnetmon/app/bin/fastnetmon 11# 0x00007FBF9C582095 12# 0x00007FBF9C3616DB 13# 0x00007FBF9567761F ``` Such entries confirm the segfault error type as well. In such cases, FastNetMon was able to intercept the error and save basic information, which may help in investigating it. In addition to writing such information, FastNetMon installer enables process memory core dumps, and they can be found in the folder /var/log/core\_dumps. They have a name in the format core.\*.\*. You can use them to find out more information about a particular crash: ``` sudo gdb /opt/fastnetmon/app/bin/fastnetmon /var/log/core_dumps/core.... ``` After it finishes loading, it will open an interactive command line console, and then you need to run the following command followed by Enter: ``` bt ``` It will show a long list of entries, and you need to share it with our support team. We will be able to review the source code, find out the root cause and address it. **Document Categories:** Maintenance operations --- ### [FastNetMon Advanced migration from MongoDB to FerretDB](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-migration-from-mongodb-to-ferretdb/) **Published:** May 29, 2024 **Author:** Pavel Odintsov **Content:** In addition to MongoDB, FastNetMon Advanced has complete support for FerretDB, which has the following advantages over MongoDB: - Easy upgrade (no need to upgrade to intermediate major versions) - Easy maintenance (just a single binary) - Truly free Apache 2 open source license instead of proprietary SSPL - Transparent and community-focused development model To migrate the existing installation from MongoDB to FerretDB, you need to export FastNetMon configuration using the configuration export/import capability. This option is supported by FastNetMon starting from 2.0.182, and if you run an older version, you will need to [upgrade](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-upgrade-procedure/) at least to 2.0.182. After that, please make a full configuration backup: ``` sudo fcli export_configuration fastnetmon_backup_to_ferretdb_migration.tar ``` Then you need to stop MongoDB and disable automatic start for it: ``` sudo systemctl stop mongod.service sudo systemctl disable mongod.service ``` Then install FerretDB: ``` wget https://install.fastnetmon.com/installer -Oinstaller sudo chmod +x installer sudo ./installer -ferretdb_only ``` Then check that FerretDB is running: ``` sudo netstat -lnpt|grep ferret tcp6 0 0 ::1:27017 :::* LISTEN 5232/ferretdb tcp6 0 0 ::1:8089 :::* LISTEN 5232/ferretdb ``` After this, you will need to upgrade FastNetMon to the latest version, which has native support for FerretDB, as older versions will not work with it. After finishing the upgrade, check that fcli can reach FerretDB: ``` sudo fcli show main enable_ban false ``` And then check that the FastNetMon daemon is working correctly with standard configuration: ``` sudo fcli commit ``` Then, wait ~60 seconds and check the following command to confirm that the FastNetMon daemon is running correctly: ``` sudo fcli show license Production license for 10000 mbits valid until 2024-06-12 ``` After that, remove the default configuration created by the FerretDB installer: ``` sudo fcli create_configuration sudo fcli delete hostgroup global ``` And import previously saved configuration from MongoDB: ``` sudo fcli import_configuration fastnetmon_backup_to_ferretdb_migration.tar ``` And apply the configuration: ``` sudo fcli commit ``` After that, we recommend doing a DDoS drill to ensure everything is working correctly after migration. **Document Categories:** Maintenance operations --- ### [Hostgroup Traffic profile capability](https://fastnetmon.com/docs-fnm-advanced/hostgroup-traffic-profile-capability/) **Published:** September 5, 2024 **Author:** Pavel Odintsov **Content:** Please note that this capability is part of a partner-only integration feature set, and we strongly advise against using it unless you have discussed it with our engineering team. This logic **can** be **changed** or **removed** without any further notice, and it is not a part of FastNetMon's backward **compatibility** guarantee. To enable per-hostgroup traffic profile collection logic, you will need to enable these configuration options: ``` sudo fcli set main generate_hostgroup_traffic_samples true sudo fcli set main generate_hostgroup_traffic_samples_delay 60 sudo fcli commit ``` After that, FastNetMon will calculate the amount of traffic with drop-down by type of traffic for each per\_host hostgroup you have in configuration and will store them to MongoDB in the collection: hostgroup\_traffic\_stats. It will do it every generate\_hostgroup\_traffic\_samples\_delay seconds. FastNetMon exports the amount of transferred traffic using the following fields: - source\_ip - destination\_ip - protocol - ttl - packet\_length - tcp\_flags - source\_port - destination\_port - source\_country - destination\_country - source\_asn - destination\_asn - source\_interface - destination\_interface - device\_address Please note that this capability depends on a correctly configured traffic buffer, and if you forget to configure it, you will see the following error in /var/log/fastnetmon/fastnetmon.log ``` Please enable traffic buffer to generate hostgroup traffic profiles ``` To get them in [MongoDB](https://fastnetmon.com/docs-fnm-advanced/mongodb-integration-with-fastnetmon-advanced/) you can use the following query: ``` db.hostgroup_traffic_stats.find({}) ``` Example report looks this way: ``` [ { _id: ObjectId('66d9d598dc1c421e770e3426'), fields: [ { bytes: 5760183, ordered_by: 'packets', packets: 39064, source_ip: '1.2.3.4' }, .... { bytes: 44638204, elements: 1984, packets: 118284, source_ip: 'total' }, ... { bytes: 15005, destination_ip: '2.3.4.5', ordered_by: 'bytes', packets: 44 }, { bytes: 44638204, destination_ip: 'total', elements: 1449, packets: 118284 }, { bytes: 25518912, ordered_by: 'packets', packets: 87422, protocol: '6' }, { bytes: 18890272, ordered_by: 'packets', packets: 27083, protocol: '17' }, { bytes: 218682, ordered_by: 'packets', packets: 3712, protocol: '1' }, { bytes: 4600, ordered_by: 'packets', packets: 37, protocol: '50' }, { bytes: 5738, ordered_by: 'packets', packets: 30, protocol: '47' }, { bytes: 25518912, ordered_by: 'bytes', packets: 87422, protocol: '6' }, { bytes: 18890272, ordered_by: 'bytes', packets: 27083, protocol: '17' }, { bytes: 218682, ordered_by: 'bytes', packets: 3712, protocol: '1' }, { bytes: 5738, ordered_by: 'bytes', packets: 30, protocol: '47' }, { bytes: 4600, ordered_by: 'bytes', packets: 37, protocol: '50' }, { bytes: 44638204, elements: 5, packets: 118284, protocol: 'total' }, { bytes: 44638204, ordered_by: 'packets', packets: 118284, ttl: '0' }, { bytes: 44638204, ordered_by: 'bytes', packets: 118284, ttl: '0' }, { bytes: 44638204, elements: 1, packets: 118284, ttl: 'total' }, { bytes: 43249862, ordered_by: 'packets', packet_length: 'jumbo_packets', packets: 103514 }, { bytes: 732127, ordered_by: 'packets', packet_length: '0_150', packets: 10097 }, { bytes: 224152, ordered_by: 'packets', packet_length: '151_300', packets: 1655 }, { bytes: 115167, ordered_by: 'packets', packet_length: '301_450', packets: 747 }, { bytes: 75581, ordered_by: 'packets', packet_length: '751_900', packets: 725 }, { bytes: 50099, ordered_by: 'packets', packet_length: '1051_1200', packets: 391 }, { bytes: 47632, ordered_by: 'packets', packet_length: '601_750', packets: 361 }, { bytes: 23177, ordered_by: 'packets', packet_length: '1201_1350', packets: 225 }, { bytes: 70347, ordered_by: 'packets', packet_length: '451_600', packets: 222 }, { bytes: 26153, ordered_by: 'packets', packet_length: '901_1050', packets: 212 }, { bytes: 23907, ordered_by: 'packets', packet_length: '1351_1500', packets: 135 }, { bytes: 43249862, ordered_by: 'bytes', packet_length: 'jumbo_packets', packets: 103514 }, { bytes: 732127, ordered_by: 'bytes', packet_length: '0_150', packets: 10097 }, { bytes: 224152, ordered_by: 'bytes', packet_length: '151_300', packets: 1655 }, { bytes: 115167, ordered_by: 'bytes', packet_length: '301_450', packets: 747 }, { bytes: 75581, ordered_by: 'bytes', packet_length: '751_900', packets: 725 }, { bytes: 70347, ordered_by: 'bytes', packet_length: '451_600', packets: 222 }, { bytes: 50099, ordered_by: 'bytes', packet_length: '1051_1200', packets: 391 }, { bytes: 47632, ordered_by: 'bytes', packet_length: '601_750', packets: 361 }, { bytes: 26153, ordered_by: 'bytes', packet_length: '901_1050', packets: 212 }, { bytes: 23907, ordered_by: 'bytes', packet_length: '1351_1500', packets: 135 }, { bytes: 23177, ordered_by: 'bytes', packet_length: '1201_1350', packets: 225 }, { bytes: 44638204, elements: 11, packet_length: 'total', packets: 118284 }, { bytes: 9807668, ordered_by: 'packets', packets: 35255, tcp_flags: 'psh,ack' }, { bytes: 10749258, ordered_by: 'packets', packets: 30799, tcp_flags: 'ack' }, { bytes: 1486870, ordered_by: 'packets', packets: 14286, tcp_flags: 'syn' }, { bytes: 3327593, ordered_by: 'packets', packets: 5086, tcp_flags: 'syn,ack' }, ... { bytes: 25518912, elements: 253, packets: 87422, tcp_flags: 'total' }, { bytes: 17114707, ordered_by: 'packets', packets: 34290, source_port: '8291' }, ... { bytes: 44409184, elements: 2703, packets: 114505, source_port: 'total' }, { bytes: 3937222, destination_port: '8291', ordered_by: 'packets', packets: 31008 }, ... { bytes: 44409184, destination_port: 'total', elements: 4317, packets: 114505 }, { bytes: 14869861, ordered_by: 'packets', packets: 49528, source_asn: '269872' }, { bytes: 44638204, elements: 252, packets: 118284, source_asn: 'total' }, { bytes: 29768343, destination_asn: '269872', ordered_by: 'packets', packets: 68756 }, ... { bytes: 44638204, destination_asn: 'total', elements: 174, packets: 118284 }, { bytes: 15505499, ordered_by: 'packets', packets: 33776, source_interface: '4.5.6.7:31' }, { bytes: 44638204, elements: 13, packets: 118284, source_interface: 'total' }, { bytes: 44638204, ordered_by: 'packets', packets: 118284, source_country: 'xx' }, { bytes: 44638204, ordered_by: 'bytes', packets: 118284, source_country: 'xx' }, { bytes: 44638204, elements: 1, packets: 118284, source_country: 'total' }, { bytes: 44638204, destination_country: 'xx', ordered_by: 'packets', packets: 118284 }, { bytes: 44638204, destination_country: 'xx', ordered_by: 'bytes', packets: 118284 }, { bytes: 44638204, destination_country: 'total', elements: 1, packets: 118284 }, { bytes: 220, destination_interface: '6.7.8.8:15811387', ordered_by: 'bytes', packets: 3 }, { bytes: 44638204, destination_interface: 'total', elements: 15, packets: 118284 }, { bytes: 44638204, device_address: '2.3.4.5', ordered_by: 'packets', packets: 118284 }, { bytes: 44638204, device_address: '3.4.5.6', ordered_by: 'bytes', packets: 118284 }, { bytes: 44638204, device_address: 'total', elements: 1, packets: 118284 } ], host_group: 'global', sample_end: '2024-09-05T16:00:23Z', sample_start: '2024-09-05T15:59:23Z' } ] ``` Please note that after listing 100 values elements for a particular field (for example, ASN): ``` { bytes: 29768343, destination_asn: '269872', ordered_by: 'packets', packets: 68756 }, ``` Each field is ordered by packets and bytes, and you can findthe sorting value this way in the section "ordered\_by": ``` { bytes: 44638204, device_address: '2.3.4.5', ordered_by: 'packets', packets: 118284 }, { bytes: 44638204, device_address: '3.4.5.6', ordered_by: 'bytes', packets: 118284 }, ``` We add a total field which carries the total amount of packets and bytes for this field: ``` { bytes: 44638204, destination_asn: 'total', elements: 174, packets: 118284 }, ``` To debug the performance of this capability, we have a dedicated system counter: ``` sudo fcli show system_counters|grep hostgroup_traffic_samples hostgroup_traffic_samples_calculation_time 0.000000 ``` After that, you will be able to request max talkers list via API. You can make a request to retrieve all records this way: ``` curl -X GET -u admin:password https://127.0.0.1:10007/hostgroup_traffic_samples ``` To retrieve records from a specific date, please use another query: ``` curl -X GET -u admin:password https://127.0.0.1:10007/hostgroup_traffic_samples/2022-02-01T00:58:40Z ``` FastNetMon has logic to remove these entries from MongoDB automatically every 15 minutes. Before version [2.0.347](https://github.com/FastNetMon/fastnetmon-advanced-releases/releases/tag/v2.0.347) we ran cleanup logic once per hour. If you run a query and the API responds with error 500 as follows: ``` [martini]2024/04/12 15:45:56 Completed GET /hostgroup_traffic_samples/2023-04-12T31:44:38Z 500 Internal Server Error in 7.135398ms [martini]2024/04/12 15:45:56 Show function returned error: We do not have any samples for your query ``` This means that for some reason FastNetMon was unable to calculate traffic profiles and store them in MongoDB. You will likely find details at /var/log/fastnetmon/fastnetmon.log. Please note that FastNetMon itself can calculate bandwidth for specific entities, such as ASNs, using its own real-time bandwidth calculation protocol, and such calculations cannot be compared to bandwidth calculated using data from hostgroup samples, as bandwidth calculated from the amount of transferred traffic is inaccurate by its own nature. ### Timeout issues with a large number of hostgroups In cases you have a large number of hostgroups (100+), you may face issues such as following: ``` curl -x GET -k -u admin:admin https://1.2.3.4/hostgroup_traffic_samples {"success":false, "error_text": "Could not retrieve configuration from database context deadline exceeded" ``` This error means that due to a very large amount of data in MongoDB, fcli cancels the query as it takes too long. To address this issue, you may consider increasing the timeout for heavy operations (it applies to hostgroups\_max\_talkers, hostgroup\_traffic\_stats, attack\_traffic\_stats) in /etc/fastnetmon/fastnetmon.conf: ``` { "mongodb_timeout_heavy": 95 } ``` After that, this issue will disappear. Please note that this flag was introduced in 2.0.363, and you need to upgrade to this version to use this capability. **Document Categories:** Maintenance operations --- ### [FastNetMon Advanced blackhole and Flow Spec persistence during restart](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-blackhole-during-restart/) **Published:** December 26, 2018 **Author:** Pavel Odintsov **Content:** By default, FastNetMon cleans up all blackhole or flow spec announces during restart/commit operation. But you can disable this behaviour and do not unblock blocked hosts during restart. Please note: This logic is known to cause issues with BGP announces when you do restarts of FastNetMon and BGP daemon at the same time (what happens during server reboot). It will cause missing announces as it does not re-announces previously blocked hosts to the BGP daemon. This logic is useful only if you do not use BGP at all. I.e. if you rely only on callback scripts. In this case, it will work fine. To enable this logic, you need to run the following commands: ``` sudo fcli set main keep_blocked_hosts_during_restart true sudo fcli set main do_not_withdraw_unicast_announces_on_restart true sudo fcli commit ``` FastNetMon can do the same for BGP Flow Spec announces, and you can enable such logic this way: ``` sudo fcli set main do_not_withdraw_flow_spec_announces_on_restart true sudo fcli set main keep_flow_spec_announces_during_restart true sudo fcli commit ``` After these changes, FastNetMon will store / load blackhole list or Flow Spec ban list during commit/restart operation. Flags do\_not\_withdraw\_unicast\_announces\_on\_restart and do\_not\_withdraw\_flow\_spec\_announces\_on\_restart disable automatic BGP clean up after restart, and BGP daemon will keep announces until FastNetMon removes it. Starting from version 2.0.357, FastNetMon can store/load blocked hostgroups to/from persistent storage too: ``` sudo fcli set main keep_blocked_hostgroups_during_restart true sudo fcli commit ``` **Document Categories:** Maintenance operations --- ### [Flexible counters for traffic calculation](https://fastnetmon.com/docs-fnm-advanced/flexible-counters-for-traffic-calculation/) **Published:** May 25, 2019 **Author:** Pavel Odintsov **Content:** FastNetMon Advanced uses flexible counters which are dynamically allocated and can handle an extremely large number of monitored hosts in networks. For debugging purposes, you can check number of counters allocated for hosts in your network this way: ``` sudo fcli show system_counters|grep hosts_hash_size ``` On modern hardware, FastNetMon Advanced can track up to 1m of active hosts, which reflects the size of multi-terabit network. To maintain a high level of performance in environments with a very large number of monitored hosts, we have cleanup logic which removes tracking entries for hosts which do not generate or receive any traffic for a long period of time. This logic is enabled by default for all new installations. On an existing installation, you can enable it manually in the following way: ``` sudo fcli set main ipv4_automatic_data_cleanup enable sudo fcli set main ipv4_automatic_data_cleanup_threshold 300 sudo fcli set main ipv4_automatic_data_cleanup_delay 300 sudo fcli set main ipv6_automatic_data_cleanup enable sudo fcli set main ipv6_automatic_data_cleanup_threshold 300 sudo fcli set main ipv6_automatic_data_cleanup_delay 300 sudo fcli commit ``` Value ipvX\_automatic\_data\_cleanup\_threshold controls the period of time in seconds for which a host has had no traffic. ipvX\_automatic\_data\_cleanup\_delay controls how often we run cleanup logic. The cleanup operation is quite expensive and blocks the whole speed tracking structure. We do not recommend running it very often. **Document Categories:** Maintenance operations --- ### [Extending disk space for FastNetMon VM installs](https://fastnetmon.com/docs-fnm-advanced/extending-disk-space-for-fastnetmon-vm-installs/) **Published:** December 12, 2019 **Author:** Pavel Odintsov **Content:** To extend default disk space size for FastNetMon installs on VM you need to extend disk space from hypervisor size and reboot virtual machine. First step to run parted to update total disk space size. parted will ask you about fixing GPT table, please accept it and answer with "Fix". ``` sudo parted GNU Parted 3.2 Using /dev/sda (parted) print Warning: Not all of the space available to /dev/sda appears to be used, you can fix the GPT to use all of the space (an extra 167772160 blocks) or continue with the current setting? Fix/Ignore? Fix ``` As next step, please increase size of underlying partition used my LVM: ``` sudo parted GNU Parted 3.2 Using /dev/sda Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) print Model: VMware Virtual disk (scsi) Disk /dev/sda: 107GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 1049kB 2097kB 1049kB bios_grub 2 2097kB 1076MB 1074MB ext4 3 1076MB 21.5GB 20.4GB (parted) resizepart 3 100% ``` After finishing this step we will have 100G partition: ``` sudo parted (parted) print Model: VMware Virtual disk (scsi) Disk /dev/sda: 107GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 1049kB 2097kB 1049kB bios_grub 2 2097kB 1076MB 1074MB ext4 3 1076MB 107GB 106GB ``` Next step will be extension of LVM physical volume: ``` sudo pvresize /dev/sda3 Physical volume "/dev/sda3" changed 1 physical volume(s) resized / 0 physical volume(s) not resized ``` ``` sudo pvs PV VG Fmt Attr PSize PFree /dev/sda3 ubuntu-vg lvm2 a-- <99.00g 80.00g ``` Finally, extend LVM volume used for / partition to maximum size: ``` sudo lvresize -l +100%FREE /dev/mapper/ubuntu--vg-ubuntu--lv Size of logical volume ubuntu-vg/ubuntu-lv changed from 89.19 GiB (22833 extents) to <99.00 GiB (25343 extents). Logical volume ubuntu-vg/ubuntu-lv successfully resized. ``` Extend root filesystem: ``` sudo resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv resize2fs 1.44.1 (24-Mar-2018) Filesystem at /dev/mapper/ubuntu--vg-ubuntu--lv is mounted on /; on-line resizing required old_desc_blocks = 3, new_desc_blocks = 13 The filesystem on /dev/mapper/ubuntu--vg-ubuntu--lv is now 25951232 (4k) blocks long. ``` After finishing process, please reboot virtual machine. **Document Categories:** Maintenance operations --- ### [FastNetMon backup / restore](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-backup-restore/) **Published:** January 30, 2020 **Author:** Pavel Odintsov **Content:** To export the configuration, please use: ``` sudo fcli export_configuration fastnetmon_backup.tar ``` To import, use the following process. First, create a new configuration using the following command (Note: it will **remove** all configuration): ``` sudo fcli create_configuration ``` Remove global hostgroup: ``` sudo fcli delete hostgroup global ``` Import configuration backup: ``` sudo fcli import_configuration fastnetmon_backup.tar ``` Please note that starting from 2.0.375 we added new logic which creates backup of all collections before proceeding with import. You can find backup collections with suffix "backup" in MongoDB ``` fastnetmon> show collections configuration configuration_backup_2026_03_14_14_59_34 hostgroups_configuration hostgroups_configuration_backup_2026_03_14_14_59_34 ``` **Document Categories:** Maintenance operations --- ### [Monitoring FastNetMon via Prometheus](https://fastnetmon.com/docs-fnm-advanced/monitoring-fastnetmon-via-prometheus/) **Published:** May 5, 2020 **Author:** Pavel Odintsov **Content:** FastNetMon has complete support for Prometheus-based monitoring. It can be enabled this way (please do not use 0.0.0.0 for production setups and use private ranges for security reasons): ``` sudo fcli set main prometheus enable sudo fcli set main prometheus_host 0.0.0.0 sudo fcli set main prometheus_port 9209 sudo fcli commit ``` After that, you will be able to access metrics via the standard Prometheus interface from https://127.0.0.1:9209/metrics FastNetMon exports the following types of metrics to the Prometheus endpoint: - Total traffic for IPv4 and IPv6 - Per network traffic (enabled by default but can be disabled) - Per host traffic for IPv4 and IPv6 (disabled by default). To enable per-network metrics, you need to apply the following configuration changes: ``` sudo fcli set main prometheus_export_network_ipv4_counters true sudo fcli set main prometheus_export_network_ipv6_counters true sudo fcli commit ``` To enable per-host metrics, you need to apply the following configuration changes: ``` sudo fcli set main prometheus_export_host_ipv4_counters true sudo fcli set main prometheus_export_host_ipv6_counters true sudo fcli commit ``` FastNetMon exports all metrics available using sudo fcli show system\_counters command. Example: ``` # HELP Total number of simple packets processed # TYPE fastnetmon_total_simple_packets_processed counter fastnetmon_total_simple_packets_processed 209 # HELP Total number of IPv4 simple packets processed # TYPE fastnetmon_total_ipv4_packets counter fastnetmon_total_ipv4_packets 209 # HELP Total number of IPv6 simple packets processed # TYPE fastnetmon_total_ipv6_packets counter fastnetmon_total_ipv6_packets 0 # HELP Non IPv4 and non IPv6 packets # TYPE fastnetmon_unknown_ip_version_packets counter fastnetmon_unknown_ip_version_packets 0 # HELP Total number of packets we failed to parse # TYPE fastnetmon_total_unparsed_packets counter fastnetmon_total_unparsed_packets 0 # HELP Number of packets we fail to parse per second # TYPE fastnetmon_total_unparsed_packets_speed gauge fastnetmon_total_unparsed_packets_speed 0 # HELP Number of packets filtered with remote whitelist option # TYPE fastnetmon_total_remote_whitelisted_packets_packets counter fastnetmon_total_remote_whitelisted_packets_packets 0 # HELP Number of packets filtered by flow spec engine # TYPE fastnetmon_total_flowspec_filtered_packets counter fastnetmon_total_flowspec_filtered_packets 0 # HELP Number of bytes filtered by flow spec engine # TYPE fastnetmon_total_flowspec_filtered_bytes counter fastnetmon_total_flowspec_filtered_bytes 0 # HELP Number of packets white listed by flowspec whitelist # TYPE fastnetmon_total_flowspec_whitelist_packets counter fastnetmon_total_flowspec_whitelist_packets 0 # HELP Number of errors related with traffic db # TYPE fastnetmon_traffic_db_errors counter fastnetmon_traffic_db_errors 0 # HELP Number of messages pushed to traffic db # TYPE fastnetmon_traffic_db_pushed_messages counter fastnetmon_traffic_db_pushed_messages 209 # HELP Number of packets seen by sampler code # TYPE fastnetmon_traffic_db_sampler_seen_packets counter fastnetmon_traffic_db_sampler_seen_packets 0 # HELP Number of packets selected by sampler, only for mirror code # TYPE fastnetmon_traffic_db_sampler_selected_packets counter fastnetmon_traffic_db_sampler_selected_packets 0 # HELP Time consumed by recalculation for all IPs # TYPE fastnetmon_speed_recalculation_time_seconds gauge fastnetmon_speed_recalculation_time_seconds 0 # HELP Time consumed by recalculation for all IPs # TYPE fastnetmon_speed_recalculation_time_microseconds gauge fastnetmon_speed_recalculation_time_microseconds 0 # HELP Traffic calculation delay was shorter than we expected # TYPE fastnetmon_all_traffic_calculation_delay_shorter counter fastnetmon_all_traffic_calculation_delay_shorter 0 # HELP Traffic calculation delay was negative # TYPE fastnetmon_all_traffic_calculation_delay_negative counter fastnetmon_all_traffic_calculation_delay_negative 0 # HELP Traffic calculation delay longer then we expected # TYPE fastnetmon_all_traffic_calculation_delay_longer counter fastnetmon_all_traffic_calculation_delay_longer 0 # HELP Total number of hosts in our networks # TYPE fastnetmon_total_number_of_hosts gauge fastnetmon_total_number_of_hosts 1024 # HELP IPv4 hosts hash load factor integer # TYPE fastnetmon_hosts_hash_load_factor_integer gauge fastnetmon_hosts_hash_load_factor_integer 0 # HELP IPv4 hosts hash load factor fraction # TYPE fastnetmon_hosts_hash_load_factor_fraction gauge fastnetmon_hosts_hash_load_factor_fraction 0 # HELP IPv4 hosts hash size # TYPE fastnetmon_hosts_hash_size gauge fastnetmon_hosts_hash_size 0 # HELP IPv4 hosts hash buckets number # TYPE fastnetmon_hosts_hash_bucket_count gauge fastnetmon_hosts_hash_bucket_count 0 # HELP IPv6 hosts hash load factor integer # TYPE fastnetmon_hosts_hash_load_factor_ipv6_integer gauge fastnetmon_hosts_hash_load_factor_ipv6_integer 0 # HELP IPv6 hosts hash load factor fraction # TYPE fastnetmon_hosts_hash_load_factor_ipv6_fraction gauge fastnetmon_hosts_hash_load_factor_ipv6_fraction 0 # HELP IPv6 hosts hash size # TYPE fastnetmon_hosts_hash_size_ipv6 gauge fastnetmon_hosts_hash_size_ipv6 0 # HELP IPv6 hosts hash buckets number # TYPE fastnetmon_hosts_hash_ipv6_bucket_count gauge fastnetmon_hosts_hash_ipv6_bucket_count 0 # HELP Total number of InfluxDB writes # TYPE fastnetmon_influxdb_writes_total counter fastnetmon_influxdb_writes_total 0 # HELP Total number of failed InfluxDB writes # TYPE fastnetmon_influxdb_writes_failed counter fastnetmon_influxdb_writes_failed 0 # HELP Total number of Clickhouse writes # TYPE fastnetmon_clickhouse_metrics_writes_total counter fastnetmon_clickhouse_metrics_writes_total 0 # HELP Total number of failed Clickhouse writes # TYPE fastnetmon_clickhouse_metrics_writes_failed counter fastnetmon_clickhouse_metrics_writes_failed 0 # HELP Number of IPFIX and Netflow per second # TYPE fastnetmon_netflow_all_protocols_total_flows_speed gauge fastnetmon_netflow_all_protocols_total_flows_speed 0 # HELP Number of sFlow headers per second # TYPE fastnetmon_sflow_raw_packet_headers_total_speed gauge fastnetmon_sflow_raw_packet_headers_total_speed 0 # HELP Number of entries in flow tracking structure # TYPE fastnetmon_entries_flow_tracking gauge fastnetmon_entries_flow_tracking 0 # HELP Number of IPs with flow information # TYPE fastnetmon_flow_exists_for_ip gauge fastnetmon_flow_exists_for_ip 0 # HELP Number of IPs without flow information # TYPE fastnetmon_flow_does_not_exist_for_ip gauge fastnetmon_flow_does_not_exist_for_ip 0 # HELP Traffic buffer for IPv4 maximum duration in seconds # TYPE fastnetmon_traffic_buffer_duration_seconds_ipv4 gauge fastnetmon_traffic_buffer_duration_seconds_ipv4 0 # HELP Traffic buffer for IPv6 maximum duration in seconds # TYPE fastnetmon_traffic_buffer_duration_seconds_ipv6 gauge fastnetmon_traffic_buffer_duration_seconds_ipv6 0 # HELP Number of IPv4 packets matched by flexible thresholds # TYPE fastnetmon_total_flexible_thresholds_matched_bytes_ipv4 counter fastnetmon_total_flexible_thresholds_matched_bytes_ipv4 0 # HELP Number of IPv4 bytes matched by flexible thresholds # TYPE fastnetmon_total_flexible_thresholds_matched_packets_ipv4 counter fastnetmon_total_flexible_thresholds_matched_packets_ipv4 0 # HELP Number of IPv6 bytes matched by flexible thresholds # TYPE fastnetmon_total_flexible_thresholds_matched_bytes_ipv6 counter fastnetmon_total_flexible_thresholds_matched_bytes_ipv6 0 # HELP Number of IPv6 packets matched by flexible thresholds # TYPE fastnetmon_total_flexible_thresholds_matched_packets_ipv6 counter fastnetmon_total_flexible_thresholds_matched_packets_ipv6 0 # HELP Total number of Netflow v5 UDP packets received # TYPE fastnetmon_netflow_v5_total_packets counter fastnetmon_netflow_v5_total_packets 0 # HELP Total number of Netflow v5 flows (multiple in each packet) # TYPE fastnetmon_netflow_v5_total_flows counter fastnetmon_netflow_v5_total_flows 0 # HELP Netflow v5 flows with duration less then 15 seconds # TYPE fastnetmon_netflow_v5_duration_less_15_seconds counter fastnetmon_netflow_v5_duration_less_15_seconds 0 # HELP Netflow v5 flows with duration less then 30 seconds # TYPE fastnetmon_netflow_v5_duration_less_30_seconds counter fastnetmon_netflow_v5_duration_less_30_seconds 0 # HELP Netflow v5 flows with duration less then 60 seconds # TYPE fastnetmon_netflow_v5_duration_less_60_seconds counter fastnetmon_netflow_v5_duration_less_60_seconds 0 # HELP Netflow v5 flows with duration less then 90 seconds # TYPE fastnetmon_netflow_v5_duration_less_90_seconds counter fastnetmon_netflow_v5_duration_less_90_seconds 0 # HELP Netflow v5 flows with duration less then 180 seconds # TYPE fastnetmon_netflow_v5_duration_less_180_seconds counter fastnetmon_netflow_v5_duration_less_180_seconds 0 # HELP Netflow v5 flows with duration more then 180 seconds # TYPE fastnetmon_netflow_v5_duration_exceed_180_seconds counter fastnetmon_netflow_v5_duration_exceed_180_seconds 0 # HELP Total number of Netflow v5 UDP packets received # TYPE fastnetmon_netflow_v9_total_packets counter fastnetmon_netflow_v9_total_packets 11 # HELP Total number of Netflow v9 flows (multiple in each packet) # TYPE fastnetmon_netflow_v9_total_flows counter fastnetmon_netflow_v9_total_flows 209 # HELP Total number of Netflow v9 IPv4 flows (multiple in each packet) # TYPE fastnetmon_netflow_v9_total_ipv4_flows counter fastnetmon_netflow_v9_total_ipv4_flows 209 # HELP Total number of Netflow v9 IPv6 flows (multiple in each packet) # TYPE fastnetmon_netflow_v9_total_ipv6_flows counter fastnetmon_netflow_v9_total_ipv6_flows 0 # HELP Netflow v9 flows with duration less then 15 seconds # TYPE fastnetmon_netflow_v9_duration_less_15_seconds counter fastnetmon_netflow_v9_duration_less_15_seconds 209 # HELP Netflow v9 flows with duration less then 30 seconds # TYPE fastnetmon_netflow_v9_duration_less_30_seconds counter fastnetmon_netflow_v9_duration_less_30_seconds 0 # HELP Netflow v9 flows with duration less then 60 seconds # TYPE fastnetmon_netflow_v9_duration_less_60_seconds counter fastnetmon_netflow_v9_duration_less_60_seconds 0 # HELP Netflow v9 flows with duration less then 90 seconds # TYPE fastnetmon_netflow_v9_duration_less_90_seconds counter fastnetmon_netflow_v9_duration_less_90_seconds 0 # HELP Netflow v9 flows with duration less then 180 seconds # TYPE fastnetmon_netflow_v9_duration_less_180_seconds counter fastnetmon_netflow_v9_duration_less_180_seconds 0 # HELP Netflow v9 flows with duration more then 180 seconds # TYPE fastnetmon_netflow_v9_duration_exceed_180_seconds counter fastnetmon_netflow_v9_duration_exceed_180_seconds 0 # HELP Number of Netflow v9 data packets # TYPE fastnetmon_netflow_v9_data_packet_number counter fastnetmon_netflow_v9_data_packet_number 11 # HELP Number of Netflow v9 data template packets # TYPE fastnetmon_netflow_v9_data_templates_number counter fastnetmon_netflow_v9_data_templates_number 0 # HELP Number of Netflow v9 options templates packets # TYPE fastnetmon_netflow_v9_options_templates_number counter fastnetmon_netflow_v9_options_templates_number 0 # HELP Number of Netflow v9 options data packets # TYPE fastnetmon_netflow_v9_options_packet_number counter fastnetmon_netflow_v9_options_packet_number 0 # HELP Number of dropped Netflow v9 packets due to unknown template in message # TYPE fastnetmon_netflow_v9_packets_with_unknown_templates counter fastnetmon_netflow_v9_packets_with_unknown_templates 0 # HELP Number of times we received sampling rate from Netflow v9 agent # TYPE fastnetmon_netflow_v9_custom_sampling_rate_received counter fastnetmon_netflow_v9_custom_sampling_rate_received 0 # HELP How much times we changed sampling rate for same agent. As change we also count when we received it for the first time # TYPE fastnetmon_netflow_v9_sampling_rate_changes counter fastnetmon_netflow_v9_sampling_rate_changes 0 # HELP Number of Netflow v9 flows with re-classified protocol version # TYPE fastnetmon_netflow_v9_protocol_version_adjustments counter fastnetmon_netflow_v9_protocol_version_adjustments 0 # HELP Count times when template data actually changed for Netflow v9 # TYPE fastnetmon_netflow_v9_template_updates_number_due_to_real_changes counter fastnetmon_netflow_v9_template_updates_number_due_to_real_changes 0 # HELP We increment these counters when field we use to store particular type of Netflow v9 record is smaller than we actually received from device # TYPE fastnetmon_netflow_v9_too_large_field counter fastnetmon_netflow_v9_too_large_field 0 # HELP Total number of headers in Netflow v9 lite received # TYPE fastnetmon_netflow_v9_lite_headers counter fastnetmon_netflow_v9_lite_headers 0 # HELP Number of Netflow v9 flows with forwarding status provided # TYPE fastnetmon_netflow_v9_forwarding_status counter fastnetmon_netflow_v9_forwarding_status 0 # HELP Netflow v9 Lite header parser errors # TYPE fastnetmon_netflow_v9_lite_header_parser_error counter fastnetmon_netflow_v9_lite_header_parser_error 0 # HELP Netflow v9 packets we cannot decode # TYPE fastnetmon_netflow_v9_broken_packets counter fastnetmon_netflow_v9_broken_packets 0 # HELP Total number of received active Netflow v9 flow timeouts # TYPE fastnetmon_netflow_v9_active_flow_timeout_received counter fastnetmon_netflow_v9_active_flow_timeout_received 0 # HELP Total number of received inactive Netflow v9 flow timeouts # TYPE fastnetmon_netflow_v9_inactive_flow_timeout_received counter fastnetmon_netflow_v9_inactive_flow_timeout_received 0 # HELP Netflow v9 flow was marked as dropped from interface and next hop information # TYPE fastnetmon_netflow_v9_marked_zero_next_hop_and_zero_output_as_dropped counter fastnetmon_netflow_v9_marked_zero_next_hop_and_zero_output_as_dropped 0 # HELP Total number of IPFIX flows (multiple in each packet) # TYPE fastnetmon_ipfix_total_flows counter fastnetmon_ipfix_total_flows 0 # HELP Total number of IPFIX UDP packets received # TYPE fastnetmon_ipfix_total_packets counter fastnetmon_ipfix_total_packets 0 # HELP Total number of IPFIX IPv4 flows (multiple in each packet) # TYPE fastnetmon_ipfix_total_ipv4_flows counter fastnetmon_ipfix_total_ipv4_flows 0 # HELP Total number of IPFIX IPv6 flows (multiple in each packet) # TYPE fastnetmon_ipfix_total_ipv6_flows counter fastnetmon_ipfix_total_ipv6_flows 0 # HELP IPFIX flows with duration less then 15 seconds # TYPE fastnetmon_ipfix_duration_less_15_seconds counter fastnetmon_ipfix_duration_less_15_seconds 0 # HELP IPFIX flows with duration less then 30 seconds # TYPE fastnetmon_ipfix_duration_less_30_seconds counter fastnetmon_ipfix_duration_less_30_seconds 0 # HELP IPFIX flows with duration less then 60 seconds # TYPE fastnetmon_ipfix_duration_less_60_seconds counter fastnetmon_ipfix_duration_less_60_seconds 0 # HELP IPFIX flows with duration less then 90 seconds # TYPE fastnetmon_ipfix_duration_less_90_seconds counter fastnetmon_ipfix_duration_less_90_seconds 0 # HELP IPFIX flows with duration less then 180 seconds # TYPE fastnetmon_ipfix_duration_less_180_seconds counter fastnetmon_ipfix_duration_less_180_seconds 0 # HELP IPFIX flows with duration more then 180 seconds # TYPE fastnetmon_ipfix_duration_exceed_180_seconds counter fastnetmon_ipfix_duration_exceed_180_seconds 0 # HELP IPFIX packets with negative duration, it may happen when vendor does not implement protocol correctly # TYPE fastnetmon_ipfix_duration_negative counter fastnetmon_ipfix_duration_negative 0 # HELP IPFIX flows finished by idle timeout # TYPE fastnetmon_ipfix_flows_end_reason_idle_timeout counter fastnetmon_ipfix_flows_end_reason_idle_timeout 0 # HELP IPFIX flows finished by active timeout # TYPE fastnetmon_ipfix_flows_end_reason_active_timeout counter fastnetmon_ipfix_flows_end_reason_active_timeout 0 # HELP IPFIX flows finished by end of flow timeout # TYPE fastnetmon_ipfix_flows_end_reason_end_of_flow_timeout counter fastnetmon_ipfix_flows_end_reason_end_of_flow_timeout 0 # HELP IPFIX flows finished by force end timeout # TYPE fastnetmon_ipfix_flows_end_reason_force_end_timeout counter fastnetmon_ipfix_flows_end_reason_force_end_timeout 0 # HELP IPFIX flows finished by lack of resources # TYPE fastnetmon_ipfix_flows_end_reason_lack_of_resource_timeout counter fastnetmon_ipfix_flows_end_reason_lack_of_resource_timeout 0 # HELP IPFIX data packets number # TYPE fastnetmon_ipfix_data_packet_number counter fastnetmon_ipfix_data_packet_number 0 # HELP IPFIX data templates number # TYPE fastnetmon_ipfix_data_templates_number counter fastnetmon_ipfix_data_templates_number 0 # HELP IPFIX options templates number # TYPE fastnetmon_ipfix_options_templates_number counter fastnetmon_ipfix_options_templates_number 0 # HELP IPFIX options data packets number # TYPE fastnetmon_ipfix_options_packet_number counter fastnetmon_ipfix_options_packet_number 0 # HELP Number of dropped IPFIX packets due to unknown template in message # TYPE fastnetmon_ipfix_packets_with_unknown_templates counter fastnetmon_ipfix_packets_with_unknown_templates 0 # HELP IPFIX customer sampling rates received # TYPE fastnetmon_ipfix_custom_sampling_rate_received counter fastnetmon_ipfix_custom_sampling_rate_received 0 # HELP How much times we changed sampling rate for same agent. As change we also count when we received it for the first time # TYPE fastnetmon_ipfix_sampling_rate_changes counter fastnetmon_ipfix_sampling_rate_changes 0 # HELP IPFIX flow was marked as dropped from interface and next hop information # TYPE fastnetmon_ipfix_marked_zero_next_hop_and_zero_output_as_dropped counter fastnetmon_ipfix_marked_zero_next_hop_and_zero_output_as_dropped 0 # HELP Count times when template data actually changed for IPFIX # TYPE fastnetmon_ipfix_template_updates_number_due_to_real_changes counter fastnetmon_ipfix_template_updates_number_due_to_real_changes 0 # HELP Total number of IPFIX packets with padding # TYPE fastnetmon_ipfix_packets_with_padding counter fastnetmon_ipfix_packets_with_padding 0 # HELP Total number of headers in IPFIX received # TYPE fastnetmon_ipfix_inline_headers counter fastnetmon_ipfix_inline_headers 0 # HELP Number of IPFIX flows with re-classified protocol version # TYPE fastnetmon_ipfix_protocol_version_adjustments counter fastnetmon_ipfix_protocol_version_adjustments 0 # HELP We increment these counters when field we use to store particular type of IPFIX record is smaller than we actually received from device # TYPE fastnetmon_ipfix_too_large_field counter fastnetmon_ipfix_too_large_field 0 # HELP Number of IPFIX flows with forwarding status provided # TYPE fastnetmon_ipfix_forwarding_status counter fastnetmon_ipfix_forwarding_status 0 # HELP IPFIX inline header parser errors # TYPE fastnetmon_ipfix_inline_header_parser_error counter fastnetmon_ipfix_inline_header_parser_error 0 # HELP Total number of received active IPFIX flow timeouts # TYPE fastnetmon_ipfix_active_flow_timeout_received counter fastnetmon_ipfix_active_flow_timeout_received 0 # HELP Total number of received inactive IPFIX flow timeouts # TYPE fastnetmon_ipfix_inactive_flow_timeout_received counter fastnetmon_ipfix_inactive_flow_timeout_received 0 # HELP Total number of Netflow or IPFIX UDP packets received # TYPE fastnetmon_netflow_ipfix_total_packets counter fastnetmon_netflow_ipfix_total_packets 11 # HELP Total number of flows summarized for all kinds of Netflow and IPFIX # TYPE fastnetmon_netflow_ipfix_all_protocols_total_flows counter fastnetmon_netflow_ipfix_all_protocols_total_flows 209 # HELP Number of UDP packets dropped by system on our socket # TYPE fastnetmon_netflow_ipfix_udp_packet_drops counter fastnetmon_netflow_ipfix_udp_packet_drops 0 # HELP Number of packets with unknown Netflow version. In may be sign that some another protocol like sFlow is being send to Netflow or IPFIX port # TYPE fastnetmon_netflow_ipfix_unknown_protocol_version counter fastnetmon_netflow_ipfix_unknown_protocol_version 0 # HELP Number of templates received with same data as inside known by us # TYPE fastnetmon_template_update_attempts_with_same_template_data counter fastnetmon_template_update_attempts_with_same_template_data 0 # HELP Number of flows which exceed specified limit in configuration # TYPE fastnetmon_netflow_ignored_long_flows counter fastnetmon_netflow_ignored_long_flows 0 # HELP Number of times when we write Netflow or ipfix templates to disk # TYPE fastnetmon_template_netflow_ipfix_disk_writes counter fastnetmon_template_netflow_ipfix_disk_writes 0 # HELP System UDP counter ignoredmulti # TYPE fastnetmon_global_system_ignoredmulti counter fastnetmon_global_system_ignoredmulti 0 # HELP System UDP counter incsumerrors # TYPE fastnetmon_global_system_incsumerrors counter fastnetmon_global_system_incsumerrors 0 # HELP System UDP counter indatagrams # TYPE fastnetmon_global_system_indatagrams counter fastnetmon_global_system_indatagrams 2118145963 # HELP System UDP counter inerrors # TYPE fastnetmon_global_system_inerrors counter fastnetmon_global_system_inerrors 26214 # HELP System UDP counter noports # TYPE fastnetmon_global_system_noports counter fastnetmon_global_system_noports 9572 # HELP System UDP counter outdatagrams # TYPE fastnetmon_global_system_outdatagrams counter fastnetmon_global_system_outdatagrams 2008799213 # HELP System UDP counter rcvbuferrors # TYPE fastnetmon_global_system_rcvbuferrors counter fastnetmon_global_system_rcvbuferrors 26214 # HELP System UDP counter sndbuferrors # TYPE fastnetmon_global_system_sndbuferrors counter fastnetmon_global_system_sndbuferrors 0 # HELP Total traffic in packets # TYPE fastnetmon_total_traffic_packets gauge fastnetmon_total_traffic_packets{traffic_direction="incoming",protocol_version="ipv4"} 0 # HELP Total traffic in bits # TYPE fastnetmon_total_traffic_bits gauge fastnetmon_total_traffic_bits{traffic_direction="incoming",protocol_version="ipv4"} 0 # HELP Total traffic in flows # TYPE fastnetmon_total_traffic_flows gauge fastnetmon_total_traffic_flows{traffic_direction="incoming",protocol_version="ipv4"}0 # HELP Total traffic in packets # TYPE fastnetmon_total_traffic_packets gauge fastnetmon_total_traffic_packets{traffic_direction="outgoing",protocol_version="ipv4"} 0 # HELP Total traffic in bits # TYPE fastnetmon_total_traffic_bits gauge fastnetmon_total_traffic_bits{traffic_direction="outgoing",protocol_version="ipv4"} 0 # HELP Total traffic in flows # TYPE fastnetmon_total_traffic_flows gauge fastnetmon_total_traffic_flows{traffic_direction="outgoing",protocol_version="ipv4"}0 # HELP Total traffic in packets # TYPE fastnetmon_total_traffic_packets gauge fastnetmon_total_traffic_packets{traffic_direction="internal",protocol_version="ipv4"} 0 # HELP Total traffic in bits # TYPE fastnetmon_total_traffic_bits gauge fastnetmon_total_traffic_bits{traffic_direction="internal",protocol_version="ipv4"} 0 # HELP Total traffic in packets # TYPE fastnetmon_total_traffic_packets gauge fastnetmon_total_traffic_packets{traffic_direction="other",protocol_version="ipv4"} 0 # HELP Total traffic in bits # TYPE fastnetmon_total_traffic_bits gauge fastnetmon_total_traffic_bits{traffic_direction="other",protocol_version="ipv4"} 0 # HELP Total traffic in packets # TYPE fastnetmon_total_traffic_packets gauge fastnetmon_total_traffic_packets{traffic_direction="incoming",protocol_version="ipv6"} 0 # HELP Total traffic in bits # TYPE fastnetmon_total_traffic_bits gauge fastnetmon_total_traffic_bits{traffic_direction="incoming",protocol_version="ipv6"} 0 # HELP Total traffic in packets # TYPE fastnetmon_total_traffic_packets gauge fastnetmon_total_traffic_packets{traffic_direction="outgoing",protocol_version="ipv6"} 0 # HELP Total traffic in bits # TYPE fastnetmon_total_traffic_bits gauge fastnetmon_total_traffic_bits{traffic_direction="outgoing",protocol_version="ipv6"} 0 # HELP Total traffic in packets # TYPE fastnetmon_total_traffic_packets gauge fastnetmon_total_traffic_packets{traffic_direction="internal",protocol_version="ipv6"} 0 # HELP Total traffic in bits # TYPE fastnetmon_total_traffic_bits gauge fastnetmon_total_traffic_bits{traffic_direction="internal",protocol_version="ipv6"} 0 # HELP Total traffic in packets # TYPE fastnetmon_total_traffic_packets gauge fastnetmon_total_traffic_packets{traffic_direction="other",protocol_version="ipv6"} 0 # HELP Total traffic in bits # TYPE fastnetmon_total_traffic_bits gauge fastnetmon_total_traffic_bits{traffic_direction="other",protocol_version="ipv6"} 0 ``` These values can be used to create alerts and monitor that FastNetMon works correctly. General alerts: - traffic\_db\_errors must not exceed 0, it will mean that FastNetMon is having issues with sending flows to traffic\_db - speed\_recalculation\_time\_seconds must not exceed 0. If it does, it will mean that FastNetMon cannot recalculate traffic in a reasonable time (<1 second), and it will lead to significant traffic calculation inaccuracy - influxdb\_writes\_failed must not exceed 0, it will mean that FastNetMon is having issues with sending metrics to InfluxDB - clickhouse\_metrics\_writes\_failed must not exceed 0, it will mean that FastNetMon is having issues with sending metrics to Clickhouse sFlow mode: - sflow\_raw\_packet\_headers\_total\_speed: this value must not be zero. It counts the number of sFlow samples processed per second. It confirms that plugins are enabled and receive traffic from routers. - sflow\_bad\_packets and sflow\_bad\_flow\_samples should both be zero, as that indicates serious issues with sFlow protocol encoding. Netflow / IPFIX mode: - netflow\_all\_protocols\_total\_flows\_speed: this value must not be zero. It counts the number of Netflow / IPFIX flows processed by second. It confirms that plugins are enabled and receive traffic from routers. - netflow\_v9\_too\_large\_field, ipfix\_too\_large\_field should not exceed 0, which means that the device uses unusal length for some field, and it may cause issues with traffic accounting - netflow\_v9\_broken\_packets should be both zero, as they will mean some serious issues with Netflow v9 protocol encoding. - netflow\_ipfix\_udp\_packet\_drops should be 0, which means that the receiving UDP socket is dropping traffic due to performance issues. - netflow\_ipfix\_unknown\_protocol\_version should be 0, which means that some unknown version of Netflow is being sent to FastNetMon. It may be a sign that some other traffic (sFlow, for example) is being sent to Netflow / IPFIX port. Port mirror mode: - af\_packet\_socket\_dropped\_packets should be zero; it counts the number of packets dropped due to performance issues. **Document Categories:** Maintenance operations --- ### [Log management in FastNetMon](https://fastnetmon.com/docs-fnm-advanced/log-management-in-fastnetmon/) **Published:** May 9, 2020 **Author:** Pavel Odintsov **Content:** FastNetMon Advanced generates a large amount of log entries, and they can be used to debug decisions made by FastNetMon. By default, FastNetMon uses file-based logging to /var/log/fastnetmon/fastnetmon.log. Example log entry looks like: ``` 2020-05-01 19:12:46,252 [INFO] FastNetMon started 2020-05-01 19:12:46,252 [INFO] FastNetMon version: 2.0.187 git 804...631 started 2020-05-01 19:12:46,252 [INFO] Read configuration file ``` For any kinds of issues or misbehaviour, FastNetMon uses logging levels WARN and ERROR: ``` 2020-04-12 22:31:24,262 [WARN] We will use 192.168.1.0/30 instead of 192.168.1.1/30 because it's host address 2020-03-17 09:40:34,244 [ERROR] Please specify intreface for AF_PACKET ``` If you have a log analytics system, it makes sense to filter out such error messages and look at them manually. If you experience complex issues, or our support team specifically advises, you can enable debug-level logging: ``` sudo fcli set main logging_level debug sudo fcli commit ``` In this mode, FastNetMon will generate a large amount of log entries. Please do not enable this mode for an extended period of time, and after debugging, please switch to the default log level “info”: ``` sudo fcli set main logging_level info sudo fcli commit ``` If you would like to debug the logic of FastNetMon during the configuration initialisation phase, before FastNetMon actually reads configuration about different logging levels from the database, you need to add the following option to /etc/fastnetmon/fastnetmon.conf: ``` { "logging_level": "debug" } ``` After this, restart FastNetMon. To return to the default logging level, you need to set it to info back to: ``` { "logging_level": "info" } ``` For systems with centralised log collection, we offer the ability to send logs to remove locations via syslog’s UDP-based protocol. ``` sudo fcli set main logging_remote_syslog_logging enable sudo fcli set main logging_remote_syslog_port 514 sudo fcli set main logging_remote_syslog_server 10.10.10.10 sudo fcli commit ``` As another option, you can send messages to the local syslog daemon: ``` sudo fcli set main logging_local_syslog_logging enable sudo fcli commit ``` Please do not rely on the text of log messages; we do not guarantee their consistency, please use the API or callback scripts instead. FastNetMon has support for versioned and stable log messages, which can be used for different actions, and we guarantee their availability and format in new versions. They’re enabled automatically when you enable remote or local syslog logging. Examples: ``` v:1 mode:blackhole action:ban proto:ipv4 target:127.0.0.1 pps_in_rate:0 pps_out_rate:0 bytes_in_rate:0 bytes_out_rate:0 v:1 mode:blackhole action:unban proto:ipv4 target:127.0.0.1 pps_in_rate:0 pps_out_rate:0 bytes_in_rate:0 bytes_out_rate:0 ``` ## Attack status reporting In addition to reports of ban and unban operations, FastNetMon has capability to report active attacks. You can enable it this way: ``` sudo fcli set main ban_status_updates true sudo fcli commit ``` After that, you can setthe period in seconds how often FastNetMon reports an active attack: ``` sudo fcli set main ban_status_delay 20 sudo fcli commit ``` Example log message format is the following: ``` v:1 mode:blackhole action:status proto:ipv4 target: 1.2.3.4 pps_in_rate: 1 pps_out_rate: 2 bytes_in_rate: 3 bytes_out_rate: 4 ``` Starting from 2.0.359, FastNetMon hasthe capability to log status of ongoing IPv6 attacks too. ### Journald logging instead of file logging By default, FastNetMon stores log information to /var/log/fastnetmon/fastnetmon.log. If you prefer, you can specify the command line flag --log\_to\_console, and it will send logs to systemd journald. The same flag is supported by traffic\_db daemon, which stores its log file to /var/log/fastnetmon/traffic\_db.log by default. To switch FastNetMon from file logging to journald you need to run the following command: ``` sudo systemctl edit fastnetmon ``` Then provide the following information: ``` [Service] # Clear previous value ExecStart= ExecStart=/opt/fastnetmon/app/bin/fastnetmon --log_to_console ``` After this, empty the file-based log file: ``` sudo cp /dev/null /var/log/fastnetmon/fastnetmon.log ``` Apply the changes: ``` sudo systemctl daemon-reload sudo systemctl restart fastnetmon ``` After that, FastNetMon will not log everything to /var/log/fastnetmon/fastnetmon.log, and all logging will be delivered to journald: ``` sudo journalctl -u fastnetmon -f -n 100 ``` Then you need to do the same with traffic\_db: ``` sudo systemctl edit traffic_db ``` And provide the following: ``` [Service] # Clear previous value ExecStart= ExecStart=/opt/fastnetmon/app/bin/traffic_db --log_to_console ``` After this, empty the file-based log file: ``` sudo cp /dev/null /var/log/fastnetmon/traffic_db.log ``` Apply changes: ``` sudo systemctl daemon-reload sudo systemctl restart traffic_db ``` After this, traffic\_db will not log everything to /var/log/fastnetmon/traffic\_db.log, and all logging will be delivered to journald: ``` sudo journalctl -u traffic_db -f -n 100 ``` **Document Categories:** Maintenance operations --- ### [FastNetMon Advanced complete removal](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-complete-removal/) **Published:** September 1, 2022 **Author:** Pavel Odintsov **Content:** In case of migration or a clean re-install, you may need to remove FastNetMon Advanced with all configuration files. Instructions in this article will lead to the complete irrecoverable loss of configuration and all data from the server. These instructions will work for Debian or Ubuntu platforms. Do not continue unless you're 100% sure that you do not need the data. You need to remove FastNetMon's package first: ``` sudo apt-get remove --purge fastnetmon ``` Then you will need to remove all MongoDB packages and configuration for them: ``` sudo apt remove --purge mongodb-database-tools mongodb-mongosh mongodb-org mongodb-org-mongos mongodb-org-server mongodb-org-shell mongodb-org-tools ``` The next step will lead to complete irrecoverable data loss. Please make a full server backup to reduce your risk of data loss. Remove all configuration files and databases: ``` sudo rm -rf /etc/fastnetmon/ /var/lib/mongodb/ /etc/apt/sources.list.d/fastnetmon.list /etc/apt/sources.list.d/mongodb-org.list ``` After that, you may start [installation](https://fastnetmon.com/docs-fnm-advanced/advanced-install-guide/) again if needed. **Document Categories:** Maintenance operations --- ### [How to keep traffic counters during restart of FastNetMon](https://fastnetmon.com/docs-fnm-advanced/how-to-keep-traffic-counters-during-restart-of-fastnetmon/) **Published:** September 9, 2022 **Author:** Pavel Odintsov **Content:** When you issue a sudo fcli commit command, you restart FastNetMon. It leads to a complete drop of all information accumulated by FastNetMon, and you may notice a drop on graphs in Grafana when such events happen. Before using this capability, you need to have subsystems which handle such logic: ``` sudo fcli set main keep_traffic_counters_during_restart true sudo fcli commit ``` We offer an option which can be used to avoid traffic drops during restart, and you can enable it this way from fcli: ``` sudo fcli set save_traffic_counters ``` After that, FastNetMon will create traffic dumps in the cache folder: ``` sudo ls -l /var/cache/fastnetmon/ total 35872 -rw-rw-rw- 1 root root 2192900 Sep 9 20:39 speed_counters_local_ipv4_hosts.dat -rw-rw-rw- 1 root root 3456 Sep 9 20:39 speed_counters_local_ipv4_networks.dat -rw-rw-rw- 1 root root 569 Sep 9 20:39 speed_counters_local_ipv6_hosts.dat -rw-rw-rw- 1 root root 569 Sep 9 20:39 speed_counters_local_ipv6_networks.dat -rw-rw-rw- 1 root root 8145 Sep 9 20:39 speed_counters_total_hostgroups.dat -rw-rw-rw- 1 root root 1620 Sep 9 20:39 speed_counters_total_ipv4.dat -rw-rw-rw- 1 root root 1531 Sep 9 20:39 speed_counters_total_ipv6.dat ``` And then you can apply a commit command, which will not lead to drops on graphs: ``` sudo fcli commit ``` You may confirm that it happened successfully using these log entries: ``` cat /var/log/fastnetmon/fastnetmon.log|grep 'Start loading' 2022-09-09 19:54:26,584 [INFO] Start loading local IPv4 hosts traffic counters from disk 2022-09-09 19:54:26,630 [INFO] Start loading local IPv4 networks traffic counters from disk 2022-09-09 19:54:26,630 [INFO] Start loading local IPv6 hosts traffic counters from disk 2022-09-09 19:54:26,630 [INFO] Start loading local IPv6 networks traffic counters from disk 2022-09-09 19:54:26,630 [INFO] Start loading total hostgroup traffic counters from disk 2022-09-09 19:54:26,631 [INFO] Start loading total IPv4 traffic counters from disk 2022-09-09 19:54:26,631 [INFO] Start loading total IPv6 traffic counters from disk 2022-09-09 20:39:37,933 [INFO] Start loading local IPv4 hosts traffic counters from disk 2022-09-09 20:39:37,983 [INFO] Start loading local IPv4 networks traffic counters from disk 2022-09-09 20:39:37,983 [INFO] Start loading local IPv6 hosts traffic counters from disk 2022-09-09 20:39:37,983 [INFO] Start loading local IPv6 networks traffic counters from disk 2022-09-09 20:39:37,983 [INFO] Start loading total hostgroup traffic counters from disk 2022-09-09 20:39:37,984 [INFO] Start loading total IPv4 traffic counters from disk 2022-09-09 20:39:37,984 [INFO] Start loading total IPv6 traffic counters from disk ``` In the current version, FastNetMon can save / load traffic for the following types of counters: - Total traffic - Per network IPv4, per network /24 IPv4, IPv6 - Per host IPv4, IPv6 traffic - Total hostgroups traffic - Per ASN traffic In case of really large networks time required to save/load all counters may be significant, and you will benefit from an NVME/SSD-based storage system to speed up this process. **Document Categories:** Maintenance operations --- ### [Memory consumption](https://fastnetmon.com/docs/memory_consumption/) **Published:** August 19, 2016 **Author:** FastNetMon **Content:** This guide applies to FastNetMon Community only. FastNetMon Advanced uses flexible counters, which are significantly faster and can scale to extremely large networks. The required amount of memory depends on the total number of monitored hosts. You can use this formula to calculate your required amount of memory: ``` total_number_of_hosts * 208 * 3 ``` - 3 is a number of counters (data counter, current speed counter, smoothed speed counter). - 208 is the total size of the traffic counting structure for the version 1.1.3. Example computations: - /16, 65535 hosts - 40 mb of RAM - /8, 16 million hosts - 10GB ram Please note: We need to iterate across all counters with a single CPU core in ~1 second. Then, for a large number of hosts, you need to havea fast CPU core. Memory requirements can be reduced using [flexible counters](https://fastnetmon.com/docs-fnm-advanced/flexible-counters-for-traffic-calculation/). **Document Categories:** Maintenance operations --- ### [FastNetMon Advanced configuration options](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-configuration-options/) **Published:** December 9, 2017 **Author:** Pavel Odintsov **Content:** In this document, we could offer detailed description of all available configuration options in all configuration namespaces ## Main configuration options ### af\_packet | Name | Type | Default value | Description | |---|---|---|---| | mirror\_afpacket | bool | false | Enable capture from mirror port using AF\_PACKET capture engine | | interfaces | string\_list | \[ \] | Interfaces list for traffic capture | | af\_packet\_extract\_tunnel\_traffic | bool | false | Enables for af\_packet code which strips external level for GRE tunnels | | mirror\_af\_packet\_sampling | bool | true | Enables sampling for mirror mode offloaded on kernel / driver level | | mirror\_af\_external\_packet\_sampling | bool | false | Enables external sampling for mirror mode when router or switch does sampling | | mirror\_af\_packet\_socket\_stats | bool | true | Enables capture socket performance statistics | | mirror\_af\_packet\_disable\_multithreading | bool | true | Disables multi thread processing and handles all traffic using single thread | | mirror\_af\_packet\_fanout\_mode | string | "cpu" | Fanout mode. Algorithm to spread load over threads | | mirror\_af\_packet\_sampling\_rate | positive\_integer\_with\_zero | 100 | Sampling rate for AF\_PACKET | | mirror\_external\_af\_packet\_sampling\_rate | positive\_integer\_with\_zero | 100 | External sampling rate for AF\_PACKET | | mirror\_af\_packet\_workers\_number\_override | bool | false | Enables logic to explicitly override number of worker processes | | mirror\_af\_packet\_workers\_number | positive\_integer\_with\_zero | 1 | Specifies how many worker processes we need for each interface | | afpacket\_strict\_cpu\_affinity | bool | false | Enables strict CPU affinity and binds traffic capture threads to fixed logical CPUs | | af\_packet\_read\_packet\_length\_from\_ip\_header | bool | false | By default, FastNetMon reads packet length from the wire. But it can use information from IP header when you enable this option | ### api | Name | Type | Default value | Description | |---|---|---|---| | enable\_api | bool | true | Enable internal FastNetMon API. It's mandatory for fcli and public web API | | api\_host | string | "127.0.0.1" | Internal API host for listening | | api\_port | numeric\_ipv4\_port | 50052 | Internal API port for listening | ### app\_packet\_sr | Name | Type | Default value | Description | |---|---|---|---| | app\_packet\_sr | bool | false | Enable App Packet SR capture for Nokia SR UDP Shim encoding | | app\_packet\_sr\_local\_addresses | string\_list | \[ \] | App Packet SR collector addresses to bind on in format: protocol://host:port as protocol you can use udp only | | app\_packet\_sr\_tunnel\_traffic | bool | false | Enables code which strips external level for GRE tunnels for App Packet SR | | app\_packet\_sr\_read\_packet\_length\_from\_ip\_header | bool | false | By default, FastNetMon reads packet length from the wire. But it can use information from IP header when you enable this option | ### ban\_management | Name | Type | Default value | Description | |---|---|---|---| | enable\_ban | bool | false | Completely enable or disable all ban actions | | enable\_ban\_hostgroup | bool | false | Completely enable or disable all ban for total traffic per hostgroup | | enable\_ban\_remote\_outgoing | bool | false | Enable blocking for remote hosts in outgoing direction | | enable\_ban\_remote\_incoming | bool | false | Enable blocking for remote hosts in incoming direction | | do\_not\_ban\_incoming | bool | false | Completely disables ban for incoming traffic | | do\_not\_ban\_outgoing | bool | false | Completely disables ban for outgoing traffic | | per\_direction\_hostgroup\_thresholds | bool | true | Changes hostgroup thresholds to be per direction. Default becomes incoming | | flexible\_thresholds | bool | false | Enables flexible thresholds logic | | flexible\_thresholds\_disable\_multi\_alerts | bool | false | Enables compatibility mode for flexible threshold which triggers attack only using single threshold and only in single direction | | keep\_flow\_spec\_announces\_during\_restart | bool | false | Saves list of flow spec announces on shutdown and restores it on startup | | keep\_blocked\_hosts\_during\_restart | bool | false | Saves list of blocked hosts on shutdown and restores it on startup | | keep\_blocked\_hostgroups\_during\_restart | bool | false | Saves list of blocked hostgroups on shutdown and restores it on startup | | enable\_ban\_ipv6 | bool | false | Completely enable or disable all ban actions for IPv6 traffic | | unban\_enabled | bool | true | We will try to unban blocked IPs after this time expires | | ban\_status\_updates | bool | false | FastNetMon will report active attacks every X seconds | | ban\_status\_delay | positive\_integer\_with\_zero | 20 | How often FastNetMon will update external systems about active attacks | | ban\_time | positive\_integer\_with\_zero | 771 | How long we should keep an IP in blocked state. Zero value is prohibited here. | | unban\_only\_if\_attack\_finished | bool | true | Check if the attack is still active, before triggering an unblock callback with this option. If the attack is still active, check each run of the unblock watchdog | | gobgp\_flow\_spec\_announces | bool | false | Announce flow spec rules to block only malicious traffic. Use only if you have BGP Flowspec capable routers | | gobgp\_flow\_spec\_v6\_announces | bool | false | Announce flow spec IPv6 rules to block only malicious traffic. Use only if you have BGP Flowspec capable routers | | flow\_spec\_unban\_enabled | bool | true | We will try to withdraw flow spec rule when blocking time expires | | flow\_spec\_per\_hostgroup\_management | bool | false | Enables logic which enables flow spec mitigations only when they explicitly enabled for hostgroup | | flow\_spec\_ban\_time | positive\_integer\_with\_zero | 1900 | How long we should flow spec keep rule in announces. Zero value is prohibited here. | | collect\_attack\_pcap\_dumps | bool | false | This option enables pcap collection for attack's traffic dump. Works only for mirror and sFlow modes | | collect\_simple\_attack\_dumps | bool | true | Collect simple attack dumps which include information from attack's sample. Works for all capture engines | | ban\_details\_records\_count | positive\_integer\_with\_zero | 25 | How many packets will be collected from attack's traffic. Please decrease this value if you are using sampled capture protocols | | threshold\_specific\_ban\_details | bool | false | In this mode FastNetMon will collect only traffic relevant to direction and type of threshold | | do\_not\_cap\_ban\_details\_records\_count | bool | false | Disables logic which automatically reduces ban\_details\_records\_count when it exceeds 100 for sFlow and Netflow | | unban\_total\_hostgroup\_enabled | bool | true | We will try to unban blocked hostgroup after specified amount of time | | ban\_time\_total\_hostgroup | positive\_integer\_with\_zero | 675 | How long we should keep hostgroup in blocked state. Zero value is prohibited here. | | bucket\_traffic\_collection\_timeout | positive\_integer\_with\_zero | 60 | How long we should wait for bucket to collect traffic after threshold was crossed | ### bgp | Name | Type | Default value | Description | |---|---|---|---| | gobgp | bool | false | Enable BGP daemon integration | | gobgp\_api\_host | string | "localhost" | IP address or host to connect to GoBGP | | gobgp\_api\_port | numeric\_ipv4\_port | 50051 | Port to connect to GoBGP | | gobgp\_bgp\_listen\_port | numeric\_ipv4\_port | 179 | BGP listen port | | gobgp\_router\_id | string | "" | Router ID to override default configuration | | gobgp\_next\_hop | numeric\_ipv4\_host | "0.0.0.0" | Next hop value for BGP unicast host and subnet IPv4 announces | | gobgp\_next\_hop\_host\_ipv4 | numeric\_ipv4\_host | "0.0.0.0" | Next hop value for BGP unicast IPv4 host announces | | gobgp\_next\_hop\_subnet\_ipv4 | numeric\_ipv4\_host | "0.0.0.0" | Next hop value for BGP unicast IPv4 subnet announces | | gobgp\_next\_hop\_remote\_host | numeric\_ipv4\_host | "0.0.0.0" | Next hop value for BGP unicast remote host IPv4 announces | | gobgp\_do\_not\_manage\_daemon | bool | false | Disables automatic start / restart operations for BGP daemon | | gobgp\_announce\_host | bool | true | Announce /32 host itself with BGP | | gobgp\_announce\_whole\_subnet | bool | false | Announce origin subnet of IP address | | gobgp\_announce\_whole\_subnet\_force\_custom\_prefix\_length | bool | false | Enables override for subnet announce | | gobgp\_announce\_whole\_subnet\_custom\_prefix\_length | positive\_integer\_with\_zero | 24 | Prefix length to override default one | | gobgp\_announce\_whole\_subnet\_force\_custom\_ipv6\_prefix\_length | bool | false | Enables override for IPv6 subnet announce | | gobgp\_announce\_whole\_subnet\_custom\_ipv6\_prefix\_length | positive\_integer\_with\_zero | 48 | IPv6 prefix length to override default one | | gobgp\_announce\_remote\_host | bool | false | Announce remote /32 host itself with BGP | | gobgp\_community\_host | string | "65001:668" | BGP community for outgoing host announces. Here you can add community string for the host announce. Usage ASN:Community. ASN and community should be from 1 to 65535). | | gobgp\_communities\_host\_ipv4 | string\_list | \[ \] | BGP communities for outgoing host announces. Here you can add communities strings for the host announces. Usage ASN:Community. ASN and community should be from 1 to 65535). | | gobgp\_communities\_host\_ipv6 | string\_list | \[ \] | BGP communities for outgoing host announces. Here you can add communities strings for the host announces. Usage ASN:Community. ASN and community should be from 1 to 65535). | | gobgp\_community\_subnet | string | "65001:667" | BGP community for outgoing subnet announces. Here you can add community string for the prefix subnet announce. Usage ASN:Community. ASN and community should be from 1 to 65535). | | gobgp\_communities\_subnet\_ipv4 | string\_list | \[ \] | BGP communities for outgoing subnet announces. Here you can add communities strings for the prefix subnet announce. Usage ASN:Community. ASN and community should be from 1 to 65535). | | gobgp\_communities\_subnet\_ipv6 | string\_list | \[ \] | BGP communities for outgoing subnet announces. Here you can add communities strings for the prefix subnet announce. Usage ASN:Community. ASN and community should be from 1 to 65535). | | gobgp\_community\_remote\_host | string | "65001:669" | BGP community for outgoing remote host announces. Here you can add community string for the host announce. Usage ASN:Community. ASN and community should be from 1 to 65535). | | gobgp\_ipv6 | bool | false | Enable BGP actions for IPv6 traffic | | gobgp\_next\_hop\_ipv6 | string | "100::1" | Next hop value for BGP unicast IPv6 announces | | gobgp\_announce\_host\_ipv6 | bool | true | Announce /128 host itself with BGP | | gobgp\_announce\_whole\_subnet\_ipv6 | bool | false | IPv6 prefix subnet, that will be announced | | gobgp\_community\_host\_ipv6 | string | "65001:668" | BGP community for outgoing host announces for IPv6 protocol. Here you can add community string for the host announce. Usage ASN:Community. ASN and community should be from 1 to 65535). | | gobgp\_community\_subnet\_ipv6 | string | "65001:667" | BGP community for outgoing subnet announces for IPv6 protocol. Here you can add community string for the prefix subnet announce. Usage ASN:Community. ASN and community should be from 1 to 65535). | | gobgp\_flow\_spec\_default\_action | string | "discard" | Default action for flow spec rules. You could specify accept, discard or rate-limit here | | gobgp\_flow\_spec\_next\_hop\_ipv4 | string\_list | \[ \] | List of IPv4 next hops | | gobgp\_flow\_spec\_next\_hop\_ipv6 | string\_list | \[ \] | List of IPv6 next hops | | gobgp\_flow\_spec\_v6\_default\_action | string | "discard" | Default action for flow spec rules. You could specify accept, discard or rate-limit here | | gobgp\_flow\_spec\_v6\_rate\_limit\_value | positive\_integer\_with\_zero | 1024 | For rate-limit action you could specify rate | | gobgp\_flow\_spec\_rate\_limit\_value | positive\_integer\_with\_zero | 1024 | For rate-limit action you could specify rate | | flow\_spec\_tcp\_options\_use\_match\_bit | bool | false | Enables force match bit in outgoing BGP Flow Spec announces about TCP flags | | flow\_spec\_fragmentation\_options\_use\_match\_bit | bool | false | Enables force match bit in outgoing BGP Flow Spec announces about fragmentation | | flow\_spec\_do\_not\_process\_length\_field | bool | false | Disables processing for length field completely. Use it if your device produces incorrect information about packet's length | | flow\_spec\_do\_not\_process\_tcp\_flags\_field | bool | false | Disables processing for TCP flags field completely. You may need it if your router does not support all TCP flags in flow spec rules | | flow\_spec\_do\_not\_process\_ip\_fragmentation\_flags\_field | bool | false | Disables processing for IP fragmentation field completely. You may need it if your router does not support all IP fragmentations flags in flow spec rules | | flow\_spec\_ignore\_do\_not\_fragment\_flag | bool | false | Disables processing for do not fragment field completely. It's useful on Arista and Extreme | | flow\_spec\_do\_not\_process\_source\_address\_field | bool | false | Disables processing for source address field completely. Use it if you experience attacks from big number of IP addresses | | flow\_spec\_execute\_validation | bool | true | With this option we check that source and destination addresses in flow spec rule specified from fcli or web API belongs to our ranges | | do\_not\_withdraw\_unicast\_announces\_on\_restart | bool | false | Disables automatic withdrawal of BGP Unicast announces | | do\_not\_withdraw\_flow\_spec\_announces\_on\_restart | bool | false | Disables automatic withdrawal of BGP Flow Spec announces | | gobgp\_announce\_hostgroup\_networks | bool | false | Enable BGP announces for any network from specific hostgroup when per hostgroup aka total thresholds in use | | gobgp\_announce\_hostgroup\_networks\_ipv4 | bool | false | Enable BGP announces for all IPv4 networks from specific hostgroup when per hostgroup aka total thresholds in use | | gobgp\_announce\_hostgroup\_networks\_ipv6 | bool | false | Enable BGP announces for all IPv6 networks from specific hostgroup when per hostgroup aka total thresholds in use | | gobgp\_next\_hop\_hostgroup\_networks\_ipv4 | string | "0.0.0.0" | Next hop for IPv4 per hostgroup network announces | | gobgp\_next\_hop\_hostgroup\_networks\_ipv6 | string | "100::1" | Next hop for IPv6 per hostgroup network announces | | gobgp\_communities\_hostgroup\_networks\_ipv4 | string\_list | \[ \] | BGP communities for IPv4 hostgroup network announces. Here you can add communities strings for the host announces. Usage ASN:Community. ASN and community should be from 1 to 65535). | | gobgp\_communities\_hostgroup\_networks\_ipv6 | string\_list | \[ \] | BGP communities for IPv6 hostgroup network announces. Here you can add communities strings for the host announces. Usage ASN:Community. ASN and community should be from 1 to 65535). | ### clickhouse\_metrics | Name | Type | Default value | Description | |---|---|---|---| | clickhouse\_metrics | bool | false | Export traffic speed metrics to ClickHouse | | clickhouse\_metrics\_database | string | "fastnetmon" | Database for ClickHouse traffic metrics | | clickhouse\_metrics\_username | string | "default" | Username for ClickHouse metrics | | clickhouse\_metrics\_password | string | "" | Password for ClickHouse metrics | | clickhouse\_metrics\_host | string | "127.0.0.1" | Server address for ClickHouse server to export metrics. IPv4, IPv6 address or hostname | | clickhouse\_metrics\_port | numeric\_ipv4\_port | 9000 | ClickHouse server port | | clickhouse\_metrics\_push\_period | positive\_integer\_with\_zero | 1 | Delay for run ClickHouse push thread | | clickhouse\_metrics\_export\_top\_hosts | bool | true | Enables export of only top talker hosts for IPv4 and IPv6 into separate table | ### email\_notification | Name | Type | Default value | Description | |---|---|---|---| | email\_notifications\_enabled | bool | false | Enable email notifications | | email\_notifications\_disable\_certificate\_checks | bool | false | Disables TLS certificate validation completely | | email\_notifications\_host | string | "smtp.gmail.com" | Hostname of SMTP server | | email\_notifications\_port | numeric\_ipv4\_port | 587 | Port of SMTP server used for email notifications | | email\_notifications\_tls | bool | true | Enable TLS for your SMTP server | | email\_notifications\_auth | bool | true | Enable auth for your SMTP server | | email\_notifications\_auth\_method | string | "" | Auth method for SMTP authorization. Used only when auth enabled | | email\_notifications\_username | string | "fastnetmon@yourdomain.com" | Username for SMTP authorization | | email\_notifications\_password | string | "super-secret-password" | Password for SMTP authorization | | email\_notifications\_from | string | "fastnetmon@yourdomain.com" | Email address for FROM field | | email\_notifications\_recipients | string\_list | \[ \] | Email notification recipients | | email\_notifications\_hide\_flow\_spec\_rules | bool | false | Hide flow spec rules from email | | email\_notifications\_add\_simple\_packet\_dump | bool | true | Add simple packet dump to email | | email\_subject\_blackhole\_block | string | "FastNetMon blocked host {{ ip }}" | Subject template for email notification about blocked host | | email\_subject\_blackhole\_unblock | string | "FastNetMon unblocked host {{ ip }}" | Subject template for email notification about unblocked host | | email\_subject\_partial\_block | string | "FastNetMon partially blocked traffic for host {{ ip }}" | Subject template for email notification about partially blocked host | | email\_subject\_partial\_unblock | string | "FastNetMon partially unblocked traffic for host {{ ip }}" | Subject template for email notification about partially unblocked host | | slack\_notifications\_add\_simple\_packet\_dump | bool | true | Add simple packet dump to Slack alerts | ### filter\_xdp | Name | Type | Default value | Description | |---|---|---|---| | filter\_xdp | bool | false | Enable capability to generate and inject filtering rules for XDP | | filter\_xdp\_mode | string | "skb" | Sets XDP mode: skb, driver, hardware | | interfaces\_filter\_xdp | string\_list | \[ \] | Interfaces list to load XDP microcode | ### graphite | Name | Type | Default value | Description | |---|---|---|---| | graphite | bool | false | Enabled metrics export to Graphite | | graphite\_host | numeric\_ipv4\_host | "127.0.0.1" | Graphite server address | | graphite\_port | numeric\_ipv4\_port | 2003 | Graphite server port | | graphite\_prefix | string | "fastnetmon" | Default prefix for Graphite metrics | | graphite\_push\_period | positive\_integer\_with\_zero | 1 | Delay for run Graphite push thread | ### influxdb | Name | Type | Default value | Description | |---|---|---|---| | influxdb\_kafka | bool | false | Enables traffic metrics export to Influxdb over Kafka | | influxdb\_kafka\_brokers | string\_list | \[ \] | Kafka brokers for InfluxDB export | | influxdb\_kafka\_topic | string | "fastnetmon" | Topic name for Kafka InfluxDB instance | | influxdb\_kafka\_partitioner | string | "consistent" | Partitioner between available partitions | | influxdb | bool | false | Enabled traffic metrics export to Influxdb | | influxdb\_database | string | "fastnetmon" | Database for InfluxDB data | | influxdb\_host | string | "127.0.0.1" | InfluxDB server address (IPv4, IPv6 address or domain name) | | influxdb\_port | numeric\_ipv4\_port | 8086 | InfluxDB server port | | influxdb\_custom\_tags | bool | false | Adds custom tag to InfluxDB export data | | influxdb\_tag\_name | string | "node" | Custom tag name | | influxdb\_tag\_value | string | "master" | Custom tag value | | influxdb\_tags\_table | string\_string\_map | | Custom tags in key / value format | | influxdb\_skip\_host\_counters | bool | false | Skip export for host counters to reduce load on InfluxDB server | | influxdb\_push\_host\_ipv6\_counters | bool | true | Enable pushing per host IPv6 counters to InfluxDB | | influxdb\_push\_host\_ipv4\_flexible\_counters | bool | true | Enables export of flexible per host IPv4 counters to InfluxDB | | influxdb\_push\_host\_ipv6\_flexible\_counters | bool | true | Enables export of flexible per host IPv6 counters to InfluxDB | | influxdb\_user | string | "fastnetmon" | Username for InfluxDB | | influxdb\_password | string | "fastnetmon" | Password for InfluxDB | | influxdb\_auth | bool | false | Enable authorization for InfluxDB | | influxdb\_attack\_notification | bool | false | Enables attack notifications in Grafana | | influxdb\_push\_period | positive\_integer\_with\_zero | 1 | Delay for run InfluxDB push thread | ### logging | Name | Type | Default value | Description | |---|---|---|---| | logging\_level | string | "info" | Configures logging level | | logging\_local\_syslog\_logging | bool | false | Enable this option if you want to send logs to local syslog facility | | logging\_remote\_syslog\_logging | bool | false | Enable this option if you want to send logs to a remote syslog server using UDP protocol | | logging\_remote\_syslog\_server | numeric\_ipv4\_host | "10.10.10.10" | This is the IPv4 address of your syslog server. You can specify the address you need | | logging\_remote\_syslog\_port | numeric\_ipv4\_port | 514 | Remote syslog server port | ### mikrotik | Name | Type | Default value | Description | |---|---|---|---| | mikrotik\_announce\_host | bool | false | Enable Mikrotik integration | | mikrotik\_announce\_host\_blackhole | bool | true | Enable blackhole flag for per host Mikrotik announce | | mikrotik\_rest\_api\_urls | string\_list | \[ \] | Mikrotik API URLs | ### mongo | Name | Type | Default value | Description | |---|---|---|---| | mongo\_store\_attack\_information | bool | false | Enables attacks export to MongoDB | ### netflow | Name | Type | Default value | Description | |---|---|---|---| | netflow | bool | false | Enable Netflow capture. We support Netflow v5, v9 and IPFIX (10) | | netflow\_count\_packets\_per\_device | bool | false | Enable logic to count number of packets from each router | | netflow\_multi\_thread\_processing | bool | false | Enables multi thread processing for each Netflow port | | netflow\_threads\_per\_port | positive\_integer\_with\_zero | 1 | Number of threads per Netflow port | | netflow\_multi\_thread\_mode | string | "" | Mode used to distribute traffic between threads | | netflow\_ports | numeric\_ipv4\_port\_list | \[ \] | Netflow collector port. It's possible to specify multiple ports here | | netflow\_host | string | "0.0.0.0" | Netflow collector host. To bind on all interfaces for IPv4 and IPv6 use ::. To bind only on IPv4 use 0.0.0.0. To bind on localhost for IPv4 and IPv6 use ::1. To bind only on IPv4 use 127.0.0.1 | | netflow\_socket\_read\_mode | string | "recvfrom" | Switches logic used to read data from socket: recvfrom or recvmsg | | netflow\_rx\_queue\_overflow\_monitoring | bool | false | Switches on logic to monitor drops on socket | | netflow\_ignore\_sampling\_rate\_from\_device | bool | false | Ignores sampling rate announces from device. For Netflow v9 and IPFIX only | | netflow\_ignore\_long\_duration\_flow\_enable | bool | false | FastNetMon will ignore flows which exceed duration specified in configuration | | netflow\_long\_duration\_flow\_limit | positive\_integer\_with\_zero | 1 | FastNetMon will ignore flows which exceed duration specified in this option | | netflow\_v5\_per\_router\_sampling\_rate | string\_positive\_integer\_with\_zero\_map | | Custom Netflow v5 sampling rate on router basis | | netflow\_v9\_per\_router\_sampling\_rate | string\_positive\_integer\_with\_zero\_map | | Custom Netflow v9 sampling rate on router basis | | netflow\_v9\_read\_sampling\_rate\_in\_data\_section | bool | false | Enables logic which can retrieve sampling rate when it was passed in data section. Mikrotik uses this approach | | netflow\_v9\_extract\_tunnel\_traffic | bool | false | Enables logic for Netflow v9 code which strips external level for GRE tunnels. It works only when packet header information is present | | ipfix\_per\_router\_sampling\_rate | string\_positive\_integer\_with\_zero\_map | | Custom IPFIX sampling rate on router basis | | ipfix\_extract\_tunnel\_traffic | bool | false | Enables logic for IPFIX code which strips external level for GRE tunnels. It works only when packet header information is present | | netflow\_sampling\_ratio | positive\_integer\_with\_zero | 1 | Netflow 9 or IPFIX sampling rate used at agent side. Netflow v9 and IPFIX agents use different and very complex approaches for notifying about sample ratio. Here you could specify a sampling ratio for all this agents. For Netflow v5 we extract sampling ratio from packets directly and this option not used. | | netflow\_v5\_custom\_sampling\_ratio\_enable | bool | false | This option will override netflow v5 sampling rate from packets by specified value | | netflow\_v5\_sampling\_ratio | positive\_integer\_with\_zero | 1 | It will be used when netflow\_v5\_custom\_sampling\_ratio\_enable set to enable | | netflow\_templates\_cache | bool | true | Cache Netflow v9 or IPFIX data templates on disk | | netflow\_sampling\_cache | bool | true | Cache Netflow v9 and IPFIX sampling rates on disk | | netflow\_process\_only\_flows\_with\_dropped\_packets | bool | false | We will process only Netflow v9 or IPFIX with forwarding status set to dropped | | netflow\_mark\_zero\_next\_hop\_and\_zero\_output\_as\_dropped | bool | false | With this option all traffic with zero IPv4 and IPv6 addresses in next hop and zero output interface will be marked as dropped | ### network\_management | Name | Type | Default value | Description | |---|---|---|---| | networks\_list | cidr\_networks\_list | \[ \] | Please specify all IPv4 and IPv6 networks which belong to you | | networks\_whitelist | cidr\_networks\_list | \[ \] | All ban actions will be disabled for your hosts in these networks. Use with attention! | | networks\_whitelist\_remote | cidr\_networks\_list | \[ \] | We will skip traffic to/from these remote networks completely from processing | | monitor\_local\_ip\_addresses | bool | false | Add local IP addresses and aliases to networks\_list | ### notify\_script | Name | Type | Default value | Description | |---|---|---|---| | notify\_script\_hostgroup\_enabled | bool | false | Enable script call in case of blocking for hostgroup total thresholds | | notify\_script\_hostgroup\_path | file | "/etc/fastnetmon/scripts/notify\_about\_attack.sh" | Path to notify script for hostgroup level blocks | | notify\_script\_enabled | bool | false | Enable script call in case of blocking, unban and attack\_details actions | | notify\_script\_attack\_status\_updates | bool | false | Enables logic to report all active attacks and their performance to callback script every ban\_status\_delay seconds | | notify\_script\_path | file | "/etc/fastnetmon/scripts/notify\_about\_attack.sh" | Path to notify script. This script executed for ban, unban and attack detail collection | | notify\_script\_format | string | "text" | Specifies format used for notify script: text or JSON | ### prometheus | Name | Type | Default value | Description | |---|---|---|---| | prometheus | bool | false | Enable Prometheus metrics endpoint | | prometheus\_host | numeric\_ipv4\_host | "127.0.0.1" | Prometheus metrics address | | prometheus\_port | numeric\_ipv4\_port | 9209 | Prometheus metrics port | | prometheus\_export\_host\_ipv4\_counters | bool | false | Enables logic to export IPv4 host counters via endpoint | | prometheus\_export\_host\_ipv6\_counters | bool | false | Enables logic to export IPv6 host counters via endpoint | | prometheus\_export\_network\_ipv4\_counters | bool | true | Enables logic to export IPv4 network counters via endpoint | | prometheus\_export\_network\_ipv6\_counters | bool | true | Enables logic to export IPv6 network counters via endpoint | ### redis | Name | Type | Default value | Description | |---|---|---|---| | redis\_enabled | bool | false | Enables attack's export to Redis | | redis\_host | numeric\_ipv4\_host | "127.0.0.1" | Redis server host | | redis\_port | numeric\_ipv4\_port | 6379 | Redis server port | | redis\_prefix | string | "fastnetmon" | Prefix for all Redis keys | ### sflow | Name | Type | Default value | Description | |---|---|---|---| | sflow | bool | false | Enables sFlow capture engine. We support only sFlow v5 | | sflow\_extract\_tunnel\_traffic | bool | false | Enables for sFlow code which strips external level for GRE tunnels | | sflow\_count\_packets\_per\_device | bool | false | Enable logic to count number of sFlow packets from each device | | sflow\_ports | numeric\_ipv4\_port\_list | \[ \] | Ports list for sFlow collector. It's possible to specify multiple ports here | | sflow\_host | string | "0.0.0.0" | sFlow collector default host. Here you can specify the IP address of the listen interface. If default is used, all interfaces will be listen. | | sflow\_read\_packet\_length\_from\_ip\_header | bool | false | Some vendors may lie about full packet length in sFlow packet. To avoid this issue we can switch to using IP packet length from parsed header | | sflow\_track\_sampling\_rate | bool | false | Enables tracking for sFlow sampling rate for all exporting entities (devices, line cards) | ### slack\_notification | Name | Type | Default value | Description | |---|---|---|---| | slack\_notifications\_enabled | bool | false | Enable Slack notifications | | slack\_notifications\_url | string | "https://hooks.slack.com/services/TXXXXXXXX/BXXXXXXXXX/LXXXXXXXXX" | Slack notification URL | ### system | Name | Type | Default value | Description | |---|---|---|---| | cache\_path | file | "/var/cache/fastnetmon" | Path to folder used for cache | | asn\_lookup | bool | true | Enable ASN mapping database to execute ASN lookup for IP. You could use it to lookup ASN for particular IP | | country\_lookup | bool | false | Enable country lookup logic | | force\_asn\_lookup | bool | false | Overwrite ASN received from device by result of lookup by our ASN database | | pid\_path | file | "/var/run/fastnetmon.pid" | Path to pid file for checking case if another copy of tool is running, it's useful when you run multiple instances of tool | | api\_host\_counters\_max\_hosts\_in\_response | positive\_integer\_with\_zero | 100 | Max number of hosts in show host\_counters output | | system\_user | string | "fastnetmon" | Run FastNetMon daemon from particular system user | | system\_group | string | "fastnetmon" | Run FastNetMon daemon from particular system group | | drop\_root\_permissions | bool | false | Try to run from non-root user. Not supported for mirror capture | | license\_use\_port\_443 | bool | true | Use port 443 instead for license server connections | ### telegram\_notification | Name | Type | Default value | Description | |---|---|---|---| | telegram\_notifications\_enabled | bool | false | Enable Telegram notifications | | telegram\_notifications\_bot\_token | string | "xxx:xxx" | Telegram bot token | | telegram\_notifications\_recipients | string\_list | \[ \] | Telegram notification recipients, can be user ids or public chat ids | | telegram\_notifications\_add\_simple\_packet\_dump | bool | true | Add simple packet dump to Telegram alert | ### tera\_flow | Name | Type | Default value | Description | |---|---|---|---| | tera\_flow | bool | false | Receive information in Tera Flow format from the network | | tera\_flow\_ports | numeric\_ipv4\_port\_list | \[ \] | Tera Flow collector port. It's possible to specify multiple ports here | | tera\_flow\_host | string | "0.0.0.0" | Tera Flow collector host. To bind to all interfaces for all protocols: not possible yet. To bind to all interfaces for a specific protocol: :: or 0.0.0.0. To bind to localhost for a specific protocol: ::1 or 127.0.0.1. | | tera\_flow\_local\_addresses | string\_list | \[ \] | Tera Flow collector addresses to bind on in format: protocol://host:port as protocol you can use udp or tcp | | tera\_flow\_tls\_certificate\_path | string | "" | TLS certificate path for FastNetMon Flow server in TLS mode | | tera\_flow\_tls\_certificate\_chain | bool | false | You need to set it when you specify path to certificate bundle with multiple certificates | | tera\_flow\_tls\_private\_key\_path | string | "" | TLS private key path for FastNetMon Flow server in TLS mode | ### traffic\_calculation\_management | Name | Type | Default value | Description | |---|---|---|---| | keep\_traffic\_counters\_during\_restart | bool | false | Keep all speed counters during restarts | | process\_incoming\_traffic | bool | true | Enables or disables processing for incoming traffic | | process\_outgoing\_traffic | bool | true | Enables or disables processing for outgoing traffic | | override\_internal\_traffic\_as\_incoming | bool | false | Enables logic to process internal traffic as incoming | | override\_internal\_traffic\_as\_outgoing | bool | false | Enables logic to process internal traffic as outgoing | | process\_ipv6\_traffic | bool | true | Enables processing for IPv6 traffic | | enable\_connection\_tracking | bool | true | Enable traffic state tracking. If you interested in flow per second rates, please enable it. Be careful, it may increase CPU usage significantly | | remote\_host\_tracking | bool | false | Completely enable or disable bandwidth calculation for remote hosts | | connection\_tracking\_skip\_ports | bool | false | Disables port processing for connection tracking | | enable\_total\_hostgroup\_counters | bool | true | Enable traffic counters for total per hostgroups traffic | | enable\_interface\_counters | bool | true | Enable interface counters for per interface traffic | | enable\_asn\_counters | bool | true | Enable ASN counters for per ASN traffic | | build\_total\_hostgroups\_from\_per\_host\_hostgroups | bool | false | Allows using per-host hostgroups for building total hostgroups | | dump\_other\_traffic | bool | false | Dump all traffic which belongs to other class to log. Only for debugging reasons. It significantly degrades performance | | dump\_internal\_traffic | bool | false | Dump all traffic which belongs to internal class to log. Only for debugging reasons. It significantly degrades performance | | dump\_all\_traffic | bool | false | Dump all traffic to log. Only for debugging reasons. It significantly degrades performance | | dump\_all\_traffic\_json | bool | false | Dump all traffic to log in JSON format. Only for debugging reasons. It significantly degrades performance | | speed\_calculation\_delay | positive\_integer\_with\_zero | 1 | This value control how often we run speed recalculation function. Please do not use this unless support suggested this to you | | average\_calculation\_time | positive\_integer\_with\_zero | 5 | We use average values for traffic speed to certain IP and calculates average over this time slice | | flow\_forwarder | bool | false | Flow forwarder allows you to send traffic to remote FastNetMon | | flow\_forwarder\_remote\_addresses | string\_list | \[ \] | Flow forwarder allows you to send traffic to remote FastNetMon: protocol://host:port as protocol you can use udp or tcp | | flow\_forwarder\_sampling\_rate | positive\_integer\_with\_zero | 512 | Sampling rate for mirrored traffic for Flow Forwarder export | | ipv6\_automatic\_data\_cleanup | bool | true | Enables logic which removes old entries from IPv6 data counters | | ipv6\_automatic\_data\_cleanup\_threshold | positive\_integer\_with\_zero | 300 | We will remove all entries which exceed this age in seconds | | ipv6\_automatic\_data\_cleanup\_delay | positive\_integer\_with\_zero | 300 | How often we will run cleanup logic | | ipv4\_automatic\_data\_cleanup | bool | true | Enables logic which removes old entries from IPv4 data counters | | ipv4\_automatic\_data\_cleanup\_threshold | positive\_integer\_with\_zero | 300 | We will remove all entries which exceed this age in seconds | | ipv4\_automatic\_data\_cleanup\_delay | positive\_integer\_with\_zero | 300 | How often we will run cleanup logic | | ipv4\_remote\_automatic\_data\_cleanup | bool | true | Enables logic which removes old entries from IPv4 remote data counters | | ipv4\_remote\_automatic\_data\_cleanup\_threshold | positive\_integer\_with\_zero | 300 | We will remove all remove IPv4 entries which exceed this age in seconds | | ipv4\_remote\_automatic\_data\_cleanup\_delay | positive\_integer\_with\_zero | 300 | How often we will run cleanup logic for remote IPv4 records | | traffic\_buffer | bool | false | Enables or disables traffic buffer which keeps some amount of previously processed packets | | traffic\_buffer\_size | positive\_integer\_with\_zero | 100000 | Specifies number of elements in traffic\_buffer for 1 second of average calculation time | | traffic\_buffer\_port\_mirror | bool | false | Enables or disables traffic buffer for port mirror modes. Do not enable unless sampling is enabled | | generate\_attack\_traffic\_samples | bool | false | Enables logic to populate statistical reports about attacks traffic. Only for vendor integrations | | generate\_attack\_traffic\_samples\_delay | positive\_integer\_with\_zero | 60 | How often we're going to produce traffic reports about active attacks | | generate\_max\_talkers\_report | bool | false | Enables logic to track max talkers and store them into MongoDB Only for vendor integrations | | generate\_max\_talkers\_report\_delay | positive\_integer\_with\_zero | 300 | How often we're going to produce reports about max talkers | | generate\_hostgroup\_traffic\_samples | bool | false | Enables logic to populate statistical reports about hostgroup traffic. Only for vendor integrations | | generate\_hostgroup\_traffic\_samples\_delay | positive\_integer\_with\_zero | 60 | How often we're going to produce traffic reports for hostgroup traffic | ### traffic\_db | Name | Type | Default value | Description | |---|---|---|---| | traffic\_db | bool | false | Enable traffic export to persistent traffic database | | traffic\_db\_host | string | "127.0.0.1" | Traffic DB server address as IPv4, IPv6 or hostname | | traffic\_db\_port | numeric\_ipv4\_port | 8100 | Traffic DB server port | | traffic\_db\_sampling\_rate | positive\_integer\_with\_zero | 512 | Sampling rate for mirrored traffic for traffic\_db export | ### vyos | Name | Type | Default value | Description | |---|---|---|---| | vyos\_announce\_host | bool | false | Enable VyOS integration | | vyos\_announce\_host\_blackhole | bool | true | Enable blackhole flag for per host VyOS announce | | vyos\_api\_urls | string\_list | \[ \] | VyOS API URL | ### web\_api | Name | Type | Default value | Description | |---|---|---|---| | web\_api\_host | string | "127.0.0.1" | Web API host for listening | | web\_api\_port | numeric\_ipv4\_port | 10007 | Web API port for listening | | web\_api\_login | string | "admin" | Login for web API | | web\_api\_password | string | "" | Password for web API | | web\_api\_ssl | bool | false | Web API host for listening for ssl API | | web\_api\_trace\_queries | bool | false | Trace all queries | | web\_api\_ssl\_port | numeric\_ipv4\_port | 10443 | Web API port for listening | | web\_api\_ssl\_host | string | "127.0.0.1" | Web API host for listening | | web\_api\_ssl\_certificate\_path | string | "" | Certificate for SSL API | | web\_api\_ssl\_private\_key\_path | string | "" | Private key for SSL API | ### web\_callback | Name | Type | Default value | Description | |---|---|---|---| | web\_callback\_enabled | bool | false | FastNetMon could call external script with http or https protocol and pass attack's details in JSON format | | web\_callback\_url | string | "https://127.0.0.1:8080/attack/notify" | We could call this script in case of blackhole ban and unban and for partial (flow spec) block action and pass details with JSON inside POST query | ### xdp | Name | Type | Default value | Description | |---|---|---|---| | mirror\_xdp | bool | false | Enable capture from mirror port using AF\_XDP capture engine | | xdp\_read\_packet\_length\_from\_ip\_header | bool | false | By default, FastNetMon reads packet length from the wire. But it can use information from IP header when you enable this option | | force\_native\_mode\_xdp | bool | false | Requires native XDP support from driver | | zero\_copy\_xdp | bool | false | Enable zero copy mode for XDP. Requires native support from driver (force\_native\_mode\_xdp) | | poll\_mode\_xdp | bool | false | Use poll system call to process incoming packets | | xdp\_set\_promisc | bool | false | Set promisc flag on interface automatically | | xdp\_extract\_tunnel\_traffic | bool | false | Enables code which strips external level for GRE tunnels | | interfaces\_xdp | string\_list | \[ \] | Interfaces list for traffic capture using XDP | | microcode\_xdp\_path | string | "/etc/fastnetmon/xdp\_kernel.o" | You can specify custom path to microcode | ## Hostgroups configuration ### default | Name | Type | Default value | Description | |---|---|---|---| | name | string | "global" | Name of host group | | parent\_name | string | "" | Parent host group name | | description | string | "This is default group for all hosts" | Human-friendly name for this group | | calculation\_method | string | "per\_host" | Traffic calculation method for host group: total or per\_host (or empty value) | | networks | cidr\_networks\_list | \[ \] | List of networks which belong to this group | | enable\_ban | bool | false | Enable ban actions for hosts in this group | | ban\_for\_pps | bool | false | Should we block host in this group if it exceeds packet per second threshold? | | ban\_for\_bandwidth | bool | false | Should we block host in this group if it exceeds bandwidth threshold? | | ban\_for\_flows | bool | false | Should we block host in this group if it exceeds flows threshold? | | threshold\_pps | positive\_integer\_with\_zero | 100000 | Packet per second traffic to/from this host should exceed this value | | threshold\_mbps | positive\_integer\_with\_zero | 1000 | Bandwidth to/from this host should exceed this value | | threshold\_flows | positive\_integer\_with\_zero | 3500 | Flow per second speed to/from this host should exceed this value | | ban\_for\_tcp\_bandwidth | bool | false | Block hosts in group for TCP bandwidth threshold? | | ban\_for\_udp\_bandwidth | bool | false | Block hosts in group for UDP bandwidth threshold? | | ban\_for\_icmp\_bandwidth | bool | false | Block hosts in group for ICMP bandwidth threshold? | | ban\_for\_tcp\_pps | bool | false | Should we block host in this group if it exceeds packet per second threshold for TCP? | | ban\_for\_udp\_pps | bool | false | Should we block host in this group if it exceeds packet per second threshold for UDP? | | ban\_for\_icmp\_pps | bool | false | Should we block host in this group if it exceeds packet per second threshold for ICMP? | | threshold\_tcp\_mbps | positive\_integer\_with\_zero | 1000 | TCP bandwidth to/from this host should exceed this value | | threshold\_udp\_mbps | positive\_integer\_with\_zero | 1000 | UDP bandwidth to/from this host should exceed this value | | threshold\_icmp\_mbps | positive\_integer\_with\_zero | 1000 | ICMP bandwidth to/from this host should exceed this value | | threshold\_tcp\_pps | positive\_integer\_with\_zero | 100000 | TCP packet per second traffic to/from this host should exceed this value | | threshold\_udp\_pps | positive\_integer\_with\_zero | 100000 | UDP packet per second traffic to/from this host should exceed this value | | threshold\_icmp\_pps | positive\_integer\_with\_zero | 100000 | ICMP packet per second traffic to/from this host should exceed this value | | ban\_for\_tcp\_syn\_pps | bool | false | Block hosts in group for TCP SYN packets per second threshold | | threshold\_tcp\_syn\_pps | positive\_integer\_with\_zero | 1000 | TCP SYN pps to/from this host should exceed this value | | ban\_for\_tcp\_syn\_bandwidth | bool | false | Block hosts in group for TCP SYN packets per second threshold | | threshold\_tcp\_syn\_mbps | positive\_integer\_with\_zero | 1000 | TCP SYN bandwidth to/from this host should exceed this value | | ban\_for\_ip\_fragments\_pps | bool | false | Block hosts in group for fragmented IP packets per second threshold | | threshold\_ip\_fragments\_pps | positive\_integer\_with\_zero | 1000 | Fragmented IP pps to/from this host should exceed this value | | ban\_for\_ip\_fragments\_bandwidth | bool | false | Block hosts in group for fragmented IP packets per second threshold | | threshold\_ip\_fragments\_mbps | positive\_integer\_with\_zero | 1000 | fragmented IP bandwidth to/from this host should exceed this value | | enable\_ban\_incoming | bool | false | Enable ban actions for this group for incoming traffic | | enable\_ban\_outgoing | bool | false | Enable ban actions for this group for incooutgoingming traffic | | enable\_bgp\_flow\_spec | bool | false | Enable BGP Flow Spec for this hostgroup | | ban\_for\_pps\_outgoing | bool | false | Should we block host in this group if it exceeds packet per second threshold? | | ban\_for\_bandwidth\_outgoing | bool | false | Should we block host in this group if it exceeds bandwidth threshold? | | ban\_for\_flows\_outgoing | bool | false | Should we block host in this group if it exceeds flows threshold? | | threshold\_pps\_outgoing | positive\_integer\_with\_zero | 100000 | Packet per second traffic to/from this host should exceed this value | | threshold\_mbps\_outgoing | positive\_integer\_with\_zero | 1000 | Bandwidth to/from this host should exceed this value | | threshold\_flows\_outgoing | positive\_integer\_with\_zero | 3500 | Flow per second speed to/from this host should exceed this value | | ban\_for\_tcp\_bandwidth\_outgoing | bool | false | Block hosts in group for TCP bandwidth threshold? | | ban\_for\_udp\_bandwidth\_outgoing | bool | false | Block hosts in group for UDP bandwidth threshold? | | ban\_for\_icmp\_bandwidth\_outgoing | bool | false | Block hosts in group for ICMP bandwidth threshold? | | ban\_for\_tcp\_pps\_outgoing | bool | false | Should we block host in this group if it exceeds packet per second threshold for TCP? | | ban\_for\_udp\_pps\_outgoing | bool | false | Should we block host in this group if it exceeds packet per second threshold for UDP? | | ban\_for\_icmp\_pps\_outgoing | bool | false | Should we block host in this group if it exceeds packet per second threshold for ICMP? | | threshold\_tcp\_mbps\_outgoing | positive\_integer\_with\_zero | 1000 | TCP bandwidth to/from this host should exceed this value | | threshold\_udp\_mbps\_outgoing | positive\_integer\_with\_zero | 1000 | UDP bandwidth to/from this host should exceed this value | | threshold\_icmp\_mbps\_outgoing | positive\_integer\_with\_zero | 1000 | ICMP bandwidth to/from this host should exceed this value | | threshold\_tcp\_pps\_outgoing | positive\_integer\_with\_zero | 100000 | TCP packet per second traffic to/from this host should exceed this value | | threshold\_udp\_pps\_outgoing | positive\_integer\_with\_zero | 100000 | UDP packet per second traffic to/from this host should exceed this value | | threshold\_icmp\_pps\_outgoing | positive\_integer\_with\_zero | 100000 | ICMP packet per second traffic to/from this host should exceed this value | | ban\_for\_tcp\_syn\_pps\_outgoing | bool | false | Block hosts in group for TCP SYN packets per second threshold | | threshold\_tcp\_syn\_pps\_outgoing | positive\_integer\_with\_zero | 1000 | TCP SYN pps to/from this host should exceed this value | | ban\_for\_tcp\_syn\_bandwidth\_outgoing | bool | false | Block hosts in group for TCP SYN packets per second threshold | | threshold\_tcp\_syn\_mbps\_outgoing | positive\_integer\_with\_zero | 1000 | TCP SYN bandwidth to/from this host should exceed this value | | ban\_for\_ip\_fragments\_pps\_outgoing | bool | false | Block hosts in group for fragmented IP packets per second threshold | | threshold\_ip\_fragments\_pps\_outgoing | positive\_integer\_with\_zero | 1000 | Fragmented IP pps to/from this host should exceed this value | | ban\_for\_ip\_fragments\_bandwidth\_outgoing | bool | false | Block hosts in group for fragmented IP packets per second threshold | | threshold\_ip\_fragments\_mbps\_outgoing | positive\_integer\_with\_zero | 1000 | fragmented IP bandwidth to/from this host should exceed this value | | flexible\_thresholds | flexible\_thresholds | "{}" | Flexible thresholds | ## BGP configuration ### default | Name | Type | Default value | Description | |---|---|---|---| | name | string | "connection\_main\_router" | System name for this connection | | description | string | "Connection to main Router at NOC" | Human-friendly name for this connection | | local\_asn | positive\_integer\_with\_zero | 123456 | Local ASN number | | local\_address | numeric\_ipv4\_or\_ipv6\_host | "10.11.22.33" | Local address for BGP connection | | remote\_asn | positive\_integer\_with\_zero | 9002 | Remote autonomous system number | | remote\_address | numeric\_ipv4\_or\_ipv6\_host | "10.11.22.1" | Remote IP address of BGP peer | | multihop | bool | true | Enable BGP multihop option | | md5\_auth | bool | false | Enable md5 auth for BGP session | | md5\_auth\_password | string | "" | md5 password for BGP session | | ipv4\_unicast | bool | true | Enable IPv4 unicast for this peering connection | | ipv6\_unicast | bool | false | Enable IPv6 unicast for this peering connection | | ipv4\_flowspec | bool | false | Enable IPv4 Flow Spec / RFC 5575 for this peering connection | | ipv6\_flowspec | bool | false | Enable IPv6 Flow Spec / RFC 5575 for this peering connection | | active | bool | false | You could enable or disable this peer with this option | ## Traffic rules configuration ### default | Name | Type | Default value | Description | |---|---|---|---| | name | string | "" | Name for this rule | | active | bool | false | You could enable or disable rule using this flag | | description | string | "" | Human-friendly name for this rule | | source\_ports | string\_list | \[ \] | Source ports | | destination\_ports | string\_list | \[ \] | Destination ports | | packet\_lengths | string\_list | \[ \] | Packet lengths | | protocols | string\_list | \[ \] | Protocols list | | fragmentation\_flags | string\_list | \[ \] | Fragmentation flags list | | tcp\_flags | string\_list | \[ \] | TCP flags list | ## User settings ### default | Name | Type | Default value | Description | |---|---|---|---| | name | string | "admin" | Name of user | | password | string | "secure" | User password | | full\_name | string | "John Doe" | Full user name | | email | string | "admin@company-name.net" | Email of user | | role | string | "admin" | Role name of user | ## Role settings ### default | Name | Type | Default value | Description | |---|---|---|---| | name | string | "admin" | Role name | | description | string | "Full Administrator Role" | Description | | permissions | string\_list | \[ \] | List of permissions allocated for role | **Document Categories:** Maintenance operations --- ### [FastNetMon BGP Flow Spec RFC 5575 JSON representation](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-bgp-flow-spec-rfc-5575-json-representation/) **Published:** February 12, 2018 **Author:** Pavel Odintsov **Content:** FastNetMon's JSON representation format Example encoded JSON: ``` { "source_prefix": "4.0.0.0/24", "destination_prefix": "127.0.0.0/24", "destination_ports": [ 80 ], "source_ports": [ 53, 5353 ], "packet_lengths": [ 777, 1122 ], "protocols": [ "tcp" ], "fragmentation_flags": [ "is-fragment", "dont-fragment" ], "tcp_flags": [ "syn" ], "action_type": "rate-limit", "action": { "rate": 1024 } } ``` Field explanation: - source\_prefix - IPv4 network in CIDR format, optional field. - destination\_prefix - IPv4 network in CIDR format, optional field. - destination\_ports - list of destination ports (from 0 to 65535), optional field. - source\_ports - list of source ports (from 0 to 65535), optional field. - packet\_lengths - list of packet sizes (from 0 to 1500), optional field. - protocols - list of protocols (allowed options: udp, tcp, icmp, gre; full list of supported protocols you can find [here](https://fastnetmon.com/docs-fnm-advanced/protocol-names-supported-by-fastnetmon-advanced/)), optional field. - fragmentation\_flags - list of fragmentation flags (allowed values: dont-fragment, is-fragment, first-fragment, last-fragment, not-a-fragment), optional field. - tcp\_flags - list of TCP flags, allowed only when TCP is used in the protocols list. Allowed values: syn, ack, fin, urgent, push, rst. Flags also could be mixed with "\|" sign (tcp\|push). Optional field. - ttls - list of TTLs for traffic matching, non RFC compliant addition - vlans - list of vlans for traffic matching, non RFC compliant addition - action\_type - action type, allowed values: accept, discard, rate-limit, redirect, mark. - ipv4\_nexthops - list of IPs which can be used when action is set to "accept" to forward traffic to them - source\_asns - list of source ASNs, non RFC compliant addition - destination\_asns - list of destination ASNs, non RFC compliant addition - input\_interfaces - list of input interfaces, non RFC compliant addition, added in 2.0.372 - output\_interfaces - list of output interfaces, non RFC compliant addition, added in 2.0.372 - agent\_addresses - list of IPv4 addresses of agent, non RFC compliant addition, added in 2.0.372 If you are using rate-limit, you should also specify the field "rate" in the section "action". Allowed values for it are from 1 to 100000. Optional field. If you use action\_type "redirect", you should provide fields "redirect\_target\_as" (16 bit) and "redirect\_target\_value" (32 bit) in the section "action". Example redirect action: ``` sudo fcli set flowspec '{ "source_prefix": "4.0.0.0/24", "destination_prefix": "127.0.0.0/24", "destination_ports": [ 80 ], "source_ports": [ 53, 5353 ], "packet_lengths": [ 777, 1122 ], "protocols": [ "tcp" ], "fragmentation_flags": [ "is-fragment", "dont-fragment" ], "tcp_flags": [ "syn" ], "action_type": "redirect", "action": { "redirect_target_as": 65000, "redirect_target_value": 666 } }' ``` Example of redirect to IPv4 next hop announce: ``` sudo fcli set flowspec '{ "source_prefix": "4.0.0.0/32", "destination_prefix": "127.0.0.0/32", "destination_ports": [ 80 ], "source_ports": [ 53, 5353 ], "packet_lengths": [ 777, 1122 ], "protocols": [ "tcp" ], "fragmentation_flags": [ "is-fragment", "dont-fragment" ], "tcp_flags": [ "syn" ], "action_type": "accept", "ipv4_nexthops": ["11.22.33.44"] }' ``` **Document Categories:** BGP, Developer guides --- ### [sFlow, Netflow or IPFIX duplication to multiple servers](https://fastnetmon.com/docs-fnm-advanced/sflow-netflow-or-ipfix-duplication-to-multiple-servers/) **Published:** March 22, 2018 **Author:** Pavel Odintsov **Content:** If you need to feed the same sFlow, Netflow or IPFIX traffic to multiple consumers and your switch or router does not support multiple targets, we suggest using an external tool for it. One such tool we can recommend is [samplicator](https://github.com/sleinen/samplicator). You can install it in the following way: Install build dependencies: ``` sudo apt-get install -y automake gcc ``` Build tool: ``` cd /tmp git clone https://github.com/sleinen/samplicator.git cd samplicator ./autogen.sh ./configure make ``` Copy binary to /opt: ``` sudo cp samplicate /opt ``` And start it: ``` sudo /opt/samplicate -S -p 2056 8.8.8.8/2055 9.9.9.9/2055 ``` It will receive messages on port 2056 on local machine and forward to: ``` 8.8.8.8/2055 9.9.9.9/2055 ``` Flag -S is very important because it will spoof the original IP address of the router, and both recipients will see the original IPs of the router. It's crucial to do it, as for Netflow v9 and IPFIX protocols, it is a mandatory requirement, and the lack of this flag will cause traffic corruption or even collector crashes. **Document Categories:** Maintenance operations --- ### [FastNetMon baseline calculation](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-naseline-calculation/) **Published:** April 9, 2018 **Author:** Pavel Odintsov **Content:** **This logic is obsolete, please do not use it for new installations.** Please try our [new baseline ](https://fastnetmon.com/docs-fnm-advanced/automated-baseline-calculation-with-fastnetmon-advanced/)recommendation logic. Baseline calculation for FastNetMon can be slightly tricky, and we prepared scripts to improve your experience during this process. To start with, please enable [visual traffic export](https://fastnetmon.com/advanced-visual-traffic/) and enable InfluxDB support for FastNetMon. Keep it running for 2-3 days (in the best case, for one week to cover all peak hours) Then, please install dependencies for the script: ``` sudo pip3 install influxdb ``` Please download the source code from [GitHub](https://github.com/FastNetMon/influxdb_baseline): ``` wget https://raw.githubusercontent.com/FastNetMon/influxdb_baseline/main/influxdb_baseline.py ``` You need to run it this way: ``` python3 influxdb_baseline.py ``` It checks metrics for the last 3 days (you can configure it in the script) and selects more loaded hosts to use them as a threshold. It will need some time (from a few minutes to a few hours, depending on the number of hosts). Example output: ``` Extracted 64000 hosts from InfluxDB Peak values for all your hosts max_packets_outgoing 118860 max_bits_outgoing    1130431688 max_bits_incoming    940248336 max_packets_incoming 217753 ``` According to these values, it should be safe to set threshold\_mbps to 1500 and set threshold\_pps to 400000 pps. You can add 100-200% to the peak value to reduce the number of false positives. We suggest setting these values as thresholds, but keep FastNetMon in email notification mode (with BGP Blackhole disabled) for 1 week and then you can put it into production if everything works as expected. If you see zeroes in output, we recommend ensuring that you have per-host traffic export enabled the following way: ``` sudo fcli set main influxdb_skip_host_counters false sudo fcli commit ``` **Document Categories:** Maintenance operations --- ### [FastNetMon Advanced scalability](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-scalability/) **Published:** July 25, 2018 **Author:** Pavel Odintsov **Content:** We have deployments with 45 Tbps of traffic and up to 1.5 Gpps (featured in [media](https://www.theregister.com/2025/09/11/fastnetmon_ddos_attack/)) of packet rate. In Netflow/IPFIX or sFlow modes FastNetMon scales almost indefinitely. FastNetMon uses our own proprietary high optimised C++ packet parser which ensured top level performance. In port mirror / SPAN mode FastNetMon can use all your available CPU resources. You will need 2-4 CPU cores for each 10-40G port. Also, you can use kernel side sampling introduced recently and it can lower hardware requirements to 1-2 CPU cores for 40G / 100G interface with decent network card. As part of FastNetMon Advanced development we do regular load testing in lab environment and last test confirmed that FastNetMon handled 3M flows per second without performance degradation For speed calculation, FastNetMon uses only single thread by default (limited by single CPU core performance) and it may affect you in case of really big number of IPv4 hosts (tens of millions or more). In this case we recommend using [parallel traffic calculation logic](https://fastnetmon.com/2024/02/20/fastnetmon-advanced-2-0-360/) as documented here **Document Categories:** Maintenance operations --- ### [Delivering traffic information to FastNetMon over the Internet](https://fastnetmon.com/docs-fnm-advanced/delivering-traffic-information-to-fastnetmon-over-the-internet/) **Published:** September 10, 2018 **Author:** Pavel Odintsov **Content:** Default setup of FastNetMon assumes that traffic between your routers and switches and machine with FastNetMon does not leave your network premises. However, in some cases, it may be useful to send traffic information over the Internet. FastNetMon could work this way without any issues. Pay attention to the following restrictions: - Netflow/IPFIX is not an encrypted protocol and could leak sensitive data (IP addresses, port numbers, protocols) - Netflow/IPFIX are UDP-based protocols and could be dropped/corrupted during transfer The same restriction applies to sFlow v5 protocol. Furthermore, it carries even more sensitive data (including HTTP headers, session id and other very important fields) because it has the first 60-120 bytes of each Ethernet frame from your network. Proceed with necessary caution. If you could deploy IPSec/VPN or any kind of L2 link between two points, it's a recommended way to implement it. Also, BGP is very sensitive to any kind of network congestion/overload and could shut down the session between the router and FastNetMon, and all announces published by FastNetMon will be removed. So, please keep your timeouts high to avoid such cases. As an additional level of security, we suggest using md5 validation for BGP sessions from both sides. FastNetMon has complete support for this option. **Document Categories:** Maintenance operations --- ### [FastNetMon Advanced example API client to add and remove networks](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-example-api-client/) **Published:** March 24, 2018 **Author:** Pavel Odintsov **Content:** To use this example, please enable the API using this [guide](https://fastnetmon.com/advanced-api/) and install the dependencies for it: ``` sudo apt-get install -y python3-requests ``` And then download fastnetmon\_api\_client.py file from [GitHub](https://github.com/FastNetMon/fastnetmon-example-api-client-python-networks): ``` wget https://raw.githubusercontent.com/FastNetMon/fastnetmon-example-api-client-python-networks/main/fastnetmon_api_client.py ``` Enable execution flag: ``` chmod +x fastnetmon_api_client.py ``` And run it this way: ``` ./fastnetmon_api_client.py ``` Valid output looks like: ``` Add random network: 114.123.112.50/22 Correctly added new subnet Networks list with new network: {u'values': [u'114.123.112.50/22'], u'error_text': u'', u'success': True} Correctly removed new subnet ``` **Document Categories:** Developer guides --- ### [FastNetMon Advanced example API client which blocks and unblocks IP](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-example-api-client-which-blocks-and-unblocks-ip/) **Published:** March 26, 2018 **Author:** FastNetMon **Content:** This example script can create a blackhole announce, list blocked hosts and remove them using UUID lookup. To use this example, please enable the API using this [guide](https://fastnetmon.com/advanced-api/) and install the dependencies for it: ``` sudo apt-get install -y python3-requests ``` Then, download fastnetmon\_api\_client.py from [GitHub](https://github.com/FastNetMon/fastnetmon-example-api-client-python-blackhole): ``` wget https://raw.githubusercontent.com/FastNetMon/fastnetmon-example-api-client-python-blackhole/main/fastnetmon_api_client.py ``` Enable execution flag: ``` chmod +x fastnetmon_api_client.py ``` And run it in the following way: ``` ./fastnetmon_api_client.py ``` Valid output looks as follows: ``` Blackhole IP: 127.0.0.197 Correctly blackholed IP Wait 5 second to propagate changes Correctly found UUID for this IP 2518758c-a751-4984-9aeb-c5a935422e91 Correctly removed blackhole announce ``` **Document Categories:** Developer guides --- ### [FastNetMon Flow specification](https://fastnetmon.com/docs-fnm-advanced/tera-flow-capnproto-specification/) **Published:** April 12, 2020 **Author:** Pavel Odintsov **Content:** FastNetMon uses [Cap’N’Proto](https://capnproto.org/) data serialisation protocol for representing our own flow format FastNetMon Flow. You can find the current up-to-date specification below. ``` @0xa8a892437a5fd28f; struct SimplePacketType { source @0 :UInt8; sampleRatio @1 :UInt32; srcIp @2 :UInt32; dstIp @3 :UInt32; srcIpv6 @4 :Data; dstIpv6 @5 :Data; srcMac @26 :Data; dstMac @27 :Data; srcAsn @6 :UInt32; dstAsn @7 :UInt32; inputInterface @8 :UInt32; outputInterface @9 :UInt32; ipProtocolVersion @10 :UInt8; ttl @11 :UInt8; sourcePort @12 :UInt16; destinationPort @13 :UInt16; protocol @14 :UInt32; length @15 :UInt64; ipLength @28 :UInt64; numberOfPackets @16 :UInt64; flags @17 :UInt8; ipFragmented @18 :Bool; ipDontFragment @19 :Bool; tsSec @20 :Int64; tsMsec @21 :Int64; packetPayloadLength @22 :Int32; packetPayloadFullLength @23 :UInt32; packetDirection @24 :UInt8; agentIpAddress @25 :UInt32; } ``` In version 2.0.355, we added fields srcMac, dstMac, and ipLength. **Document Categories:** Developer guides --- ### [FastNetMon Advanced and Slack integration](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-and-slack-integration/) **Published:** October 31, 2022 **Author:** Pavel Odintsov **Content:** FastNetMon Advanced has complete support for native Slack alerts regarding ban and unban actions for blackhole mode. It's available starting from 2.0.328. You can enable it using the following options: ``` sudo fcli set main slack_notifications_enabled true sudo fcli set main slack_notifications_url https://hooks.slack.com/services/xxx/xxx/xxx sudo fcli set main slack_notifications_add_simple_packet_dump true sudo fcli commit ``` Example callbacks look this way: ![](https://fastnetmon.com/wp-content/uploads/2022/10/slack-1024x498.png) **Document Categories:** Attack actions --- ### [FastNetMon Advanced and Telegram integration](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-and-telegram-integration/) **Published:** November 4, 2022 **Author:** Pavel Odintsov **Content:** FastNetMon Advanced has complete support for native Telegram alerts for ban and unban actions for blackhole mode. It’s available starting from 2.0.329. To use notifications, you need to create a bot in Telegram. To [create bot](https://core.telegram.org/bots#how-do-i-create-a-bot), you will need to contact a special @[BotFather](https://t.me/botfather) account in Telegram and then follow the instructions. After this, you will need to get a user id (positive integer number) to send alerts to a specific user account or group/chat ID (negative integer number) to send alerts to a group which has multiple people. It can be done using a web client for [Telegram](https://web.telegram.org). After successful authentication, you will see these numbers in the browser's address bar (-1124297600 in the example) when you open private messages with a user or open a specific chat room: ![](https://fastnetmon.com/wp-content/uploads/2022/11/telegram-1-1024x275.png)After that, you can use these numbers for the field telegram\_notifications\_recipients. You can enable Telegram integration using the following options: ``` sudo fcli set main telegram_notifications_enabled true sudo fcli set main telegram_notifications_add_simple_packet_dump true sudo fcli set main telegram_notifications_bot_token secret_token sudo fcli set main telegram_notifications_recipients 12345 sudo fcli set main telegram_notifications_recipients -12345 sudo fcli commit ``` Example notification: ![](https://fastnetmon.com/wp-content/uploads/2022/11/Telegram-alerts.png) **Document Categories:** Attack actions --- ### [FastNetMon Advanced integration with Cloudflare Magic Transit scrubbing centre](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-integration-with-cloudflare-magic-transit-scrubbing-centre/) **Published:** November 19, 2022 **Author:** Pavel Odintsov **Content:** FastNetMon Advanced offers complete production-ready integration with a cloud DDoS scrubbing service called Magic Transit, provided by Cloudflare Inc. Cloudflare and Magic Transit are registered trademarks of Cloudflare Inc. Please check that your version of FastNetMon is 2.0.357 or newer. To use this capability, you will need to create an API key which allows you to control Magic Transit. You can do it from this page (click in the top right corner on "user" logotype, then select "My Profile". After that, on the left side select "API Tokens"). ![](https://fastnetmon.com/wp-content/uploads/2022/11/cf_tokens-1024x556.png)You need to create an API token that allows access only for Magic Transit and does not provide full control over the account. Click "Create token", then on the page bottom select "Create Custom Token" and click "Get started". - Token name: "fastnetmon" - Permissions: "Account", "Magic transit", "Edit" ![](https://fastnetmon.com/wp-content/uploads/2022/11/token_type-1024x804.png)Then continue to Summary and then "Create token". You will see a token in the format of a long, alphanumeric string; copy it. In addition to the authentication token, you will need the account ID. To get it, you need to pick any domain, and then in the right panel you will see ZoneID and AccountID. If you do not have any domains at Cloudflare, then you need to open the main dashboard and, on the left menu, select "Manage account", "Members". Then you need to check the URL in your browser: "https://dash.cloudflare.com/xxxx/members". The long xxxx sequence is your AccountID. ### How does FastNetMon scrubbing diversion automation work? When FastNetMon detects an attack against an IP address, it determines /24 prefix for the IP which is under attack and then announces it to the scrubbing centre. When the attack stops or the ban time expires, FastNetMon removes the announce from the scrubbing centre using their API. You can set a priority and weight as you wish; the next hop needs to be set to the value provided by the scrubbing centre. Then use fcli to apply the configuration instead of editing the file manually: ``` sudo fcli set plugin scrubbing_services_integration provider_name cloudflare sudo fcli set plugin scrubbing_services_integration cloudflare_api_token yyy sudo fcli set plugin scrubbing_services_integration cloudflare_account_id xxx sudo fcli set plugin scrubbing_services_integration cloudflare_next_hop 10.20.30.40 sudo fcli set plugin scrubbing_services_integration cloudflare_priority 100 sudo fcli set plugin scrubbing_services_integration cloudflare_weight 100 sudo fcli set plugin scrubbing_services_integration log_path /var/log/fastnetmon/fastnetmon_scrubbing_services_integration.log ``` Finally, configure it on the FastNetMon side to call it when FastNetMon blocks/unblocks IP: ``` sudo fcli set main notify_script_enabled enable sudo fcli set main notify_script_format json sudo fcli set main notify_script_path /opt/fastnetmon/libraries/scrubbing_services_integration_plugin/scrubbing_services_integration sudo fcli commit ``` After that, we recommend manually blocking some IP addresses from the test prefix and checking that it works as expected. You can do it this way: ``` sudo fcli set blackhole 1.2.3.4 ``` And then to unblock the list of all blocked hosts with their UUIDs: ``` sudo fcli show blackhole ``` And unblock it: ``` sudo fcli delete blackhole ``` Integration logic has very detailed logging, and you can find the log file here: /var/log/fastnetmon/fastnetmon\_scrubbing\_services\_integration.log **Document Categories:** Attack actions --- ### [FastNetMon Advanced notify script in Perl](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-notify-script-in-perl/) **Published:** December 13, 2017 **Author:** Pavel Odintsov **Content:** This script implements an example notify script in Perl, which implements a JSON interface for FastNetMon Advanced. Please note: JSON-based script uses different arguments from text text-based notify script. Please install JSON processing library for Perl: ``` sudo apt-get install -y libjson-perl ``` It prints all information received from FastNetMon to log file /tmp/fastnetmon\_notify\_script.log. You need to download it from [GitHub](https://github.com/FastNetMon/fastnetmon_notify_perl): ``` wget https://raw.githubusercontent.com/FastNetMon/fastnetmon_notify_perl/main/notify_json.pl chmod +x notify_json.pl sudo cp notify_json.pl /usr/local/bin/notify_json.pl ``` You need to use the following mode from FastNetMon to use this script properly: ``` sudo fcli set main notify_script_enabled enable sudo fcli set main notify_script_format json sudo fcli set main notify_script_path /usr/local/bin/notify_json.pl sudo fcli commit ``` For more documentation regarding JSON formats, refer to [this page](https://fastnetmon.com/fastnetmon-json-formats/). **Document Categories:** Callback scripts --- ### [FastNetMon Advanced Notify Script in Bash](https://fastnetmon.com/docs-fnm-advanced/notify-script-in-bash/) **Published:** December 14, 2017 **Author:** Pavel Odintsov **Content:** ## Deprecation notice Please note: We do **not** **recommend** using this script for new production installations as it does not support the majority of new capabilities in FastNetMon. Please use JSON-based scripts instead: [Python callback script](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-json-notify-script-in-python/) and [Perl callback script](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-notify-script-in-perl/). ## Introduction FastNetMon can call a notify script, which calls when DDoS traffic arrives. You could use it for integration with third-party applications or monitoring systems. We use mail tool, please install it before: ``` sudo apt-get install -y bsd-mailx ``` Example script provided below will send an email to the address specified inside the script: ``` #!/usr/bin/env bash # This script will get following parameters: # $1 client_ip_as_string # $2 data_direction # $3 pps_as_string # $4 action (ban or unban) email_notify="root,please_fix_this_email@domain.ru" if [ "$4" = "unban" ]; then # No details arrived to stdin here # Unban actions if used exit 0 fi # # For ban action we will receive attack details to stdin # # Please do not remove "cat" command because # FastNetMon will crash in this case (it expect read of data from script side). # if [ "$4" = "ban" ]; then cat | mail -s "FastNetMon Guard: IP $1 blocked because $2 attack with power $3 pps" $email_notify; # You can add ban code here exit 0 fi ``` Please put it to file /usr/local/bin/notify\_script.bash And set executable bit for it: ``` sudo chmod +x /usr/local/bin/notify_script.bash ``` Then open example notify script with favourite editor and specify your email in field: “email\_notify”. Then try to run it manually for ban action: ``` echo ban_details | /usr/local/bin/notify_script.bash 11.22.33.44 incoming 100500 ban ``` And try to run it manually for unban (we do not have details in this case): ``` /usr/local/bin/notify_script.bash 11.22.33.44 incoming 100500 unban ``` You should receive example emails in both cases. From FastNetMon side you need to apply the following configuration: ``` sudo fcli set main notify_script_enabled enable sudo fcli set main notify_script_path /usr/local/bin/notify_script.bash sudo fcli set main notify_script_format text sudo fcli commit ``` **Document Categories:** Callback scripts --- ### [Example web hook receiver for FastNetMon Advanced in Python](https://fastnetmon.com/docs-fnm-advanced/example-web-hook-receiver-for-fastnetmon-advanced/) **Published:** February 24, 2018 **Author:** Pavel Odintsov **Content:** This page provides example code for HTTP web server implemented in Python to test web\_hook capability in FastNetMon and return all data received from FastNetMon. Insert the following code into the file fastnetmon\_webhook\_receiver\_server.py: ``` wget https://raw.githubusercontent.com/FastNetMon/webhook_receiver_python/main/fastnetmon_webhook_receiver_server.py ``` And run it in the following way: ``` python3 fastnetmon_webhook_receiver_server.py 8080 ``` And enable FastNetMon's feature: ``` sudo fcli set main web_callback_enabled enable sudo fcli set main web_callback_url https://127.0.0.1:8080/attack/notify sudo fcli commit ``` Starting from FastNetMon 2.0.320, you will be able to use IPv6 addresses for callbacks this way: ``` sudo fcli set main web_callback_enabled enable sudo fcli set main web_callback_url https://[::1]:8080/attack/notify sudo fcli commit ``` **Document Categories:** Attack actions --- ### [FastNetMon Advanced JSON notify script in Python](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-json-notify-script-in-python/) **Published:** March 17, 2018 **Author:** Pavel Odintsov **Content:** This script implements an example notify script in Python, which implements a JSON interface for FastNetMon Advanced. This script is implemented in Python and does not need any additional libraries. You can find a detailed description of all data formats used by FastNetMon to pass information about attacks [here](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-json-formats/). It prints all information received from FastNetMon to a log file /tmp/fastnetmon\_notify\_script.log. Download an example notify script from [GitHub](https://github.com/FastNetMon/fastnetmon_notify_python "GitHub"): ``` wget https://raw.githubusercontent.com/FastNetMon/fastnetmon_notify_python/main/notify_json.py ``` Insert it into file: ``` sudo cp notify_json.py /usr/local/bin/notify_json.py ``` And set executable bit for it: ``` sudo chmod +x /usr/local/bin/notify_json.py ``` You need to use the following mode from FastNetMon to use this script properly: ``` sudo fcli set main notify_script_enabled enable sudo fcli set main notify_script_format json sudo fcli set main notify_script_path /usr/local/bin/notify_json.py sudo fcli commit ``` **Document Categories:** Callback scripts --- ### [FastNetMon e-mail notifications](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-e-mail-notification/) **Published:** April 14, 2019 **Author:** Pavel Odintsov **Content:** FastNetMon can send emails about hosts blocked using the blackhole approach, and it can send emails about each partial block rule (BGP Flow spec mode) deployed to block malicious traffic. We recommend using an SMTP server in your network to avoid issues during DDoS attacks because external connectivity may be affected by the attack, and email notification will not be sent. We strongly advise against using standard Gmail accounts for email alerts, as Google frequently blocks them, and recently, password authentication was disabled completely. You can use Google Suite services, but please add IP of server into [allow list](https://support.google.com/a/answer/60751) to avoid blocks. We recommend using the internal SMTP server to avoid potential connectivity disruption due to an attack, which will lead to an inability to send alert emails. Example configuration which includes all available options: ``` sudo fcli set main email_notifications_enabled enable sudo fcli set main email_notifications_tls enable sudo fcli set main email_notifications_auth enable sudo fcli set main email_notifications_port 587 sudo fcli set main email_notifications_host smtp.email-service.com sudo fcli set main email_notifications_from mynotificationemail@email-service.com sudo fcli set main email_notifications_username mynotificationemail@email-service.com sudo fcli set main email_notifications_password please_keep_it_secure sudo fcli set main email_notifications_recipients noc@yourcompany.com sudo fcli set main email_notifications_recipients tech@yourcompany.com ``` Then you could use this command and send a test email to the configured notification emails ``` sudo fcli set email_test ``` In case of any issues with email delivery, please check that your server has the application "msmtp" installed. Also, you may check /var/log/fastnetmon/email.log file about any error messages. You also may change default email subjects easily: ``` sudo fcli set main email_subject_blackhole_block "Our defense system blocked host {{ ip }}" sudo fcli set main email_subject_blackhole_unblock "Our defense system unblocked host {{ ip }}" sudo fcli set main email_subject_partial_block "FastNetMon partially blocked traffic for host {{ ip }}" sudo fcli commit ``` If your server uses a custom auth method, then you can specify it explicitly, but in almost all cases, you do not need to do so; the best auth method will be selected automatically: ``` sudo fcli set main email_notifications_auth_method XXX ``` Where XXX may be one of the following options: - login - plain - scram-sha-1 - cram-md5 - gssapi - external - digest-md5 - ntlm If you use self-signed certificates for your SMTP server, you will need to set this option to ignore certificate validation issues: ``` sudo fcli set main email_notifications_disable_certificate_checks true sudo fcli commit ``` By default, FastNetMon adds dump of attack's traffic but this behavior can be disabled this way: ``` sudo fcli set main email_notifications_add_simple_packet_dump false sudo fcli commit ``` In case of any issues with msmpt you can try running it directly using same syntax as FastNetMon uses internally: ``` cat message.txt | sudo msmtp -t -a default --file=/etc/fastnetmon/msmtp.conf ``` As an example, message.txt you can use: ``` To: noc@domain.net From: noc@domain.net Subject: Test . Test body ``` After running this command, please share the error message with our support team, and we will be able to advise further. On old installations which use Ubuntu or Debian, you may face issues related with AppArmor, which did not like fact that msmtp uses a non-standard configuration path and blocks execution. To address this issue, you need to do the following: ``` sudo apt-get install -y apparmor-utils sudo /usr/sbin/aa-disable msmtp ``` After that, please try sending a test email: ``` sudo fcli set email_test ``` Service specific recommendations - Zoho SMTP, default port 565 requires option tls\_starttls to be disabled explicitly and it's not supported in FastNetMon. Please use port 578 instead **Document Categories:** Attack actions --- ### [FastNetMon Radware Integration](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-radware-second-generation-integration/) **Published:** October 3, 2019 **Author:** Pavel Odintsov **Content:** You can use FastNetMon Advanced with Radware Defense Flow as a DDoS sensor. In this case, FastNetMon can detect an attack and enable mitigation using Radware DefenseFlow and APSVision over API. ### Capabilities Integration tool supports two major notification modes: - Per host attack alerts - Per [hostgroup](https://fastnetmon.com/per-hostgroup-thresholds/) attack alerts - Full IPv6 support - Baseline information For per-host attack alerts, FastNetMon can pass the following information: - Hostgroup – will be used as a protected object on the Defense Flow side - Attack’s performance - Attack’s protocol – UDP, TCP, ICMP or OTHER - Attack’s source port - Attack’s destination port - Up to 50 source hosts (/32) - Host affected by attack (/32) For per-hostgroup attacks, we provide less information as FastNetMon does not capture a sample of the attack: - Hostgroup – will be used as protected object on Defense Flow side - Attack’s performance - List of all networks which belong to the hostgroup ### Configure DefenseFlow As the first step, please [create protected object in DefenseFlow](https://support.radware.com/app/answers/answer_view/a_id/1011361/session/L2F2LzEvdGltZS8xNTMxMTQzMDAxL2dlbi8xNTMxMTQzMDAxL3NpZC9mVTZZZHVaOHlpRW55a2I2SGltdGFtSEpuMHpQTjl4OWFZTGs3MDFPVGRKcU4wQnp6TlhwYkl2c0J2aW94VE1WMHJkVXVaSmh5QlFYeTZnM3ROS1NJN1VXc3M2ZSU3RTdYWkt5QlJ3c1FKWEdPWURLTEVkelc3d2szZyUyMSUyMQ%3D%3D). Make sure to specify the protected networks in the Protected Object. ### Configure integration For configuration, we use JSON format. Please create a configuration file in /etc/fastnetmon\_radware.json with the following content: ``` { "log_path":"/tmp/fastnetmon_radware_go_notify_script.log", "vision_ip": "192.168.1.38", "vision_username": "radware", "vision_password": "radware", "skip_ssl_verification": true, "skip_source_networks": true, "pass_baseline": false, "clickhouse_host": "127.0.0.1", "clickhouse_port": 9000, "clickhouse_database": "fastnetmon", "clickhouse_user": "default", "clickhouse_password": "" } ``` We have HA support for this integration, and it can be enabled in the following way: ``` "secondary_vision": true, "secondary_vision_ip": "11.11.11.11", "secondary_vision_username": "radware", "secondary_vision_password": "secret_password", ``` You can use fcli to manage the plugin’s configuration in the following way: ``` sudo fcli set plugin radware_defense_flow vision_ip 192.168.1.38 sudo fcli set plugin radware_defense_flow vision_username admin sudo fcli set plugin radware_defense_flow vision_password radware sudo fcli set plugin radware_defense_flow log_path /tmp/fastnetmon_radware_go_notify_script.log sudo fcli set plugin radware_defense_flow skip_source_networks enable sudo fcli set plugin radware_defense_flow skip_ssl_verification enable ``` ### Configure FastNetMon for per-host callbacks Before enabling this integration, please be sure that you have configured hostgroups using our official [guide](https://fastnetmon.com/per-hostgroup-thresholds/). To enable per-host callbacks, please specify the integration tool for FastNetMon: ``` sudo fcli set main notify_script_enabled enable sudo fcli set main notify_script_format json sudo fcli set main notify_script_path /opt/fastnetmon/libraries/radware_plugin/radware_notify_script sudo fcli commit ``` To confirm proper integration, please run the example ban: ``` sudo fcli set blackhole 11.22.33.44 ``` To unban the host, please follow this process: ``` sudo fcli show blackhole ``` Then, please use UUID near the blocked host and unblock it: ``` sudo fcli delete blackhole 777f81c4-e352-4c69-a193-7a82ee429562 (please replace this UUID by real one) ``` ### Configure FastNetMon for per-hostgroup callbacks In this mode, FastNetMon will alert to DefenseFlow when total traffic to the specified hostgroup (protected object) exceeds a specified amount of traffic. ``` sudo fcli set main notify_script_hostgroup_enabled enable sudo fcli set main notify_script_hostgroup_path /opt/fastnetmon/libraries/radware_plugin/radware_notify_script sudo fcli commit ``` Run test block: ``` sudo fcli set hostgroup_block test_total_group ``` To unblock, list all blocks: ``` sudo fcli show hostgroup_block ``` And unblock it using the UUID from the previous command: ``` sudo fcli delete hostgroup_block {uuid} ``` ### Known issues In the current version of integration, DefenseFlow cannot withdraw an announce when the source networks list in the unblock callback does not match to source networks in the block callback. We suggest disabling this option for now: ``` "skip_source_networks": true ``` **Document Categories:** Attack actions --- ### [MongoDB integration with FastNetMon Advanced](https://fastnetmon.com/docs-fnm-advanced/mongodb-integration-with-fastnetmon-advanced/) **Published:** August 11, 2022 **Author:** Pavel Odintsov **Content:** FastNetMon Advanced relies on MongoDB for configuration storage. It does not store traffic here or metrics, but it stores every configuration option. MongoDB is crucial for FastNetMon to function properly. FastNetMon uses upstream version of MongoDB from [official site](https://www.mongodb.com/docs/manual/tutorial/install-mongodb-on-ubuntu/). By default, both the FastNetMon daemon and the fcli command line tool connect directly to MongoDB. Both tools use the login "fastnetmon\_user" and the password from file /etc/fastnetmon/keychain/.mongo\_fastnetmon\_password. For debugging purposes, you can log in to MongoDB with the admin password in the following way: ``` mongo admin --username administrator --password `sudo cat /etc/fastnetmon/keychain/.mongo_admin` use fastnetmon ``` For [new](https://www.mongodb.com/docs/manual/reference/program/mongo/) installations, you will need to use the mongosh tool for management: ``` mongosh --username administrator --password `sudo cat /etc/fastnetmon/keychain/.mongo_admin` use fastnetmon ``` You can log in with the same permissions as fcli, and FastNetMon use that way: ``` mongosh --username fastnetmon_user --password `sudo cat /etc/fastnetmon/keychain/.mongo_fastnetmon_password` ``` If you use FerretDB, you may need to addthe following flag: ``` --authenticationMechanism PLAIN ``` If you use a Docker-based setup, then you can get the password that way: ``` sudo cat /var/lib/fastnetmon_docker/fastnetmon/conf/keychain/.mongo_admin ``` After this, you will need to log in to the container with MongoDB: ``` sudo docker exec -ti mongo-server.networkd bash ``` And then use the commands provided above, manually setting the password into the arguments. Optionally, you can set your own connection information for MongoDB using the configuration file /etc/fastnetmon/fastnetmon.conf with the following information: ``` { "mongodb_host": "127.0.0.1", "mongodb_port": 27017, "mongodb_database_name": "fastnetmon", "mongodb_username": "fastnetmon_user", "mongodb_auth_source": "admin", "mongodb_auth_mechanism": "", "mongodb_timeout": 5, "mongodb_timeout_heavy": 95 } ``` We use different timeout mongodb\_timeout\_heavy for queries which involve the retrieval and processing of a large amount of data. For all other queries, we use mongodb\_timeout. After that, please put the password for mongodb\_username in to file /etc/fastnetmon/keychain/.mongo\_fastnetmon\_password. Starting from version 2.0.351, you can use IPv6 address in field mongodb\_host. In addition to configuration storage, FastNetMon can store attack information in JSON format. You can enable this behaviour in the following way: ``` sudo fcli set main mongo_store_attack_information true sudo fcli commit ``` Attack information will be stored in collections with names "attacks" and "mitigations". Data stored in the "attacks" collection uses [same format](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-json-formats/) as webhook callbacks and JSON callback scripts. For flow spec bans, we store data into the "mitigations" collection in the following format: ``` { "_id" : ObjectId("61254d9e09f2c264c71a152f"), "active" : true, "mitigation_source" : "automatic", "affected_host" : "0.0.0.0/32", "mitigation_type" : "flow_spec", "mitigation_uuid" : "f2411460-3904-4610-83f3-62632a9ba2a3", "details" : { "uuid" : "f2411460-3904-4610-83f3-62632a9ba2a3", "source_prefix" : "152.228.221.228/32", "destination_prefix" : "192.168.1.112/32", "destination_ports" : [ 34772 ], "source_ports" : [ 443 ], "packet_lengths" : [ 1492 ], "protocols" : [ "tcp" ], "fragmentation_flags" : [ "dont-fragment" ], "tcp_flags" : [ "ack|push" ], "action_type" : "discard", "action" : { } } } ``` For blackhole bans, we store them in the "attacks" collection using the following format for ban: ``` { _id: ObjectId('66fea5ad7695a083eb0450a8'), action: 'ban', alert_scope: 'host', attack_details: { attack_detection_source: 'manual', attack_detection_threshold: 'unknown', attack_detection_threshold_direction: 'unknown', attack_direction: 'other', attack_protocol: 'hopopt', attack_severity: 'middle', attack_type: 'unknown', attack_uuid: '6642f712-e3c4-478f-8b3d-e400d176c12d', average_incoming_flows: 0, average_incoming_pps: 0, average_incoming_traffic: 0, average_incoming_traffic_bits: 0, average_outgoing_flows: 0, average_outgoing_pps: 0, average_outgoing_traffic: 0, average_outgoing_traffic_bits: 0, host_group: 'global', host_network: '45.189.200.0/22', incoming_dropped_pps: 0, incoming_dropped_traffic: 0, incoming_dropped_traffic_bits: 0, incoming_icmp_pps: 0, incoming_icmp_traffic: 0, incoming_icmp_traffic_bits: 0, incoming_ip_fragmented_pps: 0, incoming_ip_fragmented_traffic: 0, incoming_ip_fragmented_traffic_bits: 0, incoming_syn_tcp_pps: 0, incoming_syn_tcp_traffic: 0, incoming_syn_tcp_traffic_bits: 0, incoming_tcp_pps: 0, incoming_tcp_traffic: 0, incoming_tcp_traffic_bits: 0, incoming_udp_pps: 0, incoming_udp_traffic: 0, incoming_udp_traffic_bits: 0, initial_attack_power: 0, outgoing_dropped_pps: 0, outgoing_dropped_traffic: 0, outgoing_dropped_traffic_bits: 0, outgoing_icmp_pps: 0, outgoing_icmp_traffic: 0, outgoing_icmp_traffic_bits: 0, outgoing_ip_fragmented_pps: 0, outgoing_ip_fragmented_traffic: 0, outgoing_ip_fragmented_traffic_bits: 0, outgoing_syn_tcp_pps: 0, outgoing_syn_tcp_traffic: 0, outgoing_syn_tcp_traffic_bits: 0, outgoing_tcp_pps: 0, outgoing_tcp_traffic: 0, outgoing_tcp_traffic_bits: 0, outgoing_udp_pps: 0, outgoing_udp_traffic: 0, outgoing_udp_traffic_bits: 0, parent_host_group: '', peak_attack_power: 0, protocol_version: 'IPv4', total_incoming_flows: 0, total_incoming_pps: 0, total_incoming_traffic: 0, total_incoming_traffic_bits: 0, total_outgoing_flows: 0, total_outgoing_pps: 0, total_outgoing_traffic: 0, total_outgoing_traffic_bits: 0 }, ip: '1.2.3.4' } ``` For blackhole unbans, we store it this way (starting from v2.0.367): ``` { _id: ObjectId('66fead2af5cb9c63ba0d6a3b'), action: 'unban', alert_scope: 'host', attack_details: { attack_detection_source: 'manual', attack_detection_threshold: 'unknown', attack_detection_threshold_direction: 'unknown', attack_direction: 'other', attack_protocol: 'unknown', attack_severity: 'middle', attack_type: 'unknown', attack_uuid: '4d07be25-e458-4355-952f-aad22b7bd8d7', average_incoming_flows: 0, average_incoming_pps: 0, average_incoming_traffic: 0, average_incoming_traffic_bits: 0, average_outgoing_flows: 0, average_outgoing_pps: 0, average_outgoing_traffic: 0, average_outgoing_traffic_bits: 0, host_group: 'global', host_network: '45.189.200.0/22', incoming_dropped_pps: 0, incoming_dropped_traffic: 0, incoming_dropped_traffic_bits: 0, incoming_icmp_pps: 0, incoming_icmp_traffic: 0, incoming_icmp_traffic_bits: 0, incoming_ip_fragmented_pps: 0, incoming_ip_fragmented_traffic: 0, incoming_ip_fragmented_traffic_bits: 0, incoming_syn_tcp_pps: 0, incoming_syn_tcp_traffic: 0, incoming_syn_tcp_traffic_bits: 0, incoming_tcp_pps: 0, incoming_tcp_traffic: 0, incoming_tcp_traffic_bits: 0, incoming_udp_pps: 0, incoming_udp_traffic: 0, incoming_udp_traffic_bits: 0, initial_attack_power: 0, outgoing_dropped_pps: 0, outgoing_dropped_traffic: 0, outgoing_dropped_traffic_bits: 0, outgoing_icmp_pps: 0, outgoing_icmp_traffic: 0, outgoing_icmp_traffic_bits: 0, outgoing_ip_fragmented_pps: 0, outgoing_ip_fragmented_traffic: 0, outgoing_ip_fragmented_traffic_bits: 0, outgoing_syn_tcp_pps: 0, outgoing_syn_tcp_traffic: 0, outgoing_syn_tcp_traffic_bits: 0, outgoing_tcp_pps: 0, outgoing_tcp_traffic: 0, outgoing_tcp_traffic_bits: 0, outgoing_udp_pps: 0, outgoing_udp_traffic: 0, outgoing_udp_traffic_bits: 0, parent_host_group: '', peak_attack_power: 0, protocol_version: 'IPv4', total_incoming_flows: 0, total_incoming_pps: 0, total_incoming_traffic: 0, total_incoming_traffic_bits: 0, total_outgoing_flows: 0, total_outgoing_pps: 0, total_outgoing_traffic: 0, total_outgoing_traffic_bits: 0 }, ip: '2.3.4.5' } ``` FastNetMon does not store information about the time when it discovered an attack and added it into MongoDB. But you can use the internal feature of MongoDB to retrieve this information. For example, you have this attack in MongoDB (attacks collection): ``` db.attacks.findOne() { "_id" : ObjectId("5a985f3cec7006077668a321"), "ip" : ":0001", "attack_details" : { "attack_uuid" : "e9ba83bd-389f-4332-8e2e-0300c01c839b", "attack_severity" : "middle", "attack_type" : "unknown", .... } } ``` And you can extract information when this object was added in the following way: ``` ObjectId("5a985f3cec7006077668a321").getTimestamp() ``` And it will return a timestamp object: ``` ISODate("2022-03-01T20:14:52Z") ``` FastNetMon has logic to try connecting to MongoDB multiple times, and you may find it in the log file /var/log/fastnetmon/fastnetmon.log: ``` 2022-08-11 12:28:20,459 [INFO] This is 1 try to connect to MongoDB 2022-08-11 12:28:20,459 [DEBUG] Start MongoDB connection checking 2022-08-11 12:28:20,459 [INFO] PING mongodb database fastnetmon 2022-08-11 12:28:20,460 [ERROR] Could not ping MongoDB: No suitable servers found (`serverSelectionTryOnce` set): [connection refused calling ismaster on '127.0.0.1:27017']: generic server error 2022-08-11 12:28:20,460 [INFO] Will do second try in 5 seconds 2022-08-11 12:28:25,460 [INFO] This is 2 try to connect to MongoDB 2022-08-11 12:28:25,460 [DEBUG] Start MongoDB connection checking 2022-08-11 12:28:25,460 [INFO] PING mongodb database fastnetmon 2022-08-11 12:28:25,460 [ERROR] Could not ping MongoDB: No suitable servers found (`serverSelectionTryOnce` set): [connection refused calling ismaster on '127.0.0.1:27017']: generic server error 2022-08-11 12:28:25,460 [INFO] Will do second try in 5 seconds 2022-08-11 12:28:30,460 [INFO] This is 3 try to connect to MongoDB 2022-08-11 12:28:30,460 [DEBUG] Start MongoDB connection checking 2022-08-11 12:28:30,460 [INFO] PING mongodb database fastnetmon 2022-08-11 12:28:30,461 [ERROR] Could not ping MongoDB: No suitable servers found (`serverSelectionTryOnce` set): [connection refused calling ismaster on '127.0.0.1:27017']: generic server error 2022-08-11 12:28:30,461 [INFO] Will do second try in 5 seconds ``` fcli has similar logic, and it tries multiple times to establish a connection to MongoDB: ``` sudo fcli 2022/08/11 12:48:35 We cannot establish connection with MongoDB: server selection error: context deadline exceeded, current topology: { Type: Unknown, Servers: [{ Addr: 127.0.0.1:27017, Type: Unknown, Last error: connection() error occurred during connection handshake: dial tcp 127.0.0.1:27017: connect: connection refused }, ] } Attempt number: 1 ``` To investigate the root cause of issues with MongoDB, we recommend checking the daemon status first: ``` sudo systemctl status mongod ``` The output for MongoDB instance looks like: ``` ● mongod.service - MongoDB Database Server Loaded: loaded (/lib/systemd/system/mongod.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2022-08-11 12:29:46 BST; 3s ago Docs: https://docs.mongodb.org/manual Main PID: 8921 (mongod) CGroup: /system.slice/mongod.service └─8921 /usr/bin/mongod --config /etc/mongod.conf Aug 11 12:29:46 fastlab1 systemd[1]: Started MongoDB Database Server. ``` If "Active" field differs from "active", you may have issues with MongoDB. In addition to systemd service status, you may check that MongoDB process is running: ``` ps aux|grep mongo mongodb 8921 0.3 0.2 1009456 73424 ? Ssl 12:29 0:03 /usr/bin/mongod --config /etc/mongod.conf odintsov 9465 0.0 0.0 12940 968 pts/0 S+ 12:47 0:00 grep --color=auto mongo ``` It may be useful to check your disk space usage. You need to have at least 10G of spare disk space for MongoDB to operate correctly. You can check disk space usage in the following: ``` df -h ``` To find more reasons about issues with MongoDB we recommend checking the log file /var/log/mongodb/mongod.log. In addition to the log file, you may check systemd service logs in the following way: ``` sudo journalctl -u mongod -n 1000 -f ``` In case your server runs out of disk space, MongoDB terminates its daemons to prevent data corruption, and you will need to start it again manually. You need to allocate more disk space to the server or free up existing disk space. We recommend carefully investigating which service used all the disk space to avoid similar cases in future. This can be done using the following command: ``` sudo systemctl start mongod ``` And then you need to restart FastNetMon as it depends on MongoDB: ``` sudo systemctl restart fastnetmon ``` You can check that FastNetMon is running well using the fcli command: ``` sudo fcli show total_traffic_counters ``` Modern versions of MongoDB require AVX support, and ifthe CPU on your server does not support it, it will crash with a SIGILL error such as this: ``` sudo service mongod status × mongod.service - MongoDB Database Server Loaded: loaded (/lib/systemd/system/mongod.service; enabled; vendor preset: enabled) Active: failed (Result: signal) since Thu 2023-11-09 14:56:28 UTC; 5min ago Docs: https://docs.mongodb.org/manual Process: 154878 ExecStart=/usr/bin/mongod --config /etc/mongod.conf (code=killed, signal=ILL) Main PID: 154878 (code=killed, signal=ILL) CPU: 12ms Nov 09 14:56:28 flowdetector systemd[1]: Started MongoDB Database Server. Nov 09 14:56:28 flowdetector systemd[1]: mongod.service: Main process exited, code=killed, status=4/ILL Nov 09 14:56:28 flowdetector systemd[1]: mongod.service: Failed with result 'signal'. ``` ### Upgrade procedure If you run an old version of MongoDB and you want to upgrade to the latest one, you cannot upgrade directly to the latest version due to MongoDB upgrade process constraints. You need to upgrade from version to version. Fortunately, you can skip some versions where MongoDB database format did not change. Before you start the upgrade process, we recommend doing a full backup of the VM/server and making a configuration [export](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-backup-restore/) this way. Let's assume that you run MongoDB 3.4. To upgrade to 5.0, you need to do the following upgrades: - Upgrade 3.4 to 3.6: [documentation](https://www.mongodb.com/docs/manual/release-notes/3.6-upgrade-standalone/) - Upgrade 3.6 to 4.0: [documentation](https://www.mongodb.com/docs/manual/release-notes/4.0-upgrade-standalone/) - Upgrade 4.0 to 4.2: [documentation](https://www.mongodb.com/docs/manual/release-notes/4.2-upgrade-standalone/) - Upgrade 4.2 to 4.4: [documentation](https://www.mongodb.com/docs/manual/release-notes/4.4-upgrade-standalone/) - Upgrade 4.4 to 5.0: [documentation](https://www.mongodb.com/docs/manual/release-notes/5.0-upgrade-standalone/) ### Removal of a large number of values from the configuration If you've added too many networks in configuration and are looking for an easy way to remove all of them, you can use the following command in the MongoDB client: ``` db.configuration.findOneAndUpdate({}, { $set: { networks_list: [] } }); ``` ### How to back up the entire MongoDB database? We recommend using our own [backup tool](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-backup-restore/). ``` export FASTNETMON_BACKUP_PATH=/var/backup/fastnetmon-`date +"%m-%d-%Y-%T"` sudo mkdir $FASTNETMON_BACKUP_PATH sudo mongodump  --username administrator --password `sudo cat /etc/fastnetmon/keychain/.mongo_admin` --out $FASTNETMON_BACKUP_PATH tar -cpzf ~/fastnetmon_configuration_dump.tar.gz $FASTNETMON_BACKUP_PATH ``` ### How to import a MongoDB backup? We recommend using our own [backup tool](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-backup-restore/). Proceed with caution. This command will overwrite the current configuration with data from the backup: ``` sudo mongorestore --username administrator --password `sudo cat /etc/fastnetmon/keychain/.mongo_admin`  --drop /tmp/folder_with_incompressed_backup ``` Then, ask FastNetMon to re-read the new configuration: ``` sudo fcli commit ``` ### Controlling MongoDB verbosity in logs If you find that MongoDB generates an excessive amount of log messages to /var/log/mongodb/mongod.log you can decrease the verbosity level by making the following change (adding quiet flag) in /etc/mongod.conf: ``` systemLog: destination: file logAppend: true path: /var/log/mongodb/mongod.log # Reduce logging verbosity little bit quiet: true ``` For all new installations this is default configuration. Unfortunately, this change does not stop even the latest MongoDB 6.0.13 from logging every single client connection to the log file this way: ``` {"t":{"$date":"2024-03-06T15:39:51.328+00:00"},"s":"I", "c":"-", "id":20883, "ctx":"conn11","msg":"Interrupted operation as its client disconnected","attr":{"opId":23223}} {"t":{"$date":"2024-03-06T15:39:51.772+00:00"},"s":"I", "c":"NETWORK", "id":51800, "ctx":"conn14","msg":"client metadata","attr":{"remote":"127.0.0.1:55784","client":"conn14","doc":{"driver":{"name":"mongo-go-driver","version":"v1.12.1"},"os":{"type":"linux","architecture":"amd64"},"platform":"go1.18.1"}}} {"t":{"$date":"2024-03-06T15:39:51.772+00:00"},"s":"I", "c":"NETWORK", "id":51800, "ctx":"conn13","msg":"client metadata","attr":{"remote":"127.0.0.1:55782","client":"conn13","doc":{"driver":{"name":"mongo-go-driver","version":"v1.12.1"},"os":{"type":"linux","architecture":"amd64"},"platform":"go1.18.1"}}} {"t":{"$date":"2024-03-06T15:39:51.773+00:00"},"s":"I", "c":"NETWORK", "id":51800, "ctx":"conn15","msg":"client metadata","attr":{"remote":"127.0.0.1:55796","client":"conn15","doc":{"driver":{"name":"mongo-go-driver","version":"v1.12.1"},"os":{"type":"linux","architecture":"amd64"},"platform":"go1.18.1"}}} ``` ### MongoDB logrotate configuration Please note that this change is included in FastNetMon 2.0.362 and newer releases. To address the issue with MongoDB's excessive logging, we can recommend enabling logrotate for the MongoDB log file /var/log/mongodb/mongod.log. As a first step, please makethe following changes to the MongoDB configuration file /etc/mongod.conf: ``` systemLog: destination: file logAppend: true logRotate: reopen path: /var/log/mongodb/mongod.log # Reduce logging verbosity little bit quiet: true ``` Then apply configuration changes: ``` sudo systemctl restart mongod ``` Then create the following file /etc/logrotate.d/mongodb with the following content: ``` /var/log/mongodb/mongod.log { rotate 7 daily size 1M missingok create 0600 mongodb mongodb delaycompress compress sharedscripts postrotate /bin/kill -SIGUSR1 $(pidof mongod) endscript } ``` To check that it works, you can run the following actions: ``` sudo logrotate --force /etc/logrotate.d/mongodb ``` **Document Categories:** Attack actions --- ### [FastNetMon Advanced integration with Path.net DDoS scrubbing centre](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-integration-with-path-net-ddos-scrubbing-centre/) **Published:** October 20, 2022 **Author:** Pavel Odintsov **Content:** FastNetMon Advanced offers complete, production-ready integration with the cloud DDoS scrubbing service provided by Path.net. To use this capability, you will need a username and a password for their API. Please check that your version of FastNetMon is 2.0.357 or newer. ### How does FastNetMon scrubbing centre diversion automation work? When FastNetMon detects an attack against an IP address, it determines /24 prefix for the IP which is under attack and then announces it to the scrubbing centre. When the attack stops or the ban time expires, FastNetMon removes the announce from the scrubbing centre using their API. You can use fcli to apply a configuration: ``` sudo fcli set plugin scrubbing_services_integration provider_name path sudo fcli set plugin scrubbing_services_integration path_username your_username sudo fcli set plugin scrubbing_services_integration path_password your_password sudo fcli set plugin scrubbing_services_integration log_path /var/log/fastnetmon/fastnetmon_scrubbing_services_integration.log ``` Finally, configure it on the FastNetMon side to call it when FastNetMon blocks/unblocks IP: ``` sudo fcli set main notify_script_enabled enable sudo fcli set main notify_script_format json sudo fcli set main notify_script_path /opt/fastnetmon/libraries/scrubbing_services_integration_plugin/scrubbing_services_integration sudo fcli commit ``` After this, we recommend manually blocking some IP addresses from the test prefix and checking that it works as expected. You can do it in the following way: ``` sudo fcli set blackhole 1.2.3.4 ``` To unblock, list all blocked hosts with their UUIDs: ``` sudo fcli show blackhole ``` And unblock: ``` sudo fcli delete blackhole ``` Integration logic has very detailed logging, and you can findthe log file here: /var/log/fastnetmon/fastnetmon\_scrubbing\_services\_integration.log **Document Categories:** Attack actions --- ### [FastNetMon Advanced InfluxDB integration](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-influxdb-integration/) **Published:** August 4, 2022 **Author:** Pavel Odintsov **Content:** Warning: Please note that new versions of FastNetMon Advanced do not use InfluxDB. It was replaced by [Clickhouse](https://fastnetmon.com/docs-fnm-advanced/traffic-metrics-in-clickhouse/), which is more flexible and reliable. You still can use it for existing installations, but we do not recommend using it for new installations. ### Introduction FastNetMon has very solid and extensive support for exporting metrics and alerts to InfluxDB. We recommend using our [installer tool](https://fastnetmon.com/docs-fnm-advanced/advanced-visual-traffic/) for installing and enabling integration with InfluxDB. This article will cover InfluxDB integration in detail and will provide enough information for you to integrate FastNetMon with existing or third-party installations of InfluxDB. By default, InfluxDB stores data for 7 days, but you can easily change it using this [guide](https://fastnetmon.com/docs-fnm-advanced/influxdb-data-retention-configuration/). FastNetMon can export two types of data to InfluxDB: - Traffic [metrics](https://fastnetmon.com/docs-fnm-advanced/advanced-visual-traffic/) - Attack [alerts](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-attack-notification-in-grafana/) (events) FastNetMon does not export flows as is to InfluxDB, as this database is not suitable for storing this kind of data. In this case, we recommend using [Clickhouse](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-traffic-persistency/). To enable InfluxDB integration (both for metrics and alerts), you need to enable InfluxDB integration: ``` sudo fcli set main influxdb true ``` Then you need to provide the IP address and port where you've installed InfluxDB: ``` sudo fcli set main influxdb_host 127.0.0.1 sudo fcli set main influxdb_port 8086 ``` As influxdb\_host, you can use IPv4, IPv6 address or even a hostname, which will be resolved by FastNetMon using the system resolver. IPv6 address should be provided in the following format without any square brackets: ``` sudo fcli set main influxdb_host ::1 ``` After this, you need to set the InfluxDB database name: ``` sudo fcli set main influxdb_database fastnetmon ``` By default, FastNetMon does not enable authentication for InfluxDB, but we have support for it: ``` sudo fcli set main influxdb_auth true sudo fcli set main influxdb_user fastnetmon sudo fcli set main influxdb_password secure_password ``` To create a user in the InfluxDB site, run the influx tool and run the following command: ``` CREATE USER admin WITH PASSWORD 'influxsecure999' WITH ALL PRIVILEGES ``` By default, FastNetMon exports metrics every second to offer real-time visibility, but you can control it using this option: ``` sudo fcli set main influxdb_push_period 1 ``` If you have multiple FastNetMon instances which export data to the same InfluxDB, you may consider the option to add custom tags in the following way: ``` sudo fcli set main influxdb_custom_tags true ``` Then you can add a single tag with the following name and value: ``` sudo fcli set main influxdb_tag_name server sudo fcli set main influxdb_tag_value fastnetmon5 ``` As another option, you may add any number of tags this way: ``` sudo fcli set main influxdb_tags_table foo=bar sudo fcli set main influxdb_tags_table server=superserver5 ``` To remove tag, use this command: ``` sudo fcli delete main influxdb_tags_table server ``` In addition to the option to export metrics directly into InfluxDB, we offer Kafka integration, which can be used for HA setups. You can read more details about it [here](https://fastnetmon.com/docs-fnm-advanced/traffic-export-to-influxdb-using-kafka/). To enable [attack alerts](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-attack-notification-in-grafana/) export to InfluxDB, you need to use the following options: ``` sudo fcli set main influxdb_attack_notification true ``` By default, FastNetMon exports total (IPv4, IPv6), per network (IPv4, IPv6), per host (IPv4, IPv6) and [per hostgroup](https://fastnetmon.com/docs-fnm-advanced/per-hostgroup-thresholds/) and system counters to InfluxDB. In some cases, per-host IPv4 counters generate a very significant load on the database, and we offer the option to disable per-host traffic export this way: ``` sudo fcli set main influxdb_skip_host_counters true ``` If you want to remove existing hosts' metrics data from InfluxDB to free up disk space, you can run influx tool: ``` influx -database fastnetmon ``` After this, run the following command to remove all data older than 1000 seconds (to remove all data, simply remove the where section). Run the following command: ``` delete from hosts_traffic where time > 1000s; ``` IPv6 per-host counters are enabled by defaul,t but you can disable them this way: ``` sudo fcli set main influxdb_push_host_ipv6_counters false ``` For flexible traffic counters, we offeran optional capability to export all flexible metrics to InfluxDB, which can be enabled this way: ``` sudo fcli set main influxdb_push_host_ipv4_flexible_counters true sudo fcli set main influxdb_push_host_ipv6_flexible_counters true ``` To debug any issues with InfluxDB export, we offerthe following system metrics: ``` sudo fcli show system_counters |grep influx influxdb_writes_total 9536189 influxdb_writes_failed 0 ``` If you see a significant number of influxdb\_writes\_failed it may be a sign that something is wrong with InfluxDB. First, you need to check that the daemon is running: ``` sudo systemctl status influxdb ``` Example output with correctly running InfluxDB looks like following: ``` ● influxdb.service - InfluxDB is an open-source, distributed, time series database Loaded: loaded (/lib/systemd/system/influxdb.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2022-06-24 14:11:47 UTC; 2 months 4 days ago Docs: https://docs.influxdata.com/influxdb/ Main PID: 20690 (influxd) Tasks: 16 (limit: 19189) Memory: 258.4M CGroup: /system.slice/influxdb.service └─20690 /usr/bin/influxd -config /etc/influxdb/influxdb.conf ``` In case of issues, it may provide some details about the reasons for failure. As the next step, we can recommend checking log files: ``` sudo journalctl -u influxdb -n 100 -f ``` Often InfluxDB failure is caused by a disk space shortage as it needs at least 10G or more disk space for compaction operations. You can check disk space usage in the following way: ``` df -h ``` After fixing the disk space shortage, you will need to restart the InfluxDB daemon: ``` sudo systemctl restart influxdb ``` Note: In cases of large networks, InfluxDB will need a rather long time to start, in the range of tens of minutes. To configure disk space usage for InfluxDB, we can recommend the following articles: - [InfluxDB data retention](https://fastnetmon.com/docs-fnm-advanced/influxdb-data-retention-configuration/) configuration ### How could I select the top K hosts by traffic in InfluxDB? ``` use fastnetmon select top(packets_incoming, host, 10),host from hosts_traffic where time > now() - 1h; ``` ### How could I select the top K network by traffic amount in InfluxDB? ``` use fastnetmon; select top(packets_incoming, network, 10),network from networks_traffic where time > now() - 1h; ``` ### Export of flexible traffic counters to InfluxDB You can enable this capability this way: ``` sudo fcli set main influxdb_push_host_ipv4_flexible_counters true sudo fcli set main influxdb_push_host_ipv6_flexible_counters true sudo fcli commit ``` Then you can use the following pre-defined dashboards for InfluxDB: - Flexible Traffic Counters for specific host: [dashboard](https://grafana.com/grafana/dashboards/16102) - Flexible Traffic Counters for specific hostgroup: [dashboard](https://grafana.com/grafana/dashboards/16104) **Document Categories:** Traffic reports --- ### [Per interface counters](https://fastnetmon.com/docs-fnm-advanced/per-interface-counters/) **Published:** September 18, 2023 **Author:** Pavel Odintsov **Content:** FastNetMon Advanced (from version 2.0.350) can calculate per interface bandwidth and packet rate using Netflow, IPFIX or sFlow as a source of data without any use of SNMP technology. To enable this logic, you need to use the following option: ``` sudo fcli set main enable_interface_counters true sudo fcli commit ``` After that, you will be able to see per-device / per-interface traffic: ``` sudo fcli show interface_counters ``` Example: ``` 10.1.2.1_27 in packets: 33678 out packets: 14026 in mbps: 332 out mbps: 19 10.1.2.1_64 in packets: 15536 out packets: 4337 in mbps: 153 out mbps: 5 10.1.2.1_31 in packets: 32950 out packets: 87125 in mbps: 43 out mbps: 830 ``` We have two Grafana / InfluxDB dashboards to see traffic for [all interfaces](https://drive.google.com/file/d/1gj5jSvkvhAeFY-8axb_KdAEHFH2iP2Tc/view?usp=sharing) ![](https://fastnetmon.com/wp-content/uploads/2023/09/per_interface_all_graph-1024x324.png)Or for a [particular](https://drive.google.com/file/d/1rxdcTCjj-GJ5s_T5gvYjC4lTMOmpUd9K/view?usp=sharing) interface: ![](https://fastnetmon.com/wp-content/uploads/2023/09/traffic_for_specific_interface-1024x370.png)To calculate the incoming and outgoing direction, we use the following logic: Let's assume we received traffic telemetry information about transfer of X bytes, which has input\_interface A and output\_interface B. We will count these bytes as outgoing for input\_interface A, and we will count them as incoming for output\_interface B. Netflow or IPFIX family of protocols may include packet or flow direction provided explicitly. sFlow protocol has no way to report flow / packet direction. Even if you have this information in your telemetry stream, we do not use it for this purpose. **Document Categories:** Traffic reports --- ### [Traffic Metrics in ClickHouse](https://fastnetmon.com/docs-fnm-advanced/traffic-metrics-in-clickhouse/) **Published:** December 10, 2017 **Author:** Pavel Odintsov **Content:** As an alternative to InfluxDB, traffic metrics can be stored in ClickHouse. This capability is available only for FastNetMon Advanced. In addition to our legacy / deprecated traffic metrics storage [InfluxDB](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-influxdb-integration/), we offer complete support for Clickhouse. It has many advantages over InfluxDB: - Unlimited scalability - Predictable memory usage - Clustering/redundancy support - Ability to store not only metrics but [traffic](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-traffic-persistency/), too. We recommend using Clickhouse for metrics for any network which exceeds 50.000 active hosts. To enable this capability, you will need to install [visual graphic stack](https://fastnetmon.com/docs-fnm-advanced/advanced-visual-traffic/). It will install and configure all daemons for you. To enable metrics export to Clickhouse, run the following command: ``` sudo fcli set main clickhouse_metrics true sudo fcli commit ``` After this, set the database host: ``` sudo fcli set main clickhouse_metrics_host 127.0.0.1 sudo fcli commit ``` By default, we use Clickhouse on the same machine, but for large installations, you may consider running it on another machine. In this case, you will need to set external IP address. This field supports hostnames starting from 2.0.348. You can use both IPv4 and IPv6 addresses for clickhouse\_metrics\_host. And then set port, we use native TCP/IP port for sending data to Clickhouse: ``` sudo fcli set main clickhouse_metrics_port 9000 sudo fcli commit ``` Set database name: ``` sudo fcli set main clickhouse_metrics_database fastnetmon sudo fcli commit ``` Optionally, you may set username and password: ``` sudo fcli set main clickhouse_metrics_username default sudo fcli set main clickhouse_metrics_password "" sudo fcli commit ``` You may even configure how often FastNetMon exports traffic to Clickhouse, by default, it does it every single second to provide real-time graphs: ``` sudo fcli set main clickhouse_metrics_push_period 1 sudo fcli commit ``` Starting from 2.0.378 release you can use TLS to connect to remote Clickhouse server: ``` sudo fcli set main clickhouse_metrics_tls true sudo fcli set main clickhouse_metrics_port 9440 sudo fcli commit ``` Optionally you can disable certificate validation this way: ``` sudo fcli set main clickhouse_metrics_disable_certificate_checks true ``` You can specify multiple custom CA certificates using following option: ``` sudo fcli set main clickhouse_metrics_tls_ca_paths /etc/ca.crt ``` Starting from 2.0.378 you can use client TLS certificates to connect to remote Clickhouse server: ``` sudo fcli set main clickhouse_metrics_tls_client_auth true sudo fcli set main clickhouse_metrics_tls_client_certificate_path client.crt sudo fcli set main clickhouse_metrics_tls_client_certificate_private_key_path client.key sudo fcli commit ``` FastNetMon does not rely on pre-created tables, and it can create all required tables in Clickhouse automatically for you. Clickhouse will create the following tables for metrics export: - total\_metrics, total\_metrics\_ipv4, total\_metrics\_ipv6 - network\_metrics, network\_24\_metrics\_ipv4, network\_metrics\_ipv6 - host\_metrics, host\_metrics\_ipv6 - asn\_metrics\_ipv4, asn\_metrics\_ipv6 - system\_metrics - total\_hostgroup\_metrics - interface\_metrics - flexible\_host\_metrics\_ipv4, flexible\_host\_metrics\_ipv6 - flexible\_total\_hostgroup\_metrics ### Total traffic counters schema Tables total\_metrics (IPv4+IPv6), total\_metrics\_ipv4, total\_metrics\_ipv6 share the same schema, and you can find it below: ``` CREATE TABLE fastnetmon.total_metrics ( `metricDate` Date DEFAULT toDate(metricDateTime), `metricDateTime` DateTime, `direction` String, `flows` UInt64, `packets` UInt64, `bits` UInt64, `tcp_packets` UInt64, `udp_packets` UInt64, `icmp_packets` UInt64, `fragmented_packets` UInt64, `tcp_syn_packets` UInt64, `dropped_packets` UInt64, `tcp_bits` UInt64, `udp_bits` UInt64, `icmp_bits` UInt64, `fragmented_bits` UInt64, `tcp_syn_bits` UInt64, `dropped_bits` UInt64, `schema_version` UInt8 DEFAULT 0 COMMENT '1' ) ENGINE = MergeTree PARTITION BY metricDate ORDER BY (direction, metricDate) TTL metricDate + toIntervalDay(7) SETTINGS index_granularity = 8192 ``` ### Network counters schema All three tables network\_metrics (IPv4), network\_metrics\_ipv6 and network\_24\_metrics\_ipv4 (has information only on /24 basis for IPv4 networks) share the same schema: ``` CREATE TABLE fastnetmon.network_metrics ( `metricDate` Date DEFAULT toDate(metricDateTime), `metricDateTime` DateTime, `network` String, `packets_incoming` UInt64, `packets_outgoing` UInt64, `bits_incoming` UInt64, `bits_outgoing` UInt64, `tcp_packets_incoming` UInt64, `tcp_packets_outgoing` UInt64, `udp_packets_incoming` UInt64, `udp_packets_outgoing` UInt64, `icmp_packets_incoming` UInt64, `icmp_packets_outgoing` UInt64, `fragmented_packets_incoming` UInt64, `fragmented_packets_outgoing` UInt64, `tcp_syn_packets_incoming` UInt64, `tcp_syn_packets_outgoing` UInt64, `tcp_bits_incoming` UInt64, `tcp_bits_outgoing` UInt64, `udp_bits_incoming` UInt64, `udp_bits_outgoing` UInt64, `icmp_bits_incoming` UInt64, `icmp_bits_outgoing` UInt64, `fragmented_bits_incoming` UInt64, `fragmented_bits_outgoing` UInt64, `tcp_syn_bits_incoming` UInt64, `tcp_syn_bits_outgoing` UInt64, `schema_version` UInt8 DEFAULT 0 COMMENT '1' ) ENGINE = MergeTree PARTITION BY metricDate ORDER BY (network, metricDate) TTL metricDate + toIntervalDay(7) SETTINGS index_granularity = 8192 ``` ### Per host counters schema Both tables host\_metrics (IPv4) and host\_metrics\_ipv6 use following schema: ``` CREATE TABLE fastnetmon.host_metrics_ipv6 ( `metricDate` Date DEFAULT toDate(metricDateTime), `metricDateTime` DateTime, `host` String, `packets_incoming` UInt64, `packets_outgoing` UInt64, `bits_incoming` UInt64, `bits_outgoing` UInt64, `flows_incoming` UInt64, `flows_outgoing` UInt64, `tcp_packets_incoming` UInt64, `tcp_packets_outgoing` UInt64, `udp_packets_incoming` UInt64, `udp_packets_outgoing` UInt64, `icmp_packets_incoming` UInt64, `icmp_packets_outgoing` UInt64, `fragmented_packets_incoming` UInt64, `fragmented_packets_outgoing` UInt64, `tcp_syn_packets_incoming` UInt64, `tcp_syn_packets_outgoing` UInt64, `tcp_bits_incoming` UInt64, `tcp_bits_outgoing` UInt64, `udp_bits_incoming` UInt64, `udp_bits_outgoing` UInt64, `icmp_bits_incoming` UInt64, `icmp_bits_outgoing` UInt64, `fragmented_bits_incoming` UInt64, `fragmented_bits_outgoing` UInt64, `tcp_syn_bits_incoming` UInt64, `tcp_syn_bits_outgoing` UInt64, `schema_version` UInt8 DEFAULT 0 COMMENT '2' ) ENGINE = MergeTree PARTITION BY metricDate ORDER BY (host, metricDate) TTL metricDate + toIntervalDay(7) SETTINGS index_granularity = 8192 ``` ### ASN metrics schema Both tables asn\_metrics\_ipv4 and asn\_metrics\_ipv6 share same schema: ``` CREATE TABLE fastnetmon.asn_metrics_ipv4 ( `metricDate` Date DEFAULT toDate(metricDateTime), `metricDateTime` DateTime, `asn_number` UInt64, `packets_incoming` UInt64, `packets_outgoing` UInt64, `bits_incoming` UInt64, `bits_outgoing` UInt64, `flows_incoming` UInt64, `flows_outgoing` UInt64, `tcp_packets_incoming` UInt64, `tcp_packets_outgoing` UInt64, `udp_packets_incoming` UInt64, `udp_packets_outgoing` UInt64, `icmp_packets_incoming` UInt64, `icmp_packets_outgoing` UInt64, `fragmented_packets_incoming` UInt64, `fragmented_packets_outgoing` UInt64, `tcp_syn_packets_incoming` UInt64, `tcp_syn_packets_outgoing` UInt64, `tcp_bits_incoming` UInt64, `tcp_bits_outgoing` UInt64, `udp_bits_incoming` UInt64, `udp_bits_outgoing` UInt64, `icmp_bits_incoming` UInt64, `icmp_bits_outgoing` UInt64, `fragmented_bits_incoming` UInt64, `fragmented_bits_outgoing` UInt64, `tcp_syn_bits_incoming` UInt64, `tcp_syn_bits_outgoing` UInt64, `schema_version` UInt8 DEFAULT 0 COMMENT '2' ) ENGINE = MergeTree PARTITION BY metricDate ORDER BY (asn_number, metricDate) TTL metricDate + toIntervalDay(7) SETTINGS index_granularity = 8192 ``` ### System counters schema System counters table has the following schema: ``` CREATE TABLE fastnetmon.system_metrics ( `metricDate` Date DEFAULT toDate(metricDateTime), `metricDateTime` DateTime, `name` String, `type` String, `value` UInt64, `schema_version` UInt8 DEFAULT 0 COMMENT '1' ) ENGINE = MergeTree PARTITION BY metricDate ORDER BY (name, metricDate) TTL metricDate + toIntervalDay(7) SETTINGS index_granularity = 8192 ``` ### Interface metrics schema FastNetMon stores per interface bandwidth in table interface\_metrics using the following schema: ``` CREATE TABLE fastnetmon.interface_metrics ( `metricDate` Date DEFAULT toDate(metricDateTime), `metricDateTime` DateTime, `device_ip` String, `interface_id` UInt64, `interface_name` String, `packets_incoming` UInt64, `packets_outgoing` UInt64, `bits_incoming` UInt64, `bits_outgoing` UInt64, `flows_incoming` UInt64, `flows_outgoing` UInt64, `tcp_packets_incoming` UInt64, `tcp_packets_outgoing` UInt64, `udp_packets_incoming` UInt64, `udp_packets_outgoing` UInt64, `icmp_packets_incoming` UInt64, `icmp_packets_outgoing` UInt64, `fragmented_packets_incoming` UInt64, `fragmented_packets_outgoing` UInt64, `tcp_syn_packets_incoming` UInt64, `tcp_syn_packets_outgoing` UInt64, `tcp_bits_incoming` UInt64, `tcp_bits_outgoing` UInt64, `udp_bits_incoming` UInt64, `udp_bits_outgoing` UInt64, `icmp_bits_incoming` UInt64, `icmp_bits_outgoing` UInt64, `fragmented_bits_incoming` UInt64, `fragmented_bits_outgoing` UInt64, `tcp_syn_bits_incoming` UInt64, `tcp_syn_bits_outgoing` UInt64, `schema_version` UInt8 DEFAULT 0 COMMENT '1' ) ENGINE = MergeTree PARTITION BY metricDate ORDER BY (device_ip, interface_id, metricDate) TTL metricDate + toIntervalDay(7) SETTINGS index_granularity = 8192 ``` ### Per hostgroup metrics schema To store per hostgroup metrics in table total\_hostgroup\_metrics FastNetMon uses the following schema: ``` CREATE TABLE fastnetmon.total_hostgroup_metrics ( `metricDate` Date DEFAULT toDate(metricDateTime), `metricDateTime` DateTime, `hostgroup_name` String, `packets_incoming` UInt64, `packets_outgoing` UInt64, `bits_incoming` UInt64, `bits_outgoing` UInt64, `tcp_packets_incoming` UInt64, `tcp_packets_outgoing` UInt64, `udp_packets_incoming` UInt64, `udp_packets_outgoing` UInt64, `icmp_packets_incoming` UInt64, `icmp_packets_outgoing` UInt64, `fragmented_packets_incoming` UInt64, `fragmented_packets_outgoing` UInt64, `tcp_syn_packets_incoming` UInt64, `tcp_syn_packets_outgoing` UInt64, `tcp_bits_incoming` UInt64, `tcp_bits_outgoing` UInt64, `udp_bits_incoming` UInt64, `udp_bits_outgoing` UInt64, `icmp_bits_incoming` UInt64, `icmp_bits_outgoing` UInt64, `fragmented_bits_incoming` UInt64, `fragmented_bits_outgoing` UInt64, `tcp_syn_bits_incoming` UInt64, `tcp_syn_bits_outgoing` UInt64, `schema_version` UInt8 DEFAULT 0 COMMENT '1' ) ENGINE = MergeTree PARTITION BY metricDate ORDER BY (hostgroup_name, metricDate) TTL metricDate + toIntervalDay(7) SETTINGS index_granularity = 8192 ``` ### Flexible per hostgroup metrics schema To store flexible counters, FastNetMon uses table flexible\_total\_hostgroup\_metrics with the following schema: ``` CREATE TABLE fastnetmon.flexible_total_hostgroup_metrics ( `metricDate` Date DEFAULT toDate(metricDateTime), `metricDateTime` DateTime, `hostgroup_name` String, `schema_version` UInt8 DEFAULT 0 COMMENT '1', `memcache_bits_incoming` UInt64, `memcache_bits_outgoing` UInt64, `memcache_packets_incoming` UInt64, `memcache_packets_outgoing` UInt64, `chargen_bits_incoming` UInt64, `chargen_bits_outgoing` UInt64, `chargen_packets_incoming` UInt64, `chargen_packets_outgoing` UInt64, `dns_bits_incoming` UInt64, `dns_bits_outgoing` UInt64, `dns_packets_incoming` UInt64, `dns_packets_outgoing` UInt64, `mt_winbox_bits_incoming` UInt64, `mt_winbox_bits_outgoing` UInt64, `mt_winbox_packets_incoming` UInt64, `mt_winbox_packets_outgoing` UInt64, `mt_api_bits_incoming` UInt64, `mt_api_bits_outgoing` UInt64, `mt_api_packets_incoming` UInt64, `mt_api_packets_outgoing` UInt64, `ntp_bits_incoming` UInt64, `ntp_bits_outgoing` UInt64, `ntp_packets_incoming` UInt64, `ntp_packets_outgoing` UInt64 ) ENGINE = MergeTree PARTITION BY metricDate ORDER BY (hostgroup_name, metricDate) TTL metricDate + toIntervalDay(7) SETTINGS index_granularity = 8192 ``` Please note that all prefixes for bits\_incoming, bits\_outgoing, packets\_incoming and packets\_outgoing are dynamic. They're created immediately after customer creates hostgroup. Configuration without flexible traffic counters has only the following fields inside: ``` CREATE TABLE fastnetmon.flexible_total_hostgroup_metrics ( `metricDate` Date DEFAULT toDate(metricDateTime), `metricDateTime` DateTime, `hostgroup_name` String, `schema_version` UInt8 DEFAULT 0 COMMENT '1' ) ENGINE = MergeTree PARTITION BY metricDate ORDER BY (hostgroup_name, metricDate) TTL metricDate + toIntervalDay(7) SETTINGS index_granularity = 8192 ``` ### Per host flexible counters To store flexible counters for hosts, we use tables flexible\_host\_metrics\_ipv4 and flexible\_host\_metrics\_ipv6 with the following schema: ``` CREATE TABLE fastnetmon.flexible_host_metrics_ipv6 ( `metricDate` Date DEFAULT toDate(metricDateTime), `metricDateTime` DateTime, `host` String, `schema_version` UInt8 DEFAULT 0 COMMENT '1', `memcache_bits_incoming` UInt64, `memcache_bits_outgoing` UInt64, `memcache_packets_incoming` UInt64, `memcache_packets_outgoing` UInt64, `chargen_bits_incoming` UInt64, `chargen_bits_outgoing` UInt64, `chargen_packets_incoming` UInt64, `chargen_packets_outgoing` UInt64, `dns_bits_incoming` UInt64, `dns_bits_outgoing` UInt64, `dns_packets_incoming` UInt64, `dns_packets_outgoing` UInt64, `mt_winbox_bits_incoming` UInt64, `mt_winbox_bits_outgoing` UInt64, `mt_winbox_packets_incoming` UInt64, `mt_winbox_packets_outgoing` UInt64, `mt_api_bits_incoming` UInt64, `mt_api_bits_outgoing` UInt64, `mt_api_packets_incoming` UInt64, `mt_api_packets_outgoing` UInt64, `ntp_bits_incoming` UInt64, `ntp_bits_outgoing` UInt64, `ntp_packets_incoming` UInt64, `ntp_packets_outgoing` UInt64 ) ENGINE = MergeTree PARTITION BY metricDate ORDER BY (host, metricDate) TTL metricDate + toIntervalDay(7) SETTINGS index_granularity = 8192 ``` ### Attack notifications schema To implement Grafana notification we use special table attack\_events with the following schema: ``` CREATE TABLE fastnetmon.attack_events ( `eventDate` Date DEFAULT toDate(eventDateTime), `eventDateTime` DateTime, `title` String, `text` String, `event_type` String, `ip` String ) ENGINE = MergeTree PARTITION BY eventDate ORDER BY (ip, eventDate) TTL eventDate + toIntervalDay(7) SETTINGS index_granularity = 8192 ``` To monitor that the Clickhouse export works as expected, you can check these counters: ``` sudo fcli show system_counters|grep click clickhouse_metrics_writes_total 2044855 clickhouse_metrics_writes_failed 0 ``` Clickhouse may use a significant amount of disk space, and you can find a detailed guide about ways to control [disk space](https://fastnetmon.com/docs-fnm-advanced/data-retention-for-clickhouse-persistent-data-storage/) usage by it. We offer the following dashboards, which will be installed by our installer tool automatically. Also, you could use such a query in the clickhouse-client tool to retrieve data: ``` select host, packets_incoming from fastnetmon.host_metrics where metricDate == today() AND metricDateTime >= now() - 5 order by packets_incoming desc limit 10; ``` If you use an existing installation of Clickhouse, you need to grant the following permissions for Clickhouse user: ``` SELECT,INSERT,ALTER,CREATE TABLE, CREATE DICTIONARY ``` ### Top talkers pre-calculation To provide lightning-fast reports for top talker hosts in network, FastNetMon has the ability to pre-calculate top 10 hosts which generate most traffic each second and export traffic for them to Clickhouse. This ability is enabled by default on all new installations. On old installations, you can enable it in the following way: ``` sudo fcli set main clickhouse_metrics_export_top_hosts true sudo fcli commit ``` After enabling this option, FastNetMon will create tables: - host\_metrics\_ipv4\_top - host\_metrics\_ipv6\_top These tables have schema which is identical to regular tables with traffic about hosts: ``` CREATE TABLE fastnetmon.host_metrics_ipv4_top ( `metricDate` Date DEFAULT toDate(metricDateTime), `metricDateTime` DateTime, `host` String, `packets_incoming` UInt64, `packets_outgoing` UInt64, `bits_incoming` UInt64, `bits_outgoing` UInt64, `flows_incoming` UInt64, `flows_outgoing` UInt64, `tcp_packets_incoming` UInt64, `tcp_packets_outgoing` UInt64, `udp_packets_incoming` UInt64, `udp_packets_outgoing` UInt64, `icmp_packets_incoming` UInt64, `icmp_packets_outgoing` UInt64, `fragmented_packets_incoming` UInt64, `fragmented_packets_outgoing` UInt64, `tcp_syn_packets_incoming` UInt64, `tcp_syn_packets_outgoing` UInt64, `tcp_bits_incoming` UInt64, `tcp_bits_outgoing` UInt64, `udp_bits_incoming` UInt64, `udp_bits_outgoing` UInt64, `icmp_bits_incoming` UInt64, `icmp_bits_outgoing` UInt64, `fragmented_bits_incoming` UInt64, `fragmented_bits_outgoing` UInt64, `tcp_syn_bits_incoming` UInt64, `tcp_syn_bits_outgoing` UInt64, `schema_version` UInt8 DEFAULT 0 COMMENT '2' ) ENGINE = MergeTree PARTITION BY metricDate ORDER BY (host, metricDate) TTL metricDate + toIntervalDay(7) SETTINGS index_granularity = 8192 ``` These tables are very similar to tables used to storing regular per host traffic: host\_metrics, host\_metrics\_ipv6. In these tables, FastNetMon will store top 10 hosts in each particular second. It will use 4 different approaches to calculate top talkers: - Top hosts by incoming bytes - Top hosts by incoming packets - Top hosts by outgoing bytes - Top hosts by outgoing packets If some hosts were picked up as top by more than one approach, then we will store it only once. ### Top talker networks and ASNs In similar way as for hosts starting from 2.0.375 FastNetMon can pre-calculate top talkers for ASNs and networks. This logic can be enabled this way: ``` sudo fcli set main clickhouse_metrics_export_top_networks true sudo fcli set main clickhouse_metrics_export_top_asns true ``` Then it will create tables - network\_metrics\_ipv4\_top - network\_24\_metrics\_ipv4\_top - network\_metrics\_ipv6\_top - asn\_metrics\_ipv4\_top - asn\_metrics\_ipv6\_top These tables have exactly same schema as regular tables for these entities. In these tables, FastNetMon will store top 10 entities in each particular second. It will use 4 different approaches to calculate top talkers: - Top entities by incoming bytes - Top entities by incoming packets - Top entities by outgoing bytes - Top entities by outgoing packets If some entities were picked up as top by more than one approach, then we will store it only once. ### Clickhouse password reset In some rare cases, you may need to reset the password for Clickhouse user used to access database from Grafana: ``` wget https://install.fastnetmon.com/installer -Oinstaller sudo chmod +x installer sudo ./installer -reset_clickhouse_password ``` Due to Grafana limitations and the inability to reload the datasource configuration change, you may need to run the following commands to reload the configuration: ``` sudo apt install -y sqlite3 sudo sqlite3 /var/lib/grafana/grafana.db ``` And then you will need to remove the cached datasource: ``` delete from data_source where uid = 'fastnetmonclickhouseofficialdatasourceuid'; ``` And after that, restart Grafana: ``` sudo systemctl restart grafana-server ``` After all these changes, you will be able to access Clickhouse dashboards in Grafana. **Document Categories:** Traffic reports --- ### [FastNetMon attack notification in Grafana via InfluxDB](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-attack-notification-in-grafana/) **Published:** March 26, 2018 **Author:** Pavel Odintsov **Content:** **This guide is obsolete as this capability is included in a default installation of visual traffic. In the latest version, we use Clickhouse powered notifications instead of InfluxDB.** In this guide, you can enable attack notification in FastNetMon. This guide assumes that you configured InfluxDB properly using [Visual Traffic](https://fastnetmon.com/advanced-visual-traffic/) guide. This capability is available only for FastNetMon Advanced. ![](https://fastnetmon.com/wp-content/uploads/2018/02/advanced-screen-1024x583.png)It will look like: Please open any dashboard where you need this information (we suggest using "FastNetMon Advanced Total traffic"). Then find the button with a gear symbol on top of the screen and press it. Next, select "annotations" on the left panel and press "Add Annotation Query" button. ``` Name: FastNetMonAttacks Data source: InfluxDB ``` Query: ``` select title, tags, text from events where $timeFilter ``` Field mappings: ``` Text: text Tags: tags ``` And save all changes with "Save" button on left side. You need to use the following mode from FastNetMon to enable this feature : ``` sudo fcli set main influxdb_attack_notification enable sudo fcli commit ``` Finally, please test integration using ban function for some test IP address (be careful, FastNetMon will block it!): ``` sudo fcli set blackhole 11.22.33.44 ``` **Document Categories:** Traffic reports --- ### [InfluxDB data retention configuration](https://fastnetmon.com/docs-fnm-advanced/influxdb-data-retention-configuration/) **Published:** May 3, 2018 **Author:** Pavel Odintsov **Content:** By default we keep traffic metrics in InfluxDB only for 7 days. You may increase or decrease this duration using this guide. Open command line management interface for InfluxDB: ``` influx ``` Then adjust retention using this command: ``` ALTER RETENTION POLICY "fastnetmon_default_rp" ON "fastnetmon" DURATION 31d DEFAULT ``` If you prefer to reduce disk usage then approach with removal database and then creation of new database may be better option. Delete old database (it will **remove** all data): ``` drop database fastnetmon ``` And recreate it with a new retention configuration (you can replace 7d by any value): ``` CREATE DATABASE fastnetmon WITH DURATION 7d REPLICATION 1 NAME fastnetmon_default_rp ``` After these changes, InfluxDB will automatically remove all metrics older than the specified period. If InfluxDB uses a significant amount of disk space, you can follow our [guide](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-influxdb-integration/) and suppress data export for hosts. **Document Categories:** Traffic reports --- ### [FastNetMon per protocol traffic counters in InfluxDB](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-per-protocol-traffic-counters/) **Published:** July 10, 2018 **Author:** Pavel Odintsov **Content:** Please note that this guide is InfluxDB specific In addition to the three kinds of speed (packets per second, bytes per second and flows per second) in each direction, FastNetMon calculates per-protocol counters (udp, tcp, tcp syn, fragmens). FastNetMon will export bandwidth/speed for the following types of traffic for hosts: ``` bits_incoming bits_outgoing flows_incoming flows_outgoing fragmented_bits_incoming fragmented_bits_outgoing fragmented_packets_incoming fragmented_packets_outgoing icmp_bits_incoming icmp_bits_outgoing icmp_packets_incoming icmp_packets_outgoing packets_incoming packets_outgoing tcp_bits_incoming tcp_bits_outgoing tcp_packets_incoming tcp_packets_outgoing tcp_syn_bits_incoming tcp_syn_bits_outgoing tcp_syn_packets_incoming tcp_syn_packets_outgoing udp_bits_incoming udp_bits_outgoing udp_packets_incoming udp_packets_outgoing ``` Then, to check it, please select one heavily loaded host using fcli: ``` sudo fcli show host_counters ``` Output will look like: ``` 11.22.33.44 4284 pps 44 mbps 0 flows/s 22.33.44.55 4059 pps 35 mbps 0 flows/s 55.66.77.88 2889 pps 29 mbps 0 flows/s 99.00.11.22 3423 pps 29 mbps 0 flows/s ``` Open InfluxDB client: ``` influx ``` And enter the following commands to retrieve all available counters for the specified host: ``` use fastnetmon select last(*) from hosts_traffic WHERE host = '11.22.33.44' AND time > now() - 1h; ``` And InfluxDB will return the latest data for all available counters: ``` name: hosts_traffic time last_bits_incoming last_bits_outgoing last_flows_incoming last_flows_outgoing last_fragmented_bits_incoming last_fragmented_bits_outgoing last_fragmented_packets_incoming last_fragmented_packets_outgoing last_icmp_bits_incoming last_icmp_bits_outgoing last_icmp_packets_incoming last_icmp_packets_outgoing last_packets_incoming last_packets_outgoing last_tcp_bits_incoming last_tcp_bits_outgoing last_tcp_packets_incoming last_tcp_packets_outgoing last_tcp_syn_bits_incoming last_tcp_syn_bits_outgoing last_tcp_syn_packets_incoming last_tcp_syn_packets_outgoing last_udp_bits_incoming last_udp_bits_outgoing last_udp_packets_incoming last_udp_packets_outgoing ---- ------------------ ------------------ ------------------- ------------------- ----------------------------- ----------------------------- -------------------------------- -------------------------------- ----------------------- ----------------------- -------------------------- -------------------------- --------------------- --------------------- ---------------------- ---------------------- ------------------------- ------------------------- -------------------------- -------------------------- ----------------------------- ----------------------------- ---------------------- ---------------------- ------------------------- ------------------------- 1531255903575088478 84848024 64061304 0 0 0 0 0 0 13432 64848 0 54 13925 7828 6761960 8625736 1681 1379 25632 8912 10 0 78072224 55370272 12203 6334 > ``` You can also retrieve the same information for all available networks. For networks, FastNetMon exports the same counters as for hosts, excluding flow counters: ``` bits_incoming bits_outgoing fragmented_bits_incoming fragmented_bits_outgoing fragmented_packets_incoming fragmented_packets_outgoing icmp_bits_incoming icmp_bits_outgoing icmp_packets_incoming icmp_packets_outgoing packets_incoming packets_outgoing tcp_bits_incoming tcp_bits_outgoing tcp_packets_incoming tcp_packets_outgoing tcp_syn_bits_incoming tcp_syn_bits_outgoing tcp_syn_packets_incoming tcp_syn_packets_outgoing udp_bits_incoming udp_bits_outgoing udp_packets_incoming udp_packets_outgoing ``` Select a heavily loaded network: ``` sudo fcli show network_counters ``` Example output: ``` 11.22.33.44/22 in packets: 172656 out packets: 165568 in mbps: 956 out mbps: 1000 22.33.44.55/22 in packets: 91338 out packets: 98779 in mbps: 468 out mbps: 671 66.77.88.99/22 in packets: 73421 out packets: 73215 in mbps: 375 out mbps: 433 ``` Open InfluxDB client: ``` influx ``` And enter the following commands: ``` use fastnetmon select * from networks_traffic WHERE network = '11.22.33.00/22' AND time > now() - 1h; ``` Example output: ``` name: networks_traffic time last_bits_incoming last_bits_outgoing last_fragmented_bits_incoming last_fragmented_bits_outgoing last_fragmented_packets_incoming last_fragmented_packets_outgoing last_icmp_bits_incoming last_icmp_bits_outgoing last_icmp_packets_incoming last_icmp_packets_outgoing last_packets_incoming last_packets_outgoing last_tcp_bits_incoming last_tcp_bits_outgoing last_tcp_packets_incoming last_tcp_packets_outgoing last_tcp_syn_bits_incoming last_tcp_syn_bits_outgoing last_tcp_syn_packets_incoming last_tcp_syn_packets_outgoing last_udp_bits_incoming last_udp_bits_outgoing last_udp_packets_incoming last_udp_packets_outgoing ``` To add per-protocol counters to Grafana for each host, please use the bundled dashboard "FastNetMon Advanced Traffic for specified host", click on any graph ("incoming traffic" for example), select "Edit" and select any required traffic type in "SELECT" field. [![](https://fastnetmon.com/wp-content/uploads/2018/07/grafana_per_host-1024x305.png)](https://fastnetmon.com/wp-content/uploads/2018/07/grafana_per_host.png)For per network counters, you can use "FastNetMon Advanced networks traffic" as reference. **Document Categories:** Traffic reports --- ### [Traffic export to InfluxDB using Kafka](https://fastnetmon.com/docs-fnm-advanced/traffic-export-to-influxdb-using-kafka/) **Published:** May 25, 2019 **Author:** Pavel Odintsov **Content:** For sophisticated deployments we offer option to export metrics to InfluxDB using Kafka queue engine. It may be useful in case when you need redundancy and cannot lost even single metric. FastNetMon does not support authorization or encryption, it supports only plain Kafka connection. FastNetMon does not implement batching and exports traffic for each network or host as separate message. Your consumer (we can suggest using Telegraf) should implement batching. FastNetMon does not acknowledge every sent message. This guide requires that you already enabled [InfluxDB](https://fastnetmon.com/advanced-visual-traffic/) support. You can enable Kafka export this way: ``` sudo fcli set main influxdb_kafka enable sudo fcli set main influxdb_kafka_topic fastnetmon ``` You can add multiple brokers using IP addresses or host names. Each host name can be resolved to multiple IP addresses too: ``` sudo fcli set main influxdb_kafka_brokers 10.154.0.1:9092 sudo fcli set main influxdb_kafka_brokers 10.154.0.2:9092 sudo fcli set main influxdb_kafka_brokers 10.154.0.3:9092 ``` To spread load over available partitions, we offer multiple options: ``` sudo fcli set main influxdb_kafka_partitioner random ``` FastNetMon has support for following partitioners: - random - consistent - consistent\_random - murmur2 - murmur2\_random **Document Categories:** Traffic reports --- ### [JunOS BGP configuration](https://fastnetmon.com/docs-fnm-advanced/junos-bgp-configuration/) **Published:** August 25, 2022 **Author:** Pavel Odintsov **Content:** In this guide, we will provide a detailed guide which will help you establish a BGP session between FastNetMon and JunOS / Juniper network devices. To apply commands which alter the configuration of a router, you need to be in JunOS CLI, in configure mode. To switch JunOS CLI into configure mode, you need to runthe following command: ``` configure ``` We assume that you have BGP enabled on your router, but if you configure a new router, it may be needed. ``` set routing-options router-id 192.168.1.132 set routing-options autonomous-system 65001 ``` Then you need to create a BGP peering session: ``` set protocols bgp group fastnetmon-advanced type internal set protocols bgp group fastnetmon-advanced description "Connection to FastNetMon" ``` In our example, we use iBGP, but you may use eBGP as well. On the next step, you need to set local and remote IPs (for a machine with FastNetMon installed) for this BGP session. Please ensure that each device can reach each other using these IP addresses: ``` set protocols bgp group fastnetmon-advanced local-address 192.168.1.132 set protocols bgp group fastnetmon-advanced neighbor 192.168.1.106 ``` If FastNetMon is not connected directly into router, you will need to set this option on the router: ``` set protocols bgp group fastnetmon-advanced multihop ``` If you set multihop on the router, then on FastNetMon's side, you will need to set the flag multihop for [BGP peering](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-bgp-unicast-configuration/) session too. In addition, I can recommend setting this option to simplify debugging as it will provide log entries when the BGP session goes up or down: ``` set protocols bgp group fastnetmon-advanced log-updown ``` Finally, commit changes: ``` commit ``` Then you will need to check that [BGP peering session](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-bgp-unicast-configuration/) is configured properly on FastNetMon's side. As the next step, you can run this command to check the BGP session state change with this command. To run a command which just shows information, you need to use the "quit" command to leave configuration mode. Then check the log files: ``` show log messages | last 5 ``` Example output may look like: ``` Mar 1 03:12:24 rpd[8494]: RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer 192.168.1.106 (Internal AS 65001) changed state from Established to Idle (event RecvNotify) (instance master) Mar 1 03:12:32 rpd[8494]: BGP_NLRI_MISMATCH: bgp_process_caps: mismatch NLRI with 192.168.1.106 (Internal AS 65001): peer: (16385) us: (1) (instance master) Mar 1 03:12:32 rpd[8494]: RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer 192.168.1.106 (Internal AS 65001) changed state from OpenConfirm to Established (event RecvKeepAlive) (instance master) ``` It confirms that the BGP session was successfully established between FastNetMon and GoBGP. You may check the BGP session status from FastNetMon's side this way (use IP of router here): ``` gobgp nei 192.168.1.132 ``` Example output: ``` BGP neighbor is 192.168.1.132, remote AS 65001 BGP version 4, remote router ID 192.168.1.132 BGP state = ESTABLISHED, up for 00:07:15 BGP OutQ = 0, Flops = 0 Hold time is 90, keepalive interval is 30 seconds Configured hold time is 90, keepalive interval is 30 seconds Neighbor capabilities: multiprotocol: ipv4-unicast: advertised and received ipv4-flowspec: advertised route-refresh: advertised and received extended-nexthop: advertised Local: nlri: ipv4-unicast, nexthop: ipv6 nlri: ipv4-flowspec, nexthop: ipv6 graceful-restart: received Remote: notification flag set 4-octet-as: advertised and received long-lived-graceful-restart: received cisco-route-refresh: received Message statistics: Sent Rcvd Opens: 1 1 Notifications: 0 0 Updates: 0 1 Keepalives: 15 17 Route Refresh: 0 0 Discarded: 0 0 Total: 16 19 Route statistics: Advertised: 0 Received: 0 Accepted: 0 ``` To see the BGP session status from Juniper, you can use this command (use IP of FastNetMon's machine): ``` show bgp neighbor 192.168.1.106 ``` Example output: ``` Peer: 192.168.1.106+179 AS 65001 Local: 192.168.1.132+62243 AS 65001 Description: Connection to FastNetMon Group: fastnetmon-advanced Routing-Instance: master Forwarding routing-instance: master Type: Internal State: Established Flags: Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Options: Options: Local Address: 192.168.1.132 Holdtime: 90 Preference: 170 Graceful Shutdown Receiver local-preference: 0 Number of flaps: 3 Last flap event: RecvNotify Error: 'Cease' Sent: 0 Recv: 3 Peer ID: 192.168.1.106 Local ID: 192.168.1.132 Active Holdtime: 90 Keepalive Interval: 30 Group index: 0 Peer index: 0 SNMP index: 0 I/O Session Thread: bgpio-0 State: Enabled BFD: disabled, down NLRI for restart configured on peer: inet-unicast NLRI advertised by peer: inet-unicast inet-flow NLRI for this session: inet-unicast Peer supports Refresh capability (2) Stale routes from peer are kept for: 300 Peer does not support Restarter functionality NLRI of all end-of-rib markers sent: inet-unicast Peer does not support Receiver functionality Peer does not support LLGR Restarter or Receiver functionality Peer supports 4 byte AS extension (peer-as 65001) Peer does not support Addpath NLRI that peer supports extended nexthop encoding for: inet-unicast NLRI(s) enabled for color nexthop resolution: inet-unicast Table inet.0 Bit: 20000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 0 Received prefixes: 0 Accepted prefixes: 0 Suppressed due to damping: 0 Advertised prefixes: 0 Last traffic (seconds): Received 20 Sent 13 Checked 860 Input messages: Total 29 Updates 0 Refreshes 0 Octets 551 Output messages: Total 33 Updates 0 Refreshes 0 Octets 631 Output Queue[1]: 0 (inet.0, inet-unicast) ``` To confirm that everything works fine, we recommend blocking some test host on FastNetMon's side in the following way: ``` sudo fcli set blackhole 11.22.33.44 ``` And then checking that Juniper receive it correctly (use IP of the machine with FastNetMon): ``` show route receive-protocol bgp 192.168.1.106 ``` Example output: ``` inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 11.22.33.0/24 1.2.3.4 100 ? * 11.22.33.44/32 1.2.3.4 100 ? inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) ``` This guide covers only BGP peering session setup. We did not create any filters or policies to apply a BGP blackhole. You need to do it on your own using the BGP communities provided by your ISP. **Document Categories:** BGP --- ### [FRR BGP configuration with FastNetMon](https://fastnetmon.com/docs-fnm-advanced/frr-bgp-configuration-with-fastnetmon/) **Published:** November 19, 2022 **Author:** Pavel Odintsov **Content:** In this guide, we will provide a detailed guide which will help you establish a BGP session between FastNetMon and FRR. FRR is a network routing toolkit which includes support for many routing protocols. In this guide, we will work only with the BGP protocol, and we will use Ubuntu as the platform. The very same guide should work well on the Debian platform, too. First, we need to install FRR. Unfortunately, even the latest versions of Linux distributions do not ship fresh versions of FRR, and we will use their official repository to install it. If you have FRR installed, you can skip this guide to the configuration step. Add GPG key into the trust store: ``` curl -s https://deb.frrouting.org/frr/keys.asc | sudo apt-key add - ``` Add FRR repositories into the system: ``` FRRVER="frr-stable" echo deb https://deb.frrouting.org/frr $(lsb_release -s -c) $FRRVER | sudo tee -a /etc/apt/sources.list.d/frr.list ``` Install FRR: ``` sudo apt update sudo apt install -y frr frr-pythontools ``` Enable BGP daemon: ``` sudo sed -i "s/^bgpd=no/bgpd=yes/" /etc/frr/daemons ``` Restart FRR daemons: ``` sudo systemctl restart frr ``` Check that the bgpd daemon is running: ``` ps aux|grep bgpd ``` You need to check that the following daemons are in the list of running processes: ``` root 11177 0.0 0.0 38544 2872 ? S best, = multipath, i internal, r RIB-failure, S Stale, R Removed Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path *> 11.22.33.44/32 1.2.3.4 100 0 ? Total number of prefixes 1 ``` This guide covers only BGP peering session setup. We did not create any filters or policies to apply a BGP blackhole. You need to do it on your own using the BGP communities provided by your ISP. **Document Categories:** BGP --- ### [FastNetMon BGP Peering session setup](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-bgp-peering-session-setup/) **Published:** April 7, 2023 **Author:** Pavel Odintsov **Content:** In this guide, we will configure a BGP peering session between your network equipment and FastNetMon. For this manual, you need to configure a BGP peering connection from your router side, and you need to know all the following data: - Peering IP for FastNetMon - ASN for FastNetMon - Router’s IP - Router’s ASN Please do not redistribute the full BGP table towards FastNetMon as it will require an enormous amount of memory and will take a long time to process. This information is not needed for FastNetMon operations. As a first step, please enable BGP support: ``` sudo fcli set main gobgp enable ``` Then we need to create a new BGP peering session ``` sudo fcli set bgp connection_to_my_router ``` And configure it (if you are using a different IP from management for peering, you need to configure it manually for your Ubuntu instance) ``` sudo fcli set bgp connection_to_my_router local_asn 65001 sudo fcli set bgp connection_to_my_router remote_asn 65001 sudo fcli set bgp connection_to_my_router local_address 11.22.33.44 sudo fcli set bgp connection_to_my_router remote_address 22.33.44.55 ``` If your server with FastNetMon is connected to peer through intermediate hosts, we suggest setting the BGP multi-hop feature ``` sudo fcli set bgp connection_to_my_router multihop enable ``` Then enable support for IPv4 unicast for this device explicitly when needed: ``` sudo fcli set bgp connection_to_my_router ipv4_unicast enable ``` Then enable support for IPv6 unicast for this device explicitly when needed: ``` sudo fcli set bgp connection_to_my_router ipv6_unicast enable ``` To enable BGP Flow Spec for IPv4, please use this flag: ``` sudo fcli set bgp connection_to_my_router ipv4_flowspec enable ``` Finally, enable this peering connection: ``` sudo fcli set bgp connection_to_my_router active enable ``` And then we need to commit changes to FastNetMon and the BGP daemon configuration You may add any reasonable number of BGP peers, just set a unique name for each peering session and configure all options as for the first session: ``` sudo fcli set bgp second_connection_to_my_router ``` Apply changes: ``` sudo fcli commit ``` Starting from FastNetMon 2.0.336, you can specify different local ASNs for different BGP peers. You can set up md5 password for a BGP session this way: ``` sudo fcli set bgp connection_to_my_router md5_auth true sudo fcli set bgp connection_to_my_router md5_auth_password secure_password sudo fcli commit ``` For implementing ECMP and announcing [multiple next hops](https://github.com/FastNetMon/fastnetmon_ecmp_announces) for the same prefix, you can enable the following option in the configuration. This option is available starting from 2.0.364: ``` sudo fcli set bgp connection_to_my_router ipv4_unicast_add_path true sudo fcli set bgp connection_to_my_router ipv6_unicast_add_path true sudo fcli commit ``` You can check all active outgoing announces this way: ``` gobgp global rib -a ipv4 ``` You could check the status for all neighbors this way ``` gobgp neighbor ``` You can check the peering session status this way: ``` gobgp neigh 22.33.44.55 ``` Please note that starting from 2.0.363, we added a command which allows reloading BGP settings and BGP daemon configuration without restarting FastNetMon with the commit command: ``` sudo fcli set reload_bgp ``` We have detailed BGP setup guides for the following vendors: - [Juniper](https://fastnetmon.com/docs-fnm-advanced/junos-bgp-configuration/) - [Mikrotik](https://fastnetmon.com/mikrotik-bgp-configuration/) - [FRR](https://fastnetmon.com/docs-fnm-advanced/frr-bgp-configuration-with-fastnetmon/) ### Router ID setup In the BGP protocol, we need to set identifier called "Router ID" for each router. Usually, it's public IPv4 address of local peer. For a BGP peering connection via IPv4, FastNetMon will configure the router ID using local\_address field for BGP configuration. If you would like to set the router ID to a value which is different from local\_address please use the following command: ``` sudo fcli set main gobgp_router_id 1.2.3.4 sudo fcli commit ``` For a BGP peering connection over IPv6 connection, you must specify it manually as we have no way to get it from the BGP peer configuration. **Document Categories:** BGP --- ### [Country lockdown capability](https://fastnetmon.com/docs-fnm-advanced/country-lockdown-capability/) **Published:** April 23, 2024 **Author:** Pavel Odintsov **Content:** In addition to the capability to inject [IP feeds](https://fastnetmon.com/docs-fnm-advanced/automated-bgp-feed-injection/) to BGP routing table to block them, we provide the capability to block certain countries from reaching the service. Please note that this approach can be used only for compliance reasons in regulated industries where you're certain you do not have legitimate users in the blocked countries. Please do not use this approach for DDoS mitigation purposes, as DDoS traffic is very often spoofed. It is also useful to note that the country which is the source of the attack may not have anything in common with the country where the malicious actors are located. To use this capability, please use binary rpm and deb files from this [repo](https://github.com/FastNetMon/country_lockdown/releases/tag/v0.0.2). Please note that this capability may not be included in your current license and may be subject to additional charges. To use this logic, you will need to have FastNetMon Advanced installed with an active license for it. Also, you will need to set up BGP peering session with your routers. Then you need to create a configuration file /etc/country\_lockdown.json: ``` { "geoip_path": "/usr/share/GeoIP/GeoIP2-Country.mmdb", "gobgp_api_host": "127.0.0.1:50051", "bgp_ipv4_next_hop": "10.0.0.1", "bgp_ipv4_communities": [ "900:123", "1783:9000" ], "country_block_list": [ "TV" ], "ip_allow_list": [ "202.2.96.2" ] } ``` Please note that you need to obtain MaxMind directly from them, as it's not included in our product. Alternatively, you can use data supplied by [ipinfo.io](https://ipinfo.io/). You will need to adjust the path to GeoIP2-Country.mmdb. If it differs, please check that you have logic to automatically update this file. You can find all country codes used by MaxMind on this page: <https://www.geonames.org/countries/> ip\_allow\_list list can include IP addresses from blocked countries, and it will explicitly split prefixes which include them into multiple prefixes to explicitly avoid blocking them. Please note that it may significantly increase the number of prefixes if you add many IPs to this list. After finishing the configuration, please use the file in the attachment and upload it to the server. Then you need to set the executable bit for it: ``` chmod +x country_lockdown ``` After that, you can run it, and it will announce all prefixes to block using our BGP daemon: ``` ./country_lockdown ``` Example output will be as follows: ``` ./country_lockdown 2023/06/30 18:13:44 Loaded GeoIP file: {BinaryFormatMajorVersion:2 BinaryFormatMinorVersion:0 BuildEpoch:1687446147 DatabaseType:GeoIP2-Country Description:map[en:GeoIP2 Country database] IPVersion:6 Languages:[de en es fr ja pt-BR ru zh-CN] NodeCount:977873 RecordSize:24} 2023/06/30 18:13:44 GeoIP database has correct format 2023/06/30 18:13:44 Will use next hop: 10.0.0.1 2023/06/30 18:13:44 We have 1 countries in country block list 2023/06/30 18:13:44 Loading prefixes for country code: TV 2023/06/30 18:13:47 Successfully loaded 41 prefixes which belong to this country 2023/06/30 18:13:47 Country prefixes: [5.62.56.241/32 5.62.56.242/31 5.62.58.221/32 5.62.58.222/31 14.137.42.0/24 31.42.183.228/32 45.11.240.128/26 45.42.220.0/24 45.138.10.36/30 57.70.170.0/23 57.71.64.0/20 104.28.13.128/31 104.28.13.130/32 104.28.29.83/32 104.28.29.84/32 104.28.35.98/31 104.28.72.30/31 104.28.90.84/31 104.28.125.92/31 104.28.220.236/30 104.28.220.240/31 104.28.252.236/30 104.28.252.240/31 104.167.192.0/24 136.23.10.195/32 136.23.21.19/32 140.248.20.22/31 146.75.136.22/31 146.75.160.154/31 146.75.190.28/31 172.225.62.192/27 172.225.231.96/28 172.225.245.32/28 194.50.99.228/32 194.50.111.228/32 196.48.196.0/24 196.56.196.0/24 196.197.196.0/24 196.198.196.0/24 196.199.196.0/24 202.2.96.0/19] 2023/06/30 18:13:47 We have 1 entries in allow list 2023/06/30 18:13:47 Allow list: [202.2.96.2] 2023/06/30 18:13:47 We have 2 communities in configuration 2023/06/30 18:13:47 53 prefixes to block 2023/06/30 18:13:47 Prefixes to block [5.62.56.241/32 5.62.56.242/31 5.62.58.221/32 5.62.58.222/31 14.137.42.0/24 31.42.183.228/32 45.11.240.128/26 45.42.220.0/24 45.138.10.36/30 57.70.170.0/23 57.71.64.0/20 104.28.13.128/31 104.28.13.130/32 104.28.29.83/32 104.28.29.84/32 104.28.35.98/31 104.28.72.30/31 104.28.90.84/31 104.28.125.92/31 104.28.220.236/30 104.28.220.240/31 104.28.252.236/30 104.28.252.240/31 104.167.192.0/24 136.23.10.195/32 136.23.21.19/32 140.248.20.22/31 146.75.136.22/31 146.75.160.154/31 146.75.190.28/31 172.225.62.192/27 172.225.231.96/28 172.225.245.32/28 194.50.99.228/32 194.50.111.228/32 196.48.196.0/24 196.56.196.0/24 196.197.196.0/24 196.198.196.0/24 196.199.196.0/24 202.2.96.0/31 202.2.96.3/32 202.2.96.4/30 202.2.96.8/29 202.2.96.16/28 202.2.96.32/27 202.2.96.64/26 202.2.96.128/25 202.2.97.0/24 202.2.98.0/23 202.2.100.0/22 202.2.104.0/21 202.2.112.0/20] 2023/06/30 18:13:47 Successfully connected to GoBGP 2023/06/30 18:13:47 Load all active announces 2023/06/30 18:13:47 Active announces: [] 2023/06/30 18:13:47 Finished withdrawal process 2023/06/30 18:13:47 Skipped following prefixes as already active [] 2023/06/30 18:13:47 Prepare to announce prefixes [5.62.56.241/32 5.62.56.242/31 5.62.58.221/32 5.62.58.222/31 14.137.42.0/24 31.42.183.228/32 45.11.240.128/26 45.42.220.0/24 45.138.10.36/30 57.70.170.0/23 57.71.64.0/20 104.28.13.128/31 104.28.13.130/32 104.28.29.83/32 104.28.29.84/32 104.28.35.98/31 104.28.72.30/31 104.28.90.84/31 104.28.125.92/31 104.28.220.236/30 104.28.220.240/31 104.28.252.236/30 104.28.252.240/31 104.167.192.0/24 136.23.10.195/32 136.23.21.19/32 140.248.20.22/31 146.75.136.22/31 146.75.160.154/31 146.75.190.28/31 172.225.62.192/27 172.225.231.96/28 172.225.245.32/28 194.50.99.228/32 194.50.111.228/32 196.48.196.0/24 196.56.196.0/24 196.197.196.0/24 196.198.196.0/24 196.199.196.0/24 202.2.96.0/31 202.2.96.3/32 202.2.96.4/30 202.2.96.8/29 202.2.96.16/28 202.2.96.32/27 202.2.96.64/26 202.2.96.128/25 202.2.97.0/24 202.2.98.0/23 202.2.100.0/22 202.2.104.0/21 202.2.112.0/20] 2023/06/30 18:13:47 Announce 5.62.56.241/32 2023/06/30 18:13:47 Announce 5.62.56.242/31 2023/06/30 18:13:47 Announce 5.62.58.221/32 2023/06/30 18:13:47 Announce 5.62.58.222/31 2023/06/30 18:13:47 Announce 14.137.42.0/24 2023/06/30 18:13:47 Announce 31.42.183.228/32 2023/06/30 18:13:47 Announce 45.11.240.128/26 2023/06/30 18:13:47 Announce 45.42.220.0/24 2023/06/30 18:13:47 Announce 45.138.10.36/30 2023/06/30 18:13:47 Announce 57.70.170.0/23 2023/06/30 18:13:47 Announce 57.71.64.0/20 2023/06/30 18:13:47 Announce 104.28.13.128/31 2023/06/30 18:13:47 Announce 104.28.13.130/32 2023/06/30 18:13:47 Announce 104.28.29.83/32 2023/06/30 18:13:47 Announce 104.28.29.84/32 2023/06/30 18:13:47 Announce 104.28.35.98/31 2023/06/30 18:13:47 Announce 104.28.72.30/31 2023/06/30 18:13:47 Announce 104.28.90.84/31 2023/06/30 18:13:47 Announce 104.28.125.92/31 2023/06/30 18:13:47 Announce 104.28.220.236/30 2023/06/30 18:13:47 Announce 104.28.220.240/31 2023/06/30 18:13:47 Announce 104.28.252.236/30 2023/06/30 18:13:47 Announce 104.28.252.240/31 2023/06/30 18:13:47 Announce 104.167.192.0/24 2023/06/30 18:13:47 Announce 136.23.10.195/32 2023/06/30 18:13:47 Announce 136.23.21.19/32 2023/06/30 18:13:47 Announce 140.248.20.22/31 2023/06/30 18:13:47 Announce 146.75.136.22/31 2023/06/30 18:13:47 Announce 146.75.160.154/31 2023/06/30 18:13:47 Announce 146.75.190.28/31 2023/06/30 18:13:47 Announce 172.225.62.192/27 2023/06/30 18:13:47 Announce 172.225.231.96/28 2023/06/30 18:13:47 Announce 172.225.245.32/28 2023/06/30 18:13:47 Announce 194.50.99.228/32 2023/06/30 18:13:47 Announce 194.50.111.228/32 2023/06/30 18:13:47 Announce 196.48.196.0/24 2023/06/30 18:13:47 Announce 196.56.196.0/24 2023/06/30 18:13:47 Announce 196.197.196.0/24 2023/06/30 18:13:47 Announce 196.198.196.0/24 2023/06/30 18:13:47 Announce 196.199.196.0/24 2023/06/30 18:13:47 Announce 202.2.96.0/31 2023/06/30 18:13:47 Announce 202.2.96.3/32 2023/06/30 18:13:47 Announce 202.2.96.4/30 2023/06/30 18:13:47 Announce 202.2.96.8/29 2023/06/30 18:13:47 Announce 202.2.96.16/28 2023/06/30 18:13:47 Announce 202.2.96.32/27 2023/06/30 18:13:47 Announce 202.2.96.64/26 2023/06/30 18:13:47 Announce 202.2.96.128/25 2023/06/30 18:13:47 Announce 202.2.97.0/24 2023/06/30 18:13:47 Announce 202.2.98.0/23 2023/06/30 18:13:47 Announce 202.2.100.0/22 2023/06/30 18:13:47 Announce 202.2.104.0/21 2023/06/30 18:13:47 Announce 202.2.112.0/20 2023/06/30 18:13:47 Success ``` After testing that it works as expected, you can add this tool to cron to run it every day, or you can run it manually. On each run, it will add new announcements and withdraw irrelevant/stale prefixes. You can check the list of outgoing BGP announces from our BGP daemon in the following way: ``` gobgp global rib ``` You can add example prefixes that way: ``` gobgp global rib add 8.88.88.8/24 ``` You can delete example prefixes that way: ``` gobgp global del 8.88.88.8/24 ``` **Document Categories:** BGP --- ### [FastNetMon BGP IPv6 Blackhole unicast configuration](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-ipv6-bgp-configuration/) **Published:** March 18, 2018 **Author:** Pavel Odintsov **Content:** Before starting with this guide, you need to establish a BGP peering session between FastNetMon and your network equipment using this [guide](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-bgp-peering-session-setup/). We have made multiple changes to BGP announces logic in IPv6 mode. Please ensure that you run at least 2.0.363 before starting with this guide. For this manual, you need to know the community number used for Blackhole (RFC 7999) at the router side To start with, enable BGP action for IPv6 traffic: ``` sudo fcli set main gobgp_ipv6 enable ``` To enable announces of the attacked host (/128), use this option: ``` sudo fcli set main gobgp_announce_host_ipv6 enable ``` Then specify blackhole communities used in your network (We encourage you to use the recommended [RFC 7999](https://tools.ietf.org/html/rfc7999) number, 666). Please use only 16-bit ASN numbers (< 65535) for communities here: ``` sudo fcli set main gobgp_communities_host_ipv6 65001:666 sudo fcli set main gobgp_communities_host_ipv6 65001:667 ``` Finally, configure the next hop to the required value: ``` sudo fcli set main gobgp_next_hop_host_ipv6 100::1 ``` Also, you need to enable IPv6 NLRI for a particular peer: ``` sudo fcli set bgp peer_name ipv6_unicast enable sudo flci commit ``` After this, we recommend checking that we can announce IP’s correctly. We can ban a test IP for this purpose: ``` sudo fcli set blackhole dead::beef ``` You can check all active outgoing announces in the following way: ``` gobgp global rib -a ipv6 ``` You can check the status for all neighbours in the following way: ``` gobgp neighbor ``` You can check the peering session status in the following way: ``` gobgp neigh 22.33.44.55 ``` In addition to per-host announces, FastNetMon can [announce network](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-and-bgp-traffic-diversion/) which includes host under attack. Starting from version 2.0.363 you can assign custom BGP Communities for each hostgroup in the following way: ``` sudo fcli set hostgroup aaa bgp_communities_host_ipv6 65001:671 sudo fcli set hostgroup aaa bgp_communities_subnet_ipv6 65001:672 sudo fcli commit ``` Starting from version 2.0.364, you can specify a custom next hop for announces for each hostgroup: ``` sudo fcli set hostgroup aaa bgp_next_hops_host_ipv6 ::1 sudo fcli set hostgroup aaa bgp_next_hops_subnet_ipv6 ::2 sudo fcli commit ``` Starting from version 2.0.367 you can specify a custom AS\_PATH this way: ``` sudo fcli set main gobgp_as_path_host_ipv6 12345 sudo fcli set main gobgp_as_path_host_ipv6 56789 sudo fcli commit ``` Alternatively, you can provide a custom AS\_PATH for each hostgroup: ``` sudo fcli set hostgroup global bgp_as_path_host_ipv6 12345 sudo fcli set hostgroup global bgp_as_path_host_ipv6 56789 sudo fcli commit ``` You can make such AS\_PATH manipulations for subnet announces by using gobgp\_as\_path\_subnet\_ipv6 and bgp\_as\_path\_subnet\_ipv6 as field names. **Document Categories:** BGP --- ### [Selective BGP blackhole or traffic diversion in FastNetMon Advanced](https://fastnetmon.com/docs-fnm-advanced/selective-bgp-blackhole-or-traffic-diversion-in-fastnetmon-advanced/) **Published:** March 22, 2018 **Author:** Pavel Odintsov **Content:** In this guide, we will describe the required steps to announce hosts from the first host group as /32 with a specific community (blackhole, for example) and hosts from the second host group as /24 with a different community (to redirect traffic to a scrubbing centre, for example). A host group is a group of multiple networks in CIDR format. This guide assumes that you have configured a BGP connection. Please follow [quick start](https://fastnetmon.com/advanced-quick-start/) guide for it. After configuring BGP, please disable any standard actions for BGP. We will use the notify script instead because we need custom logic: ``` sudo fcli set main gobgp_announce_host disable sudo fcli set main gobgp_announce_whole_subnet disable sudo fcli commit ``` To start with, convert (split or aggregate) all your networks in networks\_list (*sudo fcli show main networks\_list*) to /24 CIDR networks only. You can remove existing networks from this list in the following way: ``` sudo fcli delete main networks_list 11.22.33.44/32 ``` And add new ones in the following way: ``` sudo fcli set main networks_list 11.22.33.44/24 ``` After this, you need to create two host groups. First one for hosts where you need blackhole action. ``` sudo fcli set hostgroup host_to_blackhole sudo fcli set hostgroup host_to_blackhole threshold_mbps 100 sudo fcli set hostgroup host_to_blackhole ban_for_bandwidth enable sudo fcli set hostgroup host_to_blackhole enable_ban enable sudo fcli set hostgroup host_to_blackhole networks 11.22.33.44/24 ``` Second one for hosts where you need traffic diversion action: ``` sudo fcli set hostgroup host_to_scrubbing sudo fcli set hostgroup host_to_scrubbing threshold_mbps 100 sudo fcli set hostgroup host_to_scrubbing ban_for_bandwidth enable sudo fcli set hostgroup host_to_scrubbing enable_ban enable sudo fcli set hostgroup host_to_scrubbing networks 10.10.10.10/24 ``` Install JSON processing library for Perl: ``` sudo apt-get install -y libjson-perl git ``` Finally, you need to download the script from [GitHub](https://github.com/FastNetMon/selective_blackhole_traffic_diversion): ``` git clone git@github.com:FastNetMon/selective_blackhole_traffic_diversion.git cd selective_blackhole_traffic_diversion sudo cp notify_json.pl /usr/local/bin/notify_json.pl ``` And configure it for your FastNetMon instance to call it when FastNetMon detects an attack. ``` sudo fcli set main notify_script_enabled enable sudo fcli set main notify_script_format json sudo fcli set main notify_script_path /usr/local/bin/notify_json.pl sudo fcli commit ``` After initial setup, we suggest a manual check for hosts from each group and test FastNetMon's behaviour in each case. To test host from group host\_to\_blackhole: ``` sudo fcli set blackhole 11.22.33.44 ``` To test host from group host\_to\_scrubbing: ``` sudo fcli set blackhole 10.10.10.10 ``` You can debug actions from our script using this command: ``` sudo tail -f /tmp/fastnetmon_notify_script.log ``` **Document Categories:** BGP --- ### [Escalation script for FastNetMon Advanced](https://fastnetmon.com/docs-fnm-advanced/escalation-script-for-fastnetmon-advanced/) **Published:** April 9, 2018 **Author:** Pavel Odintsov **Content:** FastNetMon Advanced provides a number of options to apply different actions when it discovers a DDoS attack. Also, it provides a number of options to extend it using different approaches. In this guide, we will provide a completely working approach for implementing escalations. Using this script, you can configure FastNetMon to create a custom BGP announce for already blocked (blackholed) host when it crosses a specified ("emergency") threshold of traffic. To use this script, please configure [BGP](https://fastnetmon.com/advanced-quick-start/) Then, please enable [API](https://fastnetmon.com/advanced-api/) You need to set a secure password for API, and specify this password inside the specified script on line: "auth\_data". Please download this script from [GitHub](https://github.com/FastNetMon/blackhole-escalation-script-fastnetmon-advanced): ``` wget https://raw.githubusercontent.com/FastNetMon/blackhole-escalation-script-fastnetmon-advanced/main/escalation_to_bgp_blackhole.py chmod +x escalation_to_bgp_blackhole.py sudo cp escalation_to_bgp_blackhole.py /opt ``` Please install dependencies: ``` sudo pip install requests ``` Also, in script, change the following configuration options according to your requirements: ``` incoming_mbits_threshold = 100 outgoing_mbits_threshold = 100 incoming_packets_threshold = 2000 outgoing_packets_threshold = 2000 bgp_community = '65001:777' bgp_next_hop = '11.22.33.44' ``` Finally, please add the following cron entry in the file /etc/cron.d/escalation\_to\_bgp\_blackhole: ``` SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin * * * * * root /opt/escalation_to_bgp_blackhole.py ``` Apply changes for cron: ``` service cron restart ``` This script will run each minute, check list of all already blackholed hosts and if they exceed thresholds in script it will announce /24 subnet for them with specified nexthop and community. **Document Categories:** BGP --- ### [FastNetMon BGP IPv4 Blackhole unicast configuration](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-bgp-unicast-configuration/) **Published:** April 14, 2019 **Author:** Pavel Odintsov **Content:** Before starting with this guide, you need to establish a BGP peering session between FastNetMon and your network equipment using this [guide](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-bgp-peering-session-setup/). We made multiple changes to the BGP announce logic in subnet mode. Please [ensure](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-upgrade-procedure/) that you run at least 2.0.360 before starting with this guide. For this manual, you need to know the community number used for Blackhole (RFC 7999) at the router side Enable announces about attacked host: ``` sudo fcli set main gobgp_announce_host enable ``` Then specify blackhole communities used in your network (I personally encourage you to use recommended by [RFC 7999](https://tools.ietf.org/html/rfc7999) number, 666). Please use only 16-bit ASN numbers (< 65535) for communities here: ``` sudo fcli set main gobgp_communities_host_ipv4 65001:666 sudo fcli set main gobgp_communities_host_ipv4 65001:667 ``` Then specify the next hop only for host announces: ``` sudo fcli set main gobgp_next_hop_host_ipv4 1.2.3.4 sudo fcli commit ``` After this, it’s good to check that we can announce IPs correctly. We could ban some test IP for it ``` sudo fcli set blackhole 11.22.33.44 ``` You can check all active outgoing announces the following way: ``` gobgp global rib -a ipv4 ``` You can check status for all neighbours in the following way ``` gobgp neighbor ``` You can check the peering session status the following way: ``` gobgp neigh 22.33.44.55 ``` In addition to per host announces, FastNetMon can [announce network](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-and-bgp-traffic-diversion/) which includes host under attack. Starting from 2.0.363 you can assign custom BGP Communities for each hostgroup this way: ``` sudo fcli set hostgroup aaa bgp_communities_host_ipv4 65001:771 sudo fcli set hostgroup aaa bgp_communities_subnet_ipv4 65001:772 sudo fcli commit ``` Starting from 2.0.364 you can specify a custom next hop for announces for each hostgroup: ``` sudo fcli set hostgroup aaa bgp_next_hops_host_ipv4 1.2.3.4 sudo fcli set hostgroup aaa bgp_next_hops_subnet_ipv4 5.6.7.8 sudo fcli commit ``` Starting from 2.0.367 you can specify a custom AS\_PATH this way: ``` sudo fcli set main gobgp_as_path_host_ipv4 12345 sudo fcli set main gobgp_as_path_host_ipv4 56789 sudo fcli commit ``` Alternatively, you can provide a custom AS\_PATH for each hostgroup in the following way: ``` sudo fcli set hostgroup global bgp_as_path_host_ipv4 12345 sudo fcli set hostgroup global bgp_as_path_host_ipv4 56789 sudo fcli commit ``` **Document Categories:** BGP --- ### [Automated BGP Feed injection](https://fastnetmon.com/docs-fnm-advanced/automated-bgp-feed-injection/) **Published:** October 13, 2019 **Author:** Pavel Odintsov **Content:** FastNetMon was originally built as a tool to automatically inject BGP announces when an event (traffic spike, DoS, DDoS) happens in your network using network telemetry. Naturally, network telemetry is not required for all varieties of cases, and FastNetMon can use any external source of information to announce/withdraw BGP announces. In FastNetMon, we have solid support for BGP Unicast v4 and BGP Flow Spec protocols tested with all major vendors with a clear and flexible [API](https://fastnetmon.com/fastnetmon-developer-documentation/) and [command line interface](https://fastnetmon.com/advanced-cli-reference/). We offer an official plugin which can read data from different data sources (HTTP, HTTPS, S3-compatible storage) and create BGP announces from this feed with custom communities. We offer solid monitoring options for this plugin: - SNMP traps when the data source fails to provide data - SNMP traps when some issue happens during BGP announce/withdraw process - SNMP heartbeat to confirm that the plugin works fine - Prometheus endpoint, which exports very precise metrics about each action Our integration can sync up to hundreds of thousands of IP addresses specified as /32 without any issues. Synchronisation implementations: - When FastNetMon detects a new host in the data source, it creates BGP announces for it with a specified community - When FastNetMon detects a known (and already announced) host, then we ignore it - When a host known by FastNetMon (and announced) disappears from the dataset, we withdraw it from BGP - A special option can be used to withdraw all announces To begin, you need to download the integration tool from this [link](https://drive.google.com/file/d/1Gf0HDk7uHIWb-1VgXzV6gweh7fr4r4J8/view?usp=sharing). To use BGP Manager, you will need to configure BGP Unicast, <https://fastnetmon.com/docs-fnm-advanced/fastnetmon-bgp-unicast-configuration/> and then enable FastNetMon API: <https://fastnetmon.com/docs-fnm-advanced/advanced-api/> You need to create a configuration for daemon in /etc/bgp\_manager.json Example configuration: ``` { "region": "eu-west-1", "access_key": "secret", "secret_key": "secret", "ping_check": false, "ping_bucket_name": "ping-bucket-name", "ping_bucket_key" : "ping.txt", "iplist_bucket_name": "test-blocklist", "iplist_bucket_key": "iplist.txt", "execute_hmac_validation": false, "checksum_secret_key": "aaa", "api_user": "admin", "api_password": "your_password_replace_it", "api_host": "127.0.0.1", "api_port": 10007, "debug": false, "daemon_mode": true, "prometheus": false, "prometheus_host": ":9725", "run_delay": 5, "log_path": "/tmp/bgp_manager.log", "snmp_traps": false, "snmp_host": "127.0.0.1", "snmp_port": 162, "snmp_community": "public", "snmp_timeout": 5, "snmp_retries": 2, "snmp_global_alert_value": ".1.3.6.1.4.1.2021.251.1", "snmp_global_clear_value": ".1.3.6.1.4.1.2021.251.2", "snmp_fastnetmon_alert_value": ".1.3.6.1.4.1.2021.252.1", "snmp_fastnetmon_clear_value": ".1.3.6.1.4.1.2021.252.2", "snmp_s3_alert_value": ".1.3.6.1.4.1.2021.253.1", "snmp_s3_clear_value": ".1.3.6.1.4.1.2021.253.2", "snmp_heartbeat_value": ".1.3.6.1.4.1.2021.254.1", "snmp_heartbeat_frequency": 15 } ``` You will need to change your FastNetMon API password: api\_password, then you will need to adjust S3 region and S3 access credentials: ``` "region": "eu-west-1", "access_key": "secret", "secret_key": "secret", ``` Finally, you will need to specify the bucket and file name which has block list in text format: ``` "iplist_bucket_name": "test-blocklist", "iplist_bucket_key": "iplist.txt", ``` We expect that IP block list has only IP addresses (not prefixes) and they're delimited by newlines. To run this script, please execute the following commands: ``` chmod +x bgp_manager ./bgp_manager -configuration_path /etc/bgp_manager.json ``` This tool runs as a daemon, and it will sync blocked hosts from S3 bucket with BGP daemon. By default, it will write a log file to /tmp/bgp\_manager.log You can specify a custom BGP configuration for hosts blocked in the following way: ``` sudo fcli set main gobgp_announce_remote_host enable sudo fcli set main gobgp_next_hop_remote_host 1.0.0.0 sudo fcli set main gobgp_community_remote_host 65001:669 sudo fcli commit ``` You can check list of blocked host in the following way: ``` sudo fcli show remote_blackhole ``` We have added support to read feed from a file, and it can be activated in the following way: ``` { "data_sources": { "file": true }, "iplist_path": "/tmp/blocklist", "flush_list_option": false, "flush_list_value": "1.2.3.4", "api_user": "admin", "api_password": "your_password_replace_it", "api_host": "127.0.0.1", "api_port": 10007, "debug": false, "daemon_mode": true, "prometheus": false, "prometheus_host": ":9725", "run_delay": 5, "log_path": "/tmp/bgp_manager.log", } ``` You need to put a list of newline-separated IP addresses to file available from iplist\_path. **Document Categories:** BGP --- ### [Mikrotik BGP configuration](https://fastnetmon.com/docs-fnm-advanced/mikrotik-bgp-configuration/) **Published:** May 31, 2020 **Author:** Pavel Odintsov **Content:** In this guide we will provide detailed guide which will help to establish BGP session between FastNetMon and Mikrotik. To start configuration, please establish ssh connection with your device. If you need IPv6 support you need to enable additional package and reboot router after that: ``` /system package enable ipv6 ``` As first step, you need to create BGP instance, we use private 16 bit ASN in our tests. With 32 bit ASN you will need to follow slightly different steps: ``` /routing bgp instance set default as=65001 redistribute-static=no ``` To confirm that it was created correctly, please use this command: ``` /routing bgp instance print ``` Example output: ``` Flags: * - default, X - disabled 0 * name="default" as=65001 router-id=0.0.0.0 redistribute-connected=no redistribute-static=no redistribute-rip=no redistribute-ospf=no redistribute-other-bgp=no out-filter="" client-to-client-reflection=yes ignore-as-path-len=no routing-table="" ``` As next step, we will create peer for FastNetMon which supports IPv4 and IPv6 unicast families. Please replace 192.168.1.134 by address of machine with FastNetMon: ``` /routing bgp peer add remote-address=192.168.1.134 remote-as=65001 address-families=ip,ipv6 ``` Then check configuration of created peer: ``` /routing bgp peer print ``` Example output: ``` Flags: X - disabled, E - established # INSTANCE REMOTE-ADDRESS REMOTE-AS 0 default 192.168.1.134 65001 ``` Check peer status using this command: ``` /routing bgp peer print status ``` Example output: ``` Flags: X - disabled, E - established 0 name="peer1" instance=default remote-address=192.168.1.134 remote-as=65001 tcp-md5-key="" nexthop-choice=default multihop=no route-reflect=no hold-time=3m ttl=255 in-filter="" out-filter="" address-families=ip,ipv6 default-originate=never remove-private-as=no as-override=no passive=no use-bfd=no state=opensent ``` You need to look on "state=..." it should be "Established" for a properly configured BGP session. As next step, we need to configure FastNetMon's BGP session (please replace ASN number by your real ASN and replace "192.168.1.188" by IP address of Mikrotik): ``` sudo fcli set main gobgp enable sudo fcli set bgp connection_to_my_router sudo fcli set bgp connection_to_my_router local_asn 65001 sudo fcli set bgp connection_to_my_router remote_asn 65001 sudo fcli set bgp connection_to_my_router local_address 192.168.1.134 sudo fcli set bgp connection_to_my_router remote_address 192.168.1.188 sudo fcli set bgp connection_to_my_router ipv4_unicast enable sudo fcli set bgp connection_to_my_router active enable sudo fcli commit ``` After that, you can check status of session from FastNetMon: ``` gobgp nei 192.168.1.188 BGP neighbor is 192.168.1.188, remote AS 65001 BGP version 4, remote router ID 10.0.0.1 BGP state = ESTABLISHED, up for 00:00:22 BGP OutQ = 0, Flops = 0 Hold time is 90, keepalive interval is 30 seconds Configured hold time is 90, keepalive interval is 30 seconds Neighbor capabilities: multiprotocol: ipv4-unicast: advertised and received ipv4-flowspec: advertised route-refresh: advertised and received 4-octet-as: advertised and received Message statistics: Sent Rcvd Opens: 1 1 Notifications: 0 0 Updates: 0 0 Keepalives: 1 1 Route Refresh: 0 0 Discarded: 0 0 Total: 2 2 Route statistics: Advertised: 0 Received: 0 Accepted: ``` BGP state should be ESTABLISHED and on lines about ipv4-unicast you will see advertised and received. As next step, we need to check BGP status on Mikrotik again using command: ``` /routing bgp peer print status ``` Example output: ``` Flags: X - disabled, E - established 0 E name="peer1" instance=default remote-address=192.168.1.134 remote-as=65001 tcp-md5-key="" nexthop-choice=default multihop=no route-reflect=no hold-time=3m ttl=255 in-filter="" out-filter="" address-families=ip,ipv6 default-originate=never remove-private-as=no as-override=no passive=no use-bfd=no remote-id=192.168.1.134 local-address=192.168.1.188 uptime=3s prefix-count=0 updates-sent=0 updates-received=0 withdrawn-sent=0 withdrawn-received=0 remote-hold-time=1m30s used-hold-time=1m30s used-keepalive-time=30s refresh-capability=yes as4-capability=yes state=established ``` For correctly established session you will see state=established. That's great success. After making example blackhole announce from FastNetMon you can confirm that it was received this way: ``` /ip route print detail ``` Example output (we've announces 11.22.33.0/24 and 11.22.33.44/32 from FastNetMon): ``` Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit 0 A S dst-address=0.0.0.0/0 gateway=192.168.1.254 gateway-status=192.168.1.254 reachable via ether1 distance=1 scope=30 target-scope=10 1 DC dst-address=10.0.0.0/24 pref-src=10.0.0.1 gateway=ether2 gateway-status=ether2 unreachable distance=255 scope=10 2 ADb dst-address=11.22.33.0/24 gateway=192.168.1.134 gateway-status=192.168.1.134 reachable via ether1 distance=200 scope=40 target-scope=30 bgp-local-pref=100 bgp-origin=incomplete bgp-communities=65001:667 received-from=peer1 3 ADb dst-address=11.22.33.44/32 gateway=192.168.1.134 gateway-status=192.168.1.134 reachable via ether1 distance=200 scope=40 target-scope=30 bgp-local-pref=100 bgp-origin=incomplete bgp-communities=65001:668 received-from=peer1 4 ADC dst-address=192.168.1.0/24 pref-src=192.168.1.188 gateway=ether1 gateway-status=ether1 reachable distance=0 scope=10 ``` **Document Categories:** BGP --- ### [FastNetMon Advanced per-host hostgroups](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-per-host-hostgroups/) **Published:** August 22, 2022 **Author:** Pavel Odintsov **Content:** On this page, you will learn about the options to set custom per-host thresholds for specific IPv4 or IPv6 prefixes in your networks. By default, FastNetMon uses the same thresholds for all hosts in your network. They're configured using a special hostgroup with the name "global". It's special in a way that it includes all networks added to networks\_list, and you do not need to add any networks for it. All recommendations (excluding the requirement to add any hosts to networks list) on this page can be applied to the "global" hostgroup. It may be possible to use the same thresholds for all hosts, but in many cases, you will need to have multiple levels for different groups of hosts. Most common cases are: - Business customers - Caches from content providers - NAT pools FastNetMon allows you to create a nearly unlimited number of so-called hostgroups and set custom threshold values for each of them. Name of hostgroup can only consist of Latin letters (uppercase and lowercase), numbers and symbols "-" and "\_". We do not recommend using a very large number of them, as it will make maintenance and configuration more complicated. We recommend keeping around 5-7 hostgroups to reflect the most popular traffic generation profiles. To create a custom hostgroup, you can use the following command: ``` sudo fcli set hostgroup my_new_group ``` After this, you need to set the type for it, to reflect the fact that it will apply on a per-host basis only: ``` sudo fcli set hostgroup my_new_group calculation_method per_host ``` As the next step, you can add any number of IPv4 or IPv6 prefixes for hostgroups: ``` sudo fcli set hostgroup my_new_group networks 11.22.33.44/24 sudo fcli set hostgroup my_new_group networks 10.10.10.0/24 sudo fcli set hostgroup my_new_group networks beef::1/64 ``` On this step, ensure that all these networks were added to networks\_list as documented in this [quick start](https://fastnetmon.com/docs-fnm-advanced/advanced-quick-start/) guide. To remove a network, use the following command: ``` sudo fcli delete hostgroup my_new_group networks 11.22.33.44/24 ``` After this, set required thresholds for incoming traffic from all available [threshold types](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-threshold-types/): ``` sudo fcli set hostgroup my_new_group ban_for_bandwidth enable sudo fcli set hostgroup my_new_group threshold_mbps 200 ``` To enable any attack actions (incoming or outgoing), enable ban for this hostgroup globally: ``` sudo fcli set hostgroup my_new_group enable_ban enable ``` You may keep enable\_ban disabled, and in this case, FastNetMon will not trigger any attacks for IP addresses from that hostgroup. As the next step, you can enable incoming attack alerts for this hostgroup: ``` sudo fcli set hostgroup my_new_group enable_ban_incoming enable sudo fcli commit ``` FastNetMon can detect outgoing attacks, and you can set outgoing thresholds separately in the following way: ``` sudo fcli set hostgroup my_new_group ban_for_bandwidth_outgoing enable sudo fcli set hostgroup my_new_group threshold_mbps_outgoing 200 sudo fcli commit ``` After this, enable attack detection in the outgoing direction: ``` sudo fcli set hostgroup my_new_group enable_ban_outgoing enable sudo fcli commit ``` To debug hostgroup logic, we have a command which returns the hostgroup name for each specified IP address: ``` sudo fcli show ip_hostgroup 1.2.3.4 ``` ### Maximum number of hostgroups There is no limit on the number of per-host hostgroups in place, hostgroup lookup logic uses a highly efficient tree-based data structure, which offers exceptional scalability with a larger number of hostgroups. We did lab testing with 2048 hostgroups, and it worked without any issues or degradation ### Live hostgroup reloading logic Normally you need to restart FastNetMon daemon to apply any configuration changes. As hostgroup configuration is expected to change often we provide option to reload configuration for such data without daemon restart. Starting from FastNetMon 2.0.362 can do it this way: ``` sudo fcli set reload_hostgroups ``` Please note that this logic is supported only for per\_host hostgroups and it's not supported for total hostgroups yet **Document Categories:** Mitigation modes --- ### [FastNetMon Advanced BGP Blackhole automation](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-bgp-blackhole-automation/) **Published:** April 7, 2023 **Author:** Pavel Odintsov **Content:** In BGP Blackhole mode, FastNetMon can announce your own host (or subnet for this host) with a specified BGP community. You can use this approach for traffic diversion to a cloud scrubbing centre or to completely block all (incoming and outgoing) traffic to this host in your network. In this mode, FastNetMon tracks number of counters for each host in your network (number of bytes, packets and flows per second for different types of traffic). And if some of your hosts cross this baseline value, then FastNetMon will create a BGP announce automatically. To start with BGP Blackhole automation, you need to set thresholds using this [guide](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-per-host-threshold-configuration/). Then enable ban actions globally: ``` sudo fcli set main enable_ban enable ``` If you're configuring IPv6 blackhole, then you need to set this command: ``` sudo fcli set main enable_ban_ipv6 enable sudo fcli commit ``` Then you could check blocks for hosts which exceed this threshold: ``` sudo fcli show blackhole ``` For testing purposes, you may manually blackhole some host: ``` sudo fcli set blackhole 1.2.3.4 ``` To unblock a host, you need to use UUID from the previous command and issue the following command: ``` sudo fcli delete blackhole d9b1885f-6d9b-4167-9e3e-0a3198bacee9 ``` To get more information about a particular blackhole, you can usethe following command: ``` sudo fcli show blackhole d9b1885f-6d9b-4167-9e3e-0a3198bacee9 ``` Example output: ``` IP: 10.0.10.1 UUID: 41799e15-8fa7-4b56-b3d6-840db3fcb956 Hostgroup: global Host Network: 10.0.10.1/22 Detection Source: manual Detection Threshold: unknown Detection Direction: unknown ``` To run some automatic block / mitigation actions, we offer a huge variety of options: - [BGP Blackhole for IPv4](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-bgp-unicast-configuration/) - [BGP Blackhole for IPv6](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-ipv6-bgp-configuration/) - [Email alerts](https://fastnetmon.com/fastnetmon-e-mail-notification/) - [Callback script](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-callback-scripts/) - [Mikrotik route integration](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-and-mikrotik-route-management-integration/) - [Cloud based DDoS scrubbing center traffic diversion via API](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-and-ddos-scrubbing-centers-integration/) - [Cloud based DDoS scrubbing center traffic diversion via BGP](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-and-bgp-traffic-diversion/) - [VyOS route management](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-and-vyos-route-management-integration/) - [Web callback](https://fastnetmon.com/example-web-hook-receiver-for-fastnetmon-advanced/) - [InfluxDB / Grafana alert](https://fastnetmon.com/fastnetmon-attack-notification-in-grafana/) We recommend enabling email alerts before enabling BGP mode to confirm the correctness of the thresholds configuration. ### Automatic unblock When the attack is finished, FastNetMon can automatically unblock the blocked IP address. This capability can be enabled this way: ``` sudo fcli set main unban_enabled true sudo fcli commit ``` By default, FastNetMon unblocks the host after 12 minutes. This time can be changed (ban time in seconds) in the following way: ``` sudo fcli set main ban_time 600 sudo fcli commit ``` In addition to unconditional unblocking by timeout, FastNetMon has the capability to check if the attack has finished before unblocking it. This logic is enabled by default on all new installations. You can manually enable it this way: ``` sudo fcli set main unban_only_if_attack_finished true sudo fcli commit ``` ### Attack confirmation logic For simplicity, the beginning of this guide omits an explanation of attack confirmation logic. In reality, after a host crosses the threshold, FastNetMon does not block it immediately. Instead, it creates a traffic capture request. We do it to capture the context of the attack for email alerts and script callbacks. After capture request creation, FastNetMon will collect all traffic to/from a specified host. By default, FastNetMon captures 500 (for mirror/SPAN mode) or 20 (for sFlow v5, Netflow, IPFIX) packets. If you wish, you can adjust the number of packets in the following way: ``` sudo fcli set main ban_details_records_count 5 sudo fcli commit ``` If it cannot capture this amount of packets for 60 seconds (can be configured using bucket\_traffic\_collection\_timeout starting from 2.0.359), it removes the "traffic capture request" as orphaned and removes it completely. In this case, FastNetMon declares the attack as a false positive and does not apply any actions. If you use sampled Netflow/IPFIX/sFlow v5, you can reduce this value to 2-3 packets or even set it to a single packet. In this case, FastNetMon will block the host almost immediately after receiving the initial alert, but you will lose the ability to understand the attack traffic. If you enable traffic buffer capability attack confirmation step will be skipped, and the attack will be triggered immediately. In this case, FastNetMon will retrieve an attack sample from the in-memory traffic buffer, which stores packets and flows for the last X seconds. This sample will be used for script callbacks and email alerts. In addition to the option to announce /32 or /128 hosts which are under attack, FastNetMon can announce whole networks where the attacked host is located. It may be useful for DDoS scrubbing centre diversion or internal network policy changes (i.e. to move the prefix under attack to in-house scrubbing or move it to another ISP). In addition to BGP-based integration, we have [native integration with multiple DDoS scrubbing centres](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-and-ddos-scrubbing-centers-integration/) via API. **Document Categories:** Mitigation modes --- ### [Per direction hostgroup thresholds](https://fastnetmon.com/docs-fnm-advanced/per-direction-hostgroup-thresholds/) **Published:** May 2, 2023 **Author:** Pavel Odintsov **Content:** Early versions of FastNetMon Advanced used the same thresholds for incoming and outgoing traffic, which wasn't optimal behaviour for all customers. Starting from version 2.0.313, we added an option to use different thresholds for incoming and outgoing traffic. This behaviour is controlled using the following flag, and you may check the current configuration for it this way: ``` sudo fcli show main per_direction_hostgroup_thresholds ``` All new installations have this flag set to true. This flag changes the logic of FastNetMon, and instead of using thresholds like this for both incoming and outgoing traffic: ``` threshold_mbps: 1000 ban_for_bandwidth: true ``` It adds a dedicated set of thresholds for outgoing traffic: ``` threshold_mbps_outgoing: 1000 ban_for_bandwidth_outgoing: true ``` Old-style thresholds without the suffix "\_outgoing" continue to work but apply only for incoming traffic direction. In addition to separate thresholds, this new flag, when set to true, introduces a behaviour change and adds logic to check new per-direction attack detection flags for each hostgroup: ``` sudo fcli show hostgroup global|grep enable enable_ban_incoming: false enable_ban_outgoing: false ``` Previously, you had to set enable\_ban flag to "true" for a host group to enable attack detection. When per\_direction\_hostgroup\_thresholds is enabled in addition to setting enable\_ban, you need to explicitly set enable\_ban\_incoming or enable\_ban\_outgoing to "true". For example, for configuration with incoming only attack detection, you need to have the following flags set for a particular host group: ``` enable_ban: true enable_ban_incoming: true enable_ban_outgoing: false ``` If you want to migrate your old installation and enable per-direction thresholds, you need to apply the following changes: ``` sudo fcli set per_direction_hostgroup_thresholds true sudo fcli commit ``` After that, you need to manually enable ban for incoming traffic for all hostgroups, including the global host group: ``` sudo fcli set hostgroup enable_ban_incoming true sudo fcli commit ``` If you use remote host attack detection, you need to check this guide, as this change affects remote thresholds too. After that, you can set outgoing thresholds with \_outgoing suffix if needed. We recommend switching to the new per\_direction\_hostgroup\_thresholds logic, as the old logic will be deprecated in future. **Document Categories:** Mitigation modes --- ### [Automated baseline calculation with FastNetMon Advanced](https://fastnetmon.com/docs-fnm-advanced/automated-baseline-calculation-with-fastnetmon-advanced/) **Published:** June 17, 2023 **Author:** Pavel Odintsov **Content:** To configure thresholds in FastNetMon correctly, you need to know peak traffic values during peacetime for all the hosts in your network. To simplify this process, FastNetMon includes the capability to show you peak traffic levels for all types of standard [fixed thresholds](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-threshold-types/) available in FastNetMon. To use this feature, you need to enable traffic metrics export to Clickhouse using this [guide](https://fastnetmon.com/docs-fnm-advanced/traffic-metrics-in-clickhouse/). If you have our visual stack installed, you have all the needed components in place, and you do not need to configure anything. Please check that you run [at least](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-upgrade-procedure/) FastNetMon Advanced version 2.0.358 before using this guide. After enabling metrics export, we recommend keeping FastNetMon running without enabling and blocking actions for at least 1 week to cover all possible weekly peak times. If you need baseline data urgently, you can keep it for 10-15 minutes - it will be good for a start. We have no plans to support using data from InfluxDB as it does not handle such queries very well and fails to process a large number of metrics. Our baseline tool works on multiple levels of aggregation: - Global, includes all hosts in the network - Per host (IPv4 only) - Per prefix (IPv4 only, CIDR format) - Per hostgroup For small and medium-sized networks, we recommend starting with setting up only a single global hostgroup for simplicity. If you have more than a single type of bandwidth profile with significantly different peak traffic (i.e. cache nodes, CDN server, high bandwidth business connections) in your network, we recommend moving hosts with significantly larger bandwidth usage into a separate [hostgroup](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-per-host-hostgroups/). To get peak traffic metrics for all hosts in your network, you can run the following command: ``` sudo fcli show baseline_per_host global ``` After this command finishes, you may see output like this: ``` threshold_pps 145912 threshold_mbps 1585 threshold_flows 55892 threshold_tcp_pps 145910 threshold_udp_pps 61630 threshold_icmp_pps 1129 threshold_ip_fragments_pps 0 threshold_tcp_syn_pps 141824 threshold_tcp_mbps 1585 threshold_udp_mbps 559 threshold_icmp_mbps 0 threshold_ip_fragments_mbps 0 threshold_tcp_syn_mbps 1531 ``` By default, we return baseline for incoming traffic, but you can explicitly specify the direction this way: ``` sudo fcli show baseline_per_host global outgoing ``` Example output: ``` threshold_pps_outgoing 377 threshold_mbps_outgoing 4535344 threshold_flows_outgoing 0 threshold_tcp_pps_outgoing 292 threshold_udp_pps_outgoing 377 threshold_icmp_pps_outgoing 79 threshold_ip_fragments_pps_outgoing 0 threshold_tcp_syn_pps_outgoing 32 threshold_tcp_mbps_outgoing 1629352 threshold_udp_mbps_outgoing 4534784 threshold_icmp_mbps_outgoing 58056 threshold_ip_fragments_mbps_outgoing 0 threshold_tcp_syn_mbps_outgoing 19512 ``` Please note that if the hostgroup or network consists of a large number of hosts (as global), the query may require a prolonged time to finish, as it will process a very significant amount of metrics. These values are your peak values over a period of 7 days. We recommend checking them for validity, and if you see unreasonably high values, we recommend checking your configuration by following our quick start step-by-step. We do provide all the possible threshold types in output, but we do not recommend setting up all of them. We recommend using only pps and mbps thresholds for the majority of setups. You may add per-protocol thresholds to adjust to specific attack types, but we do not recommend doing so from the beginning. If you use sampled protocols such as sFlow, or you have sampling enabled for Netflow or IPFIX, you will see zero numbers for flow metrics. Unfortunately, sampling theory does not allow us to recover the flow rate after packet-based sampling was applied, and that's why these metrics are set to zeroes. You may have peak traffic for a specific host in your network this way: ``` sudo fcli show baseline_per_host 10.1.2.3 ``` To get a baseline value for a prefix, you can use it in CIDR format: ``` sudo fcli show baseline_per_host 10.1.2.3/24 ``` To get a baseline value for the whole hostgroup, you can use the following format. Our tool will load all networks from specified hostgroup and then calculate peak traffic over all hosts in it: ``` sudo fcli show baseline_per_host my_hostgroup ``` If you had a DDoS attack over the last week, the attack traffic will be included and may affect the reliability of calculations. To use peak traffic values as thresholds for attack detection, we recommend multiplying them by x2-x3 and then use. Basic recommendation for threshold setup is to set them to values which cannot be reached by normal traffic. For example, if you have 1G limit for customers, then it may be reasonable to set the threshold to 1.2G as this value cannot be reached by normal service usage and in case of DDoS, it can easily exceed this value. Another approach to set them up to value when you know your network starts performance degradation. For example, you know that your routers will melt down after X packets per second or you know that your upstream cannot handle more than 5G. Baseline configuration is an ongoing process, and if you noticed that some attack was missed or you experienced a false alert on legitimate traffic, it may be a good time to review thresholds and adjust them. **Document Categories:** Mitigation modes --- ### [FastNetMon Advanced BGP mitigation modes](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-bgp-mitigation-modes/) **Published:** February 25, 2018 **Author:** Pavel Odintsov **Content:** FastNetMon can work in two mutually exclusive modes: \- BGP Blackhole \- BGP Flow spec In BGP Blackhole mode, FastNetMon can announce your own host (or subnet for this host) with a specified BGP community. You can use this approach for traffic diversion to a cloud scrubbing centre or to completely block all (incoming and outgoing) traffic to this host in your network. In this mode, FastNetMon tracks a number of counters for each host in your network (number of bytes, packets and flows per second for different types of traffic). And if some of your host crosses the baseline specified value, FastNetMon will create a BGP announce automatically. FastNetMon has options to exclude any ban actions for hosts in your network (whitelist). Also, it can ignore traffic related to some remote hosts (whitelist\_remote) completely (useful mode to whitelist backup servers). If you need DDoS detection only for incoming or outgoing attack types, you can enable only the important direction of traffic (process\_incoming\_traffic and process\_outgoing\_traffic). To switch FastNetMon to BGP Flow spec mode, you need to enable Flow spec globally (set main gobgp\_flow\_spec\_announces enable) and activate Flow Spec NLRI/family for at least a single BGP peering connection (set bgp connection\_to\_my\_router ipv4\_flowspec enable). In this mode, FastNetMon also keeps traffic counters for each host in your network, but actions executed when a host crosses baseline are different. Instead of immediately blocking the host, FastNetMon attempts to collect a traffic sample (from 20 to 500 packets) for the affected host. If it can collect the required amount of traffic, it uses our own attack detection engine to find attack traffic and create filtering rules. This engine works only on L3 and L4 layers and does not have options to check the content of packets. FastNetMon uses a statistical approach and can find popular attack types (all kinds of amplification, floods from a few IP addresses) easily. But it's important to have a rather large values for baselines in prder to have a significant amount of attack traffic in the sample. FastNetMon implements a number of optimisations to reduce the number of BGP Flow spec rules and uses aggregation to find the best match. **Document Categories:** Mitigation modes --- ### [Per hostgroup thresholds](https://fastnetmon.com/docs-fnm-advanced/per-hostgroup-thresholds/) **Published:** June 27, 2019 **Author:** Pavel Odintsov **Content:** In many cases, it may be useful to calculate total traffic for a number of prefixes and take custom actions when it reaches a specified value. You can enable it this way: ``` sudo fcli set main enable_total_hostgroup_counters enable ``` You can also create any number of custom hostgroups, which can consist of any number of networks the following way: ``` sudo fcli set hostgroup servers sudo fcli set hostgroup servers calculation_method total sudo fcli set hostgroup servers networks 192.168.1.0/24 sudo fcli set hostgroup servers networks 10.10.1.2/16 sudo fcli commit ``` Please be aware that each specific prefix can be added only once for all total hostgroups. If you add the same prefix multiple for two different hostgroups it will be assigned only to one of them randomly. You can debug per hostgroup traffic using the following fcli command: ``` sudo fcli show hostgroup_counters_total ``` Our default [dashboards](https://fastnetmon.com/docs-fnm-advanced/advanced-visual-traffic/) set for Grafana include a dashboard which shows per hostgroup traffic. When you create a total hostgroup, you will be able to see host top talkers per hostgroup in the following way: ``` sudo fcli show host_counters_per_hostgroup_v4 sudo fcli show host_counters_per_hostgroup_v6 ``` For all total hostgroups, we have a field “parent\_name” which specifies hostgroup name which should be used as parent. In this context, “parent” means that the current group will use networks list from parent group. It’s a useful option when you have the same networks list for per-host and for total hostgroups. You can use only per\_host hostgroup as parent. Please note that "global" hostgroup cannot be specific in "parent\_name" as it has a special meaning. You can set it this way: ``` sudo fcli set hostgroup client1 parent_name client1_per_host ``` To configure automated attack detection using total traffic to hostgroup, please follow this [guide](https://fastnetmon.com/attack-detection-for-per-hostgroup-thresholds/). FastNetMon automatically creates a hostgroup called global\_total, which accounts for traffic not included in any existing total hostgroup. If you prefer, you can create it manually, but it's not required. ``` sudo fcli set hostgroup global_total sudo fcli set hostgroup global_total calculation_method total ``` **Document Categories:** Mitigation modes --- ### [Attack detection for per hostgroup thresholds](https://fastnetmon.com/docs-fnm-advanced/attack-detection-for-per-hostgroup-thresholds/) **Published:** June 27, 2019 **Author:** Pavel Odintsov **Content:** This guide requires a completely working setup for [total hostgroups](https://fastnetmon.com/per-hostgroup-thresholds/). When a hostgroup reaches a specified total traffic value, FastNetMon can call different actions. To enable this feature, you have to enable ban actions this way: ``` sudo fcli set main enable_ban enable sudo fcli set main enable_ban_hostgroup enable ``` Before enabling the automatic way, you can block some hostgroup manually using the following command: ``` sudo fcli set hostgroup_block global_total ``` You can list all active blocks this way: ``` sudo fcli show hostgroup_block ``` Unblock example: ``` sudo fcli delete hostgroup_block 9905ee8f-b5fa-4d46-b232-75f508f13fd5 ``` To automate attack detection, please set [thresholds](https://fastnetmon.com/fastnetmon-threshold-types/): ``` sudo fcli set hostgroup global_total enable_ban enable sudo fcli set hostgroup global_total enable_ban_incoming enable sudo fcli set hostgroup global_total ban_for_bandwidth enable sudo fcli set hostgroup global_total threshold_mbps 10 ``` After that, please apply the configuration using the commit command, and FastNetMon will start automatic attack detection. When an attack comes, FastNetMon can run different actions: - [BGP announce](https://fastnetmon.com/bgp-announces-for-total-hostgroups/) of all networks and hosts in hostgroup - [Script callback](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-callback-scripts/) **Document Categories:** Mitigation modes --- ### [Traffic buffer capability to speed up attack detection](https://fastnetmon.com/docs-fnm-advanced/traffic-buffer-capability-to-speed-up-attack-detection-speed/) **Published:** July 4, 2022 **Author:** Pavel Odintsov **Content:** We've introduced a traffic buffer, storing every single packet received by FastNetMon in a very efficient storage. When FastNetMon detects an attack (when a host crosses a threshold), we use a traffic buffer to retrieve all flows or packets arriving in the network before attack detection. This way, we can immediately trigger a blackhole or BGP Flow Spec announce, and we do not need to wait for more traffic to arrive. It reduces attack detection time by at least 15-90 seconds. To use all capabilities on this page, you need to upgrade FastNetMon to version 2.0.314. To enable this logic, you will need: ``` sudo fcli set main traffic_buffer enable ``` Traffic buffer will keep all traffic for sFlow, Netflow, IPFIX and Tera Flow protocols by default. To enable a traffic buffer for port mirror, you need to set this flag: ``` sudo fcli set main traffic_buffer_port_mirror true ``` Pay careful attention when using this option in a non-sampled port mirror setup, as the number of packets will be very high and it may degrade performance. We do recommend using this flag only for sampled port mirror setups. Next, set buffer size: ``` sudo fcli set main traffic_buffer_size 100000 ``` Buffer size calculation may be tricky as it should accommodate all traffic processed by FastNetMon for average\_calculation\_time seconds. To get the number for a specific installation, you will need to get the number of arriving flows per second in the following way: ``` sudo fcli show system_counters |grep netflow_all_protocols_total_flows_speed ``` For sFlow-based capture, you need to usea different value: ``` sudo fcli show system_counters | grep sflow_raw_packet_headers_total_speed ``` And then multiply one of these values by average\_calculation\_time. After that, we recommend doubling or even tripling this value to cover possible spikes during peak time or attacks. In addition to this, we have a runtime metric which shows how long, in seconds, FastNetMon can keep your traffic in memory: ``` sudo fcli show system_counters | grep traffic_buffer_duration ``` Example output: ``` traffic_buffer_duration_seconds_ipv4 77 traffic_buffer_duration_seconds_ipv6 0 ``` We do not recommend using the traffic\_buffer capability in Flow Spec mitigation mode in a production environment, as it may have detection issues, but feel free to try it in a lab environment. Please note that due to performance reasons traffic buffer does not store packet payload, and the configuration option collect\_attack\_pcap\_dumps will not store pcap dumps when the traffic buffer is enabled. Starting from 2.0.373, you can get the content of the traffic buffer for a specific IP using the following commands: ``` sudo fcli show traffic_buffer 10.1.1.1 ``` **Document Categories:** Mitigation modes --- ### [FastNetMon VyOS sFlow v5 configuration](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-vyos-sflow-v5-configuration/) **Published:** May 10, 2020 **Author:** Pavel Odintsov **Content:** You can use FastNetMon Advanced with the VyOS routing platform. It is an open source platform, and you can [buy support](https://vyos.io/subscriptions/software) directly from developers. In this guide, we will provide detailed instructions about this process. All these instructions were tested with VyOS 1.4.x dev. VyOS has two implementations of sFlow protocol agent. One is legacy available from set system flow-accounting sflow, and it does not work well with FastNetMon, and requires [manual installation](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-sflow-v5-export-from-linux/) of third party sFlow agent. The newer one is based on hsflowd, and is available as set system sflow, and it works well for this purpose. VyOS offers Netflow and sFlow support in same time. sFlow offers faster detection and lower CPU usage, which makes it more suitable for DDoS detection. As the first step, log in to VyOS over SSH using the default login and password: vyos/vyos and then switch to configuration mode: conf Configure sFlow export (please replace 192.168.1.134 with the address of the server with FastNetMon installed): ``` set system sflow agent-address 'your-router-ip' set system sflow sampling-rate '100' set system sflow polling '30' set system sflow server 192.168.1.134 port '6343' ``` After this, select interfaces to enable sFlow export. We recommend exporting traffic from upstream ports: ``` set system sflow interface 'ethX' set system sflow interface 'ethY' ``` We set the sampling rate to 100 for testing. For ports with at least 1G of bandwidth, I recommend increasing this value to 1024; for 10G, you can use 2048. After this, apply changes: ``` save commit ``` **Document Categories:** sFlow v5 --- ### [Port mirror or SPAN over GRE](https://fastnetmon.com/docs-fnm-advanced/port-mirror-or-span-over-gre/) **Published:** August 16, 2022 **Author:** Pavel Odintsov **Content:** FastNetMon has extremely solid support for [port mirror](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-port-mirror-configuration/) capture, but standard port mirror or SPAN are both complicated to operate without direct connectivity between FastNetMon and routers. In this case, a sampled or unsampled port mirror over GRE may be extremely helpful. You need to explicitly enable GRE unpacking when you can guarantee that your environment is safe. Automated GRE stripping may have security implications, as an attacker may use GRE as an attack vector with private/your own IP addresses inside. In this case, FastNetMon will not be able to identify the attack properly. ``` sudo fcli set main af_packet_extract_tunnel_traffic enable sudo fcli commit ``` After this, you will need to send port mirror / SPAN over GRE to FastNetMon's IP address. We recommend creating a separate interface (with increased MTU) from the management interface to avoid conflicts and potential issues. Also, please keep in mind that GRE adds additional encapsulation headers to every packet, and GRE traffic will exceed 1500 bytes. Therefore, you need to be sure that all routers between FastNetMon and your routers will pass such a large MTU. We have many successful deployments using Juniper's capability to send port mirror over GRE, and all other vendors using standard encapsulation will work fine. In addition to using 1:1 port mirror over GRE, you may consider another sampled version of it which significantly reduces the required CPU load on the machine with FastNetMon and dramatically decreases the requirement for bandwidth between the router and FastNetMon. You may start from some sampling like 1:1024 as a very safe option which offers great accuracy and extremely fast attack detection. As sampled port mirror over GRE has no options to encode sampling rate in packet direction, you need to set it manually using the following flags: ``` sudo fcli set main mirror_af_external_packet_sampling enable sudo fcli set main mirror_external_af_packet_sampling_rate 1000 sudo fcli commit ``` If you run a sampled port mirror, you must have a separate interface for it, and you need to ensure that you do not capture traffic from the management interface. Such a setup will be extremely dangerous as all traffic over the management interface (for example a downloading a file) will be multiplied by the sampling rate, which is 1000, and this will trigger a false positive attack detection. **Document Categories:** Port mirror / SPAN --- ### [sFlow configuration on Cisco Nexus 9000 for FastNetMon Advanced](https://fastnetmon.com/docs-fnm-advanced/sflow-configuration-on-cisco-nexus-9000-for-fastnetmon-advanced/) **Published:** September 19, 2023 **Author:** Pavel Odintsov **Content:** To enable sFlow on this switch, you need to make the following configuration changes: ``` feature sflow sflow sampling-rate 4096 sflow max-sampled-size 128 sflow counter-poll-interval 20 sflow max-datagram-size 1400 sflow counter-poll-interval 30 sflow collector-ip vrf default sflow collector-port 6343 sflow agent-ip ``` You may need to change "default" to "management" to alter VRF. Please check if your switch supports values smaller than 4096 for sampling-rate, and if it does, change it to 2000 or 1000. Then you need to add all ports for traffic monitoring: ``` sflow data-source interface ethernet 1/5 ``` For port channel interfaces syntax will be slightly different: ``` sflow data-source interface port-channel xxx ``` You may experience issues with 40G modules, and you will need to change TCAM configuration. We recommend checking vendor guides for this. To monitor that it works correctly, please use the following command: ``` show sflow statistics Total Packets : 108379009735 Packets Total Samples : 86338 Packets Processed Samples : 86449 Packets Dropped Samples : 17 Packets Sent Datagrams : 14317 Packets Dropped Datagrams : 5 Packets ``` **Document Categories:** sFlow v5 --- ### [sFlow configuration for Extreme XOS](https://fastnetmon.com/docs/extreme/) **Published:** August 17, 2016 **Author:** FastNetMon **Content:** Please note: Extreme XOS operating system before 15.4 release lack of support for ingress sFlow, only for egress. Please use 15.4 version or more recent. Example of sFlow configuration for Extreme XOS: ``` configure sflow collector 10.0.2.33 port 6343 vr "VR-Default" # add collector configure sflow agent 10.0.2.15 # agent address configure sflow poll-interval 1 # send data to collector once per second configure sflow sample-rate 1024 # sampling rate enable sflow ports 1:39,1:40,2:39 both # add ports to sFLOW monitoring for egress and ingress traffic. enable sflow # enable sflow globally ``` Check configuration for correctness: ``` show sflow SFLOW Global Configuration Global Status: enabled Polling interval: 1 Sampling rate: 2048 Maximum cpu sample limit: 2000 SFLOW Configured Agent IP: 10.0.2.15 Operational Agent IP: 10.0.2.15 Collectors Collector IP 10.0.2.33, Port 6343, VR "VR-Default" SFLOW Port Configuration Port Status Sample-rate Subsampling Config / Actual factor 1:39 enabled 1024 / 1024 1 1:40 enabled 1024 / 1024 1 2:39 enabled 1024 / 1024 1 ``` **Document Categories:** sFlow v5 --- ### [FastNetMon sFlow v5 export from Linux](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-sflow-v5-export-from-linux/) **Published:** September 10, 2018 **Author:** Pavel Odintsov **Content:** If you have a Linux machine and you need to export traffic from it, we suggest using hsflowd. It generates sFlow v5 stream and works very well with FastNetMon Advanced. This guide works only for machines with kernel 3.19 (CentOS 7 with standard kernel is not supported) or more recent as these kernels have support for kernel-side BPF sampling. As a first step, please download the latest binary version for your Linux distribution. ``` wget https://github.com/sflow/host-sflow/releases/download/.....deb sudo dpkg -i hsflowd...amd64.deb ``` And add the following to configuration file: ``` sudo vim /etc/hsflowd.conf ``` Configuration example. Replace ens3 by your interface name, replace collector IP by the address of FastNetMon and replace agentIP by the address of the router itself.): ``` sflow { DNSSD = off polling = 30 agentIP = 127.0.0.1 sampling.100M = 100 sampling.1G = 500 sampling.10G = 1000 sampling.40G = 4000 sampling = 1000 collector { ip = 127.0.0.1 udpport = 6343 } # Add all relevant interfaces to this list pcap { dev = ens3 } pcap { dev = ens4 } } ``` Apply changes: ``` sudo systemctl restart hsflowd ``` Enable auto start on boot: ``` sudo systemctl enable hsflowd ``` **Document Categories:** sFlow v5 --- ### [FastNetMon Advanced AF_XDP support](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-af_xdp-support/) **Published:** November 24, 2018 **Author:** Pavel Odintsov **Content:** ### What is AF\_XDP? AF\_XDP is a new kernel bypass technology integrated into the Linux Kernel. It offers very high performance and low CPU overhead. It does not require any additional licenses or third-party libraries. You can use it to process 1G, 10G or even 40G of traffic. We recommend using the [AF\_PACKET](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-port-mirror-configuration/) capture engine for production deployments. AF\_XDP support has some limitations and is not ready for production use: - Supports only a single interface - Uses only a single queue per network card - Requires manual configuration with ethtool AF\_PACKET is a way simpler to operate and offers better scalability. ### Dependencies You need to have at least Linux kernel 4.19 or more recent. ### Modes There are two modes of AF\_XDP - Copy mode (works for all NIC supported in Linux). It offers great compatibility, but does not offer top performance - Native (driver) mode. Offers decent performance and requires support from the driver. Supported only for Intel XL710 now In FastNetMon, you can require native mode support using **force\_native\_mode\_xdp** option ### Configuration This mode requires XDP microprogram to work properly. You can download it here: [xdp\_kernel.o](https://fastnetmon.com/wp-content/uploads/2018/11/xdp_kernel.o.zip) and put it to /root/xdp\_kernel.o. Optionally, you can [compile](https://github.com/pavel-odintsov/fastnetmon/blob/master/src/xdp_plugin/xdp_kernel.c) it on your own. You can enable this mode in FastNetMon using the following commands: ``` sudo fcli set main mirror_xdp enable sudo fcli set main microcode_xdp_path /root/xdp_kernel.o sudo fcli set main force_native_mode_xdp disable sudo fcli set main poll_mode_xdp enable sudo fcli set main xdp_set_promisc enable sudo fcli set main interfaces_xdp ethX ``` To get maximum throughput (but it will also increase CPU usage) you may disable poll\_mode\_xdp. It will switch FastNetMon into "active polling" mode and will eat the whole CPU. When you enable AF\_XDP, FastNetMon detaches the interface from the standard Linux Network stack. To return it, please reboot the machine. FastNetMon binds only to the first RX queue. By default, your NIC allocates many queues, and you can reduce the number of them to 1 this way: ``` sudo ethtool --set-channels eth4 combined 1 ``` **Document Categories:** Port mirror / SPAN --- ### [FastNetMon Advanced sFlow configuration](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-sflow-configuration/) **Published:** April 14, 2019 **Author:** Pavel Odintsov **Content:** You may find sFlow protocol in wide range of switches. Some models of routers also offer it as option. One of the key benefits of sFlow is an ability to detect DDoS in few seconds. You can enable sFlow support in FastNetMon with few easy steps. Enable sFlow plugin: ``` sudo fcli set main sflow enable ``` Specify port / ports for sFlow capture (6343 is default port): ``` sudo fcli set main sflow_ports 6343 ``` Specify interface for listening (0.0.0.0 is default): ``` sudo fcli set main sflow_host 0.0.0.0 ``` To listen on IPv4 and IPv6 protocols on same port you need to set host to following value: ``` sudo fcli set main sflow_host :: sudo fcli commit ``` If your run any kind of firewall on your network or on server with FastNetMon itself you will need to allow traffic over ports you've added towards machine with FastNetMon. Apply changes and restart FastNetMon: ``` sudo fcli commit ``` After that you have to configure sFlow on sFlow agent’s side (switch, router, server) to configured port and host. We have our own guides for configuring sFlow: - [Extreme](https://fastnetmon.com/docs/extreme/) - [Arista](https://fastnetmon.com/docs-fnm-advanced/sflow-v5-configuration-on-arista/) - [Cisco ASR 9000](https://fastnetmon.com/docs-fnm-advanced/cisco-asr-9000-sflow-configuration-for-fastnetmon-advanced/) - [Cisco Nexus 9000](https://fastnetmon.com/docs-fnm-advanced/sflow-configuration-on-cisco-nexus-9000-for-fastnetmon-advanced/) - [Juniper EX / QFX](https://fastnetmon.com/docs-fnm-advanced/juniper-ex-and-qfx-sflow-v5-configuration-for-fastnetmon-advanced/) - [Juniper MX](https://fastnetmon.com/docs-fnm-advanced/sflow-on-juniper-mx-fastnetmon-advanced/) - [Huawei](https://fastnetmon.com/fastnetmon-advanced-technical-documentation/fastnetmon-advanced-configuration-with-huawei-sflow-v5/) - [IP Infusion OcNos](https://fastnetmon.com/docs-fnm-advanced/ip-infusion-ocnos-sflow-v5-configuration-with-fastnetmon-advanced/) - [Linux](https://fastnetmon.com/fastnetmon-sflow-v5-export-from-linux/) - [VyOS](https://fastnetmon.com/fastnetmon-vyos-sflow-v5-configuration/) Selection of sampling rate value depends on real amount of traffic value in link. It does not depend on peak link capacity or interface speed. According to real amount of traffic in network we suggest following sampling rates: | Bandwidth | Sampling rate | |---|---| | 100 Mbit | 500 | | 1 Gbit | 1000 | | 10 Gbit | 1000 | | 40 Gbit | 1000 | | 100 Gbit | 1000 | After finishing configuration from agent's side, you may check that FastNetMon receives data using our counters: ``` sudo fcli show system_counters|grep sflow ``` It's very important to keep reasonable sampling rate for accurate bandwidth calculation. In some cases during traffic spikes switches can increase sampling rate over value specified in configuration. FastNetMon has an option to expose sampling rate for each router. You can enable it this way: ``` sudo fcli set main sflow_track_sampling_rate enable sudo fcli commit ``` After enabling this option, you can check sampling rate for each device and line card this way: ``` sudo fcli show sflow_sampling_rates ``` FastNetMon offers an option to count number of sFlow packets received from different devices and you can enable it this way: ``` sudo fcli set main sflow_count_packets_per_device true sudo fcli commit ``` Then you will be able to see number of sFlow packet per device this way: ``` sudo fcli show sflow_packets_per_device ``` Starting from 2.0.374 you can enable option which strips MPLS tags to reach IPv4 or IPv6 traffic inside: ``` sudo fcli set main sflow_strip_mpls_tags true sudo fcli commit ``` ### Why are the flow counters zero? If you use sampling, due to [sampling theory](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-connection-tracking/) limitations, we cannot calculate flow / second correctly. **Document Categories:** sFlow v5 --- ### [FastNetMon AF_PACKET port mirror configuration](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-port-mirror-configuration/) **Published:** April 14, 2019 **Author:** Pavel Odintsov **Content:** In this mode, you need to configure port mirror / SPAN / TAP from your switch or router device. We suggest using a separate interface for management connection with FastNetMon for reliability reasons. Enable plugin for mirror capture: ``` sudo fcli set main mirror_afpacket enable ``` List all available interfaces for your system: ``` sudo fcli show interfaces ``` Enable capture for specific port (you may specify any number of ports): ``` sudo fcli set main interfaces em1 sudo fcli commit ``` Then enable port mirroring on the router or switch side. By default, FastNetMon samples traffic 1 to 100 for better accuracy on low speeds, but if your capture 1G or more, we recommend increasing the sampling rate to at least 1 to 1000 to avoid traffic drops: ``` sudo fcli set main mirror_af_packet_sampling enable sudo fcli set main mirror_af_packet_sampling_rate 1000 sudo fcli commit ``` By default, FastNetMon relies on the Linux kernel to do packet sampling and then receives data using a single thread. If you use sampling, you must enable this mode, or you will have enormous traffic spikes during FastNetMon restart, which will lead to false positives: ``` sudo fcli set main mirror_af_packet_disable_multithreading enable sudo fcli commit ``` Each AF\_PACKET socket has multiple counters for the number of packets dropped due to performance issues. This option is disabled by default, but you can easily enable it in the following way: ``` sudo fcli set main mirror_af_packet_socket_stats enable sudo fcli commit ``` After enabling this option, you will see two more counters for the following debug command: ``` sudo fcli show system_counters |grep socket ``` Example output: ``` socket_received_packets 0 socket_dropped_packets 0 ``` If you do not use sampling (not recommended for production setups), FastNetMon will run 1 worker thread for each queue on the NIC. For many modern NICs number of queues is set to the number of active cores. In cases when your machine has many cores (16, 24 or more), it may lead to lock contention, and you will see all CPU cores busy, but traffic will be undercounted. In this case, we suggest setting a lower number of queues on the NIC in the following way: ``` sudo ethtool --set-channels eth4 combined 8 ``` Another option to improve mirror capture performance is the fanout type. FastNetMon has support for the following fanout algorithms (for more details, please check this [page](https://man7.org/linux/man-pages/man7/packet.7.html) in PACKET\_FANOUT section): - cpu - lb - hash - random - rollover - queue\_mapping By default, FastNetMon uses "cpu", but you can easily change it in the following way: ``` sudo fcli set main mirror_af_packet_fanout_mode cpu sudo fcli commi ``` Some routers, such as Juniper MX, have the capability to sample mirrored traffic on the router's data plane. It's a very good approach as it reduces the amount of traffic delivered from the router to the machine with FastNetMon and significantly reduces the amount of required CPU resources. To get the correct traffic, all data has to be multiplied by the sampling rate by FastNetMon. Port mirror has no options to encode the sampling rate in the traffic stream, and you need to specify it manually in the following way: ``` sudo fcli set main mirror_af_external_packet_sampling enable sudo fcli set main mirror_external_af_packet_sampling_rate 1000 sudo fcli commit ``` If you have any performance issues with this capture mode, we suggest testing the new experimental capture plugin: [A](https://fastnetmon.com/fastnetmon-advanced-af_xdp-support/)[F\_XDP](https://fastnetmon.com/fastnetmon-advanced-af_xdp-support/). If you're looking for GRE support, please check this [article](https://fastnetmon.com/docs-fnm-advanced/port-mirror-or-span-over-gre/). Starting from version 2.0.368, you can use GTPv1 tunnel stripping capability, which can be enabled this way: ``` sudo fcli set main af_packet_extract_gtp_v1_tunnels true sudo fcli commit ``` By default FastNetMon uses packet length as received from the interface for bandwidth calculation but on some platforms you may prefer to deliver first X bytes of packet instead of delivering full packet ("mirror first 64" on Cisco ASR 9000 or "maximum-packet-length 100" on Juniper MX) and in this case you need to switch FastNetMon to read packet length from IP header that way: ``` sudo fcli set main af_packet_read_packet_length_from_ip_header true sudo fcli commit ``` **Document Categories:** Port mirror / SPAN --- ### [FastNetMon Flow](https://fastnetmon.com/docs-fnm-advanced/tera-flow/) **Published:** April 12, 2020 **Author:** Pavel Odintsov **Content:** FastNetMon Flow is FastNetMon’s own format for very efficient flow representation, which includes many improvements over existing flow protocols, with the main target to improve developer experience and cross-language integration. FastNetMon uses this format to export and receive data to/from other instances of FastNetMon. You can find a detailed format description [here](https://fastnetmon.com/tera-flow-capnproto-specification/). This logic supports multiple protocols. Please keep in mind that TCP and UDP transports do not offer any encryption and cannot be used via public networks. If you transport telemetry traffic over the Internet, please use TLS. TLS mode uses TLS 1.3, which is the most secure version of the TLS protocol. FastNetMon can receive traffic telemetry in our format or can export it to a remote machine. Your own applications can send traffic in this format to FastNetMon. To configure FastNetMon in client mode, you need to apply the following changes. To use this capability, please upgrade to version 2.0.353. Enable plugin: ``` sudo fcli set main tera_flow enable ``` Then specify addresses to listen using URL-based configuration: ``` sudo fcli set main tera_flow_local_addresses tcp://[::0]:8104 sudo fcli set main tera_flow_local_addresses udp://0.0.0.0:8104 sudo fcli set main tera_flow_local_addresses tls://0.0.0.0:8104 sudo fcli commit ``` To use TLS mode, you need to specify paths to your TLS certificates: ``` sudo fcli set main tera_flow_tls_certificate_path /etc/ssl/certs/ssl-cert-snakeoil.pem sudo fcli set main tera_flow_tls_private_key_path /etc/ssl/private/ssl-cert-snakeoil.key sudo fcli commit ``` You can use Let's encrypt issues certificates or certificates issued by any other CA. Self-signed certificates are not supported for security reasons. If you have a chain of certificates specified, you need to enable chain mode: ``` sudo fcli set main tera_flow_tls_certificate_chain true sudo fcli commit ``` You can confirm that FastNetMon receives traffic from remote end using the following command: ``` sudo fcli show system_counters |grep total_simple_packets_processed ``` You can check different per-protocol counters that way: ``` sudo fcli show system_counters|grep fastnetmon_flow fastnetmon_flow_udp_packets 0 fastnetmon_flow_tcp_packets 0 fastnetmon_flow_tls_packets 582987 ``` In addition to receiving mode, FastNetMon can export traffic to the remote side using Tera Flow protocol too. To enable export capability, you can use the following commands. Enable plug-in: ``` sudo fcli set main flow_forwarder true ``` Specify remote host and port: ``` sudo fcli set main flow_forwarder_remote_addresses udp://[aaff::beef]:8104 ``` You can use UDP, TCP or TLS as protocols. In addition to using IPv4 or IPv6 addresses, you can use hostnames, and FastNetMon will resolve them automatically for you. For TLS mode, we support only hostnames as they're required for TLS certificate validation. If you use traffic capture from mirror / SPAN, you can enable sampling to reduce the load and amount of telemetry traffic: ``` sudo fcli set main flow_forwarder_sampling_rate 512 ``` And apply changes: ``` sudo fcli commit ``` To debug issues with traffic export, you can use this command: ``` sudo fcli show system_counters | grep flow_forwarder ``` It will show you multiple metrics about any issues that happened during export: ``` flow_forwarder_errors 0 flow_forwarder_pushed_messages 40864 flow_forwarder_sampler_seen_packets 0 flow_forwarder_sampler_selected_packets 0 ``` For both TCP and TLS modes, FastNetMon has reconnection logic in place, which checks the connection status and reconnects in 60 seconds after the first failure is detected. **Document Categories:** Capture engines --- ### [FastNetMon and Amazon VPC flow logs](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-and-amazon-vpc-flow-logs/) **Published:** April 12, 2020 **Author:** Pavel Odintsov **Content:** FastNetMon was built with flexibility in mind, and we do offer security solutions for on-premises and cloud environments. Amazon AWS offers great way to export traffic telemetry from all VPCs (VPC Flow logs), and you can use your FastNetMon instance to process this data easily. Many features from this article (VPC Flow Log, CloudWatch, Lambda) are subject to charge; please check with your financial team before moving forward to avoid unexpected costs. From FastNetMon side, please enable FastNetMon Flow plugin using the following commands: ``` sudo fcli set main tera_flow enable sudo fcli set main tera_flow_host 0.0.0.0 sudo fcli set main tera_flow_ports 8104 sudo fcli commit ``` With this configuration, FastNetMon will listen for Tera Flow UDP messages on port 8104. If you’ve deployed FastNetMon in Amazon AWS too, you need to change the security policy for your EC2 instance to allow UDP traffic over port 8104. In the instance’s description, select “Security groups” and click on it. In this case, you need to click on “launch-wizard-2”. ![](https://fastnetmon.com/wp-content/uploads/2020/04/security-1024x288.png)Then you will see all security groups: ![](https://fastnetmon.com/wp-content/uploads/2020/04/security_groups-1024x173.png)Then click on security group to open configuration: ![](https://fastnetmon.com/wp-content/uploads/2020/04/security_list-1024x365.png)As next step you’ll need to click on “Edit inbound rules” then click “Add rule” and create following rule: “Custom UDP”, “Port Range”: 8104, “Source”: “anywhere”, “Description”: “Allow FastNetMon Tera Flow from Lambda” and finally click on save rules. ![](https://fastnetmon.com/wp-content/uploads/2020/04/rule-1024x315.png)Next, you need to configure CloudWatch. We need CloudWatch to export Flow Logs into it for processing. Open Logs, Log groups and then from “Actions” select “Create log group”. Use the name fastnetmon\_flow\_logs. ![](https://fastnetmon.com/wp-content/uploads/2020/04/cloudwatch.png)As the next step, create IAM Role for Flow logs. Please follow [official guide](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs-cwl.html#flow-logs-iam) for it. When asked for Role Name, please use “vpc\_flow\_watch\_role”. Then you need to enable VPC Flow logs export for VPCs in all your regions. Open the required VPC and then select the tab “Flow logs” and then click on “Create Flow log”. ![](https://fastnetmon.com/wp-content/uploads/2020/04/vpc_flow_logs-1024x180.png)Then set the following options for it: - Filter: all - Maximum aggregation interval: 1m - Destination: Send to CloudWatch Logs - Destination log group: fastnetmon\_flow\_logs - Role: vpc\_flow\_watch\_role ![](https://fastnetmon.com/wp-content/uploads/2020/04/flow_logs_export-1024x560.png)Check that we’re receiving data for this log group. Let’s open CloudWatch, then “Log Groups”, and select fastnetmon\_flow\_logs. You will see flow data in the following format if you’ve configured everything right. ![](https://fastnetmon.com/wp-content/uploads/2020/04/flow_data-1024x224.png)The next step is Amazon Lambda configuration. We need it to run a small function which receives every VPC Flow Log, encodes it into Tera Flow format and then exports it into FastNetMon. Open Lambda setup and click on the button “Create Function”, then select “Blueprint” and find “cloudwatch-logs-process-data”, and after that click “configure”. ![](https://fastnetmon.com/wp-content/uploads/2020/04/lambda-1024x397.png)Then please specify the following options: - Function name: process\_vpc\_flow\_fastnetmon - Execution role: Create a new role with basic Lambda permissions - Log group: fastnetmon\_flow\_logs - Filter name: fastnetmon\_flow\_logs\_filter - Set flag Enable trigger And after this, click on create function. ![](https://fastnetmon.com/wp-content/uploads/2020/04/setup_lambda-979x1024.png)On next page you will need to set “Runtime” to “Go 1.x”, then set”HandlerInfo” to fastnetmon\_flowlogs\_lambda”, set option “Code entry type” to “Upload zip file” and upload [this file](https://github.com/FastNetMon/fastnetmon_flowlogs_lambda/releases/download/1.0.0/lambda-handler.zip) . To specify FastNetMon’s address you need to add Environment variable with name “fastnetmon\_server\_address” set to “10.10.10.10:8104” (please change to correct external IP address of EC2 instance or another server, please do not use internal IPs from instances here, Lambda does not have permissions to use them). After finishing all steps, click “Save”. ![](https://fastnetmon.com/wp-content/uploads/2020/04/conf_lambda-1024x338.png)That’s one more time to check that everything works as expected. Let’s open CloudWatch then select “Logs”, “Log groups” and open “/aws/lambda/process\_vpc\_flow\_fastnetmon”. This log group was created for default logging from our Lambda. We ill use it to confirm that Lambda is working fine. You will see the following entries if lambda works fine: ![](https://fastnetmon.com/wp-content/uploads/2020/04/lambda_output-1024x59.png)To confirm the correctness of the setup, we recommend using the following option on FastNetMon to dump every received packet into a log file: ``` sudo fcli set main dump_all_traffic enable sudo fcli commit ``` After this, you can monitor all arriving packets with the following command: ``` sudo tail -f /var/log/fastnetmon/fastnetmon.log ``` As a final step, specify the [average calculation time](https://fastnetmon.com/docs-fnm-advanced/what-is-average_calculation_time/) value: ``` sudo fcli set main average_calculation_time 60 sudo fcli commit ``` **Document Categories:** Capture engines --- ### [FastNetMon and Google Compute GCE VPC Flow logs](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-and-google-compute-gce-vpc-flow-logs/) **Published:** April 13, 2020 **Author:** Pavel Odintsov **Content:** FastNetMon can ingest data from Google's VPC Flow logs easily. Let's start from required configuration steps on GCE side. You need to open VPC Networks and enable VPC Flow logs for all required regions. We will use europe-west3 as example. Open VPC configuration and then select Edit and enable flag for "Flow logs", select Aggregation interval "5" seconds, select flag "Include metadata" and select sample rate 50%. ![](https://fastnetmon.com/wp-content/uploads/2020/04/flow_logs-1024x811.png)After saving changes your will see "View flow logs" link on VPC, click on it to confirm that you receive flow entries for particular VPC. You will see entries like these if it was enabled properly: ![](https://fastnetmon.com/wp-content/uploads/2020/04/logs-1024x50.png)As next step we need to export flow entries into Pub/Sub interface to process them from FastNetMon. On top panel you need to select "Create Sink". ![](https://fastnetmon.com/wp-content/uploads/2020/04/Create_sink-1024x70.png)After that, on right panel specify name "fastnetmon\_eu\_west3\_sub\_sub\_export", Sink Service "Pub/Sub" and in field "Sink destination" select "Create New Cloud Pub Sub topic" with name "fastntemon\_eu\_west3\_topic" and click on "Create sink". ![](https://fastnetmon.com/wp-content/uploads/2020/04/sink.png)We're ready to read VPC flow data from this Pub/Sub topic and we need to have compute instance with access to Pub/Sub for reading. Open configuration for your existing VM, stop it and then click on Edit and wait for machine shutdown. After shutdown, you need to find "Access scopes" and select "Set access for each API" and set flag enable for "Cloud Pub/Sub". After that, save and start VM. ![](https://fastnetmon.com/wp-content/uploads/2020/04/access.png)![](https://fastnetmon.com/wp-content/uploads/2020/04/apis.png)As next step, please enable [Tera Flow](https://fastnetmon.com/tera-flow/) plugin in FastNetMon: ``` sudo fcli set main tera_flow enable sudo fcli set main tera_flow_host 0.0.0.0 sudo fcli set main tera_flow_ports 8104 sudo fcli commit ``` To convert data from VPC Flow log format you will need to download this [tool](https://drive.google.com/file/d/1wiBg_Q0OvJ40SluVW-K9X2gCUVvmH000/view?usp=sharing). After downloading, please specify executable flag for it. You need to run this tool on GCE to have access to Pub/Sub. ``` chmod +x gce_flow_logs_processor ``` And run using following syntax: ``` ./gce_flow_logs_processor -topic_id fastntemon_eu_west3_topic -tera_flow_server 127.0.0.1:8104 ``` After these steps, you will see lots of log entries about traffic and in same time this information will be exported to FastNetMon. You need to keep this intermediate daemon running all the time to feed data into FastNetMon, you can use screen session or run it as daemon. **Document Categories:** Capture engines --- ### [FastNetMon Netflow v9 configuration for Cisco ASR 1000](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-netflow-v9-configuration-for-cisco-asr-1000/) **Published:** November 15, 2022 **Author:** Pavel Odintsov **Content:** We suggest the following configuration from ASR 1000 (including 1001-X) series of Cisco routers: ``` flow record netflow_record_v4 match ipv4 tos match ipv4 protocol match ipv4 source address match ipv4 destination address match transport source-port match transport destination-port match interface input collect interface output collect counter bytes collect counter packets collect timestamp sys-uptime first collect timestamp sys-uptime last flow record netflow_record_v6 match ipv6 protocol match ipv6 source address match ipv6 destination address match transport source-port match transport destination-port match interface input collect routing next-hop address ipv6 collect ipv6 dscp collect ipv6 hop-limit minimum collect ipv6 hop-limit maximum collect transport tcp flags collect interface output collect counter bytes collect counter packets collect timestamp sys-uptime first collect timestamp sys-uptime last flow exporter netflow_exporter destination 10.10.10.1 source Loopback0 transport udp 2055 template data timeout 60 option interface-table timeout 60 option sampler-table timeout 60 flow monitor netflow_monitor_v4 exporter netflow_exporter cache timeout active 30 cache timeout inactive 30 record netflow_record_v4 flow monitor netflow_monitor_v6 exporter netflow_exporter cache timeout active 30 cache timeout inactive 30 record netflow_record_v6 sampler sampler mode random 1 out-of 1000 ``` Also, please set these options for all interfaces: ``` ip flow monitor netflow_monitor_v4 sampler sampler input ip flow monitor netflow_monitor_v4 sampler sampler output ipv6 flow monitor netflow_monitor_v6 sampler sampler input ipv6 flow monitor netflow_monitor_v6 sampler sampler output ``` FastNetMon can detect the sampling rate from routers automatically in almost all cases. You can check the detected sampling rate per router this way: ``` sudo fcli show netflow_sampling_rates ``` It may detect the sampling rate incorrectly when you have multiple samplers configured on routers. That’s a technical restriction; please avoid this configuration. FastNetMon can detect the sampling rate when you have only a single sampler. As an option, if you need multiple samplers, please set them to the same sampling rate. Also, you may check system counters to confirm that FastNetMon received and decoded sampling announcements from routers: ``` sudo fcli show system_counters |grep netflow9 |grep sampling netflow9_custom_sampling_rate_received 8688 netflow9_sampling_rate_changes 1 ``` If you see zero values, you may check that FastNetMon received options Netflow packets (they carry all meta information about Netflow exporters): ``` sudo fcli show system_counters |grep netflow9 |grep options netflow9_options_templates_number 844 netflow9_options_packet_number 1448 ``` As a fallback option, you can configure the sampling rate manually in FastNetMon this way: ``` sudo fcli set main netflow_sampling_ratio 1000 ``` For specified active and inactive timeouts, we can suggest using the following average calculation time values: ``` sudo fcli set main average_calculation_time 60 sudo fcli commit ``` If you noticed an incorrect bandwidth calculation, we suggest using [visual traffic](https://fastnetmon.com/advanced-visual-traffic/) for debugging purposes. And after that, please check out the dashboard “Netflow v9 metrics” from the default dashboard list. **Document Categories:** Netflow and IPFIX --- ### [FastNetMon Advanced IPFIX configuration for A-10 Networks Thunder](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-ipfix-configuration-for-a-10-networks-thunder/) **Published:** September 12, 2023 **Author:** Pavel Odintsov **Content:** To configure A10 Networks Thunder to work with FastNetMon, apply the following changes on A10 Networks side: ``` netflow monitor fnm protocol v10 record nat44 destination 10.0.0.100 2055 flow-timeout 1 resend-template timeout 60 source-address ip 10.0.0.1 ! ``` Unfortunately, flow timeout uses minutes and 60 seconds; it is the best flow timeout we can get. To specify [average calculation time](https://fastnetmon.com/docs-fnm-advanced/what-is-average_calculation_time/) value: ``` sudo fcli set main average_calculation_time 60 sudo fcli commit ``` **Document Categories:** Netflow and IPFIX --- ### [App Packet SR Plugin](https://fastnetmon.com/docs-fnm-advanced/app-packet-sr-plugin/) **Published:** December 2, 2023 **Author:** Pavel Odintsov **Content:** This plugin provides the capability to decode the format used by Nokia SR routers in their layer 3 encapsulated UDP shim-enabled port mirror format. You can use this capability starting from 2.0.357. We recommend checking official [guides](https://documentation.nokia.com/sr/25-10/7750-sr/books/oam-diagnostics/mirror-services.html#ai9exgsu19) to learn more about it. You need to enable the plugin in the following way: ``` sudo fcli set main app_packet_sr true sudo fcli commit ``` After this, you need to add at least one address to listen for traffic: ``` sudo fcli set main app_packet_sr_local_addresses udp://0.0.0.0:3000 sudo fcli commit ``` If you use packet clipping when the router crops the packet before exporting, you need to addthe following option: ``` sudo fcli set main app_packet_sr_read_packet_length_from_ip_header true sudo fcli commit ``` If you use GRE traffic, you need to set this option: ``` sudo fcli set main app_packet_sr_tunnel_traffic true sudo fcli commit ``` Starting from 2.0.374 you can specify sampling rate for this mode that way: ``` sudo fcli set main app_packet_sr_sampling_ratio 100 sudo fcli commit ``` Please note that in latest releases Nokia switched to use version 2 in SHIM header and you need to upgrade to version [2.0.374](https://fastnetmon.com/2026/03/09/fastnetmon-advanced-2-0-374/) or later to support it **Document Categories:** Netflow and IPFIX --- ### [FastNetMon integration with TNSR high-performance router and VPN concentrator](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-integration-with-tnsr-high-performance-router-and-vpn-concentrator/) **Published:** December 19, 2023 **Author:** FastNetMon **Content:** [Netgate](https://www.netgate.com/)® TNSR® is a high-performance router and VPN concentrator. This article provides detailed information on how to configure FastNetMon Advanced with TNSR software. ### TNSR overview [TNSR](https://www.netgate.com/tnsr) software is a high-speed (exceeding 100 Gbps) virtual router and VPN concentrator. Businesses can deploy TNSR as a [Netgate hardware appliance](https://shop.netgate.com/), Bare Metal Image, KVM and ESXi, or a Network Virtual Appliance on [Amazon® Web Services](https://aws.amazon.com/marketplace/pp/prodview-ljejxqker2ndg) and [Microsoft® Azure®](https://azuremarketplace.microsoft.com/en-ca/marketplace/apps/netgate.netgate-tnsr-azure-fw-vpn-router?tab=Overview). TNSR software leverages several open-source projects (VPP) and Netgate value-added software. Netgate integrates these technologies into an enterprise-grade turnkey software solution complemented by Netgate-assured testing, release packaging, and customer support. ![](https://fastnetmon.com/wp-content/uploads/2023/12/netgate_features-1024x1024.png)### FastNetMon and TNSR Software IPFIX Configuration Steps In this section, we will provide detailed instructions on how to integrate FastNetMon with IPFIX using the TNSR High-Performance Router and VPN Concentrator. In the following example, we are going to collect traffic flow information on the WAN interface of the TNSR edge router and send IPFIX data to the FastNetMon collector, which resides somewhere on the LAN side of the network. For the detailed IPFIX configuration guide, please follow this [link](https://docs.netgate.com/tnsr/en/latest/monitoring/ipfix.html). ![](https://fastnetmon.com/wp-content/uploads/2023/12/netgate_scheme.png)The first step is to configure the FastNetMon IP address and port number, to which TNSR will deliver IPFIX data, and how it delivers that data. FastNetMon uses port 2055 by default. ``` ipfix exporter fastnetmon source 192.0.2.1 collector 203.0.113.10 port 2055 pmtu 1400 template-interval 20 checksum true exit ``` The TNSR WAN interface connected to the internet is the observation point in our scenario, with both egress and ingress directions configured. ``` ipfix observation-point fastnetmon interface WAN direction both exit ``` “Selection-process” allows you to control what IP traffic you want to collect: IPv4, IPv6, or both. ``` ipfix selection-process fastnetmon selector all exit ``` The cache behaviour for IPFIX flows can also be fine-tuned. For example, collectors may prefer to receive flows more/less often, or changes in templates may need to happen more frequently. For more details about timeouts, [see here](https://fastnetmon.com/docs-fnm-advanced/what-is-average_calculation_time/). ``` ipfix cache fastnetmon timeout-cache active-timeout 15 timeout-cache idle-timeout 20 exit ``` Then you need to adjust [average\_calculation\_time](https://fastnetmon.com/docs-fnm-advanced/what-is-average_calculation_time/) on FastNetMon to match these values: ``` sudo fcli set main average_calculation_time 30 sudo fcli commit ``` Here are the steps for troubleshooting TNSR software: - IPFIX traffic port 2055 is allowed between TNSR and FastNetMon. - Verify that the FastNetMon server is pingable from TNSR - FastNetMon IP address in the TNSR routing table: ``` tnsr# sh route table ipv4-VRF:0 203.0.113.10/32 Route Table ipv4-VRF:0 AF: ipv4 ID: 0 ----------------------------------------- 203.0.113.0/24 via 192.0.2.1 LAN weight 1 ``` Additional Resources: - [TNSR IPFIX Configuration Guide](https://docs.netgate.com/tnsr/en/latest/monitoring/ipfix.html) - [TNSR Documentation](https://docs.netgate.com/tnsr/en/latest/index.html) If you are a [Netgate](https://www.netgate.com/) customer and need help, you can contact the Netgate support team [here](https://www.netgate.com/tac-support-request). **Document Categories:** Netflow and IPFIX --- ### [Juniper: handling jFlow/IPFIX export issues](https://fastnetmon.com/docs-fnm-advanced/juniper-handling-jflow-ipfix-export-issues/) **Published:** September 21, 2019 **Author:** Pavel Odintsov **Content:** If you use IPFIX or jFlow with [Juniper MX](https://fastnetmon.com/docs/junos_integration/) you may notice that you can see only a fraction of your traffic, or you do not observe any traffic at all. There are many reasons why it may happen, but as a first step, we recommend checking flow export statistics using this command: ``` run show services accounting flow inline-jflow fpc-slot 0 ``` Example output looks like the following: ``` Flow information FPC Slot: 0 Flow Packets: 351249300, Flow Bytes: 442103634726 Active Flows: 392, Total Flows: 81309409 Flows Exported: 141878284, Flow Packets Exported: 139750373 Flows Inactive Timed Out: 31317878, Flows Active Timed Out: 49991139 Total Flow Insert Count: 31318270 IPv4 Flows: IPv4 Flow Packets: 350051006, IPv4 Flow Bytes: 440445759152 IPv4 Active Flows: 391, IPv4 Total Flows: 81055216 IPv4 Flows Exported: 141405211, IPv4 Flow Packets exported: 139277471 IPv4 Flows Inactive Timed Out: 31226179, IPv4 Flows Active Timed Out: 49828646 IPv4 Flow Insert Count: 31226570 IPv6 Flows: IPv6 Flow Packets: 1198294, IPv6 Flow Bytes: 1657875574 IPv6 Active Flows: 1, IPv6 Total Flows: 254193 IPv6 Flows Exported: 473073, IPv6 Flow Packets Exported: 472902 IPv6 Flows Inactive Timed Out: 91699, IPv6 Flows Active Timed Out: 162493 IPv6 Flow Insert Count: 91700 ``` Another very useful command to see if we have any issues is the following: ``` show services accounting errors inline-jflow fpc-slot 0 ``` Example output may look like the following: ``` Error information FPC Slot: 0 Flow Creation Failures: 4783091798 Route Record Lookup Failures: 0, AS Lookup Failures: 0 Export Packet Failures: 0 Memory Overload: No, Memory Alloc Fail Count: 0 IPv4: IPv4 Flow Creation Failures: 4783091798 IPv4 Route Record Lookup Failures: 0, IPv4 AS Lookup Failures: 0 IPv4 Export Packet Failures: 0 ``` In some cases, this issue may happen when you have very small IPv4 Flow Tables, and the router cannot store all flows. As a consequence, FastNetMon will see only part of your bandwidth. From Juniper router's perspective, you may confirm the issue using this command: A large number of "Flow Creation Failures" errors means that you experience an issue caused by a very small flow table size. You can confirm the current size of the table that way: ``` start shell pfe network fpcX show jnh 0 inline-services flow-table-info ``` Example output: ``` Configured IPv4 Flow Table in Unit: 0 Configured IPv6 Flow Table in Unit: 0 Configured VPLS Flow Table in Unit: 0 Programmed IPv4 Flow Table Size : 3932160 Programmed IPv6 Flow Table Size : 1024 Programmed VPLS Flow Table Size : 1024 IPv6 Extended Attribute : 0 IPv4 Ring Buffer Size : 262144 IPv6 Ring Buffer Size : 262144 VPLS Ring Buffer Size : 262144 ``` Juniper allows setting ipv4-flow-table-size up to 245. Each entry means 256K flows in table. But we do not recommend using the maximum value as it may overload the router. Instead, we suggest using a slow process to increase it: 15, 20, 30, 40, 50, until the number of 90, 180, 180+ second flows disappears from FastNetMon completely. NB! Changes mentioned in the next section may cause immediate card/router reboot (prior 16.1R1 and 15.1F2). Please be very careful! You can apply flow-table-size this way: ``` set chassis fpc inline-services flow-table-size ipv4-flow-table-size 30 ``` After applying changes, you may see that values in sections “Configured IPv4 Flow Table in Unit” and “Programmed IPv4 Flow Table Size” (can be calculated from “IPv4 Flow Table in Unit” using multiplication by 256k) do not match each other. In this case, you have to reboot your router. **Document Categories:** Netflow and IPFIX --- ### [Aggregation free Netflow and IPFIX with packet payload](https://fastnetmon.com/docs-fnm-advanced/netflow-lite-and-ipfix-inline-monitoring-services/) **Published:** August 4, 2022 **Author:** Pavel Odintsov **Content:** This family of protocols can be called PSAMP, and it's well described in this RFC. It works by delivering truncated raw packet headers encoded in Netflow v9 or IPFIX formats to the collector. These protocols do not implement any aggregation at all. Hardware just randomly samples a packet, wraps it into an IPFIX / Netflow packet and sends it to the collector. Please ensure that you run at least version 2.0.361 before moving forward with this guide, as we made multiple significant changes for protocol support. Family of these protocols includes: - IPFIX inline monitoring services, available in Juniper MX and PTX - IPFIX 315 by Cisco, available in ASR 9000, [NCS 5500](https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5500/netflow/70x/configuration/guide/b-netflow-cg-ncs5500-70x/m-about-ipfix.html) - ie315 by Nokia SR starting from 25.7.R1 - Netflow v9 lite from Cisco, mostly available in switches Instead of adding separate fields for port numbers, IP addresses, protocol IDs and other information from network packets, these network telemetry protocols just add the first X bytes (60-100) of the packet header and deliver it to the collector. In this way, they behave like sFlow, but they use Netflow and IPFIX protocols as transport to carry this data as they're way more flexible. Such an approach provides great benefits as we have access to all information available in the packet and we're not limited by the number of fields provided by the vendor. In addition to that, both protocols have no export delay and no flow aggregation. Both protocols offer extremely fast DDoS detection time, which can be in the range of a few seconds. In most cases, it is implemented in hardware, and it makes it one of the most attractive protocols for network monitoring. This family of protocol uses standard for Netflow or IPFIX way of [sampling encoding](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-netflow-and-ipfix-sampling-configuration/), which is completely supported by FastNetMon. To enable support for each protocol, you need to enable [Netflow / IPFIX plugin](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-configuration-for-netflow-and-ipfix/) first. To confirm that these parsers work as intended, we offer the following system metrics: ``` sudo fcli show system_counters|egrep 'lite|inline' netflow_v9_lite_headers 0 netflow_v9_lite_header_parser_error 0 ipfix_inline_headers 0 ipfix_inline_header_parser_error 0 ``` As these protocols do not use aggregation, you can set a very short average calculation time to detect a DDoS attack in a matter of seconds: ``` sudo fcli set main average_calculation_time 3 ``` For Juniper MX, we can offerthe following configuration example, which enables IPFIX inline monitoring services on the router: ``` set services inline-monitoring template FastNetMonInlineTemplate template-refresh-rate 30 set services inline-monitoring template FastNetMonInlineTemplate option-template-refresh-rate 100 set services inline-monitoring template FastNetMonInlineTemplate observation-domain-id 1 set services inline-monitoring instance FastNetMon-instance template-name FastNetMonInlineTemplate set services inline-monitoring instance FastNetMon-instance maximum-clip-length 126 set services inline-monitoring instance FastNetMon-instance collector FastNetMon-collector source-address 10.20.30.40 set services inline-monitoring instance FastNetMon-instance collector FastNetMon-collector destination-address 10.10.10.10 set services inline-monitoring instance FastNetMon-instance collector FastNetMon-collector destination-port 2055 set services inline-monitoring instance FastNetMon-instance collector FastNetMon-collector sampling-rate 1000 set interfaces xe-1/0/7 unit 0 family inet filter input FastNetMon-filter set interfaces xe-1/0/7 unit 0 family inet filter output FastNetMon-filter set firewall family inet filter FastNetMon-filter term 1 then inline-monitoring-instance FastNetMon-instance set firewall family inet filter FastNetMon-filter term 1 then accept ``` To enable telemetry export for IPv6, you need to add the following section: ``` set interfaces xe-1/0/7 unit 0 family inet6 filter input FastNetMon-filter-v6 set interfaces xe-1/0/7 unit 0 family inet6 filter output FastNetMon-filter-v6 set firewall family inet6 filter FastNetMon-filter-v6 term 1 then inline-monitoring-instance FastNetMon-instance set firewall family inet6 filter FastNetMon-filter-v6 term 1 then accept ``` For Cisco ASR 9000, it can be enabled this way, and for [NCS 5500](https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5500/netflow/70x/configuration/guide/b-netflow-cg-ncs5500-70x/m-about-ipfix.html) you need to follow this guide. FastNetMon has logic to strip outer GRE headers for this family of protocols, and it can be enabled ona protocol basis this way: ``` sudo fcli set main netflow_v9_extract_tunnel_traffic true sudo fcli set main ipfix_extract_tunnel_traffic true sudo fcli commit ``` **Document Categories:** Netflow and IPFIX --- ### [FastNetMon Connection tracking](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-connection-tracking/) **Published:** March 28, 2024 **Author:** Pavel Odintsov **Content:** In addition to the capability to track the number of packets or bytes per second for a variety of traffic types ([pre-defined](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-threshold-types/) and [flexible](https://fastnetmon.com/docs-fnm-advanced/flexible-thresholds/)), FastNetMon can calculate the number of incoming and outgoing flows per second for each IP address. This capability is enabled by default, and you can ensure that it's enabled this way: ``` sudo fcli show main enable_connection_tracking ``` After that, you will find the total number of flows per second in your network: ``` sudo fcli show total_traffic_counters incoming traffic 63676 pps incoming traffic 573 mbps incoming traffic 771 flows outgoing traffic 24668 pps outgoing traffic 50 mbps outgoing traffic 762 flows internal traffic 362 pps internal traffic 0 mbps other traffic 6475 pps other traffic 70 mbps ``` In addition to total counters, we maintain flow / second counters for all the hosts in your network: ``` sudo fcli show host_counters incomnig flows 10.1.2.237 6406 pps 61 mbps 33 flows/s 10.1.2.236 5494 pps 53 mbps 32 flows/s 10.1.2.238 5951 pps 52 mbps 31 flows/s 10.1.2.235 4470 pps 42 mbps 30 flows/s 10.1.2.88 454 pps 2 mbps 20 flows/s 10.1.2.93 748 pps 5 mbps 11 flows/s 10.1.2.85 529 pps 5 mbps 5 flows/s 10.1.2.77 689 pps 6 mbps 3 flows/s 10.1.2.139 357 pps 2 mbps 2 flows/s 10.1.2.185 236 pps 1 mbps 2 flows/s ``` Optionally, you can get this counter for a specific host: ``` sudo fcli show single_host_counters 10.1.2.236 dropped_in_bytes 0 dropped_in_packets 0 dropped_out_bytes 0 dropped_out_packets 0 fragmented_in_bytes 0 fragmented_in_packets 0 fragmented_out_bytes 0 fragmented_out_packets 0 icmp_in_bytes 131 icmp_in_packets 0 icmp_out_bytes 1051 icmp_out_packets 0 in_bytes 7870565 in_flows 35 in_packets 6282 out_bytes 756743 out_flows 28 out_packets 2560 tcp_in_bytes 4103972 tcp_in_packets 3005 tcp_out_bytes 133730 tcp_out_packets 1493 tcp_syn_in_bytes 556569 tcp_syn_in_packets 456 tcp_syn_out_bytes 48821 tcp_syn_out_packets 279 udp_in_bytes 3766431 udp_in_packets 3261 udp_out_bytes 621930 udp_out_packets 1043 ``` It is implemented via a capability called connection tracking. FastNetMon accumulates all unique 5 tuples (source IP, destination IP, source port, destination port and protocol number) for each IP address which belongs to your network and calculates their number for each second. It is a rather CPU-intensive operation, and you can track its performance using the following flags: ``` sudo fcli show system_counters|grep flow_counters_calculation_time ipv4_local_host_flow_counters_calculation_time 0.000188 ``` By default, we use 5 tuple to calculate unique flows, but you can optionally change this logic to avoid using ports and stick with 3 tuple (source IP, destination IP, protocol): ``` sudo fcli set main connection_tracking_skip_ports true sudo fcli commit ``` With this capability enabled flow / second metric will calculate the number of unique IPs which contacted your network per second. Please note that if your network telemetry protocol uses any kind of sampling, you will not have flow/second counters working. In the majority of cases, sampling on switches and routers is implemented on a packet basis. For example, when the router observes 1000 packets, and the sampling rate is set to 1:1000, then it will send to FastNetMon only a single flow. FastNetMon can recover the bytes per second and packets per second rate by multiplying the length of this flow by the sampling rate. Unfortunately, flow/second information cannot be recovered similarly. All these 1000 packets may equally belong to a single flow or they may be 1000 unique flows. So we cannot get flow/second counters in this case. If you can accept such inaccuracy, you can multiply the flow/s rate calculated by FastNetMon by the sampling rate used in your network, but it will be mathematically inaccurate. **Document Categories:** Introduction --- ### [FastNetMon Advanced quick start](https://fastnetmon.com/docs-fnm-advanced/advanced-quick-start/) **Published:** December 4, 2017 **Author:** Pavel Odintsov **Content:** In this document, we will help you to set up FastNetMon in sFlow, Netflow / IPFIX or mirror mode. To start this process, you should have [installed FastNetMon](https://fastnetmon.com/advanced-install-guide/). ### Common steps You need to finish these steps for all available capture methods (sFlow, NetFlow, IPFIX, Mirror). Please enumerate all your IPv4 and IPv6 networks in CIDR form: ``` sudo fcli set main networks_list 11.22.33.0/22 sudo fcli set main networks_list beef::1/64 sudo fcli commit ``` We need this information to properly detect the traffic direction. Please note that you cannot use wildcard prefixes like 0.0.0.0/0 as FastNetMon explicitly ignores them in networks\_list. If you have a large number of networks and they change frequently, we have options to read the network list directly from BGP peering connection. Please refer to this [guide](https://fastnetmon.com/subnet-collection-from-bgp-peering-session/). ### Enable traffic capture FastNetMon supports a variety of traffic telemetry protocols. We recommend checking [this](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-navigating-all-available-telemetry-protocols-for-different-vendors/) page to select protocol which works best for your equipment: - [Netflow v5, v9, v10 (IPFIX)](https://fastnetmon.com/fastnetmon-configuration-for-netflow-and-ipfix/) - [sFlow](https://fastnetmon.com/fastnetmon-sflow-configuration/) - [Port mirror](https://fastnetmon.com/fastnetmon-port-mirror-configuration/) - [Nokia L3 sampled mirror](https://fastnetmon.com/app-packet-sr-plugin/) - [FastNetMon Flow](https://fastnetmon.com/docs-fnm-advanced/tera-flow/) - [Amazon AWS VPC Flow logs](https://fastnetmon.com/fastnetmon-and-amazon-vpc-flow-logs/) - [Google GCE VPC Flow logs](https://fastnetmon.com/fastnetmon-and-google-compute-gce-vpc-flow-logs/) ### How to check if it is working? The best way to confirm that FastNetMon calculates traffic correctly is to run command-line client: ``` fastnetmon_client ``` It will show a window like this: ![](https://fastnetmon.com/wp-content/uploads/2023/04/fastnetmon_client-1024x800.png)Alternatively, you can use the command-line tool fcli to see total traffic for IPv4 and IPv6 protocols: ``` sudo fcli show total_traffic_counters sudo fcli show total_traffic_counters_v6 ``` If telemetry was set up correctly, you should see non-zero counters for incoming and outgoing traffic. Total traffic counter types: - Other traffic - “nor source nor destination is known to be part of our list of networks”. Also, it may be a non-IP (for example, ARP) traffic too - Internal traffic - traffic where source and destination both belong to your list of networks. FastNetMon does not trigger DDoS alerts for such traffic at all If you see a significant amount of other traffic, then it may bea good idea to enable the following option temporarily to dump all flows classified as other to /var/log/fastnetmon/fastnetmon.log to find all networks you've missed during setup: ``` sudo fcli set main dump_other_traffic true sudo fcli commit ``` You could check the load for all your IPv4 and IPv6 networks in the following way: ``` sudo fcli show network_counters sudo fcli show network_counters_v6 ``` To see the top 10 IPv4 or IPv6 hosts in your network, you can use the following command: ``` sudo fcli show host_counters bytes outgoing sudo fcli show host_counters_v6 bytes outgoing ``` To get traffic for specific IPv4 or IPv6 hosts, you can use the following command: ``` sudo fcli show single_host_counters 10.1.2.3 sudo fcli show single_host_counters_v6 beef::1 ``` ### Detection modes FastNetMon offers multiple ways to defend your network from DDoS attacks: - [Blackhole mode](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-bgp-blackhole-automation/), in this mode FastNetMon blocks the attacked host using BGP Blackhole and effectively unplugs it from the Internet to move malicious traffic away from your network and keep its uptime. - [Total hostgroup](https://fastnetmon.com/docs-fnm-advanced/per-hostgroup-thresholds/) logic offers the ability to create BGP announces or alerts when the total traffic for a group of networks exceeds a defined value. It may be useful as defence against carpet bombing attacks and as a reliable trigger for traffic diversion to DDoS scrubbing centres. - [BGP Flow spec based](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-bgp-flow-spec-configuration/) mitigation, in this mode, FastNetMon can isolate only malicious traffic and filter it out using your routers. - [Remote host blocking](https://fastnetmon.com/docs-fnm-advanced/automatic-blocks-for-remote-attackers/) offers an option to block attackers using the BGP protocol. **Document Categories:** Introduction --- ### [Screenshots FastNetMon Advanced](https://fastnetmon.com/screenshoots-fastnetmon-advanced/) **Published:** March 11, 2018 **Author:** Pavel Odintsov **Content:** Grafana Dashboard for Traffic database [![Grafana_FTN](https://fastnetmon.com/wp-content/uploads/2019/03/Grafana_FTN-1024x486.png)](https://fastnetmon.com/wp-content/uploads/2019/03/Grafana_FTN.png) Real-time attack notification [![](https://fastnetmon.com/wp-content/uploads/2018/02/advanced-screen-1024x583.png)](https://fastnetmon.com/wp-content/uploads/2018/02/advanced-screen.png) Total traffic dashboard #### [![FastNetMon Advanced visual traffic](https://fastnetmon.com/wp-content/uploads/2017/12/visual-traffic8.png)](https://fastnetmon.com/wp-content/uploads/2017/12/visual-traffic8.png) Per host traffic dashboards ![FastNetMon Advanced visual traffic](https://fastnetmon.com/wp-content/uploads/2017/12/visual-traffic9.png) Per network traffic dashboard ![FastNetMon Advanced visual traffic](https://fastnetmon.com/wp-content/uploads/2017/12/visual-traffic10.png) Per-network traffic overview dashboard ![FastNetMon Advanced visual traffic](https://fastnetmon.com/wp-content/uploads/2017/12/visual-traffic7.png) Command line real-time reporting interface (fastnetmon\_client) #### [![](https://fastnetmon.com/wp-content/uploads/2018/03/advanced_fastnetmon_client-1024x498.png)](https://fastnetmon.com/wp-content/uploads/2018/03/advanced_fastnetmon_client.png) FastNetMon's command line interface [![](https://fastnetmon.com/wp-content/uploads/2018/03/fcli_screen-1024x595.png)](https://fastnetmon.com/wp-content/uploads/2018/03/fcli_screen.png) Traffic persistence database [![](https://fastnetmon.com/wp-content/uploads/2018/03/sql_traffic_database-1024x488.png)](https://fastnetmon.com/wp-content/uploads/2018/03/sql_traffic_database.png) **Document Categories:** Introduction --- ### [FastNetMon Advanced high availability setup](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-high-availability-setup/) **Published:** July 12, 2018 **Author:** Pavel Odintsov **Content:** To achieve a high availability setup (HA), you can deploy multiple independent instances of FastNetMon and feed the same traffic to them. In this case, you need to use the same configuration for all instances to keep their behaviour the same. We suggest using similar hardware if you can afford it. Additionally, if you have multiple network devices which can generate traffic telemetry for the same traffic (sFlow, Netflow, IPFIX and others), you can use different sources of traffic information to handle the case where one device misbehaves and can't export traffic information to FastNetMon. For example, you have sFlow from switches and Netflow from the router, and they see the same traffic. In this case, you can feed traffic from the switch to the first instance of FastNetMon and feed traffic from the router to another instance. In this case, both instances will see traffic using different sources and detect attacks. Usually, network equipment (routers or switches) can support streaming to multiple Netflow/sFlow collectors. Even if it does not support this option, we have a guide about traffic duplication with [external tool](https://fastnetmon.com/sflow-netflow-or-ipfix-duplication-to-multiple-servers/). If you use BGP diversion/blackhole, you can establish an independent session with all your routers from all FastNetMon instances. Routers can handle duplicate announces very well. If you use any kind of API integration, you need to add more checks in notify scripts to avoid duplicate calls for the same event generated by different instances. As an example, you can implement it in the following way: - 00:00:01: FastNetMon #1 detected attack to 10.0.0.1/32 - 00:00:02: FastNetMon #1 triggered and executed script which created notification in the CRM system - 00:00:03: FastNetMon #2 detected attack to 10.0.0.1/32 - 00:00:04: FastNetMon #2 discovered that a notification was sent recently and suppress any additional actions **Document Categories:** Introduction --- ### [FastNetMon Advanced deployment scenarios](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-deployment-scenarios/) **Published:** September 5, 2018 **Author:** Pavel Odintsov **Content:** FastNetMon is a very flexible software, and you can use almost any possible deployment option. We selected the two most popular cases and explained them in detail. If you have something more complicated, do not hesitate to contact our support team. We have a number of internal cases and examples of FastNetMon deployment. ### BGP connectivity FastNetMon uses the following protocols to manage traffic: - BGP v4 unicast (implements RTBH or BGP traffic diversion) - BGP v4 Flow Spec / RFC 5575 (selectively filters out malicious traffic) You will need to have a BGP peering session with your routers to inject rules. ### Router-based setup Almost all routers provide some way to export information about traffic. FastNetMon supports the following protocols to receive traffic information from routers: - Netflow v5 - Netflow v9 - IPFIX - Netstream - jFlow - cFlow - sFlow v5 In this case, you can deploy FastNetMon in any place in your network. To reduce the probability of congestion, we suggest using a direct connection between the router and server or VM with FastNetMon. ![](https://fastnetmon.com/wp-content/uploads/2018/09/SwitchSetup-1024x588.png)### Switch-based setup If your router does not provide any traffic visibility options or if traffic information export causes CPU overload, you can export traffic information from your switch. Also, you may consider port mirror/SPAN capture too. Switches usually support the following traffic export options, and FastNetMon supports all of them: - sFlow v5 - Netflow v9 - IPFIX ![](https://fastnetmon.com/wp-content/uploads/2018/09/RouterSetup-1024x570.png)### Mixed setup You can use this approach as part of HA scenario and export traffic from the router and from switch/traffic mirror at the same time. We have a dedicated article about the [HA scenario](https://fastnetmon.com/fastnetmon-advanced-high-availability-setup/). ### Distributed setup If you run a large network which includes multiple PoPs / Data Centres, you may read about our distributed deployment options on our [page](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-multi-pop-data-centre-deployment-options/). **Document Categories:** Introduction --- ### [FastNetMon multi PoP / Data Centre deployment options](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-multi-pop-data-centre-deployment-options/) **Published:** September 1, 2022 **Author:** Pavel Odintsov **Content:** In case of large geographically distributed networks, you may have multiple options to run FastNetMon. The simplest option to deploy a single central instance of FastNetMon in a location which is well interconnected with all your remote PoPs and send network telemetry traffic to it. In this case, we recommend using private connectivity and encrypted lines to deliver network telemetry, as it carries very sensitive information. You will need to keep BGP connections with remote locations too, and it may be challenging in case of network congestion, which is very likely to happen during DDoS attacks. We recommend running individual FastNetMon instances in each Data Centre/PoPs to avoid dependency on external connectivity, which may be interrupted by an attack. This approach offers the best guarantees about DDoS detection and offers extremely fast attack detection. In addition, it keeps network telemetry traffic local and helps to avoid potential leaks of sensitive information. Our licensing is built with this deployment option in mind, and our licenses starting from 40G allow multiple individual instances. To verify your bandwidth use for licensing purposes, we aggregate traffic from all instances and then apply limits. It is implemented using our very flexible online licensing approach. In case of individual installations of FastNetMon, each site will have its completely independent visibility into its network segment, and DDoS detection will see only traffic from a particular PoP. For some attack types, it may be beneficial to have a global overview of traffic from all sites. It may be useful for networks which deploy BGP anycast and announce the same prefixes from multiple locations, and in this case, it may be very useful to count their traffic usage for all PoPs. To implement it, you may send copies of network telemetry to a local instance of FastNetMon using the device's capabilities, or you can use FastNetMon's own protocol for that [purpose](https://fastnetmon.com/docs-fnm-advanced/tera-flow/). **Document Categories:** Introduction --- ### [Proxmox VM configuration for FastNetMon Advanced](https://fastnetmon.com/docs-fnm-advanced/proxmox-vm-configuration-for-fastnetmon-advanced/) **Published:** April 25, 2023 **Author:** Pavel Odintsov **Content:** To use the Clickhouse-backed dashboard, your CPU needs to support SSE 4.2. To use the latest version of MongoDB, you need to have support for AVX1. Your host CPU may have complete support for both these technologies, but it may be explicitly disabled by Proxmox configuration. For example, it may look this way from your Linux VM on Proxmox: ``` cat /proc/cpuinfo | grep flags | head -1 ``` Example output: ``` flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx lm constant_tsc nopl xtopology cpuid tsc_known_freq pni cx16 x2apic hypervisor lahf_lm cpuid_fault pti ``` Options SSE42 and AVX are clearly missing from this list. To address this issue, you will need to open the CPU configuration and switch the CPU type to "host": ![](https://fastnetmon.com/wp-content/uploads/2023/04/cpu.jpg)After that, you will need to restart the VM to apply the changes. After changes, CPU flags will appear as following: ``` flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq vmx ssse3 cx16 pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx hypervisor lahf_lm cpuid_fault pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid tsc_adjust xsaveopt arat umip md_clear arch_capabilities ``` In this particular case we still have no AVX support but SSE42 is here and we can run Clickhouse without any issues. **Document Categories:** Virtual machines and hypervisors --- ### [FastNetMon ssh shell](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-ssh-shell/) **Published:** October 3, 2023 **Author:** Pavel Odintsov **Content:** Please note that this capability is experimental and can be subject to significant changes. FastNetMon Advanced provides the capability to expose the command line configuration tool fcli via the SSH protocol without using the system SSH server. Such an approach offers better security as it provides access only for FastNetMon specific configuration options and does not provide access to filesystem at all. FastNetMon SSH shell does not use Linux access control, and you can control it completely independent way. To enable this capability, please use at least version 2.0.351. As the very first step, we need to create a systemd service unit for FastNetMon's SSH shell: ``` sudo vim /lib/systemd/system/fastnetmon_ssh_shell.service ``` After this, populate the following content: ``` [Unit] Description=FastNetMon Advanced web API gateway After=network.target remote-fs.target [Service] Type=simple Environment=SSH_SERVER_MODE=on ExecStart=/opt/fastnetmon/app/bin/fcli Restart=on-failure RestartSec=5s [Install] WantedBy=multi-user.target ``` By default, it will use port 2222, but you can change it using the environment variable SSH\_SERVER\_PORT. After this, you need to populate your public ssh key in the same format as for ~/.ssh/authorized\_keys to /etc/fastnetmon/authorized\_keys. You can only put a single key here. Then, start the service: ``` sudo systemctl restart fastnetmon_ssh_shell ``` Enable auto start on machine boot: ``` sudo systemctl enable fastnetmon_ssh_shell ``` Check that the service is up and running: ``` sudo systemctl status fastnetmon_ssh_shell ``` After this, you can access fcli interface via SSH in non non-interactive way: ``` ssh flab1 -p2222 fcli show license Production license for 10000 mbits valid until 2023-10-17 ``` Or using the interactive fcli console: ``` ssh flab1 -p2222 fcli> ``` Where you can run any commands in an interactive shell session: ``` fcli> show license Production license for 10000 mbits valid until 2023-10-17 ``` This interface provides exactly the same commands as regular fcli. **Document Categories:** Deployment --- ### [FastNetMon Advanced manual install process on Ubuntu LTS](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-manual-install-process/) **Published:** February 12, 2019 **Author:** Pavel Odintsov **Content:** In this guide, we will provide a detailed process for installing FastNetMon manually. You may need it when you run FastNetMon in non non-standard environment or use cloud provisioning. In other cases, please use [installer](https://fastnetmon.com/advanced-install-guide/) tool. ### Requirements We support this guide only for Ubuntu 18.04 ### Install process To start with, we will need HTTPS support for APT because FastNetMon's repository is secured using this protocol: ``` sudo apt install -y apt-transport-https libssl1.0.0 iproute2 ``` After that, please sync time. Our license server relies on accurate time, and SSL certificate validation can fail in case of inaccurate time or date. Add FastNetMon's repository: ``` echo "deb [arch=amd64] https://repo.fastnetmon.com/fastnetmon_ubuntu_bionic bionic fastnetmon" | sudo tee /etc/apt/sources.list.d/fastnetmon.list ``` Insert this content into the file fastnetmon.key: ``` -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1 mQINBFenbeUBEADdN/WjudCb0FgC3Oe02R3DriRwzlgirMYGOApT+cfMvsety/Wk SRztjFFkX2K/ywXOSRG1+s95D2KG9Ic9vV+2iGKw7q8++v8I1J/bij4r7rY5Pz7m diC83JjdcjX86rmJ0m2P3trhqWhYhd3yxwinQg1/P9Oydv7EqS8ool4RXz9/QKfd U6KtVTp84F/ONVVZaXv1MPLi/OyG/UJKMuYie0Gw6DCsb4KDVukUZisttk5fucz7 HvWU9cD0Xgqxup0QFSa6uI6Zcq7FAlfujeIISAsAAk7IzaIbCiae89HPbmGG0gtH tSJTgrZKl9oshtZcEOyFDX/Q8dUlzv+GIdbK0BJG8buui+2gRGiANe6glplcQGZE kEqSKRnJNi/1WAG4NLpik8WLDhNGVk1G496GtIQl7yyWnB1awXPQqNUBSazdJR9b 6mHQiz1ZoH1LMP2zCwopGrdxQJsi+8bhx9iDUlJbwDhcmNny5oEsbjBZnSwO6CS7 TKUOgpxiCNQ/p/0dM0IlTz2YdAVFAbXW3A3tq+cKRBTSrIMDsm0pPckhgeuekM4K NSb4Izm5NrlM1+tV/JfUUr7I7jSuSpaIbJBgsC94NvA1K2+T0J/gHzsDOASf6OiB rWZ7u+SMSlha2j5dhB3eqt+UZfErBhmnR6Qy4jKncSlo5FiQDTkhDWKKqwARAQAB tClQYXZlbCBPZGludHNvdiA8cGF2ZWwub2RpbnRzb3ZAZ21haWwuY29tPokCPQQT AQoAJwUCV6dt5QIbAwUJEswDAAULCQgHAwUVCgkICwUWAwIBAAIeAQIXgAAKCRDM fW3ec2JlYw6OEACDOzIrVFTHkRt09Zr5Eoi501+ZH+H0S0+ujuMps76o405lCRZv eUSrLgdGGx6NxkR6x7cGLAeJpn0xuKcVb0fNDwNQQ/wFxsI8h8p0OrIkXJ2I2dX3 8edeNT6Y7dbR7MeSUbRkd5rJECMGT3BJvpHZ8bYosptETlp4HajpTPohZU9poPG/ H+liYcbtFAcw3LqcWzUABqX45UiSittKUgYv4G19/+IkEAjF916fj20HlkZyvU1M aRGfGIQDmLLEsC37iBxfeSmokcb68Ld2uWxTPeZYdAAn2cogu2mO+MKFnCtfGnkP 32IGXcEtTI+dOK6umKiL7tQqmRou2Knx0F4ul7f2i1oTRlf3w5PKKt7BwF572hqW VeGWwVAG4gVEAMncMgFMJPFju9vJX+Zq5WBR8cAJOkA2f6fGsklZgC4qOg/TZeNh WUKdYPXneoh7YMqOY8PaDeVPArk2+N38vsa2sSuSesoo7Xr4b+9D59ZoxEHn6qKs zfIGJqS9dV1OMqwNNi9BDyivor/iDnaoK3xwNsWOg0CjpnFhTLmq1cctO+4pm97q 4JVfmyedg14ADhe3cAsmXWep8v19+OtN3CkHF+HHKULGn3EOIHk7VQmpJlx74y3Q O1QasPDzl2v0nggAJzCng4SkCivzHkP31Y7T4q+WPMjxBfsr9BveAGH6KA== =kFoU -----END PGP PUBLIC KEY BLOCK----- ``` Add key trust storage: ``` sudo apt-key add fastnetmon.key ``` Install FastNetMon: ``` sudo apt-get update sudo apt install -y fastnetmon ``` FastNetMon will fail because you do not have MongoDB. ### MongoDB installation If you use Docker, you may use [standard images](https://hub.docker.com/_/mongo) with MongoDB. Otherwise, you can install it manually. We use version 4.0 for Ubuntu 18.04. You can follow [official guide](https://docs.mongodb.com/manual/tutorial/install-mongodb-on-ubuntu/#install-mongodb-community-edition-using-deb-packages) or you can follow our own guide. Add Mongo repository: ``` echo "deb [ arch=amd64 ] https://repo.mongodb.org/apt/ubuntu bionic/mongodb-org/4.0 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-4.0.list ``` Add Mongo gpg key: ``` sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 9DA31620334BD75D9DCB49F368818C72E52529D4 ``` Install MongoDB: ``` sudo apt-get update sudo apt-get install -y mongodb-org ``` Load MongoDB: ``` sudo systemctl enable mongod sudo systemctl start mongod ``` Create users in MongoDB. NB! Please replace "<secret\_password>" and "<fastnetmon\_secure\_pasword>" by secure passwords with at least 16 symbols. Open MongoDB console: ``` mongo --host 127.0.0.1 ``` Create administrator: ``` use admin db.createUser( { user: "administrator", pwd: "secret_password", roles: [ { role: "userAdminAnyDatabase", db: "admin" }, { role: "readWriteAnyDatabase", db: "admin" }, { role: "dbAdminAnyDatabase", db: "admin"}, { role: "__system", db: "admin" }] }) ``` Open MongoDB configuration: ``` sudo nano /etc/mongod.conf ``` And near commented line "security" add (it enabled authorisation): ``` security: authorization: enabled ``` Apply changes: ``` sudo systemctl restart mongod ``` Create a folder for FastNetMon's passwords: ``` sudo mkdir -p /etc/fastnetmon/keychain sudo chmod 700 /etc/fastnetmon/keychain ``` And after that, insert the administrator password into this file: ``` echo -n "secret_password" | sudo tee /etc/fastnetmon/keychain/.mongo_admin ``` Log in to MongoDB as administrator: ``` mongo admin --username administrator --password `sudo cat /etc/fastnetmon/keychain/.mongo_admin` ``` Create a user for FastNetMon: ``` use admin db.createUser( { user: "fastnetmon_user", pwd: "fastnetmon_secure_pasword", roles: [ { role: "dbOwner", db: "fastnetmon" } ] } ) ``` Store password for user in file: ``` echo -n "fastnetmon_secure_pasword" | sudo tee /etc/fastnetmon/keychain/.mongo_fastnetmon_password ``` Apply changes: ``` sudo systemctl restart mongod ``` Confirm that you can log in to MongoDB using user credentials: ``` mongo --host 127.0.0.1 -u fastnetmon_user -p `sudo cat /etc/fastnetmon/keychain/.mongo_fastnetmon_password` --authenticationDatabase admin ``` Specify MongoDB access credentials for FastNetMon (you do not need it for localhost case, but you have to specify the remote server when you use it): ``` sudo nano /etc/fastnetmon/fastnetmon.conf ``` Default configuration: ``` { "mongodb_host": "127.0.0.1", "mongodb_port": 27017, "mongodb_database_name": "fastnetmon", "mongodb_username": "fastnetmon_user", "mongodb_auth_source": "admin" } ``` Create default configuration: ``` sudo fcli create_configuration ``` Restart FastNetMon: ``` sudo systemctl restart fastnetmon ``` Confirm that FastNetMon is running properly: ``` sudo fcli show system_counters ``` **Document Categories:** Deployment --- ### [Migration from Community edition to Advanced](https://fastnetmon.com/docs-fnm-advanced/migration-from-community-edition-to-advanced/) **Published:** March 3, 2019 **Author:** Pavel Odintsov **Content:** We offer a migration tool which can convert your configuration for FastNetMon Community into a format suitable for FastNetMon Advanced. You need to [install Advanced version](https://fastnetmon.com/docs-fnm-advanced/advanced-install-guide/) first. After that, you can run this command. It will read FastNetMon Community configuration from /etc/fastnetmon.conf and will create the same configuration for FastNetMon Advanced. To avoid any issues, we recommend creating a backup of the old FastNetMon Advanced configuration using this guide before running the import tool. ``` wget https://install.fastnetmon.com/installer -Oinstaller sudo chmod +x installer sudo ./installer -import_community_edition_configuration ``` **Document Categories:** Deployment --- ### [Manual installation FastNetMon Advanced on Google Compute Engine](https://fastnetmon.com/docs-fnm-advanced/installing-fastnetmon-advanced-on-google-compute-engine/) **Published:** March 18, 2019 **Author:** Pavel Odintsov **Content:** In this guide, we will provide a detailed guide to deploy FastNetMon in Google Compute Engine. To start with, please create an instance with at least two CPU cores and 4-7GB of memory with at least 20 GB of disk space. ![](https://fastnetmon.com/wp-content/uploads/2019/03/instance_fastnetmon-560x1024.png)After creating an instance, please open the network configuration for it to add a static external IP address, as the FastNetMon license server relies on it. ![](https://fastnetmon.com/wp-content/uploads/2019/03/network_configuration-1024x345.png)After opening the network configuration, select network details, and you will see the following panel: ![](https://fastnetmon.com/wp-content/uploads/2019/03/external_ip-1024x562.png)Finally, select the external IP address on the left side ![](https://fastnetmon.com/wp-content/uploads/2019/03/static_external_ip-1024x511.png)After assigning IP to this machine, log in into SSH using your favourite SSH client and start the installation process: ``` wget https://install.fastnetmon.com/installer -Oinstaller sudo chmod +x installer sudo ./installer -activation_coupon your_coupon_from_email ``` After finishing the installation process, please check the license status, and then you can continue to [quick start guide](https://fastnetmon.com/advanced-quick-start/). **Document Categories:** Public cloud deploy --- ### [Amazon AWS Network Traffic Monitoring with FastNetMon](https://fastnetmon.com/aws-network-analytics/) **Published:** April 12, 2021 **Author:** FastNetMon **Content:** Operating workloads in Amazon AWS introduces new challenges for network visibility and security. Traffic is distributed across regions, services, and shared infrastructure, while traditional packet capture is not available. FastNetMon provides flow-based network traffic monitoring and DDoS detection for AWS by integrating with native Amazon services. Using VPC Flow Logs as the primary telemetry source, FastNetMon enables operators to analyse traffic patterns, detect anomalies, and gain visibility into cloud network behaviour. ## **Flow-Based Visibility Using VPC Flow Logs** In AWS environments, FastNetMon relies on Amazon VPC Flow Logs to collect network telemetry. VPC Flow Logs provide metadata about traffic flowing to and from network interfaces within a Virtual Private Cloud. FastNetMon processes this flow data and converts it into its internal traffic representation, enabling consistent monitoring across cloud and on-premise environments. This approach avoids the need for packet inspection and works at scale within AWS constraints. ## **Native AWS Components Integration** FastNetMon integrates with several AWS-native services to collect and process flow data. Amazon Lambda is used to receive VPC Flow Logs, transform them into a format supported by FastNetMon, and forward them for analysis. This process is automated once configured and does not require manual intervention during operation. FastNetMon can also use the Amazon API to retrieve metadata about cloud resources. This includes mapping internal IP addresses used by virtual machines or load balancers to external IP addresses where required. This mapping allows traffic statistics and detections to be presented in a way that is meaningful for operators monitoring internet-facing services. ## **Cloud Traffic Analytics and Cost Visibility** Understanding traffic patterns in AWS is critical not only for security, but also for cost control. FastNetMon helps identify which regions, services, and external networks generate the most traffic to and from your VPCs. This visibility supports capacity planning, optimisation of data transfer costs, and informed decisions about architecture changes such as load balancing, regional deployments, or use of CDNs. ## **Deployment Models in AWS** FastNetMon can be deployed directly within AWS as a virtual machine instance. Two common deployment models are supported. A single central FastNetMon instance can collect and analyse flow data from multiple AWS regions. Alternatively, separate FastNetMon instances can be deployed per region to keep traffic telemetry local and avoid transferring flow data across regions or external networks. The choice depends on operational, security, and data residency requirements. ## **DDoS Detection in Cloud Environments** Using flow data from VPC Flow Logs, FastNetMon monitors traffic rates, packet counts, and flow characteristics to detect abnormal patterns that may indicate DDoS attacks. This enables early detection of volumetric and protocol-level attacks affecting cloud workloads, even in environments where traditional network-level controls are limited. ## **Network Visibility for AWS at Scale** FastNetMon integrates with AWS services such as VPC Flow Logs, Lambda, and the Amazon API to provide reliable, scalable network traffic visibility without requiring changes to application workloads. The same FastNetMon platform can be used across cloud and on-premise environments, simplifying operations and tooling. ## **Get Started with FastNetMon on AWS** FastNetMon helps you gain clear visibility into your AWS network traffic and detect DDoS attacks using native cloud telemetry. Start a **free trial** to evaluate FastNetMon in your AWS environment, or **contact our sales team** to discuss deployment options and architecture recommendations. --- ### [Blocklist-Based Filtering with FastNetMon](https://fastnetmon.com/blocklist-filtering/) **Published:** March 31, 2021 **Author:** FastNetMon **Content:** Blocklist-based filtering is a practical way to reduce exposure to known malicious hosts by blocking traffic at the network level before it reaches services or customers. FastNetMon supports automated ingestion and enforcement of IP-based blocklists, allowing operators to integrate external threat intelligence feeds or their own curated lists directly into their network mitigation workflows. This approach is commonly used to block traffic associated with malware, phishing infrastructure, botnets, scanners, and other known malicious sources. ## **Flexible Blocklist Ingestion** FastNetMon can consume blocklists from multiple sources and formats. Blocklists may be hosted externally or managed internally, depending on operational requirements. Commonly supported delivery methods include blocklists hosted over HTTP or HTTPS, as well as blocklists stored in object storage such as Amazon S3. FastNetMon regularly retrieves these lists and maintains a local, up-to-date copy for enforcement. Blocklists must consist of individual IP addresses. Prefix aggregation and long CIDR chains are not supported for this feature, ensuring predictable behaviour and precise control. ## **Using External Threat Intelligence Feeds** Many organisations rely on third-party threat intelligence providers to maintain blocklists. These providers typically specialise in specific threat categories and continuously update their data based on global telemetry. FastNetMon can ingest blocklists from multiple intelligence providers at the same time. All received entries are merged into a single internal master blocklist, allowing operators to enforce a unified filtering policy while benefiting from multiple data sources. Update intervals are configurable, giving full control over how frequently blocklists are refreshed and changes propagated to the network. ## **Network-Level Enforcement via BGP** Once a blocklist is loaded, FastNetMon distributes blocking information to routers using BGP. This enables filtering to occur directly at the network edge or core, without relying on application-level controls or firewalls. When new IP addresses are added to a blocklist, FastNetMon automatically announces the corresponding routes to the configured routers. When entries are removed from the blocklist, FastNetMon withdraws the routes, ensuring that traffic is no longer blocked unnecessarily. This fully automated lifecycle ensures that blocking rules remain accurate and aligned with the current state of threat intelligence feeds. ## **Operational Benefits** Blocklist-based filtering with FastNetMon helps reduce unwanted traffic before it consumes bandwidth or processing capacity. By enforcing policies at the routing level, networks gain an additional layer of protection with minimal operational overhead. Because FastNetMon supports multiple feeds and continuous updates, it is well-suited for environments where threat intelligence changes frequently, and manual rule management would be impractical. ## **Part of a Broader DDoS Protection Strategy** Blocklist-based filtering complements FastNetMon’s other DDoS detection and mitigation capabilities, including traffic anomaly detection, BGP Blackhole automation, FlowSpec mitigation, and scrubbing centre diversion. It is most effective when used as one component of a layered, network-level defence strategy. ## **Start Blocking Malicious Traffic with FastNetMon** FastNetMon makes it straightforward to integrate external threat intelligence into your network and enforce blocking policies automatically. Start a **free trial** to evaluate blocklist-based filtering in your environment, or **contact our sales team** to discuss integration options and operational requirements. --- ### [FastNetMon Blog: DDoS News & Network Security Insights](https://fastnetmon.com/blog/) **Published:** March 5, 2026 **Author:** FastNetMon **Content:** # FastNetMon Blog: DDoS News & Network Security Insights [Home](https://fastnetmon.com/ "Home")‣ FastNetMon Blog: DDoS News & Network Security Insights FastNetMon Blog brings you the latest DDoS news, expert analysis, and technical insights on DDoS attacks and network security. As the leading source for DDoS-related content, we cover new threats, attack trends, and protection strategies. Our articles are written for network engineers, security teams, and tech professionals who want to stay ahead of evolving cyber threats. Follow us for updates, how-to guides, and research from the front lines of DDoS defence. [![What Is a DDoS Scrubber? How DDoS Traffic Scrubbing Works](https://fastnetmon.com/wp-content/uploads/2026/10/DDoS-Traffic-Scrubbing-EXPLAINED.png)](https://fastnetmon.com/2026/10/19/what-is-a-ddos-scrubber-how-ddos-traffic-scrubbing-works/) ## [What Is a DDoS Scrubber? How DDoS Traffic Scrubbing Works](https://fastnetmon.com/2026/10/19/what-is-a-ddos-scrubber-how-ddos-traffic-scrubbing-works/) Oct 19, 2026 \| [FastNetMon Blog](https://fastnetmon.com/category/blog/) A DDoS scrubber is a network security system designed to identify and remove malicious traffic during a DDoS attack while allowing legitimate traffic to reach its destination. During a DDoS attack,… [![Faster Packet Filtering on BlueField-3 Arm Cores with VPP’s Native RDMA Driver](https://fastnetmon.com/wp-content/uploads/2026/10/Denys-Haryachyy-Faster-Packet-Filtering-on-BlueField-3-Arm-Cores-with-VPPs-Native-RDMA-Driver.png)](https://fastnetmon.com/2026/10/14/faster-packet-filtering-on-bluefield-3-arm-cores-with-vpps-native-rdma-driver/) ## [Faster Packet Filtering on BlueField-3 Arm Cores with VPP’s Native RDMA Driver](https://fastnetmon.com/2026/10/14/faster-packet-filtering-on-bluefield-3-arm-cores-with-vpps-native-rdma-driver/) Oct 14, 2026 \| [FastNetMon Blog](https://fastnetmon.com/category/blog/), [Featured](https://fastnetmon.com/category/featured/) This post is a repost of a technical blog originally published by Denys Haryachyy, shared here with permission as part of ongoing research and engineering work around FastNetMon’s inline traffic… [![NVIDIA and Cisco Introduce USFP Optics for 12.8 Tbps AI Networking](https://fastnetmon.com/wp-content/uploads/2026/10/NVIDIA-and-Cisco-Unveil-USFP-Optics-to-Scale-AI-Data-Center-Networks-to-12.8-Tbps.png)](https://fastnetmon.com/2026/10/13/nvidia-and-cisco-introduce-usfp-optics-for-12-8-tbps-ai-networking/) ## [NVIDIA and Cisco Introduce USFP Optics for 12.8 Tbps AI Networking](https://fastnetmon.com/2026/10/13/nvidia-and-cisco-introduce-usfp-optics-for-12-8-tbps-ai-networking/) Oct 13, 2026 \| [FastNetMon Blog](https://fastnetmon.com/category/blog/) NVIDIA and Cisco have announced Ultra-Dense Small Form Factor Pluggable (USFP), a new optical transceiver form factor designed for next-generation AI factories and high-performance Ethernet… [![IPv6 DDoS Attacks and Mitigation with FastNetMon](https://fastnetmon.com/wp-content/uploads/2026/10/IPv6-DDoS-attacks-explained.png)](https://fastnetmon.com/2026/10/08/ipv6-ddos-attacks-and-mitigation-with-fastnetmon/) ## [IPv6 DDoS Attacks and Mitigation with FastNetMon](https://fastnetmon.com/2026/10/08/ipv6-ddos-attacks-and-mitigation-with-fastnetmon/) Oct 8, 2026 \| [FastNetMon Blog](https://fastnetmon.com/category/blog/), [Featured](https://fastnetmon.com/category/featured/) IPv6 is now a standard part of many service provider, hosting, data centre and enterprise networks. As more services become reachable over IPv6, network operators also need to make sure that their… [![Packet Filtering with VPP on BlueField-3 Arm Cores and 100G NICs](https://fastnetmon.com/wp-content/uploads/2026/10/Packet-Filtering-with-VPP-on-BlueField-3-Arm-Cores-and-100G-NICs-Denys-Haryachyy.png)](https://fastnetmon.com/2026/10/05/packet-filtering-with-vpp-on-bluefield-3-arm-cores-and-100g-nics/) ## [Packet Filtering with VPP on BlueField-3 Arm Cores and 100G NICs](https://fastnetmon.com/2026/10/05/packet-filtering-with-vpp-on-bluefield-3-arm-cores-and-100g-nics/) Oct 5, 2026 \| [FastNetMon Blog](https://fastnetmon.com/category/blog/), [Featured](https://fastnetmon.com/category/featured/) This post is a repost of a technical blog originally published by Denys Haryachyy , shared here with permission as part of ongoing research and engineering work around FastNetMon’s inline traffic… [![Inside Today’s Botnets – Changing Supply Chain Behind the Terabit Scale Attacks](https://fastnetmon.com/wp-content/uploads/2026/10/Inside-Todays-DDoS-Botnet-Economy-Residential-Proxies-Contested-Android-TVs-and-Blockchain-C2-Outi-Pietilanaho.png)](https://fastnetmon.com/2026/10/02/inside-todays-botnets-changing-supply-chain-behind-the-terabit-scale-attacks/) ## [Inside Today’s Botnets – Changing Supply Chain Behind the Terabit Scale Attacks](https://fastnetmon.com/2026/10/02/inside-todays-botnets-changing-supply-chain-behind-the-terabit-scale-attacks/) Oct 2, 2026 \| [FastNetMon Blog](https://fastnetmon.com/category/blog/) This article is based on the presentation “Tracking Today’s Botnets — Threat Intel & Lessons to Defend Against DDoS”, presented by FastNetMon’s Outi Maria Pietilanaho at NOG.HR Meetup 7 in… [![DDoS Scrubbing Centre Automation Explained: How On-Demand Traffic Diversion Works](https://fastnetmon.com/wp-content/uploads/2025/08/FastNetMon-DDoS-Scrubbing-Centre-Automation-Explained.png)](https://fastnetmon.com/2026/10/01/ddos-scrubbing-centre-automation-explained/) ## [DDoS Scrubbing Centre Automation Explained: How On-Demand Traffic Diversion Works](https://fastnetmon.com/2026/10/01/ddos-scrubbing-centre-automation-explained/) Oct 1, 2026 \| [FastNetMon Blog](https://fastnetmon.com/category/blog/) DDoS scrubbing centre automation is the process of automatically redirecting network traffic to a scrubbing provider when a DDoS attack is detected. Instead of routing traffic through a scrubbing… [![Introducing FastACL Community: Open-Source DDoS Scrubbing](https://fastnetmon.com/wp-content/uploads/2026/09/FastACL-1.png)](https://fastnetmon.com/2026/09/25/introducing-fastacl-community-open-source-ddos-scrubbing/) ## [Introducing FastACL Community: Open-Source DDoS Scrubbing](https://fastnetmon.com/2026/09/25/introducing-fastacl-community-open-source-ddos-scrubbing/) Sep 25, 2026 \| [FastNetMon Blog](https://fastnetmon.com/category/blog/), [Featured](https://fastnetmon.com/category/featured/), [Press & Newsroom](https://fastnetmon.com/category/news-and-media/) For more than a decade, FastNetMon Community has given network operators an open-source option for high-performance DDoS detection. Today, we’re extending that approach from detecting attacks to… [![Introducing Netom: an open-source BGP/BMP monitoring engine built for scale](https://fastnetmon.com/wp-content/uploads/2026/09/Introducing-Netom-BGPBMP-monitoring-at-scale.png)](https://fastnetmon.com/2026/09/24/introducing-netom-an-open-source-bgp-bmp-monitoring-engine-built-for-scale/) ## [Introducing Netom: an open-source BGP/BMP monitoring engine built for scale](https://fastnetmon.com/2026/09/24/introducing-netom-an-open-source-bgp-bmp-monitoring-engine-built-for-scale/) Sep 24, 2026 \| [FastNetMon Blog](https://fastnetmon.com/category/blog/), [Featured](https://fastnetmon.com/category/featured/), [Press & Newsroom](https://fastnetmon.com/category/news-and-media/) We’re excited to announce the first release of Netom, an open-source BGP and BMP monitoring engine developed and maintained by FastNetMon. Netom is built for network operators who need to collect,… [![DDoS News: FBI Disrupts NightmareStresser DDoS-for-Hire Service in Operation PowerOFF](https://fastnetmon.com/wp-content/uploads/2026/09/DDoS-News-FBI-Disrupts-NightmareStresser-DDoS-for-Hire-Service.png)](https://fastnetmon.com/2026/09/22/ddos-news-fbi-disrupts-nightmarestresser-ddos-for-hire-service-in-operation-poweroff/) ## [DDoS News: FBI Disrupts NightmareStresser DDoS-for-Hire Service in Operation PowerOFF](https://fastnetmon.com/2026/09/22/ddos-news-fbi-disrupts-nightmarestresser-ddos-for-hire-service-in-operation-poweroff/) Sep 22, 2026 \| [FastNetMon Blog](https://fastnetmon.com/category/blog/) The FBI has seized internet domains associated with NightmareStresser, a long-running DDoS-for-hire service accused of enabling hundreds of thousands of actual or attempted attacks worldwide. The… Page 1 of 261[2](https://fastnetmon.com/wp-cron.php/page/2/?doing_wp_cron=1792528011.6662390232086181640625&et_blog "Page 2")[3](https://fastnetmon.com/wp-cron.php/page/3/?doing_wp_cron=1792528011.6662390232086181640625&et_blog "Page 3")[4](https://fastnetmon.com/wp-cron.php/page/4/?doing_wp_cron=1792528011.6662390232086181640625&et_blog "Page 4")[5](https://fastnetmon.com/wp-cron.php/page/5/?doing_wp_cron=1792528011.6662390232086181640625&et_blog "Page 5")…[10](https://fastnetmon.com/wp-cron.php/page/10/?doing_wp_cron=1792528011.6662390232086181640625&et_blog "Page 10")[20](https://fastnetmon.com/wp-cron.php/page/20/?doing_wp_cron=1792528011.6662390232086181640625&et_blog "Page 20")…[»](https://fastnetmon.com/wp-cron.php/page/2/?doing_wp_cron=1792528011.6662390232086181640625&et_blog)[Last »](https://fastnetmon.com/wp-cron.php/page/26/?doing_wp_cron=1792528011.6662390232086181640625&et_blog) --- ### [Add-ons](https://fastnetmon.com/addons/) **Published:** August 26, 2016 **Author:** FastNetMon **Content:** FastNetMon offers a range of add-ons that extend and complement its core detection and mitigation capabilities. These add-ons enable deeper integrations, additional data sources and enhanced workflows to support different network environments and operational needs. The list below highlights some of the most commonly used add-ons, both developed internally and by 3rd parties. If you are interested in developing a custom add-on or integrating FastNetMon with your own systems, our team is happy to help and open to collaboration. For more information, please [contact us.](https://fastnetmon.com/contact/) ![](https://fastnetmon.com/wp-content/uploads/2026/04/FastNetMonLiveView.png "FastNetMonLiveView") **FastNetMon LiveView** is the official web interface add-on for FastNetMon, bringing traffic analytics, DDoS visibility, and platform management into one dashboard. [Add LiveView](https://fastnetmon.com/fastnetmon-subscription-upgrade-process/) to your subscription and learn how to configure it [here.](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-panel-ui-installation/) | ![Mitigator](https://fastnetmon.com/wp-content/uploads/2020/04/mitigation_logo_new.png) | Integration between Mitigator product and FastNetMon. Find how to set up it [here](https://docs.mitigator.ru/master/integrate/fastnetmon/). | |---|---| | ![Juniper](https://fastnetmon.com/wp-content/uploads/2019/07/Juniper-Networks-logo-300x150.jpg) | Juniper FastNetMon plug-in by Christian David. Connects to a Juniper router and adds or removes a blackhole rule for an attack by IP address. Find it [here](https://github.com/pavel-odintsov/fastnetmon/blob/master/src/juniper_plugin/README.md). | | ![Prometheus](https://fastnetmon.com/wp-content/uploads/2022/01/prometheus-550x120-1.png) | Exporter for metrics from FastNetMon API to use with [Prometheus](https://prometheus.io) monitoring by lwlcom. You can find it on [GitHub](https://github.com/lwlcom/fastnetmon_exporter). | | ![UKFast FTN UX](https://fastnetmon.com/wp-content/uploads/2019/03/UKFast-300x69.png) | Team UkFast developed Web Interface for FastNetMon. It builds on our API. You can find it [here](https://github.com/ukfast/fnm-webui/blob/master/README.md). | | ![Dolly Team](https://fastnetmon.com/wp-content/uploads/2022/01/startnix.png) | Team Dolly implemented their addon to announce blackhole announces to multiple ISPs with custom BGP Blackhole community for each provider. You could find more documents about it [here](https://github.com/DollyTeam/Dolly-Fastnetmon). | | ![A10 networks](https://fastnetmon.com/wp-content/uploads/2016/08/A10_networks-small-300x118.png) | FastNetMon has support for integration with A10 Thunder TPS Appliance. You could read more documents about it [here](https://github.com/pavel-odintsov/fastnetmon/tree/master/src/a10_plugin). It was contributed by Eric Chou and Rich Groves from A10 Networks. | | ![Mikrotik](https://fastnetmon.com/wp-content/uploads/2016/08/logo_mikrotik-300x73.png) | FastNetMon has support for Mikrotik Router OS API. You could read more about it [here](https://github.com/elmaxid/Fastnetmon-MikroTik-Plugin). Contributed by Maximiliano Dobladez from Mkesolutions.net | | ![Slack](https://fastnetmon.com/wp-content/uploads/2016/08/slack-logo-to_addons-300x118.png) | FastNetMon has support for Slack integration. You install it from here: [GitHub](https://github.com/pavel-odintsov/fastnetmon/blob/master/src/scripts/notify_with_slack.sh). It was developed by Ronan Daly. | | ![Python](https://fastnetmon.com/wp-content/uploads/2016/08/Python-logo-long-300x159.png) | Original bash-powered notification script implemented by Pavel Odintsov. You could download it here: [GitHub](https://github.com/pavel-odintsov/fastnetmon/blob/master/src/notify_about_attack.sh) | | ![Bash](https://fastnetmon.com/wp-content/uploads/2016/08/bash-logo-web-300x126.png) | Original bash powered notification script implemented by Pavel Odintsov. You could download it here: [GitHub](https://github.com/pavel-odintsov/fastnetmon/blob/master/src/notify_about_attack.sh) | --- ### [FastNetMon subscription upgrade process](https://fastnetmon.com/fastnetmon-subscription-upgrade-process/) **Published:** January 30, 2019 **Author:** Pavel Odintsov **Content:** ## How to upgrade my FastNetMon subscription plan? You can upgrade your FastNetMon plan at any time. The new plan will be activated when your current billing period for your current subscription expires. If you need an immediate upgrade, please contact our [support team](https://support.fastnetmon.com/hc/en-gb/requests/new). To upgrade, login into your [managing interface of your subscription](https://fastnetmon.chargebee.com/portal/v2/login?forward=home). First, please specify your email used for the current subscription: ![](https://fastnetmon.com/wp-content/uploads/2026/04/Chargebee_login_fastnetmon-791x1024.png)After logging in, select your current subscription and press "edit subscription": ![](https://fastnetmon.com/wp-content/uploads/2026/04/Chargebee_current_plan_fastnetmon.png)Select new subscription type (please use "annual" license type if your subscription is annual) in drop down list and then press "Update subscription": ![](https://fastnetmon.com/wp-content/uploads/2019/01/3-Select-plan-249x300.png)After that, you will see new entry "Scheduled changes". Your new subscription will be started when current one expires (for monthly subscriptions in <4 weeks). ![](https://fastnetmon.com/wp-content/uploads/2019/01/4-Scheduled-changes-250x300.png)Your scheduled subscription change: ![](https://fastnetmon.com/wp-content/uploads/2019/01/5-list-of-scheduled-changes-250x300.png)## Managing your addons Log in to the subscription [managing interface](https://fastnetmon.chargebee.com/portal/v2/login?forward=home): ![Modal login: Manage Your Subscriptions with email field showing alex.taylor@demo.com and a Continue button](https://fastnetmon.com/wp-content/uploads/2026/04/Chargebee_login_fastnetmon.png)Then select active subscription: ![](https://fastnetmon.com/wp-content/uploads/2026/04/Step-2.png)Then click on "Edit subscription": ![](https://fastnetmon.com/wp-content/uploads/2026/04/Step-3.png)Click "Add addons": ![](https://fastnetmon.com/wp-content/uploads/2026/04/Step-5.png)Then select the desired addon: ![](https://fastnetmon.com/wp-content/uploads/2026/04/Step-6.png)Confirm order: ![](https://fastnetmon.com/wp-content/uploads/2026/04/Step-7.png) --- ### [About FastNetMon](https://fastnetmon.com/about-the-company/) **Published:** October 27, 2025 **Author:** Outi Maria Pietilanaho **Excerpt:** FastNetMon, a London-based network security leader founded in 2016, specializes in high-speed DDoS detection and mitigation. We empower service providers and enterprises globally to safeguard critical infrastructure with precision and speed. **Content:** FastNetMon is a network security company focused on fast, accurate DDoS detection and mitigation. Founded in London in 2016, we work with service providers, data centres, and enterprises around the world to protect critical network infrastructure from DDoS attacks. ![](https://fastnetmon.com/wp-content/uploads/2026/01/ripe91-1-copy-1024x1015.jpeg)FastNetMon leadership team, Pavel Odintsov, Outi Maria Pietilanaho and Virgil Truica at RIPE91 in 2025Our [core product](https://fastnetmon.com/product-overview/) is a high-performance DDoS detection and mitigation platform designed to run on networks of any size — from small ISPs to large, multi-vendor environments. The team brings deep hands-on experience operating and defending real-world networks, with a strong focus on automation, accuracy, and operational simplicity. FastNetMon’s roots are in open source. The project began in 2013 when Pavel Oditsov released the first version of FastNetMon Community on[ GitHub ](https://github.com/pavel-odintsov/fastnetmon)— a fully open-source DDoS detection tool that is still actively maintained today. That foundation continues to shape how we build: transparent, engineer-driven, and focused on real operational needs. Today, FastNetMon protects networks in over 140 countries and is trusted by telecom operators, hosting providers, internet exchanges, and enterprises worldwide. Alongside our [global partner network](https://fastnetmon.com/partners/), we support customers with flexible deployment models and deep protocol-level integrations. Our mission is simple:**to make reliable, high-performance DDoS protection accessible to networks of any scale.** You can get in touch with the team [here](https://fastnetmon.com/contact/), we'd be happy to hear from you! --- ### [FastNetMon Advanced installer configuration options reference](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-installer-configuration-options-reference/) **Published:** March 25, 2026 **Author:** Pavel Odintsov **Content:** This document lists all supported command-line options for the FastNetMon installer binary ## Installation and upgrade options - upgrade\_fastnetmon\_advanced - upgrade FastNetMon Advanced and exit - developer\_version - use developer build (latest build from developer branch) for FastNetMon Advanced installation - do\_not\_install\_fastnetmon - skip FastNetMon core installation during main install flow, used for preparing testing / developer environment - do\_not\_add\_repositories - do not add Internet repositories for dependencies, used for installed in air-gap environment with no Internet access or when custom repository proxy is being used ## Configuration database management options - create\_mongodb\_admin\_user - create MongoDB admin user and exit - create\_mongodb\_user\_for\_fastnetmon - create FastNetMon MongoDB user using existing admin password and exit - ferretdb - install FerretDB instead of MongoDB in the main flow - ferretdb\_only - install only FerretDB and exit ## Visualisation and dashboard options - install\_graphic\_stack - install graphic stack for traffic/attack visualization and exit - install\_grafana\_dashboards - provision Grafana dashboards and exit - reset\_visual\_passwords - Reset Grafana password and exit, you can specify your own password using flag: -password, visual\_login - login name for Grafana password reset - download\_only - download rpm packages for visual stack only (no installation). Intended for Red Hat family systems only ## Clickhouse metrics and traffic persistence logic - install\_traffic\_persistency - install traffic persistence stack (ClickHouse) and exit - reset\_clickhouse\_password - reset ClickHouse password used by Grafana and exit - configure\_clickhouse\_logging - disable excessive ClickHouse logging and exit ## Docker options - fastnetmon\_docker - install Docker Engine and deploy FastNetMon stack in containers - docker - install only Docker Engine and exit ## License and activation options - activation\_coupon - provides coupon code for license activation when default installation option is used (no arguments) - activate\_coupon - activate coupon only and exit (uses -activation\_coupon) - check\_license\_server\_connection - check connectivity to licensing server and exit - do\_not\_check\_license -disable installer-side license validation checks ## Networking and platform behavior - ipv6\_only\_setup - configure services to use IPv6 for communications - force\_old\_cpu - force use of packages for older CPUs (SSE4.2/AVX constrained environments) ## Privacy and telemetry options - do\_not\_use\_google\_analytics - disable Google Analytics usage for Community edition installs. - do\_not\_use\_sentry - disable Sentry error tracking. ## Configuration migration and utility options - import\_community\_edition\_configuration - import Community edition configuration from /etc/fastnetmon.conf and exit - version - print installer build/version information and exit. --- ### [FastNetMon API user control](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-api-user-control/) **Published:** November 14, 2024 **Author:** Pavel Odintsov **Content:** FastNetMon offers a granular access control system which allows you to have multiple API users with different access levels. This capability is available from 2.0.368. To create a new user, you can use the following command: ``` sudo fcli set user support ``` Then you need to set a password for it, please use single quotes to avoid bash interpretation of special symbols in password: ``` sudo fcli set user support password '' ``` Then set the role for the user: ``` sudo fcli set user support role administrator ``` Show newly created user settings: ``` sudo fcli show user support ``` To remove user, use this command: ``` sudo fcli delete user support ``` And to list all users, please use this command: ``` sudo fcli show user ``` --- ### [FastNetMon Advanced and Bison router integration](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-and-bison-router-integration/) **Published:** March 29, 2026 **Author:** Pavel Odintsov **Content:** FastNetMon Advanced has complete support for BGP Flow Spec based mitigation mode when FastNetMon detects malicious patterns and generates filtering rules to filter them out. Bison router does not support native BGP Flow Spec protocol yet but we have an option to add / remove ACLs via SSH automatically To start you need to fully configure FastNetMon in [BGP Flow Spec mode](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-bgp-flow-spec-configuration/) As Bison ACLs in Bison router do not support particular filtering options available in FastNetMon we need to explicitly disable them: ``` sudo fcli set main flow_spec_do_not_process_ip_fragmentation_flags_field true sudo fcli set main flow_spec_do_not_process_length_field true sudo fcli set main flow_spec_do_not_process_tcp_flags_field true sudo fcli commit ``` As we're going to use ssh to connect from FastNetMon server / VM to server with Bison you need to create ssh user for it on server with Bison router. Then grant following sudo permissions as rcli tools requires root access by placing following lines to /etc/sudoers.d/bison: ``` fastnetmon ALL=(root) NOPASSWD: /usr/sbin/rcli vif acl rule * fastnetmon ALL=(root) NOPASSWD: /usr/sbin/rcli vif acl flush aclid * fastnetmon ALL=(root) NOPASSWD: /usr/sbin/rcli sh vif acl rules aclid * fastnetmon ALL=(root) NOPASSWD: /usr/sbin/rcli sh vif acl ``` After that please configuration /etc/fastnetmon\_bison\_flow\_spec\_acl.json with following content (adjust options to your particular case): ``` { "log_path": "/var/log/fastnetmon/fastnetmon_bison_flow_spec_acl.log", "ssh_host": "10.0.0.1", "ssh_port": 22, "ssh_user": "fastnetmon", "ssh_password": "", "ssh_key_path": "/etc/bison_flow_spec_acl_ssh_private.key", "acl_id_ipv4": 21, "acl_id_ipv6": 22, "sudo": true } ``` After that please download [this](https://drive.google.com/file/d/1XjwBaxDhQBnKfTt41Zo3CsYNKvvNHnuY/view?usp=sharing) file, please it to /opt/fastnetmon\_bison\_flow\_spec\_acl and then set executable bit for it: ``` sudo chmod +x /opt/fastnetmon_bison_flow_spec_acl ``` Then enable JSON based callback scripts on FastNetMon side: ``` sudo fcli set main notify_script_enabled enable sudo fcli set main notify_script_format json sudo fcli set main notify_script_path /opt/fastnetmon_bison_flow_spec_acl sudo fcli commit ``` Please note that Bison ACLs work before NAT port translation happens and they will work in private IPs. Then you need to enable ACL for IPv4 on Bison side this way: ``` # # Apply ACL to PPPoE # # create ACL template VIF "pppoe_acl_tpl" acl template vif add pppoe_acl_tpl # add ACL 21 to VIF "pppoe_acl_tpl" vif acl add dev pppoe_acl_tpl dir ingress aclid 21 prio 10 # use VIF "pppoe_acl_tpl" for every PPPPoE subscriber sysctl set pppoe_template_acl "pppoe_acl_tpl" ``` To enable both IPv4 and IPv6 ACLs you will need to apply following configuration options: ``` # # ACL # vif acl create aclid 21 type ipv4_tuple deny vif acl create aclid 22 type ipv6_tuple deny # # Apply ACL to PPPoE # # create ACL template VIF "pppoe_acl_tpl" acl template vif add pppoe_acl_tpl # add ACL 21 to VIF "pppoe_acl_tpl" vif acl add dev pppoe_acl_tpl dir ingress aclid 21 prio 10 vif acl add dev pppoe_acl_tpl dir ingress aclid 22 prio 20 # use VIF "pppoe_acl_tpl" for every PPPPoE subscriber sysctl set pppoe_template_acl "pppoe_acl_tpl" ``` Please note that ACL rules will start applying **only** after PPPoE session is re-established again. You may wait for all customers to reconnect or restart Bison entirely (be aware about downtime during this procedure). Please note that IPv4 and IPv6 ACLs use different ACL IDs If you use Netflow please note that you must not send NAT events (net collector) to FastNetMon as NAT event packets may cause issues with detection logic in versions older then 2.0.376. To check that tool can connect to remote server please use following command: ``` echo '{"alert_scope":"host","action":"connection_check"}' | sudo /opt/fastnetmon_bison_flow_spec_acl ``` After all configuration is put in place FastNetMon will automatically create and remove filtering rules on Bison router via ssh To ensure that everything works I can recommend creating rule which filters UDP traffic towards 192.0.2.1/32 which belong to IETF [documentation](https://datatracker.ietf.org/doc/html/rfc5737) range and not used publicly: ``` sudo fcli set flowspec '{"protocols":["udp"], "destination_prefix": "192.0.2.1/32","action_type": "discard"}' ``` And then check that everything went well in /var/log/fastnetmon/fastnetmon\_bison\_flow\_spec\_acl.log Then check that ACLs present on Bison side: ``` sudo /usr/sbin/rcli sh vif acl rules aclid 21 acl id 21, type ipv4_tuple, action deny, num rules 5 -- prio 5, proto 17, src 172.16.12.83, dst 192.0.2.1, sport any, dport any prio 4, proto 17, src 172.16.7.193, dst xx, sport 45772, dport 36891 prio 3, proto 17, src 172.16.12.83, dst xx, sport 56186, dport 53726 prio 2, proto 17, src 172.16.9.52, dst xx, sport 53418, dport 12612 prio 1, proto 17, src 172.16.13.102, dst xx, sport 48130, dport 60187 ``` In case of need you can remove all ACLs using this command: ``` sudo /usr/sbin/rcli vif acl flush aclid 21 ``` For testing (will cause outage when applied on live traffic) purposes you can run random commands to create rules: ``` echo '{"alert_scope":"host","action":"partial_block", "flow_spec_rules":[{"action_type": "discard", "protocols":["udp"]}]}' | sudo bin/fastnetmon_bison_flow_spec_acl echo '{"alert_scope":"host","action":"partial_block", "flow_spec_rules":[{"action_type": "discard", "protocols":["tcp"]}]}' | sudo bin/fastnetmon_bison_flow_spec_acl echo '{"alert_scope":"host","action":"partial_block", "flow_spec_rules":[{"action_type": "discard", "protocols":["udp"], "destination_ports": [123] }]}' | sudo bin/fastnetmon_bison_flow_spec_acl echo '{"alert_scope":"host","action":"partial_block", "flow_spec_rules":[{"action_type": "discard", "protocols":["udp"], "source_ports": [123] }]}' | sudo bin/fastnetmon_bison_flow_spec_acl echo '{"alert_scope":"host","action":"partial_block", "flow_spec_rules":[{"action_type": "discard", "protocols":["udp"], "destination_ports": [123], "source_prefix": "10.0.0.1/32" }]}' | sudo bin/fastnetmon_bison_flow_spec_acl echo '{"alert_scope":"host","action":"partial_block", "flow_spec_rules":[{"action_type": "discard", "protocols":["udp"], "destination_ports": [123], "source_prefix": "10.0.0.1/24" }]}' | sudo bin/fastnetmon_bison_flow_spec_acl echo '{"alert_scope":"host","action":"partial_block", "flow_spec_rules":[{"action_type": "discard", "source_prefix": "10.0.0.1/24" }]}' | sudo bin/fastnetmon_bison_flow_spec_acl echo '{"alert_scope":"host","action":"partial_block", "flow_spec_rules":[{"action_type": "discard", "destination_prefix": "10.0.0.1/24" }]}' | sudo bin/fastnetmon_bison_flow_spec_acl echo '{"alert_scope":"host","action":"partial_block", "flow_spec_rules":[{"action_type": "discard", "protocols":["udp"], "destination_ports": [123], "source_ports":[1234],"destination_perfix": "10.0.3.0/24","source_prefix": "10.0.0.1/24" }]}' | sudo bin/fastnetmon_bison_flow_spec_acl ``` --- ### [FastNetMon Advanced callback scripts](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-callback-scripts/) **Published:** March 24, 2026 **Author:** Pavel Odintsov **Content:** FastNetMon Advanced has capability to run scripts implemented in different programming languages when it detects attack against IP or hostgroup or identifies malicious pattern (BGP Flow Spec mode). In addition it can report information ongoing attacks using attack status capability By default FastNetMon passes information about attack in JSON format to script's standard input (stdin). You can find detailed JSON formats [here](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-json-formats/). Please note that your script MUST read all standard output passed by FastNetMon. Otherwise it may cause stability issues for FastNetMon daemon ### Per host attack notifications To pass information when particular IP is under attack (per host hostgroups) you can enable it this way: ``` sudo fcli set main notify_script_enabled enable sudo fcli set main notify_script_format json sudo fcli set main notify_script_path /usr/local/bin/notify_json.py sudo fcli commit ``` For backward compatibility reasons FastNetMon for per host bans FastNetMon passes following command line arguments to script: - Action name: ban or unban - IP address of host under attack This capability is considered obsoleted on March 2026 and may be removed in future. We strongly recommend against using command line arguments as this data is available in JSON document. For compatibility with legacy systems FastNetMon supports text based callback format (it can be enabled by setting notify\_script\_format to text) for per host alerts but on march of 2026 this capability is considered deprecated and strongly not recommended for usage. In this mode ### Hostgroup blocks notifications To enable this logic for per hostgroup attacks you need to use following syntax: ``` sudo fcli set main notify_script_hostgroup_enabled enable sudo fcli set main notify_script_hostgroup_path /usr/local/bin/notify_json.py sudo fcli commit ``` This capability works in JSON mode by default and notify\_script\_format is ignored. We provide multiple examples of callback scripts implemented in different programming languages: - [Python](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-json-notify-script-in-python/) - [Perl](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-notify-script-in-perl/) - [Golang](https://github.com/FastNetMon/fastnetmon-go) - [Bash](https://fastnetmon.com/docs-fnm-advanced/notify-script-in-bash/) (legacy, deprecated) ### Attack status information Starting from version 2.0.359, FastNetMon has the capability to call notify script for all blocked IPs (IPv4+IPv6) and pass attack details to it. This capability works only in JSON mode only (notify\_script\_format must be set to JSON). Please note that attack performance is **not updated** in this case; we plan to add this capability in future releases. This capability can be enabled this way; ``` sudo fcli set main notify_script_attack_status_updates true sudo fcli commit ``` You can configure how often FastNetMon runs this logic in seconds in the following way: ``` sudo fcli set main ban_status_delay 20 sudo fcli commit ``` --- ### [Customer Stories](https://fastnetmon.com/publications/) **Published:** August 23, 2016 **Author:** FastNetMon **Content:** #### **carbon+grafana on raspberry pi2 in 2019** 実例の非常に多いであろうraspberry pi2\*1でデータを貯めてgrafanaでみてみよう、みたいなことを、今時点(2019)で、こんな手順で、みたいなメモです。データストアとしてgraphite-carbon(whisper)を使い、これもpi2の中に押し込んで、データ量青天井とか同時大量アクセスとかは望めないなれど、一人分の一人使い用途としてはいい感じと思ってます。 [Read story](https://blog.balus.xyz/entry/2019/03/12/203846) #### **Netwerk: Monitoring 2.0** De bewaking van de continuiteit van een netwerk volstaat tegenwoordig niet meer met het controleren of routers bereikbaar zijn, of het netwerk verkeer kan transporteren, of hoeveel verkeer dit betreft. Traffic moet ook geanalyseerd kunnen worden: wat is de bron en het doel, om welk protocol gaat het, welke poorten worden gebruikt en op welk moment? [Read story](https://blog.duocast.net/netwerk-monitoring-2-0/) #### **M3AAWG Border Gateway Protocol (BGP) Flowspec Best Practices (pdf)** This paper is for individuals wanting to learn more about Flowspec and are interested in taking advantage of the numerous opportunities for use that it offers. It is written for network engineers responsible for Network Service Provider (NSP), hosting provider, or enterprise networks. [Read story](https://www.m3aawg.org/sites/default/files/m3aawg-flowspec-bp-2019-02.pdf) #### **RouterOS+Fastnetmon 全自动BGP路由黑洞 避免被D到路由器冒烟 XD** 继BGP速成班后…已经有好几个月想不出新教程…因为本菜鸡的水平实在提升的太慢 …总算经过一番大脑升级之后, 达成了大神们3年前就已经实现的全自动黑洞路由系统…那么3年前的东西, 现在难道没淘汰 ? 完全木有 , Working like a charm !… [Read story](https://www.91yunbbs.com/discussion/644/routeros-fastnetmon-全自动bgp路由黑洞-避免被d到路由器冒烟-xd) #### **Network Telemetry для задач обнаружения DDoS** FastNetMon представляет собой DDoS детектор базирующийся на пороговых значениях трафика. Пороговые значения в данном случае — это уровень трафика в пакетах секунду или байтах секунду для заданного типа трафика... [Read story](https://linkmeup.ru/blog/927/) #### **Proteja-se de ataques DoS/DDoS mitigando com FastNetMon e anuncie os prefixos atacados (blackholes) para sua operadora, usando Mikrotik** ... [Read story](https://blog.remontti.com.br/3981) #### **Fastnetmon on Ubuntu 18.04** I’ve spent some time trying to manually install Fastnetmon community edition on Ubuntu 18.04 Bionic Beaver. I was unsuccessful. However, I didn’t do an apt-cache search fastnetmon. There is a package in universe. Bionic Beaver also includes exabgp 4.0.2 by default. [Read story](https://bgp.guru/2019/02/09/fastnetmon-on-ubuntu-18.04/) #### ******Ultra fast automated DDoS detection & mitigation****** A few weeks back an Indian ISP contacted me via a contact form on my blog. That ISP has been struggling with a targetted DDoS attack. For the reason of privacy as well as the stability of their network, I will not put their name or AS number. [Read story](https://anuragbhatia.com/2017/10/networking/isp-column/ultra-fast-automated-ddos-detection-mitigation/) #### ****NetFLOW / sFLOW 流量报告：FastNetMon + InfluxDB + Grafana**** 最近稍微有点时间折腾了下 Cisco 的三层交换，尝试搭建了一套数据中心用的流量统计/监控/报告系统。过程不是很复杂，但是也只算利用了一套高级软件组合的一点点功能。之后打算继续研究更多的功能实现，不过也要看有没有时间了. [Read story](https://blog.phoenixlzx.com/2017/06/06/netflow-sflow-graph-fastnetmon-influxdb-grafana/) #### **Netwerk: Monitoring 2.0** De bewaking van de continuiteit van een netwerk volstaat tegenwoordig niet meer met het controleren of routers bereikbaar zijn, of het netwerk verkeer kan transporteren, of hoeveel verkeer dit betreft. Traffic moet ook geanalyseerd kunnen worden: wat is de bron en het doel, om welk protocol gaat het, welke poorten worden gebruikt en op welk moment? [Read story](https://blog.duocast.net/netwerk-monitoring-2-0/) #### ****FASTNETMON与MIKROTIK集成（DDOS检测系統)**** 背景 從事IDC行業經常會遇到DDoS攻擊，一般用以下解決辦法處理，即： – NULL路由 – 一堆金盾用帶寬硬撐 – 切路由到國外清洗（Voxility&incapsula） – 等死 [Read story](https://zhu.vn/archives/1966) #### **GARR customer triggered blackholing** From discussions with the GARR working group on “contrast to DDoS”, we understood the importance of a collaboration between GARR and its users to mitigate attacks. With the other components of the group, some open source tools for detecting DDoS and related reporting have been studied and tested. [Read story](https://fastnetmon.com/wp-content/uploads/2017/08/EN_GARRCustomerTriggeredBlackholing.pdf) #### **FastNetMon Integration with MikroTik** This guide will show you how to install and configure FastNetMon to be used with MikroTik and also as a bonus how to integrate it with Slack and Grafana, the first one is used to get reports about DDoS and the second one to have a really great reporting tool that will allow you to check PPS and Throughput as a whole and per IP address… [Read story](https://forum.mikrotik.com/viewtopic.php?t=124958) #### **Metrics and events collection in Ingenico Payment Services** I work at Ingenico Payment Services as an Infrastructure Manager, in a Business Unit called Axis, a card present payment processing platform. The growth of the processing on the platform year over year is double digit and in infrastructure, one has often to answer tricky questions like: Why did yesterday batch finish late ? Do we have enough capacity for hosting this new application ? [Read story](https://www.linkedin.com/pulse/metrics-events-collection-ingenico-payment-services-jean-lubatti) #### **养鸡厂厂长日记—规模化Botnet养殖和应用** 前一段时间memcache drdos攻击可谓是借着各种渠道火了一次，包括笔者所在的公司也被社会人反手抡了几次，可以预见这种类型的DDoS一旦发生起来非常的可怕。我们对这种情况往往都是看到流量异常之后选择封堵相关的协议和端口，或者有钱的方法直接上电信云堤（据说收费非常坑爹，5000块钱一次，现在不知道涨价没有），这样的话始终处于一个被动挨打的局面，那么有没有什么方法可以稍微减轻一下被动的局面呢？答案在下面. [Read story](https://zhuanlan.zhihu.com/p/34792130) #### **A evolução dos ataques de negação de serviço (DoS). Seu provedor está preparado?** Os ataques de negação de serviço, do inglês Denial of Service (DoS), são uma preocupação constante dos administradores de redes e devem ser objeto de muita atenção dos provedores de acesso à internet. Os ataques ocorrem, geralmente, quando uma rede ou aplicação são sobrecarregadas por um volume de tráfego ou processamento anormal, provocados intencionalmente para prejudicar a disponibilidade de um serviço. [Read story](https://www.pontoisp.com.br/evolucao-dos-ataques-de-negacao-de-servico-dos-seu-provedor-esta-preparado/) #### **Mitigating DDoS** Your first line of defense to any DDoS, at least on the network side, should be to disperse the traffic across as many resources as you can. Basic math implies that if you have fifteen entry points, and each entry point is capable of supporting 10g of traffic, then you should be able to simply absorb a 100g DDoS attack while still leaving 50g of overhead for real traffic (assuming perfect efficiency, of course — YMMV). Dispersing a DDoS in this way may impact performance — but taking bandwidth and resources down is almost always the wrong way to react to a DDoS attack. [Read story](https://circleid.com/posts/20170206_mitigating_ddos/) #### **How to Prevent DDoS Attacks on a Cloud Server Using Open Source Software** A Distributed Denial of Service Attack (DDoS) is, unfortunately, an increasingly common form of premeditated attack against an organization’s web infrastructure. Typically, it involves using multiple external systems to flood the target system with requests with the intention of overwhelming the system with network traffic. [Read story](https://www.globalsign.com/en/blog/how-to-prevent-a-ddos-attack-on-a-cloud-server) #### **BGP BLACKHOLE Community** DDoS attacks continue to be a wide-spread problem on the internet. Their size has grown over the past few years to where BGP Blackholing to reduce collateral damage has become widespread. As more and more networks built support for BGP Blackholing – each with their own BGP community – it became clear that there was a need for a standardized “well known” community for BGP Blackholing. From this need was born RFC 7999: BLACKHOLE Community. This reserves 65535:666 as the well known, BLACKHOLE. [Read story](https://bgp.guru/2017/01/01/bgp-blackhole-community/) #### **FastNetMon: Detectando y protegiéndonos de ataques DDoS** Uno de los gajes del oficio del networking y en especial de los ISP son los ataques de Denegación de Servicio Distribuida DDoS. Hay varias maneras de protegerse, las mejores o con mas opciones son pagas y con elevados costos de licenciamiento. Un proyecto OpenSource (GNU GPLv2) que lo inicio un amigo de Rusia (Pavel Odintsov) llamado FastNetMon es una buena opción como alternativa gratuita. [Read story](https://www.maxid.com.ar/fastnetmon-detectando-y-protegiendonos-de-ataques-ddos) #### **FastNetMon – open source DDoS detection new release 1.1.2** Hello, folks! This article will continue <https://www.lowendtalk.com/discussion/43473/open-source-ddos-dos-monitoring-toolkit-fastnetmon> . We have spent about 10 months for development of FastNetMon and could present huge feature list now! 🙂Stop! What is FastNetMon? It’s really very fast toolkit which could find attacked host in your network and block it (or redirect to filtering appliance). [Read story](https://lowendtalk.com/discussion/55176/fastnetmon-open-source-ddos-detection-new-release-1-1-2) #### **Open source DDoS/DoS monitoring toolkit – FastNetMon** Hello, folks! I would like to share my DDoS monitoring toolkit with community. You can find it on GitHub: <https://github.com/FastVPSEestiOu/fastnetmon> It supports Linux (Centos 5/6, Debian 6/7), FreeBSD 9/10/11 and Mac OS X since Yosemite. It provide ability to detect bandwidth, flow and pps (packet per second) spikes which last more than X seconds and trigger action agains IP which generated this issue (our own IP, not an attacker IP). [Read story](https://lowendtalk.com/discussion/43473/open-source-ddos-dos-monitoring-toolkit-fastnetmon) #### **FastNetMon – DDoS analyzer** FastNetMon – A high performance DoS/DDoS and netflowk load analyzer built on top of multiple packet capture engines (netmap, PF\_RING, sFLOW, Netflow, PCAP). What can we do? We can detect hosts in our own network with a large amount of packets per second/bytes per second or flow per second incoming or outgoing from certain hosts. And we can call an external script which can notify you, switch off a server or blackhole the client. Why did we write this? Because we can’t find any software for solving this problem in the open source world! [Read story](https://rstforums.com/forum/topic/92181-fastnetmon-ddos-analyzer/) #### **Релиз FastNetMon 1.1.2 открытого решения для мониторинга DoS/DDoS атак** За прошедшие почти 10 месяцев с релиза 1.0.0 была очень большая работа по улучшению программы. Из основных изменений стоит отметить следующие: - Возможность выявлять самые популярные виды атак: syn\_flood, icmp\_flood, udp\_flood, ip\_fragmentation\_flood [Read story](https://habr.com/en/post/259399/) #### **FastNetMon – Very Fast DDoS Analyzer with Sflow/Netflow/Mirror Support** A high performance DoS/DDoS load analyzer built on top of multiple packet capture engines (NetFlow, IPFIX, sFLOW, netmap, PF\_RING, PCAP). What can we do? We can detect hosts in our own network with a large amount of packets per second/bytes per second or flow per second incoming or outgoing from certain hosts. And we can call an external script which can notify you, switch off a server or blackhole the client. [Read story](https://www.kitploit.com/2015/05/fastnetmon-very-fast-ddos-analyzer-with.html) #### **A10 Networks Launches World’s Most Powerful DDoS Protection Solution to Stop Multi-Vector DDoS Disruption** A10 Networks, a leader in application networking and security, today introduced A10 Thunder 14045 TPS, the fastest appliance on the market, that provides highest DDoS attack mitigation for Service Providers, Web 2.0 and Cloud Providers – 300 Gbps of mitigation throughput capacity (or 2.4 terabits per second in a cluster). [Read story](https://ict.root-technologies.net/Show_News-9237.html) #### **FastNetMon 1.0.0 — программа для выявления входящих/исходящих атак** Хотел бы поделиться своей программой для анализа проходящего миррор-порты/роутеры/OpenVZ ноды трафика на предмет входящих/исходящих DDoS атак. - Для чего она писалась? Чтобы фиксировать серьезные всплески в сотни kpps по полосе/pps как со стороны клиентов, так и со стороны интернета в сторону клиентов. [Read story](https://www.linux.org.ru/news/security/10603941) #### **FastNetMon 1.0.0 – программа для выявления входящих/исходящих DDoS-атак** Доступен релиз программы [FastNetMon 1.0.0](https://github.com/FastVPSEestiOu/fastnetmon), предназначенной для выявления входящих и исходящих DDoS-атак на основе анализа транзитного трафика. Программа разработана для фиксации серьезных всплесков интенсивности отправки пакетов (сотни тысяч пакетов в секунду), как со стороны клиентов, так и со стороны внешней сети в сторону клиентов. Данные о трафике могут собираться через PF\_RING (рекомендуется), PCAP (не рекомендуется) и ULOG2 (не рекомендуется). [Read story](https://www.opennet.ru/opennews/art.shtml?num=40058) #### **Релиз FastNetMon 1.1.2, открытого решения по обнаружению DDoS-атак** [Состоялся](https://github.com/FastVPSEestiOu/fastnetmon/releases/tag/v1.1.2) релиз программы [FastNetMon 1.1.2](https://github.com/FastVPSEestiOu/fastnetmon), предназначенной для выявления входящих и исходящих DDoS-атак на основе анализа транзитного трафика. Программа разработана для фиксации серьезных всплесков интенсивности отправки пакетов (сотни тысяч пакетов в секунду), как со стороны клиентов, так и со стороны внешней сети в сторону клиентов. Данные о трафике могут собираться через PF\_RING, PCAP, ULOG2, Netmap, NetFlow, sFLOW. На выходе выводится список 10 самых активных потребителей ресурсов сети, как по числу пакетов в секунду, так и по трафику. [Read story](https://www.opennet.ru/opennews/art.shtml?num=42346) #### **FastNetMon – решение для высокоскоростного анализа трафика и блокировки узлов, на которые идет DDoS атака** Данная задача крайне часто встает в моей практике и, к сожалению, не имеет ни красивых ни удобных, ни вообще каких-либо решений. Что мы делаем? Мы работаем через PF\_RING и на очень высокой скорости извлекаем транзитные либо входящие пакеты идущие на нашу машину либо крупную сеть. Приложение написано на С++ и может работать до очень и очень серьезных нагрузок, 10-15 Gbps или 2-5 Mpps – это нормально. [Read story](https://www.stableit.ru/2014/06/fastnetmon-ddos.html) #### **昨天看到這個工具還不錯 fastnetmon** 可以使用netflow sflow port mirror的資料來計算pps mbps 及flow數 當到達指定的上限時 可以發出告警或執行特定動作 安裝很簡單 裝好centos 7後 wget https://raw.githubusercontent.com/pavel-odintsov/fastnetmon/master/src/fastnetmon\_install.pl -Ofastnetmon\_install.pl perl fastnetmon\_install.pl [Read story](https://adminkk.blogspot.com/2016/01/fastnetmon-httpsgithub.html) #### **Un Sanjuanino en Rio Cuarto** Ha pasado mucho tiempo desde la última vez que postee y el motivo del descuido tanto de mi blog como de las redes sociales se debe a los nuevos proyectos que he iniciado y me consume mucho tiempo. En estos momento me encuentro con varios proyectos en desarrollo, uno de ellos es FastNetMon, un sistema de detección y protección contra ataques DDoS utilizando Netflow. [Read story](https://www.maxid.com.ar/retomando-el-blog) #### **FastNetMon** High performance DoS/DDoS load analyzer. Kan lyssna på bl.a. Netflow, IPFIX, sFLOW, PCAP, SPAN och PF\_RING. Om en överbelastningsattack upptäcks exekveras ett script. Vad scriptet gör avgör man själv, t.ex. maila/SMSa admin eller null routa prefix med ExaBGP. Installation: *Debian, Ubuntu, CentOS, Fedora*... [Read story](https://hackernet.se/w/FastNetMon) #### **FastNetMon: Analisador DDoS de Alta Performance com Suporte a Sflow/Netflow/Mirror** FastNetMon é um utilitário que funciona como um analisador de alta performance, voltado para DoS/DDoS. Ele foi projetado a partir de vários mecanismos de captura de pacotes (NetFlow, IPFIX, sFlow, netmap, PF\_RING, PCAP). Com ele, é possível detectar guests em sua própria rede, com uma grande quantidade de pacotes por segundo/bytes por segundo ou fluxo por segundo de entrada ou saída de certos hosts. E além disso, também é possível estabelecer comunicação com um script externo que pode notificá-lo e desligar um servidor. [Read story](https://under-linux.org/content.php?r=9500) #### HOSTED BY JAMES DEAN #### Pavel Odinstov, E50 podcast episode On our 50th episode of The Route to Networking podcast, James Dean had the pleasure of being joined by Pavel Odinstov Co-Founder and CTO at FastNetMon LTD. Pavel is a Software Engineer with a passion for computer networks, with his work being orientated around delivering effective DDoS protection. During this episode, they delve into everything DDoS-related, involving the biggest changes that Pavel has seen in this space during his career, as well as some of the main concerns he has for the industry as well. [Read story](https://hamilton-barnes.com/podcasts/e50-pavel-odinstov/) --- ### [FastNetMon Advanced and Mikrotik route management integration](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-and-mikrotik-route-management-integration/) **Published:** January 24, 2024 **Author:** Pavel Odintsov **Content:** Starting from RouterOS v7.1beta4, Mikrotik has support for [REST API](https://help.mikrotik.com/docs/display/ROS/REST+API), which can be used by FastNetMon to create or remove routes (typically blackholes) without using BGP. Before beginning this guide, please read the official Mikrotik guide and enable the www or www-ssl service on Mikrotik. To enable this capability, please [upgrade](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-upgrade-procedure/) FastNetMon to version 2.0.359 or more recent. Then enable this logic in the following way: ``` sudo fcli set main mikrotik_announce_host true sudo fcli set main mikrotik_announce_host_blackhole true sudo fcli set main mikrotik_rest_api_urls https://admin:admin@192.168.1.131 sudo fcli commit ``` In addition to plain HTTP mode, we support encrypted HTTPS mode to access Mikrotik REST API, too. After that, FastNetMon will create / remove routes on Mikrotik side whenever FastNetMon blocks/unblocks hosts: ![](https://fastnetmon.com/wp-content/uploads/2024/01/image.png)To test that integration works correctly we recommend manually blocking and then unblocking some test host: ``` sudo fcli set blackhole 1.2.3.4 ``` Then check the list of blocked hosts and get UUID of it: ``` sudo fcli show blackhole ``` To unblock the host, you need to use the UUID from the previous command and issue the following command: ``` sudo fcli delete blackhole d9b1885f-6d9b-4167-9e3e-0a3198bacee9 ``` --- ### [FastNetMon Advanced and VyOS route management integration](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-and-vyos-route-management-integration/) **Published:** January 26, 2024 **Author:** Pavel Odintsov **Content:** You can integrate FastNetMon Advanced with VyOS using their official [API](https://docs.vyos.io/en/latest/configuration/service/https.html) (available starting version 1.2.x). This integration allows FastNetMon to create or remove routes (blackholes) without using BGP. To enable this capability, please [upgrade](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-upgrade-procedure/) FastNetMon to version 2.0.359 or more recent. To start, you need to create an API Key on VyOS: ``` set service https api keys id key-01 key 'VyOS-super-secret-key' ``` After this, you need to configure the following options on FastNetMon: ``` sudo fcli set main vyos_announce_host true sudo fcli set main vyos_announce_host_blackhole true sudo fcli set main vyos_api_urls https://:VyOS-super-secret-key@192.168.1.132 sudo fcli commit ``` Please note that we support only blackhole mode, and vyos\_announce\_host\_blackhole must be set at all times. In future, we will add the capability to add regular routes. You can specify multiple VyOS servers in the configuration. To test that integration works correctly, we recommend manually blocking and then unblocking some test host: ``` sudo fcli set blackhole 1.2.3.4 ``` Then check the list of blocked hosts and get UUID of it: ``` sudo fcli show blackhole ``` To unblock host, you need to use UUID from the previous command and issue the following command: ``` sudo fcli delete blackhole d9b1885f-6d9b-4167-9e3e-0a3198bacee9 ``` --- ### [Network Traffic Visibility with FastNetMon](https://fastnetmon.com/traffic-visibility/) **Published:** March 16, 2021 **Author:** FastNetMon **Content:** Modern networks are business-critical. As infrastructure grows in scale and complexity, having accurate, real-time visibility into network traffic is essential for maintaining performance, availability, and security. FastNetMon provides high-performance network traffic visibility using flow-based monitoring. By analysing traffic metadata from routers, switches, and virtual infrastructure, FastNetMon helps network and security teams understand traffic behaviour, detect anomalies early, and respond quickly to incidents such as DDoS attacks. Rather than relying on packet payload inspection, FastNetMon focuses on scalable, efficient traffic analysis that works reliably at very high speeds and across diverse network environments. ## **Flow-Based Network Traffic Visibility** Network traffic visibility is the ability to observe and analyse how traffic moves through your network — who is communicating, over which protocols, at what rate, and for how long. FastNetMon builds this visibility using industry-standard telemetry sources such as NetFlow, IPFIX, sFlow, and port mirroring. These technologies provide detailed traffic metadata without introducing latency or requiring specialised hardware. This approach allows FastNetMon to deliver consistent visibility across physical networks, virtualised environments, and cloud infrastructure while remaining lightweight and highly scalable. ## **Reduce Network Blind Spots** Hybrid architectures, cloud deployments, and rapidly changing traffic patterns often create blind spots that limit effective monitoring. FastNetMon integrates directly with existing network devices and collects flow data from multiple sources simultaneously, creating a unified view of network traffic. This makes it easier to identify unexpected traffic spikes, abnormal protocol usage, or unusual traffic sources that may indicate misconfigurations, performance issues, or active attacks. By analysing traffic patterns in real time, FastNetMon helps teams detect problems early — before they escalate into outages or security incidents. ## **Real-Time and Historical Traffic Analysis** FastNetMon provides immediate insight into current network conditions while also maintaining long-term historical traffic data. This combination supports both day-to-day operations and post-incident investigation. Real-time monitoring enables fast detection of anomalies such as sudden increases in bandwidth usage or packet rates. Historical data allows teams to compare current traffic against baselines, analyse previous incidents, and refine detection thresholds over time. Traffic data is stored in a high-performance, column-oriented ClickHouse database, enabling efficient querying and long-term retention even in high-volume networks. ## **Reporting, Metrics, and Integrations** FastNetMon enables flexible analysis of traffic data using SQL-based queries. Network engineers can generate custom reports to understand traffic distribution, identify top talkers, or investigate specific hosts, subnets, or protocols. The platform also exports metrics to popular time-series databases such as ClickHouse, InfluxDB, Graphite, and VictoriaMetrics. These metrics include bandwidth, packet rates, and flow counts at host or network level, making it easy to integrate FastNetMon into existing monitoring and observability stacks. This openness allows teams to build custom dashboards, automate alerts, and connect traffic visibility directly to operational workflows. ## **Traffic Visibility as the Foundation for DDoS Protection** Effective DDoS detection depends on accurate traffic visibility. FastNetMon continuously monitors traffic behaviour and identifies attacks based on abnormal changes in volume, packet rates, and flow characteristics. This flow-based approach allows FastNetMon to detect both large volumetric attacks and lower-volume anomalies that may evade traditional threshold-based monitoring. Stored traffic data also supports post-attack analysis, helping teams improve detection logic and mitigation strategies over time. By combining traffic visibility with automated DDoS detection and mitigation, FastNetMon provides a complete, network-level view of security and performance. ## **Built for Scale and Performance** FastNetMon is designed for environments where scale matters. Its high-performance processing engine and efficient storage architecture allow it to operate reliably in enterprise, service provider, and cloud networks without artificial limits on traffic volume or monitored devices. Whether you need visibility across a single network segment or a multi-terabit backbone, FastNetMon scales with your infrastructure. ## **Get Full Visibility Into Your Network** FastNetMon turns raw traffic data into clear, actionable visibility — helping you operate more reliable networks and respond faster to threats. **[Start a free trial](https://fastnetmon.com/trial)** to see FastNetMon in action, or **talk to our sales team** at <sales@fastnetmon.com> to discuss how it fits your network and operational requirements. --- ### [Compare Community and Advanced editions](https://fastnetmon.com/compare-community-and-advanced/) **Published:** March 3, 2026 **Author:** Milan Milosevic **Excerpt:** Compare FastNetMon Advanced vs. Community edition. Discover why Advanced is the production-ready choice for large networks, while Community is best suited for labs and basic testing. **Content:** On this page, we review the key differences between FastNetMon Advanced and the Community edition. FastNetMon Advanced is designed as a solid, production-ready solution for organisations operating medium- to large-scale networks. FastNetMon Community offers a limited set of capabilities that are sufficient only for basic DDoS detection. It is primarily intended for small networks and test lab environments. ## DDoS detection options | Feature name | Community edition | **Advanced edition** | |---|---|---| | Volumetric DDoS detection | Yes | Yes | | Amplification attack detection | Yes | Yes | | Ability to block host under attack | Yes | Yes | | [Rapid](https://fastnetmon.com/docs-fnm-advanced/traffic-buffer-capability-to-speed-up-attack-detection-speed/) attack detection | No | Yes | | Ability to detect [prefix](https://fastnetmon.com/docs-fnm-advanced/per-hostgroup-thresholds/) under attack | No | Yes | | Arbitrary attack detection | No | Yes | | Ability to [filter](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-bgp-flow-spec-configuration/) only malicious traffic (BGP Flow Spec) | No | Yes | | Ability to whitelist [remote](https://fastnetmon.com/docs-fnm-advanced/advanced-cli-reference/) hosts | No | Yes | | Custom thresholds for [different](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-per-host-hostgroups/) networks | No | Yes | | Ability to [block remote attacker](https://fastnetmon.com/docs-fnm-advanced/automatic-blocks-for-remote-attackers/) IPs | No | Yes | | Different thresholds for [incoming and outgoing](https://fastnetmon.com/docs-fnm-advanced/per-direction-hostgroup-thresholds/) traffic | No | Yes | | Ability to create [customized thresholds](https://fastnetmon.com/docs-fnm-advanced/flexible-thresholds/) for L3, L4 traffic | No | Yes | | Support for BGP [traffic diversion](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-and-bgp-traffic-diversion/) | No | Yes | | Integrations with Cloud based [DDoS scrubbing](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-and-ddos-scrubbing-centers-integration/) centers | No | Yes | ## Scalability | Feature name | Community edition | **Advanced edition** | |---|---|---| | Bandwidth | Up to ~10G | Up to 45 Terabits | | Number of monitored hosts | Tens of thousands | Hundreds of thousands | | Monitored networks | 5-10 | Thousands | | Custom thresholds groups | 1 IPv6, ~10 for IPv4 | 2000+ | | Flow / s | < 10k | Up to 800k per server | | Monitored routers / switches | 3-5 | 1000+ | ## Traffic capture support | Feature name | Community edition | **Advanced edition** | |---|---|---| | IPv6 support | Yes | Yes | | sFlow v5 support | Yes | Yes | | Netflow v5 support | Yes | Yes | | Netflow v9 support | Yes | Yes | | IPFIX support | Yes | Yes | | [PSAMP](https://fastnetmon.com/docs-fnm-advanced/netflow-lite-and-ipfix-inline-monitoring-services/), inline monitoring services, IPFIX 315 | No | Yes | | GRE decapsulation | No | Yes | | VLAN stripping | Yes | Yes | | Google Compute Engine VPC Flow Logs | No | Yes | | FastNetMon [Flow](https://fastnetmon.com/docs-fnm-advanced/tera-flow/) | No | Yes | | FastNetMon Flow with [encryption](https://fastnetmon.com/docs-fnm-advanced/tera-flow/) | No | Yes | | Amazon AWS VPC Flow Logs | No | Yes | | Netflow / IPFIX template cache | No | Yes | | Optimized mirror capture / SPAN | No | Yes | | 1GE mirror capture support | Yes | Yes | | 10, 40, 100 GE mirror capture | No | Yes | ## Attack mitigation / notification options | Feature name | Community edition | **Advanced edition** | |---|---|---| | Native BGP Unicast support | No | Yes | | Native BGP Flow Spec / RFC 5575 | No | Yes | | SMTP notification | No | Yes | | Slack support | No | Yes | | Telegram support | No | Yes | | Call script when attack arrives | Yes | Yes | | Call web hook when attack arrives | No | Yes | | Syslog alerts | No | Yes | | Attack alerts in Grafana | No | Yes | | Persistent traffic storage | No | Yes | ## Attack and traffic reporting | Feature name | Community edition | **Advanced edition** | |---|---|---| | Graphite support | Yes | Yes | | InfluxDB support | Yes | Yes | | Clickhouse support | No | Yes | | Grafana dashboards support | Basic | Extended | | Pre calculated top talkers reports | No | Yes | ## Deployment options | Feature name | Community edition | **Advanced edition** | |---|---|---| | Automatic install tool | Basic | Extended | | Rest based API | No | Yes | | ARM64, Ampere, Graviton support | Yes | Yes | | Network equipment configuration guides | No | Yes | | Configuration database | No | Yes | | Command line configuration tool fcli | No | Yes | | Binary .deb packages | No | Yes | | APT and RPM repositories | No | Yes | | OVA based deployment | No | Yes | | Official Docker images | No | Yes | ## Vendor compatibility | Feature name | Community edition | **Advanced edition** | |---|---|---| | Cisco | Yes | Yes | | Juniper | Yes | Yes | | Brocade | Yes | Yes | | Extreme | Yes | Yes | | Nokia | Yes | Yes | | Arista | Yes | Yes | | Huawei | Yes | Yes | | Dell | Yes | Yes | | HP | Yes | Yes | | D-Link | Yes | Yes | | Netgate | Yes | Yes | | VyOS | Yes | Yes | | 6Wind | Yes | Yes | | Mikrotik | Yes | Yes | | A-10 Networks | Yes | Yes | | Radware | Yes | Yes | --- ### [FastNetMon Newsletter: Network Engineering Community News](https://fastnetmon.com/newsletter/) **Published:** March 5, 2026 **Author:** FastNetMon **Content:** # FastNetMon Newsletter: Network Engineering Community News [Home](https://fastnetmon.com/ "Home")‣ FastNetMon Newsletter: Network Engineering Community News Welcome to the archive of the FastNetMon Network Engineering Community News: a monthly newsletter covering notable network incidents, DDoS trends, industry developments, and updates from the FastNetMon team, including product news and events we attend. **Stay up to date:** Subscribe via [this link](https://cdn.forms-content.sg-form.com/b3c8181d-c30d-11ef-b203-ca12671f70d2) to receive the newsletter once a month in your inbox. We respect your inbox — you’ll only receive this newsletter, no additional marketing emails. [![Network Engineering Community News: September 2026](https://fastnetmon.com/wp-content/uploads/2026/09/FastNetMon-Newsletter-September-26-Web.webp)](https://fastnetmon.com/2026/09/29/network-engineering-community-news-september-2026/) ## [Network Engineering Community News: September 2026](https://fastnetmon.com/2026/09/29/network-engineering-community-news-september-2026/) Sep 29, 2026 \| [Newsletter](https://fastnetmon.com/category/newsletter/) ⚡️ Network Engineering Community News – from FastNetMon September at FastNetMon brings new open-source launches, FastNetMon Advanced 2.0.384, community updates from events, and a closer look at… [![Network Engineering Community News: August 2026](https://fastnetmon.com/wp-content/uploads/2026/08/Web-FastNetMon-Newsletter-August-26.png)](https://fastnetmon.com/2026/08/27/network-engineering-community-news-august-2026/) ## [Network Engineering Community News: August 2026](https://fastnetmon.com/2026/08/27/network-engineering-community-news-august-2026/) Aug 27, 2026 \| [Newsletter](https://fastnetmon.com/category/newsletter/) ⚡️ Network Engineering Community News – from FastNetMon Welcome to the August edition of Network Engineering Community News! This month, we’re covering key FastNetMon product updates, the recent… [![Blue grid background with 'What’s new?' headline and white rounded labels listing updates: Netomics: Self-Hosted Routing Intelligence Platform; HPPT & HTTPS Proxy Support; New releases; Expanded Fedora and EPEL Support for Community Edition; Learning Mellanox Connect X5 & VPP; FastNetMon Sessions Podcast; Emerging LLM Built DDoS Malware.](https://fastnetmon.com/wp-content/uploads/2026/07/FastNetMon-Newsletter-July26.png)](https://fastnetmon.com/2026/07/30/network-engineering-community-news-july-2026/) ## [Network Engineering Community News: July 2026](https://fastnetmon.com/2026/07/30/network-engineering-community-news-july-2026/) Jul 30, 2026 \| [Newsletter](https://fastnetmon.com/category/newsletter/) ⚡️ Network Engineering Community News – from FastNetMon Big news this month: we’ve launched Netomics, a new self-hosted routing intelligence platform for network operators. We’ve also shipped a ton… [![Blue grid banner with 'What’s new?' and white rounded topic chips listing items like 'Lab sneak peek' and 'Monitoring 2,800 BGP Sessions' with a FastNetMon logo in the top-right corner.](https://fastnetmon.com/wp-content/uploads/2026/06/FastNetMon-Newsletter-June26-–-Web.png)](https://fastnetmon.com/2026/06/30/network-engineering-community-news-june-2026/) ## [Network Engineering Community News: June 2026](https://fastnetmon.com/2026/06/30/network-engineering-community-news-june-2026/) Jun 30, 2026 \| [Newsletter](https://fastnetmon.com/category/newsletter/) ⚡️ Network Engineering Community News – from FastNetMon We’ve given the newsletter a bit of a fresh coat of paint, but the goal is the same: keeping you in the loop on what we’re building, sharing… [![Blue grid banner with the heading "What’s new?" and rounded white tags listing topics like security advisories, NANOG 97 updates, and various tech notes.](https://fastnetmon.com/wp-content/uploads/2026/05/FastNetMon-Newsletter-May26-–-WebV.png)](https://fastnetmon.com/2026/05/31/network-engineering-community-news-may-2026/) ## [Network Engineering Community News: May 2026](https://fastnetmon.com/2026/05/31/network-engineering-community-news-may-2026/) May 31, 2026 \| [Newsletter](https://fastnetmon.com/category/newsletter/) ⚡️ Network Engineering Community News – from FastNetMon We’ve given the newsletter a bit of a fresh coat of paint, but the goal is the same: keeping you in the loop on what we’re building, sharing… [![Header graphic for Network Engineering Community News (April 2026) featuring a cartoon lighthouse on rocky islets with waves, a light-blue diagonal banner in the top-right, and a blue diagonal FastNetMon section at the bottom-left.](https://fastnetmon.com/wp-content/uploads/2026/04/Newsletter-2.png)](https://fastnetmon.com/2026/04/30/network-engineering-community-news-april-2026/) ## [Network Engineering Community News: April 2026](https://fastnetmon.com/2026/04/30/network-engineering-community-news-april-2026/) Apr 30, 2026 \| [Newsletter](https://fastnetmon.com/category/newsletter/) Welcome to our Network Engineering Community News! Hi from FastNetMon! March brought plenty to share. We released two new FastNetMon Advanced versions, added Debian 13 support and Bison router… [![Network Engineering Community News: March 2026](https://fastnetmon.com/wp-content/uploads/2026/03/Newsletter-1.png)](https://fastnetmon.com/2026/03/31/network-engineering-community-news-march-2026/) ## [Network Engineering Community News: March 2026](https://fastnetmon.com/2026/03/31/network-engineering-community-news-march-2026/) Mar 31, 2026 \| [Newsletter](https://fastnetmon.com/category/newsletter/) Network Engineering Community News – from FastNetMon Welcome to our Network Engineering Community News! Hi from FastNetMon! March brought plenty to share. We released two new FastNetMon Advanced… [![Network Engineering Community News: February 2026](https://fastnetmon.com/wp-content/uploads/2026/02/FastNetMon-Newsletter-February-2026.png)](https://fastnetmon.com/2026/02/26/network-engineering-community-news-february-2026/) ## [Network Engineering Community News: February 2026](https://fastnetmon.com/2026/02/26/network-engineering-community-news-february-2026/) Feb 26, 2026 \| [Newsletter](https://fastnetmon.com/category/newsletter/) Welcome to our Network Engineering Community News! If you’re new here, welcome. This monthly update goes out to everyone who has used or trialed FastNetMon. In February, we were at APRICOT in… [![Network Engineering Community News: December 2025](https://fastnetmon.com/wp-content/uploads/2026/01/Network-Engineering-Communiy-News-December-2025.png)](https://fastnetmon.com/2025/12/27/network-engineering-community-news-december-2025/) ## [Network Engineering Community News: December 2025](https://fastnetmon.com/2025/12/27/network-engineering-community-news-december-2025/) Dec 27, 2025 \| [Newsletter](https://fastnetmon.com/category/newsletter/) Welcome to Network Engineering Community News – End of Year 2025 Hello from all of us at FastNetMon, your trusted partner in DDoS detection and mitigation. While the year is coming to a close,… [![Network Engineering Community News: October 2025](https://fastnetmon.com/wp-content/uploads/2025/10/FastNetMon-October-2025-Newsletter.png)](https://fastnetmon.com/2025/10/30/network-engineering-community-news-october-2025/) ## [Network Engineering Community News: October 2025](https://fastnetmon.com/2025/10/30/network-engineering-community-news-october-2025/) Oct 30, 2025 \| [Newsletter](https://fastnetmon.com/category/newsletter/) Welcome to our Network Engineering Community News! Hi from FastNetMon! October brought plenty of tricks and treats on the network front: outbound DDoS attacks, new botnets lurking in misconfigured… Page 1 of 21[2](https://fastnetmon.com/wp-cron.php/page/2/?doing_wp_cron=1792528011.6662390232086181640625&et_blog "Page 2")[»](https://fastnetmon.com/wp-cron.php/page/2/?doing_wp_cron=1792528011.6662390232086181640625&et_blog) --- ### [DDoS Scrubbing Centre Diversion Automation](https://fastnetmon.com/ddos-scrubbing-centre-diversion/) **Published:** March 16, 2021 **Author:** FastNetMon **Content:** ### **Automated traffic diversion to external scrubbing centres** Scrubbing centres are a proven way to mitigate large-scale DDoS attacks by diverting malicious traffic away from your network for cleaning before it reaches services or customers. During an attack, affected prefixes are redirected to a scrubbing provider, where attack traffic is filtered and legitimate traffic is returned. FastNetMon automates this diversion process by acting as the control plane between real-time DDoS detection and your scrubbing infrastructure. Instead of relying on manual intervention or always-on scrubbing, engineers define the rules in advance, and FastNetMon executes them immediately when an attack is detected. ## **How scrubbing centre diversion works with FastNetMon** FastNetMon continuously analyses live network traffic and detects DDoS attacks in near real time. When an attack meets operator-defined thresholds, FastNetMon automatically initiates traffic diversion using the configured method. The most common approach is **BGP Unicast diversion**, where FastNetMon announces a more specific prefix (for example, a /24 in IPv4) toward the scrubbing centre while keeping the covering prefix routed normally. Due to standard BGP path selection, traffic for the affected prefix is redirected to the scrubbing centre globally. For IPv6 networks, FastNetMon supports configurable prefix lengths (such as /48) to accommodate different routing policies and operational constraints. Once the attack subsides, FastNetMon can automatically withdraw the diversion announcement, restoring normal routing without manual cleanup. ## **Automation without sacrificing operator control** FastNetMon does not enforce a fixed mitigation model. Instead, it allows engineers to define exactly **when**, **how**, and **for which prefixes** scrubbing diversion should occur. Diversion can be triggered using: - BGP Unicast announcements - BGP Flow Spec–based signalling - External scripts - API-based integrations with scrubbing providers FastNetMon determines the affected host or prefix, maps it to the appropriate network block, and applies the preconfigured diversion logic consistently and at machine speed—eliminating delays caused by human intervention during active attacks. ## **API-based integration with scrubbing providers** In addition to BGP-based diversion, FastNetMon Advanced supports **native API integrations** with several cloud and on-premise DDoS scrubbing services. These integrations allow FastNetMon to signal scrubbing providers directly, without requiring custom glue logic. Currently supported scrubbing integrations include: - **Gcore Global DDoS Protection - **F5 - **Cloudflare Magic Transit Using these integrations, FastNetMon can: - Programmatically enable traffic diversion via the provider’s API - Pass attack context and affected prefixes - Automatically withdraw diversion once the attack ends This provides a clean, deterministic lifecycle for scrubbing activation and rollback. ## **Designed for large and complex networks** Scrubbing diversion is typically used in scenarios where absorbing or filtering traffic locally is no longer viable. FastNetMon is designed to support these decisions at network scale, where sacrificing a specific prefix is preferable to risking congestion or instability across the entire network. By automating detection and diversion: - Attack traffic is removed before it consumes backbone capacity - Scrubbing is activated only when required - Legitimate traffic can be returned after filtering - Engineers retain full visibility and control over mitigation behaviour FastNetMon works with existing routers, mitigation systems, and scrubbing providers, making it suitable for ISPs, telcos, hosting providers, and large enterprise networks. ## **Part of a complete DDoS mitigation stack** Scrubbing centre automation is one component of FastNetMon’s broader DDoS protection capabilities. It integrates seamlessly with: - Real-time DDoS detection and traffic visibility - BGP Blackhole (RTBH) automation - BGP Flow Spec rule enforcement - Blocklist-based filtering - External mitigation systems This allows operators to build layered, network-level defence strategies without locking into a single vendor or mitigation approach. --- ### [BGP Flow Spec DDoS Mitigation with FastNetMon](https://fastnetmon.com/bgp-flow-spec-ddos-mitigation/) **Published:** March 15, 2021 **Author:** FastNetMon **Content:** ## **Targeted traffic filtering with operator-defined Flow Spec rules** BGP Flow Spec is a network-layer mitigation technique that allows operators to filter malicious traffic without fully blackholing affected prefixes. Instead of dropping all traffic to a destination, Flow Spec enables precise filtering based on protocol attributes such as IP addresses, ports, and TCP flags. FastNetMon uses BGP Flow Spec as a controlled, rule-based mitigation mechanism tightly integrated with real-time DDoS detection. Engineers define the detection thresholds and mitigation logic in advance, and FastNetMon applies Flow Spec rules automatically when those conditions are met. ## **Why BGP Flow Spec is effective for DDoS mitigation** BGP Flow Spec has become a core mitigation tool in ISP, telco, and large enterprise networks because it allows traffic filtering to be enforced directly on routers using standard BGP signalling. This removes the need for specialised mitigation hardware while keeping enforcement close to the traffic source. By matching traffic on protocol-level attributes—such as source and destination addresses, transport ports, and TCP or ICMP flags—Flow Spec enables operators to suppress malicious flows while allowing legitimate traffic to continue. This makes it particularly effective in high-volume environments where precision matters and full blackholing would be too disruptive. ## **How FastNetMon applies Flow Spec rules** FastNetMon continuously analyses live network traffic and detects anomalies based on operator-defined thresholds. When traffic for a host or network exceeds expected behaviour, FastNetMon captures representative traffic samples and classifies the attack pattern. Using this data, FastNetMon can automatically generate Flow Spec rules that describe the malicious traffic characteristics observed. These rules are derived from real traffic and designed to maximise attack coverage while minimising the impact on legitimate flows. Once generated, Flow Spec rules are propagated to routers using BGP and enforced at the network layer. Engineers remain fully in control of which attacks should trigger Flow Spec, how rules are constructed, and when mitigation should be applied or withdrawn. FastNetMon acts as the control plane for this process—it does not enforce a fixed mitigation model or hide decision-making logic. ## **Full Flow Spec mitigation lifecycle** FastNetMon supports the complete lifecycle of Flow Spec-based mitigation: 1. **Detection** – Identify abnormal traffic patterns in near real time 1. **Rule creation** – Generate Flow Spec rules matching observed attack characteristics 1. **Distribution** – Propagate rules to routers via BGP 1. **Enforcement** – Filter malicious traffic directly on routers at line rate 1. **Withdrawal** – Automatically remove rules when the attack subsides This ensures that Flow Spec rules remain temporary, accurate, and aligned with current network conditions, without requiring manual cleanup. ## **Supported attack types** Flow Spec mitigation with FastNetMon is commonly used to mitigate: - TCP flood attacks - UDP floods and amplification attacks - DNS, SSDP, SNMP, and Memcached reflection attacks - GRE and other protocol-specific floods - Attacks identifiable by TCP flags such as SYN, ACK, or SYN-ACK - ICMP-based floods and fragment-related attack patterns Flow Spec supports fragment matching, allowing operators to address attacks that exploit IP fragmentation behaviour. ## **Flow Spec and BGP Blackhole: complementary techniques** Flow Spec and BGP Blackhole mitigation serve different purposes and are often combined as part of a layered defence strategy. Flow Spec is designed to filter specific malicious traffic patterns while preserving legitimate traffic. BGP Blackhole mitigation, by contrast, drops all traffic to a destination, including legitimate flows. In practice, Flow Spec is typically used first to contain attacks with precision. If traffic volume continues to grow beyond what the network can safely handle, operators may escalate to BGP blackholing as a last-resort containment measure. FastNetMon supports both approaches and allows engineers to define escalation logic explicitly. ## **Standards-based and vendor-neutral** FastNetMon implements BGP Flow Spec in accordance with RFC 5575 and has been tested across a wide range of routing platforms, including Cisco, Juniper, Arista, Nokia, Huawei, Extreme, and others. For environments where Flow Spec enforcement is handled externally, FastNetMon can also export rule data in structured formats for consumption by third-party mitigation systems, custom tooling, or notification pipelines. ## **Part of a broader DDoS mitigation stack** Flow Spec mitigation with FastNetMon integrates seamlessly with the platform’s other capabilities, including real-time DDoS detection and traffic visibility, BGP Blackhole (RTBH) automation, scrubbing centre diversion, blocklist-based filtering, and API-driven integrations with external systems. Together, these components allow operators to build deterministic, scalable DDoS defence strategies tailored to their own networks and operational practices. --- ### [FastNetMon Advanced](https://fastnetmon.com/fastnetmon-advanced/) **Published:** March 22, 2017 **Author:** Pavel Odintsov **Content:** FastNetMon Advanced is the commercial edition of FastNetMon, designed to provide a fully supported, production-ready solution for organisations that require reliable, network-level DDoS detection and mitigation. It builds on FastNetMon’s core capabilities in real-time traffic monitoring and automated response to L3 and L4 attacks, while offering a streamlined deployment model and professional support for business environments. FastNetMon Advanced is developed to operate independently within your infrastructure and integrate with existing network telemetry and routing systems without operational friction. On this page, you will find links to key resources for FastNetMon Advanced, including an overview of the product, technical documentation, pricing details and trial options. [Product overview](https://fastnetmon.com/product-overview/) [Documentation](https://fastnetmon.com/docs-fnm-advanced/) [Pricing](https://fastnetmon.com/price/) [Free trial](https://fastnetmon.com/trial/) [Terms and conditions](https://fastnetmon.com/terms-conditions/) [Payment methods](https://fastnetmon.com/payment/) --- ### [Cookie Policy](https://fastnetmon.com/cookie-policy/) **Published:** March 26, 2017 **Author:** FastNetMon **Content:** This site uses cookies - small text files that are placed on your machine to help the site provide a better user experience. In general, cookies are used to retain user preferences, store information for things like shopping carts, and provide anonymised tracking data to third party applications like Google Analytics. As a rule, cookies will make your browsing experience better. However, you may prefer to disable cookies on this site and on others. The most effective way to do this is to disable cookies in your browser. We suggest consulting the Help section of your browser or taking a look at [the About Cookies website](https://www.aboutcookies.org) which offers guidance for all modern browsers --- ### [FastNetMon Brand Kit](https://fastnetmon.com/fastnetmon-brand-kit/) **Published:** October 10, 2025 **Author:** Outi Maria Pietilanaho **Content:** Here you’ll find FastNetMon’s official logos, colours, and visual assets for use in media, partner materials and collaborations. Please use these resources to represent our brand consistently. For any questions about usage or additional formats, please contact <media@fastnetmon.com>. ## FastNetMon logos **Web (raster)** [Full colour logo (PNG)](https://fastnetmon.com/wp-content/uploads/2025/10/logo_FastNetMon.png) [Symbol - bolt (PNG)](https://fastnetmon.com/wp-content/uploads/2025/10/Symbol_FastNetMon.png) **Vector (scalable)** [Full colour logo (vector PDF)](https://fastnetmon.com/wp-content/uploads/2026/02/FastNetMon_logo_vector.pdf) [White logo (vector PDF)](https://fastnetmon.com/wp-content/uploads/2026/02/logo_FastNetMon_white_vectorised.pdf) [Bolt\_Symbol (vector PDF)](https://fastnetmon.com/wp-content/uploads/2026/02/Bolt_symbol_vectorised.pdf) **Print** [Print logo (PDF)](https://fastnetmon.com/wp-content/uploads/2025/10/print_logo_FastNetMon.pdf) ## FastNetMon brand colours These are the official FastNetMon brand colours. Use them whenever featuring FastNetMon visually. Do not modify or substitute them. ![](https://fastnetmon.com/wp-content/uploads/2026/02/Darker-blue-1.png)**Darker Blue** RGB: 31 \| 42 \| 127 HEX: #1f2f7f CMYK: 76\|63\|0\|50 ![](https://fastnetmon.com/wp-content/uploads/2026/02/Blue-1.png)**Blue** RGB: 30 \| 115 \| 190 HEX: #1E73BE CMYK: 63 \|29\|0\|25 ![](https://fastnetmon.com/wp-content/uploads/2026/02/Light-blue.png)**Lighter Blue** RGB: 220 \| 238 \| 251 HEX: #DCEEFB CMYK: 12 502 ![](https://fastnetmon.com/wp-content/uploads/2026/02/Slate.png)**Slate** RGB: 48 \| 61 \|72 HEX: #303D48 CMYK: 33 \|15\|0 \|72 ![](https://fastnetmon.com/wp-content/uploads/2026/02/White.png)**White** RGB: 255 255 255 HEX: #FFFFFF CMYK: 0000 ## FastNetMon typography **Primary typeface:** Poppins Used for headings, logos, and key brand elements. [Download Poppins from Google Fonts](https://fonts.google.com/specimen/Poppins) **Secondary typeface:** Open Sans Used for body text, paragraphs, and supporting content. [Download Open Sans from Google Fonts](https://fonts.google.com/specimen/Open+Sans) For any questions about usage or additional formats, please contact <media@fastnetmon.com> --- ### [BGP Blackhole (RTBH) DDoS Mitigation with FastNetMon](https://fastnetmon.com/bgp-blackhole-automation/) **Published:** February 25, 2021 **Author:** FastNetMon **Content:** ### **Automated traffic dropping to protect network stability** BGP Blackhole mitigation—often referred to as RTBH (Remote Triggered Black Hole)—is a routing-based technique used to protect networks during large-scale DDoS attacks by deliberately dropping traffic to a targeted destination. While this approach sacrifices availability for the affected host or prefix, it prevents attack traffic from overwhelming shared infrastructure and impacting the wider network. FastNetMon automates BGP Blackhole mitigation as part of a controlled, operator-defined DDoS response strategy. Detection, decision-making, and execution are handled automatically, without requiring manual intervention during an active attack. ## **What BGP Blackhole mitigation does—and when it’s used** In a BGP Blackhole scenario, traffic destined for an attacked host or prefix is routed to a null interface, effectively dropping all packets before they consume bandwidth or router resources. This technique is typically applied at the /32 (IPv4) or /128 (IPv6) level, though larger prefixes may be used depending on routing policy. BGP Blackholing is not intended to preserve service availability for the affected destination. Instead, it is used when the priority is protecting the rest of the network—particularly in situations where attack volume is high enough to threaten shared links, routing infrastructure, or upstream capacity. This makes RTBH especially valuable for service providers, ISPs, and large networks where isolating a single customer or service is preferable to risking widespread disruption. ## **Why blackholing focuses on the destination, not the source** In most DDoS scenarios, attempting to block individual attack sources is ineffective. Attacks are commonly distributed across large botnets, frequently involve spoofed source addresses, and change rapidly over time. BGP Blackhole mitigation avoids this problem by focusing on the attack target instead of chasing individual sources. By dropping traffic to the destination, the network is immediately protected from the aggregate impact of the attack—regardless of how many sources are involved. ## **How FastNetMon automates RTBH** FastNetMon continuously monitors live network traffic and detects DDoS attacks in near real time using operator-defined thresholds. When an attack is identified and meets the criteria for blackholing, FastNetMon automatically initiates RTBH according to predefined rules. This typically involves: - Announcing a blackhole route via BGP - Applying the appropriate BGP community or next-hop - Propagating the announcement to internal routers, upstream providers, or both FastNetMon supports both **internal RTBH**, where traffic is dropped within your own network, and **upstream RTBH**, where blackholing occurs at the provider edge to protect core infrastructure and transit links. Once the attack subsides, FastNetMon can automatically withdraw the blackhole route, restoring normal traffic without manual cleanup. ## **Full black hole mitigation lifecycle** FastNetMon supports the complete RTBH lifecycle: 1. **Detection** – Identify attack traffic in near real time 2. **Decision** – Evaluate operator-defined thresholds and policies 3. **Announcement** – Inject blackhole routes via BGP 4. **Withdrawal** – Remove routes when the attack ends This lifecycle ensures blackholing is applied deliberately, temporarily, and consistently. ## **RTBH and Flow Spec: different tools for different situations** BGP Blackhole and BGP Flow Spec serve distinct roles in a layered DDoS defence strategy. Flow Spec is designed to filter specific malicious traffic patterns while preserving legitimate flows. BGP Blackhole, by contrast, drops all traffic to the affected destination and is typically used when attack volume exceeds what selective filtering can safely handle. In practice, many operators use Flow Spec first and escalate to RTBH only if necessary. FastNetMon supports both approaches and allows engineers to define escalation logic explicitly, based on traffic volume, duration, or other operational criteria. ## **Flexible deployment options** FastNetMon supports multiple RTBH deployment models, including: - Blackholing within your own network using iBGP - Blackholing via upstream providers using agreed BGP communities - Hybrid models combining internal and upstream enforcement These options allow operators to choose where traffic is dropped—at the edge, upstream, or both—based on capacity, topology, and commercial agreements. ## **Designed to protect the rest of the network** The purpose of RTBH is not to keep the attacked host online, but to preserve the stability of the network as a whole. By isolating attack traffic quickly and automatically, FastNetMon helps ensure that unaffected customers, services, and infrastructure continue to operate normally. For networks where uptime and predictability matter, automated blackholing provides a critical safety valve during extreme attack conditions. ## **Part of a broader DDoS mitigation stack** BGP Blackhole automation with FastNetMon integrates seamlessly with the platform’s other capabilities, including real-time DDoS detection, BGP Flow Spec mitigation, scrubbing centre diversion, blocklist-based filtering, and API-driven integrations with external systems. This allows operators to build layered, deterministic DDoS defence strategies tailored to their own networks and operational practices. --- ### [IP Infusion OcNOS sFlow v5 configuration with FastNetMon Advanced](https://fastnetmon.com/docs-fnm-advanced/ip-infusion-ocnos-sflow-v5-configuration-with-fastnetmon-advanced/) **Published:** February 25, 2026 **Author:** Pavel Odintsov **Content:** To configure sFlow v5 on IP Infusion OcNOS you need to apply following options First of all you need to enable sFlow v5 globally: ``` feature sflow sflow agent-ip [Local IP of router to send sFlow from] sflow collector [FastNetMon IP] port 6393 receiver-time-out 100 max-datagram-size 1400 vrf default ``` Then you need to enable it for all upstream facing ports: ``` interface xe8 sflow sampling-rate 1024 direction ingress max-header-size 256 sflow enable ``` Then ensure that configuration is applied correctly: ``` sflow detail sFlow Feature: Enabled sFlow Version: 5 Agent IP : [Local IP of router to send sFlow from] Collector 1: IP: [FastNetMon IP] Port: 6393 VRF : default Maximum Datagram Size(bytes): 1400 Receiver timeout(sec) : 98 sFlow Port Detailed Information: Interface Collector Packet-Sampling Packet-Sampling Counter-Polling Maximum Header ID Rate Count Interval Count Size(bytes) Ingress Egress Ingress Egress (sec) Ingress Egress --------- --------- ----------------------- ----------------------- ----------------------- -------------------- xe8 1 1024 0 4587927 0 10 9135 256 ``` --- ### [Cisco ASR 9000 sFlow configuration for FastNetMon Advanced](https://fastnetmon.com/docs-fnm-advanced/cisco-asr-9000-sflow-configuration-for-fastnetmon-advanced/) **Published:** February 24, 2026 **Author:** Pavel Odintsov **Content:** To configure sFlow v5 on Cisco ASR 9000 platform please apply following configuration: ``` flow exporter-map SFLOW-EXP-MAP version sflow v5 ! transport udp 6343 source Loopback0 destination [FastNetMon IP] ! flow monitor-map SFLOW-MON-MAP record sflow exporter SFLOW-EXP-MAP ! sampler-map SFLOW-SAMP-MAP random 1 out-of 1000 ``` Then enable it for all upstream facing interfaces: ``` interface TenGigE0/X/X/X flow datalinkframesection monitor SFLOW-MON-MAP sampler SFLOW-SAMP-MAP ingress ``` Then check that configuration was applied correctly: ``` #sh flow monitor-map SFLOW-MON-MAP Flow Monitor Map : SFLOW-MON-MAP ------------------------------------------------- Id: 4 RecordMapName: sflow (1 labels) ExportMapName: SFLOW-EXP-MAP CacheAgingMode: Normal CacheMaxEntries: 65535 CacheActiveTout: 1800 seconds CacheInactiveTout: 15 seconds CacheUpdateTout: N/A CacheRateLimit: 2000 HwCacheExists: False HwCacheInactTout: 50 sFlow options: Option: Max sample header ``` Then check that sFlow 5 frames are being exported correctly: ``` show flow exporter SFLOW-EXP-MAP location 0/0/CPU0 Flow Exporter: SFLOW-EXP-MAP Export Protocol: sFlow v5 Flow Exporter memory usage: 5265224 Used by flow monitors: SFLOW-MON-MAP Status: Normal Transport: UDP Destination: [FastNetMon IP] (6343) VRF default Source: [Agent IP] (64232) Flows exported: 158663104 (19446652344 bytes) Flows dropped: 0 (0 bytes) Packets exported: 14500603 (19446652344 bytes) Packets dropped: 0 (0 bytes) Total export over last interval of: 1 hour: 135190 pkts 181446820 bytes 1492583 flows 1 minute: 2019 pkts 2708076 bytes 22345 flows 1 second: 0 pkts 0 bytes 0 flows ``` --- ### [FastNetMon Engineer Community](https://fastnetmon.com/fastnetmon-engineer-community/) **Published:** February 18, 2026 **Author:** Outi Maria Pietilanaho **Content:** ## A space for operator-to-operator DDoS knowledge exchange The FastNetMon Engineer Community is a space for network engineers and security practitioners to discuss DDoS detection, mitigation, and day-to-day operational challenges. The focus is practical: peer-to-peer support, sharing real-world experience, and helping each other solve problems faster. Many members use it as a place to ask quick technical questions and get answers from people actively working in network security environments. The community is bridged across multiple messaging platforms into one shared conversation, so you can participate using the tools you already use. ## Join the FastNetMon Engineer Community [![](https://fastnetmon.com/wp-content/uploads/2026/02/Telegram.svg)](https://t.me/fastnetmon) [![](https://fastnetmon.com/wp-content/uploads/2026/02/Slack.svg)](https://fastnetmon.slack.com/join/shared_invite/zt-1i2cutd07-qEafHVoJvAOV5ODlHFsLoQ) [![](https://fastnetmon.com/wp-content/uploads/2026/02/discord-2.svg)](https://discord.com/invite/Q4h9AUqFng) ![](https://fastnetmon.com/wp-content/uploads/2026/02/libera-IRC-1.svg) [![](https://fastnetmon.com/wp-content/uploads/2026/02/google_groups.svg)](https://groups.google.com/g/fastnetmon) --- ### [Contact us](https://fastnetmon.com/contact/) **Published:** August 26, 2016 **Author:** FastNetMon **Content:** # Contact us Contact the FastNetMon team for licensing, support, partnership discussions, or any other enquiries. You can find the relevant contact details below. We will get back to you as soon as we can. ### Sales & licensing - sales@fastnetmon.com - Book a Meeting ### Support - support@fastnetmon.com - Submit a Ticket ### Partnerships - partner@fastnetmon.com - Become a Partner ### Press & Media - media@fastnetmon.com - Visit Media Centre ### Careers - careers@fastnetmon.com - Work With Us ### Community & Social - media@fastnetmon.com - Join the Community ### Company details **Address**: 20-22 Wenlock Road, London, N1 7GU, United Kingdom Fastnetmon LTD is a registered company in the United Kingdom **Company registration number**: 10667417 **VAT number:** GB317925879 ### Follow us on Social Media [](https://t.me/fastnetmon) [](https://slack.fastnetmon.com/) [](https://web.libera.chat/?channels=#fastnetmon) [](https://groups.google.com/forum/#!forum/fastnetmon) [](https://www.facebook.com/fastnetmon) [](https://twitter.com/FastNetMon) [](https://www.linkedin.com/company/fastnetmon) [](https://github.com/FastNetMon/) --- ### [FastNetMon Advanced free trial](https://fastnetmon.com/trial/) **Published:** July 9, 2025 **Author:** FastNetMon **Content:** ### Order your trial now After submitting the trial order form, you will receive the instructions to install via email. By submitting this form, you accept our [privacy policy](https://fastnetmon.com/privacy-policy/) and [terms and conditions](https://fastnetmon.com/terms-conditions/). ### FastNetMon Advanced 30-day free trial Join thousands of network professionals protecting their networks with FastNetMon! **No credit card required**. ### With your trial you get: - Ultra-fast DDoS detection - Automated mitigation tools - Traffic visibility & analytics **Questions?** Contact our friendly sales team at <sales@fastnetmon.com> or [book a meeting](https://meetings-eu1.hubspot.com/virgil-truica). [![](https://fastnetmon.com/wp-content/uploads/2025/05/stars-4.5.svg)](https://uk.trustpilot.com/review/fastnetmon.com)Read what others are saying [on Trustpilot](https://uk.trustpilot.com/review/fastnetmon.com) ### FastNetMon is a proud partner of: ![](https://fastnetmon.com/wp-content/uploads/2025/07/FastNetMon-proud-partner-of-1.png) --- ### [Juniper EX and QFX sFlow v5 configuration for FastNetMon Advanced](https://fastnetmon.com/docs-fnm-advanced/juniper-ex-and-qfx-sflow-v5-configuration-for-fastnetmon-advanced/) **Published:** February 13, 2026 **Author:** Pavel Odintsov **Content:** To enable sFlow v5 on Juniper EX or QFX you need to apply initial configuration for sFlow v5 agent on switch: ``` set protocols sflow polling-interval 30 set protocols sflow sample-rate ingress 1000 set protocols sflow sample-rate egress 1000 set protocols sflow source-ip [Local IP to send sFlow from your switch] set protocols sflow collector [FastNetMon IP] udp-port 6343 ``` Please note that EX and QFX switches allow you to configure multiple collectors Then you need to enable sFlow protocol for interfaces facing your upstreams: ``` set protocols sflow interfaces et-0/0/xxx set protocols sflow interfaces et-0/0/yyy ``` To ensure that configuration is correct we recommend checking sFlow agent configuration: ``` show sflow sFlow : Enabled Adaptive fallback : Disabled Sample limit : 300 packets/second Sample limit threshold : 150 packets/second Polling interval : 30 second Sample rate egress : 1:1000: Enabled Sample rate ingress : 1:1000: Enabled Agent ID : ... Source IP address : ... ``` And then we recommend checking per interface configuration which looks this way on EX platforms: ``` show sflow interface Interface Status Sample rate Adapted sample rate Polling-interval Egress Ingress Egress Ingress Egress Ingress ge-0/0/0.0 Enabled Enabled 1000 1000 1000 1000 30 ``` On QFX it looks different way: ``` show sflow interface Interface Status Sample rate Adapted sample rate Polling-interval Egress Ingress Egress Ingress Egress Ingress ge-0/0/13.0 Enabled Enabled 1000 1000 1000 1000 30 ge-1/0/15.0 Enabled Enabled 1000 1000 1000 1000 30 ge-1/0/20.0 Enabled Enabled 1000 1000 1000 1000 30 ge-1/0/21.0 Enabled Enabled 1000 1000 1000 1000 30 ``` For more detailed information please check official vendor [documentation](https://supportportal.juniper.net/s/article/EX-QFX-How-to-monitor-traffic-using-sFlow-technology) --- ### [FastNetMon Automated DDoS Detection](https://fastnetmon.com/ddos-detection-and-mitigation/) **Published:** February 17, 2021 **Author:** FastNetMon **Content:** FastNetMon provides high-performance DDoS detection at the network layer, enabling organisations to identify and respond to L3 and L4 attacks in real time. It is designed for service providers, data centres, cloud operators and enterprises that require fast, accurate visibility into network traffic and automated response to volumetric threats. By analysing traffic telemetry directly from network infrastructure, FastNetMon detects abnormal behaviour within seconds and provides the intelligence required to trigger mitigation actions before services are disrupted. ## **Why DDoS Detection Matters** DDoS attacks target network availability by overwhelming links, devices or services with malicious traffic. Even short disruptions can result in: - Downtime of critical applications and services - Breaches of SLAs and contractual obligations - Loss of customer trust and revenue - Increased operational and recovery costs As networks grow in size and complexity, manual monitoring is no longer sufficient. Effective DDoS protection starts with fast, reliable detection at the network level. ## **Near-Instant DDoS Detection** FastNetMon is designed for rapid detection of abnormal traffic patterns associated with DDoS attacks. Detection speed depends on the telemetry source: - **sFlow and SPAN / port mirroring:** detection in as little as 1–2 seconds - **NetFlow v5/v9 and IPFIX:** typically 5–30 seconds This near-real-time detection enables operators to respond quickly to attacks, reducing both impact and response time. ## **How FastNetMon Detects DDoS Attacks** FastNetMon ingests traffic telemetry from routers, switches and virtual networks using standard, widely supported methods: - sFlow - NetFlow v5 / v9 - IPFIX - SPAN / port mirroring - Cloud flow logs (e.g. AWS and Google Cloud) Traffic is analysed continuously to establish a baseline of normal behaviour. FastNetMon detects anomalies by monitoring changes in: - Bandwidth utilisation - Packets per second (PPS) - Flow count Detection thresholds are fully configurable, allowing engineers to tune sensitivity based on network characteristics and historical attack patterns. ## **DDoS Attack Types Detected** FastNetMon detects a wide range of common and complex DDoS attack vectors, including: - UDP, TCP and ICMP flood attacks - TCP protocol attacks such as SYN, SYN-ACK and FIN floods - Fragmentation-based IP protocol attacks - Amplification and reflection attacks (e.g. DNS, NTP, SSDP, SNMP, GRE) - Multi-vector attacks combining multiple techniques The detection engine is implemented in high-performance C++ and is designed to operate at scale without introducing latency or packet loss. ## **Scalable by Design** FastNetMon is built for high-throughput environments and can scale from small enterprise networks to large service provider backbones. - Supports millions of flows per second per server - Scales linearly by adding additional instances - Runs on standard commodity hardware or virtual machines - Supports both IPv4 and IPv6 networks This makes FastNetMon suitable for networks where traffic volumes and attack sizes continue to grow. ## **From Detection to Mitigation** Detection is the foundation of effective DDoS defence. Once an attack is detected, FastNetMon can automatically trigger mitigation workflows using standard network mechanisms, including: - [BGP BlackHole / RTBH](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-bgp-blackhole-automation/) - [BGP FlowSpec filtering](https://fastnetmon.com/flowspec-ddos-mitigation/) - [Scrubbing centre traffic diversion](https://fastnetmon.com/ddos-scrubbing-centre-diversion/) - [Blocklist-based filtering](https://fastnetmon.com/blocklist-filtering/) These mitigation methods are configured separately and activated only when detection thresholds are exceeded, giving operators full control over how attacks are handled. ## **Designed for Network Engineers** FastNetMon gives network teams full visibility and control over detection and response: - Configurable detection thresholds per host, subnet or protocol - Integration via REST API, scripts and webhooks - Export of metrics to external systems (e.g. Grafana, ClickHouse, InfluxDB) - CLI-based configuration designed for operational workflows No proprietary hardware or vendor-specific dependencies are required. ## **Who Uses FastNetMon for DDoS Detection** FastNetMon is used globally by organisations that rely on network availability, including: - ISPs and telecom operators - Data centres and hosting providers - Cloud and hybrid infrastructure operators - Enterprises with high-value online services Customers in more than 140 countries rely on FastNetMon to detect and respond to DDoS attacks at the network scale. ## **Get Started with FastNetMon DDoS Detection** FastNetMon provides fast, accurate and scalable DDoS detection as the foundation of a complete network-level defence strategy. You can evaluate FastNetMon with a free trial and see how it fits into your existing network and operational model. **Start your** [**free trial**](https://fastnetmon.com/trial) or explore [pricing options](https://fastnetmon.com/price/) to learn more. --- ### [FastNetMon - Flexible and Powerful Embeddable Solutions for Your DDoS Detection Systems](https://fastnetmon.com/embeddable-solutions/) **Published:** March 31, 2021 **Author:** FastNetMon **Content:** FastNetMon is designed to be flexible by default. In addition to standard server deployments, it can be embedded into a wide range of hardware platforms and integrated directly into existing DDoS detection and mitigation systems. This makes FastNetMon suitable for network vendors, service providers, and engineering teams building custom security appliances or distributed monitoring solutions. ## **Designed for Embedded and Distributed Deployments** FastNetMon can be deployed on-premise or in cloud environments. In scenarios where traditional server deployments are not practical — such as limited rack space, lack of spare servers, or remote locations with constrained resources — FastNetMon can run on embedded and compact computing platforms. Typical deployment targets include industrial computers, single-board computers (SBCs), and other embeddable systems used for network monitoring and security workloads. ## **ARM64 Support for Flow-Based DDoS Detection** FastNetMon provides full support for ARM64 (AArch64) architectures and is optimised for flow-based traffic processing. This makes it particularly well suited for handling NetFlow, IPFIX, and sFlow data without requiring high-end hardware. ARM64 platforms are strongly recommended when FastNetMon is used purely for flow-based monitoring and DDoS detection, as they offer an efficient balance of performance, power consumption, and cost. FastNetMon has been tested on a variety of ARM64 platforms running Linux, including common SBCs and embedded systems using Ubuntu or compatible distributions. ## **Cloud and Virtual Embedded Use Cases** FastNetMon can also be deployed on cloud platforms that offer ARM64 instances. For example, in AWS environments, FastNetMon can run on ARM-based instances using Graviton processors, enabling cost-efficient and scalable DDoS detection in virtualised and hybrid architectures. This approach is commonly used when FastNetMon is embedded as a detection component alongside other cloud-native network services. ## **Port Mirroring Considerations** FastNetMon supports traffic ingestion via port mirroring (SPAN), but this method requires significantly more computing resources compared to flow-based protocols. When using port mirroring in embedded scenarios, higher-performance hardware is typically required. For embedded and low-resource deployments, flow-based telemetry remains the recommended approach. ## **Tested Platforms and Installation** FastNetMon has been tested on multiple embedded and SBC platforms, including systems based on ROCK Pi, ESPRESSObin, and similar ARM64 hardware. Installation follows the same standard FastNetMon installer process used on traditional servers, with no special builds required. As hardware ecosystems evolve, FastNetMon continues to evaluate and test new platforms to expand support for additional embedded use cases. ## **Start Building with FastNetMon** FastNetMon can be embedded into a wide range of DDoS detection architectures, from compact edge deployments to large-scale distributed systems.Start a [**free trial**](https://fastnetmon.com/trial) to test FastNetMon on your target platform, or [**contact our team** ](https://fastnetmon.com/contact/)to discuss embedded deployment scenarios, performance requirements, and integration options. --- ### [Payment Methods](https://fastnetmon.com/payment/) **Published:** July 19, 2017 **Author:** Pavel Odintsov **Content:** FastNetMon supports the following payment options: - **Credit card** — available for monthly or annual subscriptions (including American Express) - **PayPal** — available for monthly or annual subscriptions - **International bank transfer** to a UK bank account — available for annual subscriptions only - **Automated ACH payments** — available for customers in the United States If you require an alternative payment method, please contact our [customer care team](https://fastnetmon.com/contact/) to discuss available options. --- ### [FastNetMon for Google Cloud](https://fastnetmon.com/google-cloud-network/) **Published:** April 12, 2021 **Author:** FastNetMon **Content:** FastNetMon extends real-time network visibility and analytics into Google Cloud environments by leveraging native **VPC Flow Logs**. It enables operators to monitor traffic patterns, identify anomalies and support network security decisions within Google Cloud workloads. ## **What It Does** FastNetMon ingests **VPC Flow Logs** exported from Google Cloud into a processing pipeline where traffic telemetry is transformed and analysed. This gives you insight into: - Traffic entering and leaving Google Cloud resources - Top talkers and high-traffic paths - Anomalous usage patterns indicative of performance issues or attacks - Distribution of traffic by source, destination, subnet and region To feed Flow Logs into FastNetMon, you export them from Google Cloud to Pub/Sub and use a lightweight processor to convert them into FastNetMon’s analysis format. ## **How It Works** 1. **Enable VPC Flow Logs** for your VPC networks/subnets in the Google Cloud Console or via API/CLI. These logs capture sampled network flows across your cloud infrastructure. 2. **Export flow logs** to **Cloud Pub/Sub**, where a FastNetMon component reads them in real time. 3. A **flow log processor** converts the logs into a format FastNetMon can analyse, feeding them into the FastNetMon engine for metrics and detection. 4. FastNetMon’s dashboards and alerts surface insights and anomalies for network monitoring and operational decision-making. This approach decouples collection from analysis, allowing you to scale and centralise network monitoring across regions and projects. ## **Key Benefits** - **Cloud-native visibility:** Uses Google Cloud’s native VPC Flow Logs for accurate telemetry across VPCs, subnets and instances. - **Real-time analysis:** Continuous log ingestion supports near-real-time understanding of network traffic trends and anomalies. - **Integrated with existing pipelines:** Works with Pub/Sub and standard Google Cloud logging exports to fit into your existing observability workflows. - **Actionable insights:** Helps identify overloaded resources, unexpected traffic patterns, and lenses into traffic distribution (e.g., by region or autonomous system). ## **Deployment Options** FastNetMon in Google Cloud can be deployed to suit your architecture: - **Centralised instance** that processes flow logs from all regions - **Per-region instances** for distributed analysis - **Hybrid topology** combining central and regional visibility for both local and global insights ## **Ideal Use Cases** FastNetMon’s Google Cloud integration is suitable for: - Network operations teams seeking enhanced visibility into VPC traffic - Security teams tracking anomalous or suspicious network behaviour - Engineering teams diagnosing performance or over-utilisation conditions - Hybrid environments where cloud and on-premise traffic visibility needs to be unified ## **Get Started** FastNetMon is ideal for telcos, ISPs, cloud providers and enterprise networks seeking **fast, automated, network-level DDoS defence** with wide vendor support and integration into existing infrastructure. [Start a free trial](https://fastnetmon.com/trial/) or [contact us ](https://fastnetmon.com/contact/)for more information. --- ### [Resources](https://fastnetmon.com/resources/) **Published:** August 25, 2016 **Author:** FastNetMon **Content:** Explore FastNetMon through insights from our team and real-world experiences from our customers. Here you’ll find practical guidance, recommendations, and examples of how FastNetMon is used in production environments. Choose the format that works best for you — videos, podcasts, presentations, or written articles. ![](https://fastnetmon.com/wp-content/uploads/2026/01/video-icon.png) ## Video Watch recordings from conferences, talks, and industry events featuring the FastNetMon team. [LEARN MORE](https://fastnetmon.com/video/) ![](https://fastnetmon.com/wp-content/uploads/2026/01/podcast-icon-2.png) ## Podcasts Listen to podcast episodes where we discuss FastNetMon, DDoS defence, and our journey. [LEARN MORE](https://fastnetmon.com/podcast/) ![](https://fastnetmon.com/wp-content/uploads/2026/01/presentations-icon.png) ## Presentations View presentations explaining how FastNetMon helps protect networks from DDoS attacks. [LEARN MORE](https://fastnetmon.com/presentation/) ![](https://fastnetmon.com/wp-content/uploads/2026/01/stories-icon.png) ## Customer stories Read real-world examples of how organisations use FastNetMon in production networks. [LEARN MORE](https://fastnetmon.com/publications/) --- ### [FastNetMon Advanced integration with GCore Global DDoS protection scrubbing centre](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-integration-with-gcore-global-ddos-protection-scrubbing-centre/) **Published:** August 6, 2025 **Author:** Pavel Odintsov **Content:** FastNetMon Advanced offers a complete, production-ready integration with [GCore Global DDoS](https://gcore.com/ddos-protection) protection service. Please check that your version of FastNetMon is 2.0.373 or newer. To use this capability, please create an API access key in your portal this way: ![](https://fastnetmon.com/wp-content/uploads/2025/08/API-Key-generation-1024x393.png)### How FastNetMon scrubbing centre diversion work? When FastNetMon detects an attack against an IP address, it determines /24 prefix for IP which is under attack and then announces it to the scrubbing centre. When a ban time expires, FastNetMon removes the announce from the scrubbing centre using their API. Then use fcli to specify API key: ``` sudo fcli set plugin scrubbing_services_integration provider_name gcore sudo fcli set plugin scrubbing_services_integration gcore_api_token very-secure-code sudo fcli set plugin scrubbing_services_integration log_path /var/log/fastnetmon/fastnetmon_scrubbing_services_integration.log ``` And enable callback logic on FastNetMon: ``` sudo fcli set main notify_script_enabled enable sudo fcli set main notify_script_format json sudo fcli set main notify_script_path /opt/fastnetmon/libraries/scrubbing_services_integration_plugin/scrubbing_services_integration sudo fcli commit ``` After this, we recommend manually blocking some IP addresses from the test prefix and checking that it works as expected. You can do it in the following way: ``` sudo fcli set blackhole 1.2.3.4 ``` To unblock, list all blocked hosts with their UUIDs: ``` sudo fcli show blackhole ``` And unblock: ``` sudo fcli delete blackhole ``` Integration logic has very detailed logging, and you can find the log file here: /var/log/fastnetmon/fastnetmon\_scrubbing\_services\_integration.log --- ### [FastNetMon Community and ExaBGP without socat](https://fastnetmon.com/docs/fastnetmon-community-and-exabgp-without-socat/) **Published:** December 10, 2017 **Author:** FastNetMon **Content:** With this guide, you can integrate ExaBGP and FastNetMon without the socat tool Create example configuration: vim /etc/exabgp\_blackhole.conf Example here (please fix this configuration to your network): ``` group Core_v4 { hold-time 180; local-as 65001; peer-as 1234; router-id 10.0.3.114; graceful-restart 1200; # Static announce is not used # static { # route 10.10.10.1/32 next-hop 10.0.3.114 community 65001:666; # } neighbor 10.0.3.115 { local-address 10.0.3.114; description "Quagga"; } # Add this line for process management process service-dynamic { run /etc/exabgp/exabgp_pipe_provider.sh; } } ``` For PIPE API, create this script: vim /etc/exabgp/exabgp\_pipe\_provider.sh Script code: ``` #!/bin/sh FIFO="/var/run/exabgp.cmd" rm -f $FIFO mkfifo $FIFO tail -f $FIFO ``` Set exec flag for script: ``` chmod +x /etc/exabgp/exabgp_pipe_provider.sh ``` Run ExaBGP: ``` env exabgp.daemon.user=root exabgp.daemon.daemonize=true exabgp.daemon.pid=/var/run/exabgp.pid exabgp.log.destination=/var/log/exabgp.log exabgp /etc/exabgp_blackhole.conf ``` --- ### [FastNetMon community CLI and API](https://fastnetmon.com/docs/fastnetmon-community-api/) **Published:** December 9, 2017 **Author:** FastNetMon **Content:** The current version of FastNetMon Community includes a basic command-line interface and gRPC-based API. If you're looking for a comprehensive API, we recommend our commercial edition FastNetMon Advanced, which includes [REST based HTTP API](https://fastnetmon.com/docs-fnm-advanced/advanced-api/) for all operations. Enable API in configuration file /etc/fastnetmon.conf: ``` enable_api = on ``` You could ban IP in the following way: ``` /opt/fastnetmon/fastnetmon_api_client ban 192.168.1.1 ``` You could unban IP in the following: ``` /opt/fastnetmon/fastnetmon_api_client unban 192.168.1.1 ``` You can check for a list of blocked hosts in the following way: ``` /opt/fastnetmon/fastnetmon_api_client get_banlist ``` Sample output: ``` 192.168.1.1/32 ``` --- ### [FastNetMon Community edition Privacy Notice](https://fastnetmon.com/fastnetmon-community-edition-privacy-notice/) **Published:** August 8, 2023 **Author:** FastNetMon **Content:** [fastnetmon-community-edition-privacy-notice-10-aug-2023](https://fastnetmon.com/wp-content/uploads/2025/12/fastnetmon-community-edition-privacy-notice-10-aug-2023.pdf)[Download](https://fastnetmon.com/wp-content/uploads/2025/12/fastnetmon-community-edition-privacy-notice-10-aug-2023.pdf) --- ### [Controlling ExaBGP from external tool](https://fastnetmon.com/docs/how-to-control-exabgp-from-external-tool/) **Published:** March 27, 2018 **Author:** FastNetMon **Content:** Set up ExaBGP and Quagga before proceeding with this guide, using [this](https://fastnetmon.com/quagga-bgp-and-exabgp/) manual. Here, we are creating a fabricated process which works as a proxy for relying on data from Linux PIPE to ExaBGP: ``` vim /etc/exabgp/exabgp_pipe_provider.sh ``` With this content: ``` #!/bin/sh FIFO="/var/run/exabgp.cmd" #trap "rm -f $FIFO" SIGINT rm -f $FIFO mkfifo $FIFO tail -f $FIFO ``` Setting exec flag: ``` chmod +x /etc/exabgp/exabgp_pipe_provider.sh ``` And adding the following (process service-dynamic ....) to ExaBGP config: /etc/exabgp\_blackhole.conf ``` group Core_v4 { hold-time 180; local-as 65001; peer-as 1234; router-id 10.0.3.114; graceful-restart 1200; static { route 10.10.10.1/32 next-hop 10.0.3.114 community 65001:666; } neighbor 10.0.3.115 { local-address 10.0.3.114; description "Quagga"; } # Add this line for process management process service-dynamic { run /etc/exabgp/exabgp_pipe_provider.sh; } } ``` At this point, we run ExaBGP. Now, we can see multiple processes in the process list: ``` ps aux|grep exa root 36854 0.0 0.0 52764 14604 ? S 11:47 0:00 /usr/bin/python /usr/local/bin/exabgp /etc/exabgp_blackhole.conf root 36855 0.0 0.0 4328 868 ? S 11:47 0:00 /bin/sh /etc/exabgp/exabgp_pipe_provider.sh root 36858 0.0 0.0 5800 1324 ? S 11:47 0:00 tail -f /var/run/exabgp.cmd ``` We are ready to add the announce: ``` echo "announce route 10.10.10.123/32 next-hop 10.0.3.114 community 65001:666" > /var/run/exabgp.cmd ``` If you want to disable it, you can use this syntax: ``` echo "withdraw route 10.10.10.123/32" > /var/run/exabgp.cmd ``` After the route announce, we can see on Quagga a new prefix: ``` *> 10.10.10.123/32 10.0.3.114 0 65001 i ``` --- ### [Graphite integration](https://fastnetmon.com/docs/graphite_integration/) **Published:** August 17, 2016 **Author:** FastNetMon **Content:** Example screen: [![graphite](https://fastnetmon.com/wp-content/uploads/2016/08/fastnetmon_graphite-1024x565.png)](https://fastnetmon.com/wp-content/uploads/2016/08/fastnetmon_graphite.png)We can store pps/bps/flow number for the top 7 hosts (configuration possible) in incoming and outgoing directions. Additionally, we export the total pps/bps/flow number which flows over FastNetMon. Configuration from the FastNetMon side is very simple. Start by putting the following fields in/etc/fastnetmon.conf: ``` graphite = on graphite_host = 127.0.0.1 graphite_port = 2003 graphite_prefix = fastnetmon ``` ### Install Graphite on Debian or Ubuntu To start with, please install all packages: ``` sudo apt-get install -y python-whisper graphite-carbon ``` Whisper is a database for data. Graphite is a service for storing and retrieving data from a database. To install web frontend: ``` sudo apt-get install -y graphite-web ``` To create a database, specify login/password and email in the following way: ``` sudo graphite-manage syncdb ``` Specify your timezone in file /etc/graphite/local\_settings.py on line TIME\_ZONE. Change owner: ``` sudo chown _graphite:_graphite /var/lib/graphite/graphite.db ``` Run it with Apache: ``` sudo apt-get install -y libapache2-mod-wsgi apache2-mpm-prefork sudo cp /usr/share/graphite-web/apache2-graphite.conf /etc/apache2/sites-available/graphite-web.conf sudo a2dissite 000-default.conf sudo a2ensite graphite-web sudo a2enmod wsgi ``` Enable load on startup: ``` sudo systemctl enable apache2.service sudo systemctl restart apache2.service ``` Open site: [https://ip.ad.dr.es](https://ip.ad.dr.es/) Populate test data into Graphite: ``` echo "test.bash.stats 42 `date +%s`" | nc -q0 127.0.0.1 2003 ``` If you have the following issues with Carbon: ``` /etc/init.d/carbon-cache start * Starting Graphite backend daemon carbon-cache Traceback (most recent call last): File "/usr/bin/carbon-cache", line 32, in run_twistd_plugin(__file__) File "/usr/lib/python2.7/dist-packages/carbon/util.py", line 90, in run_twistd_plugin config.parseOptions(twistd_options) File "/usr/local/lib/python2.7/dist-packages/twisted/application/app.py", line 619, in parseOptions usage.Options.parseOptions(self, options) File "/usr/local/lib/python2.7/dist-packages/twisted/python/usage.py", line 270, in parseOptions raise UsageError("Unknown command: %s" % sub) twisted.python.usage.UsageError: Unknown command: carbon-cache ``` Please refer to this [resource.](https://stackoverflow.com/questions/27951317/install-graphite-statsd-getting-error-unknown-carbon-cache) Some useful graphics for Graphite. Total load: ``` fastnetmon.incoming.pps fastnetmon.outgoing.pps fastnetmon.incoming.mbps fastnetmon.outgoing.mbps ``` Top talkers: ``` highestMax(fastnetmon.hosts.*.outgoing.average.pps, 10) highestMax(fastnetmon.hosts.*.outgoing.average.mbps, 10) highestMax(fastnetmon.hosts.*.incoming.average.pps, 10) highestMax(fastnetmon.hosts.*.incoming.average.mbps, 10) ``` Also I recommend to configure Graphite this way. For big networks please enlarge number of created file in /etc/carbon/carbon.conf: ``` MAX_CREATES_PER_MINUTE = 5000 ``` And if you want to store data every 5 seconds for 1 month please do following *before* starting collection to Graphite in file /etc/carbon/storage-schemas.conf: ``` [default_5sec_for_1month] pattern = .* retentions = 5s:31d ``` --- ### [Redis backend support](https://fastnetmon.com/docs/redis/) **Published:** August 17, 2016 **Author:** FastNetMon **Content:** FastNetMon has native support for Redis. Please call `redid-cli` and input the following commands: ``` keys * 1) "10.10.10.200_flow_dump" 2) "10.10.10.200_information" 3) "10.10.10.200_packets_dump" ``` Basic information about the attack: ``` get 10.10.10.200_information ``` Complete flow dump for attack if flow tracking is enabled (stored immediately) ``` get 10.10.10.200_flow_dump ``` Complete per packet attack dump (stored with some delay; can be absent in some cases of slow attacks) ``` get 10.10.10.200_packets_dump ``` --- ### [FastNetMon Community GoBGP integration](https://fastnetmon.com/docs/gobgp-integration/) **Published:** August 26, 2016 **Author:** FastNetMon **Content:** FastNetMon features complete support for GoBGP for BGP announce and includes compatible GoBGP in our official packages. Note: For FastNetMon Advanced edition, please use [this guide](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-bgp-unicast-configuration/) instead. We have the following configuration options for GoBGP in /etc/fastnetmon.conf: ``` gobgp = on gobgp_next_hop = 1.2.3.4 gobgp_announce_host = on gobgp_announce_whole_subnet = off gobgp_community_host = 65001:666 gobgp_community_subnet = 65001:777 # Configuration for IPv6 announces gobgp_next_hop_ipv6 = 100::1 gobgp_next_hop_host_ipv6 = 100::1 gobgp_next_hop_subnet_ipv6 = 100::1 gobgp_announce_host_ipv6 = on # Not supported yet gobgp_announce_whole_subnet_ipv6 = off gobgp_community_host_ipv6 = 65001:666 gobgp_community_subnet_ipv6 = 65001:777 ``` To establish a BGP session with your network equipment, you need to create a configuration for GoBGP in /etc/gobgpd.conf file: ``` [global.config] as = 65001 router-id = "192.168.1.134" [[neighbors]] [neighbors.config] neighbor-address = "192.168.1.188" peer-as = 65001 [neighbors.ebgp-multihop.config] enabled = true [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv4-unicast" [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv6-unicast" [neighbors.transport.config] local-address = "192.168.1.134" ``` Run it: ``` sudo /opt/fastnetmon.community/libraries/gobgp_3_12_0/gobgpd -f /etc/gobgpd.conf ``` After that, you will see the following log message when the BGP session is established successfully: ``` {"Key":"192.168.1.188","State":"BGP_FSM_OPENCONFIRM","Topic":"Peer","level":"info","msg":"Peer Up","time":"2020-05-24T14:42:12+01:00"} ``` You may check neighbor's status the following way: ``` /opt/fastnetmon.community/libraries/gobgp_3_12_0/gobgp nei 192.168.1.188 ``` Example output: ``` BGP neighbor is 192.168.1.188, remote AS 65001 BGP version 4, remote router ID 192.168.1.188 BGP state = ESTABLISHED, up for 00:01:24 BGP OutQ = 0, Flops = 0 Hold time is 90, keepalive interval is 30 seconds Configured hold time is 90, keepalive interval is 30 seconds Neighbor capabilities: multiprotocol: ipv4-unicast: advertised and received ipv6-unicast: received route-refresh: advertised and received 4-octet-as: advertised and received Message statistics: Sent Rcvd Opens: 1 1 Notifications: 0 0 Updates: 0 0 Keepalives: 3 4 Route Refresh: 0 0 Discarded: 0 0 Total: 4 5 Route statistics: Advertised: 0 Received: 0 Accepted: 0 ``` Check announced routes: ``` /opt/fastnetmon.community/libraries/gobgp_3_12_0/gobgp global rib Network Next Hop AS_PATH Age Attrs *> 192.168.1.1/32 0.0.0.0 00:00:08 [{Origin: ?}] ``` Announce custom route: ``` /opt/fastnetmon.community/libraries/gobgp_3_12_0/gobgp global rib add 10.33.0.0/32 -a ipv4 ``` Withdraw route: ``` /opt/fastnetmon.community/libraries/gobgp_3_12_0/gobgp global rib del 10.33.0.0/32 -a ipv4 ``` To control BGP announces directly from FastNetMon, you may consider using the [command line](https://fastnetmon.com/docs/fastnetmon.community-api/) tool. --- ### [Quagga BGP and exabgp: work together for BGP blackhole implementation](https://fastnetmon.com/docs/quagga-bgp-and-exabgp/) **Published:** March 27, 2018 **Author:** FastNetMon **Content:** In this test case, we will deploy two machines: 10.0.3.114 for exabgp (it announces/32 prefix for blackholing on the core router side) and 10.0.3.115 (it emulates the core router). We will do this work on Debian 8 Jessie. Install exabgp: ``` pip install exabgp ``` Create ExaBGP configuration: ``` vim /etc/exabgp_blackhole.conf ``` Here you can find an example for exabgp configuration: ``` group Core_v4 { hold-time 180; local-as 65001; peer-as 1234; router-id 10.0.3.114; graceful-restart 1200; static { route 10.10.10.1/32 next-hop 10.0.3.114 community 65001:666; } neighbor 10.0.3.115 { local-address 10.0.3.114; description "Quagga"; } } ``` We specify the current machine IP as the next hop because without it, Quagga ignores it: 10.0.3.114 rcvd UPDATE about 10.10.10.1/32 -- DENIED due to: martian next-hop; Start exabgp: ``` env exabgp.daemon.user=root exabgp.daemon.daemonize=true exabgp.daemon.pid=/var/run/exabgp.pid exabgp.log.destination=/var/log/exabgp.log exabgp /etc/exabgp_blackhole.conf ``` We recommend opening the log file and looking at it: ``` tail -f /var/log/exabgp.log exabgp ``` Now we will install Quagga. Install package: ``` apt-get install -y quagga ``` Enable BGP daemon in Quagga: ``` vim /etc/quagga/daemons ``` And change the following lines: ``` zebra=yes bgpd=yes ``` Then you should create config files and fix permissions for them: ``` touch /etc/quagga/zebra.conf touch /etc/quagga/bgpd.conf touch /etc/quagga/quagga.conf chown quagga:quagga /etc/quagga/bgpd.conf chown quagga:quagga /etc/quagga/zebra.conf chown quagga:quagga /etc/quagga/quagga.conf ``` Create BGP configuration: ``` vi /etc/quagga/bgpd.conf ``` Example for configuration (please be aware! It's **not suitable** for production): ``` hostname SoftBGP password zebra987 enable password zebra987 log file /var/log/quagga/bgpd.log debug bgp events debug bgp filters debug bgp fsm debug bgp keepalives debug bgp updates router bgp 1234 bgp router-id 10.0.3.115 bgp log-neighbor-changes neighbor 10.0.3.114 remote-as 65001 ``` Apply configuration: ``` /etc/init.d/quagga restart ``` Success! We see this announce in Quagga: ``` /usr/bin/vtysh -d bgpd -c "show ip bgp summary" BGP router identifier 10.0.3.115, local AS number 1234 RIB entries 1, using 112 bytes of memory Peers 1, using 4568 bytes of memory Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 10.0.3.114 4 65001 12 18 0 0 0 00:01:12 1 Total number of neighbors 1 ``` Check announced subnets from exabgp: ``` /usr/bin/vtysh -d bgpd -c "show ip bgp" BGP table version is 0, local router ID is 10.0.3.115 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath, i internal, r RIB-failure, S Stale, R Removed Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 10.10.10.1/32 10.0.3.114 0 65001 i Total number of prefixes 1 ``` This guide was prepared from a more detailed and complex article: [https://www.m00nie.com/2014/01/bgp-rtbh-setup-using-exabgp/](https://www.m00nie.com/bgp-rtbh-setup-using-exabgp/) --- ### [Protocol names supported by FastNetMon Advanced](https://fastnetmon.com/docs-fnm-advanced/protocol-names-supported-by-fastnetmon-advanced/) **Published:** December 3, 2024 **Author:** Pavel Odintsov **Content:** In all systems where a protocol name is needed in FastNetMon Advanced, we use the following protocol names based on up-to-date IANA documentation: - hopopt 0 - icmp 1 - igmp 2 - ggp 3 - ipv4 4 - st 5 - tcp 6 - cbt 7 - egp 8 - igp 9 - bbn\_rcc\_mon 10 - nvp\_ii 11 - pup 12 - argus\_deprecated 13 - emcon 14 - xnet 15 - chaos 16 - udp 17 - mux 18 - dcn\_meas 19 - hmp 20 - prm 21 - xns\_idp 22 - trunk\_1 23 - trunk\_2 24 - leaf\_1 25 - leaf\_2 26 - rdp 27 - irtp 28 - iso\_tp4 29 - netblt 30 - mfe\_nsp 31 - merit\_inp 32 - dccp 33 - threepc 34 - idpr 35 - xtp 36 - ddp 37 - idpr\_cmtp 38 - tppppp 39 - il 40 - ipv6 41 - sdrp 42 - ipv6\_route 43 - ipv6\_frag 44 - idrp 45 - rsvp 46 - gre 47 - dsr 48 - bna 49 - esp 50 - ah 51 - i\_nlsp 52 - swipe\_deprecated 53 - narp 54 - mobile 55 - tlsp 56 - skip 57 - ipv6\_icmp 58 - ipv6\_nonxt 59 - ipv6\_opts 60 - unknown\_61 61 - cftp 62 - unknown\_63 63 - sat\_expak 64 - kryptolan 65 - rvd 66 - ippc 67 - unknown\_68 68 - sat\_mon 69 - visa 70 - ipcv 71 - cpnx 72 - cphb 73 - wsn 74 - pvp 75 - br\_sat\_mon 76 - sun\_nd 77 - wb\_mon 78 - wb\_expak 79 - iso\_ip 80 - vmtp 81 - secure\_vmtp 82 - vines 83 - iptm\_or\_ttp 84 - nsfnet\_igp 85 - dgp 86 - tcf 87 - eigrp 88 - ospfigp 89 - sprite\_rpc 90 - larp 91 - mtp 92 - ax\_25 93 - ipip 94 - micp\_deprecated 95 - scc\_sp 96 - etherip 97 - encap 98 - unknown\_99 99 - gmtp 100 - ifmp 101 - pnni 102 - pim 103 - aris 104 - scps 105 - qnx 106 - a\_n 107 - ipcomp 108 - snp 109 - compaq\_peer 110 - ipx\_in\_ip 111 - vrrp 112 - pgm 113 - unknown\_114 114 - l2tp 115 - ddx 116 - iatp 117 - stp 118 - srp 119 - uti 120 - smp 121 - sm\_deprecated 122 - ptp 123 - isisoveripv4 124 - fire 125 - crtp 126 - crudp 127 - sscopmce 128 - iplt 129 - sps 130 - pipe 131 - sctp 132 - fc 133 - rsvp\_e2e\_ignore 134 - mobilityheader 135 - udplite 136 - mpls\_in\_ip 137 - manet 138 - hip 139 - shim6 140 - wesp 141 - rohc 142 - ethernet 143 - unassigned\_144 144 - unassigned\_145 145 - unassigned\_146 146 - unassigned\_147 147 - unassigned\_148 148 - unassigned\_149 149 - unassigned\_150 150 - unassigned\_151 151 - unassigned\_152 152 - unassigned\_153 153 - unassigned\_154 154 - unassigned\_155 155 - unassigned\_156 156 - unassigned\_157 157 - unassigned\_158 158 - unassigned\_159 159 - unassigned\_160 160 - unassigned\_161 161 - unassigned\_162 162 - unassigned\_163 163 - unassigned\_164 164 - unassigned\_165 165 - unassigned\_166 166 - unassigned\_167 167 - unassigned\_168 168 - unassigned\_169 169 - unassigned\_170 170 - unassigned\_171 171 - unassigned\_172 172 - unassigned\_173 173 - unassigned\_174 174 - unassigned\_175 175 - unassigned\_176 176 - unassigned\_177 177 - unassigned\_178 178 - unassigned\_179 179 - unassigned\_180 180 - unassigned\_181 181 - unassigned\_182 182 - unassigned\_183 183 - unassigned\_184 184 - unassigned\_185 185 - unassigned\_186 186 - unassigned\_187 187 - unassigned\_188 188 - unassigned\_189 189 - unassigned\_190 190 - unassigned\_191 191 - unassigned\_192 192 - unassigned\_193 193 - unassigned\_194 194 - unassigned\_195 195 - unassigned\_196 196 - unassigned\_197 197 - unassigned\_198 198 - unassigned\_199 199 - unassigned\_200 200 - unassigned\_201 201 - unassigned\_202 202 - unassigned\_203 203 - unassigned\_204 204 - unassigned\_205 205 - unassigned\_206 206 - unassigned\_207 207 - unassigned\_208 208 - unassigned\_209 209 - unassigned\_210 210 - unassigned\_211 211 - unassigned\_212 212 - unassigned\_213 213 - unassigned\_214 214 - unassigned\_215 215 - unassigned\_216 216 - unassigned\_217 217 - unassigned\_218 218 - unassigned\_219 219 - unassigned\_220 220 - unassigned\_221 221 - unassigned\_222 222 - unassigned\_223 223 - unassigned\_224 224 - unassigned\_225 225 - unassigned\_226 226 - unassigned\_227 227 - unassigned\_228 228 - unassigned\_229 229 - unassigned\_230 230 - unassigned\_231 231 - unassigned\_232 232 - unassigned\_233 233 - unassigned\_234 234 - unassigned\_235 235 - unassigned\_236 236 - unassigned\_237 237 - unassigned\_238 238 - unassigned\_239 239 - unassigned\_240 240 - unassigned\_241 241 - unassigned\_242 242 - unassigned\_243 243 - unassigned\_244 244 - unassigned\_245 245 - unassigned\_246 246 - unassigned\_247 247 - unassigned\_248 248 - unassigned\_249 249 - unassigned\_250 250 - unassigned\_251 251 - unassigned\_252 252 - unknown\_253 253 - unknown\_254 254 - reserved 255 --- ### [sFlow v5 configuration on Arista](https://fastnetmon.com/docs-fnm-advanced/sflow-v5-configuration-on-arista/) **Published:** February 21, 2025 **Author:** Pavel Odintsov **Content:** To configure sFlow v5 on the Arista platform, we recommend usingthe following guide: ``` show run section sflow sflow sample 1024 sflow polling-interval 60 sflow destination 10.0.0.70 sflow source 10.0.0.10 sflow sample input subinterface sflow sample output subinterface sflow run ``` After this, you need to enable sFlow v5 monitoring for each interface: ``` interface Port-Channel10 sflow enable ``` If your hardware supports hardware sFlow v5 acceleration, we recommend enabling it. In case of need for more information, please check the official [guide](https://www.arista.com/en/um-eos/eos-sflow) --- ### [FastNetMon Advanced simple average traffic calculation mode](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-simple-average-traffic-calculation-mode/) **Published:** October 17, 2023 **Author:** Pavel Odintsov **Content:** By default, FastNetMon Advanced uses exponential moving average algorithm to calculate bandwidth. In some cases, when routers send traffic telemetry in bursts or a stream of telemetry is not even, it may not provide the best accuracy, and you may notice 20-30% deviation from real traffic. Usually, it happens only with Netflow / IPFIX-based protocols. The best option to address it is to move to sFlow or PSAMP-based protocols if they're supported by equipment, as these protocols provide way better bandwidth calculation accuracy. In this case, you may switch FastNetMon to simple average calculation mode this way: ``` sudo fcli set main speed_calculation_delay 45 sudo fcli set main average_calculation_time 1 sudo fcli commit ``` In this mode, FastNetMon does not use any complicated algorithms, which may be vulnerable to anomalies in telemetry export logic to calculate bandwidth and just calculates traffic every speed\_calculation\_delay seconds. Unfortunately, attack detection will be delayed by the value set in speed\_calculation\_delay. For Netflow / IPFIX-based algorithms, speed\_calculation\_delay should exceed both active and inactive flow timeouts. All dashboards and traffic calculation metrics from fcli and API will be re-calculated once per speed\_calculation\_delay seconds. --- ### [Requirements for integration with cloud-based DDoS scrubbing centers](https://fastnetmon.com/docs-fnm-advanced/requirements-for-integration-with-new-cloud-based-ddos-scrubbing-centers/) **Published:** February 27, 2024 **Author:** Pavel Odintsov **Content:** FastNetMon has solid integrations with multiple [leading DDoS mitigation](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-and-ddos-scrubbing-centers-integration/) cloud providers, and we are constantly working to add more providers. Our preferred integration method is API based integration where FastNetMon connects to the scrubbing centre API endpoint to announce/withdraw prefix under attack. API based integration eliminates the need to make adjustments to BGP policy configuration on routers and, in general, is more reliable as it does not rely on a persistent connection such as BGP, which may be easily disrupted during an attack. We're open to using BGP-based integration as well, but in this case, we will need detailed documentation about all aspects of BGP setup and [FastNetMon BGP Diversion](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-and-bgp-traffic-diversion/) configuration. To integrate FastNetMon with your scrubbing centre, we need the following API endpoints: - To start announcing IPv4 / IPv6 prefixes over cloud cloud-based scrubbing centre - To withdraw announces for IPv4 / IPv6 prefix via the cloud-based scrubbing centre Optionally, we will be happy to get some API endpoint which returns the amount of clean / filtered traffic for the prefix during the time when the attack is still going. We need it to provide more information about attack performance to customers and do prefix withdrawal when the attack is actually finished instead of doing withdrawal by timeout, which has the risk of disabling protection when the attack is still going. To implement the integration, we will need to have an API specification from your company. Ideally, if you can allocate a test sandbox account which we can use for integration. To start the integration process, please contact us at <support@fastnetmon.com>, and we will be happy to discuss details. --- ### [Podcast](https://fastnetmon.com/podcast/) **Published:** March 31, 2022 **Author:** FastNetMon **Content:** Welcome to the FastNetMon Podcast Hub. Here, you'll find a range of podcasts featuring discussions on DDoS detection, network security, and the latest in cybersecurity. Listen to experts and industry professionals share their insights and experiences, providing practical advice on protecting your network from new threats. Whether you are experienced in the field or just starting out, these podcasts offer valuable information to help you stay informed. We are always happy to participate in a new podcasts! If you are a creator and interested in collaborating, please contact sales@fastnetmon.com, we would be happy to record something together. [![](https://fastnetmon.com/wp-content/uploads/2025/03/Play-now-The-Hedge-Podcast-with-FastNetMon-1024x574.png)](https://www.youtube.com/watch?v=zlGh_XaI1Lc)###### The Hedge Podcast e.10 FastNetMon CTO Pavel Odintson joins Russ White to discuss FastNetMon for DDoS detection [![](https://fastnetmon.com/wp-content/uploads/2025/03/Play-now-packetpushers-with-FastNetMon-1024x574.png)](https://www.youtube.com/watch?v=5vmmNwQURKc)###### Packet Pushers Podcast e.375 Our CTO Pavel Odintsov visits the Packet Pushers podcast to discuss the open-source version of our DDoS detection product. [![](https://fastnetmon.com/wp-content/uploads/2025/03/Play-Now-The-Hedge-Podcast-FastNetMon-Usecases-1024x576.png)](https://www.youtube.com/watch?v=LhnezZkuHVg)###### The Hedge Podcast e.16 Pavel Odintsov, CTO of FastNetMon joins Russ White and Tom Ammon to talk about the multiple use cases of FastNetMon’s tools. [![](https://fastnetmon.com/wp-content/uploads/2025/03/Play-now-Route-to-Networking-Episode-50-1024x576.png)](https://www.youtube.com/watch?v=lryg9EeMZnQ)###### Route to Networking Podcast e.50 The episode features an in-depth discussion on all things DDoS, hosted by James Dean and joined by Pavel Odinstov. --- ### [FastNetMon LTD subprocessors and subcontractors](https://fastnetmon.com/fastnetmon-ltd-subprocessors-and-subcontractors/) **Published:** September 16, 2018 **Author:** FastNetMon **Content:** To provide best service for you we use number of external contractors. Advertisement platforms: - Google Adwords, <https://adwords.google.com/> - Twitter Ads, <https://ads.twitter.com/> - LinkedIn Advertising, <https://business.linkedin.com/marketing-solutions/ads> Web site analytic: - Google Analytics, Google LLC , 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA, <https://google.com> Email delivery: - SendGrid, Inc, <https://sendgrid.com/> Hosting providers: - DigitalOcean LLC, <https://www.digitalocean.com/> Support system: - Zendesk Inc, <https://www.zendesk.com/> Site performance: - Cloudflare Inc, <https://www.cloudflare.com/> - Fastly Inc, <https://fastly.com> Payment processing systems: - GoCardless Ltd., Sutton Yard, 65 Goswell Road, London, EC1V 7EN, United Kingdom <https://gocardless.com/> - PayPal Inc, <https://www.paypal.com/> - Stripe Inc, <https://stripe.com/> - Chargebee Inc, <https://www.chargebee.com/company/> Accounting software: - Intuit Inc, Registered in England No. 2679414, <https://quickbooks.intuit.com/uk/> - Dext, Unit 1.2 Techspace Shoreditch, 25 Luke Street, London, EC2A 4DS, [https://dext.com](https://dext.com "https://dext.com") --- ### [Huawei router configuration with FastNetMon Advanced](https://fastnetmon.com/docs-fnm-advanced/huawei-routers-configuration-with-fastnetmon-advanced/) **Published:** April 27, 2018 **Author:** Pavel Odintsov **Content:** This guide describes the required configuration steps for Huawei routers (tested with NE40) In this guide, we use a sampling rate of 1:1000, and it works as expected for bandwidth starting from 1G. To enable Netstream for the IPv4 protocol, you need to apply the following global configuration options: ``` ip netstream timeout active interval-second 15 ip netstream timeout inactive 15 ip netstream export version 9 ip netstream as-mode 32 ip netstream tcp-flag enable ip netstream export template timeout-rate 1 ip netstream export template option timeout-rate 1 ip netstream export source YOUR_ROUTER_IP ip netstream export host FASTNETMON_IP 2055 ip netstream export template option sampler ip netstream inbound ip netstream outbound ip netstream sampler fix-packets 1000 inbound ip netstream sampler fix-packets 1000 outbound ``` To enable Netstream for the IPv6 protocol, apply the same commands, but instead of using "ip netstream", use "ipv6 netstream". To apply the following commands, you will need to know the number of slots for the line card. You can list all available line cards and get their slot IDs in the following way: ``` display device ``` Example output: ``` display device S6730-H24X6C's Device status: Slot Sub Type Online Power Register Status Role -------------------------------------------------------------------------------------- 0 - S6730-H24X6C Present PowerOn Registered Normal Master PWR1 POWER Present PowerOn Registered Normal NA PWR2 POWER Present PowerOn Registered Normal NA FAN1 FAN Present PowerOn Registered Normal NA FAN2 FAN Present PowerOn Registered Normal NA FAN3 FAN Present PowerOn Registered Normal NA FAN4 FAN Present PowerOn Registered Normal NA ``` Enable Netstream IPv4 for each available slot: ``` slot ip netstream sampler to slot self ``` To enable Netsteram for IPv6, apply the following command: ``` ipv6 netstream sampler to slot self ``` Or, you can enable Netstream on an interface basis for inbound: ``` interface ip netstream inbound ``` And outbound: ``` interface ip netstream outbound ``` To enable Netstream for IPv6 protocol in both directions on a specific interface, apply the following commands: ``` interface ipv6 netstream outbound ipv6 netstream inbound ``` Check Netstream export statistics: ``` display ip netstream statistics slot ``` Example output: ``` ===== Netstream statistics: ===== Origin/Flexible ingress entries : 12345 Origin/Flexible ingress packets : 12345 Origin/Flexible ingress octets : 12345 Origin/Flexible egress entries : 12345 Origin/Flexible egress packets : 12345 Origin/Flexible egress octets : 12345 Origin/Flexible total entries : 100 Handle origin entries : 800000 Handle As aggre entries : 0 Handle ProtPort aggre entries : 0 Handle SrcPrefix aggre entries : 0 Handle DstPrefix aggre entries : 0 Handle Prefix aggre entries : 0 Handle AsTos aggre entries : 0 Handle ProtPortTos aggre entries : 0 Handle SrcPreTos aggre entries : 0 Handle DstPreTos aggre entries : 0 Handle PreTos aggre entries : 0 ``` On FastNetMon's side, you may specify the sampling rate if needed using [this guide](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-netflow-and-ipfix-sampling-configuration/): ``` sudo fcli set main netflow_sampling_ratio 1000 sudo fcli commit ``` And specify the [average calculation time](https://fastnetmon.com/docs-fnm-advanced/what-is-average_calculation_time/) value: ``` sudo fcli set main average_calculation_time 30 sudo fcli commit ``` **Document Categories:** Netflow and IPFIX --- ### [What is average_calculation_time?](https://fastnetmon.com/docs-fnm-advanced/what-is-average_calculation_time/) **Published:** June 21, 2023 **Author:** Pavel Odintsov **Content:** Concept of average\_calculation\_time is exceptionally important in FastNetMon as correct bandwidth calculation relies on correct setting of this value. Internally, FastNetMon uses algorithm called exponential [moving average](https://en.wikipedia.org/wiki/Moving_average) to approximate speed. This algorithm allows us to react on new traffic information way faster in compare with simple average which can provide traffic speed only after getting all the data over period. With exponential moving average we review all new traffic information every second and re-calculate speed according to this data. This approach allows us to detect DDoS attacks way faster. The simplest way to explain meaning of this value as time duration over which FastNetMon collects traffic data before calculating speed. For example you use Netflow or IPFIX protocol and your router has active and inactive flow timeouts set to 30 seconds. Such flow timeouts mean that all information about traffic observed by router right now will reach FastNetMon with delay ranging between 0 and 30 seconds. Network telemetry data may arrive in single burst (i.e. one large flow occupying all the bandwidth) or as multiple smaller flows distributed over time period of 30 seconds. The naive approach to calculate bandwidth is to wait 30 seconds and then divide amount of transferred data by 30 seconds and as result we will receive smoothed / approximated bandwidth. That's exactly why correct keeping of average\_calculation\_time value in sync with active and inactive flow timeout on router is paramount for getting accurate traffic bandwidth. By default, average\_calculation\_time set to 5 seconds which may work fine for sFlow, port mirror protocols only. If you use Netflow or IPFIX you have to adjust this value to match your active and inactive flow timeouts set on router. We recommend setting average\_calculation\_time slightly little bit bigger then active and inactive flow timeout on router. Such protocols as sFlow or port mirror do not have any aggregation delay as network devices export traffic information without any significant delay and in this case you may even set average\_calculation\_time to 1. What will happen in case of average\_calculation\_time misconfiguration? You will see bandwidth which is way bigger than actual traffic in your network or way smaller then your actual traffic and bandwidth metrics will be very spiky. As consequence DDoS detection will not work as you expect and real attacks may be missed and you will definitely have false positive alerts. Misconfiguration of average\_calculation\_time is one of the main root causes of bandwidth miscalculation and it's very important to understand how it work to efficiently operate FastNetMon. If you experience traffic calculation bandwidth issues and all configuration options are correct please check this [guide](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-simple-average-traffic-calculation-mode/). **Document Categories:** Netflow and IPFIX --- ### [Automatic baseline calculation for FastNetMon](https://fastnetmon.com/docs-fnm-advanced/automatic-baseline-calculation-for-fastnetmon/) **Published:** September 3, 2018 **Author:** Pavel Odintsov **Content:** Important note: Before beginning this guide, we recommend trying our [new baseline ](https://fastnetmon.com/docs-fnm-advanced/automated-baseline-calculation-with-fastnetmon-advanced/)recommendation logic, as it offers better integration with FastNetMon. This tool is an experimental feature; please do not use it without rigorous testing. You can download the current version [here](https://github.com/FastNetMon/baseline_magician/releases) Known restrictions: - Removes all existing non-global host groups - IPv4 only - Does not reload FastNetMon automatically Dependencies: - Metric (per host bandwidth) [export to Clickhouse](https://fastnetmon.com/docs-fnm-advanced/traffic-metrics-in-clickhouse/) - API access to FastNetMon, and you need to [enable API](https://fastnetmon.com/advanced-api/) The threshold calculation tool has the following configuration file at /etc/fastnetmon/baseline\_magician.conf: ``` { "clickhouse_host": "127.0.0.1", "clickhouse_port": 9000, "calculaton_period": 604800, "clickhouse_database": "fastnetmon", "clickhouse_table": "host_metrics", "api_user": "admin", "api_password": "XXX", "api_host": "127.0.0.1", "api_port": 10007, "generate_incoming_packet_threshold": true, "incoming_packet_expression": "value * 2", "generate_incoming_bit_threshold": true, "incoming_bit_expression": "value * 3", "generate_incoming_flow_threshold": true, "incoming_flow_expression": "value + 200", "remove_existing_hostgroups": true, "aggregation_function": "max" } ``` All fields with expression suffix keep math expressions to calculate threshold/baseline value from aggregated value (using aggregation\_function) of particular threshold from Clickhouse (calculated over the last 7 days). Run it the following way: ``` sudo chmod +x baseline_magician sudo ./baseline_magician ``` This tool can create a host group for each of your networks according to thresholds configured according to average bandwidth usage from Clickhouse. Note: This tool removes all your existing host groups and keeps only the global host group. Proceed with care. It does not restart FastNetMon to apply changes. You need to restart manually. In case of any issues, please report to our support team. This tool is open source, and you can find [the source code here](https://github.com/FastNetMon/baseline_magician). **Document Categories:** Maintenance operations --- ### [FastNetMon Advanced per host threshold configuration](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-per-host-threshold-configuration/) **Published:** April 7, 2023 **Author:** Pavel Odintsov **Content:** FastNetMon is a baseline / threshold based DDoS detection engine and it means that you need to set level of traffic which will be considered as attack by FastNetMon. By default, FastNetMon has global hostgroup which keeps thresholds for all hosts in your network. To set level of traffic which FastNetMon will consider as an attack we need to make some configuration adjustments. As example we will trigger attack detection for hosts which are receiving more than 100 Mbps of incoming traffic: ``` sudo fcli set hostgroup global threshold_mbps 100 sudo fcli set hostgroup global ban_for_bandwidth enable sudo fcli commit ``` Then we need to enable attack detection action for all hosts in our network this way: ``` sudo fcli set hostgroup global enable_ban enable sudo fcli commit ``` After that we need to specify that we need attack detection only in incoming direction as DDoS is mostly coming from the outside. ``` sudo fcli set hostgroup global enable_ban_incoming enable sudo fcli commit ``` If you would like to configure attack detection in outgoing direction you will need to apply following commands: ``` sudo fcli set hostgroup global enable_ban_outgoing enable sudo fcli set main per_direction_hostgroup_thresholds enable sudo fcli set main do_not_ban_outgoing disable sudo fcli commit ``` And then set thresholds in outgoing direction too: ``` sudo fcli set hostgroup global threshold_mbps_outgoing 100 sudo fcli set hostgroup global ban_for_bandwidth_outgoing enable sudo fcli commit ``` FastNetMon has multiple pre-defined thresholds types and you can find all of them on this [page](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-threshold-types/). You can enable multiple thresholds in same time. In addition to pre-defined thresholds you can create completely custom thresholds using arbitrary information about traffic from Layers 3 and 4 of OSI model using [flexible thresholds](https://fastnetmon.com/docs-fnm-advanced/flexible-thresholds/) capability. For networks with multiple types of client's traffic profiles you may prefer to set different thresholds for different groups of your networks. We call these per network thresholds configurations hostgroups and you may create any number of them using this [guide](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-advanced-per-host-hostgroups/). To help you with threshold configuration we have [tool](https://fastnetmon.com/docs-fnm-advanced/automated-baseline-calculation-with-fastnetmon-advanced/) which can proving baseline recommendations using your historical traffic data. **Document Categories:** Mitigation modes --- ### [FastNetMon Advanced threshold types](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-threshold-types/) **Published:** April 2, 2019 **Author:** Pavel Odintsov **Content:** To achieve better DDoS detection, FastNetMon offers a number of predefined threshold types. For each entity (host or group of hosts) in your network, FastNetMon maintains a set of counters for different traffic types. FastNetMon calculates all counter types for incoming and outgoing traffic. Global counters: - Packets per second - Mbits per second - Flow per second (not available for sampled Netflow/IPFIX and sFlow) Per protocol packet counters: - TCP packets per second - UDP packets per second - ICMP packets per second - TCP SYN packets per second Per protocol bandwidth counters: - TCP mbits per second - TCP SYN Mbits per second - UDP Mbits per second - ICMP Mbits per second You may set thresholds for incoming and outgoing traffic independently. Learn more about it in this [guide.](https://fastnetmon.com/docs-fnm-advanced/per-direction-hostgroup-thresholds/) Please note that TCP SYN counters count all packets/flows with the SYN flag set. I.e. it will be incremented in cases even when other flags are set as well (like SYN+ACK or SYN+ACK+PSH). Please note that versions before 2.0.342 did not count ICMPv6 traffic for the ICMP threshold. You can use any of these counters to trigger a DDoS alert. In the table below, you can find an option to enable a particular threshold and field name for setting the threshold itself. | Option to enable | Threshold value name | |---|---| | ban\_for\_pps | threshold\_pps | | ban\_for\_bandwidth | threshold\_mbps | | ban\_for\_flows | threshold\_flows | | ban\_for\_tcp\_pps | threshold\_tcp\_pps | | ban\_for\_udp\_pps | threshold\_udp\_pps | | ban\_for\_icmp\_pps | threshold\_icmp\_pps | | ban\_for\_tcp\_bandwidth | threshold\_tcp\_mbps | | ban\_for\_udp\_bandwidth | threshold\_udp\_mbps | | ban\_for\_icmp\_bandwidth | threshold\_icmp\_mbps | | ban\_for\_tcp\_syn\_pps | threshold\_tcp\_syn\_pps | | ban\_for\_tcp\_syn\_bandwidth | threshold\_tcp\_syn\_mbps | In addition to thresholds for incoming traffic, FastNetMon offers the option to set independent thresholds for outgoing traffic: | Option to enable | Threshold value name | |---|---| | ban\_for\_pps\_outgoing | threshold\_pps\_outgoing | | ban\_for\_bandwidth\_outgoing | threshold\_mbps\_outgoing | | ban\_for\_flows\_outgoing | threshold\_flows\_outgoing | | ban\_for\_tcp\_pps\_outgoing | threshold\_tcp\_pps\_outgoing | | ban\_for\_udp\_pps\_outgoing | threshold\_udp\_pps\_outgoing | | ban\_for\_icmp\_pps\_outgoing | threshold\_icmp\_pps\_outgoing | | ban\_for\_tcp\_bandwidth\_outgoing | threshold\_tcp\_mbps\_outgoing | | ban\_for\_udp\_bandwidth\_outgoing | threshold\_udp\_mbps\_outgoing | | ban\_for\_icmp\_bandwidth\_outgoing | threshold\_icmp\_mbps\_outgoing | | ban\_for\_tcp\_syn\_pps\_outgoing | threshold\_tcp\_syn\_pps\_outgoing | | ban\_for\_tcp\_syn\_bandwidth\_outgoing | threshold\_tcp\_syn\_mbps\_outgoing | FastNetMon evaluates all enabled thresholds using the logical operator OR. If any of the enabled threshold triggers are met, FastNetMon declares it as an attack. To set a threshold for a hostgroup, you can use the following syntax: ``` sudo fcli set hostgroup [hostgroup name] [option name] true sudo fcli set hostgroup [hostgroup name] [threshold name] 1000 ``` For example, to enable a limit by UDP packets per second, you can use: ``` sudo fcli set hostgroup global ban_for_udp_pps true sudo fcli set hostgroup global threshold_udp_pps 1000 sudo fcli commit ``` If you're looking for more flexible thresholds, please refer to [this guide](https://fastnetmon.com/docs-fnm-advanced/flexible-thresholds/). **Document Categories:** Mitigation modes --- ### [FastNetMon NetFlow v9 configuration for Cisco ASR 9000](https://fastnetmon.com/docs-fnm-advanced/fastnetmon-netflow-v9-configuration-for-cisco-asr-9000/) **Published:** January 24, 2019 **Author:** Pavel Odintsov **Content:** Cisco ASR 9000 series routers have solid support for NetFlow and can generate NetFlow for a large amount of traffic without any issues. But considering the amount of available port capacity on these routers, we suggest using sampling by default to avoid control plane CPU overload. We can suggest the following configuration from the ASR 9000 series of Cisco routers: ``` flow exporter-map FASTNETMON-EXPORTER version v9 options interface-table timeout 60 options sampler-table timeout 60 template timeout 60 template data timeout 60 template options timeout 60 ! transport udp 2055 source Loopback0 destination 10.0.0.1 ! flow monitor-map SECOND-MAP record ipv4 exporter FASTNETMON-EXPORTER cache entries 200000 cache timeout active 30 cache timeout inactive 30 ! sampler-map FIRST-SAMPLER random 1 out-of 1024 ``` If you prefer IPFIX, you can replace "v9" with "ipfix" in this configuration. Also, replace "10.0.0.1" in this configuration with the address of the machine where you have FastNetMon. Also, set the following option for all interfaces: ``` flow ipv4 monitor exporter-map sampler FIRST-SAMPLER ingress ``` FastNetMon can detect the sampling rate from routers automatically in almost all cases. You can check the detected sampling rate per router this way: ``` sudo fcli show netflow_sampling_rates ``` Sampling rate may be detected incorrectly when multiple samplers are configured on the routers. This is a technical restriction; please avoid this configuration. FastNetMon can detect the sampling rate correctly when you only have a single sampler. As an alternative, in case you need multiple samplers, set them to the same sampling rate. Also, you may check system counters to confirm that FastNetMon received and decoded sampling announcements from routers: ``` sudo fcli show system_counters |grep netflow9 |grep sampling netflow9_custom_sampling_rate_received 8688 netflow9_sampling_rate_changes 1 ``` If you see zero values, you should check that FastNetMon received options Netflow packets (they carry all meta information about Netflow exporters): ``` sudo fcli show system_counters |grep netflow9 |grep options netflow9_options_templates_number 844 netflow9_options_packet_number 1448 ``` As a fallback option, you can configure the sampling rate manually in FastNetMon in the following way: ``` sudo fcli set main netflow_sampling_ratio 1000 ``` For specified active and inactive timeouts, we recommend using the following [average calculation time](https://fastnetmon.com/docs-fnm-advanced/what-is-average_calculation_time/) values: ``` sudo fcli set main average_calculation_time 60 sudo fcli commit ``` If you notice an incorrect bandwidth calculation, we recommend using [visual traffic](https://fastnetmon.com/advanced-visual-traffic/) for debugging purposes. After this, please revise the dashboard "Netflow v9 metrics" from the default dashboard list. Occasionally, on high-traffic routers, we have observed that the router exports only a small amount of all flows, and FastNetMon sees very low traffic. This may be caused by an internal rate limit on the number of flows exported per second. You can increase it using the following command ([undocumented engineering](https://www.dnzydn.com/2018/07/27/asr9000-netflow-configuration-and-performance-issues/)): ``` cache timeout rate-limit 4096 ``` Use this command with caution. Increase the value incrementally; values up to 32,000 have been tested successfully. If you plan to use NetFlow with ASN information, you will need to enable the following option in the BGP section: ``` bgp attribute-download ``` **Document Categories:** Netflow and IPFIX --- ## Document Categories ### [Deployment](https://fastnetmon.com/doc_category/deployment/) --- ### [Introduction](https://fastnetmon.com/doc_category/introduction/) --- ### [Capture engines](https://fastnetmon.com/doc_category/capture-engines/) --- ### [Netflow and IPFIX](https://fastnetmon.com/doc_category/netflow-and-ipfix/) --- ### [sFlow v5](https://fastnetmon.com/doc_category/sflow-v5/) --- ### [Mitigation modes](https://fastnetmon.com/doc_category/mitigation-modes/) --- ### [BGP](https://fastnetmon.com/doc_category/bgp/) --- ### [Traffic reports](https://fastnetmon.com/doc_category/traffic-reports/) --- ### [Attack actions](https://fastnetmon.com/doc_category/attack-actions/) --- ### [Developer guides](https://fastnetmon.com/doc_category/developer-guides/) --- ### [Maintenance operations](https://fastnetmon.com/doc_category/maintenance-operations/) --- ### [Inline filtering](https://fastnetmon.com/doc_category/inline/) ---