From: Cedric Blancher <blancher@cartel-securite.fr>
To: "Robert P. J. Day" <rpjday@mindspring.com>
Cc: netfilter mailing list <netfilter@lists.netfilter.org>
Subject: Re: what filtering to do on the OUTPUT chain?
Date: 22 Oct 2002 22:09:04 +0200 [thread overview]
Message-ID: <1035317344.8858.14.camel@elendil> (raw)
In-Reply-To: <Pine.LNX.4.44.0210221455120.15018-100000@localhost.localdomain>
Le mar 22/10/2002 à 20:57, Robert P. J. Day a écrit :
> i've had a number of people tell me that, while they put a
> good deal of thought into their INPUT filtering, they simply
> ACCEPT all outgoing traffic since, if their input filtering
> is working properly, there's no reason to stop outgoing
> packets.
> comments?
Once you have accepted the fact that your box can get compromised, you
easily understand why you should filter outgoing traffic. Moreover,
maximum security relies on the "lesser privilege rule" which specifies
that an object must not be allowed to do more than he has to. According
to this, you have to filter network output.
Consider you have a web server which is vulnerable to a 0day private
flaw. It is exploited, then cracker has a low privilege shell. If your
output is not filtered, he can just send any packet he wants which can
be bad for your environment, especialy when INPUT chain accepts all
ESTABLISHED packets. Well, if he gets root, you're lost unless you
harden your kernel with access control stuff like LIDS. But, in between,
it slows down the attacker and make its progression far more difficult.
If you plan to filter traffic on the box itself, than you have to do it
well. Not filtering in OUTPUT chain is just the same as if you set a
firewall up with no rule for returning packets, something like :
iptables -A FORWARD -s $IN_NET -i $IN_IF -o $OUT_IF -j ACCEPT
which is, imho, truely bad.
You have, on one hand, to protect your box from the outside (that's
INPUT filtering). But on the other hand, you have to protect the rest of
your infrastructure (and also others) from this very box (this is OUTPUT
filtering).
Then it is just a matter of what security level you want to reach ;)
--
Cédric Blancher <blancher@cartel-securite.fr>
IT systems and networks security expert - Cartel Sécurité
Phone : +33 (0)1 44 06 97 87 - Fax: +33 (0)1 44 06 97 99
PGP KeyID:157E98EE FingerPrint:FA62226DA9E72FA8AECAA240008B480E157E98EE
next prev parent reply other threads:[~2002-10-22 20:09 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-22 18:57 what filtering to do on the OUTPUT chain? Robert P. J. Day
2002-10-22 20:03 ` Antony Stone
2002-10-22 23:26 ` Nick Drage
2002-10-22 20:09 ` Cedric Blancher [this message]
2002-10-22 20:10 ` Robert P. J. Day
2002-10-22 23:21 ` Cedric Blancher
2002-10-23 9:43 ` Antony Stone
2002-10-23 10:24 ` Cedric Blancher
2002-10-24 21:31 ` Nick Drage
2002-10-24 23:06 ` Antony Stone
2002-10-22 23:31 ` Nick Drage
2002-10-23 6:51 ` Cedric Blancher
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1035317344.8858.14.camel@elendil \
--to=blancher@cartel-securite.fr \
--cc=netfilter@lists.netfilter.org \
--cc=rpjday@mindspring.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.