stressfree - security

Transparent Single Sign-On with CAS & eDirectory

David — Thu, 27 Nov 2008 02:41:34 +0000

A few months ago I had a patch accepted by the JA-SIG CAS project to enable this single sign-on (SSO) service to automatically authenticate users who are part of an internal Novell network. The benefit of this is that once a user has logged into their corporate network they do not have to authenticate themselves when they use any of the company's web applications. CAS is a good choice for an SSO solution because it is free, fairly simple to setup and has libraries for integrating with Java and just about every other web language. Also, due to its relative simplicity, many popular web applications support CAS 'out of the box', so it pays to do some checking before reinventing the SSO wheel.

How exactly this transparent authentication mechanism works is a little complicated, but in practice it occurs in a fraction of a second without any intervention. Below is a diagram outlining the actions that take place and a brief description of what happens at each step.

An overview of the transparent authentication process (click to enlarge)

The staff member logs in to the Novell network to gain access to their desktop.
Once logged in the user visits an internally hosted web application. (e.g. CRM, DMS, etc.)
Because the user is not logged in, the web application returns a CAS redirect command to the browser.
The user's browser is automatically redirected to the CAS web service for authentication.
The CAS service detects the incoming I.P. address and performs an LDAP search for this value in the eDirectory.
The LDAP search finds the user's I.P. address and returns their credentials.
CAS creates an authenticated session for the user and returns a one-time use ticket to the browser.
The browser automatically redirects back to the web application and presents the authentication ticket for validation.
The web application checks this ticket against the CAS service. If valid the user's credentials are returned.
The web application creates an authenticated session and returns the relevant HTML content to the browser.

Setting all this up is not too difficult, so long as you carefully follow my instructions on the CAS wiki. The key is understanding what is going on and how the CAS configuration files work to achieve this task. The added bonus is that because this technique uses information stored in eDirectory it works with (pretty much) any Internet browser without any extra client-side software.

A little OSX security tip

David — Thu, 13 Jul 2006 23:04:25 +0000

The administrator designated user is by default the first user created on an OSX system.
In many cases you probably only have one user on the system and in that case this account will have administrator privileges. Whilst administrator privileges are not complete 'root' privileges it does hold enough power to do serious damage.

Most of the so called OSX 'viruses' are actually trojan horses that are executed by an unsuspecting user. The most famous one was a bash script named like an image file and then given a picture icon (so when the user opened it the malicious script was run).

The easiest way to protect yourself from all of this is to create an admin account with administrator privileges and then take away administrator privileges from your everyday users. This will ensure that even if you accidentally run a trojan or just a malicious application it won't be able to cause any real harm (though it would still be possible to delete all your personal data files). Whenever a system modification is about to take place the authentication box will popup asking for the administrator username/password. This is a nice warning message to you that a system change is going to take place and a deterrent to those users who are not supposed to be making system changes (like kids wanting to install games or p2p clients).

It is a nice security blanket and something Apple should really consider doing by default (but I guess they are more concerned about ease of use). If you ever need true root privileges to edit system details (like files in /etc/) open the Terminal and do the following:

su admin [enter]
(change from your account to the admin)
sudo sh [enter]
(open an sh terminal prompt with root privileges, you'll then be able to make any edits you like)

In both cases you'll need to enter the admin password as the sudo command is only available to the user designated as the administrator on the computer. It is possible to edit the sudo configuration file and add a specific non-administrator user to the list of allowed users but it is a lot easier (and a little bit more secure) not to do this.

Parallels on OSX and OpenSUSE 10.1 experimenting

David — Tue, 23 May 2006 20:53:17 +0000

I have been trying out SuSE 10.1 on my iMac with the Release Candidate version of Parallels. Parallels is awesome, there is nothing like being able to play with (and blow away) Linux and Windows at almost full speed directly within OSX. On the PowerPC I have used Virtual PC and the Intel iMac has also gone through Bootcamp but Parallels is far and away a better solution for most tasks (you would not want to run games through Parallels).
From a website design perspective it really eases the testing of html/css in all four major environments (Windows Explorer, Firefox, Linux Konquerer and OSX Safari).

One new default feature in OpenSUSE 10.1 that is really very cool is AppArmor. It makes the task of securing server and client based applications simple through the automatic creation of application-based rules (i.e. Firefox can execute these files, modify these files and access these devices). The SUSE Diary has a nicely written tutorial introducing the application and describing how to easily create rulesets.

Through proper use it can protect systems from zero day exploits and just stop users from doing dumb things. It is definitely a huge feature that will appeal to corporate users, rather than messing around with file permission and access levels directly, you just tell the kernel what you want the application to be able to do and it looks after it from there. In theory these rulesets can be managed centrally from Zen (they are just simple text files) but I don't think Novell have released details on this.

Also the Jem Report have a useful article describing how to get your OpenSUSE 10.1 install up to speed with all the packages you may need (Java, mp3, etc.). OpenSUSE have begun to make this task easier with their 'Add-On' CD but still it is nice to have a single document that lists all the optional features available.

Bug in SUSE 9.2/9.3 Yast Firewall Scripts

David — Sun, 27 Nov 2005 09:09:30 +0000

There exists a bug in the Yast firewall scripts for configuring access to a DHCP server. DHCP requires broadcasting capability but the Yast firewall script does not enable this by default. In order to fix the problem ensure the following two directives are set in the /etc/sysconfig/SuSEfirewall2 script:

FW_SERVICES_EXT_UDP="bootps"
FW_ALLOW_FW_BROADCAST="yes bootps"

Setting these two directives will allow the DHCP server to broadcast its availability to the rest of the network without having to lower your server's firewall.

Border Manager with Linux Howto

David — Mon, 31 Oct 2005 09:13:21 +0000

After some experimenting today I have put together a howto for getting Linux to authenticate to a Border Manager proxy server. If you do not know what that means do not worry but if you do and have tried in the past you maybe very interested to have a read of this tutorial.

Border Manager Authentication with Linux

David — Mon, 31 Oct 2005 07:20:35 +0000

Getting a Linux server or workstation to work nicely with Novell's Border Manager can be very difficult. Novell have recently brought out a Linux version of their clntrust.exe application for Linux workstations (available in Border Manager 3.8 SP4) but this requires Gnome and the Novell Linux Client. If you are running a server (or use a non-Novell supported Linux distro) meeting these requirements can be difficult. Fortunately there is cl4others which authenticates to the Border Manager through simple command line instructions in a far more flexible manner. Documentation for cl4others is pretty sparse so I have written this little tutorial on how to get it set up and running.

This solution is really intended for servers where shell access by normal users is limited as Border Manager authentication is not handled on a per user basis. For web and file servers such a setup is fine but if you require per user authentication to the Border Manager you should probably look at the Gnome/Netware Linux Client/clntrust stack from Novell.

NOTE: For instructions 1-9 you will need to have root privileges.

1. Install ncp for your distribution.
The easiest way to find the rpm is through rpmfind or if you are running SuSE you will find ftp.suse.com has an rpm for your specific version.

2. Extract the cl4others x86 binary and copy it to /usr/bin.
Make sure its permissions are set so that it can be executed by non-root users.

chmod a+x /usr/bin/cl4others

3. Make a directory in /mnt called bordermanager so that you can mount the volume to it.

4. Edit /etc/fstab and add the following entry: (all on one line)

NW_SERVER/NW_USER /mnt/bordermanager ncp defaults,ro,mode=400,uid=root,gid=root,owner=root,ipserver=NW_SERVERIP,
passwdfile=/root/.ncppasswd,multiple 0 0

Replace the following with your network details:
NW_SERVER = Netware BorderManager server name
NW_SERVERIP = Netware BorderManager IP/DNS name
NW_USER = Netware user you will be accessing the proxy as

This mounts the Border Manager volume read-only with all files owned by root with read access to the files only granted to root. This means if one of your server accounts gets compromised (other than root) your Border Manager files will be safe and away from prying eyes.

NOTE: In order for cl4others to work you must have read access to the BorderManager SYS volume. Remember to set a Border Manager access rule for the user you are connecting attempting to access the Internet as.

5. Now create a file for storing the login password to the server:

pico /root/.ncppasswd

Add the following entry:

NW_SERVER/NW_USER:Your Password

Change the file so that it can only be read by root:

chmod og-rwx /root/.ncppasswd

6. Mount the Border Manager volume:

mount /mnt/bordermanager

(This should mount the SYS volume of the BM server

7. If you have a firewall running you will need to open port 3024 for UDP traffic.
For SuSE edit edit /etc/sysconfig/SuSEfirewall2 and add an entry:

FW_SERVICES_EXT_UDP="3024"

Restart the firewall, for SuSE:

rcSuSEfirewall2 restart

8. Now as root start cl4others (I have had mixed results starting it as any other user).

cl4others /mnt/bordermanager &

9. With Yast setup the proxy. You don't need to specify any user just point the proxy to the url of the proxy server. Save the changes. In order for them to take effect you will need to logout of the console and log back in again.

You should be able to access websites now through the Border Manager proxy with any of the Linux accounts.

10 .Test it by downloading an html file:

wget https://www.stress-free.co.nz/sites/default/files/images/whichdoctor.jpg

Hopefully if everything works correctly you should be authenticating and using your Border Manager proxy with Linux.

Useful SSH Keygen Guide

David — Wed, 26 Oct 2005 09:21:32 +0000

This Red Hat document although old concisely explains how to generate and install DSA and RSA keys via SSH. Very handy when you are logging in to a number of different servers for administration purposes.