¿Soy atacado o simplemente estúpido?


11

Ejecuto un servidor usando Debian Squeeze con varios contenedores OpenVZ. Los contenedores funcionan principalmente con Squeeze, algunos con Lenny y otros ya actualizados a Wheezy. El host no hace mucho más allá de iptables y DHCP. Los servidores de archivos, servidores proxy, servidores de correo, kerberos, LDAP, ... se colocan en contenedores. El sistema se mantuvo estable durante muchos años y no tuvo cambios importantes, excepto algunas reglas de firewall durante más de un año.

Hace 2 días, de repente, el sistema se bloqueó. Tuve muchos problemas para volver a mencionarlo. Al principio no me dejaba iniciar sesión a través de ssh. el inicio de sesión raíz fue denegado por 'No existe. ¡Vete!' El inicio de sesión local estuvo bien. Algún tiempo después, ssh funcionó nuevamente. Por coincidencia, no reutilicé la línea del historial de bash, sino que escribí un nuevo comando, que triplicado era idéntico a la línea, que no funcionaba antes pero funcionaba antes del bloqueo.

Luego se ejecutó el sistema, pero el tráfico de red en la mayoría de los protocolos se bloqueó después de SYN ACK. DNS, Telnet y SSH estaban bien, pero el resto era un desastre. Después de un par de horas pescando en la oscuridad y recargando el cortafuegos varias veces, de repente todo volvió a funcionar. No pude encontrar nada sospechoso en los registros, pero no soy un experto forense.

Hoy, el nscd del servidor de archivos se quedó sin enchufes para contactar al LDAP debido a la cuota del contenedor. Algo que nunca sucedió antes. También vi muchos (> 30) enchufes reclamados por smbd.

/ var / log / messages se parecía bastante a syslog . /var/log/kern.log tenía esta información adicional sobre los motivos del bloqueo:

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

El bloqueo final de 'sendmail' fue después de reiniciar la máquina. Desde entonces no se produjeron más eventos de este tipo. 'imapd' y 'postgres' definitivamente se ejecutan en diferentes contenedores.

Bueno, no veo ninguna pistola humeante, pero probablemente estoy ciego. Configurar el sistema a partir de copias de seguridad conocidas / supuestas buenas me golpearía demasiado para intentarlo sin muy buenas razones.

Agradecería cualquier consejo sobre qué consultar a continuación.

Gracias por tu ayuda.

Actualización : Al poner más esfuerzo en la búsqueda de algún precursor del bloqueo, encontré lo siguiente en 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)

Sé que esto se considera poco crítico, pero parece ser un evento raro. El truncamiento de paquetes solo existe el día del segundo bloqueo. En ningún otro lugar en todos los archivos de registro disponibles.

Respuestas:


2

Esto se parece a DoS, muy probablemente originario de nework o del interior de uno de los contenedores comprometidos.

Examinaría vmstat, lo ejecutaría continuamente cada 5 segundos: vmstat 5 y tomaría nota de dónde se gastan los recursos. También puede usar la pantalla y ejecutar vmstat 60 (cada minuto) en una ventana separada, de esta manera puede notar picos cuando ocurren durante un período de tiempo más largo.

En esta situación, la CPU (sy) de sistema alta / alta, la alta velocidad de cambio de contexto (cs) y la alta IO (muestra tanto la red como el disco) indicarán 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

Al mismo tiempo, supervise el tráfico de red en el host, recomiendo ntop, es decir:

$ nload -t 10000 -u H eth0

0

Parece un error de E / S de disco. Ejecute fsck y verifique si hay errores.


Intentaré programar el tiempo de inactividad para eso. Sin embargo, no hay registros relacionados con fallas de disco de E / S en ninguna parte. ¿O viste alguno?
Lars Hanke

0

Tal vez no tenga ningún error en el sistema de archivos, pero estoy seguro de que verá esas advertencias en su registro, porque tiene muchos procesos en estado D (esperando E / S) y el núcleo le informa de la larga espera.


Supongo que este ha sido el caso. ¿Pero por qué? En condiciones normales no hay procesos en estado D. Si en realidad la red se cayó, podría explicar eso. Pero, ¿por qué bajaría solo para algunos servicios? ¿Por qué esa condición sobrevivió al reinicio? ¿Y por qué volvió a aparecer?
Lars Hanke

0

El error indica que sus procesos están esperando demasiado (120 segundos) para acceder a los discos; Esto sucede en servidores muy concurridos donde los discos están demasiado ocupados para responder a los procesos.

Puede asegurarse marcando "Esperando" en vmstat.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.