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).

 

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.

 

Estudo de Caso – rede Linux, Editora Manifesto

Nesta semana, tivemos a satisfação de entregar uma rede 100% Linux na Editora Manifesto, que publica a revista Retrato do Brasil.

A Editora utilizava uma rede LTSP adquirida da empresa Samurai em 2001. A tecnologia e a rede eram muito estáveis, mas a plataforma de HW e SW estava defasada, tanto em velocidade de processamento quanto em novas tecnologias Internet (streaming, flash, HTML5, etc.), além de crescente dificuldade de manutenção.

O projeto do upgrade tecnológico teve os seguintes pontos de partida: baixo custo, estabilidade e gerenciamento centralizado.

A Editora adquiriu um lote minibooks Intel ATOM dual-core como desktops, com 2GB de RAM e 320GB de HD Sata2, que forneceria um desempenho compatível com as necessidades dos usuários. O servidor escolhido foi HP ML-110G7. Todos os equipamentos foram fornecidos pela Bluetech.

Os desktops foram instalados com Ubuntu Desktop 11.04 LTS, o qual oferece uma alternativa robusta, moderna e atraente ao Microsoft Windows, além do conjunto de softwares de produtividade (browser, email, editor de texto, planilha eletrônica) competitivo e gratuito.

O servidor é um capítulo à parte. Pela premissa de gerenciamento centralizado, decidiu-se implementar diretório OpenLDAP 2.4 como backend de autenticação de todos os desktops, com transporte seguro via TLS. O gerenciamento de contas de usuários ficou a cargo do LDAP Account Manager (LAM), um aplicativo PHP. Finalmente, o serviço NFSv4 fornece o mapeamento transparente das pastas de trabalho locais aos desktops Ubuntu a um compartilhamento centralizado no servidor, facilitando os procedimentos de backup.

Este projeto foi concebido, definido, implementado e implantando em um mês, e demonstra a convergência entre tecnologia de ponta, custo contido e facilidade de gerenciamento de operação num ambiente Linux.

 

Amazon EBS Snapshot Copy

Em meados de Dezembro/2012, Amazon Web Services anunciou uma facilidade adicional para Elastic Block Store (EBS): a função Snapshot Copy permite que snapshots EBS possam ser copiados facilmente entre diferentes regiões de disponibilidade AWS.

Antes desta facilidade, a cópia de um EBS (ou de um snapshot) de uma região para outra envolvia um processo tortuoso. Era necessário anexá-lo a uma instância EC2 Linux, na região-origem; criar um novo EBS do mesmo tamanho e anexá-lo na região-destino a uma instância EC2 Linux, e depois utilizar o comando dd para copiar bloco-a-bloco do EBS-origem, via ssh, ao EBS-destino (ex. dd if=/dev/sdg | ssh -i root-key root@destino “dd of=/dev/sdf”)

Para usar esta nova facilidade, basta acessar o console de gerenciamento AWS, selecionar um snapshot para cópia, definir a região-destino, e comandar o início da cópia. Esta função de cópia pode ser iniciada via linha de comando, através da EC2 Command Line Interface, facilitando sua execução em modo batch. O snapshot copiado para a região-destino é como qualquer snapshot, e poderá ser usado para criar novos volumes EBS para serem anexados a instâncias EC2.

Esta função facilita o uso de múltiplas regiões de disponibilidade AWS para diversas finalidades, como entregar aplicações web em várias regiões geográficas, migrar aplicações de datacenter, implementar plano de recuperação de desastre, etc.

Amazon Glacier – Arquivamento de elevado volume

A área de tecnologia de qualquer empresa tem que lidar com volume cada vez maior de dados ativos (documentos, planilhas, emails – ninguém deleta mais emails hoje em dia -, vídeo de treinamento, gravações de ligações de voz, etc.). Como consequência, o arquivamento desta grande massa de dados – por períodos determinados por lei ou pelas boas práticas de governança – está se tornando um processo trabalhoso e caro, requerendo cada vez mais tempo e esforço na escolha da tecnologia (fita, disco, mídia óptica), no planejamento de capacidade, na manutenção de hardware e na negociação com fornecedores.

A Amazon Web Services apresentou recentemente um serviço de arquivamento, denominado Glacier, que interessará a muitos profissionais de TI. Com Glacier, qualquer volume de dados poderá ser arquivado de forma durável e fácil, e a um custo extremamente competitivo com as mais tradicionais bibliotecas de fitas e robôs, que formam o esteio das soluções de arquivamento há décadas.

Glacier oferece armazenamento para arquivamento de dados a um custo extremante baixo – até US$ 0,01 (um centavo de dólar) por Gigabyte por mês. Pode ser usado para qualquer volume, de megabyte a terabytes a petabytes, e não ná nenhum custo para setup inicial. Glacier acaba com as preocupações tradicionais de acerto no “capacity planning”, de falta de espaço para arquivamento, de verificar a integridade de hardware e dados, e de planejar redundância geográfica no arquivamento – independentemente do período de retenção do arquivamento.

Para começar a arquivar dados usando Glacier, basta criar um vault (em tradução livre, uma caixa-forte) e nomeá-lo. Cada região AWS permite até 1.000 vaults. Assim que criar o vault, basta fazer upload de dados, e estes serão organizados em arquivos (pela nomenclatura AWS). Cada arquivo pode conter até 40TB de dados, e há múltiplas maneiras de fazer upload. Os dados enviados serão criptografados com AES-256, e armazenados em formato de elevadíssima durabilidade. Glacier executará checagens regulares de integridade, e corrigirá eventuais erros de forma automática.

Para restaurar os dados, basta enviar um job para Glacier. O Amazon SNS poderá ser programado para avisá-lo assim que os dados estiverem disponíveis para download. Os dados pederão ser acessados via solicitações de HTTP GET.

Os custos do serviço Glacier estão aqui.

Atualmente, Glacier está disponível nas regiões S-East (N. Virginia), US-West (N. California), US-West (Oregon), Asia Pacific (Tokyo) e EU-West (Irlanda).