[j-nsp] Flowspec not filtering traffic.

[Alexandre Snarskii]

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