4 \section*{Consid\'erations sur la s\'ecurit\'e de Bacula}
5 \label{_ChapterStart14}
6 \index[general]{Bacula!Consid\'erations sur la s\'ecurit\'e de }
7 \index[general]{Consid\'erations sur la s\'ecurit\'e de Bacula }
8 \addcontentsline{toc}{section}{Consid\'erations sur la s\'ecurit\'e de Bacula}
11 \item Le client ({\bf bacula-fd}) doit \^etre ex\'ecut\'e en tant que root
12 afin d'avoir l'acc\`es \`a tous les fichiers du syst\`eme.
13 \item Il n'est pas n\'ecessaire d'ex\'ecuter le Director en tant que root.
14 \item Il n'est pas n\'ecessaire d'ex\'ecuter le Storage Daemon en tant que
15 root, mais vous devez vous assurer qu'l peut utiliser le lecteur de bandes,
16 dont l'acc\`es est presque toujours r\'eserv\'e \`a root par d\'efaut.
18 \item Vous devriez restreindre l'acc\`es au fichiers de configuration de
19 Bacula, de sorte que les mots de passe ne soient pas lisibles par tous. Les
20 {\it daemons} {\bf Bacula} sont prot\'eg\'es par des mots de passe et CRAM-MD5
21 (i.e. les mots de passe ne sont pas envoy\'es sur le r\'eseau). Ceci assur
22 que tout le monde ne peut acc\'eder aux {\it daemons}. C'est une protection
23 raisonnablement bonne, mais qui peut \^etre craqu\'e par un expert.
24 \item Si vous utilisez les ports recommand\'es 9101,9102 et 9103, vous voudrez
25 probablement prot\'eger ces ports des acc\`es externes \`a l'aide d'un
26 firewall et/ou en utilisant tcp wrappers ({\bf etc/hosts.allow}).
27 \item Actuellement, toutes les donn\'es sont envoy\'ees sur le r\'eseau sans
28 chiffrage. Par cons\'equent, \`a moins que vous n'utilisiez {\bf ssh} ou {\bf
29 stunnel} pour la transmission de port (port forwarding), il n'est pas
30 recommand\'e de faire des sauvegardes \`a travers un r\'eseau non
31 s\'ecuris\'e (par exemple, Internet). Nous pr\'evoyons d'int\'egrer le
32 chiffrage {\bf ssl} dans une version future.
33 \item Vous devriez vous assurer que seuls les {\it daemons} de Bacula ont
34 acc\`es en lecture et \'ecriture aux r\'epertoires de travail de Bacula.
35 \item Si vous utilisez {\bf MySQL}, il n'est pas n\'ecessaire de l'ex\'ecuter
37 \item Le script par d\'efaut de Bacula {\bf grant-mysql-permissions} accorde
38 toutes les permissions d'utilisation de la base de donn\'ees MySQL sans mot
39 de passe. Si vous voulez la s\'ecurit\'e, affinez ceci !
40 \item N'oubliez pas que Bacula est un programme r\'eseau, ainsi quiconque sur
41 le r\'eseau dispose du programme console et du mot de passe du Director peut
42 acc\'eder \`a Bacula et aux donn\'ees sauvegard\'ees.
43 \item Vous pouvez restreindre les adresses IP avec auxquelles Bacula se
44 connectera en utilisant les enregistrements appropri\'es {\bf DirAddress},
45 {\bf FDAddress}, ou {\bf SDAddress} dans les fichiers de configurations
46 respectifs des {\it daemons}
51 \subsection*{Configurer et tester TCP Wrappers avec Bacula}
52 \index[general]{Configurer et tester TCP Wrappers avec Bacula }
53 \index[general]{Bacula!Configurer et tester TCP Wrappers avec }
54 \addcontentsline{toc}{subsection}{Configurer et tester TCP Wrappers avec
57 Les TCP Wrappers sont impl\'ement\'es si vous les activez lors de la
58 configuration ({\bf ./configure \verb{--{with-libwrap}). Avec ce code activ\'e, vous
59 pourrez contr\^oler qui peut acc\'eder \`a vos {\it daemons}. Ce contr\^ole
60 est obtenu par la modification du fichier {\bf /etc/hosts.allow}. Le nom de
61 programme qu'utilise {\bf Bacula} pour appliquer ces restrictions est celui
62 que vous avez sp\'ecifi\'e dans le fichier de configuration du {\it daemon}.
63 Vous ne devez pas utiliser l'option {\bf twist} dans votre {\bf
64 /etc/hosts.allow} car elle stopperait les {\it daemons} Bacula lorsqu'une
65 connection est refus\'ee.
67 Dan Languille a fourni les informations suivantes concernant la configuration
68 et les tests de TCP Wrappers avec Bacula.
70 Si vous lisez hosts\_options(5), vous verrez une option nomm\'ee twist. Cette
71 option remplace le processus courant par une instance de la commande shell
72 sp\'ecifi\'ee. Ce qui suit est un exemple typique de son utilisation :
77 : severity auth.info \
78 : twist /bin/echo "Vous n'\^etes pas autoris\'e \`a utiliser %d depuis %h."
83 {\bf question 1} Le code libwrap tente d'\'eviter {\bf twist} s'il est
84 ex\'ecut\'e dans un processus r\'esident (i.e. , mais ce test ne prot\'egera
85 pas le premier appel hosts\_access(). Il en r\'esulte que le processus (e.g.
86 bacula-fd, bacula-sd, bacula-dir) sera stopp\'e si la premi\`ere connection
87 \`a son port provoque l'invocation de l'option twist. Le risque est qu'une
88 attaque provoque l'arr\^et des {\it daemons}.
90 The libwrap code tries to avoid {\bf twist} if it runs in a resident process,
91 but that test will not protect the first hosts\_access() call. This will
92 result in the prcess (e.g. bacula-fd, bacula-sd, bacula-dir) being terminated
93 if the first connection to their port results in the twist option being
94 invoked. The potential, and I stree potential, exists for an attacker to
95 prevent the daemons from running. Cette situation est \'evit\'ee si votre
96 fichier /etc/hosts.allow contient un jeu de r\`egles appropri\'e. L'exemple
97 suivant est suffisant :
101 undef-fd : localhost : allow
102 undef-sd : localhost : allow
103 undef-dir : localhost : allow
104 undef-fd : ALL : deny
105 undef-sd : ALL : deny
106 undef-dir : ALL : deny
110 Vous devez accorder les noms des {\it daemons} \`a ceux de leurs fichiers de
111 configuration respectifs. Dans ces exemples, le Director est undef-dir, le
112 Storage Daemon est undef-sd, et le File Daemon est undef-fd. Ajustez pour
113 coller \`a votre configuration. L'exemple de r\`egles ci-dessus suppose que
114 SD, FD et DIR sont tous sur la m\^eme machine. Si vous avez un client FD
115 distant, il vous suffira de placer le jeu de r\^egles suivant sur ce client :
119 undef-fd : director.example.org : allow
120 undef-fd : ALL : deny
124 O\`u director.example.org est l'h\^ote qui contactera le client (i.e. la
125 machine sur laquelle le Bacula Director tourne). L'usage de ``ALL : deny''
126 assure que l'option twist (si pr\'esente) n'est pas invoqu\'ee. Pour tester
127 correctement votre configuration, d\'emarrez le(s) {\it daemon(s)}, puis
128 essayez de vous y connecter depuis une adresse IP qui devrait \^etre capable
129 de le faire. Vous devriez voir quelque chose comme :
134 Trying 192.168.0.56...
135 Connected to undef.example.org.
136 Escape character is '^]'.
137 Connection closed by foreign host.
142 C'est la r\'eponse correcte. Si vous voyez ceci :
147 Trying 192.168.0.56...
148 Connected to undef.example.org.
149 Escape character is '^]'.
150 You are not welcome to use undef-sd from xeon.example.org.
151 Connection closed by foreign host.
156 Alors, twist a \'et\'e invoqu\'ee, et votre configuration est incorrecte. vous
157 devez ajouter la directive ``deny''. Il est important de noter que vos tests
158 doivent inclure le red\'emarrage des {\it daemons} apr\`es chaque tentative de
159 connexion. Vous pouvez aussi tcpdchk(8) et tcpdmatch(8) pour valider jeu de
160 r\`egles /etc/hosts.allow. Voici un test simple avec tcpdmatch :
164 $ tcpdmatch undef-dir xeon.example.org
165 warning: undef-dir: no such process name in /etc/inetd.conf
166 client: hostname xeon.example.org
167 client: address 192.168.0.18
168 server: process undef-dir
169 matched: /etc/hosts.allow line 40
175 Si vous ex\'ecutez Bacula en tant que {\it standalone daemon}, les
176 avertissements ci-dessus peuvent \^etre ignor\'es sans scrupules. Voici un
177 exemple qui r\'ev\`ele que ``deny'' fait defaut \`a vos r\`egles, et que
178 l'option twist a \'et\'e invoqu\'ee.
182 $ tcpdmatch undef-dir 10.0.0.1
183 warning: undef-dir: no such process name in /etc/inetd.conf
184 client: address 10.0.0.1
185 server: process undef-dir
186 matched: /etc/hosts.allow line 91
187 option: severity auth.info
188 option: twist /bin/echo "You are not welcome to use
189 undef-dir from 10.0.0.1."
194 \subsection*{Executer Bacula sans \^etre root}
195 \index[general]{Root!Executer Bacula sans \^etre }
196 \index[general]{Executer Bacula sans \^etre root }
197 \addcontentsline{toc}{subsection}{Executer Bacula sans \^etre root}
199 Un conseil de s\'ecurit\'e de Dan Languille:
201 C'est une bonne id\'ee d'ex\'ecuter vos {\it daemons} avec des privil\`eges
202 aussi faibles que possible. En d'autres termes, si vous pouvez, n'ex\'ecutez
203 pas d'applications en tant que root si elle n'ont pas besoin d'\^etre
204 ex\'ecut\'ees en tant que root. Le Storage Daemon et le Director Daemon n'ont
205 pas besoin d'\^etre ex\'ecut\'es en tant que root. Le File Daemon en a besoin
206 pour acc\'eder \`a l'ensemble des fichiers du syst\`eme. Pour vous passer des
207 privil\`eges root, il vous faut cr\'eer un utilisateur et un groupe. Choisir
208 {\tt bacula} pour l'un et l'autre me semble une bonne id\'ee.
210 Le port FreeBSD cr\'ee cet utilisateur et ce groupe pour vous. (En fait, au
211 moment ou j'\'ecris ces lignes, ce n'est pas encore le cas, mais {\c c}a le
212 sera bient\^ot). Voici \`a quoi ressemblent ces entr\'ees sur mon portable
217 bacula:*:1002:1002::0:0:Bacul Daemon:/var/db/bacula:/sbin/nologin
221 J'ai utilis\'e vipw pour cr\'eer ces entr\'ees. J'ai utilis\'e un User ID et
222 un Group ID disponibles sur mon syst\`eme : 1002.
224 J'ai aussi cr\'e\'e un groupe dans /etc/group:
232 L'utilisateur bacula, contrairement au {\it daemon} Bacula, aura un
233 r\'epertoire d\'edi\'e (home directory) : {\tt /var/db/bacula} qui est le
234 r\'epertoire standard pour le catalogue de Bacula.
236 A pr\'esent, vous avez un utilisateur et un groupe bacula, et vous pouvez
237 s\'ecuriser le r\'epertoire d\'edi\'e de bacula en utilisant cette commande :
241 chown -R bacula:bacula /var/db/bacula/
245 Celle-ci assure que seul l'utilisateur bacula peut acc\'eder \`a ce
246 r\'epertoire. Elle signifie aussi que si nous ex\'ecutons le Director et le
247 Storage Daemon en tant que bacula, ces {\it daemons} auront aussi des acc\`es
248 restreints. Ce ne serait pas le cas s'ils \'etaient ex\'ecut\'es en tant que
251 Il est important de noter que le Storage Daemon a vraiment besoin
252 d'appartenir au groupe operator pour un acc\`es normal aux lecteurs de bandes.
253 (au moins sur FreeBSD, c'est ainsi que les choses sont configur\'ees par
254 d\'efaut). De tels p\'eriph\'eriques sont en principe attribu\'es \`a
255 root:operator. Il est plus facile et moins dangereux de faire de bacula un
256 membre de ce groupe que de jouer avec les permissions du syst\`eme.
258 D\'emarrer les {\it daemons} bacula
260 Pour d\'emarrer les {\it daemons} bacula sur FreeBSD, utilisez la commande :
264 /usr/local/etc/rc.d/bacula.sh start
268 Pour vous assurer que tous fonctionnent :
272 $ ps auwx | grep bacula
273 root\ 63416\ 0.0\ 0.3\ 2040 1172\ ??\ Ss\ 4:09PM 0:00.01
274 /usr/local/sbin/bacula-sd -v -c /usr/local/etc/bacula-sd.conf
275 root\ 63418\ 0.0\ 0.3\ 1856 1036\ ??\ Ss\ 4:09PM 0:00.00
276 /usr/local/sbin/bacula-fd -v -c /usr/local/etc/bacula-fd.conf
277 root\ 63422\ 0.0\ 0.4\ 2360 1440\ ??\ Ss\ 4:09PM 0:00.00
278 /usr/local/sbin/bacula-dir -v -c /usr/local/etc/bacula-dir.conf