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