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 <[email protected]> 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 <[email protected]> > <[email protected]> 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 <[email protected]> >> 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 < >>> [email protected]> escreveu: >>> >>>> >>>> >>>> On Feb 2, 2021, at 00:34, Douglas Fischer <[email protected]> >>>> 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 <[email protected]> >>>> >>> >>> >>> -- >>> 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
