[[IPTABLES HELP (fwd)]] (fwd)
---------- Forwarded message ----------
Date: Sat, 14 Jul 2001 17:30:26 -0400
From: Wayne Topa <wtopa@dmcom.net>
To: dude@deletia.com
Subject: [[IPTABLES HELP (fwd)]]
OK, 1 more time. If you don't get this, go to the archives.
----- Forwarded message from Wayne Topa <wtopa@dmcom.net> -----
From: Wayne Topa <wtopa@dmcom.net>
Date: Sat, 14 Jul 2001 10:53:10 -0400
To: dude <dude@deletia.com>
Subject: [debian-security@virtual.doorstop.net: Re: IPTABLES HELP (fwd)]
Reply-To: wtopa@dmcom.net
dude...... You got a very good response sent to the list!
Yes your test messages are also getting there as well.
----- Forwarded message from Vineet Kumar <debian-security@virtual.doorstop.net> -----
From: Vineet Kumar <debian-security@virtual.doorstop.net>
Date: Fri, 13 Jul 2001 15:25:26 -0700
To: debian-firewall@lists.debian.org
Subject: Re: IPTABLES HELP (fwd)
A few general comments on your setup:
You don't have any policy statements. The built-in chains default to
policy ACCEPT, which is probably not what you want. True, the last
statement of your block chain is effectively the same as setting
policy to DROP for INPUT and FORWARD, but I always like to see it
specified right at the top of your firewall setup.
Second, I also like to see rules crafted as explicitly as possible:
include incoming and outgoing interfaces wherever applicable.
It seems to me you have a slightly befuddled view of this setup: you -j
ACCEPT some things and -j DROP other things based on what you think
you need. I have found that an easy way to get a relatively secure
setup is to start with policy drop on all chains and then simply add
rules for only what you want to allow. My first impression of your
ruleset is that it should work and should do what you want it to do.
You won't have any incoming connections made from the outside world
(ssh included).
I know the old saying about giving a man a fish and teaching a man to
fish, so let me try to talk you though the way I'd approach this
setup.
#!/bin/sh
# I find it easier to avoid catastrophic typographical errors and
# allow for easy maintenance by using some definitions at the top;
# something like this:
IPTABLES=/sbin/iptables
INTERNAL_IFACE=eth1
EXTERNAL_IFACE=eth0
INTERNAL_IP=192.168.1.1
INTERNAL_NETWORK=192.168.1.1/27
# no EXTERNAL_IP definition because you're presumedly using a dynamic
# address (hence MASQUERADE, right?)
# These definitions also make the script portable; you can use it on
# your machine just by changing the definitions above and not mess
# with the rules below.
# Start with policy.
$IPTABLES -P INPUT DROP
$IPTABLES -P FORWARD DROP
$IPTABLES -P OUTPUT ACCEPT
# clean up
$IPTABLES -F
$IPTABLES -X
$IPTABLES -Z
# Remember that separate tables need separate statements entirely!
# You're implicitly saying -t filter above, and it doesn't affect
# (clean up) the nat table.
$IPTABLES -t nat -F
$IPTABLES -t nat -X
$IPTABLES -t nat -Z
# Enable nat
$IPTABLES -t nat -s $INTERNAL_NETWORK -d ! $INTERNAL_NETWORK \
-o $EXTERNAL_IFACE -j MASQUERADE
# Filtering section
# INPUT chain
# We want to allow ONLY:
# 1. local (loopback) traffic
# 2. traffic from our LAN hosts
# 3. traffic from the Internet that is part of an existing connection
# (no new connections)
$IPTABLES -A INPUT -i lo -j ACCEPT
$IPTABLES -A INPUT -s $INTERNAL_NETWORK -i $INTERNAL_IFACE -j ACCEPT
$IPTABLES -m state -A INPUT -s ! $INTERNAL_NETWORK \
-i $EXTERNAL_IFACE --state ESTABLISHED,RELATED -j ACCEPT
# FORWARD chain
# We want to forward only for hosts on our LAN. This means 2 rules:
# 1. outgoing traffic
# 2. reply traffic
$IPTABLES -A FORWARD -s $INTERNAL_NETWORK -d ! $INTERNAL_NETWORK \
-i $INTERNAL_IFACE -o $EXTERNAL_IFACE -j ACCEPT
$IPTABLES -m state -A FORWARD \
-s ! $INTERNAL_NETWORK -d $INTERNAL_NETWORK \
-i $EXTERNAL_IFACE -o $INTERNAL_IFACE \
--state ESTABLISHED,RELATED -j ACCEPT
That's it! I'm not sure I explained it too well, and my intention was
not just to do it for you, so please, if you have any questions about
the setup itself *or* about how I came up with it, please don't
hesitate to ask.
Also notice that in this setup I have just let the OUTPUT policy
remain ACCEPT. This should be acceptable for most purposes, unless you
really want to enforce that the gateway system is not to converse with
the Internet, or some such thing. If you did want to do that, it would
be like this:
# change the output policy line above to this:
$IPTABLES -P OUTPUT -P DROP
# Add this to the filtering section:
# OUTPUT chain:
# only allow outgoing traffic:
# 1. to loopback
# 2. to LAN
$IPTABLES -A OUTPUT -o lo -j ACCEPT
$IPTABLES -A OUTPUT -o $INTERNAL_IFACE -d $INTERNAL_NETWORK -j ACCEPT
Note that this practically disconnects the gateway machine from the
Internet, which is probably not what you want. It can still be used to
forward/filter for your LAN, but it will be impossible to, for
instance, use apt-get from the machine (horrors!).
I hope you see what I mean about setting a policy and then only adding
rules for scenarios that go against policy. This approach should keep
your setup cleaner, which will make it easier to troubleshoot/modify
in the future.
Vineet
P.S. IANAG. YMMV.
----- End forwarded message -----
--
Don't compute and drive; the life you save may be your own.
_______________________________________________________
----- End forwarded message -----
--
There can never be a computer language in which you cannot write a
bad program.
_______________________________________________________
Reply to: