Showing posts with label ssh. Show all posts
Showing posts with label ssh. Show all posts

28 June 2013

Samurai Notes



Samurai Web Test Framework

The Samurai Web Test Framework is an excellent starting place to learn the intricacies of  security testing of web-based systems. 

Because of the nature of the content on the system, it is locked down in various ways to remain walled off. 

Here are notes on how to gain remote access to the system.

SSH Access

The remote ssh sessions will be refused with the message “no hostkey alg”. 

On Samurai, run the following commands:

# ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key
# ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key

24 June 2013

Dual factor SSH: Google Authenticator, SElinux, and CentOS

 

Intro

Dual factor authentication often requires the purchase of RSA tokens or some similar physical piece of hardware. Even the much touted Yubikey cost $25 a unit. Google Authenticator is quickly becoming one of the new standards for implementing a dual factor solution using a smart phone instead of a purchased token. 

The Google Authenticator PAM allows time-based dual factor authentication on a Linux machine. The installation is documented on the Google Authenticator wiki in a couple of lines, but little is said about implementation with SE Linux enabled. Most other blogs simply state, "Turn off SE Linux", which seems less than ideal. 

Here is an end to end set up for Google Authenticator on Cent OS 6.4.  


Installation - Method 1 (via RPM)

Easy, but not recommended.

Enable the EPEL repository, if not already enabled. 

For example: 

# wget http://mirror.symnds.com/distributions/fedora-epel/6/i386/epel-release-6-8.noarch.rpm
# yum localinstall epel-release-6-8.noarch.rpm

Then install via yum. 

# yum install google-authenticator

The downside of this is the RPM is most likely not the most up to date.

Installation - Method 2 (via make) 

Not so difficult and recommended.

Make sure you have pam-devel (yum install pam-devel) installed. Then clone latest from Google. 

# git clone https://code.google.com/p/google-authenticator/

Change into the build directory. 

# cd google-authenticator/libpam/ 

Then do the build. 

# make && make install
 

Basic Server Set up

Two places have to be modified, the sshd configuration file and the PAM configuration file. 

In /etc/ssh/sshd_config ensure the setting match below: 


PasswordAuthentication yes
ChallengeResponseAuthentication yes
#ChallengeResponseAuthentication no

UsePAM yes


In the PAM file /etc/pam.d/sshd, a new line will need to be added at the top: 

auth   required        pam_google_authenticator.so

Restart the sshd daemon: 

# service sshd restart

That is it for the server. 

If, however, SELinux is enabled, additional configuration is needed (see below). Otherwise, an error like this will appear in /var/log/secure: 


Failed to update secret file "/home/${USER}/.google_authenticator"
error: PAM: Cannot make/remove an entry for the specified session


Basic User Set Up

First, install the Google Authenticator on your mobile phone.

Next, on the Linux system run the Google Authenticator command: 

# google-authenticator

Read and answer the yes/no questions. After setup, the user will have a .google_authenticator file in the home directory. 

The command will also create a URL and/or a QR code. With Google Authenticator on your mobile phone, capture the QR. It will create a new account automatically.

This has to be done for each user.


Advanced Setup for SELinux

Google Authenticator and its incompatibility with SELinux is known. But there is little agreement on how to fix it. Some recommendations include compiling and rolling new SE policies. Others recommend disabling SELinux. But there is a straight forward workaround. 

First, in the PAM file /etc/pam.d/sshd, modify the pam_google_authenticator line: 

auth   required        pam_google_authenticator.so nullok secret=/home/${USER}/.ssh/.google_authenticator

This does several things. First "nullock" tells PAM to accept null if the user does not have the Google Authenticator configured. In other words, users who don't have dual-factor configured can still log in. Next, the "secret= ..." gives PAM access to the needed key file, even with SELinux installed, just as it does for key-based SSH sessions. 

Second, move the
.google_authenticator to the .ssh folder for the user -- it may need to be created. It is best to do this as the user.

# mkdir /home/${USER}/.ssh 
# mv /home/${USER}/.google_authenticator /home/${USER}/.ssh/.google_authenticator


Restart the sshd daemon: 

# service sshd restart

That is it for the SELinux. 


Expected Behavior

  • Users with dual factor configured will need a verification code and a password. 
  • Users with no dual factor configured will only need a password. 
  • This configuration will not work with key-based ssh configurations. They will bypass the dual factor process.


14 May 2011

A secure, consistent SVN mirror

Using svnsync, ssh+svn, and post-commit hooks


Many svn mirror implementations take the hammer approach by running a cron job every minute to poll for changes. Bang, bang, bang and any change is pushed to a mirror via svnsync. But do you really want cron pounding away at subversion all the time and pulling changes out like a rusty nail?

Hammers and mirrors do not work well together.

The more elegant approach is to set up post-commit hooks. These capture every change as it happens. Unfortunately getting this to work is frustrating. Many administrators can’t get the post-commit to do anything at all; the post-commit “never runs” with no hint of failure and no logged errors.

Post-commit configuration usually fails due to permission problems. Each ssh+svn user comes in as themselves when a commit is being made, but that user often does not have permissions to a) run the post-commit hook and/or b) run commands in the post-commit script.

So here is how to both set up the mirror and set up the permissions so that post-commit can run.
This installation assumes CentOS/Redhat/AWS platforms and an already working svn repository where users access via ssh+svn.

Set up the svn mirror (aka target)

On the target system, create a user that will have exclusive write access to the mirror, traditionally this username is svnsync.
useradd svnsync
As the svnsync user, replicate the file system location of the original subversion repository. Then create the blank repository.
svnadmin create --fs-type=fsfs /repos/svn/myrepos
Normally when creating an SSH subversion repository, it is necessary to adjust the umask to 002 and create a group that will have write access. But in this case, only this user will have write privileges, so there is no need to create a subversion group, nor to adjust umask.

Then, if not already done, generate the ssh keys needed for the svnsync user to access the blank repository via SSH. For added security, add the following string to lock down the public key:
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="/usr/bin/svnserve -t --tunnel-user=svnsync"
On the source system, add the svnsync user and the private SSH key. This user will read from the source and push changes to the target.

If a bit paranoid, a secondary check can be put on the target repository which ensures only the svnsync user can make a change in the form of a pre-revision change hook. This will prevent a non-SSH user from accidentally making commits.
cp -p pre-revprop-change.tmpl pre-revprop-change
Adjust the script to ensure only the svnsync user can effect a revision** change:
USER="$3"
if [ "$USER" = "svnsync" ]
then exit 0
fi
echo "Error: only the svnsync user can make changes" >&2
exit 1
Then enable the script: chmod 755 pre-revprop-change

Populate the mirror

Now the mirror is ready to be initialized and synchronized (a two step process). On the source system first initialize the mirror, which locks the target to the source repository. The init flag uses the <destination> <source> format:
svnsync init –username svnsync \ svn+ssh://svnsync@<mirror_server>/repos/svn/myrepos \ file:///repos/svn/myrepos
If this fails with the error “svnsync: Session is rooted”, double-check the SSH key. It likely has the repository path in the key: -r /repos/svn/myrepos. Remove this to generate a successful initialization.

The target is now locked to the source. Time to push the repository data. On the source svn server, synchronize the data:
svnsync synchronize --username svnsync \ svn+ssh://svnsync@<mirror_server>/repos/svn/myrepos
This may take some time, depending on the number of revisions in the repository and whether the mirror is on the local LAN or remote, such as on Amazon Web Services.

Congratulations, the source repository now has a read-only mirror.

However, maybe the network went down or something else happened during the first sync and now the re-sync attempt produces this error:
Failed to get lock on destination repos
Run the propdel command to remove the lock and restart the sync:
svn propdel svn:sync-lock --revprop -r 0 \ svn+ssh://svnsync@<mirror_server>/repos/svn/myrepos/
That should allow the sync to pick up where it stopped before.

Automate the mirror

Here is where the magic comes in. When a user makes a commit to the source repository via SSH, that process has the permissions of that user, not as root or some svn service. Unfortunately, the mirror only accepts writes from the svnsync user, not from everyone. This is where sudo comes in to solve the problem.
1. Set up SUDO privileges
On the source server, for SSH+SVN access, every user is already a member of a OS group that has read-write access to the repository. These group members must be given the ability to a) become the synsync user and b) run a single command. Fire up visudo and add this line:
%svngroup ALL=(svnsync) NOPASSWD: /usr/bin/svnsync
This allows all members of the svngroup (%svngroup) the ability to switch to the svnsync user (ALL=(svnsync)) without a password prompt (NOPASSWD) and run a single command (/usr/bin/svnsync).

Of course, users won’t be doing this manually. They won’t even know they have this “privilege”. If the SSH keys are locked down properly, users can’t log onto the subversion server, much less execute sudo commands remotely.

Instead, what this sudo change does is give the post-commit hook scripts the ability to push any changes to the mirror as the svnsync user.
2. Set up the post-commit scripts
Post-commit scripting is well documented, but without the sudo setup and sudo commands in the script, the post-commit scripts will not execute in a SSH+SVN environment.

On the source server, in the hooks folder, copy post-commit.tmpl and post-revprop-change.tmpl scripts:
cp –p post-commit.tmpl  post-commit
cp –p post-revprop-change.tmpl post-revprop-change
Add the svnsync commands to the post-commit script:
REPOS="$1"
REV="$2"
sudo -H -u svnsync /usr/bin/svnsync sync --non-interactive –-username svnsync svn+ssh://svnsync@<mirror_server>/repos/svn/myrepos &
exit 0
And also a slight variant to the post-revprop-change script:
REPOS="$1"
REV="$2"
USER="$3"
PROPNAME="$4"
ACTION="$5"
sudo -H -u svnsync /usr/bin/svnsync sync --non-interactive --username svnsync copy-revprops svn+ssh://svnsync@<mirror_server>/repos/svn/myrepos "$REV" &
exit 0
If desired, something like >> /tmp/mirror-commit.log 2>&1 can be added in front of the ampersand so the mirror commits can be monitored.

Finally, enable the scripts with a chmod 755.

Congratulations. You now have an elegant, automated svn mirror!