[rancid] Securing RANCID installation

[Jason Humes]

Hi
Are there are tips or best practices for securing a RANCID installation...the clogin files, the backed up configs, etc.

Thanks for any advice! :)

Cheers

Jason

[Hughes, Doug]

1) rancid already eliminates the passwords from the configs - that's pretty significant
2) define a rancid group.
3) make a rancid user that is part of that group
4) make the rancid writable directories be chmod g+s for that group, and make the umask 022 to prevent other people from reading the files (if so inclined - depending on your security needs)

Optionally, store the versioned configs in a repository with restricted permissions for view (e.g. git+gerrit or just git or perforce or whatever) or use a local repository (again git, svn, cvs, whatever) that has permissions for the rancid group. If you use a web server that diffs these things for quick visual, colorized config audits, make sure you protect that with the same level of permissions. Define passwords or http access lists or whatever according to your needs.

-----Original Message-----
From: Rancid-discuss [mailto:rancid-discuss-***@shrubbery.net] On Behalf Of Jason Humes
Sent: Tuesday, December 16, 2014 9:43 AM
To: rancid-***@shrubbery.net
Subject: [rancid] Securing RANCID installation

Hi
Are there are tips or best practices for securing a RANCID installation...the clogin files, the backed up configs, etc.

Thanks for any advice! :)

Cheers

Jason

[Lance Vermilion]

No one has access to the server running rancid unless necessary.

Provide access via webpage.

Attempts at encrypting the .cloginrc always seen fruitless because you
provide a way to decrypt somewhere.

You could ways look at doing ACLs to restrict and log who can see what.

Post by Jason Humes
Hi
Are there are tips or best practices for securing a RANCID
installation...the clogin files, the backed up configs, etc.
Thanks for any advice! :)
Cheers
Jason
_______________________________________________
Rancid-discuss mailing list
http://www.shrubbery.net/mailman/listinfo/rancid-discuss

[Howard Jones]

Post by Jason Humes
Hi
Are there are tips or best practices for securing a RANCID installation...the clogin files, the backed up configs, etc.
Thanks for any advice! :)

Don't tell anyone the account password who you don't trust! :-)
Seriously, it's a bunch of scripts that run as a single non-privileged
user, producing files owned by that user. Run everything as a dedicated
'rancid' user, and basic Unix file permissions will take care of that.
Your most likely information leak is the diff e-mails.

If you have a web UI for it, that's a whole different story, but that's
not really part of RANCID either. We use mod_authnz_ldap against our AD,
mod_python, mod_ssl and viewvc pointed to the RANCID svn files, and that
seems to work well enough - you need to modify the group permissions for
the svn files so that a group that apache and rancid both belong to can
read them. Using AD (or individual htpasswd accounts) means we get audit
logs of who accessed what in the webserver access logs.

Cheers,

Howard

[Alan McKinnon]

Post by Jason Humes
Hi
Are there are tips or best practices for securing a RANCID installation...the clogin files, the backed up configs, etc.
Thanks for any advice! :)

Others have explained well how to secure the data rancid produces to
avoid information leakage.

I would add that protecting .cloginrc is very very important as it
contains login and enable passwords for the admin account on all your
network devices.

Make sure that only authorized sysadmins have login access to the rancid
host, and that the rancid user's home directory is set with very
restricted permissions (assuming a user called rancid):

chown -R rancid ~rancid
chmod -R go-rwx ~rancid


Considering what can happen if .cloginrc leaks, it's a good idea to run
rancid on a dedicated single-purpose host. Rancid is very light on
resources, a basic VM with 1 cpu and 512M RAM does the job admirably

[Daniel Anderson]

I would also recommend configuring/using a dedicated network (TACACS/RADIUS) account that only has permissions to run the commands that RANCID uses so that if someone does get the .cloginrc file somehow that it's harder for them to make config changes on the devices.

--
Dan

Post by Alan McKinnon

Post by Jason Humes
Hi
Are there are tips or best practices for securing a RANCID installation...the clogin files, the backed up configs, etc.
Thanks for any advice! :)

Others have explained well how to secure the data rancid produces to
avoid information leakage.
I would add that protecting .cloginrc is very very important as it
contains login and enable passwords for the admin account on all your
network devices.
Make sure that only authorized sysadmins have login access to the rancid
host, and that the rancid user's home directory is set with very
chown -R rancid ~rancid
chmod -R go-rwx ~rancid
Considering what can happen if .cloginrc leaks, it's a good idea to run
rancid on a dedicated single-purpose host. Rancid is very light on
resources, a basic VM with 1 cpu and 512M RAM does the job admirably
--
Alan McKinnon
_______________________________________________
Rancid-discuss mailing list
http://www.shrubbery.net/mailman/listinfo/rancid-discuss

[Daniel Schmidt]

I wrote an article on tacacs.org on security rancid. However, tacacs.org
appears to be gone. Pretty easy to lock down with do_auth. As for local
passwords, if tacacs is properly configured, they are useless.

Post by Daniel Anderson
I would also recommend configuring/using a dedicated network
(TACACS/RADIUS) account that only has permissions to run the commands that
RANCID uses so that if someone does get the .cloginrc file somehow that
it's harder for them to make config changes on the devices.
--
Dan

Post by Alan McKinnon

Post by Jason Humes
Hi
Are there are tips or best practices for securing a RANCID

installation...the clogin files, the backed up configs, etc.

Post by Alan McKinnon

Post by Jason Humes
Thanks for any advice! :)

Others have explained well how to secure the data rancid produces to
avoid information leakage.
I would add that protecting .cloginrc is very very important as it
contains login and enable passwords for the admin account on all your
network devices.
Make sure that only authorized sysadmins have login access to the rancid
host, and that the rancid user's home directory is set with very
chown -R rancid ~rancid
chmod -R go-rwx ~rancid
Considering what can happen if .cloginrc leaks, it's a good idea to run
rancid on a dedicated single-purpose host. Rancid is very light on
resources, a basic VM with 1 cpu and 512M RAM does the job admirably
--
Alan McKinnon
_______________________________________________
Rancid-discuss mailing list
http://www.shrubbery.net/mailman/listinfo/rancid-discuss

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

E-Mail to and from me, in connection with the transaction
of public business, is subject to the Wyoming Public Records
Act and may be disclosed to third parties.

[Aaron Block]

I wrote an article on tacacs.org on security rancid. However, tacacs.org appears to be gone. Pretty easy to lock down with do_auth. As for local passwords, if tacacs is properly configured, they are useless.

tacacs.org appears to be back.

Aaron Block

[Joseph Jackson]

Just for future reference here is my tacacs+ config that only allows rancid user to do show commands it needs to run.

user = rancid2 {
member = rancid
login =
}


group = rancid {
default service = deny
service = exec {
priv-lvl = 6
}
cmd = show {
permit .*
}
cmd = write {
permit term
}
cmd = dir {
permit .*
}
cmd = admin {
permit .*
}
cmd = more {
permit .*
}

-----Original Message-----
From: Rancid-discuss [mailto:rancid-discuss-***@shrubbery.net] On Behalf Of Aaron Block
Sent: Wednesday, January 07, 2015 4:06 PM
To: Daniel Schmidt
Cc: rancid-***@shrubbery.net
Subject: Re: [rancid] Securing RANCID installation

I wrote an article on tacacs.org on security rancid. However, tacacs.org appears to be gone. Pretty easy to lock down with do_auth. As for local passwords, if tacacs is properly configured, they are useless.

tacacs.org appears to be back.

Aaron Block