O bombardeio por email é um dos tipos mais antigos de ataques cibernéticos. No seu núcleo, ele se assemelha a um ataque de DoS regular, mas, em vez de uma onda de solicitações de diferentes endereços IP, um grupo de emails é enviado ao servidor, que em grandes quantidades chega a um dos endereços de email, devido ao qual a carga nele aumenta significativamente. Esse ataque pode levar à incapacidade de usar a caixa de correio e, às vezes, até à falha de todo o servidor. A longa história desse tipo de ataque cibernético levou a várias consequências positivas e negativas para os administradores de sistema. Os fatores positivos incluem um bom conhecimento do bombardeio por email e a disponibilidade de maneiras simples de se defender contra esse ataque. Os fatores negativos incluem um grande número de soluções de software publicamente disponíveis para realizar esses tipos de ataques e a capacidade de um invasor se proteger com segurança da detecção.
Uma característica importante desse ataque cibernético é que é quase impossível usar com fins lucrativos. Bem, o invasor enviou um monte de emails para uma das caixas de correio, bem, ele não permitiu que a pessoa usasse emails normalmente, bem, o invasor invadiu o correio corporativo de alguém e começou a enviar em massa milhares de emails em toda a GAL, por causa dos quais o servidor travou ou começou a desacelerar de modo que se tornou impossível usá-lo, e o que vem depois? A conversão de um crime cibernético em dinheiro real é quase impossível; portanto, o bombardeio por e-mail é atualmente bastante raro e os administradores de sistema ao projetar a infraestrutura podem simplesmente não se lembrar da necessidade de se proteger contra um ataque cibernético.
No entanto, apesar do fato de o próprio bombardeio por e-mail ser uma atividade comercial bastante insensata, é frequentemente parte integrante de outros ataques cibernéticos, mais complexos e de vários estágios. Por exemplo, ao invadir e usar mensagens para invadir uma conta em algum serviço público, os atacantes geralmente “bombardeiam” a caixa de correio da vítima com letras sem sentido, para que a mensagem de confirmação se perca no fluxo e passe despercebida. O bombardeio por email também pode ser usado como um meio de pressão econômica sobre a empresa. Assim, o bombardeio ativo da caixa de correio pública de uma empresa, para a qual as aplicações dos clientes são recebidas, pode complicar seriamente o trabalho com elas e, como resultado, pode levar ao tempo de inatividade do equipamento, pedidos pendentes, perda de reputação e perda de lucro.
É por isso que o administrador do sistema não deve esquecer a probabilidade de realizar bombardeios por email e sempre tomar as medidas necessárias para se proteger contra essa ameaça. Dado que isso pode ser feito mesmo na fase de construção da infraestrutura de correio, bem como o fato de o administrador do sistema levar muito pouco tempo e mão-de-obra, razões objetivas para não fornecer proteção à infraestrutura contra bombardeio por email, simplesmente não permanecem . Vamos dar uma olhada em como a proteção contra esse ataque cibernético é implementada no Zimbra Collaboration Suite Open-Source Edition.
No coração de Zimbra está o Postfix - um dos agentes de transferência de código-fonte aberto mais confiáveis e funcionais no momento. E uma das principais vantagens de sua abertura é o suporte a uma ampla variedade de soluções de terceiros para expandir a funcionalidade. Em particular, o Postfix oferece suporte total ao cbpolicyd, um utilitário avançado de segurança cibernética para o servidor de email. Além de proteger contra spam e criar listas de permissões, listas negras e listas cinzas, o cbpolicyd permite que o administrador do Zimbra configure a verificação de assinatura SPF, além de definir limites para receber e enviar emails ou dados. Eles podem fornecer proteção confiável contra e-mails de spam e phishing, além de proteger o servidor contra bombardeios por e-mail.
A primeira coisa necessária ao administrador do sistema é a ativação do módulo cbpolicyd, 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 da web para poder gerenciar confortavelmente o cbpolicyd. Para fazer isso, é necessário ativar as conexões na porta da web número 7780, criar um link simbólico usando o comando
ln -s / opt / zimbra / common / share / webui / opt / zimbra / data / httpd / htdocs / webui e, em seguida, edite o arquivo de configurações usando o comando nano
/opt/zimbra/data/httpd/htdocs/webui/includes/config.php , no qual você precisa registrar as seguintes linhas:
$ DB_DSN = "sqlite: /opt/zimbra/data/cbpolicyd/db/cbpolicyd.sqlitedb";
$ DB_USER = "root";
$ DB_TABLE_PREFIX = "";
Depois disso, resta apenas reiniciar os serviços Zimbra e Zimbra Apache usando os comandos zmcontrol restart e zmapachectl restart. Depois disso, você terá acesso à interface da web em
example.com : 7780 / webui / index.php . A principal nuance é que a entrada para essa interface da web não é protegida de forma alguma e, para impedir que pessoas não autorizadas entrem nela, você pode simplesmente fechar as conexões na porta 7780 após cada entrada na interface da web.
As cotas para envio de e-mails, que podem ser definidas graças ao cbpolicyd, permitem que você se proteja do fluxo de cartas provenientes da rede interna. Essas cotas permitem definir um limite para o número máximo de cartas que podem ser enviadas de uma caixa de correio para uma unidade de tempo. Por exemplo, se os gerentes da sua empresa enviarem uma média de 60 a 80 e-mails por hora, dada a pequena margem, você poderá definir uma cota de 100 e-mails por hora. Para esgotar essa cota, os gerentes terão que enviar uma carta a cada 36 segundos. Por um lado, isso é suficiente para funcionar totalmente e, por outro lado, com essa cota, os invasores que obtêm acesso ao correio de um de seus gerentes não organizarão ataques por bomba de email ou spam em massa na empresa.
Para definir essa cota, é necessário criar uma nova política de restrição para o envio de cartas na interface da web e especificar que ela atue nas cartas enviadas no domínio e nas cartas que atuam em endereços externos. Isso é feito da seguinte maneira:
Depois disso, será possível 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 o usuário que exceder seu limite receberá. Depois disso, você pode definir a restrição no envio de cartas. Pode ser definido como o número de letras enviadas e o número de bytes de informações transmitidas. Nesse caso, com cartas enviadas além do limite designado, faça de maneira diferente. Assim, por exemplo, você pode simplesmente excluí-los imediatamente ou salvá-los para que eles sigam imediatamente após atualizar o limite para o envio de mensagens. A segunda opção pode ser usada ao identificar o limite ideal para o envio de e-mails pelos funcionários.
Além das restrições ao envio de cartas, o cbpolicyd permite configurar um limite para o recebimento de cartas. Essa restrição, à primeira vista, é uma excelente solução para proteção contra ataques por e-mail, mas, na verdade, o estabelecimento desse limite, mesmo que grande, é repleto do fato de que, sob certas condições, uma carta importante pode não chegar até você. É por isso que é altamente desencorajado incluir quaisquer restrições para o correio recebido. No entanto, se você ainda decidir arriscar, para se aproximar da definição do limite de mensagens recebidas, precisará se aproximar com atenção especial. Por exemplo, você pode limitar o número de cartas recebidas de contrapartes confiáveis para que, se o servidor de email deles estivesse comprometido, ele não executaria um ataque de spam na sua empresa.
Para se proteger do fluxo de mensagens recebidas durante o bombardeio por email, o administrador do sistema deve fazer algo mais inteligente do que simplesmente restringir o correio recebido. Essa solução poderia ser o uso de listas cinzas. O princípio de sua ação é que, na primeira tentativa de entregar uma mensagem de um remetente não confiável, a conexão com o servidor é interrompida abruptamente, e é por isso que a entrega da mensagem falha. No entanto, se em um determinado período o servidor não confiável tentar novamente enviar a mesma mensagem, o servidor não será desconectado e sua entrega será bem-sucedida.
O significado de todas essas ações é que os programas para envio em massa automático de emails geralmente não verificam o sucesso da entrega da mensagem enviada e não tentam enviá-la uma segunda vez, enquanto a pessoa certamente garantirá se sua carta foi enviada para o endereço ou não.
Você também pode ativar as listas cinzas 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, em seguida, criar uma regra de lista cinza com base nessa política, onde é possível configurar o intervalo durante o qual o cbpolicyd aguardará uma resposta repetida de um desconhecido. remetente. Geralmente são 4-5 minutos. Ao mesmo tempo, as listas cinzas podem ser configuradas para que todas as tentativas bem-sucedidas e malsucedidas de entregar cartas de diferentes remetentes sejam levadas em consideração e, com base no número delas, seja tomada a decisão de adicionar automaticamente o remetente às listas brancas ou negras.
Chamamos sua atenção para o fato de que o uso de listas cinzas deve ser abordado com a máxima responsabilidade. Será melhor que o uso dessa tecnologia acompanhe a manutenção constante das listas brancas e negras, a fim de excluir a possibilidade de perda de cartas realmente importantes para a empresa.
Além disso, a adição de verificações de SPF, DMARC e DKIM pode ajudar a proteger contra bombardeios por correio. Freqüentemente, as cartas recebidas durante o processo de bombardeio por correio não passam nessas verificações. Como fazer isso foi descrito
em um de nossos artigos anteriores .
Portanto, proteger-se de ameaças como o bombardeio por email é bastante simples, e você pode fazer isso mesmo na fase de construção da infraestrutura Zimbra para sua empresa. No entanto, é importante garantir constantemente que os riscos do uso dessa proteção nunca excedam os benefícios que você recebe.
Para todas as perguntas relacionadas ao Zextras Suite, você pode entrar em contato com o representante da empresa "Zextras" Katerina Triandafilidi pelo e-mail katerina@zextras.com