Security: Difference between revisions

From MidasWiki
Jump to navigation Jump to search
mNo edit summary
(15 intermediate revisions by 2 users not shown)
Line 5: Line 5:
* [[odbedit]]
* [[odbedit]]
* [[/Experiment ODB tree #/Experiment/Security |/Experiment/Security]] ODB subtree
* [[/Experiment ODB tree #/Experiment/Security |/Experiment/Security]] ODB subtree
* [[mserver]]
</div>
</div>
== Access Control to a MIDAS experiment ==  
= 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 [[mhttpd]] by default now requires an SSL Certificate and a username and password (see [[#Web Access]]).
 
Other network security issues have also been addressed (see  [https://midas.triumf.ca/elog/Midas/1088 Note 1088]). Changes to [[mserver]] (August 2015) make the default behaviour to reject all external network connections ([https://midas.triumf.ca/elog/Midas/1090 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 [[#MIDAS programs on remote machines|below]].
 
 
== Web Access ==
In versions prior to May 2015, the default web access to MIDAS and ELOG uses the "http:" protocol which is insecure. In this case, all information is transmitted as clear text meaning that secret, confidential and sensitive information (such as the MIDAS and ELOG passwords and usernames) can be stolen "easily". This means that even "password protected" MIDAS and ELOG pages are not adequately protected if accessed using the "http" method. Until now, an SSL (https) proxy had to be set up to provide reasonable security for experiments.
 
Recent versions of elogd (ELOG) do support SSL https:// connections, and
the Web Server [[mhttpd]] has recently (May 2015) been updated to use OpenSSL to provide secure HTTPS connections via the [https://bitbucket.org/tmidas/midas/src/ecb9a8537448a8a43f7f9a2bfdb82e578208cde3/doc/mongoose/?at=develop Mongoose] web server. This limits access by default, by requiring a username and password - see [[mhttpd#HTTPS/SSL server (Mongoose)|HTTPS/SSL server (Mongoose)]] for more information. This option provides a similar level of security to an HTTP proxy.
=== Which security option to choose? ===
 
For a small operation that does not require root access to the host computer, mhttpd with mongoose is a good light weight solution. It is ideal for small experiments that until now have been using the "http:" protocol for mhttpd.
 
For a more elaborate setup with private networks etc., APACHE https proxy is probably better. For big experiments, resources like webcams,ganglia, couchdb, etc. also need password protection and APACHE https can provide all this.
 
=== Which one is easier to setup? ===
 
*  mhttpd with mongoose is fairly simple - you have to create a password file and provide a properly signed https certificate - see [[mhttpd#HTTPS/SSL server (Mongoose)|HTTPS/SSL server (Mongoose)]]
*  apache httpd is fairly straightforward if you follow well written instructions (such as we provide for using it with midas), but you do need root access and you do have to edit a good number of config files. Note that mhttpd with mongoose can be run with an SSL proxy - see [[Setup MIDAS experiment#using an HTTPS/SSL proxy]]
 
 
== 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  [https://midas.triumf.ca/elog/Midas/1090 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 ODB tree#midas server port|/Experiment/midas server port]] - are still supported.
 
== MIDAS programs on remote machines ==
 
To run MIDAS programs on remote machines the following is now required:
# change the ODB setting [[/Experiment ODB tree#Enable non-localhost RPC|/Experiment/Security/Enable non-localhost RPC]] to "yes" and restart [[mserver]]
# add the hostnames of all remote machines that will run MIDAS programs to the MIDAS RPC access control list in ODB key [[/Experiment ODB tree#Allowed hosts|/Experiment/Security/RPC hosts/Allowed hosts]].
# if needed, add firewall rules on both the MIDAS host and on all the MIDAS client machines - each machine running MIDAS programs must have permission to connect to all other machines running MIDAS programs.
<pre>
firewall-cmd --permanent --add-rich-rule="rule family="ipv4" source address="x.y.z.w/32" port protocol="tcp" port="0-65535" accept"
... repeat for the midas host and for all client machines, replace x.y.z.w with the actual IP addresses.
firewall-cmd --reload
firewall-cmd --list-all
</pre>
 
 
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 [[Message System#midas.log|Midas log file]] rejecting the connection from unallowed host 'ladd21.triumf.ca'.
* Add this host to <span style="color: purple; font-style:italic;">/Experiment/Security/RPC hosts/Allowed hosts</span>.
* After you add this hostname to <span style="color: purple; font-style:italic;">RPC hosts</span>, you should see messages in the [[Message System#midas.log|Midas log file]] about reloading the access control list
* try connecting again, it should work now.
;NOTE
;NOTE
:<span style="color: maroon; font-weight:bold;">To prevent access by determined or malicious hackers via the web, the following strategies are recommended: </span>
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 ODB tree#Disable RPC hosts check|/experiment/security/Disable RPC hosts check]] to "yes". This configuration is insecure and should only be done on a private network behind a firewall.
* Use the '''HTTPS/SSL server''' using the command [[mhttpd|mhttpd --mg]] (instead of mhttpd -p)
* Implement a '''firewall''' and/or restrictions on off-site access. This kind of security can be provided by setting up Proxy Access to [[mhttpd]] .


= ODB access control =
Note that '''other forms of ODB access control''' independent of these security features is also available which can protect the experiment from accidental access by authorized users:
*    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 Page|Custom web pages]] can provide experimenters with access to a subset of ODB keys necessary for the experiment. By [[Status Page#suppressed|hiding]] the [[ODB Page]] access button, the ODB can be protected from non-expert access via the web server. 
<br>
------------
<br>
<div style="background-color:whitesmoke">
= Security on OLDER (pre-August 2015) versions of MIDAS =
Versions of MIDAS older than August 2015 are vulnerable to malicious/unauthorized access. Network security on old versions can be enhanced by implementing a '''firewall''' and/or restrictions on off-site access. This kind of security can be provided by [[Setup MIDAS experiment#Setting up an HTTP proxy|setting up an HTTP proxy]] to [[mhttpd]] .
== Protect experiment from accidental access (old MIDAS versions) ==


By default, there is no restriction for any user to connect locally or remotely to a given experiment. The MIDAS system provides a means to setup access restrictions using the ODB in order to protect the experiment from accidental or 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''' but may prevent mistakes by authorized users.  These security features are still available, but their usefulness has largely been superceded by the improved security features implemented August 2015 (see [[#Access Control to a MIDAS experiment]]);


There are two levels of access restriction available each of which can be enabled independently:
There are two levels of access restriction available each of which can be enabled independently:
Line 22: Line 97:
The user can select either or both of these security features.
The user can select either or both of these security features.


;
== Restrict user access (old MIDAS versions) ==
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.


== How to Setup Web Access Restrictions ==
'''NOTE: this is not proof against malicious access.''' See [[#Access Control to a MIDAS experiment]].


 
The ODB [[/Experiment ODB tree #/Experiment/Security |/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 cmd|cmd=webpasswd}} is issued as follows:
 
 
<br>
The ODB [[/Experiment ODB tree #/Experiment/Security |/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:


   C:\online>odbedit
   C:\online>odbedit
Line 41: Line 109:
   Retype password:<xxxx>
   Retype password:<xxxx>


After running webpasswd, a new ODB key i.e. [[/Experiment ODB tree #/Experiment/Security/Web Password |/Experiment/Security/Web Password]] will  
After running the {{Odbedit cmd|cmd=webpasswd}}, a new ODB key i.e. [[/Experiment ODB tree #/Experiment/Security/Web Password |/Experiment/Security/Web Password]] will  
be present containing the encrypted web password.
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.
If this 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 of older versions of [[mhttpd]], or those who supply the username and password now required by [[mhttpd]] (May 2015).  


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


== How to Setup Client Access Restrictions ==
== Restrict client access (old MIDAS versions) ==
'''NOTE: this is not proof against malicious access.''' See [[#Access Control to a MIDAS experiment]].


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


   C:\online>odbedit
   C:\online>odbedit
Line 59: Line 128:
   Retype password:<xxxx>
   Retype password:<xxxx>


After running the odb command "passwd", the /Experiment/Security subtree will be present.
After running the {{Odbedit cmd|cmd=passwd}}, the {{Odbpath|path=/Experiment/Security}} subtree will be present.
 
=== Allowing access without password (old MIDAS versions) ===
NOTE: This feature has been superceded by [[#Access Control to a MIDAS experiment]] for [[mhttpd]] versions May 2015 or later.


=== Allowing specific hosts/clients access without password ===
While  [[#Restrict client access|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.


While  [[#How to Setup Client Access Restrictions|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 (old MIDAS versions) ====
NOTE: This feature has been superceded by [[#Access Control to a MIDAS experiment]] for [[mhttpd]] versions May 2015 or later.


==== Allowed hosts ====
Hostnames to be allowed full access to the ODB are listed in the [[/Experiment ODB tree #/Experiment/Security/Allowed hosts subtree |/Experiment/Security/Allowed hosts]] subtree, e.g.
Hostnames to be allowed full access to the ODB are listed in the [[/Experiment ODB tree #/Experiment/Security/Allowed hosts subtree |/Experiment/Security/Allowed hosts]] subtree, e.g.


Line 76: Line 148:




==== Allowed programs ====
==== Allowed programs (old MIDAS versions) ====
NOTE: This feature has been superceded by [[#Access Control to a MIDAS experiment]] for [[mhttpd]] versions May 2015 or later.


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
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
Line 84: Line 157:
   [local]:S>create int mstat
   [local]:S>create int mstat
   [local]:S>
   [local]:S>
</div>  <!-- obsolescent - silver -->




[[Category:Security]] [[Category:Experiment]]
[[Category:Security]] [[Category:Experiment]]

Revision as of 16:51, 1 March 2017


Links

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 mhttpd by default now requires an SSL Certificate and a username and password (see #Web Access).

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.


Web Access

In versions prior to May 2015, the default web access to MIDAS and ELOG uses the "http:" protocol which is insecure. In this case, all information is transmitted as clear text meaning that secret, confidential and sensitive information (such as the MIDAS and ELOG passwords and usernames) can be stolen "easily". This means that even "password protected" MIDAS and ELOG pages are not adequately protected if accessed using the "http" method. Until now, an SSL (https) proxy had to be set up to provide reasonable security for experiments.

Recent versions of elogd (ELOG) do support SSL https:// connections, and the Web Server mhttpd has recently (May 2015) been updated to use OpenSSL to provide secure HTTPS connections via the Mongoose web server. This limits access by default, by requiring a username and password - see HTTPS/SSL server (Mongoose) for more information. This option provides a similar level of security to an HTTP proxy.

Which security option to choose?

For a small operation that does not require root access to the host computer, mhttpd with mongoose is a good light weight solution. It is ideal for small experiments that until now have been using the "http:" protocol for mhttpd.

For a more elaborate setup with private networks etc., APACHE https proxy is probably better. For big experiments, resources like webcams,ganglia, couchdb, etc. also need password protection and APACHE https can provide all this.

Which one is easier to setup?

  • mhttpd with mongoose is fairly simple - you have to create a password file and provide a properly signed https certificate - see HTTPS/SSL server (Mongoose)
  • apache httpd is fairly straightforward if you follow well written instructions (such as we provide for using it with midas), but you do need root access and you do have to edit a good number of config files. Note that mhttpd with mongoose can be run with an SSL proxy - see Setup MIDAS experiment#using an HTTPS/SSL proxy


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.
  3. if needed, add firewall rules on both the MIDAS host and on all the MIDAS client machines - each machine running MIDAS programs must have permission to connect to all other machines running MIDAS programs.
firewall-cmd --permanent --add-rich-rule="rule family="ipv4" source address="x.y.z.w/32" port protocol="tcp" port="0-65535" accept"
... repeat for the midas host and for all client machines, replace x.y.z.w with the actual IP addresses.
firewall-cmd --reload
firewall-cmd --list-all


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 'ladd21.triumf.ca'.
  • 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.
NOTE

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.

ODB access control

Note that other forms of ODB access control independent of these security features is also available which can protect the experiment from accidental access by authorized users:

  • 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.




Security on OLDER (pre-August 2015) versions of MIDAS

Versions of MIDAS older than August 2015 are vulnerable to malicious/unauthorized access. Network security on old versions can be enhanced by implementing a firewall and/or restrictions on off-site access. This kind of security can be provided by setting up an HTTP proxy to mhttpd .


Protect experiment from accidental access (old MIDAS versions)

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 but may prevent mistakes by authorized users. These security features are still available, but their usefulness has largely been superceded by the improved security features implemented August 2015 (see #Access Control to a MIDAS experiment);

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.

Restrict user access (old MIDAS versions)

NOTE: this is 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:

 C:\online>odbedit
 [local:Default:S]/>cd Experiment/
 [local]/>webpasswd
 Password:<xxxx>
 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 this 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 of older versions of mhttpd, or those who supply the username and password now required by mhttpd (May 2015).

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

Restrict client access (old MIDAS versions)

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

In order to restrict accidental access to the experiment, a password mechanism can 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:

 C:\online>odbedit
 [local:Default:S]/>cd Experiment/
 [local]/>passwd
 Password:<xxxx>
 Retype password:<xxxx>

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

Allowing access without password (old MIDAS versions)

NOTE: This feature has been superceded by #Access Control to a MIDAS experiment for mhttpd versions May 2015 or later.

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 (old MIDAS versions)

NOTE: This feature has been superceded by #Access Control to a MIDAS experiment for mhttpd versions May 2015 or later.

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
 [local]rhosts>

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


Allowed programs (old MIDAS versions)

NOTE: This feature has been superceded by #Access Control to a MIDAS experiment for mhttpd versions May 2015 or later.

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
 [local]:S>