Depuis les tous premiers stades de Bacula (janvier 2000) jusqu'à aujourd'hui (Décembre 2005), Bacula a connu deux formats majeurs d'écriture sur les cartouches. Le second format a été introduit dans la version 1.27 en novembre 2002, et n'a pas changé depuis. En principe, Bacula devrait encore pouvoir lire le format d'origine, mais j'avoue ne pas avoir essayé depuis longtemps...
Bien que le format des cartouches soit fixé, les types de données qui peuvent être écrites sur les cartouches sont extensibles, ce qui nous a permis d'ajouter de nouvelles fonctionnalités telles que les ACLs, les données Win32, les données chiffrées... Naturellement, une ancienne version de Bacula ne saurait lire des nouveaux flux de données, mais chaque nouvelle version de Bacula est en principe capable de lire les anciens flux.
Si vous voulez être absolument certain de pouvoir lire vos vieilles cartouches, vous devriez :
1. Essayer de lire les vieilles cartouches de temps en temps, une fois par an par exemple.
2. Conserver une copie statiquement liée de chaque version de Bacula que vous avez utilisée en production. Ainsi, si pour quelque raison nous venions à abandonner la compatibilité avec les anciens formats de cartouches, vous pourriez toujours remettre en service une vieille copie de Bacula...
Le second point est probablement excessif, en toute rigueur, il pourrait vous sauver un jour.
Les TCP Wrappers sont implémentés si vous les activez lors de la
configuration (./configure :--:with-tcp-wrappers). Avec ce code activé, vous
pourrez contrôler qui peut accéder à vos daemons. Ce contrôle
est obtenu par la modification du fichier /etc/hosts.allow. Le nom de
programme qu'utilise Bacula pour appliquer ces restrictions est celui
que vous avez spécifié dans le fichier de configuration du daemon.
Vous ne devez pas utiliser l'option twist dans votre /etc/hosts.allow car elle stopperait les daemons Bacula lorsqu'une
connection est refusée.
Le nom exact du paquet requis pour compiler avec le support TCP wrappers dépend du système. Il s'agit, par exemple, de tcpd-devel sur SuSE, et de tcp_wrappers sur RedHat.
Dan Langille 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ée twist. Cette option remplace le processus courant par une instance de la commande shell spécifiée. Voici un exemple typique de son utilisation :
ALL : ALL \ : severity auth.info \ : twist /bin/echo "Vous n'\^etes pas autoris\'e \`a utiliser %d depuis %h."
Le code libwrap tente d'éviter twist s'il est exécuté dans un processus résident. Il en résulte que le processus (e.g. bacula-fd, bacula-sd, bacula-dir) sera stoppé si la première connection à son port provoque l'invocation de l'option twist. Le risque est qu'une attaque provoque l'arrêt des daemons. Cette situation est évitée si votre fichier /etc/hosts.allow contient un jeu de règles approprié. L'exemple suivant est suffisant :
undef-fd : localhost : allow undef-sd : localhost : allow undef-dir : localhost : allow undef-fd : ALL : deny undef-sd : ALL : deny undef-dir : ALL : deny
Vous devez accorder les noms des daemons à ceux spécifiés dans leurs fichiers de configuration respectifs. Ce ne sont, en général, pas les noms des fichiers binaires des daemons. Il n'est pas possible d'utiliser les noms des binaires car plusieurs daemons peuvent être exécutés sur une machine avec des fichiers de configuration distincts.
Dans ces exemples, le Director est undef-dir, le Storage Daemon est undef-sd, et le File Daemon est undef-fd. Ajustez ces noms pour qu'ils conviennent à votre configuration. L'exemple de règles ci-dessus suppose que SD, FD et DIR sont tous sur la même machine. Si vous avez un client FD distant, il vous suffira de placer le jeu de règles suivant sur ce client :
undef-fd : director.example.org : allow undef-fd : ALL : deny
Où director.example.org est l'hôte 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ésente) n'est pas invoquée. Pour tester correctement votre configuration, démarrez le(s) daemon(s), puis essayez de vous y connecter depuis une adresse IP qui devrait être capable de le faire. Vous devriez voir quelque chose comme :
$ telnet undef 9103 Trying 192.168.0.56... Connected to undef.example.org. Escape character is '^]'. Connection closed by foreign host. $
C'est la réponse correcte. Si vous voyez ceci :
$ 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. $
Alors, twist a été invoquée, et votre configuration est incorrecte. vous devez ajouter la directive "deny". Il est important de noter que vos tests doivent inclure le redémarrage des daemons après chaque tentative de connexion. Vous pouvez aussi tcpdchk(8) et tcpdmatch(8) pour valider jeu de règles /etc/hosts.allow. Voici un test simple avec tcpdmatch :
$ 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
Si vous exécutez Bacula en tant que standalone daemon, les avertissements ci-dessus peuvent être ignorés sans scrupules. Voici un exemple qui révèle que "deny" fait defaut à vos règles, et que l'option twist a été invoquée.
$ 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
Voici quelques recommandations de Dan Languille :
C'est une bonne idée d'exécuter vos daemons avec des privilèges aussi faibles que possible. En d'autres termes, si vous pouvez, n'exécutez pas d'applications en tant que root si elle n'ont pas besoin d'être exécutées en tant que root. Le Storage Daemon et le Director Daemon n'ont pas besoin d'être exécutés en tant que root. Le File Daemon en a besoin pour accéder à l'ensemble des fichiers du système. Pour vous passer des privilèges root, il vous faut créer un utilisateur et un groupe. Choisir bacula pour l'un et l'autre me semble une bonne idée.
Le port FreeBSD crée cet utilisateur et ce groupe pour vous. (En fait, au moment ou j'écris ces lignes, ce n'est pas encore le cas, mais ça le sera bientôt). Voici à quoi ressemblent ces entrées sur mon portable FreeBSD :
bacula:*:1002:1002::0:0:Bacul Daemon:/var/db/bacula:/sbin/nologin
J'ai utilisé vipw pour créer ces entrées. J'ai utilisé un User ID et un Group ID disponibles sur mon système : 1002.
J'ai aussi créé un groupe dans /etc/group:
bacula:*:1002:
L'utilisateur bacula, contrairement au daemon Bacula, aura un répertoire dédié (home directory) : /var/db/bacula qui est le répertoire standard pour le catalogue de Bacula.
A présent, vous avez un utilisateur et un groupe bacula, et vous pouvez sécuriser le répertoire dédié de bacula en utilisant cette commande :
chown -R bacula:bacula /var/db/bacula/
Celle-ci assure que seul l'utilisateur bacula peut accéder à ce répertoire. Elle signifie aussi que si nous exécutons le Director et le Storage Daemon en tant que bacula, ces daemons auront aussi des accès restreints. Ce ne serait pas le cas s'ils étaient exécutés en tant que root.
Il est important de noter que le Storage Daemon a vraiment besoin d'appartenir au groupe operator pour un accès normal aux lecteurs de bandes. (au moins sur FreeBSD, c'est ainsi que les choses sont configurées par défaut). De tels périphériques sont en principe attribués à 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ème.
Démarrer les daemons bacula
Pour démarrer les daemons bacula sur FreeBSD, utilisez la commande :
/usr/local/etc/rc.d/bacula.sh start
Pour vous assurer que tous fonctionnent :
$ 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