[tomlelab]

Bonjour
je possède un serveur dédié qui fonctionne sous linux / plesk.

Suite à 3 plantages répétés en moins d'une heure, ma machine sétait éteinte, je regarde via ssh les messages.
en faisant tail -f /var/log/messages
et je vois ceci:

Nov 16 16:21:01 ns303027 kernel: Firewall: *UDP_OUT Blocked* IN= OUT=eth0 SRC=94.23.203.196 DST=94.23.203.251 LEN=54 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=52812 DPT=6154 LEN=34
Nov 16 16:22:01 ns303027 kernel: Firewall: *UDP_OUT Blocked* IN= OUT=eth0 SRC=94.23.203.196 DST=94.23.203.251 LEN=42 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=56483 DPT=6110 LEN=22
Nov 16 16:22:01 ns303027 kernel: Firewall: *UDP_OUT Blocked* IN= OUT=eth0 SRC=94.23.203.196 DST=94.23.203.251 LEN=44 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=43535 DPT=6148 LEN=24
Nov 16 16:22:01 ns303027 kernel: Firewall: *UDP_OUT Blocked* IN= OUT=eth0 SRC=94.23.203.196 DST=94.23.203.251 LEN=57 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=59691 DPT=6187 LEN=37
Nov 16 16:22:01 ns303027 kernel: Firewall: *UDP_OUT Blocked* IN= OUT=eth0 SRC=94.23.203.196 DST=94.23.203.251 LEN=54 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=41209 DPT=6138 LEN=34
Nov 16 16:22:01 ns303027 kernel: Firewall: *UDP_OUT Blocked* IN= OUT=eth0 SRC=94.23.203.196 DST=94.23.203.251 LEN=55 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=50624 DPT=6185 LEN=35

Qu'est ce qui est bloqué au juste ? est ce que ça aurait un rapport avec mes plantages ?

Mes pistes: derniers évènements récents concernant ma machine:
--> plesk n'arrive pas à mettre à jour sa key update
--> j'ai fait une mise à jour sur mon forum afin de permettre d'uploader des pièces jointes

J'aurais bien aimé avoir quelques avis, afin de m'aiguiller dans la bonne direction et éviter que ça ne replante.

Merci

[Kioob]

Bonjour,

je ne suis pas forcément un expert en sécurité, mais visiblement ton serveur test des ports UDP sur le serveur 94.23.203.251. C'est pas bon signe du tout (à moins que tu utilises une application spécifique qui s'amuserait avec l'UDP ?), à mon avis ton serveur est utilisé pour scanner le réseau OVH ; et si c'est bien le cas OVH ne devrait pas tarder à la couper.

[tomlelab]

Kioob, le 16 novembre 2009 - 17:00, dit :

Bonjour,

je ne suis pas forcément un expert en sécurité, mais visiblement ton serveur test des ports UDP sur le serveur 94.23.203.251. C'est pas bon signe du tout (à moins que tu utilises une application spécifique qui s'amuserait avec l'UDP ?), à mon avis ton serveur est utilisé pour scanner le réseau OVH ; et si c'est bien le cas OVH ne devrait pas tarder à la couper.

Suite à ton message je les ai appelés , en fait c'est une de leur application qui check ma machine.

[Kioob]

lol. Dans ce cas je n'ai vraiment rien compris aux logs en question.
Bonne nouvelle en tous cas, et désolé pour la fausse alerte.

[SStephane]

Tu es même sensé ouvrir certains ports pour OVH, j'ai ces règles dans mon Firewall qui les concernent :

iptables -A INPUT -i eth0 -p icmp --source proxy.ovh.net -j ACCEPT
iptables -A INPUT -i eth0 -p icmp --source proxy.p19.ovh.net -j ACCEPT
iptables -A INPUT -i eth0 -p icmp --source proxy.rbx.ovh.net -j ACCEPT
iptables -A INPUT -i eth0 -p icmp --source proxy.rbx2.ovh.net -j ACCEPT
iptables -A INPUT -i eth0 -p icmp --source ping.ovh.net -j ACCEPT
iptables -A INPUT -i eth0 -p icmp --source XXX.XXX.XXX.250 -j ACCEPT
iptables -A INPUT -i eth0 -p icmp --source XXX.XXX.XXX.251 -j ACCEPT
iptables -A OUTPUT -p udp --dport 6100:6200 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --source 192.168.0.0/16 -j ACCEPT
iptables -A INPUT -i eth0 -p udp --source 192.168.0.0/16 -j ACCEPT
iptables -A INPUT -i eth0 -p icmp --source mrtg-rbx-47.ovh.net -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 22 --source cache.ovh.net -j ACCEPT

Il faut remplacer les XXX par le début de ton IP, plus d'information ici : http://guides.ovh.com/FireWall

[tomlelab]

Suite de SSH pour les nuls
Mon serveur a à nouveau planté aujourd'hui .
OVH me dit de regarder dans les logs, mais où ?
je n'ai rien trouvé de suspect dans les logs messages (à part donc les scans d'ovh )
Je n'ai pas de logs syslog, j'ai ceci dans /var/log/

acpid            cron             mail        psa-horde     spooler.2
anaconda.log     cron.1           maillog     rkhunter.log  spooler.3
anaconda.syslog  cron.2           maillog.1   rpmpkgs       spooler.4
anaconda.xlog    cron.3           maillog.2   rpmpkgs.1     sso
atmail           cron.4           maillog.3   rpmpkgs.2     sw-cp-server
audit            cups             maillog.4   rpmpkgs.3     tallylog
auth.log.save    denyhosts        mailman     rpmpkgs.4     tomcat5
boot.log         dmesg            messages    samba         wtmp
boot.log.1       faillog          messages.1  secure        wtmp.1
boot.log.2       httpd            messages.2  secure.1      yum.log
boot.log.3       install_rtm.log  messages.3  secure.2      yum.log.1
boot.log.4       kav              messages.4  secure.3
btmp             lastlog          mysqld.log  secure.4
conman           lfd.log          pm          spooler
conman.old       lfd.log.1.gz     prelink     spooler.1

Merci de votre aide

Ce message a été modifié par tomlelab - 17 novembre 2009 - 14:47.

[Dan]

Lorsque tu dis 'serveur planté', il faut comprendre quoi ?
Il a rebooté tout seul ou il était "figé" ?

C'est quelle distribution de Linux ?
Tu tournes quelle version du noyau ?

[tomlelab]

Bonjour Dan
La première fois, il a rebooté tout seul.
La deuxième fois, l'équipe d'OVH l'a trouvé étéint.
La troisième fois, il a rebooté tout seul.

Quand j'écris rebooté tout seul, je veux dire par là qu'il était "unreachable"
(PING ns303027.ovh.net (94.23.203.196) from 213.186.33.13 : 56(84) bytes of data.
From 213.186.33.13: Destination Host Unreachable From 213.186.33.13: Destination Host Unreachable From 213.186.33.13: Destination Host Unreachable
)
et qu'avant qu'OVH n'ait le temps d'intervenir il avait rebooté et était ok.

les infos sur mon serveur:
Linux 2.6.28.4-xxxx-std-ipv4-32
système CentOS 5.2
Plesk 9.0

Ce message a été modifié par tomlelab - 18 novembre 2009 - 18:57.

[Dan]

Essaie en changeant de noyau : passe en 2.6.31.5 ... Avec le netboot c'est rapide.
Assure-toi aussi que ta distrib CentOS est bien en 32 bits... comme le noyau.

[tomlelab]

Dan, le 19 novembre 2009 - 11:02, dit :

Essaie en changeant de noyau : passe en 2.6.31.5 ... Avec le netboot c'est rapide.
Assure-toi aussi que ta distrib CentOS est bien en 32 bits... comme le noyau.

Je vais essayer, tu penses à un problème spécifique lié à ma version ?
Comme c'est survenu subitement, au bout d'un mois de fonctionnement, je pensais à un problème soit matériel, soit venant de mon application. ca ne le fait plus depuis 2 jours mais bon, je laisse une fenetre ssh ouverte avec la commande top, pour voir.