Today I added a new feature when compiling against libtorrent 1.0.x.
The peer block log indicates the reason why a particular ip/peer was blocked.
As it turns out many peers a getting blocked because they use a low port. The denying of this kind of peers is configurable.
The libtorrent logs say this about the setting:
no_connect_privileged_ports
if true (which is the default), libtorrent will not connect to any peers on priviliged ports (<= 1023). This can mitigate using bittorrent swarms for certain DDoS attacks.
I wonder if this is actually good practice or we should always allow those connections.
What do you say?
-or a third option: make it configurable in the advanced settings.-
Right now the execution log shows 3 blocked IP's because of low port being used.
The blocked peers are retrying to connect but each time is being blocked again. This has no influence on speeds at all and everything works just fine however.
The third option seems a good idea to me because there could be good peers also that are being blocked by using a low port number on purpose (don't ask me why). If people get to choose to disable or enable it at advanced settings thats fine, but I would leave it enabled as a default setting.
Why?????? It is the listening end that would be at risk when using a "privileged" port, because they have had to override to root/administrator permissions to use ports below 1023 . If "low ports" are going to be blocked it needs to restrict ports below 1023 from be used in the client for listening. What other idiots do it their concern.
Also what happens if there is are "web seeds" using port 80?
Other than ports 80 and 443 I can't think of any reason to have additional low ports open. It would be interesting to see what the actual port numbers were in the above listing. Are they port scans or web seeds?
[quote="Muzak"]
Other than ports 80 and 443 I can't think of any reason to have additional low ports open. It would be interesting to see what the actual port numbers were in the above listing. Are they port scans or web seeds?
[/quote]
From my understanding the peer port is used by us to connect to them. eg a peer tells us "hey you, I have torrent X. connect to me on port 61.". I don't really understand how this setting could protect the peer from DDOS. Unless someone poisons the dht/tracker and make them report ips with low ports. So the rest of the swarm tries to connect to that ip/port, which in reality is a server hosting a site.
From my limited knowledge you cannot poison the bittorrent dht this way. The dht nodes record the ip that has connected to them and not the one you are telling them to record. As for trackers it could be possible if the tracker operators are malicious.
Now that I think about it you could also be connected to a malicious dht node, or exchange peers with a malicious peer, or the .torrent itself might contain malicious peers/nodes.
As for trackers it could be possible if the tracker operators are malicious.
Trackers either operate on the default port for the protocol used (80 or 443) or specify the port in the URI, so blocking 'low' port numbers there is going to prevent qBT connecting to 99% or more of the public trackers, and the 'default' DHT port is 6881.
I don't really understand how this setting could protect the peer from DDOS
It wouldn't, ... Any identified port could be the target of a DoS or DDoS attack, about the only thing it MIGHT prevent a hijacked armada of BitTorrent clients from being used as the "bot net" for attacking a remote web server or mail server. If that is the intent, it's hardly worth the effort because there are far easier ways of creating a "bot net" or a network of zombie machines than hijacking a torrent client swarm and redirecting that to an attack vector.
As for trackers it could be possible if the tracker operators are malicious.
Trackers either operate on the default port for the protocol used (80 or 443) or specify the port in the URI, so blocking 'low' port numbers there is going to prevent qBT connecting to 99% or more of the public trackers, and the 'default' DHT port is 6881.
What I meant is that a malicous tracker could respond with fake peers with low port numbers. This way it could instruct an attack to specific site/network.
The same goes for a malicious dht node.
I think I should ask arvidn for his input. From my understanding this setting doesn't do much in terms of security.
Should be configurable in advanced, where users could disable it.
To be honest, most people just use old (hell, very old) uTorrent in this country.
So ... like 95% of the users will be vulnerable and stay vulnerable here.
Even if I check around my current torrents, almost everyone - even international peers - use older clients.
I think the best solution is to have it configurable in advanced settings if it gets implented, but then again im thinking ''Is it needed/necessary to have such a setting'' in the first place?.
Its true that there are alot of users using old versions of any client out there (especially old uTorrent users) and probably never had any issues with it. The number of peers that are using such low ports are countable, max 5-10 at its highest I think, and could be good peers also that are being blocked. I would probably disable it right away if it gets implented.
I think I should ask arvidn for his input. From my understanding this setting doesn't do much in terms of security.
I do not have a strong opinion on this, and I'm not all that confident
that
this logic has more up sides than down sides.
The scenario is some one placing a bunch of DHT nodes close to very
popular swarms. When peers go there to ask for other peers, these nodes
can respond with just a single IP:port, pointing to its DDoS victim.
The same thing is possible if the attacker runs a tracker that people
use,
or if a popular tracker is hacked by the attacker.
For large swarms, say 100k peers, each peer may try to connect to
this peer (say) 3 times before giving up. That's 300k SYN packets
potentially to a web server (or some other service which is assumed
to be important because it's running on a privileged port).
Now, unless the churn is really high on the swarm, that's probably not
a very effective attack, but for a small web site it might be.
If there are a lot of legitimate bittorrent peers running on privileged
ports, it might make sense to turn this off by default.
From that my opinion is to enable it AND not have it as an configurable option. IMO a configurable option will just add bloat with no measurable usability. I don't think someone will REALLY need to disable this.
I agree with him, to make a DDoS attack 'effective' using a torrent swarm would require hundreds of thousands of clients in a single swarm, and even then, given that any client will not make continuous requests to a 'tracker', they would make a less than effective 'bot net' and what would be 'thrill' in bringing down the 'blog' of some non-entity in 'cyber-space' that only 100 people on the planet even know about. It might annoy three people for about twenty minutes at three AM some Sunday, but it won't get them the "recognition" they crave.
