Thanks, i haven't used preacct before, in what module is this, can you send detailed solution? Sorry, i am only a beginner in writing customized things for freeradius. About the NAS: in our case, the client is in posession of the shared secret, but the NAS is set incorrectly. Also, we are using a global user database for hundreds of NAS clients, and we would like to avoid a situation when a NAS client is sending accounting information for an existing user as a hacker attempt, causing invalid usage data and causing users account to expire. In case the existing user is configured as a local user AND the hacker knows that a username exists in our radcheck table (or just use a username list for guessing), this can be easily done. On Feb 14, 2012, at 11:49 AM, Phil Mayers wrote: On 14/02/12 10:27, justin76@mac.com wrote:

Hi all,

we are using freeradius with mysql.

Accounting works fine, but we discovered that the server is doing accounting for users which don't exist at all in our system. They are probably local users but accounting information is sent to our servers.

How do we allow accounting for only our users? The server should check whether the user is in the radcheck table as we only keep users that which have a valid account.

How can this be achieved?

Well, possibly something like: preacct { update control { Tmp-Integer-0 := %{sql:select 1 from radcheck where username='%{User-Name}'} } } accounting { if (control:Tmp-Integer-0 == 1) { detail sql # whatever } }

Furthermore, it would be good if we could verify the NAS value so the server should only do accounting when the NAS is allowed.

I don't know what this means. If the NAS is "not allowed" then surely it's not a valid client, so it doesn't have a shared secret? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

NAS are set up by partner companies all around the world. We can tell them to fix the NAS but maybe it can take weeks and we don't want to allow misconfigured NAS in the accounting at all. On Feb 14, 2012, at 12:08 PM, Phil Mayers wrote: On 14/02/12 10:59, justin76@mac.com wrote:

Thanks, i haven't used preacct before, in what module is this, can you send detailed solution? Sorry, i am only a beginner in writing customized things for freeradius.

This is a section in the standard virtual server config. If you look in sites-enabled/default, you'll see: authorize { ... } authenticate { ... } post-auth { ... } preacct { ... } accounting { ... } ...and others. The sections are lists of modules, or "unlang" config processing statements. See "man unlang".

About the NAS: in our case, the client is in posession of the shared secret, but the NAS is set incorrectly. Also, we are using a global user database for hundreds of NAS clients, and we would like to avoid a situation when a NAS client is sending accounting information for an existing user as a hacker attempt, causing invalid usage data and causing users account to expire. In case the existing user is configured as a local user AND the hacker knows that a username exists in our radcheck table (or just use a username list for guessing), this can be easily done.

I'm sorry, I don't understand any of that. If the NAS is "set incorrectly" why not fix the NAS? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

On Tue, Feb 14, 2012 at 6:31 PM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:

On 14/02/12 11:18, justin76@mac.com wrote:

...

NAS are set up by partner companies all around the world. We can tell them to fix the NAS but maybe it can take weeks and we don't want to allow misconfigured NAS in the accounting at all.

Freeradius can perform arbitrary processing, to ignore or accept packets. You need to:

 1. Write down a policy showing which requests you want to permit, based on which attributes

... and that is often the hardest part. Really. IMHO it's easier to just do something like this: - give out unique shared secret for each NAS - log NAS IP address (e.g. Packet-Src-IP-Address) on radacct (either by overwriting an existing column, or add a new one) - handle user complains if and when they come. If a user complains that their quota is used incorrectly, and you can trace that the NAS is misbehaving (or hacked, although unlikely) by looking at records on radacct, then simply ban the NAS. It's the least-effort method to get what you want. -- Fajar

Any suggestions? Thank you! On Feb 14, 2012, at 3:47 PM, justin76@mac.com wrote: Can this be achived for only accounting start requests? So the check would be only when a new accounting session starts, ongoing sessions shouldn't be checked. preacct { update control { Tmp-Integer-0 := %{sql:select 1 from radcheck where username='%{User-Name}'} } } accounting { if (control:Tmp-Integer-0 == 1) { detail sql # whatever } } On Feb 14, 2012, at 1:08 PM, Fajar A. Nugraha wrote: On Tue, Feb 14, 2012 at 6:31 PM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:

On 14/02/12 11:18, justin76@mac.com wrote:

...

NAS are set up by partner companies all around the world. We can tell them to fix the NAS but maybe it can take weeks and we don't want to allow misconfigured NAS in the accounting at all.

Freeradius can perform arbitrary processing, to ignore or accept packets. You need to:

1. Write down a policy showing which requests you want to permit, based on which attributes

... and that is often the hardest part. Really. IMHO it's easier to just do something like this: - give out unique shared secret for each NAS - log NAS IP address (e.g. Packet-Src-IP-Address) on radacct (either by overwriting an existing column, or add a new one) - handle user complains if and when they come. If a user complains that their quota is used incorrectly, and you can trace that the NAS is misbehaving (or hacked, although unlikely) by looking at records on radacct, then simply ban the NAS. It's the least-effort method to get what you want. -- Fajar - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html