(RADIATOR) Global RADMIN accounting for abuse tracking

[Hugh Irvine]

Hello Miguel -

On Thursday 26 July 2001 14:33, Miguel A.L. Paraz wrote:
> On Sat, Jul 21, 2001 at 11:14:26AM +1000, Hugh Irvine wrote:
> > On Friday 20 July 2001 19:53, Miguel A.L. Paraz wrote:
> > > Hi,
> > > I tried AcctLogFilename and it works inside <Realm>.
> > > It does nothing when placed outside.
> > > Is this the correct behavior?
> > > I want one file to log to regardless of realm.
> >
> > This is the correct behaviour. You have to specify the AcctLogFilename in
> > each Realm or Handler (you can use the same file however).
>
> Thanks, here's more detail on what I want.
>
> I find that a plain text AcctLogFilename generates too much detail.  I only
> need the username, Framed-IP-Address, Calling-Station-ID and time stamp -
> enough to identify security/abuse violations.  For speed of lookups, I
> would like it to be in a SQL database.  I need an interface where
> complaints can be looked up by our security team, and will also take
> SpamCop mail as input.
>
> My RADMIN and others are already using MySQL.  From my reading archives I
> find that <AuthBy SQL> will do the logging.  But, don't want to auth since
> my incoming RADIUS requests are either local via RADMIN, or proxied.  What
> is the invocation to do SQL accounting only?
>
> Can I use <AuthBy RADMIN>, and the AccountingTable, even for proxied
> requests? If so, I think the way to do it for proxies is:
>
> <AuthBy RADIUS>
>   Host ...
> </AuthBy>
> <AuthBy RADMIN>
>   AccountingTable RADUSAGEPROXIED
>   AcctColumnDef ...
> </AuthBy>
>
> How do I make the <AuthBy RADMIN> be called only for accounting?
>
> Thanks, and I think this should be useful for everyone who proxies to
> servers not under their control but have to be responsible to the community
> for spam complaints and security incidents.
>

You are correct - many of our customers do exactly what you describe.

Here is an example of what to do:

# define AuthBy clauses

<AuthBy RADMIN>
	Identifier CheckRADMIN
	DBSource .....
	DBUsername ....
	DBAuth .....
	.......
</AuthBy>

# define AuthBy SQL for accounting only (note empty AuthSelect)
# use the same DBSource, etc. as AuthBy RADMIN

<AuthBy SQL>
	Identifier SQLAccounting
	DBSource .....
	DBUsername ....
	DBAuth .....
	AuthSelect
	AccountingTable RADUSAGEPROXIED
	AcctColumnDef .....
	.....
</AuthBy>

<AuthBy RADIUS>
	Identifier ProxyToDownstream
	.....
</AuthBy>

# define Realms

<Realm your.local.realm>
	AuthBy CheckRADMIN
	.....
</Realm>

<Realm some.other.realm>
	AuthByPolicy ContinueAlways
	AuthBy SQLAccounting
	AuthBy ProxyToDownstream
	....
</Realm>


Of course, you can do a similar thing with Handlers if you prefer.

hth

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.