followsymlinks no apache porque é um risco de segurança

Question

That said, symlinks aren't necessarily bad but you have to have a clear understanding of your implementation of Apache. To a non-chrooted Apache, symlinks certainly pose a significant risk to exposing files outside of your document root.

Eu recebi isso de um tópico antigo que já foi respondido. Eu queria saber como links de sistema podem expor outros arquivos externos a raiz do documento? Eu pensei que eles apontam apenas para um diretório. Eu não teria que adicionar especificamente o link simbólico para permitir que um hacker saia da raiz do documento? Além disso, como um chroot ajuda nesta instância

    

Answer 1

Muitas vezes, você executa aplicativos web reais dentro do seu servidor web (php, perl, whatever). Esses aplicativos da web normalmente têm acesso de gravação a algum diretório dentro da raiz do documento para fazer upload de material.

Agora, pode haver um bug dentro de seu aplicativo da Web que permitiria que um invasor criasse arquivos arbitrários dentro de sua raiz da web (e provavelmente também links simbólicos). Isso pode até ser possível quando você não tem um componente de upload real, mas apenas o bug. Esses bugs não são tão incomuns que você deve ignorá-los. Especialmente aplicativos como o wordpress têm uma longa história desse tipo de bugs.

Agora que um invasor pode criar arquivos e links simbólicos dentro de sua raiz da web, ele pode permitir que esses links simbólicos apontem para arquivos arbitrários em seu servidor da web ( /etc/passwd , arquivos de configuração com senhas de texto não criptografado, ...) que poderiam significar um invasor pode baixar todos esses arquivos e usar as informações coletadas para ataques posteriores, como ataques de dicionário na senha do SSH, acesso autorizado simples ao seu banco de dados, ...)

Se você restringir o seu Apache para não seguir links simbólicos, esse vetor de ataque é muito mais difícil de explorar. Outra medida de segurança igualmente importante é restringir o acesso de leitura a apenas arquivos absolutamente necessários para o usuário do servidor web / aplicativo da web. Você também pode usar o servidor de aplicativos externo (comum em aplicativos python e ruby, mas também com configurações de fcgi) e executá-lo com outro usuário que não o usuário principal do servidor da web. Se você restringir o acesso a arquivos importantes entre esse usuário e o usuário do servidor da Web, poderá obter um nível de segurança bastante alto.

Outra alternativa seria chroot seu apache para a raiz do documento, caso em que o sistema operacional garantiria que os processos do Apache não acessem nenhum arquivo fora da raiz do documento. Note que isto é bastante difícil de conseguir com os pacotes em distribuições comuns.

    

Answer 2

Digamos que eu consiga entrar no seu servidor, mas sei que você fechará a lacuna em breve (talvez seja uma senha simbólica RSA que muda a cada 60 segundos e por acaso tenho a senha pelos próximos 30 segundos). Ou eu só tenho 30 segundos para implantar minha porta dos fundos em seu servidor, porque você deixou seu terminal aberto e eu sei que você estará de volta em breve e eu sou um oppertunist.

A coisa mais rápida e fácil para mim é fazer um link simbólico de / para dizer htdocs/mysuperhiddendirectory/ e agora posso navegar em todo o seu sistema de arquivos remotamente.

Se você estiver executando o apache como chroot , então o symlinking / será vinculado apenas à raiz desse processo, não à raiz real do SO.