Ctm Flood Detection

[RoLex 1]

Good day.

A suggestion, as I spoke in this post, you should start thinking about some kind of CTM flood detection in ApexDC++ and all other clients for that matter.

Thank you.

[Guest Toast]

Good day.

A suggestion, as I spoke in this post, you should start thinking about some kind of CTM flood detection in ApexDC++ and all other clients for that matter.

Thank you.

Not to diss your idea but we are on top of this we are taking preventive steps to minimize CTM scriptkiddie usage in the future cause we are dead tired of this.. so yeah this is an active discussion in DCDev no need to plague mod developers with ideas this is being handled higher up to it will trickle down

[RoLex 1]

we are taking preventive steps to minimize CTM scriptkiddie usage in the future

Are you going to shoot every single scriptkiddie in the head? Funny reply you have there. ;)

[Guest Toast]

Are you going to shoot every single scriptkiddie in the head? Funny reply you have there.

no but we are taking preventive steps towards ctm ddosing but u seem to focus more on me then what i write so i will not waste my time replying more..

[RoLex 1]

no but we are taking preventive steps towards ctm ddosing but u seem to focus more on me then what i write so i will not waste my time replying more..

Alright, sorry, I did indeed try to make joke out of your reply. Lets be more specific to the topic.

Could you please tell me what steps you and other dcdevs has taken to improve CTM flood detection?

[Guest Toast]

well start off by taking a look at rev 2159 and 2163 or 4 of DC++, the code there should be pretty easy to follow what it does thats a start and REF should be a good deterrent but seems most scriptkiddie ddoser cant read what that actual implementation does kinda nice that it actually exposes the source the hubs thats been used for the purpose so we have taken steps and more are being discussed each day.

[Big Muscle 1]

Neither rev2159 nor rev2163 really does something against DDoS attacks. Rev2159 only increases reconnect interval after timeout and stops reconnecting after procotol error (which is very rare case), almost no change in the reality. Rev2163 is controlling UPnP interface to automatically forward ports in your FW/router.

[Guest Toast]

2159 came out a discussion between flipflop and poy as a alternative for connection against web servers so yes it has something to do with ctm ddos since it makes less efficient since it wont reconnect as fast as older clients wouldnt call that nothing bm

now the other was a fix to the inital reconnection reduction that is dealing with the problem and the more active discussions we have in dcdev about this the more will come out of it

[RoLex 1]

2159 came out a discussion between flipflop and poy as a alternative for connection against web servers so yes it has something to do with ctm ddos since it makes less efficient since it wont reconnect as fast as older clients

Right, web servers, but I think BM:s feature in StrongDC++ which completely blocks connections to ports 80 and 2501 is more useful in that case, there are only 1 out of 1000 users who manage to put port 80 in connection settings. I assume that StrongDC++ doesn't allow to set port 80 in settings.

now the other was a fix to the inital reconnection reduction that is dealing with the problem

Good to hear, but still that's not a solution by my opinion.

I would do a very simple flood detection, to count amount of similar incoming CTM requests under specified interval. Most CTM flooders out there send requests every second, but ofcourse, the amount of requests and interval should be customizable in client settings. And some kind of customizable blocklist, where requests are filtered by connection address + port. Maybe some kind of expiration for blocklist, per hub session for example, or in minutes.

That would atleast give us the opportunity to protect ourselves from any kind of CTM exploitation.

Thank you.

[Big Muscle 1]

Blocking those ports is only temporary solution until something better is developed. One man did some exploration and he discovered that those ports are the main interest of DDoS attacks and that my workaround solved the problem. And it's logical to me because most webservers run on port 80 (and 2501 is used by hublists). This workaround seems to be better than blocking connections to certain websites only like DC++ does, because it prevents DDoS to all sites (of course, except those running on different ports).

There are also other DDoS prevention mechanisms in StrongDC++. For example:

- allowing only so many incoming connections how many CTMs your client sent

- allowing maximally 5 connections from same IP:port

- allowing certain amount of incoming connections per time (this is taken from DC++ but code is in "false" branch there, so it does nothing)

- thread stack size is decreased so it allows creating much more threads on 32-bit build which prevents remote crash by initiating DDoS attack (64bit build doesn't suffer from this issue)

This is solution made in older RevConnect - http://reverseconnect.cvs.sf.net/viewvc/reverseconnect/RevConnect/client/FloodTrigger.h?view=markup (when more than 10 connections in last 2 seconds is detected, IP will be blocked for some time)

Although all that things need improving, I think they are much more useful than blocking reconnect on protocol error or increasing reconnect time on timeout (done in DC++) which can't prevent DDoS attacks in any way.

[Guest Toast]

- allowing only so many incoming connections how many CTMs your client sent

- allowing maximally 5 connections from same IP:port

- allowing certain amount of incoming connections per time (this is taken from DC++ but code is in "false" branch there, so it does nothing)

- thread stack size is decreased so it allows creating much more threads on 32-bit build which prevents remote crash by initiating DDoS attack (64bit build doesn't suffer from this issue)

This is ok but i would like to see something more the first discussion that was actively taken with poy and flipflop to reduce is worthy by itself.

Solo development without communication is not always good (directed at bm) not meant to spite but as a hint that we need more communication with dealing with this issue and i do not exclude anyone as long as they dont troll of make stupid suggestions.

since this is a serious problem thats equal to botnet control etc so have some suggestions throw em out where it counts either in dcdev public or at adcportal or at launchpad cause it need to trickle down instead of being just a mod implementation (sure i can forward it but i would rather see an active discussion then a 3 way discussion)