[prev in list] [next in list] [prev in thread] [next in thread]
List: juniper-nsp
Subject: Re: [j-nsp] Flowspec not filtering traffic.
From: Gustavo Santos via juniper-nsp <juniper-nsp () puck ! nether ! net>
Date: 2022-09-21 2:29:29
Message-ID: CAOXUNqmXaFAnM6i_ROY_ti7YBjdbujHUTQg=ppEa7OrmqOfoQw () mail ! gmail ! com
[Download RAW message or body]
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 <
nitzan.tzelniker@gmail.com> 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 <
> 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 <
>> snar@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 <saku@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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic