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
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.