Bonsoir,
 
J'ai chrooté mon Bind9 y a deux jours (sous Lenny), je n'ai pas rencontré de problèmes particulier si ce n'est que mes logs éclatés par la "directive" logging qui ne sont plus alimentés . Au début, j'ai pensé que c'était du au fait qu'ils n'étaient pas dans le jail, mais j'ai vu dans des tutos que c'était possible de faire ainsi. J'ai pas trop envie de les mettre dans ma prison car en cas de hack, ils seront facilement effaçables. Ceci dit, grâce à rsyslog j'ai encore un minimum de log (dans /var/log/syslog) comme vous le voyez mais plus rien pour mes transferts de zone et autres .
 
Pouvez-vous m'aider ?, ça fait deux soirées que je cherche et je ne trouve pas la solution.
 
Voici mes logs :

 
Mes permissions :

Existe t'il un répertoire /var/chroot/bind9/var/log/bind9 ?

Non justement, car j'aimerais qu'il me les met dans /var/log/bind9/ afin d'éviter qu'un hacker y ait accès.

Ici il le fait bien pourtant, il utilise le logging channel de Bind tout comme moi en étant dans un chroot et ses logs vont dans /var/log/named/. Seulement avec moi ça ne va pas.

Apparemment il n'est pas possible de placer les logs en dehors du chroot ... tant pis, je vais m'arranger autrement .
J'aimerais quand même bien savoir comment fait Syslog pour mettre un minimum dans /var/log/syslog

Quand bind démarre, il n'est pas encore chrooté,c'est la raison pour laquelle tu as une partie des logs (le démarrage jusqu'au moment ou bind se chroot).
Par la suite rsyslog ne permet pas d'écouter semble t'il sur un autre socket alors que dans les liens que tu fournis tu dois t'apercevoir que syslogd est configuré afin d'aller directement écouter au niveau du chroot.,  tu n'as simplement pas configuré rsyslog pour écouter dans le chroot.
un  

devrait faire l'affaire. dans un fichier prénommé par exemple  
/etc/rsyslog.d/bind-chroot.conf
 
cf: http://www.dmo.ca/blog/20081009143754/

C'est exactement ce que je fais
Pour le reste, je vais mettre mes logging channels dans mon chroot avec des permissions qui vont bien.
 
Merci

Mes channels fonctionnent
Mais j'ai un nouveau problème, il me charge des zones qui n'existent pas ma classe IP n'est pas 192.0.2 mais 10.1.1.

Ça ne semble pas venir de la clef rndc car je viens d'en générer une nouvelle et c'est pareil.

tu  n'as probablement pas correctement interprété les données fournies par bind9

Je ne comprends pas ce que tu veux dire.

• Concernant rndc

je pense que tu n'as pas correctement configuré la chose. ce qui expliquerait les erreurs lors de l'extinction de bind

• concernant les zones

tu devrais faire attention aux termes employés :
il y a des zones qui sont *automatiquement* chargés par bind : c'est le automatic empty zone dans tes logs.
ce n'est 1) pas grave
             2) configurable (cf doc de bind 9.4)

Mon rndc.conf a été généré par rndc-confgen.
Mon rndc.key contient la partie key "rndc-key" { }; du rndc.conf.
Et j'ai bien la ligne include "/etc/bind/rndc.key" dans mon named.conf

Je ne vois pas où et comment je me suis trompé

Est-ce que tu a precisé dans ta conf. d'envoyer tes log a syslog? Sinon c'est sur qu'il ne les recevera pas et bind s'en occupera.
 
channel syslog { severity info; syslog daemon; print-category yes; print-severity yes; print-time no; };
category default { all; named; syslog; debug; }; etc...

Je ne m'en rappelle plus de tête, je te dirai quoi ce soir, merci.

Ça n'y était pas, voici l'erreur retourné grâce à l'ajout de ta directive.
 

bah le pid existe donc en principe le daemon tourne. Donc kill le et reessaye peut etre ^^

Bonne nouvelle, Bind démarre sans erreur , c'était un problème de permission sur le répertoire run.
Mes zones sont bien chargées d'après mon channel bind.log mais /var/log/syslog continue avec ses "automatic empty zone", je vais chercher dans la doc comme me l'a conseillé Mikala pour voir si y a pas moyen de les virer.
 
J'attends un peu avant de passer mon post en résolu afin de voir si tout est vraiment bon.
 
Un grand merci à vous tous

Mon problème étant résolu, je me pose tout de même des questions sur la sécurité mise en œuvre ...
Mon idée de base était qu'un hacker arrivant a pénétrer dans mon chroot ne puisse pas supprimer les logs. Dans l'état actuel, je pense qu'il le pourrait car il aurait les permissions de l'utilisateur bind car les fichiers logs générés appartiennent à bind:bind, le répertoire /var/log dans le chroot est à root:bind.
 
Est-ce que je me trompe ?
Désolé pour ma paranoïa.

S'il "arrive dans ton chroot" via bind, effectivement il aurait les droits du process. Le process pouvant écrire dans les logs, pourrait effectivement les modifier.
 
=> la solution les exporter en live via le réseau en udp sur un serveur syslog.

Oui , il pourra les effacer facilement... Un chroot n'est pas la pour eviter d'effacer les logs mais pour separer les services entre eux . Cela rends la tache a un "hacker" plus dur pour trouver un moyen d'avoir un compte root sur la machine, car avec un compte utilisateur, il fera pas grand chose, enfin quand meme un peu .
 
Pour garder des logs sur, le mieux, c'est d'envoyer ca un serveur syslog en effet.  
 
Si tu peux pas, tu devrais envoyer tes logs bind vers syslog qui s'en occupera et auront les droit root.root , car la c'est pas secure du tout.

Ok merci à vous deux, je vais regarder à ça

Je vais laisser les logs en locale pour le moment, si je veux déporter mes logs en dehors du chroot avec des droits root:root et splités. Je ne vois qu'une solution c'est de rediriger /var/chroot/.../dev/log vers syslog-ng et les faire spliter par lui même via des filtres.
 
Mais bien sûr ça aurait été trop beau que ça aille du premier coup alors Mr Syslog-ng se plaint dès le début :

Apparemment du au fait qu'il y ait deux sources : source s_all et source s_bind9 écoutant chacun sur un fichier /dev/log. Si j'ajoute ma directive unix-stream("/var/chroot/bind9/dev/log" ); à s_all, c'est pareil si on ne peut écouter qu'un seul flux je trouve ça très mal foutu ...

Je n'ai pas trop envie de me prendre la tête à chercher à résoudre le problème pendant une semaine. Donc je vais directement passé par l'étape serveur de log malgré que je voulais mettre cela à plus tard.