DC++ CTM Proof

In a previous post I was wondering if the whole concept of centralization is obsolete or has major flaws. The problem that is bothering everybody in the last years is that clients can be used ( unwillingly ) as tools in distributed denial of service attacks. Jan Vidar Krey is proposing a hub refferal on c-c connections that can point to a source of CTM attacks via the messages that the client sends on first connection attempt. In this case an attacked entity can see the hub with problems/intentional flooding that is causing the attacks.

As a first step to prevent this kind of abuses in DC++, poy added a static IP protection for the major hublists that were attacked via the client. This kind of measure is just temporary since hublists can change IP anytime and it protects only them, not everybody else that can be attacked ( Also the fun part is that the hublist server is actually running a DC client and wants to download from other users, it can’t ! ) .  A second step was to dynamically resolve the hublist ip’s and block them for c-c connections.

The main idea that I considered is to practically check all the users on a specific hub to see if they actually are real. On CTM receive the client should not connect but send another CTM to see if that IP actually connects to them . This will make sure that the user is the actual owner of that specific IP address. Of course the biggest problem is if the user is passive, in which case it can’t send a CTM back. This could be against the protocol principles but it’s a solution to see if the other peer really exists. I don’t know if a RCM would do something good in this situation but it’s a start.

Another thing that should be done ( if not implemented already ) is that on c-c connections if the first attempt was unsuccessful then no further attempts should be done until the user at least reconnects or changes state ( passive/active ). Also the hubs should be trustworthy. In a previous post I suggested a way to make hubs trustful via a CA authority system, but most people were quite reticent about it. Perhaps this could be the only way to make hubs trustful. Warning messages will not help too much ( Strong DC implements such messages ) since most of the users either don’t read them or don’t care. We shouldn’t let users question this problem, but solve it for them. Continuous problems from the Direct Connect network might be a cause to mark DC software ( and DC++ ) as badware, which will definitely take down the network. It’s time to do something about it.

I’m hoping for more ideas how to make DC++ proof against CTM abuses and I’m waiting for opinions from you as well.

8 Responses to DC++ CTM Proof

  1. pirreparys says:

    Well a short answer, i do agree that it has to stop, but anouncing the hubs ip aint a answer it takes us to the level of the torrent trackers, if you do i don’t lol. the solution is very simple don’t allow msg to anything in a hub for a ip thats not persent and any hub allowing that (and that counts for ctm and reverse and searche} should be banned from hublist’s , sounds simple but putting our ip’s detectable to things like RIA and alikes is not what this P2P is about

  2. pirreparys says:

    o and ps since ADC0 is future dc standard, what is goig to help that hubs ip sending encrypted :)

  3. djoffset says:

    pirreparys: I don’t know what mean by that, but in any case this is not leaking any information, except in the scenario where you or someone else who is not affiliated with p2p can become bombarded with connections. In that case it is possible to figure out *why* that is happening.

    Currently this is happening to websites which are specifically targetted in effect creating a denial of service attack.

  4. pietry says:

    My main concern is : The hub is corrupted , eg the hub is sending false ctms to clients . This means there is nobody spamming the hub, the hubowner himself is running a script that sends ctms to flood somebody. The presumption I start with, is that the hub is untrustable. Even if such hubs are banned from hublists, they can still exist and get redirects from hubs that are present in hublists.

  5. pirreparys says:

    -First: Seems you still don’t get the main picture, alto all hubs are trying to prevent illigal transfers we do miss some of them, with the feature you propose anny isp log can show behond any doubt that the hub is responsible for that transfer in a court of law -Second: A problem inside a community like ours should be solved inside and not be putted on the victims side to take action, even in your hub pietry @ the moment of this post i can force a client to send a msg to a non hub ip -Third: the proposed solution is not going to help once dc++ is going to be ssl enabled, the target will not be able to get the hubs ip from the encrypted CTM message

  6. djoffset says:

    > alto all hubs are trying to prevent illigal transfers we do miss
    > some of them, with the feature you propose anny isp log can
    > show behond any doubt that the hub is responsible for that
    > transfer in a court of law

    No, it will only show that the connection used was setup via a specific hub. If your ISP logs that, then your ISP already logs it as it were.

    So, this changes nothing.

    > the proposed solution is not going to help once dc++ is
    > going to be ssl enabled, the target will not be able to get the
    > hubs ip from the encrypted CTM message

    Yes, that is a valid complaint if the protocol mandates an immediate handshake after connect (there are good reasons for doing that).
    So, it does require that the attacked party can set up a server that will complete the SSL handshake in order to obtain the information needed (identifying that the incoming bytes are an SSL handshake is fairly easy in any case).
    While that is suboptimal, it is still an improvement.

  7. pietry says:

    Pirre: I’m not getting the picture? This post has nothing to do with legal or illegal file sharing.
    If you have some bug you have found in my hub software then I suggest you report it for improvement if you really are for the best of the network.

  8. quicksilver666 says:

    This referrer is a nice idea…

    jucy will implement this in nmdc as well as in ADC as no problems were found with other clients..
    (“CSTA_000__RFurl” for ADC)

    hmm it allways pays of to have a look at this weblog from time to time..

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: