238
|
1 .. _security:
|
|
2
|
|
3 Securing Orthanc
|
|
4 ================
|
|
5
|
|
6 .. contents::
|
|
7
|
|
8 Orthanc is a microservice for medical imaging. Out-of-the-box, it
|
|
9 makes the assumption that it runs on the localhost, within a secured
|
|
10 environment. As a consequence, care must be taken if deploying Orthanc
|
|
11 in a insecure environment, especially if it is run as a public-facing
|
|
12 service on Internet. This page provides instructions to secure Orthanc
|
|
13 through its :ref:`configuration options <configuration>`.
|
|
14
|
|
15
|
|
16 General configuration
|
|
17 ---------------------
|
|
18
|
|
19 As for any service running on a computer, you should:
|
|
20
|
|
21 * Make sure to run the Orthanc service as a separate user. In
|
|
22 particular, never run Orthanc as the ``root`` user on GNU/Linux, or
|
|
23 as the ``Administrator`` user on Microsoft Windows.
|
|
24
|
|
25 * Contact your network administrators to setup `Intranet firewalls
|
|
26 <https://en.wikipedia.org/wiki/Firewall_(computing)>`__, so that
|
|
27 only trusted computers can contact Orthanc through its REST API
|
|
28 or through the DICOM protocol.
|
|
29
|
|
30 Care must also be taken about some configuration options specific to
|
|
31 Orthanc:
|
|
32
|
|
33 * ``LimitFindResults`` and ``LimitFindInstances`` should not be set to
|
|
34 zero to avoid making Orthanc unresponsive on large databases by a
|
|
35 malicious user that would make many lookups within Orthanc. A value
|
|
36 of ``100`` should be a good compromise.
|
|
37
|
|
38 * ``HttpsVerifyPeers`` should be set to ``true`` to secure outgoing
|
|
39 connections to remote HTTPS servers (such as when Orthanc is acting
|
|
40 as a :ref:`DICOMweb client <dicomweb-client>`).
|
|
41
|
|
42 * Make sure to understand the implications of the
|
|
43 ``OverwriteInstances`` option.
|
|
44
|
|
45 * You might also be interested in checking the options related to
|
|
46 :ref:`performance optimization <scalability>`.
|
|
47
|
|
48
|
|
49
|
|
50 Securing the HTTP server
|
|
51 ------------------------
|
|
52
|
|
53 .. highlight:: lua
|
|
54
|
|
55 Orthanc publishes a :ref:`REST API <rest>` that provides full
|
|
56 programmatic access to its content, in read/write. This means for
|
|
57 instance that a malicious user could delete the entire content of the
|
|
58 server, or could inspect confidential medical data.
|
|
59
|
|
60 By default, the HTTP server is restricted to the localhost to prevent
|
|
61 such attacks from the outside world. However, as soon as external
|
|
62 access is granted by setting the ``RemoteAccessAllowed`` configuration
|
|
63 option to ``true``, you should:
|
|
64
|
|
65 * Set ``AuthenticationEnabled`` to ``true`` to force the users to
|
|
66 authenticate. The authorized users are listed in the option
|
|
67 ``RegisteredUsers``.
|
|
68
|
|
69 * Enable :ref:`HTTPS encryption <https>` to prevent the stealing of
|
|
70 medical data or passwords, even on the Intranet.
|
|
71
|
|
72 * If Orthanc is put on a server that can be contacted from Internet,
|
|
73 put Orthanc behind a :ref:`reverse proxy <https>`, and let this
|
|
74 reverse proxy take care of the HTTPS encryption.
|
512
|
75
|
|
76 * Enable :ref:`Client certificate authentication <https>` between multiple
|
|
77 Orthanc peers.
|
|
78
|
238
|
79 * Setup rules that define, for each authorized user, which resources
|
|
80 it can access, and through which HTTP method (GET, POST, DELETE
|
|
81 and/or PUT). This can be done by defining a :ref:`filter written in
|
|
82 Lua <lua-filter-rest>`. Here is a sample Lua filter that
|
|
83 differentiates between an administrator user (``admin``) who has
|
|
84 full access on the localhost only, and a generic user (``user``)
|
|
85 that has only read-only access::
|
|
86
|
|
87 function IncomingHttpRequestFilter(method, uri, ip, username, httpHeaders)
|
|
88 if method == 'GET' and (username == 'user' or username == 'admin') then
|
|
89 -- Read-only access (only GET method is allowed)
|
|
90 return true
|
|
91 elseif username == 'admin' and ip == '127.0.0.1' then
|
|
92 -- Read-write access for administrator (any HTTP method is allowed on localhost)
|
|
93 return true
|
|
94 else
|
|
95 -- Access is disallowed by default
|
|
96 return false
|
|
97 end
|
|
98 end
|
|
99
|
|
100 Very importantly, make sure to protect ``POST`` access to the
|
|
101 ``/tools/execute-script`` URI. This URI can indeed be used by a
|
|
102 malicious user to execute any system command on the computer as the
|
|
103 user that runs Orthanc.
|
|
104
|
|
105 * Consider implementing a :ref:`higher-level application
|
289
|
106 <improving-interface>` (e.g. in PHP, Java, Django...) that takes
|
|
107 care of user authentication/authorization, and that is the only one
|
|
108 to be allowed to contact the Orthanc REST API. In particular, you
|
|
109 must create a higher-level application so as to properly deal with
|
|
110 `CSRF attacks
|
|
111 <https://en.wikipedia.org/wiki/Cross-site_request_forgery>`__:
|
|
112 Indeed, as explained in the introduction, Orthanc is a microservice
|
|
113 that is designed to be used within a secured environment.
|
238
|
114
|
|
115 * For advanced scenarios, you might have interest in the
|
|
116 :ref:`advanced authorization plugin <authorization>`. Similarly,
|
|
117 developers of :ref:`plugins <plugins>` could be interested by the
|
|
118 ``OrthancPluginRegisterIncomingHttpRequestFilter2()`` function
|
|
119 provided by the Orthanc plugin SDK.
|
|
120
|
|
121
|
|
122 **Remark:** These parameters also apply to the :ref:`DICOMweb server plugin <dicomweb>`.
|
|
123
|
|
124
|
|
125 Securing the DICOM server
|
|
126 -------------------------
|
|
127
|
|
128 .. highlight:: json
|
|
129
|
|
130 Besides its REST API that is served through its embedded HTTP/HTTPS
|
|
131 server, Orthanc also acts as a :ref:`DICOM server <dicom-protocol>`
|
|
132 (more precisely, as a DICOM SCP).
|
|
133
|
248
|
134 In general, the DICOM protocol should be disabled if running Orthanc
|
|
135 on a cloud server, except if you use a VPN (cf. `reference
|
517
|
136 <https://groups.google.com/d/msg/orthanc-users/yvHexxG3dTY/7s3A7EHVBAAJ>`__)
|
|
137 or a SSH tunnel (cf. `reference
|
518
|
138 <https://www.howtogeek.com/168145/how-to-use-ssh-tunneling/>`__). Favor
|
517
|
139 HTTPS for transfering medical images across sites (see above). You can
|
|
140 turn off DICOM protocol by setting the configuration option
|
|
141 ``DicomServerEnabled`` to ``false``.
|
248
|
142
|
238
|
143 The DICOM modalities that are known to Orthanc are defined by setting
|
|
144 the ``DicomModalities`` configuration option. Out-of-the-box, Orthanc
|
|
145 accepts C-ECHO and C-STORE commands sent by unknown modalities, but
|
|
146 blocks C-FIND and C-MOVE commands issued by unknown modalities.
|
|
147
|
|
148 To fully secure the DICOM protocol, you should:
|
|
149
|
|
150 * Set the ``DicomAlwaysAllowEcho`` configuration option to ``false``
|
|
151 to disallow C-ECHO commands from unknown modalities.
|
|
152
|
|
153 * Set the ``DicomAlwaysAllowStore`` configuration option to ``false``
|
|
154 to disallow C-STORE commands from unknown modalities.
|
|
155
|
|
156 * Set the ``DicomCheckModalityHost`` configuration option to ``true``
|
|
157 to validate the IP and hostname address of the remote modalities.
|
|
158
|
|
159 * For each modality that is defined in ``DicomModalities``,
|
|
160 selectively specify what DICOM commands are allowed to be issued by
|
|
161 the SCU of this modality by setting the suboptions ``AllowEcho``,
|
413
|
162 ``AllowFind``, ``AllowMove``, ``AllowStore`` and ``AllowGet``. For instance, a
|
238
|
163 modality could be allowed to C-STORE images, but be disallowed to
|
|
164 C-FIND the content of Orthanc. Here is a sample configuration to
|
|
165 define a single modality that is only allowed to send DICOM
|
|
166 instances to Orthanc::
|
|
167
|
|
168 {
|
|
169 "DicomModalities" : {
|
|
170 "untrusted" : {
|
|
171 "AET" : "CT",
|
|
172 "Port" : 104,
|
|
173 "Host" : "192.168.0.10",
|
|
174 "AllowEcho" : false,
|
|
175 "AllowFind" : false,
|
|
176 "AllowMove" : false,
|
413
|
177 "AllowGet" : false,
|
238
|
178 "AllowStore" : true
|
|
179 }
|
|
180 }
|
|
181 }
|
|
182
|
|
183 **Note:** These configuration suboptions only affect the behavior of
|
|
184 the DICOM SCP of Orthanc (i.e. for incoming connections). Orthanc
|
|
185 will always be able to make outgoing DICOM SCU connections to these
|
|
186 modalities, independently of the value of these suboptions.
|
|
187
|
|
188 * Consider implementing a :ref:`filter implemented in Lua
|
|
189 <lua-filter-rest>` to restrict which modalities can C-STORE images
|
|
190 within Orthanc, and which kind of images are accepted by Orthanc.
|
|
191
|
|
192 * Consider setting ``DicomCheckCalledAet`` to ``true`` to force proper
|
|
193 configuration of remote modalities.
|
|
194
|
|
195
|
513
|
196 **Remark:** As of Orthanc 1.7.4, `DICOM TLS encryption
|
238
|
197 <https://www.dicomstandard.org/using/security/>`__ is not supported
|
|
198 yet. We are looking for :ref:`an industrial sponsor <contributing>` to
|
248
|
199 get this feature implemented, as it is useful in enterprise and cloud
|
|
200 environments.
|