From: Cedric Blancher <blancher@cartel-securite.fr>
To: Antony Stone <Antony@Soft-Solutions.co.uk>
Cc: netfilter mailing list <netfilter@lists.netfilter.org>
Subject: Re: what filtering to do on the OUTPUT chain?
Date: 23 Oct 2002 12:24:10 +0200 [thread overview]
Message-ID: <1035368650.8853.33.camel@elendil> (raw)
In-Reply-To: <200210230943.g9N9hiL02304@vulcan.rissington.net>
Le mer 23/10/2002 à 11:43, Antony Stone a écrit :
> The OUTPUT rules are always going to allow traffic to or from expected
> ports. 53 is a good one to guess is going to be made accessible, so
> you simply set up netcat to contact your external system on port 53,
> and you can still do what you've outlined above even with pretty good
> OUTPUT filters in place.
Yes you can. Even if you're facing a rule like
iptables -A OUTPUT -p udp -d $IN_DNS --dport 53 -j ACCEPT
You can use DNS tunnel stuff. But it makes things more difficult. And it
is just the point of security tools.
> If you're concerned about this level of security (which you should be) then
> you need to deal with Operating System security and things like Host
> Intrustion Detection - netfilter is not going to do the job effectively for
> you.
Yeah sure, but it's an active part of the overall stuff, and, as such,
must be completly configured.
If I begin to admit the fact that because one tool does not all the job
for me, I can let it unconfigured, well, I do not see the point of
filtering INPUT with Netfilter ? My closed ports are closed, and open
ones can be wrapped, so what's the point adding packet filtering for
local applications that can provide address based access control through
tcpd or internal wrappers ? No tool can provide full security alone.
Each one is one brick of the wall. If bricks are missing, you wall is
shacky.
My point of vue is that you should use every security mecanism available
to enforce your security policy. You can say that it is too much work,
too much time or too much money to do ; I understand this kind of
reason. But doing nothing because what you can implement can be evaded
is not a valuable reason, imho. If you extend this, you would not set
security at all, as every security tool can be evaded.
--
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-23 10:24 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
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 [this message]
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=1035368650.8853.33.camel@elendil \
--to=blancher@cartel-securite.fr \
--cc=Antony@Soft-Solutions.co.uk \
--cc=netfilter@lists.netfilter.org \
/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.