Server Administration

  Home arrow Server Administration arrow Page 3 - Netfilter and Iptables Overview
SERVER ADMINISTRATION

Netfilter and Iptables Overview
By: Barzan 'Tony' Antal
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating: 5 stars5 stars5 stars5 stars5 stars / 5
    2009-07-15

    Table of Contents:
  • Netfilter and Iptables Overview
  • Netfilter
  • Iptables
  • Final Thoughts

  •  
     

    SEARCH CODEWALKERS

    TOOLS YOU CAN USE

    advertisement

    Netfilter and Iptables Overview - Iptables


    (Page 3 of 4 )

    Iptables was designed as an extension of Netfilter; it uses its set of APIs. Moreover, this combination of Netfilter/Iptables is often simply called the Iptables firewall that runs on Linux distributions. Iptables cannot exist without Netfilter, so that part is kind of assumed. Iptables is the user space, while Netfilter is the kernel space.

    Simply put, system administrators can specify chains and rules (rule-sets) in terms of IP packets. We’ve already mentioned previously that this firewall is stateful. It works with tables (Xtables framework of Netfilter) which contain those chains that are composed on their end by rule-sets. Each packet ought to travel at least one chain. Three predefined chains are available: INPUT, OUTPUT, and FORWARD.

    For example, the recommended default policy is to reject (DROP) each IP packet that is not discussed specifically. If you are creating customized chains to handle the packets that are traversing through, then you are advised to reject the rest. This can be done using the following commands. Please be aware that IPTABLES is an exported variable that calls ‘iptables’ along with its location; in my case, that’s /sbin/iptables.

    $IPTABLES –P INPUT DROP

    $IPTABLES –P FORWARD DROP

    $IPTABLES –P OUTPUT DROP

    User-defined modules can be created and placed anywhere as long as they are based on globally exported variables (such as the $IPTABLES points to /sbin/iptables). It is a general recommendation to create individual modules for specific rights/rules rather than just creating one huge module with a pile of rule-sets.

    Everybody has heard of Counter Strike 1.6. It’s one of the most popular FPS games. Millions of people play it everywhere. This particular game needs the 27015 port. With LAN games, this is done via the UDP protocol; otherwise, via the TCP, too. Check out the following module (set of rules) we’ve created for CS 1.6. Please replace xxx.xxx.xxx.xxx with the IP address to which those packets should be forwarded.

    $IPTABLES –A FORWARD –p UDP –s xxx.xxx.xxx.xxx --dport 27015 –m state --state NEW, ESTABLISHED –j ACCEPT

    $IPTABLES –A FORWARD –p UDP –d xxx.xxx.xxx.xxx --sport 27015 –m state --state ESTABLISHED –j ACCEPT

    At first the above snippet may look scary, but it’s quite easy to comprehend once you are familiar with their structure and syntax. Probably the most thorough and best documentation available on the Internet on the subject of Iptables is the Iptables Tutorial. It covers every possible aspect of Iptables and leads you through all of the basics of networking concepts. It’s long, yes, but it’s worth it.

    There are particular third-party GUI-based front-ends that can aid the process. These utilities automatically generate your iptables rules. One example is Firewall Builder. You should probably check it out, but we don’t really advise the use of these applications. If you know what you are doing, then creating your own chains is a piece of cake, but if you find out that your “generated rules” aren’t really suiting your specific network scheme, then troubleshooting and finding its flaws is more time-consuming.

    More Server Administration Articles
    More By Barzan 'Tony' Antal

    blog comments powered by Disqus

    SERVER ADMINISTRATION ARTICLES

    - SSH Case Studies: Gateway Hosts
    - SSH Case Studies: More on Pine and SSH
    - SSH Case Studies: Pine and IMAP
    - SSH Case Studies: More on the Passive Mode
    - SSH Case Studies: Network Address Translation
    - SSH Case Studies: The Passive Mode
    - SSH Case Studies: The FTP Protocol
    - SSH Case Studies: Batch Jobs, FTP and SSH
    - SSH Case Studies: Agents and Authentication
    - SSH Case Studies
    - Server Responses to Client Communication
    - Authentication in Client/Server Communication
    - Client/Server Communication
    - Understanding Awk in the UNIX Shell
    - Stream Editor in the UNIX Shell

    Developer Shed Affiliates

     



    © 2003-2013 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap