Linux – Firewall questions about state and policy

iptableslinuxrules

I finally managed to install my VM host and now I am messing with iptables to create, test and learn.

  1. Does it matter if i put the below
    rules at the begin or at the end of
    my rules ?

    $IPT -P INPUT DROP
$IPT -P FORWARD DROP
$IPT -P OUTPUT DROP

    i have tested and there was no difference but i would like to confirm.

    Answer I choose so far:
    It is a good idea to apply your policies as early as possible. Put them at the start. DROP rules on internal traffic can cause problems.

  2. Having the below rule would be considered as a fault on the firewall ?

    $IPT -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

    Without this rule i would need to add for example an OUTPUT rule for my ssh connection, example:

    $IPT -A OUTPUT -p tcp --sport 2013 -j ACCEPT

    Answer:
    After more tests and talks with people on #iptables@freenode, i came to the conclusion that using -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT for INPUT and OUPUT is a fine approch and will help you deal with lots of things like for example the FTP and is a fine approch because unless you have that given port open and being accept there will be no malicious connection on it.

    Here is a normal example without using the above:

    $IPT -A INPUT -p tcp --dport 20:21 -j ACCEPT
$IPT -A OUTPUT -p tcp --dport 20:21 -j ACCEPT

    Now here is how the rule looks like using the above:

    $IPT -A INPUT -p tcp --dport 21 -m conntrack --ctstate NEW -j ACCEPT

    That's all you need because once the connection is ESTABLISHED, the output will follow-up right away and you won't need to make rules for the ftp-data port.

  3. What are bad things of having the below rule, could you give some example as to why not have it and instead just define anything you may need to use ?

    $IPT -P OUTPUT ACCEPT

    Answer I choose so far:
    This policy rule allows all outgoing traffic. As a policy, allowing everything is obviously less secure than allowing only explicit kinds of traffic. So if security is your utmost priority, you'll want to set a DROP policy on the output chain instead. Just be aware that you'll then have to include a number of rules to allow outgoing traffic to a possibly large number of mundane things, such as: DNS, SMTP, IMAP, POP3, HTTP, HTTPS, etc.

  4. What is the difference between conntrack and state in the below context ?

    state example:

    $IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

    conntrack example:

    $IPT -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

    Answer:
    After some research talks with people on #iptables@freenode i came to the conclusion i should be using conntrack from here on.

    Technically the conntrack match
    supersedes – and so obsoletes – the
    state match. But practically the
    state match is not obsoleted in any
    way.

I would aswell appreciate good online iptables reading materials.

Links recommended so far:

Perfect Ruleset

The Linux Documentation Project

Best Answer

  1. It is a good idea to apply your policies as early as possible. Put them at the start. DROP rules on internal traffic can cause problems.
  2. This rule would be consideref a fault, as it implements and ACCEPT policy. Adding an accept rule per service is the correct way to build your firewall.
  3. An accept policy indicates you are running a mostly open policy. (We locked the front door locked, but you can use any other door to get in.) Best policy is a mostly closed policy. We keep all door and windows locked, and only unlock the ones we need.
  4. It would appear there is no difference, although all the rules I have seen use state. The conctrack module will monitor the state. Use this rule with the port accept rule in question 2 to enable services.

You may want to look at the Shorewall documentation to see what can be done with iptables. I use it to build a firewall on all my Linux instances (including OpenWRT). It has well documented sample (default/base) configurations for servers with 1, 2 or 3 interfaces.

The Linux Documentation Project also has documentation.

Related Topic