IPTABLES: Why is my script not applied?

0

I am installing a fresh new VPS (from linode.com, if that matters) with Ubuntu 16.04 LTS. I wrote the following script for iptables:

#!/bin/sh

iptables -F

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

iptables -A INPUT -i eth0 -p tcp -m multiport --dports 22,80,443 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp -m multiport --sports 22,80,443 -m state --state ESTABLISHED -j ACCEPT

iptables -A OUTPUT -p udp -o eth0 --dport 53 -j ACCEPT
iptables -A INPUT -p udp -i eth0 --sport 53 -j ACCEPT

iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

iptables -A INPUT -j DROP
iptables -A OUTPUT -j DROP
iptables -A FORWARD -j DROP

This script should only allow 22, 80 and 443. It also allows outgoing DNS resolves.

I created and named this script iptables.sh as root and put it in /etc/network/if-pre-up.d. I did also chmod +x.

Now, after reboot, this script does not seem to be applied. I verified this by executing iptables -S, which gives:

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

How do I progress from here? I am quite stuck right now.

update

I have no idea why, but after renaming uptables.sh to iptables, I cannot log in into my server anymore after a reboot. This makes me think that now the script is actually executed (and when it has .sh file extension not, why?) during boot and there is an error in my script. I am so confused.

Dave Teezo

Posted 2017-11-20T20:56:26.270

Reputation: 115

"I cannot log in into my server anymore after a reboot". I think the line iptables -A OUTPUT -o eth0 -p tcp -m multiport --dports 22,80,443… should use --sports, because in OUTPUT you want to allow response from port 22 etc. Notice UDP/53 has dport/sport rules corresponding to each other, not dport/dport nor sport/sport. – Kamil Maciorowski – 2017-11-20T21:32:14.830

Oh, ofcourse! I will try again, THANKS A LOT for that tip. – Dave Teezo – 2017-11-20T21:33:56.240

This not working :(. I updated the script in my question, so its clears what my current version is. – Dave Teezo – 2017-11-20T21:40:45.187

Are you sure the interface is eth0? Modern Ubuntu may use something like enpXsY. Why is my network interface named enp0s25 instead of eth0?

– Kamil Maciorowski – 2017-11-20T21:48:37.030

It's indeed eth0 in my case. I verified by running ifconfig, which gives eth0 and lo. – Dave Teezo – 2017-11-20T21:50:44.243

I've found this about state module: "ESTABLISHED meaning that the packet is associated with a connection which has seen packets in both directions, NEW meaning that the packet has started a new connection, or otherwise associated with a connection which has not seen packets in both directions". This suggests you should use NEW,ESTABLISHED instead of lone ESTABLISHED. I have no practical experience with this though, I may be very wrong. – Kamil Maciorowski – 2017-11-20T22:00:24.843

I wll try that out! – Dave Teezo – 2017-11-20T22:01:45.253

The way I see it, your question is "why is (was) the script not applied?" My attempts in comments to solve the other issue (that manifested itself after the script was renamed and applied) were out of courtesy, because there's not a single question about it; it's a separate problem for sure. Now there's an "answer" that tries to fix your iptables commands without addressing the explicit question; in my opinion this is formally wrong. Before I downvote the answer, please state clearly whether the question is still "why was the script not applied?" or "how to make my firewall sane?" – Kamil Maciorowski – 2017-11-20T23:59:29.803

You are absolutely right, my question was mainly about getting my script to do something. That has been solved. I should open a new issues for questions regarding the actual content/sanity of my rules. THANKS for your help! – Dave Teezo – 2017-11-21T08:48:54.830

Answers

0

NEW is by itself and RELATED,ESTABLISHED go together. When you connect via ssh the destination maybe port 22, but the source port is random that is why rule #2 in output does function as expected.

iptables -I INPUT 1 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -I OUTPUT 1 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

Once these rules are in place your DNS request are part of the RELATED,ESTABLISHED traffic and you can delete your port 53 references.

cybernard

Posted 2017-11-20T20:56:26.270

Reputation: 11 200

I appreciate your feedback. I don't think it's a good idea to do such things on all ports? Also, shouldn't it be something like NEW, ESTABLISHED for the to flow and ESTABLISHED, RELATED for the from flow? – Dave Teezo – 2017-11-21T09:05:48.207

I also don't understand your remark regarding 53. Isn't an outgoing DNS resolve a NEW request? – Dave Teezo – 2017-11-21T09:30:35.780

@DaveTeezo You can allow OUTBOUND port 53, but INPUT 53 is handled by RELATED,ESTABLISHED. RELATED,ESTABLISHED on all ports is a lot easier than trying to do it per service. Also the packet has to make it through the OUTPUT chain to become RELATED,ESTABLISHED, so if you block the connection in the OUTPUT chain it will never become RELATED or ESTABLISHED. – cybernard – 2017-11-21T12:53:00.927