Como fazer: Chroot Ssh (Ssh mais seguro)
--------------------------------------------------------------------------------
Antes de qualquer coisa vale lembrar que este texto existe como um esforço da comunidade linux em ajudar os usuários menos experientes (e também os veteranos) a resolver rapidamente os problemas encontrados na implementação de soluções baseadas em linux.
É MUITO IMPORTANTE estar ciente de que as instruções contidas neste texto são baseadas em observações particulares minhas e PODEM DESTRUIR SEU COMPUTADOR, SUA VIDA, SUA MENTE E OUTRAS COISAS MAIS, de forma que você foi avisado e não tenho NENHUMA RESPONSABILIDADE pelos prejuizos que você possa sofrer ao utilizar as informações contidas neste "Como fazer". Se fizer, o faça por sua conta e risco. Algumas pessoas reclamaram que em outros artigos eu escrevi "não venha me encher o saco se alguma coisa der errado", então dessa vez serei mais sutil: "seja homem, se alguma coisa der errado, assuma o prejuizo, não ponha a culpa em terceiros".
As pessoas de bom senso podem ficar a vontade para me contactar se precisarem de alguma ajuda na configuração do que será mostrado abaixo.
Todas as marcas citadas no texto são propriedade dos seus respectivos donos (não sou dono de nada).
Pode copiar este texto a vontade, pode publicar onde quiser, desde que mantida a integridade do texto, traduções são permitidas e incentivadas, desde que mantida a integridade do texto, não se esqueça de colocar uma nota dizendo que você traduziu.
Seja gentil e me avise se este material lhe for util.
Hamilton R. Amorim (algorista @ yahoo . com . br)
--------------------------------------------------------------------------------
Escrevi anteriormente um tutorial (how-to, como fazer) que explica como configurar um ambiente para o dosemu onde o usuário não tem acesso ao sistema de arquivos do servidor linux, assim protegendo a integridade do sistema. Aquele tutorial foi escrito embasado em uma experiência real onde precisei montar um servidor de aplicações para um ERP escrito em clipper. Naquele momento foi necessário criar um servidor que fosse o mais seguro o possível, e que fornecesse o minimo de acesso aos usuários, pois sempre tem algum espertinho que pega as receitinhas de bolo na internet e se acha "o hacker".
Recentemente algumas pessoas me contactaram e pediram um tutorial de como fazer esse mesmo trabalho sem o dosemu, só com o ssh. Me parece algo estranhamente simples, esse tutorial será quase igual ao outro, só com menos coisas a fazer.
--------------------------------------------------------------------------------
Este tutorial explica como configurar um ambiente para o servidor sshd de forma que o usuário só tenha acesso a seu diretório home, e tenha o minimo de comandos disponíveis, só o necessário para executar suas tarefas, assim incrementando a segurança.
REQUISITOS
Todo esse trabalho de configuração está baseado em uma maquina com RedHat 7.3 com uma instalação do tipo "servidor", tudo padrão, sem nada de especial, pouca coisa muda para outras distribuições. Nesta instalação tem praticamente tudo que um servidor pode ter, todos os comandos de shell e todos os serviços, quase uma instalação full, só não tem o ambiente gráfico.
Vamos trabalhar com um usuário chamado "teste", então crie este usuário da forma mais "default" o possível:
useradd teste
passwd teste
Desta forma temos uma pasta em /home/teste onde faremos todo o trabalho.
CRIANDO A RAIZ
A primeira coisa a fazer é criar uma raiz de diretórios e arquivos que no final será a raiz visivel para o usuário "teste". Abaixo do diretório /home/teste crie as seguintes pastas:
/bin
/dev
/etc
/home
/home/teste2
/lib
/sbin
/tmp
/usr
/usr/sbin (link simbolico para sbin)
/usr/bin (link simbolico para bin)
/usr/share
Todas essas pastas estão abaixo da pasta /home/teste, não se esqueça disso, os links em /usr/bin e /usr/sbin também apontam para essas pastas "internas" do usuário teste. Cuidado para não apontar esses links para as pastas "reais" na raiz do linux, no final deste tutorial o usuário teste não terá mais acesso a raiz real do linux, só vai enchergar essa raiz falsa.
Nesta próxima etapa nós vamos copiar os comandos de shell que o usuário teste vai utilizar e as libs relacionadas a esses comandos. Vamos fornecer apenas um minimo para o usuário navegar no sistema, editar um arquivo e nada mais.
Copie os seguintes arquivos de suas origens reais para suas respectivas pastas dentro do /home/teste:
/bin
bash
id
cat
clear
cp
du
grep
less
ls
mv
mkdir
rmdir
rm
sh -> bash (link simbolico para arquivo bash)
su (não copie esse ainda)
pico (um editor de textos, não precisa copiar)
vi (mais um editor de textos)
/dev
null (não copie, crie um link real)
/etc
bashrc (não é realmente necessário)
group (não copie ainda)
passwd (não copie ainda)
/lib
ld-2.2.5.so
ld-linux.so.2 -> ld-2.2.5.so (link simbolico)
libc-2.2.5.so
libcrypt.so.1
libc.so.6 -> libc-2.2.5.so (link simbolico)
libdl-2.2.5.so
libdl.so.2 -> libdl-2.2.5.so (link simbolico)
libncurses.so.5
libnsl.so.1
libnss_compat.so.2
libnss_files.so.2
libpam_misc.so.0
libpam.so.0
libtermcap.so.2 -> libtermcap.so.2.0.8 (link simbolico)
libtermcap.so.2.0.8
/usr/share
terminfo/ (pasta, copie inteira)
/home/teste
.bash_history (mover do /home/teste original)
.bash_logout (idem)
.bash_profile (idem)
.bashrc (idem)
Essa lista de arquivos foi montada da seguinte forma, copiei os arquivos dos "comandos de shell" e com o comando ldd eu descobri as libs necessárias para o funcionamento dos comandos. O comando ldd não lista tudo, então fui executando os comandos e vendo o que ainda faltava, assim montei a lista de libs. Tem ainda alguns arquivos que merecem um cuidado especial, veja os detalhes de cada um deles:
Links simbolicos : Aqueles criados com comando "ln -s arq-origem"
/bin/su : este arquivo é um problema, o su que vem com o RedHat73
está linkado com as libs de pam e não servem para nossa necessidade.
Precisamos uma versão mais simplificada. O ideal é baixar o
pacote sh-utils em
ftp://alpha.gnu.org/gnu/coreutils/sh...-2.0.15.tar.gz
e compilar (simples: "tar ...; cd ...; ./configure; make"),
pegue o arquivo src/su, este funciona perfeito.
Se tiver algum problema em compilar pegue este "su" precompilado: aqui.
/dev/null : crie um link real que tudo funciona bem.
Você consegue sobreviver sem esse arquivo, então não precisa copiar se não quiser.
/etc/group : crie um arquivo só com as duas linhas do root e do seu usuário,
no meu caso é o usuário "teste".
meu arquivo ficou assim: (sem o ascii-art tosco, é claro)
/--------------\
|root:x:0:root |
|teste:x:515: |
\--------------/
/etc/passwd : O mesmo caso, crie um arquivo só com as duas linhas que interessam.
/---------------------------------------\
|root:x:0:0:root:/root:/bin/bash |
|teste:x:515:515::/home/teste:/bin/bash |
\---------------------------------------/
/usr/share/terminfo : Nesta pasta tem as informações para seu terminal remoto,
necessário para o comando less. Se não precisa do less, não precisa disso.
Obs: cuidado com o Uid e Gid nos arquivos passwd e group, se você errar qualquer desses números o seu usuário vai ficar recebendo erros de acesso a pasta home quando for conectar.
PERMISSÕES DOS ARQUIVOS
É importante estar atendo as permissões destas pastas e arquivos, tire todas as permissões de escrita, deixe tudo como sendo propriedade do usuário root. Dê acesso de leitura e execução a tudo isso e só deixe escrever na pasta /home/teste
Mesmo com tudo isso feito ainda é possível ao usuário escrever em sua raiz ("/") pois a raiz é na verdade o seu /home/teste original, para resolver esse problema retire a permissão de escrita da pasta /home/teste original (chmod u-w /home/teste).
Outro detalhe, jamais coloque o comando chmod nesta arvore, se você colocar um chmod o usuário poderá simplesmente entrar pelo ftp e fazer o upload dos programas que quiser, mudar os atributos dos arquivos e executar quando quiser, assim sua segurança vai pelo ralo.
Certifique-se de que seu servidor de ftp tem desabilitado a opção de chmod.
O servidor wu-ftpd desta distribuição (RedHat73) já vem com o chmod desabilitado. Se você tem duvida quanto a esta configuração, basta fazer um teste, ou melhor seria aprender a configurar seu servidor de ftp.
Aqui acaba a configuração do userspace, agora vamos efetuar as configurações globais no servidor.
CONFIGURANDO O LINUX
Daqui pra frente as configurações devem ser efetuadas no "linux mesmo", estas alterações de arquivos devem ser feitas no sistema de arquivos real.
A configuração do linux fica por conta de alterar a shell do usuário "teste" de forma a acessar uma shell alternativa que colocará sua seção em uma "chain root", essa cela que impedirá o usuário de enxergar o sistema de arquivos real, vendo apenas nosso "pseudo sistema de arquivos".
Primeira coisa a fazer: crie um shell script em /bin com as seguintes linhas (menos o ascii-art tosco):
/---------------------------------------------------------------\
| ARQUIVO: /bin/chroot-shell |
|---------------------------------------------------------------|
|#!/bin/bash |
|/usr/bin/sudo /usr/sbin/chroot /home/$USER /bin/su - $USER |
|---------------------------------------------------------------/
Acerte a permissão deste arquivo (eu sempre esqueço isso, hehehe):
chmod ugo+x /bin/chroot-shell
Altere o shell do usuário em /etc/passwd para apontar para essa nova shell:
teste:x:515:515::/home/teste:/bin/chroot-shell
É necessário acertar as permissões de sudo para o usuário "teste". Para isso edite o arquivo /etc/sudoers adicionando a linha abaixo (sem o ascii tosco, hehehe):
/------------------------------------------------------------------------\
|teste ALL= NOPASSWD: /usr/sbin/chroot /home/teste /bin/su - teste* |
|------------------------------------------------------------------------/
Tem que fazer isso com todos os seus usuários, uma linha para cada, não é nenhum martírio, só uma linha para cada usuário.
Não precisa nem dizer que pra alterar esses arquivos você precisa estar logado como root né.
Está pronto, agora é só logar como teste e navegar pela máquina, logo perceberá que está "preso" em nossa pseudo-arvore, sem nenhuma chance de acessar o sistema de arquivos real.
Suas oportunidades de executar comandos estão limitados aos programas em /bin e em /sbin, com isso não dá pra fazer muita coisa na maquina, sem gcc, sem make, e sem chmod você fica com as mãos atadas.
É preciso validar isso, não fiz muitas tentativas de furar a segurança, mas com certeza alguém cheio de disposição o fará por nós e dirá se essa solução é segura mesmo, hehehe.
--------------------------------------------------------------------------------
Espero que este documento contribua para a sua solução ou estudo, em caso de dúvida entre em contato que ficarei grato em poder ajudar. Estou disponível para trabalhos de consultoria em linux, precisando entre em contato.
Não se esqueça que este documento é gratuito e pode ser distribuido e publicado em outros sites a vontade, também pode e deve ser traduzido para outros idiomas. Se você considerar que este documento está incorreto ou que pode ser melhorado fale comigo que poderemos melhorá-lo juntos, ou se preferir escreva um outro "Como fazer" baseado neste, o importante é contribuir para a comunidade linux crescer.
Hamilton R. Amorim (algorista @ yahoo . com . br)
20031009
09-out-2003
