Take the 2-minute tour ×
Code Review Stack Exchange is a question and answer site for peer programmer code reviews. It's 100% free, no registration required.

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?

share|improve this question
1  
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

3 Answers 3

up vote 6 down vote accepted

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.

share|improve this answer
    
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.

share|improve this answer
    
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

In addition to other answers, I want to caution you about the blanket:

 $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
share|improve this answer
    
Great point on the DNS. NTP and DHCP, thank you. I'll look into the outbound traffic –  James Willson Mar 23 at 14:15

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.