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.

AWS – como recuperar a senha do administrador para Windows Server

No mundo da tecnologia, acidentes sempre acontecem, e o que importa é sempre existir procedimentos para recuperação de desastres.

Recentemente, um cliente nosso alterou a senha do administrador num servidor Windows 2008R2 hospedado na Amazon Web Services, e usou caracteres acentuados num teclado francês. Resultado: a senha anotada não permitu mais login, e não havia outra conta de login com direitos de administrador.

A seguinte sequência de ações permitiu recuperar a senha perdida:

  1. Criar uma nova instância EC2 com servidor Windows 2008.
  2. Desligar o servidor Windows cuja senha está perdida, e identificar o volume EBS do drive C:.
  3. Dissociar este volume EBS, e associá-lo à nova instância EC2 como drive D:.
  4. Editar com Notepad o arquivo D:\Program Files\Amazon\Ec2ConfigService\Settings\config.xml.
  5. O primeiro parâmetro deste arquivo é “Ec2SetPassword”; mudar seu valor para “Enabled”, depois salvar o arquivo.
  6. Dissociar o volume EBS, e associá-lo novamente à instância Windows cuja senha está perdida, como volume /dev/sda1.
  7. Iniciar esta instância Windows, e pelo console EC2 a função “Get Windows Password” permite recuperar nova senha do administrador.