Por que executar o nomeado(bind) no chroot é tão importante para a segurança? Ou talvez não seja?

Question 1

Como @Some Guy mencionou, você precisa pensar sobre isso em uma perspectiva histórica.

A perspectiva histórica era que uma única peça de hardware representava cerca de uma dúzia de serviços diferentes em um único sistema operacional. Se um serviço fosse comprometido, tudo nesse hardware seria comprometido.

Com a virtualização, isso é um problema muito menor. Embora não seja impossível escapar de uma VM, isso está longe de ser trivial. Certamente é mais difícil sair de uma VM do que um processo executado com privilégios de root sair de um chroot. Portanto, meus servidores de ligação estão sendo executados em sua própria VM. Realmente não há muito sentido em um chroot nesse caso, pois o dano já é limitado simplesmente pelo fato de ser uma VM.

Um chroot é uma tentativa muito fraca de criar algo como uma VM. Chroots podem ser escapados por qualquer processo com privilégios de root. Um chroot não se destina e não funciona como um mecanismo de segurança. Um chroot com prisão BSD ou LXC oferece virtualização no nível do sistema operacional e fornece recursos de segurança. Mas hoje em dia, sendo tão fácil criar uma nova VM de uma máquina inteira, pode não valer a pena o esforço de configuração ou aprender como usar as ferramentas de virtualização no nível do sistema operacional para essa finalidade.

Versões anteriores do bind não eliminavam privilégios. No Unix, apenas a conta root pode abrir portas abaixo de 1024, e o Bind, como todos sabemos, precisa escutar em udp/53 e tcp/53. Como o Bind começa como root e não elimina privilégios, qualquer comprometimento significaria que todo o sistema poderia ser comprometido. Quase todos os softwares hoje em dia começarão a abrir seus soquetes e fazer qualquer outra coisa que exija privilégios de root, então eles mudarão o usuário que estão executando para uma conta não privilegiada. Depois que os privilégios são eliminados, o impacto do comprometimento é muito menor para o sistema host.

Answer

Como @Some Guy mencionou, você precisa pensar sobre isso em uma perspectiva histórica.

A perspectiva histórica era que uma única peça de hardware representava cerca de uma dúzia de serviços diferentes em um único sistema operacional. Se um serviço fosse comprometido, tudo nesse hardware seria comprometido.

Com a virtualização, isso é um problema muito menor. Embora não seja impossível escapar de uma VM, isso está longe de ser trivial. Certamente é mais difícil sair de uma VM do que um processo executado com privilégios de root sair de um chroot. Portanto, meus servidores de ligação estão sendo executados em sua própria VM. Realmente não há muito sentido em um chroot nesse caso, pois o dano já é limitado simplesmente pelo fato de ser uma VM.

Um chroot é uma tentativa muito fraca de criar algo como uma VM. Chroots podem ser escapados por qualquer processo com privilégios de root. Um chroot não se destina e não funciona como um mecanismo de segurança. Um chroot com prisão BSD ou LXC oferece virtualização no nível do sistema operacional e fornece recursos de segurança. Mas hoje em dia, sendo tão fácil criar uma nova VM de uma máquina inteira, pode não valer a pena o esforço de configuração ou aprender como usar as ferramentas de virtualização no nível do sistema operacional para essa finalidade.

Versões anteriores do bind não eliminavam privilégios. No Unix, apenas a conta root pode abrir portas abaixo de 1024, e o Bind, como todos sabemos, precisa escutar em udp/53 e tcp/53. Como o Bind começa como root e não elimina privilégios, qualquer comprometimento significaria que todo o sistema poderia ser comprometido. Quase todos os softwares hoje em dia começarão a abrir seus soquetes e fazer qualquer outra coisa que exija privilégios de root, então eles mudarão o usuário que estão executando para uma conta não privilegiada. Depois que os privilégios são eliminados, o impacto do comprometimento é muito menor para o sistema host.

Question 2

As outras respostas são muito boas, mas não mencionam o conceito de segurança em camadas. Cada camada de segurança que você adiciona ao seu sistema é outra camada que um adversário deve superar. Colocar o BIND em um chroot adiciona mais um obstáculo.

Digamos que haja uma vulnerabilidade explorável no BIND e alguém seja capaz de executar código arbitrário. Se eles estiverem em um chroot, eles precisam sair dele antes de acessar qualquer outra coisa no sistema. Como mencionado, privilégios de root são necessários para quebrar o chroot. O BIND não roda como root, e supostamente há ferramentas mínimas disponíveis no chroot, limitando ainda mais as opções e essencialmente deixando apenas chamadas de sistema. Se não houver chamada de sistema para escalar privilégios, o adversário ficará preso olhando seus registros DNS.

A situação acima mencionada é um tanto improvável, como SomeGuy menciona, o BIND tem poucas vulnerabilidades atualmente e elas estão restritas principalmente a cenários do tipo DoS, em vez de execução remota. Dito isto, rodar em um chroot é a configuração padrão em alguns sistemas operacionais, então é improvável que você precise de algum esforço para manter a segurança ligeiramente aumentada.

Answer

As outras respostas são muito boas, mas não mencionam o conceito de segurança em camadas. Cada camada de segurança que você adiciona ao seu sistema é outra camada que um adversário deve superar. Colocar o BIND em um chroot adiciona mais um obstáculo.

Digamos que haja uma vulnerabilidade explorável no BIND e alguém seja capaz de executar código arbitrário. Se eles estiverem em um chroot, eles precisam sair dele antes de acessar qualquer outra coisa no sistema. Como mencionado, privilégios de root são necessários para quebrar o chroot. O BIND não roda como root, e supostamente há ferramentas mínimas disponíveis no chroot, limitando ainda mais as opções e essencialmente deixando apenas chamadas de sistema. Se não houver chamada de sistema para escalar privilégios, o adversário ficará preso olhando seus registros DNS.

A situação acima mencionada é um tanto improvável, como SomeGuy menciona, o BIND tem poucas vulnerabilidades atualmente e elas estão restritas principalmente a cenários do tipo DoS, em vez de execução remota. Dito isto, rodar em um chroot é a configuração padrão em alguns sistemas operacionais, então é improvável que você precise de algum esforço para manter a segurança ligeiramente aumentada.

Question 3

preâmbulo

continuo ouvindo pessoas reiterando conceitos errados de toda a internet.. portanto, tentarei dar alguns esclarecimentos

primeiramente;quantas descobertas acidentais ocorreram, que simplesmente.. devido acausa e efeito, acabou sendo usado para alguma coisaoutrodo que a finalidade pretendida?

o que era e o que é uma prisão Chroot

Chroot foi inicialmente projetado para alterar o diretório raiz do processo ou usuário (ótimo para compilar software de fontes desconhecidas). isso é fornecidosegurançaao sistema base, bem como um aparelho de teste rápido, incluindo fácil limpeza. anos se passaram desde então, e seu conceito e usos implícitos certamente mudaram, da mesma forma.

chroot foi usadoefetivamente, e está diretamente na base de código paradiversosprogramas e bibliotecas (ou seja, openSSHd, apache2 + mod_security2/mod_chroot, dovecot, sendmail, openVPN, pam_chroot,e muito mais). presumir que todos esses aplicativos convencionais implementaram soluções de segurança defeituosas é simplesmenteNão é verdade

chroot é uma solução para virtualização de sistemas de arquivos: nada menos, nada mais. a suposição de que você pode facilmente sair de um chroot também não é verdadeira... contanto que você siga as diretrizes de execução de processos dentro da prisão chroot.

alguns passos para proteger sua prisão chroot

ou seja, façoNÃOexecute processos como ROOT. isso poderia abrir um vetor de escalonamento raiz (o que também é verdadeiro dentro ou fora do chroot). não execute um processodentroo chroot, usando o mesmo usuário de outro processoforao chroot. separe cada processo e usuário em seu próprio Chroot para limitar as superfícies de ataque e fornecer privacidade. monte apenas arquivos, bibliotecas e dispositivos necessários. por último, chroot NÃO substitui a segurança básica do sistema. proteger o sistema em sua totalidade.

outra observação importante:muitas pessoas pensam que o OpenVZ está quebrado ou que não é igual em comparação com a virtualização completa do sistema. eles fazem essa suposição porque é essencialmente um Chroot, com uma tabela de processos que foi esterilizada. com medidas de segurança em vigor em hardware e dispositivos.maioriados quais você pode implementar em um chroot.

nem todo administrador tem o nível de conhecimento necessário para proteger todos os parâmetros necessários do kernel em um servidor dedicado ou sob virtualização completa do sistema. isso significa que a implantação do OpenVZ significa que seus clientes terão muito menos superfície de ataque para tentar cobrir e proteger antes de implantar seus aplicativos. um bom host fará um bom trabalho protegendo esses parâmetros e, por sua vez, isso é melhor não apenas para todos no Node ou no data center, mas para a Internet como um todo...

conforme declarado, o chroot fornece virtualização do sistema de arquivos. você deve garantir que não haja executáveis setuid, aplicativos inseguros, bibliotecas, links simbólicos sem proprietário pendentes, etc. se o invasor PUDER comprometer a ligação, ele precisará vasculhar o sistema de arquivos virtual em busca de algo para saturação de buffer, brincar com descritores de arquivo ou de alguma outra forma, compromete algo que reside dentro do chroot - escapando da prisão geralmente por meio de escalonamento de privilégios ou injetando sua carga útil no sistema básico.

se isso acontecer, geralmente é o resultado de uma atualização incorreta, exploração de dia zero ouerro humano idiomático.

por que o chroot ainda é usado, em oposição à virtualização completa do sistema

considere este cenário: você está executando um servidor virtual privado, com o nó host executando OpenVZ. você simplesmentenão podeexecute qualquer coisa que funcione no nível do kernel. isso também significa que você não pode usar a virtualização do sistema operacional para separar processos e fornecer segurança adicional. assim, vocêDEVEuse chroot para esse propósito.

além disso, o chroot é sustentável em qualquer sistema, independentemente dos recursos disponíveis. Simplificando, ele tem a menor sobrecarga de qualquer tipo de virtualização. isso significa que ainda é importante em muitas caixas de baixo custo.

considere outro cenário: você tem o Apache rodando dentro de um ambiente virtualizado. você deseja separar cada usuário. fornecer um sistema de arquivos virtualizado por meio de um complemento chroot ao apache (mod_chroot, mod_security, etc) seria a melhor opção para garantir a máxima privacidade entre os usuários finais. isso também ajuda a impedir a coleta de informações e oferece outra camada de segurança.

Simplificando, é importante implementar segurança emcamadas. Chroot é potencialmente um deles. nem todo mundo e todo sistema tem o luxo de ter acesso ao Kernel, portanto, chrootAINDAserve a um propósito. há uma variedade de aplicativos nos quais a virtualização completa do sistema é essencialmente um exagero.

Em resposta à sua pergunta

eu particularmente não uso o CentOS, mas sei que o Bind agora elimina seus privilégios antes das operações. eu presumiria, no entanto, que o bind está em chroot devido ao seu histórico de vetores de ataque e vulnerabilidades potenciais.

também... faz mais sentido fazer chroot automaticamente neste aplicativo do que não, porque nem TODOS têm acesso à virtualização completa no nível do sistema/sistema operacional. isso, por sua vez, e em teoria, ajuda a fornecer segurança à base de usuários do CentOS:

os fornecedores de sistemas operacionais simplesmente não saem por aí assumindo que todos estão executando o mesmo sistema. dessa forma, eles podem ajudar a fornecer uma camada adicional de segurança em geral...

há uma razão pela qualtantos aplicativos usam issoe por que obviamente o seu sistema operacional funciona por padrão: porque É usado como um recurso de segurança e FUNCIONA. com uma preparação cuidadosa, como afirmado anteriormente, é mais um obstáculo que o potencial invasor deve superar - na maioria das vezes, restringindo os danos causados apenas à prisão chroot.

Answer