A question - User Auth etc

classic Classic list List threaded Threaded
5 messages Options
| Threaded
Open this post in threaded view
|

A question - User Auth etc

Richard J Palmer

HI


I have 'possibly' a slightly odd request - I am sure this can be
solved with FreeRadius but I'd really appreciate some pointers.

We are using FreeRadius to authenticate broadband connections reaching
us via L2TP over a number of providers. So far it works really well
and I've had a few questions and help from here in the past which I
really appriciate


Obviously we get some connections reach us with invalid username's or
wrong passwords.

The problem (and which we don't have any control over) is that in the
case of a wrong username - the customers router etc can simply try
constantly to log on. Obviously it never connects (as the current
design) but this obviously causes extra records in postauth and so on.

What I'd like to do is


1) user logs on and works (as now)
2) user with wrong login (wrong password / unknown username) - we
allow this to log on - send a specific reply back that pushes them
into a VRF which has a walled garden. it should also make the user ad
being in an IP Pool so it gets an IP from there)

3) BUT ideally logs this connection as 'failed' OR adds a flag so we
can see easily that the login was accepted by the above rule - so it's
not a 'working' session

The change to radreply - I know and have something we already use for
a disabled or suspended user,

I am however after some guidance on how I can allow the user to get an
'accept' packet back with the extra reply attribute - and the logging
information. There's some extra complexity which is this should only
be the case where I am authenticating on a username with a '@'
(realm). Any login being authenticated via Calling Station ID or with
no realm (just a username) should perform as now.


I have a few ideas but would really appreciate some pointers as the
best way to implement this one


Thanks in advance

Richard



-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: A question - User Auth etc

Alan DeKok-2
On Jun 24, 2020, at 9:27 AM, Richard J Palmer <[hidden email]> wrote:
> I have 'possibly' a slightly odd request - I am sure this can be solved with FreeRadius but I'd really appreciate some pointers.

  FreeRADIUS can do almost anything.  v4 will be able to do more. :)

> We are using FreeRadius to authenticate broadband connections reaching us via L2TP over a number of providers. So far it works really well and I've had a few questions and help from here in the past which I really appriciate

  Good to hear.

> Obviously we get some connections reach us with invalid username's or wrong passwords.
>
> The problem (and which we don't have any control over) is that in the case of a wrong username - the customers router etc can simply try constantly to log on. Obviously it never connects (as the current design) but this obviously causes extra records in postauth and so on.
>
> What I'd like to do is
>
> 1) user logs on and works (as now)
> 2) user with wrong login (wrong password / unknown username) - we allow this to log on - send a specific reply back that pushes them into a VRF which has a walled garden. it should also make the user ad being in an IP Pool so it gets an IP from there)

  Sure.  That's relatively common.  Let them on, but push them to a blocked VLAN, etc.

> 3) BUT ideally logs this connection as 'failed' OR adds a flag so we can see easily that the login was accepted by the above rule - so it's not a 'working' session

  You can use the "linelog" module to selectively log bad authentications.  i.e.

        if (!known user) {
                linelog_bad_user
        }

  Where you can create a "linelog" module:"

linelog linelog_bad_user {
        ... stuff to log ...
}

  And that logs what you want, where you want.

  How to check for an unknown user is up to you.  It depends on a number of things.  And no, you can't just do "if (!known_user)".  That's just an example.

> The change to radreply - I know and have something we already use for a disabled or suspended user,

  i.e. add a custom reply attribute which says "bad user".  This doesn't have to be an attribute which is sent to the NAS.  It can just be in raddb/dictionary

> I am however after some guidance on how I can allow the user to get an 'accept' packet back with the extra reply attribute - and the logging information. There's some extra complexity which is this should only be the case where I am authenticating on a username with a '@' (realm). Any login being authenticated via Calling Station ID or with no realm (just a username) should perform as now.

  You can write whatever complex rules you want in "unlang".  :)

        if (User-Name =~ /@/) {
                ... check database for known users...

                if (!known_user) {
                        linelog_bad_user
                        put them in a VRF / VLAN / whatever
                        accept
                }
        }
        }

  Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: A question - User Auth etc

Peter Lambrechtsen-4
I had a similar problem at my old role.

What I talked about doing would be to create a dummy virtual network on the
BNG that didn’t route anywhere.

Then have a single host even a Raspberry Pi would do with DNS and a web
server.
On the dns have the Microsoft / Apple / google redirect dns domains all
pointing to your Pi for a web server

Then on the web server have a singe page saying the config on your router
is wrong and you need to fix it.

I provided it worked fine and expected in the lab but we never deployed it
into production as no one wanted to fund buying a server for it and we
weren’t allowed to use unsupported hardware such as a Pi in the core.

But that is how you solve it.

On Thu, 25 Jun 2020 at 01:37, Alan DeKok <[hidden email]> wrote:

> On Jun 24, 2020, at 9:27 AM, Richard J Palmer <[hidden email]> wrote:
> > I have 'possibly' a slightly odd request - I am sure this can be solved
> with FreeRadius but I'd really appreciate some pointers.
>
>   FreeRADIUS can do almost anything.  v4 will be able to do more. :)
>
> > We are using FreeRadius to authenticate broadband connections reaching
> us via L2TP over a number of providers. So far it works really well and
> I've had a few questions and help from here in the past which I really
> appriciate
>
>   Good to hear.
>
> > Obviously we get some connections reach us with invalid username's or
> wrong passwords.
> >
> > The problem (and which we don't have any control over) is that in the
> case of a wrong username - the customers router etc can simply try
> constantly to log on. Obviously it never connects (as the current design)
> but this obviously causes extra records in postauth and so on.
> >
> > What I'd like to do is
> >
> > 1) user logs on and works (as now)
> > 2) user with wrong login (wrong password / unknown username) - we allow
> this to log on - send a specific reply back that pushes them into a VRF
> which has a walled garden. it should also make the user ad being in an IP
> Pool so it gets an IP from there)
>
>   Sure.  That's relatively common.  Let them on, but push them to a
> blocked VLAN, etc.
>
> > 3) BUT ideally logs this connection as 'failed' OR adds a flag so we can
> see easily that the login was accepted by the above rule - so it's not a
> 'working' session
>
>   You can use the "linelog" module to selectively log bad
> authentications.  i.e.
>
>         if (!known user) {
>                 linelog_bad_user
>         }
>
>   Where you can create a "linelog" module:"
>
> linelog linelog_bad_user {
>         ... stuff to log ...
> }
>
>   And that logs what you want, where you want.
>
>   How to check for an unknown user is up to you.  It depends on a number
> of things.  And no, you can't just do "if (!known_user)".  That's just an
> example.
>
> > The change to radreply - I know and have something we already use for a
> disabled or suspended user,
>
>   i.e. add a custom reply attribute which says "bad user".  This doesn't
> have to be an attribute which is sent to the NAS.  It can just be in
> raddb/dictionary
>
> > I am however after some guidance on how I can allow the user to get an
> 'accept' packet back with the extra reply attribute - and the logging
> information. There's some extra complexity which is this should only be the
> case where I am authenticating on a username with a '@' (realm). Any login
> being authenticated via Calling Station ID or with no realm (just a
> username) should perform as now.
>
>   You can write whatever complex rules you want in "unlang".  :)
>
>         if (User-Name =~ /@/) {
>                 ... check database for known users...
>
>                 if (!known_user) {
>                         linelog_bad_user
>                         put them in a VRF / VLAN / whatever
>                         accept
>                 }
>         }
>         }
>
>   Alan DeKok.
>
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: A question - User Auth etc

Richard J Palmer
In reply to this post by Richard J Palmer

Hi Alan

I really appreciate your help - thank you


I'm working though this  - I may have some extra questions from this -
a couple of initial questions if I may ?


Currently for uses that we suspend I have a group defined and assign
users to that group if they are disabled


id    GroupName    Attribute    op    Value
219    disabledusers    Filter-Id    =     T3


Which effectively puts the sessions into a known VRF - so that part is
in place. The VRF works and traffic blackholed. This works if they
enter the right username and password - the NAS and network does the
rest ...


In this case I ideally want:

i) Users we know BUT the user has the wrong password - AND there's an
'@' in the username
or
ii) Unknown users AND there's an '@' in the username


The server should allow the users but.. have the same effect as being
in the disabledusers group or add that attribute and set the user to
get an IP from sqlippool (I already have that module setup for other
users - it's just setting these users to be assigned to a specific
(single) pool

I mentioned above that this should only be the case if the username
has an '@' the alternative is that this only happens when the request
comes from certain NAS addresses - this is because I also have some
wireless hotspots etc using the radius server and I don't want this
behaviour to affect them.

We also have a couple of realms we proxy for another home server -
that's sort of in my control... Now I could copy this onto there
server - but wondered if there's any way to implement this so it
covers both uers authenticated locally - OR after a proxy has taken
place

I probably wasn't clear on logging - which was my fault - we have a
portal that I created that feeds from the SQL database - radpostauth
and radacct. In the ideal world I'd like there to be something I can
add to radpostauith query that flags this user has connected - BUT
with the 'disabled' flag - I assume I could set a variable somewhere
in the auth part and access this in the post-auth section to add to
the SQL query ?

My aim is to test this on a clone of one of the current servers but
not *yet* used by any of the NAS's so I can send requests to it - and
test until I have this correct


IF I have got the wrong end of the stick .... please feel free to
point me to the correct end ....

Thanks again

Richard


> --- Original message ---
> Subject: Re: A question - User Auth etc
> From: Alan DeKok <[hidden email]>
> To: FreeRadius users mailing list
> <[hidden email]>
> Date: Wednesday, 24/06/2020 2:37 PM
>
> On Jun 24, 2020, at 9:27 AM, Richard J Palmer <[hidden email]>
> wrote:
>>
>> I have 'possibly' a slightly odd request - I am sure this can be
>> solved with FreeRadius but I'd really appreciate some pointers.
>
>    FreeRADIUS can do almost anything.  v4 will be able to do more. :)
>
>>
>> We are using FreeRadius to authenticate broadband connections reaching
>> us via L2TP over a number of providers. So far it works really well
>> and I've had a few questions and help from here in the past which I
>> really appriciate
>
>    Good to hear.
>
>>
>> Obviously we get some connections reach us with invalid username's or
>> wrong passwords.
>>
>> The problem (and which we don't have any control over) is that in the
>> case of a wrong username - the customers router etc can simply try
>> constantly to log on. Obviously it never connects (as the current
>> design) but this obviously causes extra records in postauth and so on.
>>
>> What I'd like to do is
>>
>> 1) user logs on and works (as now)
>> 2) user with wrong login (wrong password / unknown username) - we
>> allow this to log on - send a specific reply back that pushes them
>> into a VRF which has a walled garden. it should also make the user ad
>> being in an IP Pool so it gets an IP from there)
>
>    Sure.  That's relatively common.  Let them on, but push them to a
> blocked VLAN, etc.
>
>>
>> 3) BUT ideally logs this connection as 'failed' OR adds a flag so we
>> can see easily that the login was accepted by the above rule - so it's
>> not a 'working' session
>
>    You can use the "linelog" module to selectively log bad
> authentications.  i.e.
>
> if (!known user) {
> linelog_bad_user
> }
>
>    Where you can create a "linelog" module:"
>
> linelog linelog_bad_user {
> ... stuff to log ...
> }
>
>    And that logs what you want, where you want.
>
>    How to check for an unknown user is up to you.  It depends on a
> number of things.  And no, you can't just do "if (!known_user)".  
> That's just an example.
>
>>
>> The change to radreply - I know and have something we already use for
>> a disabled or suspended user,
>
>    i.e. add a custom reply attribute which says "bad user".  This
> doesn't have to be an attribute which is sent to the NAS.  It can just
> be in raddb/dictionary
>
>>
>> I am however after some guidance on how I can allow the user to get an
>> 'accept' packet back with the extra reply attribute - and the logging
>> information. There's some extra complexity which is this should only
>> be the case where I am authenticating on a username with a '@'
>> (realm). Any login being authenticated via Calling Station ID or with
>> no realm (just a username) should perform as now.
>
>    You can write whatever complex rules you want in "unlang".  :)
>
> if (User-Name =~ /@/) {
> ... check database for known users...
>
> if (!known_user) {
> linelog_bad_user
> put them in a VRF / VLAN / whatever
> accept
> }
> }
> }
>
>    Alan DeKok.
>
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: A question - User Auth etc

Alan DeKok-2
On Jun 24, 2020, at 3:38 PM, Richard J Palmer <[hidden email]> wrote:
> I really appreciate your help - thank you

  You're welcome.

> I'm working though this  - I may have some extra questions from this - a couple of initial questions if I may ?

  Questions are always good.

> Currently for uses that we suspend I have a group defined and assign users to that group if they are disabled
>
>
> id    GroupName    Attribute    op    Value
> 219    disabledusers    Filter-Id    =     T3
>
> Which effectively puts the sessions into a known VRF - so that part is in place. The VRF works and traffic blackholed. This works if they enter the right username and password - the NAS and network does the rest ...

  OK...

> In this case I ideally want:
>
> i) Users we know BUT the user has the wrong password - AND there's an '@' in the username
> or
> ii) Unknown users AND there's an '@' in the username

  That depends on exactly what "unknown user" or "wrong password" means.  You could do something like:

authorize {
        ...
        sql
        if (notfound && (User-Name =~ /@/)) {
                update reply {
                        Filter-Id := T3
                }
                accept
        }
        ...
}

  Which does pretty much what you expect.  Then for authentication:

Auth-Type pap {
        pap
        if (reject && (User-Name =~ /@/)) {
                update reply {
                        Filter-Id := T3
                }
                accept
        }
}

  Which also does pretty much what you expect.  FreeRADIUS isn't that hard in the end.  But knowing what to do depends on so many things that we just can't document every situation.  So we document how the server works, and how to put solutions together.

> The server should allow the users but.. have the same effect as being in the disabledusers group or add that attribute and set the user to get an IP from sqlippool (I already have that module setup for other users - it's just setting these users to be assigned to a specific (single) pool

  Sure.  Since IP pools are assigned in the post-auth section, you can do this easily.  Just check for the disabled users.  At this point, it doesn't matter why they were disabled:

post-auth {
        ...
        if (reply:Filter-Id == "T3") {
                sqlippool_disabled
        }
}

> I mentioned above that this should only be the case if the username has an '@' the alternative is that this only happens when the request comes from certain NAS addresses - this is because I also have some wireless hotspots etc using the radius server and I don't want this behaviour to affect them.

  Sure.

> We also have a couple of realms we proxy for another home server - that's sort of in my control... Now I could copy this onto there server - but wondered if there's any way to implement this so it covers both uers authenticated locally - OR after a proxy has taken place

  v3 can't turn a proxied reject into an accept, so that's a little more difficult.

> I probably wasn't clear on logging - which was my fault - we have a portal that I created that feeds from the SQL database - radpostauth and radacct. In the ideal world I'd like there to be something I can add to radpostauith query that flags this user has connected - BUT with the 'disabled' flag - I assume I could set a variable somewhere in the auth part and access this in the post-auth section to add to the SQL query ?

  Sure.  Update the radpostauth query to include another attribute, say by editing raddb/dictionary, and defining one:

ATTRIBUTE User-Disabled 3000 string

  And edit the radpostauth query to include that:

        ... %{reply:User-Disabled} ...

  Then in post-auth again:

post-auth {
        ...
        if (reply:Filter-Id == "T3") {
                sqlippool_disabled
                update request {
                        User-Disabled := "disabled"
                }
        }
        ...
        sql
        ...
}

  And the users status will be logged.

> My aim is to test this on a clone of one of the current servers but not *yet* used by any of the NAS's so I can send requests to it - and test until I have this correct

  Sure.  As with everything, test in small pieces.  It will work.

> IF I have got the wrong end of the stick .... please feel free to point me to the correct end ....

  Asking questions and explaining what you want is exactly the right thing to do.

  Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html