RTBH and Flowspec Measurements - Stop guessing when the attack will over

Wed Feb 3 10:36:45 UTC 2021

In between the FS-Enforcer and the network there should be an arbiter that is able to report, analyse, approve, ignore or rollback rules that are being pushed. Not sure if this already exsists.

Verzonden vanuit Outlook<http://aka.ms/weboutlook>

________________________________
Van: NANOG <nanog-bounces+peterf.deboer=hotmail.com at nanog.org> namens Douglas Fischer <fischerdouglas at gmail.com>
Verzonden: woensdag 3 februari 2021 10:59
Aan: Hank Nussbacher <hank at interall.co.il>
CC: NANOG <nanog at nanog.org>
Onderwerp: Re: RTBH and Flowspec Measurements - Stop guessing when the attack will over

Yep...
But I remember the first concept of security:
There is no real security on a single layer.

So, considering That, FlowSpec should never be accepted directly by the FlowSpec-Enforcer-Box.
It should be announced to another box, running other software than that one on the Perimeter, and filtering and refiltering should be done on both layers.

Em qua., 3 de fev. de 2021 às 02:43, Hank Nussbacher <hank at interall.co.il<mailto:hank at interall.co.il>> escreveu:
On 02/02/2021 19:08, Douglas Fischer wrote:
Well... That is a point of view!
And I must respect that.

Against this position, there are several companies, including some tier 1, that sells this as an $extra$.

About the "Please break me at my earliest inconvenience." part:
I believe that the same type of prefix filtering that applies to Downstream-BGP-Routes applies to RTBH and Flowspec.
So, exactly as in common BGP Route-Filtering:
- If the network operator does it correctly, it should work correctly.
- If the network operator deals with that without the needed skills, expertise, attention+devotion, wrong things will come up.

You forgot to mention software bugs:

https://kb.juniper.net/InfoCenter/index?page=content&id=JSA11101&cat=SIRT_1&actp=LIST

Note what Juniper states:

Workaround:
There are no viable workarounds for this issue

-Hank

But, this still does not helps to find a solution do an organization A that sends some flowspec our RTBH to organization B(presuming organization B will accept that),  and organization B do some reports of what is match with that flowspec or RTBH.

That, in my opinion, is the only way to stop guessing how long will an attack will last, and start to define the end of a flowspec/RTBH action based on real information related to that.
I want to close the feedback loop.

Em ter., 2 de fev. de 2021 às 13:07, Tom Beecher <beecher at beecher.cc><mailto:beecher at beecher.cc> escreveu:
Personally, I would absolutely, positively, never ever under any circumstances provide access to a 3rd party company to push a FlowSpec rule or trigger RTBH on my networks. No way.  You would be handing over a nuclear trigger and saying "Please break me at my earliest inconvenience."

On Tue, Feb 2, 2021 at 5:56 AM Douglas Fischer <fischerdouglas at gmail.com<mailto:fischerdouglas at gmail.com>> wrote:
OK, but do you know any company the sells de Flowspec as a service, in the way that the Attack Identifications are not made by their equipment, just receiving de BGP-FlowSpec and applying that rules on that equipments... And even then give back to the customer some way to access those statistics?

I just know one or two that do that, and(sadly) they do it on fancy web reports or PDFs.
Without any chance of using that as structured data do feedback the anomaly detection tools to determine if already it is the time to remove that Flowsperc rule.

What I'm looking for is something like:
A) XML/JSON/CSV files streamed to my equipment from the Flowspec Upstream Equipments saying "Heepend that, that, and that." Almost in real time.
B) NetFlow/IPFIX/SFlow streamed to my equipment from the Upstream Equipment, restricted to the DST-Address that matches to the IP blocks that were involved to the Flowspec or RTBH that I Annouced to then.
C) Any other idea that does the job of gives me the visibility of what is happening with FlowSpec-rules, or RTBH on theyr network.

Em seg., 1 de fev. de 2021 às 22:07, Dobbins, Roland <Roland.Dobbins at netscout.com<mailto:Roland.Dobbins at netscout.com>> escreveu:

On Feb 2, 2021, at 00:34, Douglas Fischer <fischerdouglas at gmail.com<mailto:fischerdouglas at gmail.com>> wrote:

Or even know if already there is a solution to that and I'm trying to invent the wheel.

Many flow telemetry export implementations on routers/layer3 switches report both passed & dropped traffic on a continuous basis for DDoS detection/classification/traceback.

It's also possible to combine the detection/classification/traceback & flowspec trigger functions.

[Full disclosure: I work for a vendor of such systems.]

--------------------------------------------

Roland Dobbins <roland.dobbins at netscout.com<mailto:roland.dobbins at netscout.com>>

--
Douglas Fernando Fischer
Engº de Controle e Automação

--
Douglas Fernando Fischer
Engº de Controle e Automação

--
Douglas Fernando Fischer
Engº de Controle e Automação
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20210203/2ee15405/attachment.html>