Checklist: como auditar permissões de arquivo no Linux com find

16 min de leitura  ·  Guia técnico

Auditar permissões de arquivo no Linux com find é o processo de inspecionar sistematicamente os atributos de acesso de arquivos e diretórios em um servidor, identificando configurações inseguras antes que sejam exploradas. Para executar o checklist completo, siga estes passos:

1. Listar arquivos com permissão 777 no diretório web com find
2. Identificar binários com bit SUID ou SGID ativos no sistema
3. Localizar arquivos sem dono válido (orphan files)
4. Verificar arquivos graváveis por qualquer usuário fora do diretório web
5. Corrigir permissões incorretas com chmod e chown
6. Automatizar a auditoria via cron para execução periódica

Pré-requisitos para auditar permissões de arquivo no Linux

• Acesso root ou sudo ao servidor Linux (Debian 12, Rocky Linux 9, AlmaLinux 9 ou Ubuntu 24.04 LTS)
• Utilitário find instalado (presente por padrão em todas as distribuições)
• Shell Bash ou compatível (versão 5.x ou superior recomendada)
• Permissão para leitura recursiva nos diretórios a auditar (ex.: /var/www, /home, /etc)
• Espaço em disco suficiente para salvar logs de auditoria (mínimo 50 MB recomendado)
• Acesso SSH configurado — veja o guia Acessando servidores VPS Linux da AviraHost se precisar configurar o acesso

Por que auditar permissões de arquivo no Linux é crítico em servidores web

Permissões incorretas em servidores Linux são uma das causas mais comuns de comprometimento de aplicações web. Quando um arquivo PHP recebe permissão 777, qualquer processo no servidor — incluindo scripts maliciosos injetados via upload — pode sobrescrevê-lo ou executá-lo com privilégios indevidos. Em ambientes de hospedagem compartilhada ou VPS com múltiplos sites, o risco se multiplica.

O comando find é a ferramenta nativa mais poderosa para essa tarefa: ele permite filtrar arquivos por permissão exata, permissão parcial (bits específicos), proprietário, grupo, data de modificação e tipo. Combinado com chmod e chown, forma um pipeline completo de auditoria e correção sem dependências externas.

Além da segurança imediata, a auditoria regular de permissões é exigida por frameworks de conformidade como PCI-DSS (requisito 10.2) e ISO 27001. Servidores que hospedam e-commerce ou dados de cartão precisam de registros auditáveis de cada verificação realizada.

Para entender melhor como configurar seu servidor Linux para hospedagem segura desde o início, consulte o artigo Configurando um Servidor Linux para Hospedagem de Sites.

Checklist: como auditar permissões de arquivo no Linux com find — passo a passo

Passo 1: Listar arquivos com permissão 777

O primeiro item do checklist de auditoria de permissões é identificar arquivos com permissão total (leitura, escrita e execução para todos os usuários). Execute o comando abaixo no diretório raiz do seu site:

find /var/www -type f -perm 0777 -ls

Output esperado (exemplo com arquivos problemáticos encontrados):

123456  4 -rwxrwxrwx  1 www-data www-data  1024 Jan 10 14:32 /var/www/html/uploads/shell.php
123457  4 -rwxrwxrwx  1 www-data www-data   512 Jan 08 09:15 /var/www/html/cache/tmp.php

Se o comando não retornar nenhuma linha, não há arquivos com permissão 777 — o que é o resultado desejado. Para diretórios com permissão 777, use:

find /var/www -type d -perm 0777 -ls

Passo 2: Verificar arquivos graváveis por qualquer usuário

Além da permissão exata 777, arquivos com o bit de escrita ativo para "outros" (o+w) também representam risco. O parâmetro -perm /o+w captura qualquer arquivo onde outros usuários possam escrever:

find /var/www -type f -perm /o+w -ls 2>/dev/null

Output esperado:

123458  4 -rw-rw-rw-  1 deploy deploy  2048 Jan 09 11:00 /var/www/html/config/settings.php

Corrija imediatamente qualquer arquivo de configuração listado aqui:

chmod o-w /var/www/html/config/settings.php

Passo 3: Auditar binários com bit SUID e SGID

Binários com SUID (Set User ID) ou SGID (Set Group ID) executam com os privilégios do dono do arquivo, não do usuário que os invoca. Isso é legítimo em comandos como passwd e sudo, mas perigoso em binários desnecessários ou modificados.

find / -type f \( -perm -4000 -o -perm -2000 \) -ls 2>/dev/null

Output esperado (lista parcial de binários legítimos):

  12345  52 -rwsr-xr-x  1 root root  52880 Mar 28  2023 /usr/bin/passwd
  12346  36 -rwsr-xr-x  1 root root  35040 Mar 28  2023 /usr/bin/newgrp
  12347  68 -rwsr-xr-x  1 root root  67816 Mar 28  2023 /usr/bin/sudo

Compare a lista com os binários esperados para sua distribuição. Qualquer entrada desconhecida deve ser investigada. Para remover o bit SUID de um binário suspeito:

Atenção: remover o bit SUID de binários do sistema como passwd ou sudo tornará esses comandos inutilizáveis para usuários não-root. Remova apenas de binários que você identificou como desnecessários ou suspeitos.

chmod u-s /caminho/do/binario/suspeito

Passo 4: Localizar arquivos sem dono válido (orphan files)

Arquivos órfãos surgem quando um usuário é removido do sistema sem que seus arquivos sejam realocados. O UID numérico permanece no sistema de arquivos, mas não corresponde a nenhuma entrada em /etc/passwd. Isso pode ser explorado para escalonamento de privilégios se um novo usuário receber o mesmo UID.

find / -nouser -o -nogroup 2>/dev/null | head -50

Output esperado (exemplo de arquivo órfão):

/home/olduser/public_html/index.php
/tmp/olduser_session_data

Para cada arquivo encontrado, decida entre atribuir um dono válido ou remover:

chown www-data:www-data /home/olduser/public_html/index.php

Passo 5: Verificar permissões específicas do WordPress

Se o servidor hospeda WordPress, as permissões corretas são fundamentais para segurança e funcionamento. Aplique o padrão recomendado em lote:

find /var/www/html/wordpress -type f -exec chmod 644 {} \;
find /var/www/html/wordpress -type d -exec chmod 755 {} \;
chmod 600 /var/www/html/wordpress/wp-config.php

Verifique o resultado para o arquivo mais sensível:

ls -la /var/www/html/wordpress/wp-config.php

Output esperado:

-rw------- 1 www-data www-data 3218 Jan 10 10:00 /var/www/html/wordpress/wp-config.php

Passo 6: Verificar o proprietário dos arquivos web

Além das permissões numéricas, o proprietário dos arquivos deve corresponder ao usuário do processo web (Apache ou PHP-FPM). Arquivos pertencentes a root em diretórios web são um sinal de alerta:

find /var/www -not -user www-data -not -user deploy -ls 2>/dev/null

Substitua www-data e deploy pelos usuários legítimos do seu ambiente. Para corrigir em lote:

chown -R www-data:www-data /var/www/html/meusite

Passo 7: Automatizar a auditoria com cron

Para manter a auditoria de permissões contínua, crie um script e agende-o via cron. Crie o arquivo /usr/local/bin/audit-permissions.sh:

#!/bin/bash
LOGFILE="/var/log/audit-permissions-$(date +%Y%m%d).log"
echo "=== Auditoria de Permissões: $(date) ===" > "$LOGFILE"

echo "--- Arquivos com permissão 777 ---" >> "$LOGFILE"
find /var/www -type f -perm 0777 -ls 2>/dev/null >> "$LOGFILE"

echo "--- Diretórios com permissão 777 ---" >> "$LOGFILE"
find /var/www -type d -perm 0777 -ls 2>/dev/null >> "$LOGFILE"

echo "--- Binários SUID/SGID ---" >> "$LOGFILE"
find / -type f \( -perm -4000 -o -perm -2000 \) -ls 2>/dev/null >> "$LOGFILE"

echo "--- Arquivos sem dono ---" >> "$LOGFILE"
find /var/www -nouser -o -nogroup 2>/dev/null >> "$LOGFILE"

echo "Auditoria concluída. Log salvo em $LOGFILE"

Torne o script executável e agende no cron:

chmod +x /usr/local/bin/audit-permissions.sh
crontab -e

Adicione a linha para execução semanal às 3h da manhã toda segunda-feira:

0 3 * * 1 /usr/local/bin/audit-permissions.sh

Referência rápida: permissões seguras por tipo de arquivo

Manter um padrão de permissões consistente reduz a superfície de ataque e facilita auditorias futuras. Abaixo estão os valores recomendados para os tipos de arquivo mais comuns em servidores web Linux:

• Arquivos PHP, HTML, CSS, JS: 644 — dono lê e escreve, grupo e outros apenas leem
• Diretórios web: 755 — dono tem controle total, grupo e outros podem listar e entrar
• wp-config.php e arquivos de configuração com credenciais: 600 — somente o dono lê e escreve
• Scripts de shell em /usr/local/bin: 750 — dono executa, grupo executa, outros sem acesso
• Arquivos de log em /var/log: 640 — dono lê e escreve, grupo lê, outros sem acesso
• Chaves SSH privadas (~/.ssh/id_rsa): 600 — somente o dono acessa
• Diretório ~/.ssh: 700 — somente o dono acessa

Problemas comuns e como resolver

Sintoma: find retorna "Permission denied" em muitos diretórios

Causa: O usuário que executa o find não tem permissão de leitura em diretórios do sistema como /proc, /sys ou diretórios de outros usuários.
Solução: Execute o comando com sudo para obter acesso root, ou redirecione os erros para /dev/null com 2>/dev/null ao final do comando. Para auditorias de produção, sempre use root ou sudo para garantir cobertura completa.

Sintoma: Arquivos do WordPress perdem permissões após deploy

Causa: Ferramentas de deploy como rsync, Git ou FTP podem sobrescrever permissões ao transferir arquivos, especialmente se o umask do usuário de deploy for diferente do esperado.
Solução: Adicione o bloco de correção de permissões ao final do script de deploy. Use rsync --chmod=D755,F644 para definir permissões durante a transferência. Verifique também o umask do usuário de deploy com o comando umask — o valor recomendado é 0022. Para transferências via FTP, consulte o guia Como usar o Filezilla como software FTP da minha Hospedagem.

Sintoma: find -nouser não retorna resultados mesmo após remoção de usuário

Causa: O sistema de arquivos pode estar usando cache de UID/GID, ou o usuário foi removido mas seu UID foi imediatamente reutilizado por outro usuário criado em seguida.
Solução: Verifique se o UID do usuário removido ainda existe em /etc/passwd com getent passwd UID_NUMERO. Se um novo usuário recebeu o mesmo UID, os arquivos agora pertencem a ele — revise se isso é intencional. Use userdel --remove ao remover usuários para limpar arquivos automaticamente.

Sintoma: Script de auditoria cron não gera log

Causa: O cron executa com um ambiente mínimo, sem as variáveis de ambiente do usuário. Caminhos relativos ou variáveis não definidas causam falha silenciosa.
Solução: Use sempre caminhos absolutos no script (como /usr/bin/find em vez de apenas find). Adicione PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin no início do script. Verifique erros do cron em /var/log/syslog ou /var/log/cron com grep CRON /var/log/syslog | tail -20.

Sintoma: Permissões corretas mas site retorna erro 403 Forbidden

Causa: O erro 403 pode ocorrer mesmo com permissões corretas se o usuário do processo web (Apache ou PHP-FPM) não for o proprietário dos arquivos, ou se o SELinux/AppArmor estiver bloqueando o acesso.
Solução: Verifique o usuário do Apache com ps aux | grep apache e confirme que ele é o dono dos arquivos. Em sistemas com SELinux (Rocky Linux 9, AlmaLinux 9), verifique o contexto com ls -Z /var/www/html e restaure com restorecon -Rv /var/www/html.

Perguntas frequentes sobre auditoria de permissões de arquivo no Linux

Como encontrar arquivos com permissão 777 no Linux?

Execute o comando find /var/www -type f -perm 0777 para listar todos os arquivos com permissão total no diretório especificado. Permissões 777 concedem leitura, escrita e execução a qualquer usuário do sistema, representando risco grave em servidores web. Corrija com chmod 644 para arquivos e chmod 755 para diretórios. Para uma varredura mais ampla, substitua /var/www pelo diretório raiz / e adicione 2>/dev/null para suprimir erros de acesso.

Qual a permissão correta para arquivos do WordPress no Linux?

Arquivos do WordPress devem ter permissão 644 (leitura e escrita para o dono, somente leitura para grupo e outros) e diretórios devem ter 755. O arquivo wp-config.php deve ter permissão 600 ou 640 para restringir acesso ao proprietário. O dono dos arquivos deve ser o usuário do processo PHP-FPM ou Apache correspondente ao site — geralmente www-data no Debian/Ubuntu ou apache no Rocky Linux e AlmaLinux.

Como auditar arquivos SUID e SGID no servidor Linux?

Use find / -type f \( -perm -4000 -o -perm -2000 \) -ls para listar todos os binários com bit SUID ou SGID ativos. Esses bits permitem que o arquivo seja executado com os privilégios do dono ou grupo, o que pode ser explorado por atacantes caso o binário tenha vulnerabilidades. Revise cada resultado comparando com a lista de binários legítimos da sua distribuição, e remova o bit com chmod u-s /caminho/do/arquivo quando não for necessário.

Como verificar arquivos sem dono (orphan files) no Linux?

Execute find / -nouser -o -nogroup para localizar arquivos cujo UID ou GID não corresponde a nenhum usuário ou grupo existente no sistema. Esses arquivos surgem após remoção de usuários sem limpeza adequada e podem ser explorados para escalonamento de privilégios caso um novo usuário receba o mesmo UID numérico. Atribua um dono válido com chown usuario:grupo /caminho ou remova o arquivo se não for necessário.

Com que frequência devo auditar permissões em um servidor Linux de produção?

Em servidores de produção, recomenda-se executar a auditoria de permissões ao menos uma vez por semana, preferencialmente via cron automatizado com registro em log. Após qualquer deploy, instalação de plugin ou atualização de CMS, execute a auditoria imediatamente — essas operações são as que mais frequentemente alteram permissões de forma inadvertida. Ambientes com PCI-DSS ou outros requisitos de conformidade podem exigir auditorias diárias com registro em log auditável e imutável.

Conclusão

• Execute o checklist completo agora: rode os comandos find para permissão 777, SUID/SGID e arquivos órfãos no seu servidor — qualquer resultado inesperado deve ser corrigido antes de continuar.
• Automatize com cron: crie o script de auditoria apresentado neste guia e agende-o para execução semanal, salvando logs datados em /var/log/ para rastreabilidade.
• Padronize permissões por tipo: adote a tabela de referência (644 para arquivos, 755 para diretórios, 600 para configurações sensíveis) e integre a correção de permissões ao seu pipeline de deploy para evitar regressões.

Leia também

• Checklist Essencial para Migrar Sites Entre Hospedagens Linux com Segurança
• Checklist Completo para Configurar e Testar o Firewall UFW em VPS Linux e Servidores Dedicados
• Checklist de Segurança para Servidor Linux em Produção 2026

Precisa de ajuda com segurança e permissões no seu servidor Linux?

Manter permissões corretas é mais fácil quando você tem infraestrutura confiável como base. Os servidores VPS da AviraHost são entregues com Linux atualizado e suporte técnico disponível para ajudar na configuração segura do seu ambiente.

Conheça os planos de VPS Linux da AviraHost