# Iptables Lockdown

I have nginx serving files with uwsgi and I wanted to lock my server down just to allow SSH and Nginx to run. This is what I have:

i=/sbin/iptables

# Flush all rules
$i -F$i -X

# Setup default filter policy
$i -P INPUT DROP$i -P OUTPUT DROP
$i -P FORWARD DROP # Allow unlimited traffic on loopback$i -A INPUT -i lo -j ACCEPT
$i -A OUTPUT -o lo -j ACCEPT # Open up ports for nginx$i -A INPUT -p tcp --dport 443 -j ACCEPT
$i -A INPUT -p tcp --dport 80 -j ACCEPT$i -A INPUT -p tcp --dport 22 -j ACCEPT

# Make sure nothing comes or goes out of this box
$i -A INPUT -j DROP$i -A OUTPUT -j DROP


It's quite a minimal example but it looks like it would do the job. Are there any improvements to be had?

-
What shell script is this? bash? ksh? sh? What is the she-bang line #!/.... ? –  rolfl Mar 22 at 23:16
Bash script, i am missing the shebang :( –  James Willson Mar 23 at 14:11

There is a miniscule chance of a failure between /sbin/iptable -P INPUT DROP and /sbin/iptables -A INPUT -p tcp --dport 22 -j ACCEPT. It really isn't likely, as there's not much that could go wrong, but it's theoretically possible. If you are remotely administering this server over SSH, then you might get locked out of your own machine. Therefore, I suggest deferring the following sequence of commands:

1. /sbin/iptables -P {INPUT,OUTPUT} ACCEPT
2. /sbin/iptables -F; /sbin/iptables -X
3. Set up the rules
4. /sbin/iptables -P {INPUT,FORWARD} DROP

In contrast to @eckes, who worries about leaving the server vulnerable for a moment, I worry about possibly losing SSH access to it. If you are raising the firewall for the first time, my sequence introduces no new window of vulnerability. If you are reinitializing the firewall, the window of vulnerability between steps 1 and 3 would only be a split second, not enough for a meaningful attack.

-
Thank you for the reply @200_success. Are we saying move this line to the very bottom "/sbin/iptable -P INPUT DROP"? –  James Willson Mar 23 at 14:12
@JamesWillson I've clarified my advice in the answer. –  200_success Mar 23 at 15:45

I typically recommend to first set the policy and then flush the rules. This reduces the chance that you flush all deny rules with a open policy (also it is unlikely).

Your rules will most likely not work as you need to allow the outgoing resonse packages to the incoming connections as well.

-
Hi @eckes, thank you for the reply. So are you saying a should move the flush rules to below the "# Setup default filter policy" bit or instead all the way to the bottom. Would you also be kind enough to explain what you mean about the outgoing response packages please? –  James Willson Mar 23 at 14:10
@JamesWillson yes for security reasons setting up the policy should come before the flush. Optionally you can also do "set policy to deny, flush rules, setup rules, set policy to reject" This would avoid intermediate rejects. –  eckes Mar 24 at 12:11
@JamesWillson I mean if you allow incoming packages to the SSH port you also need to allow the answer packages for this connection to go out. You typically do this with a state established rule. BTW: most distros have some sort of sample rules shipped, it is easier to expand on them. –  eckes Mar 24 at 12:12

 \$i -A OUTPUT -j DROP


The following services should be running on your system and will need access:

• DNS
• NTP
• DHCP?
• others.

It is my experience that blanket/policy DENY for outbound traffic requires a signfificant effort for maintenance. Are you prepared for that.

Altough it is not the most secure view on the world, I don't think there is much point in restricting out-bound traffic. If a 'hacker' has gained enough access to your system to enable outbound systems you were not expecting, then the chances are that they can just open up your IPTables anyway. The frustration is not worth it.

Ping allow ping from inside and from outside

iptables -A OUTPUT -p icmp --icmp-type echo-request -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT

-
Great point on the DNS. NTP and DHCP, thank you. I'll look into the outbound traffic –  James Willson Mar 23 at 14:15