É seguro revogar o outro acesso a todos os diretórios em um sistema de arquivos?

Question

Eu estou tentando proteger uma conta em nosso servidor chamada ssh_user que é usada apenas para conectar via SSH ao nosso servidor. Todos na nossa equipe fazem login nesta conta por meio de uma conexão ssh segura do PSK e túneis para uma porta específica do nosso sistema de controle de versão. A segurança é mantida por todos com seu próprio PSK no arquivo / etc / ssh / ssh_user / authorized_users

A conta ssh_user foi criada com o sudo adduser -r -s / bin / sh ssh_user para tornar o usuário uma conta do sistema, sem diretório inicial e com o limite de shell possível.

Embora esses usuários já sejam confiáveis, a preocupação é sempre saber de que acesso essa conta realmente precisa, porque ainda posso listar diretórios no sistema de arquivos raiz por meio dessa conta e ler arquivos de configuração em / etc / ssh / .. ., então eu estou querendo saber se esse problema é tão fácil como emitir revogando todo o acesso ao grupo "outros" em todo o sistema de arquivos com o sudo chmod go-rwx / * ? Eu não sei o que (se alguma coisa) isso iria quebrar em uma instalação padrão do Ubuntu 16.04.

Não sou de forma alguma um especialista em linux ou segurança, e não estou tentando fingir que sei o que estou fazendo, portanto, qualquer contribuição é muito apreciada.

Obrigado!

    

Answer 1

Repita depois de mim: Executar QUALQUER comando de permissão em / sem saber exatamente o que você está fazendo é uma ótima maneira de quebrar seu sistema. Mesmo se você souber o que você está fazendo, ainda é provavelmente a coisa errada a se fazer.

No seu caso, o comando não funcionará porque é o errado para começar. Em segundo lugar, os grupos são uma construção de usuários do Linux muito válida, e impedir que os grupos acessem arquivos é realmente uma péssima idéia.

Se eu estou entendendo o seu caso corretamente, você quer bloquear usuários de recursos que eles não estão autorizados a ler. Felizmente para você, existem algumas maneiras de fazer isso, cada uma com trocas.

Opção 1: sem casca de todo (melhor caminho)

Você está usando o SSH para permitir que os usuários se conectem em um servidor seguro, certo? Por que os usuários até precisam de um shell neste caso? Basta bloquear o acesso deles ao shell e somente deixá-los túnel !

Para fazer isso, basta criar um novo grupo chamado noaccess ou similar. Em seguida, copie e cole o arquivo abaixo em /etc/ssh/sshd_config :

Match Group noaccess
    AllowTcpForwarding yes
    X11Forwarding no

Se você quiser ser ainda mais seguro por restringindo onde eles podem tunelizar , você pode adicionar o parâmetro PermitOpen à configuração do SSH. Por exemplo, se você quiser permitir que apenas os usuários encaminhem para a porta 1337 no servidor atual, adicione PermitOpen localhost:1337 ao seu arquivo de configuração, logo abaixo da diretiva AllowTcpForwarding , assim:

Match Group noaccess
    AllowTcpForwarding yes 
    PermitOpen localhost:1337
    X11Forwarding no
    ...

Por fim, defina o shell dos usuários para /bin/true executando o comando chsh -s /bin/true <username> . Os usuários serão chutados silenciosamente (e com força) se tentarem iniciar qualquer tipo de sessão interativa. Se você quiser incluir uma mensagem de erro "amigável", poderá criar um shell "falso" rápido e sujo que retornará uma mensagem de erro.

O SSH fica bastante irritado quando não consegue acessar um shell, então você precisa passar o argumento de linha de comando -N para o comando OpenSSH da seguinte forma:

ssh [email protected] -N -L 3307:localhost:3306

Se você estiver usando o PuTTY, verifique se a caixa de seleção destacada está marcada:

Eu fui em frente e fiz um shell realmente simples ( não testado ) que retorna uma mensagem de erro, e também mantém a janela do terminal aberta para que -N seja desnecessário. Você pode encontrar a fonte aqui se quiser compilá-la e usá-la. Mesmo com isso, você ainda deve usar -N , mas não é mais necessário.

Opção 2: Deixe-os ser

Usuários no Linux já possuem um conjunto de permissões bastante aceitável. Eles podem ler arquivos que são relevantes para eles e são importantes para a funcionalidade do sistema. Ao mesmo tempo, arquivos que são "protegidos" (como chaves privadas e /etc/shadow ) já não permitem leituras de usuários não autorizados.

Se seus usuários já forem confiáveis (e realmente estiverem trabalhando em seu sistema), essa é a melhor opção - com o custo de manter os usuários fora de onde eles não pertencem

Opção 3: Segmentação seletiva

Se a Opção 2 ainda estiver muito insegura para suas necessidades, você poderá chmod o-rwx arquivos que não deseja que eles acessem. Exemplos destes incluem arquivos de configuração "seguros". No entanto, você deve ter muito cuidado para não perder serviços e aplicativos para os arquivos necessários para realizar seu trabalho.

Você também pode usar as Listas de controle de acesso para bloquear grupos de usuários fora dos arquivos, sem defini-los como o grupo proprietário . Eu aviso, no entanto, que isso é bastante envolvido, e abre uma maneira de permitir que os usuários "escapem" do seu conjunto confinado se encontrarem um usuário com shell que não esteja no grupo bloqueado.

Opção 4: chroot

O uso de chroot permite que você controle exatamente o que seus usuários têm acesso. Você decide quais permissões, quais comandos e assim por diante. Este é um método muito envolvido que precisa de muito trabalho para funcionar corretamente, por isso não é recomendado para todos.

Se você estiver interessado, esta pergunta explica isso muito bem.

    

Answer 2

Rodando

sudo chmod go-rwx /*

só permitiria que o root acessasse qualquer coisa no seu sistema que quebrasse tudo.

Veja Simple & amp; maneira fácil de prender usuários para melhorar as maneiras de restringir o que um usuário pode fazer.