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

Estou brincando com o bind e comecei a me perguntar por que esse software está, por exemplo, no CentOS em execução no chroot. Não me entenda mal, eu sei o que é bind e para que serve chroot (prisão). Mas minha pergunta principal é que o bind é executado sem chroot tão inseguro?

É realmente prejudicial configurá-lo sem uma prisão (mais que qualquer outro serviço ou software). Nos sistemas, existem muitos processos em execução sem chroot e acho que o comprometimento de qualquer um deles é muito perigoso, mas o que torna o nome mais perigoso do que outro software executando sem chroot?

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

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

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

Um chroot é uma tentativa muito fraca de criar algo como uma VM. Os chroots podem ser evitados 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 uma prisão BSD ou LXC oferece virtualização no nível do SO e fornece recursos de segurança. Atualmente, porém, como é tão fácil ativar 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 SO para esse fim.

As 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 ouvir no udp / 53 e tcp / 53. Como o Bind inicia como raiz e não descarta privilégios, qualquer comprometimento significaria que todo o sistema poderia ser comprometido. Atualmente, quase todos os softwares começam a abrir seus soquetes e fazem qualquer outra coisa que exija privilégios de root; depois, eles mudam o usuário que estão executando como uma conta não privilegiada. Depois que os privilégios são eliminados, o impacto de ser comprometido é muito menor para o sistema host.

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 que o adversário deve superar. Colocar BIND em um chroot adiciona mais um obstáculo.

Digamos que exista uma vulnerabilidade explorável no BIND e alguém possa executar código arbitrário. Se eles estão em um chroot, precisam sair disso antes de chegar a qualquer outra coisa no sistema. Como mencionado, privilégios de root são necessários para quebra de chroot. O BIND não roda como root, e supõe-se haver ferramentas mínimas disponíveis no chroot, limitando ainda mais as opções e deixando essencialmente apenas as chamadas do sistema. Se não houver uma chamada do sistema para aumentar os privilégios, o adversário ficará parado olhando os seus registros DNS.

A situação acima mencionada é um pouco improvável, como SomeGuy menciona, o BIND tem poucas vulnerabilidades atualmente e está restrito 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 vários sistemas operacionais, por isso é improvável que você se esforce para manter a segurança um pouco maior.

preâmbulo

eu continuo ouvindo as pessoas reiterar conceitos errôneos de toda a internet .. assim, tentarei dar alguns esclarecimentos

primeiramente; Quantas descobertas acidentais ocorreram, as quais simplesmente ... devido a causa e efeito , acabaram sendo usadas para algo diferente do objetivo a que se destina?

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

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

O chroot foi usado de maneira eficaz e está diretamente na base de código de vários programas e bibliotecas (por exemplo, openSSHd, apache2 + mod_security2 / mod_chroot, dovecot, sendmail, openVPN, pam_chroot e muito mais ). supor que todos esses aplicativos convencionais implementaram soluções de segurança com defeito simplesmente não é verdade

O chroot é uma solução para a 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 ... desde que você siga as diretrizes de execução de processos dentro da prisão de chroot.

algumas etapas para proteger sua prisão chroot

isto é, NÃO execute processos como ROOT. isso pode abrir um vetor de escalação raiz (que também é verdade dentro ou fora do chroot). não execute um processo dentro do chroot, usando o mesmo usuário que outro processo fora do 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 fim, o chroot NÃO substitui a segurança do sistema básico. 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 processo que foi esterilizada. com medidas de segurança em vigor em hardware e dispositivos. a maioria dos 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 implantar o 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 para não apenas todos no Node ou no data center, mas também para a Internet como um todo ...

como afirmado, 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. de alguma outra maneira, comprometa algo que reside dentro da prisão - escapando da prisão normalmente através de escalonamento de privilégios ou injetando sua carga no sistema básico.

se isso acontecer, geralmente é o resultado de uma atualização incorreta, exploração de dia zero ou erro 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 privado virtual, com o nó host executando o OpenVZ. você simplesmente não pode executar nada 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. portanto, você DEVE usar o chroot para esse fim.

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

considere outro cenário: você tem o apache em execução em um ambiente virtualizado. você deseja separar cada usuário. fornecer um sistema de arquivos virtualizado por meio de um chroot add-on para o 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 mais uma camada de segurança.

Simplificando, é importante implementar a segurança em camadas . Chroot potencialmente sendo um deles. nem todo mundo e todo sistema tem o luxo de ter acesso ao Kernel; portanto, o chroot STILL serve a um propósito. há uma variedade de aplicativos em que a virtualização do sistema completo é essencialmente um exagero.

Em resposta à sua pergunta

Não uso particularmente o CentOS, mas sei que o Bind agora remove seus privilégios antes das operações. Eu assumiria, no entanto, que o vínculo é chroot devido ao seu histórico de vetores de ataque e possíveis vulnerabilidades.

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

os provedores de sistemas operacionais simplesmente não andam 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 qual tantos aplicativos usam isso e, obviamente, o sistema operacional o faz 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 invasor em potencial deve superar - na maioria das vezes, restringindo os danos causados ​​apenas à prisão chroot.

Isso se deve parcialmente a razões históricas, quando as versões mais antigas do Bind tinham vulnerabilidades de segurança graves e frequentes. Ainda não me atualizei sobre o assunto, mas aposto que melhorou muito desde os dias ruins.

O outro motivo, o mais prático, é que ele geralmente é implantado em uma função voltada para a Internet e, como tal, está aberto a mais ataques, investigações e travessuras em geral.

Portanto, como costuma ser a regra de ouro em questões de segurança: é melhor prevenir do que remediar, principalmente porque o esforço de fazer chroot é relativamente pequeno.