O mail bombing é uma das formas mais antigas de ataques cibernéticos. Essencialmente, é semelhante a um ataque DoS comum, mas em vez de uma onda de solicitações de diferentes endereços IP, uma avalanche de e-mails é enviada para um único endereço, aumentando significativamente a carga sobre ele. Esse tipo de ataque pode levar à impossibilidade de usar a conta de e-mail e, às vezes, até mesmo causar a falha total do servidor. A longa história desse tipo de ciberataque trouxe tanto consequências positivas quanto negativas para administradores de sistemas. Entre os fatores positivos, podemos destacar o bom entendimento do mail bombing e a existência de métodos simples para se proteger contra esse ataque. Já entre os fatores negativos, há uma grande quantidade de soluções de software disponíveis publicamente para realizar esse tipo de ataque e a capacidade do criminoso em se proteger de forma eficaz contra a detecção.
Uma característica importante deste ciberataque é que é praticamente impossível utilizá-lo para obter lucro. O criminoso envia uma avalanche de e-mails a uma caixa de entrada, impede que a pessoa utilize o e-mail normalmente, ou então ele invade a conta de e-mail corporativa de alguém e começa a enviar milhares de mensagens pelo GAL, resultando na queda do servidor ou na lentidão que impede seu uso. E o que acontece depois? Converter esse tipo de crime cibernético em dinheiro é quase impossível, por isso o mail bombing é atualmente um fenômeno bastante raro e os administradores de sistemas podem simplesmente não pensar na necessidade de proteção contra esse tipo de ciberataque ao projetar a infraestrutura.
No entanto, apesar de o mail bombing em si ser uma atividade bastante sem sentido do ponto de vista comercial, frequentemente ele faz parte de outros ataques cibernéticos mais complexos e em várias etapas. Por exemplo, ao invadir um email e usá-lo para sequestrar uma conta em algum serviço público, os malfeitores muitas vezes "bombardeiam" a caixa de entrada da vítima com emails sem sentido, para que um email de confirmação se perca em meio ao fluxo e passe despercebido. Além disso, o mail bombing pode ser utilizado como uma forma de pressão econômica sobre uma empresa. Assim, uma bombardear ativa de uma caixa de email pública da empresa, que recebe solicitações de clientes, pode dificultar seriamente o trabalho com essas solicitações e, como consequência, pode levar a períodos de inatividade, pedidos não atendidos, bem como à perda de reputação e lucro perdido.
É por isso que o administrador de sistema não deve esquecer a possibilidade de um ataque de mail bombing e deve sempre tomar as medidas necessárias para se proteger dessa ameaça. Considerando que isso pode ser feito já na fase de construção da infraestrutura de email, e também que isso demanda muito pouco tempo e esforço do administrador de sistema, não há razões objetivas para não assegurar a proteção da infraestrutura contra o mail bombing. Vamos ver como a proteção contra esse ataque cibernético é implementada no Zimbra Collaboration Suite Open-Source Edition.
Na base do Zimbra está o Postfix — um dos mais confiáveis e funcionais Mail Transfer Agents de código aberto atualmente. E uma das principais vantagens de sua abertura é que ele suporta uma ampla variedade de soluções de terceiros para expandir a funcionalidade. Em particular, o Postfix suporta completamente o cbpolicyd — uma ferramenta avançada para garantir a cibersegurança do servidor de email. Além de proteção contra spam e criação de listas brancas, negras e cinzas, o cbpolicyd permite que o administrador do Zimbra configure a verificação de assinatura SPF e estabeleça limites para o recebimento e envio de emails ou dados. Eles podem garantir uma proteção robusta contra spam e emails de phishing, assim como proteger o servidor contra mail bombing.
A primeira coisa que um administrador de sistema precisa fazer é ativar o módulo cbpolicyd, que já vem instalado no Zimbra Collaboration Suite OSE no servidor MTA da infraestrutura. Isso é feito com o comando zmprov ms `zmhostname` +zimbraServiceEnabled cbpolicyd. Em seguida, será necessário ativar a interface web para gerenciar o cbpolicyd de forma confortável. Para isso, é preciso permitir conexões pela porta web número 7780 e criar um link simbólico usando o comando ln -s /opt/zimbra/common/share/webui /opt/zimbra/data/httpd/htdocs/webui, e depois editar o arquivo de configuração com o comando nano /opt/zimbra/data/httpd/htdocs/webui/includes/config.php, onde é necessário incluir as seguintes linhas:
$DB_DSN="sqlite:/opt/zimbra/data/cbpolicyd/db/cbpolicyd.sqlitedb";
$DB_USER="root";
$DB_TABLE_PREFIX="";
Após isso, resta apenas reiniciar os serviços do Zimbra e do Zimbra Apache com os comandos zmcontrol restart e zmapachectl restart. Depois disso, você terá acesso à interface web pelo endereço :7780/webui/index.php. O detalhe principal é que o acesso a esta interface web ainda não está protegido, por isso, para evitar o acesso de terceiros, você pode simplesmente fechar as conexões na porta 7780 após cada acesso à interface web.
Proteger-se contra o fluxo de emails originados da rede interna é possível por meio de quotas de envio de emails, que podem ser estabelecidas através do cbpolicyd. Essas quotas permitem definir um limite para o número máximo de emails que podem ser enviados de uma caixa de entrada em um determinado período. Por exemplo, se os gerentes da sua empresa enviam em média de 60 a 80 emails por hora, você pode, considerando uma pequena margem, estabelecer uma quota de 100 emails por hora. Para esgotar essa quota, os gerentes teriam que enviar um email a cada 36 segundos. Por um lado, isso é suficiente para um funcionamento adequado, mas, por outro lado, com essa quota, invasores que obtiverem acesso ao email de um dos seus gerentes não serão capazes de realizar ataques de mail bombing ou ataques de spam em massa na empresa.
Para estabelecer uma quota como essa, é necessário criar uma nova política de limitação de envio de emails na interface web e especificar que ela deve ser aplicada tanto aos emails enviados dentro do domínio como aos emails destinados a endereços externos. Isso é feito da seguinte maneira:
Depois disso, será possível especificar com mais detalhes as restrições relacionadas ao envio de e-mails, em particular estabelecer um intervalo de tempo após o qual as restrições serão atualizadas, bem como a mensagem que o usuário receberá ao exceder seu limite. Após isso, pode-se estabelecer o próprio limite de envio de e-mails. Isso pode ser definido tanto em termos de número de e-mails enviados quanto em termos de quantidade de bytes de informação transmitida. A partir daí, pode-se lidar de diferentes maneiras com os e-mails que forem enviados além do limite estabelecido. Por exemplo, é possível excluí-los imediatamente ou mantê-los para que sejam enviados assim que o limite de envio de mensagens for atualizado. A segunda opção pode ser utilizada ao determinar o valor ideal do limite de envio de e-mails pelos funcionários.
Além das restrições no envio de e-mails, o cbpolicyd permite configurar um limite para o recebimento de mensagens. Essa espécie de restrição, à primeira vista, pode parecer uma ótima solução para se proteger de bombardeios de e-mail, porém, na prática, a implantação de tal limite, mesmo que alto, pode acarretar o risco de não receber um e-mail importante sob certas condições. Por isso, é altamente recomendável evitar a inclusão de quaisquer restrições para o correio de entrada. No entanto, se você decidir correr esse risco, deve tratar a configuração do limite de mensagens recebidas com atenção redobrada. Por exemplo, pode-se limitar o número de e-mails provenientes de contratantes confiáveis, para que, caso o servidor de correio deles seja comprometido, não ocorra uma ataque de spam à sua empresa.
Para se proteger contra um fluxo de mensagens recebidas durante bombardeios de e-mail, o administrador do sistema deve adotar medidas mais inteligentes do que apenas impor um limite ao correio de entrada. Uma solução pode ser o uso de listas cinzas. O princípio de funcionamento delas é que, na primeira tentativa de entregar uma mensagem de um remetente não confiável, a conexão com o servidor é abruptamente interrompida, resultando na falha da entrega do e-mail. No entanto, se, dentro de um determinado período, o servidor não confiável tenta novamente enviar o mesmo e-mail, o servidor não interrompe a conexão e a entrega é concluída com sucesso.
O propósito de todas essas ações é que os programas de envio automático em massa de e-mails geralmente não verificam a eficácia da entrega da mensagem enviada e não tentam reenviá-la, enquanto uma pessoa certamente se certificaria de que sua mensagem foi enviada para o endereço correto ou não.
Você também pode ativar listas cinzas na interface web do cbpolicyd. Para que tudo funcione, é necessário criar uma política que capture todos os e-mails recebidos destinados a usuários em nosso servidor e, em seguida, com base nessa política, crie uma regra de Greylisting, onde você pode definir o intervalo durante o qual o cbpolicyd aguardará uma resposta de remetente desconhecido. Normalmente, esse intervalo é de 4 a 5 minutos. Além disso, as listas cinzas podem ser configuradas para que todas as tentativas bem-sucedidas e malsucedidas de entrega de e-mails de diferentes remetentes sejam contabilizadas e, com base em sua quantidade, seja tomada a decisão de adicionar automaticamente o remetente à lista branca ou negra.
É importante notar que o uso de listas cinzas deve ser abordado com a máxima responsabilidade. O ideal seria que o uso dessa tecnologia andasse de mãos dadas com a manutenção contínua de listas brancas e negras, para evitar a possibilidade de perda de e-mails realmente importantes para a empresa.
Além disso, adicionar verificações SPF, DMARC e DKIM pode ajudar a se proteger contra bombardeio de e-mails. Frequentemente, os e-mails que chegam durante um bombardeio dessa natureza não passam por essas verificações. A respeito de como fazer isso, já foi discutido. .
Assim, proteger-se contra uma ameaça como o bombardeio de e-mails é bastante simples e pode ser feito já na fase de construção da infraestrutura Zimbra para sua empresa. No entanto, é importante monitorar constantemente para garantir que os riscos associados a esse tipo de proteção nunca superem os benefícios que você obtém.
Fonte: habr.com
