[rancid] Alternatives to cleartext password in .cloginrc ?

[Matt Almgren]

What are the available options, if any, to using non-cleartext passwords for Rancid in the .cloginrc file? We also use TAC+ as the backend AAA.

This wasn’t a huge concern for me until I realized that it goes against some of the PCI compliance regulations about storing passwords in the clear.

Thanks, Matt

[Matt Almgren]

BTW, I have read some interesting replies in the mailing list archives:

If your poller is not secure it doesn't matter what authentication method you use. So while you could for some platforms set up .shosts or RSA authorized keys, it doesn't really accomplish anything.

And

If something automated is going to log into a router, it needs an authentication credential. That's going to have to be stored somewhere. If you store it encrypted, then you're going to need to store the decryption key somewhere. All that does is rearrange the exposure, not solve it.

And


If you use a TACACS server for authentication, then you could do some interesting things to make the passwords RANCID uses less useful to outsiders - for example, the TACACS server could only allow the RANCID username to be used from the RANCID host, or during certain times of day, or only allow it to execute a limited subset of commands.


I’m just wondering if there’s any new information or ideas.

Thanks, Matt






From: Matt Almgren <***@surveymonkey.com<mailto:***@surveymonkey.com>>
Date: Tuesday, May 5, 2015 at 11:11 AM
To: "rancid-***@shrubbery.net<mailto:rancid-***@shrubbery.net>" <rancid-***@shrubbery.net<mailto:rancid-***@shrubbery.net>>
Subject: Re: [rancid] Alternatives to cleartext password in .cloginrc ?


What are the available options, if any, to using non-cleartext passwords for Rancid in the .cloginrc file? We also use TAC+ as the backend AAA.

This wasn’t a huge concern for me until I realized that it goes against some of the PCI compliance regulations about storing passwords in the clear.

Thanks, Matt

[Daniel Schmidt]

Use tacacs - use do_auth. Make rancid user that can only type a few
commands and only when logged in from that IP. If somebody get my rancid
password, it's practically useless.

http://www.tacacs.org/tacacsplus/2011/03/02/securing-rancid-with-do_auth

*If your poller is not secure it doesn't matter what authentication **method
you use.* So while you could for some platforms set up .shosts or RSA
authorized keys, it doesn't really accomplish anything.
And
If something automated is going to log into a router, it needs an
authentication credential. That's going to have to be stored somewhere. If
you store it encrypted, then you're going to need to store the decryption
key somewhere. *All that does is rearrange the exposure, not solve it.*
And
If you *use a TACACS server for authentication, then you could do some interesting things to make the passwords RANCID uses less useful to outsiders *- for example, the TACACS server could only allow the RANCID username to be used from the RANCID host, or during certain times of day, or only allow it to execute a limited subset of commands.
I’m just wondering if there’s any new information or ideas.
Thanks, Matt
Date: Tuesday, May 5, 2015 at 11:11 AM
Subject: Re: [rancid] Alternatives to cleartext password in .cloginrc ?
What are the available options, if any, to using non-cleartext
passwords for Rancid in the .cloginrc file? We also use TAC+ as the
backend AAA.
This wasn’t a huge concern for me until I realized that it goes against
some of the PCI compliance regulations about storing passwords in the
clear.
Thanks, Matt
_______________________________________________
Rancid-discuss mailing list
http://www.shrubbery.net/mailman/listinfo/rancid-discuss

[Lee Rian (CENSUS/TCO FED)]

I know one person that installed Rancid on an encrypted USB drive. It doesn't eliminate the risk of cleartext passwords in .cloginrc but it does reduce the exposure.


Regards,

Lee



________________________________
From: Rancid-discuss <rancid-discuss-***@shrubbery.net> on behalf of Matt Almgren <***@surveymonkey.com>
Sent: Tuesday, May 5, 2015 2:38 PM
To: rancid-***@shrubbery.net
Subject: Re: [rancid] Alternatives to cleartext password in .cloginrc ?


BTW, I have read some interesting replies in the mailing list archives:

If your poller is not secure it doesn't matter what authentication method you use. So while you could for some platforms set up .shosts or RSA authorized keys, it doesn't really accomplish anything.

And

If something automated is going to log into a router, it needs an authentication credential. That's going to have to be stored somewhere. If you store it encrypted, then you're going to need to store the decryption key somewhere. All that does is rearrange the exposure, not solve it.

And


If you use a TACACS server for authentication, then you could do some interesting things to make the passwords RANCID uses less useful to outsiders - for example, the TACACS server could only allow the RANCID username to be used from the RANCID host, or during certain times of day, or only allow it to execute a limited subset of commands.


I'm just wondering if there's any new information or ideas.

Thanks, Matt






From: Matt Almgren <***@surveymonkey.com<mailto:***@surveymonkey.com>>
Date: Tuesday, May 5, 2015 at 11:11 AM
To: "rancid-***@shrubbery.net<mailto:rancid-***@shrubbery.net>" <rancid-***@shrubbery.net<mailto:rancid-***@shrubbery.net>>
Subject: Re: [rancid] Alternatives to cleartext password in .cloginrc ?


What are the available options, if any, to using non-cleartext passwords for Rancid in the .cloginrc file? We also use TAC+ as the backend AAA.

This wasn't a huge concern for me until I realized that it goes against some of the PCI compliance regulations about storing passwords in the clear.

Thanks, Matt

[rdrake]

*If your poller is not secure it doesn't matter what authentication
**method you use.* So while you could for some platforms set up
.shosts or RSA authorized keys, it doesn't really accomplish anything.
And
If something automated is going to log into a router, it needs an
authentication credential. That's going to have to be stored
somewhere. If you store it encrypted, then you're going to need to
store the decryption key somewhere. *All that does is rearrange the
exposure, not solve it.*
And
If you*use a TACACS server for authentication, then you could do some interesting things to make the passwords RANCID uses less useful to outsiders*- for example, the TACACS server could only allow the RANCID username to be used from the RANCID host, or during certain times of day, or only allow it to execute a limited subset of commands.
I’m just wondering if there’s any new information or ideas.
Thanks, Matt

If you're okay with not using Expect, you could use my perl tel script:

https://github.com/rfdrake/tel

It supports storing the password in Keepass and Keyrings (Gnome, KDE and
MacOS). I honestly recommend you stick with clogin on a very secure
machine for rancid, but for interactive logins in a NOC environment I
would recommend doing something with a keyring or password vault.

Yes, you do need to store the decryption key somewhere, but that should
be only in a protected memory space that only that user and superuser
could access. Obviously you'll need to tailor your security to your own
environment and needs.

Alternatives to this:

If you need one time keys and all your routers support them then tacacs
will also do this (I think. I'm not sure how you would go about setting
up rancid to use it but I imagine it would be cumbersome. I would just
bypass it for rancid use).

If all your routers support ssh user keys then you should use them and
use passphrases to protect security. Revocation can happen through
whatever means the router supports (something custom I suspect, but
maybe puppet on some boxes?). At one point in time I thought about
modifying tacacs to support ssh user key distribution (so on a login
request it would ask the tacacs server for the users public key). I
ended up getting distracted.

[Lukasz Sokol]

Post by Matt Almgren
What are the available options, if any, to using non-cleartext
passwords for Rancid in the .cloginrc file? We also use TAC+ as the
backend AAA.

I've no TAC+, but

Post by Matt Almgren
This wasn’t a huge concern for me until I realized that it goes
against some of the PCI compliance regulations about storing
passwords in the clear.

Did you consider rancid over ssh private/public key pairs
(do your devices support ssh, in the first place)?

Post by Matt Almgren
Thanks, Matt

HTH
Lukasz

[Matt Almgren]

Ssh keys are still on the table and that is one of the alternatives.
However, I¹d like to use TAC+ as well for authorization and accounting.

However, I¹m not finding too much information for incorporating TAC+ with
SSH keys. If we went that route, that would probably solve most of our
issues - albeit more of a headache to roll out.

Thanks, Matt

Post by Lukasz Sokol

Post by Matt Almgren
What are the available options, if any, to using non-cleartext
passwords for Rancid in the .cloginrc file? We also use TAC+ as the
backend AAA.

I've no TAC+, but

Post by Matt Almgren
This wasn¹t a huge concern for me until I realized that it goes
against some of the PCI compliance regulations about storing
passwords in the clear.

Did you consider rancid over ssh private/public key pairs
(do your devices support ssh, in the first place)?

Post by Matt Almgren
Thanks, Matt

HTH
Lukasz
_______________________________________________
Rancid-discuss mailing list
http://www.shrubbery.net/mailman/listinfo/rancid-discuss

[Matt Almgren]

I’m just curious, if you’re not using TAC+ or RADIUS, how do you manage
authorization (user levels, permissions per device, etc)?

Thanks, Matt

Post by Matt Almgren
Ssh keys are still on the table and that is one of the alternatives.

They are relatively easy to roll out on rancid by itself - I did it after
some
googling, and it wasn't too bad... (key based ident is mentioned in one
of the articles
that pop up when googling for rancid and ssh... adapted a bit to my
debian needs and that's
it, all it really needed.)

Post by Matt Almgren
However, I¹d like to use TAC+ as well for authorization and accounting.

However I've no notion or knowledge of TAC+ sorry...

Post by Matt Almgren
However, I¹m not finding too much information for incorporating TAC+ with
SSH keys. If we went that route, that would probably solve most of our
issues - albeit more of a headache to roll out.
Thanks, Matt

el es

[heasley]

Post by Matt Almgren
Ssh keys are still on the table and that is one of the alternatives.

They are relatively easy to roll out on rancid by itself - I did it after some
googling, and it wasn't too bad... (key based ident is mentioned in one of the articles
that pop up when googling for rancid and ssh... adapted a bit to my debian needs and that's
it, all it really needed.)

the passphrase is still stored somewhere. although interactive users could
use ssh-agent.

[Lance Vermilion]

For user access (not config backup) of rancid scripts a simple work around
I am (sometime soon) implementing a script that does a find/replace in the
.cloginrc. The password stored in the . cloginrc is in base64 format so not
clear text. This means i will also patch rancid to decode the password
encoded in base64. Each time the user logs in they will need to enact this
script that does the updating of the .cloginrc because at logout/login the
.cloginrc is set back to variables (for easy find and replace).

This solution will not work for everyone but it will for me.

Post by heasley

Post by Matt Almgren
Ssh keys are still on the table and that is one of the alternatives.

They are relatively easy to roll out on rancid by itself - I did it after some
googling, and it wasn't too bad... (key based ident is mentioned in one of the articles
that pop up when googling for rancid and ssh... adapted a bit to my debian needs and that's
it, all it really needed.)

the passphrase is still stored somewhere. although interactive users could
use ssh-agent.
_______________________________________________
Rancid-discuss mailing list
http://www.shrubbery.net/mailman/listinfo/rancid-discuss

[Alan McKinnon]

Post by Matt Almgren
What are the available options, if any, to using non-cleartext passwords
for Rancid in the .cloginrc file? We also use TAC+ as the backend AAA.
This wasn’t a huge concern for me until I realized that it goes against
some of the PCI compliance regulations about storing passwords in the
clear.

Unfortunately some of those rules and regulations are subject to far too
much FUD and cargo-culting. The original intent is obvious - don't store
user's login creds in cleartext on the host that delivers the service.
Much the same as how we now hash passwords strongly and put them in
/etc/shadow.

.cloginrc is an entirely different kettle of fish, a completely
different problem altogether. The only way to log into the network
device is with a password as the vendor doesn't offer anything else.
Therefore something needs to know what the password is and needs to be
able to render it in plaintext. You could encrypt .cloginrc somehow, but
the automated system still needs the decryption key and at some point
that key needs to be plaintext. So as you said in your other mail, all
"solutions" to this problem just shuffle it around in obfuscating ways.

What I did was get my Risk Officer's backing for my security measures,
and that satisfied the Compliance people. All we did was the ordinary:

- access to the rancid server was closely controlled and only the team
managing it had access. Login by ssh key only. A system was in place to
automate account add/remove as people moved around.
- Only the rancid user could read .cloginrc (done by file permissions)
and the human user had to use sudo -i to become rancid, controlled by
/etc/sudoers
- it was the responsibility of NetOps to ensure all rancid-polled
devices were Tacacs-enabled, and we controlled the tacacs accounts which
had strong passwords, a strong hashing system in tac_plus.conf, and the
account was locked down to the exact set of commands that rancid runs
- The tacacs and rancid servers were located in the network management
range which was monitored by several teams due to it's sensitive nature

There were a few other details, but you get the gist - use the ordinary
proven techniques to protect your system.