Denying distributed attacks

The most unfortunate thing about the past, the present and the future, is the ever growing thought of people that are using the Internet (that include DC) to cause havoc.

This havoc could problably most summarized into using distributed denial of service attacks.

You’ve seen it in action; The cause of dcpp.net’s disappearance and Hublist.org’s unresponsiveness during the past year or so.

To tackle the problem, we first need to understand how people are performing them using DC.

It’s quite simple. These people are in control over one or many hubs. They have operator-status, and are able to manipulate two things. First, they can re-direct your client to an address that’s their target. (Redirect to example.com to cause a bunch of users to connect to the server simultaniously.) Secondly, they are manipulatng C-C initations. When you say to someone else that you want to connect to them, you “say” your IP. (You know, the thing that identifies your computer on the Internet?) This IP can be altered by the hub. So you might have the IP “192.168.0.1” and say this, but the hub will change the message so the address is “192.168.0.2”, causing the other client trying to connect to the second address. (Since it believe that’s where you’re at.)

What can we do to prevent this, or at least minor the damage somewhat?

A few versions back, DC++ added a particular clever scheme. If it tries to connect to a hub but fail and it’s the first time DC++ has seen it (that is, during this session), DC++ will cease to re-connect. Only when a successful connect has been made, will DC++ start to re-connect if the connection fail. I urge all client developers to also add this, if you haven’t.

Another type of protection that was added to DC++, was to internally block certain addresses when users tried to connect to them. (Eg dcpp.net and hublist.org.)

A suggestion that was fairly hard pushed by Nev (do I need to say Y[n]Hub?) and Jove (the dude behind Aquila) was to block certain re-directs. These certain re-directs would be identified by looking at the port number that is being used in the re-direct. One of the propositions were that ports like 25, 80 and other known service-ports should be blocked. Another proposition were to completely restrict port numbers below 1024 (as they’re usually restricted/registered to a known service). The entire suggestion was faced with opposition. I didn’t and don’t like the suggestion. But I can understand wanting it. [I have no idea if the suggestion actually went into production in either hub software.]

Unfortunately, we need to come to a grip that no matter how much protection we add to new hubs and clients, there will always be those who are using old versions of their client or hub of choice. Which is exactly how people exploit DC. They are taking advantage of people’s resistance of upgrading.

We could always force people to upgrade, by using DC++’s (now deprecated) BadVersion in version.xml… Or perhaps by other hub operators to block those clients that do not have the above mentioned protected.

Having that said, I think hub list operators are the ones with much power. They are able to filter what hub are going to be displayed in the list. With information on who are running malicious hubs, the hub list operators can simply filter away the hub. This will lower the rouge people’s leverage.

Sure, one could build a database over “safe and good hubs” (or something similar to the information for browsers concerning phising sites), but I think it’ll be expensive and difficult to build.

Don’t forget that you can make topic suggestions for blog posts in our “Blog Topic Suggestion Box!”