(RADIATOR) proxy impersonating many NASen :-(

Hugh Irvine hugh at open.com.au
Wed May 30 19:49:34 CDT 2001 

Hi Neale -

On Wednesday 30 May 2001 23:24, Neale Banks wrote:
> G'day Hugh,
>
> > I would like to see some packet dumps from this proxy, as rewriting the
> > NAS-IP-Address is completely bogus.
>
> Packet dumps coming separately.  I agree that rewriting the NAS-IP-Address
> is just "not Cricket" - and rewriting them all to the same value isn't
> even Ice Hockey ;-)
>
> > In any case, as you rightly point out, the standard Radiator behaviour is
> > based on a unique NAS-IP-Address/NAS-Port tuple, and if this is not
> > unique then you will have problems.
>
> Yes.  Looking a bit further under the hood at the Radiator (yes, pun
> intended ;-) I see that it's actually "$nas_id:$nas_port" that must be
> unique and that Radius.pm first tries NAS-IP-Address then NAS-Identifer
> when determining $nas_id - fine but for this bit of Radius.pm:
>
>             # Theres no Nas-IP-Address, so try for NAS-Identifier
>             my $nas_id = $self->getAttrByNum
>                 ($Radius::Radius::NAS_IDENTIFIER);
>             if ($nas_id =~ /(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})/)
>             {
>                 $self->{CachedAttrs}{NasId} = $1;
>             }
>
> Not being a perl programmer, I struggle - but that does look mightily like
> as if NAS-Identifier will only get into $nas_id if NAS-Identifier looks
> like an IP Address in dotted-quad format.  But RFC2865 defines
> NAS-Identifer as a string, so it can legitimately take almost any form.
> What have I missed?
>
> > You basically have two options. The first is to find something in the
> > packet that is unique and use that. And the second is to do some
> > manipulation of the contents of one or more attributes to generate
> > something unique.
>
> Agreed.  And as I can't find anything unique-to-NAS in the packet, that
> leaves manipulation.
>
> > In either case, I would use an SQL session database and set up your own
> > queries in the SessionDatabase SQL clause, which avoids having to mess
> > around with the standard Radiator code.
>
> What a fiendishly clever idea!  Unfortunately there's no convenient SQL
> repository right now - but I'll definitely keep that one in mind.
>
> > One note on your hack-around below - by definition the Access-Request's
> > will not contain an Acct-Session-Id (at least I would be surprised if
> > they did), so I doubt that you will be able to do what you describe.
>
> No, the Access-Request does include Acct-Session-Id (according to the
> RFC2866 it MAY do this: "An Access-Request packet MAY have an
> Acct-Session-Id; if it does, then the NAS MUST use the same
> Acct-Session-Id in the Accounting- Request packets for that session" -
> hopefully it's only an oversight that that last MUST is not currently
> being complied with).
>From owner-radiator at open.com.au Wed May 30 18:06:22 2001
Received: (from majordomo at localhost)
	by server1.open.com.au (8.11.0/8.11.0) id f4UN6Mt29776
	for radiatorzz-list; Wed, 30 May 2001 18:06:22 -0500
X-Authentication-Warning: server1.open.com.au: majordomo set sender to owner-radiator at open.com.au using -f
Received: from entoo.connect.com.au (entoo.connect.com.au [192.189.54.8])
	by server1.open.com.au (8.11.0/8.11.0) with ESMTP id f4UN6CD29768
	for <radiator at open.com.au>; Wed, 30 May 2001 18:06:20 -0500
Received: from hugo (acc16-ppp216.mel.dialup.connect.net.au [210.10.135.216])
	by entoo.connect.com.au (Postfix) with SMTP
	id C140EDD41A; Thu, 31 May 2001 10:59:32 +1000 (EST)
From: Hugh Irvine <hugh at open.com.au>
Reply-To: hugh at open.com.au
Organization: Open System Consultants
To: Gerd Bitzer <gerd.bitzer at tesion.de>, radiator at open.com.au
Subject: Re: (RADIATOR) Subroutines or Macros
Date: Thu, 31 May 2001 10:55:43 +1000
X-Mailer: KMail [version 1.1.99]
Content-Type: text/plain;
  charset="us-ascii"
References: <3B14E688.6DCDDC42 at tesion.de>
In-Reply-To: <3B14E688.6DCDDC42 at tesion.de>
MIME-Version: 1.0
Message-Id: <0105311055435H.00907 at hugo>
Content-Transfer-Encoding: 8bit
Sender: owner-radiator at open.com.au
Precedence: bulk


Hello Gerd -

On Wednesday 30 May 2001 22:24, Gerd Bitzer wrote:
> Hi List,
>
> there are multiple Handlers defined in my radius.cfg, but there are
> identical lines in each of the Handlers, typically RewriteUsername
> statements.
> Is there a way to define a kind of subprogram or macro, which could be
> referenced inside each of the handlers, but could then be maintained
> only once in this subprogram ?
>

You can define your AuthBy clauses outside your Handlers and use Identifiers 
to refer to them, like this:

# define AuthBy clauses

<AuthBy ....>
	Identifier CheckSomeThing
	....
</AuthBy>

<AuthBy ....>
	Identifier CheckAnotherThing
	.....
</AuthBy>

<AuthBy GROUP>
	Identifier CheckSeveralThings
	AuthByPolicy .....
	AuthBy CheckSomeThing
	AuthBy CheckAnotherThing
	.....
</AuthBy>

# now define Handlers

<Handler .....>
	AuthBy CheckSeveralThings
	.....
</Handler>

<Handler .....>
	AuthBy CheckSeveralThings
	.....
</Handler>


Note that you can also use "Include" files if you wish, although I personally 
prefer the above format.

regards

Hugh


-- 
Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.
ba mencionadas. Si usted no es el destinatario
> señalado, le informamos que cualquier divulgación, copia, distribución o
> uso de los contenidos está prohibida. Si usted ha recibido este mensaje por
> error, por favor borre su contenido y comuníquenoslo en la dirección
> postmaster at bt.es. Gracias
> ===
> Archive at http://www.open.com.au/archives/radiator/
> Announcements on radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' with
> 'unsubscribe radiator' in the body of the message.

-- 
Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.


Quite right - I've just never seen it before.

> I think this whole problem would go away if:
>
> * the proxy did NOT send NAS-IP-Address at all (or we strip it out), and
> * the proxy sent NAS-Identifier (with a suitable per-NAS value, or we
>   construct this Attribute with a suitable value), and
> * Radiator was happy with the format of the NAS-Identifier.
>

You can easily strip out or modify the NAS-IP-Address in a PreClientHook (see 
the file "goodies/hooks.txt").

Radaitor will be happy with a string format.

regards

Hugh


-- 
Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.

More information about the radiator mailing list