Security Overview

Security on BlueSky starts with the protocol: SSH is a really good start.

We've chosen what we feel offers the best combination of SSH variables for security. On OS X 10.10 and earlier, we had to make lesser choices for compatibility.

All client computers will still require a name and password local to that computer in order to connect and do anything of consequence. That includes your connections. You can make this easier with a standard admin user account and a public key installed in its homefolder, but BlueSky doesn't do that. That's up to you.

On the server we have a number of SSH hardening techniques. (Console access protection is up to you.) Client keys are generated during install, encrypted using a certificate pair that’s created during server setup, and provided to the server via HTTPS (you will need a valid SSL certificate).

BlueSky runs on your clients’ computer as an unprivileged user account without a password (in other words, no one can log in as the BlueSky user – only root can execute commands as the BlueSky user).

The commands that can be executed on the server and by the server on your client workstations are limited by SSH forced commands. In the event that your BlueSky server were compromised, the connected computers are still protected by the allowed command list and the local authentication of each computer. Likewise, forced commands keep your BlueSky server safe from anyone sitting at an installed client and getting curious. The client can only establish the tunnel; it’s not allowed to get an interactive shell on the server. To see what we mean, take a look at /var/bluesky/.ssh/wrapper.sh on one of your client computers. These are the only commands that can be run on the client from the server without authentication. The server is trying to read the serial number of the computer for confirmation of its identification. Anything else is rejected.

Each server runs Fail2Ban to block any IPs that are attempting brute force or probing for certain vulnerabilities. Servers listen for SSH on non-standard ports (default 3122 but you can change that), which keeps away the script kiddies who are looking for open port 22.

Since each BlueSky server runs with unique keys generated during setup, there is absolutely no chance of mingling with other BlueSky installs.

Protection from rogue admins is a concern, so protect your web admin password and the the Admin Tools download. (Read more about Emergency Stop for what to do if admin level access is compromised.) You can also receive an email from the server any time a new admin key is added to the system (if you enable emailHelper.sh during setup).

It is worth noting that the client workstation may now be accepting SSH and VNC connections on its Local Area Network where they may not have before. For mobile Macs, that could include potentially hostile environments. To that end, here are some tips for hardening the workstations:

• Limit access to the protocols to specific users. BlueSky will add itself to SSH. This is a good option if your users do not leverage the services.
• Ensure your users have strong passwords. Nothing like hacking into Bob’s MacBook with username “Bob” and “password”
• Install a local firewall that blocks traffic to SSH and VNC from the LAN. BlueSky looks like it is coming from localhost (because it is) so it is exempt from LAN rules.
• Make SSH on the workstations listen on a different port. Be careful not to use old instructions that will break SIP.