Nevertheless, since 2 day I am observing a quite insistent kad flood from chinese IPs (I estimate that most of the sources are in south-east asia).
Hundreds of messages like this:
11/11/2017 16.35.49: Kad: Massive request flood detected for opcode 0x21 (0x21) from IP 119.140.73.41 - Banning IP 11/11/2017 16.35.52: Kad: Massive request flood detected for opcode 0x21 (0x21) from IP 1.80.219.72 - Banning IP 11/11/2017 16.36.30: Kad: Massive request flood detected for opcode 0x21 (0x21) from IP 222.209.235.125 - Banning IP 11/11/2017 16.37.03: Multiple KadIDs pointing to same IP (183.62.21.45) in KADEMLIA(2)_RES answer - ignored, sent by 113.13.163.82 11/11/2017 16.37.03: Multiple KadIDs pointing to same IP (183.62.21.45) in KADEMLIA(2)_RES answer - ignored, sent by 113.13.163.82 11/11/2017 16.06.07: Ignored kad contact (IP=183.62.21.45:22541) - too many contacts with the same IP (global) 11/11/2017 16.06.07: Ignored kad contact (IP=183.62.21.45:22541) - too many contacts with the same IP (global) 11/11/2017 16.06.07: Ignored kad contact (IP=183.62.21.45:49153) - too many contacts with the same IP (global) 11/11/2017 16.11.54: Rejected value update for legacy kad2 contact (123.5.110.112 -> 125.89.88.53, 4 -> 4) 11/11/2017 16.11.59: Rejected value update for legacy kad2 contact (123.5.110.112 -> 61.165.163.190, 4 -> 4)
I am surprised that their attack (or sort of attack) uses ways that emule can still detect and log. This since I assume that the code about attack detection and flooding, in emule and mods, is stable at least from 2010. Thus without improvements to detect possible new ways of attack. It is likely that the attacker/flooder is using the most naive way, that is, just flooding the network.
I am also impressed how the code reacts. I know that emule is mature since 0.48, nevertheless is also likely that has a lot of little flaws that may bring the application to halt under some conditions, instead it just chugs along banning IPs and rejecting legacy values.
The only problem may be the continuous bandwidth usage. I will likely block those requests, slowly (their IP won't change quickly), on the main firewall. This would be still useless if the flooder floods without caring for replies, my bandwidth will still be used.
I know that there exists super updated ip filters, but I prefer to collect actual attacks and strike them at the main gate of my network.
Maybe this flooding is due a botnet trying to use kad. I read around that a lot of good and bad stuff use kad - not necessarily that implemented by emule though, - since it is pretty reliable as network concept.
By the way, nowadays that the ed2k network shrunk a lot and it is a niche p2p network, it is surprising to see a kad "attack".
edit. It seems like a repetition of those two threads
https://forum.emule-...howtopic=159307
https://forum.emule-...howtopic=151610
so attacks that go on for years. I wonder why.
updated: I was able to bring the flood down (could be that the attackers decided to slow down in the same moment).
In the main firewall I added like 30+ "/24" ipv4 segments, like "111.246.113.0/24" dropping their incoming packets and soon their request petered out.
I got the addresses from the emule log, searching for banned IPs or "kad flood request" or "multiple kad id" and then extending the ban to the entire /24 segment.
In total I banned some 9000 ip addresses, at this day located in south-east asia. Surely in the ban I put also innocent nodes, but it is a price I am willing to pay for the moment.
update2: impressive how one can learn even after years of using the same application that is mostly unchanged (for kad at least).
As far as I understood reading the logs, plus some minimal knowledge about network protocols, it seems that the KAD traffic is nonetheless encrypted if one sets encryption required (I thought only transfers were encrypted).
Not only that. Nodes that are able to spam with the kad protocol, generating log messages containing "flood", are likely to have successfully connected to our emule client due to the required encryption.
Therefore banning them (especially on the firewall) ensures that there is no initial exchange of encryption keys and so they are effectively unable to communicate freely. This brings the flood to an halt because it is likely that those "flooders" are programmed to flood only after being acknowledged.
Indeed when external nodes attempts to communicate on their own, without that our client acknowledge the connection, the following happens
11/11/2017 22.20.42: Client UDP socket: prot=0xe4 opcode=0x29 sizeaftercrypt=119 realsize=119 ***NOTE: Received unrequested response packet, size (117) in Kademlia::CKademliaUDPListener::Process_KADEMLIA2_RES: 222.20.99.240:16821
Of course I may have understood wrongly because I tried to infer information from the log, given the setup of my client and some network knowledge. I did not check emule's code because it takes time to be analyzed, way more than simple logs.
This post has been edited by pier4r: 11 November 2017 - 09:44 PM