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 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
> 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: 0001
>> > 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:
>> > 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:
>> > NameBytes
>> > 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
