A melhor defesa é um bom ataque!

Ora bem, eu tenho estado para aqui a vociferar postas de pescada sobre botnets e sistemas comprometidos, quando tenho um enorme “esqueleto no armário”: tenho um servidor Linux a correr em casa, ligado à net 24h por dia.

Dado que os tempos dourados do “É Linux, por isso é seguro” já estão a acabar (aqui ele é vítima da própria estratégia de popularização, que está a ganhar cada vez mais força), resolvi fazer um esforço mínimo para garantir que a minha máquina não se transforma numa “caixa de Petri” para seres digitais indesejáveis… fica aqui o lamiré para quem quiser reproduzir.

Mas mais importante, fica também a dica: nós também podemos contra-atacar, sabiam?

Passo 1: Defesa.

O único serviço que eu (intencionalmente) tenho a correr é o SSH. Como o SSH serve de túnel encriptado para praticamente tudo o resto, não vejo necessidade de ter outros serviços a correr. Principalmente agora, que há muitas ferramentas porreiras para que todos os sistemas (incluindo MS Windows) possam aceder a um servidor SSH, como por exemplo o Putty (que até tem uma versão para Pocket PC!) e o WinSCP, e claro, o cliente X mais “light” e simples que conheço, o Xming.

Ora, um serviço SSH é um alvo muito apetecível na Internet, já que pode dar o controlo total da máquina se for comprometido. Dado que existem grandes quantidades de computadores a “varrer” continuamente a Internet à procura de SSHs abertos, desde o princípio que adoptei uma estratégia de minimização do risco:

  1. Esconder a máquina do mundo, evitando responder aos “pings” (ICMP). Isto pode ser feito tanto nas opções de configuração dos routers/wifi/modems que quase toda a gente tem em casa hoje em dia, e/ou através das regras de firewall da própria máquina. Logo aqui o número de ataques baixa drasticamente, pois a maioria deles é descontinuada logo no início.
  2. Desviar o porto SSH para um número não-standard, em vez do esperado 22. Novamente o número de ataques reduz drasticamente, pois haverá alvos mais fáceis de localizar com configurações standard. De notar que até agora, estas duas medidas praticamente anularam os ataques SSH sofridos pela minha máquina.
  3. No entanto, como dizem nuestros hermanos españoles: “No creo en brujas; pero que las hay, las hay!”🙂 Existe sempre a possibilidade de algum atacante mais esperto descobrir o porto activo do servidor (não é difícil, existem ferramentas potentes para fazer isso, como por exemplo o “nmap“) e tentar arrombar o acesso através dum ataque de força bruta. Por isso há que desabilitar o login com base em passwords, aceitando apenas logins seguros com chave criptográfica. Ah, e evidentemente também se desactiva o acesso remoto à conta “root”, embora isto seja apenas uma mera medida de atraso ao atacante. Ver a documentação do sshd para saber como configurar isto, e também ver como gerar as chaves necessárias (tanto para o servidor como para os clientes). Tanto quanto sei, e ao cabo de cerca de 3 anos exposta à internet 24h por dia, esta máquina nunca foi comprometida, o que me dá alguma confiança nestas medidas.

Portanto, a coisa agora está segura, não?… …NÃO!

Ainda existe a possibilidade de o serviço SSH (ou mesmo qualquer outra parte da pilha protocolar de rede do sistema operativo) conter vulnerabilidades exploráveis remotamente, mesmo que não seja possível ao atacante fazer um login inicial. Aqui já entramos no reino das baixas probabilidades, mas um atacante que consiga chegar a este ponto pode ser considerado alguém muito perigoso, e como tal não o queremos a remexer os nossos dados, certo?

Então vamos lá.

Numa primeira abordagem, pode-se usar técnicas de lista negra, ou seja, instalar ferramentas que analisam o tráfego à procura de ataques e respondem aos mesmos inserindo os endereços IP dos atacantes na lista negra do sistema operativo ou nas regras da firewall. Aqui experimentei:

  1. denyhosts” – procura ataques SSH no ficheiro de registo do SSH daemon e insere os IPs ofensivos no ficheiro “/etc/hosts.deny”. Até agora, não tive problemas com ele, nem de falsos positivos, nem de falsos negativos. No entanto, o filtro é muito básico, e como tal, um pouco perigoso… pode ser usado por alguém para “denial of service”, se se simular um ataque com um endereço IP falso (“spoofed”), possivelmente trancando o acesso a utilizadores legítimos.
  2. psad” – procura ataques de muitas naturezas diferentes (não apenas SSH) através da análise contínua do ficheiro de registo da firewall iptables, e insere regras nela para eliminar o acesso aos atacantes. Acabei de instalar há poucos dias, ainda estou a ver como vai. Mas cobre mais ameaças que o denyhosts, e como tal já é o meu favorito.

Ambas as ferramentas são fáceis de instalar e configurar em Linux. E ambas podem produzir relatórios detalhados dos ataques, o que pode ser interessante, tanto para nós termos uma noção mais realista daquilo que se passa à nossa volta, como também para o contra-ataque… 😉

Uma outra tendência que está a ganhar volume é a técnica de “Single Packet Authorization“. Esta técnica promete revolucionar a segurança dos servidores na net, pois permite tornar um servidor 100% invisível e praticamente inexpugnável à maioria dos ataques. Consiste na rejeição total de todos os pacotes IP, a não ser que um primeiro pacote criptográfico seja enviado para estabelecer a ligação. Dado que todos os pacotes sem ligação prévia são descartados (incluindo ICMP), nem sequer o nmap é capaz de analisar uma máquina protegida por SPA. E como bónus, mesmo que alguma parte do sistema operativo contenha um “buraco” explorável remotamente, isso é irrelevante, pois os pacotes nunca chegam ao destino.

  1. Uma ferramenta que implementa SPA num servidor é o “fwknop“, que ainda hei-de experimentar um dia destes. Tenho é a dúvida sobre que tipo de clientes se podem usar com ele…

Passo 2: contra-ataque!

Pegando no output das análises feitas pelas ferramentas de defesa, é possível alimentar web sites que centralizam esta informação, como por exemplo o denyhosts.net ou o dshield.org, que depois compilam, organizam, publicam, e disseminam esta informação.

  1. A ferramenta “denyhosts” pode ser configurada para aceder ao “denyhosts.net”, tanto para relatar os ataques sofridos e colaborar nas estatísticas, como para “aprender” endereços de atacantes que ainda não tentaram aceder ao nosso sistema (mas já atacaram outros). Nota pessoal: se o risco de “denial-of-service” era possível correndo autonomamente, então o risco de uma “pandemia” de acessos recusados causada pelo sistema distribuído é ainda maior…
  2. A ferramenta “psad” pode ser configurada para alimentar o dshield.org, que é uma organização com operadores humanos em serviço 24H por dia. Estes operadores analisam os resultados e comunicam com as entidades pertinentes (ISPs inclusivé) caso seja necessário. No entanto, parece-me que eles não se vão mexer por pequenos ataques localizados. Portanto, para nos protegermos pessoalmente, há que subscrever o serviço gratuito deles “fightback“, que implica que todo e qualquer ataque por nós sofrido (e relatado automaticamente pela nossa máquina) irá ser tratado com a seriedade e urgência necessárias.

Usando estas capacidades de relatório automático, podemos ajudar as entidades que gerem a internet e as forças policiais a encontrar a origem dos ataques cibernéticos, eliminando o problema na origem.

Enjoy!🙂

~ por Vasco Névoa em Fevereiro 8, 2008.

Uma resposta to “A melhor defesa é um bom ataque!”

  1. Obrigado pelas dicas. A ver se implemento algumas destas sugestões na minha workstation lá do trabalho (não vá o diabo tentar aceder à minha máquina).

Deixe uma Resposta

Preencha os seus detalhes abaixo ou clique num ícone para iniciar sessão:

Logótipo da WordPress.com

Está a comentar usando a sua conta WordPress.com Terminar Sessão / Alterar )

Imagem do Twitter

Está a comentar usando a sua conta Twitter Terminar Sessão / Alterar )

Facebook photo

Está a comentar usando a sua conta Facebook Terminar Sessão / Alterar )

Google+ photo

Está a comentar usando a sua conta Google+ Terminar Sessão / Alterar )

Connecting to %s

 
%d bloggers like this: