The synflood limit is too low for the modern internet

Installing and Using OpenWrt Network and Wireless Configuration
1

The tcp synflood limits in the firewall are set to 25 and a burst of 50, which is what they were set to back in the 20Mbit/5Mbit up/download days 8+ years ago. I'd argue that nowadays with a typical download speeds 5x that, that this is too low, particularly in busier than home environments.

Recently I did a set of tests in coffee shops and saw that 30% of my syn attempts were retried. There could have been a variety of reason for that, but....

It would be interesting for more folk to take a look at their busier environments and see how often this chain is hit:

iptables -nvL | grep -A 4 "Chain syn_flood"

As for what to do about it - not a clue - turn it off by default? Scale it as part of an sqm system?

3 Likes
2

OpenWrt 18.06.4, uptime 32d 22h, Comcast, SQM Cake set to 120Mbit/5.9Mbit, home router, multiple users, streaming video and torrents

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

While that is a pretty trivial amount the synflood concept is about being resistant to attacks, more than an attempt to ratelimit tcp attempts to save bandwidth, particularly in a cake'd environment.
Are you running ipv6 also (same command ip6ables)? On ipv6 there is generally less need
to do this in that it doesn't impact the conntrack table....

It made sense to try and ratelimit tcp somehow back in the day, but in your case, I'd bump it up.

My key parameters (used to be):

option synflood_protect '1'
option synflood_rate '200/s'
option synflood_burst '500'

But I basically have been turning it off everywhere else for years, and simply hadn't noticed others weren't until I got back those stats from my coffee shop tests.

That said, I'd like to be tracking syn failures more generally from the clients than we have been.

1 Like
4

For typical home use, I'd only consider increasing it for "semi-trusted" clients, not for the outside sources. I'd also only consider increasing it for ports 80 and 443. Even with a browser opening a dozen, simultaneous HTTPS connections, 25/second is two people opening a page a second, on average.

1 Like
5

Actually, it turns out that this is only enabled for the INPUT path - where protecting the router itself from a synflood makes sense. That said, it can be triggered if you run stuff (like torrent or web services) on the router, and doesn't necessarily need to be this low.

4 Likes
6

This feature is definitely a controversial one, and perhaps it should not be enabled by default.
I didn't bother with calculations and simply disabled it as it negatively affects torrent uploading.

1 Like
7

Given that the openwrt default builds have this:

config defaults
       option syn_flood '1'

Doesn't that mean all interfaces have it enabled by default, and at the very low 25/50 limits?

8

Wait...can someone explain to me why anyone would want SYN packets - that you don't intend to acknowledge with a proper TCP handshake?

Interesting.

9

A lot of peers, many file fractions, quite a few connections.
These limits are much easier and more flexible to control via the torrent client/server settings.

1 Like
10

Default WAN input policy is REJECT and forwarding from WAN to LAN is disabled.
So, it is more like a limitation on your own network than protection from outside threats.
The only tangible profit is for open ports if any.

It is supposed to protect services on the open ports from SYN-flood or some type of brute force attacks, but the drawbacks make me think it is not worth to be enabled by default.

11

Currently I don't have syn flood protection enabled.
But if I remember correctly this rule only applies to the Input chain.
So this only affects traffic directed at the router?
For the wan side no big deal because by default everything is filtered anyway.
This only affects traffic from the lan to the router?
And what is the purpose of this rule when syn cookies are enabled by default?

1 Like
12

Its more then that to be fair.

A modern web browser will use multiple connections at once to load a page, the exception been if the page itself is so basic that it there is no objects on the page at all (basic text html).

This rule was probably created in the days when cpu's were 10-20x weaker and the average connection was dialup or slow adsl.

One of the first things I tend to disable on firewalls/routers on home networks now days is anti ddos type features, they are more likely to cause problems than to solve them. Maybe consider this if you are hosting public services on your home network (use a datacentre but whatever), but otherwise I would just turn it off, if you do keep it on, set numbers that fit better the modern hardware and bandwidth available.

1 Like
13

Unless UPnP (or the user) has opened ports on the router so unsolicited inbound traffic can reach gaming consoles or other devices, in which case, the traffic would be subject to the limits established for the synflood settings (e.g. 25/50 default), right?

14

The Input chain applies to the traffic that is directed to processes running on the router.
The Output chain applies to the traffic that is generated by processes running on the router.
(local process)

So does this Synflood Protection Rule apply to traffic that is forwarded?
I guess, No. :wink:

2 Likes