Taming the Wild Netfilter
The iptables command line is broken down into as many as six parts. The first part is the iptables command, which will not be discussed further. The second part is the table specification, and the chain name is the third part. The fourth part is the rule specification, which is the part of the command to match against the IP or ICMP header, but also could be a rule number in some incantations. The fifth part is the target, and the sixth part is the target option. The general command line, then, looks like
iptables [-t table] -ACDI CHAIN rule-specification å -j TARGET [target option]
The above does not hold true for all incantations but is the most common. You will also find the -L command useful. It will be covered in this article, along with several other command-line variants.
Netfilter has three tables you need to concern yourself with: filter, nat and mangle. This article, whenever it shows an iptables incantation, will always have a table specified. However, if no table is specified, the filter table is assumed. Therefore, if you do not specify a table and your rule fails, try putting a table specification in and try again.
Each table has certain chains available to it. User-created chains will belong to one and only one table. You will see that some built-in chains belong to more than one table, but this is only true for built-in chains. You cannot mix chains from other tables within user-created chains.
The filter table is the basic packet-filter table and has the built-in chains INPUT, FORWARD and OUTPUT. Rules added to user-created chains created in the filter table can only contain targets valid in the INPUT, FORWARD or OUTPUT chains. Packets traversing the filter table will pass through one and only one of INPUT, FORWARD or OUTPUT. The INPUT chain will only be traversed if the packet's destination is the local system. The FORWARD chain will only be traversed if the packet is passing through the local system and bound for another system. And the OUTPUT chain is traversed only by packets originating on the local system with an external destination. Only one chain will be traversed by any given packet. This is in contrast to ipchains that always used the input and output chains and also used the forward chain if the packet was passing through.
Note that in the previous paragraph, the iptables chain names were capitalized, while the ipchains chain names were not. This was deliberate and reflects a change in syntax.
The nat table performs network address translation. Built-in chains for nat are PREROUTING, POSTROUTING and OUTPUT. Each chain permits a particular target. The PREROUTING accepts the DNAT target, and the remaining chains accept the SNAT target. More on these targets shortly.
The mangle table is used to change (mangle) information other than the IP address in the header. It can be used to mark the packets, change type of service (TOS) or change time-to-live (ttl) information.
The rule-specification portion of each iptables command is the heart of the command. By properly crafting your rule, you can select exactly which packets to which a rule should apply. This selection criteria can be as general or as specific as you need. In most cases, you'll want to make sure specific criteria come before more general criteria.
That said, I'll not belabor rules too much here other than to add that multiple options, some of which carry their own options, can be strung together. But you do need to ensure that rules make sense. For example, don't specify an output interface in an input chain or that rule will never match anything. The syntax may allow you to construct impossible rules, but it's not a good idea. If you're in doubt about a particular rule, you can always make the target a log target then send traffic that matches that rule to see if it does in fact trigger. If you need a tool to test your rules, take a look at SendIP (www.earth.li/projectpurple/progs/sendip.html).
Netfilter has four built-in targets: ACCEPT, DROP, QUEUE and RETURN. The DROP target replaces ipchain's DENY target. All other targets used are based on modules that load as a target. These include REJECT, LOG, MARK, MASQUERADE, MIRROR, REDIRECT and TCPMSS. Terminal targets, such as ACCEPT, DROP, REJECT, MASQUERADE, MIRROR and REDIRECT, terminate a chain. A LOG target does not terminate a chain. LOG also neither ACCEPTS, REJECTS nor DROPS a packet, so the chain continues to be traversed. Thus the ipchains -l option is now another target but a nonterminating one. The rest of the chain will be traversed until it hits the policy rule.
The policy rule is the overall rule for the chain. If your FORWARD chain contains a policy of DROP, and no rules above match in the chain, the packet will terminate when it hits the policy rule. Your policy rule can only be one of the built-in targets. You cannot have REJECT as a policy rule.
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
| Designing Electronics with Linux | May 22, 2013 |
| Dynamic DNS—an Object Lesson in Problem Solving | May 21, 2013 |
| Using Salt Stack and Vagrant for Drupal Development | May 20, 2013 |
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
- New Products
- Linux Systems Administrator
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Web & UI Developer (JavaScript & j Query)
- Designing Electronics with Linux
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- Reply to comment | Linux Journal
1 hour 29 min ago - Nice article, thanks for the
12 hours 9 min ago - I once had a better way I
17 hours 55 min ago - Not only you I too assumed
18 hours 13 min ago - another very interesting
20 hours 6 min ago - Reply to comment | Linux Journal
21 hours 59 min ago - Reply to comment | Linux Journal
1 day 4 hours ago - Reply to comment | Linux Journal
1 day 5 hours ago - Favorite (and easily brute-forced) pw's
1 day 7 hours ago - Have you tried Boxen? It's a
1 day 12 hours ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?




Comments
NetFilter for non-IP packets
Hi, Iam new to netfilter. I want to know whether i can use netfilter API to send/receive (and possibly replace) ethernet packets irrespective of the protocol used in the ethernet payload(without writing my own device driver) or netfilter just provides api to work only at IP level.
Limiting simultaneous incoming connections by IP?
It seems dificult to find this information.
How does one limit the amount of connections by IP?
For example, one may want to limit the amount of connections from an IP to 10, so from a single IP you only allow up to 10 connections.
It is useful to avoid a single IP eating all the connections to an email server or webserver or whatever service, to avoid simple to do DoS.
Using the programs for this isn't that nice, since one would like to limit by DROP and not REJECT in some cases, and also some programs don't even have the option to limit the connections allowed by each IP.
Thanks for your article!
i am using netfilter hook to
i am using netfilter hook to capture a simple packet which contains an http request then it is been sent to a particular node by dev_queue_xmit function by changing its source ip and hardware address but am unable to transmit i have used nf_stolen option please help
Will You Tell Me How To ..
Enhance & secure web-server, mail server(qmail) & internet speed (in LAN with 100 workstations).I have got only one HP Proliant ML150 Server(Xeon/256MbRam/34*3SCSI Discs)..I am using Fedora Core3.
How can we configure Squid for offline mode ?
Re: Taming the Wild Netfilter
Hi,
I have implemented, IP tunnelling in kernel by hooking to Netfilters. The implementation goes as a module. I am sending the packet out by calling dev_queue_xmit by filling the required fields in the skb and returning NF_STOLEN. I just want to know, if I capture a packet at pre/post routing hook and mangle the IP addresses(which could result in local/forward delivery) and return NF_ACCEPT to corresponding NF hook, would the packet be routed. This is required so that, if any module registered to NF after this tunneling module, can also get the packet and also I don't need to fill in the fields in the skb and call dev_queue_xmit.
BTW, I am Suresh.
thanks
regards
Suresh
Re: Taming the Wild Netfilter
Does anybody know how to get snort to work with netfilter?
Re: Taming the Wild Netfilter
Snort is an IDS..Netfilter is a firewall..what do you mean getting Snort to work with netfilter?
Re: Taming the Wild Netfilter
Snort can be run on Netfilter. Look into snort_inline, It takes packets using ip_queue.o module to user space where snort is run.
I suggest you rewrite snort engine in kernel space and reduce the packet moving time from kernel space to user space and thus increase the performance.
Ravi
ravivsn@rocsys.com
ROCSYS technologies ltd
Hyderabad
Re: Taming the Wild Netfilter
THANK YOU DAVID!!!!!! For a VERY long time now I have been trying to figure out why, when I made my INPUT chain's policy DROP/REJECT, my connection would fall off too. After months of searching, including a few wild goose chases, the answer was your discussion about allowing ESTABLISHED,RELATED connections on the INPUT chain. I now have a default policy of deny, whereas before I had to keep track of what was being broadcast and lock it down. THANKS AGAIN!!
You're welcome.... Eat more
You're welcome....
Eat more fruits.