A Humble Proposal

A Humble Proposal

[John A. Sullivan III]

	What an interesting project! Perhaps nufw and ISCS
(http://iscs.sourceforge.net) can share some ideas.  ISCS plans to
support the dynamic creation of iptables rules based upon LDAP, AD, NDS,
SecureID and RADIUS in version 2.x.  It currently supports the dynamic
creation of iptables rules based upon the fields of a user's X.509
digital certificate.  The scripts to make this happen on the enforcement
device are in the project CVS but we are still building the
administrative interface.  In fact, we may be looking to hire a few
developers to accelerate this process.  Please feel free to use the
scripts if they are of help - John
-- 
John A. Sullivan III
Chief Technology Officer
Nexus Management
+1 207-985-7880
john.sullivan@nexusmgmt.com
---
If you are interested in helping to develop a GPL enterprise class
VPN/Firewall/Security device management console, please visit
http://iscs.sourceforge.net 

> 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.
NuFW provides these sort of things :
  http://www.nufw.org
Code can be considered has beta code. It works but things need to be
done (especially a Windows Client ;-).
With NuFW, you really filter by User (Group) and not by IP as it often
the case.

Re: A Humble Proposal

[John A. Sullivan III]

	I can certainly appreciate the desire to do this and it would be most
helpful for us in the ISCS project but there are some significant
hurdles if I correctly understand what you desire.
	I will be delighted to be wrong on this subject so, if someone sees a
better way, please correct me.  In ISCS (http://iscs.sourceforge.net),
we have been very interested in out-of-band authentication.  As far as I
know, all we consistently have to identify a user when the packet comes
in (in-band authentication) is the IP address.  How do we associate some
other kind of user authentication with this packet stream?
	We have been able to successfully use out-of-band authentication with
X.509 certs because we associate them with a specific tunnel using
FreeS/WAN (http://www.freeswan.org) and the X.509 patch
(http://www.strongsec.com).  When the IPSec session is initiated, we
capture the various fields of the cert (actually the fields in the
passed DER_ASN.1_DN ID) and the issuing CA.  We compare these against a
list of user groups associated with those fields (wildcards are allowed
in the security definitions so that we don't have to define every
specific user - just groups of users).  We then dynamically create rules
in the FORWARD or INPUT chains to jump the associated IP addresses to
the chains that contain the rules for those groups.  When the IPSec
session is torn down, we dynamically delete those chain jump rules.
	This is relatively safe against spoofing since we look for the traffic
coming off the ipsec interface.  It can't get to that interface unless
it has been authenticated in the IPSec tunnel creation and we will not
have two identical IPSec sessions with the same IP address.
	Other forms of out-of-band authentication are much more difficult.  We
have examined two approaches. One is to have a user application handle
it and the request for the authentication comes from the gateway.  The
other is to have the user initiate the authentication via something like
a Java app running in a browser.
	We found the first approach highly problematic.  It involves the
creation, distribution and maintenance of an OS specific application. 
The mechanism creates firewall problems.  Basically, the data packet
arrives at the gateway and the gateway sees if it has any rules to allow
the packet.  If it does not, it initiates a conversation with the
application running on the user's computer to ask for any other means of
identification.  Since the stream is initiated by the gateway, the
request is blocked if the user is behind a firewall that does not
(wisely) allow such inbound initiated streams.
	The user authentication method is much friendlier that way.  The data
stream is initiated by the user before sending any data packets and it
can run in any browser on any platform (theoretically!). However, we
have not yet set our minds to working around the spoofing problem.  Once
a user's IP address has been cached against that ID, in other words -
the dynamic iptables rules have been created based upon the
authentication and are checking packets on the physical interface, what
is to prevent another user from spoofing that address and obtaining the
same security clearance?
	My understanding from some of the major vendors who have implemented
this kind of out-of-band authentication is that they are subject to
spoofing attacks and it is an imperfect science.
	It would be wonderful if this could be in the state table but since the
authentication is a different data stream than the service data request,
how would it be associated? What happens when the user wishes to access
a different service, e.g., they first check their e-mail and then wish
to access the Human Resources web server? I,too, would love the ability
to do this but I see it as quite a challenging proposal.  Good luck to
all those working on it - John
-- 
John A. Sullivan III
Chief Technology Officer
Nexus Management
+1 207-985-7880
john.sullivan@nexusmgmt.com
---
If you are interested in helping to develop a GPL enterprise class
VPN/Firewall/Security device management console, please visit
http://iscs.sourceforge.net 

RE: A humble proposal

[Daniel Chemko]

I had a thought about this, and I see a lot of work taking this
approach.

How about this:

Write a jump target that applies only inside the filter table, since the
first revision would just implement filtering control.

The module itself would be initialized by a userspace tool be adding
rules. An example would be:

iptables -I INPUT -m expire --expire-condition timer=6000 --expire-id
12123124325 --source 192.168.1.1/24 -j ACCEPT
iptables -I OUTPUT -m expire --expire-condition timer=6000 --expire-id
12123124326 --destination 192.168.1.1/24 -j ACCEPT

Since they are inserted in these tables, they should be called before
ESTABLISHED,RELATED is even hit.

The jump determines if the packets are valid any longer. The problems
that I can see here are:

- The rule itself needs to be cleared out of the chain once it is
expired. I could get the daemon to do some housekeeping, but it'd be
better if the jump module could clean up its own reference. Can this be
done?

- The CONNTRACK entries for the allowed sessions are not dropped. Once
again, it would be nice if the jump module could clean up the CONNTRACK
entry.


-----Original Message-----
From: Joel Newkirk [mailto:firewalldude@newkirk.us] 
Sent: Tuesday, September 23, 2003 2:10 PM
To: Daniel Chemko
Cc: netfilter@lists.netfilter.org; netfilter-devel@lists.netfilter.org
Subject: Re: A humble proposal

On Tue, 2003-09-23 at 12:13, Daniel Chemko wrote:
> I have been researching some possible extensions to the Netfilter
> environment, and something has become very necessary for my current
> environment. The following proposal outlines what I wish to implement.
I
> am wondering if anyone would find value in this. Plus, I look forward
to
> feedback so that I may improve my ideas.


> Suggestion:
> 
> I would like to take pam_iptables and expand it beyond its simple
> structure. Features will include:

My humble suggestion would be that this should be handled in the
stateful
connection tracking - If a session is authenticated and certain
connections
are to be allowed, then the new allowed connections would be of state 
"related".  Really handy would be the ability to distinguish these
particular
'related' connections and feed them through specific chains.  I for one 
would NOT want to simply open the box (or network) wide for every
authenticated 
connection, but would like to be able to specify a different set of
(more 
permissive) rules for them once authenticated.  Perhaps patch an
additional
state - "PAM" or "AUTH".  Or the ability to specify a fwmark that is
automatically implemented for RELATED traffic to the authenticated
session,
allowing different chains to be traversed based on the mark found.

j

RE: A humble proposal

[Eric Leblond]

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

Le ven 26/09/2003 à 02:19, Daniel Chemko a écrit :
> I had a thought about this, and I see a lot of work taking this
> approach.
> 
> How about this:
> 
> Write a jump target that applies only inside the filter table, since the
> first revision would just implement filtering control.
> 
> The module itself would be initialized by a userspace tool be adding
> rules. An example would be:
> 
> iptables -I INPUT -m expire --expire-condition timer=6000 --expire-id
> 12123124325 --source 192.168.1.1/24 -j ACCEPT
> iptables -I OUTPUT -m expire --expire-condition timer=6000 --expire-id
> 12123124326 --destination 192.168.1.1/24 -j ACCEPT

Great, but Have you any idea of the induced overload ? (I've never work
with dynamic rules).

> - The CONNTRACK entries for the allowed sessions are not dropped. Once
> again, it would be nice if the jump module could clean up the CONNTRACK
> entry.
> My humble suggestion would be that this should be handled in the
> stateful
> connection tracking - If a session is authenticated and certain
> connections
> allowing different chains to be traversed based on the mark found.

From my point of view this is a good idea for a mono user machine land.
But I think this appproach is for more too restrictive and too unsecure.

First, lot's of people use "terminal server" (X remote server, rdesktop,
cytrix,...) so you've got different people coming from the same IP who
should have dissociated IPs. In such a case, the permissions of these
users is the sum of the permissions of all users. It's really unsecure.

Second, you encounter harsh limitation with Full multiuser server. It's
a nice security feature to be able to say for example :
  - Clamav daemon can connect directly to sites providing antivirus
pattern update
  - Other users can't go directly out by http.
It's a small example taken from my test environnement of NuFW, but I
think it shows what can be done.

BR,
-- 
Eric Leblond
Nufw, Now User Filtering Works (http://www.nufw.org)

[-- Attachment #2: Ceci est une partie de message numériquement signée. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

A humble proposal

[Daniel Chemko]

I have been researching some possible extensions to the Netfilter
environment, and something has become very necessary for my current
environment. The following proposal outlines what I wish to implement. I
am wondering if anyone would find value in this. Plus, I look forward to
feedback so that I may improve my ideas.


Problem:

When you need to have internet services open to the internet, some of
them are inherently insecure, such as FTP, SMB, etc. Even if the
protocols have built in encryption, there is still a chance that the
protocol can be compromised.

Also, I have a VPN connection into my internal network. I want anyone
connecting to be forced to authenticate to access mission-critical
components of the system, keeping them safe unless the user themselves
need to do emergency work on these servers.

Related:

While looking into PAM support for various Hardware Tokens, I can
across, pam_iptables. This allows one to login to a SSH, Telnet, or
whatever PAM supported daemon is installed with the module. Once
authenticated, the user has full TCP/IP access to the machine. Once the
SSH session has been closed, so does the iptables rule for access to the
system.

Suggestion:

I would like to take pam_iptables and expand it beyond its simple
structure. Features will include:

- Getting rid of the requirement to keep SSH open the whole time
- Create a daemon that keeps track of the sessions, instead of worrying
about the lifetime of the PAM session
- Allow iptables or any command to be executed once successful
authentication has occurred
- Customize the executed commands based on user/groups to give more fine
grained control over who has what protocol access
- Ability to expire sessions based on:
	- Upload/Download Quotas
	- Time in the system
	- Time idling on all services
	- Line Hang-up (VPN disconnect)
	- Other events that I can't think up on the spot

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

Re: A humble proposal

[Eric Leblond]

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

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

NuFW provides these sort of things :
  http://www.nufw.org
Code can be considered has beta code. It works but things need to be
done (especially a Windows Client ;-).
With NuFW, you really filter by User (Group) and not by IP as it often
the case.

BR,
-- 
Eric Leblond
Nufw, Now User Filtering Works (http://www.nufw.org)

[-- Attachment #2: Ceci est une partie de message numériquement signée --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: A humble proposal

[Joel Newkirk]

On Tue, 2003-09-23 at 12:13, Daniel Chemko wrote:
> I have been researching some possible extensions to the Netfilter
> environment, and something has become very necessary for my current
> environment. The following proposal outlines what I wish to implement. I
> am wondering if anyone would find value in this. Plus, I look forward to
> feedback so that I may improve my ideas.


> Suggestion:
> 
> I would like to take pam_iptables and expand it beyond its simple
> structure. Features will include:

My humble suggestion would be that this should be handled in the stateful
connection tracking - If a session is authenticated and certain connections
are to be allowed, then the new allowed connections would be of state 
"related".  Really handy would be the ability to distinguish these particular
'related' connections and feed them through specific chains.  I for one 
would NOT want to simply open the box (or network) wide for every authenticated 
connection, but would like to be able to specify a different set of (more 
permissive) rules for them once authenticated.  Perhaps patch an additional
state - "PAM" or "AUTH".  Or the ability to specify a fwmark that is
automatically implemented for RELATED traffic to the authenticated session,
allowing different chains to be traversed based on the mark found.

j

Re: A humble proposal

[Harald Welte]

[-- 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 --]

Re: A humble proposal

[Eric Leblond]

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

Le jeu 02/10/2003 à 21:51, Harald Welte a écrit :
> On Tue, Sep 23, 2003 at 09:13:21AM -0700, Daniel Chemko wrote:
> > 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.

I agree with you in the sense that we can do a better work. As I said
earlier in this thread and in this mailling list, the current tools
provided by Netfilter are great enough to build a good user
authentication system.

The NuFW project (http://www.nufw.org) has managed to build a user
authentication of packet, by (only) using libipq. We (the NuFW team)
think that in the current state of the project, we have managed to prove
the viability of the concept.

But, it's just the beginning ! With a slight modification of libipq and
of the corresponding module conbined with the use of CONNMARK, we should
be able to provide a user based marking of the connection.
If we're able to do so, the path to a user based ,QOS, bandwith sharing,
or even routing will be wide open.

We think that it's not a 'feature' but that it could really bring
something to the iptables community.

BR,
-- 
Eric Leblond
Nufw, Now User Filtering Works (http://www.nufw.org)

[-- Attachment #2: Ceci est une partie de message numériquement signée. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]