You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This one's a bit peculiar and I'm not sure if it qualifies as a bug, so feel free to close. But I wanted to draw attention to it.
Today I noticed that one of the threads belonging to the qbittorrent-nox process was constantly at 100% cpu usage.
I first checked using strace and it seemed to be doing normal stuff, sending packets, receiving packets.
What caught my eye in the strace output was this:
IP addresses are usually distributed quite randomly, so qBt organically interacting with this many IPs in the same subnet is statistically unlikely.
I also checked all my active torrents and couldn't find a single of these IPs in the peer list.
Next I used tcpdump to capture all traffic to/from the relevant subnet (190.80.24.0/24).
In the ~20 seconds I captured Wireshark counted more than 800 unique conversations happening with the port qBt was listening on.
Almost all of the 256 IPs in that subnet were involved (that includes .0 and .255).
What I tried next was to block all traffic from 190.80.24.0/24 in the firewall. The CPU usage instantly returned to normal levels.
The last thing I tested was to remove the firewall rule. It didn't take long for some suspicious CPU peaks to appear and the 100% usage returned after about half an hour.
Unanswered questions:
what exactly is happening that uses so much CPU?
does qBt/libtorrent have any built-in protections against this?
could this be a bad actor? if so, what does he gain from this?
has anyone else seen this?
Steps to reproduce
run active installation of qBt
???
Additional context
I can share the PCAPs if they're useful.
Log(s) & preferences file(s)
No response
The text was updated successfully, but these errors were encountered:
does qBt/libtorrent have any built-in protections against this?
qB restricts a number of active connections (Settings > Connection > Global maximum number of connections) to 500 by default. This could not really help if the connections are fast pacing though and total count doesn't make it enough to hit the limit.
could this be a bad actor? if so, what does he gain from this?
Yes. Who knows.
has anyone else seen this?
Yep, different kind of attacks will happen, especially if you have a static IP. Torrent clients basically advertise their existance to the whole world via DHT.
So you have no other choice than utilizing firewalls. The client itself also supports IP filters, but I guess it will continue to drain CPU to reject connections (and also spams into the log), so OS-level firewall it the way to go I believe.
Changing your client port could help, at least temporarily, but chances are attackers will find the new port. Switching IP also could help, if possible.
qBittorrent & operating system versions
qBittorrent: v4.6.4
Operating system: Ubuntu 20.04
Qt: 6.7.0
libtorrent-rasterbar: 2.0.10.0
What is the problem?
This one's a bit peculiar and I'm not sure if it qualifies as a bug, so feel free to close. But I wanted to draw attention to it.
Today I noticed that one of the threads belonging to the
qbittorrent-nox
process was constantly at 100% cpu usage.I first checked using strace and it seemed to be doing normal stuff, sending packets, receiving packets.
What caught my eye in the strace output was this:
IP addresses are usually distributed quite randomly, so qBt organically interacting with this many IPs in the same subnet is statistically unlikely.
I also checked all my active torrents and couldn't find a single of these IPs in the peer list.
Next I used tcpdump to capture all traffic to/from the relevant subnet (
190.80.24.0/24
).In the ~20 seconds I captured Wireshark counted more than 800 unique conversations happening with the port qBt was listening on.
Almost all of the 256 IPs in that subnet were involved (that includes
.0
and.255
).What I tried next was to block all traffic from
190.80.24.0/24
in the firewall. The CPU usage instantly returned to normal levels.The last thing I tested was to remove the firewall rule. It didn't take long for some suspicious CPU peaks to appear and the 100% usage returned after about half an hour.
Unanswered questions:
Steps to reproduce
Additional context
I can share the PCAPs if they're useful.
Log(s) & preferences file(s)
No response
The text was updated successfully, but these errors were encountered: