Bensoftware Blog

Secure Sockets Layer (SSL) is a cryptographic protocol that provides secure communications on the internet. It uses two keys to encrypt data: a public key and a private key. URLs that require an SSL connection start with https:// insead of http:// and operate on port 443 instead of 80 by default. SSL increases security as it makes it impossible for someone intercepting the stream of data to decode any information from it.

SecuritySpy does not have built-in support for SSL, however Mac OS X comes with Apache, a fully-featured and powerful web server, that can be used to set up the secure communication between the internet and SecuritySpy. In this way, Apache will be acting as a secure “reverse proxy” web server for SecuritySpy. This post describes how to set this up.

These instructions describe how to set up SSL using “self-signed” certificates. This allows you to get everything up and running, however for a proper installation you should ideally obtain a certificate from a Certificate Authority (such as Verisign or Thawte). A Certificate Authority is a trusted entity that confirms to whomever is connecting to your web server that you are who you say you are. This is only really applicable for web servers available to the general public, and a self-signed certificate is appropriate for when the server will be accessed by you or your employees or agents, as in this case there is no doubt about the server’s authenticity.

Although we have made every effort to make this guide easy to follow, this is a complex setup that requires use of the Terminal and editing of Apache configuration files, so is not for the novice user. This guide assumes that you have already set up the web server feature of SecuritySpy and are familiar with concepts such as dynamic DNS, port forwarding, and IP addressing on local networks.

For editing the configuration files, we highly recommend TextMate – this is a flexible and user-friendly editor that will make editing these files easy. You will also need to use the Terminal application, which is in your Utilities folder within your Applications folder.

These instructions are suitable for Mac OS X versions 10.5 through 10.8.

Step 1: Create a Certificate Authority (CA) certificate

In Terminal, type (or copy-and-paste) the following commands, each followed by a return:

mkdir ~/Documents/myssl
cd ~/Documents/myssl
openssl genrsa -des3 -out ca.key 1024
openssl req -new -x509 -days 3650 -key ca.key -out ca.crt

These commands create a myssl folder in your Documents folder, a RSA key file, and a Certificate Authority certificate. You will be asked for some details about you (as the certificate authority), and for a passphrase – use something simple and memorable; it doesn’t have to be secure.

The Terminal output for this step will look something like this:

Step 2: Generate a private key for the web server

In Terminal, enter the following commands, each followed by a return:

openssl genrsa -des3 -out server.key 1024
openssl req -new -key server.key -out server.csr

This creates a server key file.  It will ask for some details about you (as the server administrator). The vital thing here is, when it askes you to enter the Common Name, you must enter the host name (or IP address) of your server as a client would connect to it over the internet. For example, if you have a Dynamic DNS name set up for accessing your server over the internet called myserver.viewcam.me, this is what you enter here. It may also ask you for a challenge password and optional company name - just leave these blank.

The Terminal output for this step will look something like this:

Step 3: Sign the server key with your CA certificate

You need to download the latest mod_ssl, locate the sign.sh file from the pkg.contrib folder, and place it in your ~/Documents/myssl folder.

Back in the Terminal, enter:

chmod +x sign.sh
./sign.sh server.csr

You will be asked for the passphrase for the ca.key file that you created above. For the questions Sign the certificate? and commit?, type y and enter.

Step 4: Remove the passphrase requirement from the server key file

This step is required so that Apache can read the private key without you having to manually start Apache from the command line with the passphrase every time you need to enable the web server. In Terminal, enter:

cp server.key server.key.original
openssl rsa -in server.key.original -out server.key

You will be asked for the passphrase that you initially specified for the server.key file.

Step 5: Configure the Apache web server for SSL

Now we have all the files needed to enable SSL in Apache. In the Finder, choose Go to folder from the Go menu and type /etc/apache2/ – this is where all the Apache configuration files reside:

Firstly, copy the server.crt and server.key files from ~/Documents/myssl/ into this folder.

Next, open the httpd.conf file in TextMate (before doing this it is good practice to create a backup of this file before making any changes, in case you need to revert to it). These are the changes you need to make to this file:

• Locate the ServerName parameter and set it to the external host name (or IP address) of your server. Remove any # character from the start of the line

• Locate the line Include /private/etc/apache2/extra/httpd-ssl.conf and remove any # character from the start of this line

• Locate the line LoadModule ssl_module libexec/apache2/mod_ssl.so and remove any # character from the start of this line (Mac OS X 10.7 and above)

• Save the file (TextMate will ask if you want to overwrite the existing file, which you do)

Finally, open the httpd-ssl.conf file within the extra directory (again you should make a backup first). Make the following changes:

• Locate the ServerName parameter and set it to the external host name (or IP address) of your server, and remove any # character from the start of the line

• Locate the SSLCertificateFile parameter and set it to “/private/etc/apache2/server.crt” (with quotes), and remove any # character from the start of this line

• Locate the SSLCertificateKeyFile parameter and set it to “/private/etc/apache2/server.key” (with quotes), and remove any # character from the start of this line

• Scroll to the bottom of the file, and just above the “</VirtualHost>” tag, add these two lines:

RewriteEngine On
RewriteRule ^/(.*) http://127.0.0.1:8000/$1 [P]

• Save the file

Step 6: Test it

Everything is now set up. Go to System Preferences, click on Sharing, and enable Web Sharing –  this starts the Apache web server. If web sharing was already enabled, you need to disable it and then enable it again to restart the web server (if it does not start, check the Console for errors – probably there is some mistake in the configuration files you edited above). Make sure SecuritySpy is open, and then open Safari and enter:

https://127.0.0.1/

Note that this URL starts with https and not http. The IP address 127.0.0.1 is what is called the “loopback” address that refers to “this computer”. You should get a warning about the certificate being invalid because of a host name mismatch. This is because the address that you are using to access the server (127.0.0.1) is different from the address that you specified in the server certificate. This error will not occur when accessing the web server from the internet using the proper host name (although the client will get a warning that the certificate was signed by an unknown authority). Simply click the Continue button to ignore the warning and enter the secure site. You should see the SecuritySpy web interface with a padlock to the left of the address bar (or the top right of the Safari window, depending on your version of Safari), indicating a secure connection.

Step 7: Set up port forwarding

The final step is to set up port forwarding in your router to the computer on port 443 – this is the port used by HTTPS. Then you will be able to access SecuritySpy securely from the internet.

When your SecuritySpy system is running autonomously at a remote location, there are a number of measures you can put in place to help ensure reliable operation, and to remotely control it if necessary, avoiding the need to physically visit the site to resolve any problems. Problems that may occur include computer crashes and router problems. Although such problems are rare, it is a good idea to implement some or all of the below suggestions, especially if the site is far away and a visit in person would be inconvenient.

This document assumes you have already set up your SecuritySpy system for remote viewing, so you are already familiar with concepts such as dynamic DNS, port forwarding, and IP addressing on local networks. For the purposes of this document, the computer running SecuritySpy is the server computer, and any computer used to connect to it in the ways described below is the client computer.

1. Energy Saver Settings

Open System Preferences on the server computer and click on Energy Saver:

Turn on the option “Restart automatically after a power failure”. This is the most important option here. If the power is cut to the computer for any reason, the computer will automatically turn on and boot up when the power is restored. Make sure that SecuritySpy is set to open automatically after the computer starts (right-click on the SecuritySpy icon in the Dock and enable the Open at Login option).

Turn off the option “Allow power button to sleep the computer”. This will prevent the computer going to sleep if the power button is pressed.

Click the Schedule… button and set the computer to wake up every day (at any time). This is a backup that is useful if for any reason the computer is shut down.

Note that all desktop Mac computers have a “PRAM” battery that is responsible for retaining settings such as the time and date, as well as the above energy saver settings, when the computer is switched off. If the PRAM battery is dead, the computer will not be able to restart automatically in the event of a power failure. Therefore it is a good idea to change the battery every two years or so to avoid this problem. You can tell if the battery is dead by switching the computer off, unplugging the power cable, waiting for a minute, and then powering on the computer on again. If it gives you a warning about incorrect date and time settings, you know that the PRAM battery is dead and needs replacing.

2. Screen Sharing

Open System Preferences on the server computer, click on Sharing and enable “Screen Sharing”:

Screen Sharing allows you to view and control the server computer directly from the client computer through a window that represents its screen. The server computer can be running Mac OS X 10.4 (“Tiger”) or later, but the client computer must be running Mac OS X 10.5 or later for built-in support of this feature.
To access Screen Sharing over the internet, you will need to set up port forwarding to the server computer on port 5900. If the server computer is running Mac OS X 10.4, this feature is also present in the Sharing system preference, but is called “Apple Remote Desktop”.

To connect to the server computer from the client computer, open the Screen Sharing application that is located at /System/Library/CoreServices/ and it will prompt you for the address of the server computer (you could make an alias of this application in a more convenient place if you like).

3. Remote Login (SSH)

Open System Preferences on the server computer, click on Sharing and enable the Remote Login option (see screenshot above).
This allows you to log in from the client computer using the Terminal application and control various things – in this way it is an alternative to (or a backup for) Screen Sharing but requires much less bandwidth so it is useful for situations with slow internet connections. To access SSH over the internet, you will need to set up port forwarding to the server computer on port 22.
To log in remotely from the client computer, open Terminal (which is in your /Applications/Utilities/ folder), and type:
ssh user@ipaddress
where user is the name of the admin account on the server computer, and ipaddress is the IP address or domain name of the server computer’s internet connection. You will be asked for the password for the account you are logging into.
Here are some useful commands for the purposes of remote administration:
ls
Displays a directory listing for the directory that you are currently in. When you first log in, the current directory will the the user folder.
cd ..
Navigates up one directory level.
cd foldername
Navigates into the directory called foldername.
top
Displays a list of current processes along with the processor time being used by that process. Press q to quit top.
man
Displays a manual page for any command. For example “man top” tells you about top. Press q to quit man.
osascript -e ‘tell app “securityspy” to quit’
Sends an AppleScript command to quit SecuritySpy.
kill 235
An alternative to the above, terminates the process with PID 235. The PID for a particular process can be obtained from top. It is better to use the AppleScript command above as it allows the process to perform any tasks that it needs to before terminating.
kill -9 235
This is a “non-ignorable kill” for process 235, equivalent to a force quit. Useful if the process in question is not responding.
open /applications/securityspy.app
Opens SecuritySpy, as if it were double-clicked in the Finder.
sudo reboot
Reboots the computer (you will be asked for the administrator password before this command will be executed).
exit
Ends the ssh session.

4. File Sharing

Open System Preferences on the server computer, click on Sharing and enable the File Sharing option (see screenshot above – this option is called “Personal File Sharing” on Mac OS X 10.4). This allows you to upload new versions of software to the server computer. To access file sharing from the internet you will have to set up port forwarding to the server computer on port 548.
To install a new version of SecuritySpy on the server computer remotely, you would do the following on the client computer:

• Open Terminal and log in to the server computer using ssh
• Quit SecuritySpy by typing osascript -e ‘tell app “securityspy” to quit’
• Connect to the server computer by file sharing: in the Finder, select Connect to Server… from the Go menu, and type in the IP address or domain name of the remote site. Log in with the administrator account and choose the server computer’s hard drive in the list of share points.
• You will now have the server computer’s hard drive available under the “Shared” section in any Finder window (Mac OS X 10.5), or mounted on your desktop (Mac OS X 10.4). Open it, navigate to the Applications folder, and copy the new version of SecuritySpy across, replacing the old version. Then unmount the drive by clicking the eject icon next to the drive in the Finder window (Mac OS X 10.5), or dragging it from your desktop to the trash (Mac OS X 10.4).
• In Terminal again, open SecuritySpy by typing open /applications/securityspy.app

5. Power Management Device

The only thing that will help in the rare event of a total server computer crash is an IP-addressable power management device. Several of these devices exist – a good low-cost example is the Dataprobe iBoot:

Dataprobe also make the iBootBar, which has multiple power adapters that can be controlled independently.

So to restart the server computer remotely you would log in to the device using a web browser, cut the power to the computer, wait for ten seconds or so, and then restore the power again. The computer will turn on automatically (due to the settings in Energy Saver described above).

Routers are generally reliable devices, however it is not uncommon to a have a router that stops working every now and then and requires resetting by turning off and on. A solution to this is to connect the router to a standard timer switch which can be obtained cheaply from most electronics/hardware stores. Set the timer switch to turn off and then on one minute later, every week at midnight.

Overseeing a new installation of a video surveillance system recently gave me some useful insights into network hardware and layout. The system is relatively high-spec, using Arecont AV2100 and ACTi ACM-1231 megapixel network cameras, with a Mac Mini as the recording computer (running SecuritySpy of course!). If you are unfamiliar with Arecont, they produce simple box cameras with unparalleled visual quality. ACTi cameras were chosen for other areas because they offer additional features such as infrared night vision and audio.

A high-performance switch was required, and a Netgear FS116 was chosen:

This switch supplies power-over-ethernet (PoE) on 8 of the 16 ports, which is supported by both models of camera mentioned above, simplifying the wiring installation.

From my experience, it is not worth economising on such items of network hardware. Netgear is a company with a long history of making high-quality reliable products. You may be tempted by alternative cheaper products from little-known manufacturers but it is generally a false economy. The above switch costs around GBP £150, a small price to pay for such a critical component.

The first setup of the system was laid out as follows:

As you can see, the router connects the Mac Mini and the main switch – the router basically contains its own internal hub/switch that provides four ethernet ports. This setup was chosen because of the close proximity of the router and Mac Mini (therefore easier wiring), and also to implement as short a route as possible from the Mac Mini to the internet. As well as managing the video surveillance system, the Mac Mini is providing some important web server functionality to the internet, and the above layout means that a failure of the main switch would not cause an outage of these functions.

However, this setup was plagued with problems. There were frequent timeouts and disconnections in the communication between the Mac Mini and the cameras. Troubleshooting revealed that the problem was down to the router’s internal hub. As you can see from the above diagram, the traffic from the cameras has to pass through the router to get to the Mac Mini, and apparently the router’s hub wasn’t up to the task. This underlines the point made above about only using high-quality networking hardware – a point apparently ignored by router’s manufacturer. So, the topology was changed as follows:

Now, the Mac Mini connects directly to the main switch. The traffic from the cameras goes straight through the main switch to the Mac Mini, and the router doesn’t see any of this traffic. Since the change, performance has improved and reliability has been flawless.

The above switch works at “fast ethernet” speeds, up to 100Mbps. This works well for the system described above, which has only four cameras. With more cameras, this speed limitation may start to impact on performance (depending of course on the cameras’ resolutions and your desired frame rates). The solution is to to use a gigabit switch, which offers speeds 10 times that of fast ethernet. For this I would recommend the Netgear FS728:

As well as 24 fast ethernet ports (all of which provide PoE), this switch offers four gigabit ethernet ports, one of which you would use to connect the computer. This removes the speed limitation and will allow you to connect many more cameras without any problems of network bandwidth. In addition, this is a managed switch, so has a web interface that has some useful statistics as well as other features such as cable tests – very handy for troubleshooting network connections.