Printable View
I found a very interseting article about iptables config for starters in 2 parts.
I felt that could be helpful to new linux users.
Part1
Part2
There nothing new but its an easier way to get the iptables basics than with the manpage.
The article includes a good link to iptables scripts library.
http://www.linuxguruz.com/iptables/
enjoy ;)
Links seem to be broken. When I attempted to go to the site, I was greeted by a "You don't have permission to access <insert page here>." Too bad too, I wanted to read it.
-The Eeshman
eeshman :
the part 2 page is ok i'm sure u can read it
Part 1 is a blank page now & that's weird (maybe earthweb is updating the database...)
If u can't still access maybe are u going through a proxy that forbid access to earthweb!!!???
Here is a copy of Part 2:
Quote:
This article had been published http://networking.earthweb.com/
Building Firewalls with iptables, Part 2
June 10, 2003
By Carla Schroder
Last week in Part 1 we began uncovering some of the mysteries of tables and chains, and how to build iptables rules. This week we will dig more into writing rules for basic firewalling, sharing an Internet connection, and scripting.
Paying for Our SYNs
We can't close off all ports; that will shut us off completely. We also can't just specify that certain ports will remain open, since it's impossible to predict which ports non-service programs will grab. And simply allowing traffic destined for specific ports does nothing to prevent malicious bits from waltzing right on in. So what exactly can we do to set up an effective rule that allows the good guys to pass through while preventing the bad ones from accessing our network?
For starters, we can take advantage of the syn flag set to prevent unauthorized access. While iptables examines only headers, not payload, it still does a lot of useful packet analysis based on the headers. For example, when Web surfing, a request goes from your PC to a web server out there somewhere. The web server then responds and sends packets back to you, grabbing the first convenient ephemeral (temporary) port on your system. Other than responding to your request, the server has no reason whatsoever to be sending traffic your way. We can take advantage of this by setting up a rule that blocks all incoming TCP connections that are not initiated by your system:
# iptables -t filter -A INPUT -i eth0 -p tcp --syn -j DROP
-i names the network interface, -p names which protocol, and --syn means TCP packets with the syn flag set. This also illustrates the importance of understanding TCP/IP. SYN is used to initiate a TCP connection. If you're not running any servers on your end, there's no reason for anyone to be sending you SYN packets.
At this point, someone usually wails, "Why can't it be EASY?" Yes, there are easier ways to build firewalls. There are nice hardware widgets as well as software utilities for constructing rulesets (see Resources), but Grasshopper, you know as well as I do, the easy way is not always the best way. And if an old fossil like me can figure this stuff out, anyone can.
Stateful Packet Inspection
The previous example rule looks at each packet individually, rather than in context, and relies on the information in the header. If everyone were truthful and benevolent, this would be enough. (Heck, if everyone were truthful and benevolent, we wouldn't need firewalls in the first place, would we?) iptables inspects the source and destination IP addresses, the source and destination ports, the sequence numbers of incoming packets, the TCP sequencing information, and the status from the header flags (SYN, ACK, FIN, RST, etc.). In other words, it tracks entire connection sessions, making filtering decisions in context.
Sharing an Internet Connection
Network address translation/IP masquerading allows sharing a single Internet connection among several hosts -- a mixed LAN with Linux and Windows systems, for example. Assume a firewall box with two NICs and a static, routable IP address. eth0 is the "public" NIC, eth1 the "private." In other words, eth0 is assigned the static, routable IP, while eth1 is assigned a private, non-routable IP, and belongs to the LAN subnet. We need to add chains to the nat and filter tables:
# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
# iptables -t filter -A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
# iptables -t filter -A FORWARD -i eth1 -o eth0 -j ACCEPT
This illustrates the great value of stateful packet inspection. Notice how only incoming packets that belong to an existing connection are allowed. All packets from the LAN headed outbound are allowed to pass. (Note: filter is the default table; it is not necessary to explicitly name it. Many iptables examples leave it out.) The first rule makes all outgoing traffic appear as though it comes only from the firewall machine, with no indication there is an entire LAN lurking behind it.
This example sets the default policies for the FORWARDand POSTROUTING chains. It is important to have a default POSTROUTING DROP policy when using masquerading; otherwise, it is possible for a malicious user to tunnel through your gateway and masquerade their own identity.
# iptables -t filter -P FORWARD DROP
# iptables -t filter -P POSTROUTING DROP
This example is for dialup connections, with dynamically-assigned IPs:
# iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
Running Servers
A popular way to pass time is to engage in arguments about whether it is better to put servers behind firewalls, or outside of them. If you choose to put them behind your firewall, iptables needs to know where to pass the packets:
# iptables -t nat -A PREROUTING -i eth0 -p tcp -dport 80 -j DNAT -to 192.168.0.10:80
# iptables -t nat -A PREROUTING -i eth0 -p tcp -dport 25 -j DNAT -to 192.168.0.11:25
Scripting
So far, all the examples have been run from the command line. This is a good way to test new rules. Once they are working to your satisfaction, preserve them in a script. This sample is not a complete script, though, as it only illustrates using variables and provides additional sample rules.
#!/bin/sh
#Assign variables
IPTABLES=/sbin/iptables
LAN_NET="192.168.1.0/24"
IFACE= "eth0"
LO_IFACE="lo"
LO_IP="127.0.0.1"
#Any kernel modules that need to be loaded go here
/sbin/modprobe ip_conntrack
/sbin/modprobe iptable_nat
#IP forwarding is usually disabled in the kernel, by default. To enable it:
echo "1" > /proc/sys/net/ipv4/ip_forward
#Sers with dynamically assigned IPs need this
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
###Every time this script is restarted, it is a good idea to flush all rules and start over
#Many tutorials recommend setting OUTPUT to DROP. This is very restrictive, so
#do what suits your needs
$IPTABLES -P INPUT DROP
$IPTABLES -F INPUT
$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -F OUTPUT
$IPTABLES -P FORWARD DROP
$IPTABLES -F FORWARD
$IPTABLES -F -t nat
###Random useful rule examples
#Allow ssh connections inside the LAN only
$IPTABLES -A INPUT -s LAN_NET -p tcp --destination-port ssh -j ACCEPT
#Must enable loopback!
$IPTABLES -A INPUT -i lo -p all -j ACCEPT
$IPTABLES -A OUTPUT -o lo -p all -j ACCEPT
###Foil source IP spoofing; drop incoming packets that claim to be from us,
#and drop outgoing packets that are not from us
$IPTABLES -A INPUT -i $IFACE -s $LAN_NET -j DROP
$IPTABLES -A OUTPUT -o $IFACE -s ! $LAN_NET -j DROP
###Some outgoing traffic must be restricted, to
#foil spyware and trojans from phoning home
$IPTABLES -A OUTPUT -o eth0 -p tcp -dport 31337 -j DROP
$IPTABLES -A OUTPUT -o eth0 -p tcp -sport 31337 -j DROP
###Other good ports to block include 31335, 27444, 27665, 20034 NetBus, 9704, 137-139 (smb)
#...etc.... it may be easier to OUTPUT DROP and then define what is allowed!
Big Fat Warning
We have used only tcp in our examples to this point, but don't forget there are UDP and ICMP packets to contend with as well. In other words, by no means is this a complete firewall tutorial! Hopefully, you now understand the basic concepts and terminology. If you are new to iptables, I recommend starting with some serious TCP/IP study, followed by a review of Oskar Andreasson's wonderful iptables tutorial.
Resources
iptables Tutorial 1.1.19 by Oskar Andreasson
Netfilter/iptables home page - includes downloads, documentation, and mail lists
LinuxGuruz - offers a mondo collection of iptables scripts
Building Secure Servers with Linux by Michael D. Bauer
Here's a copy of Part 1
Building Firewalls with iptables, Part 1
May 28, 2003
By Carla Schroder
Exposing any system, no matter how briefly, to an untrusted network is suicidal. A firewall, while not a 100% secure solution, is absolutely vital. The Linux world gives us an excellent firewall utility in netfilter/iptables. It is free and runs nicely on feeble old PCs. Netfilter/iptables is flexible, powerful, and enables fine-grained control of incoming and outgoing traffic. The two main functions this series will address are building firewalls and sharing Internet connections, which commonly go hand-in-hand. In Part 1 we'll cover basic concepts; Part 2 will offer examples of rulesets for various uses.
Netfilter/iptables is included with the 2.4/2.5 Linux kernel for firewall, network address translation (NAT), and packet mangling functions. Netfilter works inside the kernel, while iptables is the table structure for the user-defined rulesets. Netfilter/iptables is the descendant of our old friends ipchains and ipwadfm (IP firewall administration); for simplicity, let's call it iptables from this point forward.
Some other excellent uses for iptables are for building firewalls for individual Unix/Linux/BSD workstations and also for building firewalls for subnets to protect other platforms. It's free, so why not construct layers of defenses? Depending solely on a gateway firewall is not enough.
iptables reads only packet headers, and as a result does not inspect payload. It also does not perform authentication. For extra security, combine it with a proxy server such as squid. For Windows users, AnalogX is a popular proxy server noted for its ease of use. (Beware that the default configuration is completely insecure. Do not "set it and forget it," as it installs wide open.)
What It Does
The typical setup is to have two network interfaces -- one "outward" and one "inward" (or call them public and private). iptables reads incoming (and outgoing -- don't forget egress filtering!) packet headers and compares them to the rulesets, then forwards the acceptable packets from one interface to the other. Rejected packets are dropped on the spot -- boom splat -- or are directed in other ways, as you prefer.
Packets must traverse tables and chains. iptables has three built-in tables: filter, NAT, and mangle. (The mangle table is for specialized packet alterations, which we will not cover in this series.) Chains are the lists of rules in each table that match packets and then tell what to do with them. Target is any rule that applies to a matching packet. You'll see these terms a lot.
Unlike ipchains and ipfwadm, iptables uses stateful packet inspection. iptables inspects the source and destination IP addresses, the source and destination ports, and the sequence numbers of incoming packets. In a sense, iptables "remembers" which packets are already permitted on an existing connection. This provides a significant gain in security -- ephemeral ports are open only for as long as they are needed, as opposed to requiring all manner of permanent holes in the firewall to accomodate the various protocols. Malicious packets with altered headers are detected and dropped, even when they contain an allowed destination address and port.
Starting and Stopping iptables
This depends on your individual flavor of Linux; a nice rc script does the job, or you can run it manually from the command line. Please consult the docs for your distribution. Part 2 in this series will have sample scripts.
TCP/IP
As always, the more you understand about TCP/IP, the more this stuff makes sense. iptables rules filter and match on packet headers and TCP/IP protocols -- any of them.
Installation
iptables is commonly included in Linux distributions; it would be very unusual to not have it. Run iptables --version to see what's on your system. If for some inexplicable reason you do not have it, see Resources at the end of this article.
Checking Rulesets
man iptables is a complete reference for all the commands and options, or run iptables --help for a quick reference. To view your existing iptables rules, run:
# iptables --list
This is what iptables looks like with no rules defined:
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
As shown in the above example, every packet must first traverse one of three built-in chains: INPUT, OUTPUT, or FORWARD.
Filter is the most commonly used table. Here is the basic syntax for all iptables rules:
iptables [-t table] command [match] [target/jump]
Not every piece of this is required, nor does it need to be in this order; however, this is the usual method, and as always, I encourage verbosity for the sake of clarity.
The filter table is the default if none is specified. The three most common targets in the filter table are ACCEPT, DROP, and REJECT. DROP drops packets dead, with no further processing. No messages are sent at all to anyone. REJECT sends back an error message to the sending host. DROP is very useful, although at times it may have undesirable side effects, such as leaving a messy trail of dead sockets.
Adding Rules
This example rule blocks traffic from a specific IP range because it belongs to a notoriously noxious spammer, and we don't want the spammer's spew polluting our nice systems:
# iptables -t filter -A INPUT -s 123.456.789.0/24 -j DROP
See how it follows the syntax described above. (See man iptables for definitions of the various switches and commands.) Now let's say your users are becoming increasingly vindictive and resentful towards spammers, which is understandable, but certain retaliatory tactics are simply not permissible, at least not from your network. We can also block all outgoing packets directed to the spammer's IPs easily enough with this slightly different syntax:
# iptables -t filter -A OUTPUT -d 123.456.789.0/24 -j DROP
Notice the -A switch. Use this to append rules to existing chains.
Deleting Rules
Spammers are shifty, experts at playing whack-a-mole (in the role of the mole) by continually changing IPs and DNS. Suppose our ignominious spammer moves to a new IP range, and the old IP address is then reassigned to some saintly nuns, whose bits are worthy to traverse your network. Simply delete the rule with the -D switch:
# iptables -t filter -D OUTPUT -d 123.456.789.0/24 -j DROP
Default Policies
Crafting rules to cover every contingency is a nice way to consume mass quantities of time. For those who would rather not, the basic principle is "deny all, allow only as needed." Let's set up the default rules for each chain:
# iptables -P INPUT DROP
# iptables -P FORWARD DROP
# iptables -P OUTPUT ACCEPT
-P sets the policy for the chain. Only the three built-in chains can have policies. These policies permit unfettered outgoing traffic, but no incoming traffic. At the very least, we want to hear from the nuns:
# iptables -t filter -A INPUT -s 123.456.789.0/24 -j ACCEPT
Now go read the one from networker ;)
oh yeah : Source http://www.esecurityplanet.com/trend...le.php/2213171