Recentemente, recebi uma mensagem de "Correio não entregue retornado ao remetente" de um domínio .ru referente a uma mensagem que, tenho certeza, não foi enviada por mim ou por qualquer código que tenha escrito. Estou usando o Google Apps para e-mail e o servidor em questão é um servidor Ubuntu 10.04.1 em um provedor de hospedagem na nuvem. Estou procurando uma lista de verificação de coisas que posso fazer para determinar se meu servidor foi comprometido. Até agora, executei o domínio por meio de um teste de retransmissão aberta (não é uma retransmissão aberta) e execute netstat -an e ps aux para determinar que apenas os programas que eu quero escutando as portas estão rodando (SSH, Tomcat, MySQL, Postfix (eu não acho que posso desabilitar o Avahi por causa do funcionamento do meu provedor de serviços em nuvem)). E eu corri cat /etc/passwd para ter certeza de que não há usuários desconhecidos. Há mais alguma coisa que eu deva fazer?
O e-mail que você recebeu pode muito bem ser "backscatter" , ou seja, o resultado de spam enviado usando seu endereço de e-mail e o servidor SMTP .ru fazendo isso. Não necessariamente porque o seu servidor foi comprometido e o email foi enviado por ele.
Execute um sniffer como o wireshark e procure conexões suspeitas, mas não acho que você tenha sido comprometido.
É provável que alguém esteja simplesmente falsificando seu endereço de e-mail como "remetente". É trivialmente fácil fazer isso. À medida que enviam spam, qualquer rejeição volta para você (também conhecido como backscatter). Muitos servidores de e-mail retornarão o e-mail com cabeçalhos completos no NDR (retorno) para que você possa determinar se esse é o caso.
Se você descobrir que o e-mail suspeito é originário de um servidor que não é seu, recomendamos que você adicione a autenticação do remetente à sua retransmissão de e-mail. Nesse caso, você gostaria que seu registro se referisse ao registro spf do google.
O primeiro passo é verificar se alguém está enviando spam pelo seu servidor.
Primeiro, passe pelos seus registros de e-mail! Estou acostumado a exim, mas tenho certeza que os passos são os mesmos. Procure em sua fila de mensagens e veja se há mensagens enfileiradas. Uma grande execução de spam sempre deixará você com mensagens que não podem ser entregues por dias a fio, porque as listas de discussão de spam sempre têm entradas inválidas.
Analise também os logs de email. Para exim eu uso o grep '< =' / var / log / exim_mainlog | awk '{print $ 5}' | grep \ @ | classificar | uniq -c | ordene -nk1 para ver quantas mensagens várias pessoas enviaram.
Por fim, verifique os cabeçalhos nas mensagens devolvidas para ver se o email está realmente vindo de uma das suas máquinas / instâncias. Você pode precisar apenas de registros SPF.
As chances são de que agora você tenha uma boa ideia se o seu servidor está com hemorragia de mensagens em todos os lugares.
Se você encontrou mensagens de spam, tente ver como o usuário de e-mail está sendo enviado. Altere a senha desse usuário. Geralmente spam aleatório vem de scripts php, o php geralmente inclui um cabeçalho X-Script-Sentby: (ou algo) nos cabeçalhos completos das mensagens, que você pode usar para encontrar o script responsável.
Na maioria das vezes, você encontrará algum script php aleatório que envia e-mails para todos os lugares. Ocasionalmente eu vejo pessoas fazendo spam através da horda (o que é um pouco mais difícil de rastrear) ou usando o Outlook ou usando outros clientes que exigem apenas uma senha.
Se o correio estiver vindo do seu servidor e você não tiver certeza de onde, você também pode colocar disable_function = mail no seu php.ini
Estar enraizado é o cenário menos provável, mais provável que algum aplicativo php aleatório tenha sido invadido. Se você se enraizou tente rkhunter ou algo assim, também hackers tendem a usar nomes bizarros para script, e scripts php deixados por hackers tendem a ser eval (base64_decode (gunzip (comprimido, então se você grep -reval $ docroot você pode encontrar Por último, o clamav não é muito ruim em pegar scripts maliciosos de php.
Sem acesso físico ao sistema ou à infraestrutura que o envolve, você não tem muitas opções. A primeira suposição é que qualquer ferramenta em um sistema comprometido também pode ser comprometida. Nos dias de hoje, os sistemas atacados normalmente têm um kit de raiz ou um software de controle remoto instalado (eu estive fora do jogo por um tempo) que dificultará a identificação e, muitas vezes, subverterá os utilitários e comandos comuns do sistema operacional.
1) Portalize o sistema usando um utilitário externo
2) Você pode tentar mover alguns binários vinculados estaticamente (cópias adicionais de ps, netstat, etc) e usá-los para verificar portas, contas e processos (estaticamente vinculado significa que não usará nada externo ao binário biblioteca do seu sistema).
3) Você já considerou que alguém pode ter enviado uma mensagem usando um endereço de retorno que aponta para você? (backscatter ... há um termo para isso!)
Tags linux web-server ubuntu-10.04