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.
Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.
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
| 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 |
| Non-Linux FOSS: Seashore | May 10, 2013 |
| Trying to Tame the Tablet | May 08, 2013 |
| Dart: a New Web Programming Experience | May 07, 2013 |
- RSS Feeds
- New Products
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Home, My Backup Data Center
- A Topic for Discussion - Open Source Feature-Richness?
- Dart: a New Web Programming Experience
- Developer Poll
- What's the tweeting protocol?
- May 2013 Issue of Linux Journal: Raspberry Pi
- Reply to comment | Linux Journal
1 hour 6 min ago - Reply to comment | Linux Journal
2 hours 24 min ago - great post
2 hours 59 min ago - Google Docs
3 hours 21 min ago - Reply to comment | Linux Journal
8 hours 10 min ago - Reply to comment | Linux Journal
8 hours 56 min ago - Web Hosting IQ
10 hours 30 min ago - Thanks for taking the time to
12 hours 7 min ago - Linux is good
14 hours 5 min ago - Reply to comment | Linux Journal
14 hours 22 min ago
Free Webinar: Linux Backup and Recovery
Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.
In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.




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.