Nginx, www-data, e se preocupa em hospedar vários sites sob o mesmo pai

3

Tenho uma pergunta sobre o usuário do Nginx e do www-data no meu VPS.

Digamos que eu tenha dois sites siteA e siteB em uma pasta pai comum /var/www . Ambos os sites e a pasta pai têm www-data como usuário e grupo. Se o siteA for comprometido / hackeado, o hacker poderá acessar os arquivos em siteB ?

Eu li em outro post que, para evitar isso, eu deveria executar cada site sob seu próprio usuário e grupo. Como eu iria conseguir isso com o Nginx?

Adicional:
siteA é um site WordPress usando php-fpm e siteB será um aplicativo NodeJS

    
por Dani 02.05.2017 / 16:21

1 resposta

1

Vale notar que o tipo de ataque que você está perguntando (desfiguração do site) é uma forma de ataque relativamente pouco frequente. Os hackers geralmente estão mais interessados em roubar dados e / ou seqüestrar todo o seu servidor. Também é relativamente fácil combater o desfiguramento simplesmente substituindo o conteúdo do site. A menos que você tenha um inimigo determinado, isso muitas vezes o impedirá enquanto você rastreia a vulnerabilidade que o levou.

Dito isto, sim, a configuração que você descreve apresenta uma superfície de ataque maior do que ter sites separados, e sim, há coisas que você pode fazer para reduzir essa superfície.

A primeira coisa que você pode fazer é usar grupos e usuários padrão do Linux para negar completamente o acesso de gravação a todo o conteúdo do site estático e código-fonte. Você pode fazer isso criando um usuário www-admin e chown todo o conteúdo para esse usuário. Depois, tenha um usuário (ou usuários) diferente para os programas e serviços. Um usuário comum de serviço da web é o usuário nobody, mas usuários com finalidades especiais, como www ou http, também podem trabalhar. Coloque conteúdo estático e código-fonte em seus próprios diretórios, de propriedade de www-admin, com permissão 755 nos diretórios e 644 nos arquivos. Isso impedirá que qualquer alteração no seu site por um serviço ou aplicativo da Web comprometido. Você pode afinar isso ainda mais com os grupos, se quiser, por motivos de conveniência, mas, para fins de segurança, essa configuração de propriedade protegerá seus arquivos contra o desfoque baseado na Web e será fácil de implementar e manter.

Por padrão, o nginx não aceita solicitações HTTP TRACE, DELETE ou PUT. No entanto, é uma boa ideia testar isso:

curl -v -X TRACE "http://www.example.com"
curl -v -X DELETE "http://www.example.com/dummy-page.html"
echo evil > ./test4evil.txt
curl -v -X PUT "http://www.example.com" -F "file=./test4evil.txt"

Você deve obter 405 respostas (não permitidas) para esses testes.

Se você quiser que os visitantes do site possam fazer upload de conteúdo, crie diretórios especiais somente para o conteúdo do usuário para isso e atribua permissões de gravação restritas a esses diretórios para os aplicativos / serviços que fazem o upload. Por pouco, quero evitar dar permissão de gravação para usuários ou grupos que não precisam escrever para esse diretório.

Tudo isso trata de arquivos apenas no disco. Uma vez que seus sites geram conteúdo dinamicamente, você também deve se certificar de lidar com injeção de php, injeção de SQL e outras explorações potenciais relacionadas ao conteúdo dinâmico. No entanto, esse é um tópico diferente e a questão aqui é apenas sobre como evitar alterações em arquivos no disco.

    
por 04.05.2017 / 19:59