Re: [j-nsp] Flowspec not filtering traffic.
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.tzelni...@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 <
>> s...@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: 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#
Re: [j-nsp] Flowspec not filtering traffic.
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 >
> 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 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;
> > > }
> > >
Re: [j-nsp] Outgrowing a QFX5100
Why would you want DHCP snooping or dot1x on a campus core router? Those functions are typically implemented at the access layer switches connected directly to end users. On Fri, Sep 16, 2022 at 03:11:22PM -0400, Jason Healy via juniper-nsp wrote: > We're a small school campus that's been running a QFX 5100 as our core > switch/router for several years. It's been a good piece of equipment but we > continue to hit weird limitations and I'm wondering if we're pushing the > platform too hard. > > Does the MX line handle all the layer-2 stuff that the QFX has, like DHCP > snooping, vlan firewall filters, or even dot1x? Coming from the switching > family, I wasn't sure how prevalent those features are on the layer-3 > equipment, or if they're configured in some totally different way. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Outgrowing a QFX5100
On Sep 20, 2022, at 12:57 AM, Mike Gonnason wrote: > Do you have any more details about what limitations you are encountering on > the QFX? Is it hardware related or software? The example that spurred my email was DDOS protection on the QFX. We're getting lots of L3NHOP errors (still, I wrote to the list a while back about it) and have been trying to track them down. On some platforms you can capture the flows causing the DDOS violation, but not the QFX. We've been forced to perform random packet captures in the hope of finding the traffic on the right interface. Another bug causes DHCP relay to fail when an ACL is applied on an interface, even if the filter explicitly permits DHCP traffic. The chipset has a "feature" where IPv6 counters aren't incremented at all (they claim this is "working as designed"). Filter-based forwarding is not supported on IPv6 (the documentation on this has been corrected, but only after we escalated our case through ATAC). There's a bug where setting a 0.0.0.0/0 match in an inet firewall filter prevents ipv6 traffic from passing (incorrect hardware programming). We have to use ether-type instead in order to hack around it. There are limitations on egress filters that don't appear to apply on other platforms. Many of these issues were not stated in the official documentation, and some still aren't (you have to search KB articles to find the limitations). That makes product evaluation very difficult and is part of why I was asking the list. Most of our problems seem to center around L3 stuff (ACLs, forwarding, etc), which I why I asked about the router line. It seems like I'm asking "too much" of the QFX as a core router, though it does pretty well as a switch. The full router line is overkill for me (I don't need a full table, for example), but if it means some of these other features will actually work as designed, it might be worth it. The mx304 is an interesting option, as is the ACX line. Maybe one of the newer QFX models will fix some issues that the broadcom chipset had, but I'll need to test the heck out of that first. Thanks, Jason ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
