Initial revision

[bacula/docs] / docs / manual-fr / security.tex

%%
%%

\section*{Consid\'erations sur la s\'ecurit\'e de Bacula}
\label{_ChapterStart14}
\index[general]{Bacula!Consid\'erations sur la s\'ecurit\'e de }
\index[general]{Consid\'erations sur la s\'ecurit\'e de Bacula }
\addcontentsline{toc}{section}{Consid\'erations sur la s\'ecurit\'e de Bacula}

\begin{itemize}
\item Le client ({\bf bacula-fd}) doit \^etre ex\'ecut\'e en tant que root
   afin d'avoir  l'acc\`es \`a tous les fichiers du syst\`eme. 
\item Il n'est pas n\'ecessaire d'ex\'ecuter le Director en tant que root. 
\item Il n'est pas n\'ecessaire d'ex\'ecuter le Storage Daemon en tant que
   root, mais  vous devez vous assurer qu'l peut utiliser le lecteur de bandes,
   dont l'acc\`es  est presque toujours r\'eserv\'e \`a root par d\'efaut.
\item 
\item Vous devriez restreindre l'acc\`es au fichiers de configuration de
   Bacula, de  sorte que les mots de passe ne soient pas lisibles par tous.  Les
   {\it daemons} {\bf Bacula} sont prot\'eg\'es par des mots de passe et CRAM-MD5
(i.e. les mots de passe ne sont pas envoy\'es sur le r\'eseau). Ceci assur
que tout le  monde ne peut acc\'eder aux {\it daemons}. C'est une protection
raisonnablement bonne,  mais qui peut \^etre craqu\'e par un expert. 
\item Si vous utilisez les ports recommand\'es 9101,9102 et 9103, vous voudrez
   probablement  prot\'eger ces ports des acc\`es externes \`a l'aide d'un
   firewall et/ou en utilisant  tcp wrappers ({\bf etc/hosts.allow}).  
\item Actuellement, toutes les donn\'es sont envoy\'ees sur le r\'eseau sans
   chiffrage. Par  cons\'equent, \`a moins que vous n'utilisiez {\bf ssh} ou {\bf
   stunnel} pour la  transmission de port (port forwarding), il n'est pas
recommand\'e de faire des  sauvegardes \`a travers un r\'eseau non
s\'ecuris\'e (par exemple, Internet). Nous  pr\'evoyons d'int\'egrer le
chiffrage {\bf ssl} dans une version future.  
\item Vous devriez vous assurer que seuls les {\it daemons} de Bacula ont
   acc\`es  en lecture et \'ecriture aux r\'epertoires de travail de Bacula.  
\item Si vous utilisez {\bf MySQL}, il n'est pas n\'ecessaire de l'ex\'ecuter
   en tant que root  
\item Le script par d\'efaut de Bacula {\bf grant-mysql-permissions} accorde
   toutes les  permissions d'utilisation de la base de donn\'ees MySQL sans mot
   de passe. Si vous  voulez la s\'ecurit\'e, affinez ceci !  
\item N'oubliez pas que Bacula est un programme r\'eseau, ainsi quiconque sur
   le r\'eseau  dispose du programme console et du mot de passe du Director peut
   acc\'eder \`a  Bacula et aux donn\'ees sauvegard\'ees.  
\item Vous pouvez restreindre les adresses IP avec auxquelles Bacula se
   connectera en  utilisant les enregistrements appropri\'es {\bf DirAddress},
   {\bf FDAddress},  ou {\bf SDAddress} dans les fichiers de configurations
respectifs des {\it daemons}  
\end{itemize}

\label{wrappers}

\subsection*{Configurer et tester TCP Wrappers avec Bacula}
\index[general]{Configurer et tester TCP Wrappers avec Bacula }
\index[general]{Bacula!Configurer et tester TCP Wrappers avec }
\addcontentsline{toc}{subsection}{Configurer et tester TCP Wrappers avec
Bacula}

Les TCP Wrappers sont impl\'ement\'es si vous les activez lors de la
configuration ({\bf ./configure \verb{--{with-libwrap}). Avec ce code activ\'e, vous
pourrez contr\^oler qui peut acc\'eder \`a vos {\it daemons}. Ce contr\^ole
est obtenu par la modification du fichier {\bf /etc/hosts.allow}. Le nom de
programme qu'utilise {\bf Bacula} pour appliquer ces restrictions est celui
que vous avez sp\'ecifi\'e dans le fichier de configuration du {\it daemon}.
Vous ne devez pas utiliser l'option {\bf twist} dans votre {\bf
/etc/hosts.allow} car elle stopperait les {\it daemons} Bacula lorsqu'une
connection est refus\'ee. 

Dan Languille a fourni les informations suivantes concernant la configuration
et les tests de TCP Wrappers avec Bacula. 

Si vous lisez hosts\_options(5), vous verrez une option nomm\'ee twist. Cette
option remplace le processus courant par une instance de la commande shell
sp\'ecifi\'ee. Ce qui suit est un exemple typique de son utilisation : 

\footnotesize
\begin{verbatim}
ALL : ALL \
 : severity auth.info \
 : twist /bin/echo "Vous n'\^etes pas autoris\'e \`a utiliser %d depuis %h."
\end{verbatim}
\normalsize

\label{question-1}
{\bf question 1} Le code libwrap tente d'\'eviter {\bf twist} s'il est
ex\'ecut\'e dans un processus r\'esident (i.e. , mais ce test ne prot\'egera
pas le premier appel hosts\_access(). Il en r\'esulte que le processus (e.g.
bacula-fd, bacula-sd, bacula-dir) sera stopp\'e si la premi\`ere connection
\`a son port provoque l'invocation de l'option twist. Le risque est qu'une
attaque provoque l'arr\^et des {\it daemons}. 

The libwrap code tries to avoid {\bf twist} if it runs in a resident process,
but that test will not protect the first hosts\_access() call. This will
result in the prcess (e.g. bacula-fd, bacula-sd, bacula-dir) being terminated
if the first connection to their port results in the twist option being
invoked. The potential, and I stree potential, exists for an attacker to
prevent the daemons from running. Cette situation est \'evit\'ee si votre
fichier /etc/hosts.allow contient un jeu de r\`egles appropri\'e. L'exemple
suivant est suffisant : 

\footnotesize
\begin{verbatim}
undef-fd : localhost : allow
undef-sd : localhost : allow
undef-dir : localhost : allow
undef-fd : ALL : deny
undef-sd : ALL : deny
undef-dir : ALL : deny
\end{verbatim}
\normalsize

Vous devez accorder les noms des {\it daemons} \`a ceux de leurs fichiers de
configuration respectifs. Dans ces exemples, le Director est undef-dir, le
Storage Daemon est undef-sd, et le File Daemon est undef-fd. Ajustez pour
coller \`a votre configuration. L'exemple de r\`egles ci-dessus suppose que
SD, FD et DIR sont tous sur la m\^eme machine. Si vous avez un client FD
distant, il vous suffira de placer le jeu de r\^egles suivant sur ce client : 

\footnotesize
\begin{verbatim}
undef-fd : director.example.org : allow
undef-fd : ALL : deny
\end{verbatim}
\normalsize

O\`u director.example.org est l'h\^ote qui contactera le client (i.e. la
machine sur laquelle le Bacula Director tourne). L'usage de ``ALL : deny''
assure que l'option twist (si pr\'esente) n'est pas invoqu\'ee. Pour tester
correctement votre configuration, d\'emarrez le(s) {\it daemon(s)}, puis
essayez de vous y connecter depuis une adresse IP qui devrait \^etre capable
de le faire. Vous devriez voir quelque chose comme : 

\footnotesize
\begin{verbatim}
$ telnet undef 9103
Trying 192.168.0.56...
Connected to undef.example.org.
Escape character is '^]'.
Connection closed by foreign host.
$
\end{verbatim}
\normalsize

C'est la r\'eponse correcte. Si vous voyez ceci : 

\footnotesize
\begin{verbatim}
$ telnet undef 9103
Trying 192.168.0.56...
Connected to undef.example.org.
Escape character is '^]'.
You are not welcome to use undef-sd from xeon.example.org.
Connection closed by foreign host.
$
\end{verbatim}
\normalsize

Alors, twist a \'et\'e invoqu\'ee, et votre configuration est incorrecte. vous
devez ajouter la directive ``deny''. Il est important de noter que vos tests
doivent inclure le red\'emarrage des {\it daemons} apr\`es chaque tentative de
connexion. Vous pouvez aussi tcpdchk(8) et tcpdmatch(8) pour valider jeu de
r\`egles /etc/hosts.allow. Voici un test simple avec tcpdmatch : 

\footnotesize
\begin{verbatim}
$ tcpdmatch undef-dir xeon.example.org
warning: undef-dir: no such process name in /etc/inetd.conf
client: hostname xeon.example.org
client: address 192.168.0.18
server: process undef-dir
matched: /etc/hosts.allow line 40
option: allow
access: granted
\end{verbatim}
\normalsize

Si vous ex\'ecutez Bacula en tant que {\it standalone daemon}, les
avertissements ci-dessus peuvent \^etre ignor\'es sans scrupules. Voici un
exemple qui r\'ev\`ele que ``deny'' fait defaut \`a vos r\`egles, et que
l'option twist a \'et\'e invoqu\'ee. 

\footnotesize
\begin{verbatim}
$ tcpdmatch undef-dir 10.0.0.1
warning: undef-dir: no such process name in /etc/inetd.conf
client: address 10.0.0.1
server: process undef-dir
matched: /etc/hosts.allow line 91
option: severity auth.info
option: twist /bin/echo "You are not welcome to use
  undef-dir from 10.0.0.1."
access: delegated
\end{verbatim}
\normalsize

\subsection*{Executer Bacula sans \^etre root}
\index[general]{Root!Executer Bacula sans \^etre }
\index[general]{Executer Bacula sans \^etre root }
\addcontentsline{toc}{subsection}{Executer Bacula sans \^etre root}

Un conseil de s\'ecurit\'e de Dan Languille: 

C'est une bonne id\'ee d'ex\'ecuter vos {\it daemons} avec des  privil\`eges
aussi faibles que possible. En d'autres termes,  si vous pouvez, n'ex\'ecutez
pas d'applications en tant que root  si elle n'ont pas besoin d'\^etre
ex\'ecut\'ees en tant que root.  Le Storage Daemon et le Director Daemon n'ont
pas besoin  d'\^etre ex\'ecut\'es en tant que root. Le File Daemon en a besoin
pour acc\'eder  \`a l'ensemble des fichiers du syst\`eme. Pour vous passer des
privil\`eges  root, il vous faut cr\'eer un utilisateur et un groupe. Choisir
{\tt bacula}  pour l'un et l'autre me semble une bonne id\'ee.  

Le port FreeBSD cr\'ee cet utilisateur et ce groupe pour vous. (En fait, au
moment  ou j'\'ecris ces lignes, ce n'est pas encore le cas, mais {\c c}a le
sera bient\^ot).  Voici \`a quoi ressemblent ces entr\'ees sur mon portable
FreeBSD : 

\footnotesize
\begin{verbatim}
bacula:*:1002:1002::0:0:Bacul Daemon:/var/db/bacula:/sbin/nologin
\end{verbatim}
\normalsize

J'ai utilis\'e vipw pour cr\'eer ces entr\'ees. J'ai utilis\'e un User ID et
un Group ID  disponibles sur mon syst\`eme : 1002.  

J'ai aussi cr\'e\'e un groupe dans /etc/group:  

\footnotesize
\begin{verbatim}
bacula:*:1002:
\end{verbatim}
\normalsize

L'utilisateur bacula, contrairement au {\it daemon} Bacula, aura un 
r\'epertoire d\'edi\'e (home directory) : {\tt /var/db/bacula}  qui est le
r\'epertoire standard pour le catalogue de Bacula.  

A pr\'esent, vous avez un utilisateur et un groupe bacula, et vous pouvez 
s\'ecuriser le r\'epertoire d\'edi\'e de bacula en utilisant cette commande : 

\footnotesize
\begin{verbatim}
chown -R bacula:bacula /var/db/bacula/
\end{verbatim}
\normalsize

Celle-ci assure que seul l'utilisateur bacula peut acc\'eder \`a ce
r\'epertoire.  Elle signifie aussi que si nous ex\'ecutons le Director et le
Storage Daemon  en tant que bacula, ces {\it daemons} auront aussi des acc\`es
restreints.  Ce ne serait pas le cas s'ils \'etaient ex\'ecut\'es en tant que
root.  

Il est important de noter que le Storage Daemon a vraiment besoin 
d'appartenir au groupe operator pour un acc\`es normal aux lecteurs de bandes.
(au moins sur FreeBSD, c'est ainsi que les choses sont configur\'ees par
d\'efaut).  De tels p\'eriph\'eriques sont en principe attribu\'es \`a
root:operator. Il est plus  facile et moins dangereux de faire de bacula un
membre de ce groupe que de jouer  avec les permissions du syst\`eme. 

D\'emarrer les {\it daemons} bacula 

Pour d\'emarrer les {\it daemons} bacula sur FreeBSD, utilisez la commande : 

\footnotesize
\begin{verbatim}
/usr/local/etc/rc.d/bacula.sh start
\end{verbatim}
\normalsize

Pour vous assurer que tous fonctionnent : 

\footnotesize
\begin{verbatim}
$ ps auwx | grep bacula
root\ 63416\ 0.0\ 0.3\ 2040 1172\ ??\ Ss\ 4:09PM 0:00.01
    /usr/local/sbin/bacula-sd -v -c /usr/local/etc/bacula-sd.conf
root\ 63418\ 0.0\ 0.3\ 1856 1036\ ??\ Ss\ 4:09PM 0:00.00
    /usr/local/sbin/bacula-fd -v -c /usr/local/etc/bacula-fd.conf
root\ 63422\ 0.0\ 0.4\ 2360 1440\ ??\ Ss\ 4:09PM 0:00.00
    /usr/local/sbin/bacula-dir -v -c /usr/local/etc/bacula-dir.conf
\end{verbatim}
\normalsize