Mailing List Archive

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

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)
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

Are you exceeding the configured rate for the policer? Did you expect
to drop at any rate? The rule sets a non-0 policing rate.

On Sat, 17 Sept 2022 at 17:42, Gustavo Santos <gustkiller@gmail.com> 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)
> 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



--
++ytti
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Actually I think I'm confused, I'm just not accustomed to seeing other
than 0:0 as rate, but it may be thaat the first 0 doesn't matter.

I would verify 'show route flow validation detail' as well as verify
presence of policers if any (in PFE 'show filter counters').

I'd also look at the filter more closely at PFE:
- show filter (get the index)
- show filter index X program



On Sun, 18 Sept 2022 at 09:39, Saku Ytti <saku@ytti.fi> wrote:
>
> Are you exceeding the configured rate for the policer? Did you expect
> to drop at any rate? The rule sets a non-0 policing rate.
>
> On Sat, 17 Sept 2022 at 17:42, Gustavo Santos <gustkiller@gmail.com> 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)
> > 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
>
>
>
> --
> ++ytti



--
++ytti
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

Weird, show route flow validation detail came out empty.

But on PFE looks like rules are been accepted.

But when DDoS traffic comes with high volume, all of them are forwarded to
customers instead of being dropped at the edge..

{master}
gustavo@MX10K3> show route flow validation detail

inet.0:

{master}

show filter inside pfe ( shows only this index for flowspec)

65024 Classic - __flowspec_default_inet__

SMPC0(MX10003-CORE vty)# show filter index 65024 program
Filter index = 65024
Optimization flag: 0xf7
Filter notify host id = 0
Pfe Mask = 0xFFFFFFFF
jnh inst = 0x0
Filter properties: None
Filter state = CONSISTENT
term interface-group
term priority 0
interface-group
0
2-255
true branch to match action in rule default-term
false branch to match protocol in rule 4?.1?3.1?9.2?9,*,proto=1
term 4?.1?3.1?9.209,*,proto=1
term priority 0
protocol
1
6 -> port in 1?8.2?8.?4.15,*,proto=6,port=123
17 -> port in 1?8.2?8.?4.15,*,proto=17,port=123
false branch to match action in rule default-term
destination-address
45.1?3.1?9.209/32
1?8.2?8.8?.4/32 -> action in 168.228.84.4,*,proto=1
1?8.2?8.8?.15/32 -> action in 168.228.84.15,*,proto=1
1?8.2?8.8?.34/32 -> action in 168.228.84.34,*,proto=1
1?8.2?8.8?.61/32 -> action in 168.228.84.61,*,proto=1
false branch to match action in rule default-term

then
discard
count 4?.1?3.1?9.209,*,proto=1
term 1?8.2?8.8?.4,*,proto=1
term priority 0

then
discard
count 1?8.2?8.84.4,*,proto=1
term 1?8.2?8.84.15,*,proto=1
term priority 0

then
discard
count 168.228.84.15,*,proto=1
term 168.228.84.15,*,proto=6,port=123
term priority 0
port
123
false branch to match action in rule default-term
destination-address
1?8.2?8.?4.15/32
false branch to match action in rule default-term

then
discard
count 1?8.2?8.?4.15,*,proto=6,port=123
term 1?8.2?8.?4.15,*,proto=17,port=123
term priority 0
port
123
false branch to match port in rule 1?8.2?8.?4.34,*,proto=17,port=0
destination-address
1?8.2?8.34.15/32
false branch to match port in rule 1?8.2?8.84.34,*,proto=17,port=0

then
discard
count 1?8.2?8.84.15,*,proto=17,port=123
term 1?8.2?8.84.34,*,proto=1
term priority 0

then
discard
count 1?8.2?8.84.34,*,proto=1
term 1?8.2?8.84.34,*,proto=17,port=0
term priority 0
port
0
false branch to match port in rule 1?8.2?8.84.34,*,proto=17,port=123
destination-address
1?8.2?8.84.34/32
false branch to match port in rule 1?8.2?8.84.34,*,proto=17,port=123

then
discard
count 1?8.2?8.84.34,*,proto=17,port=0
term 1?8.2?8.84.34,*,proto=17,port=123
term priority 0
port
123
false branch to match port in rule
1?8.2?8.84.190,*,proto=17,port=9001
destination-address
1?8.2?8.84.34/32
false branch to match port in rule
1?8.2?8.84.190,*,proto=17,port=9001

then
discard
count 1?8.2?8.84.34,*,proto=17,port=123
term 1?8.2?8.84.61,*,proto=1
term priority 0

then
discard
count 1?8.2?8.84.61,*,proto=1
term 1?8.2?8.84.190,*,proto=17,port=9001
term priority 0
port
9001
false branch to match action in rule default-term
destination-address
1?8.2?8.84.190/32
false branch to match action in rule default-term

then
discard
count 1?8.2?8.84.190,*,proto=17,port=9001
term default-term
term priority 0

then
accept


Em dom., 18 de set. de 2022 às 03:57, Saku Ytti <saku@ytti.fi> escreveu:

> Actually I think I'm confused, I'm just not accustomed to seeing other
> than 0:0 as rate, but it may be thaat the first 0 doesn't matter.
>
> I would verify 'show route flow validation detail' as well as verify
> presence of policers if any (in PFE 'show filter counters').
>
> I'd also look at the filter more closely at PFE:
> - show filter (get the index)
> - show filter index X program
>
>
>
> On Sun, 18 Sept 2022 at 09:39, Saku Ytti <saku@ytti.fi> wrote:
> >
> > Are you exceeding the configured rate for the policer? Did you expect
> > to drop at any rate? The rule sets a non-0 policing rate.
> >
> > On Sat, 17 Sept 2022 at 17:42, Gustavo Santos <gustkiller@gmail.com>
> 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)
> > > 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: 65000
> > > 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
> >
> >
> >
> > --
> > ++ytti
>
>
>
> --
> ++ytti
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

I can't blame the port=0, even though I agree with the explanation
that you shouldn't rely on it for identifying fragmentation. Looking
at the program, whenever the counter you mentioned
(1x8.2x8.84.34,*,proto=17,port=0) is punched, it is also discarded.
And you can observe the counter being punched, therefore it should be
discarded to my understanding of the PFE programming.

The first term surprises me a little bit. It basically seems to be 'if
interface-group is 0 or 2-255 permit, otherwise check next term', but
it doesn't seem to offer any help to you, just curious detail. Unless
the help is, the counter and discard are working as intended, it's
just the interface you are interested in, belongs to interface-group
1, and traffic from that interface is not being filtered.

For the next step, I would reduce the complexity of your test to
single term, with just src or dst IP address match of some test
address, and review.

On Sun, 18 Sept 2022 at 22:05, Gustavo Santos <gustkiller@gmail.com> 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



--
++ytti
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

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