Zimbra e proteção contra sobrecarga de servidor

O e-mail solidificou-se como um padrão para comunicação comercial. Devido à alta eficiência econômica dos emails, além de vários recursos associados à citação de texto e anexos, são os emails mais adequados para o papel de uma maneira universal de troca de documentos e comunicação comercial educada. Esses mesmos recursos se tornaram a razão pela qual os spammers gostam tanto de e-mail. Como resultado, hoje o e-mail é um imenso oceano furioso de spam, em cujas águas apenas ocasionalmente são encontradas cartas comerciais. É por isso que uma das principais tarefas do administrador de qualquer servidor de email é a proteção contra emails de spam. Vamos dar uma olhada no que você pode fazer com isso no Zimbra Collaboration Suite Open-Source Edition.



Apesar da solução gratuita, o Zimbra OSE pode fornecer ao administrador do sistema uma tonelada de ferramentas extremamente eficazes para resolver o problema de recebimento de emails indesejados. Já escrevemos sobre utilitários como Amavis, SpamAssassin, ClamAV e cbpolicyd, que permitem filtrar com segurança mensagens de e-mail filtrando e-mails de spam, além de e-mails infectados e de phishing. No entanto, sua principal desvantagem é que todos eles trabalham com mensagens de correio já recebidas e gastam recursos do sistema na filtragem de mensagens inúteis, que sempre podem ser encontradas muito melhor. Mas e se sua empresa estivesse presa aos olhos de uma grande botnet que constantemente lança seu servidor de correio em quantidades tão grandes de lixo eletrônico que apenas a sua filtragem ocupará a maior parte da capacidade do servidor MTA?

Em teoria, você pode se proteger disso conectando um serviço de nuvem para filtrar as mensagens recebidas, mas, na prática, esse método de proteção não é adequado para todas as empresas, pois nesse caso você terá que confiar a terceiros o processamento não apenas de spam, mas também de correspondência comercial, o que nem sempre é seguro e muitas vezes diretamente contrário à política de segurança da empresa. Além disso, há riscos associados à confiabilidade do filtro de spam na nuvem. A saída dessa situação pode ser a organização da proteção do servidor por si só. Especialmente para esses fins, o Zimbra possuía o utilitário Postscreen, desenvolvido para proteger o servidor de correio de cartas enviadas por botnets, sem carregar o servidor de correio.

A essência do trabalho do Postscreen é que esse utilitário verifica todas as solicitações de conexão com o servidor de correio e não permite que os clientes que parecem suspeitos se conectem ao servidor. Como, segundo as estatísticas, cerca de 90% do spam no mundo é enviado por botnets, o Postscreen é frequentemente usado como o primeiro grau de proteção de um servidor de correio contra correspondências indesejadas. Graças a isso, o servidor de email pode funcionar de forma estável sem sobrecargas, mesmo diante de fortes ataques de spam de grandes redes de bots.

O princípio de operação do Postscreen é bastante simples, o utilitário é capaz de realizar várias verificações simples das cartas recebidas antes de transferi-las para o servidor de correio ou outros serviços que realizam uma verificação mais profunda e detalhada das cartas recebidas. Cada uma das verificações, respectivamente, pode ser aprovada, mas não pode ser aprovada. Com base nos resultados de cada uma das verificações, o Postscreen pode aplicar uma das três ações à escolha do administrador do Zimbra: Descartar , Ignorar ou Aplicar . A ação Eliminar força a conexão com o cliente a ser desconectada se a verificação falhar; a ação Ignorar permite ignorar os resultados das verificações ao tomar a decisão final, mas ao mesmo tempo coletar informações e estatísticas sobre as verificações, e a ação Impor permite levar em consideração os resultados das verificações ao tomar a decisão final. mas, ao mesmo tempo, continue executando todos os testes planejados pelo administrador do sistema.

O simples princípio de operação não significa facilidade de uso e configuração. O fato é que uma Postscreen configurada incorretamente pode se tornar o motivo pelo qual várias mensagens importantes para a empresa não chegarão ao destinatário. É por isso que é necessário abordar a instalação de uma ferramenta tão poderosa como o Postscreen com muito cuidado e testá-la constantemente quanto ao comportamento em determinadas situações.

O Postscreen no Zimbra é incluído inicialmente, mas muitos podem não estar satisfeitos com a configuração inicial. Agora, veremos a melhor opção para configurar o Postscreen em termos de segurança e sem riscos. Sua essência é que, após a falha de qualquer uma das verificações, o Postscreen não será desconectado do cliente sem falar, mas realizará todas as verificações até o fim e, se essas verificações falharem, será exibida uma mensagem de erro. Isso notificará o remetente vivo da não entrega da mensagem se o Postscreen a aceitar como spam. Isso é alcançado configurando o valor de aplicação nos parâmetros das verificações. É esse valor que permite concluir as verificações iniciadas até o final, sem interromper a conexão com o cliente na primeira falha, mas ao mesmo tempo, após a conclusão, ainda bloquear o email de spam sem entregá-lo ao servidor.

Para habilitar as verificações necessárias, insira os seguintes comandos:

zmprov mcf zimbraMtaPostscreenDnsblSites 'b.barracudacentral.org = 127.0.0.2 * 7' zimbraMtaPostscreenDnsblSites 'zen.spamhaus.org = 127.0.0. [10; 11] * 8' zimbraMtaPostscreenDnsblSites 'zen.spamhaus.org = 127.0.0. ..7] * 6 'zimbraMtaPostscreenDnsblSites' zen.spamhaus.org = 127.0.0.3 * 4 'zimbraMtaPostscreenDnsblSites' zen.spamhaus.org = 127.0.0.2 * 3 '

Este comando permite adicionar uma verificação de DNS das conexões de entrada aos dois bancos de dados de spam públicos mais populares e letras de taxa, dependendo do banco de dados em que o endereço do remetente será encontrado. Quanto mais "estrelas" penalizadas um cliente recebe, maior a probabilidade de ele ser um spammer

zmprov mcf zimbraMtaPostscreenDnsblAction enforce

Este comando determina a ação que é executada como resultado da aprovação na verificação de DNS. Nesse caso, o resultado do teste é lembrado e a própria letra continua sendo submetida a mais testes.

zmprov mcf zimbraMtaPostscreenGreetAction enforce

Como no protocolo SMTP, após uma conexão direta, o servidor inicia a comunicação com o cliente e, portanto, o Postscreen pode enviar uma saudação ao cliente. Devido ao fato de muitos clientes de spam, sem aguardar o final da saudação, começarem a enviar comandos, eles podem ser facilmente reconhecidos. Este comando permite que você leve em consideração os resultados desse teste, mas, ao mesmo tempo, continue a executar outros testes.

zmprov mcf zimbraMtaPostscreenNonSmtpCommandAção drop

Como parte desse teste, o Postscreen permite filtrar as conexões que não são provenientes de clientes de email. Como eles não enviam cartas, você pode desconectá-los com segurança do servidor sem medo.

zmprov mcf zimbraMtaPostscreenPipeliningAction enforce

Essa verificação é baseada no fato de que, por padrão, no protocolo SMTP, o cliente pode enviar apenas um comando por vez e aguardar o servidor responder a esse comando. No entanto, muitos bots de spam se comportam de maneira diferente enviando muitos comandos sem aguardar uma resposta do servidor. Isso permite que você identifique os bots de spam quase de maneira inconfundível.

Em princípio, essas verificações no Postscreen serão mais que suficientes para cortar a maior parte dos bots de spam do servidor e obter uma redução significativa na carga no servidor de correio. Ao mesmo tempo, as pessoas vivas receberão uma mensagem de que sua carta não foi entregue, o que reduz significativamente o risco de perda de mensagens importantes devido às configurações do Postscreen. Caso isso aconteça, você pode adicionar um remetente confiável à lista de permissões da Tela de publicação. Para criar listas brancas e negras do Postscreen, você deve primeiro criar o arquivo / opt / zimbra / conf / postfix / postscreen_wblist .

Adicionaremos uma lista de endereços IP e sub-redes permitidos e proibidos no formato de tabela CIDR. Por exemplo, bloqueie a sub-rede 121.144.169. *, Mas permita a conexão com um único endereço IP desta sub-rede:

# As regras são avaliadas na ordem especificada.
# Lista negra 121.144.169. * Exceto 121.144.169.196.
121.144.169.196/32 permitir
121.144.169.0/24 rejeitar

Chamamos sua atenção para a importância da ordem das entradas. O fato é que o Postscreen varrerá o arquivo com listas brancas e negras até a primeira correspondência, e se a sub-rede bloqueada estiver antes do endereço IP permitido, a verificação simplesmente não alcançará o registro de que esse endereço IP foi adicionado à lista branca e à conexão o servidor não vai acontecer.

Depois que o arquivo com listas brancas e negras for editado e salvo, você poderá ativar a verificação correspondente usando os seguintes comandos:

zmprov mcf zimbraMtaPostscreenAccessList "allow_mynetworks, cidr: / opt / zimbra / conf / postfix / postscreen_wblist"
zmprov mcf zimbraMtaPostscreenBlacklistAction enforce

Agora, o Postscreen, além das verificações que já definimos, também acessará o arquivo com listas brancas e negras, o que permitirá ao administrador resolver facilmente problemas com a incapacidade de conectar remetentes confiáveis ​​ao servidor.

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