Weird Kad Nodes Id
Posted 21 December 2010 - 09:40 PM
As it is so obvious I wonder if there is a new research going on which eventually will result in a new paper about Kad?
Atm, I can't find those KadID's in the new Kad graph when searching for some made up file ID's close to their KadId's.
ed2k://|file|98000000|1024|98000000000000000000000000000000|/ ed2k://|file|9A000000|1024|9A000000000000000000000000000000|/ ed2k://|file|9B000000|1024|9B000000000000000000000000000000|/ ed2k://|file|9B220000|1024|9B220000000000000000000000000000|/ ed2k://|file|9B240000|1024|9B240000000000000000000000000000|/ ed2k://|file|9B280000|1024|9B280000000000000000000000000000|/
Nor can I find your own KadID in the network when using the same technique. So, if you at this moment still are suffering from this problem I can't come to another conclusion that your Kad node has been totally eclipsed by those fake nodes.
Posted 21 December 2010 - 10:31 PM
Also: Are you sure you are using official 0.49c? Given the fact that type (0) means Kad 1 and we dropped compability that in 0.49c, that seems a bit strange. Edit: Oh nm, you should upgrade to the latest version 0.50a
Posted 22 December 2010 - 10:52 AM
My apologies, but I don't have time to make a proper post right now. It's this Christmas thing...
Anyway check your verbose logs. I think the IP's can be found there. As once375ml posted 15 december 2010 - 03:08 AM I went through my verbose logs for that period and found some suspect activities. A lot of Kad: Sender (xx.xx.xx.xx) tried to update contact entry but failed to provide the proper sender key (Sent Empty: No) for the entry (xx.xx.xx.x) - denying update, starting at 2010-12-15 03:41:52 and ending at 2010-12-15 12:17:20.
2010-12-15 03:41:52: Kad: Sender (123.117.189.xx) tried to update contact entry but failed to provide the proper sender key (Sent Empty: No) for the entry (123.117.189.xx) - denying update 2010-12-15 03:41:52: Kad: Sender (123.121.171.xx) tried to update contact entry but failed to provide the proper sender key (Sent Empty: No) for the entry (123.121.171.xx) - denying update ... ...
over and out
Edit: All timestamps in GMT +1
This post has been edited by Nissenice: 22 December 2010 - 10:56 AM
Posted 06 January 2011 - 04:20 PM
Here are the IP's I've been keeping an eye on. So for those who don't want to try figuring out what is going on I suggest an update of ranges in ipfilters would be suitable.
184.108.40.206 - 220.127.116.11 /edit
18.104.22.168 - 22.214.171.124
126.96.36.199 - 188.8.131.52
184.108.40.206 - 220.127.116.11
18.104.22.168 - 22.214.171.124
Almost all of the contacts in these ranges are using UDP ports in either 25xxx or 35xxx range.
The Kad version they claim to be using is version 8. At first their KadID's looked just like they did in OP's post, but the last days they have become a bit more sophisticated as they are not as identical they were initially. Atm they match in their first 8-10 hexadecimal numbers.
What appears to be happening is the following:
There are a few alive fake-contacts your own client will get in contact with first. How many depends on the distance to their ID in relation to your own ID. At most I have seen 8-12 contacts in the list at the same time, but then our ID's have been VERY close.
If there is a search for a target ID close to one of these alive contacts ID's they will, if asked for, either respond with two new dead (at least initially dead) contacts or if one of the alive contacts is the closest contact to the targetID your client will ask for more contacts as the first two are not responding. The response will be another 11 more dead contacts. Now, if your own KadID is very close to their ID's most of them will be added to the list of contacts with type=3. If they still doesn't respond they will shortly be removed from your contact list. So far they have always remained dead when I've been watching (who knows, perhaps they dislike me? ) , but would happen if they came alive before that happens? I dunno, but it seems to me that they might exploting this "asking for more contacts if the first two were dead".
Until recently these dead contacts also were of Kad version 8, but the last days they are of version 6. Those version 6 IP's are scattered all over the world as far as I can see, with no visible pattern, afaik. So far I haven't seen any response from these version 6 contacts so it might be questionable if they are Kad nodes at all.
This post has been edited by Nissenice: 06 January 2011 - 04:36 PM
Posted 07 January 2011 - 02:11 AM
At this moment there are 4 contacts in the list of contacts on one of the mules (eMuleFuture v1.1) running atm.
All their ID's starts with 891B2D4C7.... All their IPs in the IP-ranges shown in previous post.
When searching for a non existent file created by using a FileID close to (actually I searched for an ID close to a dead contact of protocol version 6 one of the contacts announced just a few minutes earlier) one of their ID's one of these contacts responds with 13 nodes and the other responds with two nodes. All of them claiming to have a Kad version of 6.
The search for sources of the non-existent file was done on another mule (also eMuleFuture) with no ipfilter in use. Also, before anyone asks, the result is the same with the official client.
Here is the ed2k-link I used: ed2k://|file|test891B26C1|1024|891B26C1000000000000000000000000|/
And here is another one: ed2k://|file|test891B2B88|1024|891B2B88000000000000000000000000|/
Posted 07 January 2011 - 10:47 AM
Again i also already wrote that this attack is kinda easy to detect with some improvements, because the IDs are too close together and every client can figure that out. Of course the question remains what to do after knowing that those are fake nodes. I think one of the research papers had just this as topic, didn't get arround to read it completly yet, but will do by time.
Posted 07 January 2011 - 03:07 PM
Create a fakenodes.dat file, and later use it like ipfilter does.
Posted 08 January 2011 - 09:08 AM
It is not that simply. We only can detect that there is an attack. Not which one of the nodes are actually genuine ones and related to this we still want to find our keyword somehow. But again hopefully one of the papers offers more insight.
Posted 10 January 2011 - 01:44 PM
10/01/2011 14:09:38: Kad: Sender (126.96.36.199) tried to update contact entry but failed to provide the proper sender key (Sent Empty: No) for the entry (188.8.131.52) - denying update
10/01/2011 14:09:38: Kad: Sender (184.108.40.206) tried to update contact entry but failed to provide the proper sender key (Sent Empty: No) for the entry (220.127.116.11) - denying update
10/01/2011 14:09:39: Kad: Sender (18.104.22.168) tried to update contact entry but failed to provide the proper sender key (Sent Empty: No) for the entry (22.214.171.124) - denying update
10/01/2011 14:13:09: Kad: Sender (126.96.36.199) tried to update contact entry but failed to provide the proper sender key (Sent Empty: No) for the entry (188.8.131.52) - denying update
10/01/2011 14:13:09: Kad: Sender (184.108.40.206) tried to update contact entry but failed to provide the proper sender key (Sent Empty: No) for the entry (220.127.116.11) - denying update
10/01/2011 14:13:09: Kad: Sender (18.104.22.168) tried to update contact entry but failed to provide the proper sender key (Sent Empty: No) for the entry (22.214.171.124) - denying update
10/01/2011 14:13:09: Kad: Sender (126.96.36.199) tried to update contact entry but failed to provide the proper sender key (Sent Empty: No) for the entry (188.8.131.52) - denying update
This post has been edited by Riso64Bit: 10 January 2011 - 01:56 PM
Posted 15 January 2011 - 02:37 PM
I haven't checked this with all the IDs, but I suspect that if these version 8 nodes is asked for closer nodes and if they respond they responds with kad nodes sharing their first 5 hexadecimal digits and all of them claimed to be using protocol version 6.
0B565DBAC.... 0D63602B8.... 1A93E72FB.... 1FB015729.... 3B16E5B4C.... 3B16EE3D6.... 3F022B289.... 4192693F0.... 5375D698B.... 564C5E710.... 6032D69C1.... 623C180FC.... 74C9DD10D.... 75FF81B87.... 776772ED4.... 80AB86091.... 81A0917FA.... 88C06B8F9.... 891B2D4C7.... 8B009DDB4.... 8B325CE8E.... 8B32D5F6F.... 9D50961DF.... A0E09F595.... A1987A4D4.... A1A0A8E38.... A282413C1.... A2C8D7346.... DDC0747C6.... E73CE8B9C.... F2AE81358.... F32787566.... F5C5D6205.... F95F08DB1.... FD6FCF00C....
Yeah, I love the graph too. Very useful. Just can't stop watching it.
I have tried once to check key_index.dat, but I couldn't find anything obvious. Maybe I give it another try. I still have the file left. I suspect though that the keyword in question, if that's what it is, is written in chinese letters or in any other to me foreign letters and what to do then?...
Well, let's hope that noone gets the idea to create and inject superfakenodes in the network then.
Wouldn't we just move the problem up a level and with less nodes to control for good guys ... and for bad guys.
EDIT: and even more IDs of attacking nodes:
1A7BDD3B9.... 1E094571F.... 1EEAAB078.... 383A730BE.... 3847A8E55.... 3A1D5CDDB.... 53D5E6B70.... 60FE58CE1.... 6A954BFF7.... 82D3FCA50.... 85EE0CA3C.... 8680FD67F.... A853EE22B.... B9DC281BB.... BC58D2702.... C930980CC....
2566FF247.... 263EAA001.... 3FC7E0C07.... 78700D8A9.... 80F9ACE07.... 815633B24.... 82226F16A.... A96DFCECE.... A9745F59C.... AA72342E4....
This post has been edited by Nissenice: 16 January 2011 - 10:58 PM
Posted 16 January 2011 - 10:16 PM
Is this the end of the glory days?
PS. Here's another one:
The lack of responses here is not a result of the attacking nodes efficiency, but because I had set a very high lower limit on the file size.
This post has been edited by Nissenice: 17 January 2011 - 12:08 AM
Posted 16 January 2011 - 11:57 PM
It would be interesting what the source is through, there are basically only 4 options: Research, Attack on the Network, Stupid Mod/Client, Misuse for other stuff (like worms and co). Some could be found out (esp. if it is a client and if not if the software runs on enduser pcs or centralized servers) with a bit time and investigating into it, well see if i get to do in the next days/weeks
Posted 17 January 2011 - 05:52 AM
BTW, can anybody listed some keywords they are trying with, In Chinese? That may give us some clue of the sources and/or purposes.
This post has been edited by Enig123: 17 January 2011 - 05:52 AM
Posted 17 January 2011 - 12:07 PM
Posted 17 January 2011 - 04:11 PM
Yes, they seem to be down since this morning. The same thing happened nearly or about a week ago. But I think it was all up again less than 24 hours later.
I believe this is a sort of attack. I also get the impression that they are experimenting so it seems like it is in a research phase, but to me it looks a bit too big for a scientific study. So far I've found approx 60 groups of IDs distributed in the Kad space where their nodes are clustering about (see earlier post). I doubt though that this is more than half of all the IDs they are trying to attack. So, I think it's at least 120 keywords, that is if it's only keywords this all about, which are attacked.
Those two keywords I found above are the only ones found so far. Just pure luck I found them probably. What I had in mind when testing them was: Isn't pornography forbidden in China and haven't I read that you can't search for porn when using clients like xunlei, flashget etc and wasn't the case the same when it comes to the new easymule one year ago where the developers denied being thieves stealing the Kad code from aMule?
So if they are trying to prohibit people to get porn so what are their plans for vanilla mule and vanilla mods. The european servers are almost gone - the Chinese ones remains...
Well, if that's the purpose it looks though like QUITE a big project to clean KAD from porn.
PS. I tried some other obscene keywords too yesterday, which wasn't under attack... It would be interesting to test similar words in Chinese when those adversery nodes are up again.
This post has been edited by Nissenice: 17 January 2011 - 04:50 PM
Posted 17 January 2011 - 09:59 PM
Also, if indeed china itself (or someone bound to china) is doing serious attacks, the solution is fairly simple: We could just block all NodeIDs from chinese IPs. Chinese users could still use Kad, they would be jsut not used for routing tasks anymore. Of course this only works if the Kad network doesn't consists of too many Chinese (more than 30% would be bad, unfortunatly i really dont have any stats on this right now) users or the load for the rest of the network would become too big.
Of course that would really only be the last defence if everything else fails and they really do disrupt the network considerably.
Posted 07 March 2011 - 06:21 PM
As far as I can tell after checking a few IDs it looks like they are targeting the same ones as in post #12 above.
The IPs have changed a bit and are now in the ranges:
123.144.160.xx - 123.144.173.xx
123.145.160.xx - 123.145.198.xx