On Mon, Oct 21, 2024, 6:28 PM Alexander V. Makartsev <avbetev@gmail.com> wrote:
On 21.10.2024 16:59, Eduardo M KALINOWSKI wrote:they actually speaking the BitTorrent protocol? Could this be caused by simply connecting to the host (in some kind of port scan), or perhaps connecting and probing for some other vulnerability, maybe not even related to BitTorrent (something like "GET /admin?user=admin&password=imasuperhacker HTTP/1.0")?It doesn't look like some port scan or automated exploitation attempts. Those are usually one-offs.
Instead, these suspicious connections successfully negotiate with my torrent client and stay connected, downloading that one ISO file indefinitely.
If I manually throttle these connections they disconnect after some time and soon after a new connection from another IP from the same subnet or different network establishes.
Maybe choose a couple of those subnets that they bounced-to after you throttled them. Look for other legitimate-looking connections in the logs from that same subnet over a longer time-span. Are they burning through whole subnets at-a-time which show no other legitimate connections to you? Or does it seem more scattershot than that? Examine the numerical values of the addresses. Do they seem to be working in a systematic fashion through the octets and subnets? Or does it arrive looking more random than that?
So it is an automated distributed process, the only thing still missing is the purpose of it.
I know there are techniques to fool DPI systems and mask SNI of the outgoing HTTPS connections, but AFAIK they should go to 443/tcp port and my torrent port is different.
I'm pretty sure that other peers of tracker at "bttracker.debian.org" are having exactly the same problem.
