A guide to securing Platinum systems
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
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:
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:
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 DM24 module. The configuration of the attached Platinum module cannot be altered, but the firmware and configuration of the DM24 can be. In addition, it is very easy for a TCP port scan to accidentally activate terminal mode on the 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
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:
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
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
Again, sensor commands are logged through
and TCP access can be locked down using a firewall.
/etc/ssh.localto match their desired configuration.
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:
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
~/.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:
The key must be manually added each time the session is started with:
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:
To install the public key (which is a plain text file consisting of one long
line), it must be added to the file
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.
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
in either vi or nano, and find the line containing
If this line is not present or is commented out, then add or uncomment it. Change it to:
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
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:
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.
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
- 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
The built-in firewall uses a limited set of the Linux
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
save option will save any rules added or modified using
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
removing the files in that directory will remove the firewall rules on the
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.