Por algum motivo (economia? flexibilidade? independência de fornecedor? serviço de porco?) alguns servidores do banco eram máquinas “montadas” ao invés de máquinas “de marca”. Tinhamos Dell, HP e outros, mas alguns servidores mais antigos eram sem marca mesmo. E um deles era um dos firewalls internos.

Eu entrava às 09:00hrs, mas no dia eu peguei um trânsito fenomenal (saudades de São Paulo, né?) e um dos meus colegas liga no meu celular, quase chorando, 09:05hrs:

- Eri… Cadê você véio? Deu mor merda aqui.

- To a caminho, dirindo. Puta trânsito. O que foi?

- Cara, corre pra cá que preciso de você.

Corre no trânsito de São Paulo é mais ou menos 20Km/h e por isso cheguei lá umas 09:20 +/-. Quado desço do elevador no andar de IT eu vejo, de longe, três diretores e o vice-presidente em pé, do lado de fora do data-center olhando pela porta (que era de vidro).  Coisa boa não podia ser.

Fui chegando perto e pedindo licença. Quando eles afastaram olho pela porta e vejo meu colega sentado no chão, todo sujo, suado, com cara de quem estava chorando, com dois servidores inteiros desmontados no chão e peças para tudo quando é lado.

Eu entro lá rola a seguinte conversa:

-Meu! O firewall interno morreu. Não liga mais nem o botão de power. Todas as operações tão paradas. O firewall de contingência tá desatualizado e o acesso através dele não tá funcionando. Achei que alternar pra contingência* do SPB ia ajudar, mas não adiantou nada.

- Nossa… Q m*. Mas e ai? Por quê desmontou os servidores?

- Ah, imaginei que se colocasse a fonte do servidor contingência no produção ia funcionar. Mas mesmo assim ele não ligou.

- Putz. e ai?

- Ai achei que se pegasse os HDs do produção e colocasse no contingência ia funcionar. Mas não funcionou. Ai eu resolvi que podia ser porque as placas de rede são de fabricantes diferentes, então substitui elas também. Também não funcionou.

- Mas não era mais fácil editar as configurações do firewall pra refletir os drivers novos?

- Deve ser, mas não sei mexer nessa m* de Unix (Era um Unix mesmo)

- Vamos montar de volta que eu tento então.

Eu acabo de falar isso e chega o terceiro membro do time, ainda com cara de sono e remela no olho: “Pô? Que tá acontecendo?” (E os chefes ainda do lado de fora, no melhor estilo aquário mesmo).

Contamos rapidamente pra ele o começo da história e ele responde rindo:

- AHHH… Não… Sabe o que é que é? É que por motivos de segurança, eu substitui o botão de power pelo botão reset. Então pra ligar o servidor precisa apertar reset.

Ele só não apanhou porquê os chefes ainda estavam lá olhando.

* Cada vez que um banco entra em contingência é preciso pagar uma multa.

E ainda pior do que isso, mesmo arquivos que foram fisicamente apagados e até mesmo HDs que foram formatados podem ter seus dados recuperados.

Aliás, vira e mexe aparecem artigos falando sobre informações sigilosas – e muitas vezes embaraçosas – sobre alguém ou alguma empresa ou órgão de algum governo que foram recuperados de HDs jogados fora ou comprados em leilões e coisas do tipo.

Existem diversas formas de garantir que seus dados não poderão ser recuperados por alguém malicioso, mas eu gostei mesmo desse sistema ai no vídeo. Esse eu garanto que é 100% seguro!

Vi aqui.

Melhor parte da entrevista:

- So, basically TCP/IP as we know it is Broken?

- On the current implementation, yes

Via /.

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.

Se for só atualizar o sistema nem vou xingar ninguém, mas este último bug no SSL/SSH é NOJENTO de resolver… pelamor…

Pessoal do Debian: Quando forem fazer m* de novo, pelo menos tenham a decência de estragar alguma coisa que se resolve com um simples reboot. Pode ser?

Quase toda semana tem, 10, 15 updates. Caracas… Que coisa feia.

Lógico que o fato de updates de segurança serem lançados rapidamente e não ficarem aculumando pra um “Service Pack” da vida é muito importante, mas se os programadores estivessem fazendo a coisa com capricho não ia precisar de update de segurança com tanta freqüência.

Eu não tenho o menor gabarito pra dar pitaco em programação, mesmo porquê Bash Script é a única coisa que sei programar, mas a memória me diz que uns anos atrás não eram tão freqüentes as falhas.

Ou será que era o fato de eu usar Debian, com sua filosofia de “rock stable melhor que bleeding edge” é que me fazia ter menos correções?

Aliás, ainda melhor, tem alguém me ouvindo que use a última versão LTS do Ubuntu pra dizer se tem tanta atualização assim?

Hoje durante os momentos de ociosidade no serviço eu “sem querer” fui parar na página do Slackware… deu uma coçada no dedo e rolou aquela saudadezinha de 1999… Não, não… Eu tenho que ser forte.

Aliás, hoje lendo o BR-Linux dei de cara com esta notícia: Ubuntu Reina nos Desktops do Campus Party.

Isso  muito me preocupa, porquê eu uso Ubuntu. E se todo mundo usa Ubuntu eu faço parte da maioria e a maioria é burra.