Article delegate-en/4901 of [1-5169] on the server localhost:119
  upper oldest olders older1 this newer1 newers latest
search
[Top/Up] [oldest] - [Older+chunk] - [Newer+chunk] - [newest + Check]
[Reference:<_A4900@delegate-en.ML_>]
Newsgroups: mail-lists.delegate-en

[DeleGate-En] Re: Does Delegate support user-based access lists, with those users authenticated by a RADIUS server?
11 Sep 2010 09:27:38 GMT feedback@delegate.org (Yutaka Sato)
The DeleGate Project


In message <_A4900@delegate-en.ML_> on 09/11/10(15:28:24) I wrote:
 |The following is an example of a configuration of DeleGate
 |as a SOCKS proxy 1),
 |with proxy authentication/authorization by PAM 2),
 |with access permittion only for SSH servers 3),
 |with access restriction based on client hosts 4).
 |
 | ## 1) ################### a SOCKS proxy
 | -P1080
 | SERVER=socks
 |
 | ## 2) ################### adding auth. by PAM
 | AUTHORIZER=-pam
 |
 | ## 3) ################### adding restriction on destination protocol/port
 | REMITTABLE=tcprelay/22 ## allow destination port num. 22 only
 |
 | ## 4) ################### adding restriction on unreachable serv. for clients
 | HOSTLIST=ConsServ:svhost1,svhost2   ## permitted servers for consultants
 | HOSTLIST=ConsClnt:clhostA,clhostB   ## from which hosts consultants access
 | REJECT=tcprelay:!ConsServ:ConsClnt  ## reject consul. access to 
 | PERMIT=tcprelay:*:!ConsClnt
 |
 |Note that in this case these 2),3),4) are orthogonal and independent from
 |others; all of them are optional and can be used with any combinations.
 |Also, in the SOCKS proxy, DeleGate does not care the kind of application
 |protocols relayed on it, and regards them just a "tcprelay".
 |
 |Here is another way to restrict access (not by client hosts but) by user
 |names authenticated by AUTHORIZER, as follows.
 |
 | ## 4') ################## access restriction based on authenticated names
 | HOSTLIST=ConsServ:svhost1,svhost2
 | REJECT=tcprelay:!ConsServ:user1@*,user2@*  ## users authenticated by 2)
 | PERMIT=tcprelay:*:*

Maybe the safest configuration in your usage is restricting the target
servers available for "consultants" who are identified as A) any users
making accesses from "consultants' hosts" or B) users authenticated by
"consultant name" on any host.  This can be represented by a mixture
of 4) and 4') as follows:

 ## 4'') ################## access restriction based on authenticated names
 HOSTLIST=ConsServ:svhost1,svhost2
 HOSTLIST=ConsClnt:clhostA,clhostB
 REJECT=tcprelay:!ConsServ:ConsClnt,user1@*,user2@*
 PERMIT=tcprelay:*:*

Cheers,
Yutaka
--
  9 9   Yutaka Sato, CSDP#005482 <y.sato@delegate.org> http://delegate.org/y.sato/
 ( ~ )  National Institute of Advanced Industrial Science and Technology
_<   >_ 1-1-4 Umezono, Tsukuba, Ibaraki, 305-8568 Japan
Do the more with the less -- B. Fuller

  admin search upper oldest olders older1 this newer1 newers latest
[Top/Up] [oldest] - [Older+chunk] - [Newer+chunk] - [newest + Check]
@_@V