[Bloat] talking at linux plumbers in portugal next week

[Toke Høiland-Jørgensen]

Dave Taht <dave.taht at gmail.com> writes:

> On Tue, Sep 3, 2019 at 7:45 AM Toke Høiland-Jørgensen <toke at toke.dk> wrote:
>>
>> Dave Taht <dave.taht at gmail.com> writes:
>>
>> > On Tue, Sep 3, 2019 at 5:23 AM Mikael Abrahamsson <swmike at swm.pp.se> wrote:
>> >>
>> >> On Mon, 2 Sep 2019, Dave Taht wrote:
>> >>
>> >> > with copy-pasted parameters set in the 90s - openwrt's default, last I
>> >> > looked, was 25/sec.
>> >>
>> >> -A syn_flood -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit 25/sec --limit-burst 50 -m comment --comment "!fw3" -j RETURN
>> >> -A syn_flood -m comment --comment "!fw3" -j DROP
>> >>
>> >> Well, it's got a burst-size of 50. I agree that this is quite
>> >> conservative.
>> >>
>> >> However, at least in my home we're not seeing drops:
>> >>
>> >> # iptables -nvL | grep -A 4 "Chain syn_flood"
>> >> Chain syn_flood (1 references)
>> >>   pkts bytes target     prot opt in     out     source               destination
>> >>   2296  113K RETURN     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp flags:0x17/0x02 limit: avg 25/sec burst 50 /* !fw3 */
>> >>      0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* !fw3 */
>> >>
>> >> But you might be right that in places with a lot more clients then this
>> >> might indeed cause problems.
>> >
>> > Well, *I* long ago had upped those params by 10x and don't see syn
>> > drops either on my backbone. But I rather suspect the rest of the
>> > world just copy-pasted it. It should scale as a function of bandwidth,
>> > I suppose, or get updated as a side effect of setting QoS - or just
>> > get bumped up. Start a bug over with openwrt? Take a hard look at
>> > other firewall designs?
>>
>> FWIW:
>>
>> # iptables -nvL syn_flood
>> Chain syn_flood (1 references)
>>  pkts bytes target     prot opt in     out     source               destination
>>  195K   12M RETURN     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp flags:0x17/0x02 limit: avg 25/sec burst 50 /* !fw3 */
>>     0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* !fw3 */
>>
>> # ip6tables -nvL syn_flood
>> Chain syn_flood (1 references)
>>  pkts bytes target     prot opt in     out     source               destination
>>   396 41508 RETURN     tcp      *      *       ::/0                 ::/0                 tcp flags:0x17/0x02 limit: avg 25/sec burst 50 /* !fw3 */
>>     0     0 DROP       all      *      *       ::/0                 ::/0                 /* !fw3 */
>>
>> rebooted this box today; don't seem to have hit the limit thus far,
>> though... This is on a gigabit link.
>
> Hmm. Try to trigger it with --te=upload_streams=200 ?

Sure, that triggers it:

# iptables -nvL syn_flood
Chain syn_flood (1 references)
 pkts bytes target     prot opt in     out     source               destination         
 197K   12M RETURN     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp flags:0x17/0x02 limit: avg 25/sec burst 50 /* !fw3 */
  275 16480 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* !fw3 */


And I get tons of errors from netperf failing to start up.

However, the protection is only actually enabled for the INPUT chain;
i.e., I had to use the router itself as the netperf target to trigger
the rule. So not sure a rule such as this would be the cause of your
coffee shop failures?

This is with the default openwrt config, BTW:


config defaults
        option syn_flood '1'


-Toke