NGINX

O NGINX substituiu o Apache na liderança do mercado principalmente devido à forma como lida com o tráfego moderno e a quantidade massiva de acessos simultâneos (o chamado problema C10K, ou seja, suportar 10.000 ligações concorrentes num único servidor).

A instalação do NGINX é um processo simples, mas os comandos variam conforme a distribuição Linux que estiver a utilizar.#

Antes de começar, certifique-se de que tem acesso como root ou utilizador com privilégios sudo.

Escolha abaixo o método correspondente ao seu sistema operativo:

Em Ubuntu, Debian, Linux Mint ou Pop!_OS (Sistemas Baseados em APT)#

Os repositórios oficiais destas distribuições já trazem sempre a versão estável mais recente do NGINX

# 1. Atualize a lista de pacotes do sistema
sudo apt update

# 2. Instale o NGINX
sudo apt install nginx -y

Em CentOS, RHEL, Rocky Linux ou AlmaLinux (Sistemas Baseados em RPM/DNF)#

Nas versões mais recentes (como o Rocky Linux 9), o NGINX está disponível através do gestor de pacotes padrão dnf.

# 1. Atualize os repositórios do sistema
sudo dnf update -y

# 2. Instale o servidor NGINX
sudo dnf install nginx -y

Gerir o Serviço NGINX (Para todos os sistemas)#

Após a instalação, o serviço do servidor precisa de ser iniciado e configurado para arrancar automaticamente junto com o Linux. Utilize os comandos do systemctl:

1. Iniciar o NGINX: sudo systemctl start nginx

2. Ativar no arranque do sistema: sudo systemctl enable nginx

3. Verificar o estado do servidor: sudo systemctl status nginx

Se o estado aparecer como active (running), o NGINX já está a funcionar corretamente.

O que é o Document Root em servidores Web?#

Se já configurou um servidor Linux para alojar um site, certamente já se deparou com caminhos como /var/www/html (no Apache) ou /usr/share/nginx/html (no NGINX). Esse local tem um nome técnico oficial: Document Root (ou Web Root).

Em termos simples, o Document Root é o diretório público principal do seu servidor. É a pasta raiz onde o servidor web (como o NGINX ou o Apache) vai procurar os ficheiros do seu site (como o index.html, imagens e scripts) quando alguém digita o seu domínio no navegador.

Nunca trabalhe no Document Root como Root! Saiba o motivo#

Ao instalar um servidor web como o NGINX ou o Apache no Linux, a pasta pública padrão (o Document Root) é criada automaticamente pelo sistema sob a propriedade do utilizador root.

Se tentar criar um ficheiro lá dentro com o seu utilizador normal, vai deparar-se com o erro "Permission denied". A tentação imediata de muitos administradores iniciantes é usar o comando sudo para tudo ou dar permissão total (777). Isto é um erro grave de segurança.

Por que é uma má prática trabalhar como root no Document Root?

Risco de Segurança Crítico: O NGINX corre no sistema com um utilizador de baixos privilégios (como nginx ou www-data). Se der permissões de root a ficheiros da web e o seu site sofrer um ataque ou invasão, o hacker poderá ganhar controlo sobre partes sensíveis de todo o sistema operativo.

Bloqueio de Ficheiros: Se criar ficheiros usando o sudo, o dono deles será o root. Mais tarde, quando tentar atualizar o site via Git, FTP ou scripts automatizados com o seu utilizador normal, o sistema vai bloquear a operação, gerando erros constantes de permissão.

A Solução Ideal#

A boa prática dita que deve alterar o dono (owner) do Document Root para o utilizador comum que usa para aceder ao servidor (como o ec2-user na AWS) e definir o grupo para o utilizador do próprio servidor web (nginx).

Desta forma, consegue gerir os seus ficheiros com total segurança e sem precisar de recorrer ao sudo.

Se estiver com Amazon Linux, o utilizador padrão chama-se ec2-user e o grupo do servidor web chama-se nginx.

Como corrigir as permissões do Document Root de forma segura#

Para resolver o problema do "Permission denied" sem comprometer a segurança do servidor, precisamos de fazer duas coisas: mudar o dono (owner) da pasta para o nosso utilizador do dia a dia e mudar o grupo para o utilizador que o NGINX usa.

No Amazon Linux, o utilizador padrão chama-se ec2-user e o grupo do servidor web chama-se nginx

Utilize o comando chown (change owner) com a flag -R (recursivo, para aplicar a todas as pastas e ficheiros lá dentro):

sudo chown -R ec2-user:nginx /usr/share/nginx/html

Agora, o ec2-user pode criar e editar ficheiros livremente, e o nginx consegue ler os ficheiros para os mostrar na web.

Ajustando as permissões de leitura e escrita#

# Define permissões ideais para as pastas (755)
sudo find /usr/share/nginx/html -type d -exec chmod 755 {} \;

# Define permissões ideais para os ficheiros (644)
sudo find /usr/share/nginx/html -type f -exec chmod 644 {} \;

Opcional (Se o seu site precisar de receber Uploads)#

Se o seu site tiver um sistema onde os visitantes fazem uploads de imagens ou ficheiros (como um site WordPress), o NGINX precisará de permissão para escrever numa pasta específica. Nesse caso, mude o dono dessa pasta específica para o próprio NGINX:

sudo chown -R nginx:nginx /usr/share/nginx/html/nome-da-pasta-de-uploads

Desvendando o Mistério do Chmod 2775 e o SetGID#

Se já consultou os manuais da AWS para configurar um servidor, certamente reparou que eles não recomendam a permissão padrão 755 ou 775 para as pastas web. Em vez disso, a Amazon diz para usar o número 2775.

O que faz o número "2" (SetGID)?#

Normalmente, as permissões do Linux usam apenas 3 dígitos (Dono, Grupo e Outros). O quarto dígito, colocado à esquerda, ativa permissões especiais. O número 2 ativa o SetGID (Set Group ID) num diretório.

Numa pasta normal, quando cria um novo ficheiro, ele herda automaticamente o grupo do utilizador que o criou. Mas num servidor web partilhado, isto causa problemas: se o seu utilizador ec2-user criar um ficheiro, o grupo dono será o ec2-user, e o NGINX (grupo nginx) não conseguirá ler nem alterar esse ficheiro, bloqueando o site.

O SetGID (2) resolve isto de forma mágica: ele força o sistema operativo a garantir que qualquer nova pasta ou ficheiro criado ali dentro herde automaticamente o grupo da pasta pai (neste caso, o nginx), independentemente de quem o criou.

Para aplicar a recomendação exata da AWS no seu Document Root, execute:

# Aplica a permissão 2775 em todas as pastas
sudo find /usr/share/nginx/html -type d -exec chmod 2775 {} \;

# Mantém os ficheiros com a permissão padrão segura (0664)
sudo find /usr/share/nginx/html -type f -exec chmod 0664 {} \;

NGINX vs Apache: Segurança por Padrão (Out of the Box)#

Para quem está a dar os primeiros passos na administração de servidores, um dos choques mais comuns surge ao comparar o comportamento de fábrica do NGINX com o do Apache. Quando falamos de segurança e exposição de dados, o NGINX vence por larga margem no quesito "seguro por padrão".

O Cenário: O que acontece sem um ficheiro de Índice?#

Imagine que criou uma pasta chamada /test no seu servidor para guardar alguns ficheiros internos, mas esqueceu-se de colocar lá dentro um ficheiro de índice (como o index.html ou index.php).

Se um utilizador comum tentar aceder a ://o-seu-dominio.como comportamento varia drasticamente consoante o servidor web utilizado:

• No NGINX (Comportamento Seguro): O servidor assume uma postura defensiva. Ele bloqueia imediatamente o acesso público, gerando um erro 403 Forbidden. A estrutura das suas pastas e ficheiros permanece oculta.

• No Apache (Comportamento Vulnerável): Por padrão em muitas distribuições Linux, o Apache tem a diretiva Options Indexes ativa. Isto significa que ele vai gerar o famoso e antiquado "Index of /test", listando publicamente todos os ficheiros, scripts e subpastas que lá estiverem dentro para qualquer pessoa ver (e descarregar).

Por que razão isto importa?#

A exposição de diretórios (Directory Listing) é uma das falhas de segurança mais fáceis de evitar, mas que continua a expor o código-fonte de aplicações, ficheiros de configuração com passwords e uploads privados por toda a internet.

Ao optar pelo NGINX, ganha não só a performance massiva contra o problema C10K, mas também a tranquilidade de saber que o seu servidor protege a sua árvore de ficheiros por defeito.