Tuesday, 22 July 2014

Running Crypt Server on a Mac via Server.app

(Revised for new Django 1.5 version of Crypt Server)
Crypt is software written by Graham Gilbert of pebble.it to provide a FileVault2 escrow solution. That is to provide a secure centralised store for FileVault2 recovery passwords. With this (or similar FileVault2 Escrow solution) the user or authorised administrator can generate the recovery key to get back into a FileVault2 protected machine should the user forget their original code or leave the company. See http://grahamgilbert.com/blog/2013/01/18/crypt-a-filevault-2-escrow-solution/

Crypt consists of two parts, a client part which firstly enforces the use of FileVault2 encryption on the computer and secondly stores the details for the recovery key in the matching Crypt Server. There are other similar solutions available but Crypt has the advantages of being free and not using any external hosted systems.

Whilst (obviously) the client part of Crypt is native Mac software designed to run on Macs, currently the only official documentation for the Crypt Server is aimed at running Crypt Server on a Ubuntu Linux Server. It is certainly possible to run the Crypt Server on an Ubuntu Server with Mac clients by following those instructions and you can even host the Ubuntu Server in a Virtual Machine running on a Mac, e.g. in VirtualBox. However some people might prefer to run Crypt Server natively on an existing OS X Server and this article therefore describes how to achieve this.

Firstly we need to look at the requirements for running Crypt Server -
Apache
Python
VirtualEnv
Django
mod_wsgi
Of these Apache is included on all Macs as is Python, Django can be easily installed but mod_wsgi is only included if you have Server.app installed on top of Lion or Mountain Lion. This article is only aimed at how to get Crypt Server working with Server.app. As Server.app is very cheap if your unwilling to pay even that modest sum then your on your own and perhaps should stick to using the free Ubuntu Server approach. So in terms of this article the full requirements will be -

OS X Lion or OS X Mountain Lion
Server.app
Apache
Python
VirtualEnv
Django
mod_wsgi

I will be differing from the normal Crypt Server install instructions so as to be able to integrate with Apple's Server.app approach. I will be including download links for the configuration files I had to create to achieve this.

Step 1.
Ensure you have Server.app installed and have run it at least once so it can configure itself. As is best practice your server should have a static IP address. The only service in Server.app we will require is the webserver service. We will configure this later. You can if you wish run other services and even other websites on the server you will be using. In order to be able to run multiple websites on the standard port 80, you need to have at least one extra DNS name pointing to this server. So if its main DNS name (A record) is server.example.com you would add an alias (CNAME) and pick a new name for that for example cryptserver.example.com this will allow using a website name of cryptserver.example.com for the website we will be using.

Note: I see no benefit to running Crypt Server on a (web) server accessible from the Internet. In fact I would suggest from a security point of view you should only run it on an internal private server. This does mean client machines will need to be setup either on the internal private network or via a VPN connection to the private internal network.

Step 2.
We will be installing various Django and other python modules. The standard Ubuntu instructions describe using apt-get and pip to install these modules. Neither of these commands is as standard part of OS X however we can install pip very easily by using the built-in 'easy_install' command. So the first command will be

sudo easy_install pip

We now have the pip command installed so we can now use it to install the other modules as follows. First we will install VirtualEnv which allocates the modules to an environment private for the use of Crypt to prevent conflicts with any other python based software which might use different versions of these modules.
(You can check to see if virtualenv is already installed by typing the command virtualenv -–version if it is already installed then you can skip this step.)
sudo pip install virtualenv
We will then create the environment for Crypt.
cd /usr/local
bash
(virtualenv prefers using the bash shell rather than the standard sh shell)
sudo virtualenv crypt_env
cd crypt_env
sudo source bin/activate
sudo pip install django==1.5.3
(The current version of Crypt Server is now written specifically for Django 1.5 and has not been tested with Django 1.6, the above command ensures that Django 1.5.3 is used.)
sudo pip install south
sudo pip install django-bootstrap_toolkit
Step 3.
We will now download the Crypt Server software. This is available here https://github.com/grahamgilbert/Crypt-Server this can in theory be downloaded using a GIT client however I chose to download the ZIP archive listed on the right-hand side and save having to install GIT on my server.

In order to have file paths matching (as much as possible) the original Ubuntu instructions and also to match the settings files I am providing you then need to expand the zip file and move/copy the resulting folder of files as follows. The zip file contains at the top a single folder called crypt-server-master and in that various subfolders. The folder crypt-server-master needs to be renamed crypt and moved into /usr/local/crypt_env/ therefore the path to crypt will become /usr/local/crypt_env/crypt/ I did this in Terminal.app.
Step 4.
We now need to create a wsgi file, the author provides an example one but strangely does not include it in the zip file, so here is one I prepared earlier crypt.wsgi :)

Note: Oops! Just discovered on 22nd July 2014 that the link above to the example crypt.wsgi was pointing to an old incorrect version, I have updated the link to point to a corrected version.

You need to download that file and copy it to /usr/local/crypt_env/crypt/crypt.wsgi
Note: Apple's Server.app will not process python webapps unless they use the file extension .wsgi if you try using the file extension .py they will not work.
Step 5.
We now need to create and configure the settings file for Crypt Server, first we copy the example file.
sudo cd /usr/local/crypt_env/crypt/fvserver/
sudo cp example_settings.py settings.py

We now need to edit settings.py pick your favourite commandline editor, e.g. nano, pico or vi.

You need to set the Administrator email details and the TimeZone for your server. This step is the same as the original Ubuntu instructions. You can therefore look at section 27 here http://derflounder.wordpress.com/2012/12/31/first-look-at-crypt/
Step 6.
We now need to generate the database that Crypt Server will use to store the accounts and FileVault2 recovery keys. To do this we use the following commands.
sudo cd /usr/local/crypt_env/crypt/
sudo python manage.py syncdb

These steps are again the same as the original Ubuntu instructions so you can look at section 28 here http://derflounder.wordpress.com/2012/12/31/first-look-at-crypt/

Note: The user account being created here is only used internally in the database it is not linked in anyway to Open Directory or any other OS X user account. It is used when you login to Crypt Server via a web-browser.

Then we do

sudo python manage.py migrate
sudo python manage.py collectstatic

Again this is the same as the standard Ubuntu instructions so see sections 29 and 30 here http://derflounder.wordpress.com/2012/12/31/first-look-at-crypt/

We have now in theory finished installing and setting up Crypt Server, the remaining steps will be integrating it into Apple's Server.app

Step 7.
Launch Server.app and go to the webserver service. Create a new website using the hostname you chose in step 1. Leave it using the standard port 80 and all IP addresses settings. Click on the Edit button next to Aliases and add a rule to map from a path of /static/ to a folder (any folder) we will be manually editing this later because Server.app does not let you browse to /usr/local where we need it to point to.

You should now quit Server.app for now, do not start the webservice yet. Next we want to manually edit the apache conf file corresponding to the website you have just created. This will be located in /Library/Server/Web/Config/apache2/sites/ it will have a name something like 0000_any_80_cryptserver.example.com.conf the exact name will depend on the host name you are using. You need to edit this in Terminal.app using your favourite editor. You want to set the line beginning with DocumentRoot (the fourth line typically) to the following

DocumentRoot "/usr/local/crypt_env/crypt"

You also want to set the line beginning with <Directory similarly as follows

<Directory "/usr/local/crypt_env/crypt">
Finally we want to edit the line beginning Alias /static/ it will be need the bottom of this file, change it to the following
Alias /static/ "/usr/local/crypt_env/crypt/static/"
We have to do this manually because the files for Crypt Server are not in the normal websites folder location, and because in Server.app you cannot browse and set the location to somewhere in /usr/local/ as this is 'hidden' from view.

Note: Fortunately my experience is that once this change is made manually, Server.app respects it and does not later overwrite it.

The standard Ubuntu instructions tell you to run the website with an additional user account setup specifically for it and that you need to add an additional command to the apache conf file you have just edited above. I could not get those instructions to work with Server.app but fortunately it is not necessary to do so. If you follow the instructions here the website will run successfully with the standard _www account. You do need however to set the ownership of the Crypt Server files to _www so that the standard account can access and modify the Crypt Server database. To do this issue the following command

sudo chown -R _www /usr/local/crypt_env

Step 8.
We now need to setup the extra config files to make the Crypt Server django webapp available as a webapp that will be listed in Server.app and this will allow us to have this webapp run when someone accesses this website. In this article I will merely tell you what to put where and how to then turn it on, but for more details on how you setup webapps in general with Server.app see my other article about this topic available here http://jelockwood.blogspot.co.uk/2013/06/running-django-webapps-with-os-x.html

You need to first place a file called com.crypt.webapp.wsgi.plist in /Library/Server/Web/Config/apache2/webapps/ here is a copy of com.crypt.webapp.wsgi.plist I have made for you. You also need to place a file called httpd_crypt.conf in /Library/Server/Web/Config/apache2/ here is a copy of httpd_crypt.conf for you to use.

You can now open Server.app again. Go to the webserver service and select the website you previously added in step 7 above. Edit the website by clicking on the pencil button, scroll down and click on the 'Edit Advanced Settings...' button. You should now see a list of available webapps, the one you want to enable (tick) is the 'FileVault Escrow Server'. This corresponds to the webapp that the two files you have just installed has defined and this will run the Crypt Server webapp when you access this website. Then click OK and then click Done. You can now start the websites service.


All being well you should now be able to access the Crypt Server in a web-browser at a URL like http://cryptserver.example.com/ depending on what hostname you are using.

Thursday, 27 March 2014

DHCP Option Code Utility 1.1

I finally updated my DHCP Option Code Utility to make it compatible with Mountain Lion. This gets round a change Apple introduced (it had worked fine with Tiger, Leopard, Snow Leopard and Lion).

DHCP Option Code Utility makes it easy for mere mortals to generate the encoded values needed to define DHCP Option Codes for use with Apple's DHCP server. The most common uses of DHCP Option Codes are to define extra fields of information to advertise things like a VoIP phone system or a PXE Boot Server.

I also took the opportunity to add the ability to define 'null-terminate strings' as well as normal strings.

More details along with a download link can be found here.

http://jelockwood.blogspot.co.uk/2013/06/dhcp-server-on-os-x-server.html

[As a belated update to this post - I did sometime ago confirm that version 1.1 also works fine running in Mavericks, and that the DHCP server in Mavericks Server.app still accepts the same encoded values. Version 1.1 can therefore run on 10.4 all the way up to (currently) 10.9.2 and the values work with 10.5 Server through to Mavericks Server.app]

Sunday, 16 March 2014

How to do VPN on Demand for iOS at zero cost despite Apple's best efforts to prevent this

Apple support a feature called 'VPN on Demand' despite the best efforts of both Apple and VirnetX to sabotage this. There are three main requirements in order to implement this.
  1. You need to use a supported VPN client which can either be the built-in Cisco IPSec client or a supported SSL VPN client
  2. You need to use certificates for authentication instead of a pre-shared-key
  3. You need to use a MDM (Mobile Device Management) solution to configure and push the settings to the client device (iOS or Mac) including the VPN on Demand settings
With regards to the VPN client it would seem you can therefore use the built-in Cisco IPSec VPN client on your iOS or Mac client, however as we shall see Apple have made this as difficult as possible to achieve. While some techies may prefer an SSL solution and it is certainly the case that Apple's built-in IPSec client is falling behind with regards to newer security standards e.g. IKEv2, I prefer using the built-in client as there is no extra cost for it, nothing extra needs to be installed and in theory being from Apple themselves it will always be compatible with the current OS version.

Before I go on to how to get this working despite Apple's best efforts, why do we want VPN on Demand? This can be for one of two reasons.
  1. To give access to an internal system that is not directly visible on the Internet and to do so in a way that is as seamless and automatic as possible in order to make things as easy as possible for users
  2. or to have a mobile device always route all traffic via a VPN connection so that its traffic is always protected even when using public WiFi hot-spots. By automating and enforcing this you avoid users forgetting to manually establish a VPN connection
The later reason is becoming more and more important these days with not only the threat of cyber-criminals but also Governments snooping on your traffic. So the goal is to have a compatible VPN server, a compatible VPN client and to configure things so that the VPN connection routes all traffic via it, and for the connection to be established completely automatically.

I could have bought a commercial VPN server from Cisco, Juniper, SonicWall, F5, Aruba or CheckPoint but this would have been very expensive. It is not possible to use Apple's own VPN server solution as it only supports PPTP or L2TP, this is despite the fact that Apple use the open-source Racoon software which does support using Cisco IPSec. I initially looked at compiling and installing the standard unmodified Racoon software in OS X but this would risk causing incompatibilities with Apple's own software so my first effort was to install and configure Racoon in an Ubuntu Linux virtual machine using Virtualbox. Total cost £0

I initially and successfully did so with a pre-shared-key (henceforth referred to as PSK) and then added authentication via LDAP to OpenDirectory running on a Mac server. Total cost so far £0

I then setup a self-signed rootCA and server certificate and client certificate using XCA. Total cost so far £0

Note: Apple's built-in VPN client requires that server certificates have the server name also in a subject alternative name field (SAN). While it is possible to do this using the command line openssl tool or Certificate Assistant in Keychain Access, life is made much easier with XCA.

I reconfigured Racoon to use certificates instead of a PSK and likewise the test iPhone I was using initially running iOS 7.0.4. I then hit the first Apple bug. If you modify a VPN configuration on the iOS device changing it from using IPSec with a PSK to IPSec with a certificate, even though all the details are correctly filled in it will fail to connect. This is because even though you have switched from PSK mode to certificate mode which hides the Cisco 'Group' field, it will still try and use the Cisco 'Group' field. As this is irrelevant for a certificate authenticated connection the VPN server will reject the connection due to being very confused. Nothing on the iPhone will give you a clue about this so I had to dig through debug logs on the Linux server to track this down. To work around this you must delete the old VPN configuration and create a fresh one. Once I had cracked this I was able to successfully get the iPhone to connect and use a certificate and username/password to connect. Total cost so far £0 plus a lot of my hair being pulled out.

At this stage we now have a Cisco IPSec compatible VPN server using a certificate, and the iOS device also using a certificate and the username/password being authenticated via OpenDirectory. In theory we are now ready to setup the MDM system. At this point as a diversion I also got StrongSwan working in another Ubuntu Linux virtual machine using the same certificates as another alternative Cisco IPSec compatible server. I did not get it working with LDAP to OpenDirectory at this point because the standard version 4.5.2 of StrongSwan for Ubuntu 12.04 is too old to enable this, but I did get it working with manually defined username/password details. StrongSwan 5 or later would be able to use LDAP authentication.

I already had a copy of Server.app and hence Apple's ProfileManager so I set it up and was able to successfully enrol my test iPhone and push profiles over the air to it. I was using the same self-signed rootCA, plus an additional server certificate but the same client certificate. So far however I am unable to get ProfileManager to push this certificate to the iPhone. As far as I am concerned there is nothing wrong with the certificates as the same client certificate works when emailed to the iPhone directly, and works for the VPN connection from the iPhone, and what's more works when pushed over-the-air from the free Cisco Meraki Systems Manager MDM solution. I therefore gave up on ProfileManager and switched to the free Cisco Meraki Systems Manager. I again enrolled the iPhone and created a profile in Systems Manager to push the client certificate to the iPhone and to also push a VPN configuration set to use that client certificate with a Cisco IPSec connection. This worked with a another major issue still to be resolved as we will see. Total cost so far £0 and the loss of some more hair.

Note: This certificate problem with ProfileManager may be a second Apple bug.

Having now successfully got a Cisco IPSec compatible VPN server working with certificates and successfully setup an MDM solution to push the settings to the iPhone I tested manual connections to the VPN server. This worked and I was able to enter and save and use the same OpenDirectory user credentials. However when I turned on VPN on Demand as part of the profile being pushed to the iPhone I discovered that the iPhone would not save the password, it would not let me edit the VPN configuration, there was also no way in the profile to define the password. As a result every time the VPN connection was told to connect I was asked again to re-enter the password. It turns out this is how currently it is 'supposed' to work. This makes it in not only my but many other peoples opinions an unusable solution for VPN on Demand. I personally consider this to be yet another Apple bug. (In Microsoft speak this would be described as a feature.)

Note: My Ubuntu Racoon VPN server had been configured to allow clients to save passwords and this had already been proven to work with manually configured VPN settings on the same iPhone.

I tried various options like an account with an empty password, not entering a username or %short name% in the VPN profile, even creating and manually editing a mobileconfig file with Xauth disabled. None of these options worked. It was beginning to look like I would have no choice but to pay for a commercial SSL VPN server.

I had when initially investigating this from the angle of 'how to do you save the password' found some discussions from other equally annoyed and frustrated Apple customers regarding this but none of these had listed a solution. By now I had gone as far as asking for a quote for an SSL VPN solution, however I did then find mention of something called Xauth-noauth for StrongSwan.

See http://serverfault.com/questions/476033/strongswan-without-password-on-ios

I found this when I switched to searching for how to connect without a username and password. As you can see other people have hit the same problem as I had. Fortunately someone (ecdsa) had come up with a solution which was to write a special Xauth module for use with StrongSwan which effectively ignores the Xauth details leaving just the certificate authentication active. With this the iPhone no longer asks for a password as it has not been asked by StrongSwan for one.

Note: There are normally two stages to authenticating a VPN connection, the first stage is either via a PSK or by exchanging and verifying SSL certificates, the second stage is eXtended AUTHentication or Xauth and is where the username and password are normally exchanged and verified.

I therefore dusted off my StrongSwan configured virtual machine. Unfortunately this Xauth-noauth module is only for StrongSwan 5.0.2 or later and as previously mentioned the standard version of StrongSwan for Ubuntu 12.04 is the much older and substantially different 4.5.2. As a pre-built StrongSwan 5 or later was not available for Ubuntu 12.04 I had to download the source code for StrongSwan 5.1.2 and build it myself along with all its dependencies. I was however able to do this and install it and thankfully it did exactly what was wanted and no longer asked the iPhone for a username and password. I was therefore able to use the VPN profile from the Systems Manager MDM with VPN on Demand enabled and the iPhone was now able to repeatedly connect without nagging me each time for the password! Yippee! Total cost so far - drum roll please - £0

Building StrongSwan 5.1.2 from scratch

First install dependencies

sudo apt-get install libpam0g-dev
sudo apt-get install libcurl4-openssl-dev
sudo apt-get install libcurl4-nss-dev
sudo apt-get install libldap2-dev
sudo apt-get install libgmp3-dev

Then download and uncompress source code

wget http://download.strongswan.org/strongswan-5.1.2.tar.bz2
tar -xjvf strongswan-5.1.2.tar.bz2

Then configure what modules to enable and compile and install (the configure command is all on a single line)

cd strongswan-5.1.2

./configure --prefix=/usr --sysconfdir=/etc --enable-curl --enable-ldap --enable-pkcs11 --enable-md4 --enable-openssl --enable-ccm --enable-gcm --enable-farp --enable-eap-identity --enable-eap-aka --enable-eap-aka-3gpp2 --enable-eap-md5 --enable-eap-gtc --enable-eap-mschapv2 --enable-eap-dynamic --enable-eap-radius --enable-eap-tls --enable-eap-ttls --enable-eap-peap --enable-eap-tnc --enable-xauth-eap --enable-dhcp --enable-charon --enable-xauth-pam --enable-xauth-noauth

sudo make
sudo make install

Here is the /etc/ipsec.conf I used for StrongSwan 5

# basic configuration

config setup
uniqueids=never

# Add connections here.

conn %default
authby=rsasig
leftrsasigkey=%cert
rightrsasigkey=%cert
keyingtries=1
keylife=60m
ikelifetime=240m

conn ios
keyexchange=ikev1
left=%defaultroute
leftsubnet=0.0.0.0/0
leftfirewall=yes
leftcert=serverCert.pem
right=%any
rightsubnet=10.0.1.0/24
rightsourceip=10.0.1.0/24
leftauth=rsa
rightauth=rsa
rightauth2=xauth-noauth
ike=aes128-sha1-modp2048,3des-sha1-modp1536
esp=aes128-sha1-modp2048,3des-sha1-modp1536
rekey=no
reauth=no
dpddelay=10
dpdtimeout=30
dpdaction=clear
auto=add

The last step was tweaking the rules for VPN on Demand. Both Apple's ProfileManager and Cisco Meraki System Manager have very limited options for VPN on Demand that can be configured in their GUI interfaces. In fact they are so limited that effectively they can only accomplish option 1 I listed at the beginning which is to automate providing access to an internal server, and not to automate connecting via VPN all the time for all traffic. Fortunately Apple do document how to manually configure this. Yes I know it is a big shock but Apple does still provide some useful documentation sometimes.

See page 40 https://developer.apple.com/library/ios/featuredarticles/iPhoneConfigurationProfileRef/iPhoneConfigurationProfileRef.pdf

I therefore used iPhone Configuration Utility to build a mobileconfig profile containing the client certificate and the VPN settings, I then exported it and edited this as per Apple's documentation above to use the URLStringProbe option to check for the ability to access a URL on my VPN server and if found to be true to trigger a VPN connection. This might be opposite of what you would expect but it is the correct choice to force a connection always to happen and by doing it this way if my server is down the URL test will fail and VPN on Demand will not be activated and the device will still be usable although not protected by a VPN connection. You therefore need to use a URL that is accessible without a VPN connection. I then pushed this out to the iPhone using Systems Manager. With this installed my iPhone now as soon as it gets an Internet connection will automatically trigger a VPN connection which will route all traffic over it and all without any user interaction being needed. Grand total cost a massive £0!

As a final aside, all the above should apply equally to using Mac clients, testing this shall be my next project.

Links to Resources

VirtualBox or ESXi 5.1
Ubuntu 12.04 Server
StrongSwan 5.1.2
Cisco Meraki Systems Manager
XCA
iPhone Configuration Utility 3.5 for Mac

Saturday, 15 March 2014

Deploying Sophos Anti-Virus on a Mac network

Sophos have provided a Mac version of their Anti-Virus software for a long time and uniquely also used to provide a Mac tool for providing an internal corporate deployment and update service for this.

This tool was called 'Sophos Update Manager' (SUM) it did two things. Firstly it let you build a pre-configured installer package which would include the settings telling Mac clients how to get updates, and secondly it would automatically update this install and folder, it would also put in this folder new anti-virus definitions.

You would therefore normally have this folder on a Mac file server and have the installer package and hence client Macs configured to get updates from this folder. You could also define Sophos' own servers as the backup - secondary source for updates.

This solution was therefore comparable with Sophos' own Windows tools of in the past Sophos Library Manager and now Sophos Enterprise Console, and also comparable with equivalent Windows only tools from McAfee and Symantec. The big difference being that no-one else makes a similar Mac tool for Mac only environments.

In more recent times Sophos have failed to update SUM and officially it only runs on OS X 10.7 (Lion) or older, it did however continue to be able to distribute updates for Sophos Anti-Virus 8 for Macs even if client Macs were running Mountain Lion. However not only does SAV8 not officially support running on OS X 10.9 (Mavericks) SAV8 is also due to be discontinued in April 2014.

 It is therefore necessary to move all Macs to SAV9 by April.

SUM does not support SAV9 and so far Sophos have shown no interest in providing an updated version. Sophos do provide a standalone installer for SAV9 which will automatically if needed uninstall SAV8 and replace it with SAV9, and this installer can be pre-configured with the credentials needed to get updates directly from Sophos' servers.

See http://www.sophos.com/en-us/support/knowledgebase/119744.aspx

You might think therefore that all one needs to do is download the standalone SAV9 installer, pre-configure it as per the above article and then deploy it to all your Macs. Unfortunately the standalone SAV9 installer is not a standard Apple installer type package, it is an application that itself does the installation. This means it cannot be deployed using standard Apple administration tools like Apple Remote Desktop, Casper, or Munki. All these tools will merely see it as an application and at best just copy it to a client Macs Applications folder where it will just sit and do nothing.

As a reminder, the SAV8 installer was a standard installer package and after being configured using SUM could be deployed using standard Mac tools.

What was really annoying is that as someone who has also managed both Windows only and mixed environments with Sophos I happen to know that SAV9 when managed by Sophos Enterprise Console on a Windows server does still come as a standard Apple installer package.

Sophos technical support were not a lot of help regarding this and frankly seem pretty clueless about how Mac software is deployed in an enterprise environment. They suggested switching to Sophos Cloud. Sophos Cloud can be thought of as being a cloud based version of Sophos Enterprise Console in that it lets you manage settings and view the status of the client computers running Sophos Anti-Virus, and unlike the Sophos Enterprise Console can be accessed via a web-browser on a Mac. However the client installer used with Sophos Cloud for Mac is still the same custom application and not a standard Apple installer package, as such it still cannot be deployed using standard Mac administration tools.

As an aside the free home edition of Sophos Anti-Virus for Mac is also based on the same custom application.

So at this point the only official options were to buy a Windows Server just so you could run Sophos Enterprise Console, something that would have cost a fortune even if you run it in a virtual machine as you not only would have to buy Windows Server but also all the Client Access Licenses for all your Macs, or you would have to go round each and every Mac client and manually run the standalone installer application with the huge administrative overhead this entails and the often frequent difficulty to get access to machines.

Clearly this had moved Sophos from being by far the most friendly Mac solution thanks to SUM, to being actually worse than most since at least McAfee with their ePO system use standard Apple installer packages.

I raised this issue in some user forums including here https://jamfnation.jamfsoftware.com/discussion.html?id=9785 and also pursued this matter directly with another contact I had at Sophos. Via that contact I was able to find out that hidden inside the Sophos standalone installer application was a command line tool called InstallationDeployer and that this tool could be scripted and run via a standard Unix shell script. With this information which is still not on the Sophos website, it then immediately became obvious that it would be possible to build an Apple installer package containing the Sophos standalone installer application and a post-install script which would automate running the Sophos standalone installer.

After updating the above forum with this information I had started building such an installer package but Richard Trouton beat me to it and to be honest his solution is cleaner than the one I was building. Richard has written this up here http://derflounder.wordpress.com/2014/02/20/deploying-sophos-anti-virus-for-mac-os-x-9-x/ however Richard's script only works with the free home edition of Sophos Anti-Virus for Mac which would have been the only version he had access to. I have therefore taken his script and enhanced it so that it works for both the free home edition and also the paid-for official SAV9 standalone installer.

My updated version of the script can be accessed here http://pastebin.com/uRT2VMw9

Note: The free home edition is not authorised for business use, only for home use.

So if you have no Windows server and need to mass deploy Sophos Anti-Virus 9 for Mac the best solution is as follows.
  1. Download the SAV9 standalone installer
  2. Pre-configure it with your Sophos update credentials as per the Sophos article
  3. Convert it to an Apple installer package as per Richard's article but with my version of his script
  4. Deploy it using your favourite tool - ARD, Casper, Munki, or other
You don't need to keep building new versions of the installer as once installed the client Macs will then update themselves directly from the Sophos servers.

Tuesday, 5 November 2013

mod_xsendfile and OS X Server.app

mod_xsendfile is a small Apache2 module that processes X-SENDFILE headers.

It makes it much quicker to download large files from a webserver and allows them to be streamed directly from disk without having to be first read in to memory.

This module is not included in OS X as standard but is included in OS X Server.app. You might want to use this module with websites you have written yourself or with web systems you have downloaded and installed. I recently wanted to install and test the free open-source MunkiServer project which uses this module, I however encountered an issue doing so which I am documenting here so anyone else using OS X Server.app and mod_xsendfile can understand and solve if they also encounter it.

I initially found that the Apache web-server in Server.app was crashing repeatedly when I tried loading the MunkiServer web application. I eventually tracked this down to when MunkiServer tried loading mod_xsendfile and I determined it was when MunkiServer tried using the command

XSendFilePath /path/to/files

This command was added in mod_xsendfile version 0.10 it turns out that the version of mod_xsendfile included in Server.app does not include this command because it is an older version and therefore only supports the previous command of XSendFileAllowAbove instead. This command was no help for MunkiServer. The solution is to download the current version, compile it in Terminal using the command

apxs –cia mod_xsendfile.c

which requires you to have XCode installed and then configure Apache to load it instead of the version included in Server.app.

It seems the majority of MunkiServer users either don’t run it on a Mac or don’t run it using Server.app and either option means they typically always download the latest version and compile it.

You can download the latest mod_xsendfile from https://tn123.org/mod_xsendfile/

Sunday, 28 July 2013

FileVault 2 Escrow Servers

What is FileVault?
FileVault is Apple’s solution for securing a users files by encrypting them. The original version of FileVault (FileVault 1) was introduced with Mac OS X Panther (10.3) and continued through to Mac OS X Snow Leopard (10.6). FileVault 1 worked by storing the users home directory inside an encrypted disk image file, the rest of the contents of the hard disk where not encrypted. Later on security was further improved with the introduction of ‘Secure Virtual Memory’ whereby the contents of virtual memory stored on the hard disk was also encrypted, it was still the case that the rest of the hard disk was not encrypted.
sp_accounts_security[1] 

FileVault 1 however had two major problems, firstly it had a reputation for reliability problems potentially losing all your personal files (unless you had a backup), and secondly because the entire hard disk was not encrypted it was possible for either the user to mistakenly store files outside their encrypted home directory, or for misbehaving applications to do so. As a result FileVault 1 was never accepted as being adequate for use by Governments or Enterprise customers especially in regulated industries like finance, law, and medicine. As a result Government and Enterprise customers would instead use products meeting the FIPS 140-2 security standard such as CheckPoint Full Disk Encryption, PGP Whole Disk Encryption, Sophos SafeGuard, or WinMagic SecureDoc Disk Encryption (all of which are available for both Mac and Windows computers).

Apple therefore with OS X Lion (10.7) introduced FileVault 2, this encrypts the entire hard disk like its competitors and can also encrypt external drives as well (for storing your backups). FileVault 2 in OS X Lion eventually gained FIPS 140-2 certification itself, and OS X Mountain  Lion also gained FIPS 140-2 certification in July 2013. FileVault 2 is regarded as being far more reliable than FileVault 1 and as it now encrypts the entire hard disk there is no danger of files accidently leaking outside the protected area.

What is Escrow?
With all encryption products you need to ensure you can still access the contents by knowing the correct security key. If you lose the key you lose the ability to access the files. Therefore most if not all such encryption products provide a means to generate a ‘recovery’ key if you lose your passcode either by a user being forgetful or a user leaving and you then wanting to gain access. FileVault 2 is no exception to this and Apple have provided such a mechanism. This is where the term Escrow comes in, a third-party stores (securely) the information needed to generate a recovery key. The rest of this article discusses the alternatives available to do this in-conjunction with Apple’s FileVault 2 software.

1. Using your Apple ID to store the recovery key
Many people may forget that Apple provide a means when you enable FileVault 2 to at the same time store your recovery key on Apple’s servers in your Apple ID account and this service is completely free of charge. This does count as an Escrow service with Apple acting as the third-party.
See http://support.apple.com/kb/ht4790
HT4790_StoreKey----en[1]
However some users may be unhappy with the fact another company is storing this information. It is also not designed to make it easy for an IT administrator to manage multiple computers.

2. Cauliflower Vest
This is free open source software written by Google. It allows setting up a central store of recovery keys with secure access making it much more suitable for an IT administrator to manage. It can also make the use of FileVault 2 compulsory ensuring the laptop is secure.
See http://google-opensource.blogspot.co.uk/2012/02/cauliflower-vest-end-to-end-os-x.html
See http://code.google.com/p/cauliflowervest/
1330528122_mgpic_final[1]
However it uses Google’s App Engine servers to store the information so again some users may not be happy with the thought someone else is storing their security keys.

3. Casper Suite
JAMF Software produce an extensive suite of management software for managing both Macs and iOS devices. This includes the ability to manage FileVault 2 both to enforce its use (like Cauliflower Vest) and to store the recover keys.
See http://www.jamfsw.com/solutions/filevault/
Unlike the previous two solutions as Casper Suite runs on your own servers you don’t have to worry about the possibility of a third-party having access to your security keys. This is however a commercial solution so you do have to buy the Casper Suite software and licenses.

4. Crypt Server
This is another free open source solution written this time by Graham Gilbert of pebble.it. It allows you to run your own server internally and securely store the recovery keys. It includes a matching client component so that like Casper Suite and Cauliflower Vest you can enforce the use of FileVault 2 encryption and automate the storing of the recovery keys.
See http://grahamgilbert.com/blog/2013/01/18/crypt-a-filevault-2-escrow-solution/
See https://github.com/grahamgilbert/Crypt-Server 
home[1]
Above is a page from the server web administration interface, below is what the client sees when they setup a computer.
Crypt-Screenshot[1]
Crypt Server was however originally written to run on a Linux Ubuntu Server. I have however worked out how to run it on an OS X Server using Apple’s Server.app software and instructions on how to do this are available here -
http://jelockwood.blogspot.co.uk/2013/07/running-crypt-server-on-mac-via.html

Monday, 24 June 2013

Mountain Lion gets FIPS 140-2 approval at last

Mountain Lion was released in July 2012, its encryption code was effectively identical to that in Lion. As is usual Apple still had to apply for a new certification for Mountain Lion and did so. However the wheels obviously grind very slowly and it was only on June 14th 2013 that Mountain Lion finally received FIPS 140-2 certification.

This should now make it possible to use Apple's built-in FileVault2 encryption in organisations that require a FIPS 140-2 certified product. I myself have been using PGP instead due to this issue.

Anyone interested in doing this should visit the following two links

http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2013.htm (search for Apple)
http://support.apple.com/kb/ht5396