Uma palavra sobre segurança

O mais problemático em relação à segurança no LTSP são justamente os ataques locais, feitos pelos próprios usuários. Originalmente, um usuário comum não deve conseguir alterar arquivos fora do seu diretório home, nem alterar as configurações do sistema, mas eventualmente podem existir vulnerabilidades locais, que podem ser exploradas para obter privilégios adicionais.

Essas vulnerabilidades locais são muito mais comuns que vulnerabilidades remotas, já que é muito mais difícil proteger o sistema de um usuário que está logado e tem acesso a vários aplicativos, do que de um usuário remoto que precisa passar pelo firewall e encontrar algum serviço vulnerável escutando conexões.

Um exemplo rápido de como isso funciona: imagine que, por descuido, você usou no terminal (como root) o comando “chmod +s /usr/bin/mcedit”. O “chmod +s” ativa o SUID para o mcedit, o que faz com que ele seja sempre executado pelo root. Um usuário que percebesse isso, poderia usar o mcedit para editar o arquivo “/etc/passwd” e modificar a linha referente a seu login para:

joaozinho:x:0:0:joaozinho:/home/joaozinho:/bin/bash

Com o SUID ativado, o medit passaria a ser sempre executado com permissão de root. Isso permitiria que o joaozinho o usasse para editar arquivos que originalmente apenas o root poderia editar. Modificando os campos do UID e GID dentro do “/etc/passwd” para “0”, joaozinho faz com que seu login ganhe poderes de root. A partir daí ele pode fazer o que quiser no sistema.

Esse é um exemplo exagerado, que mostra como pequenos erros podem abrir brechas graves, que não podem ser exploradas remotamente, mas que podem ser facilmente exploradas por usuários locais.

Um tipo de ataque grave e relativamente comum são os famosos rootkits, softwares que exploram um conjunto de vulnerabilidades conhecidas para tentar obter privilégios de root na máquina afetada. Existem vários rootkits que podem ser baixados da Net, variando em nível de eficiência e atualização.

Os rootkits podem ser instalados tanto localmente (quando alguém tem acesso físico à sua máquina) quanto remotamente, caso o intruso tenha acesso via SSH, VNC, XDMCP (usado pelo LTSP) ou qualquer outra forma de acesso remoto. Nesse caso, ele precisará primeiro descobrir a senha de algum dos usuários do sistema para poder fazer login e instalar o programa. A partir do momento que é possível logar na máquina, o atacante executa o rootkit para tentar obter privilégios de root.

Uma vez instalado, o rootkit vai alterar binários do sistema, instalar novos módulos no Kernel e alterar o comportamento do sistema de várias formas para que não seja facilmente detectável. O processo do rootkit não aparecerá ao rodar o “ps -aux”, o módulo que ele inseriu no Kernel para alterar o comportamento do sistema não vai aparecer ao rodar o “lsmod” e assim por diante.

Aparentemente vai estar tudo normal, você vai poder continuar usando a máquina normalmente, mas existirão outras pessoas com acesso irrestrito a ela, que poderão usá-la remotamente da forma que quiserem.

Naturalmente também existem programas capazes de detectar rootkits. Um dos mais populares é o chkrootkit, que pode ser encontrado no: http://www.chkrootkit.org/.

No site está disponível apenas o pacote com o código fonte, que você precisa compilar manualmente, mas ele é um programa bastante popular e vem incluso na maior parte das distribuições. No Debian, Kurumin ou derivados, você pode instalá-lo pelo apt-get:

# apt-get install chkrootkit

Ele pergunta se deve ser executado automaticamente todos os dias, através do cron. Isso garante uma proteção adicional, pois ele avisa caso futuramente a máquina seja comprometida.

Para executar o chkrootkit, basta chamá-lo no terminal:

# chkrootkit

Ele exibe um longo relatório, mostrando um por um os arquivos checados. Em uma máquina saudável, todos retornarão um “nothing found”:

Searching for Ramen Worm files and dirs… nothing found
Searching for Maniac files and dirs… nothing found
Searching for RK17 files and dirs… nothing found
Searching for Ducoci rootkit… nothing found
Searching for Adore Worm… nothing found
Searching for ShitC Worm… nothing found
Searching for Omega Worm… nothing found
…

Uma parte importante é a checagem das interfaces de rede, que aparece no final do relatório:

Checking `sniffer’… lo: not promisc and no packet sniffer sockets
eth0: not promisc and no packet sniffer sockets

Os sniffers são usados para monitorar o tráfego da rede e, assim, obter senhas e outras informações não apenas do servidor infectado, mas também de outras máquinas da rede local. Um dos sintomas de que existe algum sniffer ativo é a placa da rede estar em modo promíscuo, onde são recebidos também pacotes destinados a outros micros da rede local.

Alguns programas, como o VMware, o Ethereal e o Nessus colocam a rede em modo promíscuo ao serem abertos, mas caso isso aconteça sem que você tenha instalado nenhum destes programas, é possível que outra pessoa o tenha feito.

Instale o chkrootkit logo depois de configurar o sistema e execute o teste regularmente. Ele é capaz de detectar a maioria das intrusões de usuários locais, permitindo que você tenha uma certa segurança. Caso seja detectada uma intrusão, o ideal é desconectar o servidor da rede, fazer um backup dos dados de todos os usuários e reinstalar o sistema do zero, depois de enforcar e esquartejar o usuário “esperto” naturalmente ;).

Essas precauções não são necessárias se seus usuários são todas pessoas cultas e integras, interessadas no bem comum (sarcástico). Mas, como não vivemos em um mundo ideal, o melhor é tomar as precauções necessárias e tentar estar sempre um passo a frente.