[Résolu] Problème de logging depuis chrootage

Problème de logging depuis chrootage [Résolu] - Installation - Linux et OS Alternatifs

Marsh Posté le 09-07-2009 à 21:27:09    

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 :
http://gopix.fr/image-EDA7_4A563DD0.jpg
 
Mes permissions :

Code :
  1. orbis-2:/var/chroot# tree -pug
  2. .
  3. `-- [drwxr-xr-x root     root    ]  bind9
  4.     |-- [drwxr-xr-x root     root    ]  dev
  5.     |   |-- [srw-rw-rw- root     root    ]  log
  6.     |   |-- [crw-r--rw- root     root    ]  null
  7.     |   `-- [crw-r--rw- root     root    ]  random
  8.     |-- [drwxr-xr-x root     root    ]  etc
  9.     |   `-- [drwxr-sr-x root     bind    ]  bind
  10.     |       |-- [-rw-r--r-- root     root    ]  db.0
  11.     |       |-- [-rw-r--r-- root     root    ]  db.127
  12.     |       |-- [-rw-r--r-- root     root    ]  db.255
  13.     |       |-- [-rw-r--r-- root     root    ]  db.empty
  14.     |       |-- [-rw-r--r-- root     root    ]  db.local
  15.     |       |-- [-rw-r--r-- root     root    ]  db.root
  16.     |       |-- [-rw-r--r-- root     bind    ]  named.conf
  17.     |       |-- [-rw-r--r-- root     bind    ]  named.conf.local
  18.     |       |-- [-rwxr-xr-x root     bind    ]  named.conf.options
  19.     |       |-- [-rw-r----- bind     bind    ]  rndc.key
  20.     |       `-- [-rw-r--r-- root     root    ]  zones.rfc1918
  21.     `-- [drwxr-xr-x root     root    ]  var
  22.         |-- [drwxr-xr-x bind     bind    ]  cache
  23.         |   `-- [drwxr-xr-x root     root    ]  bind
  24.         |       |-- [-rwxr-xr-x root     root    ]  db.0
  25.         |       |-- [-rwxr-xr-x root     root    ]  db.127
  26.         |       |-- [-rwxr-xr-x root     root    ]  db.255
  27.         |       |-- [-rwxr-xr-x root     root    ]  db.empty
  28.         |       |-- [-rwxr-xr-x root     root    ]  db.local
  29.         |       |-- [-rwxr-xr-x root     root    ]  db.root
  30.         |       |-- [-rwxr-xr-x root     root    ]  ns.1.1.10.db
  31.         |       |-- [-rwxr-xr-x root     root    ]  ns.1.1.10.rev
  32.         |       |-- [-rwxr-xr-x root     root    ]  ns.toto.net
  33.         |       `-- [-rwxr-xr-x root     root    ]  ns.titi.be
  34.         `-- [drwxr-xr-x bind     bind    ]  run
  35.             `-- [drwxr-xr-x bind     bind    ]  bind
  36.                 `-- [drwxr-xr-x bind     bind    ]  run
  37.                     `-- [-rw-r--r-- bind     bind    ]  named.pid
  38. orbis-2:/var# ls -l /var/log/
  39. drwxr-xr-x 2 bind        bind    4096 mai 21 11:13 bind9


Message édité par Gavrinis le 28-08-2009 à 15:36:41
Reply

Marsh Posté le 09-07-2009 à 21:27:09   

Reply

Marsh Posté le 09-07-2009 à 21:43:08    

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


---------------
Intermittent du GNU
Reply

Marsh Posté le 09-07-2009 à 22:01:58    

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

Reply

Marsh Posté le 09-07-2009 à 22:12:25    

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.

Reply

Marsh Posté le 12-07-2009 à 18:33:37    

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

Reply

Marsh Posté le 12-07-2009 à 19:12:03    

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  

Citation :

$AddUnixListenSocket /var/chroot/bind9/dev/log
 
 


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


Message édité par mikala le 12-07-2009 à 19:16:39

---------------
Intermittent du GNU
Reply

Marsh Posté le 12-07-2009 à 19:20:10    

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 :jap:

Reply

Marsh Posté le 12-07-2009 à 20:58:26    

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.

 
Code :
  1. orbis-2:/# /etc/init.d/bind9 restart
  2. Stopping domain name service...: bind9
  3. rndc: connect failed: 127.0.0.1#953: connection refused
  4. .
  5. Starting domain name service...: bind9 failed!
  6. orbis-2:/# !grep
  7. grep named /var/log/syslog | tail
  8. Jul 12 20:41:53 orbis-2 named[3538]: automatic empty zone: 2.0.192.IN-ADDR.ARPA
  9. Jul 12 20:41:53 orbis-2 named[3538]: automatic empty zone: 255.255.255.255.IN-ADDR.ARPA
  10. Jul 12 20:41:53 orbis-2 named[3538]: automatic empty zone: 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
  11. Jul 12 20:41:53 orbis-2 named[3538]: automatic empty zone: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
  12. Jul 12 20:41:53 orbis-2 named[3538]: automatic empty zone: D.F.IP6.ARPA
  13. Jul 12 20:41:53 orbis-2 named[3538]: automatic empty zone: 8.E.F.IP6.ARPA
  14. Jul 12 20:41:53 orbis-2 named[3538]: automatic empty zone: 9.E.F.IP6.ARPA
  15. Jul 12 20:41:53 orbis-2 named[3538]: automatic empty zone: A.E.F.IP6.ARPA
  16. Jul 12 20:41:53 orbis-2 named[3538]: automatic empty zone: B.E.F.IP6.ARPA
  17. Jul 12 20:41:53 orbis-2 named[3538]: command channel listening on 127.0.0.1#953


Message édité par Gavrinis le 12-07-2009 à 21:12:42
Reply

Marsh Posté le 12-07-2009 à 22:02:28    

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

Reply

Marsh Posté le 13-07-2009 à 01:39:03    

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


---------------
Intermittent du GNU
Reply

Marsh Posté le 13-07-2009 à 01:39:03   

Reply

Marsh Posté le 13-07-2009 à 09:45:58    

Je ne comprends pas ce que tu veux dire.

Reply

Marsh Posté le 13-07-2009 à 12:13:09    

  • 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)


---------------
Intermittent du GNU
Reply

Marsh Posté le 13-07-2009 à 12:46:15    

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é :sweat:


Message édité par Gavrinis le 13-07-2009 à 12:47:09
Reply

Marsh Posté le 13-07-2009 à 13:12:13    

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...

Reply

Marsh Posté le 13-07-2009 à 14:03:02    

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

Reply

Marsh Posté le 13-07-2009 à 19:08:53    

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

Code :
  1. 13-Jul-2009 18:56:03.022 general: critical: couldn't open pid file '/var/run/bind/run/named.pid': File exists
  2. 13-Jul-2009 18:56:03.023 general: critical: exiting (due to early fatal error)
Code :
  1. .
  2. |-- [drwxr-xr-x root     root    ]  var
  3. |   |-- [drwxr-xr-x root     bind    ]  run
  4. |   |   `-- [drwxr-xr-x root     bind    ]  bind
  5. |   |       `-- [drwxr-xr-x root     bind    ]  run
  6. |   |           `-- [-rwxrwxr-x root     bind    ]  named.pid

Reply

Marsh Posté le 13-07-2009 à 19:29:36    

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

Reply

Marsh Posté le 13-07-2009 à 19:39:04    

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 :hello:

Reply

Marsh Posté le 14-07-2009 à 13:16:04    

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.

Reply

Marsh Posté le 14-07-2009 à 14:40:35    

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.


---------------
Relax. Take a deep breath !
Reply

Marsh Posté le 14-07-2009 à 15:19:39    

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.

Reply

Marsh Posté le 14-07-2009 à 15:49:06    

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

Reply

Marsh Posté le 14-07-2009 à 22:24:05    

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 :

Code :
  1. Starting system logging: syslog-ngError binding socket; addr='AF_UNIX(/var/chroot/bind9/dev/log)', error='Address already in use (98)'
  2. Error initializing source driver; source='s_bind9'


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 ...

Reply

Marsh Posté le 15-07-2009 à 08:51:02    

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.

Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed