O ditado de que em casa de ferreiro o espeto é de pau é verdade. Aqui em casa a rede não passa nem perto do relógio suiço que é na empresa. Só tenho uma pasta compartilhada na rede, vira e mexe a esposa tem problemas de permissão copiando arquivos, a impressora não é compartilhada, os backups são manuais (quando eu lembro) e não tinha nada organizado em termos de storage.

Resolvi começar atacando o problema de storage e minha idéia inicial foi usar ZFS.

Peguei emprestado um HD externo na empresa (ah, sim… meu HD de backup não tem espaço para um backup full das minhas coisas), fiz aquele backup com capricho e mandei ver…

Comecei pensando em instalar o Debian/kFreeBSD, mas pensei: Pô… Se eu vou instalar FreeBSD vamos logo pras cabeças, né? Baixei FreeBSD 8.1 e comecei a instalar, mas logo de cara já deu aquela sensação ruim. A última vez que usei FreeBSD foi circa 2001 e logo de cara vi que o processo de instalação continua igualzinho! O bagulho não evoluiu uma vírgula em 10 anos. Começou mal.

Depois de instalado passei um bom tempo tentando configurar o X, sem sucesso. Verdade que tenho uma maldita nVidia, mas deveria funcionar com um driver genérico. Mas não rolou. Tudo bem, não preciso de X, vamos instalar outras coisas. Vou até o ports e instalo meia dúzia de coisas, mas outras que vou tentar só dão erro. Quer saber? Não sou masoquista não.

Vamos pro Debian/BSD então. Pra instalar com suporte a ZFS na partição root só usando o daily build do mini.iso. Beleza. Tem um mirror numa universidade aqui perto e o download é rápido pra cacete. Não vai ser o problema.

A instalação é linda, vai tudo bem até o final, dou boot no sistema, ZFS online, apt-get install comendo solto e coloco X pra funcionar num instante (ruim, mas funcionando). Ai o primeiro problema: Conecto meu HD externo e o meninão não reconhece EXT3… Só EXT2. :-\

Conecto o HD no meu notebook e começo um rsync via rede. Mesmo demorando uma eternidade as coisas vão indo bem e eu já penso: Bom… enquanto restaura vou brincar com as configurações. Essa pasta aqui eu vou compartilhar na rede e…

warning: mountd isn't supported in Debian GNU/kFreeBSD yet

WTF? Como assim? Não posso compartilhar meus volumes ZFS? E só descubro isso umas 2 horas depois de tudo instalado e com metade dos backups restaurados?

Quer saber, vocês vão tudo praquele lugar. Eu vou instalar OpenIndiana mesmo. Mais 30 minutos de download, gravar DVD, boot… boot? Nem boot deu no meu PC. TAQUEO!

Nesse momento eu desisti. Chega. Sofrimento tem limites. Bora baixar Ubuntu 10.10 e usar Btrfs mesmo…

Não sei vocês, mas eu tenho a impressão que as coisas estão meio estacionadas faz um tempo. Eu mesmo estou usando na minha workstation do trabalho um Ubuntu 9.10 e não vejo o menor motivo pra upgrade. Parece que nos últimos anos nada digno de nota aconteceu. Ou talvez tenha, mas só não foi nada que me interessou.

Porém para um futuro próximo parece que vamos ter um aumento de performance sensacional, um filesystem de gente grande e uma camada gráfica decente . Isso tudo num espaço de talvez um ano?

Tô na pilha para colocar as mãos num Ubuntu 11.10 e descobrir que ele roda melhor, mais rápido, mais confiável e mais bonito na mesma máquina que estou usando hoje.

Como saiu mês passado o novo Ubuntu resolvi instalar a nova versão. Mas desta vez resolvi fazer um downgrade: Instalei a versão 32 bits.

Meu proc é um AMD Athlon(tm) 64 X2 Dual Core Processor 5000+ e apesar do Linux e todos os aplicativos open-source funcionarem perfeitamente nele uma coisa me irritava muito: O plugin do flash.

Eu tentei tanto com o plugin 32 bits emulado quando o 64 bits nativo, tanto no Ubuntu (8.04) quando no OpenSuSE 11.1 sempre com o mesmo problema. O plugin travava, congelando tudo que fosse flash, 100% de CPU sendo usada o tempo todo e algumas vezes mesmo depois de fechar o firefox o processo continuava pendurado até eu dar um kill nele. Um saco.

Além disso eu tava querendo instalar o plugin de off-line do Gmail, mas é outra coisa que só tem pra 32 bits. Aliás, vários plugins e extensões proprietários nem sequer tem versão 64bits. Uma piada, já que a plataforma está por ai há um bom tempo.

Mas como a máquina é só meu desktop pessoal, que uso aqui em casa basicamente pra ver email, assistir vídeo do youtube e navegar na internet não vou ter nenhum impacto.

Também não sou nenhum freetard que normalmente brada contra software proprietário, mas em situações como essa que eu vejo que m* que é ter que usar coisa que não é open-source. Fico na depedência de uma empresa imbecil se dar ao trabalho de compilar as aplicações deles para minha plataforma.

Bah.

Tudo bem, atualizar é preciso. Inclusive eu tinha um atualização de kernel instalada fazia umas três semanas, mas ainda não tinha dado boot. Aproveitei o fiz. Fui embora na sexta com a máquina 100% atualizada.

Cá chego eu hoje de manhã e dou de cara com isso:

Como isso, amigão? Tu tá de brincadeira?

E ai me lembro que já reclamei disso antes. E uma rápida busca me mostrou que foi exatamente um ano atrás.

Pode ser impressão, mas em casa estou usando o OpenSuSE e tenho atualizações muito menores e menos freqüentes.

Mas o importante mesmo é lembrar que hoje é segunda-feira e pode ser apenas ranhetice de começo de semana…

Não sei se o que engatilhou o easter egg foi parar e recomeçar a instalação ou o horário já avançado que me colocou mais perto do Natal, mas aqui está a tela de boot que apareceu para mim:

Bacana.

Solaris 9: OK

$ cat /etc/redhat-release
Red Hat Enterprise Linux ES release 4 (Nahant Update 6)

$ tail +3 abc.txt
linha 3
linha 4
linha 5
linha 6

RHEL 5: OK

$ cat /etc/issue
Ubuntu 8.10 \n \l

$  tail +3 abc.txt
tail: cannot open `+3' for reading: No such file or directory

Intrepid Ibex: FAIL

UPDATE: Aparentemente isso é uma feature, não um bug.

Um dos meus colegas aparece hoje com o seguinte desafio: Instalar Linux num servidor IBM Netfinity antigão que está jogado nos fundos do data center. O problema é que o leitor de CD está bem zoado e depois de uns 2 minutos funcionando ele simplesmente pára de ler. Sem contar que ele não consegue dar boot de jeito nenhum.

Comecei pensando em dar boot pelo floppy e depois instalar o resto via CD até descobrir que o leitor estava mais bichado do que eu tinha imaginado.

A solução então foi instalar usando floppy + netinstall

Posso estar errado, mas aparentemente não tenho a opção de netinstall via floppy no Ubuntu e precisei baixar o mini-iso para fazer isso.

Mas como o CD não dá boot também precisei usar o Smart Boot Manager para conseguir bootar a máquina.

As referências caso você precise passar pela mesma situação:

How To Install Ubuntu Locally Over The Network

Smart Boot Manager

Baixe o seu por Bittorrent e faça sua parte! Eu to fazendo a minha:

Sou apenas um sysadmin metido a besta que gosta de fazer uns scripts de vez em quando. No meu antigo emprego eu fazia muitos, mas sempre para aplicações específicas, que não teriam uso para mais ninguém fora da empresa.

Mas no atual emprego estou fazendo coisas mais genéricas e resolvi compartilhar este script que fiz estes dias. Ainda está bem verde e mostra claramente minha falta de finesse como programador.

Se você utiliza Ubuntu e tem o UFW ativado já deve ter reparado que os logs que ele gera não são exatamente fáceis de ler. Nada que um bando de pipes, greps, seds e cuts encadeados não resolva, mas como o UFW em si é feito em Python e eu ando querendo melhorar meus conhecimentos nesta linguagem, resolvi fazer meu parser também em Python.

Se alguém eventualmente baixar e usuar este treco, depois me fala o que achou e me mande patches.

Download aqui.

A rede mundial de computadores tem mais de 10 botnets. Todas dominadas por crackers armados até os dentes. É só nego de nmap, nessus, tcpdump e por ai vai.
No resto do mundo são softwares de auditoria. Na internet, são as armas do crime.

Um 0-day attack atravessa um firewall como se fosse papel. É burrice pensar que numa rede assim os daemons, mesmo atualizados, não vão ser crackeados apenas para fazer valer a lei.
E Linux também tem bug amigo, Linux também tem falha de segurança.

É por isso que nessa rede todo administrador tem que escolher: Ou se corrompe, ou se omite, ou vai pra guerra.

Aviso

Se você é um profissional decente, não tenho dúvidas que vai decidir partir para guerra e nesse tutorial vamos ver os passos básicos para tornar seu servidor mais resistente a invasões.

Mas não se iluda. Nada é 100% seguro e seguir as boas práticas de segurança uma vez na vida não vai te ajudar muito. Mantenha-se atualizado, mantenha sua infra-estrutura atualizada (não apenas seus servidores) e seja humilde. Aprenda com seus erros e com os erros dos outros.

Outro ponto que vale ressaltar aqui: Esse tutorial é dirigido ao Ubuntu Server 8.04 (Hardy). Muita coisa pode ser aplicada para desktop e para outras distribuições, mas não é sobre isso que vou falar aqui.

Fique com o básico

Quanto menos pacotes instalados no seu Ubuntu, melhor. Mais pacotes significam mais potenciais pontos de falha, mais opções para um invasor tentar escalar privilégios e mais recursos para ele utilizar sua máquina como ponte para outros ataques em caso de uma invasão bem sucedida.

Durante a instalação do seu Ubuntu Server, quando apresentado às opções, não escolha nenhum pacote. Você pode manualmente instalar openssh, LAMP, DNS e etc mais tarde, num momento mais conveniente.

Num primeiro momento fique apenas com o sistema mais enxuto possível para facilitar as implementações de segurança antes de começar a abrir as portas.

Application Specific

Ter um servidor para cada serviço que você precisa não é mais exclusividade de grandes empresas, com um gordo orçamento. Utilize máquinas virtuais baseadas no seu hypervisor preferido e crie uma máquina virtual para cada tipo de serviço que for utilizar.

Utilize de bom-senso. Não coloque banco de dados da intranet na mesma partição virtual que está seu banco de dados da DMZ.

Algo como um servidor de banco de dados para todos os serviços da DMZ e um servidor HTTP para todos os bancos de dados da DMZ parece mais coerente.

Servidores em redes muito hostis (como um servidor do lado de fora dos firewalls da DMZ) ficam melhor se forem self-contained, ou seja, com todos os serviços rodando numa mesma partição virtual.

Tenha certeza de que tem uma placa de rede exclusiva para administração do seu hypervisor e proteja-a muito bem.

No Ubuntu o Xen é uma excelente opção.

Guardando seus logs

Numa situação ideal sua rede vai dispor de um servidor de syslog onde todos os hosts enviam seus eventos, mas se não for o caso, durante a instalação crie uma partição /var/log com filesystem ext3.

Isso vai permitir que você utilize o chattr para restrigir seus arquivo ao modo append only.

# cd /var/log
# chattr +a messages syslog auth.log daemon.log

Caso esteja utilizando rotacionamento de log, lembre-se de editar as políticas para evitar erros.

Ter logs é essencial para previnir invasões, mas pode ser seu passe livre de problemas em caso de invasão concretizada ou investigação judicial.

Se possível utilize sempre um servidor de syslog numa máquina física à parte. Seja bem paranóico na configuração da segurança dessa máquina.

Utilize firewall local

Mesmo que sua rede disponha de firewall de borda, existe sempre a possibilidade de alguém conseguir acesso à sua rede local. Um visitante numa sala de reunião, um esperto num wireless rogue, etc.

No Hardy nem mesmo com sintaxe do iptables você precisa se preocupar. Basta utilizar o ufw.

Ele já vem com uma lista de regras pré-configuradas com um nível de segurança bem aceitável. Falando em bom iptablês, as policies são DROP e você aplica suas excessões.

Exemplificando um servidor LAMP na sua DMZ:

# ufw allow proto tcp from 192.168.5.0/24 to 192.168.100.2 port 22
# ufw allow proto tcp from any to any port 80
# ufw enable

Onde:

192.168.5.0/24 é sua rede interna.

192.168.100.2 é o IP interno do seu LAMP server

Ou um servidor de DNS apenas com ip válido:

# ufw allow proto tcp from 200.200.200.201 to 200.200.200.10 port 22
# ufw allow proto udp from any to 200.200.200.10 port 53
# ufw allow proto tcp from 200.1.1.200 to 200.200.200.10 port 53
# ufw enable

Onde:

200.200.200.201 é o IP nateado da sua rede

200.200.200.10 é o IP do seu servidor de DNS

200.1.1.200 é o seu DNS Slave

Colocando uma armadura

A Novell desenvolveu um excelente framework de segurança chamado AppArmor e disponibilizou como open source.

Consiste basicamente em um patch no kernel e uma série de ferramentas de gerenciamento.

O conceito é: Uma determinada aplicação, independentemente de estar sendo executada pelo zezinho ou pelo root deve conseguir acessar somente determinados diretórios e arquivos, executar somente determinados comandos e utilizar somente determinadas bibliotecas.

O grande trunfo do AppArmor é que ele proteje seus servidor mesmo contra 0-day attacks. Se você preparar o perfil da sua aplicação muito bem são grandes as chances de seu servidor sair ileso mesmo num ataque a um daemon bugado.

Para isso você gera um arquivo com o “perfil” da aplicação e fala pro AppArmor: Amigão, esse binário só pode fazer isso aqui ó…

O Hardy já vem com o kernel patcheado e com as ferramentas de gerenciamento instaladas. Basta baixar os profiles e sair usando.

# apt-get install apparmor-profiles

Mas lembre-se do seguinte: Os profiles que você instalou levam em conta que você está utilizando os serviços conforme a configuração padrão do Ubuntu. Eu inclusive recomendo que você realmente faça isso sempre que possível, mas caso esteja utilizando alguma coisa diferente do padrão, um pouco de tweak pode ser necessário.

Pessoalmente senti falta de um profile para o Apache, mas depois de criar o meu eu entendi o motivo: Depende muito do que você vai rodar no seu webserver.

Talvez mais para frente eu escreva um artigo sobre o AppArmor, mas por enquanto, fique com este link da Wiki do Ubuntu.

UPDATE (29/08/2008 08:27): Meu amigo Mezzanotti, que é especialista em IT Security, mandou um link bem interessante que eu não conhecia: Center for Internet Security. Muitos tutoriais de hardening lá. Vale uma passada.