Considérations sur la sécurité de Bacula

Configurer et tester TCP Wrappers avec Bacula

Les TCP Wrappers sont implémentés si vous les activez lors de la configuration (./configure --with-libwrap). 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.

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ée twist. Cette option remplace le processus courant par une instance de la commande shell spécifiée. Ce qui suit est un exemple typique de son utilisation :

ALL : ALL \
 : severity auth.info \
 : twist /bin/echo "Vous n'êtes pas autorisé à utiliser %d depuis %h."

question 1 Le code libwrap tente d'éviter twist s'il est exécuté dans un processus résident, mais ce test ne protégera pas le premier appel hosts_access(). 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.

The libwrap code tries to avoid 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 é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 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 à 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

question 2 Ne faudrait-il pas aussi une règle sur le serveur autorisant ce client à connecter le FD ? 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

Executer Bacula sans être root

Un conseil de sécurité 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 libre 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