Hi Nitzan, This is a custom policy to catch Carpet Bomb attacks ( low traffic to each /32 host from a larger network /22 for example).
But we are getting the same results ( no flow spec filtering) on any port, like 123 , 53 , and every amplification type attack. Em ter., 20 de set. de 2022 às 16:56, Nitzan Tzelniker < [email protected]> escreveu: > 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 < > [email protected]> 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 < >> [email protected]> >> 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 <[email protected]> >> 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 >> > > > <[email protected]> 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 [email protected] >> > > > > https://puck.nether.net/mailman/listinfo/juniper-nsp >> > > > >> > > > >> > > > >> > > > -- >> > > > ++ytti >> > > > >> > > _______________________________________________ >> > > juniper-nsp mailing list [email protected] >> > > https://puck.nether.net/mailman/listinfo/juniper-nsp >> > >> _______________________________________________ >> juniper-nsp mailing list [email protected] >> https://puck.nether.net/mailman/listinfo/juniper-nsp >> > _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
