Suis-je attaqué ou simplement stupide?


11

Je gère un serveur utilisant Debian Squeeze avec plusieurs conteneurs OpenVZ. Les conteneurs exécutent principalement Squeeze, certains Lenny et certains déjà mis à jour vers Wheezy. L'hôte ne fait pas grand-chose au-delà d'iptables et de DHCP. Les serveurs de fichiers, les proxys, les serveurs de messagerie, les kerberos, LDAP, ... sont tous placés dans des conteneurs. Le système est resté stable pendant de nombreuses années et n'a subi aucun changement majeur, à l'exception de quelques règles de pare-feu pendant plus d'un an.

Il y a 2 jours, tout à coup, le système s'est écrasé. J'ai eu beaucoup de problèmes pour le reprendre. Au début, cela ne me permettait pas de me connecter via ssh. la connexion root a été refusée par 'Vous n'existe pas. Allez-vous en!' La connexion locale était correcte. Quelque temps plus tard, ssh a de nouveau fonctionné. Par coïncidence, je n'ai pas réutilisé la ligne de l'historique bash, mais j'ai tapé une nouvelle commande, qui triplement vérifiée était identique à la ligne, qui ne fonctionnait pas auparavant mais fonctionnait avant le crash.

Ensuite, le système a fonctionné, mais le trafic réseau sur la plupart des protocoles a été bloqué après SYN ACK. DNS, Telnet et SSH étaient bien, mais le reste était un gâchis. Après quelques heures de pêche dans l'obscurité et de rechargement du pare-feu à plusieurs reprises, tout s'est bien passé. Je n'ai rien trouvé de suspect dans les journaux - mais je ne suis pas un expert en médecine légale.

Aujourd'hui, le nscd du serveur de fichiers est sorti des sockets pour contacter le LDAP en raison du quota de conteneur. Quelque chose qui ne s'était jamais produit auparavant. J'ai également vu beaucoup (> 30) de prises revendiquées par smbd.

/ var / log / messages ressemblait assez à syslog . /var/log/kern.log contenait ces informations supplémentaires sur les raisons des plantages:

/var/log/kern.log:2950:Sep 19 10:46:57 asgard kernel: [6529441.320086] INFO: task sendmail:32181 blocked for more than 120 seconds.
/var/log/kern.log:2982:Sep 19 10:48:57 asgard kernel: [6529561.324525] INFO: task kdmflush:1932 blocked for more than 120 seconds.
/var/log/kern.log:3005:Sep 19 10:48:57 asgard kernel: [6529561.324694] INFO: task xfssyncd:10162 blocked for more than 120 seconds.
/var/log/kern.log:3027:Sep 19 10:48:57 asgard kernel: [6529561.324934] INFO: task postgres:16827 blocked for more than 120 seconds.
/var/log/kern.log:3060:Sep 19 10:49:51 asgard kernel: [6529561.325129] INFO: task imapd:31749 blocked for more than 120 seconds.
/var/log/kern.log:3084:Sep 19 10:49:51 asgard kernel: [6529561.325248] INFO: task cleanup:32194 blocked for more than 120 seconds.
/var/log/kern.log:3106:Sep 19 10:50:57 asgard kernel: [6529681.324028] INFO: task flush-253:3:3216 blocked for more than 120 seconds.
/var/log/kern.log:3142:Sep 19 10:50:57 asgard kernel: [6529681.324224] INFO: task kjournald:6859 blocked for more than 120 seconds.
/var/log/kern.log:3166:Sep 19 10:50:57 asgard kernel: [6529681.324366] INFO: task syslogd:11720 blocked for more than 120 seconds.
/var/log/kern.log:3198:Sep 19 10:50:57 asgard kernel: [6529681.324574] INFO: task postgres:16827 blocked for more than 120 seconds.
/var/log/kern.log:7152:Sep 19 19:29:41 asgard kernel: [ 1440.617090] INFO: task sendmail:11892 blocked for more than 120 seconds.

Le plantage final de «sendmail» s'est produit après le redémarrage de la machine. Depuis lors, plus aucun événement de ce type ne s'est produit. 'imapd' et 'postgres' s'exécutent définitivement dans des conteneurs différents.

Eh bien, je ne vois aucun pistolet fumant, mais je suis probablement aveugle. La configuration du système à partir de bonnes sauvegardes connues / présumées me frapperait trop fort pour l'essayer sans de très bonnes raisons.

J'apprécierais tout conseil que vérifier ensuite.

Merci de votre aide.

Mise à jour : En mettant plus d'efforts dans la recherche d'un précurseur du crash, j'ai trouvé ce qui suit dans syslog:

Sep 19 10:09:56 asgard ntop[7965]:   **WARNING** packet truncated (8754->8232)
Sep 19 10:09:56 asgard ntop[7965]:   **WARNING** packet truncated (8754->8232)
Sep 19 10:09:56 asgard ntop[7965]:   **WARNING** packet truncated (10490->8232)
Sep 19 10:09:56 asgard ntop[7965]:   **WARNING** packet truncated (8754->8232)
Sep 19 10:09:56 asgard ntop[7965]:   **WARNING** packet truncated (8754->8232)
Sep 19 10:09:56 asgard ntop[7965]:   **WARNING** packet truncated (17442->8232)
Sep 19 10:11:02 asgard ntop[7965]:   **WARNING** packet truncated (11650->8232)
Sep 19 10:11:02 asgard ntop[7965]:   **WARNING** packet truncated (10202->8232)
Sep 19 10:11:29 asgard ntop[7965]:   **WARNING** packet truncated (8754->8232)
Sep 19 10:13:27 asgard ntop[7965]:   **WARNING** packet truncated (8754->8232)
Sep 19 10:20:33 asgard ntop[7965]:   **WARNING** packet truncated (8754->8232)

Je sais que cela est jugé non critique, mais cela semble être un événement rare. La troncature des paquets n'existe que le jour du deuxième plantage. Nulle part ailleurs dans tous les fichiers journaux disponibles.

Réponses:


2

Cela ressemble à DoS, très probablement originaire de Nework ou de l'intérieur d'un des conteneurs compromis.

Je regarderais dans vmstat, l'exécuterais continuellement toutes les 5 secondes: vmstat 5 et prendrais une note où les ressources sont dépensées. Vous pouvez également utiliser l'écran et exécuter vmstat 60 (toutes les minutes) dans une fenêtre distincte - de cette façon, vous pouvez remarquer des pics lorsqu'ils surviennent sur une période plus longue.

Dans cette situation, un CPU système élevé / dopé (sy), un taux de changement de contexte élevé (cs) et un IO élevé (il montre à la fois le réseau et le disque) indiqueront le DoS:

$ vmstat 5
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0   9584   6820 132432  23256    1    1   136    12    1    1 83  1 15  0  0
 0  0   9584   6696 132432  23256    0    0     0     0   20   32  0  0 99  0  1

En même temps, surveillez le trafic réseau sur l'hôte, je recommande ntop, c'est-à-dire:

$ nload -t 10000 -u H eth0

0

Cela ressemble à une erreur d'E / S disque. Exécutez fsck et recherchez les erreurs.


Je vais essayer de planifier des temps d'arrêt pour cela. Cependant, il n'y a aucun journal lié aux pannes de disque d'E / S. Ou en avez-vous vu?
Lars Hanke

0

Vous n'avez peut-être aucune erreur de système de fichiers, mais je suis sûr que vous voyez ces avertissements dans votre journal, car vous avez de nombreux processus à l'état D (en attente d'E / S) et le noyau vous informe de la longue attente.


Je suppose que cela a été le cas. Mais pourquoi? Dans des conditions normales, il n'y a aucun processus à l'état D. Si le réseau tombait en panne, cela pourrait expliquer cela. Mais pourquoi ne baisserait-elle que pour certains services? Pourquoi cette condition a-t-elle survécu au redémarrage? Et pourquoi est-il revenu?
Lars Hanke du

0

L'erreur indique que vos processus attendent trop longtemps (120 secondes) pour accéder aux disques; cela se produit sur des serveurs très encombrés où les disques sont trop occupés pour répondre aux processus.

Vous pouvez vous en assurer en cochant "En attente" sous vmstat.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.