[j-nsp] Flowspec not filtering traffic.
Gustavo Santos
gustkiller at gmail.com
Sun Sep 18 15:05:24 EDT 2022
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
>
More information about the juniper-nsp
mailing list