Re: Using variables in unlang conditions
I put it in the authorize section of the default virtual server, just before if conditions. So this file is not considered a "configuration file" :) I just put definitions to the end of the radiusd.conf file, try to start in debug mode with freeradius -X, getting the same error: ((&Packet-Src-IP-Address < ${etu_aruba_wlc_rektorluk}) ^ Failed to parse value for attribute bottom of radiusd.conf #### VARIABLES ############################# etu_aruba_wlc_rektorluk = 10.10.243.0/24 etu_aruba_wlc_ogrenci_merkezi = 10.10.244.0/24 I read all the documentation about using variables already. But it seems I miss something. Rahman Duran Message: 2
Date: Thu, 24 Feb 2022 09:51:13 -0500 From: Alan DeKok <aland@deployingradius.com> To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: Using variables in unlang conditions Message-ID: <701442B2-1FCC-4232-BCF2-85A83572176E@deployingradius.com> Content-Type: text/plain; charset=us-ascii
On Feb 24, 2022, at 5:50 AM, Rahman Duran <rahman.duran@erzurum.edu.tr> wrote:
I am trying to do some filtering/policing in the authorize section of the default virtual server. I need to check source ip matches our Wireless Controllers and SSID and username format etc then decide what to do with the request. How can I user some kind of alias/variable for our IP address block so I should not need to write and update IP addresses multiple places?
You can edit raddb/dictionary to define local attributes. Or, if the values don't change too often (i.e. rarely), you can out them into the configuration files themselves.
Here sample of what I try to achieve:
////////////////////// etu_aruba_wlc_001 = 10.10.243.0/24 etu_aruba_wlc_002 = 10.10.244.0/24 etu_aruba_wlc_002 = 10.10.245.0/24
You can just put that at the bottom of radiusd.conf.
Where did you put the above text? Into a configuration file? Which one? Or some other file? If so, how is the server supposed to find it?
### 001: Test Wifi Service ### *if ((&Packet-Src-IP-Address < ${etu_aruba_wlc_001}) \*
Then that will work.
There are many examples of this.
Well using variables (${...}) in conditions not working, Freeradius daemon not starting with parse error:
/etc/freeradius/3.0/sites-enabled/default[40]: ((&Packet-Src-IP-Address < *${etu_aruba_wlc_001}) * && (&NAS-Port-Type == "Wireless-80... /etc/freeradius/3.0/sites-enabled/default[40]: ^ Failed to parse value for attribute
Because you didn't define "etu_aruba_wlc_001" anywhere.
There are many examples of using variables defined in configuration files. It works. You just have to define the variables in the configuration files...
Alan DeKok.
------------------------------
Message: 3 Date: Thu, 24 Feb 2022 10:08:39 -0500 From: Alan DeKok <aland@deployingradius.com> To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: Advice on RADIUS security and MD5 encryption? Message-ID: <0B7CD3D0-8BD3-4773-BFDD-7700C1A01B7F@deployingradius.com> Content-Type: text/plain; charset=us-ascii
On Feb 24, 2022, at 4:39 AM, Ole Holm Nielsen via Freeradius-Users < freeradius-users@lists.freeradius.org> wrote:
We're using the pam_radius module for SSH login authentication on a
CentOS 7 server. Our university's RADIUS server is a Microsoft Windows server. This seems to work well.
Some of my colleagues are wary about using RADIUS for authentication
because the network traffic is encrypted with the obsolete MD5 algorithm.
The real question is: "Has anyone broken the encryption method used by RADIUS?"
The answer is "no".
I would like to understand if this is a relevant objection or not for the present case.
It's not relevant.
The Wikipedia article https://en.wikipedia.org/wiki/RADIUS does raise some security concerns.
Anyone can edit Wikipedia. It doesn't really mean anything.
Question: When the user's password hash is transmitted across the network, how secure is the password from decryption by eavesdroppers?
If you have a shared secret of "hello", it's easy to crack.
If the shared secret of "284nv82fskljhfw9yf2hfjb3fjgf8gb83bg", then no one will be able to crack it.
Are there any good articles on RADIUS security?
Not really.
In short, it's fine.
Alan DeKok.
------------------------------
Message: 4 Date: Fri, 25 Feb 2022 09:06:36 +0100 From: Ole Holm Nielsen <Ole.H.Nielsen@fysik.dtu.dk> To: <freeradius-users@lists.freeradius.org> Subject: Re: Advice on RADIUS security and MD5 encryption? Message-ID: <11d65956-d0b7-8ccd-791b-e605539ce21b@fysik.dtu.dk> Content-Type: text/plain; charset="UTF-8"; format=flowed
Hi Alan,
Thanks very much for your definitive answers, it's much appreciated! Such clear messages are almost impossible to find elsewhere. So we should be good to go with RADIUS, provided that we use hard-to-crack shared secrets.
Best regards, Ole
-- Ole Holm Nielsen PhD, Senior HPC Officer Department of Physics, Technical University of Denmark
------------------------------
Subject: Digest Footer
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
------------------------------
End of Freeradius-Users Digest, Vol 202, Issue 34 *************************************************
On Feb 25, 2022, at 8:28 AM, Rahman Duran <rahman.duran@erzurum.edu.tr> wrote:
I put it in the authorize section of the default virtual server
Well, you can't just randomly add things to the "authorize" section. It won't work. The configuration file syntax is documented.
, just before if conditions. So this file is not considered a "configuration file" :) I just put definitions to the end of the radiusd.conf file, try to start in debug mode with freeradius -X, getting the same error:
((&Packet-Src-IP-Address < ${etu_aruba_wlc_rektorluk}) ^ Failed to parse value for attribute
bottom of radiusd.conf #### VARIABLES ############################# etu_aruba_wlc_rektorluk = 10.10.243.0/24 etu_aruba_wlc_ogrenci_merkezi = 10.10.244.0/24
OK, after some looking at it, you should put those in "radiusd.conf", just before the "modules {" line. It should then work. Alan DeKok.
Ok, I did what you suggested and defined variables just before "modules {" but it still does not work, same error. //////////// ###################################################################### # # SNMP notifications. Uncomment the following line to enable # snmptraps. Note that you MUST also configure the full path # to the "snmptrap" command in the "trigger.conf" file. # #$INCLUDE trigger.conf #### VARIABLES ############################# etu_aruba_wlc_rektorluk = 10.10.243.0/24 etu_aruba_wlc_ogrenci_merkezi = 10.10.244.0/24 etu_ssid_eduroam = "eduroam" # MODULE CONFIGURATION # # The names and configuration of each module is located in this section. # # After the modules are defined here, they may be referred to by name, # in other sections of this configuration file. # modules { ///////////////////////// /etc/freeradius/3.0/sites-enabled/default[40]: ((&Packet-Src-IP-Address < ${etu_aruba_wlc_rektorluk}) && (&NAS-Port-Type == "Wireless-80... /etc/freeradius/3.0/sites-enabled/default[40]: ^ Failed to parse value for attribute Rahman Duran Message: 2 Date: Fri, 25 Feb 2022 09:55:25 -0500 From: Alan DeKok <aland@deployingradius.com> To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: Using variables in unlang conditions Message-ID: <C473A2CB-1BB9-4EF8-90DA-36987FD19B90@deployingradius.com> Content-Type: text/plain; charset=us-ascii On Feb 25, 2022, at 8:28 AM, Rahman Duran <rahman.duran@erzurum.edu.tr> wrote:
I put it in the authorize section of the default virtual server
Well, you can't just randomly add things to the "authorize" section. It won't work. The configuration file syntax is documented.
, just before if conditions. So this file is not considered a "configuration file" :) I just put definitions to the end of the radiusd.conf file, try to start in debug mode with freeradius -X, getting the same error:
((&Packet-Src-IP-Address < ${etu_aruba_wlc_rektorluk}) ^ Failed to parse value for attribute
bottom of radiusd.conf #### VARIABLES ############################# etu_aruba_wlc_rektorluk = 10.10.243.0/24 etu_aruba_wlc_ogrenci_merkezi = 10.10.244.0/24
OK, after some looking at it, you should put those in "radiusd.conf", just before the "modules {" line. It should then work. Alan DeKok.
On Feb 28, 2022, at 12:49 AM, Rahman Duran <rahman.duran@erzurum.edu.tr> wrote:
Ok, I did what you suggested and defined variables just before "modules {" but it still does not work, same error.
I'm not sure what to say. It works for me. Alan DeKok.
participants (2)
-
Alan DeKok -
Rahman Duran