Setting up git

Git is yet another open source version control, and seems to be the tool of choice for contemporary coding mavericks. I still prefer svn and cvs, for centralised version control, but can appreciate why some projects may require distributed repositories as afforded by git.

Setting up a central git repository on a server is easy. You basically setup a user, whose home directory is used to store the repositories, and allow access to people using keys, where the user retain their private key and their public key is saved as an authorised key for the git user account.

Note: I've documented the steps I used below for my benefit. The name of the server has been replace with <SERVER>, and the source code repository example is project.git

Set-up

1. groupadd git
2. useradd -g git -d /home/git -m git
3. su - git
4. mkdir -p /home/git/.ssh
5. cat id_rsa.pub > /home/git/.ssh/authorized_keys
6. chmod 600 /home/git/.ssh/authorized_keys
7. chmod 700 /home/git/.ssh
8. exit
9. vi /etc/passwd     # change the shell for user git from /bin/bash to /usr/bin/git-shell
1. /usr/bin/git-shell
10. vi /etc/ssh/sshd_config     # ensure that the following are uncommented
1. RSAAuthentication yes
2. PubkeyAuthentication yes
3. AuthorizedKeysFile      .ssh/authorized_keys
11. service sshd restart

Git Notes

• Create repositories

1. cd /home/git
2. mkdir project.git
3. cd project.git
4. git --bare init

• Initially adding to the repository

1. git init
2. git add .
3. git commit -m 'initial commit'
4. git remote add origin git@<SERVER>:/home/git/project.git
5. git push origin master

• Other users cloning the repository

1. git clone git@<SERVER>:/home/git/project.git

References:

1. http://git-scm.com/book/en/Git-on-the-Server-Setting-Up-the-Server

Denyhost 2.6 on CentOS 6.5

Denyhosts is another utility similar to fail2ban. It parses log files to identify potential attacks against SSH services. A clear advantage that Denyhosts has over fail2ban is the synchronisation mechanism since version 2.0[1]. Denyhosts permits communication with a central server to exchange information about denied hosts by other Denyhosts daemons. However unlike fail2ban, it does not modify any firewall (iptables) rules, instead it relies on tcpwrapper and the hosts.deny file to block ssh access. Fail2ban also offers the advantage of monitoring other services and logs, whereas Denyhosts is specific to SSH. There are other utilities which use tcpwrapper such which can handle additional services[2].

To install Denyhost using yum, ensure that the EPEL repository is installed and enabled (refer to old post[3] albeit an older version).

Installation and configuration

1. vi /etc/hosts.allow     # whitelist any trusted hosts and/or networks
2. yum install denyhosts     # install the denyhosts package
3. vi /etc/denyhosts.conf     # change to suit, the file is well documented
4. chkconfig denyhosts --level 2345 on     # set runlevels to start daemon on
5. service denyhosts start    # manually start the daemon
6. tail /var/log/denyhosts    # confirm daemon started successfully

References:

1. http://denyhosts.sourceforge.net/
2. http://www.aczoom.com/blockhosts/
3. http://nkush.blogspot.com.au/2011/10/installing-snort-2912-on-centos-57.html

I wrote a small (single use) script to generate a set of iptables rules from the tcpwrapper hosts.deny file to drop traffic from denied hosts.

for A in `egrep -v '^#' /etc/hosts.deny | tr -d '\t' | tr -d 'ALL:' | grep '[0-9]'`

do

        echo "/sbin/iptables -I -s $A -j DROP"

done

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/

Patching Bash "shellshock" on Apple Mac OS X 10.9.5

Given the recent bash vulnerability disclosure[1] most linux distributions have released patches. Unfortunately Apple still expected users to compile their patches into bash. If you were using Homebrew or Macport you were in better standing and simply had to create symlinks to the patched executables. I've documented the steps I had to take on my Mac desktop.

Compile

1. mkdir bash
2. cd bash/
3. wget http://opensource.apple.com/tarballs/bash/bash-92.tar.gz
4. tar zxvf bash-92.tar.gz
5. cd bash-92
6. cd bash-3.2/
7. curl https://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-052 | patch -p0
8. curl https://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-053 | patch -p0
9. curl https://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-054 | patch -p0
10. cd ..
11. xcodebuild

Verify

1. /bin/bash --version
2. ~/bash/bash-92/build/Release/bash --version

Install

1. sudo mv /bin/bash /bin/bash.vulnerable sudo cp /bin/bash /bin/bash.vulnerable
2. sudo mv /bin/sh /bin/sh.vulnerable sudo cp /bin/sh /bin/sh.vulnerable
3. sudo chmod 0000 /bin/bash.vulnerable
4. sudo chmod 0000 /bin/sh.vulnerable
5. sudo cp ~/bash/bash-92/build/Release/bash /bin/
6. sudo cp ~/bash/bash-92/build/Release/sh /bin/
7. /bin/bash --version

References:

1. https://www.us-cert.gov/ncas/current-activity/2014/09/24/Bourne-Again-Shell-Bash-Remote-Code-Execution-Vulnerability
2. http://www.theregister.co.uk/2014/09/24/bash_shell_vuln/
3. https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/
4. https://access.redhat.com/articles/1200223
5. http://alblue.bandlem.com/2014/09/bash-remote-vulnerability.html
6. http://support.apple.com/kb/HT1222
7. http://lists.gnu.org/archive/html/bug-bash/2014-09/msg00085.html
8. http://lists.gnu.org/archive/html/bug-bash/2014-09/msg00228.html
9. http://lists.gnu.org/archive/html/bug-bash/2014-09/msg00282.html

Microsoft Office 2013 Activation - Error 0x800070005

I have some customers who do not volume license their Microsoft Product and need to activate their Microsoft Office products. This particular customer bought a laptop with Microsoft Office 2013 pre-loaded and purchased a separate Microsoft Office Home and Business 2013 1PC License, however when they tried to activate the license by entering in their product key they kept getting a pop-up error message;

"We're sorry, something went wrong and we can't do this for you right now. Please try again later. ( 0x80070005 )".

The error occurs because the user account does not have appropriate permissions to modify the registry[1]. Thus the activation needs to be run with Administrator privileges[2]. So I right clicked on Word and selected Run as administrator and it activated automatically.

References:

1. http://support.microsoft.com/kb/968003
2. http://techhstuff.blogspot.com.au/2014/01/office-2013-activation-pop-up-with.html