# Bittorrent firewall ports & security

## grant123

I'm using the transmission bittorrent client and I'd like to open only the ports I need on my shorewall firewall which runs on the same machine.  Port 10000 is specified in the transmission preferences so I'm opening firewall to net source port 10000 udp/tcp and net to firewall destination port 10000 udp/tcp.  It works, but I think I should be getting more peers and I get a lot of firewall to net rejections in the log across a wide variety of ports.  Is there a better config other than opening all ports?

I'd also prefer to keep all inbound ports closed on this machine.  Is there a way to close all inbound bittorrent ports but keep the functionality of the application?

----------

## Yuu

Hi grant123,

I'm not a network expert but.. How could you know the peer's source ports ? I think you just can't, that's impossible to predict.

Quick explanation : 

- destination port = the port that you open to allow people to connect to you (example : you're opening the destination port #80 for apache)

- source port = the port that people uses to connect to your destination port (example : A uses port 23824 to connect to your port #80); and as far as I know, it's a random port given by the OS.

Of course your bittorent client is working, because you only gets the peers which are connecting to you, but you can't get the peers which wants you, to connect to them (mostly misconfigured clients or firewalled connections).

So, my advice is : keep the firewall, at least on incomming packets, but allow everything on the outputs packets. With iptables, I know that you can add rules for a specific user (with -m owner --uid-owner=<uid>), so maybe you could do the same with shorewall.

PS : I hope that my little explanation is clear, english is not my native language; and I'm not a network expert  :Wink: 

----------

## grant123

 *Quote:*   

> How could you know the peer's source ports ? I think you just can't, that's impossible to predict.

 

I agree.  When I unblocked the 10000 source port it was from the firewall to the net.  I realize now that transmission doesn't use a predictable/definable source port when making outbound requests. 

 *Quote:*   

> allow everything on the outputs packets

 

I'd rather not do that.  If bittorrent used a predicable/definable source port when making outbound requests, it would be simple to open the firewall for outbound requests from that source port.  Is there anything else I can do to avoid opening all outbound ports?

Am I the only one not comfortable leaving an inbound port open for bittorrent?

----------

## Yuu

For your last question, maybe you could : create a dedicated user to your bittorrent client (something like torrentuser)

chroot your torrentuser

block all output packets (iptables -P OUTPUT DROP = the default policy to drop all ouput)

only allow sending outputs packets from this specific user (iptables -A OUTPUT -p tcp --sport 1024:65535 -m owner --uid-owner torrentuser -j ACCEPT)

only allow incoming connections from your specific port (iptables -A INPUT -p tcp --dport 10000 -j ACCEPT); it's because you can't filter input packets with a specific owner

and drop all the connections that are not associated with known connections (iptables -A INPUT -m state --state INVALID -j DROP and iptables -A OUTPUT -m state --state INVALID -j DROP)

That's just a more secure idea, but yes you're still allowing any connections to your bittorent client; if you don't do that, you won't be connectable. It's like you would like to deny specific ranges of ports allowed to connect to your web server. So sorry, I don't have a solution for this :/

Also, I know that I gave you the rules for iptables and not shorewall, but I don't know shorewall's syntax. Maybe you'll be able to translate yourself the rules, or find someone who could.

Edit : corrected some typos

----------

## grant123

Thanks Yuu, that's very helpful.  Shorewall is just a frontend for iptables so it's easy to translate.

----------

## Hu

 *grant123 wrote:*   

>  *Quote:*   allow everything on the outputs packets 
> 
> I'd rather not do that.  If bittorrent used a predicable/definable source port when making outbound requests, it would be simple to open the firewall for outbound requests from that source port.  Is there anything else I can do to avoid opening all outbound ports?

 Could you explain why this is an issue?  Generally, the only reason to restrict outbound ports is if you expect one or more locally executed applications to behave in a manner contrary to your network security policy.  For example, you might not want users with a shell account to be able to connect out to attack other machines.  For a single user system, I would expect that you trust yourself to run only "good" applications.

 *grant123 wrote:*   

> Am I the only one not comfortable leaving an inbound port open for bittorrent?

 Why are you uncomfortable?  There is a political risk that you will be persecuted for running a P2P client, but that risk applies whether or not you allow inbound connections.  There is a technical risk that a remote user could connect and send a message that your P2P client handles in a manner contrary to your intended security policy, but that can be mitigated through a combination of good configuration and standard measures to harden any network-facing program.

----------

## grant123

 *Quote:*   

> Could you explain why this is an issue? Generally, the only reason to restrict outbound ports is if you expect one or more locally executed applications to behave in a manner contrary to your network security policy. For example, you might not want users with a shell account to be able to connect out to attack other machines. For a single user system, I would expect that you trust yourself to run only "good" applications.

 

It's just a matter of closing everything and only opening what's specifically needed.  I think that's a good policy.

 *Quote:*   

> Why are you uncomfortable? There is a political risk that you will be persecuted for running a P2P client, but that risk applies whether or not you allow inbound connections. There is a technical risk that a remote user could connect and send a message that your P2P client handles in a manner contrary to your intended security policy, but that can be mitigated through a combination of good configuration and standard measures to harden any network-facing program.

 

I like having as few ports open as possible and having really solid software listening on any ports that are open.  openssh, apache2, postfix.  Transmission?  By hardening network-facing programs, do you mean running them as a dedicated user or in a chroot?

----------

## Hu

If you want to restrict outbound traffic, use SELinux or GRsecurity.  They can provide much finer control over which processes can connect out.  I generally place my trust in the program rather than the port it uses.  If you cannot trust the program enough to allow it out on whatever port it wants, then how can you trust it not to send sensitive information on the one port you do give it?

If you do not trust Transmission, then do not run it unconfined.  You can harden a program in various ways.  Running it under a dedicated user, running it in a restricted filesystem, and building it with exploit mitigation techniques such as SSP and PIE all contribute to hardening.  However, none of these can fully protect you if the software is actively malicious.  They can only lessen the damage done by security vulnerabilities.

----------

## v_andal

 *Quote:*   

> I'd also prefer to keep all inbound ports closed on this machine. Is there a way to close all inbound bittorrent ports but keep the functionality of the application?

 

Aren't we supposed to talk about inbound ports and not outbound ones? It really does not make too much sense to restrict outbound ports, at least in general case. I'm using rtorrent and have 5 inbound ports opened for it. Plus I use the option of reporting my current external IP to torrents tracker (with the help of DynDns). No restrictions for outgoing ports. I don't know if the last measure (IP reporting) is needed, but I never have problems with peers.

----------

