How not to become a bot in Bittorrent DHT and other P2P networks
The Bittorrent DHT network allows you to find hash sources from a magnet link hash . The network consists of nodes that can be either Bittorent clients or malicious programs that interfere with the normal operation of the network. They prevent the client from receiving torrent sources, redirect requests to the attacked nodes, and fill the list of nodes with useless addresses.
While I was working on a peer and seed counter ( DHT Scrape ) on this network, I came across these types of attacks.
Port number 1
Some nodes returned a list of nodes where the first port was specified. On the Internet there was a recommendation not to connect from 0 to 1024 port. They contain critical services for the operation of the Internet. The node that sent addresses with a port in this segment is ignored.
Mirrors
There are nodes that simply return the packet sent back. It turns out that we ask ourselves and answer ourselves. Since the node answered correctly, it is marked by some clients as active and its address will be transferred to other nodes. In order to exclude such nodes from the network, you need to check this option.
Flood ports
Some nodes issue the same IP with a bunch of different ports. This can happen to the host behind NAT which changes the outbound port of the host. In this case, if a node with such IP and ID has already been confirmed (i.e. there was a connection with it), new information is discarded. Otherwise, the last or random record is used for verification.
Token
Each packet has a token that allows us to determine that our request has reached the addressee and he answered us, thereby eliminating attacks with address spoofing. But you need to check that the token (like the rest of the lines) does not crawl out of the package. This may allow reading data from the memory following the packet.
Timer
The token is not a panacea for incoming requests with a fake address. In this case, only 2 consecutive requests per second from one IP are allowed. In the case of more, they are simply ignored.
Local addresses
Some sites return local addresses that are accordingly inaccessible from the Internet. This can also be the internal address of the router. These addresses should also be ignored unless of course they are received from a host on the same local network.
We publish only trusted sites
When we are asked a list of nodes from the database of nodes, only those are selected from which we received the correct response to our request (active). The rest (uncertain) are interrogated gradually and are removed from the database in the absence of an answer (dead).
The G2 network has recently suffered very much from the fact that a large number of dead node addresses are running in it. This slows down network entry and search.
We store the base of nodes
After a long break in the client’s work in the nodes database, all entries become expired. But the client must use them to enter the network before receiving a sufficient number of active nodes. If all nodes are dead, then the client accesses the input nodes. In my experience, even a very old base with a sufficiently large number of nodes allows you to enter the network.
Filter bits
To obtain the number of feasts and distribution seeds in the network, the Bloom Filter is used . Fake nodes can fill it with units and thereby distort the numbers. Therefore, data from at least three nodes is compared.
Send ping before reply
In order not to participate in primitive DDoS attacks, before sending a large packet, we send ping to the host. With the correct answer to the ping, we send a large packet.
Conclusion
I hope this article helps you write more efficient and secure clients for P2P networks.