Hi, does anyone know how to use flow data to trigger a rtbh (remotely triggered blackhole) route using bgp ? …I’m thinking we could use quagga or a script of some sort to interact with a router to advertise to bgp the /32 host route of the victim under attack.
Btw, I already have nfsen running and we receive real-time alters of various types of attacks, high volume, high ports, etc… and then we telnet into a cisco trigger router and drop a few lines of code into it and then bgp does the rest within seconds, the upstream providers learn of this route via communities and they rtbh it in their cloud, BUT, I would like my alerts to do this automatically… that would be very nice. Any guidance would be appreciated.
Aaron Gould wrote :
Hi, does anyone know how to use flow data to trigger a rtbh (remotely triggered blackhole) route using bgp ? ...I'm thinking we could use
quagga or a script of some sort to interact with a router to advertise to bgp the /32 host route of the victim under attack.
TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!...
Thanks, but what if the attacker is many... like thousands ? ...isn't that
typically what we see, is tons and tons of sources (hence
distributed....dos) ?
Exactly Aaron. No provider will allow a customer to null route a source IP address. I could only assume that a null route on Michel's network is tanking the packets at their edge to 192.0.2.1 (discard/null0).
Aaron Gould wrote :
Thanks, but what if the attacker is many... like thousands ? ...isn't that typically what we see, is tons and tons of sources (hence distributed....dos) ?
At this very moment I blacklist ~ 56,000 individual /32s and historically it has been up to 135,000 at times. It's not a problem for most routers, unless you're on one of these old clunkers with un-upgradable TCAM and a full feed (if you are, you don't have much time left anyway).
Ryan Hamel wrote :
Exactly Aaron. No provider will allow a customer to null route a source IP address.
Yes, unless you have your own router on their side of the link and pay for it, or have your own VRF on their router which is not going to be cheap either.
I could only assume that a null route on Michel's network is tanking the packets at their edge to 192.0.2.1 (discard/null0).
Correct, and I clearly understand its limitations, paragraph below taken from Home of the CBBC : Consolidated Blackhole BGP Communities 65532:666
There indeed is a value in blacklisting the IP address of the host being attacked and feed that with the appropriate community to the upstream that will accept it as it is part of your own space. You sacrifice one host to save the bandwidth to the rest.
That being said, if the DDOS targets your entire IP range, none of these will help.
I have to withstand DDOS attacks all the time, can the CBBC feed help ?
It depends on the type of attack; the CBBC feed is not designed as DDOS mitigation tool. There is no such thing as a free lunch : your ISP will not take the full CBBC feed for free when they can make you pay big bucks for their own one. The CBBC does not prevent the DDOS attack to get to you, it may help with attacks that are based on PPS, not raw bandwidth. What the CBBC does is to block the offending traffic at the router level, so it is blocked before it even reaches your server / firewall. However, the CBBC does not prevent the DDOS traffic from coming to you, so if you have a slow connection to the Internet and the DDOS sends more bandwidth than you have, you still are down. However, if the DDOS is based not on bandwidth but on a higher-level protocol such as DNS or HTTPS, it helps by taking the load off the server.
Aaron Gould wrote :
Hi, does anyone know how to use flow data to trigger a rtbh (remotely triggered blackhole) route using bgp ? ...I'm thinking we could use
quagga or a script of some sort to interact with a router to advertise to bgp the /32 host route of the victim under attack.
I use a bunch of scripts plus a supervisory sqlite3 database process all injecting into quagga
Also aimed at attacker sources. I feed it with honeypots and live servers, hooked into fail2ban and using independent host scripts.
Not very sophisticated, the remotes use ssh executed commands to add/delete. I also setup a promiscuous ebgp RR so I can extend my umbrella to CPE with diverse connectivity.
Using flow data, that sounds like an interesting direction to take this into, so thank you!
Joe Maimon wrote :
I use a bunch of scripts plus a supervisory sqlite3 database process all injecting into quagga
I have the sqlite part planned, today I'm using a flat file I know
Also aimed at attacker sources. I feed it with honeypots and live servers, hooked into fail2ban and using independent host scripts. Not very sophisticated, the remotes use ssh executed commands to add/delete. I also setup a promiscuous ebgp RR so I can extend my umbrella to CPE with diverse connectivity.
I would like to have your feed. How many attacker prefixes do you currently have ?
Using flow data, that sounds like an interesting direction to take this into, so thank you!
The one thing we can share here is the attacker prefixes. The victim prefixes are unique to each of us but I expect our attacker prefixes to be very close.
Michel.
TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!...
I'm really surprised that you all are doing this based on source ip, simply because I thought the distribution of botnet members around the world we're so extensive that I never really thought it possible to filter based on sources, if so I'd like to see the list too
Even so, this would not stop the attacks from hitting my front door, my side of my Internet uplink...when paying for a 30 gigs CIR and paying double for megabits per second over that, up to the ceiling of 100 gig every bit that hits my front door over 30 gig would cost me extra, remotely triggering based on my victim IP address inside my network would be my solution to saving money
But stopping the attack even on my side of my Internet up like would at least stop it from proliferating throughout my internal network which is also costing me when it affects cell towers, etc.
Using S/RTBH to drop attack sources has been a valid and useful mitigation tactic for close to 20 years. Any kind of modern router scales up to large numbers of sources; and note that S/RTBH isn't limited to /32s.
Aaron Gould wrote :
I'm really surprised that you all are doing this based on source ip, simply because I thought the distribution of botnet members around
the world we're so extensive that I never really thought it possible to filter based on sources, if so I'd like to see the list too.
I emailed you. For years I ran it at home on a Cisco 1841, 100,000 BGP prefixes is nothing these days. I am not surprised that Joe pushes that to some CPEs.
Even so, this would not stop the attacks from hitting my front door, my side of my Internet uplink...when paying for a 30 gigs CIR
and paying double for megabits per second over that, up to the ceiling of 100 gig every bit that hits my front door over 30 gig
would cost me extra, remotely triggering based on my victim IP address inside my network would be my solution to saving money.
I agree. If you want to get a real use of source blacklisting, to save bandwidth, you probably went to rent a U in a rack at your upstream(s) to block it there.
I never did it past 1GE, and I have never measured seriously the bandwidth it would save, would be curious to know.
I think the two approaches are complementary to each other though.
Most of the solutions mentioned are paid, or fastnetmon is partially paid. And the thing you want is paid i believe....
Nice tool though, not saying anything against it. However....
My personal view is, as long as you can store your flow info in a timeseries database (like influxdb and NOT SQL LIKE!!!!!!!) you can do whatever you want with the (raw) data. And create custom triggers for different calculations.
Flows are on the fly and are coming in constantly, you could have a calculation like group by srcip and whatever protocol you want or just srcip,
and make a calculation for every x seconds or minutes. As i mentioned the flow data is a constant stream, so you could have it triggered as fast as you want.
(and the nice thing is, with sflow, you also get as path, peer as, localpref,community (if enabled). You could group by anything..
I admit it takes a bit more time to setup but the outcome is amazing (especially if you graph it then with grafana)
And in your case it would be a script that does a influxdb command to make the calculations and if the outcome shows an IP meeting the thresholds you have set in the calculation, you trigger a script that adjusts the route to be announced to your upstream with the correct (rtbh) community.
( as i mentioned, as long as you have the "raw" flows, you can do anything )
From experience, sflows are horribly inaccurate for DDoS detection, since the volume could disrupt the control plane and render the process useless, thus not giving data to the external system to act upon it. You can't get any better than mirroring your inbound transit, and sampling the output to a sensor.
I have also spent some time on a spare server running netmap and influxdb, it simply could not keep up, nor could I write any useful queries against it. Which is why I'm deciding on using pf_ring ft (flow table) and just let it calculate all the data to be dumped into a MySQL memory table, and also harvesting ntop's NDPI protocol decoding, to enhance the detection rules. My ideal setup is to break things down into dedicated programs like flow exporter, detection, and response.
I also want to make clear to Michel, that colo'ing a router at an ISP is no different than plugging it into your local router, your uplink will get saturated beyond what it can physically handle with only the ACLs protecting the other side, but if your clients are also receiving traffic on the same uplink as the attack, it's a denial of service to them.
I think your experience has to do more with your setup than sflow or influxdb...
my sflow data, that i push into influxdb. is 1 on 1 accurate with the interface utilization ( even on group by per source ip )
Arista performs fine with sflow.... Don't know what brand you used.
I'm getting 300 mbit of constant (sflow) data in influxdb....
'''
it simply could not keep up, nor could I write any useful queries against it
'''
again, i really think this has to do with the setup or the queries you tried to do. (and (i think ) you tried sflow exporter on a server, i think the topic was from a appliance as an exporter)
If you still want to give influxdb+ sflow a try, i'm more than willing to help you out
On the contrary, flow telemetry in general works quite well for DDoS detection/classification/traceback, and is widely utilized for such purposes; it has been for many years.
I'm not a big fan of s/Flow comparatively speaking, but it and NetFlow, IPFIX, et. al. have proven themselves over the years, assuming that the flow export parameters on the exporting devices are configured correctly, and the collection/analysis systems are configured optimally.
Flow telemetry is management-plane, not control-plane. Implementing network infrastructure self-protection BCPs such as iACLs is definitely recommended in general.
Instead of rtbh I would suggest blocking/rate limiting common ports used in DDoS attacks. That will block 90% of the DDoS attacks. We recently open sourced a BGP Flowspec based tool for DDoS Mitigation. It applies Flowspec rules per victim IP Addr. https://github.com/racompton/docker-auto-flowspec
I know 
(especially if you graph it then with grafana)