Como diagnosticar o bloqueio de um servidor web em alta carga

Question

Eu tenho problemas para entender quais problemas podem causar interrupções ocasionais que o servidor recebe devido a picos repentinos de carga alta. Eu não sou um administrador do sistema (eu sou um programador PHP), mas desde que o administrador de sistema oficial é bastante falta de esforço me pedem para encontrar uma solução eu mesmo.

O servidor é executado em um Debian Lenny e serve via apache um site baseado em wordpress + vbulletin com 40-60k visitas / dia. Tendo feito toda a otimização do lado do aplicativo que pude, chegamos à situação em que o site é executado sem problemas, mesmo por semanas, então ele tropeça em algo que faz a carga do servidor pular para 80+. Parar o apache para reiniciá-lo ajuda, mas ele geralmente se acalma sozinho, se for dado tempo suficiente. Pode "colidir" duas vezes por dia ou não ver problemas durante semanas. Parece ser totalmente aleatório.

Uma coisa estranha e estranha aconteceu. Fui avisado de um comportamento estranho e após a inspeção, descobri que o arquivo .htaccess foi alterado para redirecionar o tráfego proveniente de mecanismos de pesquisa para algum site externo. Eu verifiquei o código e todos os plugins (todos atualizados) e finalmente tentei a "maneira difícil" chown ing .htaccess to root.root . A parte estranha é que, quando surgiu outro problema, descobri que o arquivo foi alterado de volta para pertencer ao usuário atribuído ao site virtualhost. Eu entendo que não é possível que isso aconteça apenas por meio de alguma exploração da Web ou estou enganado?

Como posso encontrar a causa desses altos picos de carga?
O que pode explicar um arquivo root.root alterando permissões, outro que alguém com acesso root faz isso?
Essas duas coisas poderiam estar ligadas a algum tipo de ataque?

    

Answer 1

Em relação ao problema do Apache, uma causa possível é que sua configuração MaxClient / MaxServer é muito alta. Quando você começa a aumentar o tráfego, você usa toda a sua memória RAM e faz com que o Apache comece a usar o swap, o que rapidamente matará seu desempenho. Da próxima vez que você tiver o problema, verifique a saída de top / free e veja se alguma troca está sendo usada. Se estiver tentando reduzir os valores de MaxClient / MaxServer.

Eu também tive um problema com o Apache 1.3 onde algumas conexões nunca fechavam e depois de alguns dias haveria 90% das conexões sem fazer nada, não deixando clientes para manipular novas conexões de entrada. Eu resolvi isso simplesmente reiniciando o Apache todos os dias. Pelo que parece, você não tem tráfego ou tempo suficiente entre os problemas para que isso seja uma causa provável.

    

Answer 2

Parece-me que alguém pode ter comprometido o seu servidor, mais por causa do redirecionamento do tráfego do mecanismo de pesquisa para um site diferente do que por causa do problema de propriedade de arquivo. Infelizmente, algumas explorações da Web podem dar a um invasor acesso root ao seu sistema.

Eu baixaria e executaria um detector de rootkit, como o Rootkit Hunter . Se você tiver sido enraizado, provavelmente desejará que alguém experiente ajude você a corrigi-lo.

    

Answer 3

Pode ser um ataque, mas por que só mudar o arquivo .htaccess , provavelmente há mais coisas para verificar. Talvez um script php esteja gerando o arquivo automaticamente. Quais são as permissões no arquivo?

Em relação à carga, pode ser um monte de coisas, especialmente por sua natureza aleatória. Assista os logs e use ferramentas (webalizer, para ver se os picos de carga coincidem com tempos de acesso pesados ou acesso a um recurso específico que pode ser o caso dele.

Verifique seu servidor com chkrootkit e ferramentas semelhantes para verificar se há comprometimento. Se isso aconteceu, talvez você precise / queira reinstalar seu servidor do zero.

    

Answer 4

I understand there is no way for this to happen just via some web exploit, or am I mistaken?

Por si só, isso não levaria em conta as permissões de uma raiz: alteração do arquivo de propriedade da raiz, mas um comprometimento da Web pode permitir que um invasor implante malwares no sistema, o que poderia comprometer o sistema de outras maneiras. E há outras maneiras de comprometer um sistema.

Se tiver certeza de que seu código não foi modificado desde a última vez que você verificou, é hora de eliminar tudo o mais - usar verificadores de rootkit é uma boa ideia em um sistema que você acredita estar seguro - mas se você tiver dúvidas você deve reformatar / reinstalar.

    

Answer 5

No servidor web # ps -uapache -o wchan=WIDE-WCHAN-COLUMN,cmd try, encontre algo semelhante a flock_lock_file_w /usr/sbin/httpd no primeiro campo.

Qual é o seu session.save_handler ?