Estou preparando um treinamento de hardening para servidores Linux e ambientes Web, falo de Apache, Nginx, DNSs e mais algumas coisitas. Devido a isso, venho pesquisando uma série de papers, livros e afins atrás de algo relevante. Me deparo com configurações quase que iguais em todos os casos, e no final, o que mais me intriga é que os autores esquecem de falar sobre o básico.

Estou me referindo ao controle de usuários, grupos e permissões configurados em servidores Linux. Este sistema operacional possui ferramentas e alguns atributos fantásticos já “instalados de fábrica onde não é necessário a implementação de muitos patches, em alguns casos, é claro.

Vejam o exemplo do comando chattr e do lsattr – um é para mudar os atributos de um arquivo e o outro para visualizá-lo. Vocês sabiam que a alteração de um atributo de um arquivo com este comando, o chattr, é capaz de bloquear a sua modificação ou apaga-lo até mesmo pelo root ?

Em alguns servidores Web, a sua utilização é mais do que obrigatória em arquivos ou diretórios que contenham dados críticos como senhas e acesso à banco de dados. Sendo assim, ninguém poderá alterá-los ou remove-los, por exemplo, isso inclui root.

Outro ponto que muita gente que trabalha com administração de servidores Linux esquece é de dar um find por arquivos e diretórios que possuam stick bit, setGUID e setUID, as permissões especiais tão faladas e tão confundidas – 1000, 2000 e 4000, não respectivamente.

Rodar um find do tipo:

find / \( -perm -4000 -fprintf /root/suid.txt '%#m %u %p\n' \), 
\ \( -size +100M -fprintf /root/big.txt '%-10s %p\n' \) ou find * -perm 4755

é importante para saber o que há de podre no reino da Dinamarca, quer dizer, em seu servidores Linux.

Isso sem falar em parar os serviços que não sejam essenciais para o funcionamento de seu ambiente, também como remover as permissões de execução de comandos, leitura e gravação de arquivos e diretórios que só deverão ser utilizados por root como make, gcc, restart, shutdown, /etc/shadown e tantos outros.

Scripts como o abaixo (parte dele) ajudam e muito nesta tarefa:

 find / \( -perm -4000 -o -perm -2000 \) -mount -type f -print > /tmp/suids sed -e '/\/sbin\/pwdb_chkpwd/ d' \ -e '/\/sbin\/unix_chkpwd/ d'\ -e '/\/sbin\/pam_timestamp_check/ d'\ -e '/\/bin\/su/ d'\ -e '/\/usr\/bin\/passwd/ d'\ -e '/\/usr\/bin\/sudo/ d'\ -e '/\/usr\/bin\/crontab/ d'\ /tmp/suids > /tmp/suids2 for arquivo in $(cat /tmp/suids2); do chmod -s $arquivo done rm /tmp/suids /tmp/suids2 # Mundando a permissão dos compiladores chmod go-rwx /usr/bin/gcc chmod go-rwx /usr/bin/cc # Parando os serviços desnecessários service gpm stop service apmd stop service atd stop service xinetd stop service sendmail stop service cups stop # Retirando do startup os serviços desnecessários chkconfig --level 12345 cups off chkconfig --level 12345 sendmail off chkconfig --level 12345 xinetd off chkconfig --level 12345 gpm off chkconfig --level 12345 apmd off chkconfig --level 12345 atd off 

 

Por que tem administrador que possui um usuário no Liux que a sua senha nunca expira ? Vocês já se perguntaram isso ? Então pare com essa porra e coloque uma data de expiração máxima de 2 meses para senha de usuários que administrem os seus servidores e um detalhe, com mais de 8 caracteres, que não possam se repetir e utilizando  a mesma ladainha, mas que adianta, de maiúsculas e minúsculas, caracteres especiais e alfa-númericas.

Cuidado com a configuração do /bin/vi no /etc/sudoers — isso é uma puta armadilha 🙂

A monitoração quanto a integridade, criação, modificação ou deleção de qualquer coisa em Linux é um dos pontos mais importantes, e para isso não é necessário instalar trocentos sistemas, programas ou daemons, mas sim, utilizar finds e tantos outros comandos em sua crontab que possam enviá-los e-mails de 5 em 5 minutos, por exemplo, com relatórios.

Outro ponto importante é já muito comentado por aqui, antes de sair copiando e colando os parâmetros de hardening indicados por alguém, pare, analise-os e pesquisa. Quer testar antes de colocar em produção ? Perfeito, crie um ambiente de testes, é para isso que serve a virtualização, e o mais importante, verifique se estas configurações não ferrarão com o que já está rodando.

E por último : O diabo está nos detalhes, então, fique atento com o que você faz no seu ambiente.

Falaremos mais sobre isso no curso de hardening que ministraremos e no hackingday – então não percam…

Compartilhar:

Este post tem 3 comentários

  1. Como você mencionou no inicio do seu texto, o que acaba confundindo e atrasando o iniciante em hardening é o fato de toda documentação disponível tanto na web quanto em livros serem voltadas para quem já tem uma noção desse básico que engloba permissões, tempo de duraçao de senhas. Essas coisas aprendemos na unha e geralmente somente aprendemos quando passamos por algum perrengue…

    Infelizmente não poderei ir nesse hackingday, mas espero que você leve esse curso de hardening para outros eventos.

    Até mais XD

  2. “utilizar finds e tantos outros comandos em sua crontab que possam enviá-los e-mails de 5 em 5 minutos, por exemplo, com relatórios.”

    Fazer isso em um servidor com 12 milhões de arquivos!? Acho que não.

  3. Bom, aí é outro problema e uma outra solução — neste caso, eu acredito que seja tudo imagem.. Que tal cache, um varnish na frente.. ?

Deixe uma resposta

Fechar Menu