Advanced Firewall Configurations with ipset
iptables is the user-space tool for configuring firewall rules in the Linux kernel. It is actually a part of the larger netfilter framework. Perhaps because iptables is the most visible part of the netfilter framework, the framework is commonly referred to collectively as iptables. iptables has been the Linux firewall solution since the 2.4 kernel.
ipset is an extension to iptables that allows you to create firewall rules that match entire "sets" of addresses at once. Unlike normal iptables chains, which are stored and traversed linearly, IP sets are stored in indexed data structures, making lookups very efficient, even when dealing with large sets.
Besides the obvious situations where you might imagine this would be useful, such as blocking long lists of "bad" hosts without worry of killing system resources or causing network congestion, IP sets also open up new ways of approaching certain aspects of firewall design and simplify many configuration scenarios.
In this article, after quickly discussing ipset's installation requirements, I spend a bit of time on iptables' core fundamentals and concepts. Then, I cover ipset usage and syntax and show how it integrates with iptables to accomplish various configurations. Finally, I provide some detailed and fairly advanced real-world examples of how ipsets can be used to solve all sorts of problems.
With significant performance gains and powerful extra features—like the ability to apply single firewall rules to entire groups of hosts and networks at once—ipset may be iptables' perfect match.
Because ipset is just an extension to iptables, this article is as much about iptables as it is about ipset, although the focus is those features relevant to understanding and using ipset.
Getting ipset
ipset is a simple package option in many distributions, and since plenty of other installation resources are available, I don't spend a whole lot of time on that here.
The important thing to understand is that like iptables, ipset consists of both a user-space tool and a kernel module, so you need both for it to work properly. You also need an "ipset-aware" iptables binary to be able to add rules that match against sets.
Start by simply doing a search for "ipset" in your
distribution's package management tool.
There is a good chance you'll be able to find an easy
procedure to install ipset in a turn-key way. In Ubuntu (and
probably Debian), install the ipset and xtables-addons-source
packages. Then, run module-assistant auto-install
xtables-addons, and
ipset is ready to go in less than 30 seconds.
If your distro doesn't have built-in support, follow the manual installation procedure listed on the ipset home page (see Resources) to build from source and patch your kernel and iptables.
The versions used in this article are ipset v4.3 and iptables v1.4.9.
iptables Overview
In a nutshell, an iptables firewall configuration consists of a set of built-in "chains" (grouped into four "tables") that each comprise a list of "rules". For every packet, and at each stage of processing, the kernel consults the appropriate chain to determine the fate of the packet.
Chains are consulted in order, based on the "direction" of the packet (remote-to-local, remote-to-remote or local-to-remote) and its current "stage" of processing (before or after "routing"). See Figure 1.
Figure 1. iptables Built-in Chains Traversal Order
When consulting a chain, the packet is compared to each and every one of the chain's rules, in order, until it matches a rule. Once the first match is found, the action specified in the rule's target is taken. If the end of the chain is reached without finding a match, the action of the chain's default target, or policy, is taken.
A chain is nothing more than an ordered list of rules, and a rule is nothing more than a match/target combination. A simple example of a match is "TCP destination port 80". A simple example of a target is "accept the packet". Targets also can redirect to other user-defined chains, which provide a mechanism for the grouping and subdividing of rules, and cascading through multiple matches and chains to arrive finally at an action to be taken on the packet.
Every iptables command for defining rules, from the very short to the very long, is composed of three basic parts that specify the table/chain (and order), the match and the target (Figure 2).
Figure 2. Anatomy of an iptables Command
To configure all these options and create a complete firewall configuration, you run a series of iptables commands in a specific order.
iptables is incredibly powerful and extensible. Besides its many built-in features, iptables also provides an API for custom "match extensions" (modules for classifying packets) and "target extensions" (modules for what actions to take when packets match).
Enter ipset
ipset is a "match extension" for iptables. To use it, you create and populate uniquely named "sets" using the ipset command-line tool, and then separately reference those sets in the match specification of one or more iptables rules.
A set is simply a list of addresses stored efficiently for fast lookup.
Take the following normal iptables commands that would block inbound traffic from 1.1.1.1 and 2.2.2.2:
iptables -A INPUT -s 1.1.1.1 -j DROP
iptables -A INPUT -s 2.2.2.2 -j DROP
The match specification syntax -s 1.1.1.1 above
means "match packets
whose source address is 1.1.1.1". To block both 1.1.1.1 and 2.2.2.2,
two separate iptables rules with two separate match specifications
(one for 1.1.1.1 and one for 2.2.2.2) are defined above.
Alternatively, the following ipset/iptables commands achieve the same result:
ipset -N myset iphash
ipset -A myset 1.1.1.1
ipset -A myset 2.2.2.2
iptables -A INPUT -m set --set myset src -j DROP
The ipset commands above create a new set (myset of
type iphash)
with two addresses (1.1.1.1 and 2.2.2.2).
The iptables command then references the set with the match specification
-m set --set myset src, which means "match packets whose source header
matches (that is, is contained within) the set named myset".
The flag src means match on "source".
The flag dst would match on
"destination", and the flag src,dst would match on both source and
destination.
In the second version above, only one iptables command is required, regardless of how many additional IP addresses are contained within the set. Although this example uses only two addresses, you could just as easily define 1,000 addresses, and the ipset-based config still would require only a single iptables rule, while the previous approach, without the benefit of ipset, would require 1,000 iptables rules.
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
If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.
Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.
Sponsored by ActiveState
| Non-Linux FOSS: libnotify, OS X Style | Jun 18, 2013 |
| Containers—Not Virtual Machines—Are the Future Cloud | Jun 17, 2013 |
| Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer | Jun 12, 2013 |
| Weechat, Irssi's Little Brother | Jun 11, 2013 |
| One Tail Just Isn't Enough | Jun 07, 2013 |
| Introduction to MapReduce with Hadoop on Linux | Jun 05, 2013 |
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Linux Systems Administrator
- Validate an E-Mail Address with PHP, the Right Way
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- RSS Feeds
- Senior Perl Developer
- Introduction to MapReduce with Hadoop on Linux
- Technical Support Rep
- Weechat, Irssi's Little Brother
- Reply to comment | Linux Journal
4 hours 3 min ago - Reply to comment | Linux Journal
4 hours 49 min ago - Didn't read
4 hours 59 min ago - Reply to comment | Linux Journal
5 hours 4 min ago - Poul-Henning Kamp: welcome to
7 hours 14 min ago - This has already been done
7 hours 15 min ago - Reply to comment | Linux Journal
8 hours 40 sec ago - Welcome to 1998
8 hours 49 min ago - notifier shortcomings
9 hours 12 min ago - heroku?
10 hours 49 min 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
Nice article for linux new bee
Nice article for linux new bee
Information as a concept
Information as a concept bears a diversity of meanings, from everyday usage to technical settings. Generally speaking, the concept of information is closely related to notions of constraint, communication, control, data, form, instruction, knowledge, meaning, mental stimulus, pattern, perception, and representation. Thanks.
Regards,
web design companies
Have you experimented with
Have you experimented with the Windows Firewall With Advanced Security snap-in? I bet you didn't! How well do you think the advanced configuration options might serve your needs?
Thanx
Thanx a lot for that helpful one ...!
LOVE
Most connections are structural not due to deficit of love but existence of worry.
Learned LOTS from this
Learned LOTS from this article, very informative and specially the VPN and NAT part was very usefull to me :D
src,dst flag
Hi!
When multiple flags are specified, the effect depends on the type of the set. If the type is for example ipportmap, the source IP and destination port should match the pair in the set. If the set is something like an iphash, only the source should match (unless there is a binding).
Very good article
Learned LOTS from this article, very informative and specially the VPN and NAT part was very usefull to me :D
looks like anyone can spam
looks like anyone can spam the comments section as there is no captcha!
There is a captcha actually,
There is a captcha actually, but only sometimes. If you are curious about how it works, read this: http://mollom.com/how-mollom-works
Mollom is quite accurate, but we get a particularly high volume, so even if only a small fraction slips through before we remove it, it may appear to be a lot of spam.
Katherine Druckman is webmistress at LinuxJournal.com. You might find her on Twitter or at the Southwest Drupal Summit