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
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 ?
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
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
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:
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
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
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 wrote:
>
> Hi Saku,
>
> PS: Real ASN was changed to 65000 on the configuration snippet.
>
>
>
> show route table
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
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
wrote:
>
> Hi,
>
> We have noticed that flowspec is not working or filtering as expected.
> Trying a DDoS detection and rule generator tool, and we
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
11 matches
Mail list logo
