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...

5 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.

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.

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

1 Like