On Jun 24, 2020, at 9:27 AM, Richard J Palmer <richard@merula.net> 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.