Sou atacada ou estúpida?

Question

Eu corro um servidor usando o Debian Squeeze com vários containers OpenVZ. Os contêineres executam principalmente Squeeze, alguns Lenny e alguns já atualizados para Wheezy. O host não faz muito além do iptables e do DHCP. Servidores de arquivos, proxies, servidores de correio, kerberos, LDAP, ... são colocados em contêineres. O sistema ficou estável por muitos anos e não teve grandes mudanças, exceto algumas regras de firewall por mais de um ano.

2 dias atrás, de repente, o sistema caiu. Eu tive muitos problemas em trazer isso de novo. No começo, não me permitia logar via ssh. O login root foi negado por 'Você não existe. Vá embora!' Login local estava bem. Algum tempo depois, o ssh voltou a funcionar. Por coincidência eu não reutilizei a linha do histórico do bash, mas digitei um novo comando, que triplamente verificado era idêntico à linha, que não funcionava antes, mas funcionava antes do acidente.

Em seguida, o sistema foi executado, mas o tráfego de rede na maioria dos protocolos foi bloqueado após o SYN ACK. DNS, Telnet e SSH estavam bem, mas o resto estava uma bagunça. Depois de algumas horas pescando no escuro e recarregando o firewall várias vezes, de repente tudo correu bem novamente. Não consegui encontrar nada de suspeito nos registros - mas não sou especialista em perícia.

Hoje, o nscd do servidor de arquivos ficou sem soquetes para entrar em contato com o LDAP devido à cota do contêiner. Algo que nunca aconteceu antes. Eu também vi muito (> 30) de soquetes reivindicados pelo smbd.

/ var / log / messages parecia o mesmo que o syslog . /var/log/kern.log tinha esta informação adicional sobre razões de falha:

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

A última falha do 'sendmail' ocorreu após a reinicialização da máquina. Desde então, não ocorreram mais tais eventos. 'imapd' e 'postgres' são executados em contêineres diferentes.

Bem, eu não vejo nenhuma arma fumegante, mas provavelmente sou apenas cego. Configurar o sistema a partir de backups conhecidos / presumidos seria muito difícil para mim tentar sem boas razões.

Eu gostaria de receber conselhos sobre o que verificar em seguida.

Obrigado pela sua ajuda.

Atualização : Colocando mais esforço na busca de algum pré-cursor da falha, encontrei o seguinte no 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)

Eu sei que isso é considerado não-crítico, mas parece ser um evento raro. O truncamento de pacotes só existe no dia da segunda falha. Em nenhum outro lugar em todos os arquivos de log disponíveis.

    

Answer 1

Isso se parece com DoS, provavelmente originário de nework ou de dentro de um contêiner comprometido.

Eu examinaria o vmstat, o executaria continuamente a cada 5 segundos: vmstat 5 e anotaria onde os recursos são gastos. Você também pode usar a tela e rodar o vmstat 60 (a cada minuto) em uma janela separada - assim você pode notar picos quando eles acontecem por um longo período de tempo.

Nessa situação, alta / alta CPU do Sistema (sy), alta taxa de chaveamento de contexto (cs) e alta IO (mostra rede e disco) indicarão 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

Ao mesmo tempo monitorar o tráfego de rede no host, eu recomendo ntop, ou seja:

$ nload -t 10000 -u H eth0

    

Answer 2

Parece um erro de E / S de disco. Execute fsck e verifique se há erros.

    

Answer 3

Talvez você não tenha nenhum erro no sistema de arquivos, mas tenho certeza de que vê esses avisos em seu log, porque você tem muitos processos no estado D (aguardando E / S) e o kernel está informando sobre o processo. espera longa.

    

Answer 4

O erro indica que seus processos estão aguardando muito tempo (120 segundos) para acessar os discos; isso acontece em servidores altamente lotados, onde os discos estão ocupados demais para responder aos processos.

Você pode verificar marcando "Aguardando" em vmstat.