Zimbra – como deletar mensagem enviada a muitos destinatários

Use o script descrito abaixo para deletar rapidamente uma mensagem enviada a muitos destinatários

Zimbra logo

Zimbra Logo

A maioria dos administradores Zimbra já recebeu alguma ligação de usuário angustiado: “você consegue deletar a mensagem que mandei por engano, para a empresa toda (centenas de destinatários)?” ou de gerente de TI inconformado: “alguém enviou o manual de normas e procedimentos de 100MB para todos da empresa, agora a Internet está quase parando!”

Sempre é possível deletar emails entrando de conta em conta através do console de administração, mas quando a lista de destinatários é grande um bash script pode ser mais eficaz e rápido. Abaixo segue um script que facilita este trabalho, originalmente publicado no GitHub por jigstar.

#!/bin/bash
# USO: rm_message.sh user@domain.com subject
# Antes de executar, eh necessario criar uma listagem de contas de email
# com este comand: zmprov -l gaa | grep domain.com > /tmp/temp_email

if [ -z "$2" ]; then
echo "usage:  rm_message.sh user@domain.com <subject>"
exit 0
else
addr=$1
subject=$2
for acct in `cat /tmp/temp_email` ; do
    echo "Searching $acct  for Subject:  $subject"
    for msg in `/opt/zimbra/bin/zmmailbox -z -m "$acct" s -l 999 -t message "from:$addr subject:$subject"|awk '{ if (NR!=1) {print}}' | grep -v -e Id -e "-" -e "^$" | awk '{ print $2 }'`
      do
    echo "Removing "$msg" from "$acct""
    /opt/zimbra/bin/zmmailbox -z -m $acct dm $msg
    done
done
fi

Antispam via Postfix – atualização 2016

Publicamos as listas mais recentes da nossa proteção antispam, contendo atualizações nos domínios mais recentes de spammers (Julho/2016).

As listas whiteblackip e sender_access devem ser utilizadas com Postfix smtpd_recipient_restrictions, da seguinte maneira:

smtpd_recipient_restrictions = [outras opções], 
check_sender_access lmdb:/opt/zimbra/postfix/conf/sender_access, 
check_client_access lmdb:/opt/zimbra/postfix/conf/whiteblackips,
[mais opções...]

 

Rede Wireless 802.11ac

Dispositivos com suporte a rede wireless 802.11ac está começando a ganhar volume no mercado corporativo e de consumo. Veja as suas principais características:

  1. Suporte a taxas de transmissão de até 6,93Gbps.
  2. Transmissão somente na banda de 5GHz.
  3. Não há alteração no alcance da rede wireless.
  4. MU-MIMO: permite transmissão para até 4 outros dispositivos de forma simultânea, com uso de múltiplas antenas (nas outras versões 802.11, apenas 1 dipositivo transmite a cada vez).

A implantação da tecnologia 801.22ac está prevista em 3 etapas.

  1. Etapa 1 (já no mercado) prevê uso de canais de transmissão de rádio de 80MHz e até 3 fluxos de dados totalizando 1.3Gbps (por dispostivo).
  2. Na etapa 2 estão previstos os primeiros dispostivos MU-MIMO, o uso de canais de transmissão de rádio de 160MHz e até 4 fluxos de dados, totalizando 3.47Gbps.
  3. Na etapa 3 estão previstos 8 fluxos de dados totalizando 6.93Gbps.

Dispositivos 802.11ac podem coexistir com dispostivos com tecnologias 802.11 anteriores, mas estes vão limitar a taxa máxima de dados. Assim, a recomendação é isolar dispositivos 802.11ac em rede própria. As redes cabeadas existentes, às quais novas redes 802.11ac estarão conectadas, precisarão de revisão por conta da maior taxa de transmissão.

 

 

Como prevenir ataques DDoS ao servidor Apache

Cedo ou tarde, qualquer servidor Apache vai sofrer ataque DDoS HTTP. Felizmente, podemos utilizar o mod_evasive do Apache para medidas evasivas contra um ataque DDoS ou por força bruta.

A sua instalação e ativação é bem simples em um servidor Linux moderno. Para Ubuntu ou Debian, basta executar:

# apt-get install libapache2-mod-evasive.

Será necessário acrescentar esta configuração em /etc/apache2/mods-available/mods-evasive.load:

<IfModule mod_evasive20.c>
        DOSHashTableSize 2048
        DOSPageCount 20
        DOSSiteCount 300
        DOSPageInterval 1.0
        DOSSiteInterval 1.0
        DOSBlockingPeriod 10.0
        DOSLogDir "/var/log/apache2/evasive"
        #DOSEmailNotify admin@domain.com
        DOSWhiteList 127.0.0.1
</IfModule>

Esta configuração faz com que qualquer IP que faça mais do que 20 solicitações da mesma URL num intervalo de 1 segundo, ou mais do que 300 URLs ao mesmo website num intervalo de 1 segundo, seja bloqueado por 10 segundos e passe a receber erro 403 (Forbidden). O localhost 127.0.0.1 é liberado da checagem.

Depois, será necessário criar a pasta para guardar os logs de ação do mod_evasive, e reiniciar o Apache:

# mkdir -p /var/log/apache2/evasive
# service apache2 restart

 

 

Antispam via Postfix – atualização

Com base na experiência de quase 12 meses de ajustes no bloqueio antispam em nosso servidor de email corporativo, recentemente implementamos dois dos mecanismos de bloqueio básicos do Postfix para o sistema de email de um cliente, e obtivemos uma  redução de spam da ordem de 90% de imediato.

1) Bloqueio via header_checks, a apenas um cabeçalho:

/^List-Unsubscribe/ REJECT

2) Bloqueio via sender_access, com uma lista conhecida de spammers brasileiros. A lista pode ser obtida aqui.

Resultado surpreendente!

 

nbtscan – como descobrir o nome NetBIOS do Windows

Aqui vai outra ferramenta de rede muito útil no dia-a-dia do administrador Linux e Samba, nbtscan, que permite descobrir qual é o nome NetBIOS de um PC Windows com determinado IP, conforme ilustrado na tela abaixo:

Screenshot from 2014-07-10 12:18:26Note que, caso a distribuição de IPs é dinâmica vi DHCP, o nome da estação Windows fica registrado também nas tabelas de atribuição e nos logs do servidor DHCP.

 

MTR – ferramenta para depurar lentidão de Internet

A Internet está cada vez mais complexa, e muitas vezes é difícil descobrir a causa da demora para uma página web carregar ou para fazer um download.

Há diversas ferramentas Linux para facilitar debugs nesse sentido, uma delas é o MTR (My TraceRoute), que combina os tradicionais ping e traceroute em uma ferramenta semi-gráfica. Executando o comando “mtr www.intercomti.com.br” numa sessão bash, podemos observar esta tela:

Screenshot from 2014-06-13 16:20:54Claramente podemos ver por onde o tráfego está passando entre a estação Linux (192.168.150.53) e o servidor destino linode-gw.intercomti.com.br. Neste caso específico, há 2 informações adicionais importantes:

  1. Entre os hosts 6 e 7 há um aumento significativo de tempo de Ping, indicando que o tráfego está passando por um link de alta latência.
  2. Não há nenhuma perda no tráfego (perdas na transmissão TCP reduzem muito a taxa de transferência).

 

AWS – como recuperar uma instância Windows Server finalizada

Dias atrás, um cliente nosso comandou a operação “Terminate” numa instância Windows Server 2008 R2 na Amazon West Virginia sem função de “Termination Protection“, e fomos incumbidos de recuperar o servidor.

Por sorte, os volumes que compunham o servidor ainda estavam intactos. A recuperação da instância exigiu uma seqüência de ações semelhante àquela que seria usada para substituir um hardware físico defeituoso, seqüência esta delineada a seguir:

  1. Criar uma nova instância EC2 com servidor Windows 2008 R2.
  2. Assim que a instância estiver ativa, desligá-la.
  3. Dissociar o volume de boot desta nova instância.
  4. Associar o volume de boot da instância antiga com à nova instância, como dispositivo /dev/sda1.
  5. Associar outros volumes à nova instância.
  6. Iniciar a nova instância.

Assim que certificarmos que todas as funções de software e os dados estavam intactos, geramos snapshots devidamente e configuramos “Termination Protection” para evitar futuros problemas!

Antispam via Postfix

Recentemente implementamos um upgrade na proteção antispam do sistema de email Intercom, que é utilizado por diversos clientes nossos junto com serviço agregado de backup centralizado.

O serviço de email Intercom sempre foi baseado em Qmail, e através de Qmailscanner é feita a integração antivírus com Clamav e antispam com Spamassassin, que possui filtragem Bayesiana habilitada e tem treinamento regular. O próprio Qmail permite diversos bloqueios antispam (RBLs, contra remetentes registrados em envelop-sender, SPF, etc.).

Pelo crescimento vertiginoso no volume de spam nos últimos tempos (por conta de aumento de empresas de email-marketing, facilidade de compra e operação de softwares de mass-mailing, e adoção de email-marketing por empresas que nunca o utilizou, etc.), sentimos necessidade de melhorar a proteção antispam do sistema de email. Mas Qmail não é atualizado há muito tempo (último Netqmail foi de 2005; Qmail-spp, de 2008), e não possui mecanismos atualizados de filtragem com base em análise do cabeçalho dos emails. Sempre podemos filtrar cabeçalhos via Spamassassin, mas economizaremos CPU se conseguirmos rejeitar spams logo no início das sessões SMTP.

Depois de diversas análises, optamos por adicionar um servidor Postfix à frente do Qmail, para aproveitar seus múltiplos mecanismos de controle de acesso. Além dos bloqueios triviais no início de sessão SMTP (reject_non_fqdn_*, reject_unknown_*, check_client_access, reject_rbl_client), implementamos uma checagem extremamente poderosa: header_checks. Com este mecanismo, podemos filtrar por qualquer atributo do cabeçalho de email (exemplos: List-Unsubscribe e X-Mailer), facilitando muito o bloqueio de emails gerados por sistemas de email-marketing.

Com a estrutura de bloqueio Postfix implementada, fizemos um trabalho intensivo de análise de cabeçalhos de emails para identificar e selecionar atributos genéricos para bloqueio. Depois de 15 dias, os resultados são muito animadores: redução aproximada de 95% de spam! (comparando número de spams capturados num período de 15 dias antes do início das filtragens, com um mesmo período de 15 dias após início da filtragem).

Há alguns aspectos para melhorias ainda (mais especificamente na proteção SPF, em casos onde os domínios-remetentes não tenham registro SPF), mas estamos muito satisfeitos no salto de eficácia da proteção anti-spam.

Sobrecarga em tasks do Cron

Autoprojete-se no seguinte cenário da sua infra-estrutura: Existem diversas tarefas agendadas via Cron em seu sistema operacional. No entanto, por alguma razão, elas levam mais tempo para serem executadas do que o previsto. Por que? O que pode estar havendo? Muitas pessoas têm como conceito que as coisas movidas por tecnologias ou funcionam ou não funcionam. No entanto, existem alguns casos que perdas de integridade e confiabilidade não são tão brutas e repentinas. Elas ocorrem vagarosamente assim como um relógio de quartzo pode atrasar eventualmente, enquanto um relógio feito de isótopo de césio 133 apenas atrasará após centenas de anos de utilização, isto é, o início do seu respectivo clock.

 

Basicamente temos que esses atrasos podem significar que as tarefas começaram a se sobrepor e a serem executadas ao mesmo tempo. Se esses cronjobs estiverem atuando sobre os mesmos dados de um banco de dados, por exemplo, isso pode gerar uma corrupção de dados. Se eles estiverem fazendo um grande processamento de dados, esta ação poderá ter como consequência um elevado custo energético para a CPU da máquina. Por causa dessa alta carga, esses cronjobs iniciam um círculo vicioso resultando em mais problemas para o administrador do sistema operacional, uma vez que, os cronjobs mantêm os seus respectivos lançamentos e se sobrepõem uns aos outros.

 

No mundo GNU/Linux sempre estamos nos aperfeiçoando. E para que isto ocorra, problemas precisam surgir. O problema de sobrecarga do Cron apareceu no nosso cotidiano, e uma evolução das nossas ferramentas tornou-se necessária ou pelo menos a integração de soluções modulares disponibilizando-se como algo mais performático e eficaz.

 

Flock

O flock é uma ferramenta muito interessante para o gerenciamento de arquivos de bloqueio. Esses arquivos de bloqueio são usados para determinar se um script ou um aplicativo já está em execução (comparável a um arquivo PID que contém a identificação do processo do script sendo executado). Se o bloqueio existe, o cronjob não será iniciado. Se o bloqueio não existe, é seguro lançar o cron.

 

Veja o seguinte exemplo comum, onde um cron é executado a cada minuto no servidor.

$ crontab -l
* * * * * /usr/bin/php /www/app/cron.php

Se o script leva mais de um minuto para executar, eles começam a se sobrepor.

 

Para evitar isso, você pode mudar com o exemplo flock abaixo.

$ crontab -l
* * * * * /usr/bin/flock -w 0 /root/cron/cron.lock /usr/bin/php /www/app/cron.php

 

O exemplo a cima requer que o flock gerencie esses arquivos de bloqueio. Se isso ainda não existe no seu sistema, a instalação deve ser tão simples como um yum install flock ou apt-get install flock, dependendo de sua distribuição Linux.

 

No momento em que o flock começa, ele bloqueia o arquivo .lock que você especificar no comando. Você pode ver isso ao solicitar o usuário/script que está tendo o bloqueio sobre esse arquivo.

$ fuser -v /path/to/cron.lock
USER        PID ACCESS COMMAND
cron.lock:           root       7836 f…. flock
root       7837 f…. php

 

Ele vai mostrar o processo de IDs (PIDs) do script que está mantendo o bloqueio. Se nenhum script estiver mantendo o bloqueio, o comando fuser retornará simplesmente nada.

$ fuser -v /path/to/cron.lock

 

Então, o flock é uma boa maneira de evitar a sobreposição de cronjobs usando uma ferramenta de linha de comando adicional.
 

 

 

Pgrep

Outro método, sem o uso de arquivos de bloqueio, é utilizar um liner bash-one bem simples que verifica o arquivo de execução atual e o executa se ele não estiver funcionando. O grande segredo aqui é envolver seu crontask em um nome exclusivo do bash-script, assim:

$ cat /root/cron/cron.sh
#!/bin/bash
/usr/bin/php /www/app/cron.php

$ chmod +x /root/cron/cron.sh

 

No seu crontab, ele deve ser listado assim:

$ crontab -l
* * * * * /www/app/cron.sh

O comando acima irá, assim como o primeiro exemplo, executar o nosso script PHP a cada minuto através de um script. Para evitar a sobreposição, ele pode também ser alterado para isto:

 

$ crontab -l
* * * * * /usr/bin/pgrep -f /root/cron/cron.sh > /dev/null 2> /dev/null || /root/cron/cron.sh

O comando pgrep irá retornar falso se não encontrar um processo de execução correspondente ao primeiro argumento, /root/cron/cron.sh. Se ele retornar falso, vai processar a segunda parte da comparação OR  (a linha vertical dupla, ||). Se o processo de execução foi encontrado, pgrep irá retornar o ID do processo (PID) e Bash não vai continuar para a segunda parte do argumento OR, já que o primeiro já retornou verdadeiro.

 

A dica aqui é usar nomes de script muito originais. Se o nome é muito genérico (como “cron.sh”), pgrep pode retornar IDs de processo a partir de outras tarefas cron em execução e não executar o cron que você queria.

 

 

Utilizando bloqueio de arquivos dentro do script

Se os exemplos acima não estão disponíveis para você, você ainda pode usar o conceito de arquivos de bloqueio em seu aplicativo. Um dos primeiros comandos em seu script poderia ser verificar a existência de um arquivo de bloqueio. Se ele existir, o script poderia simplesmente sair (1) do aplicativo e parar de rodar. Se o bloqueio de arquivo não existir, o script poderia criá-lo e evitar que o próximo trabalho seja executado. Como último passo no seu script, você remove o arquivo de bloqueio para indicar que o script terminou e permitir que a próxima execução continue.