Use branches no Git!

Apesar da ampla adoção do Git, ainda são poucas as equipes que utilizam com eficácia os branchs. Acredito que a culpa disso seja em grande parte pelo baixo uso de branches no SVN ou CVS. Talvez isso tenha até contribuido para criar um certo medo de branches.

Porém, existe ínumeras situações do dia a dia em que o uso de branches irá poupar muito trabalho, viabilizar experimentos ou organizar o desenvolvimento.

É fundamental compreender o uso de branches para que você possa compreender a sua correta utilização.

A diretriz que eu tenho seguido é simples: criar um branch novo para qualquer linha de desenvolvimento. Caso seja necessário o desenvolvimento em conjunto com algum outro desenvolvedor, faça um branch remoto. Fazer pequenos commits irá te ajudar na hora de selecionar um commit defeituoso e a procurar erros com git bisect.

Realize merges entre as linhas de desenvolvimento o máximo de vezes que for permitido. Quanto maior a divergência entre as linhas de desenvolvimento, maior será o número de conflitos e mais díficil será o merge. O momento do merge é um gargalo, pois os conflitos tem de serem resolvidos localmente, ou seja, apenas um desenvolvedor pode resolver os conflitos entre dois merges.

Desconheço qualquer forma de resolver conflitos que não seja local e isso me parece uma limitação grave, se alguém souber de algo ficarei muito contente se me explicar.

Nos primeiros dias que segui essa abordagem, apanhei um pouco do Git (um pouco mais do que o habitual), mas foram os momentos em que mais aprendi sobre o seu funcionamento. Comece nesse exato momento a utilizar branches, mesmo que o seu projeto esteja atrasado 28 dias, 6 horas, 42 minutos e 12 segundos *.

Apenas para o não ficar incompleto, seguem as receitinhas de bolo mais simples para criação e remoção de branches remotos.

Criando um branch remoto

$ git push repos src:dst

repos

Repositório

src

Branch de origem no repositório

dst

Branch de destino no repositório

Deletando um branch remoto

$ git push repos :dst

* Este é o tempo que falta para o mundo acabar quando Donnie Darko encontra Frank pela primeira vez.

Aumentando a segurança do SSH com 3 medidas simples (leiam a conclusão também)

Aqui vão 3 dicas de fácil implementação e que com certeza aumentarão muito a segurança do seu servidor SSH. Ao alterar a configuração do SSH você deve reiniciar o servidor SSH para que a nova configuração seja carregada.

Arquivos

Configuração do servidor SSH:
/etc/ssh/sshd_config

Reiniciar o servidor SSH:
/etc/init.d/ssh restart

1. Restrinja o uso ao Protocol 2

O Protocol 2 é o padrão, porém, muitas distribuições vem com a configuração padrão Protocol 1,2. A release mais recente do Ubuntu, Karmic, já vem configurada para apenas Protocol 2, porém, muitas vezes temos um sistema que foi atualizado de releases mais atingas sem trocar os arquivos de configuração, portanto vale a pena você verificar quais protocolos o seu servidor SSH está aceitando.

/etc/ssh/ssh_config:
Protocol 2

2. Restrinja o acesso root

Existem diversos usuários que são criados automaticamente nas distribuições. Uma boa distribuição retira a senha destes usuários, impedindo a autenticação através de senha. Porém, muitos administradores configuram uma senha para o root.

A forma mais básica de um script de acesso à força bruta em um sistema funciona da seguinte forma: achar um IP que aceita uma conexão na porta 22 e tentar diversas senhas com o usuário root.

Impedir o login do root já cria uma dificuldade extra: qual usuário utilizar para se logar?

/etc/ssh/ssh_config:
PermitRootLogin no

3. Impeça a autenticação por senha

De nada adianta qualquer outra medida de segurança se as senhas utilizadas forem fracas. Com um pouco de sorte, um ataque de dicionário consegue quebra-las. Podemos implementar diversas políticas de criação de senha, atualização etc. Geralmente essas medidas tendem a piorar o problema, pois elas se sustentam exatamente no aspecto mais falho do sistema: o ser humano.

Impossibilitar a autenticação atavés de senhas e permitir apenas através de troca de chaves ou certificados nos trás dois benefícios: elimina a necessidade de memorização da senha e impede ataques de dicionário.

/etc/ssh/ssh_config:
PasswordAuthentication no

NOTA: É de extrema importância que você já possua ao menos um usuário com as chaves já configuradas e acesso previlegiado ao sistema, do contrário, ao reiniciar o SSH você ficará impossibilitado de se autenticar.

NOTA 2: Você deve configurar as chaves para cada máquina que irá se autenticar com aquele usuário. Isto pode gerar um pequeno trabalho para transportar as chaves públicas das suas máquinas para o servidor de uma vez só. Ex. desktop do trabalho e notebook de casa. É melhor configurar todas as chaves e só depois proibir autenticação por senha.

Conclusão

Estes 3 passos estão longe de ser uma solução completa de segurança, mas acho sejam o mínimo de segurança que devemos prover a qualquer máquina com servidor SSH na internet.

O melhor destas 3 iniciativas é que elas requerem muito pouco trabalho e dão um bom resultado. Isto é muito importante para equipes enxutas aonde uma única pessoa tem diversas roles ou é responsável por diversos servidores.

Outras medidas são o uso de TCP Wrappers, mudança de porta do SSH, knocking doors, lista de usuários que podem se autenticar e mais um infinito de soluções.

PS: Muitas pessoas acreditam que apenas alterar a porta SSH oferece alguma proteção, porém se esquecem que é extremamente simples construir um script que busque uma porta SSH aberta.