Questão servidores rogue smtp


Recentemente, tivemos um problema em uma rede na qual o e-mail de spam estava sendo enviado. O próprio servidor mostrou muito pouco tráfego de saída, apenas uma grande quantidade de mensagens de falha de entrega do postmaster recebidas. Os logs mostravam pouco ou nada e até mesmo fazer uma captura de pacotes no servidor acabava mostrando pouca ou nenhuma informação útil para eu filtrar.

A empresa acabou na lista negra, nós checamos aleatoriamente todos os computadores e tivemos a sorte de acertar o computador com a infecção muito rapidamente. Um dos computadores da rede tinha um root-kit e, presumivelmente, enviava e-mails como um servidor de e-mail falso. Isso é o que eu tirei da situação de qualquer maneira.

Eu me considero muito bom com redes, e não vejo razão para que um vírus não possa simplesmente enviar um email para outro servidor a partir de uma estação de trabalho em uma rede, fingindo ser o domínio local e ter sucesso em penetrar filtros de spam. Assumindo que o servidor do exchange está sendo executado sob o mesmo endereço IP (e neste local estava)

Então, essa é uma questão em duas partes, 1. Existe alguma parte do sistema de e-mail em falta que torna isso impossível, e eu estou latindo na árvore errada? 2. Se eu estiver certo, e foi um 'falso servidor de e-mail' enviando esses e-mails, haveria algum problema em mim que bloqueia todo o tráfego através do firewall que tem uma porta DESTINATION para o tráfego de e-mail que não é originado o servidor?

Eu sou muito novo em ser um administrador de rede, então eu poderia ter alguns parques de bolinhas, mas isso é algo que está me incomodando há uma semana. Inferno, pelo que sei, é assim que todos os vírus de spam funcionam (eu supus que eles geralmente passavam pelo servidor de troca principal)

Qualquer conselho sobre este tópico seria apreciado, uma busca rápida on-line realmente não cresceu muito para obter informações sobre "servidores Rogue smtp", exceto em um site que exige que você tenha uma participação para ver as respostas (todos nós sabemos aquele local)


1


origem


Eu tive um caso semelhante uma vez. Coloquei uma regra no firewall para registrar todas as portas de segmentação de tráfego 25 que não fez originam do nosso servidor de email. Dessa forma, eu poderia rastrear instantaneamente o cliente infectado. Ninguém deve falar diretamente com qualquer servidor na porta 25, exceto que é nosso servidor de e-mail. Além disso, outros servidores devem rejeitar emails de endereços IP que não estejam registrados como MX. Mas isso raramente é implementado, pelo que eu posso dizer. - Der Hochstapler
Ok, eu não tinha certeza se bloquear 25 causaria problemas ou não. Obrigado :) - RyanTimmons91
Pessoalmente, considero uma contra-medida válida contra este problema específico. No entanto, se você puder, não se esqueça de registrar os pacotes de qualquer maneira. Dessa forma, você pode detectar se uma máquina está mostrando o mesmo problema novamente. - Der Hochstapler
Eu realmente não queria bloquear / registrar pacotes até ter certeza de que era a única coisa que deveria ter um destino de 25, e não, ofc não resolveria todo o problema, mas certamente é um passo à direita direção. - RyanTimmons91


Respostas:


Apenas para FYI, os programas maliciosos podem modificar a porta / ip de origem / destino dos pacotes. Eles não necessariamente conseguirão enganar o SPI inteligente nos roteadores (a menos que os roteadores estejam infectados), mas às vezes podem evitar regras simples de firewall alterando cabeçalhos de IP ou cabeçalhos TCP no caso de portas.

Quanto à sua pergunta - os autores de malware considerariam um servidor de qualquer tipo (especialmente um servidor de email) como um prêmio mais valioso do que uma estação de trabalho simples. Isso ocorre porque os servidores recebem, inerentemente, maior confiança na rede do que um terminal do cliente. Infectar apenas um software de servidor de e-mail por si só não é tão útil, mas você também pode ajustar as configurações de firewall e enviar cópias de todo o tráfego de e-mail da organização (entrada e saída) infectando um servidor.

Se o objetivo deles é apenas enviar E-mails, então com certeza, a maneira mais fácil é aproveitar as rotinas de envio de e-mail existentes do usuário, e o servidor de e-mail não será mais sábio, a menos que localize palavras spam no e-mail de saída e as contrate.

Se eles quiserem não apenas enviar e-mails, mas estar a par de comunicações privadas dentro da organização, eles infectarão um servidor de e-mail.

O motivo pelo qual eles podem ter feito seu próprio servidor SMTP incorporado (em uma estação de trabalho, suponho) é que você não está, então, comprometido com os filtros de spam de saída do servidor SMTP downstream. Como um autor de malware, você não quer depender de verificações de legitimidade ignoradas, você deseja rotear completamente elas. Naturalmente, muitos roteadores são configurados para bloquear protocolos de correio, como o Exchange e o SMTP, em todas as rotas, exceto para o servidor de email certificado, para impedir exatamente esse tipo de exploração.

(Atualizado abaixo) ...

  1. Existe alguma parte do sistema de e-mail em falta que torna isso impossível, e eu estou latindo na árvore errada?

Enviar email "como" o usuário autorizado usando as credenciais da própria conta do usuário não é impossível, mas para alguns clientes pode ser muito difícil fazê-lo sem ser detectado se o cliente for resistente à automação, como o Outlook. Você também precisa escrever um software para cada cliente de email específico e tentar antecipar e evitar possíveis problemas que podem acionar diálogos pop-up, permitindo que o usuário saiba de um possível problema, etc.

Eu não acho que você está latindo na árvore errada, mas a implementação de um servidor micro-smtp em seu malware terá maior probabilidade de sucesso, a menos que haja regras de roteamento configuradas para bloqueá-lo (que não existem em muitas redes, incluindo a sua, aparentemente).

  1. Se eu estiver certo, e foi um 'falso servidor de e-mail' enviando esses e-mails, haveria algum problema que surge de mim bloqueando todo o tráfego através do firewall que tem uma porta DESTINATION para tráfego de e-mail que não é originado do servidor ?

Isso não será um problema, mas também não o tornará seguro.

Para ser totalmente seguro, você precisa de rota nula todos tráfego em todos os endpoints por padrãoe forçar todos os clientes a usar um proxy HTTP que inspecione todo o tráfego e "entenda" o HTTP (bem como uma lista negra bem mantida ou uma lista branca de sites permitidos).

A razão pela qual simplesmente escrever uma regra de roteamento para a porta SMTP não funcionará é que eles podem apenas usar outras portas para atividades maliciosas.

O problema que estamos vendo agora (nós = comunidade de segurança) é que a nova onda de ataques não usa nenhuma porta ou protocolo exótico, tudo é baseado em HTTP e feito através do navegador agora. Algo tão inofensivo quanto visitar o msn.com pode levar ao XSS armazenado, resultando em javascript malicioso sendo executado no navegador que envia e-mail via webmail, rouba informações ou usa recursos de computação locais para o ganho do invasor (botnets, DDoS, mineração de bitcoin etc.) . Nós criamos um monstro. A web é praticamente uma lacuna de segurança não mitigada, realmente escassa, por si só, mesmo quando você bloqueia a execução de executáveis ​​estrangeiros e bloqueia sua rede atrás de um proxy inteligente.


2



é isso que eu estava pensando, se fosse possível. O servidor de e-mail em si não é comprometido e, tanto quanto eu posso dizer nem era a senha do usuário. (Mudou assim mesmo ofc) No que diz respeito a troca de porta, se enviando para um servidor remoto para enviar email, teria que ter uma porta de destino específica, sim? Eles não conseguiriam mudar a porta de destino, pois nunca atingiriam a porta correta no servidor de destino. É um firewall SonicWall, muito bom, eu só não acho que a restrição do servidor que você falou está no lugar. ainda. - RyanTimmons91
Bem, eles poderia retransmiti-lo através de um servidor em uma porta alternativa, mas eles teriam que saber especificamente sobre (ou operar-se) um servidor SMTP em uma porta não padrão. Alguns legítimos podem existir, mas se o invasor tiver que hospedar o retransmissor, eles provavelmente o farão no computador de outra pessoa (uma botnet), e não no próprio, pago pela infraestrutura de servidor dedicado, já que o desligamento ocorreria em um piscar de olhos. - allquixotic
Venha para pensar sobre isso, isso é bastante engenhoso: o malware poderia ambos tente enviar e-mail em um servidor SMTP e configure um retransmissor SMTP de escuta em uma porta estranha e use NAT-T ou primeiro emite ou outros truques de protocolo para retransmitir o SMTP para uma porta não padrão. - allquixotic
mas se você saltar através de um relay, ele não terá o ip de retorno correto, então ele deve aparecer como spam de qualquer maneira, sim? - RyanTimmons91