Iptables initialization

Archaic archaic at indy.rr.com
Thu Feb 12 16:32:11 PST 2004

On Thu, Feb 12, 2004 at 04:54:49PM -0600, Dagmar d'Surreal wrote:
> To clarify the nature of what kind of thinking is needed, I want to
> point out that much of the brain work in security engineering does not 
> actually involve meddling with source code.  Quite often the main work
> is done just by isolating what's called "best practices" and
> implementing those in the configuration and/or design stages of
> deployment.

Absolutely agreed. I know Robert agrees as well. We just haven't gotten
that far, yet. I fully believe in the combination of tightest code, and
tightest privs necessary. I see them both as equally necessary and

> PRINCIPLE OF LEAST PRIVILEGE: That which is not explicitly allowed, is
> automatically denied.

I understand you came to the list late and probably didn't want to read
all the archives. This has been agreed upon as utterly vital. A major
section on firewalling is planned. Looks like you volunteered. ;) Also,
we will be focusing much more on sysadmin practices. Granted, we won't
be able to be ultimately specific, but text and links are planned for
the reader, not just commands to build a box that protects against
buffer overflows.

> (With respect to a host's participation in a network, it means that the
> machine should initially respond to *no* packets whatsoever.  When a
> host is acting as a firewall, it is especially important that this be
> the case, and as to routers, it's actually documented in an RFC for
> machines acting as routers that they should have their policies in place
> before enabling any interface for routing.)

Shall I just post my firewall scripts? You're preaching to the choir. :)
I use a pre-network-up script and a post-network-up script. Throw in
some nice seds and greps and you don't even have to hardcode the
interface names. I've been using that for awhile and it works quite

> In theory, this means that your security policies should always begin
> with the most restrictive policy possible (i.e., no one is allowed to do
> anything), and then add policy that allows the users who need access the
> ability to do the specific things they need to do.

Just a note; I also prefer specifically denying certain known weaknesses
as well, even if they would be denied by default. The reason for this is
in case I make some bonhead mistake when allowing something, it will
still be denied.

> I've just about got this all solved, but I want to see if there are
> any fresh ideas to this end before I publish my solutions because
> someone just might come up with something unique and useful.

# Our real device interface (eth*, ppp*, etc.) and its settings
InFACE="eth0" # Edit InFACE according to your hardware
InIP="`ifconfig $InFACE |grep addr: |sed 's%.*addr:\([^ ]*\) .*%\1%'`" &&
InBCAST="`ifconfig $InFACE |grep Bcast: |sed 's%.*Bcast:\([^ ]*\) .*%\1%'`" &&
InMSK="`ifconfig $InFACE |grep Mask: |sed 's%.*Mask:\([^ ]*\)%\1%'`" &&
InNET="$InIP/$InMSK" &&

# You can comment these out after you've finished testing and modifying
# the script to your specific needs.
#echo -e "\nMake sure the follwing values are correct:" &&
#echo -e  "InFACE=$InFACE\nInIP=$InIP\nInBCAST=$InBCAST" &&
#echo -e "InMSK=$InMSK\nInNET=$InNET\n" &&

(stolen from Real World Linux Security)

> Mind you, what folks should be thinking about is a generic method (i.e.,
> a best practice) for implementing firewalling rulesets, not a list of
> specific firewall rules that people should use.
> (hint: firewalling rules that won't match are a waste of CPU cycles)

So I guess you don't like this:

PORTBLOCK="0:1 13 98 111 137:139 445 161:162 512:515 517:518 520 1080 3128 \
8000 8008 8080 1214 2049 6000 6112 9000 1999 4329 6346 3049 12345 65535" &&
for i in $PORTBLOCK; do
        $IPT -A INPUT   -p tcp  --dport $i -j LOGDROP
        $IPT -A OUTPUT  -p tcp  --dport $i -j LOG --log-prefix 'TEST: '
        $IPT -A OUTPUT  -p tcp  --dport $i -j DROP
        $IPT -A INPUT   -p udp  --dport $i -j LOGDROP
        $IPT -A OUTPUT  -p udp  --dport $i -j LOGDROP
done &&

BTW, you'll notice I use modified log targets to avoid excessive typing:

$IPT -A LOGDROP   -j LOG --log-prefix 'DROP: ' &&
$IPT -A LOGREJECT -j LOG --log-prefix 'REJECT: ' &&

It's nifty!

Well, there you go. Some initial ideas from me. Never had any noticeable
slowdown with the explicity prot drops (and yes, the default rule is to
drop all, not just these). Dag, let me know if you'd like to see my 2
scripts. I can bzip them and send them to you if you'd like.


I recall the *first* time I read through the docs. The pain was
immediate, intense and interminable!

- Bill Maltby (in a post on the LFS mailing lists)

More information about the hlfs-dev mailing list