Eu sou atacado ou apenas estúpido?

Eu executo um servidor usando o Debian Squeeze com vários contêineres OpenVZ. Os contêineres rodam principalmente Squeeze, alguns Lenny e outros já atualizados para o 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 todos colocados em contêineres. O sistema ficou estável por muitos anos e não teve grandes alterações, exceto algumas regras de firewall por mais de um ano.

Há 2 dias, de repente, o sistema travou. Eu tive muitos problemas para trazer isso à tona novamente. No começo, não me deixava entrar via ssh. o login raiz foi negado por 'Você não existe. Vá embora!' O login local foi bom. Algum tempo depois, o ssh voltou a funcionar. Por coincidência, não reutilizei a linha do histórico do bash, mas digitei um novo comando, verificado três vezes, idêntico à linha, que não funcionava antes, mas funcionava antes da falha.

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 suspeito nos logs - mas não sou um especialista forense.

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. Também vi muitos (> 30) soquetes reivindicados pelo smbd.

/ var / log / messages parecia exatamente o mesmo que o syslog . /var/log/kern.log possui essas informações adicionais por motivos 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 falha final do 'sendmail' ocorreu após a reinicialização da máquina. Desde então, nenhum desses eventos ocorreu. 'imapd' e 'postgres' são executados em diferentes contêineres.

Bem, não vejo nenhuma arma que fume, mas provavelmente sou apenas cego. Configurar o sistema a partir de bons backups conhecidos / presumidos seria muito difícil para testá-lo sem muito bons motivos.

Agradeço qualquer conselho sobre o que verificar a seguir.

Obrigado pela ajuda.

Atualização : Colocando mais esforço na busca por 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 crítico, mas parece ser um evento raro. O truncamento de pacotes existe apenas no dia da segunda falha. Em nenhum outro lugar em todos os arquivos de log disponíveis.

Isso se parece com o DoS, provavelmente originário de nework ou de dentro de um dos contêineres comprometidos.

Eu olhava para o vmstat, executava-o continuamente a cada 5 segundos: vmstat 5 e anotava onde os recursos são gastos. Você também pode usar a tela e executar o vmstat 60 (a cada minuto) em uma janela separada - dessa forma, poderá observar picos quando eles ocorrerem por um longo período de tempo.

Nessa situação, a CPU do sistema alta / alta (sy), alta taxa de comutação de contexto (cs) e alta IO (mostra a rede e o 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 o ntop, ou seja:

$ nload -t 10000 -u H eth0

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

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

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

Você pode ter certeza marcando "Aguardando" em vmstat.