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@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 <s...@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@MX10K3# edit policy-options policy-statement flowspec-import > > > > > > {master}[edit policy-options policy-statement flowspec-import] > > > gustavo@MX10K3# show > > > term 1 { > > > then accept; > > > } > > > > > > IP transit interface > > > > > > {master}[edit interfaces ae0 unit 10] > > > gustavo@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 <s...@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@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@puck.nether.net > > > > > https://puck.nether.net/mailman/listinfo/juniper-nsp > > > > > > > > > > > > > > > > -- > > > > ++ytti > > > > > > > _______________________________________________ > > > juniper-nsp mailing list juniper-nsp@puck.nether.net > > > https://puck.nether.net/mailman/listinfo/juniper-nsp > > > _______________________________________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp