Cloudflare

Esses dias estava lendo sobre um incidente de segurança que ocorreu com a cloudflare e o que mais me chamou atenção foi a enorme quantidade de serviços afetados pela vulnerabilidade. Soube ainda que o pessoal da lulz sec usou o serviço em 2011, inclusive esse foi o motivo que desencadeou os primeiros ataques a cloudflare naquela época! Então esse post é para falar de segurança da informação? resposta: Não! No meio da leitura eu me interessei, por incrível que pareça, pelo serviço oferecido pela cloudflare.

Sei o quanto é estranho se interessar por um serviço de CDN enquanto lê um incidente de segurança do mesmo, fazer o que, aconteceu. O que de fato ocorreu foi que interrompi a leitura do incidente de segurança para fazer o cadastro no site e logo em sequencia fiz o redirecionamento do DNS para só então seguir a leitura do incidente. Usar o serviço quer dizer que eu estou vulnerável? resposta: depende. O caso do blog pviana.com.br é diferente dos demais afetados. Gostaria de aproveitar o momento e explicar que só é possível usar o serviço da cloudflare em um blogspot porque tenho registrado o nome pviana.com.br, caso contrario eu não teria acesso as configurações de DNS.

Ideia desse post é explicar como o serviço funciona e quero também mostrar métricas, isso tudo sem entrar aprofundar em assuntos muito técnicos. Aos mais atenciosos, já repararam que eu estou a um ano sem escrever nada por aqui, então acreditem estou enferrujado

O que é o Cloudflare?
Um serviço de CDN (content delivery network), em outras palavras uma rede de entrega de conteúdo onde o acesso de cada visitante é, em teoria, redirecionado para um servidor geograficamente mais perto, até porque a chance desse servidor conseguir prover uma melhor experiencia é bem alta. Por falar nisso, existe uma lista de onde a cloudflare está presente bem aqui

Quanto custa?
Depende! pode custar R$ 0,00 reais se você não se importar com algumas coisas, veja aqui a lista completa com os planos oferecidos. Maiores vantagens dos planos pagos são segurança, SLA e suporte. Toda parte de analytics pode ser usada no plano free, porem os dados são do ultimo dia apenas. No plano pago, é possível filtrar por um espaço de tempo menor, algo como 6h por exemplo.

Antes e Depois:
Infelizmente não tenho dados do pviana antes da configuração, mas consegui realizar os testes de comparação em um outro blog. A comparação vai ser feita através do https://tools.pingdom.com e também do https://www.neustar.biz/resources/tools/free-website-performance-test

Como pode ser visto nas imagens houve uma melhora significativa no tempo de carregamento na maioria das vezes.

Teste realizado ANTES da configuração do Cloudflare
Teste realizado APÓS a configuração do Cloudflare

Neustar simula acesso de varias localidades ao mesmo tempo.
Repare que nem tudo deu tão certo assim, olhe o tempo em Dublin.
Sentiu falta do tempo de carregamento da pagina no Brasil? Então, esse teste eu deixo para você! acesse http://www.fadasliterarias.com.br e confira, particularmente estou muito satisfeito.

UPDATE

Deixo aqui uma das telas do dashboard do Cloudflare, indicando a economia de dados, umas das features prometida pelo serviço. O pviana é um blog pequeno, então os números são modestos. ;)

 

É possivel apagar nossas informações da internet?

A ideia de escrever esse post veio de uma coisa que faço com uma certa frequência. Organizar da melhor maneira possível os vários logins que tenho espalhados pela internet.

Não é sempre que consigo apagar uma conta criada e as regras de apagamento são as mais criativas possíveis. Pelas minhas contas eu tenho uma conta de email, de um domínio muito conhecido, e eles não permitem que eu cancele a conta e informam que o apagamento ocorre de forma natural apos um período de 365 dias sem uso. Lembrando que isso é apenas um exemplo, tenho outros casos também complexos.
 
Na minha opinião apagar um login em qualquer plataforma deveria ser simples, melhor, tão simples quanto criar um novo login/account. Infelizmente sabemos que não é, tanto que o britânico Robb Lewis criou o JustDelete.me onde ele acabou classificando a dificuldade em conseguir este feito.

Robb não foi o único a inventar uma ferramenta de apagamento para os mais variados sites pela internet, conheço ainda o Account Killer. Abaixo é possível ver um rápido video do canal Olhar Digital do UOL sobre o assunto.


Uma curiosidade, o pessoal do JustDelete.me tem uma categoria chamada: "Impossible". Uma categoria com esse nome não deixa duvidas não é mesmo. Em outras palavras se você entregou seus dados esquece pois não vai conseguir apagar! Se você tiver a curiosidade de ler essa lista vai ficar tão surpreso quanto eu fiquei. Tenho certeza que você tem um login em um site listado nessa categoria.

HTTPie

O HTTPie é um projeto de Jakub Roztocil, desenvolvido em Python, usando as bibliotecas Requests e Pygments, e está sob uma licença BSD. A ferramenta está disponível para instalação através do pip ou pode ser obtida no repositório Github do projeto.

A proposta da ferramenta é ser um CLI(Command Line Interface) para servidores web mais humano, a sintaxe dos comandos são simples e o retorno por ex é colorido. Acredite, isso facilita muito a visualização de informações em momentos mais críticos em que você está com pressa.

Inevitável não comparar com o cURL até porque os dois possuem recursos semelhante, quer ver um exemplo? Instale os dois na sua maquina e digite o seguinte:
curl -i -X PUT -H 'Content-Type:application/json' -d '{"blog":"pviana"}' http://httpbin.org/put
Agora vamos fazer o mesmo utilizando o HTTPie:
http PUT http://httpbin.org/put blog=pviana

Ficou com preguiça? Pois bem o retorno dos dois comandos segue abaixo:

HTTPie  vs  cURL

Volto a afirmar que a ideia do post não é dizer que uma ferramenta é melhor que a outra. Escrevi esse post apenas para documentar uma experiência que tive com uma ferramenta que achei muito mais simples de utilizar do que a que estava habituado.

Logrotate

Logs são extremamente importantes para o correto funcionamento de um sistema, pois estão ali as informações necessárias para corrigir um problema ou para entender porque ocorreu uma determinada falha. Agora logs também possuem seus defeitos, afinal eles podem ser o responsáveis por encher uma partição raiz sem que você perceba, deixando assim o ambiente extramente lento e algumas vezes inutilizável causando os mais diversos problemas.

Uma excelente opção de gerencia disso é o tradicional LogRotate. Com ele você indica o período de rotação do arquivo de log, pode determinar ainda o apagamento e se for o caso compressão, alias extensão da compressão também é possível configurar.

Arquivo de configuração do log rotate é: /etc/logrotate.conf, o que devemos fazer é indicar o arquivo a ser monitorado e quais as métricas por ex:
/var/log/messages {
   rotate 5
   weekly 
   postrotate
      /sbin/killall -HUP syslogd 
   endscript
}
Acima temos o arquivo messages (ou syslog em algumas distribuições) como base, em seguida está definido que haverá uma rotação de 5 arquivos ( messages.1, messages.2, messages.3...) que ocorrerá semanalmente e por fim toda vez que houver uma rotação o comando killall será executado.



Lembrando que existem diversas opções para utilizarmos no LogRotate. Se me permite um "copy / translate / paste" da documentação.

compress - Opção utilizada para comprimir os logs.
compresscmd - Comprimir os logs de outra forma. O padrão é gzip.
uncompresscmd - Opção utilizada para definir o comando para descomprimir os logs. O padrão é gunzip.
compressext - Especifica a extensão usada para o arquivo de log comprimido, caso a compressão esteja habilitada.
compressoptions - Opção possibilita incluir parâmetros aos comandos de compressão. Por exemplo: gzip -5. O padrão é a compressão máxima "-9".
copy - Copia o log sem modificar o original.
copytruncate - Copia o log e move o original para outro lugar.
create [mode owner group] - Este é o comando usado para a criação de um novo arquivo de log vazio após a rotação. Você pode alterar as permissões, o dono do arquivo e o grupo.
daily - Rotacionar diariamente.
delaycompres - Atrasa a compressão do log para a próxima rotação.
extension [ext] - Inclui uma extensão para o arquivo de log. Se a compressão usada for a padrão a extensão será .gz.
ifempty - Rotaciona os logs mesmo quando vazios. O inverso pode ser definido através da opção: notifempty
include [file or directory] - Indica outros arquivos de configuração ou diretórios que tenham arquivos de configuração para o logrotate.
mail - Envia um email com logs extintos.
mailfirst - Envia um email com os logs rotacionados.
maillast - Envia um email com os logs que serão rotacionados, os logs originais.
missingok - Não enviar mensagem de erro no caso de um arquivo de log não existir.
monthly - Rotaciona os logs mensalmente.
nocompress/nocopy/nocopytruncate/nocreate/nodelaycompress/nomail/nomissingok/noolddir/nosharedscripts/notifempty - Negativas aos comandos correspondentes.
olddir [directory] - Guardar as versões rotacionadas em outro diretório.
postrotate/endscript - Comandos a serem executados após a rotação do log.
prerotate/endscript - Comandos a serem executados antes da rotação do log, caso o log seja rotacionado.
firstaction/endscript - Comandos a serem executados imediatamente antes dos prerotates comandos.
lastaction/endscript - Comandos a serem executados depois do postrotate.
rotate - Indicativo sobre a quantidade de rotações que o log vai ter.
size - Rotacionar os logs quando ultrapassarem o tamanho indicado.
start - Inclui um número para a base dos logs rotacionados, por exemplo: start 0 - log.0.
weekly - Rotacionar semanalmente.

Devpi

Devpi é uma excelente opção para repositório pypi, claro não desmerecendo do Bandersnatch. A grande diferença entre os dois é que o Bandersnatch foi pensado para um ambiente totalmente offline. Quando o Bandersnatch é iniciado faz download de todos os pacotes disponíveis no repositório que foi previamente indicado no seu arquivo de configuração para um diretório local só então começa a servir. Enquanto que o Devpi trabalha com cache, ou seja, você também indica um repositório mestre e um diretório onde ele vai guardar os pacotes, mais o download acontecerá sob demanda. Isso sem falar que o Devpi também trabalha com replicação, quando for iniciar o servidor você pode indicar outro servidor devpi como master.

As duas opções são boas a diferença está no jeito que cada uma funciona, acredito que a escolha ficará por conta do ambiente que você possui. Caso tenha uma maquina com acesso a internet então eu usaria o Devpi, até porque não imagino alguém precisando dos 180Gb de pacotes que o Bandersnatch baixa do repositório python padrão.


Vamos instalar o Devpi então? Primeiro passo, precisamos do pacote Python-pip instalado na maquina. Caso já tenha otimo, do contrario, execute o seguinte comando:
sudo apt-get install python-pip
 Utilizando o pip instale o Devpi.
sudo pip install devpi
Agora que o servidor devpi está instalado. Recomendo ler também o "--help" antes de iniciar. Para esse post vou usar apenas o parâmetro "--host". Isso significa que o "--serverdir" permanecerá o padrão. (~./devpi/server).
sudo devpi-server --host=0.0.0.0
Simples demais não é mesmo? Servidor devpi está operacional. Quando os clientes solicitarem os pacotes ele vai entregar e guardar no cache local. Dessa forma ele consegue servir mais rapidamente das próximas vezes sem a necessidade de ir para internet em todas as requisições que receber.

Ok... Agora e na maquina cliente, como fazer para pedir esses pacotes? pip install e pronto?!
Resposta: Não! Execute o comando pip da seguinte forma:
sudo pip install -i http://ip_do_servidor:porta/root/pypi/+simple/ nome_do_pacote

Siege HTTP Benchmark

Recentemente pesquisando sobre balanceamento de carga e também como melhorar performance do nginx, esbarrei com uma ferramenta simples e ao mesmo tempo muito útil. Para exemplificar melhor a situação vamos considerar uma instancia com 1GB de RAM, 2 CPUs e um Debian8, calma, não se prenda muito nesses valores.

Primeiro passo foi entender o que poderia fazer a diferença no nginx.conf. Encontrei duas opções logo no inicio que chamaram muito atenção: worker_processes e worker_connections. Na documentação oficial do nginx existe uma recomendação de preencher o worker_processes com total de CPUs e no worker_connections o valor obtido através do resultado do comando: ulimit -n.

Obs: Total de cpu pode ser obtido através do comando:
cat /proc/cpuinfo |grep -i processor |wc -l 

Próximo passo foi encontrar uma ferramenta que fosse capaz de realizar um teste de performance, algo semelhante ao que o AB faz com o Apache. Afinal de contas, será que os valores indicados estão sendo levados em consideração? Foi nesse momento que encontrei o Siege, uma excelente opção capaz de realizar esse teste. 

Instalação é muito fácil, está disponível no repositório brew(osx) e também no repositório do Ubuntu. Hmm, putz! estamos usando Debian não é mesmo? Falei para não se prender naqueles valores, hehehe. Pois bem, adicione um repositório ai:
vim /etc/apt/sources.list
deb http://ftp.de.debian.org/debian sid main

Existem muitas opções disponíveis para que possamos estressar nosso webserver através do Siege. Recomendo muito a leitura da documentação. Devido a limitação do meu ambiente virtual, montei esse post considerando apenas duas: -t(tempo de execução) e -c(numero de conexões). Sintaxe ficou assim:
siege -t10s -c800 https://IP_DO_SEU_WEB_SERVER
Ao termino da execução do siege, vamos ter acesso a um relatório semelhante ao da imagem abaixo, onde é possível observar o tempo médio de execução, total de dados transferidos, tempo médio de resposta por usuário...

O post chega ao fim não porque esgotamos todas as possibilidades, longe disso, o nginx possibilita uma gamma muito maior de opções a serem alteradas quando o assunto é performance. Foco foi apenas em apresentar uma boa ferramenta para estressar seu webserver dentro da limitação do meu ambiente de testes.