Mercurial > hg > orthanc-book
annotate Sphinx/source/faq/security.rst @ 581:e75d79048623
openapi is done
author | Sebastien Jodogne <s.jodogne@gmail.com> |
---|---|
date | Wed, 30 Dec 2020 09:39:04 +0100 |
parents | 090cc988c35e |
children | 5f5519f1491a |
rev | line source |
---|---|
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 | |
568 | 200 **Remark:** As of Orthanc 1.8.2, `DICOM TLS encryption |
238 | 201 <https://www.dicomstandard.org/using/security/>`__ is not supported |
544
d7ec7ea133b8
note about nginx to emulate dicom tls
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
528
diff
changeset
|
202 yet. As a temporary workaround, `it has been reported |
d7ec7ea133b8
note about nginx to emulate dicom tls
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
528
diff
changeset
|
203 <https://www.digihunch.com/2020/11/medical-imaging-web-server-deployment-pipeline/>`__ |
d7ec7ea133b8
note about nginx to emulate dicom tls
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
528
diff
changeset
|
204 that the "*SSL Termination for TCP Upstream Servers*" feature of nginx |
546 | 205 can be used to emulate DICOM TLS. Another option is to use `stunnel |
206 <https://www.stunnel.org/>`__. We are looking for :ref:`an industrial | |
207 sponsor <contributing>` to implement DICOM TLS in the core of Orthanc, | |
208 as this feature is dedicated to enterprise and cloud environments. |