Iptables initialization

Dagmar d'Surreal dagmar.wants at nospam.com
Sat Feb 14 08:35:15 PST 2004


(Oh dear, I can see I've started a serious thread here.  Oh well, not
much else to do this morning)

On Thu, 2004-02-12 at 18:32, Archaic wrote:
> 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
> fundamental.

It's important to start with policy, and then enumerate privileges and
develop code from there, because other and following admins will be more
likely to understand things written in english, and if you have to
collaborate with other security engineers, it's good to have something
in plain english that is _not_ code, so that technical errors become
fixable instead of something that requires a higher level of change
management.

> > 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.

No problems on volunteering for that from me.  I kind of figured I would
be writing large chunks of documentation for this particular book
anyway.

> > (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
> nicely.
>
> > 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.

It's generally not necessary to do that...  the why will become more
obvious as I work my way through the first ten emails or so.

> > 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)

There's this nifty little binary called `ip` that fwbuilder's scripts
that is for facilitating stuff like this that I didn't initially have
and wound up copying over from a Mandrake build.  

> > 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 -N LOGDROP &&
> $IPT -A LOGDROP   -j LOG --log-prefix 'DROP: ' &&
> $IPT -A LOGDROP   -j DROP &&
> $IPT -N LOGREJECT &&
> $IPT -A LOGREJECT -j LOG --log-prefix 'REJECT: ' &&
> $IPT -A LOGREJECT -j DROP &&
> 
> 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.

That's one of the kinds of things I am talking about as being a
not-so-good practice.  For just about everything someone can do that's
not "perfect" I can pop right off with a way to use it to defeat the
security model.  For instance, if someone's firewall ruleset does 20x
the amount of work it needs to, then it's 20x easier for someone to
choke the network down (compromise of Availability) by deliberately
overworking the firewall with complex traffic patterns.  (20x is a
large, but somewhat realistic figure.  Even twice as easy is nasty.)

New chains for logging targets is however, perfectly reasonable.  It's
also a good place to put in throttling so that each and every packet
someone generates of 40 bytes doesn't turn into a 128 byte log entry. 
(You can probably see where I'm going with this).  The harder it is for
someone to fill /var/log, the harder it is to get the machine to a state
where they might be able to do something without it being logged.  One
can't assume that an attacker won't know about some specific weakness
that the engineer knows about and is considering acceptable due to it's
obscurity... in practice, a determined attacker will try almost
everything, and even not-so-determined attackers can generally boil down
their intrusion checklist to 20 or so things that will address 90% of
the common vulnerabilities.  Since CERT claims 80% of computer security
incidents are done by "insiders", we can't really assume that potential
violators aren't going to be aware of these little things, either.
-- 
The email address above is phony because my penis is already large enough, kthx. 
              AIM: evilDagmar  Jabber: evilDagmar at jabber.org




More information about the hlfs-dev mailing list