That’s gonna be a tough sell…

Still excited about VyOS, but I have to tell you, I’ve discovered something that might be what you’d call “a showstopper” in terms of using it in production…

Let’s talk about AAA (or “Triple-A”) for a moment.

AAA is neither a bond rating, a level of professional baseball, nor an automotive club…  It stands for:

  • Authentication – Who are you?
  • Authorization – What are you allowed to do?
  • Accounting – What did you do?

This is a centralized mechanism for administering username/password, system privileges, and recording activities on network devices like routers, switches, etc.

In the network space, there are really only two ways to provide AAA services.  TACACS+ or RADIUS.  They are ubiquitous.

TACACS stands for:

  • Terminal
  • Access
  • Controller
  • Access
  • Control
  • System

The original TACACS protocol, which dates back to 1984, was used for communicating with an authentication server, common in older UNIX networks.  TACACS+ was later developed by Cisco and released as an open standard in 1993. Although derived from TACACS, TACACS+ is a separate protocol that handles AAA services.

Absent support for TACACS+, the second most prevalent means for centralized user management in the network space is RADIUS:

  • Remote
  • Authentication
  • Dial
  • In
  • User
  • Service

Like TACACS, RADIUS is a networking protocol that provides centralized AAA management for users who connect and use a network service. RADIUS was developed by Livingston Enterprises, Inc. in 1991 as an access server authentication and accounting protocol and later brought into the Internet Engineering Task Force (IETF) standards.

Basically, your network appliance needs to support either TACACS+ or RADIUS, and generally, most support both.

Having seen a number of VyOS related snippets out there, I assumed that there would be at least minimal support for TACACS+.

In order to prove it out, I installed tac_plus, an open version of TACACS+ AAA service with a few added features.  In order the verify that I had it up and working, I managed to get my Cisco SG300-28 switch to start using it for authentication.  In and of itself, this was a worthwhile exercise, but I probably wouldn’t have bothered had I not expected to be able to use it with VyOS.

Alas, despite all of the discussion around TACACS+ support, none of that seems to have found its way into the current version (1.1.7 Helium).

While combing through the UI, I did see that there were a number of RADIUS related commands:

vyos@VyOS-1# set system login radius-server <xx.xx.xx.xx> 
Possible completions:
   port         Radius port [REQUIRED]
   secret       Secret for radius access [REQUIRED]
   timeout      Timeout for radius session [REQUIRED]

That was encouraging.  I set out to install and configure FreeRADIUS, which describes itself thusly:

FreeRADIUS includes a RADIUS server, a BSD licensed client library, a PAM library, and an Apache module. In most cases, the word FreeRADIUS refers to the RADIUS server.

FreeRADIUS is the most widely deployed RADIUS server in the world. It is the basis for multiple commercial offerings. It supplies the AAA needs of many Fortune-500 companies and Tier 1 ISPs.

It is also widely used for Enterprise Wi-Fi and IEEE 802.1X network security, particularly in the academic community, including eduroam.

The server is fast, feature-rich, modular, and scalable.

After getting that installed, I started watching the logs, and attempting to authenticate into the VyOS instance where I’d entered the RADIUS configs…

Nothing in the logs.  No connection attempts.  No authentication failures.  Zip.

I hit the VyOS IRC channel on freenode, and asked if there was some trick I’d missed.  Turns out there isn’t…  They haven’t really implemented any of the RADIUS elements necessary for system level authentication.

This is a problem.

The business world demands accountability, and auditability…  That just how it is.  When you handle people’s identity information, and their payment information, you have to be able to lock things down, record all activity on productions systems, and have an bullet-proof audit trail in the event of a breach.  Not only that, but you have to be able to demonstrate all of it, often to external parties.

The inability to handle either of the two main AAA mechanisms is, frankly, a disastrous gap.

This is, unfortunately, what it always comes down to for me with a lot of open source projects/products…  I don’t write code.  I use it.

At this stage, the only hope I have for getting this “accredited” is to tie it in with some kind of LDAP authentication.  I hope that works…

Share this post:
Facebooktwittergoogle_plusredditpinterestlinkedintumblrmail
war Written by:

11 Comments

  1. September 3, 2016
    Reply

    Nice write-up!
    Right!
    Since the VyOS project has kind of limited resources, we need to select priorities well, for a long time priority #1 was porting to Debian 8 as there is no life in Debian 6 anymore, and it’s hard to put there anything fresh.
    Now, when we are near to beta 2, we can consider adding “things” which will appear in 1.2.x.
    AFAIR you have an account on our https://phabricator.vyos.net, it will be great if you can spend some time and create tasks regarding this feature set.
    We need more participants in the project and everybody welcome, especially with value inputs
    Thank you!

    • September 3, 2016
      Reply

      Yuriy, first, thanks for reading and commenting. I hope you understand that this is “constructive criticism,” rather than some jerk on the Internet lashing out. I *really* like this project, and have very high hopes for it.

      I do have an account, and I would be happy to create some tasks on phabricator. To be honest, I’ve always viewed that as something for people that were actually in a position to contribute code to a project.

      If instead, it’s meant for the average user to help steer and prioritize the development effort – say no more! I’m your Huckleberry.

  2. September 3, 2016
    Reply

    By the way!
    Since you talking about auditors/security folks

    We started conversation with rkhunter author which now runs company
    https://cisofy.com/lynis/
    And we are looking deliver lynis as part of base image(lot of work to be done)
    So i hope this will be really useful

    • September 3, 2016
      Reply

      Interesting… I’ll take a look at this.

  3. Chance Ellis
    September 4, 2016
    Reply

    I noticed the lack of AAA when I was playing with VyOS too. My thought was in the SDN world, administrators will be touching the actual devices less and less. This is especially true in virtualized platforms where you may not have any idea where the network “device” lives. A good SDN controller should have all of the AAA features built in.

    • September 4, 2016
      Reply

      Agreed, in an SDN environment, AAA is handled through the controller, rather than at the endpoint, but I think there’s a difference between an SDN controlled “cloud router,” and my perception of what VyOS is: a dedicated (albeit virtualized) routing appliance.

      I put it in the category of a Cisco CSR, a Juniper vXM, or a Brocade vRouter, where the network administrator interacts with the appliance in the same manner as he would any hardware based appliance. That fact that it’s running on VMware, or KVM, is immaterial. After all, network folks log into devices they’ve never seen or touched before all the time.

      At least, that’s what it is today. In the future, who knows? Today’s use case is not the cloud provider – it’s the cloud tenant, or the small to medium enterprise who’s looking to get more out of his existing virtualization investment, without being beholden to the main network vendors in terms of annual licensing costs.

    • September 10, 2016
      Reply

      Well, VyOS is not the UI-less SDN router. People touch it all the time.
      But, proper RADIUS/TAC+ AAA is not really requested all that often, probably because average user doesn’t have nearly enough routers to make the first two A’s entirely unmanageable, and the commit archive functionality provides pretty good accounting already. Typical setup may be say 20 web servers behind just one or two top of the rack routers, or 100 workstations behind one router.
      Besides, in a system where configuration commands mean nothing until you commit, traditional command accounting isn’t of much use.

      Still, the first two A’s are quite tricky to do right, there are many implementation details that should be agreed upon, such as how to handle homedirs for users who only exist in RADIUS (something that is often handled by storing homedirs outside of machines, in LDAP setups for workstations). It takes a person who’s invested enough in the idea to participate in design and do real-life testing, like WAR, for instance. 😉

  4. September 10, 2016
    Reply

    Howdy, i read your blog occasionally and i own a similar one and i was just curious if you get a lot of spam comments?
    If so how do you prevent it, any plugin or anything
    you can recommend? I get so much lately it’s driving
    me mad so any support is very much appreciated.

    • September 11, 2016
      Reply

      Can’t tell if this is spam or not, but a plug for Akismet is never a bad idea.

Leave a Reply

Your email address will not be published. Required fields are marked *