My firewalls/iptables setup, don't think it's doing it's job

PACMANchasingme · 10-11-2015, 03:46 AM

Hey I'm a little confused at how exactly firewalls work. I know the process is

Code:

Computer > IPtables firewall > Router firewalls > Internet

In my router I have enabled ipv4 and ipv6 firewalls and port forwarded 51414 for torrenting.

On iptables, I did not enable 51414. Yet rTorrent can still use that port and run torrents, where is my iptables layer of protection?

Quote:

robby ~ $ sudo iptables -L
[sudo] password for robby:
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere
DROP all -- anywhere anywhere ctstate INVALID
ACCEPT icmp -- anywhere anywhere icmp echo-request ctstate NEW
UDP udp -- anywhere anywhere ctstate NEW
TCP tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/SYN ctstate NEW
REJECT udp -- anywhere anywhere reject-with icmp-port-unreachable
REJECT tcp -- anywhere anywhere reject-with tcp-reset
REJECT all -- anywhere anywhere reject-with icmp-proto-unreachable

Chain FORWARD (policy DROP)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain TCP (1 references)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere tcp dpt:netbios-ns
ACCEPT tcp -- anywhere anywhere tcp dpt:netbios-dgm
ACCEPT tcp -- anywhere anywhere tcp dpt:netbios-ssn
ACCEPT tcp -- anywhere anywhere tcp dpt:microsoft-ds

Chain UDP (1 references)
target prot opt source destination
robby ~ $

As you can see I only accepted 137-139+445 but not 51414.

My iptables.service is running fine.

Quote:

robby ~ $ systemctl status iptables
iptables.service - Packet Filtering Framework
Loaded: loaded (/usr/lib/systemd/system/iptables.service; enabled; vendor preset: disabled)
Active: active (exited) since Sat 2015-10-10 23:54:35 PDT; 1h 49min ago
Process: 261 ExecStart=/usr/bin/iptables-restore /etc/iptables/iptables.rules (code=exited, status=0/SUCCESS)
Main PID: 261 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/iptables.service

Oct 10 23:54:33 robbyARCHPC systemd[1]: Starting Packet Filtering Framework...
Oct 10 23:54:35 robbyARCHPC systemd[1]: Started Packet Filtering Framework.
robby ~ $

I am using Arch.

unSpawn · 10-11-2015, 04:08 AM

Quote:

Originally Posted by PACMANchasingme

In my router I have enabled ipv4 and ipv6 firewalls and port forwarded 51414 for torrenting. On iptables, I did not enable 51414. Yet rTorrent can still use that port and run torrents, where is my iptables layer of protection? As you can see I only accepted 137-139+445 but not 51414.

Two things:
0) Please make it a habit to post (sudo) 'iptables-save;' output instead of anything else. That lists the current rule set in an unambiguous way most users understand.
1) On your machines firewall you have a default INPUT chain policy:

Code:

Chain INPUT (policy DROP)

that should deny all traffic except it's negated by the first two rules:

Code:

ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere

that basically read "allow back traffic from connections this machine initiated" and "allow traffic from connections a remote machine initiated". So basically you're allowing everything.

There's some rules I can't make sense of so if you post (sudo) 'iptables-save;' output I'll craft you a rule set that makes sense (at least to me ;-p), OK?

PACMANchasingme · 10-11-2015, 05:28 AM

Quote:

Originally Posted by unSpawn

Two things:
0) Please make it a habit to post (sudo) 'iptables-save;' output instead of anything else. That lists the current rule set in an unambiguous way most users understand.
1) On your machines firewall you have a default INPUT chain policy:

Code:

Chain INPUT (policy DROP)

that should deny all traffic except it's negated by the first two rules:

Code:

ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere

that basically read "allow back traffic from connections this machine initiated" and "allow traffic from connections a remote machine initiated". So basically you're allowing everything.

There's some rules I can't make sense of so if you post (sudo) 'iptables-save;' output I'll craft you a rule set that makes sense (at least to me ;-p), OK?

Here it is, and thanks a lot!

Quote:

# Generated by iptables-save v1.4.21 on Sun Oct 11 03:26:05 2015
*raw
:PREROUTING ACCEPT [261069:290277928]
:OUTPUT ACCEPT [199065:24789489]
COMMIT
# Completed on Sun Oct 11 03:26:05 2015
# Generated by iptables-save v1.4.21 on Sun Oct 11 03:26:05 2015
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [199065:24789489]
:TCP - [0:0]
:UDP - [0:0]
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -p icmp -m icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -p udp -m conntrack --ctstate NEW -j UDP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j TCP
-A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p tcp -j REJECT --reject-with tcp-reset
-A INPUT -j REJECT --reject-with icmp-proto-unreachable
-A TCP -p tcp -m tcp --dport 137 -j ACCEPT
-A TCP -p tcp -m tcp --dport 138 -j ACCEPT
-A TCP -p tcp -m tcp --dport 139 -j ACCEPT
-A TCP -p tcp -m tcp --dport 445 -j ACCEPT
COMMIT
# Completed on Sun Oct 11 03:26:05 2015
# Generated by iptables-save v1.4.21 on Sun Oct 11 03:26:05 2015
*nat
:PREROUTING ACCEPT [402:18982]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [4287:269865]
:POSTROUTING ACCEPT [4349:272345]
COMMIT
# Completed on Sun Oct 11 03:26:05 2015
# Generated by iptables-save v1.4.21 on Sun Oct 11 03:26:05 2015
*mangle
:PREROUTING ACCEPT [261069:290277928]
:INPUT ACCEPT [261067:290277582]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [199065:24789489]
:POSTROUTING ACCEPT [199172:24809179]
COMMIT
# Completed on Sun Oct 11 03:26:05 2015
# Generated by iptables-save v1.4.21 on Sun Oct 11 03:26:05 2015
*security
:INPUT ACCEPT [260469:290235616]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [199065:24789489]
COMMIT
# Completed on Sun Oct 11 03:26:05 2015

unSpawn · 10-11-2015, 06:44 AM

Code:

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
# For logging: -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW --dport 51414 -m limit --limit 1/s -j LOG --log-prefix "in_tcp_BT "
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -m multiport --dports 137:139,51414 -j ACCEPT
# For logging: -A INPUT -p udp -m udp -m conntrack --ctstate NEW --dport 51414 -m limit --limit 1/s -j LOG --log-prefix "in_udp_BT "
-A INPUT -p udp -m udp -m conntrack --ctstate NEW -m multiport --dports 137:139,51414 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT
# -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
# -A INPUT -p tcp -j REJECT --reject-with tcp-reset
# -A INPUT -j REJECT --reject-with icmp-proto-unreachable
COMMIT

Ditching the raw, nat and mangle tables (no rules using them.) we only keep the filter table. In filter table I put loop back device rule first so we then know remaining rules are for Ethernet devices. I removed the custom TCP and UDP chains as they only contain one rule. This also allows one to combine protocol rules (notice "multiport" module). Note I removed TCP+UDP/445 as I doubt you'll be using an AD machine? Note also the commented out rules which are redundant due to "DROP" Policy. *Also also note the "# For logging: " rules I've added but commented out so you can see (log) what (new) Bittorrent traffic is reaching you on those ports. Do note the majority of remote client BT traffic will be UDP-based, TCP for connecting to trackers.

How to test and enable this rule set?

Code:

# Prefix 'sudo' where necessary:
# First backup your old rule set:
iptables-save > /etc/iptables/iptables.rules.sav
# Now save above rule set to a (any) file, say "/etc/iptables/iptables.rules.new" and test it:
iptables-restore -v -t < /etc/iptables/iptables.rules.new
# and if no errors show activate it:
iptables-restore < /etc/iptables/iptables.rules.new
# Do test it some time and to make it permanent use:
iptables-save > /etc/iptables/iptables.rules
# *Do note saving rule sets in this way removes commented out rules.

That's it.

PACMANchasingme · 10-12-2015, 08:59 AM

Quote:

Originally Posted by unSpawn

Ditching the raw, nat and mangle tables (no rules using them.) we only keep the filter table. In filter table I put loop back device rule first so we then know remaining rules are for Ethernet devices. I removed the custom TCP and UDP chains as they only contain one rule. This also allows one to combine protocol rules (notice "multiport" module). Note I removed TCP+UDP/445 as I doubt you'll be using an AD machine? Note also the commented out rules which are redundant due to "DROP" Policy. *Also also note the "# For logging: " rules I've added but commented out so you can see (log) what (new) Bittorrent traffic is reaching you on those ports. Do note the majority of remote client BT traffic will be UDP-based, TCP for connecting to trackers.

That's strange didn't even see those two rules with accept all. I don't know how I managed to add that!

And I don't use AD but I think 445 is required to browse windows shares? this ruleset is great, I'm going to learn nmap/wireshark now so I probably don't need to use those logging rules.

unSpawn · 10-13-2015, 04:21 PM

Quote:

Originally Posted by PACMANchasingme

And I don't use AD but I think 445 is required to browse windows shares?

Check the SMB protocol specs?

Quote:

Originally Posted by PACMANchasingme

I'm going to learn nmap/wireshark now so I probably don't need to use those logging rules.

Suit yourself. While using these logging rules is more efficient (no need for BPF filters, following sessions etc, etc) Linux is the networked OS so any exercise involving tcpdump / tshark / Wireshark is commendable, useful, beneficial in the long run.