A guide to securing Platinum systems

General

Change the password!

The first and most important step to securing a system is to change the default password. We have seen many instances of systems exposed to the Internet being compromised simply because the password has not been changed, and has been guessed by a dictionary attack.

On the web interface, visit the User→ Change password menu entry.

On the command line, either via SSH or serial port, log in as root and run the command passwd. This will prompt you to enter a new password, asking twice for confirmation, and then it will update it. This password is used for web, SSH and serial port access.

Password reset guides:

Firmware updates

Another important step is to keep up-to-date with the latest firmware. We have recently introduced several features to improve security, and we do release firmware updates for security fixes in the open source packages that we use. Please refer to our firmware page for the most recent release notes as well as instructions for upgrading systems which are not connected to the Internet:

Protecting instruments

There are two protocol servers running on Platinum which, by default, allow unauthenticated access to instruments in various forms.

Most importantly, the Scream server (which at present cannot be disabled) will allow any TCP client full access to an attached CMG-DM24 module. The configuration of the attached Platinum module cannot be altered, but the firmware and configuration of the CMG-DM24 can be. In addition, it is very easy for a TCP port scan to accidentally activate terminal mode on the CMG-DM24, as the protocol requires only a single byte to be transmitted to do so.

This access is enabled by default. It can be disabled in the web interface by following Configuration→ Services→ GCF→ gcf-out-scream and then selecting the server in question. On the configuration screen, the option is under the "Terminal" tab. Simply check the box "Disable terminal access" and press to prevent this:

gcf-out-scream configuration window screenshot

As this screenshot implies, terminal access can also be restricted by source IP address. TCP access can also be restricted by firewall, but note that TCP access is required for the Scream protocol to work properly (even in UDP mode).

Terminal access is logged under /var/log/libterminal (and the files there can be examined with the dump-serial-log command).

Secondly, the gdi-link server allows sensor control (lock, unlock, calibration etc.) by default. This cannot be accidentally activated; negotiation is required and the command structure is not trivial enough for accidental activation. By default, raw terminal access is disabled through gdi-link (though it could be enabled). These more secure defaults were introduced in Platinum release 13664.

On the web interface (of the sending system), this can be disabled by following Configuration→ Services→ gdi→ gdi-link-tx and then selecting the server in question. On the "Network" tab the relevant option is "Instrument control":

Again, sensor commands are logged through /var/log/libterminal and TCP access can be locked down using a firewall.

SSH

Please note: users familiar with configuring OpenSSH should feel free to modify the SSH server configuration files in /etc/ssh.local to match their desired configuration.

Disable SSHv1

Older Platinum systems will have shipped with SSH protocol version 1 (SSHv1) enabled. This is no longer recommended, as the protocol is not secure by today's standards. SSHv1 should be disabled.

On the command line, open the file /etc/ssh/sshd_config in either vi or nano, and find any line containing the word Protocol. If missing altogether, or commented out, then SSHv1 is already disabled. Otherwise, change the line to read Protocol 2. This ensures that only version 2 of the protocol can be used.

Using SSH keypairs

SSH keypairs can be used in lieu of passwords to authenticate users. This method is both safer (the private key contains much more "entropy" or randomness than a password does, so cannot realistically be attacked using only brute-force) and more convenient, because it does not require entry of password at every login.

In this technique, the client generates a public/private keypair. The public key is safe to distribute and does not need to be kept secret. It must be installed on each server to which access should be granted. The private key must be kept secure. Only users with access to the private key can log in to servers where the public key has been installed.

To generate an SSH keypair under Linux, run the command:

ssh-keygen

This asks for a filename; the default it suggests is the file that the ssh command always tries to use. It may be sensible to choose another name (e.g. ~/.ssh/id_guralp). It also asks for a passphrase. This is used to encrypt the private key on disk in order to keep it secure. The passphrase can be omitted (just press enter), which is suitable for automatic scripts etc. but, for a user key, we recommended that you provide a passphrase.

Most Linux distributions come equipped with ssh-agent by default. This keeps an unencrypted copy of the private key in memory only, so that it cannot be stolen by access to the disk alone. The list of available keys can be inspected with:

ssh-add -l

The key must be manually added each time the session is started with:

ssh-add ~/.ssh/id_guralp

It is possible to edit the file ~/.ssh/config in order to tell ssh to use the private key file for a particular server. An example of such an entry might be:

Host eam1234
Hostname eam1234.domain.example
User root
IdentityFile ~/.ssh/id_guralp

A guide for the equivalent SSH key generation for Putty under Windows may be found with a web search:
https://www.google.com/search?q=putty+keypair+openssh.

To install the public key (which is a plain text file consisting of one long line), it must be added to the file /root/.ssh/authorized_keys.

By default, this file contains the Güralp Systems skeleton key, which allows our support team to log in without needing a password. This key can be removed at your choice, but this disables the utility of the remote-assistance tool.

To add the key, use a web browser to visit Configuration → Networking → SSH server.

Upload a new public key screen-shot

In the resulting screen, click and use your browser's standard upload dialogue.

Disable password-based login

If SSH keypairs are deployed and all users are trained in their use, then it is sensible to disable password-based login. This completely prevents dictionary attacks, since only the pre-authorised private key files can be used to log in.

This must be done through the command line. Open the file /etc/ssh/sshd_config in either vi or nano, and find the line containing PasswordAuthentication. If this line is not present or is commented out, then add or uncomment it. Change it to:

PasswordAuthentication no

If the SSH private key file is lost then it will be necessary to log in via the serial port to reset this option. Alternatively, if the support skeleton key has been left in place, remote-assistance may be activated through the web interface. If you then contact , GSL support staff can re-enable password logins for you.

Web interface

When accessing the device's web interface over an unsecured channel (such as the Internet), it may be desirable to use secure HTTP (HTTPS) instead of plain HTTP. This ensures the contents of any conversation are encrypted and cannot be read. HTTPS access is enabled by default and no changes are required to use it; simply change the browser address bar to use https:// instead of http://

Normally, each Platinum system uses its own self-generated, self-signed HTTPS certificate. This will cause a warning in any web browser that tries to access it, as the certificate has not been signed in advance by a known certificate authority (CA). If desired, the file:

/etc/lighttpd/lighttpd.pem.local

can be edited to replace the built-in certificate with a new one. This file also contains the private key. Getting such a certificate is beyond the scope of this document, and probably requires a network administrator with knowledge of the CA system and processes.

If desired, it is possible to prevent HTTP access altogether using the built-in firewall. See the section on the firewall below for details.

Firewall

Border firewall

The best solution to securing systems is to use a border firewall to prevent unexpected access. Such systems can be tightly controlled yet still be flexible. The following specific recommendations can be made:

Rate-limit inbound SSH connections from unknown addresses, or lock down completely to known sources.
Prevent inbound HTTP, only allowing inbound HTTPS.
Prevent inbound NTP.
Inbound UDP and TCP are required to port 1567 (default) for the Scream protocol.
Inbound TCP to port 1565 (default) is required to retrieve data via gdi-link.
Inbound TCP to port 1566 (default) is required to push data to the target system via gdi-link.
Do not forget to secure IPv6 with the same rules as well.

The following outgoing connections (IPv4 and IPv6) can be expected by default. Note that the server IP addresses have changed over their lifetime, so it is best to not lock down outbound connections too stringently if it can be avoided:

Outbound connections to ports 22 and 80 of iridium.guralp.com, for the remote assistance features
Outbound connections to port 873 of rsync.guralp.com, for firmware upgrades.
Outbound connections to port 80 of www.guralp.com, for periodic leap second table updates.
Note : Before Platinum firmware release 14864, leap-second updates were downloaded from www.lwithers.me.uk

Built-in firewall

The built-in firewall uses a limited set of the Linux iptables utilities. The following two commands list the existing rules:

iptables -L
ip6tables -L

Starting in firmware build 14187, the following commands are also available for managing the firewall:

firewall save
firewall reload
firewall clear

The save option will save any rules added or modified using the iptables/ip6tables commands to persistent configuration storage. This would normally happen as part of a clean reboot process, but not on an unexpected reboot/power outage. The reload option reloads the set of rules as last saved to persistent storage. The clear option clears all current rules, but does not immediately save this.

The firewall rules are saved under /etc/iptables.local and removing the files in that directory will remove the firewall rules on the next reboot.

Starting in firmware build 14187, the web interface has a tool to view the state of the firewall, and flush the rules if necessary. This tool is available under the "Troubleshooting" menu link: simply click the "Firewall diagnostics" button.

This example shows our recommended rules if a border firewall is not present. These can be adapted easily, and should be entered in the order they are shown. Further web searches on the iptables tool may provide additional information for further tailoring the firewall.

Always allow loopback connections, in order for various features to work:

iptables -A INPUT -i lo -j ACCEPT
ip6tables -A INPUT -i lo -j ACCEPT

Enable connection tracking (this ensures outbound connections are not affected by rules further down):

iptables -A INPUT -m state --state invalid -j DROP
iptables -A INPUT -m state --state related,established -j ACCEPT
ip6tables -A INPUT -m state --state invalid -j DROP
ip6tables -A INPUT -m state --state related,established -j ACCEPT

Lock down SSH to known addresses:

iptables -N inbound_ssh
iptables -A inbound_ssh --src 192.168.0.0/24 -j ACCEPT
	# add other addresses as required here
iptables -A INPUT -p tcp --dport ssh -j inbound_ssh
iptables -A INPUT -p tcp --dport ssh -j REJECT

ip6tables -N inbound_ssh
ip6tables -A inbound_ssh --src fe80::/64 -j ACCEPT    # IPv6LL: recommended!
	# add other addresses as required here
ip6tables -A INPUT -p tcp --dport ssh -j inbound_ssh
ip6tables -A INPUT -p tcp --dport ssh -j REJECT

This allows inbound SSH connections from any machine on the 192.168.0.0/24 network (a typical "local" network address: substitue the address of your own network here as required) and from fe80::/64, which specifies any IPv6 "link-local" address

Note that you can add further addresses at any time with any number of further iptables -A inbound_ssh commands.

Be sure to add your own address before the REJECT rule if entering these rules over SSH!

Lock down inbound NTP:

iptables -A INPUT -p udp --dport ntp -j REJECT
ip6tables -A INPUT -p udp --dport ntp -j REJECT

Lock down inbound HTTP:

iptables -N inbound_http
iptables -A INPUT -p tcp --dport http -j inbound_http
iptables -A INPUT -p tcp --dport http -j REJECT

ip6tables -N inbound_http
ip6tables -A INPUT -p tcp --dport http -j inbound_http
ip6tables -A INPUT -p tcp --dport http -j REJECT

If desired, specific hosts can be whitelisted for HTTP using an iptables -A inbound_http command similar to that used in the SSH example.

For more information, first contact your local distributor or email .