Monitore a atividade postfix em um servidor Debian compartilhado com mais de 100 vhosts

1

Eu tenho uma situação única. Eu tenho um servidor Debian Lenny compartilhado com mais de 100 vhosts para vários clientes. Recentemente eu notei um aumento na atividade postfix dentro dos meus gráficos Munin. Parece haver um script PHP dentro de um dos muitos vhosts no servidor que está sendo usado para enviar explosões de e-mail. Por um lado eu entendo que o Postfix não vem com configurações para ajudar a limitar o envio de e-mail. Eu olhei em volta e parece que o postfix-policyd é uma solução viável. Aqui está o que eu gostaria de fazer.

  1. instale o software para me ajudar a identificar qual vhost em particular está enviando a maioria dos e-mails
  2. qual script php em particular está sendo explorado
por SoMoSparky 23.09.2011 / 07:44

2 respostas

1

Você tem algumas opções, dependendo da sua configuração.

Limitar no servidor da web se suphp ou similar for usado

Se os seus scripts PHP forem executados através de suphp ou mecanismo semelhante que executa os scripts com os privilégios do usuário proprietário do script (em vez do Apache), você poderá limitar a quantidade de e-mails que essa única conta pode enviar durante algum intervalo de tempo. A limitação pode ser feita com qpsmtpd ; Há muitos anos, escrevi um plugin em Perl que armazenava o nome da conta no MySQL e depois checava quantos e-mails esse usuário tinha enviado recentemente. Se o limite foi excedido, o correio foi armazenado em quarentena temporária, um alerta foi gerado e a equipe administrativa pôde verificar o que estava acontecendo.

A mesma coisa pode ser feita com o Postfix-policyd, pelo menos em teoria - seria muito fácil se o PHP enviasse emails autenticados, mas como normalmente isso não acontecerá, você terá que ser mais criativo ao criar as regras de limitação.

Limitando no servidor web se mod_php for usado

Se os scripts PHP forem executados com mod_php simples (para que todo e qualquer script seja executado como usuário do Apache), ficar mais difícil localizar o script culpado e limitar o envio de mensagens. Novamente, isso pode ser feito com um uso inteligente de qpsmtpd .

Versões recentes do PHP incluem uma opção para incluir X-PHP-Script header em cada e-mail. Esse cabeçalho, como o nome sugere, contém o caminho para o script PHP. Você pode usar essas informações de caminho junto com qpsmtpd e considerar apenas a parte do usuário da URL e fazer o controle dessa maneira.

Se você está preso a alguma versão antiga do PHP, você ainda pode consertar a função de e-mail PHP sozinho. Eu escrevi um pequeno patch abaixo em 2005, não o usei recentemente, então não tenho idéia se ele ainda funciona. Ainda assim, a ideia deve ser clara: obtenha o nome do caminho, anexe-o a todos os e-mails.

--- ext/standard/mail.c 2004-01-09 03:35:58.000000000 +0200
+++ ext/standard/mail.c 2005-03-14 13:33:33.069826225 +0200
@@ -180,0 +181 @@
+   char *runningscript = zend_get_executed_filename(TSRMLS_C);
@@ -229,0 +231,6 @@
+       if (runningscript != NULL) {
+           fprintf(sendmail, "X-PHP-Script-Path: %s\n", runningscript);
+       }
+       else {
+           fprintf(sendmail, "X-PHP-Script-Path: Unknown\n");
+       }

Encontrando os problemas no servidor SMTP

Como você está usando o Postfix, pfqueue é seu amigo quando se trata de inspecionar a fila de mensagens. Se você vir muitas mensagens de spam semelhantes na fila de mensagens, basta acionar pfqueue e inspecionar os cabeçalhos de uma única mensagem com ela. A maior parte do tempo é suficiente para revelar o spammer; os cabeçalhos podem conter as informações do domínio, o cabeçalho do script X-PHP ou alguma outra pista.

    
por 23.09.2011 / 09:59
0

Eu acho que a solução mais rápida pode ser executar: cd /root/of/www ; grep -R 'mail(' * Isso deve mostrar todos os arquivos que contêm string 'mail ('. mail () é a função que o PHP usa para enviar mensagens, então você pode ser capaz de identificar vhost e script de uma só vez.

    
por 23.09.2011 / 07:56

Tags