Configuring RANCID on CentOS 6.5

RANCID stands for really awesome new cisco configuration differ[1] and polls Cisco devices to get a copy of the configuration and an inventory of the hardware and commits the details to a version control system such a CVS or SVN. The version control is used to maintain a history of the changes, and any changes to the configuration are reported. There are a number of guides available for installing RANCID[2,4,5], but I've documented the steps I took here for my reference.

Pre-requisites
You must have and use the EPEL repositories. Note that at the time this post was made, the current version was version 3.1[3]. However, the version available via EPEL was only 2.3.6.

Installation

1. yum -y update
2. yum -y upgrade
3. yum -y install rancid

Configuration

1. Edit the /etc/rancid/rancid.conf file to create a list of groups for your devices to change the LIST_OF_GROUPS variable e.g., LIST_OF_GROUPS="routers switches", change the CVSROOT if you are using SVN i.e., CVSROOT=$BASEDIR/SVN; export CVSROOT and change the RCS system if changing to SVN i.e., RCSSYS=svn; export RCSSYS
1. vi  /etc/rancid/rancid.conf 
2. Create e-mail aliases for the groups, note that the names should match. Edit the /etc/aliases file. Ensure that the newaliases command is execute after the file has been modified
1. vi /etc/aliases
2. newaliases
3. The rancid group and users should already be created. The home directory for the rancid user corresponds with the BASEDIR in the configuration file viz. /var/rancid. Generate the svn repository for the configuration, group directories, and the log directories by running the rancid-cvs script
1.  /usr/bin/rancid-cvs
4. Add devices to each group to specify their IP address, the make or type, and their status i.e., up or down. Edit the router.db file in each group directory. e.g., c7206-core-router:cisco:up
1. vi /var/rancid/routers/router.db
5. Next the login credentials for each node is to be specified in the .cloginrc. Copy the file from the sample documentation, and edit the file to provide the login credentials. I prefer to explicitly set the node address, and user
1. cp /usr/share/doc/rancid-2.3.6/cloginrc.sample /var/rancid/.cloginrc
2. vi /var/rancid/.cloginrc
3. chmod 600 .cloginrc
6. Configure a user using TACACS or on your Cisco device to only have privilege to view the  config 
1. username rancid privilege 3 secret <SECRET>
2. privilege exec level 3 show start-config
7. Change ownership of all files and directories in the rancid users home directory to the rancud group and user
1. chown -R rancid:rancid /var/rancid
8. Test the clogin as the rancid user
1. su - rancid
2. /usr/libexec/rancid/clogin c7206-core-router
9. If all goes well, run rancid manually for the first time. This will generate config files for each define in the group in the config directory
1. /usr/bin/rancid-run
10. Schedule rancid and the cleanup by setting up cron jobs as the rancid user, crontab -e

# Minute   Hour   Day of Month   Month              Day of Week      Command

# (0-59)   (0-23) (1-31)         (1-12 or Jan-Dec)  (0-6 or Sun-Sat) /...

# shedule to run rancid every 15 minute

*/15 * * * * /usr/bin/rancid-run

# schedule to remove rancid log files over 2 days old at 8am

0 8 * * * /bin/find /var/rancid/logs -type f -mtime +2 -exec rm {} \;

References

1. http://www.shrubbery.net/rancid/
2. http://www.shrubbery.net/rancid/RhysEvans_overview_0.3.pdf
3. ftp://ftp.shrubbery.net/pub/rancid/
4. http://networklore.com/rancid-getting-started/
5. http://fakrul.wordpress.com/2013/11/20/rancid-websvn-centos-howto/

Dog Training for Network Admins: Managing POODLE - CVE-2014-3566

CVE-2014-3566 relates to a flaw found in handling of padded bytes in SSL 3.0 when using CBC mode for the encryption[3]. The flaw may be exploited to permit a man-in-the-middle (MITM) attack. The attacker may be able to decrypt a selected byte of a cipher text in a limited number (256) of attempts, by repeatedly requesting the victim to send the same data over multiple SSLv3 connections.

The vulnerability exists in the protocol itself and not a specific implementation of the protocol e.g., OpenSSL, GnuTLS, etc. Thus, the mitigation is to stop using SSLv3 and to have TLSv1+ as the minimum.

Both clients and servers are vulnerable to the attack. Server administrators should configure all services to disable the use of SSLv3. There are numerous sources[2] documenting the disabling of SSLv3 on browsers. Again, unfortunately Apple's Safari does not appear to be as configurable has not provided such control for Safari to disable SSLv3. In fact Apple's approach seems to have been to disable CBC mode encryption if TLS negotiation fails. However Safari Version 8.0 (10600.1.25) on Yosemite, i.e Mac OS X 10.10 still appeared to be vulnerable using the poodletest.com website[4].

In addition to disabling SSLv3 at the servers and browsers, it may also be desirable to block SSLv3 traffic at the network perimeter in case something is not patched. This would require examining the SSL handshakes for the cipher suite negotiation, and blocking SSLv3 connections. Fortunately someone has already done the hardwork[1] of finding the offsets, etc.

References

1. https://blog.g3rt.nl/take-down-sslv3-using-iptables.html
2. https://zmap.io/sslv3/browsers.html
3. http://security.stackexchange.com/questions/70719/ssl3-poodle-vulnerability
4. https://www.poodletest.com/