Comments on Basic Iptables - Debian/RedHat

Sarge not exist the iptables exist in /etc/init.d/

for default iptables is installed...but not have a script in these location

SEE: zcat /usr/share/doc/iptables/README.Debian.gz |less

METHOD:
... in /etc/network/interfaces
...run the a packet filtering script (with the interface name and address as arguments) before actually bringing up the interface.

auto eth0
iface eth0 inet dhcp
pre-up /etc/myfirewall.sh $IFACE $IF_ADDRESS

You can find a copy of the script in Sarge at /usr/share/doc/iptables/examples/oldinitdscript.gz

Just gunzip it into /etc/init.d/ as super user

gunzip -c -d /usr/share/doc/iptables/examples/oldinitdscript.gz > /etc/init.d/iptables

and chmod 755 /etc/init.d/iptables

mkdir /var/lib/iptables
chmod 700 /var/lib/iptables
cd /var/lib/iptables/
touch active inactive

In year 2005, writing hand-crafted iptables rules makes about as much sense as using assembly language to produce dynamic webpages. Sure, you can do it and it offers the best possible performance, but does it make sense?

There are dozens of tools that makes it easy to manage iptables. Among those, 2 open source projects stand out far above the rest:

1. Shorewall - http://www.shorewall.net/
2. FireHOL - http://firehol.sourceforge.net/

It is very easy to make mistakes with hand-crafted iptables rules that is hard to detect. You can end up with numerous security holes without even being aware of their existence until someone exploits them.

Seriously consider using one of the above tools, you'll find that they provide all the flexibility you need for managing iptables without having to hand-craft rules using iptables syntax.

I started using shorewall to manage my iptables and I've never looked back. And this includes gateways with multiple ethernet cards, public servers, and secure desktops.

Try any 3 iptables-related projects--the 2 mentioned above and 1 other of your choice. Pick one and you'll end up far better than directly writing iptables rules.

I have to disagree with you. You're making some assumptions that might not be correct.

You say that people would use iptables rules because they offer "the best possible performance"; or alternatively people would use a tool because that "makes it easy to manage iptables". Neither is necessarily true.

I use a custom iptables script because that makes firewalling *easier* for me. No, it's not so easy to learn the syntax of iptables for a beginner; but once you learn, having a firewall script lets you see and (more importantly) proofread all your rules in one file.

If you know anything at all about security, you know that policy is paramount. That's why a firewall script is ideal: you can have the rules, accompanied by comments that describe your policy.

Having a script also makes your firewall easier to distribute. You can copy it to other hosts & modify to suit. You can send or show it to someone who knows more about security than you do, for them to proofread and find holes.

Using a GUI tool just gets in the way. You have to trust that what you *think* you're specifying in the GUI actually gets implemented in the way you intended. And how do you check? By using "iptables -L -v" of course; but now you're back to using iptables anyway!

If you understand firewalling, then iptables is just a tool and it shouldn't be too hard to understand. If not, then is a GUI really going to save you? You'd be better off downloading a boilerplate iptables script that's well-documented, from a reputable source. Or getting a friend who understands firewalling to help you.

the_dave at fastmail dot fm

I agree about using a gui, but shorewall is just a set of scripts that uses txt config files. Easy, efficient and double checked by many people that know.

I added a nice init script that does the work for me, all I have to do is to edit the file from time to time according to my needs.

Here is the script: (/etc/init.d/iptables)

====== CUT BELOW HERE ======

#!/bin/bash
#
if [ ! -x /sbin/iptables ]; then
exit 0
fi

start()
{
# clear all
clearall

# Create new chain (I called it filter) which blocks new
# connections, except if coming from inside.
iptables -N filter
iptables -A filter -m state --state ESTABLISHED,RELATED -j ACCEPT
# The next rule depends on what connection to the NET you have
# It could be ppp0 instead of eth0, suit your own needs
iptables -A filter -m state --state NEW -i ! eth0 -j ACCEPT

# Allowed Services - Here you can put all the actually needed
# ports, a few common examples below:
iptables -A filter -p tcp --dport http -j ACCEPT
iptables -A filter -p tcp --dport ftp -j ACCEPT
iptables -A filter -p tcp --dport smtp -j ACCEPT
iptables -A filter -p tcp --dport pop3 -j ACCEPT
iptables -A filter -p udp --dport 53 -j ACCEPT
# Allowed IPs/Networks
iptables -A filter -p all -s 192.168.0.0/24 -j ACCEPT
iptables -A filter -p all -s 192.168.1.15 -j ACCEPT
# Blacklisted IPs/Networks
iptables -A filter -p all -s 192.168.100.0/24 -j DROP
iptables -A filter -p all -s 10.0.0.32 -j DROP
# drop tcp priv'd ports
iptables -A filter -p tcp --dport 0:1023 -j DROP
# drop udp priv'd ports
iptables -A filter -p udp --dport 0:1023 -j DROP
iptables -A filter -j DROP

# Jump to that chain from INPUT and FORWARD chains.
iptables -A INPUT -j filter
iptables -A FORWARD -j filter


}

clearall()
{
iptables -F
iptables -X
}


case "$1" in
restart|start)
start
;;
stop)
clearall
;;
*)
echo "Usage: $0 {start|stop|restart}"
exit 1
esac

exit 0

===== END CUT =====

After saving this script as /etc/init.d/iptables , don't forget to chmod it

chmod 755 /etc/init.d/iptables

Now you need to add it to the default runlevels, make this command:

update-rc.d iptables defaults 12

Have fun!

Ziv

Hi, you seem to have missed that the init skript is not part of iptables in Sarge anymore: iptables (1.2.7-8) unstable; urgency=low * removed init.d, /var/lib/iptables, and debconf-ization If you still have that file it is probably a relic of older iptables versions from which you upgraded. Because init scripts are treated like configuration files, they are not automatically removed when you remove or upgrade the package. If you want to initialize iptables, you need your own skript, or you can run iptables when the interfaces come up (see /etc/network/interfaces and /etc/network/if-ip.d).

You are correct... this system was upgraded from woody... which I've had running over a year before Sarge was stable.... I shall update this howto as "Pre-Sarge"... and when I get a second do a Sarge install from scratch and update as necessary.

Thanks for the note.

---
BJ Dierkes, RHCE4 - LPIC1
wdierkes [at] machinehost [dot] org
Texas, USA

Thanks so much for your article here. Every document I ever tried to read about iptables before was like a freaking Chinese Instruction Manual! I never realized it could be so easy. Thanks a million.

Wow... and here I thought I might be wasting my time.... ;)

http://www.fwbuilder.org/

It creates fw scripts for that can be automatically deployed to all of yer fw´s using ssh. Best thing is that it´s gui is simular to checkpoints interface, all for free (using linux!) Creating fw setups using windows is gonna cost 49,95 dollars. hahahahah

Thanks for the howto! always nice to see the inner workings!

Just wanted to thankyou for something very rare in the linux world: An easy to understand howto, covering the basics!

Everywhere else, you find badly written solutions to extremely uncommon problems.

Thanks!
&flix

The following page is also pretty good:

http://www.siliconvalleyccie.com/linux-hn/iptables-intro.htm

It outlines how the mangle and nat chains work, which is obviously less useful for most people, but anyway.

I second that!

Too many Linux tutorials (and softwares for that matter) fall victim to Pareto inefficiency (80% of features and documentation for 20% of people) and try to be everything to everyone and end up being overkill for the majority of people.

Kudos on providing concise information that will meet most peoples needs.

Remember that automated tools like Fail2Ban and PortSentry leave you open to denial of service attacks. If someone were spoof the address of an SSH client you regularly connect from, you could be locked out of your server. While it's not easy to spoof enough of an SSH connection to trigger Fail2Ban, it is possible.

Another senario is where you SSH to your home server from behind a corporate NAT router.  Anyone else on you your corporate network could lock you out by simply trying to log in a few times.

I'm not trying to talk anyone out of using Fail2Ban (I use it!), but I think it's important to know the implications of doing so.

Rich B.