DDoS protection

Hello.

I suggest to add DDoS protection.in one of newest version or as plugin. Many routers have that futures. There are several way how to detected abnormal traffic.

and if your firewall already drops (or rejects) all incoming traffic, what else would you like to do ?

5 Likes

You can hack your own rules into default ratelimit chain. Show one rule you have in mind get instructions that you should be able to derive from fw4 github issues.

You really can not remedy a volumetric (D)DOS attack from the remote side... the attacker simply throws so many packets at you that the ISP side buffers overflow and packets get dropped left and right...

6 Likes

Does not mean you should not comb traffic in l3 l4 cases, some gamers are quite advanced at that. Sadly in both sides of good.

First of all, no home user get DDOS attacked, they get at best DoS attacked.

DDoS attacks are global sourced and humungously huge, like 10000Gbit/second.

And a home router at very very best maybe have a 10/10Gbit line, but more likely under 1Gbps in both ways. So it is really easy to overwhelm a home router.

But anyway as already mentioned, the receiver end can’t protect itself agains DoS attacks, that is why cloudflare exist. They simply is a goalkeeper and shift the legal traffic to another place where the server is located.

The internal network will work flawless but you wont have any internet data available while it is ongoing.

You can stop sending responses to attack over asymmetrical line, (rate-)limit new connections to good services, in general there are some chances to improve your posture when attacked by similarly resourced attacker, like overcompetitive gamer.

1 Like

There used to be IIRC network stress testing services that took your money and your word that a specific IP to stress address was yours... these used distributed attacks IIRC... Not finding any of those with cursory searches right now, I guess the sketchiness of that business model might have driven these folks to keep off the lime light...

Not without opensourcing their tools....

They don’t care about answers, the simply flood you internet line with more that it is even possible to swallow.

So if you have 1 Gbit line and you get drenched with 1 Gbit of requests, what does it matter if you respond or not?

It is like standing in front of firehouse and try to drink the water to get it to move away…

But to be honest, a lot bigger organizations that you have been brought down by this and they have a lot more resources than you.

Even cloudflare having trouble handling the really big ones nowadays.

If you have DSL and your adversary pings you ....

I think the observation was that with asymmetric lines most end users can not DOS each other, as my uplink likely is smaller than your downlink, so I could at best inconvenience you a bit, but not deny you internet access.

That's not true. Reflection DDoS/DoS, generally in the form of spoofed layer 7 UDP packets is a real problem that can get an abuse complaint filled to your ISP.
I used to run some servers running an old protocol over UDP that answered to status requests without any form of validation or authentication.
Long story short, someone started running reflection DoS against one of them. The traffic wasn't enough to disrupt the service, but it was enough for the datacenter to get a complaint filled against me.

Bit in that case you likely were not the true DDOS victim, but part of the first D swarm in DDOS, no?

The intention was to saturate the process' CPU time, which was single threaded and a lot of that time was spent answering status requests. The attacker simply used a spoofed range that pointed to a monitored university network, thus the abuse complaint.

But yes, reflection can work both ways, it can be used to generate larger traffic from a host to the victim or just a side effect of spoofed packets targeting a layer 7 vulnerability.
In both cases, the statement that attackers don't care about the reply is false.

Many devices cannot comfortably discard incoming gigabit traffic just passing "outgoing connections" coming in

config zone
        option name 'wan'
        list network ....
        option input 'DROP'
        option output 'ACCEPT'
        option forward 'DROP'
        option masq '1'
        option mtu_fix '1'

The solution to reflection can be applied to layer 2 to 7. Without the resources of big corporations like CF, they all involve rate-limiting, which can lead to partial or complete denial of service, but without the danger of abuse complaints being filled against you.

  1. Layer 2 or 3: Your firewall rules match the content of the payload with those that lead to server replies, rate-limiting them. This was already possible over a decade ago with iptables, it can be CPU expensive under stress though. Can be implemented at both the router or server machine.
  2. Layer 4: If the software running the server cannot be extended naturally, hooking its networking API and rate limiting packets before they are presented to the application works. This is a solution that works on the server machine itself and has the benefit that you're only processing through incoming packets to the application. Can be fairly expensive if single-threaded, more so if you've a powerful enough router that can do concurrent filter at kernel or hardware level.
  3. Layer 7: Works like layer 4, but you can just implement rate-limiting naturally in the application's source code and drop excessive requests. Same cons as layer 4 too.
1 Like

With this script you can add DDos protection to the Openwrt firewall. Simply include the script via the firewall config file.

4 Likes

For me personally, the built-in protections work great but with the caveat that I merely use OpenWRT as a home router.

If I were hosting services and needed something more robust against DoS and distributed attacks, I would probably get a better firewall engine, ie. switch from nft to pf.

As an example, I would probably buy the cheapest Deciso DEC6xx and run OPNsense on it.

That said, improvements to OpenWRT are always good of course. Asking for "protection against DDoS" is maybe a tall order though? There are a number of different attacks so it quickly ends up being a very broad discussion. Maybe focus on one particular problem area?

Testing could be a strategy to pinpoint exactly where improvements are relevant.

To demonstrate how broad this can get, here are some random concrete ideas.

  • Automatic DROP on REJECT #1

There are default zone rules and general rules with the "reject" action. Nice because it makes troubleshooting easy.

Potential improvement: Would it be nice if the nftables rules automatically switched from REJECT to DROP when it starts sending out more than, say, 100 RST or UNREACH per second?

  • SYN tracking #2

Default rule drops SYN at 25/sec. Default conntrack limit is 16K entries. If you hit it with 20 handshakes per second, could you fill the conntrack table in about 15 minutes?

Potential improvement: Would it be nice with rules to automatically enable synproxy at some preset threshold, before the hard limit kicks in?

  • Connection table prune when no egress throughput #3

There's a couple attacks such as slowloris, search api overloading, etc. that relies on a service not producing any output while keeping a conntrack entry alive. Conntrack currently updates timeouts when traffic is seen in either direction.

Potential improvement: Might it be nice if conntrack had a another threshold to drop entries faster when nothing is seen in the egress direction (towards WAN) at all?

  • Self-adjusting connection tracking TTL #4

The timeout for conntrack table entries is 30 seconds.

Potential improvement: When the table is 85% full might it make sense to start pruning entries after 20 seconds, at 95% maybe after 10 seconds etc.?

  • Fragmentation drop during high fragmentation loads #5

When "-m conntrack" or "-t nat" is present in nftables rules, the kernel modules nf_defrag_ipv4 and nf_defrag_ipv6 are loaded automatically at prio -400. I don't see any limits to how much CPU is spent reassembling IP fragments in the current rules.

Potential improvement: Would it be nice if a counter rule was installed at priority -450 or something, that switches to rejecting fragments when a particular rate is encountered, to avoid spending infinite CPU on reassembly?

  • Invalid packet drops #6

Built-in option, disabled by default.

Potential improvement: Would it make sense to enable it per default for fresh installs?

  • Routing overhead decrease #7

Nearly all users have a symmetric setup with no inherent need to consult routing tables for every packet.

Some platforms have hardware offload that help.

Potential improvement: For the rest, would it be nice with a kernel module that keeps a table of which interfaces a conntracked connection was established through, and then when something needs to be forwarded, just super-fast-path it out the correct interface instead of spending CPU time doing complex longest-prefix matching against a routing table?

As a bonus, would also help things "just work" out of the box on multi-homed setups (eg. 2x WAN).

  • Reverse path filtering #8

Potential improvement: Would it make sense to early drop as much as possible by having a "table netdev type filter hook ingress" that drops frames from a subnet that doesn't belong on an interface?

I tested it on one box:

table netdev antispoof {
   chain wan {
      type filter hook ingress device wan priority 10; policy drop;
      ip saddr { <WAN> } counter packets 1276145 bytes 139678092 accept
      meta protocol arp counter packets 15416200 bytes 709145200 accept
      counter packets 42012 bytes 6427634 drop
   }
}

and did see a few drops.

(Might already be available and I just don't know where to click to enable it...?)

  • Self-adjusting rate limits and buffer sizes #9

Some of the defaults could probably do with adjustments based on available CPU and RAM.

Example 25/sec SYN, probably appropriate for MT7621 but maybe a bit low for a Xeon E5.

Another example could be 16K conntrack entries, appropriate for 128MB RAM but maybe a bit low for 2GB RAM.

I'm sure there are more, fragmentation reassembly buffers come to mind for example.

Potential improvement: Would it be helpful if all those knobs were automatically tuned for the platform CPU and memory limits?

So, anyway..

I could keep going :slight_smile:

Suffice to say that adding "protection" could mean any number of things.

I want to ans!er, can you number paragraphs plees :roll_eyes: