A NATural Progression

David continues his series on the Netfilter framework with a look at NAT and how to avoid common errors when constructin iptales rules.
Conclusion

Netfilter and iptables make an extremely powerful firewall. But to take advantage of it, you need to master the basic syntax as explained in my first article (“Taming the Wild Netfilter”, published in the September 2001 issue of LJ), have an understanding of the modules and matches available to you and have an understanding of what a particular system can know about a packet. Armed with these three things, you can build highly complex, tailored firewall solutions for whatever problem you might have.

Know how to take advantage of new and experimental matches and targets (and always test them). You learned this in last month's article with the iptables build targets of pending-patches, most-of-pom and patch-o-matic. Testing by creating and sending specific packets to a firewall interface is beyond the scope of this particular article, but a number of utilities exist to assist you here (sendip or ipmagic come to mind).

Build the missing modules for the kernel (make sure they're selected).

Build your rule chains, more specific rules first followed by more general rules. If it helps you organize things, go ahead and build custom user chains that can be called from another chain. While this was not covered specifically in this article, it was addressed in the September 2001 article. Use everything at your disposal, including the LOG target to help you see if particular rules were applied and to which packets.

With just some basic knowledge, iptables are not difficult to use. Read some iptables scripts on the Internet. I don't recommend using them as they are; they almost certainly won't work for you without a lot of tweaking, but they will show you syntax, rules (from which you can grab fragments), thought processes, etc.

David A. Bandel (david@pananix.com) is a Linux/UNIX consultant currently living in the Republic of Panama. He is coauthor of Que Special Edition: Using Caldera OpenLinux.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Re: Kernel Korner: A NATural Progression

Anonymous's picture

My copy of Linux Journal had page 21 missing. It had two (2) identical page 20's followed by page 22. Is this a known error in this month's print? [Page 20 - 24 is this Kernel Korner: A NATural Progression article]

Re: Kernel Korner: A NATural Progression

Anonymous's picture

No - it was an error.

Read the next issue's first page of letters/comments/whatever - in the lower-right corner it mentions the double-printing as a mistake...

(too lazy to find the actual page right now... :-P )

Re: Kernel Korner: A NATural Progression

Anonymous's picture

same here. is this an advertising campaign? :) And could I just print a page 21 and add it back to the printed copy?

Re: Kernel Korner: A NATural Progression - MASQUERADE

htmlspinnr's picture

One rule you did not mention which many home users may be interested in is the MASQUERADE rule. This rule comes in handy when you're riding on a dynamic IP connection, but still want to use NAT. MASQUERADE uses the interface IP vs. having to hard code within your tables script (or your iptables-save list).

An example may be:

iptables -t nat -A POSTROUTING -s 192.168.0.0/255.255.255.0 -o eth0 -j MASQUERADE

Which would masquerade the 192.168.0.0/24 block as whatever address is assigned to eth0 - be it static or dynamic (though static should stick with SNAT for best results).

I've seen some firewalls use this in static situations as well (Astaro Security Linux 2.x - based on iptables) due to it's simplicity.

Hope this helps.

-Rick

Re: Kernel Korner: A NATural Progression - MASQUERADE

Anonymous's picture

David's previous NetFilter article covered MASQUERADE, IIRC

Re: Kernel Korner: A NATural Progression - MASQUERADE

Anonymous's picture

This article, a two-part article (of which this month was the second part), was a continuation of a more basic article I wrote and was published in last September's LJ. The basic article (referred back to in this article) discussed MASQUERADE and provided examples and scripts. Please check out September's LJ article on Netfilter/iptables.

David A. Bandel

White Paper
Fabric-Based Computing Enables Optimized Hyperscale Data Centers

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.

Learn More

Sponsored by AMD

White Paper
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy

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.

Learn More

Sponsored by DLT Solutions