Evitar spam de saída

Question

Quais são algumas maneiras de evitar que o spam saia de seus servidores caso uma conta de hospedagem seja comprometida?

Tenha um monte de clientes em um servidor com cpanel, mas questionando se havia uma maneira de evitar uma chance de uma conta ser comprometida.

• Quando eu quis dizer comprometido, quis dizer, um cliente se inscreve ou uma conta de cliente e é hackeado e sua conta é usada para spam.

• você não poderia configurar algum tipo de termo de filtro / lista negra em exim ou spamassassin, o que bloquearia / pararia o envio de e-mails se fosse compatível?

Answer 1

Não fique comprometido. A sério.

• Monitore seu tráfego. Você entenderá o que é normal e poderá reconhecer tráfego anormal.

• Encerra os daemons desnecessários. Se o servidor não deve enviar mensagens, não execute o sendmail ou o postfix.

• Restrinja o acesso SSH e / ou atribua ao SSH uma porta não padrão (por exemplo, não use a porta padrão 22). Se você precisar usar a porta 22, aumente com um serviço como DenyHosts para rastrear e interromper as tentativas de autenticação de bots SSH de entrada.

• Use ou imponha senhas strongs para você e seus clientes.

Ah, e isso: Combatendo o Spam - O que eu posso fazer como administrador de email, proprietário de domínio ou usuário?

    

Answer 2

O mais fácil é bloquear as conexões de saída para a porta 25 até que um cliente "solicite" que ele seja desbloqueado para seu IP. Na verdade, não deveria haver ninguém executando um servidor de email a partir de um site de hospedagem CPanel (se ele estiver gerando um email que é "enviado" por outro servidor, ele deverá ser enviado para esse servidor em port 587 por RFC e tem sido assim desde 1998).

Eu realmente gostaria que mais provedores tivessem o seu nível de consideração, mesmo que você não bloqueie o tráfego da Destination Port 25. Agradecemos o pensamento e gostaríamos mais do firewall.

    

Answer 3

Você está executando um provedor de hospedagem na Web, o que, por sua natureza, significa que seus clientes executarão códigos não confiáveis e muitas vezes inseguros.

Além das coisas que você já deveria estar fazendo para proteger o servidor em geral, considere:

• Execute verificações de malware nos dados do cliente usando uma ferramenta como maldet . Mantenha suas definições atualizadas.

• Permitir somente o tráfego de saída de SMTP para o servidor de e-mail local, onde você pode registrar e exercer algum controle sobre os e-mails enviados. Adicione uma regra de firewall de saída que impeça qualquer coisa, exceto o servidor de email, de se conectar à porta 25 em hosts remotos. Uma regra de exemplo poderia ser:

  iptables -I OUTPUT -m owner ! --uid-owner EXIM_USER -p tcp --dport 25 -j DROP
  

  (O tráfego SMTP autenticado para o servidor de email de terceiros de um cliente, como o Gmail, será executado na porta 587 e não será afetado por isso.)

Answer 4

Se nenhum dos servidores que você usa requerer mensagens de saída, eu colocaria um ticket com seu host e pediria que eles bloqueiem a entrada e saída da porta 25 para os sistemas. ewwhite tem a idéia certa - se um de seus sistemas estiver completamente comprometido, não há nada que você possa fazer nesse sistema para evitar que ele se torne um zumbi de spam ou coisas igualmente indesejáveis. Você pode, no entanto, intervir um passo adiante na cadeia.

Além de uma abrangente estratégia de defesa, mantendo suas atualizações, restringindo seu acesso e todas as outras práticas recomendadas mencionadas por ewwhite, sugiro levar o princípio do menor privilégio a um nível para o host ou para o provedor de rede. Se as máquinas nunca precisarem enviar e-mails, faça com que elas realmente não possam.

    

Answer 5

Eu irei ecoar o conselho do ewwhite, assim como a sugestão de eliminar todo o tráfego SMTP de outro servidor que não o seu mailhost no seu firewall, do Micheal Hampton.

Outra sugestão é configurar uma invasão de tráfego nos aplicativos do seu cliente para SMTP de saída. Seus servidores web não devem estar gerando e-mails, então, se eles fizerem isso, você quer ver do que se trata - talvez você possa obter algumas informações sobre a fonte original. Outras coisas para talvez tentar:

Se você souber o bloco IP do seu cliente, poderá capturar o telnet, o desktop remoto (3389) e o tráfego SSH no host da web e filtrar o bloco de IPs dos resultados. Isso deve lhe dar uma ideia se alguém está controlando o host além deles.

Outro tipo de tráfego para snoop é o IRC, já que este protocolo é amplamente usado como uma rede de comando e controle para computadores zumbis. Ou simplesmente solte as portas de IRC no seu firewall da mesma forma que você removeu o SMTP.

Outro vetor possível para malware é via torrents. Se o servidor da Web do seu cliente estiver abrindo conexões de torrent, ele poderá estar em uso como um nó de distribuição de torrent, bem como uma fonte de spam de email. Se seus clientes não solicitaram isso como um serviço suportado, você poderá soltá-lo no firewall ou eliminar os serviços no host.

A solução definitiva, depois de ter feito o backup do que você precisa para pesquisar o vetor de controle (ou se não houver nenhum empurrão real para descobrir o que aconteceu), você pode simplesmente matar a VM ou recriar a imagem do servidor e restaurá-la os aplicativos e dados do cliente de um backup anterior. Eles podem ter problemas com isso ... mas, é um dos custos de executar um código não seguro.

    

Answer 6

instale o CSF (firewall ConfigServer)