Iptables and Bittorrent

ethics · 05-30-2007, 06:46 PM

Good evening,

Background:

I am in the process of locking down my server using iptables.

Basically the only services i need are SSH, SAMBA, Bittorrent, DNS & HTTP/HTTPS (for the occasional browsing on it)

I've done some research on iptables and found a script, which i've edited down to just include the ports i need.

Problem:
I'm running a BT client on the server (Ktorrent) and so i need to allow its access through iptables. I did some googling and found some obscure wiki, so i tried the rules however i still cannot get any connectivity through the client.

Below is my iptables ruleset:

Code:

#The NAT portion of the ruleset. Used for Network Address Transalation.
#Usually not needed on a typical web server, but it's there if you need it.
*nat
:PREROUTING ACCEPT [127173:7033011]
:POSTROUTING ACCEPT [31583:2332178]
:OUTPUT ACCEPT [32021:2375633]
COMMIT

#The Mangle portion of the ruleset. Here is where unwanted packet types get dropped.
#This helps in making port scans against your server a bit more time consuming and difficult, but not impossible.
*mangle
:PREROUTING ACCEPT [444:43563]
:INPUT ACCEPT [444:43563]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [402:144198]
:POSTROUTING ACCEPT [402:144198]
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP
COMMIT

#The FILTER section of the ruleset is where we initially drop all packets and then selectively open certain ports.
#We will also enable logging of all dropped requests.
*filter
:INPUT DROP [1:242]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
:LOG_DROP - [0:0]
:LOG_ACCEPT - [0:0]
:icmp_packets - [0:0]

#First, we cover the INPUT rules, or the rules for incoming requests.
#Note how at the end we log any incoming packets that are not accepted.
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

# Allow SSH Connections IN
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT

# Allow Samba Connections IN
-A INPUT -p tcp -m tcp --dport 445 -j ACCEPT

# Allow Bittorrent connections IN
-A INPUT -p tcp -m tcp --dport 59000:62000 -j ACCEPT 

-A INPUT -s 127.0.0.1 -j ACCEPT
-A INPUT -p icmp -j icmp_packets
-A INPUT -j LOG_DROP

#Next, we cover the OUTPUT rules, or the rules for all outgoing traffic.
#Note how at the end we log any outbound packets that are not accepted.
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
# Allow HTTP OUT
-A OUTPUT -p tcp -m tcp --dport 80 -j ACCEPT

# Allow HTTPS OUT
-A OUTPUT -p tcp -m tcp --dport 443 -j ACCEPT

# Allow DNS access for web
-A OUTPUT -p udp -m udp --dport 53 -j ACCEPT

# Allow Bittorrent connections OUT
-A OUTPUT -p tcp --tcp-flags SYN,RST,ACK SYN --dport 62000 -m state --state NEW -j ACCEPT
-A OUTPUT -p udp --dport 62000 -m state --state NEW -j ACCEPT
-A OUTPUT -d 127.0.0.1 -j ACCEPT
-A OUTPUT -p icmp -j icmp_packets
-A OUTPUT -j LOG_DROP

#Here we have 2 sets of logging rules. One for dropped packets to log all dropped requests and one for accepted packets, should we wish to log any accepted requesets.
-A LOG_DROP -j LOG --log-prefix "[IPTABLES DROP] : " --log-tcp-options --log-ip-options
-A LOG_DROP -j DROP

-A LOG_ACCEPT -j LOG --log-prefix "[IPTABLES ACCEPT] : " --log-tcp-options --log-ip-options
-A LOG_ACCEPT -j ACCEPT

#And finally, a rule to deal with ICMP requests. We drop all ping requests except from our own server.
# Make sure you replace 1.2.3.4 with the IP address of your server.
-A icmp_packets -p icmp -m icmp --icmp-type 0 -j ACCEPT
-A icmp_packets -s 192.168.1.2 -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A icmp_packets -p icmp -m icmp --icmp-type 8 -j DROP
-A icmp_packets -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A icmp_packets -p icmp -m icmp --icmp-type 11 -j ACCEPT
COMMIT

Obviously my knowledge of iptables is scant at best, as is with bittorrent.

When iptables is disabled it works fine, and i have the ports forwarded by my router. However with iptables engaged i get nothing at all.

I have 62000 as the tcp port and the udp tracker port, and 59000 as the DHT port.

Ktorrent gives a message that the tracker timed out on port 2710, do i need to set the source port as 62000 and destination as any??

Any help would be greatly appreciated.

Thanks

blackhole54 · 05-30-2007, 08:27 PM

I can't give you advice about BT since I haven't used it, but it might be instructive to look at your system logs to see what packets are getting dropped when you have the firewall running.

You are currently allowing in all tcp packets destined for ports 59000 through 62000, and allowing both udp and tcp packets out if they have a destination port of 62000. There are no provisions for incoming udp BT packets. (I don't know if there should be.)

ethics · 05-31-2007, 08:20 AM

As i understood incoming is only over TCP, UDP is required for outgoing/the tracker.

I spent some more time on it and added a rule specifically for a particular tracker, which worked ok, and i generally use the same one anyway.

However i could still not seed (upload) to any clients

.

Back to the drawing board.

blackhole54 · 06-01-2007, 02:00 AM

Quote:

Originally Posted by ethics

However i could still not seed (upload) to any clients

.

Forgive my ignorance about the BT protocol, but don't the clients for you to seed contact you? If so, your system log will show those packets getting dropped and you can figure out how to adjust to let them through. On the other hand, if you don't see any packets getting dropped (you would have to sort these out from the misc. real garbage your firewall is correctly blocking), then it would seem that somehow you haven't relayed the correct info so they can contact you.

Unless of course I totally misunderstand how this works. :-/

ethics · 06-03-2007, 10:42 AM

Ok i switched to the Azureus client (which seems to do everything through the same port on UDP/TCP as ooposed to ktorren and found the ticket on the azureus wiki.

So i added these lines to my iptables.rules ruleset:

Code:

-A INPUT -i eth0 -p tcp --tcp-flags SYN,RST,ACK SYN --dport 62000 -m state --st
-A INPUT -i eth0 -p udp --dport 62000 -m state --state NEW -j ACCEPT

Should someone else want to use the rules change eth0 to ppp or whatever interface you're using, and the port and it should work fine.

Iptables logs still show dropped packets but they dont seem to be destined for the port Azureus is using (they use the same source port) so i figure they're not ones i want anyway.

Edit:

I've also had to add a rule for allowing Out on port 2710 for interaction with trackers.