Problème avec apache 2 et bind

Support Debian
#1

Bonjour,
J’ai un problème avec mon serveur, tous les dimanches à la même heure, apache 2 s’arrête pour je pense faire la rotation des fichiers de log, et il ne redemarre pas correctement.
J’ai une erreur me disant que apache ne peut pas écouter sur les ports 443 et 80.
Hors quand je fait un “netstat -pan”, je vois que le service named “squatte” ces ports et empeche donc apache de les utiliser.

Est ce que quelqu’un aurait une explication de pourquoi lorsque le serveur faut la rotation des fichiers de log le service named va-t-il occuper les ports 443 et 80, empechant apache de fonctionner par la même occasion ?

Merci d’avance pour vos réponse

#2

tu es sur que ce n’est pas un rootkit qui se ferait passer pour un named ?
tu as essayé de voir ce que servait ce named sur les ports 443 et 80, avec telnet ou un browser web ?
Quand tu fais un apache stop, combien de temps faut il pour que ton “named” s’accapare les ports ?

#3

Premierement je ne sais pas du tout d’où vient le problème, et le premier truc que je me suis dit c’est que je m’étais chopé un rootkit … mais je ne sais pas comment detecter ce rootkit (si il y a) …

Deuxièmement quand je fais “apache stop”, mes ports ne sont pas accaparés par named … c’est seulement lorsqu’il y a la rotation hebdomadaire de log que named s accapare des ports …

Et non je n’ai pas testé en telnet ce qu’il y a sur les ports 443 et 80 lorsque bind s en accapare, par contre avec un web browser, je n’ai absolument rien.

Merci de ta réponse

#4

déjà, tu peux faire une detection de rootkit avec chkrootkit, et/ou rkhunter.
Ceci etant dit, s’il detecte quelquechose, pas la peine de réparer, il vaut mieux réinstaller.
Sinon, il faudrait vraiment se connecter sur les ports en telnet, pour voir ce qui répond. Et essayer en ssh, aussi.

#5

Avec un rkhunter, la seule erreur que je peux avoir est :

Scanning for hidden files… [ Warning! ]

/dev/.udevdb /etc/.pwd.lock

Please inspect: /dev/.udevdb (directory)

Sinon pour tester le telnet, il faut que j’attende la semaine prochaine que j’ai une rotation des logs …

#6

Pour provoquer l’operation, changes la date de la machine pour provoquer le logrotate, ou bien trouves dans cron.d ce qui le provoque.
Le message sur udev n’est pas un rk.

#7

Et avec chkrootkit je n’ai aucune erreur …

#8

Voila ce que j’ai dans cron :
[ul]crontab

cron.d:
amavisd-new php4 php5

cron.daily:
5snort* bsdmainutils* exim4-base* logrotate* modutils* netkit-inetd* rkhunter* squirrelmail* sysklogd*
amavisd-new* chkrootkit* find* man-db* mysql-server* ntp-server* samba* standard*

cron.hourly:

cron.monthly:
scrollkeeper* standard*

cron.weekly:
lpr* man-db* ntp-server* rkhunter* sysklogd*
[/ul]

Je ne vois aparaitre ni apache, ni bind … sont-ils stockés ailleurs ???

#9

Ayé j’ai trouvé pour apache2, dans logrotate.d j’ai les fichiers suivants :
[ul]apache2 aptitude base-config cupsys dpkg exim4-base mysql-server ppp samba scrollkeeper snort vsftpd[/ul]

Mais pas de bind, ni named …

#10

Bon, ben c’est peut être une fonctionnalité d’apache lui même, peut être dans la config y a t il des optionsde programmation pour la rotation des logs, non ?
Donc eventuellement, alors, regardes le fonctionnement/la configuration du logrotate.
Au fait, as tu toi même installé un bind ?

#11

Dans le fichier logrotate d’apache 2, j’ai le code suivant :

/var/log/apache2/*.log { weekly missingok rotate 52 compress delaycompress notifempty create 640 root adm sharedscripts postrotate if [ -f /var/run/apache2.pid ]; then /etc/init.d/apache2 restart > /dev/null fi endscript }

Et pour bind, je l’ai installé avec un “apt-get install bind9”

Le truc qui est bizar c’est que j’ai ce problème que depuis 3 semaines, et avant aucun problème depuis l’installation du serveur qui a eu lieu il y a 6 mois … alors peut etre que lors d’un “apt-get upgrade”, des fichiers de config ce sont mis en conflit ???

#12

c’est possible.
Ce qui est bizarre, c’est que le restart du serveur apache ne se produit qu’en fin de logrotate, et sous la forme d’un appel au “restart” du script init…
Donc je ne vois pas pourquoi ça provoquerait un attachement du “bind” à ce moment là, alors que quand tu lances toi même le restart, ça ne provoque rien.
C’est vraiment déroutant.