Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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

share|improve this question

3 Answers 3

up vote 3 down vote accepted
  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.

share|improve this answer
    
about your answer on 2 that is what i was thinking about it. So having an open state rule like that wether on the INPUT OR OUTPUT indeed does allow any requests to any services i have available and would be more suitable if i do it those per rule ? –  Guapo Oct 14 '10 at 19:43
    
+1 Thanks for the links while i am not planning on using any softwares (i will take a look at the docs from shoreall) on top of my iptables most because i want to learn on it and not on tools that goes on top of it. –  Guapo Oct 14 '10 at 19:45
    
something just crossed my mind, you can use ptables -A INPUT -m state --state RELATED,ESTABLISHED without pointing it to ACCEPT would that be the same as declaring it on all rules in place on the rules list ? –  Guapo Oct 14 '10 at 20:26
    
@Guapo I believe you need to point the rule at ACCEPT. This should be an early rule as it is intended to bypass rule processing for connections which habe been accepted, and are being tracked. The RELATED portion allows FTP connections and other protocols which use multiple ports. These are handled by protocol specific modules such as ns_conntract_ftp. –  BillThor Oct 16 '10 at 5:39
    
yes i figured that out after some more tests but thanks :) –  Guapo Oct 16 '10 at 12:31

You didn't mention anything about the nat table, so I'm going to assume that this question relates to writing iptables firewall scripts for standalone servers, and not for multi-homed/gateway boxes.

  1. You are correct: Each chain has a single policy, so it doesn't matter where or in what order that policy rules are stated.

  2. This rule establishes a convention that many/most firewall scripts use: that of statefulness. Just a minor nitpick, though. I would not include the NEW state, and I would also include a rule for the INPUT chain, i.e.:

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

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

    I put these rules near or at the top of all of my firewall scripts, as they allow me to concentrate on creating rules for filtering connection attempts, and not have to think about non-connection-establishing packets. In my opinion, a firewall script without these rules is likely to be more complicated, and thus more prone to mistakes, than one that includes them.

  3. 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.

share|improve this answer
    
You didn't mention anything about the nat table thanks for point that out but i am doing the questions as i face them so i am yet to get to the nat part currently i am learning OUTPUT INPUT FORWARD then i will move to nat and mangle. i've made a VM just to learn those so dont worry we will get there :) about Q2 i do have one for INPUT without the NEW ofc but i was just wondering about the output one since that is more related to inner stuff i mean if you can't stablish a IN connection there will be no OUT connection ssh as for example. –  Guapo Oct 14 '10 at 19:34
    
About Q3 i do realise that ;) and i prefer it as DROP, also there is Q4 :) if u know about it let me know. –  Guapo Oct 14 '10 at 19:38
    
Just to tell a little more about the Q2 from the test i did, having only $IPT -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT i don't even need $IPT -A OUTPUT -p tcp --sport 2013 -j ACCEPT as it already seem to understand that it is an stablished OUTPUT from an known INPUT –  Guapo Oct 14 '10 at 19:40
    
Oh yes, I missed Q4. I think BillThor covered that pretty well. As for iptables docs, the man iptables is quite comprehensive :) . –  Steven Monday Oct 14 '10 at 19:53

State vs. Conntrack: State was removed in favor of conntrack effective with Linux kernel 3.7

share|improve this answer
1  
This isn't an answer and should be posted as a comment to the question. –  Sven Jan 7 '13 at 3:51
    
Well, it is hard for soemone without enough rep to post a comment, to do that. I still like that he wanted to add some info about the topic. Maybe a mod could transform this post to a comment. –  Levit Jul 28 at 12:25

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.