Written by yours truly - With collaborative contributions from the following individuals:
Lord_Zero
Introduction
Hubs today are not like they were years ago. Today, there exist many people using hubs for malicious purposes, and it is this exact thing that should raise concerns to people who run hublists.
A good hublist will provide a reliable service to both hubowners and users. The hubowners should be provided with a reliable server that will be always available for their needs and supportive in its responses to questions. The users of a hublist should be provided with a safe, impartial, and neutral list of hubs which not only consist of real users, but also do not compromise the experience of the user.
The experience of a user can be compromised by the following: The use of their client to participate in an attack against another server.
To ensure that the occurences of such compromise are minimized, certain measures can be taken. This page describes the known process of implementation of such a detection, which is a simple process that only takes a little bit of modification of your pinger. Feel free to discuss this idea further in QSDC DAG Public Hub, where QSDC, NMDC, and ADC are freely discussed, at qsdc-public.qsdc.org:2424 . Your input, if approved, will be added here with proper credit and acknowledgement.
Implementation
The simplest way to implement CTM detection is to keep track of the CTM count from a hub during a ping session. Most hubs send you CTM data after sending the MyINFO collection, and if you have sent $BotINFO early in the handshake, they will just immediately send $HubINFO after it sent the MyINFOs. There is a simple way around this. After $HubINFO is received, the pinger can linger for a few seconds in the hub to keep track of CTMs. If two or more of the addresses in a 3+ CTM collection are the same, it is likely that the hub is being used to ddos someone, and should be either banned or notified of its vulnerability. The most effective treatment for such hubs is a ban, since many hubowners use their own hubs to CTM flood and do not have any regard for warnings. Your best bet is to round up CTMs from a hub within a 5 second period of time. If there are 3 or more CTMs, check the IPs for any doubles. If all 3 IPs are the same in the collection, you are very likely to have a CTM attack. You can also store an array of structures containing each an IP address detected along with how many times it recurs. If the time of recurring is more than one third of the CTMs detected, and CTMs count in the session is more than 3, the hub is likely being used to attack.
It must also be noted that the detection described in the above paragraph does not work for all hubsofts due to a number of reasons. The following are possible ways that the detection above cannot be performed:
1. Some hubsoftwares disconnect the pinger once the pinging is finished, not letting it linger to get traffic afterwards.
2. Some hubsoftwares do not allow CTMs to be passed to pingers.
The way these two circumstances can be worked around is to have two bots log into each hub. One bot will be the actual pinger, and another bot will login as a normal user to detect any traces that make a CTM flood evident. In any case in which both instances cannot connect to the hub, the bot that made it into the hub can manage the task of traffic detection. This scenario was presented by Lord_Zero and, if the solution to such the problem scenario is implemented, will make detection of CTM floods even more accurate.
Example
2/7/2008 10:23:28 PM *** Received CTM from: rotsman.bounceme.net:415 - RockyPinger 216.220.40.244:80
2/7/2008 10:23:28 PM *** Received CTM from: rotsman.bounceme.net:415 - RockyPinger 216.220.40.244:80
2/7/2008 10:23:29 PM *** Received CTM from: rotsman.bounceme.net:415 - RockyPinger 216.220.40.244:80
2/7/2008 10:23:30 PM *** Received CTM from: rotsman.bounceme.net:415 - RockyPinger 216.220.40.244:80
2/7/2008 10:23:33 PM *** Hub is banned for CTM Floods: rotsman.bounceme.net:415 - Number of packets: 6
Dev Zone
