Product SiteDocumentation Site

10.5. Idéias Geniais/Paranóicas — o que você pode fazer

Esta é provavelmente a mais instável e divertida seção, apenas espero que algumas das ideias "duh, isso parece loucura" possam ser realizadas. A seguir algumas idéias para melhorar a segurança — talvez geniais, paranóicas, loucas ou até inspiradas dependendo do seu ponto de vista.
  • Brincando com o PAM. Como citado no artigo Phrack 56 PAM, a coisa legal do PAM é que "Você é limitado somente pelo o que pode imaginar". É verdade. Imagine efetuar login de root somente através de impressão digital ou verificação de retina ou cartão de criptografia (por que usei a conjunção OU em vez de E?).
  • Gravação fascista de logs. Eu prefiro me referir à toda discussão anterior acima como um "esquema leve de logs". Se você quiser fazer um esquema real de logs, pegue uma impressora com papel de formulário contínuo, e envie todos os logs para ela. Parece engraçado, mas é realmente confiável e as informações não podem ser sobrescritas ou apagadas.
  • Distribuição de CD. Essa idéia é muito simples de se realizar e oferece uma boa segurança. Crie uma distribuição Debian segura, com as regras de firewall apropriadas. Coloque ela em uma imagem ISO inicializável e grave em um CDROM. Agora você tem uma distribuição somente leitura, com mais ou menos 600 MB de espaço para os serviços. Tenha certeza de que todos os dados que devem ser escritos sejam feitos pela rede. É impossível para um intruso ter acesso de leitura/escrita no sistema, e qualquer alteração feita pelo intruso pode ser desfeita em uma reinicilização do sistema.
  • Desabilite a capacidade de carregar módulos. Como discutido anteriormente, quando você desabilita o uso de módulos em tempo de compilação do kernel, muitos backdoors baseados em kernel ficam impossíveis de serem implementados, pois a maioria deles é baseada na instalação de módulos do kernel modificados.
  • Grave os logs por um cabo serial. (contribuido por Gaby Schilders) Já que os servidores ainda têm portas serial, imagine ter um sistema de gravação de logs para um série de servidores. O sistema de logs é desconectado da rede, e conectado aos servidores via um multiplexador de porta serial (Cyclades ou algo do tipo). Agora faça com que todos os seus servidores gravem o log através da porta serial. A máquina de log vai somente aceitar o texto plano como entrada nas portas serial e escrever em um arquivo de log. Conecte um gravador de CD/DVD e grave o arquivo de log quando atingir a capacidade máxima da mídia.
  • Altere as atribuições do arquivo usando chattr. (dica tirada do Tips-HOWTO, escrito por Jim Dennis). Depois de uma instalação limpa e configuração inicial, use o programa chattr com o atributo +i para que os arquivos não sejam modificados (o arquivo não pode ser apagado, renomeado, criado link ou escrito algo nele). Defina este atributo em todos os arquivos que estão em /bin, /sbin/, /usr/bin, /usr/sbin, /usr/lib e também nos arquivos do kernel no root. Você também pode fazer uma cópia de todos os arquivos do /etc/, usando o tar ou algo do tipo e marcar o arquivo comprimido como imutável.
    Esta estratégia irá ajudar a limitar o estrago que você poderá causar estando logado como root. Você não poderá sobrescrever arquivos por engano, nem deixar o sistema inoperante digitando por engano um espaço no comando rm -fr (você pode ainda fazer um monte de estragos no seus dados — mas suas bibliotecas e seus binários estarão seguros.)
    Esta estratégia também faz com que uma variedade de exploits de segurança e de negação de serviços (DoS) sejam difíceis ou impossíveis de serem realizados (já que a maioria deles conta com a permissão de sobrescrever um arquivo através de algum programa SETUID que a princípio não esteja fornecendo um comando shell arbitrário).
    Uma inconveniência desse tipo de estratégia aparece durante a compilação e instalação de alguns binários do sistema. Por outro lado, isso previne que um comando make install sobrescreva os arquivos. Quando você se esquece de ler o Makefile e executa um chattr -i nos arquivos a serem sobrescritos, (também nos diretórios nos quais serão adicionados os arquivos) ‐ o comando make falha. Então você deve usar o comando chattr para desativar a flag de imutável e rodar o make novamente. Você também pode optar por mover os binários e as bibliotecas antigas para dentro de um diretório .old/ ou para um arquivo tar por exemplo.
    Note que esta estratégia também impede que você atualize seu próprio sistema de pacotes, já que os arquivos que os pacotes a serem atualizados fornecem não podem ser sobrescritos. Você pode fazer um script ou usar outro mecanismo parecido para desativar a permissão de imutável em todos os binários antes de fazer um apt-get update.
  • Você pode brincar um pouco com o cabeamento UTP cortando 2 ou 4 fios, tornando um cabo de tráfego unidirecional. Então use pacotes UDP para enviar informação para uma máquina de destino que atuaria como um servidor de log seguro ou até mesmo um sistema de armazenamento de cartões de crédito.

10.5.1. Construindo um honeypot

Um honeypot é um sistema feito para auxiliar os administradores de sistemas a descobrir como os crackers sondam a máquina em busca de exploits. O sistema é configurado com a expectativa e objetivo de ser sondado, atacado e potencialmente invadido. Aprendendo as ferramentas e os métodos empregados pelo cracker, um administrador de sistema pode saber como melhor proteger seus sistemas e a rede.
Um sistema Debian GNU/Linux pode ser facilmente configurado como um honeypot, se você dedicar tempo para implementar e monitorá-lo. Simplesmente configure o servidor falso com um firewall e algumas ferramentas de detecção de intrusão de rede, coloque ele na Internet, e espere. Tome o cuidado de que se o sistema for invadido você seja imediatamente alertado (veja Seção 4.13, “A importância dos logs e alertas”), desta forma você poderá tomar providências necessárias e paralizar a invasão quando tiver informações suficientes. Abaixo estão alguns dos pacotes e questões importantes quando estiver configurando seu honeypot:
  • A tecnologia de firewall que irá usar (fornecidade pelo kernel do Linux).
  • syslog-ng, useful for sending logs from the honeypot to a remote syslog server.
  • snort, to set up capture of all the incoming network traffic to the honeypot and detect the attacks.
  • osh, a SETUID root, security enhanced, restricted shell with logging (see Lance Spitzner's article below).
  • Of course, all the daemons you will be using for your fake server honeypot. Depending on what type of attacker you want to analyse you will or will not harden the honeypot and keep it up to date with security patches.
  • Integrity checkers (see Seção 4.17.3, “Verificando a integridade do sistema de arquivos”) and The Coroner's Toolkit (tct) to do post-attack audits.
  • honeyd and farpd to setup a honeypot that will listen to connections to unused IP addresses and forward them to scripts simulating live services. Also check out iisemulator.
  • tinyhoneypot to setup a simple honeypot server with fake services.
If you cannot use spare systems to build up the honeypots and the network systems to protect and control it you can use the virtualisation technology available in xen or uml (User-Mode-Linux). If you take this route you will need to patch your kernel with either kernel-patch-xen or kernel-patch-uml.
You can read more about building honeypots in Lanze Spitzner's excellent article http://www.net-security.org/text/articles/spitzner/honeypot.shtml (from the Know your Enemy series). Also, the http://project.honeynet.org/ provides valuable information about building honeypots and auditing the attacks made on them.