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