From Alexander.Hartmaier at t-systems.com  Thu Dec  2 09:21:58 2021
From: Alexander.Hartmaier at t-systems.com (Alexander.Hartmaier at t-systems.com)
Date: Thu, 2 Dec 2021 09:21:58 +0000
Subject: [RADIATOR] radiator requires systemd?
In-Reply-To: <7e1eea28-1646-a70e-5cd4-d0f895041432@vianet.ca>
References: <d9b3d8a7-357f-8e58-5148-8ca9495d82dc@srce.hr>
 <24ea3cfb-e219-02a0-e1db-f812041aa5fe@open.com.au>
 <0a580f5e-e268-5654-0b1e-6764d518e476@vianet.ca>
 <55be92c3-7f50-7587-cfc4-40d573c0b04c@srce.hr>
 <fb9f78f8-cc64-435b-c549-60f899037ab2@vianet.ca>
 <5e83bfcc-ca38-ffd3-1fdf-489d1fef75c2@srce.hr>
 <80ac69ba-8ad0-d79e-333c-af08d5cf7beb@vianet.ca>
 <b26be1be-91bc-37f6-682a-8e136fdaade1@open.com.au>
 <7e1eea28-1646-a70e-5cd4-d0f895041432@vianet.ca>
Message-ID: <FR2P281MB0725856C8B862CD9B8BFEEFEA5699@FR2P281MB0725.DEUP281.PROD.OUTLOOK.COM>

FYI Debian without systemd is available as Devuan.

T-SYSTEMS AUSTRIA GESMBH
PU Cyber Security
Network Architecture
Operation Manager Authentication
Rennweg 97-99, A-1030 Vienna
+43 57057 4320 (phone)
+43 676 8642 4320 (mobile)
E-mail: alexander.hartmaier at t-systems.com
Internet: www.t-systems.at
Blog: blog.t-systems.at
Social Media: Facebook, Linkedin, Twitter

BIG CHANGES START SMALL ? CONSERVE RESOURCES BY NOT PRINTING EVERY E-MAIL.

****************************************************************************************************************
T-Systems Austria GesmbH, Rennweg 97-99, A-1030 Vienna
Commercial Court Vienna, FN 79340b
****************************************************************************************************************
Notice: This transmittal and/or attachments may be privileged or confidential. It is
intended solely for the addressee named above. If you received this transmittal in error,
please notify us immediately by reply and delete this message and all its attachments.
Thank you.
****************************************************************************************************************
________________________________
Von: radiator <radiator-bounces at lists.open.com.au> im Auftrag von Michael <ringo at vianet.ca>
Gesendet: Dienstag, 30. November 2021 22:47
An: Heikki Vatiainen <hvn at open.com.au>; radiator at lists.open.com.au <radiator at lists.open.com.au>
Betreff: Re: [RADIATOR] radiator requires systemd?

yep worked good.  I used source package and goodies/ stuff. Thanks.


On 2021-11-30 6:17 a.m., Heikki Vatiainen wrote:
> On 30.11.2021 0.46, Michael wrote:
>
>> yes Debian default was changed to systemd.  i change the default back
>> to sysvinit.  I'll try installing from source thanks.
>
> The source packages remain as they have always been. As Dubravko
> wrote, the deb packages target systems with systemd. The .tgz and .zip
> packages  are for other init methods, custom installations and other
> operating systems. There's also a generic init.d file for linux in
> goodies/linux-radiator.init
>
> How the deb packages set up the installation is described here:
>
> https://files.radiatorsoftware.com/radiator/ref/Linux-deb-Installation.html
>
>
> The similar setup is used with RPM packages too.
>
> Logrotate configuration is available in goodies as goodies/logrotate
> and systemd unit files are goodies/radiator*.service
>
> Thanks,
> Heikki
>

_______________________________________________
radiator mailing list
radiator at lists.open.com.au
https://lists.open.com.au/mailman/listinfo/radiator
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.open.com.au/pipermail/radiator/attachments/20211202/54fcbcc2/attachment.html>

From dlr at radiatorsoftware.com  Mon Dec 13 10:49:06 2021
From: dlr at radiatorsoftware.com (Daniela Loya Ramos)
Date: Mon, 13 Dec 2021 12:49:06 +0200
Subject: [RADIATOR] Radiator is not affected by log4j vulnerability
Message-ID: <CAJ9WLubxU-aoCLn_EghMH2hdrgcRYwLsc=XLuzkxbbyxsDgNUQ@mail.gmail.com>

 On the 10th of December 2021 a vulnerability (CVE-2021-44228
<http://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-44228>) in a popular
Java-based logging utility log4j was published. Since then, we have
received some customer queries about Radiator?s vulnerability.

Radiator does not utilise Java or log4j as a component of our software and
is therefore not vulnerable to the log4j vulnerability.

While closely following the situation, research, and responses around the
vulnerability, we have identified that RADIUS protocol and infrastructure
can be used to deliver the exploit to more vulnerable services such as
Java-based backend services, AAA information sources and centralised
logging systems. We have documented this delivery method principle into a
separate blog post found here:

https://blog.radiatorsoftware.com/2021/12/radius-servers-and-log4j-vulnerability.html

We will continue monitoring the issue closely and announce if issues
affecting Radiator or Radiator services are found.

-- 
Daniela Loya Ramos
Sales, Radiator Software Oywww.radiatorsoftware.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.open.com.au/pipermail/radiator/attachments/20211213/069afcda/attachment.html>

From publist.cr at gmail.com  Sat Dec 18 14:05:16 2021
From: publist.cr at gmail.com (C R)
Date: Sat, 18 Dec 2021 15:05:16 +0100
Subject: [RADIATOR] Authby REST: ACCEPT/REJECT
Message-ID: <CAD_Vsg0kw246e67DgaS1ftfFWEqBcyD6Tyus=bjc5XvCgZMOZA@mail.gmail.com>

Hi,

After reading the Radiator documentation and code, it's not completely
clear to me how Radiator determines if a request should is accepted or
rejected by a "AuthBy REST".

This is the relevant Radiator configuration:
RestAuthRequestDef mac, %{Calling-Station-Id}
RestAuthRequestDef ip, %{NAS-IP-Address}
RestAuthRequestDef endpoints, /v2/mac/iotdr:/v2/mac/iodtd-u, literal
RestAuthReplyDef reply,Reply,reply

This is the (stripped down) response of my REST service (used for MAB
and iPSK for now):
{
  "authorized": true,
  "reply": "Reply-Message=accepted by
rest,Tunnel-Type=VLAN,Tunnel-Medium-Type=802,Tunnel-Private-Group-ID=vlan1,cisco-avpair=psk-mode=ascii,cisco-avpair=psk=foo123"
}
or
{
  "authorized": false,
  "reply": "Reply-Message=rejected by rest"
}

I thought of using the "authorized" key in the response to make the
decision, but I only see a way to add this to the reply, not as the
result. Does Radiator expect an specific HTTP Statuscode (401, 404?)
to identify a REJECT? I can adapt the REST service to what's needed,
so pointers in that direction are also appreciated.

Thank you,

CR

From hvn at open.com.au  Mon Dec 20 14:59:14 2021
From: hvn at open.com.au (Heikki Vatiainen)
Date: Mon, 20 Dec 2021 16:59:14 +0200
Subject: [RADIATOR] Authby REST: ACCEPT/REJECT
In-Reply-To: <CAD_Vsg0kw246e67DgaS1ftfFWEqBcyD6Tyus=bjc5XvCgZMOZA@mail.gmail.com>
References: <CAD_Vsg0kw246e67DgaS1ftfFWEqBcyD6Tyus=bjc5XvCgZMOZA@mail.gmail.com>
Message-ID: <d90ee983-b4f5-bf02-bbd3-e13ab3724dfe@open.com.au>

On 18.12.2021 16.05, C R wrote:

> After reading the Radiator documentation and code, it's not completely
> clear to me how Radiator determines if a request should is accepted or
> rejected by a "AuthBy REST".

There are a couple of ways to do this. Because the AuthBy does not 
require a certain response, but can be configured to match what the 
server responds, a couple of examples are in order. I'll also see that 
the reference manual and configuration sample get updated.

> This is the relevant Radiator configuration:
> RestAuthRequestDef mac, %{Calling-Station-Id}
> RestAuthRequestDef ip, %{NAS-IP-Address}
> RestAuthRequestDef endpoints, /v2/mac/iotdr:/v2/mac/iodtd-u, literal
> RestAuthReplyDef reply,Reply,reply

Related to example below: If you have a number of attributes=value pairs 
in the "reply" key, do this:

RestAuthReplyDef reply,GENERIC,reply

> This is the (stripped down) response of my REST service (used for MAB
> and iPSK for now):
> {
>    "authorized": true,
>    "reply": "Reply-Message=accepted by
> rest,Tunnel-Type=VLAN,Tunnel-Medium-Type=802,Tunnel-Private-Group-ID=vlan1,cisco-avpair=psk-mode=ascii,cisco-avpair=psk=foo123"
> }
> or
> {
>    "authorized": false,
>    "reply": "Reply-Message=rejected by rest"
> }
> 
> I thought of using the "authorized" key in the response to make the
> decision, but I only see a way to add this to the reply, not as the
> result. Does Radiator expect an specific HTTP Statuscode (401, 404?)
> to identify a REJECT? I can adapt the REST service to what's needed,
> so pointers in that direction are also appreciated.

In this case there's no attributes in the request that can be configured 
to values returned with the JSON reply. Please find below some options:

1) You can use 401 or other non-OK status codes. These also require 
'NoReplyReject' flag parameter to ensure that a timed out or non-OK 
reply triggers a reject.


2) Within Handler (or Client) add to request the desired authorization 
result. X-Authorized is a private pseudo attribute which does not need 
to exist in the dictionary:

<Handler ...>
   # Use 1 or 0 with JSON booleans
   AddToReply X-Authorized = 1

   <AuthBy REST>
       # Current configuration

       RestAuthReplyDef authorized,X-Authorized,check

       # Rest of current configuration

Within REST response failure is:

     "authorized": false

And success is:

     "authorized": true
or
     <key not present at all>



3) Use Auth-Type reply attribute.

Within AuthBy REST configuration:

     RestAuthReplyDef authorized,GENERIC,check

Within REST response failure is:

     "authorized": "Auth-Type=Reject:Bad MAC"

The text following 'Reject:' becomes the reject reason in the 
authentication log.

And success is:

     "authorized": "Auth-Type=Accept"
or
     <key not present at all>



With 2) and 3) you need to be careful to include the "authorized" key 
when you want to reject the user. In other words, if the user should be 
accepted, you can leave out "authorized" completely. The follows the 
logic with SQL and other AuthBys where check and reply items are only 
evaluated if the server returns them.

The logic for this is that this allows, for example, returning a static 
IP or some other reply or check attribute the just some of the users. 
The configuration on Radiator side can list them but it's the server's 
decision if they are used or not.



Finally, there's also MapResponseHook that allows doing custom 
modifications to the OK responses. However, it's likely that this is not 
needed here, but it's available in case the responses need processing 
soon after they are received but before they are processed further.

https://files.radiatorsoftware.com/radiator/ref/MapResponseHook_common_httpclient.html 


-- 
Heikki Vatiainen
OSC, makers of Radiator
Visit radiatorsoftware.com for Radiator AAA server software

From publist.cr at gmail.com  Mon Dec 20 15:21:39 2021
From: publist.cr at gmail.com (C R)
Date: Mon, 20 Dec 2021 16:21:39 +0100
Subject: [RADIATOR] Authby REST: ACCEPT/REJECT
In-Reply-To: <d90ee983-b4f5-bf02-bbd3-e13ab3724dfe@open.com.au>
References: <CAD_Vsg0kw246e67DgaS1ftfFWEqBcyD6Tyus=bjc5XvCgZMOZA@mail.gmail.com>
 <d90ee983-b4f5-bf02-bbd3-e13ab3724dfe@open.com.au>
Message-ID: <CAD_Vsg3z7WcBXdAc+HLOXayTOGZBNhRpn9wE1vF+Nbzy+6B1GQ@mail.gmail.com>

Thank you, Heikki! I will try it out. It looks very flexible. Updating
the documentation will certainly facilitate the usage of this rather
new functionality (the authby being async is a huge win).

CR

Le lun. 20 d?c. 2021 ? 15:59, Heikki Vatiainen <hvn at open.com.au> a ?crit :
>
> On 18.12.2021 16.05, C R wrote:
>
> > After reading the Radiator documentation and code, it's not completely
> > clear to me how Radiator determines if a request should is accepted or
> > rejected by a "AuthBy REST".
>
> There are a couple of ways to do this. Because the AuthBy does not
> require a certain response, but can be configured to match what the
> server responds, a couple of examples are in order. I'll also see that
> the reference manual and configuration sample get updated.
>
> > This is the relevant Radiator configuration:
> > RestAuthRequestDef mac, %{Calling-Station-Id}
> > RestAuthRequestDef ip, %{NAS-IP-Address}
> > RestAuthRequestDef endpoints, /v2/mac/iotdr:/v2/mac/iodtd-u, literal
> > RestAuthReplyDef reply,Reply,reply
>
> Related to example below: If you have a number of attributes=value pairs
> in the "reply" key, do this:
>
> RestAuthReplyDef reply,GENERIC,reply
>
> > This is the (stripped down) response of my REST service (used for MAB
> > and iPSK for now):
> > {
> >    "authorized": true,
> >    "reply": "Reply-Message=accepted by
> > rest,Tunnel-Type=VLAN,Tunnel-Medium-Type=802,Tunnel-Private-Group-ID=vlan1,cisco-avpair=psk-mode=ascii,cisco-avpair=psk=foo123"
> > }
> > or
> > {
> >    "authorized": false,
> >    "reply": "Reply-Message=rejected by rest"
> > }
> >
> > I thought of using the "authorized" key in the response to make the
> > decision, but I only see a way to add this to the reply, not as the
> > result. Does Radiator expect an specific HTTP Statuscode (401, 404?)
> > to identify a REJECT? I can adapt the REST service to what's needed,
> > so pointers in that direction are also appreciated.
>
> In this case there's no attributes in the request that can be configured
> to values returned with the JSON reply. Please find below some options:
>
> 1) You can use 401 or other non-OK status codes. These also require
> 'NoReplyReject' flag parameter to ensure that a timed out or non-OK
> reply triggers a reject.
>
>
> 2) Within Handler (or Client) add to request the desired authorization
> result. X-Authorized is a private pseudo attribute which does not need
> to exist in the dictionary:
>
> <Handler ...>
>    # Use 1 or 0 with JSON booleans
>    AddToReply X-Authorized = 1
>
>    <AuthBy REST>
>        # Current configuration
>
>        RestAuthReplyDef authorized,X-Authorized,check
>
>        # Rest of current configuration
>
> Within REST response failure is:
>
>      "authorized": false
>
> And success is:
>
>      "authorized": true
> or
>      <key not present at all>
>
>
>
> 3) Use Auth-Type reply attribute.
>
> Within AuthBy REST configuration:
>
>      RestAuthReplyDef authorized,GENERIC,check
>
> Within REST response failure is:
>
>      "authorized": "Auth-Type=Reject:Bad MAC"
>
> The text following 'Reject:' becomes the reject reason in the
> authentication log.
>
> And success is:
>
>      "authorized": "Auth-Type=Accept"
> or
>      <key not present at all>
>
>
>
> With 2) and 3) you need to be careful to include the "authorized" key
> when you want to reject the user. In other words, if the user should be
> accepted, you can leave out "authorized" completely. The follows the
> logic with SQL and other AuthBys where check and reply items are only
> evaluated if the server returns them.
>
> The logic for this is that this allows, for example, returning a static
> IP or some other reply or check attribute the just some of the users.
> The configuration on Radiator side can list them but it's the server's
> decision if they are used or not.
>
>
>
> Finally, there's also MapResponseHook that allows doing custom
> modifications to the OK responses. However, it's likely that this is not
> needed here, but it's available in case the responses need processing
> soon after they are received but before they are processed further.
>
> https://files.radiatorsoftware.com/radiator/ref/MapResponseHook_common_httpclient.html
>
>
> --
> Heikki Vatiainen
> OSC, makers of Radiator
> Visit radiatorsoftware.com for Radiator AAA server software
> _______________________________________________
> radiator mailing list
> radiator at lists.open.com.au
> https://lists.open.com.au/mailman/listinfo/radiator