Implementação de um Servidor LAMP com WordPress no Debian 13

Implementação e Hardening Básico de um Servidor LAMP com WordPress no Debian 13

Estudo de caso de laboratório | Administração Linux · Virtualização · Hospedagem web · Segurança de arquivos
Ambiente: rede local, VM Debian 13 sobre libvirt/KVM
Endereço de acesso: http://192.168.0.6
Atualização das evidências: outubro de 2026

1. Identificação do Problema

O objetivo do laboratório foi aprender a administrar serviços Linux e compreender, na prática, a integração da pilha LAMP — Linux, Apache, MariaDB e PHP — na hospedagem de uma aplicação real. O WordPress foi escolhido para exercitar o processamento de requisições web, a conexão com banco de dados, o gerenciamento de arquivos e a validação dos serviços.

O desafio foi construir um ambiente funcional a partir de uma instalação mínima do Debian, sem depender de uma plataforma de hospedagem gerenciada. Além de colocar o site no ar na rede local, o exercício incluiu uma revisão posterior das permissões do sistema de arquivos, com correção e testes efetivos.

Escopo: ambiente educacional, sem alegação de alta disponibilidade, segurança completa ou prontidão para produção.

2. Panorama Geral da Solução

Foi criada uma VM Debian GNU/Linux 13 (Trixie) no ambiente libvirt/KVM, executado em um host também Debian 13. A VM utiliza interface de rede em bridge, segundo a configuração informada, e possui endereço IPv4 fixo 192.168.0.6/24.

O Apache atende a aplicação pela porta HTTP 80; o PHP executa o WordPress; e o MariaDB armazena os dados da aplicação em banco com usuário exclusivo. O WordPress foi obtido do site do projeto usando wget e instalado na raiz web /var/www/html.

Após a implantação, as permissões foram revistas para separar a propriedade dos arquivos de código da conta de execução do servidor web. O resultado foi verificado com comandos executados como www-data e com testes funcionais no navegador e no painel do WordPress.

3. Aplicabilidade e Cenários

Embora seja um laboratório, o projeto reproduz tarefas presentes em ambientes reais de hospedagem de aplicações PHP:

• instalação e operação de um servidor Linux com recursos limitados;
• configuração de serviços web, linguagem de execução e banco de dados;
• organização de rede virtual e acesso por endereço IP local;
• administração de permissões e identificação de configurações permissivas;
• testes de funcionamento, leitura de logs e diagnóstico básico;
• preparação para uma futura camada de monitoramento.

A arquitetura também serve como base de estudo para aplicações internas, protótipos e ambientes de homologação. Não há exposição pública deliberada nem configuração HTTPS demonstrada. Como a VM possui também um endereço IPv6 global, a alegação de acesso restrito à LAN descreve o uso pretendido, não comprova, por si só, uma restrição efetiva de roteamento ou filtragem.

4. A Estrutura da Solução

4.1. Infraestrutura e recursos

---

4.2. Serviços e aplicação

O Apache relatou o aviso AH00558 por não ter um ServerName global definido. Esse aviso, isoladamente, não impediu o funcionamento do serviço. A versão do PHP apresentada corresponde ao interpretador de linha de comando, e a do MariaDB, ao cliente: ainda não foram coletadas evidências independentes das versões efetivamente utilizadas pelo Apache e pelo daemon do banco.

4.3. Arquitetura lógica

flowchart TD
    CLIENTE["Navegador na rede local"] -->|"HTTP · 192.168.0.6:80"| REDE["Rede local / bridge"]
    REDE --> APACHE
    subgraph VM["VM Debian 13 · 2 vCPU · ~2 GB RAM · 20 GB"]
        APACHE["Apache 2.4.68 · DocumentRoot /var/www/html"] --> PHP["WordPress / PHP"]
        PHP <-->|"Consultas SQL"| DB[("MariaDB · banco dedicado")]
        PHP --> UP["wp-content/uploads · escrita autorizada"]
    end

O diagrama descreve os componentes lógicos, não substitui uma auditoria de portas, roteamento, TLS ou exposição IPv6.

4.4. Fluxo de uma requisição

sequenceDiagram
    participant N as Navegador
    participant A as Apache / PHP
    participant W as WordPress
    participant B as MariaDB
    N->>A: GET http://192.168.0.6/
    A->>W: Processamento da aplicação
    W->>B: Consulta de dados
    B-->>W: Resultado
    W-->>A: Conteúdo gerado
    A-->>N: Resposta HTTP

4.5. Modelo de permissões após correção

Os comandos de ajuste aplicados incluíram mudança de propriedade para root:www-data no código, modos padrão 755 para diretórios e 644 para arquivos, exceção 640 para wp-config.php e propriedade www-data para uploads. Isso diminui a capacidade do processo web de modificar o código da aplicação. Não elimina outros riscos, como plugins vulneráveis, execução de scripts enviados em uploads, credenciais fracas ou falta de HTTPS.

5. Abordagem Estratégica Adotada

A execução combinou implantação por componentes, validação do funcionamento e uma segunda rodada de melhorias após análise das evidências:

1. Provisionamento: instalação mínima do Debian 13 em VM no ambiente KVM/QEMU.
2. Rede: uso de bridge e endereço 192.168.0.6 para acesso pela LAN.
3. Serviços: instalação do Apache, PHP e MariaDB, com verificação da disponibilidade dos serviços.
4. Banco: criação de banco de dados e usuário exclusivos do WordPress.
5. Aplicação: obtenção do WordPress com wget e disponibilização em /var/www/html.
6. Validação inicial: acesso pelo navegador, integração com MariaDB, testes após reinício e consulta de logs.
7. Revisão de permissões: identificação de wp-config.php inicialmente em modo 666 e de código gravável por www-data.
8. Correção e reteste: separação da propriedade dos arquivos, escrita concentrada em uploads e confirmação do painel e do envio de imagens.

flowchart TD
    A["Instalação mínima da VM"] --> B["Rede bridge + IPv4 fixo"]
    B --> C["Instalar Apache, PHP e MariaDB"]
    C --> D["Banco e usuário dedicados"]
    D --> E["Instalar WordPress com wget"]
    E --> F{"WordPress acessível na LAN?"}
    F -- Não --> G["Revisar serviços e logs"]
    G --> F
    F -- Sim --> H["Auditar permissões"]
    H --> I["Corrigir propriedade e modos"]
    I --> J["Validar como www-data"]
    J --> K["Testar painel e uploads"]
    K --> L["Registrar evidências"]

O fluxograma apresenta a sequência lógica documentada, não uma transcrição literal de todos os comandos digitados durante a instalação.

6. Impacto e Resultados Esperados

6.1. Resultados obtidos

• Aplicação operacional: WordPress acessível no navegador pelo endereço http://192.168.0.6.
• Serviços disponíveis: Apache e MariaDB observados ativos e habilitados para inicialização automática.
• Integração funcional: comunicação entre WordPress/PHP e MariaDB validada no uso da aplicação, conforme teste informado.
• Persistência operacional: ambiente testado após reinicialização, segundo relato do autor.
• Segurança de arquivos melhorada: permissões corrigidas e verificadas diretamente no sistema.
• Aplicação preservada: painel administrativo e envio de imagens continuaram funcionando após as mudanças, conforme confirmação do autor.

6.2. Evidência objetiva do teste de permissões

Comandos executados como root, usando o caminho absoluto de runuser:

/usr/sbin/runuser -u www-data -- test -r /var/www/html/wp-config.php && echo "Leitura OK"
/usr/sbin/runuser -u www-data -- test -w /var/www/html/wp-content/uploads && echo "Uploads OK"
/usr/sbin/runuser -u www-data -- test ! -w /var/www/html/wp-admin && echo "wp-admin protegido"

Saída obtida:

Leitura OK
Uploads OK
wp-admin protegido

Isso comprova, para o usuário www-data e os caminhos testados, leitura do arquivo de configuração, escrita no diretório de uploads e ausência de escrita em wp-admin. Não é um teste de invasão nem uma auditoria completa do WordPress.

6.3. Competências exercitadas

O laboratório consolidou práticas de provisionamento, manutenção de serviços, interpretação de comandos Linux, gerenciamento de permissões, integração de camadas web e banco de dados e verificação de hipóteses por evidências.

7. Evolução e Próximas Etapas

O próximo objetivo é adicionar monitoramento, ainda sem ferramenta escolhida. Os indicadores de interesse incluem CPU, memória, espaço disponível, disponibilidade HTTP, estado de Apache/MariaDB e análise de logs.

Outras melhorias recomendadas, não apresentadas como concluídas, incluem:

• testar backups e restauração do WordPress e do banco de dados;
• avaliar HTTPS e regras efetivas de acesso antes de qualquer publicação externa;
• revisar a exposição IPv6 e as portas em escuta;
• estabelecer um processo de atualização do Debian, WordPress, temas e plugins;
• verificar a possibilidade de execução de PHP em diretórios de upload;
• configurar ServerName se fizer sentido para o laboratório;
• verificar e documentar a versão do WordPress e as versões efetivas dos serviços em execução.

As regras persistentes de iptables não foram configuradas e, portanto, não fazem parte da implementação documentada.

8. Considerações Finais

O projeto cumpriu seu propósito educacional: foi implantado um servidor LAMP funcional sobre uma VM Debian 13, capaz de hospedar o WordPress e atender dispositivos da rede local. O laboratório permitiu acompanhar a relação entre sistema operacional, rede, servidor HTTP, PHP, banco de dados e aplicação.

Um dos resultados mais relevantes surgiu após a instalação: a identificação e a correção de permissões excessivas. Essa etapa mostrou que administrar um servidor não se resume a colocar serviços em execução, mas também exige revisitar configurações, limitar privilégios e validar alterações sem interromper as funcionalidades necessárias.

A evolução natural será acrescentar monitoramento, ampliar a documentação de evidências e continuar o fortalecimento operacional do ambiente.

Diagrama de Fluxo — Visualização Ampliada

100%1:1