Re: [RADIATOR] Is the Radiator NFV customizable?
Thanks for the detailed response, Tuure :) Any chance OSC will be creating a video for NFV installation on OpenStack/ESXi in the near future? From: radiator-boun...@open.com.au [radiator-boun...@open.com.au] on behalf of Tuure Vartiainen [varti...@open.com.au] Sent: Tuesday, June 28, 2016 10:43 AM To: radiator@open.com.au Subject: Re: [RADIATOR] Is the Radiator NFV customizable? Hello, > On 27 Jun 2016, at 10:34, Nadav Hod wrote: > > I have the impression that the VNF is much like an appliance, where the only > interface the user has with the VNF is the configuration file. I was hoping > the amazing Radiator team could clear up the following issues: > yes, VNF is a kind of an software appliance which is meant to be configured through different interfaces. > 1) Is the operating system (CentOS if I recall correctly) fully writeable so > that other applications can interface with Radiator (such as logrotate, rsync > etc.)? > Yes. Radiator VNF is not restricted to using CentOS, but we are using CentOS as a base Linux distribution for Radiator VNF. Adaptation for Ubuntu/Debian will require some work but it is feasible. > 2) Can patches (including security) be applied to the underlying OS? Does > this void warranty? > Yes, patches can be applied and do not void warranty/support. > 3) Are there any common use cases when it's best not to use Radiator as NFV? > Radiator VNF is meant for AAA cases which require scaling for performance, either automatically or manually. > 4) Does the VNF include all the common perl modules necessary for Radiator? > Can more be installed and updated? > Yes. Modules can be updated and more modules can be installed. > 5) What are the specs for the VNF? Is there any resource allocation necessary > from the hypervisor's side? > Radiator VNF does not have any strict requirements. Currently we are running Radiator VNF on OpenStack, but it can also be adapted to run on a bare metal hardware or in VMware vCloud. Default minimum HA setup of Radiator VNF consists of 11 virtual machines: - 2 Radiator load balancers (RADIUS or Diameter) - 2 Radiator AAA workers (number of workers scales according to load) - 3 Database/message broker nodes - 2 External database connector nodes (LDAP, SQL, RADIUS or Diameter) - 2 Management nodes With OpenStack, creating Radiator VNF stack is automated through its Heat orchestration. BR -- Tuure Vartiainen Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Questions regarding new release and current roadmap
Hi Heikki, Thanks for the update. 1) Any news on uploading the roadmap? 2) Thanks for taking an interest. The features I'm interested in are the following: 2.1) OCSP + OCSP stapling. I've heard this is on the roadmap for the near future. 2.2) TLS resumption support by Session Tickets (RFC 5077). Another option is to just wait for TLS 1.3 support although it would take several years until most clients in an organization would support TLS 1.3, if at all. 2.3) Multithreading support for Windows Server (at the moment I'm using a master service and splitting the handling of different authentication methods to different Windows services). 2.4) A mature, flexible and robust web GUI, preferably one that can manage distributed Radiator servers. The web GUI I'm using for 4.15 isn't much help for maintaining configuration and reading log files, let alone multiple configuration files. Therefore I need to remote desktop into the Radiator server in order to manage anything. This is compounded further if you're using many Radiator servers. 2.5) A method of synchronizing configuration files (apart from certain variables) across multiple servers. If all Radiator servers have very similar configuration and are distributed for load balancing and redundancy, it's a shame that the configuration needs to be managed and configured separately for each server. There are differences between servers, but the bulk of the configuration can remain the same. There is 3rd party software such as rsync for synchronizing files, but the variables for each Radiator configuration file have to be within the file itself (as far as I can tell). If the variables could be configured outside of each configuration file, such as a header file, this would allow for synchronizing the configuration files effectively across all servers while still taking into account the differences between each server. 2.6) A more secure method for storing credentials, at the moment they can only be stored locally on the Radiator servers. Perhaps integration with popular 3rd party solutions (such as CyberArk) if their API permits it. That's my wishlist :) From: radiator-boun...@open.com.au [radiator-boun...@open.com.au] on behalf of Heikki Vatiainen [h...@open.com.au] Sent: Friday, June 10, 2016 11:26 AM To: radiator@open.com.au Subject: Re: [RADIATOR] Questions regarding new release and current roadmap On 7.6.2016 19.56, Nadav Hod wrote: > 1) It's been awhile since 4.16 was released, I was wondering if there is > a candidate release date for the next version. If you have valid download access for the full or evaluation version, you can download the current patch set to see what's currently intended for the next release. There's no candidate release date yet. We are currently using the patched version heavily ourselves and we are aiming for the release during this summer. > 2_ For those of us who won't be in London for 5G World, is there any > chance of disclosing the roadmap for Radiator soon after? Is there something you are particulary interested in? I'll ask the others here about publishing more information about the upcoming features. There's nothing secret about the roadmap :) Thanks, Heikki -- Heikki Vatiainen Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Questions regarding new release and current roadmap
Hi, > 2.5) A method of synchronizing configuration files (apart from certain > variables) across multiple servers. If all Radiator servers have very similar > configuration and are distributed for load balancing and redundancy, it's a > shame that the configuration needs to be managed and configured separately > for each server. There are differences between servers, but the bulk of the > configuration can remain the same. > > There is 3rd party software such as rsync for synchronizing files, but the > variables for each Radiator configuration file have to be within the file > itself (as far as I can tell). If the variables could be configured outside > of each configuration file, such as a header file, this would allow for > synchronizing the configuration files effectively across all servers while > still taking into account the differences between each server. eh??? we do multi server configuration syncing already - you know that you can just include different files for each server...using...a headerfile as you say - our radius.cfg contains all local requirements and then pulls in the local config file for the server. (in our case we use a database to hold all details, generate the required new configs for each server then push out to each server) > 2.6) A more secure method for storing credentials, at the moment they can > only be stored locally on the Radiator servers. Perhaps integration with > popular 3rd party solutions (such as CyberArk) if their API permits it. read discussions on the list - if stored elsewhere there are still security issues. what are you hoping to fix/resolve? you can store configs on a remote DB if there are basic local issues (though anyone with admin access could still read the DB credentials and then connect to the DB to get hold of config). alan ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] ServerTACACSPLUS logging improvements
On 28.6.2016 11.24, Hartmaier Alexander wrote: > Tue Jun 28 08:18:50 2016: DEBUG: ServerTACACSPLUS: New connection from > 1.2.3.4:11422 > Tue Jun 28 08:18:50 2016: ERR: Could not get peer name on > TacacsplusConnection socket: Transport endpoint is not connected > Tue Jun 28 08:18:50 2016: DEBUG: TacacsplusConnection disconnected from : > > As you can see is the last message lacking the source infos although > I've applied the latest patchset. > Any idea why? The 'Could not get peer name' log message was not changed at those patches yet. What was changed was the addition of the 'New connection' message. To get rid of need for Trace 4, the current patches now include slightly changed connection handling and updated logging. The peer IP and port are now saved from accept() and while getpeername() is still called, its function is only to check for connections that got immediately closed after they were opened. This check is depends on the timing, but it should catch those disconnects that were causing the 'Could not get peer name' log message. Otherwise the connections get closed by the normal processing. Or in brief: the log message is now more informative but the processing is otherwise the same. Note: the peer name log message is now logged as a WARNING instead of ERR. > But the 'New connection' message should be enough to find the bad boys > which seem to be two Cisco IOS routers. Hmm, that's interesting. Any reason why they do this? Thanks, Heikki -- Heikki Vatiainen Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Questions regarding new release and current roadmap
On 29.6.2016 12.16, Nadav Hod wrote: > 1) Any news on uploading the roadmap? No new news. > 2.1) OCSP + OCSP stapling. I've heard this is on the roadmap for the > near future. Yes, there was recently discussion about this related to RadSec support. What would your use case be? If it's for TSL based EAP methods, do you know what the stepling support is on the client side? > 2.2) TLS resumption support by Session Tickets (RFC 5077). Another > option is to just wait for TLS 1.3 support although it would take > several years until most clients in an organization would support > TLS 1.3, if at all. Noted. For this feature too, would it be for EAP methods too or do you have something else in mind? > 2.3) Multithreading support for Windows Server (at the moment I'm > using a master service and splitting the handling of different > authentication methods to different Windows services). I don't think multithreading support is the way forward. What we are interested in doing is making it easier to run multiple instances that work together. > 2.4) A mature, flexible and robust web GUI, preferably one that can > manage distributed Radiator servers. The web GUI I'm using for 4.15 > isn't much help for maintaining configuration and reading log files, > let alone multiple configuration files. Therefore I need to remote > desktop into the Radiator server in order to manage anything. This > is compounded further if you're using many Radiator servers. Centralised logging, and logging enhancements in general, is also something we're working on. There's also work done for interfaces that can enable building a web GUI, so the GUI does not have to be within Radiator itself. What comes to credential security, the credentials can be encrypted/obfuscated so that they are not in clear text format in the configuration file. There's initial support for that in the patches. However, we have not looked at separate products for credential storage. Thanks, Heikki -- Heikki Vatiainen Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Questions regarding new release and current roadmap
Hi, 2.1) I haven't dealt with OCSP in the context of RadSec, but rather as a scalable and faster alternative to CTL files in general when dealing with any certificate. Many of our applications already support OCSP, and it would be preferable to use OCSP with stapling than to perform the query from the server each time a certificate needs to be validated. 2.2) EAP methods and LDAPS bindings. 2.3) I agree that setting up multiple processes isn't a bottleneck, but it is a bit of a hassle. It's a hassle you can automate, though. Thanks for the update :) From: radiator-boun...@open.com.au [radiator-boun...@open.com.au] on behalf of Heikki Vatiainen [h...@open.com.au] Sent: Wednesday, June 29, 2016 2:20 PM To: radiator@open.com.au Subject: Re: [RADIATOR] Questions regarding new release and current roadmap On 29.6.2016 12.16, Nadav Hod wrote: > 1) Any news on uploading the roadmap? No new news. > 2.1) OCSP + OCSP stapling. I've heard this is on the roadmap for the > near future. Yes, there was recently discussion about this related to RadSec support. What would your use case be? If it's for TSL based EAP methods, do you know what the stepling support is on the client side? > 2.2) TLS resumption support by Session Tickets (RFC 5077). Another > option is to just wait for TLS 1.3 support although it would take > several years until most clients in an organization would support > TLS 1.3, if at all. Noted. For this feature too, would it be for EAP methods too or do you have something else in mind? > 2.3) Multithreading support for Windows Server (at the moment I'm > using a master service and splitting the handling of different > authentication methods to different Windows services). I don't think multithreading support is the way forward. What we are interested in doing is making it easier to run multiple instances that work together. > 2.4) A mature, flexible and robust web GUI, preferably one that can > manage distributed Radiator servers. The web GUI I'm using for 4.15 > isn't much help for maintaining configuration and reading log files, > let alone multiple configuration files. Therefore I need to remote > desktop into the Radiator server in order to manage anything. This > is compounded further if you're using many Radiator servers. Centralised logging, and logging enhancements in general, is also something we're working on. There's also work done for interfaces that can enable building a web GUI, so the GUI does not have to be within Radiator itself. What comes to credential security, the credentials can be encrypted/obfuscated so that they are not in clear text format in the configuration file. There's initial support for that in the patches. However, we have not looked at separate products for credential storage. Thanks, Heikki -- Heikki Vatiainen Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Questions regarding new release and current roadmap
Hi Alan,
2.5) I probably wasn't clear enough. The include command isn't what I'm looking
for since that takes blocks of configuration, not variables, and embeds it in
the current configuration. It can't be used to extract a specific variable
within that external file. A header file isn't a configuration file which is
put into another configuration file, it's just variables and declarations.
I've used Radiator 4.15, and I couldn't use external variables as part of
parameters in order to make a generic configuration. What I'm looking for is
something like the following: assume I have an AuthBy LDAP2 clause. I would
like to declare:
Host %{GlobalVar:my_ldap_variables.txt::FirstHost}
In this example my_ldap_variables.txt contains variables bindings for LDAP
configurations, FirstHost being one of them.
Something like this, as far as I can tell, isn't possible today. I would need
to have FirstHost configured within the local configuration file.
If I could create a directory on each server that contains files, each of which
contain variables relevant to that file, it would make things very easy and
manageable. I could put the same Radiator configuration on each server, and
just update the variables per server.
Is this possible with Radiator using existing features?
2.6) Password vaults are designed to not only maintain passwords (by a strong
complexity policy, frequent generation of new passwords, etc.) but also be
physically tamper-proof, provide high availability and be FIPS 140-2 compliant.
That's not the same as storing it on a mysql database on a remote machine.
The service running Radiator can be a strong user which needs to know only the
hostname of the clients, without the passwords. The passwords can be maintained
somewhere else. Yes, passwords will be loaded into RAM during authentication
and a more sophisticated attacker can extract these passwords locally if they
are local admins, but password vaults update these passwords frequently so that
it doesn't really matter.
I think that allowing a 3rd party solution manage the passwords, assuming that
the API exists, could help secure credentials immensely.
From: a.l.m.bu...@lboro.ac.uk [a.l.m.bu...@lboro.ac.uk]
Sent: Wednesday, June 29, 2016 1:09 PM
To: Nadav Hod
Cc: Heikki Vatiainen; radiator@open.com.au
Subject: Re: [RADIATOR] Questions regarding new release and current roadmap
Hi,
> 2.5) A method of synchronizing configuration files (apart from certain
> variables) across multiple servers. If all Radiator servers have very similar
> configuration and are distributed for load balancing and redundancy, it's a
> shame that the configuration needs to be managed and configured separately
> for each server. There are differences between servers, but the bulk of the
> configuration can remain the same.
>
> There is 3rd party software such as rsync for synchronizing files, but the
> variables for each Radiator configuration file have to be within the file
> itself (as far as I can tell). If the variables could be configured outside
> of each configuration file, such as a header file, this would allow for
> synchronizing the configuration files effectively across all servers while
> still taking into account the differences between each server.
eh??? we do multi server configuration syncing already - you know that you
can just include different files for
each server...using...a headerfile as you say - our radius.cfg contains all
local requirements and then pulls in
the local config file for the server. (in our case we use a database to hold
all details, generate the required
new configs for each server then push out to each server)
> 2.6) A more secure method for storing credentials, at the moment they can
> only be stored locally on the Radiator servers. Perhaps integration with
> popular 3rd party solutions (such as CyberArk) if their API permits it.
read discussions on the list - if stored elsewhere there are still security
issues. what are you hoping to fix/resolve?
you can store configs on a remote DB if there are basic local issues (though
anyone with admin access could still read the
DB credentials and then connect to the DB to get hold of config).
alan
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Questions regarding new release and current roadmap
On 29/06/2016 13:23, Nadav Hod wrote:
>
>
> 2.5) I probably wasn't clear enough. The include command isn't what I'm
> looking for since that takes blocks of configuration, not variables, and
> embeds it in the current configuration. It can't be used to extract a
> specific variable within that external file. A header file isn't a
> configuration file which is put into another configuration file, it's just
> variables and declarations.
>
> I've used Radiator 4.15, and I couldn't use external variables as part of
> parameters in order to make a generic configuration. What I'm looking for is
> something like the following: assume I have an AuthBy LDAP2 clause. I would
> like to declare:
>
> Host %{GlobalVar:my_ldap_variables.txt::FirstHost}
>
> In this example my_ldap_variables.txt contains variables bindings for LDAP
> configurations, FirstHost being one of them.
>
> Something like this, as far as I can tell, isn't possible today. I would need
> to have FirstHost configured within the local configuration file.
>
> If I could create a directory on each server that contains files, each of
> which contain variables relevant to that file, it would make things very easy
> and manageable. I could put the same Radiator configuration on each server,
> and just update the variables per server.
>
> Is this possible with Radiator using existing features?
>
hi nadav
there is no need for radiator to do any of the above as there are
numerous tools/suites for exactly this sort of thing : saltstack,
puppet, ansible, chef et al
signature.asc
Description: OpenPGP digital signature
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
