Linux Netfilter discussions
 help / color / mirror / Atom feed
From: Harald Welte <laforge@netfilter.org>
To: Daniel Chemko <dchemko@smgtec.com>
Cc: netfilter@lists.netfilter.org, netfilter-devel@lists.netfilter.org
Subject: Re: A humble proposal
Date: Thu, 2 Oct 2003 21:51:32 +0200	[thread overview]
Message-ID: <20031002195132.GA5758@sunbeam.de.gnumonks.org> (raw)
In-Reply-To: <7C9884991ADAE0479C14F10C858BCDF5122E46@alderaan.smgtec.com>

[-- Attachment #1: Type: text/plain, Size: 1600 bytes --]

On Tue, Sep 23, 2003 at 09:13:21AM -0700, Daniel Chemko wrote:
 
> I would like to take pam_iptables and expand it beyond its simple
> structure. Features will include:
> [...]

Feel free to implement those features.

> Since PAM returns the originating IP address of the request, most of the
> rule functionality can be used to discriminate on a host level. I don't
> think many people would have a problem with this. The only side effect
> here is that a user behind a NAT'd network accessing the system opens
> the services to everyone behind that host. This is unavoidable.

I personally don't believe in this kind of 'security'.  The only way to
do this in a really secure way is to open a VPN tunnel to your firewall
and do the authentication related to the VPN protocol used.   Your
firewall ruleset can then have seperate rules for packets coming from
the VPN or packets outside of the VPN sessions.

> I have seen some of this functionality in Checkpoint, and I think that
> it would be immensely useful in the iptables community if it is adopted.

Just because a particular proprietary vendor offers a 'feature', it
doesn't necessarrily mean that we need to do a blind copy of that
feature.

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

  parent reply	other threads:[~2003-10-02 19:51 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-23 16:13 A humble proposal Daniel Chemko
2003-09-23 16:39 ` Eric Leblond
2003-09-23 21:10 ` Joel Newkirk
2003-10-02 19:51 ` Harald Welte [this message]
2003-10-02 21:26   ` Eric Leblond
  -- strict thread matches above, loose matches on Subject: below --
2003-09-24 10:57 A Humble Proposal John A. Sullivan III
2003-09-26  0:19 A humble proposal Daniel Chemko
2003-09-26  7:21 ` Eric Leblond
2003-09-26 11:53 A Humble Proposal John A. Sullivan III

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=20031002195132.GA5758@sunbeam.de.gnumonks.org \
    --to=laforge@netfilter.org \
    --cc=dchemko@smgtec.com \
    --cc=netfilter-devel@lists.netfilter.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox