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 La sécurité, c'est de pouvoir restaurer vos fichiers, aussi, lisez
12 attentivement le chapitre \ilink{Critical Items Chapter}{Critical} de
14 \item Le client ({\bf bacula-fd}) doit \^etre ex\'ecut\'e en tant que root
15 afin d'avoir l'acc\`es \`a tous les fichiers du syst\`eme.
16 \item Il n'est pas n\'ecessaire d'ex\'ecuter le Director en tant que root.
17 \item Il n'est pas n\'ecessaire d'ex\'ecuter le Storage Daemon en tant que
18 root, mais vous devez vous assurer qu'l peut utiliser le lecteur de bandes,
19 dont l'acc\`es est presque toujours r\'eserv\'e \`a root par d\'efaut.
20 De plus, si vous n'exécutez pas le Storage Daemon en tant que root, il sera
21 dans l'incapacité de régler automatiquement les paramètres de votre lecteur
22 de bandes. En effet, ces fonctions requièrent les droits root sur la plupart
23 des systèmes d'exploitation.
24 \item Vous devriez restreindre l'acc\`es au fichiers de configuration de
25 Bacula, de sorte que les mots de passe ne soient pas lisibles par tous. Les
26 {\it daemons} {\bf Bacula} sont prot\'eg\'es par des mots de passe et CRAM-MD5
27 (i.e. les mots de passe ne sont pas envoy\'es sur le r\'eseau). Ceci assure
28 que tout le monde ne peut acc\'eder aux {\it daemons}. C'est une protection
29 raisonnablement bonne, mais qui peut \^etre craqu\'ee par un expert.
30 \item Si vous utilisez les ports recommand\'es 9101,9102 et 9103, vous voudrez
31 probablement prot\'eger ces ports des acc\`es externes \`a l'aide d'un
32 firewall et/ou en utilisant tcp wrappers ({\bf etc/hosts.allow}).
33 \item Actuellement, toutes les donn\'ees sont envoy\'ees sur le r\'eseau sans
34 chiffrement. Par cons\'equent, \`a moins que vous n'utilisiez {\bf ssh} ou {\bf
35 stunnel} pour la transmission de port (NDT: port forwarding), il n'est pas
36 recommand\'e de faire des sauvegardes \`a travers un r\'eseau non
37 s\'ecuris\'e (par exemple, Internet). Nous pr\'evoyons d'int\'egrer le
38 chiffrage {\bf ssl} dans une version future.
39 \item Vous devriez vous assurer que seuls les {\it daemons} de Bacula ont
40 acc\`es en lecture et \'ecriture aux r\'epertoires de travail de Bacula.
41 \item Si vous utilisez {\bf MySQL}, il n'est pas n\'ecessaire de l'ex\'ecuter
43 \item Le script par d\'efaut de Bacula {\bf grant-mysql-permissions} accorde
44 toutes les permissions d'utilisation de la base de donn\'ees MySQL sans mot
45 de passe. Si vous voulez la s\'ecurit\'e, affinez ceci !
46 \item N'oubliez pas que Bacula est un programme r\'eseau, ainsi quiconque sur
47 le r\'eseau dispose du programme console et du mot de passe du Director peut
48 acc\'eder \`a Bacula et aux donn\'ees sauvegard\'ees.
49 \item Vous pouvez restreindre les adresses IP avec auxquelles Bacula se
50 connectera en utilisant les enregistrements appropri\'es {\bf DirAddress},
51 {\bf FDAddress}, ou {\bf SDAddress} dans les fichiers de configurations
52 respectifs des {\it daemons}
53 \item Soyez conscient que si vous sauvegardez votre catalogue avec le script
54 par défaut, et si l'accès à votre catalogue est protégé par un mot de passe,
55 ce dernier est transmis en tant qu'option de ligne de commande à ce script,
56 ce qui le rend visible à tout utilisateur du système. Si vous voulez
57 sécuriser ce point, vous devez le passer via une variable d'environnement
58 ou un fichier sécurisé.
61 \subsection*{Compatibilité ascendante}
62 \index[general]{Compatibilité ascendante}
63 \addcontentsline{toc}{subsection}{Compatibilité ascendante}
64 L'un des principaux objectifs de Bacula est de garantir que vous pouvez
65 restaurer depuis des cartouches (ou depuis des volumes disque) écrites des années
66 auparavant. Ceci implique que chaque nouvelle version de Bacula devrait être
67 capable de relire les anciens formats de cartouches. Le premier problème est de
68 s'assurer que le matériel fonctionne encore malgré les années, et que les supports
69 sont encore valides. Ensuite, votre système d'exploitation doit être capable
70 de s'interfacer avec le périphérique et finalement, Bacula doit être capable
71 de reconnaître les anciens formats. De tous ces problèmes, nous ne pouvons
72 prendre en charge que le dernier, pour les autres, vous devez vous préparer
75 Depuis les tous premiers stades de Bacula (janvier 2000) jusqu'à aujourd'hui
76 (Décembre 2005), Bacula a connu deux formats majeurs d'écriture sur les
77 cartouches. Le second format a été introduit dans la version 1.27 en
78 novembre 2002, et n'a pas changé depuis. En principe, Bacula devrait encore pouvoir
79 lire le format d'origine, mais j'avoue ne pas avoir essayé depuis longtemps...
81 Bien que le format des cartouches soit fixé, les types de données qui peuvent être
82 écrites sur les cartouches sont extensibles, ce qui nous a permis d'ajouter de
83 nouvelles fonctionnalités telles que les ACLs, les données Win32, les données
84 chiffrées... Naturellement, une ancienne version de Bacula ne saurait lire des
85 nouveaux flux de données, mais chaque nouvelle version de Bacula est en principe
86 capable de lire les anciens flux.
88 Si vous voulez être absolument certain de pouvoir lire vos vieilles cartouches,
91 1. Essayer de lire les vieilles cartouches de temps en temps, une fois par an
94 2. Conserver une copie statiquement liée de chaque version de Bacula que vous
95 avez utilisée en production. Ainsi, si pour quelque raison nous venions à
96 abandonner la compatibilité avec les anciens formats de cartouches, vous pourriez
97 toujours remettre en service une vieille copie de Bacula...
99 Le second point est probablement excessif, en toute rigueur, il pourrait vous
104 \subsection*{Configurer et tester TCP Wrappers}
105 \index[general]{Configurer et tester TCP Wrappers}
106 \index[general]{Bacula!Configurer et tester TCP Wrappers}
107 \addcontentsline{toc}{subsection}{Configurer et tester TCP Wrappers}
109 Les TCP Wrappers sont impl\'ement\'es si vous les activez lors de la
110 configuration ({\bf ./configure \verb{:--:{with-tcp-wrappers}). Avec ce code activ\'e, vous
111 pourrez contr\^oler qui peut acc\'eder \`a vos {\it daemons}. Ce contr\^ole
112 est obtenu par la modification du fichier {\bf /etc/hosts.allow}. Le nom de
113 programme qu'utilise {\bf Bacula} pour appliquer ces restrictions est celui
114 que vous avez sp\'ecifi\'e dans le fichier de configuration du {\it daemon}.
115 Vous ne devez pas utiliser l'option {\bf twist} dans votre {\bf
116 /etc/hosts.allow} car elle stopperait les {\it daemons} Bacula lorsqu'une
117 connection est refus\'ee.
119 Dan Languille a fourni les informations suivantes concernant la configuration
120 et les tests de TCP Wrappers avec Bacula.
122 Si vous lisez hosts\_options(5), vous verrez une option nomm\'ee twist. Cette
123 option remplace le processus courant par une instance de la commande shell
124 sp\'ecifi\'ee. Voici un exemple typique de son utilisation :
129 : severity auth.info \
130 : twist /bin/echo "Vous n'\^etes pas autoris\'e \`a utiliser %d depuis %h."
135 Le code libwrap tente d'\'eviter {\bf twist} s'il est
136 ex\'ecut\'e dans un processus r\'esident. Il en r\'esulte que le processus (e.g.
137 bacula-fd, bacula-sd, bacula-dir) sera stopp\'e si la premi\`ere connection
138 \`a son port provoque l'invocation de l'option twist. Le risque est qu'une
139 attaque provoque l'arr\^et des {\it daemons}. Cette situation est \'evit\'ee si votre
140 fichier /etc/hosts.allow contient un jeu de r\`egles appropri\'e. L'exemple
141 suivant est suffisant :
145 undef-fd : localhost : allow
146 undef-sd : localhost : allow
147 undef-dir : localhost : allow
148 undef-fd : ALL : deny
149 undef-sd : ALL : deny
150 undef-dir : ALL : deny
154 Vous devez accorder les noms des {\it daemons} \`a ceux de leurs fichiers de
155 configuration respectifs. Dans ces exemples, le Director est undef-dir, le
156 Storage Daemon est undef-sd, et le File Daemon est undef-fd. Ajustez pour
157 coller \`a votre configuration. L'exemple de r\`egles ci-dessus suppose que
158 SD, FD et DIR sont tous sur la m\^eme machine. Si vous avez un client FD
159 distant, il vous suffira de placer le jeu de r\`egles suivant sur ce client :
163 undef-fd : director.example.org : allow
164 undef-fd : ALL : deny
168 O\`u director.example.org est l'h\^ote qui contactera le client (i.e. la
169 machine sur laquelle le Bacula Director tourne). L'usage de "ALL : deny"
170 assure que l'option twist (si pr\'esente) n'est pas invoqu\'ee. Pour tester
171 correctement votre configuration, d\'emarrez le(s) {\it daemon(s)}, puis
172 essayez de vous y connecter depuis une adresse IP qui devrait \^etre capable
173 de le faire. Vous devriez voir quelque chose comme :
178 Trying 192.168.0.56...
179 Connected to undef.example.org.
180 Escape character is '^]'.
181 Connection closed by foreign host.
186 C'est la r\'eponse correcte. Si vous voyez ceci :
191 Trying 192.168.0.56...
192 Connected to undef.example.org.
193 Escape character is '^]'.
194 You are not welcome to use undef-sd from xeon.example.org.
195 Connection closed by foreign host.
200 Alors, twist a \'et\'e invoqu\'ee, et votre configuration est incorrecte. vous
201 devez ajouter la directive "deny". Il est important de noter que vos tests
202 doivent inclure le red\'emarrage des {\it daemons} apr\`es chaque tentative de
203 connexion. Vous pouvez aussi tcpdchk(8) et tcpdmatch(8) pour valider jeu de
204 r\`egles /etc/hosts.allow. Voici un test simple avec tcpdmatch :
208 $ tcpdmatch undef-dir xeon.example.org
209 warning: undef-dir: no such process name in /etc/inetd.conf
210 client: hostname xeon.example.org
211 client: address 192.168.0.18
212 server: process undef-dir
213 matched: /etc/hosts.allow line 40
219 Si vous ex\'ecutez Bacula en tant que {\it standalone daemon}, les
220 avertissements ci-dessus peuvent \^etre ignor\'es sans scrupules. Voici un
221 exemple qui r\'ev\`ele que "deny" fait defaut \`a vos r\`egles, et que
222 l'option twist a \'et\'e invoqu\'ee.
226 $ tcpdmatch undef-dir 10.0.0.1
227 warning: undef-dir: no such process name in /etc/inetd.conf
228 client: address 10.0.0.1
229 server: process undef-dir
230 matched: /etc/hosts.allow line 91
231 option: severity auth.info
232 option: twist /bin/echo "You are not welcome to use
233 undef-dir from 10.0.0.1."
238 \subsection*{Executer Bacula sans \^etre root}
239 \index[general]{Root!Executer Bacula sans \^etre }
240 \index[general]{Executer Bacula sans \^etre root }
241 \addcontentsline{toc}{subsection}{Executer Bacula sans \^etre root}
243 Voici quelques recommandations de Dan Languille :
245 C'est une bonne id\'ee d'ex\'ecuter vos {\it daemons} avec des privil\`eges
246 aussi faibles que possible. En d'autres termes, si vous pouvez, n'ex\'ecutez
247 pas d'applications en tant que root si elle n'ont pas besoin d'\^etre
248 ex\'ecut\'ees en tant que root. Le Storage Daemon et le Director Daemon n'ont
249 pas besoin d'\^etre ex\'ecut\'es en tant que root. Le File Daemon en a besoin
250 pour acc\'eder \`a l'ensemble des fichiers du syst\`eme. Pour vous passer des
251 privil\`eges root, il vous faut cr\'eer un utilisateur et un groupe. Choisir
252 {\tt bacula} pour l'un et l'autre me semble une bonne id\'ee.
254 Le port FreeBSD cr\'ee cet utilisateur et ce groupe pour vous. (En fait, au
255 moment ou j'\'ecris ces lignes, ce n'est pas encore le cas, mais {\c c}a le
256 sera bient\^ot). Voici \`a quoi ressemblent ces entr\'ees sur mon portable
261 bacula:*:1002:1002::0:0:Bacul Daemon:/var/db/bacula:/sbin/nologin
265 J'ai utilis\'e vipw pour cr\'eer ces entr\'ees. J'ai utilis\'e un User ID et
266 un Group ID disponibles sur mon syst\`eme : 1002.
268 J'ai aussi cr\'e\'e un groupe dans /etc/group:
276 L'utilisateur bacula, contrairement au {\it daemon} Bacula, aura un
277 r\'epertoire d\'edi\'e (home directory) : {\tt /var/db/bacula} qui est le
278 r\'epertoire standard pour le catalogue de Bacula.
280 A pr\'esent, vous avez un utilisateur et un groupe bacula, et vous pouvez
281 s\'ecuriser le r\'epertoire d\'edi\'e de bacula en utilisant cette commande :
285 chown -R bacula:bacula /var/db/bacula/
289 Celle-ci assure que seul l'utilisateur bacula peut acc\'eder \`a ce
290 r\'epertoire. Elle signifie aussi que si nous ex\'ecutons le Director et le
291 Storage Daemon en tant que bacula, ces {\it daemons} auront aussi des acc\`es
292 restreints. Ce ne serait pas le cas s'ils \'etaient ex\'ecut\'es en tant que
295 Il est important de noter que le Storage Daemon a vraiment besoin
296 d'appartenir au groupe operator pour un acc\`es normal aux lecteurs de bandes.
297 (au moins sur FreeBSD, c'est ainsi que les choses sont configur\'ees par
298 d\'efaut). De tels p\'eriph\'eriques sont en principe attribu\'es \`a
299 root:operator. Il est plus facile et moins dangereux de faire de bacula un
300 membre de ce groupe que de jouer avec les permissions du syst\`eme.
302 D\'emarrer les {\it daemons} bacula
304 Pour d\'emarrer les {\it daemons} bacula sur FreeBSD, utilisez la commande :
308 /usr/local/etc/rc.d/bacula.sh start
312 Pour vous assurer que tous fonctionnent :
316 $ ps auwx | grep bacula
317 root\ 63416\ 0.0\ 0.3\ 2040 1172\ ??\ Ss\ 4:09PM 0:00.01
318 /usr/local/sbin/bacula-sd -v -c /usr/local/etc/bacula-sd.conf
319 root\ 63418\ 0.0\ 0.3\ 1856 1036\ ??\ Ss\ 4:09PM 0:00.00
320 /usr/local/sbin/bacula-fd -v -c /usr/local/etc/bacula-fd.conf
321 root\ 63422\ 0.0\ 0.4\ 2360 1440\ ??\ Ss\ 4:09PM 0:00.00
322 /usr/local/sbin/bacula-dir -v -c /usr/local/etc/bacula-dir.conf