Handling CTM DDoS (ADC + NMDC)

great idea :)
But hub port should not be used as Ref because one hub can use multiple ports. And result can be that 2 users on the same hub can actually use 2 different ports for same hub

I don't see why that is a problem, but I do see problems omitting it.

Any info in ref is useful since if there is a rouge hub out there used for CTM spamming sites like adcportal any info about open public ports etc are useful when reporting it to its isp.

An address is not complete without a port. If the attacked person knows the dns then what? It needs a port scan to find the hub?
One should get to know at least one working dns:port to get to the hub. The hub may be using other ports/dns that's not important. The important part is identification.

It's been a while since I looked at the ADC spec, but there's no need to
have a refe(r)rer... You get the CTM with a SID and a token... That's enough
to connect the connection with a user and a hub... The SUP needs to be
changed in the protocol, too... Not a "simple" change.

arne has said that no updates will be incorporated in the NMDC part...

--
Fredrik Ullner

Fredrik, that is totally missing the point.

This "extension", should explain where a connection originates from, but not primarily for a client's convenience, primarily for handling DDoS.

As I tried to explain above, a client is merely expected to ignore the extra support information when it is received. A client should deduce; I don't support the "Ref=dev.myhub.org:1234"-extension, so I'll just ignore it silently. That is what I described as phase 1 -- most clients, including DC++ is already compliant here.

The second phase is for the clients to actually send the extra information when it is connecting to a host, in order to indicate *where* the connection was initiated from. That's phase 2, and the actual work that needs to be done. It is totally OK if not every client has this extension, as long as *some* will send it, it is possible for whoever is attacked to get a clue about who is behind the "attacks" that have been going on for days (ask Toast!)

This solution provides a generic and simple way to communicate exactly that, and is much better than hardcoding this as copy-pasted from a dc++ patch:

+ protectedIPs.push_back("dcpp.net");
+ protectedIPs.push_back("hublist.org");
+ protectedIPs.push_back("hubtracker.com");
+ protectedIPs.push_back("dchublist.com");
+ protectedIPs.push_back("adchublist.com");
+ protectedIPs.push_back("adcportal.com");

Yes, these are the sites that have been down due to the problem this particular bug is proposing a fix for, can you imagine the time it takes for this patch to be merged into DC++, until enough people actually upgrade to it?
Let alone, at least one of those addresses are closed already...

My 2 cents.

I want to see something comment response from arne since he is the lead dev anyways is his opinion that matters in the end in anycase the nmdc problems thats going on needs to be resolved and not ignored that might lead to far worse problems.

This is just like Referer in HTTP, and will work in just the same way, being able to track down where requests originate from. Very useful.

To not implement this in nmdc or/and adc will just mean that it remains impossible to track down where DDOS attacks originate from. Only implementing in ADC just does not make sense. :)

I will implement this in peeraware, and I believe dc++ and any clone should do the same.

Hm, the ADC spec is a bit unclear on whether adding RF to SUP would be allowed - on one hand any additional flags should be ignored but SUP stands out in that the allowed flags are specified in the header of the description...

In general, once a hub has been identified as spammer, what then?
What about referer spoofing?

Spoofing can be expected, but as long as a single client has the correct information and that information ends up in logs, it can be used to identify the 'unfriendly' hub.

I hope that this suggested improvent will be implemented (or ofc something else that gives the same result) as a step in the direction that client devs take action against the ones that uses dc clients as a source for botnets.
It has gone on way too long without any actions imho.
/F

I agree, the ADC part of this is the part that worries me.
The NMDC part is actually the most straightforward change as such. Jonny has already implemented it in peeraware (that was fast!).

For instance uHub will disconnect any client that does not report HSUP [AD|RM][xxxx] where xxxx is not exactly 4 bytes alpha numeric, although that is a hub.
Alternatively, this can be done using a forced STA message.

Example:
CSUP ADBASE
CSTA 000 RFadc[s]://hub.example.com

Perhaps more elegant?

> In general, once a hub has been identified as spammer, what then?

That's out of band and out of scope. If you are attacked for days, weeks or months, then you contact the ISP of the attacker, or contact the relevant authorities.
The irony is also that hublists have been attacked systematically so far, it would be possible as a next step to remove them from hublists so that users do not join these hubs. Going even further, it is also possible to implement client based block lists, which are updated regularily without updating the client software. But, that are just future possibilities and way out of scope for this particular change...

> What about referer spoofing?

In any case, the address can give the attacked party information about who is behind. Likely the attacked party can verify this information by following the trail there to confirm the information, by for instance joining, and checking if the hub allows spoofed CTMs. A DDoS hub is likely large and open in order to be effective (that's just speculation, though).

Spoofing the referer itself would require a rogue client. In order to pull off an attack of the magnitude we have seen recently one would need thousands of these rogue clients connecting from different IPs using spoofed referers. While we are at it and someone actually has this type of capability, they can easily perform far more effective DDoS using other mechanisms than talking ADC/NMDC to webservers. Unless the idea is to blaim an unsuspecting hub, but that information still should be verifyable like described above...

> CSTA 000 RFadc[s]://hub.example.com
why not simply "CREF adc[s]://hub.example.com"?

That's an option, but an option that requires much more from what I refer to as "phase 1", it's a whole new command that all clients must be able to handle (ignore). This does require a new ADC spec too.
I expect some clients might terminate the connection if it were to get a "CREF" (remote end is sending crap, let's hang up!), but I might be wrong...

The good thing about STA is that it is allowed to send at any point according to the spec as it is. The SUP change is somewhat stretching things on the other hand.

I like STA much better for two reasons - it doesn't break the spec for sure and it's more in line with the intended use of the command - sup was never intended to convey this kind of information while sta could be...

As to adding a separate command, here's the relevant quotation: "Clients must ignore unknown/badly formatted messages" - that should be fine too...

so the question is: should we treat this as a status update or is it enough to mandate a separate command? also relevant would be how this works in practice? do clients actually ignore unknown messages?

Then I suggest:

"CSTA 000 Ref=adc[s]://<host>:port"

SHOULD be sent immediately after the CSUP for the connecting client.

uhm, it should be a flag if anything...
CSTA 000 RFadc://bla:port

(notice the double space for an empty description)

I don't think that is important:

CSTA_000_Ref=adc://bla.port
vs
CSTA_000__RFadc://bla.port

Adding it as a flag is OK, but that suggests it is machine readable.
I suggest adding Ref=adc://bla.port as a comment of the STA instead of as a flag, since that is essentially a human readable string, and since it is in line with the NMDC change.

But, In any case, this is just hair splitting, I personally don't care that much, and technically it is a one byte difference.

You will probably be first to implement, so, you choose.

how made ddos attack free client

1) don't allow use port's lower than 9000 for downloading/uploading
2) allow connect servers only lower than port 9000
3) solution, ddos attack free client

The End.

Fair enough, but it breaks alot of existing clients. Might aswell force passive mode for all clients -> problem solved.

well this depends 100% how DC++ add those steps, it can add all of then in one time or one by one

if it want less victims then i recommend add one by one

passive mode don't solve problems for ctm attack it only make problems worse for p2p, what is point for p2p if all users are passive?

I am sorry. I'll try to refrain from using sarcasm in the future.
My point is, that your change is very radical, and it would break for many users, so, you could in effect just disable p2p altogether.

Jokes asside, I do not like the separation of client and server either. For instance I am working on a client that is also a server, on the same port, and there are others also, like PeerAware.

This change would in addition to breaking existing clients, break that, and that is in my opinion unacceptable.

PeerAware and DC++ are not same thing, this is DC++ section what we talk about here
as i know DC++ don't have server and client in one software so i don't see the problem at all in here.

and if dc++ have server/client in same software i still don't see the problem how it can make problems for downloading/uploading and connecting the server

Well, your suggestion is forcing high port numbers. A change I do not beleive is needed.

thats true 100%, as we don't need fix CTM attack at all, why even someone want fix that?? CTM Attack is soo fun in first place. (ironic)

if you don't belive that uploading/downloading needs high port then you just don't get my post first place.

i don't start explain why DC++ or other dc client's should start use port limit from 9000 for downloading/uploading

if you know CTM attack you should also know why 9000 is good.

Is implementation in bzr1611 really valid according to this report/spec?

This report states "when a client connects to another client it will send the address of the hub", but implementation does "when a client connects to hub it will send the address of the hub".

I think it has no meaning to send to hub its own url. It should be send in client-client connection and in client-hub connection.

oops.

that means that we can't send the ref as part of supports for nmdc since supports is only sent after lock has been received...I put it in the pk that isn't used for anything useful as far as I remember, let me know if there are compat problems...

It works if the connecting party sends first the message

which i think it's happening