Handling of CTM/search DDoS triggered by a malicious hub

[maksis]

I've received a few weird crash reports that are both linked to a specific hub (favorite-hub.net):

https://github.com/airdcpp-web/airdcpp-webclient/issues/450
https://github.com/airdcpp/airdcpp-windows/issues/63

While inspecting the issue more closely, I noticed that the client receives about 300 search/CTM requests per second from the hub, similar to these:

$Search 82.146.38.183:80 F?F?0?1?t
$ConnectToMe maksis 82.146.38.183:443
$Search 82.146.38.183:443 F?F?0?1?p
$ConnectToMe maksis 82.146.38.183:80
$Search 82.146.38.183:80 F?F?0?1?t
$ConnectToMe maksis 82.146.38.183:443
$Search 82.146.38.183:443 F?F?0?1?p
$ConnectToMe maksis 82.146.38.183:80
$Search 82.146.38.183:80 F?F?0?1?t
$ConnectToMe maksis 82.146.38.183:443

Looks like this has been going on for years already and the client is unable to even report it in a meaningful way. DC++ shows a few status messages about search spam but that doesn't really reveal the full extent of the problem as the aim of the hub is clearly to consume all possible system resources from its users.

[maksis (maksis)]

Should be fixed in https://github.com/airdcpp/airdcpp-windows/commit/55a50d9a720c885f59ca80ab3ad206b17e387bf4 (it also adds flood checks for incoming TCP connections)

Looks like the hub also stopped flooding...

[eMTee (realprogger)]

Thanks for reporting and for the through fix!
I can confirm that, at the time of reporting, a short stay on that hub with DC++ indeed caused immense system resource consumption.
To be investigated how to adapt / apply the fix.

[maksis (maksis)]

Some experiences regarding the current implementation in AirDC++:

Looks like there's at least one user that seems the exceed even the latest block limit of 45 attempts within 30 seconds for incoming connections. The user has fake tag so I assume that the client has been modified so I guess that the error is appropriate in that case.

Connection hickups are a bit trickier. There's a guy with a VPN setup that seems to cause connection cuts (possibly for several minutes). This causes the searches to be received in bursts, triggering the spam warnings (and even the DDoS warning). I'm not sure if there is anything else that can be done than to allow the flood checks to be disabled (or make them adjustable).

[RoLex (hundrambit)]

The ability to flood and even crash clients have been there for a very long time, because the client itself does not implement any kind of flood protection, except the search flood. I guess that clients mostly rely on hub antiflood protection, but in this case it is a hub itself that enforces the flood.

I have written antiflood Lua script in 2014 for ApexDC++ that I used to run, it requires Scripts plugin, and works well on any client that supports latest Scripts plugin, inclusive DC++:

https://ledo.feardc.net/dcpp/antiflood.lua