A convite do pessoal do SecurityCast, participei de um webcast pra desmistificar sobre ataques em redes de telefonia, mais especificamente no core da rede, nos enlaces de sinalização SS7.

Não sei se consegui deixar muito claro os pontos, pois o tempo é curto pra entrar em detalhes, mas espero ter respondido a maioria das dúvidas sobre essa rede e sua segurança.

As redes de sinalização de telefonia não tem criptografia ou algo do tipo, mas estão cercadas por um ambiente seguro.  A segurança do perímetro é responsável por garantir o sigilo, confidencialidade e integridade da informação, não a rede em si.

Faz anos que escrevi sobre um uptime de 100 dias, em guerra dos 100 dias, e agora finalmente bati esse uptime.

No momento o uptime é um pouco maior:

17:42:23 up 212 days,  3:29, 31 users,  load average: 1.54, 1.25, 1.27

mas já vale pra ilustrar o quanto o Linux evoluiu em estabilidade.  Não só ele, mas toda a distro, que no meu caso é Ubuntu.

Anteriormente a maioria de problemas que exigiam o desligamento eram sempre relacionados com driver de vídeo Intel (na época do uptime de 100 dias).  Recentemente eu experimentei alguns congelamentos por falta de memória e até mesmo alguns crashes ao mudar de monitor (altero com bastante frequência entre só a tela do laptop, laptop e um monitor, e laptop e projetor).  Também tive problemas com entrada e saída de áudio com pulseaudio.

Por esse motivo eu sempre tentei compilar uma kernel mais recente e experimentar.  No caso estou 4.5.4.  Nem era dos mais estáveis e ainda está com bug de segurança pra acesso local, como o Dirty COW.  Uma vez que a invasão exige acesso local, estou relativamente seguro (se acessarem meu laptop, provavelmente será mais pelo valor do equipamento que pelos dados).

Mas uso diariamente meu laptop e de forma bastante extensiva.  Uso com docker, compilação de programas em C e C++, VMs com virtualbox e libvirt, edição de vídeo e de fotografia, etc.  É o famoso "pau pra toda obra".  E sem demais problemas.

Encontrei alguns?  Com certeza.  Tive alguns crashes do Xorg.  Mas como tenho habilitado o <ctr>+<alt>+<backspace> pra fechar o X inteiro e forçar um restart, não perdi nada além alguns segundos.

Fico feliz em usar Linux de uma maneira tão útil e que permite ser produtivo, tendo meu desktop pronto somente abrindo a tampa.

E por falar de desktop, fiz recentemente um vídeo pra mostrar o porquê de eu usar KDE, que adoro.

E agora tentar chegar em 365 dias.  Ou mais.

Software livre pode ser uma vantagem estratégica pra empresas, seja como forma de manter os custos baixos com uso da gratuidade dos programas ou seja como forma de inovação tecnológica pela forma simples e aberta de integrar os software. Mas e no lado pessoal?  Como seguir uma carreira com software livre?

Contarei como foi no meu caso, mas... não recomendo seguir os mesmos passos.  Eu tive sorte de uma questão de momento, que abriu uma enorme oportunidade pra mim.  Atualmente essa mesma condição não existe mais.  Então tente ver a questão de oportunidade aproveitada e só isso.  Como o texto ficou muito longo, resolvi quebrar em partes pra abordar o início, e como se desenvolveu em seguida.

[AVISO: O RESTANTE DO TEXTO É LONGO E CONTÉM MUITA, MUITA, MAS MUITA NOSTALGIA]

Eu comecei com software livre na faculdade, UFSC, em 97.  Eu tinha um computador que havia sido sucateado pela família, um 486, mas que era perfeito pros meus trabalhos na faculdade.  Por um acaso muito grande, um raio caiu na rede elétrica e fritou a placa mãe.  O que foi um grande azar na época acabou por se tornar um catalisador do restante da minha vida profissional nos 19 anos seguintes (e contando).

Sem muita opção eu acabei arrumando uma placa mãe de um 386 com 8MB de RAM com um amigo (valeu kibão!).  Sem coprocessador numérico.  A máquina era uma carroça e o tal do Windows 95 travava o tempo todo.  Naquela época a vida era um inferno.

E nesse inferno por coincidência eu iniciei uma matéria optativa: Unix.  Achei muito legal o sistema e descobri que tinha uma variação dele que rodava no meu cambaleante 386:  era um RedHat.  Acho que 4.  Dois CDs de instalação da Cheap&Bytes.

De início não funcionava.  Eu não conseguia instalar, mas o tal de Slackware, em disquetes funcionava.  Levei 1 mês pra desvendar o problema que era o cdrom conectado na placa de som e que exigia um parâmetro extra no RedHat após o boot.  Mas esse mês de insistência me ajudou a aprender o caminho unix de se fazer as coisas: leia as manpages!

Eu passava horas e horas nos laboratórios da faculdade lendo howtos e manpages na Internet.  Documentação existia, mas não era fácil mandar um "como faz isso aqui" pra alguém responder.  Existia a lista de discussão linux-br, mas perguntar algo que estava facilmente disponível em documentação era pedir pra ser chicoteado em praça pública.  A caminhada da vergonha de Sersei em game of thrones é muito menos humilhante pra ter idéia de como era.  Mas nesse ambiente hostil, onde só os mais fortes sobreviviam, eu consegui permanecer.  E instalar o tal RedHat.

Era um prazer imensurável ter aquele ambiente OpenWin igual do Solaris da faculdade rodando em casa.  E tinha spice (um programa de simulação de circuitos elétricos - coisa de quem faz engenharia elétrica)!  Não exatamente aquele todo gráfico e bonitinho da faculdade, mas um todo em texto.  O importante era que funcionava.  E depois de ter aprendido a usar o editor vi, entre muitas lágrimas de revolta e me perguntando como alguém poderia ter criado aquilo, o spice era moleza.

Mas não tinha editor de textos WYSIWYG (What You See Is What You Get - o que você vê é o que você quer).  Não tão simples quanto o Microsoft word.  Essa limitação me levou rapidamente a aprender e usar latex.  Textos muito mais elegantes num "vi" de distância de você.  A bem da verdade eu usava emacs pra isso.

Não demorou muito e tudo aquilo virou minha paixão.  Escolhi uma distro pra viver a minha vida com o mesmo amor com que se escolhe um time de futebol. Era torcida pura e simples.  Flameware de formatos de pacotes, escrever textos e documentação sobre tudo o que fazia e participar de encontros.  Foi assim que acabei indo pro primeiro FISL e conhecendo essas figuras que depois fizeram e até hoje fazem parte da minha vida profissional e até mesmo pessoal.

Nessa época meu sonho era ser sysadmin.  Mas não sysadmin de Linux.  Eu queria ser daqueles sysadmins que eram mitos.  Um quase Denis Ritchie.  Só não podia ser trabalho com Windows.  No máximo uma configuração de servidor samba.

Então nesse pique quase que obssessivo por me torna um sysadmin, eu comecei a fazer consultorias em Unix.  Alguns eram implementação de firewall, que eu já dominava com certa facilidade, outras eram pra instalar uma solução completa de servidor web, mail e dns.  Fiz vários updates de servidores SCO pra Linux ou FreeBSD, que virou minha outra paixão nessa época  (um TRUE Unix se comparado com Linux, que vinha do Minix - meu pensamento na época). 

Toda essa introdução de como comecei com Linux é somente pra ilustrar de como eu não tinha a menor idéia do que estava fazendo.  Não sei se outros da mesma geração como Eduardo Maçan, Nelson Murilo e Klaus Stedding-Jenssen sabiam.  Sem modéstia nenhuma, esses caras eram monstros em Unix.  Eu achava divertido, mas não entendia nada de Unix, programação, redes de computadores ou mesmo segurança.  Só me achava o máximo por rodar um Unix em casa igual ao da faculdade.  Lutar pela liberdade?  A luta era sair do Windows.  Essa era a luta pra mim.  E ter um computador funcional num 386 de 8 MB de RAM sem coprocessador numérico.  Essa era liberdade que eu queria.

Com o caminho de sysadmin escolhido, mergulhei em livros e estudei muito.  Quase abandonei a faculdade de engenharia elétrica pra tentar seguir só como sysadmin.  Nesse ponto o fato de morar em Florianópolis ajudou bastante pois era difícil encontrar emprego na área.  Então acabei levando a faculdade até o fim.  Do contrário teria tomado a decisão errada de parar os estudos.

Ao terminar a faculdade, e tentando viver como sysadmin, consegui alguns trabalhos em provedores locais que usavam Linux.  Tive inclusive a oportunidade de trabalhar com máquinas FreeBSD.  Mas a quantidade de trabalho não era tão grande assim, nem pagava tão bem.  Então eu mantinha uma bolsa de trabalho na faculdade também.

Com os "freelas" aparecendo, consegui uma oportunidade pra cobrir um colega numa empresa de treinamentos.  Esse foi meu início como instrutor de cursos de Linux, segurança e logo depois de cabeamento estruturado.  Eu entendia de Linux, mas segurança e cabeamento... então tive de buscar apostilas e livros e estudar.  Pra cabeamento estruturado até mesmo uma certificação Furukawa eu tive de fazer.

Mas esse estudo e empenho trouxeram frutos.  Logo começaram a aparecer projetos maiores e mais interessantes, com empresas grandes.  Eu me associei à empresa de treinamentos e conseguimos uma parceria pra representar a Conectiva, empresa brasileira de sistema GNU/Linux, no estado de Santa Catarina.  Com a boa quantidade de trabalho, acabei abandonando a bolsa da faculdade pra me dedicar ao que eu gostava, que era ser um sysadmin profissional, instalando e configurando servidores, firewalls, IDSs, etc.

Mas logo eu comecei a sentir as limitações regionais.  Muitos dos trabalhos exigiam não somente meu mundinho sysadmin, mas uma integração total de sistemas em rede, ou seja, conhecer melhor roteadores e switches.  As opções de aprendizado eram complicadas pela falta de equipamento, que na época era muito cara.  Com isso eu tomei a decisão de buscar emprego numa empresa maior, onde eu pudesse ter contato com esse tipo de equipamento e tecnologia.

E assim eu consegui um trabalho em São Paulo, na empresa onde trabalho até hoje.  Essa parte em diante, deixo pra contar no próximo post :)

Abrimos uma pesquisa pra saber se as pessoas gostariam de um hangout falando sobre free software e open source, história, movimentos e polêmicas.  O "sim" ganhou uma larga margem, então fizemos o último programa do canal "Unix Load On" sobre isso.

Não sei se foi abordado tudo o que deveria ser falado, mas tenho certeza que a discussão longa, interminável e improdutiva sobre o asssunto também continuará.  Infelizmente.

Então aproveitem.

Estive trabalhando nos últimos tempos em publicar as palestras do FISL no Youtube.  Por que fazer isso?  Bom... primeiramente pra atender um interesse próprio que é assistir os vídeos na minha SmartTV, que é Smart, roda Linux, mas não suporta o formato OGV disponibilizado no site do FISL (software livre é sobre coçar sua coceira, lembram?).  Publicando o conteúdo no Youtube continua OGV por trás, mas daí a TV aceita o format HMTL5 pra envio do stream do vídeo.

Mas isso não é tudo.  Publicando no Youtube um público que não sabe da existência do FISL vai ter acesso aos vídeos.  Tenho notado vários acessos de gente no exterior ao conteúdo em inglês.

E tudo é feito de forma automatizada.  Como cada FISL usou uma forma distinta de publicação, tenho usando um mesmo script modificado a cada edição do evento.  Eles estão armazenados na minha conta de Github.

https://github.com/helioloureiro/homemadescripts

No momento estão carregados os vídeos da última e penúltima edição do FISL, mas pretendo carregar o máximo possível dos eventos anteriores.  

O outro motivo, além da disponibilização dos vídeos em outra plataforma (mesmo não sendo software livre), é ter um acesso permanente aos vídeos.  No momento estão hospedados nas máquinas da ASL assim como um dia tivemos nossas listas de mails nos servidores da CIPSGA (Comitê de Incentivo à Produção de Software Gratuito e Alternativo).  Não sei se a ASL está no mesmo nível da CIPSGA, que usava máquinas na SERPRO se não estou enganado, e por uma falha de disco perderam todos os dados, mas por precaução melhor fazer a maior quantidade de cópias possíveis dos vídeos.

Essa é a idéia no momento.

Nota: eu vi que alguns vídeos estão sem alguns caractéres.  É alguma conversão de utf-8 que deu errado :(

Depois da festança, sempre vem a ressaca.  Sempre.  O governo brasileiro sente com força esse pós-festa que se reflete em toda economia e deve durar ainda alguns bons anos pra se recuperar (haja engov).  Tudo causado por um certo "abuso" nos gastos que junto com um certo "otimismo demais" e uma não leitura da realidade resultou nisso.

E o governo brasileiro não está sozinho.  Eike Batista sofreu do mesmo mal com suas empresas X.  Vendidas como o modelo de empresas que se deveriam seguir no Brasil, com o típico empresário de sucesso, a bonança terminou antes que qualquer projeto fosse finalizado e empresas gerassem algo mais que prejuízo.  Como resultado a ressaca foi brava.  Quem acreditou, perdeu muito dinheiro.  Não, o Eike não perdeu dinheiro.

Em software livre existe algo parecido.  A festança foi a celebração da luta contra "as redes devassas", contra a "monitoração da NSA".  Como a canção de Gilberto Gil, todos gritavam "vamos fugir, desse lugar, babe" e apontavam a solução pra redes como Diaspora, Quitter, OpenMailBox, RiseUp, etc.  Quando escrevi o artigo as empresas nefastas e redes devassas, já apontava um problema de sustentabilidade: como uma alternativa dessa se mantem viável?  Quem paga essa conta?

Mas era época de festança.  Quem liga pra quem paga a conta enquanto tem cerveja?  E gratuita!  Todo brasileiro que se dizia ativista corria em euforia pra nova rede gratuita, gritando que errados eram os outros.  Éramos vendidos.  Não sabíamos o preço de nossa liberdade.

Mas chegou a ressaca.  Hoje ao entrar na rede do Diáspora, que faço pelo joindiaspora.com, que consegui participar por convite do Eduardo (BoiMate), encontrei um botão de doação.  Pra se manter vivo, o serviço precisa de máquina, acesso Internet, eletricidade, etc.  De forma voluntária é mantido o software e sistema, mas isso não basta: precisa de dinheiro.

Da mesma forma, com praticamente nenhum uso, tenho uma conta no OpenMailBox.  Das mensagens que recebo, o mesmo tipo de pedido: precisamos de dinheiro pra continuar existindo!

É algo terrível ou anti-ético?  Pelo contrário.  Se o modelo de financiamento não é por monetização com propaganda, nem vendendo nossos meta-dados, nada mais transparente que pedir dinheiro.  Querem usar o serviço?  Ajudem a manter!  A ASL pediu doações  pra realizar o FISL e teve, segundo relatos, um dos melhores FISLs dos últimos anos.  Vários serviços buscam financiamento pra se manter, inclusive a FSF.

De minha parte eu contribuo para:

• JoinDiaspora (esporadicamente)
• FreeBSD Foundation (esporadicamente)
• WikiMedia Foundation (regularmente)
• Free Software Foundation (regularmente)
• Associação de Software Livre (regularmente)
• Debian (esporadicamente)

Não é um valor alto, na verdade algo como 20 reais por mês em cada (exceção da FSF que cobra beeeeem mais caro), mas já deve ajudar.

E você que usa software livre, pra qual projeto faz doação em dinheiro?  Não acha que vale à pena ajudar algum projeto que goste?  Pense bem nisso antes da ressaca bater forte.

Em janeiro eu escrevi sobre a palestra de Richard Stallman na universidade de Estocolmo, cujo assunto era privacidade.  Algumas pessoas contestaram o que foi escrito por mim pela falta de provas documentais como vídeos ou gravação de áudio.   Infelizmente no início da palestra, que era sobre privacidade, ele pediu para que todos desligassem seus celulares e não postassem nada sobre ele lá, muito menos com tag, pra evitar a geolocalização.  Não só eu mas todos que pude ver guardaram seus celulares que estavam prontos pra gravar a palestra.  E ninguém levou uma câmera como alternativa :(

Eu também nunca gastei muito tempo pra responder os questionamentos sobre o que escrevi, que foi arduamente defendido pelo Patola (valeu Patola!), pelo simples fato que são 2 ou 3 que semprem dizem esse tipo de coisa e não acrescentam muita coisa numa discussão de software livre.  Eu prefiro não gastar energia com esse tipo de polêmica vazia.

Mas felizmente Stallman repete bastante as palestras.  Não são exatamente iguais pois por aqui ele adicionou quase 1 hora a mais sobre privacidade e Snowden, mas na parte sobre software livre é a mesma coisa nas que eu vi.

Depois de Estocolmo ele fez uma palestra em Zurique na Suiça.

e agora apareceu uma outra palestra em espanhól no congresso de soberania tenológica em Barcelona.

Tem de assistir ambas?  Se quiser discutir os pontos que coloquei antes, sim.  Do contrário a palestra de Zurique está melhor pra ver os slides, mas está em inglês.  A de Barcelona é mais fácil de entender, mas não aparecem os slides.  O mundo não é mesmo perfeito...

O Debian Jessie, última versão estável do sistema operacional universal Debian, foi lançado a quase 1 ano.  Somente agora criei coragem de fazer o upgrade.  Estava rodando Wheezy, a versão anterior que entrou em LTS (Long Term Support ou suporte estendido), que atendia bem o site mas, sempre existe um mas, descobri alguns problemas de limitação do kernel com o greyd.

Alguns sites não estavam sendo marcados corretamente com ipset.  Como o greyd foi criado pra versões mais recentes de kernel (Wheezy rodava com um linux-3.2), a opção era desativar o greyd ou atualizar o sistema.  Então vamos atualizar!

Sem ajuda dos trus La_Sombra e Rootsh nada disso seria possível.  Foi um trabalho de garimpo no passado pra achar como conectar na VM e quem ainda tinha a chave de conexão.  Culpa disso pela estabilidade do sistema.  Obrigado Debian!

Eu já tinha feito o upgrade do Ubuntu LTS, de 14.04 pro 16.04, e esperava alguns problemas que seriam corrigidos com reboot e uns "apt-get -f install", então o acesso ao console era essencial.  Parte dessa espectativa era também o motivo pra ter postergado esse upgrade.  systemd é algo que ainda me dói no alma.

Pra fazer o upgrade?  Do bom e velho jeito do Debian: primeiramente deixando atualizado na versão corrente, Wheezy

# cd /etc/apt
# apt-get update && apt-get upgrade

Em seguida mover a versão pra Jessie e continuar com upgrade.

# cp sources.list sources.list.wheezy
# cat sources.list.wheezy | sed "s/wheezy/jessie/" > sources.list
# apt-get update
# apt-get dist-upgrade

Pronto.  É isso.  Fácil assim.  

Foram uns 500 MB de download, uma vez que é um servidor e roda só o necessário, um reboot e... saiu funcionando de primeira!  Eu achando que o systemd ia encrencar com alguma coisa e... nada!  Claro que nem tudo foi tão bem assim.  Precisei arrumar algumas configurações do servidor web, assim como do mail, mas muita coisa saiu funcionando sem mexer.  Ainda estou com problemas com o dovecot, mas nada que force uma volta ao Wheezy pra corrigir.

Parabéns à equipe do Debian por um sistema tão afinado e redondo assim.  Continua sendo minha distro preferida.

SPAM é uma batalha sem fim. Cria-se uma forma de mitigar ou diminuir e são apenas algumas semanas de sossego.  Logo eles acham uma forma de burlar as barreiras que criamos.  Como faz tempo que não trabalho com mail de larga escala e controlo apenas a da VM do servidor desse domínio aqui, eu não tenho nem idéia do tamanho do problema que grandes empresas como Google têm.  A quantidade de SPAM que tenho de lidar já é mais que suficiente pra eu me aborrecer.

Eu já implementei SPF pra verificação de origem dos mails, mailassassin, white e black list e... o volume continua alto.

Mailassassin era um dos mais promissores mas consome muita CPU a cada verificação.  Além disso ele é um software muito burro (desculpem ao autores e fãs) pois ele recebe o mail pra fazer análise.  Porque não fazer logo na conexão alguma verificação e descartar logo?  No fim gastou banda, CPU e memória pra ver algo óbvio.  Quando recebo um mail vindo de algo como "helio-a414c-loureiro.eng.Este endereço de email está sendo protegido de spambots. Você precisa do JavaScript ativado para vê-lo. é bastante claro que é falso e se destina à SPAM.  Então não seria lógico já matar o mail no momento do recebimento?

Pois o projeto OpenBSD resolveu cuidar disso.  Eles criaram um daemon que enferniza a vida de spammers.  É um verdadeiro saci pererê dos e-mails.  O spamd recebe o mail e funciona de uma forma muuuuuuito lenta, com a conexão bem degradada.  Após terminar a tentativa de envio do mail, ele simplesmente fecha a conexão e pede que tente novamente.  Se o servidor tentar novamente, muito provavelmente não é uma máquina de SPAM.  Como essa tentativa seguida faz parte do protocolo SMTP, servidores legítimos continuaram tentando enquanto spammers vão pra outra pobre vítima.

No último hackathon que participei eu tentei fazer um port desse daemon pro Linux.  Encontrei um port já em andamento chamado obspamd no github, que estava com o build quebrado, e consegui arrumar o que estava com problemas.  Minha idéia era fazer um daemon funcional e completo portado pra Linux, com autoconf e configure.  E foi num dos bug reports que eu estava respondendo que alguém mandou outra mensagem avisando que existia um port já bem funcional do mesmo, o greyd.

Conhecendo o greyd

Fiquei surpreso ao descobrir que até site oficial já tinha, o http://greyd.org, pois eu nunca tinha ouvido falar.  Até onde vi não existem pacotes para ele em Debian ou em Ubuntu.  Então boa parte da instalação foi feita manualmente.

O que eu gostaria de fazer com o obspamd, de criar um sistema de build com autoconfigure, já está pronto no greyd.  Além disso ele já implementa as chamadas de kernel pra adicionar as regras de firewall necessárias pro funcionamento do greyd.  

Por quê do firewall?  Tanto o original, spamd, quanto o greyd funcionam ouvindo na porta 8025.  Então todo pacote que não foi classificado, baseado em IP de origem, ao tentar conectar na porta 25, padrão de mail, é redirecionado à porta 8025.  O greyd segue com a conexão e marca esse tipo de pacote como provável whitelist (lista branca).  Na segunda tentativa de conexão esse pacote já vai direto pro servidor de mail, que no meu caso é um postfix.  Esse controle é feito através do firewall iptables com regras no PREROUTING e ipset do kernel, marcando tipos de pacote com IP de origem.  E precisa do módulo conntrack do kernel.

Baixando e compilando o greyd

Como é um programa bem recente, não existem pacotes pra ele.  Ao menos em Debian/Ubuntu.  Então ele ainda exige a compilação e instalação manual.

Para baixar o greyd diretamente do github:

# git clone https://github.com/mikey-austin/greyd.git

Pra compilação, eu escolhi usar sqlite3 como formato de arquivo de whitelist, então precisei incluir os cabeçalhos e bibliotecas referentes.

# apt-get install libsqlite3-dev libnetfilter-log-dev libnetfilter-conntrack-dev \
    libpcap0.8 libspf2-dev
# cd greyd
# autoreconf -vi
# ./configure \
    --with-sqlite \
    --with-netfilter \
    --with-spf \
    --bindir=/usr/bin \
    --sbindir=/usr/sbin \
    --sysconfdir=/etc \
    --docdir=/usr/share \
    --libdir=/usr/lib \
    --localstatedir=/var \
    GREYD_PIDFILE=/var/run/greyd.pid \
    GREYLOGD_PIDFILE=/var/run/greylogd.pid \
    DEFAULT_CONFIG=/etc/default/greyd.conf
# make

O greyd também precisa que sejam criados 2 usuários: greyd e greydb, que controlam daemon e base de dados da lista.  No seu repositório existe um diretório que ajuda a criar pacotes.  Nele é possível ver os comandos pra realizar essa tarefa manualmente em greyd/packages/debian/postinst:

# adduser --quiet --system --home /var/run/greyd --group \
    --uid 601 --gecos "greyd"  --shell /bin/false --disabled-login greyd
# adduser --quiet --system --home /var/lib/greyd --group 
    --uid 602 --gecos "greydb" --shell /bin/false --disabled-login greydb

Em seguida é preciso criar o diretório onde a base de dados em squlite3 ou bsddb será escrita.

# mkdir -p /var/greydb
# chown -R greydb:greydb /var/greydb

Com a configuração de compilação, as configuração serão armazenadas em /etc/default/greyd.conf.  O spamd do OpenBSD por padrão roda em um ambiente chroot() pra proteção do sistema.  Eu não consegui fazer o mesmo com o greyd.  As configurações que estou usando no momento são (usando diff pra comparar):

# diff -u ./etc/greyd.conf /etc/default/greyd.conf 
--- ./etc/greyd.conf    2016-07-07 13:47:43.000000000 -0300
+++ /etc/default/greyd.conf     2016-07-08 09:49:28.000000000 -0300
@@ -5,8 +5,8 @@
 #
 # Debugging options and more verbose logs.
 #
-debug = 0
-verbose = 0
+debug = 1
+verbose = 1
 daemonize = 1
 
 #
@@ -17,7 +17,7 @@
 #
 # Address to listen on.
 #
-bind_address = "127.0.0.1"
+bind_address = "200.123.234.321"
 
 #
 # Main greyd port.
@@ -32,7 +32,7 @@
 #
 # Enable listening on IPv6 socket.
 #
-enable_ipv6 = 0
+enable_ipv6 = 1
 bind_address_ipv6 = "::1"
 
 #
@@ -60,7 +60,7 @@
 #
 # Chroot enable & location for main daemon.
 #
-chroot     = 1
+chroot     = 0
 chroot_dir = "/var/empty/greyd"
 
 #
@@ -82,11 +82,13 @@
 # Specify the maximum number of connections.
 #
 # max_cons = 800
+max_cons = 30
 
 #
 # Specify the maximum number of blacklisted connections to tarpit.
 #
 # max_cons_black = 800
+max_cons_black = 30
 
 #
 # The firewall configuration.
@@ -114,8 +116,8 @@
 #
 section database {
     #driver  = "/usr/lib/greyd/greyd_bdb_sql.so"
-    #driver  = "/usr/lib/greyd/greyd_sqlite.so"
-    driver  = "/usr/lib/greyd/greyd_bdb.so"
+    driver  = "/usr/lib/greyd/greyd_sqlite.so"
+    #driver  = "/usr/lib/greyd/greyd_bdb.so"
     path    = "/var/greyd"
     db_name = "greyd.db"

Em geral ele funciona apenas na interface de loopback, mas por usar um Debian mais velho, o Wheezy, precisei ajustar pra ouvir na interface pública, a eth0.

Feito isso, basta iniciar o daemon e o daemon de controle de log:

# /etc/init.d/greylogd start
# /etc/init.d/greyd start

Para quem já usa sistemas com systemd:

# systemctl start greylogd
# systemctl start greyd

O próprio systemd cuidará de adicionar e habilitar esses serviços.

Mas ainda falta o firewall.  São necessárias algumas regras na  inicialização:

# ipset create greyd-whitelist hash:ip family inet hashsize 1024 maxelem 65536
# iptables -t nat -A PREROUTING -p tcp -m tcp --dport 25 -m set \
    --match-set greyd-whitelist src -j LOG --log-prefix "[GREYD WHITED]"
# iptables -t nat -A PREROUTING -p tcp -m tcp --dport 25 -m set \
    --match-set greyd-whitelist src -j NFLOG --nflog-group 155
# iptables -t nat -A PREROUTING -p tcp -m tcp --dport 25 -m set \
    --match-set greyd-whitelist src -j ACCEPT
# iptables -t nat -A PREROUTING -p tcp -m tcp --dport 25 -j LOG \
    --log-prefix "[GREYD 25 DNAT]"
# iptables -t nat -A PREROUTING -p tcp -m tcp --dport 25 -j DNAT \
    --to-destination 200.123.234.321:8025
# iptables -t nat -A PREROUTING -p tcp -m tcp --dport 25 -j LOG \
    --log-prefix "[GREYD 25 REDIRECTED]"
# iptables -t nat -A PREROUTING -p tcp -m tcp --dport 25 -j REDIRECT \
    --to-ports 8025
# iptables -t nat -A PREROUTING -p tcp -m tcp --dport 25 -j LOG \
    --log-prefix "[GREYD FAILED]"
# iptables -t nat -A PREROUTING -p tcp -m tcp --dport 8025 -j LOG \
    --log-prefix "[GREYD 8025 JAILED]"
# iptables -t filter -A INPUT -p tcp --dport smtp -j ACCEPT
# iptables -t filter -A INPUT -p tcp --dport 8025 -j ACCEPT

Eu adicionei mais logs pra poder também acompanhar os pacotes, pra ver se estão sendo marcados ou não de acordo.

De início eu fiquei na dúvida se eu estava recebendo algum e-mail ou não, mas logo percebi que estava funcionando de acordo.

A fila de mails indesejados, que ficavam travados por não ter endereço de retorno, praticamente zeraram.  O uso de memória aumento um pouco, assim como o conntrack no kernel.  Por enquanto nada absurdo.  E parece estar funcionando bem até agora.  Se não respondi algum mail seu, já sabe o motivo.

Acabaram os SPAMs?  Não!  Spam é spam.  Enquanto houver mail, existirá spammers.  É fácil de implementar e barato.  Mas eles diminuíram.  E ao saber que estou gastando a conexão deles fazendo nada já me alegra o suficiente.

Meu próximo passo será gerar um pacote no meu ppa no launchpad: https://launchpad.net/~helioloureiro

Pra saber mais como lutar contra spam: http://antispam.br/

Reusando o código que escrevi pra tirar snapshots durante a PyConSe e publicar automaticamente no Twitter, escrevi um pequeno aplicativo pra raspberypi com Python pra pegar o mesmo tipo de imagem, mas da minha janela, e ir acompanhando a evolução do tempo ao longo do dia e do ano.  Essa é a imagem que ilustra o início do post.

Acho que será legal fazer uma animação das imagens mostrando o sol que brilha até quase 11 da noite, o inverno que escurece às 2 da tarde, e a neve chegando.  E tudo postando no Twitter.

As ferramentas são as mais simples possível: um raspberrypi conectado com um dongle wifi e uma webcam USB creative (que aliás uso pra participar dos hangouts).  E sempre Python pra fazer tudo.

Descobri que o Forecast.IO fornece uma API com JSON pra buscar a previsão do tempo atual e até 10 dias, com permissão de 1000 queries por dia de forma gratuita.  Perfeito pro meu pequeno projeto.  O mais difícil foi fazer a conversão da temperatura de Farenheit pra Celsius (meus dias de vestibulando já se foram faz muito tempo), mas pedi ajuda à Internet pra isso. Fiz uma pequena função que retorna os dados que quero em forma de um array.

import requests
import json
import time

"""
Um monte de código por aqui
[...] 
""""
def get_content():
    timestamp = time.strftime("Date: %Y-%m-%d %H:%M", time.localtime())
    msg = []
    msg.append("Stockholm")
    msg.append(timestamp)

    url = "https://api.forecast.io/forecast/%s/%s" % (wth_key, wth_loc)
    req = requests.get(url)
    jdata = json.loads(req.text)

    summary = jdata["currently"]["summary"]
    temp = jdata["currently"]["temperature"]
    temp = Far2Celsius(temp)

    msg.append(u"Temperature: %s°C" % temp)
    msg.append("Summary: %s" %summary)

    return msg

A primeira coisa que precisei alterar foi a adição de textos à imagem.   Tendo a informação vinda do Forecast.IO, eu precisava modificar a imagem pra que ela aparecesse.  No início eu usei uma fonte de cor branca, mas logo percebi que preto ficava com um contraste melhor.  Mas quando chegar o inverno, época em que os dias são realmente muito curtos por aqui, vou precisar pensar numa forma pra trocar para branco.  Mas no momento usei as bibliotecas do PIL que manipulam imagem em Python.

import Image
import ImageFont, ImageDraw, ImageOps

IMGSIZE = (1280, 720)
BLACK = (0, 0, 0)
WHITE = (255, 255, 255)

"""
Um monte de código por aqui
[...] 
""""
def WeatherScreenshot():

    msg = get_content()
    if not msg:
        msg = "Just another shot at %s" % \
            time.strftime("%H:%M", time.localtime())
    if msg:
        msg_body = "\n".join(msg[1:])
        im = Image.open(filename)
        # just get truetype fonts on package ttf-mscorefonts-installer
        try:
            f_top = ImageFont.truetype(font="Arial", size=60)
        except TypeError:
            # older versions hasn't font and require full path
            arialpath = "/usr/share/fonts/truetype/msttcorefonts/Arial.ttf"
            f_top = ImageFont.truetype(arialpath, size=60)
        try:
            f_body = ImageFont.truetype(font="Arial", size=20)
        except TypeError:
            # older versions hasn't font and require full path
            arialpath = "/usr/share/fonts/truetype/msttcorefonts/Arial.ttf"
            f_body = ImageFont.truetype(arialpath, size=20)
        txt = Image.new('L', IMGSIZE)
        d = ImageDraw.Draw(txt)
        d.text( (10, 10), msg[0], font=f_top, fill=255)
        position = 80
        for m in msg[1:]:
            d.text( (10, position), m, font=f_body, fill=255)
            position += 20
        w = txt.rotate(0, expand=1)

        im.paste(ImageOps.colorize(w, BLACK, BLACK), (0,0), w)
        im.save(filename)

descobri que a versão de raspbian que estou usando, baseado em Debian Wheezy, tem uma API um pouco diferente e pode precisar que a fonte com o path completo seja passada no argumento.

Outra alteração foi mudar a chamada pra webcam capturar a imagem que era uma função mas modifiquei pra uma thread.  Assim o tempo fica consistente.  Do contrário ao invés de mostrar 12:00 apareceria algo como 12:03 (o tempo pra adquirir a imagem).

import threading

def WeatherScreenshot():
    th = threading.Thread(target=GetPhoto)
    th.start()
    msg = get_content()
    th.join()

E já que mencionei a imagem, esse foi o maior problema até agora.  Descobri que não existe uma forma muito confiável de inicializar a webcam.  Às vezes ela adquiri a imagem de forma bonitinha, às vezes fica super exposta, outras vezes sub.

E não tem nada que dê um feedback sobre a qualidade.  Li vários artigos com dicas de uso com pygame, que é a forma que uso, e com opencv também, mas todas com o mesmo princípio.  Basicamente fazem um start() no framework da webcam, que inicializa a webcam, adquirem um número de imagens aleatórios (alguns dizem 30) e esperam pelo melhor ao capturar a imagem.  Nada que retorne um indicador de qualidade.  Nada.

DISCARDFRAMES = 2 * 30

def GetPhoto():
    filename = None
    pygame.init()
    pygame.camera.init()
    elif os.path.exists("/dev/video0"):
        device = "/dev/video0"
    if not device:
        print "Not webcam found.  Aborting..."
        sys.exit(1)
    # you can get your camera resolution by command "uvcdynctrl -f"
    cam = pygame.camera.Camera(device, IMGSIZE)
    cam.start()
    time.sleep(3)
    counter = 10
    while counter:
        if cam.query_image():
            break
        time.sleep(1)
        counter -= 1
    # idea from https://codeplasma.com/2012/12/03/getting-webcam-images-with-python-and-opencv-2-for-real-this-time/
    # get a set of pictures to be discarded and adjust camera
    for x in xrange(DISCARDFRAMES):
        while not cam.query_image():
            time.sleep(1)
        image = cam.get_image()
    image = cam.get_image()

Basicamente um método de tentativa e erro.  Por isso que iniciei a chamada à webcam como thread.  Como as webcams USB tem CPU própria, não tem - até onde pesquisei - uma API confiável pra verificar se o balanço de branco normalizou antes de capturar a imagem.   Só retornam a própria imagem. Tosco.

Então resolvi fazer um outro script como módulo, que basicamente mapeia toda a imagem em seu tamanho e cria um dicionário do tipo "COR: quantas vezes".  Descobri que valores RGB (pega o valor de R + G + B, soma e divide por 3 pra ter a média) acima de 235 já indicam super exposição.  Não só isso.  Como eu conto a quantidade que aquele valor RGB aparece, sempre que um valor sobressai acima de 15% do total, já indica uma imagem ruim.  Não é um dos melhores métodos científicos, mas tem funcionando bem (verifiquei nas imagens já adquiridas e salvas).  Os tempos de aquisição de imagem mudaram de até 1 minuto pra em torno de 10 minutos.  Mas por enquanto com qualidade muito melhor.

import Image

def brightness(filename):
    """
    source: http://stackoverflow.com/questions/6442118/python-measuring-pixel-brightness
    """
    img = Image.open(filename)
    #Convert the image te RGB if it is a .gif for example
    img = img.convert ('RGB')
    RANK = {}
    #coordinates of the pixel
    X_i,Y_i = 0,0
    (X_f, Y_f) = img.size
    #Get RGB
    for i in xrange(X_i, X_f):
        for j in xrange(Y_i, Y_f):
            #print "i:", i,",j:", j
            pixelRGB = img.getpixel((i,j))
            R,G,B = pixelRGB
            br = sum([R,G,B])/ 3 ## 0 is dark (black) and 255 is bright (white)
            if RANK.has_key(br):
                RANK[br] += 1
            else:
                RANK[br] = 1

    color_order = []
    pic_size = X_f * Y_f
    print "Picture size:", pic_size
    for k in sorted(RANK, key=RANK.get, reverse=True):
        amount = RANK[k]
        # if low than 15%, ignore
        if amount < (.15 * pic_size):
            continue
        print k, "=>", RANK[k]
        color_order.append(k)
    if color_order:
        print color_order
        return -1
    return 0

O código todo está disponível no meu github.

https://github.com/helioloureiro/snapshot-twitter

E provavelmente devo lançar um gif animado posteriormente com o decorrer do clima ao longo do ano.

Tenho alguns problemas como concorrência no caso de tentar adquirir uma imagem ao mesmo tempo que a crontab tentar fazer isso (implementei uma API em REST pra isso, mas não é algo pra publicar :).  Devo implementar algum tipo de lock usando /tmp, mas algo simples.

E agora no verão, com sol até quase 11 horas da noite, tenho também um pequeno problema de negação de serviço que às vezes acontece.

Ainda não descobri um módulo em Python pra mitigar isso :)