Site não seguro – como resolver de graça com Let’s Encrypt

No começo de 2017, o Google Chrome passou a mostrar um aviso para os usuários, com o texto “não seguro” na barra de endereço quando um site sem HTTPS pede dados do usuário. Classificou a maioria dos sites como “site não seguro”. Assim:

Aviso de site não seguro do Chrome

Essa mensagem aparecia apenas em situações onde o site potencialmente ia coletar dados dos usuários. Basicamente, quando havia um formulário na tela. Principalmente formulários de login, mas a mensagem aparecia para praticamente qualquer formulário. Logo, durante todo o ano passado, você poderia manter um site de conteúdo sem HTTPS, sem problema nenhum, desde que não tivesse formulários.

Recentemente, porém, o Google passou a avisar site não seguro para qualquer site sem HTTPS. Assim, até o Pudim, um site que não tem formulário, nem scripts, nem nada, só uma foto de um pudim, está marcado, veja:

Site Pudim marcado pelo Chrome como site não seguro
Até o Pudim agora é um site não seguro, pobre Pudim 🙁

Tenho um site não seguro. Como resolver? Let’s Encrypt!

Essa iniciativa do Google Chrome não está sozinha. Faz parte de um esforço de várias frentes para tornar a web mais segura. O próprio Google anunciou que está privilegiando nas buscas sites com HTTPS. Quer dizer que, ao estar marcado como site não seguro, seu site não apenas vai assustar os usuários que receber, também vai receber menos usuários.

O próprio Google Chrome, junto com empresas como GitHub, Facebook, Cisco e Akamai, patrocinam uma iniciativa chamada Internet Security Research Group, que oferece, através do Let’s Encrypt, chaves SSL grátis e automáticas para qualquer site.

Assim, se o seu provedor dá suporte a Let’s Encrypt, você provavelmente pode ter seu site marcado como seguro em poucos cliques. Meu hosting predileto, por exemplo, é a Dreamhost. Se você hospeda seu site lá, pode ativar SSL em seu site em três cliques, aqui:

Página Secure Hosting no painel da Dreamhost
Viu ali? Let’s Encrypt SSL.

Se você mantém seus próprios servidores, dedicados ou VPS, você vai ter que instalar o Let’s Encrypt você mesmo. O processo é bastante simples. Expliquei nesse vídeo:

HTTPS com Let’s Encrypt

Mantenha seus servidores enxutos

Foi divulgada ontem uma vulnerabilidade no servidor de compartilhamentos Samba, usado por máquinas Linux e FreeBSD para compartilhar arquivos e recursos em redes Windows. É uma falha grave, simples de explorar, e que afeta versões do Samba desde a 3.5.0, lançada há sete anos.

Então, se você usa Linux, confira se você tem o Samba instalado. Se tiver, confira a versão menor (aquele terceiro número no código da versão). Se você estiver usando uma das seguintes, você está seguro: 4.6.4, 4.5.10 ou 4.4.14.

Se não. Você pode fazer uma das seguintes coisas:

  1. verificar se há atualização do Samba para sua distribuição, e se a versão mais atualizada é uma dessas acima; ou
  2. baixar o código fonte e compilar o Samba você mesmo, de preferência da versão 4.6.4; ou
  3. desligar o serviço vulnerável, adicionando ao seu smb.conf a linha abaixo:
    nt pipe support = no

    E em seguida reiniciando o Samba; ou

  4. desinstalar o Samba

A última alternativa pode parecer a mais preguiçosa, e talvez você simplesmente não possa cogitá-la. Mas eu recomendo que você se pergunte, antes de qualquer outra atitude: eu preciso mesmo desse serviço? Dessa vez foi uma falha no Samba, mas praticamente todo dia saem atualizações de segurança para os diversos softwares e serviços que você pode instalar em seu sistema. Cada software não utilizado que você mantém instalado aumenta suas chances de ter problemas de segurança e suas preocupações com atualizações de versão.

Nesse caso, menos é mais. Reduza os pacotes que você tem instalados aos essenciais, removendo tudo o que você não usa. Principalmente em servidores. Isso vai tornar suas máquinas mais seguras e vai tornar mais fácil para você manter tudo atualizado.

Assine a companhe os boletins de segurança dos softwares que você usa. Você não quer correr o risco de não ficar sabendo de uma atualização crítica e ter seu sistema vulnerável simplesmente por não ter sido avisado, não é?

Por fim, é importante que você saiba que a essa falha de segurança no Samba é especialmente preocupante porque muitos dispositivos NAS e outras soluções de armazenamento de dados usam Samba. Então se você possui um equipamento de armazenamento de dados, é bom investigar se ele usa Samba e está vulnerável a essa falha.


PS: obrigado ao Rodrigo por me avisar.

Para onde foi a performance do seu Linux? Glances nele!

Glances é a melhor aplicação que eu já vi para análise de performance no Linux. Veja um screenshot:

glances

Numa tela simples de terminal temos uso de memória, CPU, rede, I/O e espaço em disco. Aperte h para ver a ajuda.

Para instalar:

sudo apt-get install glances

E para executar:

sudo glances

Claro, se você não usa Debian/Ubuntu, troque apt-get por yum, pacman, emerge ou o comando correspondente em sua distro.

Pare de usar FTP

Há mais de dez anos que meus processos de deploy, isto é, colocar um site ou sistema em produção, não usam FTP. Qualquer bom provedor, nacional ou internacional, oferece ferramentas muito mais eficientes para o deploy de sites e sistemas. E isso inclui desde pequenos sites em WordPress ou HTML estático até portais com milhares de acesso por hora e grandes sistemas rodando em estruturas de cloud computing elástico.

Por que você não deveria usar FTP

FTP é um protocolo muito simples de troca de arquivos, que pode ser útil para uma porção de coisas. Mas não possui os recursos necessários para o deploy e controle eficiente de aplicações web. Entre os problemas com o protocolo FTP, podemos citar:

  1. Falta de integração com controle de versão: você está fazendo uma manutenção num site, cujo diretório tem 5MB de dados. Você alterou não mais que uma dúzia de arquivos, em pastas diferentes. Arquivos texto cujos tamanhos, somados, não passam de 200KB. Como você faz o deploy por FTP? Ou sobe o site todo, “por via das dúvidas”, ou precisa pinçar os arquivos que precisa subir, um a um, certo? Algumas ferramentas de transferência, como o Filezilla, conseguem “sincronizar” as pastas, mas eles fazem isso varrendo as pastas uma por uma e comparando as datas e tamanhos dos arquivos. Leva um tempão e, se algum outro programador alterou os arquivos antes de você isso certamente vai dar problemas. O que nos leva a um segundo ponto:
  2. Falta de recursos de “auditoria” e controle de deploys: não há como obter um log ou lista de quem fez deploy, quando e o que foi feito. Um problema recorrente em ambientes em que uma equipe trabalha com FTP é a sobrescrita de alterações já publicadas. Na pior das hipóteses, gerando perda de trabalho. Mas mesmo que a equipe tenha um ambiente interno de controle de versões e a sobrescrita no FTP seja fácil de resolver, pense na dor de cabeça de ter que explicar para o cliente que o defeito que foi corrigido ontem voltou ao ar hoje, mas já estamos resolvendo.
  3. Falta de automatização: deploy por FTP é feito à mão. Um homo sapiens navega nas pastas de seu computador e do servidor e arrasta o que deve ser atualizado de um lado para outro. Num processo chato e delicado. Se ele arrasta as coisas para a pasta errada, pode ser muito difícil consertar o problema. Pode ser difícil até entender o problema. E se você coloca um homo sapiens para repetir uma mesma tarefa vinte ou trinta vezes, ele certamente vai errar alguma.
  4. Falta de recursos para rollback automatizado: você subiu a alteração. Em seguida abriu o site e viu um “erro de conexão ao banco de dados”. Percebe então que subiu a versão errada, ou no lugar errado. Como voltar atrás? Voltar atrás com FTP é um processo ainda mais manual e trabalhoso do que subir o site. Já vi casos, e não foram poucos, em que foi preciso pedir ao provedor para restaurar o backup diário. E esperar por isso, claro.

O que você deveria usar então?

SSH e Git. Há uma série de ferramentas para deploy automático, como o Capistrano ou o Jenkins. Esqueça isso tudo no começo. Aprenda SSH e Git, e construa seu processo de deploy com isso. Você vai ganhar:

  1. Deploy realmente automático. Com um único comando.
  2. Integração real com o controle de versão. Isso significa que sempre será possível rastrear cada alteração. Também significa rollback automático, o que é maravilhoso.
  3. Controle simplificado de múltiplos ambientes. Precisa fazer deploy em um ambiente de homologação, para mostrar as novidades ao cliente? Um comando. Ele aprovou as novidades, e agora é hora de fazer deploy em produção da versão que foi homologada ontem? Um comando.
  4. Preparação para o futuro. O site cresceu e você precisa agora migrar para um serviço como o AWS Elastic Beanstalk, que oferece escalabilidade “elástica” sob demanda dentro da estrutura de serviços da Amazon. O processo vai ser praticamente indolor. O cliente precisa agora de deploys com zero de indisponibilidade, e você resolveu usar a estratégia Blue Green. Já tem tudo o que precisa.

Por isso, não se conforme em usar FTP. Se precisa estudar SSH e Git, estude, vai valer a pena. Se já sabe, está esperando o quê?

“Jabá”: uma boa maneira de aprender como mudar seus processos de deploy, e muito mais, é o treinamento DevOps Heroes da Visie, que acontece daqui a duas semanas.