Page Contents

OMERO

Downloads
Feature List
Licensing

Previous topic

Troubleshooting OMERO

Next topic

LDAP authentication

This Page

Note

This documentation is for the new OMERO 5.1. version. See the latest OMERO 5.0.x version or the previous versions page to find documentation for the OMERO version you are using if you have not upgraded yet.

Server security and firewalls

General

OMERO has been built with security in mind. Various standard security practices have been adhered to during the development of the server and client including:

  • Encryption of all passwords between client and server via SSL
  • Full encryption of all data when requested via SSL
  • User and group based access control
  • Authentication via LDAP
  • Limited visible TCP ports to ease firewalling
  • Use of a higher level language (Java or Python) to limit buffer overflows and other security issues associated with native code
  • Escaping and bind variable use in all SQL interactions performed via Hibernate

Note

The OMERO team treats the security of all components with care and attention. If you have a security issue to report, please do not hesitate to contact us using our private, secure mailing list as described on the security vulnerabilities page.

Firewall configuration

Securing your OMERO system with so called firewalling or packet filtering can be done quite easily. By default, OMERO clients only need to connect to two TCP ports for communication with your OMERO.server: 4063 (unsecured) and 4064 (SSL). These are the IANA assigned ports for the Glacier2 router from ZeroC. Both of these values, however, are completely up to you, see SSL below.

Important OMERO ports:

  • TCP/4063
  • TCP/4064

If you are using OMERO.web, then you will also need to make your HTTP and HTTPS ports available. These are usually 80 and 443.

Important OMERO.web ports:

  • TCP/80
  • TCP/443

Example OpenBSD firewall rules

block in log on $ext_if from any to <omero_server_ip>
pass in on $ext_if proto tcp from any to <omero_server_ip> port 4063
pass in on $ext_if proto tcp from any to <omero_server_ip> port 4064
pass in on $ext_if proto tcp from any to <omero_server_ip> port 443
pass in on $ext_if proto tcp from any to <omero_server_ip> port 80

Example Linux firewall rules

iptables -P INPUT drop
iptables -A INPUT -p tcp --dport 4063 -j ACCEPT
iptables -A INPUT -p tcp --dport 4064 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
...

Passwords

The passwords stored in the password table are salted and hashed, so it is impossible to recover a lost one, instead a new one must be set by an admin.

If the password for the root user is lost, the only way to reset it (in the absence of other admin accounts) is to manually update the password table. The bin/omero command can generate the required SQL statement for you:

$ bin/omero db password
Please enter password for OMERO root user:
Please re-enter password for OMERO root user:
UPDATE password SET hash = 'PJueOtwuTPHB8Nq/1rFVxg==' WHERE experimenter_id  = 0;

Current hashed password:

$ psql mydatabase -c " select * from password"
 experimenter_id |           hash
-----------------+--------------------------
               0 | Xr4ilOzQ4PCOq3aQ0qbuaQ==
(1 row)

Change the password using the generated SQL statement:

$ psql mydatabase -c "UPDATE password SET hash = 'PJueOtwuTPHB8Nq/1rFVxg==' WHERE experimenter_id  = 0;"
UPDATE 1

Java key- and truststores.

If your server is connecting to another server over SSL, you may need to configure a truststore and/or a keystore for the Java process. This happens, for example, when your LDAP server uses SSL. See the LDAP plugin for information on how to configure the LDAP URLs. As with all configuration properties, you will need to restart your server after changing them.

To do this, you will need to configure several server properties, similar to the properties you configured during installation (Windows).

  • truststore path

    bin/omero config set omero.security.trustStore /home/user/.keystore
    
    A truststore is a database of trusted entities and their
    associated X.509 certificate chains authenticating the
    corresponding public keys. The truststore contains the
    Certificate Authority (CA) certificates and the certificate(s) of
    the other party to which this entity intends to send encrypted
    (confidential) data. This file must contain the public key
    certificates of the CA and the client's public key certificate.
    

    If you don’t have one you can create it using the following:

    openssl s_client -connect {{host}}:{{port}} -prexit < /dev/null | openssl x509 -outform PEM | keytool -import  -alias ldap -storepass {{password}} -keystore {{truststore}} -noprompt
    
  • truststore password

    bin/omero config set omero.security.trustStorePassword secret
    
  • keystore path

    bin/omero config set omero.security.keyStore /home/user/.mystore
    
    A keystore is a database of private keys and their associated
    X.509 certificate chains authenticating the corresponding public
    keys.
    
    A keystore is mostly needed if you are doing client-side certificates
    for authentication against your LDAP server.
    
  • keystore password

    bin/omero config set omero.security.keyStorePassword secret
    

SSL

Especially if you are going to use LDAP authentication to your server, it is important to encrypt the transport channel between clients and the Glacier2 router to keep your passwords safe.

By default, all logins to OMERO occur over SSL using an anonymous handshake. After the initial connection, clients can request to have communication un-encrypted to speed up image loading by clicking on the lock symbol. An unlocked symbol means that non-password related activities (i.e. anything other than login and changing your password) will be unencrypted, and the only critical connection which is passed in the clear is your session id.

Administrators can configure OMERO such that unencrypted connections are not allowed, and the user’s choice will be silently ignored. The SSL and non-SSL ports are configured in the etc/grid/default.xml and windefault.xml files, and as described above, default to 4064 and 4063 respectively, and can be modified with command:

$ bin/omero admin ports --help
usage: bin/omero admin ports [-h] [--prefix PREFIX] [--registry REGISTRY]
                             [--tcp TCP] [--ssl SSL] [--webserver WEBSERVER]
                             [--revert] [--skipcheck]

Allows modifying the ports from a standard OMERO install

To have multiple OMERO servers running on the same machine several ports
must be modified from their defaults. Changing the ports on a running server
will be prevented, use --skipcheck to override this.

Examples:

  # Set ports to registry:14061, tcp:14063, ssl:14064, web:14080
  bin/omero admin ports --prefix=1
  # Set ports back to defaults: 4061, 4063, 4064, 4080
  bin/omero admin ports --prefix=1 --revert
  # Set ports to: 4444, 5555, 6666, 7777
  bin/omero admin ports --registry=4444 --tcp=5555 --ssl=6666 --webserver=7777

Optional Arguments:
  In addition to any higher level options

  -h, --help             show this help message and exit
  --prefix PREFIX        Adds a prefix to each port ON TOP OF any other settings
  --registry REGISTRY    Registry port. (default: 4061)
  --tcp TCP              The tcp port to be used by Glacier2 (default: 4063)
  --ssl SSL              The ssl port to be used by Glacier2 (default: 4064)
  --webserver WEBSERVER  The web application server port (default: 4080)
  --revert               Used to rollback from the given settings to the defaults
  --skipcheck            Skips the check if the server is already running