authpf allows only one user from the same source ip; kicks off previous user

[Chris Youb]

When multiple users with the same source IP want access through the firewall authpf grants access to the newly authenticating user and kicks off the previous user.  Is there a way to turn off this behaviour so both users maintain authpf tables?

Works:
1a. user1@192.168.0.1 -> authpf -> maintains logon
1b. user2@192.168.0.2 -> authpf -> logs on

Doesn't Work:
2a. user1@192.168.0.1 -> authpf -> gets kicked off
2b. user2@192.168.0.1 -> authpf -> logs on


Real-life example:

Step #1 xuser authenticates from IP_1; xuser has access to firewall
firewall# pfctl -s Anchors -v
 authpf
 authpf/bfisher(25933)
 authpf/xuser(1308)
 authpf/rarthur(15647)
 authpf/schatterjee(31961)

Step #2 cyoub authenticates from IP_2; both xuser and cyoub have access to firewall
firewall# pfctl -s Anchors -v
 authpf
 authpf/bfisher(25933)
 authpf/cyoub(2104)
 authpf/xuser(1308)
 authpf/rarthur(15647)
 authpf/schatterjee(31961)

Step #3 cyoub authenticates from IP_1; ONLY cyoub has access to firewall as he was the last to login.  xuser is kicked off???
firewall# pfctl -s Anchors -v
 authpf
 authpf/bfisher(25933)
 authpf/cyoub(27921)
 authpf/rarthur(15647)
 authpf/schatterjee(31961)

firewall# pfctl -a "authpf/cyoub(27921)" -s rules
pass in quick on bge0 inet from 10.0.1.47 to 172.16.0.0/22 flags S/SA keep state
pass in quick on bge0 inet from 10.0.1.47 to 172.16.4.0/22 flags S/SA keep state
pass in quick on bge0 inet from 10.0.1.47 to 172.16.8.0/22 flags S/SA keep state
pass in quick on bge0 inet from 10.0.1.47 to 172.16.12.0/22 flags S/SA keep state
pass in quick on bge0 inet from 10.0.1.47 to 172.16.20.0/22 flags S/SA keep state
pass in quick on bge0 inet from 10.0.1.47 to 172.16.20.0/22 flags S/SA keep state
pass in quick on bge0 inet from 10.0.1.47 to 172.16.80.0/22 flags S/SA keep state
pass in quick on bge0 inet from 10.0.1.47 to 172.16.48.0/22 flags S/SA keep state
pass in quick on bge0 inet from 10.0.1.47 to 172.16.4.0/22 flags S/SA keep state
pass in quick on bge0 inet from 10.0.1.47 to 172.16.28.0/22 flags S/SA keep state

[beck-7]

        Nope. That's how it is supposed to work.

        The point of authpf is for the user to say "this IP
is me" - if that IP could perhaps not be him, well, this
is not an application for authpf. I.E. if your users
are coming in from a NAT, you should rethink what you
are doing.

        -Bob


* Chris Youb <chris.youb@...> [2007-06-25 15:15]:

> When multiple users with the same source IP want access through the firewall
> authpf grants access to the newly authenticating user and kicks off the
> previous user.  Is there a way to turn off this behaviour so both users
> maintain authpf tables?
>
> Works:
> 1a. user1@... -> authpf -> maintains logon
> 1b. user2@... -> authpf -> logs on
>
> Doesn't Work:
> 2a. user1@... -> authpf -> gets kicked off
> 2b. user2@... -> authpf -> logs on
>
>
> Real-life example:
>
> Step #1 xuser authenticates from IP_1; xuser has access to firewall
> firewall# pfctl -s Anchors -v
>  authpf
>  authpf/bfisher(25933)
>  authpf/xuser(1308)
>  authpf/rarthur(15647)
>  authpf/schatterjee(31961)
>
> Step #2 cyoub authenticates from IP_2; both xuser and cyoub have access to
> firewall
> firewall# pfctl -s Anchors -v
>  authpf
>  authpf/bfisher(25933)
>  authpf/cyoub(2104)
>  authpf/xuser(1308)
>  authpf/rarthur(15647)
>  authpf/schatterjee(31961)
>
> Step #3 cyoub authenticates from IP_1; ONLY cyoub has access to firewall as
> he was the last to login.  xuser is kicked off???
> firewall# pfctl -s Anchors -v
>  authpf
>  authpf/bfisher(25933)
>  authpf/cyoub(27921)
>  authpf/rarthur(15647)
>  authpf/schatterjee(31961)
>
> firewall# pfctl -a "authpf/cyoub(27921)" -s rules
> pass in quick on bge0 inet from 10.0.1.47 to 172.16.0.0/22 flags S/SA keep
> state
> pass in quick on bge0 inet from 10.0.1.47 to 172.16.4.0/22 flags S/SA keep
> state
> pass in quick on bge0 inet from 10.0.1.47 to 172.16.8.0/22 flags S/SA keep
> state
> pass in quick on bge0 inet from 10.0.1.47 to 172.16.12.0/22 flags S/SA keep
> state
> pass in quick on bge0 inet from 10.0.1.47 to 172.16.20.0/22 flags S/SA keep
> state
> pass in quick on bge0 inet from 10.0.1.47 to 172.16.20.0/22 flags S/SA keep
> state
> pass in quick on bge0 inet from 10.0.1.47 to 172.16.80.0/22 flags S/SA keep
> state
> pass in quick on bge0 inet from 10.0.1.47 to 172.16.48.0/22 flags S/SA keep
> state
> pass in quick on bge0 inet from 10.0.1.47 to 172.16.4.0/22 flags S/SA keep
> state
> pass in quick on bge0 inet from 10.0.1.47 to 172.16.28.0/22 flags S/SA keep
> state
> --
> View this message in context: http://www.nabble.com/authpf-allows-only-one-user-from-the-same-source-ip--kicks-off-previous-user-tf3978999.html#a11295667
> Sent from the openbsd user - misc mailing list archive at Nabble.com.
>

--
#!/usr/bin/perl
if ((not 0 && not 1) !=  (! 0 && ! 1)) {
   print "Larry and Tom must smoke some really primo stuff...\n";
}

[Chris Youb]

Bob Beck-2 wrote:

        The point of authpf is for the user to say "this IP
is me" - if that IP could perhaps not be him, well, this
is not an application for authpf. I.E. if your users
are coming in from a NAT, you should rethink what you
are doing.

        -Bob

  I fully understand your reasoning.  Under normal circumstances users authenticate from their desktop machines (which is a unique IP) and therefore not a problem.  However, sometimes they are VNC'd into servers (more CPU power) and want to access resources behind the internal 'firewall'.  This was fine until we came across multiple VNC sessions on the same server.  I realize there would be a tiny loop-hole in that user A would be able to access user B's authenticated resources and vice-versa but that was a reasonable risk (these are all internal users).

  The only other option for users sharing resources on a single server was to give each VNC session a unique IP.  And the only way I know how to do that is via virtualization.  If there was one VNC session per user domain this wouldn't be a problem.  However, that is bit of work.

  In short, I know the consequences of authenticating multiple users from the same IP... is there an easy way to turn off this authpf feature? ;)

[Theo de Raadt]

>   In short, I know the consequences of authenticating multiple users from
> the same IP... is there an easy way to turn off this authpf feature? ;)

You still don't understand.

It's not a feature.  It is a requirement.

If you don't like it, then you can't provide any of the functional
parts that authpf provides.  It's a requirement for rule addition and
rule deletion to KNOW where a session is from.

Otherwise, you might as well just use pf itself, without any logging in,
because your authpf logins really mean nothing.

[beck-7]

>   I fully understand your reasoning.  Under normal circumstances users
> authenticate from their desktop machines (which is a unique IP) and
> therefore not a problem.  However, sometimes they are VNC'd into servers
> (more CPU power) and want to access resources behind the internal
> 'firewall'.  This was fine until we came across multiple VNC sessions on the
> same server.  I realize there would be a tiny loop-hole in that user A would
> be able to access user B's authenticated resources and vice-versa but that
> was a reasonable risk (these are all internal users).
>
>   The only other option for users sharing resources on a single server was
> to give each VNC session a unique IP.  And the only way I know how to do
> that is via virtualization.  If there was one VNC session per user domain
> this wouldn't be a problem.  However, that is bit of work.

        Stop talking about VNC and talk about unix shell accounts
and I've been exactly where you are - 15 years ago :)  it's the same
damn thing. I don't use authpf from shell hosts, or reccomend it's
use from them either.

>
>   In short, I know the consequences of authenticating multiple users from
> the same IP... is there an easy way to turn off this authpf feature? ;)

        Nope. and there won't be. it's important. You should just allow
your VNC'ed host through the firewall and trust that it has adequate logging
and security to deal with user separation.. Can't do that.. hmm.. then
authpf is doing *nothing* for you.

        -Bob