iptables blocking http [SOLVED]

Message

The Doctor · Post by **The Doctor** » Fri Dec 01, 2017 4:24 am

I'm rather confused. I'm not iptables genus but this one has me royally confused. I'm trying write a simple firewall for my desktop. It doesn't need to allow ssh, ntfs, or anything like that. It just needs to do its thing and let me browse the web. I've tried using the gentoo wiki and the arch wiki as a reference but http keeps being blocked. If I flush the rules then it works so the problem must be iptables. This makes no sense to me.

I'm using a script to set the rules for purposes of reputability. Here it is

Code: Select all

#!/bin/bash

#iptables log
echo "setting iptables firewall rules"

# fail on error
set -e
 
iptables -F
iptables -X
iptables -Z

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# Gentoo-sourced rules
#iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
#iptables -A INPUT -i lo -j ACCEPT
#iptables -A INPUT -p icmp --icmp-type 3 -j ACCEPT
#iptables -A INPUT -p icmp --icmp-type 11 -j ACCEPT
#iptables -A INPUT -p icmp --icmp-type 12 -j ACCEPT
#iptables -A INPUT -p tcp --syn --dport 113 -j REJECT --reject-with tcp-reset

#Arch sourced rules
iptables -N TCP
iptables -N UDP

iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP
iptables -A INPUT -p icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT
iptables -A INPUT -p udp -m conntrack --ctstate NEW -j UDP
iptables -A INPUT -p tcp --syn -m conntrack --ctstate NEW -j TCP
iptables -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
iptables -A INPUT -p tcp -j REJECT --reject-with tcp-reset
iptables -A INPUT -j REJECT --reject-with icmp-proto-unreachable


ip6tables -F
ip6tables -X
ip6tables -Z

ip6tables -P INPUT DROP
ip6tables -P FORWARD DROP
ip6tables -P OUTPUT ACCEPT

ip6tables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
ip6tables -A INPUT -i lo -j ACCEPT
ip6tables -A INPUT -m conntrack --ctstate INVALID -j DROP
ip6tables -A INPUT -s fe80::/10 -p ipv6-icmp -j ACCEPT
ip6tables -A INPUT -p udp -m conntrack --ctstate NEW -j REJECT --reject-with icmp6-port-unreachable
ip6tables -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j REJECT --reject-with tcp-reset

# finished
echo 'Finished setting rules'

EDIT: Solved. The solution is to finish clearing old rules before writing new ones

limn · Post by **limn** » Fri Dec 01, 2017 1:45 pm

At a minimum

Code: Select all

iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -P INPUT DROP

The box can talk to itself, transmissions you initiate and related ones are allowed, and everything else is dropped.

There is no harm in doing this

Code: Select all

iptables -P FORWARD DROP

but if your box is being used for forwarding without your knowledge....

Code: Select all

iptables -P OUTPUT ACCEPT

is unnecessary as it is the default. You can add these

Code: Select all

iptables -A INPUT -p tcp -j REJECT --reject-with tcp-reset
iptables -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable

or just let the INPUT DROP policy handle those packets.

If you want to know why your rule set failed, you could add the other rules until it breaks.

Ant P. · Post by **Ant P.** » Fri Dec 01, 2017 5:34 pm

Try removing all rules except the policy drop and the first conntrack accept. That should work, if not there's something else going on. Also, since you're not using iptables-save/restore (which are transactional) you should check manually that what's in the kernel matches what you expect after running that script.

FWIW, what kernel is this? 4.13 was giving me bizarre problems with nftables but 4.12 and .14 work fine.

The Doctor · Post by **The Doctor** » Fri Dec 01, 2017 7:26 pm

Removing all the rules except

Code: Select all

iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

didn't help

Code: Select all

Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED

Chain FORWARD (policy DROP)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

uname -r returns 4.12.12-gentoo

I also apologize for the confusion. I am using iptables-restore, specifically the rc-service for iptables. The script is just to set the rules and act as a memory aid.

The bit that really has me confused is how https traffic is allowed but http traffic is being blocked.

limn · Post by **limn** » Fri Dec 01, 2017 7:59 pm

Code: Select all

iptables -L -n -v

The Doctor · Post by **The Doctor** » Fri Dec 01, 2017 8:36 pm

Code: Select all

 iptables -L -n -v    
Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    1    52 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
    0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 1 packets, 52 bytes)
 pkts bytes target     prot opt in     out     source               destination

I added the net.lo rule as well here.

Ant P. · Post by **Ant P.** » Fri Dec 01, 2017 8:38 pm

Okay, that's really weird... might be a good idea to install wireshark to see where things are going wrong (is it blocked immediately, does it just time out, etc.)

The Doctor · Post by **The Doctor** » Fri Dec 01, 2017 8:52 pm

I'll give that a go as soon as my computer is back in a consistent state. I just started the emerge -e world bit of the new 17 profile switch. This is also my eternal optimism that emerge -e solves everything

limn · Post by **limn** » Fri Dec 01, 2017 8:57 pm

You monitored the packet counts while making both http and https connections?

The Doctor · Post by **The Doctor** » Fri Dec 01, 2017 10:24 pm

The number of OUTPUT packets accepted rises and an input packet gets dropped with http. There is a small increase (about 2000 packets) which may be explained by other connections.

Then it doesn't. I tried it again and the number of input packets drooped stayed constant....

So you think http is being intercepted by something else? I'll have to give wireshark a go.

The Doctor · Post by **The Doctor** » Fri Dec 01, 2017 10:33 pm

Okay, I need a bang my head against the wall emoji. My previous rules would route traffic through squid because reasons. I never did anything with it so I cleared out those rules and when on to write the new ones but I didn't clear the nat rules so apparently it was still trying to send the traffic through squid even though it has been uninstalled.

just running iptables -t nat -F iptables -t nat -X fixed it.

Thank you for all your time. I appreciate it.

Ant P. · Post by **Ant P.** » Fri Dec 01, 2017 10:48 pm

Ahh no wonder... pretty sure I've made mistakes like that before too. That's one good thing about nftables (when it works), it doesn't bury important stuff under an easily forgettable switch.

Post by Hu » Sat Dec 02, 2017 1:29 am

Just to pile on, I'd like to take this opportunity to point out that if you had used iptables-save to show the current rules (to yourself or to us), it would have dumped both the nat and filter tables, and you would've seen immediately that you had those stale rules lurking.

Likewise, if you wrote your current rules as an input to iptables-restore and then used that to load them, rather than this shell script, it would have either failed and changed nothing or succeeded and reset the rules for every table presented to it. (So you could still get burned if you gave it an input that didn't reset an important table.) Generally, I start by using iptables-save to dump the current rules, edit them to my new requirements, then load them back with iptables-restore. Once I am satisfied they are in good order, I tell the initscript to save them.