Solved nftables rules for qBittorrent

[CaffeineAddict]

The following are my nftables rules to allow qBittorrent:

filter_4 is IPv4 table name
new_out_4 is outbound IPv4 chain name (statefull)
new_in_4 is inbound IPv4 chain name (statefull)

Established and related traffic is fully allowed.
The default policy is to drop packets.

# New  IPv4traffic
add rule filter_4 input ct state new goto new_in_4
add rule filter_4 output ct state new goto new_out_4

Output:

# qbittorrent - DHT
# NOTE: We start from port 1024 which is most widely used, but some peers may set it at lower
# dport should be removed?
add rule filter_4 new_out_4 udp sport 1161 udp dport 1024-65535 accept

# qbittorrent - part of full range of ports used most often
add rule filter_4 new_out_4 udp dport { 6881-6968, 6970-6999 } accept

# NAT Port mapping protocol (qbittorrent)
add rule filter_4 new_out_4 udp dport 5351 accept

# qBittorrent - BitTorrent
# NOTE: We start from port 1024 which is most widely used, but some peers may set it at lower
add rule filter_4 new_out_4 tcp dport 1024-65535 accept

Input:

# qBittorrent - DHT
# qBittorrent UDP listener, usually for DHT
add rule filter_4 new_in_4 udp sport 1024-65535 udp dport 1161 accept

# qBittorrent - BitTorrent
# qBittorrent TCP listener, BitTorrent protocol
add rule filter_4 new_in_4 tcp sport 1024-65535 tcp dport 1161 accept

# qBittorrent - Embedded tracker port
add rule filter_4 new_in_4 tcp sport 1024-65535 tcp dport 9000 accept

I feel these rules are too weak and allowing way more than what's needed, is there any way or method to harden them so that it applies to as close to the qBittorrent as possible?

One weakness of nftables compared to Windows firewall is that you can't restrict rules to specific programs, but strength is that nftables is stateful firewall.
In this case however every new state is new traffic which defeats the purpose of statefulness since too much is allowed.

 

[Condobloke]

You may find what you need in firewalld

 

[CaffeineAddict]

You may find what you need in firewalld

Thanks but it looks like this is another firewall, I prefer to stick with nftables.

 

[f33dm3bits]

feel these rules are too weak and allowing way more than what's needed, is there any way or method to harden them so that it applies to as close to the qBittorrent as possible?

nftables is overkill for something running on your desktop, even I don't use nftables on my desktop but firewalld, only on my vpses I use nftables. Outbound rules are overkill in your situation as well, outbound rules are useful in case of a systems is running as a main firewall and you want all the clients to connect to the internet through a proxy, in that situation you can configure your firewall to drop all outbound traffic. However if you do want to go through with it, what you could do is run qBittorent in a container and then give that container it's own ip, then in your firewall rules you could list that the source ip has to be of your qBittorent container or the outgoing and incoming rules.

 

[f33dm3bits]

However if you do want to go through with it, what you could do is run qBittorent in a container and then give that container it's own ip, then in your firewall rules you could list that the source ip has to be of your qBittorent container or the outgoing and incoming rules.

I haver never used Qbittorent but thinking of it, if you run it as a daemon, you should be able have Qbittorent bind to an ip so that you can give it's own ip to Qbittorrent. That way you can use that ip for your firewall rules, that way you could do the same I said about the container setup with source and dest rules.

 

[CaffeineAddict]

I haver never used Qbittorent but thinking of it, if you run it as a daemon, you should be able have Qbittorent bind to an ip so that you can give it's own ip to Qbittorrent.

Thank you so much for this insight!

There is an option in qbittorrent to bind it to interface but not to IP, this alone is enough because I have 2 NIC's so I'll use another one for qbittorrent only and make rules for it based on that NIC.

That's solid.

Sadly no IP support: https://github.com/qbittorrent/qBittorrent/issues/4223

EDIT:
Actually I misread! there IS IP binding support!

 

[f33dm3bits]

There is an option in qbittorrent to bind it to interface but not to IP, this alone is enough because I have 2 NIC's so I'll use another one for qbittorrent only and make rules for it based on that NIC.

It is possible to create an alias interface of your main interface and assign a separate ip to that if I remember correctly. I did come across this issue which you may want to have a look at.

qBittorrent not using the interface ip the routing decides to use. · Issue #13094 · qbittorrent/qBittorrent

Please provide the following information qBittorrent version and Operating System Version: 1:4.2.5.99~202004250117-7015-2c65b79~ubuntu20.04.1 20.04 If on linux, libtorrent-rasterbar and Qt version ...

github.com

Look at that it seems that the outgoing connections use the wrong source ip, not sure if that would make a difference if you bind it to a specific interface. You would have to test it out.

 

[CaffeineAddict]

@f33dm3bits
sorry, I have edited my previous post soon after posting, there is IP binding support but it requires 2nd NIC to work the way I want.

My 2nd NIC is wireless with it's own IP which I set in qbittorrent, make rules for that IP and everything works great and it's safe!
Thanks again for your insights!

 

[f33dm3bits]

If you didn't have a second interface or don't want to use wireless you could still run Qbittorent in a container like I mentioned earlier in the topic and then assign that container it's own ip.

qbittorrent - LinuxServer.io

Welcome to the home of the LinuxServer.io documentation!

docs.linuxserver.io

 

[CaffeineAddict]

If you didn't have a second interface or don't want to use wireless you could still run Qbittorent in a container like I mentioned earlier in the topic and then assign that container it's own ip.

qbittorrent - LinuxServer.io

Welcome to the home of the LinuxServer.io documentation!

docs.linuxserver.io

I'm sure this will be useful to folks with only 1 NIC, I'm fine with WI-FI dedicated to torrents this way I simply disconnect without pausing torrents or closing the client down.