O bombardeio de correio é um dos tipos mais antigos de ataques cibernéticos. Em sua essência, lembra um ataque DoS normal, só que em vez de uma onda de solicitações de diferentes endereços IP, uma onda de e-mails é enviada ao servidor, que chega em grandes quantidades a um dos endereços de e-mail, devido ao qual a carga nele aumenta significativamente. Tal ataque pode levar à incapacidade de usar a caixa de correio e, às vezes, pode até levar à falha de todo o servidor. A longa história deste tipo de ataque cibernético levou a uma série de consequências positivas e negativas para os administradores de sistemas. Os fatores positivos incluem um bom conhecimento sobre bombardeios por correio e a disponibilidade de maneiras simples de se proteger contra esse tipo de ataque. Os fatores negativos incluem um grande número de soluções de software disponíveis publicamente para realizar esses tipos de ataques e a capacidade de um invasor se proteger de forma confiável contra detecção.
Uma característica importante deste ataque cibernético é que é quase impossível utilizá-lo para obter lucro. Bem, o invasor enviou uma onda de e-mails para uma das caixas de correio, bem, ele não permitiu que a pessoa usasse o e-mail normalmente, bem, o invasor invadiu o e-mail corporativo de alguém e começou a enviar em massa milhares de cartas por toda a GAL, que é por que o servidor travou ou começou a ficar lento, tornando impossível usá-lo e o que vem a seguir? É quase impossível converter este tipo de crime cibernético em dinheiro real, pelo que o simples bombardeamento por correio é actualmente uma ocorrência bastante rara e os administradores de sistemas, ao projectarem infra-estruturas, podem simplesmente não se lembrar da necessidade de protecção contra tal ataque cibernético.
No entanto, embora o bombardeamento por e-mail em si seja um exercício bastante inútil do ponto de vista comercial, muitas vezes faz parte de outros ataques cibernéticos mais complexos e em vários estágios. Por exemplo, ao hackear e-mails e usá-los para sequestrar uma conta em algum serviço público, os invasores muitas vezes “bombardeiam” a caixa de correio da vítima com cartas sem sentido, de modo que a carta de confirmação se perde no fluxo e passa despercebida. O bombardeio postal também pode ser usado como meio de pressão econômica sobre uma empresa. Assim, o bombardeio ativo da caixa de correio pública de uma empresa, que recebe solicitações de clientes, pode complicar seriamente o trabalho com eles e, como resultado, pode levar à paralisação de equipamentos, pedidos não atendidos, bem como perda de reputação e perda de lucros.
É por isso que o administrador do sistema não deve esquecer a probabilidade de e-mail bombardear e sempre tomar as medidas necessárias para se proteger contra esta ameaça. Considerando que isso pode ser feito na fase de construção da infraestrutura de correio, e também que exige muito pouco tempo e trabalho do administrador do sistema, simplesmente não há razões objetivas para não fornecer proteção à sua infraestrutura contra bombardeio de correio. Vamos dar uma olhada em como a proteção contra esse ataque cibernético é implementada no Zimbra Collaboration Suite Open-Source Edition.
Zimbra é baseado no Postfix, um dos agentes de transferência de correio de código aberto mais confiáveis e funcionais disponíveis atualmente. E uma das principais vantagens de sua abertura é que ela suporta uma ampla variedade de soluções de terceiros para ampliar a funcionalidade. Em particular, o Postfix oferece suporte total ao cbpolicyd, um utilitário avançado para garantir a segurança cibernética do servidor de e-mail. Além da proteção anti-spam e da criação de whitelists, blacklists e greylists, o cbpolicyd permite ao administrador do Zimbra configurar a verificação de assinatura SPF, bem como definir restrições para recebimento e envio de e-mails ou dados. Eles podem fornecer proteção confiável contra spam e e-mails de phishing e proteger o servidor contra bombardeios de e-mail.
A primeira coisa que é exigida do administrador do sistema é ativar o módulo cbpolicyd, que vem pré-instalado no Zimbra Collaboration Suite OSE no servidor MTA de infraestrutura. Isso é feito usando o comando zmprov ms `zmhostname` +zimbraServiceEnabled cbpolicyd. Depois disso, você precisará ativar a interface web para poder gerenciar confortavelmente o cbpolicyd. Para fazer isso, você precisa permitir conexões na porta web número 7780, criar um link simbólico usando o comando ln -s /opt/zimbra/common/share/webui /opt/zimbra/data/httpd/htdocs/webuie edite o arquivo de configurações usando o comando nano /opt/zimbra/data/httpd/htdocs/webui/includes/config.php, onde você precisa escrever as seguintes linhas:
$DB_DSN="sqlite:/opt/zimbra/data/cbpolicyd/db/cbpolicyd.sqlitedb";
$DB_USER="raiz";
$DB_TABLE_PREFIX="";
Depois disso, resta reiniciar os serviços Zimbra e Zimbra Apache usando os comandos zmcontrol restart e zmapachectl restart. Depois disso, você terá acesso à interface web em :7780/webui/index.php. A principal ressalva é que a entrada nesta interface web ainda não está protegida de forma alguma e para evitar a entrada de pessoas não autorizadas, você pode simplesmente fechar as conexões na porta 7780 após cada entrada na interface web.
Você pode se proteger da enxurrada de e-mails vindos da rede interna usando cotas de envio de e-mails, que podem ser definidas graças ao cbpolicyd. Essas cotas permitem definir um limite para o número máximo de cartas que podem ser enviadas de uma caixa de correio em uma unidade de tempo. Por exemplo, se os gerentes do seu negócio enviam em média 60-80 emails por hora, você pode definir uma cota de 100 emails por hora, levando em consideração uma pequena margem. Para atingir essa cota, os gestores terão que enviar um e-mail a cada 36 segundos. Por um lado, isso é suficiente para funcionar plenamente e, por outro lado, com essa cota, os invasores que obtiveram acesso ao e-mail de um de seus gerentes não lançarão bombardeios de e-mail ou ataques massivos de spam na empresa.
Para definir essa cota, você precisa criar uma nova política de restrição de envio de e-mail na interface da web e especificar que ela se aplica tanto a cartas enviadas dentro do domínio quanto a cartas enviadas para endereços externos. Isto se faz do seguinte modo:
Depois disso, você poderá especificar com mais detalhes as restrições associadas ao envio de cartas, em particular, definir o intervalo de tempo após o qual as restrições serão atualizadas, bem como a mensagem que receberá um usuário que ultrapassou seu limite. Depois disso, você pode definir a restrição ao envio de cartas. Pode ser definido tanto como o número de cartas enviadas quanto como o número de bytes de informação transmitida. Ao mesmo tempo, as cartas enviadas além do limite designado devem ter tratamento diferenciado. Assim, por exemplo, você pode simplesmente excluí-los imediatamente ou salvá-los para que sejam enviados imediatamente após a atualização do limite de envio de mensagens. A segunda opção pode ser utilizada na identificação do valor ideal para o limite de envio de e-mails pelos funcionários.
Além das restrições ao envio de cartas, o cbpolicyd permite definir um limite de recebimento de cartas. Tal limitação, à primeira vista, é uma excelente solução para proteção contra bombardeios postais, mas na verdade, estabelecer tal limite, mesmo que grande, está repleto do fato de que, sob certas condições, uma carta importante pode não chegar até você. É por isso que não é altamente recomendável ativar quaisquer restrições para mensagens recebidas. No entanto, se você ainda decidir correr o risco, precisará abordar a definição do limite de mensagens recebidas com atenção especial. Por exemplo, você pode limitar o número de e-mails recebidos de contrapartes confiáveis para que, se o servidor de e-mail deles for comprometido, ele não lance um ataque de spam à sua empresa.
Para se proteger contra o fluxo de mensagens recebidas durante o bombardeio de correio, o administrador do sistema deve fazer algo mais inteligente do que simplesmente limitar o correio recebido. Esta solução poderia passar pela utilização de listas cinzentas. O princípio de seu funcionamento é que na primeira tentativa de entrega de uma mensagem de um remetente não confiável, a conexão com o servidor é interrompida abruptamente, razão pela qual a entrega da carta falha. Porém, se em determinado período um servidor não confiável tentar enviar novamente a mesma carta, o servidor não fecha a conexão e sua entrega é bem-sucedida.
O significado de todas essas ações é que os programas de envio automático de e-mails em massa geralmente não verificam o sucesso da entrega da mensagem enviada e não tentam enviá-la uma segunda vez, enquanto uma pessoa certamente se certificará de que sua carta foi enviada para o endereço ou não.
Você também pode ativar a lista cinza na interface da web cbpolicyd. Para que tudo funcione, você precisa criar uma política que inclua todas as cartas recebidas endereçadas aos usuários em nosso servidor, e então, com base nesta política, criar uma regra de Greylisting, onde você pode configurar o intervalo durante o qual cbpolicyd irá esperar para uma resposta repetida de um remetente desconhecido. Geralmente leva de 4 a 5 minutos. Ao mesmo tempo, as listas cinza podem ser configuradas para que todas as tentativas bem-sucedidas e malsucedidas de entrega de cartas de diferentes remetentes sejam levadas em consideração e, com base no seu número, seja tomada a decisão de adicionar automaticamente o remetente às listas brancas ou negras.
Chamamos a atenção para o facto de que a utilização de listas cinzentas deve ser feita com a máxima responsabilidade. O melhor seria que a utilização desta tecnologia andasse de mãos dadas com a manutenção constante de listas brancas e negras para eliminar a possibilidade de perda de emails verdadeiramente importantes para a empresa.
Além disso, adicionar verificações SPF, DMARC e DKIM pode ajudar a proteger contra bombardeios de e-mail. Freqüentemente, as cartas que chegam por meio do processo de bombardeio postal não passam nessas verificações. Como fazer isso foi discutido .
Assim, proteger-se de uma ameaça como o bombardeio por e-mail é bastante simples, e você pode fazer isso ainda na fase de construção da infraestrutura Zimbra para sua empresa. No entanto, é importante garantir constantemente que os riscos da utilização dessa proteção nunca excedam os benefícios que você recebe.
Fonte: habr.com