Mnemonic's Fike

Da genialidade à imbecilidade o limite é uma curva

Até quando ele irá sangrar?

| Comments

Até quando corações irão sangrar?

Refazendo a pergunta, até quando teremos novidades sobre as falhas do OpenSSL e o Heartbleed? Hoje, talvez, seja a pergunta de um milhão de obamas.

Você, querido (e raro) leitor deve ter visto em milhares de sites o transtorno que o HeartBleed está causando. Pelo impacto causado é provável que seja a maior falha de segurança na era da Internet 2.0.

Resumindo o que pude compilar:

Robin Seggelmann enviou um patch para o OpenSSL implementando a extensão Heartbeat para TLS (RFC 6520)8. Infelizmente com ela foi também entrou a falha que permite capturar as chaves privadas, essa falha foi chamada pelo Codenomicon como HeartBleed.

O xkcd fez um quadrinho interessante sobre a falha.

O bom texto para entender um pouco mais o bug, é ir ao IDGNow.

O patch foi enviado pelo Robin Seggelmann em Dezembro de 2011 e entrou na versão 1.0.1 (Abril de 2012), afetando as versões posteriores até a 1.0.1f. Algumas formas de contornar são atualizar para versão 1.0.1g ou compilar novamente o Openssl usando a flag -DOPENSSL_NO_HEARTBEATS. Se você estiver usando servidor web (Apache, Nginx, etc) e usar SSL para HTTPS, considere gerar novamente os certificados, nos meus testes usando certificado com certificado antigo e o OpenSSL atualizado continuo apresentando problema com Heartbleed.

O impacto é tão significativo que praticamente todos os grandes serviços na internet bloquearam as senhas antigas forçando os usuários gerarem novamente. Na semana passada tinha até uma lista no Github com os sites mais famosos que ainda não tinha atualizado o OpenSSL e os certificados.

Além dos servidores web, outros softwares foram afetados?

Provavelmente sim, ao menos na teoria, todos os softwares que usam TLS estão potencialmente estão vulneráveis. O OpenSSH não foi afetado em princípio (até que alguém provar que sim…), outros serviços que usam somente SSLv3 também não. Entretanto, comenta-se que o Android na versão 4.1.1 tem o Hearbleed e todos os dispositivos que usam o BlackBerry Messenger também foram comprometidos. Não posso deixar de mencionar que também foi anunciado que alguns equipamentos da Cisco e Juniper entraram na lista também. A Oracle listou quais versões de seus produtos foram afetados pelo bug.

Em meio a tempestade a Akamai enviou um patch inicial para o OpenSSL com a intenção de melhorar a segurança no armazenamento das chaves privadas do SSL, entretanto Willem Pinckaers questionou a efetividade do patch. Provável que tenha novas revisões evolutivas do patch até que seja incorporado em defitinitivo no OpenSSL.

Considerando que o Heartbleed está nos servidores web desde 2012, o quanto as senhas e dados de milhões de usuários foram vazados. É impossível contabilizar porque são dois anos em que a falha esteve disponível sem nenhum alarde.

As recomendações no geral são: atualizar o OpenSSL, gerar novamente as chaves privadas e trocar as senhas. Recomendo que daqui um tempo, troque novamente as senhas porque o Hearbleed porque ainda tem muita coisa pela frente. Pelo que a Bloomblerg noticiou, a NSA sabia da existência do bug há dois anos. Quem mais sabia? Provavelmente muitos outros, infezlimente.

O Pessoal do Elastica criou um vídeo explicando como é o HeartBleed.

Isso me lembrou uma outra falha que causou um grande alvoroço e que acidentalmente foi introduzida também no OpenSSL (0.9.8c-1) mas especificamente no Debian e derivados. A falha foi descoberta em Maio de 2008 pelo Luciano Bello e ela comprometeu as chaves SSH, OpenVPN e DNSSEC.

O curioso que até os produtos e os serviços da Microsoft e outras empresas com a cultura de software proprietários não foram afetados e tem muitos “especialistas” alegando que os produtos/sistemas deles são mais seguros. Esse argumento é levemente falso porque o Heartbleed somente teve essa repercussão grande porque o OpenSSL tem uma licença considerada Código Aberto (“Software Livre”). Se o OpenSSL tivesse uma licença como a maioria dos produtos da Microsoft, provavelmente não saberíamos que ele existia.

Algumas pessoas são bem críticas ao OpenSSL, principalmente pela código enorme (200 mil linhas) e de qualidade duvidosa. Ao menos é o que diz o Poul-Henning Kamp, desenvolvedor e Varnish. Recomendo ler o artigo (inglês) na [ACM].

Alternativas?

GnuTLS e PolarSSL são algumas. Se alguém já usou algum em seus projetos, conte a experiência para nós. :)

O pessoal do OpenBSD fez um fork (LibreSSL) e estão fazendo uma pequena faxina no código para que falhas como o Heartbleed tenha pouca probabilidade de acontecer.

O artigo na Wikipedia do Heartbleed é a melhor compilação sobre o bug. Vale a leitura.

Recauchutagem do servidor do PostgreSQL Brasil

| Comments

Algum tempo atrás o servidor (olifante) do PostgreSQL Brasil foi invadido e foi colocado algumas páginas em russo. Também foi instalado um web shell que o invasor pode acessar praticamente qualquer parte do servidor.

Os serviços ativos até então eram: o site do PostgreSQL Brasil, o Planeta PostgreSQL Brasil, as listas de discussão e os sites das Conferências PostgreSQL Brasil.

Até o que o Olifante seja reinstalado, apenas as listas de discussão estão funcionando temporariamente em outro servidor.

É ruim que este tipo de coisa aconteça, entretanto o importante para pensar em como evitar que isso aconteça novamente.

Então, um pouco mais de paciência e todos os serviços estarão novamente no Olifante.

Imagem originalmente postada no Flickr do Eric Schmuttenmaer, o original pode ver [aqui][3].

Videoconf do hangout caindo no Debian

| Comments

Ultimamente tenho participado de muitas reuniões por videoconferência usando o Skype ou Hangout. O Hangout especificamente não estava funcionando direito no meu Debian Sid, ao iniciar a videoconferência, ela caía automaticamente.

Procurando um pouco encontrei no fórum de produto do Hangout pessoas com problema similar e que resolveram removendo o pacote libudev0.

lang=bash
1
#aptitude remove libudev0

Voltando ao mundo das corridas

| Comments

Recuperação de uma lesão nunca é fácil, já mais de um ano que não participava de corridas de ruas e na voltei a correr na corrida de verão do Circuito das Estações no mês de Dezembro de 2013. A intenção era correr sem me preocupar com o pace, meu tempo de corrida, etc. Era apenas correr sem dor.

Aos poucos fui sabotando meu planejamento inicial, esqueci o meu tênis de corrida e fui com um tênis que uso apenas para exercícios na academia. Para acrescentar um pouco mais, cheguei um pouco atrasado, faltando 30 segundos para fecharem a largada para preparem a saída da turma dos 10K que iria sair logo mais. Já pode imaginar que não tive tempo de fazer o aquecimento e nem o alongamento.

A corrida em si foi super tranquila, exceto pela euforia de correr primeiros 2k com um pace abaixo dos 5 minutos (não tenho certeza do meu pace porque esqueci meu relógio de corrida…) e os últimos 3km meu fôlego desapareceu completamente mas ao invés de continuar correndo como se fosse a minha última corrida da minha vida, diminui o ritmo para chegar ao final bem.

Não tenho o tempo oficial porque não tive tempo de pegar o chip da organização para marcação oficial do tempo. Mas não importa, pela minhas contas devo ter fechado os 5km perto dos 30 minutos. Gostei de voltar correr novamente e não sentir o nelson voltar a incomodar. O único efeito colateral foi as dores no dia seguinte por ficar tanto tempo sem treinar.

Sabe porque gosto de correr? Porque posso ter essa vista.

Definitivamente 2014 estou de volta as corridas. :)

Sua nuvem cai?

| Comments

Você acha que Cloud Computing são nuvens bonitinhas como essas?

Ou ela está mais para isso?

Existe um falso mito que hospedar os servidores ou aplicação na nuvem (ou cloud se preferir…). Não é mais necessário se preocupar com problemas de disponibilidade como: geradores de energia elétrica, banco de baterias (nobreak), circuitos redundantes de rede lógica e elétrica, segurança patrimonial, etc. Entretanto ao usar algum serviço de nuvem, você está delegando essas preocupações para outra empresa.

Nesse mês (Dezembro de 2013) muitas empresas que hospedam suas aplicações na nuvem foram surpreendidas porque um datacenter teve uma indisponibilidade do tipo citada acima. O datacenter, bem conhecido, teve um problema de energia elétrica e praticamente tornou indisponível todos os sistemas que estão ali hospedados, dentre eles alguns dos principais fornecedores de cloud e consequentemente todos os clientes deles também tiveram seus sistemas indisponíveis.

Um problema deste tipo num datacenter é difícil de acontecer mas acontece, aconteceu e acontecerá. É como um acidente de avião, são várias pequenas coisas que aparentemente não poderiam derrubar uma avião mas elas encadeadas derrubam. No caso de um datacenter são um conjunto de pequenos incidentes/problemas que podem torná-lo indisponível.

O falso mito que ao colocar uma aplicação/sistema na nuvem, ele nunca ficará indisponível porque na nuvem as coisas funcionam automagicamente é mais comum que possa imaginar. Pense um pouco, todo sistema precisa estar armazenado em algum lugar, se não está na empresa precisa estar em outro lugar mesmo na nuvem. A nuvem (IaaS, SaaS, PaaS, etc) facilita muito porque muito coisa é entregue praticamente pronta e com um pouco de ajuste já é possível disponibilizar um serviço rapidamente. Entretanto mesmo na nuvem, um sistema estará alocada num ou mais datacenters. Portanto ao considerar hospedar seu sistema numa infraestrutura na nuvem, considere pensar no contingenciamento dele.

Veja alguns exemplos de incidentes de indisponibilidades:

Geralmente ao colocar um sistema ou site num fornecedor de nuvem como AWS, a maioria esquece de considerar o contigenciamento no custo operacional. A necessidade somente é percebida posteriormente após uma indisponibilidade como as citadas acima. Uma grande vantagem da nuvem é permitir ter um plano de contingência mantendo quase todos serviços de contingência desligado, mantendo somente o necessário para fazer a sincronização dos dados de um infraestrutura para outra (de uma região para outra no caso do AWS).

Alguns sites adotam como parte secundário do plano de contingência ter as partes principais em cache numa CDN (Content Delivery Network), tendo como o ponto principal da contingência a redundância dos serviços numa região geograficamente distante. Exemplo: Numa região diferente do AWS ou num datacenter numa região diferente no caso da Rackspace.

O caso do Netflix é bem interessante como estudo de alta disponibilidade e contingência usando AWS, leitura recomendadíssima.

Se você estiver considerando migrar suas aplicações para a nuvem, considere um plano de contingência. Se puder, construa a arquitetura de seu site, sistema, aplicação, etc. considerando tecnologias que permitam trabalhar de forma distribuída e com redundância. Afinal, uma empresa com o seu negócio parado pode ser muito custoso do que alocar mais recursos computacionais para melhorar o SLA da sistema que suporta o negócio.

Imagens de Charles Rondeau e MALIZ ONG, elas podem ser encontradas em Public Domain Pictures.

Skype e computadores com duas placas de video

| Comments

Infelizmente uso muito Skype no trabalho e estava com um problema com ele ao participar de videoconferências, ele simplesmente caia (famoso segment fault). Depois de um tempo ele automagicamente voltou a funcionar.

Conversando com o Euler e tentando ajudá-lo a fazer o Skype funcionar, percebi que esse problema acontece em computadores que tem duas placa de vídeos e os drivers do kernel linux estão carregados na memória. Se você está com um problema como esse e tem duas placas de vídeo (no meu caso, a segunda placa é uma Nvidia), pode usar o bumblebee para contornar o problema.

O projeto Bumblebee permite usar a tecnologia Nvidia Optimus. O principal ganho em instalar o bumblebee é melhorar o gerenciamento de energia e ganhar alguns minutos a mais ao usar a bateria do notebook.

Para instalá-lo no Debian é relativamente simples, basta:

1
#aptitude bumblebee

Se quiser executar o Skype pela placa de vídeo Nvidia:

1
$optirun skype

Recuperando os podcasts perdidos

| Comments

Um pouco de arqueologia, recuperei alguns episódios de alguns podcasts que participei algum tempo atrás. O GDHcast que participei pontualmente com o @Leandro Santos nos episódios que participei. Originalmente o GDHCast foi criado pelo @Carlos Morimoto, famoso pelo Guia do Hardware e o Kurumin Linux.

Os episódios do GDHCast que participei podem ser ouvidos aqui.

O Navaranda Podcast foi experimentação fantástica realizada por @Emerson Luis, César Cardoso, Guto Carvalho, eu e muitos outras pessoas. Ele começou numa brincadeira falando sobre assuntos que gostávamos de conversar e foi crescendo até entrevistar os então Ministro do Planejamento (@Paulo Bernardo) e Ministro das Relações Instituicionais (@Alexandre Padilha). O legal era realizar os episódios literalmente na varanda do Emerson.

Ah claro, era uma delícia pesquisar músicas com licenças em Creative Commons. ;)

Infelizmente, não consegui recurperar as entrevistas dos ministros mas os registros anteriores estão todos aqui.

Fonte da imagem: Wikipedia

Convertendo arquivos de música para Ogg com avconv

| Comments

Eu estava recuperando os arquivos do Navaranda Podcast para deixar disponível na internet. A versão original estava no formato WAV e minha intenção era converter todos para o formato OGG. Para fazer isso, usei o avconv (um fork do ffmpeg) e diminiu o bitrate para 6kbits/s.

Primeiramente instalando o avconv.

lang=bash
1
#aptitude install avconv

Agora, a conversão em si:

lang=bash
1
2
3
$for i in $(echo *.wav) 
  do avconv -i $i -acodec libvorbis -b:a 64k ${i%%.wav}.ogg
done

Ah, já ia esquecendo! Isso foi feito no Debian. ;)

DatabaseCast 38: Vagas de MySQL e PostgreSQL

| Comments

Euler, um dos desenvolvedores brasileiros do PostgreSQL está no podcast DatabaseCast, neste episódio o tema é vagas de trabalho em PostgreSQL e MySQL. As vagas de trabalho em MySQL são comentados pelo Airton Lastori.

Para ouvir, pode ir na página do episódio por aqui.

O podcast é feito pelo Mauro Pichiliani e Wagner Crivelini que já está em sua edição 38, os episódios anteriores são recomendadíssimos de ouvir. ;)

Um box vagrant para o Cacic 3.0

| Comments

Se quiser ajudar no desenvolvimento ou teste, pode usar um boxe vagrant que criei com a versão 3.0 beta que está disponibilizado no Portal do Software Público.

O Vagrant permite criar ambientes de desenvolvimento, teste, etc. muito facilmente e sem precisar usar a interface gráfica do virtualbox para isso. Lembrando que a VM criada pelo template nunca deve ser usado em produção, até porque ela não tem grandes recursos configurados. Mas pode usar alguma coisa como chef, puppet, etc. para envir para um ambiente de produção do jeito certo. ;)

Vagrant está disponível para várias distribuições linux, no Debian é bem fácil porque já tem no repositório oficial. No site do Vagrant tem pacotes para instalar para diferentes sistemas operacionais e distribuições linux, pode dar uma olhada lá.

Depois de instalado e baixado o arquivo box (cacic-server-3.0b.box), os passos seguintes são bem simples.

lang=bash
1
2
3
4
5
6
7
$vagrant box add base cacic-server-3.0b.box

$vagrant init

$vagrant up

$vagrant ssh

Estes box está configurado com uma segunda placa de rede em modo bridge, então pode usá-la para que vm fique disponível na rede.

A instalação está exatamente como a documentação cita: diretórios do cacic, serviços, pacotes, etc. Exceto por duas coisas diferentes.

1 - Ao invés de editar o php.ini para alterar o fuso horário do PHP, incluí um arquivo

lang=bash
1
2
$cat /etc/php5/apache2/conf.d/30-timezone.ini 
date.timezone = America/Sao_Paulo

2 - Ao invés do Proftpd, usei o Vsftpd. Ele é mais simples de usar.

Para acessar, basta usar o IP da eth1 que você configurar. http://ip-servidor/cacic/app.php

Obs. Esse VM é Debian Wheezy 7.0 AMD64 (64 bits)