[libtorrent] Is no_connect_privileged_ports really that useful?

[sledgehammer999]

I finally used the extra info in the peer_block_alert(libtorrent v1.0x) to
see why each peer block happens. (qbittorrent log)

The vast majority happens because of privileged_ports. I read the
documentation of no_connect_privileged_ports. It doesn't really make sense
for me. This is supposed to be a security feature to not DDOS a peer (by
us).
Is it supposed to protect the remote peer? How and why? If the remote peer
has chosen to listen to a privileged port isn't this HIS problem? Or
possibly he knows what he's doing. Why are we supposed to protect him? (if
we assume that all bt clients used this library)

Unless the meaning of this setting is something else. Or unless there is a
DDOS situation that I can't imagine. Can you enlighten me?

Thank you.

[arvid]

Post by sledgehammer999
I finally used the extra info in the peer_block_alert(libtorrent v1.0x) to
see why each peer block happens. (qbittorrent log)
The vast majority happens because of privileged_ports. I read the
documentation of no_connect_privileged_ports. It doesn't really make sense
for me. This is supposed to be a security feature to not DDOS a peer (by
us).
Is it supposed to protect the remote peer? How and why? If the remote peer
has chosen to listen to a privileged port isn't this HIS problem? Or
possibly he knows what he's doing. Why are we supposed to protect him? (if
we assume that all bt clients used this library)
Unless the meaning of this setting is something else. Or unless there is a
DDOS situation that I can't imagine. Can you enlighten me?

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.

[sledgehammer999]

That's what I thought. But isn't the same attack/rationale possible on any
non-privileged port?
The only difference I can imagine in this is that THAT peer(running on
non-privileged port) won't be a valuable DDOS target. He's an actual
bittorrent peer. A (forged)peer running on a privileged port MIGHT be a
valuable DDOS target because it probably runs a web service.

Post by sledgehammer999
I finally used the extra info in the peer_block_alert(libtorrent v1.0x) to
see why each peer block happens. (qbittorrent log)
The vast majority happens because of privileged_ports. I read the
documentation of no_connect_privileged_ports. It doesn't really make sense
for me. This is supposed to be a security feature to not DDOS a peer (by
us).
Is it supposed to protect the remote peer? How and why? If the remote peer
has chosen to listen to a privileged port isn't this HIS problem? Or
possibly he knows what he's doing. Why are we supposed to protect him? (if
we assume that all bt clients used this library)
Unless the meaning of this setting is something else. Or unless there is a
DDOS situation that I can't imagine. Can you enlighten me?

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.
--
Arvid Norberg