Mercurial > hg > orthanc-book

comparison Sphinx/source/faq/security.rst @ 238:a363714813b2

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
securing orthanc
author Sebastien Jodogne <s.jodogne@gmail.com>
date Fri, 12 Apr 2019 11:37:14 +0200
parents
children b15c3423b682
comparison
equal deleted inserted replaced
237:1a701dfdfcad 238:a363714813b2
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.
75
76 * Setup rules that define, for each authorized user, which resources
77 it can access, and through which HTTP method (GET, POST, DELETE
78 and/or PUT). This can be done by defining a :ref:`filter written in
79 Lua <lua-filter-rest>`. Here is a sample Lua filter that
80 differentiates between an administrator user (``admin``) who has
81 full access on the localhost only, and a generic user (``user``)
82 that has only read-only access::
83
84 function IncomingHttpRequestFilter(method, uri, ip, username, httpHeaders)
85 if method == 'GET' and (username == 'user' or username == 'admin') then
86 -- Read-only access (only GET method is allowed)
87 return true
88 elseif username == 'admin' and ip == '127.0.0.1' then
89 -- Read-write access for administrator (any HTTP method is allowed on localhost)
90 return true
91 else
92 -- Access is disallowed by default
93 return false
94 end
95 end
96
97 Very importantly, make sure to protect ``POST`` access to the
98 ``/tools/execute-script`` URI. This URI can indeed be used by a
99 malicious user to execute any system command on the computer as the
100 user that runs Orthanc.
101
102 * Consider implementing a :ref:`higher-level application
103 <improving-interface>` (e.g. in PHP) that takes care of user
104 authentication/authorization, and that is the only one to be
105 allowed to contact the Orthanc REST API.
106
107 * For advanced scenarios, you might have interest in the
108 :ref:`advanced authorization plugin <authorization>`. Similarly,
109 developers of :ref:`plugins <plugins>` could be interested by the
110 ``OrthancPluginRegisterIncomingHttpRequestFilter2()`` function
111 provided by the Orthanc plugin SDK.
112
113
114 **Remark:** These parameters also apply to the :ref:`DICOMweb server plugin <dicomweb>`.
115
116
117 Securing the DICOM server
118 -------------------------
119
120 .. highlight:: json
121
122 Besides its REST API that is served through its embedded HTTP/HTTPS
123 server, Orthanc also acts as a :ref:`DICOM server <dicom-protocol>`
124 (more precisely, as a DICOM SCP).
125
126 The DICOM modalities that are known to Orthanc are defined by setting
127 the ``DicomModalities`` configuration option. Out-of-the-box, Orthanc
128 accepts C-ECHO and C-STORE commands sent by unknown modalities, but
129 blocks C-FIND and C-MOVE commands issued by unknown modalities.
130
131 To fully secure the DICOM protocol, you should:
132
133 * Set the ``DicomAlwaysAllowEcho`` configuration option to ``false``
134 to disallow C-ECHO commands from unknown modalities.
135
136 * Set the ``DicomAlwaysAllowStore`` configuration option to ``false``
137 to disallow C-STORE commands from unknown modalities.
138
139 * Set the ``DicomCheckModalityHost`` configuration option to ``true``
140 to validate the IP and hostname address of the remote modalities.
141
142 * For each modality that is defined in ``DicomModalities``,
143 selectively specify what DICOM commands are allowed to be issued by
144 the SCU of this modality by setting the suboptions ``AllowEcho``,
145 ``AllowFind``, ``AllowMove`` and ``AllowStore``. For instance, a
146 modality could be allowed to C-STORE images, but be disallowed to
147 C-FIND the content of Orthanc. Here is a sample configuration to
148 define a single modality that is only allowed to send DICOM
149 instances to Orthanc::
150
151 {
152 "DicomModalities" : {
153 "untrusted" : {
154 "AET" : "CT",
155 "Port" : 104,
156 "Host" : "192.168.0.10",
157 "AllowEcho" : false,
158 "AllowFind" : false,
159 "AllowMove" : false,
160 "AllowStore" : true
161 }
162 }
163 }
164
165 **Note:** These configuration suboptions only affect the behavior of
166 the DICOM SCP of Orthanc (i.e. for incoming connections). Orthanc
167 will always be able to make outgoing DICOM SCU connections to these
168 modalities, independently of the value of these suboptions.
169
170 * Consider implementing a :ref:`filter implemented in Lua
171 <lua-filter-rest>` to restrict which modalities can C-STORE images
172 within Orthanc, and which kind of images are accepted by Orthanc.
173
174 * Consider setting ``DicomCheckCalledAet`` to ``true`` to force proper
175 configuration of remote modalities.
176
177
178 **Remark:** As of Orthanc 1.5.6, `DICOM TLS encryption
179 <https://www.dicomstandard.org/using/security/>`__ is not supported
180 yet. We are looking for :ref:`an industrial sponsor <contributing>` to
181 get this feature implemented, as it is useful in enterprise scenarios.