From MidasWiki
Revision as of 18:57, 13 August 2015 by Suz (talk | contribs)
Jump to navigation Jump to search


Access Control to a MIDAS experiment

Historically, by default there has been no restriction for any user to connect locally or remotely to a given experiment. This has now changed (August 2015). The Web Server itself mhttpd has recently (May 2015) been updated to use OpenSSL to provide secure HTTPS connections via the Mongoose web server. This limits access by requiring a username and password. Access can be restricted to the web server by using the Access Control List (ACL).

Other network security issues have also been addressed (see Note 1088). Changes to mserver (August 2015) make the default behaviour to reject all external network connections (Note 1090), so that only programs running on the localhost will be allowed. To allow access from remote machines, the user will have to take action as described below.

MIDAS programs running on localhost

Out-of-the-box MIDAS is now secure (August 2015). By default, connections from the outside are not possible. MIDAS RPC TCP ports are bound to the localhost interface. This configuration is suitable for testing MIDAS on a laptop and for running a simple experiment where all programs run on one machine. MIDAS ports (except for the mhttpd web ports) do not show up on network port scans.

The change in binding UDP ports is generally incompatible with previous versions of MIDAS, so all MIDAS programs should be rebuild and restarted. If rebuilding all MIDAS programs is impossible see Note 1090).

mserver will still work in this localhost-restricted configuration - one should use "odbedit -h localhost" to connect. Multiple mserver instances on the same machine - using different TCP ports via "-p" and ODB /Experiment/midas server port - are still supported.

MIDAS programs on remote machines

To run MIDAS programs on remote machines the following is now required:

  1. change the ODB setting /Experiment/Security/Enable non-localhost RPC to "yes" and restart mserver
  2. add the hostnames of all remote machines that will run MIDAS programs to the MIDAS RPC access control list in ODB key /Experiment/Security/RPC hosts/Allowed hosts.

To avoid "guessing" the host names expected by MIDAS, follow the following procedure:

  • On the local machine ("daq06") set ODB key "enable non-localhost rpc" to "yes" and restart the mserver (step 1 above)
  • go to the remote machine ("ladd21") and try to start the MIDAS program, i.e. "odbedit -h daq06". This will bomb and there will be a message in the Midas log file rejecting the connection from unallowed host ''.
  • Add this host to /Experiment/Security/RPC hosts/Allowed hosts.
  • After you add this hostname to RPC hosts, you should see messages in the Midas log file about reloading the access control list
  • try connecting again, it should work now.

If MIDAS clients have to connect from random hosts (i.e. dynamically assigned random DHCP addresses), one can disable the host name checks by setting ODB key /experiment/security/Disable RPC hosts check to "yes". This configuration is insecure and should only be done on a private network behind a firewall.

Security on Older versions of MIDAS

Network security can be obtained by implementing a firewall and/or restrictions on off-site access. This kind of security can be provided by setting up Proxy Access to mhttpd .

Protect from accidental/unauthorized access

The MIDAS system provides a means to setup access restrictions using the ODB in order to protect the experiment from accidental or unauthorized access. This will not stop malicious or determined hackers (see #Access Control to a MIDAS experiment) but may prevent mistakes by authorized users.

There are two levels of access restriction available each of which can be enabled independently:

  • To restrict write access via the web by requiring a password before any parameter can be changed.
  • To require a password before MIDAS clients can start running on the host.

The user can select either or both of these security features.

Note that other forms of ODB access control independent of these security features is also available:

  • Write access can be restricted while a run is in progress (see Lock when running )
  • Individual keys or subtrees in the experiment's ODB can be set "read only" with the odbedit command chmod.
  • Custom web pages can provide experimenters with access to a subset of ODB keys necessary for the experiment. By hiding the ODB Page access button, the ODB can be protected from non-expert access via the web server.

How to Setup Web Access Restrictions

NOTE: these are not proof against malicious access. See #Access Control to a MIDAS experiment.

The ODB /Experiment/Security subtree can also be used to restrict access to the experiment via the Web. This subtree is automatically created (if not already present) when the odbedit command webpasswd is issued as follows:

 [local:Default:S]/>cd Experiment/
 Retype password:<xxxx>

After running the odbedit command webpasswd, a new ODB key i.e. /Experiment/Security/Web Password will be present containing the encrypted web password.

If web access restriction is set up, the user will be requested to provide the "Web Password" when accessing the requested experiment in "Write Access" mode. The "Read Only Access" mode is still available to all users.

[local:bnqr:S]/Experiment>ls Security/
Web Password                    pon4@#@%SSDF2

How to Setup Client Access Restrictions

In order to restrict access to the experiment, a password mechanism needs to be defined. This is provided by the /Experiment/Security subtree in odb. This subtree is automatically created (if not already present) when the odbedit command passwd is issued as follows:

 [local:Default:S]/>cd Experiment/
 Retype password:<xxxx>

After running the odbedit command passwd, the /Experiment/Security subtree will be present.

Allowing specific hosts/clients access without password

While restricting access can make sense to deny access to outsider to a given experiment, it can be annoying for the people working directly at the back-end computer or for an automatic frontend reloading mechanism. To address this problem, specific hosts and clients can be exempt from having to supply a password before being granted full access.

Allowed hosts

Hostnames to be allowed full access to the ODB are listed in the /Experiment/Security/Allowed hosts subtree, e.g.

 [local]/>cd "/Experiment/Security/Allowed hosts"
 [local]rhosts>create int myhost.domain

where <myHost.domain> is to be replaced by the full IP address of the host requesting full clearance, e.g "".

Allowed programs

Programs (i.e. clients) to be allowed full access to the ODB (regardless of the node on which they are running) can be listed in the /Experiment/Security/Allowed programs subtree,

 [local]/>cd "/Experiment/Security/Allowed programs"
 [local]:S>create int mstat