[j-nsp] Flowspec not filtering traffic.
Nitzan Tzelniker
nitzan.tzelniker at gmail.com
Tue Sep 20 15:55:56 EDT 2022
BTW,
As I see Kentik in the name of the BGP group
The default Kentik DDoS policie "UDP Fragments Attack" match udp port 0 and the
flowspec rule attached to it match is-fragment and first-fragment
So I don't understand why it send filter that match udp port 0 ?
Did you change the default one ?
Nitzan
On Sun, Sep 18, 2022 at 10:06 PM Gustavo Santos via juniper-nsp <
juniper-nsp at puck.nether.net> wrote:
> Hi Alexandre,
>
> The detection system throws for example port 123 and port 0 rules at the
> same time.
>
> But I got the logic but for example on our flow monitoring system we got
> 30Gbps of udp flood towards a customer, 25Gbps are from source port 123 and
> 5gbps are from port 0.
>
> What we get here is that All of the traffic is forwarded to the customer (
> 30gbps) instead of being filtered or not being forwarded to the customer´s
> interface.
>
> I think I can set the detection system to change its behavior from port 0
> to udp fragment.
>
> Thanks for your input.
>
> Em dom., 18 de set. de 2022 às 14:25, Alexandre Snarskii <snar at snar.spb.ru
> >
> escreveu:
>
> > On Sat, Sep 17, 2022 at 11:41:58AM -0300, Gustavo Santos via juniper-nsp
> > wrote:
> > > Hi Saku,
> > >
> > > PS: Real ASN was changed to 65000 on the configuration snippet.
> > >
> > >
> > >
> > > show route table inetflow.0 extensive
> > >
> > > 1x8.2x8.84.34,*,proto=17,port=0/term:7 (1 entry, 1 announced)
> >
> > port=0 seems to be poor choice when trying to shut down NTP reflection,
> > with this rule your router filters only small fraction of DDoS traffic..
> >
> > Background:
> > - udp reflection attacks try go generate as much traffic as possible,
> > so, amplification attacks usually carry lots of fragmented traffic.
> > - when non-first fragment enters your router it does not contain
> > UDP header so it's reported by netflow as having source and destination
> > ports of zeros.
> > - your detection system generates and injects flowspec matching port=0,
> > - now when your router sees first fragment of amplified packet, it does
> > not matches this rule (source port is 123 and destination port is usually
> > non-zero too), so your router passes this packet.
> > - when your router sees non-first fragment of amplified packet,
> > it understand that it does not know neither source nor destination
> > ports, so it can't compare against this rule, so this packet is
> > not matched and passed too.
> > - so, what is filtered is only these (rare) packets that are the
> > first fragments and have destination port of zero.
> >
> > What you can try here: replace port matching with is-fragment matching.
> > In JunOS syntax it will be
> >
> > set routing-options flow route NTP-AMP match destination 1x8.2x8.84.34/32
> > set routing-options flow route NTP-AMP match protocol udp fragment
> > is-fragment
> > set routing-options flow route NTP-AMP then discard
> >
> > > TSI:
> > > KRT in dfwd;
> > > Action(s): discard,count
> > > Page 0 idx 0, (group KENTIK_FS type Internal) Type 1 val 0x63b7c098
> > > (adv_entry)
> > > Advertised metrics:
> > > Flags: NoNexthop
> > > Localpref: 100
> > > AS path: [65000 I
> > > Communities: traffic-rate:52873:0
> > > Advertise: 00000001
> > > Path 1x8.2x8.84.34,*,proto=17,port=0
> > > Vector len 4. Val: 0
> > > *Flow Preference: 5
> > > Next hop type: Fictitious, Next hop index: 0
> > > Address: 0x5214bfc
> > > Next-hop reference count: 22
> > > Next hop:
> > > State: <Active SendNhToPFE>
> > > Local AS: 52873
> > > Age: 8w0d 20:30:33
> > > Validation State: unverified
> > > Task: RT Flow
> > > Announcement bits (2): 0-Flow 1-BGP_RT_Background
> > > AS path: I
> > > Communities: traffic-rate:65000:0
> > >
> > > show firewall
> > >
> > > Filter: __flowspec_default_inet__
> > > Counters:
> > > Name Bytes
> > > Packets
> > > 1x8.2x8.84.34,*,proto=17,port=0 19897391083
> > > 510189535
> > >
> > >
> > > BGP Group
> > >
> > > {master}[edit protocols bgp group KENTIK_FS]
> > > type internal;
> > > hold-time 720;
> > > mtu-discovery;
> > > family inet {
> > > unicast;
> > > flow {
> > > no-validate flowspec-import;
> > > }
> > > }
> > > }
> > >
> > >
> > >
> > > Import policy
> > > {master}[edit]
> > > gustavo at MX10K3# edit policy-options policy-statement flowspec-import
> > >
> > > {master}[edit policy-options policy-statement flowspec-import]
> > > gustavo at MX10K3# show
> > > term 1 {
> > > then accept;
> > > }
> > >
> > > IP transit interface
> > >
> > > {master}[edit interfaces ae0 unit 10]
> > > gustavo at MX10K3# show
> > > vlan-id 10;
> > > family inet {
> > > mtu 1500;
> > > filter {
> > > inactive: input ddos;
> > > }
> > > sampling {
> > > input;
> > > }
> > > address x.x.x.x.x/31;
> > > }
> > >
> > >
> > > Em sáb., 17 de set. de 2022 às 03:00, Saku Ytti <saku at ytti.fi>
> escreveu:
> > >
> > > > Can you provide some output.
> > > >
> > > > Like 'show route table inetflow.0 extensive' and config.
> > > >
> > > > On Sat, 17 Sept 2022 at 05:05, Gustavo Santos via juniper-nsp
> > > > <juniper-nsp at puck.nether.net> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > We have noticed that flowspec is not working or filtering as
> > expected.
> > > > > Trying a DDoS detection and rule generator tool, and we noticed
> that
> > the
> > > > > flowspec rule is installed,
> > > > > the filter counter is increasing , but no filtering at all.
> > > > >
> > > > > For example DDoS traffic from source port UDP port 123 is coming
> > from an
> > > > > Internet Transit
> > > > > facing interface AE0.
> > > > > The destination of this traffic is to a customer Interface
> ET-0/0/10.
> > > > >
> > > > > Even with all information and "show" commands confirming that the
> > traffic
> > > > > has been filtered, customer and snmp and netflow from the customer
> > facing
> > > > > interface is showing that the "filtered" traffic is hitting the
> > > > destination.
> > > > >
> > > > > Is there any caveat or limitation or anyone hit this issue? I tried
> > this
> > > > > with two MX10003 routers one with 19.R3-xxx and the other one with
> > 20.4R3
> > > > > junos branch.
> > > > >
> > > > > Regards.
> > > > > _______________________________________________
> > > > > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > > > > https://puck.nether.net/mailman/listinfo/juniper-nsp
> > > >
> > > >
> > > >
> > > > --
> > > > ++ytti
> > > >
> > > _______________________________________________
> > > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > > https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
More information about the juniper-nsp
mailing list